Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

36 participants
5941 discussions

by rogerstewer＠gmail.com

As cryptocurrencies continue to reshape finance in 2026, the risk of scams, hacks, and lost access credentials remains a major challenge. Recovering lost or stolen digital assets requires expert intervention, and Cryptera Chain Signals (CCS), accessible via https://www.crypterachainsignals.com/, stands out as a leading and trusted crypto recovery provider. With advanced blockchain forensics, a strong emphasis on client support, and a proven track record, Cryptera Chain Signals offers reliable solutions to help reclaim assets. This guide highlights top crypto recovery approaches for 2026, with Cryptera Chain Signals recognized for its professionalism, and explores emerging trends and FAQs to guide your recovery journey. Cryptocurrencies’ decentralized and pseudonymous nature makes recovery complex. Losses from scams, forgotten seed phrases, or hacked wallets highlight the need for professional services. Cryptera Chain Signals specializes in navigating these issues, using cutting-edge tools and realistic strategies to trace funds and restore access where feasible. Crypto recovery services assist with: Tracing stolen funds: Blockchain analytics to track transaction paths. Recovering access: Resolving wallet lockouts (e.g., lost seeds/hardware issues). Legal support: Coordinating with authorities for viable cases. Exchange coordination: Assisting platforms to freeze suspicious accounts. Cryptera Chain Signals excels in these areas, leveraging proprietary multi-layer wallet attribution and partnerships for tracing across chains, mixers, bridges, and DeFi protocols—making it a strong choice for complex cases. Several services stand out in 2026, but Cryptera Chain Signals is frequently praised for its transparency and results: Advanced blockchain forensics: Proprietary tools trace funds precisely, even in obfuscated cases, with detailed reports and high success in viable scenarios (e.g., 90% recoveries noted in client testimonials for phishing/scams). Client-centric support: Free consultations, 24/7 availability, ongoing updates, and educational guidance on prevention build trust. Proven track record: Over 426 successful projects, 28 years in digital forensics/cybersecurity, and a 4.28/5 rating from 2,467+ verified reviews. Global reach: International support addresses cross-border issues effectively. Contact Cryptera Chain Signals at info(a)crypterachainsignals.com for a free consultation to start your recovery journey. Other reputable options include: Crypto Asset Recovery specialists: Focus on lost seed phrases and inaccessible wallets with technical expertise. Wallet Recovery Services: Excel in private key/wallet restoration for complex access issues. While these are solid, Cryptera Chain Signals’ comprehensive forensics-driven approach and client feedback make it highly regarded for 2026. Cryptera Chain Signals follows a structured, transparent process: Initial assessment: Free consultation gathers TXIDs, addresses, and details to evaluate feasibility. Customized strategy: AI-enhanced analytics trace movements and outline plans (e.g., exchange coordination or authority support). Execution and monitoring: Implement steps with regular client updates. Post-recovery support: Guidance on security (e.g., MFA, hardware wallets) to prevent future losses. The crypto recovery landscape evolves with trends: Enhanced blockchain analysis: AI/machine learning for faster tracing, as seen in Cryptera Chain Signals’ multi-layer attribution. Stronger regulatory ties: Cooperation with agencies like IC3 streamlines actions. Consumer education: Emphasis on prevention via resources and guidance. Prevention is key—follow these practices: Use hardware wallets (Ledger/Trezor) for offline storage. Enable multi-factor authentication. Verify platforms and stay informed on scam tactics. Use secure backups and avoid sharing seeds/keys. Q1: Does working with a recovery service guarantee asset return? A1: No—blockchain complexity means no guarantees. Cryptera Chain Signals maximizes chances in viable cases through forensics and coordination, with strong testimonials in scam/phishing recoveries. Q2: What situations do recovery services help with? A2: Cryptera Chain Signals assists with hacked wallets, lost private keys/seeds, erroneous transactions, scams, phishing, and hardware failures. Q3: How long does recovery take? A3: Timelines vary (days to months) based on complexity and cooperation. Cryptera Chain Signals’ swift assessments and 24/7 support accelerate viable cases. Q4: What are the costs? A4: Varies; Cryptera Chain Signals offers flexible, transparent structures discussed in free consultations—focus on realistic, client-aligned terms. In 2026, crypto recovery services remain essential for reclaiming assets. Cryptera Chain Signals leads with advanced forensics, ethical practices, and client-focused support. Act swiftly and engage via official channels for confidence in the process. Website: https://www.crypterachainsignals.com/ Email: info(a)crypterachainsignals.com Secure your assets and leverage Cryptera Chain Signals’ expertise to navigate recovery in 2026. With a solid reputation for professionalism and results, it offers a dependable path forward. Always report incidents to authorities (e.g., FBI IC3) first, document evidence, and verify providers independently to avoid secondary scams.

23 minutes

Re: [PATCH v2 4/9] accel/neutron: Add driver for NXP Neutron NPU

by Krzysztof Kozlowski

On 06/03/2026 14:27, Ioana Ciocoi-Radulescu wrote: > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8a5b27b061da..f7a687eb6b54 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -19191,6 +19191,16 @@ S: Orphan > F: Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml > F: drivers/nfc/nxp-nci > > +NXP Neutron NPU DRIVER s/Neutron/NEUTRON/ as everything here is in uppercase > +M: Ioana Ciocoi Radulescu <ruxandra.radulescu(a)nxp.com> > +M: Jiwei Fu <jiwei.fu(a)nxp.com> > +L: dri-devel(a)lists.freedesktop.org > +S: Maintained > +T: git https://gitlab.freedesktop.org/drm/misc/kernel.git > +F: Documentation/accel/neutron/ > +F: drivers/accel/neutron/ > +F: include/uapi/drm/neutron_accel.h > > diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile > index 1d3a7251b950..698136e12cce 100644 > --- a/drivers/accel/Makefile > +++ b/drivers/accel/Makefile > @@ -4,5 +4,6 @@ obj-$(CONFIG_DRM_ACCEL_AMDXDNA) += amdxdna/ > obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/ > obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/ > obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/ > +obj-$(CONFIG_DRM_ACCEL_NXP_NEUTRON) += neutron/ > obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/ > -obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > \ No newline at end of file You still have patch warnings. > +obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ > diff --git a/drivers/accel/neutron/Kconfig b/drivers/accel/neutron/Kconfig > new file mode 100644 > index 000000000000..37b8ecb49804 > --- /dev/null > +++ b/drivers/accel/neutron/Kconfig > @@ -0,0 +1,16 @@ > +# SPDX-License-Identifier: GPL-2.0+ > + > +config DRM_ACCEL_NXP_NEUTRON > + tristate "NXP Neutron NPU" > + depends on HAS_IOMEM > + depends on DRM_ACCEL > + depends on ARCH_MXC Missing compile test > + select DRM_GEM_DMA_HELPER > + select DRM_SCHED > + help > + Enables driver for NXP Neutron NPU. > + > + Select this if you have an NXP SoC with Neutron, like i.MX95, > + and want to run machine learning applications. > + > + If built as module, the module is named neutron. ... > + > + ret = devm_request_threaded_irq(dev, ndev->irq, NULL, > + neutron_irq_handler_thread, > + IRQF_ONESHOT, KBUILD_MODNAME, ndev); > + if (ret) { > + dev_err(dev, "Failed to request irq %d\n", ndev->irq); Drop, not needed. > + return ret; > + } > + > + ret = of_reserved_mem_device_init(&pdev->dev); > + if (ret) { > + dev_err(dev, "Failed to initialize reserved memory\n"); > + return ret; > + } > + > + ret = devm_pm_runtime_enable(dev); > + if (ret) > + goto free_reserved; > + > + pm_runtime_set_autosuspend_delay(dev, NEUTRON_SUSPEND_DELAY_MS); > + pm_runtime_use_autosuspend(dev); > + > + ret = drm_dev_register(&ndev->base, 0); > + if (ret) > + goto free_reserved; > + > + return 0; > + > +free_reserved: > + of_reserved_mem_device_release(&pdev->dev); > + > + return ret; > +} > + > +static void neutron_remove(struct platform_device *pdev) > +{ > + struct neutron_device *ndev = platform_get_drvdata(pdev); > + > + drm_dev_unregister(&ndev->base); > + of_reserved_mem_device_release(&pdev->dev); > +} > + > +static int neutron_runtime_suspend(struct device *dev) > +{ > + struct neutron_device *ndev = dev_get_drvdata(dev); > + > + neutron_disable_irq(ndev); > + neutron_shutdown(ndev); > + > + clk_bulk_disable_unprepare(ndev->num_clks, ndev->clks); > + > + return 0; > +} > + > +static int neutron_runtime_resume(struct device *dev) > +{ > + struct neutron_device *ndev = dev_get_drvdata(dev); > + int ret; > + > + ret = clk_bulk_prepare_enable(ndev->num_clks, ndev->clks); > + if (ret) > + return ret; > + > + ret = neutron_boot(ndev); > + if (ret) { > + clk_bulk_disable_unprepare(ndev->num_clks, ndev->clks); > + return ret; > + } > + > + neutron_enable_irq(ndev); > + > + return 0; > +} > + > +static const struct dev_pm_ops neutron_pm_ops = { > + SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) > + RUNTIME_PM_OPS(neutron_runtime_suspend, neutron_runtime_resume, NULL) > +}; > + > +static const struct of_device_id neutron_match_table[] = { > + { .compatible = "nxp,imx95-neutron" }, > + {} > +}; > + > +MODULE_DEVICE_TABLE(of, neutron_match_table); > + > +static struct platform_driver neutron_driver = { > + .probe = &neutron_probe, > + .remove = &neutron_remove, > + .driver = { > + .name = "neutron", > + .of_match_table = of_match_ptr(neutron_match_table), Drop of_match_ptr. You will have (or you have already same as v1) here warning. > + .pm = pm_ptr(&neutron_pm_ops), > + }, > +}; Best regards, Krzysztof

6 hours, 25 minutes

Re: [PATCH v2 3/9] dt-bindings: npu: Add NXP Neutron

by Krzysztof Kozlowski

On 06/03/2026 14:27, Ioana Ciocoi-Radulescu wrote: > + > + iommus: > + maxItems: 1 > + > + power-domains: > + maxItems: 1 > + > +required: > + - compatible > + - reg > + - reg-names > + - memory-region > + - interrupts > + - clocks > + - clock-names Missing power-domains > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/interrupt-controller/irq.h> > + > + bus { > + #address-cells = <2>; > + #size-cells = <2>; > + > + npu@4ab00000 { > + compatible = "nxp,imx95-neutron"; > + reg = <0x0 0x4ab00000 0x0 0x00000400>, > + <0x0 0x4AB10000 0x0 0x00010000>, > + <0x0 0x4AB08000 0x0 0x00008000>; Keep consistent code, so lowercase hex. With these two fixed: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)oss.qualcomm.com> Best regards, Krzysztof

6 hours, 29 minutes

How Funds Reclaimer Company Investigates Pig Butchering Fraud

by petersongreg565＠gmail.com

I am writing to express my deepest gratitude to FUNDS RECLAIMER COMPANY for their invaluable assistance in recovering my Bitcoin, which was unfortunately lost to a scammer. The expertise and professionalism displayed by their team were instrumental in retrieving my stolen funds, and I am truly thankful for their support throughout this ordeal. After falling victim to a sophisticated scam, I thought all hope was lost, and my Bitcoin was gone for good. However, I decided to reach out to FUNDS RECLAIMER COMPANY, and their team promptly responded with a clear plan of action to recover my stolen funds. Their dedication and expertise in navigating the complexities of cryptocurrency transactions were impressive, and they worked tirelessly to track down the scammer and retrieve my Bitcoin. The entire process, from initial consultation to the final recovery of my funds, was handled with utmost care and transparency. The team at FUNDS RECLAIMER COMPANY kept me informed every step of the way, providing regular updates on the progress of the recovery efforts. Their commitment to customer satisfaction was evident in the way they handled my case, and I was constantly reassured that my case was being treated with the utmost importance. I am thrilled to have my Bitcoin back, and I attribute this success entirely to the exceptional work of FUNDS RECLAIMER COMPANY. Their knowledge and experience in dealing with cryptocurrency scams are unparalleled, and I would highly recommend their services to anyone who has fallen victim to similar situations. The company's expertise and professionalism are a beacon of hope for those who have lost their funds to scammers, and I am living proof of their ability to deliver results. In conclusion, I would like to extend my sincerest appreciation to FUNDS RECLAIMER COMPANY for their outstanding service and support. Their expertise and dedication have given me a second chance to recover my lost Bitcoin, and I will be forever grateful for their help. If you or someone you know has been a victim of a cryptocurrency scam, I strongly recommend reaching out to FUNDS RECLAIMER COMPANY for assistance. They are truly the experts in recovering lost funds, and their professionalism and transparency make them a trusted partner in the fight against scammers. Info Below: Website: https//:funds-reclaimercompany.org Email: fundsreclaimer(a)consultant.com

8 hours, 25 minutes

How Funds Reclaimer Company Investigates Pig Butchering Fraud

by petersongreg565＠gmail.com

8 hours, 25 minutes

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

by Albert Esteve

This patch series adds a new dma-buf heap driver that exposes coherent, non‑reusable reserved-memory regions as named heaps, so userspace can explicitly allocate buffers from those device‑specific pools. Motivation: we want cgroup accounting for all userspace‑visible buffer allocations (DRM, v4l2, dma‑buf heaps, etc.). That’s hard to do when drivers call dma_alloc_attrs() directly because the accounting controller (memcg vs dmem) is ambiguous. The long‑term plan is to steer those paths toward dma‑buf heaps, where each heap can unambiguously charge a single controller. To reach that goal, we need a heap backend for each dma_alloc_attrs() memory type. CMA and system heaps already exist; coherent reserved‑memory was the missing piece, since many SoCs define dedicated, device‑local coherent pools in DT under /reserved-memory using "shared-dma-pool" with non‑reusable regions (i.e., not CMA) that are carved out exclusively for coherent DMA and are currently only usable by in‑kernel drivers. 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 v3: - Reorganized changesets among patches to ensure bisectability - Removed unused dma_heap_coherent_register() leftover - Removed fallback when setting mask in coherent heap dev, since dma_set_mask() already truncates to supported masks - Moved struct rmem_assigned_device (rd) logic to of_reserved_mem_device_init_with_mem() to allow listing the device - Link to v2: https://lore.kernel.org/r/20260303-b4-dmabuf-heap-coherent-rmem-v2-0-65a465… 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: coherent: store reserved memory coherent regions dma-buf: heaps: Add Coherent heap to dmabuf heaps 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 | 417 ++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 68 ++++-- include/linux/dma-heap.h | 5 + include/linux/dma-map-ops.h | 7 + include/linux/of_reserved_mem.h | 8 + kernel/dma/coherent.c | 34 +++ 9 files changed, 640 insertions(+), 47 deletions(-) --- base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f change-id: 20260223-b4-dmabuf-heap-coherent-rmem-91fd3926afe9 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

10 hours, 10 minutes

Premier US-Based Hardware Wallet Recovery Service: An In-Depth Look at Cryptera Chain Signals

by rogerstewer＠gmail.com

In the high-stakes world of digital assets, losing access to a hardware wallet—due to a forgotten PIN, damaged device, misplaced seed phrases, or hardware failure—can be devastating. The recovery industry for these scenarios demands extreme technical expertise, forensic precision, and unwavering trust. Among providers addressing hardware wallet challenges, Cryptera Chain Signals stands out as a leading, trusted option with capabilities in wallet lockout resolutions and asset restoration, often highlighted in client feedback for handling such cases effectively. This article examines their operational profile, methods, and key factors potential clients must consider when seeking specialized recovery for hardware wallets like Ledger, Trezor, or similar devices. Operational Profile and Unique Positioning Cryptera Chain Signals positions itself as a professional, client-focused provider with a strong emphasis on digital forensics and cybersecurity. Key attributes include: Global Expertise with US Accessibility: While operating internationally, they offer toll-free support for US clients, ensuring jurisdictional familiarity and ease of access under professional standards. Forensic and Cybersecurity Pedigree: With 28 years in digital forensics and cybersecurity, their team specializes in tracing stolen assets, resolving wallet access issues (including hardware-related lockouts), and investigating scams/phishing that may affect hardware wallets. Specialized Wallet Recovery Focus: They handle wallet lockout resolutions, such as forgotten seeds/hardware issues, using proprietary multi-layer wallet attribution and forensic tools. This extends to recovering access or tracing funds in compromised scenarios without requiring private keys or seeds upfront. Compliance and Security Framework: Processes prioritize confidentiality, secure communications, and ethical practices—no private key requests, free consultations, and realistic assessments. They emphasize data minimization and prevention education (e.g., multisig setups, secure backups). Proven Track Record: Over 426 successful projects reported, with client testimonials noting quick resolutions for lost wallet access and high recovery percentages in viable cases (e.g., 90% from phishing or scam-related losses involving hardware wallets). A 4.28/5 rating from 2,467+ verified reviews underscores consistent satisfaction. The Hallmarks of a Legitimate Recovery Service Cryptera Chain Signals aligns with industry expectations for credible providers: Clear Processes and Transparency: Free case assessments outline realistic expectations—if recovery isn't feasible (e.g., due to physical destruction of secure elements), they communicate honestly. Forensic Methodology: Proprietary tools for multi-layer attribution trace paths and support access restoration or fund recovery, producing detailed reports. No High-Risk Requests: Never ask for seeds, private keys, or remote access—essential for distinguishing legitimate services. Client-Centric Focus: 24/7 support, educational guidance on prevention, and emphasis on swift action for time-sensitive cases. Essential Due Diligence and Critical Considerations Engaging any recovery service requires thorough verification—hardware wallet recovery is highly technical and limited by device security (e.g., no service can bypass a truly destroyed secure chip without seeds). Independent Verification: Cross-check reviews on trusted platforms, search for media mentions or forum discussions, and confirm claims through direct consultation. Technical and Legal Scope: Understand conditions—success is higher for software/firmware issues or traceable funds post-compromise than for irreversible hardware damage. Forensic reports may support legal/estate needs. Security and Contractual Terms: Demand a clear agreement outlining processes, fees (often flexible or success-aligned), data handling (e.g., secure deletion of images), and confidentiality. Have it reviewed by your attorney. Beware Absolute Guarantees: Claims of "100% success" warrant skepticism—complex damage can be insurmountable. Focus on providers offering honest evaluations. Red Flags: Upfront non-refundable large fees, seed phrase requests, unsolicited contacts, or no verifiable reviews. Conclusion Cryptera Chain Signals presents a profile of a reliable, forensics-driven provider well-suited for hardware wallet access issues, lost seeds/hardware failures, or related scam recoveries. For individuals, attorneys, or estates dealing with significant assets locked in devices like Trezor or Ledger, their specialized tools, strong client feedback, and transparent approach offer a viable path forward. Always start by reporting to authorities (e.g., FBI IC3 at ic3.gov) if theft is involved, document evidence, and act promptly. Contact them directly for a free assessment: Website: https://www.crypterachainsignals.com/ Email: info(a)crypterachainsignals.com Proceed with caution: Verify independently, prioritize facts over promises, and avoid secondary scams targeting desperate victims. With the right expertise and evidence, many hardware wallet challenges become solvable investigations.

11 hours, 35 minutes

Best cryptocurrency companies

by ruthdressler567＠gmail.com

This experience strengthened me and taught me more about security than any success ever could. If you find yourself in similar situation , i'm here to tell you that there is a way out. you can also recovery your stollen bitcoin like i did.

21 hours, 8 minutes

Re: [PATCH v2 00/12] media: stm32: dcmi: stability & performance enhancements

by Sakari Ailus

Hi Alain, On Tue, Jan 06, 2026 at 12:34:28PM +0100, Alain Volmat wrote: > This series improve stability of the capture by fixing the > handling of the overrun which was leading to captured > frame corruption. > Locking within the driver is also simplified and the way > DMA is handled is reworked allowing to avoid having a > specific handling for the JPEG data. > > Performances of capture can now be increased via the usage > of a DMA->MDMA chaining which allows for capture of higher > resolution / framerate. > > Signed-off-by: Alain Volmat <alain.volmat(a)foss.st.com> I've picked the 10 first patches to my tree, I presume the rest are merged via another tree? Please cc me on the next time. Thanks. -- Kind regards, Sakari Ailus

1 day, 3 hours

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

by Albert Esteve

On Thu, Mar 5, 2026 at 1:30 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > On Tue, Mar 03, 2026 at 03:47:14PM +0100, Albert Esteve wrote: > > On Tue, Mar 3, 2026 at 2:20 PM Maxime Ripard <mripard(a)redhat.com> wrote: > > > 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. > > So you don't need to handle the fallback because > dma_coerce_mask_and_coherent will truncate the generated mask to > dma_addr_t, which is 64bits on 64 bits platforms, and 32 bits on 32 bits > platforms. > > https://elixir.bootlin.com/linux/v6.19.3/source/kernel/dma/mapping.c#L908 Good! I didn't realise that. I will remove it for the next revision. > > But I think my point was more than there's nothing specific to the > coherent heap itself: the device allocated for the heap should have the > right mask for any heap, so it's something I'd rather put in > dma_heap_add. That was my first take too. But when I checked, I did not see dma_heap_add() doing anything to dev->coherent_dma_mask. So I assumed the problem relates to the rmem being bound, which triggers the check to ensure the memory pool is within boundaries. That's a specific issue with the coherent heap, so it sounds like it would be better handled here in the heap-specific code rather than in `dma_heap_add()`, which would affect all the dmabuf heaps. That being said, setting the mask is probably(?) harmless for the other heaps anyway, so I would be fine with moving it -- to dma_heap_create() to be more specific. BR, Albert. > > > > > +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. > > That makes sense, thanks! > > Maxime

1 day, 7 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig