Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5b71e308-0783-fa98-77a8-c17121ca53fc@quicinc.com>
Date:   Thu, 11 Aug 2022 15:01:47 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.2
Subject: Re: [RFC 1/2] wifi: mac80211: add a new field in ieee80211_rx_status
 for link id
Content-Language: en-US
To:     Johannes Berg <johannes@sipsolutions.net>,
        Jeff Johnson <quic_jjohnson@quicinc.com>
CC:     <linux-wireless@vger.kernel.org>
References: <20220802065019.20791-1-quic_vthiagar@quicinc.com>
 <20220802065019.20791-2-quic_vthiagar@quicinc.com>
 <29694008-63ef-4cd3-a6c6-f82fc8377be6@quicinc.com>
 <733b6f1a-8b07-4b23-2b10-af1ce68b6227@quicinc.com>
 <9e37eb24f63dbac0b13ae8b36393c8f393599d1e.camel@sipsolutions.net>
From:   Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
In-Reply-To: <9e37eb24f63dbac0b13ae8b36393c8f393599d1e.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 8/9/2022 11:42 PM, Johannes Berg wrote:
> On Wed, 2022-08-03 at 22:16 +0530, Vasanthakumar Thiagarajan wrote:
>>
>>>> +    u8 link_id;
>>>>    };
>>>>    static inline u32
>>>
>>> in other parts of the MLO code the link_id is defined as int and a value
>>> of -1 is used for a non-MLO link. but I don't know if that is currently
>>> universally true.
>>>
>>> if that is curently universally true, do we want to now have divergent
>>> definitions of a link_id?
>>
>> Good point, i see link_id is used both as unsigned and int based on
>> their usage. The reason I preferred unsigned is that we can make use of
>> the remaining 4-bits for some other purpose in future,
>> ieee80211_rx_status has size limitation.
>>
> 
> It's a bit tricky though - do we want to have 0 for all the drivers that
> don't support MLO? Might not really be an issue, but OTOH not
> initializing it should probably not result in a valid value otherwise
> you might test something, think it's fine, and it really isn't. >
> I think we should spend a bit to have a validity indication in this
> case. Even -1 wouldn't address it since you'd have to initialize to
> that.
> 

Sure, a new valid bit looks cleaner. Ill make the changes.

> It works better the other way around in APIs etc. where we have a few
> producers and many consumers (cfg80211 down to drivers), but less well
> this way where we'd have to change drivers...

I agree.

Thanks!

Vasanth