Hi Alexander,

alex.aring@gmail.com wrote on Sun, 6 Feb 2022 16:37:23 -0500:

Hi,

On Tue, Feb 1, 2022 at 9:55 AM Miquel Raynal [off-list ref] wrote:
...

quoted

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.

Thanks,
Miquèl