Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian

[Baochen Qiang <baochen.qiang@oss.qualcomm.com>]

On 7/2/2026 5:17 PM, Alexander Wilhelm wrote:
> On Thu, Jul 02, 2026 at 10:41:25AM +0200, Alexander Wilhelm wrote:
>> On Thu, Jul 02, 2026 at 04:12:00PM +0800, Baochen Qiang wrote:
>>>
>>>
>>> On 6/29/2026 3:55 PM, Alexander Wilhelm wrote:
>>>> The ath12k_dp_get_mac_addr function performs a simple memcpy from a
>>>> CPU-native data types into an u8 array. On a big-endian architecture, this
>>>> later results in a null‑pointer dereference. Convert the data to
>>>
>>> Alex, did you find a time to investigate the root cause of the null pointer?
> 
> Hi Baochen,
> 
> I am now running kernel v6.18.26, and it looks like the null-pointer issue is
> gone. I only see the following log messages:
> 
>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110

what is the actual mac addr reported from firmware in the PEER MAP event? My understanding
is that, without this patch (if we really need it) we get a wrong mac addr, then in
ath12k_dp_link_peer_map_event() we are more likely to fail the peer look up hence would
create a new peer and wakeup the waiting thread. But the log here clearly indicates that
the wait timeout, which does not make sense to me.

>     ath12k_pci 0001:01:00.0: failed to create vdev 04:f0:21:c9:e0:0e ret -110
>     ath12k_pci 0001:01:00.0: failed to assign chanctx for vif 04:f0:21:c9:e0:0e link id 0 link vif is already started
>     ath12k_pci 0001:01:00.0: invalid vdev id in vdev delete resp ev 0
> 
> Should I rebase the patch onto the latest `ath/master` branch and update the
> commit description accordingly?
> 
> 
> Best regards
> Alexander Wilhelm