On Mon, Sep 09, 2024 at 10:09:33AM +0200, Sascha Hauer wrote:
> On Fri, Sep 06, 2024 at 04:40:36PM +0200, Francesco Dolcini wrote:
> > On Mon, Aug 26, 2024 at 01:01:23PM +0200, Sascha Hauer wrote:
> > > The mwifiex driver tries to derive the MAC addresses of the virtual
> > > interfaces from the permanent address by adding the bss_num of the
> > > particular interface used. It does so each time the virtual interface
> > > is changed from AP to station or the other way round. This means that
> > > the devices MAC address changes during a change_virtual_intf call which
> > > is pretty unexpected by userspace.
> >
> > Is this the only reason for this patch or there are other reasons?
> > I'd like to understand the whole impact, to be sure the backport to
> > stable is what we want.
> >
> > > Furthermore the driver doesn't use the permanent address to add the
> > > bss_num to, but instead the current MAC address increases each time
> > > we do a change_virtual_intf.
> > >
> > > Fix this by initializing the MAC address once from the permanent MAC
> > > address during creation of the virtual interface and never touch it
> > > again. This also means that userspace can set a different MAC address
> > > which then stays like this forever and is not unexpectedly changed
> > > by the driver.
> > >
> > > It is not clear how many (if any) MAC addresses after the permanent MAC
> > > address are reserved for a device, so set the locally admistered
> > > bit for all MAC addresses modified from the permanent address.
> >
> > I wonder if we should not just use the same permanent mac address whatever
> > the virtual interface is. Do we have something similar in other wireless
> > drivers?
>
> Yes, there are at least four driver that generate different MAC
> addresses for different vifs:
Ok, fine for me. It seems like there is some real use case requiring to have
different MAC addresses for each virtual interface, and given that mwifiex is
already like that, we should keep it that way.
It would be interesting to know from NXP if they do provide some guidance on
this topic to whoever is using their chips or the reality is what you
implemented here that we cannot assume anything on how many MAC addresses are
available is just the way it is.
David?
> > > Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > ---
> > > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +-
> > > drivers/net/wireless/marvell/mwifiex/init.c | 1 -
> > > drivers/net/wireless/marvell/mwifiex/main.c | 54 ++++++++++++-------------
> > > drivers/net/wireless/marvell/mwifiex/main.h | 5 ++-
> > > 4 files changed, 30 insertions(+), 34 deletions(-)
> > >
> > ...
> >
> > > diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> > > index 96d1f6039fbca..46acddd03ffd1 100644
> > > --- a/drivers/net/wireless/marvell/mwifiex/main.c
> > > +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> > > @@ -971,34 +971,16 @@ mwifiex_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > > }
> > >
> > > int mwifiex_set_mac_address(struct mwifiex_private *priv,
> > > - struct net_device *dev, bool external,
> > > - u8 *new_mac)
> > > + struct net_device *dev, u8 *new_mac)
> > > {
> > > int ret;
> > > - u64 mac_addr, old_mac_addr;
> > > + u64 old_mac_addr;
> > >
> > > - old_mac_addr = ether_addr_to_u64(priv->curr_addr);
> > > + netdev_info(dev, "%s: old: %pM new: %pM\n", __func__, priv->curr_addr, new_mac);
> > >
> > > - if (external) {
> > > - mac_addr = ether_addr_to_u64(new_mac);
> > > - } else {
> > > - /* Internal mac address change */
> > > - if (priv->bss_type == MWIFIEX_BSS_TYPE_ANY)
> > > - return -EOPNOTSUPP;
> > this was the only usage of MWIFIEX_BSS_TYPE_ANY, correct? Did it had any
> > reason before?
>
> I haven't found a path to get here with priv->bss_type ==
> MWIFIEX_BSS_TYPE_ANY. This function is called from
Ok, so maybe we can kill the MWIFIEX_BSS_TYPE_ANY in this patch also?
> > > @@ -1364,10 +1366,6 @@ void mwifiex_init_priv_params(struct mwifiex_private *priv,
> > > priv->assocresp_idx = MWIFIEX_AUTO_IDX_MASK;
> > > priv->gen_idx = MWIFIEX_AUTO_IDX_MASK;
> > > priv->num_tx_timeout = 0;
> > > - if (is_valid_ether_addr(dev->dev_addr))
> > > - ether_addr_copy(priv->curr_addr, dev->dev_addr);
> > > - else
> > > - ether_addr_copy(priv->curr_addr, priv->adapter->perm_addr);
> >
> > With this change, when mfg_mode is true, priv->curr_addr will be not
> > initialized. Wanted?
>
> Not wanted, just me being ignorant. Let's have a look:
>
> priv->adapter->perm_addr is initialized in the response handling of the
> HostCmd_CMD_GET_HW_SPEC command. This command is only issued when
> mfg_mode is false, so in mfg mode priv->adapter->perm_addr will be the
> zero address.
>
> The only documentation we have for mfg_mode is:
>
> manufacturing mode enable:1, disable:0
>
> I don't know what this really is about, but I could imagine that this
> is for initial factory bringup when the chip is not parametrized and thus
> doesn't have a permanent MAC address yet.
Not sure even myself, but I would advise to not break it.
Francesco
