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  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]
Date:   Mon, 7 Feb 2022 08:49:18 +0100
From:   Miquel Raynal <>
To:     Alexander Aring <>
Cc:     Stefan Schmidt <>,
        linux-wpan - ML <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        "open list:NETWORKING [GENERAL]" <>,
        Michael Hennerich <>,
        Varka Bhadram <>,
        Xue Liu <>, Alan Ott <>
Subject: Re: [PATCH wpan-next v2 1/5] net: ieee802154: Improve the way
 supported channels are declared

Hi Alexander, wrote on Sun, 6 Feb 2022 16:37:23 -0500:

> Hi,
> On Tue, Feb 1, 2022 at 9:55 AM Miquel Raynal <> wrote:
> ...
> >
> > 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.  
> I am not really sure if I understood now. So far those channel/page
> combinations are the same because we have no special "type" value in
> wpan_phy,

Yes, my assumption was more: I know there are only -legacy- phy types
supported, we will add another (or improve the current) way of defining
channels when we'll need to. Eg when improving UWB support.

> what we currently support is the "normal" (I think they name
> it legacy devices) phy type (no UWB, sun phy, whatever) and as Channel
> Assignments says that it does not apply for those PHY's I think it
> there are channel/page combinations which are different according to
> the PHY "type". However we don't support them and I think there might
> be an upcoming type field in wpan_phy which might be set only once at
> registration time.

An idea might be to create a callback that drivers might decide to
implement or not. If they implement it, the core might call it to get
further information about the channels. The core would provide a {page,
channel} couple and retrieve a structure with many information such as
the the frequency, the protocol, eventually the prf, etc.


Powered by blists - more mailing lists