Hi,
On Wed, Mar 2, 2022 at 8:21 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
> Hi Alexander,
>
> alex.aring@xxxxxxxxx wrote on Sun, 20 Feb 2022 18:05:39 -0500:
>
> > Hi,
> >
> > On Mon, Feb 7, 2022 at 2:49 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> > >
> > > Hi Alexander,
> > >
> > > alex.aring@xxxxxxxxx wrote on Sun, 6 Feb 2022 16:37:23 -0500:
> > >
> > > > Hi,
> > > >
> > > > On Tue, Feb 1, 2022 at 9:55 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> > > > ...
> > > > >
> > > > > Given the new information that I am currently processing, I believe the
> > > > > array is not needed anymore, we can live with a minimal number of
> > > > > additional helpers, like the one getting the PRF value for the UWB
> > > > > PHYs. It's the only one I have in mind so far.
> > > >
> > > > I am not really sure if I understood now. So far those channel/page
> > > > combinations are the same because we have no special "type" value in
> > > > wpan_phy,
> > >
> > > Yes, my assumption was more: I know there are only -legacy- phy types
> > > supported, we will add another (or improve the current) way of defining
> > > channels when we'll need to. Eg when improving UWB support.
> > >
> > > > what we currently support is the "normal" (I think they name
> > > > it legacy devices) phy type (no UWB, sun phy, whatever) and as Channel
> > > > Assignments says that it does not apply for those PHY's I think it
> > > > there are channel/page combinations which are different according to
> > > > the PHY "type". However we don't support them and I think there might
> > > > be an upcoming type field in wpan_phy which might be set only once at
> > > > registration time.
> > >
> > > An idea might be to create a callback that drivers might decide to
> > > implement or not. If they implement it, the core might call it to get
> > > further information about the channels. The core would provide a {page,
> > > channel} couple and retrieve a structure with many information such as
> > > the the frequency, the protocol, eventually the prf, etc.
> > >
> >
> > As I said before, for "many information" we should look at how
> > wireless is using that with regdb and extend it with 802.15.4
> > channels/etc. The kernel should only deal with an unique
> > identification of a database key for "regdb" which so far I see is a
> > combination of phy type, page id and channel id. Then from "somewhere"
> > also the country code gets involved into that and you get a subset of
> > what is available.
>
> Do you want another implementation of regdb that would support the
> 802.15.4 world only (so far it is highly 802.11 oriented) ? Or is this
> something that you would like to merge in the existing project?
>
I think we should run the strategy like wpan-tools, fork it but leave
it open that probably they can be merged in future. How about that?
I don't like that it is wireless standard specific, it should be
specific to the standard which defines the regulation... As an
example, I remember that at86rf212 has some LBT (listen before
transmit) mode because of some duty cycle regulations in some
countries. The regdb should not contain if LBT should be used in a
country for specific sub 1Ghz range, etc. It should contain the duty
cycle allowance. That's an example of what I mean with "wireless
standard" and "regulation standard". However the regulation for sub
1Ghz is also a little bit crazy so far I see. :)
However I really don't know if this is extremely difficult to handle.
I would say this would be the better approach but if it doesn't work
do it wireless specific. So it's up to whoever wants to do the work?
> Overall it can be useful to define what is allowed in different
> countries but this will not save us from needing extra information from
> the devices. Describing the channels and protocols (and PRFs) for an
> UWB PHY has nothing to do with the regulatory database, it's just
> listing what is supported by the device. The actual location where it
> might be useful to have a regdb (but not mandatory at the beginning)
> would be when changing channels to avoid messing with local
> regulations, I believe?
>
I see, but I am not sure what additional information you need as
channel, page, phy type? And if you have those values in user space
you can get other information out of it, or not? Why does the kernel
need to handle more than necessary? Even there we can use helpers to
map those combinations to something else. Just avoid that drivers
declare those information what they already declared and introduce
helpers to whatever higher level information you want to get out of
it.
- Alex
