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. 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. > 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. 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. Thanks, Miquèl
