> -----Original Message-----
> From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]
> Sent: Sunday, September 18, 2016 21:54
> To: Otcheretianski, Andrei <andrei.otcheretian...@intel.com>; Luca Coelho
> <l...@coelho.fi>; johan...@sipsolutions.net
> Cc: linux-wireless@vger.kernel.org; Beker, Ayala <ayala.be...@intel.com>;
> Grumbach, Emmanuel <emmanuel.grumb...@intel.com>; Coelho, Luciano
> <luciano.coe...@intel.com>
> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
> 
> On 18-9-2016 9:44, Otcheretianski, Andrei wrote:
> >> -----Original Message-----
> >> From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]
> >> Sent: Friday, September 16, 2016 13:59
> >> To: Luca Coelho <l...@coelho.fi>; johan...@sipsolutions.net
> >> Cc: linux-wireless@vger.kernel.org; Beker, Ayala
> >> <ayala.be...@intel.com>; Otcheretianski, Andrei
> >> <andrei.otcheretian...@intel.com>; Grumbach, Emmanuel
> >> <emmanuel.grumb...@intel.com>; Coelho, Luciano
> >> <luciano.coe...@intel.com>
> >> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
> >>
> >> On 16-9-2016 10:33, Luca Coelho wrote:
> >>> From: Ayala Beker <ayala.be...@intel.com>
> >>>
> >>> This allows user space to start/stop NAN interface.
> >>> A NAN interface is like P2P device in a few aspects: it doesn't have
> >>> a netdev associated to it.
> >>> Add the new interface type and prevent operations that can't be
> >>> executed on NAN interface like scan.
> >>>
> >>> Define several attributes that may be configured by user space when
> >>> starting NAN functionality (master preference and dual band
> >>> operation)
> >>>
> >>> Signed-off-by: Andrei Otcheretianski
> >>> <andrei.otcheretian...@intel.com>
> >>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
> >>> Signed-off-by: Luca Coelho <luciano.coe...@intel.com>
> >>> ---
> >>>  include/net/cfg80211.h       | 21 +++++++++-
> >>>  include/uapi/linux/nl80211.h | 52 +++++++++++++++++++++++++
> >>>  net/mac80211/cfg.c           |  2 +
> >>>  net/mac80211/chan.c          |  3 ++
> >>>  net/mac80211/iface.c         |  4 ++
> >>>  net/mac80211/offchannel.c    |  1 +
> >>>  net/mac80211/rx.c            |  3 ++
> >>>  net/mac80211/util.c          |  1 +
> >>>  net/wireless/chan.c          |  2 +
> >>>  net/wireless/core.c          | 34 ++++++++++++++++
> >>>  net/wireless/core.h          |  3 ++
> >>>  net/wireless/mlme.c          |  1 +
> >>>  net/wireless/nl80211.c       | 93
> >> ++++++++++++++++++++++++++++++++++++++++++--
> >>>  net/wireless/rdev-ops.h      | 20 ++++++++++
> >>>  net/wireless/trace.h         | 27 +++++++++++++
> >>>  net/wireless/util.c          |  6 ++-
> >>>  16 files changed, 267 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
> >>> d5e7f69..ca64d69 100644
> >>> --- a/include/net/cfg80211.h
> >>> +++ b/include/net/cfg80211.h
> >>> @@ -2293,6 +2293,19 @@ struct cfg80211_qos_map {  };
> >>
> >> [...]
> >>
> >>> +/**
> >>> + * enum nl80211_nan_dual_band_conf - NAN dual band configuration
> >>> + *
> >>> + * Defines the NAN dual band mode of operation
> >>
> >> Does it make sense to have such a notion of bands in use. And what
> >> does 5.2GHz mean. Is this a subband within 5G channels? Probably I
> >> should read the NAN spec to understand what is meant here. I would
> >> consider 5.2G as lower 5G, ie. discovery on channel 44 but not sure if that
> is meant here.
> >>
> >
> > The NAN spec defines single and dual band modes of operation. The
> channels are fixed for each band.
> > On 2.4Ghz is channel 6 and 5GHz is either 44 or 149. Regarding 5.2 - it's 
> > just a
> typo. It should be 5G - no deeper meaning.
> 
> The thing is that it seems likely other bands will be added so that would 
> kinda
> obsolete this whole enum. So I would propose to have another way to
> configure the bands to use. This enum is not really extensible though it may
> reflect the current state of the spec, which is still in draft if I am not 
> mistaken.
> 

I guess you are talking about additional bands that are mentioned in NAN2 spec 
(like sub-1Ghz etc..).
I'm not sure that these bands will be used for sync or NAN2 specific operations 
only (like data path or ranging).
Nevertheless, you're right, I guess it doesn't harm to make it a bitmask of 
supported bands.

> Regards,
> Arend

Reply via email to