All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.