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.
> 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"?
> > 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.
To make it more understandable I guess some people can introduce some
defines/etc to make a more sense behind setting static hex values.
- Alex
