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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Feb 2022 08:49:18 +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 Sun, 6 Feb 2022 16:37:23 -0500: > Hi, > > On Tue, Feb 1, 2022 at 9:55 AM Miquel Raynal <miquel.raynal@...tlin.com> 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. Thanks, Miquèl
Powered by blists - more mailing lists