Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way supported channels are declared

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

- Alex



[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux