On Wed, Jul 23, 2014 at 9:06 PM, Luis R. Rodriguez
<mcgrof@xxxxxxxxxxxxxxxx> wrote:
>> I also suggest adding another argument to regulatory_hint_regd() to
>> allow the driver to specify the intersection policy. It seems that
>> currently the code (__reg_process_hint_driver()) only allows to
>> intersect, which is not appropriate to us.
>> So the final form can look like:
>>
>> regulatory_hint_regd(struct wiphy,
>> const struct ieee80211_regdomain *regd,
>> enum nl80211_driver_reg_hint_type,
>> enum nl80211_reg_intersect_policy policy);
>>
>> enum nl80211_reg_intersect_policy {
>> REG_INTERSECT_POLICY_DEFAULT,
>> REG_INTERSECT_POLICY_OVERRIDE,
>> REG_INTERSECT_POLICY_INTERSECT,
>> };
>
> We don't want to use the driver regulatory data to help the regulatory
> core at all because I noted it would get things messy fast. That would
> mean you never have to deal with any intersection or the cfg80211
> regulatory domain at all. So none of this would be needed. The hint
> would just be for the driver. Its sad that driver regulatory data
> can't contribute to the regulatory core but I think its best this way
> to keep things clean and simple. If the driver does want to help the
> best way is to contribute to wireless-regdb and move to that.
I guess I didn't get that one.
Isn't that problematic for cell-base hints coming from usermode? I
mean, what wiphy are they from?
It's also problematic because currently usermode uses the
cfg80211_regdomain for its regulatory data (NL80211_CMD_GET_REG).
Granted, all of this can be changed, but I think it's easier to update
the global regdomain.
The cell-base hints from usermode with the regdomain data coming from
the FW was the original reason to introduce the get_regd() callback.
For driver originating hints I agree regulatory_hint_regd() is a
cleaner solution.
I feel the case of two different cards, one of which uses get_regd()
and the other wireless-regdb is a non-existent corner-case. And we're
throwing out the baby with the bathwater.
Why write extra code for a case that doesn't happen? How about adding
appropriate regulatory_flags to ensure this can't happen?
Overall it seems to be the API you've suggested in the previous email
with the addition of get_regd() for usermode hints can work well,
updating the global cfg80211_regdomain.
Regards,
Arik
--
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
