linux-kernel - Re: ath12k: REO status on PPC does not work

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: <aKQg5vLUplzMUMlU@FUE-ALEWI-WINX>
Date: Tue, 19 Aug 2025 08:59:50 +0200
From: Alexander Wilhelm <alexander.wilhelm@...termo.com>
To: Baochen Qiang <baochen.qiang@....qualcomm.com>
Cc: Jeff Johnson <jjohnson@...nel.org>, ath12k@...ts.infradead.org,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ath12k: REO status on PPC does not work

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
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);

> > 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.


Best regards
Alexander Wilhelm