Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

10 participants
6373 discussions

Bake Your Way to Billions: A Look at the Addictive World of Store Management Games

by hot.meerkat.lloh＠hidingmail.net

Ever dreamed of running your own bustling enterprise, watching your profits soar, and building an empire from humble beginnings? If so, you've likely stumbled upon the fascinating and surprisingly addictive world of store management games. These titles offer a unique blend of strategy, incremental growth, and the satisfying feeling of seeing your hard work pay off. And when it comes to the purest, most delightful form of this genre, one game stands out: https://cookieclickers.io/ The Sweet Simplicity of Cookie Clicker: A Gateway to Management At its heart, Cookie Clicker is incredibly simple. You start with a single, humble cookie, and your goal is to click it to generate more cookies. These initial clicks are crucial, as they fund your first upgrades. Soon, you’ll be able to purchase "grandmas," who automatically bake cookies for you, freeing up your clicking finger. From there, the sky's the limit! You'll acquire farms, factories, mines, and even portals to other dimensions, all dedicated to the singular purpose of baking more and more cookies. What makes Cookie Clicker so captivating is its elegant progression system. Each new upgrade and building provides a tangible boost to your cookie production, creating a satisfying feedback loop. The numbers on your screen grow exponentially, transforming from humble dozens to mind-boggling septillions and beyond. It’s a masterclass in incremental design, making every new purchase feel impactful and exciting. Beyond the Click: Strategic Thinking and Exponential Growth While the initial appeal of Cookie Clicker might be the simple act of clicking, true mastery lies in strategic decision-making. As your cookie empire expands, you'll be faced with choices: Upgrade Prioritization: Should you invest in another Grandma, a new farm, or a powerful upgrade that boosts all your existing structures? Understanding the cost-benefit analysis of each option is key. Synergies: Many upgrades have synergistic effects, meaning they become more powerful when paired with specific buildings. Discovering these combinations is a delightful puzzle. Ascension and Prestige: Eventually, you’ll unlock the ability to “ascend,” resetting your game but granting you powerful "heavenly chips" that provide permanent bonuses. This meta-progression adds a whole new layer of long-term strategy, encouraging you to rethink your approach with each new playthrough. These elements elevate Cookie Clicker from a simple clicking game to a genuinely engaging management simulation. It teaches you about exponential growth, compound interest (in a fun, cookie-filled way!), and the satisfaction of building something from nothing. Tips for Aspiring Cookie Tycoons If you’re ready to dive into the sweet, sweet world of Cookie Clicker, here are a few friendly tips to get you started: Don't Be Afraid to Click! In the early game, your clicks are your most valuable resource. Keep that finger moving! Invest in Grandmas Early: They're your first step towards automation and a steady cookie income. Always Buy Upgrades: The small boosts they provide add up quickly and are often more cost-effective than new buildings in the short term. Look for Golden Cookies: These appear randomly and offer temporary, powerful buffs. Clicking them can drastically boost your production! Consider Ascending: While it seems daunting to reset your progress, the permanent bonuses you gain make future runs much faster and more efficient. The Endless Appeal of Automation Cookie Clicker, and store management games in general, tap into a fundamental human desire: the joy of creation and the satisfaction of watching systems work efficiently. There's a particular kind of quiet pleasure in setting up a well-oiled machine and observing its output multiply. So, if you're looking for a game that's easy to pick up, surprisingly deep, and immensely satisfying, give Cookie Clicker a try. You might just find yourself baking billions before you know it!

6 days, 22 hours

[PATCH v2] dma-buf: heaps: use max3() in dma_heap_ioctl

by Thorsten Blum

Replace two nested max() calls with a single max3() in dma_heap_ioctl(). Reviewed-by: T.J. Mercier <tjmercier(a)google.com> Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Changes in v2: - Include minmax.h as suggested by T.J. Mercier - v1: https://lore.kernel.org/lkml/20260427172519.417333-3-thorsten.blum@linux.de… --- drivers/dma-buf/dma-heap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649..d49188893608 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -13,6 +13,7 @@ #include <linux/err.h> #include <linux/export.h> #include <linux/list.h> +#include <linux/minmax.h> #include <linux/nospec.h> #include <linux/syscalls.h> #include <linux/uaccess.h> @@ -153,7 +154,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, in_size = 0; if ((ucmd & kcmd & IOC_OUT) == 0) out_size = 0; - ksize = max(max(in_size, out_size), drv_size); + ksize = max3(in_size, out_size, drv_size); /* If necessary, allocate buffer for ioctl argument */ if (ksize > sizeof(stack_kdata)) {

1 week

[PATCH] dma-buf: heaps: use max3() in dma_heap_ioctl

by Thorsten Blum

Replace two nested max() calls with a single max3() in dma_heap_ioctl(). Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/dma-buf/dma-heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index ac5f8685a649..52eec2ebb2e8 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -153,7 +153,7 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, in_size = 0; if ((ucmd & kcmd & IOC_OUT) == 0) out_size = 0; - ksize = max(max(in_size, out_size), drv_size); + ksize = max3(in_size, out_size, drv_size); /* If necessary, allocate buffer for ioctl argument */ if (ksize > sizeof(stack_kdata)) {

1 week

Why Choose Block Recovery Team

by dominicmiles54＠gmail.com

With professionalism and integrity, Block Recovery Team assures that their clients get the finest possible help in retrieving their lost digital assets. With a staff of professionals dedicated to assisting individuals in navigating the recovery process, they provide 24 hour support to guarantee that customers receive timely and effective assistance when they need it the most. Testimonials from delighted clients demonstrate Block Recovery Team abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Block Recovery Team

1 week

[PATCH V13 0/7] Rust support for powerpc

by Mukesh Kumar Chaurasiya (IBM)

Enable experimental rust support for ppc64le and ppc32be. The patch for ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been merged over it. ppc32 needs some toolchain fixes mentioned in the patch `rust: Add PowerPC support` and the discussion for that is done here[1]. This has been tested on - powernv9 hardware - pseries P11 hardware - pseries(9, 10) qemu - powernv(9, 10) qemu - rustdoc on x86 and powerpc64le - rusttest on x86 and powerpc64le We are actively working with our LLVM team to get the target for ppc, ppc64 and ppc64le in the rust compiler. [1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr [2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com Changelog: V12 -> V13: - Added a patch for fixing build issue on ppc32 by Link Mauve - Added another patch to fix a build issue in dma-buf - Added another patch to enforce minimum `rustc` version for powerpc V12: https://lore.kernel.org/all/20260421120958.190430-1-mkchauras@gmail.com/ V11 -> V12: - Rebased to mainline (rust/Makefile conflict resolved) V11: https://lore.kernel.org/all/20260417152253.2312961-1-mkchauras@gmail.com/ V10 -> V11: - Updated `rust/Makefile` - Not all libraries are move to `rust/host` directory now. Only proc_macro2, quote and syn are moved - Special handling for pin init is added. Details in commit - Removed mkdir for `rust/host`, this is now handled by toolchain. V10: https://lore.kernel.org/all/20260406200149.3727922-1-mkchauras@gmail.com/ V9 -> V10: - rust/Makefile updated with review comments from Miguel - Patch 1/4 updated with commit message and subject V9: https://lore.kernel.org/all/20260404121610.1956528-1-mkchauras@gmail.com/ V8 -> V9: - rust/Makefile updated with a directory instead of abspath V8: https://lore.kernel.org/all/20260403145308.1042622-1-mkchauras@gmail.com/ V7 -> V8: - rust/Makefile updated to separate host libraries from target V7: https://lore.kernel.org/all/20260329160254.2592207-1-mkchauras@gmail.com/ Changelog: V6 -> V7: - Documentation removed as powerpc is still under development - Added a fix for race condition in rust/Makefile V6: https://lore.kernel.org/all/20260210090023.2587534-1-mkchauras@gmail.com V5 -> V6: - Added a missing Tested by from Venkat which got missed since V3 - Support is marked as Maintained instead of experimental V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com V4 -> V5: - Removed a nested ifdef from PPC64 for Little endian toolchain V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com V3 -> V4: - Co-developed-by header added in patch 1 V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com V2 -> V3: - Splited HAVE_RUST in 2 lines - BINDGEN_TARGET_powerpc initialized before assigning the same to BINDGEN_TARGET V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com V1 -> V2: - jump label fix for rust has been moved to a separate patch - PPC32 support has been taken - rust support has been marked experimental - target.json dependency has been removed - HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64 Link Mauve (2): rust: Make __udivdi3() and __umoddi3() panic rust: Add PowerPC support Mukesh Kumar Chaurasiya (IBM) (5): rust: Fix "multiple candidates for rmeta dependency core" error dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled powerpc/jump_label: adjust inline asm to be consistent rust/powerpc: Set min rustc version for powerpc powerpc: Enable Rust for ppc64le arch/powerpc/Kconfig | 2 ++ arch/powerpc/Makefile | 7 ++++ arch/powerpc/include/asm/jump_label.h | 23 ++++++------ include/linux/dma-resv.h | 2 +- rust/Makefile | 52 +++++++++++++++++---------- rust/compiler_builtins.rs | 6 ++++ scripts/min-tool-version.sh | 6 +++- 7 files changed, 68 insertions(+), 30 deletions(-) -- 2.53.0

1 week

[PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory

by Jiri Pirko

From: Jiri Pirko <jiri(a)nvidia.com> Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, run with private/encrypted memory which creates a challenge for devices that do not support DMA to it (no TDISP support). For kernel-only DMA operations, swiotlb bounce buffering provides a transparent solution by copying data through shared memory. However, the only way to get this memory into userspace is via the DMA API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits the use of the memory to a single DMA device, and is incompatible with pin_user_pages(). These limitations are particularly problematic for the RDMA subsystem which makes heavy use of pin_user_pages() and expects flexible memory usage between many different DMA devices. This patch series enables userspace to explicitly request shared (decrypted) memory allocations from new dma-buf system_cc_shared heap. Userspace can mmap this memory and pass the dma-buf fd to other existing importers such as RDMA or DRM devices to access the memory. The DMA API is improved to allow the dma heap exporter to DMA map the shared memory to each importing device. Based on dma-mapping-for-next e7442a68cd1ee797b585f045d348781e9c0dde0d Jiri Pirko (2): dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- include/linux/dma-mapping.h | 10 +++ include/trace/events/dma.h | 3 +- kernel/dma/direct.h | 14 +++- kernel/dma/mapping.c | 13 +++- 5 files changed, 132 insertions(+), 11 deletions(-) -- 2.51.1

1 week, 1 day

[PATCH v12 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 557 ++++++++++++++++++++++++- 3 files changed, 593 insertions(+), 14 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

1 week, 2 days

(no subject)

by Alex Morgan

How Can I Recover My Lost Cryptocurrency, Hire Ghost Mystery Recovery Hacker Ghost Mystery Recovery Hacker delivered an excellent experience when I needed help recovering something I thought was permanently lost. From the start, their communication was clear, professional, and reassuring, which immediately made me feel more confident about the process. They took the time to understand my situation and explained each step in a way that was honest and easy to follow. What stood out most was their consistency and dedication. I was kept informed throughout, and they remained patient and responsive whenever I had questions. Their expertise was evident in the way they handled everything carefully and efficiently, without creating false expectations.The outcome exceeded what I had hoped for. They were able to successfully resolve my issue, which brought me a great sense of relief. It’s not often you come across a service that combines professionalism, transparency, and results so well. I would strongly recommend Ghost Mystery Recovery Hacker to anyone looking for reliable recovery support. Their commitment to helping clients and delivering real results truly sets them apart. Email address: support@ ghostmysteryrecovery. c om WhatsApp on (+44) 7480 061765 Website; ghostmysteryrecovery. c om

1 week, 3 days

(no subject)

by Alex Morgan

1 week, 3 days

(no subject)

by Alex Morgan

1 week, 3 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig