Message-ID: <20220106201526.7e513f2f@xps13>
Date:   Thu, 6 Jan 2022 20:15:26 +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 Wed, 5 Jan 2022 19:23:04 -0500:

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

My bad. I did not look at it correctly. I made a mistake when talking
about a hardMAC.

Instead, it is a "custom" low level MAC layer. I believe we can compare
the current mac802154 layer mostly to the MLME that is mentioned in the
spec. Well here the additional layer that needs these hooks would be
the MCPS. I don't know if this will be upstreamed or not, but the need
for these hooks is real if such an intermediate low level MAC layer
gets introduced.

In v2 I will get rid of the two patches adding "driver access" to scans
and beacons in order to facilitate the merge of the big part. Then we
will have plenty of time to discuss how we can create such an interface.
Perhaps I'll be able to propose more code as well to make use of these
hooks, we will see.

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

Yes, this is likely to happen quickly because of robots :)

Thanks,
Miquèl

Powered by blists - more mailing lists