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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220201155507.549cd2e3@xps13>
Date:   Tue, 1 Feb 2022 15:55:07 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Varka Bhadram <varkabhadram@...il.com>,
        Xue Liu <liuxuenetmail@...il.com>, Alan Ott <alan@...nal11.us>
Subject: Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way
 supported channels are declared

Hi Alexander,

alex.aring@...il.com wrote on Mon, 31 Jan 2022 19:04:40 -0500:

> Hi,
> 
> On Mon, Jan 31, 2022 at 9:23 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> >
> > Hi Alexander,
> >
> > alex.aring@...il.com wrote on Sun, 30 Jan 2022 16:35:35 -0500:
> >  
> > > Hi,
> > >
> > > On Fri, Jan 28, 2022 at 6:08 AM Miquel Raynal <miquel.raynal@...tlin.com> 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