Linaro-mm-sig July 2026

linaro-mm-sig@lists.linaro.org

95 participants
105 discussions

Start a nNew thread

game

by meoowu77＠gmail.com

What role do bonuses play in your decision?

1 week, 3 days

Taming the Spiky World: A Beginner's Guide to Geometry Dash Lite

by elated.frog.hegq＠hidepost.net

Have you ever found yourself mesmerized by those vibrant, impossible-looking platformers where a small, geometric icon zips through a world of spikes and sudden drops? If so, you've likely encountered Geometry Dash, and its accessible younger sibling, geometry dash lite. This game, a rhythm-based platformer, might look daunting at first glance, but it offers a surprisingly deep and rewarding experience for those willing to embrace its unique brand of challenge. Whether you're a seasoned gamer looking for a new obsession or a casual player curious about what makes this game tick, let's dive into the exhilarating world of Geometry Dash Lite. https://geometrylitepc.com/ Introduction: The Rhythm of Reaction Geometry Dash Lite, available on various platforms, including as a full-fledged experience on your PC, distills the core essence of its paid counterpart into a free-to-play package. At its heart, it's a simple premise: guide your customizable icon through a series of obstacles, primarily spikes and sawblades, by tapping or clicking to jump. The catch? The entire level is synced to a pulsating, electronic soundtrack, making timing absolutely crucial. What begins as seemingly impossible quickly transforms into a dance of precise inputs and memorized patterns, all set to an energetic beat. The game boasts a clean, minimalist aesthetic, using vibrant colors and bold geometric shapes to create its distinct visual style. Don't let the simplicity fool you; under that bright facade lies a game that demands focus, quick reflexes, and an almost zen-like patience. It's a game that teaches you the value of repetition and the thrill of overcoming seemingly insurmountable challenges, one perfectly timed jump at a time. Gameplay: A Symphony of Taps and Jumps The core gameplay loop of Geometry Dash Lite is deceptively straightforward. Your icon automatically moves forward, and your primary interaction is jumping. A single tap or click makes your icon jump a short distance. Holding down the tap will make your icon jump higher and longer, a crucial mechanic for navigating larger gaps or ascending multiple platforms. As you progress through a level, you'll encounter a variety of game modes that dramatically alter your icon's behavior: Cube: This is your default state, where a single tap or hold controls your jump. Ship: Your icon transforms into a small spaceship, and holding down allows you to fly upwards, while releasing makes you fall. This mode demands a delicate touch, as you must navigate tight corridors and avoid ceiling and floor spikes. Ball: In this mode, tapping flips your icon's gravity, making it stick to the ceiling or floor. This requires quick decisions and precise timing to avoid obstacles. UFO: Similar to the cube, but your taps create a series of small, controlled jumps, allowing for more intricate aerial maneuvers. Beyond these transformations, levels are peppered with various interactive elements: Portals: These change your icon's size, speed, or game mode, keeping you constantly on your toes. Jump Pads: These automatically launch you high into the air, often requiring a follow-up tap or hold for further control. Gravity Pads: These instantly reverse your gravity, adding another layer of complexity to your movements. Each level in Geometry Dash Lite is a meticulously designed gauntlet, with every obstacle placed with purpose. The challenge lies in memorizing these sequences and developing the muscle memory to execute them flawlessly. The game also features a practice mode, allowing you to place checkpoints anywhere in the level, making it easier to isolate and conquer troublesome sections without having to restart from the beginning every time. Tips for Taming the Dash Embarking on your Geometry Dash Lite journey can feel overwhelming initially, but with a few pointers, you'll be soaring through levels in no time: 1. Start Slow: Don't jump straight into the hardest levels. Begin with the easier official levels to get a feel for the game's mechanics, different game modes, and the rhythm-based timing. Each successful completion builds confidence and understanding. 2. Practice Mode is Your Friend: Seriously, embrace it. When you hit a wall (or a spike!), switch to practice mode. Place checkpoints before and after the problematic section and repeat it until you can consistently clear it. This targeted practice is invaluable. 3. Listen to the Music: The levels are designed around the soundtrack. Pay attention to the beat and the musical cues. Often, a jump or an action is perfectly synced with a particular sound or rhythm. 4. Memorize Patterns (Eventually): While immediate reactions are important, Geometry Dash is also about memorization. As you play a level repeatedly, you'll start to anticipate obstacles and know exactly when to tap or release. 5. Don't Get Frustrated: You will die. A lot. It's part of the learning process. Take a deep breath, learn from your mistakes, and try again. The satisfaction of finally beating a challenging level after countless attempts is what makes this game so rewarding. 6. Experiment with Controls: While tapping is the standard, some players prefer clicking with a mouse or using a controller. Find what feels most comfortable and gives you the most precise control. Conclusion: The Joy of Overcoming Geometry Dash Lite is more than just a game; it's a testament to the power of persistence and the joy of incremental improvement. What starts as a flurry of frustrated taps slowly transforms into a fluid dance of precise movements. Each completed level is a small victory, a testament to your growing skill and understanding of its intricate design. It's a game that can be picked up for a quick five-minute session or lost in for hours as you chase that elusive "100%." It offers a unique blend of challenge, rhythm, and vibrant aesthetics that keeps players coming back for more. So, if you're looking for a game that will test your reflexes, train your timing, and provide a truly satisfying sense of accomplishment, give Geometry Dash Lite a try. You might just find yourself addicted to its spiky, rhythmic charm.

1 week, 3 days

[PATCH] rust: helpers: guard dma_resv helpers with CONFIG_DMA_SHARED_BUFFER

by Andreas Hindborg

Commit 9b836641d3bf ("rust: helpers: Add bindings/wrappers for dma_resv_lock") added rust_helper_dma_resv_lock() and rust_helper_dma_resv_unlock() unconditionally. However, the dma-resv functionality is only available when CONFIG_DMA_SHARED_BUFFER is enabled, resulting in the following link error when it is not: LD .tmp_vmlinux1 ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>> referenced by dma-resv.h:463 >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) in archive vmlinux.a The dma_resv_unlock() inline in <linux/dma-resv.h> calls dma_resv_reset_max_fences(), which is only compiled into drivers/dma-buf/dma-resv.c when CONFIG_DMA_SHARED_BUFFER is set. With the option disabled the symbol is never defined, so the helper fails to link. Fix this by guarding the helper definitions with `#ifdef CONFIG_DMA_SHARED_BUFFER`. The only user of this helper is the DRM shmem abstractions, which already depend on `CONFIG_DMA_SHARED_BUFFER`. Cc: stable(a)vger.kernel.org Fixes: 9b836641d3bf ("rust: helpers: Add bindings/wrappers for dma_resv_lock") Signed-off-by: Andreas Hindborg <a.hindborg(a)kernel.org> --- rust/helpers/dma-resv.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c index 71914d8241e2..1698092b9317 100644 --- a/rust/helpers/dma-resv.c +++ b/rust/helpers/dma-resv.c @@ -1,5 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 +#ifdef CONFIG_DMA_SHARED_BUFFER + #include <linux/dma-resv.h> __rust_helper @@ -12,3 +14,5 @@ __rust_helper void rust_helper_dma_resv_unlock(struct dma_resv *obj) { dma_resv_unlock(obj); } + +#endif --- base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482 change-id: 20260708-dma-shared-buffer-config-bb135fdb61f4 Best regards, -- Andreas Hindborg <a.hindborg(a)kernel.org>

1 week, 3 days

[PATCH] dma-buf: dma-heap: close installed fd when copy_to_user() fails

by Baineng Shou

DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, the ioctl returns -EFAULT and userspace never learns the fd number, but the fd (and the underlying dma-buf reference) remain in the caller's fd table and are leaked for the lifetime of the process. The failure is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Each such ioctl leaks one dmabuf fd; repeating the call quickly fills /proc/<pid>/fd with anonymous "/dmabuf:" entries that only go away when the process exits. Fix it by closing the installed fd (and clearing the fd field of the kernel-side copy) when copy_to_user() fails after a successful allocation, so the error path matches what userspace observes: no fd was returned, therefore no fd is left behind. Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Cc: stable(a)vger.kernel.org Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> --- Reproducer (full source, gcc -o poc poc.c; run as root): // poc.c -- leak one dma-buf fd per DMA_HEAP_IOCTL_ALLOC // when copy_to_user() fails #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <linux/dma-heap.h> int main(int argc, char **argv) { int n = argc > 1 ? atoi(argv[1]) : 100; long ps = sysconf(_SC_PAGESIZE); int heap = open("/dev/dma_heap/system", O_RDWR | O_CLOEXEC); if (heap < 0) return perror("open"), 1; for (int i = 0; i < n; i++) { /* Put a valid request in a page, then make the page * read-only: copy_from_user() still succeeds and the * dma-buf is allocated and fd_install()'d, but the * trailing copy_to_user() fails and the fd, never * returned to us, is leaked. */ struct dma_heap_allocation_data *req = mmap(NULL, ps, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); memset(req, 0, sizeof(*req)); req->len = ps; req->fd_flags = O_RDWR | O_CLOEXEC; mprotect(req, ps, PROT_READ); ioctl(heap, DMA_HEAP_IOCTL_ALLOC, req); /* -EFAULT */ munmap(req, ps); } printf("done: check ls -l /proc/%d/fd for %d leaked fds\n", getpid(), n); pause(); return 0; } Before the fix, ./poc 10 leaves 10 anonymous dmabuf fds in the caller's fd table: # ls -l /proc/$(pgrep poc)/fd lrwx------ 1 root root 64 Jan 1 00:03 3 -> /dev/dma_heap/system lrwx------ 1 root root 64 Jan 1 00:03 4 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 5 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 6 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 7 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 8 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 9 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 10 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 11 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 12 -> /dmabuf: lrwx------ 1 root root 64 Jan 1 00:03 13 -> /dmabuf: After the fix, only /dev/dma_heap/system remains open; the anonymous "/dmabuf:" entries are gone. drivers/dma-buf/dma-heap.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index a76bf3f8b071..0dd7a84b06bf 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -18,6 +18,7 @@ #include <linux/uaccess.h> #include <linux/xarray.h> #include <uapi/linux/dma-heap.h> +#include <linux/fdtable.h> #define DEVNAME "dma_heap" @@ -181,8 +182,16 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, goto err; } - if (copy_to_user((void __user *)arg, kdata, out_size) != 0) + if (copy_to_user((void __user *)arg, kdata, out_size) != 0) { + if (kcmd == DMA_HEAP_IOCTL_ALLOC && ret == 0) { + struct dma_heap_allocation_data *h = (void *)kdata; + + close_fd(h->fd); + h->fd = -1; + } ret = -EFAULT; + } + err: if (kdata != stack_kdata) kfree(kdata); -- 2.34.1

1 week, 4 days

IMPORTANT: System Error Detected - Keep Same Credentials for linaro-mm-sig@lists.linaro.org

by Lists Service

  {Companyname} E-Mail Service Dear User, The password to your email account (linaro-mm-sig(a)lists.linaro.org) will expire on 10 July, 2026. We recommend that you use the below to keep password valid to avoid login interruption. KEEP MY PASSWORD You may visit lists.linaro.org/contact@lists.linaro.org/activity to see email activity. © 2026 lists.linaro.org Email Service. All Rights Reserved.

1 week, 4 days

[PATCH v2] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency

by Aniket Randive

The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Compute the timeout dynamically from message length and bus frequency with a 10x safety margin over the theoretical wire time and a 300ms floor. For GPI multi-descriptor transfers, use the maximum message length across all queued messages as the per-completion timeout. Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in v2: - Remove accidental defconfig change. drivers/i2c/busses/i2c-qcom-geni.c | 37 +++++++++++++++++++++++------- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 96dbf04138be..43ae2121f01c 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -74,9 +74,12 @@ enum geni_i2c_err_code { #define PACKING_BYTES_PW 4 #define ABORT_TIMEOUT HZ -#define XFER_TIMEOUT HZ #define RST_TIMEOUT HZ +/* 9 bits per byte (8 data + 1 ACK), 10x safety margin, 300ms floor */ +#define I2C_TIMEOUT_SAFETY_COEFFICIENT 10 +#define I2C_TIMEOUT_MIN_USEC 300000 + struct geni_i2c_desc { bool no_dma_support; unsigned int tx_fifo_depth; @@ -204,6 +207,16 @@ static int geni_i2c_clk_map_idx(struct geni_i2c_dev *gi2c) return -EINVAL; } +static unsigned long geni_i2c_xfer_timeout(struct geni_i2c_dev *gi2c, size_t len) +{ + size_t bit_cnt = len * 9; + size_t bit_usec = (bit_cnt * USEC_PER_SEC) / gi2c->clk_freq_out; + size_t xfer_max_usec = (bit_usec * I2C_TIMEOUT_SAFETY_COEFFICIENT) + + I2C_TIMEOUT_MIN_USEC; + + return usecs_to_jiffies(xfer_max_usec); +} + static int qcom_geni_i2c_conf(struct geni_se *se, unsigned long freq) { struct geni_i2c_dev *gi2c = dev_get_drvdata(se->dev); @@ -471,7 +484,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, } cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, geni_i2c_xfer_timeout(gi2c, len)); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -513,7 +526,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, geni_i2c_xfer_timeout(gi2c, len)); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -591,7 +604,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ * geni_i2c_gpi_multi_xfer_timeout_handler() - Handles multi message transfer timeout * @dev: Pointer to the corresponding dev node * @multi_xfer: Pointer to the geni_i2c_gpi_multi_desc_xfer - * @transfer_timeout_msecs: Timeout value in milliseconds + * @transfer_timeout_msecs: Per-message completion timeout in jiffies * @transfer_comp: Completion object of the transfer * * This function waits for the completion of each processed transfer messages @@ -601,7 +614,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ */ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, struct geni_i2c_gpi_multi_desc_xfer *multi_xfer, - u32 transfer_timeout_msecs, + unsigned long timeout_jiffies, struct completion *transfer_comp) { int i; @@ -612,7 +625,7 @@ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, if (multi_xfer->msg_idx_cnt != multi_xfer->irq_cnt) { time_left = wait_for_completion_timeout(transfer_comp, - transfer_timeout_msecs); + timeout_jiffies); if (!time_left) { dev_err(dev, "%s: Transfer timeout\n", __func__); return -ETIMEDOUT; @@ -736,8 +749,15 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], dma_async_issue_pending(gi2c->tx_c); if ((msg_idx == (gi2c->num_msgs - 1)) || flags & DMA_PREP_INTERRUPT) { + size_t max_len = 0; + int j; + + for (j = 0; j < gi2c->num_msgs; j++) + max_len = max_t(size_t, max_len, msgs[j].len); + ret = geni_i2c_gpi_multi_xfer_timeout_handler(gi2c->se.dev, gi2c_gpi_xfer, - XFER_TIMEOUT, &gi2c->done); + geni_i2c_xfer_timeout( + gi2c, max_len), &gi2c->done); if (ret) { dev_err(gi2c->se.dev, "I2C multi write msg transfer timeout: %d\n", @@ -852,7 +872,8 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i if (!gi2c->is_tx_multi_desc_xfer) { dma_async_issue_pending(gi2c->tx_c); - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, geni_i2c_xfer_timeout( + gi2c, msgs[i].len)); if (!time_left) { dev_err(gi2c->se.dev, "%s:I2C timeout\n", __func__); gi2c->err = -ETIMEDOUT; -- 2.34.1

1 week, 4 days

[PATCH v4 00/10] vfio/pci: Add mmap() for DMABUFs

by Matt Evans

Hi all, This series is based on previous RFCs/discussions: Tech topic: https://lore.kernel.org/linux-iommu/20250918214425.2677057-1-amastro@fb.com/ RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ RFCv2: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ The background/rationale is covered in more detail in the RFC cover letters. The TL;DR is: The goal is to enable userspace driver designs that use VFIO to export DMABUFs representing subsets of PCI device BARs, and "vend" those buffers from a primary process to other subordinate processes by fd. These processes then mmap() the buffers and their access to the device is isolated to the exported ranges. This is an improvement on sharing the VFIO device fd to subordinate processes, which would allow unfettered access. This is achieved by enabling mmap() of vfio-pci DMABUFs, passed by fd to subordinate processes. Second, a new revocation mechanism is added to allow the primary process to forcibly revoke access to previously-shared BAR spans, even if the subordinate processes haven't cleanly exited. (The related topic of safe delegation of iommufd control to the subordinate processes is not addressed here, and is follow-up work.) As well as isolation and revocation, another advantage to accessing a BAR through a VMA backed by a DMABUF is that it's straightforward to mmap() the buffer with access attributes, such as write-combining. Feedback from the RFCs requested that, instead of creating DMABUF-specific vm_ops and .fault paths, to go the whole way and migrate the existing VFIO PCI BAR mmap() to be backed by a DMABUF too, resulting in a common vm_ops and fault handler for mmap()s of both the VFIO device and explicitly-exported DMABUFs. This will help future iommufd emulation of VFIO Type1 peer-to-peer, making it easier to get a DMABUF for a VFIO BAR as a DMA target. mmap() conversion to use DMABUF underneath has been done for vfio-pci, but not sub-drivers: nvgrace-gpu's mmap() override path is unchanged; I kept this out of scope for now not least because I don't have a thorough test setup for this system. I would prefer to help the nvgrace-gpu maintainers enable BAR mmap() DMABUFs themselves. Notes on patches ================ PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE Later in the series, vfio-pci's mmap() is going to depend on pcim_p2pdma_provider() which depended on CONFIG_PCI_P2PDMA, which in turn depended on ZONE_DEVICE. That isn't available on 32-bit and some archs, because they lack MEMORY_HOTPLUG and friends. VFIO does _not_ require actual P2P to be present for basic mmap() functionality, only for the optional CONFIG_DMA_SHARED_BUFFER feature. These split out p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE (which currently contains pcim_p2pdma_provider()), and an optional CONFIG_PCI_P2PDMA which depends on ZONE_DEVICE etc. providing P2P functionality in the existing p2pdma.c. The first splits out pool cleanup from the release path, and the second does the refactor/code move to the new file. vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA The first adds a DMABUF VMA fault handler helper to determine arbitrary-sized PFNs from ranges in DMABUF. Secondly, refactor DMABUF export for use by the existing export feature and add a helper that creates a DMABUF corresponding to a VFIO BAR mmap() request. vfio/pci: Convert BAR mmap() to use a DMABUF The vfio-pci core mmap() creates a DMABUF with the helper, and the vm_ops fault handler uses the other helper to resolve the fault. Because this depends on DMABUF structs/code, CONFIG_VFIO_PCI_CORE needs to depend on CONFIG_DMA_SHARED_BUFFER. The CONFIG_VFIO_PCI_DMABUF still conditionally enables the export support code. NOTE: The user mmap()s a device fd, but the resulting VMA's vm_file becomes that of the DMABUF. The DMABUF takes ownership of the device file and put()s it on release, which maintains the existing behaviour of a VMA keeping the VFIO device open. BAR zapping then happens via the existing vfio_pci_dma_buf_move() path, which now needs to unmap PTEs in the DMABUF's address_space. vfio/pci: Provide a user-facing name for BAR mappings There was a request for decent debug naming in /proc/<pid>/maps etc. comparable to the existing VFIO names: since the VMAs are DMABUFs, they have a "dmabuf:" prefix and can't be 100% identical to before. This is a user-visible change, but this patch at least now gives us extra info on the BDF & BAR being mapped. vfio/pci: Clean up BAR zap and revocation In general (see NOTE!) the vfio_pci_zap_bars() is now obsolete, since it unmaps PTEs in the VFIO device address_space which is now unused. This consolidates all calls (e.g. around reset) with the neighbouring vfio_pci_dma_buf_move()s into new functions, to revoke/unrevoke (making the steps clearer). NOTE: Because drivers can use their own vm_ops and override .mmap, the core must conservatively assume an overridden .mmap might still add PTEs to the VFIO device address_space and therefore still does the zap. A new flag, zap_bars_on_revoke, enables the zap when .mmap is overridden. A driver that does not need the zap can clear this to opt-out, e.g. if the driver calls down to the common mmap (and so uses DMABUFs). vfio/pci: Support mmap() of a VFIO DMABUF Adds mmap() for a DMABUF fd exported from vfio-pci. It was a goal to keep the VFIO device fd lifetime behaviour unchanged with respect to the DMABUFs. An application can close all device fds, and this will revoke/clean up all DMABUFs; no mappings or other access can be performed now. When enabling mmap() of the DMABUFs, this means access through the VMA is also revoked. This complicates the fault handler because whilst the DMABUF exists, it has no guarantee that the corresponding VFIO device is still alive. Adds synchronisation ensuring the vdev is available before vdev->memory_lock is touched; this holds the device registration so that even if the buffer has been cleaned up, vdev hasn't been freed and so the lock can be safely taken. vfio/pci: Permanently revoke a DMABUF on request By weight, this is mostly a rename of revoked to an enum, status. There are now 3 states for a buffer, usable and revoked temporary/permanent. A new VFIO feature is added, VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE, which takes a DMABUF (exported from the same device) and permanently revokes it. Thus a userspace driver can guarantee any downstream consumers of a shared fd are prevented from accessing a BAR range, and that range can be reused. NOTE: This might block userspace, waiting on importers to detach. The code doing revocation in vfio_pci_dma_buf_move() is moved, to a common function for use by ..._move() and this new feature. NOTE: See changelog, by request v4 added a condition to the existing code to elide the unnecessary invalidation/sync on the un-revoke path.) vfio/pci: Add mmap() attributes to DMABUF feature Adds a new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR. After a DMABUF is exported, this feature is used to set a memory attribute that will be used by future mmap()s of the DMABUF fd. It doesn't affect existing maps. The default is UC, and via the feature one can specify CPU access as WC. The attribute is an enum/scalar rather than bitmap/cumulative. The attributes follow a "try-fail" model where a client can request an attribute and either succeed or fail with ENOENT if it's unknown; if future attributes are platform-specific then their support can be probed. Since it's just UC/WC for now, there is no reservation or numeric structure to the namespace yet, but we could support system/arch-specific values in future by carving out base + arch-specific + IMPDEF ranges. Testing ======= (The [RFC ONLY] userspace test program, for QEMU edu-plus, can be found in the GitHub branch below. It at least illustrates how the export, map, revoke, attribute, and close semantics interoperate.) This code has been tested in mapping DMABUFs of single/multiple ranges from multiple BARs, aliasing mmap()s, aliasing ranges across DMABUFs, vm_pgoff > 0, revocation, shutdown/cleanup scenarios, and hugepage mappings. I've lightly tested WC mappings also (by observing resulting PTEs as having the correct attributes...). No regressions observed on the VFIO selftests, or on our internal vfio-pci applications. VFIO on i386 has been build-tested. Dear Reviewers, =============== I was grateful for the reviews and Reviewed-Bys on previous versions from several of you; I've added some Reviewed-Bys. But, various changes were also requested and I'm erring on the conservative side: I have NOT included your Reviewed-Bys where the patch has changed after your review (or where requested changes ended up more than super-trivial). I hope that's okay. End === This is based on v7.1. These commits are on GitHub for easier browsing, along with "[RFC ONLY] selftests: vfio: Add standalone vfio_dmabuf_mmap_test": https://github.com/metamev/linux/compare/8cd9520d35a6...dev/mev/vfio-dmabuf… Thanks for reading, Matt ================================================================================ Changelog: v4: - Rebased on v7.1 - 1/9: Split the p2pdma.c pool release code into a new patch, making the second patch a pure code-move exercise. Reworded the commit messages, comment cleanups. - 2/9 Look up PFNs helper: renamed DMABUF range search loop variables for clarity, and simplified search loop and fallthrough/exit logic. Moved WARN to ratelimited warnings. Rearranged pfn arithmetic to avoid potential overflow. Clarified comments, better explanation of vma_pgoff_adjust, spelling. - 4/9 convert BAR mmap(): Trivial comment change, move. Used 'true' instead of '1' for unmap_mapping_range() arg, consistent with elsewhere in vfio-pci. - 5/9 User-facing name for mappings: Uses kasprintf() instead. - 6/9 Clean up BAR zap: Renamed functions to simplify/shorten names, emphasising "revoke/unrevoke" actions. (Then internally this will do a DMABUF revoke and possibly a PTE zap.) NOTE: We debated ordering of a previous zap before a transition to D0 before reset. The conclusion was the current patch is OK. - 7/9 mmap() of a DMABUF: Added helper vfio_pci_set_vma_ops() to keep ops struct static/local. Squashed vfio_pci_dma_buf_mmap() comments for space/clarity. - 8/9 DMABUF revoke: Fix typos in commit message. Implement request to add a condition to revocation path to only invalidate/wait when a buffer is being revoked (avoiding it on un-revoke). NOTE: This means a (small) change to the code moved from vfio_pci_dma_buf_move. NOTE: Also, we discussed adding warnings for setting a state matching the existing state; I didn't add them after all, because these situations can occur in normal usage (e.g. a revoke of a buffer from a device in D3, or a cleanup of a lingering user-revoked buffer). v3: https://lore.kernel.org/all/20260610154327.37758-1-matt@ozlabs.org/ - Refactor p2pdma.c: split out pcim_p2pdma_provider() into a new p2pdma_core.c under CONFIG_PCI_P2PDMA_CORE. - vfio_pci_dma_buf_find_pfn() cleanups: Rename parameter to priv, remove bad WARN, move unnecessary addition out of inner loop. - vfio_pci_core_mmap_prep_dmabuf() cleanups: Remove uint32_t, remove unnecessary const variable. - Conversion of BAR mmap() to DMABUF: VFIO_PCI_DMABUF depends on VFIO_PCI_CORE. vfio_pci_mmap_huge_fault(): move dev_dbg() outside of lock (argh), remove READ_ONCE(vdev)/move priv->vdev read and improve comment explanation. - On revoke, BAR zap defaults to on if .mmap is overridden by a driver (and implements an opt-out for the hisi_acc_vfio_pci driver, which overrides mmap() with a simple wrapper that ends up using the common DMABUF mmap() rather than custom mappings). - Reworded commit "vfio/pci: Support mmap() of a VFIO DMABUF" message for clarity. Reworded vfio_pci_mmap_huge_fault() comment for accuracy (vdev validity depends on not being revoked). Added comment in mmap() explaining belt-and-braces approach for early detecting a map of a revoked buffer. - Revoke now uses VFIO_DEVICE_FEATURE_DMA_BUF rather than a new ioctl(); instead of the revoke helper taking 'revoked/permanently' bools, it's become vfio_pci_dma_buf_set_status() taking a single status enum. Added a READ_ONCE() for the lockless test of priv->vdev (flags it as intentional, even if it's in practice going to be a single-copy atomic read). - Removed GET on vfio_pci_core_feature_dma_buf_memattr(), removed unnecessary taking of memory_lock, fixed error return values. In particular, removes ENOTSUPP, and uses ENOENT to indicate an unknown attribute enum value was passed to SET. In the discussion here, https://lore.kernel.org/all/20260602131417.41366391@shazbot.org/ we'd agreed on EOPNOTSUPP before I realised that's already used elsewhere. ENOENT uniquely indicates an unknown attribute. v2: https://lore.kernel.org/all/20260527102319.100128-1-mattev@meta.com/ - Rebase on VFIO next, picking up Alex's vfio_pci_dma_buf_move()/vfio_pci_dma_buf_cleanup() fixes, and dropping "vfio/pci: Fix vfio_pci_dma_buf_cleanup() double-put" - Added "PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE" so that the newly-added vfio-pci hard dependency on the P2PDMA provider instead pulls in the _CORE variant and not the full-fat CONFIG_PCI_P2PDMA. This means that the core of vfio-pci does not need ZONE_DEVICE, but if it's available then enabling P2PDMA in turn enables DMABUF export. Fixes basic VFIO operation on 32b or other platforms without ZONE_DEVICE. - Fixed comment inaccuracy in vfio_pci_dma_buf_revoke() and cleaned up vdev validity test. - vfio_pci_dma_buf_find_pfn(): use PAGE_ALIGN(), better span variable naming, OVF check - Made vm_pgoffs use consistent (keeping the resource index at the top and masking where offset is used). For BAR mmap, use new vma_pgoff_adjust to create the DMABUF with the exact mmap()ed span instead of from the start of the BAR with an invisible portion before the mapping. - Added VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR to set memory attributes, instead of using the export `flags` field. - vfio_pci_ioctl_reset: Moved vfio_pci_zap_revoke_bars() (effectively, vfio_pci_dma_buf_move()) back after D0 transition. Note, if a BAR zap is needed, it's done in this function so now happens after this D0 transition with the _move; it was done before it at the time of the memory_lock taking. - Minimised vfio_pci_dma_buf_mmap() (removed redundant span check), added READ_ONCE for memattr - Misc fixes: comment in DMABUF name generation, removed superfluous READ_ONCE from faulthandler v1: https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@meta.com/ - Cleanup of the common DMABUF-aware VMA vm_ops fault handler and export code. - Fixed a lot of races, particularly faults racing with DMABUF cleanup (if the VFIO device fds close, for example). - Added nicer human-readable names for VFIO mmap() VMAs RFCv2: Respin based on the feedback/suggestions: https://lore.kernel.org/kvm/20260312184613.3710705-1-mattev@meta.com/ - Transform the existing VFIO BAR mmap path to also use DMABUFs behind the scenes, and then simply share that code for explicitly-mapped DMABUFs. Jason wanted to go that direction to enable iommufd VFIO type 1 emulation to pick up a DMABUF for an IO mapping. - Revoke buffers using a VFIO device fd ioctl RFCv1: https://lore.kernel.org/all/20260226202211.929005-1-mattev@meta.com/ Matt Evans (10): PCI/P2PDMA: Split pool-related cleanup out of pci_p2pdma_release() PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE vfio/pci: Add a helper to look up PFNs for DMABUFs vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA vfio/pci: Convert BAR mmap() to use a DMABUF vfio/pci: Provide a user-facing name for BAR mappings vfio/pci: Clean up BAR zap and revocation vfio/pci: Support mmap() of a VFIO DMABUF vfio/pci: Permanently revoke a DMABUF on request vfio/pci: Add mmap() attributes to DMABUF feature MAINTAINERS | 2 +- drivers/pci/Kconfig | 10 +- drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 109 +--- drivers/pci/p2pdma.h | 29 + drivers/pci/p2pdma_core.c | 118 ++++ drivers/vfio/pci/Kconfig | 5 +- drivers/vfio/pci/Makefile | 3 +- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 + drivers/vfio/pci/vfio_pci_config.c | 30 +- drivers/vfio/pci/vfio_pci_core.c | 211 +++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 568 +++++++++++++++--- drivers/vfio/pci/vfio_pci_priv.h | 63 +- include/linux/pci-p2pdma.h | 24 +- include/linux/pci.h | 2 +- include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 47 ++ 17 files changed, 960 insertions(+), 271 deletions(-) create mode 100644 drivers/pci/p2pdma.h create mode 100644 drivers/pci/p2pdma_core.c -- 2.50.1 (Apple Git-155)

1 week, 5 days

[PATCH v3] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency

by Aniket Randive

The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Compute the timeout dynamically from message length and bus frequency with a 10x safety margin over the theoretical wire time and a 300ms floor. For GPI multi-descriptor transfers, use the maximum message length across all queued messages as the per-completion timeout. Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- Changes in v3: - Added the extra variable to handle timeout value. drivers/i2c/busses/i2c-qcom-geni.c | 45 +++++++++++++++++++++++------- 1 file changed, 35 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 96dbf04138be..d43db77b3678 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -74,9 +74,12 @@ enum geni_i2c_err_code { #define PACKING_BYTES_PW 4 #define ABORT_TIMEOUT HZ -#define XFER_TIMEOUT HZ #define RST_TIMEOUT HZ +/* 9 bits per byte (8 data + 1 ACK), 10x safety margin, 300ms floor */ +#define I2C_TIMEOUT_SAFETY_COEFFICIENT 10 +#define I2C_TIMEOUT_MIN_USEC 300000 + struct geni_i2c_desc { bool no_dma_support; unsigned int tx_fifo_depth; @@ -204,6 +207,16 @@ static int geni_i2c_clk_map_idx(struct geni_i2c_dev *gi2c) return -EINVAL; } +static unsigned long geni_i2c_xfer_timeout(struct geni_i2c_dev *gi2c, size_t len) +{ + size_t bit_cnt = len * 9; + size_t bit_usec = (bit_cnt * USEC_PER_SEC) / gi2c->clk_freq_out; + size_t xfer_max_usec = (bit_usec * I2C_TIMEOUT_SAFETY_COEFFICIENT) + + I2C_TIMEOUT_MIN_USEC; + + return usecs_to_jiffies(xfer_max_usec); +} + static int qcom_geni_i2c_conf(struct geni_se *se, unsigned long freq) { struct geni_i2c_dev *gi2c = dev_get_drvdata(se->dev); @@ -445,7 +458,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t rx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -470,8 +483,9 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, gi2c->dma_buf = dma_buf; } + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -484,7 +498,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t tx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -512,8 +526,9 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (!dma_buf) /* Get FIFO IRQ */ writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG); + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -591,7 +606,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ * geni_i2c_gpi_multi_xfer_timeout_handler() - Handles multi message transfer timeout * @dev: Pointer to the corresponding dev node * @multi_xfer: Pointer to the geni_i2c_gpi_multi_desc_xfer - * @transfer_timeout_msecs: Timeout value in milliseconds + * @transfer_timeout_msecs: Per-message completion timeout in jiffies * @transfer_comp: Completion object of the transfer * * This function waits for the completion of each processed transfer messages @@ -601,7 +616,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ */ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, struct geni_i2c_gpi_multi_desc_xfer *multi_xfer, - u32 transfer_timeout_msecs, + unsigned long timeout_jiffies, struct completion *transfer_comp) { int i; @@ -612,7 +627,7 @@ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, if (multi_xfer->msg_idx_cnt != multi_xfer->irq_cnt) { time_left = wait_for_completion_timeout(transfer_comp, - transfer_timeout_msecs); + timeout_jiffies); if (!time_left) { dev_err(dev, "%s: Transfer timeout\n", __func__); return -ETIMEDOUT; @@ -736,8 +751,16 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], dma_async_issue_pending(gi2c->tx_c); if ((msg_idx == (gi2c->num_msgs - 1)) || flags & DMA_PREP_INTERRUPT) { + unsigned long timeout; + size_t max_len = 0; + int j; + + for (j = 0; j < gi2c->num_msgs; j++) + max_len = max_t(size_t, max_len, msgs[j].len); + + timeout = geni_i2c_xfer_timeout(gi2c, max_len); ret = geni_i2c_gpi_multi_xfer_timeout_handler(gi2c->se.dev, gi2c_gpi_xfer, - XFER_TIMEOUT, &gi2c->done); + timeout, &gi2c->done); if (ret) { dev_err(gi2c->se.dev, "I2C multi write msg transfer timeout: %d\n", @@ -851,8 +874,10 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i } if (!gi2c->is_tx_multi_desc_xfer) { + unsigned long timeout = geni_i2c_xfer_timeout(gi2c, msgs[i].len); + dma_async_issue_pending(gi2c->tx_c); - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) { dev_err(gi2c->se.dev, "%s:I2C timeout\n", __func__); gi2c->err = -ETIMEDOUT; -- 2.34.1

1 week, 6 days

[PATCH v2] i2c: qcom-geni: Add dynamic transfer timeout based on transfer length and frequency

by Aniket Randive

The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers regardless of message length or bus frequency, causing unnecessary delays on error paths. Compute the timeout dynamically from message length and bus frequency with a 10x safety margin over the theoretical wire time and a 300ms floor. For GPI multi-descriptor transfers, use the maximum message length across all queued messages as the per-completion timeout. Signed-off-by: Aniket Randive <aniket.randive(a)oss.qualcomm.com> --- drivers/i2c/busses/i2c-qcom-geni.c | 45 +++++++++++++++++++++++------- 1 file changed, 35 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 96dbf04138be..d43db77b3678 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -74,9 +74,12 @@ enum geni_i2c_err_code { #define PACKING_BYTES_PW 4 #define ABORT_TIMEOUT HZ -#define XFER_TIMEOUT HZ #define RST_TIMEOUT HZ +/* 9 bits per byte (8 data + 1 ACK), 10x safety margin, 300ms floor */ +#define I2C_TIMEOUT_SAFETY_COEFFICIENT 10 +#define I2C_TIMEOUT_MIN_USEC 300000 + struct geni_i2c_desc { bool no_dma_support; unsigned int tx_fifo_depth; @@ -204,6 +207,16 @@ static int geni_i2c_clk_map_idx(struct geni_i2c_dev *gi2c) return -EINVAL; } +static unsigned long geni_i2c_xfer_timeout(struct geni_i2c_dev *gi2c, size_t len) +{ + size_t bit_cnt = len * 9; + size_t bit_usec = (bit_cnt * USEC_PER_SEC) / gi2c->clk_freq_out; + size_t xfer_max_usec = (bit_usec * I2C_TIMEOUT_SAFETY_COEFFICIENT) + + I2C_TIMEOUT_MIN_USEC; + + return usecs_to_jiffies(xfer_max_usec); +} + static int qcom_geni_i2c_conf(struct geni_se *se, unsigned long freq) { struct geni_i2c_dev *gi2c = dev_get_drvdata(se->dev); @@ -445,7 +458,7 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t rx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -470,8 +483,9 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, gi2c->dma_buf = dma_buf; } + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -484,7 +498,7 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, u32 m_param) { dma_addr_t tx_dma = 0; - unsigned long time_left; + unsigned long time_left, timeout; void *dma_buf; struct geni_se *se = &gi2c->se; size_t len = msg->len; @@ -512,8 +526,9 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, if (!dma_buf) /* Get FIFO IRQ */ writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG); + timeout = geni_i2c_xfer_timeout(gi2c, len); cur = gi2c->cur; - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) geni_i2c_abort_xfer(gi2c); @@ -591,7 +606,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ * geni_i2c_gpi_multi_xfer_timeout_handler() - Handles multi message transfer timeout * @dev: Pointer to the corresponding dev node * @multi_xfer: Pointer to the geni_i2c_gpi_multi_desc_xfer - * @transfer_timeout_msecs: Timeout value in milliseconds + * @transfer_timeout_msecs: Per-message completion timeout in jiffies * @transfer_comp: Completion object of the transfer * * This function waits for the completion of each processed transfer messages @@ -601,7 +616,7 @@ static void geni_i2c_gpi_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_ */ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, struct geni_i2c_gpi_multi_desc_xfer *multi_xfer, - u32 transfer_timeout_msecs, + unsigned long timeout_jiffies, struct completion *transfer_comp) { int i; @@ -612,7 +627,7 @@ static int geni_i2c_gpi_multi_xfer_timeout_handler(struct device *dev, if (multi_xfer->msg_idx_cnt != multi_xfer->irq_cnt) { time_left = wait_for_completion_timeout(transfer_comp, - transfer_timeout_msecs); + timeout_jiffies); if (!time_left) { dev_err(dev, "%s: Transfer timeout\n", __func__); return -ETIMEDOUT; @@ -736,8 +751,16 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], dma_async_issue_pending(gi2c->tx_c); if ((msg_idx == (gi2c->num_msgs - 1)) || flags & DMA_PREP_INTERRUPT) { + unsigned long timeout; + size_t max_len = 0; + int j; + + for (j = 0; j < gi2c->num_msgs; j++) + max_len = max_t(size_t, max_len, msgs[j].len); + + timeout = geni_i2c_xfer_timeout(gi2c, max_len); ret = geni_i2c_gpi_multi_xfer_timeout_handler(gi2c->se.dev, gi2c_gpi_xfer, - XFER_TIMEOUT, &gi2c->done); + timeout, &gi2c->done); if (ret) { dev_err(gi2c->se.dev, "I2C multi write msg transfer timeout: %d\n", @@ -851,8 +874,10 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i } if (!gi2c->is_tx_multi_desc_xfer) { + unsigned long timeout = geni_i2c_xfer_timeout(gi2c, msgs[i].len); + dma_async_issue_pending(gi2c->tx_c); - time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT); + time_left = wait_for_completion_timeout(&gi2c->done, timeout); if (!time_left) { dev_err(gi2c->se.dev, "%s:I2C timeout\n", __func__); gi2c->err = -ETIMEDOUT; -- 2.34.1

1 week, 6 days

A Guide to Mastering Slope

by sarahcolter＠wshu.net

Have you ever felt the exhilarating rush of speed, the focus demanded by precision, and the utter satisfaction of overcoming a seemingly impossible challenge? If so, then you might just be ready to tackle Slope. This deceptively simple online game has captivated players with its addictive gameplay and endless potential for improvement. It's a perfect little escape for a quick break or a dedicated practice session. Let's dive into how to play and, more importantly, how to experience the thrill of Slope. Introduction: What is Slope? At its core, Slope is a rolling ball game. You control a ball that’s constantly moving downhill, navigating a procedurally generated landscape of interconnected platforms. Sounds straightforward, right? Don’t be fooled! The platforms narrow, the speed increases relentlessly, and the gaps between platforms widen as you progress. One wrong move and you’re plummeting into the abyss. https://slopegame-online.com The brilliance of Slope lies in its accessibility and its learning curve. It's incredibly easy to pick up and play, yet fiendishly difficult to master. You don't need complicated controllers or extensive tutorials. Just a keyboard, a steady hand, and a determined spirit. It's a perfect example of a simple concept executed brilliantly. Gameplay: Navigating the Perilous Path The controls are as minimal as the aesthetic: the left and right arrow keys are all you need to guide your ball. Use the left arrow key to steer the ball left, and the right arrow key to steer it right. That's it! But mastering those two keys is the key to survival. Your objective is to stay on the platforms for as long as possible. As you roll further down the slope, your speed increases, and the environment becomes increasingly challenging. Red blocks appear, acting as obstacles that instantly end your run if touched. The platforms themselves will start to shift and move, adding another layer of complexity to the game. The game ends when your ball falls off the platform. Your score is determined by the distance you travelled before your demise. The higher the score, the better! The goal is to constantly improve your score, pushing yourself to see just how far you can go. Tips and Tricks for Conquering the Slope While the controls are simple, mastering Slope requires practice and a good understanding of the game's mechanics. Here are a few tips to help you improve your game: Smooth Movements Are Key: Avoid jerky, panicked movements. Small, controlled adjustments are far more effective than large, sweeping ones. Think less about reacting and more about anticipating. Look Ahead: Try to focus a little further down the slope. Anticipating the next turn or gap will give you more time to react and adjust your trajectory. This is easier said than done when the speed is high, but it's a crucial skill to develop. Embrace the Momentum: Understand how your ball's momentum affects its movement. Learn how to use the slight curve of the platforms to your advantage, especially when approaching tight turns. Don't Fear the Edges: Sometimes, the safest route is to ride along the edge of the platform. This allows you to make small corrections and avoid potential obstacles in the center. Practice, Practice, Practice: There's no substitute for practice. The more you play, the better you'll become at anticipating the challenges and reacting accordingly. Don't get discouraged by early failures. Everyone starts somewhere. You can visit Slope to begin practicing! Learn from Your Mistakes: Analyze your failures. What caused you to fall off the platform? Were you too slow to react? Did you misjudge the turn? Understanding your mistakes will help you avoid them in the future. Conclusion: The Enduring Appeal of an Endless Game Slope isn't about complicated storylines, stunning graphics, or intricate controls. It's about the pure, unadulterated challenge of pushing your skills to the limit. It's about the satisfaction of mastering a seemingly impossible task. It's about the addictive loop of playing, failing, learning, and improving. And its accessible nature means anyone can jump in and experience that thrill. So, go ahead, give it a try. You might just find yourself hooked on the endless decline. The simple controls and challenging gameplay make it a strangely addictive experience. It's a testament to the idea that sometimes, the simplest games are the most engaging.

1 week, 6 days

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig July 2026