From: Vivek Pernamitta <quic_vpernami@quicinc.com>

Certain devices like QDU100 bootloader support only up to a 32-bit DMA
address range. However, Virtual Functions (VFs) are enabled only after
the device enters Mission Mode and can support higher DMA address ranges
(up to 40 bits).

A 32-bit DMA mask limits addressable space to 4GiB, which is insufficient
for data transfer requirements over VFs on platforms like QDU100. These
devices require larger memory regions to be mapped for efficient VF
operation.

To address this, configure `dma_mask` independently for Physical Functions
(PFs) and Virtual Functions (VFs), allowing VFs to use higher DMA mask
values where supported.

As per PCIe SR-IOV specification (rev 0.9, Section 1), VFs are capable of
handling resources associated with the main data movement of the Function.

This change ensures compatibility with bootloaders that have limited DMA
capabilities while enabling full VF functionality once the device reaches
Mission Mode.

Signed-off-by: Vivek Pernamitta <quic_vpernami@quicinc.com>
---
 drivers/bus/mhi/host/pci_generic.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
index f922cca0ab633aeae942587f0c40038342ce9c33..fad08bdd59919a1cab05e9864fb38151ef79e457 100644
--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -41,6 +41,7 @@
  * @edl_trigger: capable of triggering EDL mode in the device (if supported)
  * @bar_num: PCI base address register to use for MHI MMIO register space
  * @dma_data_width: DMA transfer word size (32 or 64 bits)
+ * @vf_dma_data_width: DMA transfer word size for VF's (optional)
  * @mru_default: default MRU size for MBIM network packets
  * @sideband_wake: Devices using dedicated sideband GPIO for wakeup instead
  *		   of inband wake support (such as sdx24)
@@ -57,6 +58,7 @@ struct mhi_pci_dev_info {
 	bool edl_trigger;
 	unsigned int bar_num;
 	unsigned int dma_data_width;
+	unsigned int vf_dma_data_width;
 	unsigned int mru_default;
 	bool sideband_wake;
 	bool no_m3;
@@ -301,6 +303,7 @@ static const struct mhi_pci_dev_info mhi_qcom_qdu100_info = {
 	.config = &mhi_qcom_qdu100_config,
 	.bar_num = MHI_PCI_DEFAULT_BAR_NUM,
 	.dma_data_width = 32,
+	.vf_dma_data_width = 40,
 	.sideband_wake = false,
 	.no_m3 = true,
 	.reset_on_remove = true,
@@ -1312,6 +1315,7 @@ static int mhi_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	const struct mhi_controller_config *mhi_cntrl_config;
 	struct mhi_pci_device *mhi_pdev;
 	struct mhi_controller *mhi_cntrl;
+	unsigned int dma_data_width;
 	int err;
 
 	dev_info(&pdev->dev, "MHI PCI device found: %s\n", info->name);
@@ -1333,9 +1337,12 @@ static int mhi_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 
 	mhi_cntrl = &mhi_pdev->mhi_cntrl;
 
+	dma_data_width = (pdev->is_virtfn && info->vf_dma_data_width) ?
+			  info->vf_dma_data_width : info->dma_data_width;
+
 	mhi_cntrl->cntrl_dev = &pdev->dev;
 	mhi_cntrl->iova_start = 0;
-	mhi_cntrl->iova_stop = (dma_addr_t)DMA_BIT_MASK(info->dma_data_width);
+	mhi_cntrl->iova_stop = (dma_addr_t)DMA_BIT_MASK(dma_data_width);
 	mhi_cntrl->fw_image = info->fw;
 	mhi_cntrl->edl_image = info->edl;
 
@@ -1359,7 +1366,7 @@ static int mhi_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 		mhi_cntrl->wake_toggle = mhi_pci_wake_toggle_nop;
 	}
 
-	err = mhi_pci_claim(mhi_cntrl, info->bar_num, DMA_BIT_MASK(info->dma_data_width));
+	err = mhi_pci_claim(mhi_cntrl, info->bar_num, DMA_BIT_MASK(dma_data_width));
 	if (err)
 		return err;
 

-- 
2.34.1

On Thu, Aug 21, 2025 at 06:25:38PM GMT, Vivek.Pernamitta@quicinc.com wrote:
> From: Vivek Pernamitta <quic_vpernami@quicinc.com>
> 
> Certain devices like QDU100 bootloader support only up to a 32-bit DMA
> address range. However, Virtual Functions (VFs) are enabled only after
> the device enters Mission Mode and can support higher DMA address ranges
> (up to 40 bits).
> 
> A 32-bit DMA mask limits addressable space to 4GiB, which is insufficient
> for data transfer requirements over VFs on platforms like QDU100. These
> devices require larger memory regions to be mapped for efficient VF
> operation.
> 
> To address this, configure `dma_mask` independently for Physical Functions
> (PFs) and Virtual Functions (VFs), allowing VFs to use higher DMA mask
> values where supported.
> 
> As per PCIe SR-IOV specification (rev 0.9, Section 1), VFs are capable of
> handling resources associated with the main data movement of the Function.
> 
> This change ensures compatibility with bootloaders that have limited DMA
> capabilities while enabling full VF functionality once the device reaches
> Mission Mode.

Compatibility is with the existing non-SR-IOV devices, isn't it? How does
bootloader comes into picture for them?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

On 9/5/2025 8:33 PM, Manivannan Sadhasivam wrote:
> On Thu, Aug 21, 2025 at 06:25:38PM GMT, Vivek.Pernamitta@quicinc.com wrote:
>> From: Vivek Pernamitta <quic_vpernami@quicinc.com>
>>
>> Certain devices like QDU100 bootloader support only up to a 32-bit DMA
>> address range. However, Virtual Functions (VFs) are enabled only after
>> the device enters Mission Mode and can support higher DMA address ranges
>> (up to 40 bits).
>>
>> A 32-bit DMA mask limits addressable space to 4GiB, which is insufficient
>> for data transfer requirements over VFs on platforms like QDU100. These
>> devices require larger memory regions to be mapped for efficient VF
>> operation.
>>
>> To address this, configure `dma_mask` independently for Physical Functions
>> (PFs) and Virtual Functions (VFs), allowing VFs to use higher DMA mask
>> values where supported.
>>
>> As per PCIe SR-IOV specification (rev 0.9, Section 1), VFs are capable of
>> handling resources associated with the main data movement of the Function.
>>>> This change ensures compatibility with bootloaders that have limited DMA
>> capabilities while enabling full VF functionality once the device reaches
>> Mission Mode.
> 
> Compatibility is with the existing non-SR-IOV devices, isn't it? How does
> bootloader comes into picture for them?
> 
Set "vf_dma_data_width" explicitly for SR-IOV devices where VFs support
64-bit DMA but PFs do not. For non-SRIOV devices, this flag should 
remain dma_data_width unset and defaults to zero.  If both bootloader
and HLOS support the  same DMA width and for non-SRIOV device, set the
flag "dma_data_width" alone to the maximum supported bits to ensure
compatibility and performance.> - Mani
>