Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

32 participants
5932 discussions

Fake Investment Platforms: Anatomy of a Rug Pull Scam

by rogerstewer＠gmail.com

Scammers launch bogus trading/investment sites promising guaranteed returns, then vanish with deposits. 1. Luring Victims Ads on social media or Telegram promote "AI trading bots" or "exclusive funds." Victims sign up and deposit crypto via provided wallets. 2. Controlled Environment Fake interfaces show rising balances to encourage more investment. Withdrawals blocked with excuses ("taxes," "verification"). 3. The Exit Scam When enough funds accumulate: Site goes offline. Funds transferred out rapidly. 4. Obfuscation & Cash-Out Similar to other scams: splitting, mixing, chain-hopping, then exchange fiat off-ramps. Where Tracing Can Intervene Many platforms use traceable patterns (e.g., repeated deposit addresses). Early Alerts: Monitor for sudden outflows. Clustering: Group related wallets to reveal operators. Legal Leverage: Evidence supports civil or criminal action. Cryptera Chain Signals (CCS) analyzes these platforms' transaction histories, traces to exchanges, and supports recovery efforts with detailed reports and partnerships. For help with fake investment scams, head to https://www.crypterachainsignals.com/ or contact info(a)crypterachainsignals.com. Research platforms thoroughly check audits, team transparency, and community feedback.

18 hours, 39 minutes

Phishing Attacks on Wallets: How Hackers Drain Your Crypto in Minutes

by luisannete22＠gmail.com

Phishing remains one of the most common ways scammers steal crypto—often through fake websites, malicious emails, or compromised links. 1. The Bait Victims receive urgent messages: "Your wallet is at risk—verify here" or fake airdrop/claim links from trusted projects. Clicking leads to spoofed sites mimicking MetaMask, Ledger, or exchanges. Users enter seed phrases, private keys, or approve malicious transactions. 2. Instant Drainage Once credentials or approvals are obtained: Scammers sweep funds to their address. Drainers auto-transfer everything (tokens, NFTs). 3. Rapid Laundering Funds move fast: Split and peeled into smaller amounts. Bridged to other chains. Mixed or swapped to break links. 4. Cash-Out Deposited to exchanges, often KYC-bypassed via layered accounts. Where Tracing Can Intervene Phishing thefts leave clear on-chain trails if reported quickly. Real-Time Monitoring: Track outgoing sweeps and downstream hops. Pattern Recognition: Identify common drainer signatures or exchange deposit clusters. Freeze Potential: Exchanges can halt if illicit origin proven early. Firms like Cryptera Chain Signals (CCS) excel at rapid phishing investigations, using AI-powered tracing to follow funds across chains and facilitate exchange freezes. In 2026, they've helped recover significant portions in time-sensitive cases. Visit https://www.crypterachainsignals.com/ for crypto scam recovery support, or email info(a)crypterachainsignals.com to get started. Protect yourself with hardware wallets and bookmark verification never enter seeds online.

18 hours, 40 minutes

Romance Scams in Crypto: The Slow-Burn Theft Exposed Cryptera Chain Signals

by luisannete22＠gmail.com

The rise of cryptocurrency has amplified romance scams, where fraudsters build emotional trust over weeks or months before requesting funds. These "pig butchering" operations are particularly devastating because victims often send large sums willingly. 1. Building False Trust Scammers create fake profiles on dating apps or social media, posing as successful investors or entrepreneurs. They share "proof" of crypto gains to lure victims into trading platforms they control. Conversations escalate to "exclusive opportunities" like private presales or high-yield pools. Victims are guided to deposit crypto into wallets or fake exchanges. 2. The Extraction Phase Once trust is established, scammers pressure victims to invest more, promising quick returns. Funds go to scammer-controlled addresses. Fake dashboards show fabricated profits to encourage further deposits. 3. Obfuscation Tactics After extraction, funds are quickly moved: Split across dozens of wallets. Hopped through bridges to privacy-focused chains. Mixed via services or converted to privacy coins like Monero. 4. Final Laundering Cleaned funds hit centralized exchanges for fiat withdrawal, often via mule accounts. Recovery window closes fast once converted. Where Tracing Can Intervene Quick action is essential in romance scams due to the emotional manipulation factor. Immediate Reporting: Preserve all chat logs, transaction IDs, and screenshots. Blockchain Analysis: Trace patterns like repeated small deposits or specific bridge usage. Exchange Cooperation: Provide evidence to freeze incoming deposits. Blockchain investigation firms like Cryptera Chain Signals (CCS) specialize in tracing romance scam funds through complex paths, identifying endpoints, and assisting with freeze requests. With advanced forensics and a track record of hundreds of recoveries (including 2026 cases), they help victims map flows and pursue actionable steps before full laundering. For professional help with romance scam or crypto fraud recovery, visit the Cryptera Chain Signals website at https://www.crypterachainsignals.com/. Contact them directly via email at info(a)crypterachainsignals.com or through their secure inquiry form. Emotional scams hurt deeply, but blockchain transparency offers hope—act swiftly and seek expert help.

18 hours, 41 minutes

[PATCH v2 0/6] dma-buf: heaps: add coherent reserved-memory heap

by Albert Esteve

This patch introduces a new heap driver to expose DT non‑reusable "shared-dma-pool" coherent regions as dma-buf heaps, so userspace can allocate buffers from each reserved, named region. Because these regions are device‑dependent, each heap instance binds a heap device to its reserved‑mem region via a newly introduced helper function -namely, of_reserved_mem_device_init_with_mem()- so coherent allocations use the correct dev->dma_mem. Charging to cgroups for these buffers is intentionally left out to keep review focused on the new heap; I plan to follow up based on Eric’s [1] and Maxime’s [2] work on dmem charging from userspace. This series also makes the new heap driver modular, in line with the CMA heap change in [3]. [1] https://lore.kernel.org/all/20260218-dmabuf-heap-cma-dmem-v2-0-b249886fb7b2… [2] https://lore.kernel.org/all/20250310-dmem-cgroups-v1-0-2984c1bc9312@kernel.… [3] https://lore.kernel.org/all/20260303-dma-buf-heaps-as-modules-v3-0-24344812… Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Changes in v2: - Removed dmem charging parts - Moved coherent heap registering logic to coherent.c - Made heap device a member of struct dma_heap - Split dma_heap_add logic into create/register, to be able to access the stored heap device before registered. - Avoid platform device in favour of heap device - Added a wrapper to rmem device_init() op - Switched from late_initcall() to module_init() - Made the coherent heap driver modular - Link to v1: https://lore.kernel.org/r/20260224-b4-dmabuf-heap-coherent-rmem-v1-1-dffef4… --- Albert Esteve (5): dma-buf: dma-heap: split dma_heap_add of_reserved_mem: add a helper for rmem device_init op dma-buf: heaps: Add Coherent heap to dmabuf heaps dma: coherent: register to coherent heap dma-buf: heaps: coherent: Turn heap into a module John Stultz (1): dma-buf: dma-heap: Keep track of the heap device struct drivers/dma-buf/dma-heap.c | 138 +++++++++-- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/coherent_heap.c | 429 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 27 ++- include/linux/dma-heap.h | 16 ++ include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 642 insertions(+), 27 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

23 hours, 2 minutes

Re: [PATCH v2 3/6] of_reserved_mem: add a helper for rmem device_init op

by Albert Esteve

On Tue, Mar 3, 2026 at 2:13 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > On Tue, Mar 03, 2026 at 01:33:46PM +0100, Albert Esteve wrote: > > Add a helper function wrapping internal reserved memory > > device_init call and expose it externally. > > > > Use the new helper function within of_reserved_mem_device_init_by_idx(). > > > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > > --- > > drivers/of/of_reserved_mem.c | 27 +++++++++++++++++++++++---- > > include/linux/of_reserved_mem.h | 8 ++++++++ > > 2 files changed, 31 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > > index 1fd28f8056108..3a350bef8f11e 100644 > > --- a/drivers/of/of_reserved_mem.c > > +++ b/drivers/of/of_reserved_mem.c > > @@ -605,6 +605,28 @@ struct rmem_assigned_device { > > static LIST_HEAD(of_rmem_assigned_device_list); > > static DEFINE_MUTEX(of_rmem_assigned_device_mutex); > > > > +/** > > + * of_reserved_mem_device_init_with_mem() - assign reserved memory region to > > + * given device > > + * @dev: Pointer to the device to configure > > + * @rmem: Reserved memory region to assign > > + * > > + * This function assigns respective DMA-mapping operations based on the > > + * reserved memory region already provided in @rmem to the @dev device, > > + * without walking DT nodes. > > + * > > + * Returns error code or zero on success. > > + */ > > +int of_reserved_mem_device_init_with_mem(struct device *dev, > > + struct reserved_mem *rmem) > > +{ > > + if (!dev || !rmem || !rmem->ops || !rmem->ops->device_init) > > + return -EINVAL; > > + > > + return rmem->ops->device_init(rmem, dev); > > +} > > +EXPORT_SYMBOL_GPL(of_reserved_mem_device_init_with_mem); > > + > > /** > > * of_reserved_mem_device_init_by_idx() - assign reserved memory region to > > * given device > > @@ -643,14 +665,11 @@ int of_reserved_mem_device_init_by_idx(struct device *dev, > > rmem = of_reserved_mem_lookup(target); > > of_node_put(target); > > > > - if (!rmem || !rmem->ops || !rmem->ops->device_init) > > - return -EINVAL; > > - > > rd = kmalloc_obj(struct rmem_assigned_device); > > if (!rd) > > return -ENOMEM; > > > > - ret = rmem->ops->device_init(rmem, dev); > > + ret = of_reserved_mem_device_init_with_mem(dev, rmem); > > if (ret == 0) { > > rd->dev = dev; > > rd->rmem = rmem; > > I think you need to take the allocation of rd, and everything below. > Otherwise, your device, despite being attechd, wouldn't be listed > anywhere. True, I did not pay enough attention to that part. I will fix it in the next version. > > Maxime

1 day, 7 hours

Primatz Guard Recovery: Addressing Romance Scams Linked to Digital Assets

by phillipsmathew895＠gmail.com

Romance scams begin with emotional trust-building, often through social media or messaging apps. Scammers later introduce supposed crypto or digital asset investment opportunities and persuade victims to transfer funds. Once payments are made, communication fades and funds become difficult to retrieve. Primatz Guard Recovery supports victims by reviewing financial trails, identifying scam tactics, and providing guidance on recovery steps with no consultation charges. Staying cautious with online relationships and avoiding financial commitments based on emotional pressure remains essential. Homepage: Primatz Guard Recovery

1 day, 23 hours

How To Recover Lost Funds From Online Investment Scam - Reach Out To Betafort Recovery

by glennkael8＠gmail.com

With professionalism and integrity, Betafort Recovery 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 Betafort Recovery abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Betafort Recovery

1 day, 23 hours

Re: [PATCH v2 4/6] dma-buf: heaps: Add Coherent heap to dmabuf heaps

by Albert Esteve

On Tue, Mar 3, 2026 at 2:20 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > Hi, > > On Tue, Mar 03, 2026 at 01:33:47PM +0100, Albert Esteve wrote: > > Add a dma-buf heap for DT coherent reserved-memory > > (i.e., 'shared-dma-pool' without 'reusable' property), > > exposing one heap per region for userspace buffers. > > > > The heap binds the heap device to each memory region so > > coherent allocations use the correct dev->dma_mem, and > > it defers registration until module_init when normal > > allocators are available. > > > > Signed-off-by: Albert Esteve <aesteve(a)redhat.com> > > --- > > drivers/dma-buf/dma-heap.c | 4 +- > > drivers/dma-buf/heaps/Kconfig | 9 + > > drivers/dma-buf/heaps/Makefile | 1 + > > drivers/dma-buf/heaps/coherent_heap.c | 426 ++++++++++++++++++++++++++++++++++ > > include/linux/dma-heap.h | 11 + > > include/linux/dma-map-ops.h | 7 + > > 6 files changed, 456 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > > index 88189d4e48561..ba87e5ac16ae2 100644 > > --- a/drivers/dma-buf/dma-heap.c > > +++ b/drivers/dma-buf/dma-heap.c > > @@ -390,8 +390,8 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > > > > heap = dma_heap_create(exp_info); > > if (IS_ERR(heap)) { > > - pr_err("dma_heap: failed to create heap (%d)\n", PTR_ERR(heap)); > > - return PTR_ERR(heap); > > + pr_err("dma_heap: failed to create heap (%ld)\n", PTR_ERR(heap)); > > + return ERR_CAST(heap); > > This looks unrelated and should possibly be squashed into the previous > patch that introduces dma_heap_create()? > > > +static int coherent_heap_init_dma_mask(struct device *dev) > > +{ > > + int ret; > > + > > + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64)); > > + if (!ret) > > + return 0; > > + > > + /* Fallback to 32-bit DMA mask */ > > + return dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32)); > > +} > > Why do you need to mess with the DMA mask? I'd expect that device to be > able to access everything. When I tested I was getting: "reserved memory is beyond device's set DMA address range", so I tested if it was fixed with dma_coerce_mask_and_coherent() and/or dma_set_mask_coherent(). I did not debug the value of coherent_dma_mask, but given the error I assume it was not set properly? Ultimately, using the 64 bit mask fixed it, and I added a 32-bit fallback to ensure support for 32-bit systems. > > > +static int __coherent_heap_register(struct reserved_mem *rmem) > > +{ > > + struct dma_heap_export_info exp_info; > > + struct coherent_heap *coh_heap; > > + struct device *heap_dev; > > + int ret; > > + > > + if (!rmem || !rmem->name) > > + return -EINVAL; > > + > > + coh_heap = kzalloc_obj(*coh_heap); > > + if (!coh_heap) > > + return -ENOMEM; > > + > > + coh_heap->rmem = rmem; > > + coh_heap->name = kstrdup(rmem->name, GFP_KERNEL); > > + if (!coh_heap->name) { > > + ret = -ENOMEM; > > + goto free_coherent_heap; > > + } > > + > > + exp_info.name = coh_heap->name; > > + exp_info.ops = &coherent_heap_ops; > > + exp_info.priv = coh_heap; > > + > > + coh_heap->heap = dma_heap_create(&exp_info); > > + if (IS_ERR(coh_heap->heap)) { > > + ret = PTR_ERR(coh_heap->heap); > > + goto free_name; > > + } > > + > > + heap_dev = dma_heap_get_dev(coh_heap->heap); > > + ret = coherent_heap_init_dma_mask(heap_dev); > > + if (ret) { > > + pr_err("coherent_heap: failed to set DMA mask (%d)\n", ret); > > + goto destroy_heap; > > + } > > + > > + ret = of_reserved_mem_device_init_with_mem(heap_dev, rmem); > > + if (ret) { > > + pr_err("coherent_heap: failed to initialize memory (%d)\n", ret); > > + goto destroy_heap; > > + } > > + > > + ret = dma_heap_register(coh_heap->heap); > > + if (ret) { > > + pr_err("coherent_heap: failed to register heap (%d)\n", ret); > > + goto destroy_heap; > > + } > > I guess it's more of a comment about your previous patch, but it's not > clear to me why you needed to split dma_heap_add into dma_heap_create / > _register. Can you expand a bit? So first I tried to just use dma_heap_add() and then use the heap_dev afterward to call of_reserved_mem_device_init_with_mem(), but if that call failed, the error path required some kind dma_heap_remove() function as the heap was already registered by then. In the CMA heap for example, dma_heap_add() is invoked at the end of the `init` function. Therefore, you do not have this issue, if it failed it means the heap was not added and you just need to clean everything else. However, performing a remove() does not sound like something that can be done safely. I've spent some time thinking on alternatives, but splitting felt the best pattern. This way I can: 1. Create the device 2. Call of_reserved_mem_device_init_with_mem 3. Register the heap This places registration at the end, making every error path and cleanup easy to handle. Also, the `dma_heap_add()` code already seemed to handle these two parts/phases implicitly with device_create(), so splitting felt architecturally sound. > > > diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h > > index 1b0ea43ba66c3..77e6cb66ffce1 100644 > > --- a/include/linux/dma-heap.h > > +++ b/include/linux/dma-heap.h > > @@ -9,10 +9,12 @@ > > #ifndef _DMA_HEAPS_H > > #define _DMA_HEAPS_H > > > > +#include <linux/errno.h> > > #include <linux/types.h> > > > > struct dma_heap; > > struct device; > > +struct reserved_mem; > > > > /** > > * struct dma_heap_ops - ops to operate on a given heap > > @@ -53,4 +55,13 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info); > > > > extern bool mem_accounting; > > > > +#if IS_ENABLED(CONFIG_DMABUF_HEAPS_COHERENT) > > +int dma_heap_coherent_register(struct reserved_mem *rmem); > > +#else > > +static inline int dma_heap_coherent_register(struct reserved_mem *rmem) > > +{ > > + return -EOPNOTSUPP; > > +} > > +#endif > > + > > #endif /* _DMA_HEAPS_H */ > > Do you still need that now that you switched to an iterator-like > function? > > > diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h > > index 60b63756df821..c87e5e44e5383 100644 > > --- a/include/linux/dma-map-ops.h > > +++ b/include/linux/dma-map-ops.h > > @@ -12,6 +12,7 @@ > > > > struct cma; > > struct iommu_ops; > > +struct reserved_mem; > > > > struct dma_map_ops { > > void *(*alloc)(struct device *dev, size_t size, > > @@ -161,6 +162,7 @@ int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size, > > int dma_release_from_dev_coherent(struct device *dev, int order, void *vaddr); > > int dma_mmap_from_dev_coherent(struct device *dev, struct vm_area_struct *vma, > > void *cpu_addr, size_t size, int *ret); > > +struct reserved_mem *dma_coherent_get_reserved_region(unsigned int idx); > > #else > > static inline int dma_declare_coherent_memory(struct device *dev, > > phys_addr_t phys_addr, dma_addr_t device_addr, size_t size) > > @@ -172,6 +174,11 @@ static inline int dma_declare_coherent_memory(struct device *dev, > > #define dma_release_from_dev_coherent(dev, order, vaddr) (0) > > #define dma_mmap_from_dev_coherent(dev, vma, vaddr, order, ret) (0) > > static inline void dma_release_coherent_memory(struct device *dev) { } > > +static inline > > +struct reserved_mem *dma_coherent_get_reserved_region(unsigned int idx) > > +{ > > + return NULL; > > +} > > #endif /* CONFIG_DMA_DECLARE_COHERENT */ > > > > #ifdef CONFIG_DMA_GLOBAL_POOL > > To preserve bisectability, you shouldn't do it that way. Introduce this > function into a preliminary patch, and then use it in this one. > > Maxime

2 days

Forgot Your Crypto Wallet Password? Here's What to Do

by hamtonbecky＠gmail.com

Forgetting the password to your crypto wallet can be incredibly stressful, especially with valuable assets at stake. Unlike traditional accounts, most non-custodial crypto wallets (like MetaMask, Exodus, Electrum, or hardware wallets) don't offer simple "forgot password" resets. Recovery depends entirely on your wallet type and backups. Key Recovery Options If You Have Your Recovery Phrase (Seed Phrase) This is the most reliable method. Most wallets use a 12- or 24-word recovery phrase to restore access. Uninstall/reinstall the wallet app or extension. Choose "Import" or "Recover" wallet. Enter your seed phrase. Set a new password. This works for wallets like Crypto.com, Bitcoin.com, and many others. Always store your seed phrase securely offline. For Custodial Wallets/Exchanges If your funds are on a platform like Blockchain.com (trading account) or an exchange, use their official "Forgot Password" feature. Enter your email/phone, verify identity, and reset via link or support. These are easier since the platform holds keys. Try Remembering or Brute-Forcing (Limited Success) Brainstorm variations based on hints, patterns, or old passwords. For some wallets (e.g., Bitcoin Core .dat files), advanced users try tools like Hashcat or John the Ripper on their own hardware. This is time-consuming, technical, and often unsuccessful for strong passwords. If Nothing Works Without the seed phrase or backups, self-recovery is usually impossible due to crypto's strong security design. Many users permanently lose access. If you need expert help, reach out to Cryptera Chain Signals (CCS), a specialized firm in crypto fund recovery and wallet restoration. They assist with inaccessible wallets and related issues using advanced forensics and tracing. Website: https://www.crypterachainsignals.com/ Email: info(a)crypterachainsignals.com Important Warnings Never share your seed phrase, private keys, or password with anyone. Beware of scams promising guaranteed recovery for upfront fees. Prevention is key: Back up your seed phrase securely and use strong, memorable passwords. Act quickly and carefully your funds depend on it. Good luck!

2 days, 3 hours

[PATCH v3 0/8] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA one is a bit more involved, especially since we have a call from kernel/dma/contiguous.c to the CMA heap code. This was solved by turning the logic around and making the CMA heap call into the contiguous DMA code. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (8): dma: contiguous: Turn heap registration logic around dma: contiguous: Make dev_get_cma_area() a proper function dma: contiguous: Make dma_contiguous_default_area static dma: contiguous: Export dev_get_cma_area() mm: cma: Export cma_alloc(), cma_release() and cma_get_name() dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 21 +++++---------------- drivers/dma-buf/heaps/system_heap.c | 5 +++++ include/linux/dma-map-ops.h | 18 ++++++++++-------- kernel/dma/contiguous.c | 37 ++++++++++++++++++++++++++++++++++--- mm/cma.c | 3 +++ 7 files changed, 60 insertions(+), 29 deletions(-) --- base-commit: 499a718536dc0e1c1d1b6211847207d58acd9916 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

2 days, 4 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig