On Thu, May 4, 2023 at 6:56 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 2023-05-04 at 14:49 +1200, Gilad Itzkovitch wrote:
> >
> > * Information about a receiving or transmitting bitrate
> > *
> > * @flags: bitflag of flags from &enum rate_info_flags
> > - * @mcs: mcs index if struct describes an HT/VHT/HE rate
> > * @legacy: bitrate in 100kbit/s for 802.11abg
> > + * @mcs: mcs index if struct describes an HT/VHT/HE rate
>
> Did you mean to add S1G to this list? Not sure why else you moved it at
> all :) And maybe if yes, add EHT while at it. But I can do that
> separately too, or maybe we should just remove the list and say "if not
> legacy" or something...
>
As you said below, we shifted the kernel-doc to match the new order.
So, yes, the S1G
is missing from that list as you mentioned. Maybe it's better to
change it to non legacy as the list
becomes too long. I can change it (and add EHT) if any other change
will be required as part
of version 2, otherwise, I don’t mind you changing it as part of
committing the change.
Gilad
>
> But I can also just change that when I commit it, if you prefer/don't
> mind.
>
> > * @nss: number of streams (VHT & HE only)
> > * @bw: bandwidth (from &enum rate_info_bw)
> > * @he_gi: HE guard interval (from &enum nl80211_he_gi)
> > @@ -1761,9 +1773,9 @@ enum rate_info_bw {
> > * only valid if bw is %RATE_INFO_BW_EHT_RU)
> > */
> > struct rate_info {
> > - u8 flags;
> > - u8 mcs;
> > + u16 flags;
> > u16 legacy;
> > + u8 mcs;
>
> Oh ... I see, you moved the kernel-doc because of this reordering? No
> need to do that, FWIW, the kernel-doc order doesn't really matter.
>
> But thanks for doing this reordering to keep the struct without holes!
>
> johannes
