Hi Alexander,
alex.aring@xxxxxxxxx wrote on Sun, 13 Mar 2022 16:58:01 -0400:
> 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?
For a UWB PHY: the preamble code and the PRF, I believe.
> 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.
I'll look into it soon.
Thanks,
Miquèl
