From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F22D23EEAC4 for ; Tue, 14 Jul 2026 07:35:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784014552; cv=none; b=aEJ1cm9w5Pjsvzz2gk+9vPDQCuicZbyy2oxh+BFvc6XKx+xUyloj8fJSH0foOGtQVL1waFUZKqoQ31HcxVy3uinmvAsyYlwfUJ22iIv1bXaoKJgqlCF5SGDnRNnmXlvx/LS/blRQTdw5IDDRCcsgdAKVU2wV5rx3xSy+gLDliZA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784014552; c=relaxed/simple; bh=thE6MKDBgxQ/2kTxtQxylJzWWa2DTPV9HWq/Oqshg8w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lNTFMRR9e6UqHBq1tE4/8/PnOvb7vNhlDwyUndu3LhdRzmCtL+CqxQctkFCbmkxaUndKpKg1c9QpEHn/AXiPISjSxPYp1LkthOdOteNcCWYuCJ4sZIVZiA/fwKaBWJKefS5eoEXBKIXyZIYy+f+ZHtEbzhIvgynargps8f2+WuA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=PQjSbYhG; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="PQjSbYhG" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-4720d22c94aso594842f8f.1 for ; Tue, 14 Jul 2026 00:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784014549; x=1784619349; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=EZDP77brQ5bvhb37m4sjMTk+Xtc5WyoVuJCcZEy5/Us=; b=PQjSbYhG7l9ASUYQmKlYFS+sKvO+M8bmtQiQpO9+yci4idNJeTkjbL0liIGnl2qYXn 4YwVv3dN31nMt73EBvIVlJaIKZrBvjRJabefKFt0zaxRhJl8lokR4kW3bl/I2s5E4PvT q1QHKu7/4S1FuN+Y+hrRgOhQBCThOZwpqAgTV4omkYPO1e7VcnmhoV+b5STXEEe1r5JD d2Bqk6T0LHKEqMVA4FWw8NzyVrUhNfycHspKydsrGqcJg6jesH7fzT3sJMZWcOGP+ZUy BUXuj/2K7xFFBLBSHv8pg7qWtHmhXty2UH8Rr5vRZNuN/t0mIlCDBpsa+hcTk90njqgk B31Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784014549; x=1784619349; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EZDP77brQ5bvhb37m4sjMTk+Xtc5WyoVuJCcZEy5/Us=; b=AfvDR6qP47XlG/VbQFacUJkX3ov5aKNTT3/0aeDQ/a/V8D7oF6nIsrtWIR/UCyAnmY r4AXaMUzjMgcG2zQEkpZJsoFVGQDlbYQ2GaPDDLcgWVly4pNRMgZ3NrkSQTrikE2LZQr JUQ41gDBEng0xfoFsRdbkKC8NFJc0ACjHUc8J+zE7ABn78+3gDVrqv9fVGNZCD6f84Jb bDWAmJKxYLNtT4IW58VrEfYc3cMU5uF7tiysmdHR9o9lUin8KPU6ven76uaGU8Unrqxy DQeXx2pTH2WL3ubhaZ2G3xxHUOgFs9NP6yEvz6hHb+a17FV+UV+WGMcmpzCp6Dk38vXY Rqrw== X-Forwarded-Encrypted: i=1; AHgh+RriZHOkahFYjCxhBJIhR9VaEMNdBbPfBtUEfhIPWOvdEpob17fsKIy9jet4SwSRUoL1fqOWQm4H+U6hJos=@vger.kernel.org X-Gm-Message-State: AOJu0YwFmpTyf+ieWlCY9kq0FfasuC6d4hkXgk6C2udZMcduLcBHwVSu HZWjkz7ifa/jiwu2ADo8RZmGIMB3bYISDrFTNIW0vQPKnLJ06gt68KotpwP3P7xoStg= X-Gm-Gg: AfdE7clZa9OlrVtjjjrinXFsyeZ1a5w446UDMbTqdIPfNU1W/K675gQ2z5ngUxUKpqz Ndy8B9h0sEgUo4Y13Hv4McV0h/7oUfJSQ6DqTciSNtrOQsTYAeUtnx6Qm8Jdvs3jLRvtmoloMCw 7F2y2qoPuM/EkfX0htuN0n/0qhWbvPfnzrtJFuiC0a+WMiHDfRoBCYkwm+9wwUjz4v7fjfLKlxB ezZT41cYB3RY3dB4C/z6MMBE/2WHSYtXIPg1hxUw0o8R9PyBLYfefG6KcC5kAydryWfSgMHnEX9 yZHXwhzFEDDlOz/k2FxLl3gCEjmvkM2Nk8T3kTPbDk8vKMEvKqhjl0T8pliWOKyqKcd62jQgYvt z4Rp07kVSbwDqHs7pznn+yZy45VG7ltvrRMMkwAmF1eb8niiurNSzbUt2qWbOVqu0azr8/5elWG kWLzbo3+9uKdmk7sygt7NrI/1G X-Received: by 2002:a05:6000:2404:b0:473:673e:3836 with SMTP id ffacd0b85a97d-47f2dcf8a3amr14217779f8f.28.1784014549221; Tue, 14 Jul 2026 00:35:49 -0700 (PDT) Received: from linaro.org ([2a02:2454:ff24:7210:6c30:6cbd:7b12:2745]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f464caeffsm5599960f8f.36.2026.07.14.00.35.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 00:35:48 -0700 (PDT) Date: Tue, 14 Jul 2026 09:35:46 +0200 From: Stephan Gerhold To: Vishnu Santhosh Cc: Stephan Gerhold , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Loic Poulain , Sergey Ryazanov , Johannes Berg , linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, chris.lew@oss.qualcomm.com, Deepak Kumar Singh Subject: Re: [PATCH 2/2] net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block Message-ID: References: <20260714-qcom-bam-dmux-vmid-ext-v1-0-3f29da7cca76@oss.qualcomm.com> <20260714-qcom-bam-dmux-vmid-ext-v1-2-3f29da7cca76@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260714-qcom-bam-dmux-vmid-ext-v1-2-3f29da7cca76@oss.qualcomm.com> On Tue, Jul 14, 2026 at 11:02:32AM +0530, Vishnu Santhosh wrote: > On Qualcomm SoCs where the modem (e.g. the mDSP on Shikra, VMID 43 / > NAV) is the AXI master for BAM-DMUX RX transfers and the XPU enforces > per-region access control, each individually DMA-mapped RX buffer > requires its own XPU resource group (RG). With ~16 RGs available, the > 32 per-buffer dma_map_single() calls exhaust the table and the first > inbound transfer faults with an XPU violation. > > BAM-DMUX is a singleton (exactly one instance per SoC), so the > destination VMID does not need to be a DT property; it is looked up > from the compatible string's match data instead. Add struct > bam_dmux_data with a single vmid field, and a shikra_data instance > hardcoding QCOM_SCM_VMID_NAV for qcom,shikra-bam-dmux. > > When match data is present, allocate all BAM_DMUX_NUM_SKB RX buffers as > a single contiguous dma_alloc_coherent() block and SCM-assign that > block to HLOS plus the VMID once at probe. This reduces RG consumption > from 32 to 1. The block is never reclaimed across a modem power cycle > (bam_dmux_power_off() does not touch it), so the probe-time assignment > covers every subsequent restart without re-assigning or reclaiming. It > is reclaimed to HLOS only once, at remove or on a probe error, and if > that reclaim fails it is leaked rather than returned to the page > allocator. > > Each rx_skbs[] slot is pre-assigned its virtual and DMA address from > the block, so no per-buffer mapping is needed at power-on. Because the > coherent block is not page-backed, received payload is copied into a > regular netdev skb before handoff to the network stack; this is an > unavoidable extra copy on the XPU-enforced RX path. > > Platforms without match data are unaffected: rx_virt stays NULL, no > coherent memory is allocated, and the per-buffer dma_map_single() path > is unchanged. > > Co-developed-by: Deepak Kumar Singh > Signed-off-by: Deepak Kumar Singh > Signed-off-by: Vishnu Santhosh So how do you handle TX buffers? Right now, they are just passed on from the net subsystem. There can be up to 32 TX buffers in progress as well. Overall, I have mixed feelings about this patch. It looks reasonably simple, but fundamentally I don't understand why we need to go back to the old days of implementing protection using a highly limited MPU (in your case: the xPU). Why does the setup of BAM-DMUX differ e.g. from the setup for the crypto engine? Crypto is also using bam-dma, but it avoids this inflexibility by making use of the &apps_smmu. Is BAM-DMUX not covered by the SMMU? Or did you just decide to bypass the SMMU in this case? (If so: Why?) If you had BAM-DMUX mapped using the SMMU you would get all of this for free. No changes would be needed in the BAM-DMUX driver ... Thanks, Stephan