linux-kernel - Re: [net-next 17/18] net: mac802154: Let drivers provide their own beacons implementation

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: <20220105094849.0c7e9b65@xps13>
Date:   Wed, 5 Jan 2022 09:48:49 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Alexander Aring <alex.aring@...il.com>
Cc:     David Girault <David.Girault@...vo.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        Romuald Despres <Romuald.Despres@...vo.com>,
        Frederic Blain <Frederic.Blain@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [net-next 17/18] net: mac802154: Let drivers provide their own
 beacons implementation

Hi Alexander,

alex.aring@...il.com wrote on Thu, 30 Dec 2021 14:48:41 -0500:

> Hi,
> 
> On Thu, 30 Dec 2021 at 12:00, David Girault <David.Girault@...vo.com> wrote:
> >
> > Hi Alexander,
> >
> > At Qorvo, we have developped a SoftMAC driver for our DW3000 chip that will benefit such API.
> >  
> Do you want to bring this driver upstream as well? Currently those
> callbacks will be introduced but no user is there.

I think so far the upstream fate of the DW3000 driver has not been ruled
out so let's assume it won't be upstreamed (at least not fully), that's
also why we decided to begin with the hwsim driver.

However, when designing this series, it appeared quite clear that any
hardMAC driver would need this type of interface. The content of the
interface, I agree, could be further discussed and even edited, but the
main idea of giving the information to the phy driver about what is
happening regarding eg. scan operations or beacon frames, might make
sense regardless of the current users, no?

This being said, if other people decide to upstream a hardMAC driver
and need these hooks to behave a little bit differently, it's their
right to tweak them and that would also be part of the game.

Although we might not need these hooks in a near future at all if we
move to the filtering modes, because the promiscuous call with the
specific level might indicate to the device how it should configure
itself already.

> > To be short, beacon sending is controller by our driver to be synchronized chip clock or delayed until
> > other operation in progress (a ranging for example).
> >  
> 
> ok.
> 
> - Alex

Thanks,
Miquèl