On Wed, Nov 26, 2014 at 11:16 AM, Arik Nemtsov <arik@xxxxxxxxxx> wrote:
> On Wed, Nov 26, 2014 at 5:58 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
>> On Wed, Nov 26, 2014 at 10:39 AM, Arik Nemtsov <arik@xxxxxxxxxx> wrote:
>>> On Wed, Nov 26, 2014 at 5:28 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> 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 <mcgrof@xxxxxxxx> 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.nemtsov@xxxxxxxxx>
>>>>> >> ---
>>>>> >> 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.
>
> Let's not start adding features out of speculation. I was just proving my point.
> Everything can be easily added, but perhaps not easily predicted.
OK
> But sure, I can make this default-on if only supported interfaces are
> present. And for that case, I'll set the flag as opt-out.
Thanks for the work. Its highly appreciated.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
