Linux wireless drivers development
 help / color / mirror / Atom feed
From: Alexander Wilhelm <alexander.wilhelm@westermo.com>
To: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Cc: Jeff Johnson <jjohnson@kernel.org>,
	linux-wireless@vger.kernel.org, ath12k@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian
Date: Fri, 3 Jul 2026 09:48:15 +0200	[thread overview]
Message-ID: <akdpP27BE6kBEh1V@FUE-ALEWI-WINX> (raw)
In-Reply-To: <606bc37c-45ff-41d3-8f0f-942c3009c4b4@oss.qualcomm.com>

On Fri, Jul 03, 2026 at 03:10:23PM +0800, Baochen Qiang wrote:
> 
> 
> On 7/3/2026 2:36 PM, Alexander Wilhelm wrote:
> > On Fri, Jul 03, 2026 at 12:04:10PM +0800, Baochen Qiang wrote:
> >>
> >>
> >> On 7/2/2026 8:06 PM, Alexander Wilhelm wrote:
> >>> On Thu, Jul 02, 2026 at 05:56:01PM +0800, Baochen Qiang wrote:
> >>>>
> >>>>
> >>>> 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.
> >>
> >> I think I can understand the behavior here: even if wakeup happens, the waiter in
> >> ath12k_wait_for_dp_link_peer_common() checks the map result by calling
> >> ath12k_dp_link_peer_find_by_vdev_and_addr(). Since the mac addr of the newly created peer
> >> does not match, check failed. Finally we get timeout.
> >>
> >>>
> >>> I have now added the following debug output for `peer_map_ev` inside of
> >>> `ath12k_dp_htt_htc_t2h_msg_handler`:
> >>>
> >>>     /* DEBUG */
> >>>     switch (type) {
> >>>     case HTT_T2H_MSG_TYPE_PEER_MAP:
> >>>     case HTT_T2H_MSG_TYPE_PEER_MAP2:
> >>>     case HTT_T2H_MSG_TYPE_PEER_MAP3:
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info: %08X\n", le32_to_cpu(resp->peer_map_ev.info));
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.mac_addr_l32: %08X\n", le32_to_cpu(resp->peer_map_ev.mac_addr_l32));
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info1: %08X\n", le32_to_cpu(resp->peer_map_ev.info1));
> >>>         ath12k_err(ab, "[DEBUG]: resp->peer_map_ev.info2: %08X\n", le32_to_cpu(resp->peer_map_ev.info2));
> >>>         break;
> >>>     default:
> >>>         break;
> >>>     }
> >>>
> >>> Here is the result:
> >>>
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
> >>>     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
> >>>     ath12k_pci 0001:01:00.0: failed to vdev 0 create peer for AP: -110
> >>>     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
> >>>
> >>> Let me know if you see anything suspicious or if you need additional debug
> >>> information.
> >>
> >> I am not really sure about the final mac addr and vdev id passed to
> >> ath12k_dp_link_peer_map_event(), so can you also add print below?
> >>
> >> diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> b/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> index 47d009a0d61f..3e8201d536a5 100644
> >> --- a/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> +++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
> >> @@ -162,6 +162,9 @@ void ath12k_dp_link_peer_map_event(struct ath12k_base *ab, u8 vdev_id,
> >> u16 peer_
> >>         struct ath12k_dp *dp = ath12k_ab_to_dp(ab);
> >>         struct ath12k *ar;
> >>
> >> +       pr_info("peer map event: vdev_id %u peer_id %u mac_addr %pM ast_hash %u hw_peer_id
> >> %u\n",
> >> +               vdev_id, peer_id, mac_addr, ast_hash, hw_peer_id);
> >> +
> >>         spin_lock_bh(&dp->dp_lock);
> >>         peer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, vdev_id, mac_addr);
> >>         if (!peer) {
> > 
> > Sure, here is the output:
> > 
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info: 0002002B
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.mac_addr_l32: C921F004
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info1: FFFF0EE0
> >     ath12k_pci 0001:01:00.0: [DEBUG]: resp->peer_map_ev.info2: 000502F5
> >     peer map event: vdev_id 0 peer_id 2 mac_addr d902298bM ast_hash 5 hw_peer_id 757
> 
> what is d902298bM? are you using Linux? seems %pM is not properly formatted in your
> environment.

Sory. I got a typo while copy-and-paste. Here's the output:

    peer map event: vdev_id 0 peer_id 2 mac_addr c9:21:f0:04:0e:e0 ast_hash 5 hw_peer_id 757


Best regards
Alexander Wilhelm

      reply	other threads:[~2026-07-03  7:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29  7:55 [PATCH RESEND] wifi: ath12k: fix MAC address copy on big endian Alexander Wilhelm
2026-07-02  8:12 ` Baochen Qiang
2026-07-02  8:41   ` Alexander Wilhelm
2026-07-02  9:17     ` Alexander Wilhelm
2026-07-02  9:56       ` Baochen Qiang
2026-07-02 12:06         ` Alexander Wilhelm
2026-07-03  4:04           ` Baochen Qiang
2026-07-03  6:36             ` Alexander Wilhelm
2026-07-03  7:10               ` Baochen Qiang
2026-07-03  7:48                 ` Alexander Wilhelm [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=akdpP27BE6kBEh1V@FUE-ALEWI-WINX \
    --to=alexander.wilhelm@westermo.com \
    --cc=ath12k@lists.infradead.org \
    --cc=baochen.qiang@oss.qualcomm.com \
    --cc=jjohnson@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox