netdev - Re: [PATCH -next 1/2] brcmfmac: Support multiple AP interfaces and fix STA disconnection issue

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] [day] [month] [year] [list]

Message-ID: <20220823090353.me2pxlq4uzotp6jz@bang-olufsen.dk>
Date:   Tue, 23 Aug 2022 09:03:53 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Franky Lin <franky.lin@...adcom.com>
CC:     Alvin Šipraga <alvin@...s.dk>,
        Arend van Spriel <aspriel@...il.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Kalle Valo <kvalo@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Soon Tak Lee <soontak.lee@...ress.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Ahmad Fatoum <a.fatoum@...gutronix.de>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "brcm80211-dev-list.pdl@...adcom.com" 
        <brcm80211-dev-list.pdl@...adcom.com>,
        "SHA-cyfmac-dev-list@...ineon.com" <SHA-cyfmac-dev-list@...ineon.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next 1/2] brcmfmac: Support multiple AP interfaces and
 fix STA disconnection issue

Hi Franky,

On Mon, Aug 22, 2022 at 10:12:14AM -0700, Franky Lin wrote:
> On Wed, Aug 17, 2022 at 1:50 AM Alvin Šipraga <ALSI@...g-olufsen.dk> wrote:
> > On Wed, Aug 10, 2022 at 02:32:06PM -0700, Franky Lin wrote:
> > > On Fri, Jul 22, 2022 at 5:30 AM Alvin Šipraga <alvin@...s.dk> wrote:
> > > >  /**
> > > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > > > index fe01da9e620d..83e023a22f9b 100644
> > > > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > > > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> > > > @@ -303,6 +303,11 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> > > >                 brcmf_dbg(INFO, "CLM version = %s\n", clmver);
> > > >         }
> > > >
> > > > +       /* set apsta */
> > > > +       err = brcmf_fil_iovar_int_set(ifp, "apsta", 1);
> > > > +       if (err)
> > > > +               brcmf_info("failed setting apsta, %d\n", err);
> > > > +
> > >
> > > I do not understand why entering apsta mode by default. The mode is
> > > supposed to be enabled only when an AP interface is created in
> > > brcmf_cfg80211_start_ap. I think one of the side effects of apsta mode
> > > is that memory footprint significantly increases. It should remain
> > > disabled for STA only mode (which is the major use case) for better
> > > performance.
> >
> > By better performance, do you just mean "lower chance of memory
> > exhaustion"? If so, surely the firmware would be designed such that it
> > doesn't run out of memory under the advertised use-cases (STA, AP+STA
> > etc.), regardless of the current apsta setting?
> 
> I think some packet related buffers will be adjusted for apsta mode so
> the sta mode performance will hurt because there is less buffer to
> use.
> 
> Another significant impact I am sure about is some power saving
> features will be turned off once apsta mode is enabled. So the chip
> will drain more power even the AP interface is not created.

OK. And this apsta mode seems only to be used for STA + P2P mode in the
upstream driver's current form. But doesn't the driver also support AP +
STA mode ordinarily? Would apsta=1 not be necessary for that use-case?
Of course I assume you can only answer me for Broadcom chipsets.

Trying to understand whether to drop this whole series or whether a
modified version can be suitably upstreamed.

Kind regards,
Alvin

> 
> Regards,
> - Franky