From: "Nicolas Escande" <nico.escande@gmail.com>
To: "Karthikeyan Periyasamy" <quic_periyasa@quicinc.com>,
<ath12k@lists.infradead.org>
Subject: Re: Weird layout of struct hal_rx_desc_qcn9274
Date: Thu, 05 Sep 2024 15:06:21 +0200 [thread overview]
Message-ID: <D3YDFV83HICP.3605AE2L7PIE9@gmail.com> (raw)
In-Reply-To: <D3XL7VMHE62Y.3JJPEKV07MJAS@gmail.com>
On 2024-09-05 4:53, Karthikeyan Periyasamy wrote:
[...]
> >
> > So it seems without the quadword registration, even though qcn9274 & wcn7850
> > appears to have similar layout, the __le64 msdu_end_tag is present in the struct
> > hal_rx_desc_wcn7850 but not in struct hal_rx_desc_qcn9274. That seems weird.
> > Would this mean that firmware always sends 8bytes of msdu_end_tag in wcn7850 but
> > not on qcn9274 ?
> >
>
> yes, qcn9274 not packed with __le64 tag.
> wcn7850 expect the __le64 tag packed in the msdu_end and mpdu_start.
So in the full form, we just do not have the _le64 tag on qcn9274 but not in
wcn7850, right ?
>
>
> > It seems unlikely as when using the compact layout on qcn9274 (the default now)
> > we use QCN9274_MSDU_END_WMASK with QCN9274_MSDU_END_SELECT_MSDU_END_TAG (bit(0))
> > which seems to indicate that this 8bytes tag is part of the optional data that
> > we can select (or not) to be received from the firmware.
> >
> > Am I missing something ? Did that even worked before switching to compact layout
> > for qcn9274 ?
>
> Yes, tag tlv is configurable in the compact word subscription mode.
> Before compact mode, qcn9274 full mode is worked without any issue.
>
So that means that setting all bits in the tlv subscription mode *is not* the
same as not using the subscription and receiving the full desciptor. Setting all
bits will get you the __le64 tag, but not using the registration at all will not
get it right ?
> >
> > And if it's not working as intended, what's the layout style we actually want to
> > use for struct hal_rx_desc_XXX, do we want the __le64 msdu_end_tag inside the
> > struct hal_rx_desc_XXX or inside the struct rx_msdu_end_XXX ?
> >
>
> Either way, __le64 msdu_end_tag is part of the msdu_end because
> ath12k_hw_wcn7850_rx_desc_get_msdu_end_offset() tells the
> offsetof(struct hal_rx_desc_wcn7850, msdu_end_tag) not the
> offsetof(struct rx_msdu_end_wcn7850 msdu_end) in the
> ath12k_dp_rxdma_ring_sel_config_wcn7850() configuration.
>
Yep I saw this part, for me it accentuates the fact that the msdu_end_tag is not
something that can subscribed out of in wcn7850, as it is out of the struct,
but can in qcn9274.
next prev parent reply other threads:[~2024-09-05 13:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 14:59 Weird layout of struct hal_rx_desc_qcn9274 Nicolas Escande
2024-09-05 4:53 ` Karthikeyan Periyasamy
2024-09-05 13:06 ` Nicolas Escande [this message]
2024-09-06 3:37 ` Karthikeyan Periyasamy
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=D3YDFV83HICP.3605AE2L7PIE9@gmail.com \
--to=nico.escande@gmail.com \
--cc=ath12k@lists.infradead.org \
--cc=quic_periyasa@quicinc.com \
/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