lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1aa02e8-7f58-46ae-b3df-ae43288cf683@quicinc.com>
Date: Mon, 24 Mar 2025 16:05:33 +0800
From: Baochen Qiang <quic_bqiang@...cinc.com>
To: Johan Hovold <johan@...nel.org>
CC: Johan Hovold <johan+linaro@...nel.org>,
        Jeff Johnson
	<jjohnson@...nel.org>,
        Stephan Gerhold <stephan.gerhold@...aro.org>,
        <ath12k@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] wifi: ath12k: extend dma mask to 36 bits



On 3/24/2025 3:40 PM, Johan Hovold wrote:
> On Mon, Mar 24, 2025 at 11:06:16AM +0800, Baochen Qiang wrote:
>> On 3/22/2025 12:23 AM, Johan Hovold wrote:
>>> Extend the DMA mask to 36 bits to avoid using bounce buffers on machines
>>> without an iommu (under OS control) similar to what was done for ath11k
>>> in commit dbd73acb22d8 ("wifi: ath11k: enable 36 bit mask for stream
>>> DMA").
>>>
>>> This specifically avoids using bounce buffers on Qualcomm Snapdragon X
>>> Elite machines like the Lenovo ThinkPad T14s when running at EL1.
>>
>> why bounce buffer is used at EL1? is it because IOMMU is not working at EL1?
>> or even because IOMMU is not present on Elite machines?
> 
> As I mentioned above, the IOMMU is not under OS control. The boot
> firmware / hypervisor has configured the IOMMU in by-pass mode and it's
> effectively missing from the OS POV.
> 
> Note that this is also the case on Qualcomm platforms like sc8280xp
> (e.g. the Lenovo ThinkPad X13s which already benefits from the extended
> DMA mask for ath11k).
> 
>>> Note that the mask could possibly be extended further but unresolved DMA
>>> issues with 64 GiB X Elite machines currently prevents that from being
>>> tested.
>>
>> could you help elaborate how it could be extended?
> 
> The mask should reflect the capability of the device. That may be
> 64 (or 40) bits, but I've only been able to test using 36 bits.

are you talking about QCN9274? As far as I know, WCN7850 does not support 40 bits or more.

> 
>>> Also note that the driver is limited to 32 bits for coherent
>>> allocations and that there is no need to check for errors when setting
>>> masks larger than 32 bits.
>>
>> why is it not necessary to check error?
> 
> The DMA-API documentation was recently updated to clarify that there is
> no need to check for errors when settings DMA mask with 32 bits or more
> as the call will never fail in that case. See commit
> 
> 	f7ae20f2fc4e ("docs: dma: correct dma_set_mask() sample code")

thanks for the info.

> 
> Johan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ