ath12k: REO status on PPC does not work

ath12k: REO status on PPC does not work

[Alexander Wilhelm]

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.

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?


Best regards
Alexander Wilhelm

Re: ath12k: REO status on PPC does not work

[Sebastian Gottschall]

i played already with big endian platforms and ath11k (not ath12k) for 
months. there is also a problem with the dma descriptors. the firmware 
simply doesnt support big endian with host communication at the end even 
if there is a endian flag for the firmware.  dont get into this rabit 
hole. (i worked 3 months on it and gave up)
at the end (i was working on a cavium octeon platform at that time) i 
just switched the kernel boot to little endian which is possible on many 
ppc platforms too.

Am 15.08.2025 um 10:13 schrieb Alexander Wilhelm:
> 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.
>
> 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?
>
>
> Best regards
> Alexander Wilhelm
>
>

Re: ath12k: REO status on PPC does not work

[Alexander Wilhelm]

Am Fri, Aug 15, 2025 at 11:55:14AM +0200 schrieb Sebastian Gottschall:
> i played already with big endian platforms and ath11k (not ath12k) for
> months. there is also a problem with the dma descriptors. the firmware
> simply doesnt support big endian with host communication at the end even if
> there is a endian flag for the firmware.  dont get into this rabit hole. (i
> worked 3 months on it and gave up)
> at the end (i was working on a cavium octeon platform at that time) i just
> switched the kernel boot to little endian which is possible on many ppc
> platforms too.

The 'ath11k' driver works a bit differently. The endian swap is implemented in
the firmware and was never properly tested. My investigations show that the
firmware does not handle the swap consistently. According to 'kvalo', different
firmware versions treat the swap differently. See [1].

With 'ath12k', the situation looks better. Unfortunately, there are still some
memcpys from u32 to u8 or similar. Also, reading from DMA memory is not swapped.
I already have ath12k running, I get ping responses and can transmit data.
However, not in all modes, and there are still some bugs I’m trying to iron out.


Best regards
Alexander Wilhelm

---
[1] https://lore.kernel.org/ath11k/68290980-5bfb-c88c-be78-954f9591c135@westermo.com/T/#u

Re: ath12k: REO status on PPC does not work

[Sebastian Gottschall]

i just can say. the changes i had to make for ath11k to get big endian 
somwhat working where massive. alot of endian handling in ath11k is 
simply not considered. the firmware is little endian and alot of fields 
must be converted to host endian order. but at end end i struggled with 
dma transactions and gave up since it was not resolvable. the patch i 
made for ath11k was massive at the end and ath12k is not much different
technically ath11k and ath12k can be merged at the end. i dont know why 
there are 2 drivers maintained which are technically very similar at the 
end. alot of patches for ath12k can be applied to ath11k which i do 
sometimes if its a usefull patch. but ath11k itself is abadoned for 
maintainance as it seems (at least if you look for qualcomm supplied 
patches)

Am 15.08.2025 um 12:26 schrieb Alexander Wilhelm:
> Am Fri, Aug 15, 2025 at 11:55:14AM +0200 schrieb Sebastian Gottschall:
>> i played already with big endian platforms and ath11k (not ath12k) for
>> months. there is also a problem with the dma descriptors. the firmware
>> simply doesnt support big endian with host communication at the end even if
>> there is a endian flag for the firmware.  dont get into this rabit hole. (i
>> worked 3 months on it and gave up)
>> at the end (i was working on a cavium octeon platform at that time) i just
>> switched the kernel boot to little endian which is possible on many ppc
>> platforms too.
> The 'ath11k' driver works a bit differently. The endian swap is implemented in
> the firmware and was never properly tested. My investigations show that the
> firmware does not handle the swap consistently. According to 'kvalo', different
> firmware versions treat the swap differently. See [1].
>
> With 'ath12k', the situation looks better. Unfortunately, there are still some
> memcpys from u32 to u8 or similar. Also, reading from DMA memory is not swapped.
> I already have ath12k running, I get ping responses and can transmit data.
> However, not in all modes, and there are still some bugs I’m trying to iron out.
>
>
> Best regards
> Alexander Wilhelm
>
> ---
> [1] https://lore.kernel.org/ath11k/68290980-5bfb-c88c-be78-954f9591c135@westermo.com/T/#u
>

Re: ath12k: REO status on PPC does not work

[Alexander Wilhelm]

Am Fri, Aug 15, 2025 at 12:50:00PM +0200 schrieb Sebastian Gottschall:
> i just can say. the changes i had to make for ath11k to get big endian
> somwhat working where massive. alot of endian handling in ath11k is simply
> not considered. the firmware is little endian and alot of fields must be
> converted to host endian order. but at end end i struggled with dma
> transactions and gave up since it was not resolvable. the patch i made for
> ath11k was massive at the end and ath12k is not much different
> technically ath11k and ath12k can be merged at the end. i dont know why
> there are 2 drivers maintained which are technically very similar at the
> end. alot of patches for ath12k can be applied to ath11k which i do
> sometimes if its a usefull patch. but ath11k itself is abadoned for
> maintainance as it seems (at least if you look for qualcomm supplied
> patches)

Regarding the ath11k driver, sure, if the firmware doesn't handle the swap
correctly, it should be disabled and managed directly in the driver. I’ve
already have a patch for this, spanning over 10K lines, which I plan to
upstream at some point.

In contrast, the ath12k driver performs the swap internally from the beginning.
I only had to make a few minor changes to get a working ping. Some patches are
already in the queue, and others have already been merged upstream.


Best regards
Alexander Wilhelm

Re: ath12k: REO status on PPC does not work

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

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

> Best regards
> Alexander Wilhelm
>

Re: ath12k: REO status on PPC does not work

[Alexander Wilhelm]

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

Re: ath12k: REO status on PPC does not work

[Baochen Qiang]

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?

Re: ath12k: REO status on PPC does not work

[Alexander Wilhelm]

Am Tue, Aug 19, 2025 at 03:26:34PM +0800 schrieb Baochen Qiang:
> 
> 
> 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.

Yes, I see it the same way.

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

For example, in the function 'ath12k_dp_rx_peer_tid_delete', the function
'ath12k_dp_reo_cmd_send' is called, which in turn registers the function
'ath12k_dp_rx_tid_del_func' as a callback. On PowerPC, this callback function is
never invoked, which eventually leads to the following error:

    ath12k_pci 0002:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 15 (-105)
    ath12k_pci 0002:01:00.0: failed to update rx tid queue, tid 0 (-105)
    ath12k_pci 0002:01:00.0: failed to update reo for rx tid 0
    ath12k_pci 0002:01:00.0: failed to setup rx tid -105
    ath12k_pci 0002:01:00.0: pdev idx 0 unable to perform ampdu action 0 ret -105

My investigations have shown that a cache flush is supposed to happen at some
point, e.g. after a timeout or when a threshold of 64 is reached. Since this
does not happen, I encounter errors after the 127th 'cmd_num'. This callback
function should actually be called from the 'reo_cmd_list' within the function
'ath12k_dp_rx_process_reo_status'. However, this does not happen because the
pointer is always 0.

I hope I was able to explain clearly what I was able to trace. Please correct me
if any of my assumptions are wrong.


Best regards
Alexander Wilhelm

Re: ath12k: REO status on PPC does not work

[Vasanthakumar Thiagarajan]

On 8/19/2025 1:40 PM, Alexander Wilhelm wrote:
> Am Tue, Aug 19, 2025 at 03:26:34PM +0800 schrieb Baochen Qiang:
>>
>>
>> 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.
> 
> Yes, I see it the same way.
> 
>>>>> 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?
> 
> For example, in the function 'ath12k_dp_rx_peer_tid_delete', the function
> 'ath12k_dp_reo_cmd_send' is called, which in turn registers the function
> 'ath12k_dp_rx_tid_del_func' as a callback. On PowerPC, this callback function is
> never invoked, which eventually leads to the following error:
> 
>      ath12k_pci 0002:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 15 (-105)
>      ath12k_pci 0002:01:00.0: failed to update rx tid queue, tid 0 (-105)
>      ath12k_pci 0002:01:00.0: failed to update reo for rx tid 0
>      ath12k_pci 0002:01:00.0: failed to setup rx tid -105
>      ath12k_pci 0002:01:00.0: pdev idx 0 unable to perform ampdu action 0 ret -105
> 
> My investigations have shown that a cache flush is supposed to happen at some
> point, e.g. after a timeout or when a threshold of 64 is reached. Since this
> does not happen, I encounter errors after the 127th 'cmd_num'. This callback
> function should actually be called from the 'reo_cmd_list' within the function
> 'ath12k_dp_rx_process_reo_status'. However, this does not happen because the
> pointer is always 0.
> 
> I hope I was able to explain clearly what I was able to trace. Please correct me
> if any of my assumptions are wrong.

Your understanding is mostly correct. it is also possible that there may be something
missing in REO_CMD ring (setup and cmd_send) which shows symptom like this in
REO_STATUS ring processing. If other src and dst rings are working fine,
REO_CMD/STATUS rings also are expected to work. Pls check src and dst ring
setup path once again.

Vasanth

Re: ath12k: REO status on PPC does not work

[Alexander Wilhelm]

Am Tue, Aug 19, 2025 at 02:51:16PM +0530 schrieb Vasanthakumar Thiagarajan:
> 
> 
> On 8/19/2025 1:40 PM, Alexander Wilhelm wrote:
> > Am Tue, Aug 19, 2025 at 03:26:34PM +0800 schrieb Baochen Qiang:
> > > 
> > > 
> > > 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.
> > 
> > Yes, I see it the same way.
> > 
> > > > > > 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?
> > 
> > For example, in the function 'ath12k_dp_rx_peer_tid_delete', the function
> > 'ath12k_dp_reo_cmd_send' is called, which in turn registers the function
> > 'ath12k_dp_rx_tid_del_func' as a callback. On PowerPC, this callback function is
> > never invoked, which eventually leads to the following error:
> > 
> >      ath12k_pci 0002:01:00.0: failed to send HAL_REO_CMD_UPDATE_RX_QUEUE cmd, tid 15 (-105)
> >      ath12k_pci 0002:01:00.0: failed to update rx tid queue, tid 0 (-105)
> >      ath12k_pci 0002:01:00.0: failed to update reo for rx tid 0
> >      ath12k_pci 0002:01:00.0: failed to setup rx tid -105
> >      ath12k_pci 0002:01:00.0: pdev idx 0 unable to perform ampdu action 0 ret -105
> > 
> > My investigations have shown that a cache flush is supposed to happen at some
> > point, e.g. after a timeout or when a threshold of 64 is reached. Since this
> > does not happen, I encounter errors after the 127th 'cmd_num'. This callback
> > function should actually be called from the 'reo_cmd_list' within the function
> > 'ath12k_dp_rx_process_reo_status'. However, this does not happen because the
> > pointer is always 0.
> > 
> > I hope I was able to explain clearly what I was able to trace. Please correct me
> > if any of my assumptions are wrong.
> 
> Your understanding is mostly correct. it is also possible that there may be something
> missing in REO_CMD ring (setup and cmd_send) which shows symptom like this in
> REO_STATUS ring processing. If other src and dst rings are working fine,
> REO_CMD/STATUS rings also are expected to work. Pls check src and dst ring
> setup path once again.

Thanks you for the hint regarding the REO_CMD ring, it helped me track down the
issue. The problem was with the 'tl' field in the 'hal_tlv_64_hdr' structure: it
should be declared as '__le64' instead of 'u64', similar to the '__le32 tl'
field in 'hal_tlv_hdr'. As a result, some necessary endianness conversions were
missing.


Best regards
Alexander Wilhelm