Srinivasan Raju <[email protected]> writes:
> Thanks for reviewing the patch.
>
>>> + hw->wiphy->bands[NL80211_BAND_2GHZ] = &mac->band;
>
>> Johannes comment about piggy-backing NL80211_BAND_2GHZ is not yet addressed:
>
>> I agree with Johannes, a Li-Fi driver should not claim to be a regular
>> 2.4 GHz Wi-Fi device.
>
> Yes, I agree, As LiFi is not standardized yet we are using the
> existing wireless frameworks. For now, piggy backing with 2.4GHz is
> seamless for users. We will undertake band and other wider change once
> IEEE 802.11bb is standardized.
I don't see why the IEEE standard needs to be final before adding the
band. Much better to add a band which is in draft stage compared to
giving false information to the user space.
BTW do not use HTML mail, our lists drop those.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Tue, 2021-09-21 at 15:30 +0300, Kalle Valo wrote:
> >
> > Yes, I agree, As LiFi is not standardized yet we are using the
> > existing wireless frameworks. For now, piggy backing with 2.4GHz is
> > seamless for users. We will undertake band and other wider change once
> > IEEE 802.11bb is standardized.
>
> I don't see why the IEEE standard needs to be final before adding the
> band. Much better to add a band which is in draft stage compared to
> giving false information to the user space.
I tend to agree, but looking at the current draft (D0.6), that's ...
vague? Maybe it's obvious to somebody familiar with the technology, but
I really don't understand how 800-1000nm infrared band maps to 21 MHz +
channel offset? Isn't the frequency there a couple hundred THz?
Regardless, if the channelisation plan says 21 MHz + n_ch * 5 MHz, then
I think we can just define NL80211_BAND_LC and the driver advertises
those channels - that even gets you easy access to all the defined
channels (apparently today all the odd channels from 1-61, split into
20/40/80/160 MHz bandwidth).
I guess I'm really not sure how that maps to the actual infrared, but
reusing all the 20/40/80/160 machinery from VHT means we can actually do
a lot of things in mac80211/etc. without much changes, which isn't bad.
Anyway, I'd feel more comfortable defining an LC band here, even if it
potentially changes later. Or maybe especially if the actual channels
there change later.
johannes
> >
> > Yes, I agree, As LiFi is not standardized yet we are using the
> > existing wireless frameworks. For now, piggy backing with 2.4GHz is
> > seamless for users. We will undertake band and other wider change once
> > IEEE 802.11bb is standardized.
>
> I don't see why the IEEE standard needs to be final before adding the
> band. Much better to add a band which is in draft stage compared to
> giving false information to the user space.
> I tend to agree, but looking at the current draft (D0.6), that's ...
> vague? Maybe it's obvious to somebody familiar with the technology, but
> I really don't understand how 800-1000nm infrared band maps to 21 MHz +
> channel offset? Isn't the frequency there a couple hundred THz?
> Regardless, if the channelisation plan says 21 MHz + n_ch * 5 MHz, then
> I think we can just define NL80211_BAND_LC and the driver advertises
> those channels - that even gets you easy access to all the defined
> channels (apparently today all the odd channels from 1-61, split into
> 20/40/80/160 MHz bandwidth).
> I guess I'm really not sure how that maps to the actual infrared, but
> reusing all the 20/40/80/160 machinery from VHT means we can actually do
> a lot of things in mac80211/etc. without much changes, which isn't bad.
> Anyway, I'd feel more comfortable defining an LC band here, even if it
> potentially changes later. Or maybe especially if the actual channels
> there change later.
Thanks, I have submitted next version of the patch. I will study how to define NL80211_BAND_LC and other changes/tests required.
I will also consider other points mentioned and will reply / update the patch (or send addional pathces).
--Srini