Hi Alexander,
alex.aring@xxxxxxxxx wrote on Mon, 31 Jan 2022 19:04:40 -0500:
> Hi,
>
> On Mon, Jan 31, 2022 at 9:23 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> >
> > Hi Alexander,
> >
> > alex.aring@xxxxxxxxx wrote on Sun, 30 Jan 2022 16:35:35 -0500:
> >
> > > Hi,
> > >
> > > On Fri, Jan 28, 2022 at 6:08 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> > > >
> > > > The idea here is to create a structure per set of channels so that we
> > > > can define much more than basic bitfields for these.
> > > >
> > > > The structure is currently almost empty on purpose because this change
> > > > is supposed to be a mechanical update without additional information but
> > > > more details will be added in the following commits.
> > > >
> > >
> > > In my opinion you want to put more information in this structure which
> > > is not necessary and force the driver developer to add information
> > > which is already there encoded in the page/channel bitfields.
> >
> > The information I am looking forward to add is clearly not encoded in
> > the page/channel bitfields (these information are added in the
> > following patches). At least I don't see anywhere in the spec a
> > paragraph telling which protocol and band must be used as a function of
> > the page and channel information. So I improved the way channels are
> > declared to give more information than what we currently have.
> >
>
> This makes no sense for me, because you are telling right now that a
> page/channel combination depends on the transceiver.
That is exactly what I meant, and you made me realize that I overlooked
that information from the spec.
> > BTW I see the wpan tools actually derive the protocol/band from the
> > channel/page information and I _really_ don't get it. I believe it only
> > works with hwsim but if it's not the case I would like to hear
> > more about it.
> >
>
> No, I remember the discussion with Christoffer Holmstedt, he described
> it in his commit message "8.1.2 in IEEE 802.15.4-2011".
> See wpan-tools commit 0af3e40bbd6da60cc000cfdfd13b9cdd8a20d717 ("info:
> add frequency to channel listing for phy capabilities").
>
> I think it is the chapter "Channel assignments"?
Oh yeah, now I get it. It's gonna be much simpler than what I thought.
In the 2020 spec this is § "10.1.3 Channel assignments".
> > > Why not
> > > add helper functionality and get your "band" and "protocol" for a
> > > page/channel combination?
> >
> > This information is as static as the channel/page information, so why
> > using two different channels to get it? This means two different places
> > where the channels must be described, which IMHO hardens the work for
> > device driver writers.
> >
>
> device drivers writers can make mistakes here, they probably can only
> set page/channel registers in their hardware and have no idea about
> other things.
>
> > I however agree that the final presentation looks a bit more heavy to
> > the eyes, but besides the extra fat that this change brings, it is
> > rather easy to give the core all the information it needs in a rather
> > detailed and understandable way.
>
> On the driver layer it should be as simple as possible. If you want to
> have a static array for that init it in the phy register
> functionality, however I think a simple lookup table should be enough
> for that.
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.
> To make it more understandable I guess some people can introduce some
> defines/etc to make a more sense behind setting static hex values.
I'll propose a new approach soon.
Thanks,
Miquèl
