Search Linux Wireless

Re: brcmfmac and WIPHY_FLAG_NETNS_OK

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, March 14, 2017 2:27:53 PM EDT Arend Van Spriel wrote:
> On 14-3-2017 14:21, Mark Asselstine wrote:
> > On Tuesday, March 14, 2017 1:41:02 PM EDT Arend Van Spriel wrote:
> >> On 14-3-2017 12:28, Johannes Berg wrote:
> >>>> It never came up with any projects so far.
> > 
> > Myself and one of my colleagues had thought that this might be the case.
> > On
> > the bright side this matches my inability to find any discussions on the
> > matter and that there is the possibility to get this functionality added.
> > 
> >>>> I doubt that the patch
> >>>> below is sufficient. I suspect something more is needed. Using git
> >>>> blame I ended up finding these commits:
> >>>> 
> >>>> a272a72 mac80211: allow using network namespaces
> >>> 
> >>> This is needed in brcm drivers.
> > 
> > I will have a closer look, thanks for the pointer to this patch.
> > 
> >>>> 463d018 cfg80211: make aware of net namespaces
> >>> 
> >>> This has no impact on brcm drivers :)
> >>> 
> >>>> 5061b0c mac80211: cooperate more with network namespaces
> >>> 
> >>> This shouldn't be needed, you're not referring to init_net in brcm
> >>> drivers.
> >>> 
> >>>> I think what is required from brcmfmac is to set netns for each
> >>>> netdev that we create to the same netns as the wiphy instance using
> >>>> wiphy_net().
> >>> 
> >>> Yes, like the mac80211 patch above.
> >>> 
> >>>> Not sure if there is more to consider, but hopefully Johannes can
> >>>> comment on this although the mentioned commits have been around for a
> >>>> while.
> >>> 
> >>> I don't think there's anything else.
> >>> 
> >>>>>         wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT |
> >>>>>         
> >>>>>                         WIPHY_FLAG_OFFCHAN_TX |
> >>>>> 
> >>>>> -                       WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
> >>>>> +                       WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
> >>>>> +                       WIPHY_FLAG_NETNS_OK;
> >>> 
> >>> This is not sufficient, you still have to set the netns for newly
> >>> created netdevs.
> > 
> > Ah, that is something I had not tested out. I moved an existing phy and
> > its
> > associated vif and things worked as expected and also destroying the NS
> > had
> > things move back as expected. I did not however create any new vifs
> > 
> >> Thanks for confirming my suspicion.
> >> 
> >> Regards,
> >> Arend
> > 
> > Thanks for the quick pointers, not being all that familiar with the
> > wireless code I appreciate the discussion. I will have a closer look and
> > see if I can get a patch out for review.
> 
> Hi Mark,
> 
> I looked at it and preparing a patch. Will send it out shortly to give
> it a try.

Oh perfect thanks. I wasn't intending to create work for you but I will not 
protest. Your expert eye might catch things I would have missed, only to be 
caught in review.

Mark

> 
> Regards,
> Arend





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux