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: <CAB_54W4Z1KgT+Cx0SXptvkwYK76wDOFTueFUFF4e7G_ABP7kkA@mail.gmail.com>
Date:   Wed, 5 Jan 2022 19:23:04 -0500
From:   Alexander Aring <alex.aring@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.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,

On Wed, 5 Jan 2022 at 03:48, Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> 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.
>

ok.

> 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?
>

A HardMAC driver does not use this driver interface... but there
exists a SoftMAC driver for a HardMAC transceiver. This driver
currently works because we use dataframes only... It will not support
scanning currently and somehow we should make iit not available for
drivers like that and for drivers which don't set symbol duration.
They need to be fixed.

> 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.
>

My concern is that somebody else might want to remove those callbacks
because they are not used.

- Alex