Re: [PATCH v3 1/3] cfg80211: leave invalid channels on regdomain change

2014-11-26 Thread Arik Nemtsov
On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez mcg...@suse.com wrote:

 Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add
 some information about the amount current of grace period used,
 and types of interfaces supported. Since this is a regulatory flag
 this information will help folks decide whether to enable or not.
 Also encourage its use, and mention that once all supported devices
 get support for this will be enabled by default. In the meantime
 I'd prefer if this feature was enabled by default if the supported
 interface types of a dveice match the white list of supported
 interfaces.

Will do.

Arik
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] cfg80211: leave invalid channels on regdomain change

2014-11-26 Thread Arik Nemtsov
On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez mcg...@suse.com wrote:
 On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote:
 When the regulatory settings change, some channels might become invalid.
 Disconnect interfaces acting on these channels, after giving userspace
 code a grace period to leave them.

 This mode is currently opt-in, and not all interface operating modes are
 supported for regulatory-enforcement checks. A wiphy that wishes to use
 the new enforcement code must specify an appropriate regulatory flag,
 and all its supported interface modes must be supported by the chekcing
 code.

 This is all looking beter now, since I had a few requests for the last patch
 I'll ask for some other things here without asking  to negage the flag purpose
 as I originally wanted.

 Signed-off-by: Arik Nemtsov arikx.nemt...@intel.com
 ---
  include/net/regulatory.h |   6 +++
  net/wireless/core.c  |  13 ++
  net/wireless/reg.c   | 106 
 ++-
  3 files changed, 124 insertions(+), 1 deletion(-)

 diff --git a/include/net/regulatory.h b/include/net/regulatory.h
 index dad7ab2..701177c 100644
 --- a/include/net/regulatory.h
 +++ b/include/net/regulatory.h
 @@ -136,6 +136,11 @@ struct regulatory_request {
   *  otherwise initiating radiation is not allowed. This will enable the
   *  relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration
   *  option
 + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all
 + *   interfaces on this wiphy reside on allowed channels. Upon a regdomain
 + *   change, the interfaces are given a grace period to disconnect or move
 + *   to an allowed channels. Interfaces on forbidden channels are forcibly
 + *   disconnected.

 Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add
 some information about the amount current of grace period used,
 and types of interfaces supported. Since this is a regulatory flag
 this information will help folks decide whether to enable or not.
 Also encourage its use, and mention that once all supported devices
 get support for this will be enabled by default. In the meantime
 I'd prefer if this feature was enabled by default if the supported
 interface types of a dveice match the white list of supported
 interfaces.

btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag.

Arik
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] cfg80211: leave invalid channels on regdomain change

2014-11-26 Thread Luis R. Rodriguez
On Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote:
 On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez mcg...@suse.com wrote:
  On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote:
  When the regulatory settings change, some channels might become invalid.
  Disconnect interfaces acting on these channels, after giving userspace
  code a grace period to leave them.
 
  This mode is currently opt-in, and not all interface operating modes are
  supported for regulatory-enforcement checks. A wiphy that wishes to use
  the new enforcement code must specify an appropriate regulatory flag,
  and all its supported interface modes must be supported by the chekcing
  code.
 
  This is all looking beter now, since I had a few requests for the last patch
  I'll ask for some other things here without asking  to negage the flag 
  purpose
  as I originally wanted.
 
  Signed-off-by: Arik Nemtsov arikx.nemt...@intel.com
  ---
   include/net/regulatory.h |   6 +++
   net/wireless/core.c  |  13 ++
   net/wireless/reg.c   | 106 
  ++-
   3 files changed, 124 insertions(+), 1 deletion(-)
 
  diff --git a/include/net/regulatory.h b/include/net/regulatory.h
  index dad7ab2..701177c 100644
  --- a/include/net/regulatory.h
  +++ b/include/net/regulatory.h
  @@ -136,6 +136,11 @@ struct regulatory_request {
*  otherwise initiating radiation is not allowed. This will enable 
  the
*  relaxations enabled under the CFG80211_REG_RELAX_NO_IR 
  configuration
*  option
  + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all
  + *   interfaces on this wiphy reside on allowed channels. Upon a regdomain
  + *   change, the interfaces are given a grace period to disconnect or move
  + *   to an allowed channels. Interfaces on forbidden channels are forcibly
  + *   disconnected.
 
  Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add
  some information about the amount current of grace period used,
  and types of interfaces supported. Since this is a regulatory flag
  this information will help folks decide whether to enable or not.
  Also encourage its use, and mention that once all supported devices
  get support for this will be enabled by default. In the meantime
  I'd prefer if this feature was enabled by default if the supported
  interface types of a dveice match the white list of supported
  interfaces.
 
 btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag.

Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which
is really a better way to deal with this but Johannes considered it more
work. I'll leave it up to you but if the supported interfaces on a driver
work with it we should enable this by default. This is why the inversion
(REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want
to keep this on by default and only let folks opt out.

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] cfg80211: leave invalid channels on regdomain change

2014-11-26 Thread Luis R. Rodriguez
On Wed, Nov 26, 2014 at 10:39 AM, Arik Nemtsov a...@wizery.com wrote:
 On Wed, Nov 26, 2014 at 5:28 PM, Luis R. Rodriguez mcg...@suse.com wrote:
 On Wed, Nov 26, 2014 at 05:06:37PM +0200, Arik Nemtsov wrote:
 On Tue, Nov 25, 2014 at 9:38 PM, Luis R. Rodriguez mcg...@suse.com wrote:
  On Sun, Nov 23, 2014 at 05:02:19PM +0200, Arik Nemtsov wrote:
  When the regulatory settings change, some channels might become invalid.
  Disconnect interfaces acting on these channels, after giving userspace
  code a grace period to leave them.
 
  This mode is currently opt-in, and not all interface operating modes are
  supported for regulatory-enforcement checks. A wiphy that wishes to use
  the new enforcement code must specify an appropriate regulatory flag,
  and all its supported interface modes must be supported by the chekcing
  code.
 
  This is all looking beter now, since I had a few requests for the last 
  patch
  I'll ask for some other things here without asking  to negage the flag 
  purpose
  as I originally wanted.
 
  Signed-off-by: Arik Nemtsov arikx.nemt...@intel.com
  ---
   include/net/regulatory.h |   6 +++
   net/wireless/core.c  |  13 ++
   net/wireless/reg.c   | 106 
  ++-
   3 files changed, 124 insertions(+), 1 deletion(-)
 
  diff --git a/include/net/regulatory.h b/include/net/regulatory.h
  index dad7ab2..701177c 100644
  --- a/include/net/regulatory.h
  +++ b/include/net/regulatory.h
  @@ -136,6 +136,11 @@ struct regulatory_request {
*  otherwise initiating radiation is not allowed. This will enable 
  the
*  relaxations enabled under the CFG80211_REG_RELAX_NO_IR 
  configuration
*  option
  + * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all
  + *   interfaces on this wiphy reside on allowed channels. Upon a 
  regdomain
  + *   change, the interfaces are given a grace period to disconnect or 
  move
  + *   to an allowed channels. Interfaces on forbidden channels are 
  forcibly
  + *   disconnected.
 
  Please rename to REGULATORY_IGNORE_STALE_KICKOFF, also please add
  some information about the amount current of grace period used,
  and types of interfaces supported. Since this is a regulatory flag
  this information will help folks decide whether to enable or not.
  Also encourage its use, and mention that once all supported devices
  get support for this will be enabled by default. In the meantime
  I'd prefer if this feature was enabled by default if the supported
  interface types of a dveice match the white list of supported
  interfaces.

 btw, I think you meant REGULATORY_STALE_KICKOFF, since it's an opt-in flag.

 Indeed, the REGULATORY_IGNORE_STALE_KICKOFF would be the inversion, which
 is really a better way to deal with this but Johannes considered it more
 work. I'll leave it up to you but if the supported interfaces on a driver
 work with it we should enable this by default. This is why the inversion
 (REGULATORY_IGNORE_STALE_KICKOFF) would work better in the end, as we want
 to keep this on by default and only let folks opt out.

 I thought we agreed this to be opt-in,

We agreed to not have to require this to be opt-out, that's different
than having it enabled by default for supported devices.

 even if all interfaces are
 supported? I still think an untested driver might be hurt by this
 patch. For instance if it requires a different grace period, etc.

This is a generic feature and I think its important to enable it by
default, if a different grace period can be used it sounds like you
can easily fold that in as an alternative to override the default.

 Luis
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html