Received-SPF: pass (google.com: domain of linux-wireless+bounces-7124-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <b3999eec-e370-4c85-80b9-759f25ed98bf@gmail.com>
Date: Thu, 2 May 2024 22:27:31 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] wifi: ath11k: fix remapped ce accessing issue on 64bit OS
To: Jeff Johnson <quic_jjohnson@quicinc.com>,
 Ziyang Huang <hzyitc@outlook.com>, kvalo@kernel.org
Cc: jjohnson@kernel.org, linux-wireless@vger.kernel.org,
 ath11k@lists.infradead.org, linux-kernel@vger.kernel.org
References: <TYZPR01MB55563B3A689D54D18179E5B4C9192@TYZPR01MB5556.apcprd01.prod.exchangelabs.com>
 <6336ffc7-d8ae-4cfd-8b66-d6d91cb0d15e@quicinc.com>
Content-Language: en-US
From: Sergey Ryazanov <ryazanov.s.a@gmail.com>
In-Reply-To: <6336ffc7-d8ae-4cfd-8b66-d6d91cb0d15e@quicinc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jeff,

On 01.05.2024 19:56, Jeff Johnson wrote:
> On 5/1/2024 9:14 AM, Ziyang Huang wrote:
>> On 64bit OS, when ab->mem_ce is lower than or 4G far away from ab->mem,
>> u32 is not enough to store the offsets, which makes ath11k_ahb_read32()
>> and ath11k_ahb_write32() access incorrect address and causes Data Abort
>> Exception.
> 
> Are you actually observing this issue?
> Or is this a hypothetical situation?

Yep. This is the real issue. I faced it on IPQ5018 with 64bits kernel.

>> Let's use the high bits of offsets to decide where to access, which is
>> similar as ath11k_pci_get_window_start() done. In the future, we can merge
>> these functions for unified regs accessing.
> 
> Performing unnecessary tests and masking for every ioread/write operation will
> potentially impact performance.
> 
> What other fixes were considered (i.e. did you consider making all the
> register addresses u64?)

Probably, making argument u64 could also be too much. I/O address space 
of this chip fits 4GB so u32 should be enough. I have a bit different 
fix for this bug. It introduces an indirect call for the CE registers 
access and a dedicated set of accessing functions for chips that has the 
CE region outside the main I/O area. I am going to publish it in a 
couple of weeks, when I will come from a trip. The patch still needs 
some polishing.

--
Sergey