On 8/19/2025 2:59 PM, Alexander Wilhelm wrote: > Am Tue, Aug 19, 2025 at 02:38:38PM +0800 schrieb Baochen Qiang: >> >> >> On 8/15/2025 4:13 PM, Alexander Wilhelm wrote: >>> Hello devs, >>> >>> I'm currently working on getting the 'ath12k' driver running on a big endian >>> PowerPC platform and have encountered the following issue. >>> >>> In the function 'ath12k_dp_rx_process_reo_status', the REO status is determined >>> by inspecting memory that the hardware has previously written via DMA. >>> Specifically, during the call to 'ath12k_hal_srng_access_begin', the driver >>> reads the value of 'hp_addr' for the destination ring (in my case, always with >>> ID 21). On the big endian platform, this value is consistently 0, which prevents >>> the REO status from being updated. >> >> This does not seem an endian issue to me, because either of them we should get a value >> other than 0. > > Really? I always assumed the value remains 0 until the firmware writes something > to memory and moves the head pointer of the SRNG ring buffer. By the way, I've correct! > already implemented the missing endianness conversions for reading from and > writing to ring buffer pointers like this one: > > hp = le32_to_cpu(*srng->u.dst_ring.hp_addr); I was actually meaning that, when hp get updated by firmware, either with or without le32_to_cpu conversion, we should get a value other than 0. So in your cause I am suspecting that hardware/firmware has never sent any REO status to host. > >>> Interestingly, DMA read/write accesses work fine for other rings, just not for >>> this one. What makes the REO status ring so special? I couldn’t find anything in >>> the initialization routine that would explain the difference. >>> >>> Could anyone give me a hint on what I should be looking for? >>> >>> >> What hardware are you using? WCN7850 or QCN9274? > > I'm using QCN9274-based dualmac modules. sure > > > Best regards > Alexander Wilhelm so did you see any obvious issue?
