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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAB_54W7SZmgU=2_HEm=_agE0RWfsXxEs_4MHmnAPPFb+iVvxsQ@mail.gmail.com>
Date:   Mon, 31 Jan 2022 19:04:40 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.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,

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.

> 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