netdev - Re: [EXTERNAL] Re: [EXTERNAL] Re: [PATCH] [v15] wireless: Initial driver submission for pureLiFi STA devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 24 Sep 2021 13:27:15 +0000
From:   Srinivasan Raju <srini.raju@...elifi.com>
To:     Johannes Berg <johannes@...solutions.net>,
        Kalle Valo <kvalo@...eaurora.org>
CC:     Mostafa Afgani <mostafa.afgani@...elifi.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:NETWORKING DRIVERS (WIRELESS)" 
        <linux-wireless@...r.kernel.org>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>
Subject: Re: [EXTERNAL] Re: [EXTERNAL] Re: [PATCH] [v15] wireless: Initial
 driver submission for pureLiFi STA devices

> >
> > 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