New Regulatory Domain Api.

New Regulatory Domain Api.

[Kolekar, Abhijeet]

Hello Luis,
  I have been trying to implement new regulatory api for iwlwifi drivers. One of the problem we are facing
is that , when we tried to remove iwlagn driver without removing the cfg80211,and then again inserting the
same module , we cannot set the regulatory domain.  The reasons for this probably be ,as  we are just giving a pointer to
regulatory domain in regulatory_hint function which may lead to potential memory link. Cfg80211 should copy the regulatory domain
information in its own memory rather than a pointer to driver memory.


Abhijeet

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Thu, Oct 09, 2008 at 03:17:18PM -0700, Kolekar, Abhijeet wrote:
> Hello Luis,
>   I have been trying to implement new regulatory api for iwlwifi drivers. One of the problem we are facing
> is that , when we tried to remove iwlagn driver without removing the cfg80211,and then again inserting the
> same module , we cannot set the regulatory domain.  The reasons for this probably be ,as  we are just giving a pointer to
> regulatory domain in regulatory_hint function which may lead to potential memory link.

This was done intentionally by design so we can allow cfg80211 to free
the regulatory domain structure itself.

> Cfg80211 should copy the regulatory domain
> information in its own memory rather than a pointer to driver memory.

That is one way of doing it but we discussed this particular point on
the lists IIRC and at OLS too and we decided to let cfg80211 rather
be the father of the pointer and to be in charge of freeing it later.
This allows us to have a central place which will be in charge of this
pointer once gobbled up and therefore make it less prone to error
amongst callers.

Did you try to see where or why it was actually failing?

My guess is it fails when ignore_request() is called, particularly in
this section:

	switch (set_by) {

	/* -- stuff -- */

        case REGDOM_SET_BY_DRIVER:
                BUG_ON(!wiphy);
                if (last_request->initiator == set_by) {
                        /* Two separate drivers hinting different things,
                         * this is possible if you have two devices
                         * present on a system with different EEPROM regulatory
                         * readings. XXX: Do intersection, we support
                         * only
                         * the first regulatory hint for now */
                        if (last_request->wiphy != wiphy)
                                return -EALREADY;
                        if (rd)
                                return -EALREADY;
                        /* Driver should not be trying to hint different
                         * regulatory domains! */
                        BUG_ON(!alpha2_equal(alpha2,
                                        cfg80211_regdomain->alpha2));
                        return -EALREADY;
                }


In your case I think you hit this after rmmod and modprobe:

	if (last_request->wiphy != wiphy)
		return -EALREADY;

since the last wiphy != your new wiphy. The reason this check was added
though, as the comment indicates, was to prevent two drivers with
different regulatory domains from trying to set it. In your case this
doesn't affect your requested setting as the old regulatory domain
is still set. This check currently also forces the first device detected
on the system and its regutory_hint() to be respected over any other
devices considering that your built in wireless card on your laptop
will probably be detected first over your cardbus card, or USB card
for example.

In other words this you can treat -EALREADY return value as non
critical, as per the documentation (please see include/net/wireless.h).

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Thu, 2008-10-09 at 09:45 -0600, Luis R. Rodriguez wrote:
> 
> In your case I think you hit this after rmmod and modprobe:
> 
>         if (last_request->wiphy != wiphy)
>                 return -EALREADY;
> 
> since the last wiphy != your new wiphy. The reason this check was
> added
> though, as the comment indicates, was to prevent two drivers with
> different regulatory domains from trying to set it. In your case this
> doesn't affect your requested setting as the old regulatory domain
> is still set. This check currently also forces the first device
> detected
> on the system and its regutory_hint() to be respected over any other
> devices considering that your built in wireless card on your laptop
> will probably be detected first over your cardbus card, or USB card
> for example.
> 
> In other words this you can treat -EALREADY return value as non
> critical, as per the documentation (please see
> include/net/wireless.h).

Does below scenario an expected behaviour?

0. A system with iwl3945 BG card and iwl4965 AGN card.
1. insmod iwl3945 -> regulatory_hint(, 99, rd) return 0;
2. insmod iwl4965 -> regulatory_hint(, 99, rd2) return -EALREADY;
3. iwl4965 has no A band support!

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Thu, Oct 9, 2008 at 8:22 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> Does below scenario an expected behaviour?
>
> 0. A system with iwl3945 BG card and iwl4965 AGN card.
> 1. insmod iwl3945 -> regulatory_hint(, 99, rd) return 0;
> 2. insmod iwl4965 -> regulatory_hint(, 99, rd2) return -EALREADY;
> 3. iwl4965 has no A band support!

Yeap. We're going with the regulatory domain the first card specified,
which we believe would be the built in card. The reason we follow this
logic right now is you cannot really be in two different places at the
same time. The real correct behavior here, as the comment also
indicates, is we should be doing an intersection between the two
regulatory domains and I sent a RFC on a some initial code I had to
support such intersection. Until that is not merged we just respect
first regulatory request.

Additionally since each device can still support more channels and
since the driver itself may know better than what the wireless core
provides you can override information using reg_notifier() (part of
the wiphy) and you can be picky so that you can try to respect the
user's request REGDOM_SET_BY_USER so that when they want to be *more*
compliant you let them. For this reason I advise that if you add a
reg_notifier() you only override the information if initiator is not
REGDOM_SET_BY_USER but its up to you of course. This is essentially
why this regulatory infrastructure allows users to be more compliant.

Alternatively you can live with what you have and just let the user
change the regulatory domain (iw reg set US) and this can enable more
channels should your driver support these channels on the device
(registered channels).

So you have a few options here, just keep in mind here the goal is to
allow the user to help the core be more compliant. By overriding a
disable of a channel (if you re-enable it) you are not helping the
user do this.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Fri, 2008-10-10 at 09:49 -0700, Luis R. Rodriguez wrote:
> The real correct behavior here, as the comment also
> indicates, is we should be doing an intersection between the two
> regulatory domains and I sent a RFC on a some initial code I had to
> support such intersection. Until that is not merged we just respect
> first regulatory request.

Why should the intersection be the correct behavior? In my previous
example, the intersection of a BG card and an ABG card is the BG bands.
Why shouldn't the ABG card have the A band support?

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Mon, Oct 13, 2008 at 11:59 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Fri, 2008-10-10 at 09:49 -0700, Luis R. Rodriguez wrote:
>> The real correct behavior here, as the comment also
>> indicates, is we should be doing an intersection between the two
>> regulatory domains and I sent a RFC on a some initial code I had to
>> support such intersection. Until that is not merged we just respect
>> first regulatory request.
>
> Why should the intersection be the correct behavior? In my previous
> example, the intersection of a BG card and an ABG card is the BG bands.
> Why shouldn't the ABG card have the A band support?

Intersection of ABG and BG is BG.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Tue, 2008-10-14 at 01:04 -0600, Luis R. Rodriguez wrote:
> > Why should the intersection be the correct behavior? In my previous
> > example, the intersection of a BG card and an ABG card is the BG
> bands.
> > Why shouldn't the ABG card have the A band support?
> 
> Intersection of ABG and BG is BG.

That's what I'm saying. This is unacceptable for users. There is 2
reasons a channel is not listed in the ieee80211_reg_rule:

1. the channel is not permitted by regulatory
2. the channel is not supported by hardware but it might be permitted by
regulatory

Intersection for the case 2 is wrong. Are you telling me to insert even
A band channels into ieee80211_reg_rule for a BG only card?

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Tue, Oct 14, 2008 at 12:36 AM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Tue, 2008-10-14 at 01:04 -0600, Luis R. Rodriguez wrote:
>> > Why should the intersection be the correct behavior? In my previous
>> > example, the intersection of a BG card and an ABG card is the BG
>> bands.
>> > Why shouldn't the ABG card have the A band support?
>>
>> Intersection of ABG and BG is BG.
>
> That's what I'm saying. This is unacceptable for users. There is 2
> reasons a channel is not listed in the ieee80211_reg_rule:
>
> 1. the channel is not permitted by regulatory
> 2. the channel is not supported by hardware but it might be permitted by
> regulatory
>
> Intersection for the case 2 is wrong. Are you telling me to insert even
> A band channels into ieee80211_reg_rule for a BG only card?

No, you can add to the regulatory domain structure the regulatory
rules that you determine are valid for the card. The hardware
capabilities (as expressed to mac80211) of a card are separate but in
your case perhaps they are the same (please correct me if I'm wrong)
due to the design or your regulatory solution which is built into the
EEPROM.

The question which I thought was being asked was if you have two cards
present, one a dual band card 2.4 GHz and 5 GHz and another a single
band 2.4 GHz card what happens in terms of regulatory rules. What I'm
suggesting should happen is the intersection of their regulatory rules
should be applied and in this case only the 2.4 GHz channels that work
on both cards should be used. What currently happens is the regulatory
rules of the first card detected takes effect.

I have a feeling I am missing the question or problem here though.
Please let me know.

  Luis

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Tue, Oct 14, 2008 at 2:04 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:

> I have a feeling I am missing the question or problem here though.
> Please let me know.

I believe your issue is that your "regulatory domain" is not a
regulatory domain but hw capabilities so this is why you asked me what
values to add in case 2, please correct me if I'm wrong. In that case
-- yes, you should add regulatory rules even if the card is only
single band; but you can't because you don't have that information in
your driver. So you should just go with what you have and that is to
only provide the hardware capabilities. In that case a single band
card will report according to its regulatory info it can only work on
the 2 GHz band while a dual band card will report both 2 GHz and 5
GHz. The intersection is still 2 GHz.

Not sure what the issue is still.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Tue, 2008-10-14 at 02:13 -0700, Luis R. Rodriguez wrote:
> I believe your issue is that your "regulatory domain" is not a
> regulatory domain but hw capabilities so this is why you asked me what
> values to add in case 2, please correct me if I'm wrong. In that case
> -- yes, you should add regulatory rules even if the card is only
> single band; but you can't because you don't have that information in
> your driver. So you should just go with what you have and that is to
> only provide the hardware capabilities. In that case a single band
> card will report according to its regulatory info it can only work on
> the 2 GHz band while a dual band card will report both 2 GHz and 5
> GHz. The intersection is still 2 GHz.

Yes, this is exact my problem. Do you any better way to solve it?

Thanks,
-yi

Re: New Regulatory Domain Api.

[Zhu Yi]

On Tue, 2008-10-14 at 17:23 +0800, Zhu Yi wrote:
> Do you any better way to solve it?

For example, consider the driver provided reg_rules are driver private
(per driver). Don't make them global one.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

On Tue, 2008-10-14 at 17:27 +0800, Zhu Yi wrote:
> On Tue, 2008-10-14 at 17:23 +0800, Zhu Yi wrote:
> > Do you any better way to solve it?
> 
> For example, consider the driver provided reg_rules are driver private
> (per driver). Don't make them global one.

No, that was intentional so if you have say an Intel card builtin and
plug in a ralink usb device w/o regulatory information, that device's
information is used.

And making it global but then applying it only to devices that don't
have their own information is actually harmful because it suddenly means
that not all devices are restricted by the same rules which would make
it effectively impossible for a user to verify she's operating within
the law.

Why is this an issue for you to start with? Can you not use crda on the
system?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Tue, Oct 14, 2008 at 2:23 AM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Tue, 2008-10-14 at 02:13 -0700, Luis R. Rodriguez wrote:
>> I believe your issue is that your "regulatory domain" is not a
>> regulatory domain but hw capabilities so this is why you asked me what
>> values to add in case 2, please correct me if I'm wrong. In that case
>> -- yes, you should add regulatory rules even if the card is only
>> single band; but you can't because you don't have that information in
>> your driver. So you should just go with what you have and that is to
>> only provide the hardware capabilities. In that case a single band
>> card will report according to its regulatory info it can only work on
>> the 2 GHz band while a dual band card will report both 2 GHz and 5
>> GHz. The intersection is still 2 GHz.
>
> Yes, this is exact my problem. Do you any better way to solve it?

I'd follow Johannes' advice.

  Luis

Re: New Regulatory Domain Api.

[John W. Linville]

On Tue, Oct 14, 2008 at 02:04:50AM -0700, Luis R. Rodriguez wrote:

> The question which I thought was being asked was if you have two cards
> present, one a dual band card 2.4 GHz and 5 GHz and another a single
> band 2.4 GHz card what happens in terms of regulatory rules. What I'm
> suggesting should happen is the intersection of their regulatory rules
> should be applied and in this case only the 2.4 GHz channels that work
> on both cards should be used. What currently happens is the regulatory
> rules of the first card detected takes effect.

That doesn't sound like quite the correct behavior.  If a channel is
excluded for regulatory reasons, then I suspect that should govern
everyone.  But if one card just doesn't support a band, I don't see
why any other cards should be limited by that.

Did I miss something?

John

-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Tue, 2008-10-14 at 16:35 -0400, John W. Linville wrote:

> That doesn't sound like quite the correct behavior.  If a channel is
> excluded for regulatory reasons, then I suspect that should govern
> everyone.  But if one card just doesn't support a band, I don't see
> why any other cards should be limited by that.
> 
> Did I miss something?

Well, the thing is that the iwlwifi drivers pretend to know the
regulatory domain; thus when a single-band card registers the regulatory
domain, it gets set to just a domain with the single band.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[John W. Linville]

On Tue, Oct 14, 2008 at 11:15:57PM +0200, Johannes Berg wrote:
> On Tue, 2008-10-14 at 16:35 -0400, John W. Linville wrote:
> 
> > That doesn't sound like quite the correct behavior.  If a channel is
> > excluded for regulatory reasons, then I suspect that should govern
> > everyone.  But if one card just doesn't support a band, I don't see
> > why any other cards should be limited by that.
> > 
> > Did I miss something?
> 
> Well, the thing is that the iwlwifi drivers pretend to know the
> regulatory domain; thus when a single-band card registers the regulatory
> domain, it gets set to just a domain with the single band.

Ah, now I see what this is about...thanks!

Should there be an "I make no representation of authority" flag in
the regulatory maps?

-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

On Tue, 2008-10-14 at 17:19 -0400, John W. Linville wrote:
> On Tue, Oct 14, 2008 at 11:15:57PM +0200, Johannes Berg wrote:
> > On Tue, 2008-10-14 at 16:35 -0400, John W. Linville wrote:
> > 
> > > That doesn't sound like quite the correct behavior.  If a channel is
> > > excluded for regulatory reasons, then I suspect that should govern
> > > everyone.  But if one card just doesn't support a band, I don't see
> > > why any other cards should be limited by that.
> > > 
> > > Did I miss something?
> > 
> > Well, the thing is that the iwlwifi drivers pretend to know the
> > regulatory domain; thus when a single-band card registers the regulatory
> > domain, it gets set to just a domain with the single band.
> 
> Ah, now I see what this is about...thanks!
> 
> Should there be an "I make no representation of authority" flag in
> the regulatory maps?

The only reasonable solution I can come up with is have it make separate
hints for 2.4 and 5 GHz and then a single-band card won't say anything
about 5 GHz so the dual-band gets to set that part. But OTOH I don't see
a reasonable use-case for this whole thing so far---we really only added
this after discussions with Marcel at OLS so embedded systems can
function w/o crda, but who would build an embedded system with two
different cards like that?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[John W. Linville]

On Tue, Oct 14, 2008 at 11:27:42PM +0200, Johannes Berg wrote:
> On Tue, 2008-10-14 at 17:19 -0400, John W. Linville wrote:

> > Should there be an "I make no representation of authority" flag in
> > the regulatory maps?
> 
> The only reasonable solution I can come up with is have it make separate
> hints for 2.4 and 5 GHz and then a single-band card won't say anything
> about 5 GHz so the dual-band gets to set that part. But OTOH I don't see
> a reasonable use-case for this whole thing so far---we really only added
> this after discussions with Marcel at OLS so embedded systems can
> function w/o crda, but who would build an embedded system with two
> different cards like that?

And couldn't such a person also do the equivalent of the OLD_REGULATORY
stuff that we have now?

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

On Tue, 2008-10-14 at 17:50 -0400, John W. Linville wrote:
> On Tue, Oct 14, 2008 at 11:27:42PM +0200, Johannes Berg wrote:
> > On Tue, 2008-10-14 at 17:19 -0400, John W. Linville wrote:
> 
> > > Should there be an "I make no representation of authority" flag in
> > > the regulatory maps?
> > 
> > The only reasonable solution I can come up with is have it make separate
> > hints for 2.4 and 5 GHz and then a single-band card won't say anything
> > about 5 GHz so the dual-band gets to set that part. But OTOH I don't see
> > a reasonable use-case for this whole thing so far---we really only added
> > this after discussions with Marcel at OLS so embedded systems can
> > function w/o crda, but who would build an embedded system with two
> > different cards like that?
> 
> And couldn't such a person also do the equivalent of the OLD_REGULATORY
> stuff that we have now?

Could even just write a trivial app that once during boot requests a
setting from the kernel and then sets it.

Kinda like
iw reg set XY
and the resulting crda call rolled in one.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Johannes,

> > > > That doesn't sound like quite the correct behavior.  If a channel is
> > > > excluded for regulatory reasons, then I suspect that should govern
> > > > everyone.  But if one card just doesn't support a band, I don't see
> > > > why any other cards should be limited by that.
> > > > 
> > > > Did I miss something?
> > > 
> > > Well, the thing is that the iwlwifi drivers pretend to know the
> > > regulatory domain; thus when a single-band card registers the regulatory
> > > domain, it gets set to just a domain with the single band.
> > 
> > Ah, now I see what this is about...thanks!
> > 
> > Should there be an "I make no representation of authority" flag in
> > the regulatory maps?
> 
> The only reasonable solution I can come up with is have it make separate
> hints for 2.4 and 5 GHz and then a single-band card won't say anything
> about 5 GHz so the dual-band gets to set that part. But OTOH I don't see
> a reasonable use-case for this whole thing so far---we really only added
> this after discussions with Marcel at OLS so embedded systems can
> function w/o crda, but who would build an embedded system with two
> different cards like that?

and we need to keep it this way. For example the first card can be a
dual-band card, but the EEPROM value restricts it one band. That might
be by choice. Then attaching a second card, we can't just extend it and
let this card go ahead and use the second band.

The only valid solution might be switching cards. So if the first card
gets removed we can take the full regulatory domain of the second one,
but when does this happen at runtime.

Regards

Marcel

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

Hi Marcel,

> > The only reasonable solution I can come up with is have it make separate
> > hints for 2.4 and 5 GHz and then a single-band card won't say anything
> > about 5 GHz so the dual-band gets to set that part. But OTOH I don't see
> > a reasonable use-case for this whole thing so far---we really only added
> > this after discussions with Marcel at OLS so embedded systems can
> > function w/o crda, but who would build an embedded system with two
> > different cards like that?
> 
> and we need to keep it this way. For example the first card can be a
> dual-band card, but the EEPROM value restricts it one band. That might
> be by choice. 

Interesting point. I didn't think that was possible.

> Then attaching a second card, we can't just extend it and
> let this card go ahead and use the second band.

True. Well, not entirely true, because the first card would
 (1) register its eeprom channels as the regulatory domain for one band
 (2) register only the eeprom channels as the per-hw channels

so when the second card adds the regulatory domain for the second band
the first card still cannot use the extra channels because it doesn't
have those registered in its wiphy.

However, this really gets complicated. Do we need to go there?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Johannes,

> > > The only reasonable solution I can come up with is have it make separate
> > > hints for 2.4 and 5 GHz and then a single-band card won't say anything
> > > about 5 GHz so the dual-band gets to set that part. But OTOH I don't see
> > > a reasonable use-case for this whole thing so far---we really only added
> > > this after discussions with Marcel at OLS so embedded systems can
> > > function w/o crda, but who would build an embedded system with two
> > > different cards like that?
> > 
> > and we need to keep it this way. For example the first card can be a
> > dual-band card, but the EEPROM value restricts it one band. That might
> > be by choice. 
> 
> Interesting point. I didn't think that was possible.

the question is if that makes sense. Currently the dual-band cards are
more expensive than single-band cards, but I expect that to change and
we only see dual-band cards in the future. However then is the question
why not support both bands. So it is possible, but I think an unlikely
case at the moment.

There is a difference in the hardware capabilities and the EEPROM
settings for regulatory enforcement.

> > Then attaching a second card, we can't just extend it and
> > let this card go ahead and use the second band.
> 
> True. Well, not entirely true, because the first card would
>  (1) register its eeprom channels as the regulatory domain for one band
>  (2) register only the eeprom channels as the per-hw channels
> 
> so when the second card adds the regulatory domain for the second band
> the first card still cannot use the extra channels because it doesn't
> have those registered in its wiphy.
> 
> However, this really gets complicated. Do we need to go there?

I can see it useful when companies actually start building products with
two or more cards in the system and have different cards for different
tasks in it. So if you stick one card for one band and another one for
the other band in there, then it would make sense to do a per-band
regulatory hinting.

Not sure if this really ever ends up in a product. However I can see the
case where you have a laptop with a BG-card and then attach an A-card to
it do access an A-network and then it doesn't work. It would be nice to
just have this working. Currently this would not work.

Also the case when we unplug the first card, does the regulatory hint
gets reset and the next card could bring in a new one? I can see use
cases where you don't wanna use the built-in card, because it is just
too limited.

Regards

Marcel

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 10:26 AM, Marcel Holtmann
<holtmann@linux.intel.com> wrote:

> I can see it useful when companies actually start building products with
> two or more cards in the system and have different cards for different
> tasks in it. So if you stick one card for one band and another one for
> the other band in there, then it would make sense to do a per-band
> regulatory hinting.

Sure, but custom solutions can require custom regulatory dbs and
people can do any crazy thing they want here, just as when they need
custom regulatory domains not allowed by the FCC in the USA for
example. Remember that by default the design is trying to cover the
usual scenario of users with 1 wireless card or 2 with one built in.
We decided on our discussions to respect the built-in card first. For
more cards we can take the intersection if we want to keep being more
restrictive. Its what makes sense if you think about it.

> Not sure if this really ever ends up in a product. However I can see the
> case where you have a laptop with a BG-card and then attach an A-card to
> it do access an A-network and then it doesn't work. It would be nice to
> just have this working. Currently this would not work.

Yes it does, it just doesn't work for your hardware as Intel put into
regulatory hardware capability and these are two *very* different
things. That is the problem.

My suggestion is to add a default minimal 5 GHz regulatory domain
definition to your driver on single band cards to deal with this. When
a dual band card is present then all of the full card's capabilities
will be used.

> Also the case when we unplug the first card, does the regulatory hint
> gets reset and the next card could bring in a new one? I can see use
> cases where you don't wanna use the built-in card, because it is just
> too limited.

For now nl80211 supports changing regulatory domains.

  Luis

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On Wed, 2008-10-15 at 10:39 -0700, Luis R. Rodriguez wrote:

> We decided on our discussions to respect the built-in card first. For
> more cards we can take the intersection if we want to keep being more
> restrictive. Its what makes sense if you think about it.

I'm not really too sure the intersection makes most sense, we mostly
used the first hint because it's likely to be from the built-in card,
ergo announcing a region for which the whole product was certified. If
you add a card, we basically don't trust it currently.

> My suggestion is to add a default minimal 5 GHz regulatory domain
> definition to your driver on single band cards to deal with this. When
> a dual band card is present then all of the full card's capabilities
> will be used.

Unfortunately, there's no such thing as a default minimal 5 GHz
regulatory domain. This might work with systems built purely out of
Intel cards, but to be honest, I wouldn't want to see this because it
would mean that if you add a dual-band prism54 USB then it'll start
sending on those 5 GHz channels regardless of where you are and what
you're allowed to do.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 10:45 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2008-10-15 at 10:39 -0700, Luis R. Rodriguez wrote:
>
>> We decided on our discussions to respect the built-in card first. For
>> more cards we can take the intersection if we want to keep being more
>> restrictive. Its what makes sense if you think about it.
>
> I'm not really too sure the intersection makes most sense, we mostly
> used the first hint because it's likely to be from the built-in card,
> ergo announcing a region for which the whole product was certified. If
> you add a card, we basically don't trust it currently.

Right but we do trust it if its the only card present. And as for
conflicts -- this is exactly why we let users set the regulatory
domain too. Intersection is just a default catious policy we can take
to deal with conflicts of different sorts. Can you think of a better
solution? Remember the real issue here is when regulatory domain
information is tainted by having just capability information instead
on a regulatory hint.

>> My suggestion is to add a default minimal 5 GHz regulatory domain
>> definition to your driver on single band cards to deal with this. When
>> a dual band card is present then all of the full card's capabilities
>> will be used.
>
> Unfortunately, there's no such thing as a default minimal 5 GHz
> regulatory domain.

For World, yes, you are right, but for "all SKUs we sell our products
in", this can make sense if all SKUs do support 5GHz.

> This might work with systems built purely out of
> Intel cards, but to be honest, I wouldn't want to see this because it
> would mean that if you add a dual-band prism54 USB then it'll start
> sending on those 5 GHz channels regardless of where you are and what
> you're allowed to do.

Well dual band p54 wouldn't have this AFAICT. But yeah I agree -- this
is why I think its better to promote patches for NM/distributions to
set the regulatory domain through nl80211 (or iw) for the country the
user resides on. Maybe for now something as simple as adding as part
of the init scripts an iw line which sets the regulatory domain on an
alpha2 if the distribution can determine it? This really later should
be part of NM or something else which can definitely make use of a
real alpha2 the user set.

  Luis

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Luis,

> > I can see it useful when companies actually start building products with
> > two or more cards in the system and have different cards for different
> > tasks in it. So if you stick one card for one band and another one for
> > the other band in there, then it would make sense to do a per-band
> > regulatory hinting.
> 
> Sure, but custom solutions can require custom regulatory dbs and
> people can do any crazy thing they want here, just as when they need
> custom regulatory domains not allowed by the FCC in the USA for
> example. Remember that by default the design is trying to cover the
> usual scenario of users with 1 wireless card or 2 with one built in.
> We decided on our discussions to respect the built-in card first. For
> more cards we can take the intersection if we want to keep being more
> restrictive. Its what makes sense if you think about it.

I must admit that I never thought about the implications of multiple
bands with multiple hardware. I am not against keeping it simple and
forcing to have userspace in place to change it. However we do wanna
have support for old laptops that are currently working fine with no
extra userspace, but newer kernels where they just add the second card
to access an A-network. Also remember that internal cards can't really
be disabled most of the times.

> > Not sure if this really ever ends up in a product. However I can see the
> > case where you have a laptop with a BG-card and then attach an A-card to
> > it do access an A-network and then it doesn't work. It would be nice to
> > just have this working. Currently this would not work.
> 
> Yes it does, it just doesn't work for your hardware as Intel put into
> regulatory hardware capability and these are two *very* different
> things. That is the problem.
> 
> My suggestion is to add a default minimal 5 GHz regulatory domain
> definition to your driver on single band cards to deal with this. When
> a dual band card is present then all of the full card's capabilities
> will be used.

That would be one option, but it sounds really strange to me that a
BG-card has to "think" about A-bands.

Let not try to put this down into the drivers if we can solve this
nicely with a per-band regulatory hints inside the core.

> > Also the case when we unplug the first card, does the regulatory hint
> > gets reset and the next card could bring in a new one? I can see use
> > cases where you don't wanna use the built-in card, because it is just
> > too limited.
> 
> For now nl80211 supports changing regulatory domains.

Please keep in mind the case where we do have a new kernel with old
userspace or an userspace without CRDA.

Regards

Marce

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 10:47:48AM -0700, Marcel Holtmann wrote:
> Hi Luis,
> 
> > > I can see it useful when companies actually start building products with
> > > two or more cards in the system and have different cards for different
> > > tasks in it. So if you stick one card for one band and another one for
> > > the other band in there, then it would make sense to do a per-band
> > > regulatory hinting.
> >
> > Sure, but custom solutions can require custom regulatory dbs and
> > people can do any crazy thing they want here, just as when they need
> > custom regulatory domains not allowed by the FCC in the USA for
> > example. Remember that by default the design is trying to cover the
> > usual scenario of users with 1 wireless card or 2 with one built in.
> > We decided on our discussions to respect the built-in card first. For
> > more cards we can take the intersection if we want to keep being more
> > restrictive. Its what makes sense if you think about it.
> 
> I must admit that I never thought about the implications of multiple
> bands with multiple hardware. I am not against keeping it simple and
> forcing to have userspace in place to change it. However we do wanna
> have support for old laptops that are currently working fine with no
> extra userspace, but newer kernels where they just add the second card
> to access an A-network. Also remember that internal cards can't really
> be disabled most of the times.

So you mean you worry about cases where people are using kernels >=
2.6.28 without crda and iw? If so then they can use for 2.6.28 the
OLD_REGULATORY but the idea is for sure to push crda and iw for
distributions definitley as of 2.6.29 for when OLD_REGULATORY is
scheduled for removal.

The problem here is not this though the problem here is the case
where people are using 2.6.28 without no iw or crda *and* have more
than two cards :)

> > > Not sure if this really ever ends up in a product. However I can see the
> > > case where you have a laptop with a BG-card and then attach an A-card to
> > > it do access an A-network and then it doesn't work. It would be nice to
> > > just have this working. Currently this would not work.
> >
> > Yes it does, it just doesn't work for your hardware as Intel put into
> > regulatory hardware capability and these are two *very* different
> > things. That is the problem.
> >
> > My suggestion is to add a default minimal 5 GHz regulatory domain
> > definition to your driver on single band cards to deal with this. When
> > a dual band card is present then all of the full card's capabilities
> > will be used.
> 
> That would be one option, but it sounds really strange to me that a
> BG-card has to "think" about A-bands.

Don't think about it that way -- instead think of it this way: Intel
EEPROM is used for capability stuff but its now also being used for
regulatory and that is what is limitting you. So you *can* think about
5 GHz band for a single 2.4 GHz band card, its just that your regulatory
stuff right now is focused more on capabilities and not real regulatory.

> Let not try to put this down into the drivers if we can solve this
> nicely with a per-band regulatory hints inside the core.

Good point. This is reasonable as well, perhaps if the regulatory hint
has no 5 Ghz band channels it should not imply policy on it at all?
Should be simple enough to fix too I think instead of having two
regulatory_hint() calls per band.

> > > Also the case when we unplug the first card, does the regulatory hint
> > > gets reset and the next card could bring in a new one? I can see use
> > > cases where you don't wanna use the built-in card, because it is just
> > > too limited.
> >
> > For now nl80211 supports changing regulatory domains.
> 
> Please keep in mind the case where we do have a new kernel with old
> userspace or an userspace without CRDA.

Sure, what do you think of the above?

  Luis

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Luis,

> > > > I can see it useful when companies actually start building products with
> > > > two or more cards in the system and have different cards for different
> > > > tasks in it. So if you stick one card for one band and another one for
> > > > the other band in there, then it would make sense to do a per-band
> > > > regulatory hinting.
> > >
> > > Sure, but custom solutions can require custom regulatory dbs and
> > > people can do any crazy thing they want here, just as when they need
> > > custom regulatory domains not allowed by the FCC in the USA for
> > > example. Remember that by default the design is trying to cover the
> > > usual scenario of users with 1 wireless card or 2 with one built in.
> > > We decided on our discussions to respect the built-in card first. For
> > > more cards we can take the intersection if we want to keep being more
> > > restrictive. Its what makes sense if you think about it.
> > 
> > I must admit that I never thought about the implications of multiple
> > bands with multiple hardware. I am not against keeping it simple and
> > forcing to have userspace in place to change it. However we do wanna
> > have support for old laptops that are currently working fine with no
> > extra userspace, but newer kernels where they just add the second card
> > to access an A-network. Also remember that internal cards can't really
> > be disabled most of the times.
> 
> So you mean you worry about cases where people are using kernels >=
> 2.6.28 without crda and iw? If so then they can use for 2.6.28 the
> OLD_REGULATORY but the idea is for sure to push crda and iw for
> distributions definitley as of 2.6.29 for when OLD_REGULATORY is
> scheduled for removal.
> 
> The problem here is not this though the problem here is the case
> where people are using 2.6.28 without no iw or crda *and* have more
> than two cards :)

it might sound like an unlikely case and it will most likely only be the
A-band usage anyway, but it is a valid case. People with old laptops do
use newer wireless cards in PCMCIA or USB form factor to get better WiFi
performance and/or stability. In some cases you can just replace your
internal card, but with the switch from MiniPCI to half-MiniPCI this is
not as likely anymore. So the use of a second external card becomes more
likely.

> > > > Not sure if this really ever ends up in a product. However I can see the
> > > > case where you have a laptop with a BG-card and then attach an A-card to
> > > > it do access an A-network and then it doesn't work. It would be nice to
> > > > just have this working. Currently this would not work.
> > >
> > > Yes it does, it just doesn't work for your hardware as Intel put into
> > > regulatory hardware capability and these are two *very* different
> > > things. That is the problem.
> > >
> > > My suggestion is to add a default minimal 5 GHz regulatory domain
> > > definition to your driver on single band cards to deal with this. When
> > > a dual band card is present then all of the full card's capabilities
> > > will be used.
> > 
> > That would be one option, but it sounds really strange to me that a
> > BG-card has to "think" about A-bands.
> 
> Don't think about it that way -- instead think of it this way: Intel
> EEPROM is used for capability stuff but its now also being used for
> regulatory and that is what is limitting you. So you *can* think about
> 5 GHz band for a single 2.4 GHz band card, its just that your regulatory
> stuff right now is focused more on capabilities and not real regulatory.
> 
> > Let not try to put this down into the drivers if we can solve this
> > nicely with a per-band regulatory hints inside the core.
> 
> Good point. This is reasonable as well, perhaps if the regulatory hint
> has no 5 Ghz band channels it should not imply policy on it at all?
> Should be simple enough to fix too I think instead of having two
> regulatory_hint() calls per band.

I think that is the point Johannes was making. If the driver doesn't
register itself in the 5 GHz band with its capabilities, then its
regulatory hint should not affect this band.

And then when a card for the 5 GHz band comes into play, its regulatory
hint can be applied, while for the 2.4 GHz it looses since it is the
second card in the system.

I am still for the first card wins concept when no CRDA is present or
the userspace just doesn't know about setting the regulatory domain.
However we should have it separated for each band to not lock some
people out who have no clue on why they now loose the 5 GHz band.

Regards

Marcel

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 12:25:48PM -0700, Marcel Holtmann wrote:
> > The problem here is not this though the problem here is the case
> > where people are using 2.6.28 without no iw or crda *and* have more
> > than two cards :)
> 
> it might sound like an unlikely case and it will most likely only be the
> A-band usage anyway, but it is a valid case. People with old laptops do
> use newer wireless cards in PCMCIA or USB form factor to get better WiFi
> performance and/or stability. In some cases you can just replace your
> internal card, but with the switch from MiniPCI to half-MiniPCI this is
> not as likely anymore. So the use of a second external card becomes more
> likely.

Right, and the proposed solution I had was to use an intersection
between two regulatory domains. This solution just doesn't currently
work well with Intel cards due to the capability <-> regulatory one to
one mapping.

> I am still for the first card wins concept when no CRDA is present or
> the userspace just doesn't know about setting the regulatory domain.
> However we should have it separated for each band to not lock some
> people out who have no clue on why they now loose the 5 GHz band.

Sure.

  Luis

Re: New Regulatory Domain Api.

[Tomas Winkler]

On Wed, Oct 15, 2008 at 3:16 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Oct 15, 2008 at 12:25:48PM -0700, Marcel Holtmann wrote:
>> > The problem here is not this though the problem here is the case
>> > where people are using 2.6.28 without no iw or crda *and* have more
>> > than two cards :)
>>
>> it might sound like an unlikely case and it will most likely only be the
>> A-band usage anyway, but it is a valid case. People with old laptops do
>> use newer wireless cards in PCMCIA or USB form factor to get better WiFi
>> performance and/or stability. In some cases you can just replace your
>> internal card, but with the switch from MiniPCI to half-MiniPCI this is
>> not as likely anymore. So the use of a second external card becomes more
>> likely.
>
> Right, and the proposed solution I had was to use an intersection
> between two regulatory domains. This solution just doesn't currently
> work well with Intel cards due to the capability <-> regulatory one to
> one mapping.

This  might be viewed this way but this is not concept behind it.
First Intel HW enforce regulatory domain written in the EEPROM, which
makes it in your sense capability even it's not.
Second Intel uses special regulatory domains called MOW1 and MOW2
(most of the world 1 and 2) + possible restriction to BG. These 3
domains/capabilities should be restrictive enough comply with most of
the world regulatory restrictions. There is no real hint for specific
regulatory domain that can be applied form this, the concept is that
you should be move relatively freely around the globe without changing
anything.
You really have to use some other source to specify regulatory domain
it's cannot be retrieved from the MOW SKU's. The only exception in
Intel cards are JP and KR SKU's which are real regulatory domains.

Just my two cents, probably didn't help to solve the problem,
Tomas

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 04:31:20PM -0700, Tomas Winkler wrote:
> On Wed, Oct 15, 2008 at 3:16 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Wed, Oct 15, 2008 at 12:25:48PM -0700, Marcel Holtmann wrote:
> >> > The problem here is not this though the problem here is the case
> >> > where people are using 2.6.28 without no iw or crda *and* have more
> >> > than two cards :)
> >>
> >> it might sound like an unlikely case and it will most likely only be the
> >> A-band usage anyway, but it is a valid case. People with old laptops do
> >> use newer wireless cards in PCMCIA or USB form factor to get better WiFi
> >> performance and/or stability. In some cases you can just replace your
> >> internal card, but with the switch from MiniPCI to half-MiniPCI this is
> >> not as likely anymore. So the use of a second external card becomes more
> >> likely.
> >
> > Right, and the proposed solution I had was to use an intersection
> > between two regulatory domains. This solution just doesn't currently
> > work well with Intel cards due to the capability <-> regulatory one to
> > one mapping.
> 
> This  might be viewed this way but this is not concept behind it.
> First Intel HW enforce regulatory domain written in the EEPROM, which
> makes it in your sense capability even it's not.

I see.

> Second Intel uses special regulatory domains called MOW1 and MOW2
> (most of the world 1 and 2) + possible restriction to BG. These 3
> domains/capabilities should be restrictive enough comply with most of
> the world regulatory restrictions.

Well to meet your current SKUs requirements :)

> There is no real hint for specific
> regulatory domain that can be applied form this, the concept is that
> you should be move relatively freely around the globe without changing
> anything.

The issue was your single band cards do not store 5 GHz band regulatory
information. Is this MOW1 or MOW2?

> You really have to use some other source to specify regulatory domain
> it's cannot be retrieved from the MOW SKU's.

Right, do you have any other source for location or that you can
make this implication from your devices?

> The only exception in
> Intel cards are JP and KR SKU's which are real regulatory domains.

What makes them "real" BTW?

> Just my two cents, probably didn't help to solve the problem,

It certainly helps more understand your situation. I had no idea
of MOW1 and MOW2. Can this be documented as part of the
regulatory_hint() code changes which will be added?

  Luis

Re: New Regulatory Domain Api.

[Tomas Winkler]

On Wed, Oct 15, 2008 at 7:08 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Oct 15, 2008 at 04:31:20PM -0700, Tomas Winkler wrote:
>> On Wed, Oct 15, 2008 at 3:16 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > On Wed, Oct 15, 2008 at 12:25:48PM -0700, Marcel Holtmann wrote:
>> >> > The problem here is not this though the problem here is the case
>> >> > where people are using 2.6.28 without no iw or crda *and* have more
>> >> > than two cards :)
>> >>
>> >> it might sound like an unlikely case and it will most likely only be the
>> >> A-band usage anyway, but it is a valid case. People with old laptops do
>> >> use newer wireless cards in PCMCIA or USB form factor to get better WiFi
>> >> performance and/or stability. In some cases you can just replace your
>> >> internal card, but with the switch from MiniPCI to half-MiniPCI this is
>> >> not as likely anymore. So the use of a second external card becomes more
>> >> likely.
>> >
>> > Right, and the proposed solution I had was to use an intersection
>> > between two regulatory domains. This solution just doesn't currently
>> > work well with Intel cards due to the capability <-> regulatory one to
>> > one mapping.
>>
>> This  might be viewed this way but this is not concept behind it.
>> First Intel HW enforce regulatory domain written in the EEPROM, which
>> makes it in your sense capability even it's not.
>
> I see.
>
>> Second Intel uses special regulatory domains called MOW1 and MOW2
>> (most of the world 1 and 2) + possible restriction to BG. These 3
>> domains/capabilities should be restrictive enough comply with most of
>> the world regulatory restrictions.
>
> Well to meet your current SKUs requirements :)
>
>> There is no real hint for specific
>> regulatory domain that can be applied form this, the concept is that
>> you should be move relatively freely around the globe without changing
>> anything.
>
> The issue was your single band cards do not store 5 GHz band regulatory
> information. Is this MOW1 or MOW2?

Don't understand the question, the 5GHz channels are disabled that's
all you can read from there.
>
>> You really have to use some other source to specify regulatory domain
>> it's cannot be retrieved from the MOW SKU's.
>
> Right, do you have any other source for location or that you can
> make this implication from your devices?

No, you cannot guess that.

>
>> The only exception in
>> Intel cards are JP and KR SKU's which are real regulatory domains.
>
> What makes them "real" BTW?

They are regulatory domains in the sens you defining them.

>> Just my two cents, probably didn't help to solve the problem,
>
> It certainly helps more understand your situation. I had no idea
> of MOW1 and MOW2. Can this be documented as part of the
> regulatory_hint() code changes which will be added?

I've just checked current docs and from 5000 on inclusively there are
only 3 SKU's MOW, ABG (no N) and BG. All others were depreciated.


Tomas

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 05:35:44PM -0700, Tomas Winkler wrote:
> On Wed, Oct 15, 2008 at 7:08 PM, Luis R. Rodriguez
> > The issue was your single band cards do not store 5 GHz band regulatory
> > information. Is this MOW1 or MOW2?
> 
> Don't understand the question, the 5GHz channels are disabled that's
> all you can read from there.

Oh OK so its not just MOW1 and MOW2 but you also *do* take into account
the card's capabilities.

> > It certainly helps more understand your situation. I had no idea
> > of MOW1 and MOW2. Can this be documented as part of the
> > regulatory_hint() code changes which will be added?
> 
> I've just checked current docs and from 5000 on inclusively there are
> only 3 SKU's MOW, ABG (no N) and BG. All others were depreciated.

Interesting.. Are these SKUs also used on other platforms as well, say
for Windows?

Anyway since you only have 3 this should be very simple to resolve...
Just add the 5 GHz frequency ranges you always support. Obviously the BG
card will not be able to make use of them :)

  Luis

Re: New Regulatory Domain Api.

[Tomas Winkler]

On Wed, Oct 15, 2008 at 7:44 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Oct 15, 2008 at 05:35:44PM -0700, Tomas Winkler wrote:
>> On Wed, Oct 15, 2008 at 7:08 PM, Luis R. Rodriguez
>> > The issue was your single band cards do not store 5 GHz band regulatory
>> > information. Is this MOW1 or MOW2?
>>
>> Don't understand the question, the 5GHz channels are disabled that's
>> all you can read from there.
>
> Oh OK so its not just MOW1 and MOW2 but you also *do* take into account
> the card's capabilities.
>
>> > It certainly helps more understand your situation. I had no idea
>> > of MOW1 and MOW2. Can this be documented as part of the
>> > regulatory_hint() code changes which will be added?
>>
>> I've just checked current docs and from 5000 on inclusively there are
>> only 3 SKU's MOW, ABG (no N) and BG. All others were depreciated.
>
> Interesting.. Are these SKUs also used on other platforms as well, say
> for Windows?

Definitely It's not defined specially  for Linux market. And you may
sense that this is also station mode specific. In AP mode probably the
story would be different.

> Anyway since you only have 3 this should be very simple to resolve...
> Just add the 5 GHz frequency ranges you always support. Obviously the BG
> card will not be able to make use of them :)

It's ugly but possible w/a but we still have 3945 and 4965 where it is
not so simple.
Tomas

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 05:57:20PM -0700, Tomas Winkler wrote:
> On Wed, Oct 15, 2008 at 7:44 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > Anyway since you only have 3 this should be very simple to resolve...
> > Just add the 5 GHz frequency ranges you always support. Obviously the BG
> > card will not be able to make use of them :)
> 
> It's ugly but possible w/a but we still have 3945 and 4965 where it is
> not so simple.

Ah. I see. Ok then please try this patch. What do you guys think?

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 626dbb6..703382a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -469,6 +469,31 @@ static u32 freq_max_bandwidth(const struct ieee80211_freq_range *freq_range,
 	return 0;
 }
 
+/**
+ * freq_in_rule_band - tells us if a frequency rule is in freqs band
+ * @freq_range: frequency rule we want to query
+ * @freq_khz: frequency we are inquiring about
+ *
+ * This lets us know if a specific frequency rule is or is not relevant to
+ * a specific frequency's band. Bands are device specific and artificial
+ * definitions (the "2.4 GHz band" and the "5 GHz band"), however it is
+ * safe for now to assume that a frequency rule should not be part of a
+ * frequency's band if the start freq or end freq are off by more than 2 GHz.
+ * This resolution can be lowered and should be considered as we add
+ * regulatory rule support for other "bands".
+ **/
+static bool freq_in_rule_band(const struct ieee80211_freq_range *freq_range,
+	u32 freq_khz)
+{
+#define ONE_GHZ_IN_HZ	1000000000
+	if (abs(freq_khz - freq_range->start_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
+		return true;
+	if (abs(freq_khz - freq_range->end_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
+		return true;
+	return false;
+#undef ONE_GHZ_IN_HZ
+}
+
 /* XXX: add support for the rest of enum nl80211_reg_rule_flags, we may
  * want to just have the channel structure use these */
 static u32 map_regdom_flags(u32 rd_flags)
@@ -492,11 +517,17 @@ static u32 map_regdom_flags(u32 rd_flags)
  * @reg_rule: the regulatory rule which we have for this frequency
  *
  * Use this function to get the regulatory rule for a specific frequency.
+ * It returns 0 if it was able to find a valid regulatory rule which does
+ * apply to the given center_freq otherwise it returns non-zero. It will
+ * also -ERANGE if we determine the given center_freq does not even have
+ * a regulatory rule for a frequency range in the center_freq's band. See
+ * freq_in_rule_band() for our current definition of a band.
  */
 static int freq_reg_info(u32 center_freq, u32 *bandwidth,
 			 const struct ieee80211_reg_rule **reg_rule)
 {
 	int i;
+	bool band_rule_found = false;
 	u32 max_bandwidth = 0;
 
 	if (!cfg80211_regdomain)
@@ -510,6 +541,9 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
 		rr = &cfg80211_regdomain->reg_rules[i];
 		fr = &rr->freq_range;
 		pr = &rr->power_rule;
+
+		band_rule_found = freq_in_rule_band(fr, center_freq);
+
 		max_bandwidth = freq_max_bandwidth(fr, center_freq);
 		if (max_bandwidth && *bandwidth <= max_bandwidth) {
 			*reg_rule = rr;
@@ -518,6 +552,9 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
 		}
 	}
 
+	if (!band_rule_found)
+		return -ERANGE;
+
 	return !max_bandwidth;
 }
 
@@ -533,8 +570,15 @@ static void handle_channel(struct ieee80211_channel *chan)
 		&max_bandwidth, &reg_rule);
 
 	if (r) {
-		flags |= IEEE80211_CHAN_DISABLED;
-		chan->flags = flags;
+		/* This means a regulatory rule was found with a frequency
+		 * range in center_freq's band. In this case we know the
+		 * regulatory rule has at least *one* regulatory rule for
+		 * the band so we must respect its band definitions. Otherwise
+		 * we assume it may not even know anything about our band */
+		if (r != -ERANGE) {
+			flags |= IEEE80211_CHAN_DISABLED;
+			chan->flags = flags;
+		}
 		return;
 	}
 

Re: New Regulatory Domain Api.

[Zhu Yi]

On Wed, 2008-10-15 at 12:56 -0600, Luis R. Rodriguez wrote:
> On Wed, Oct 15, 2008 at 05:57:20PM -0700, Tomas Winkler wrote:
> > On Wed, Oct 15, 2008 at 7:44 PM, Luis R. Rodriguez
> > <lrodriguez@atheros.com> wrote:
> > > Anyway since you only have 3 this should be very simple to resolve...
> > > Just add the 5 GHz frequency ranges you always support. Obviously the BG
> > > card will not be able to make use of them :)
> >
> > It's ugly but possible w/a but we still have 3945 and 4965 where it is
> > not so simple.
> 
> Ah. I see. Ok then please try this patch. What do you guys think?

With this patch, the second card own A band reg_rules are not enforced
for itself. (Still use the first card BG, second card ABG example.)
Think about the second card is not Intel like card which enforces the
regulatory in the firmware. The second card uses alpha2 hint. But the
regdomain allows ALL A band channels.

Thanks,
-yi

> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 626dbb6..703382a 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -469,6 +469,31 @@ static u32 freq_max_bandwidth(const struct ieee80211_freq_range *freq_range,
>         return 0;
>  }
> 
> +/**
> + * freq_in_rule_band - tells us if a frequency rule is in freqs band
> + * @freq_range: frequency rule we want to query
> + * @freq_khz: frequency we are inquiring about
> + *
> + * This lets us know if a specific frequency rule is or is not relevant to
> + * a specific frequency's band. Bands are device specific and artificial
> + * definitions (the "2.4 GHz band" and the "5 GHz band"), however it is
> + * safe for now to assume that a frequency rule should not be part of a
> + * frequency's band if the start freq or end freq are off by more than 2 GHz.
> + * This resolution can be lowered and should be considered as we add
> + * regulatory rule support for other "bands".
> + **/
> +static bool freq_in_rule_band(const struct ieee80211_freq_range *freq_range,
> +       u32 freq_khz)
> +{
> +#define ONE_GHZ_IN_HZ  1000000000
> +       if (abs(freq_khz - freq_range->start_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
> +               return true;
> +       if (abs(freq_khz - freq_range->end_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
> +               return true;
> +       return false;
> +#undef ONE_GHZ_IN_HZ
> +}
> +
>  /* XXX: add support for the rest of enum nl80211_reg_rule_flags, we may
>   * want to just have the channel structure use these */
>  static u32 map_regdom_flags(u32 rd_flags)
> @@ -492,11 +517,17 @@ static u32 map_regdom_flags(u32 rd_flags)
>   * @reg_rule: the regulatory rule which we have for this frequency
>   *
>   * Use this function to get the regulatory rule for a specific frequency.
> + * It returns 0 if it was able to find a valid regulatory rule which does
> + * apply to the given center_freq otherwise it returns non-zero. It will
> + * also -ERANGE if we determine the given center_freq does not even have
> + * a regulatory rule for a frequency range in the center_freq's band. See
> + * freq_in_rule_band() for our current definition of a band.
>   */
>  static int freq_reg_info(u32 center_freq, u32 *bandwidth,
>                          const struct ieee80211_reg_rule **reg_rule)
>  {
>         int i;
> +       bool band_rule_found = false;
>         u32 max_bandwidth = 0;
> 
>         if (!cfg80211_regdomain)
> @@ -510,6 +541,9 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
>                 rr = &cfg80211_regdomain->reg_rules[i];
>                 fr = &rr->freq_range;
>                 pr = &rr->power_rule;
> +
> +               band_rule_found = freq_in_rule_band(fr, center_freq);
> +
>                 max_bandwidth = freq_max_bandwidth(fr, center_freq);
>                 if (max_bandwidth && *bandwidth <= max_bandwidth) {
>                         *reg_rule = rr;
> @@ -518,6 +552,9 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
>                 }
>         }
> 
> +       if (!band_rule_found)
> +               return -ERANGE;
> +
>         return !max_bandwidth;
>  }
> 
> @@ -533,8 +570,15 @@ static void handle_channel(struct ieee80211_channel *chan)
>                 &max_bandwidth, &reg_rule);
> 
>         if (r) {
> -               flags |= IEEE80211_CHAN_DISABLED;
> -               chan->flags = flags;
> +               /* This means a regulatory rule was found with a frequency
> +                * range in center_freq's band. In this case we know the
> +                * regulatory rule has at least *one* regulatory rule for
> +                * the band so we must respect its band definitions. Otherwise
> +                * we assume it may not even know anything about our band */
> +               if (r != -ERANGE) {
> +                       flags |= IEEE80211_CHAN_DISABLED;
> +                       chan->flags = flags;
> +               }
>                 return;
>         }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 15, 2008 at 08:00:30PM -0700, Zhu Yi wrote:
> On Wed, 2008-10-15 at 12:56 -0600, Luis R. Rodriguez wrote:
> > On Wed, Oct 15, 2008 at 05:57:20PM -0700, Tomas Winkler wrote:
> > > On Wed, Oct 15, 2008 at 7:44 PM, Luis R. Rodriguez
> > > <lrodriguez@atheros.com> wrote:
> > > > Anyway since you only have 3 this should be very simple to resolve...
> > > > Just add the 5 GHz frequency ranges you always support. Obviously the BG
> > > > card will not be able to make use of them :)
> > >
> > > It's ugly but possible w/a but we still have 3945 and 4965 where it is
> > > not so simple.
> >
> > Ah. I see. Ok then please try this patch. What do you guys think?
> 
> With this patch, the second card own A band reg_rules are not enforced
> for itself. (Still use the first card BG, second card ABG example.)
> Think about the second card is not Intel like card which enforces the
> regulatory in the firmware. The second card uses alpha2 hint. But the
> regdomain allows ALL A band channels.

So.. you didn't look at the code to check where it may have failed...

Anyway try this one. This changes two lines, it checks if the band check
was already true, if so it doesn't overwrite it. If I get a chance I'll
test it.

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 626dbb6..25b6f19 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -469,6 +469,31 @@ static u32 freq_max_bandwidth(const struct ieee80211_freq_range *freq_range,
 	return 0;
 }
 
+/**
+ * freq_in_rule_band - tells us if a frequency rule is in freqs band
+ * @freq_range: frequency rule we want to query
+ * @freq_khz: frequency we are inquiring about
+ *
+ * This lets us know if a specific frequency rule is or is not relevant to
+ * a specific frequency's band. Bands are device specific and artificial
+ * definitions (the "2.4 GHz band" and the "5 GHz band"), however it is
+ * safe for now to assume that a frequency rule should not be part of a
+ * frequency's band if the start freq or end freq are off by more than 2 GHz.
+ * This resolution can be lowered and should be considered as we add
+ * regulatory rule support for other "bands".
+ **/
+static bool freq_in_rule_band(const struct ieee80211_freq_range *freq_range,
+	u32 freq_khz)
+{
+#define ONE_GHZ_IN_HZ	1000000000
+	if (abs(freq_khz - freq_range->start_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
+		return true;
+	if (abs(freq_khz - freq_range->end_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
+		return true;
+	return false;
+#undef ONE_GHZ_IN_HZ
+}
+
 /* XXX: add support for the rest of enum nl80211_reg_rule_flags, we may
  * want to just have the channel structure use these */
 static u32 map_regdom_flags(u32 rd_flags)
@@ -492,11 +517,17 @@ static u32 map_regdom_flags(u32 rd_flags)
  * @reg_rule: the regulatory rule which we have for this frequency
  *
  * Use this function to get the regulatory rule for a specific frequency.
+ * It returns 0 if it was able to find a valid regulatory rule which does
+ * apply to the given center_freq otherwise it returns non-zero. It will
+ * also -ERANGE if we determine the given center_freq does not even have
+ * a regulatory rule for a frequency range in the center_freq's band. See
+ * freq_in_rule_band() for our current definition of a band.
  */
 static int freq_reg_info(u32 center_freq, u32 *bandwidth,
 			 const struct ieee80211_reg_rule **reg_rule)
 {
 	int i;
+	bool band_rule_found = false;
 	u32 max_bandwidth = 0;
 
 	if (!cfg80211_regdomain)
@@ -510,6 +541,13 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
 		rr = &cfg80211_regdomain->reg_rules[i];
 		fr = &rr->freq_range;
 		pr = &rr->power_rule;
+
+		/* We only need to know if one frequency rule was
+		 * was in center_freq's band, that's enough, so lets
+		 * not overwrite it once found */
+		if (!band_rule_found)
+			band_rule_found = freq_in_rule_band(fr, center_freq);
+
 		max_bandwidth = freq_max_bandwidth(fr, center_freq);
 		if (max_bandwidth && *bandwidth <= max_bandwidth) {
 			*reg_rule = rr;
@@ -518,6 +556,9 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
 		}
 	}
 
+	if (!band_rule_found)
+		return -ERANGE;
+
 	return !max_bandwidth;
 }
 
@@ -533,8 +574,15 @@ static void handle_channel(struct ieee80211_channel *chan)
 		&max_bandwidth, &reg_rule);
 
 	if (r) {
-		flags |= IEEE80211_CHAN_DISABLED;
-		chan->flags = flags;
+		/* This means a regulatory rule was found with a frequency
+		 * range in center_freq's band. In this case we know the
+		 * regulatory rule has at least *one* regulatory rule for
+		 * the band so we must respect its band definitions. Otherwise
+		 * we assume it may not even know anything about our band */
+		if (r != -ERANGE) {
+			flags |= IEEE80211_CHAN_DISABLED;
+			chan->flags = flags;
+		}
 		return;
 	}
 

Re: New Regulatory Domain Api.

[Zhu Yi]

On Thu, 2008-10-16 at 04:38 -0700, Luis R. Rodriguez wrote:
> So.. you didn't look at the code to check where it may have failed...

IIRC, below patch changes the previously allowing none 5GHz channels to
allowing all 5GHZ channels. It does resolve our problem. But is it the
correct behaviour? Or did I miss anything?

Thanks,
-yi

> Anyway try this one. This changes two lines, it checks if the band check
> was already true, if so it doesn't overwrite it. If I get a chance I'll
> test it.
> 
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 626dbb6..25b6f19 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -469,6 +469,31 @@ static u32 freq_max_bandwidth(const struct ieee80211_freq_range *freq_range,
>         return 0;
>  }
> 
> +/**
> + * freq_in_rule_band - tells us if a frequency rule is in freqs band
> + * @freq_range: frequency rule we want to query
> + * @freq_khz: frequency we are inquiring about
> + *
> + * This lets us know if a specific frequency rule is or is not relevant to
> + * a specific frequency's band. Bands are device specific and artificial
> + * definitions (the "2.4 GHz band" and the "5 GHz band"), however it is
> + * safe for now to assume that a frequency rule should not be part of a
> + * frequency's band if the start freq or end freq are off by more than 2 GHz.
> + * This resolution can be lowered and should be considered as we add
> + * regulatory rule support for other "bands".
> + **/
> +static bool freq_in_rule_band(const struct ieee80211_freq_range *freq_range,
> +       u32 freq_khz)
> +{
> +#define ONE_GHZ_IN_HZ  1000000000
> +       if (abs(freq_khz - freq_range->start_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
> +               return true;
> +       if (abs(freq_khz - freq_range->end_freq_khz) <= (2 * ONE_GHZ_IN_HZ))
> +               return true;
> +       return false;
> +#undef ONE_GHZ_IN_HZ
> +}
> +
>  /* XXX: add support for the rest of enum nl80211_reg_rule_flags, we may
>   * want to just have the channel structure use these */
>  static u32 map_regdom_flags(u32 rd_flags)
> @@ -492,11 +517,17 @@ static u32 map_regdom_flags(u32 rd_flags)
>   * @reg_rule: the regulatory rule which we have for this frequency
>   *
>   * Use this function to get the regulatory rule for a specific frequency.
> + * It returns 0 if it was able to find a valid regulatory rule which does
> + * apply to the given center_freq otherwise it returns non-zero. It will
> + * also -ERANGE if we determine the given center_freq does not even have
> + * a regulatory rule for a frequency range in the center_freq's band. See
> + * freq_in_rule_band() for our current definition of a band.
>   */
>  static int freq_reg_info(u32 center_freq, u32 *bandwidth,
>                          const struct ieee80211_reg_rule **reg_rule)
>  {
>         int i;
> +       bool band_rule_found = false;
>         u32 max_bandwidth = 0;
> 
>         if (!cfg80211_regdomain)
> @@ -510,6 +541,13 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
>                 rr = &cfg80211_regdomain->reg_rules[i];
>                 fr = &rr->freq_range;
>                 pr = &rr->power_rule;
> +
> +               /* We only need to know if one frequency rule was
> +                * was in center_freq's band, that's enough, so lets
> +                * not overwrite it once found */
> +               if (!band_rule_found)
> +                       band_rule_found = freq_in_rule_band(fr, center_freq);
> +
>                 max_bandwidth = freq_max_bandwidth(fr, center_freq);
>                 if (max_bandwidth && *bandwidth <= max_bandwidth) {
>                         *reg_rule = rr;
> @@ -518,6 +556,9 @@ static int freq_reg_info(u32 center_freq, u32 *bandwidth,
>                 }
>         }
> 
> +       if (!band_rule_found)
> +               return -ERANGE;
> +
>         return !max_bandwidth;
>  }
> 
> @@ -533,8 +574,15 @@ static void handle_channel(struct ieee80211_channel *chan)
>                 &max_bandwidth, &reg_rule);
> 
>         if (r) {
> -               flags |= IEEE80211_CHAN_DISABLED;
> -               chan->flags = flags;
> +               /* This means a regulatory rule was found with a frequency
> +                * range in center_freq's band. In this case we know the
> +                * regulatory rule has at least *one* regulatory rule for
> +                * the band so we must respect its band definitions. Otherwise
> +                * we assume it may not even know anything about our band */
> +               if (r != -ERANGE) {
> +                       flags |= IEEE80211_CHAN_DISABLED;
> +                       chan->flags = flags;
> +               }
>                 return;
>         }

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Sun, Oct 19, 2008 at 7:51 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Thu, 2008-10-16 at 04:38 -0700, Luis R. Rodriguez wrote:
>> So.. you didn't look at the code to check where it may have failed...
>
> IIRC, below patch changes the previously allowing none 5GHz channels to
> allowing all 5GHZ channels. It does resolve our problem. But is it the
> correct behaviour? Or did I miss anything?

Well if you are using regulatory_hint() and only have rules defined in
the 2 GHz band then yes it won't ever touch 5 GHz channels... I don't
like this at all but its what I thought you were asking for.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Sun, 2008-10-19 at 20:40 -0700, Luis R. Rodriguez wrote:
> On Sun, Oct 19, 2008 at 7:51 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> > On Thu, 2008-10-16 at 04:38 -0700, Luis R. Rodriguez wrote:
> >> So.. you didn't look at the code to check where it may have failed...
> >
> > IIRC, below patch changes the previously allowing none 5GHz channels to
> > allowing all 5GHZ channels. It does resolve our problem. But is it the
> > correct behaviour? Or did I miss anything?
> 
> Well if you are using regulatory_hint() and only have rules defined in
> the 2 GHz band then yes it won't ever touch 5 GHz channels... I don't
> like this at all but its what I thought you were asking for.

No, with this patch the 5GHz reg_rules on the second card are bypassed
by regdomain. This is not correct. I do like to see the new regdomain
handles all valid usage models correctly. But I fail to see how it can
be with the current design (the first one wins, or do intersection). We
should do intersection within each band, but do union between bands. 

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Sun, Oct 19, 2008 at 10:18 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Sun, 2008-10-19 at 20:40 -0700, Luis R. Rodriguez wrote:
>> On Sun, Oct 19, 2008 at 7:51 PM, Zhu Yi <yi.zhu@intel.com> wrote:
>> > On Thu, 2008-10-16 at 04:38 -0700, Luis R. Rodriguez wrote:
>> >> So.. you didn't look at the code to check where it may have failed...
>> >
>> > IIRC, below patch changes the previously allowing none 5GHz channels to
>> > allowing all 5GHZ channels. It does resolve our problem. But is it the
>> > correct behaviour? Or did I miss anything?
>>
>> Well if you are using regulatory_hint() and only have rules defined in
>> the 2 GHz band then yes it won't ever touch 5 GHz channels... I don't
>> like this at all but its what I thought you were asking for.
>
> No, with this patch the 5GHz reg_rules on the second card are bypassed
> by regdomain.

Well the code specifically disregards secondary regulatory_hint()'s
right now and we reviewed why -- we discussed it at OLS and agreed to
go with the first one as that will usually be the built in one. That's
why. The restrictive thing to do next to handle more cards better is
to keep doing intersections.

Regarding doing unions on the regulatory information on bands -- I'm
not sure I even like the current patch I posted.. it means for
regulatory domains in db.txt which have no 5 GHz band we should be
passing at least one small frequency range to indicate to the core no
5 GHz channels are allowed. I'm not liking this... and this is just to
handle the case where you cannot provide a regulatory domain for 5 GHz
as your EEPROM doesn't have it as your EEPROM is the intersection of
the hw capabilities and the regulatory domain so for 2 GHz cards you
have no 5 GHz definitions.

Again -- how about a static 5 GHz definition for your 2 GHz band
cards? This way you can deal with the *rare* case where users plug in
a new dual band card and the system had a built in 2 Ghz card. Also --
we do have support for iw reg set, it doesn't seem you have considered
the advantages of this as well.

Tomas mentioned your 5 GHz case for >= iwlagn cards is pretty easy,
how about for iwl3945 and iwl4965? If you have it listed how about
putting it in the driver code path for those drivers? How many 5 GHz
SKUs are there for these cards?

Are there Intel express cards sold BTW? Or we dealing with a case
where a box can be sold with a lot of cards pre-installed?

  Luis

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Sun, 2008-10-19 at 23:33 -0700, Luis R. Rodriguez wrote:

> Well the code specifically disregards secondary regulatory_hint()'s
> right now and we reviewed why -- we discussed it at OLS and agreed to
> go with the first one as that will usually be the built in one. That's
> why. The restrictive thing to do next to handle more cards better is
> to keep doing intersections.

If we're going to disregard 5 GHz for the first hint if there's no
information on it, then we should take the first hint containing 5 GHz
information seriously imho.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Sun, Oct 19, 2008 at 11:38 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2008-10-19 at 23:33 -0700, Luis R. Rodriguez wrote:
>
>> Well the code specifically disregards secondary regulatory_hint()'s
>> right now and we reviewed why -- we discussed it at OLS and agreed to
>> go with the first one as that will usually be the built in one. That's
>> why. The restrictive thing to do next to handle more cards better is
>> to keep doing intersections.
>
> If we're going to disregard 5 GHz for the first hint if there's no
> information on it, then we should take the first hint containing 5 GHz
> information seriously imho.

Sure but an issue here is that if we do deal with band-specific
regulatory domain definitions we change the regulatory behavior from
being "disallow everything first" to "allow everything first, disable
everything in the band for which we encounter a rule in except what
the rule allows".

Since the regulatory definitions in db.txt are in KHz we are allowing
it to grow as more technology pops up with support for more bands. I
think the first approach was better. The current suggestion of only
applying rules if a band reg definition is present is only to deal
with a rare case. I think its better we try to handle that instead and
keep our existing behaviour.

  Luis

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Sun, 2008-10-19 at 23:46 -0700, Luis R. Rodriguez wrote:

> Sure but an issue here is that if we do deal with band-specific
> regulatory domain definitions we change the regulatory behavior from
> being "disallow everything first" to "allow everything first, disable
> everything in the band for which we encounter a rule in except what
> the rule allows".
> 
> Since the regulatory definitions in db.txt are in KHz we are allowing
> it to grow as more technology pops up with support for more bands. I
> think the first approach was better. The current suggestion of only
> applying rules if a band reg definition is present is only to deal
> with a rare case. I think its better we try to handle that instead and
> keep our existing behaviour.

Ack on both points, which is why I said "If we're going to [...]". I
don't think I've seen a convincing use case for this other than test
environments, in which you can very well just use crda.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Sun, Oct 19, 2008 at 11:50 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2008-10-19 at 23:46 -0700, Luis R. Rodriguez wrote:
>
>> Sure but an issue here is that if we do deal with band-specific
>> regulatory domain definitions we change the regulatory behavior from
>> being "disallow everything first" to "allow everything first, disable
>> everything in the band for which we encounter a rule in except what
>> the rule allows".
>>
>> Since the regulatory definitions in db.txt are in KHz we are allowing
>> it to grow as more technology pops up with support for more bands. I
>> think the first approach was better. The current suggestion of only
>> applying rules if a band reg definition is present is only to deal
>> with a rare case. I think its better we try to handle that instead and
>> keep our existing behaviour.
>
> Ack on both points, which is why I said "If we're going to [...]". I
> don't think I've seen a convincing use case for this other than test
> environments, in which you can very well just use crda.

Ah, ok :)

Yi, BTW a simple way to get a distribution to add support initially
for crda is to have as part of an init script to call

iw reg set $COUNTRY

where $COUNTRY is determined though whatever distribution heuristics.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Mon, 2008-10-20 at 00:59 -0600, Luis R. Rodriguez wrote:
> > Ack on both points, which is why I said "If we're going to [...]". I
> > don't think I've seen a convincing use case for this other than test
> > environments, in which you can very well just use crda.
> 
> Ah, ok :)

OK, my point is here:
http://marc.info/?l=linux-wireless&m=122403515521098&w=2

Maybe Marcel has more to say when he wakes up...

> Yi, BTW a simple way to get a distribution to add support initially
> for crda is to have as part of an init script to call
> 
> iw reg set $COUNTRY
> 
> where $COUNTRY is determined though whatever distribution heuristics.

Thanks for the info.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Yi,

> > > Ack on both points, which is why I said "If we're going to [...]". I
> > > don't think I've seen a convincing use case for this other than test
> > > environments, in which you can very well just use crda.
> > 
> > Ah, ok :)
> 
> OK, my point is here:
> http://marc.info/?l=linux-wireless&m=122403515521098&w=2
> 
> Maybe Marcel has more to say when he wakes up...

I do wanna keep it as simple as possible, but on the other hand we
should do a pretty decent job with picking a regulatory domain when no
userspace is present (old or CRDA missing).

So my current thinking is that the regulatory hint for a card is limited
to the frequencies the card actually registers with mac80211. If the
internal card is 2.4 GHz, then we limit the hint to this. So the 5 GHz
band is still a virgin. If a 5 GHz card comes along and it is the first
in its band, then we take its regulatory hint for that band, but for the
2.4 GHz band it has to follow the first cards hint.

As I mentioned before, first card wins is a perfect solution from my
point of view, but we should not punish a second card in a different
band if the first card is not touching this band at all. And I can see
these user scenarios happening and in some cases they might be done on
purpose to serve every band with a different piece of hardware.

And for the cases where new bands might be used in the future. In that
case we do have to do this right since userspace might be outdated. Lets
face it, we should always support a new kernel with an old userspace.
That is how the Linux kernel is suppose to work. That is probably the
only reason why wireless extensions are still around ;)

The idea of having a 2.4 GHz only card provide a hint for 5 GHz is just
plain wrong. If the hardware is designed for 2.4 GHz it should not mess
with other frequencies.

So my solution would be first regulatory hint in each band wins.

Also we should have printk that shows up in dmesg in cases where neither
crda or iw modified the regulatory domain and we have clash with the
hints provided by two or more cards.

Regards

Marcel

Re: New Regulatory Domain Api.

[Zhu Yi]

On Mon, 2008-10-20 at 10:43 -0600, Marcel Holtmann wrote:
> I do wanna keep it as simple as possible, but on the other hand we
> should do a pretty decent job with picking a regulatory domain when no
> userspace is present (old or CRDA missing).
> 
> So my current thinking is that the regulatory hint for a card is limited
> to the frequencies the card actually registers with mac80211. If the
> internal card is 2.4 GHz, then we limit the hint to this. So the 5 GHz
> band is still a virgin. If a 5 GHz card comes along and it is the first
> in its band, then we take its regulatory hint for that band, but for the
> 2.4 GHz band it has to follow the first cards hint.
> 
> As I mentioned before, first card wins is a perfect solution from my
> point of view, but we should not punish a second card in a different
> band if the first card is not touching this band at all. And I can see
> these user scenarios happening and in some cases they might be done on
> purpose to serve every band with a different piece of hardware.
> 
> And for the cases where new bands might be used in the future. In that
> case we do have to do this right since userspace might be outdated. Lets
> face it, we should always support a new kernel with an old userspace.
> That is how the Linux kernel is suppose to work. That is probably the
> only reason why wireless extensions are still around ;)
> 
> The idea of having a 2.4 GHz only card provide a hint for 5 GHz is just
> plain wrong. If the hardware is designed for 2.4 GHz it should not mess
> with other frequencies.
> 
> So my solution would be first regulatory hint in each band wins.
> 
> Also we should have printk that shows up in dmesg in cases where neither
> crda or iw modified the regulatory domain and we have clash with the
> hints provided by two or more cards.

I totally agree with you. IIRC, the current situation is nobody is
willing to implement the per-band regulatory hints for such a rare but
valid case. Luis, will you accept patches if somebody else write it?

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Mon, Oct 20, 2008 at 6:34 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Mon, 2008-10-20 at 10:43 -0600, Marcel Holtmann wrote:
>> I do wanna keep it as simple as possible, but on the other hand we
>> should do a pretty decent job with picking a regulatory domain when no
>> userspace is present (old or CRDA missing).
>>
>> So my current thinking is that the regulatory hint for a card is limited
>> to the frequencies the card actually registers with mac80211. If the
>> internal card is 2.4 GHz, then we limit the hint to this. So the 5 GHz
>> band is still a virgin. If a 5 GHz card comes along and it is the first
>> in its band, then we take its regulatory hint for that band, but for the
>> 2.4 GHz band it has to follow the first cards hint.
>>
>> As I mentioned before, first card wins is a perfect solution from my
>> point of view, but we should not punish a second card in a different
>> band if the first card is not touching this band at all. And I can see
>> these user scenarios happening and in some cases they might be done on
>> purpose to serve every band with a different piece of hardware.
>>
>> And for the cases where new bands might be used in the future. In that
>> case we do have to do this right since userspace might be outdated. Lets
>> face it, we should always support a new kernel with an old userspace.
>> That is how the Linux kernel is suppose to work. That is probably the
>> only reason why wireless extensions are still around ;)
>>
>> The idea of having a 2.4 GHz only card provide a hint for 5 GHz is just
>> plain wrong. If the hardware is designed for 2.4 GHz it should not mess
>> with other frequencies.
>>
>> So my solution would be first regulatory hint in each band wins.
>>
>> Also we should have printk that shows up in dmesg in cases where neither
>> crda or iw modified the regulatory domain and we have clash with the
>> hints provided by two or more cards.
>
> I totally agree with you. IIRC, the current situation is nobody is
> willing to implement the per-band regulatory hints for such a rare but
> valid case. Luis, will you accept patches if somebody else write it?

What are you talking about? I wrote a patch for you. I just do not
agree with the approach anymore, you are trying to resolve an issue by
not fixing the real source to the problem.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Mon, 2008-10-20 at 19:42 -0600, Luis R. Rodriguez wrote:
> What are you talking about? I wrote a patch for you. I just do not
> agree with the approach anymore, you are trying to resolve an issue by
> not fixing the real source to the problem.

Your patch is incorrect. It solves one problem but brings more trouble.
For me, the per-band regulatory hint is the correct approach. What is
the real source to the problem you are talking about?

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Mon, Oct 20, 2008 at 6:58 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Mon, 2008-10-20 at 19:42 -0600, Luis R. Rodriguez wrote:
>> What are you talking about? I wrote a patch for you. I just do not
>> agree with the approach anymore, you are trying to resolve an issue by
>> not fixing the real source to the problem.
>
> Your patch is incorrect. It solves one problem but brings more trouble.
> For me, the per-band regulatory hint is the correct approach. What is
> the real source to the problem you are talking about?

As I mentioned in my previous e-mail, the real problem is what you are
asking for changes the entire regulatory design from: "disable
everything and enable only this" to "enable everything except for
elements I don't define in the band I tell you to". There are many
design flaws with this; an obvious problem to this is what is a band?
In my patch I took the liberty to define that a frequency is part of a
band if a rule was present within 2 GHz of itself. This works but it
is trying to make a definition out of something that doesn't exist --
its trying to solve the wrong problem. Since regulatory database is in
KHz it is designed to allow us to grow regardless of band notions or
associations. In the regulatory database we allow for 2 GHz, 5 GHz,
etc KH  definitions for any country and this was designed to account
for misinformation on drivers to help the user be more compliant. By
changing the design to what you are suggesting you'd have to add a
dummy rule for every frequency "band" if you really want to disable
all other bands.

The real problem here is you are not providing 5 GHz regulatory rules
on a 2 GHz capable built-in card because you currently handle
regulatory definitions by intersecting with hardware capabilities
*and* the issue is what happens when a user plugs in a 5 GHz capable
card. For >= iwlagn you have only a few SKUs so if you want you can
put these definitions in the driver. As Tomas points out for iwl3945
and iwl4965 your SKUs are more complicated. Regulatory *is*
complicated, and that is the current outsourcing of db.txt to
userspace tries to accomplish. So the solution isn't to try to "fix"
the regulatory infrastructure to handle your particular issue when a
single Intel 2 GHz band card is present and you connect a dual band
card by changing its overall design, because we already provide a
mechanism to deal with overriding regulatory rules to help the user be
more compliant.

The proper solution is to either add 5 GHz regulatory rules to your
regulatory_hint() and/or rely on crda to enable the 5 GHz channels
required for the country the user is in. It is true that you need
manual intervention and the way I am trying to resolve that is not by
changing the design of the current regulatory infrastructure, instead
I want to add country selection support to say wpa_supplicant or
Network Manager. That, IMO, is how to address the problem correctly. I
also suggested a temporary solution which a distribution can use which
requires absolutely no manual user intervention, that of determining
the country through whatever means the distribution deems more fit and
calling iw reg set on $COUNTRY.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Mon, 2008-10-20 at 19:37 -0700, Luis R. Rodriguez wrote:
> As I mentioned in my previous e-mail, the real problem is what you are
> asking for changes the entire regulatory design from: "disable
> everything and enable only this" to "enable everything except for
> elements I don't define in the band I tell you to". There are many
> design flaws with this; an obvious problem to this is what is a band?
> In my patch I took the liberty to define that a frequency is part of a
> band if a rule was present within 2 GHz of itself. This works but it
> is trying to make a definition out of something that doesn't exist --
> its trying to solve the wrong problem. Since regulatory database is in
> KHz it is designed to allow us to grow regardless of band notions or
> associations. In the regulatory database we allow for 2 GHz, 5 GHz,
> etc KH  definitions for any country and this was designed to account
> for misinformation on drivers to help the user be more compliant. By
> changing the design to what you are suggesting you'd have to add a
> dummy rule for every frequency "band" if you really want to disable
> all other bands.

I agree you on the band and KHz.

> The real problem here is you are not providing 5 GHz regulatory rules
> on a 2 GHz capable built-in card because you currently handle
> regulatory definitions by intersecting with hardware capabilities
> *and* the issue is what happens when a user plugs in a 5 GHz capable
> card. For >= iwlagn you have only a few SKUs so if you want you can
> put these definitions in the driver. As Tomas points out for iwl3945
> and iwl4965 your SKUs are more complicated. Regulatory *is*
> complicated, and that is the current outsourcing of db.txt to
> userspace tries to accomplish. So the solution isn't to try to "fix"
> the regulatory infrastructure to handle your particular issue when a
> single Intel 2 GHz band card is present and you connect a dual band
> card by changing its overall design, because we already provide a
> mechanism to deal with overriding regulatory rules to help the user be
> more compliant.

The real problem is you are forcing a device to provide a SKU even it is
not capable of. An SKU is not always necessary as long as the hardware
provides other ways to comply with regulatory. To solve the problem, I'd
suggest a special regdomain named EVERYTHING. In the case the driver or
firmware enforces reg_rules, the core wireless reg_rules are safe to be
bypassed. EVERYTHING can always be overwritten by other regdomains. For
example, when the user inserts a second card with regdomain of EU, EU
becomes the global regdomain. A driver should only claim to use
EVERYTHING when it has its own way to enforce regulatory. Now the
concept changes to "the first non-EVERYTHING regdomain wins". Thoughts?

> The proper solution is to either add 5 GHz regulatory rules to your
> regulatory_hint() and/or rely on crda to enable the 5 GHz channels
> required for the country the user is in. It is true that you need
> manual intervention and the way I am trying to resolve that is not by
> changing the design of the current regulatory infrastructure, instead
> I want to add country selection support to say wpa_supplicant or
> Network Manager. That, IMO, is how to address the problem correctly. I
> also suggested a temporary solution which a distribution can use which
> requires absolutely no manual user intervention, that of determining
> the country through whatever means the distribution deems more fit and
> calling iw reg set on $COUNTRY.

See Marcel's comment on supporting new kernels with old applications.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Mon, Oct 20, 2008 at 9:02 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Mon, 2008-10-20 at 19:37 -0700, Luis R. Rodriguez wrote:

>> The real problem here is you are not providing 5 GHz regulatory rules
>> on a 2 GHz capable built-in card because you currently handle
>> regulatory definitions by intersecting with hardware capabilities
>> *and* the issue is what happens when a user plugs in a 5 GHz capable
>> card. For >= iwlagn you have only a few SKUs so if you want you can
>> put these definitions in the driver. As Tomas points out for iwl3945
>> and iwl4965 your SKUs are more complicated. Regulatory *is*
>> complicated, and that is the current outsourcing of db.txt to
>> userspace tries to accomplish. So the solution isn't to try to "fix"
>> the regulatory infrastructure to handle your particular issue when a
>> single Intel 2 GHz band card is present and you connect a dual band
>> card by changing its overall design, because we already provide a
>> mechanism to deal with overriding regulatory rules to help the user be
>> more compliant.
>
> The real problem is you are forcing a device to provide a SKU even it is
> not capable of.

We would be if we didn't provide a db.txt with public regulatory
definitions which people can contribute to, but we do have such db.

> An SKU is not always necessary as long as the hardware
> provides other ways to comply with regulatory.

I do not agree. Consider old devices with built-in regulatory rules in
hardware which go out of date. The regulatory framework accounts for
such flaws and *helps* to remain compliant.

>To solve the problem,

What problem?

> I'd
> suggest a special regdomain named EVERYTHING. In the case the driver or
> firmware enforces reg_rules, the core wireless reg_rules are safe to be
> bypassed.

You mean we add a flag to allow cfg80211 to ignore applying its
central regulatory definition to a wiphy? I disagree -- consider
outdated set of rules.

> EVERYTHING can always be overwritten by other regdomains. For
> example, when the user inserts a second card with regdomain of EU, EU
> becomes the global regdomain.

EU is not an ISO3166 alpha2 though, but I understand your point here,
however the goal of building a central regulatory infrastructure for
wireless was so it applies to all wiphys, not just mac80211 drivers.

> A driver should only claim to use
> EVERYTHING when it has its own way to enforce regulatory. Now the
> concept changes to "the first non-EVERYTHING regdomain wins".
> Thoughts?

Yeah, again, I think this proposal is trying to solve the wrong problem.

>> The proper solution is to either add 5 GHz regulatory rules to your
>> regulatory_hint() and/or rely on crda to enable the 5 GHz channels
>> required for the country the user is in. It is true that you need
>> manual intervention and the way I am trying to resolve that is not by
>> changing the design of the current regulatory infrastructure, instead
>> I want to add country selection support to say wpa_supplicant or
>> Network Manager. That, IMO, is how to address the problem correctly. I
>> also suggested a temporary solution which a distribution can use which
>> requires absolutely no manual user intervention, that of determining
>> the country through whatever means the distribution deems more fit and
>> calling iw reg set on $COUNTRY.
>
> See Marcel's comment on supporting new kernels with old applications.

Old userspace still works, we can however require new userspace for
new features. A compliant regulatory infrastructure is a feature.

I'm inclined to believe a patch to add country selection on
wpa_supplicant is the right next step.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Mon, 2008-10-20 at 21:58 -0700, Luis R. Rodriguez wrote:
> I do not agree. Consider old devices with built-in regulatory rules in
> hardware which go out of date. The regulatory framework accounts for
> such flaws and *helps* to remain compliant.

That's another story. For these devices, you can do what you want in
user space. But for other correct behavioured devices, bypass regulatory
framework is necessary. Because you have to trust the driver anyway.

> >To solve the problem,
> 
> What problem?

The problem a driver is not able to give a SKU as regulatory hint.

> > I'd
> > suggest a special regdomain named EVERYTHING. In the case the driver
> or
> > firmware enforces reg_rules, the core wireless reg_rules are safe to
> be
> > bypassed.
> 
> You mean we add a flag to allow cfg80211 to ignore applying its
> central regulatory definition to a wiphy? I disagree -- consider
> outdated set of rules.

It has nothing to do with ourdated rules. If a reg_rule is "wrong" in a
device, it will still be wrong after the regulatory_hint() call.

The current regulatory framework 100% trust the alpha2 or regdomain the
driver provided. Thus it should also trust a hint from driver "bypass
your regulatory check, I'll handle it myself".

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Mon, Oct 20, 2008 at 10:28 PM, Zhu Yi <yi.zhu@intel.com> wrote:
> On Mon, 2008-10-20 at 21:58 -0700, Luis R. Rodriguez wrote:
>> I do not agree. Consider old devices with built-in regulatory rules in
>> hardware which go out of date. The regulatory framework accounts for
>> such flaws and *helps* to remain compliant.
>
> That's another story. For these devices, you can do what you want in
> user space. But for other correct behavioured devices, bypass regulatory
> framework is necessary. Because you have to trust the driver anyway.

We do trust the driver and we do let it say "I know better". More on this below.

>> >To solve the problem,
>>
>> What problem?
>
> The problem a driver is not able to give a SKU as regulatory hint.

That is not the problem though as there is a solution to that.

The issue at hand, which started this 60-message thread, involves a
built-in Intel single band 2 GHz card and an external dual band card.
The issue is the dual band card's regulatory_hint() is ignored as the
current infrastructure ignores secondary requests and the first one
did not define a set of rules for 5 GHz as part of its
regulatory_hint(). A resolution to this is to have crda called for the
country the user is in. The reason this solves the issue at and is
hardware which is designed to not allow channels out of its EEPROM
won't be enabled as these channels are not registered and channels
which *should* be disabled based on the user's location *are*
disabled. The 5 GHz channels on the dual band card which *should* be
allowed are allowed. Additionally we do allow drivers to be cocky
about regulatory and to claim they know better through reg_notifier().

>> > I'd
>> > suggest a special regdomain named EVERYTHING. In the case the driver
>> or
>> > firmware enforces reg_rules, the core wireless reg_rules are safe to
>> be
>> > bypassed.
>>
>> You mean we add a flag to allow cfg80211 to ignore applying its
>> central regulatory definition to a wiphy? I disagree -- consider
>> outdated set of rules.
>
> It has nothing to do with ourdated rules. If a reg_rule is "wrong" in a
> device, it will still be wrong after the regulatory_hint() call.

If a hardware device has a built in channel 14 and a user in the US
buys this device and goes to the US he/she should disable this channel
to remain compliant. Under your current suggestion this is not dealt
with. That is what I mean by handling outdated rules.

> The current regulatory framework 100% trust the alpha2 or regdomain the
> driver provided. Thus it should also trust a hint from driver "bypass
> your regulatory check, I'll handle it myself".

Agreed 100%, and this is why we allowed a reg_notfier() callback so
bossy drivers can review the information and say "Let me review this..
I think I know better, so I'm in charge here".

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Mon, 2008-10-20 at 23:02 -0700, Luis R. Rodriguez wrote:
> The issue at hand, which started this 60-message thread, involves a
> built-in Intel single band 2 GHz card and an external dual band card.
> The issue is the dual band card's regulatory_hint() is ignored as the
> current infrastructure ignores secondary requests and the first one
> did not define a set of rules for 5 GHz as part of its
> regulatory_hint(). A resolution to this is to have crda called for the
> country the user is in. 

A suboptimal solution. We all know that. The kernel has to rely on some
help from iw to resolve a problem it has the ablility to resolve itself.

> The reason this solves the issue at and is
> hardware which is designed to not allow channels out of its EEPROM
> won't be enabled as these channels are not registered and channels
> which *should* be disabled based on the user's location *are*
> disabled. The 5 GHz channels on the dual band card which *should* be
> allowed are allowed. Additionally we do allow drivers to be cocky
> about regulatory and to claim they know better through reg_notifier().

Driver's reg_notifier should only disable a channel which the regulatory
framework marks as enabled. But not vice versa. Otherwise your below
case fails.

> If a hardware device has a built in channel 14 and a user in the US
> buys this device and goes to the US he/she should disable this channel
> to remain compliant. Under your current suggestion this is not dealt
> with. That is what I mean by handling outdated rules.

I don't see where it doesn't fit in my model. The driver hints
EVERYTHING after loading. Then the user overwrote it to "US". After
that, channel 14 is forbiddened by reg framework (although driver still
claims it supports it). This is what I said EVERYTHING should always be
overwritten by other regdomains.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Luis,

> >> The proper solution is to either add 5 GHz regulatory rules to your
> >> regulatory_hint() and/or rely on crda to enable the 5 GHz channels
> >> required for the country the user is in. It is true that you need
> >> manual intervention and the way I am trying to resolve that is not by
> >> changing the design of the current regulatory infrastructure, instead
> >> I want to add country selection support to say wpa_supplicant or
> >> Network Manager. That, IMO, is how to address the problem correctly. I
> >> also suggested a temporary solution which a distribution can use which
> >> requires absolutely no manual user intervention, that of determining
> >> the country through whatever means the distribution deems more fit and
> >> calling iw reg set on $COUNTRY.
> >
> > See Marcel's comment on supporting new kernels with old applications.
> 
> Old userspace still works, we can however require new userspace for
> new features. A compliant regulatory infrastructure is a feature.

how does an old userspace with a new kernel works? If we essentially
disable hardware by not having the userspace in place, then that is not
a solution. We have to be able to install a new or development kernel on
an old distro without having to install crda/iw or updating udev or
whatever.

Regards

Marcel

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Mon, Oct 20, 2008 at 11:07 PM, Marcel Holtmann
<holtmann@linux.intel.com> wrote:
>>
>> Old userspace still works, we can however require new userspace for
>> new features. A compliant regulatory infrastructure is a feature.
>
> how does an old userspace with a new kernel works?

It works by allowing by default only what is allowed in the world
regulatory domain.

> If we essentially
> disable hardware by not having the userspace in place, then that is not
> a solution.

We are not disabling hardware, we are adding a common regulatory
infrastructure to new cfg80211/mac80211 based drivers. We are not
touching the old drivers.

> We have to be able to install a new or development kernel on
> an old distro without having to install crda/iw or updating udev or
> whatever.

And you can use new kernels on old distributions with old wireless
drivers, however new mac80211 based drivers can reasonably require new
userspace utilities, and in this case we have a new userspace
requirement *only* when cfg80211/mac80211 based drivers do not provide
their own regutory_hint() or in the particular case outlined in this
thread. Additionally this new feature allows users who want to be more
compliant to do so by s specifying a country.

Udev was used based on your suggestion BTW, I was the one suggesting
to not use it because of the possibility of no udevd  present.

  Luis

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Luis,

> >> Old userspace still works, we can however require new userspace for
> >> new features. A compliant regulatory infrastructure is a feature.
> >
> > how does an old userspace with a new kernel works?
> 
> It works by allowing by default only what is allowed in the world
> regulatory domain.
> 
> > If we essentially
> > disable hardware by not having the userspace in place, then that is not
> > a solution.
> 
> We are not disabling hardware, we are adding a common regulatory
> infrastructure to new cfg80211/mac80211 based drivers. We are not
> touching the old drivers.

the old drivers will change over time and adapt the new infrastructure.
So this is not even a valid point.

> > We have to be able to install a new or development kernel on
> > an old distro without having to install crda/iw or updating udev or
> > whatever.
> 
> And you can use new kernels on old distributions with old wireless
> drivers, however new mac80211 based drivers can reasonably require new
> userspace utilities, and in this case we have a new userspace
> requirement *only* when cfg80211/mac80211 based drivers do not provide
> their own regutory_hint() or in the particular case outlined in this
> thread. Additionally this new feature allows users who want to be more
> compliant to do so by s specifying a country.

No we can't have a new (or updated) driver require new userspace. If you
install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
hardware work without installing an extra userspace component. And yes,
it works for the first card if it provides a regulatory hint, but it
should also work for the second card.

> Udev was used based on your suggestion BTW, I was the one suggesting
> to not use it because of the possibility of no udevd  present.

And in that case we have /sbin/hotplug. That is also not what I am
talking about here.

Regards

Marcel

Re: New Regulatory Domain Api.

[John W. Linville]

On Tue, Oct 21, 2008 at 08:51:30AM +0200, Marcel Holtmann wrote:

> > And you can use new kernels on old distributions with old wireless
> > drivers, however new mac80211 based drivers can reasonably require new
> > userspace utilities, and in this case we have a new userspace
> > requirement *only* when cfg80211/mac80211 based drivers do not provide
> > their own regutory_hint() or in the particular case outlined in this
> > thread. Additionally this new feature allows users who want to be more
> > compliant to do so by s specifying a country.
> 
> No we can't have a new (or updated) driver require new userspace. If you
> install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
> hardware work without installing an extra userspace component. And yes,
> it works for the first card if it provides a regulatory hint, but it
> should also work for the second card.

That is what WIRELESS_OLD_REGULATORY is for, no?

-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi John,

> > > And you can use new kernels on old distributions with old wireless
> > > drivers, however new mac80211 based drivers can reasonably require new
> > > userspace utilities, and in this case we have a new userspace
> > > requirement *only* when cfg80211/mac80211 based drivers do not provide
> > > their own regutory_hint() or in the particular case outlined in this
> > > thread. Additionally this new feature allows users who want to be more
> > > compliant to do so by s specifying a country.
> > 
> > No we can't have a new (or updated) driver require new userspace. If you
> > install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
> > hardware work without installing an extra userspace component. And yes,
> > it works for the first card if it provides a regulatory hint, but it
> > should also work for the second card.
> 
> That is what WIRELESS_OLD_REGULATORY is for, no?

but that would go away with 2.6.29 if it proceeds as planned.

Regards

Marcel

Re: New Regulatory Domain Api.

[John W. Linville]

On Tue, Oct 21, 2008 at 07:43:53PM +0200, Marcel Holtmann wrote:

> > > No we can't have a new (or updated) driver require new userspace. If you
> > > install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
> > > hardware work without installing an extra userspace component. And yes,
> > > it works for the first card if it provides a regulatory hint, but it
> > > should also work for the second card.
> > 
> > That is what WIRELESS_OLD_REGULATORY is for, no?
> 
> but that would go away with 2.6.29 if it proceeds as planned.

I don't see a huge maintenance burden to it the way it is implemented
now.  I know Luis will hate the idea, but perhaps we could just let
it linger indefinitely?

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Tue, Oct 21, 2008 at 10:48:00AM -0700, John W. Linville wrote:
> On Tue, Oct 21, 2008 at 07:43:53PM +0200, Marcel Holtmann wrote:
> 
> > > > No we can't have a new (or updated) driver require new userspace. If you
> > > > install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
> > > > hardware work without installing an extra userspace component. And yes,
> > > > it works for the first card if it provides a regulatory hint, but it
> > > > should also work for the second card.
> > >
> > > That is what WIRELESS_OLD_REGULATORY is for, no?
> >
> > but that would go away with 2.6.29 if it proceeds as planned.
> 
> I don't see a huge maintenance burden to it the way it is implemented
> now.  I know Luis will hate the idea, but perhaps we could just let
> it linger indefinitely?

This thread has about 65 messages on it, and no patches yet from Intel.
I rather we talk productively about trying to resolve it with actual
code like Johannes or I am. OLD_REGULATORY should still go IMO.

  Luis

Re: New Regulatory Domain Api.

[John W. Linville]

On Tue, Oct 21, 2008 at 04:02:03AM -0700, Luis R. Rodriguez wrote:
> On Tue, Oct 21, 2008 at 10:48:00AM -0700, John W. Linville wrote:
> > On Tue, Oct 21, 2008 at 07:43:53PM +0200, Marcel Holtmann wrote:
> > 
> > > > > No we can't have a new (or updated) driver require new userspace. If you
> > > > > install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
> > > > > hardware work without installing an extra userspace component. And yes,
> > > > > it works for the first card if it provides a regulatory hint, but it
> > > > > should also work for the second card.
> > > >
> > > > That is what WIRELESS_OLD_REGULATORY is for, no?
> > >
> > > but that would go away with 2.6.29 if it proceeds as planned.
> > 
> > I don't see a huge maintenance burden to it the way it is implemented
> > now.  I know Luis will hate the idea, but perhaps we could just let
> > it linger indefinitely?
> 
> This thread has about 65 messages on it, and no patches yet from Intel.
> I rather we talk productively about trying to resolve it with actual
> code like Johannes or I am. OLD_REGULATORY should still go IMO.

Ok, but it isn't clear to me that any patch will resolve the issue of
someone running a new kernel on an old userland unless OLD_REGULATORY
is enabled...?

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Tue, Oct 21, 2008 at 11:05:12AM -0700, John W. Linville wrote:
> On Tue, Oct 21, 2008 at 04:02:03AM -0700, Luis R. Rodriguez wrote:
> > On Tue, Oct 21, 2008 at 10:48:00AM -0700, John W. Linville wrote:
> > > On Tue, Oct 21, 2008 at 07:43:53PM +0200, Marcel Holtmann wrote:
> > >
> > > > > > No we can't have a new (or updated) driver require new userspace. If you
> > > > > > install a 2.6.30 kernel on an Ubuntu Hardy system, it should make the
> > > > > > hardware work without installing an extra userspace component. And yes,
> > > > > > it works for the first card if it provides a regulatory hint, but it
> > > > > > should also work for the second card.
> > > > >
> > > > > That is what WIRELESS_OLD_REGULATORY is for, no?
> > > >
> > > > but that would go away with 2.6.29 if it proceeds as planned.
> > >
> > > I don't see a huge maintenance burden to it the way it is implemented
> > > now.  I know Luis will hate the idea, but perhaps we could just let
> > > it linger indefinitely?
> >
> > This thread has about 65 messages on it, and no patches yet from Intel.
> > I rather we talk productively about trying to resolve it with actual
> > code like Johannes or I am. OLD_REGULATORY should still go IMO.
> 
> Ok, but it isn't clear to me that any patch will resolve the issue of
> someone running a new kernel on an old userland unless OLD_REGULATORY
> is enabled...?

IMHO its a worthy compromise to use only the world regulatory domain
by default it no crda is present for *new drivers*, yes its restrictive,
but that is the idea. It also pushes distributions to embrace crda, and
realisticaly who is not going to have it? What prevents old distributions
from using this? We're not breaking old drivers, we're enhacing new
drivers so the logic behind this argument is just flawed.

If it is deemed we don't care about this compromise for new drivers
that is a different story. A middle solution is to move a few common
db.txt regulatory domains staticaly into the kernel but of course this
is also biased towards those countries.

On my v2 approach to regulatory support I had added a whole bunch
of generic countries staticaly into the kernel and then people opposed
to that so we moved it now to userspace as they these can change dynamically
and now people complain? Make up your mind. This has been reviewed for
a while now and when a particular case comes up and people complain
without patches we consider it?

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Tue, 2008-10-21 at 04:02 -0700, Luis R. Rodriguez wrote:
> This thread has about 65 messages on it, and no patches yet from
> Intel.

Seems you jumped up when I offered a patch.
http://marc.info/?l=linux-wireless&m=122455333027226&w=2

> I rather we talk productively about trying to resolve it with actual
> code like Johannes or I am.

Good. See my patch on the other thread. The problem is also not the dual
bands support. The regulatory framework should support hardware to do
regulatory check and don't duplicate the work.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Wed, Oct 22, 2008 at 02:20:15AM -0700, Zhu Yi wrote:
> On Tue, 2008-10-21 at 04:02 -0700, Luis R. Rodriguez wrote:
> > This thread has about 65 messages on it, and no patches yet from
> > Intel.
> 
> Seems you jumped up when I offered a patch.
> http://marc.info/?l=linux-wireless&m=122455333027226&w=2

You complained about nobody willing to do foo, and yet I had already
provided a patch. That's what I "jumped" about.

> > I rather we talk productively about trying to resolve it with actual
> > code like Johannes or I am.
> 
> Good. See my patch on the other thread. The problem is also not the dual
> bands support. The regulatory framework should support hardware to do
> regulatory check and don't duplicate the work.

Huh? Hardware to do regulatory check? Now you really got me confused.

  Luis

Re: New Regulatory Domain Api.

[Zhu Yi]

On Wed, 2008-10-22 at 04:13 -0600, Luis R. Rodriguez wrote:
> You complained about nobody willing to do foo, and yet I had already
> provided a patch. That's what I "jumped" about.

You patch is wrong and nobody likes it (including yourself).

> > > I rather we talk productively about trying to resolve it with
> actual
> > > code like Johannes or I am.
> >
> > Good. See my patch on the other thread. The problem is also not the
> dual
> > bands support. The regulatory framework should support hardware to
> do
> > regulatory check and don't duplicate the work.
> 
> Huh? Hardware to do regulatory check? Now you really got me confused.

Please stop talking in this thread. Take a look at my patch or even try
it.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Tue, 2008-10-21 at 08:07 +0200, Marcel Holtmann wrote:
> 
> how does an old userspace with a new kernel works? If we essentially
> disable hardware by not having the userspace in place, then that is not
> a solution. We have to be able to install a new or development kernel on
> an old distro without having to install crda/iw or updating udev or
> whatever.

I'm not sure where you're coming from. We can always keep the built-in
option for EMBEDDED, but currently if you enable the "old static
regdoms" option there's no regression at all vs. current kernels.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Johannes,

> > how does an old userspace with a new kernel works? If we essentially
> > disable hardware by not having the userspace in place, then that is not
> > a solution. We have to be able to install a new or development kernel on
> > an old distro without having to install crda/iw or updating udev or
> > whatever.
> 
> I'm not sure where you're coming from. We can always keep the built-in
> option for EMBEDDED, but currently if you enable the "old static
> regdoms" option there's no regression at all vs. current kernels.

the kernel drivers will changes and thus will start using the new
regulatory infrastructure. And the old static one will go away. So when
we reach the point of a 2.6.29 or 2.6.30 kernel, we still have to make
it run and work as of now with the current userspace.

Regards

Marcel

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

On Mon, 2008-10-20 at 19:37 -0700, Luis R. Rodriguez wrote:

> As I mentioned in my previous e-mail, the real problem is what you are
> asking for changes the entire regulatory design from: "disable
> everything and enable only this" to "enable everything except for
> elements I don't define in the band I tell you to".

I don't think I agree.

>  There are many
> design flaws with this; an obvious problem to this is what is a band?
> In my patch I took the liberty to define that a frequency is part of a
> band if a rule was present within 2 GHz of itself. This works but it
> is trying to make a definition out of something that doesn't exist --
> its trying to solve the wrong problem. Since regulatory database is in
> KHz it is designed to allow us to grow regardless of band notions or
> associations. In the regulatory database we allow for 2 GHz, 5 GHz,
> etc KH  definitions for any country and this was designed to account
> for misinformation on drivers to help the user be more compliant. By
> changing the design to what you are suggesting you'd have to add a
> dummy rule for every frequency "band" if you really want to disable
> all other bands.

Yes, this is a problem, but then again it's fairly well-defined which is
2.4 and which is 5 GHz band, and it probably doesn't matter much at this
point. cfg80211 _has_ a notion of bands.

If we really wanted to have band-specific hints to let a driver say
"nay, sorry, I know nothing about 5 GHz" then we can I think do this,
subject to a few constraints:
 * first hint that contains a band wins this band
 * without any other information, a band that we know nothing about is
   disabled (just like the default state would be when we know nothing
   at all)

This ought to be possible, maybe by simply moving from

regulatory_hint(alpha2, structure)

to
regulatory_hint(alpha2)

regulatory_struct_hint(structure, bandflags)

where bandflags can be BIT(IEEE80211_BAND_2GHZ) or
BIT(IEEE80211_BAND_5GHZ). It would be fairly easy to keep track of that
information and build a common struct. No need to even bother looking at
the frequencies, when you have a 2GHZ hint and get a 5GHZ one you simply
add all the rules from the new hint. Yes, that could be abused to add
more 2GHz rules, but we can "police" that code. And it can only be
abused once because when the bit is already set we ignore the hint
anyway.

> The proper solution is to either add 5 GHz regulatory rules to your
> regulatory_hint() 

I strongly disagree with that. It's not correct in any way.

> and/or rely on crda to enable the 5 GHz channels
> required for the country the user is in. It is true that you need
> manual intervention and the way I am trying to resolve that is not by
> changing the design of the current regulatory infrastructure, instead
> I want to add country selection support to say wpa_supplicant or
> Network Manager. That, IMO, is how to address the problem correctly.

This is, of course, the solution for !EMBEDDED, but I don't think that's
really what we're talking about.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Tue, 2008-10-21 at 09:30 +0200, gwingerde@kpnplanet.nl wrote:

> 
> This would help me with rt2x00 as well, provided that the
> regulatory_hint(alpha2) function gets the bandflags as well.

No, that's not possible.

> rt2x00 EEPROM contains 2 SKU's, one for 2.4GHz band and one for 5GHz
> band, which don't necesarily have to agree with each other. Having
> these bandflags in here, allows me to hint these different SKU's to
> the regulatory framework, and handle the device indications correctly.

I thought you didn't have SKUs but actual country information. Why would
a card be manufactured for 2.4 GHz operation in the US and 5 GHz
operation in Chile or something? Anyway, given that those values are
apparently invalid most of the time anyway...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Johannes,

> >  There are many
> > design flaws with this; an obvious problem to this is what is a band?
> > In my patch I took the liberty to define that a frequency is part of a
> > band if a rule was present within 2 GHz of itself. This works but it
> > is trying to make a definition out of something that doesn't exist --
> > its trying to solve the wrong problem. Since regulatory database is in
> > KHz it is designed to allow us to grow regardless of band notions or
> > associations. In the regulatory database we allow for 2 GHz, 5 GHz,
> > etc KH  definitions for any country and this was designed to account
> > for misinformation on drivers to help the user be more compliant. By
> > changing the design to what you are suggesting you'd have to add a
> > dummy rule for every frequency "band" if you really want to disable
> > all other bands.
> 
> Yes, this is a problem, but then again it's fairly well-defined which is
> 2.4 and which is 5 GHz band, and it probably doesn't matter much at this
> point. cfg80211 _has_ a notion of bands.
> 
> If we really wanted to have band-specific hints to let a driver say
> "nay, sorry, I know nothing about 5 GHz" then we can I think do this,
> subject to a few constraints:
>  * first hint that contains a band wins this band
>  * without any other information, a band that we know nothing about is
>    disabled (just like the default state would be when we know nothing
>    at all)
> 
> This ought to be possible, maybe by simply moving from
> 
> regulatory_hint(alpha2, structure)
> 
> to
> regulatory_hint(alpha2)
> 
> regulatory_struct_hint(structure, bandflags)
> 
> where bandflags can be BIT(IEEE80211_BAND_2GHZ) or
> BIT(IEEE80211_BAND_5GHZ). It would be fairly easy to keep track of that
> information and build a common struct. No need to even bother looking at
> the frequencies, when you have a 2GHZ hint and get a 5GHZ one you simply
> add all the rules from the new hint. Yes, that could be abused to add
> more 2GHz rules, but we can "police" that code. And it can only be
> abused once because when the bit is already set we ignore the hint
> anyway.

I was more thinking about

	regulatory_band_hint(band, structure)

and then you have to call it twice if you have 2.4 GHz and 5 GHz support
with your hardware. But your solution also works.

> > The proper solution is to either add 5 GHz regulatory rules to your
> > regulatory_hint() 
> 
> I strongly disagree with that. It's not correct in any way.

Yeah. A driver for 2.4 GHz hardware should not even think about any
other channels :)

Regards

Marcel

Re: New Regulatory Domain Api.

[Luis R. Rodriguez]

On Tue, Oct 21, 2008 at 09:39:56AM -0700, Marcel Holtmann wrote:
> Yeah. A driver for 2.4 GHz hardware should not even think about any
> other channels :)

No, if you have a regulatory SKU on a 2 GHz band card you can declare
it, nothing should prevent it. In your case you do not because of
the card's design but it doesn't mean this is not possible.

  Luis

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

On Tue, 2008-10-21 at 18:39 +0200, Marcel Holtmann wrote:

> I was more thinking about
> 
> 	regulatory_band_hint(band, structure)
> 
> and then you have to call it twice if you have 2.4 GHz and 5 GHz support
> with your hardware. But your solution also works.

It's more efficient with flags. I've posted patches.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Wed, 2008-10-15 at 19:26 +0200, Marcel Holtmann wrote:

> I can see it useful when companies actually start building products with
> two or more cards in the system and have different cards for different
> tasks in it. So if you stick one card for one band and another one for
> the other band in there, then it would make sense to do a per-band
> regulatory hinting.

The question is whether they'd use Intel cards that have channel-based
eeprom information ;) If it's anything else, then it needs crda anyway.

> Not sure if this really ever ends up in a product. However I can see the
> case where you have a laptop with a BG-card and then attach an A-card to
> it do access an A-network and then it doesn't work. It would be nice to
> just have this working. Currently this would not work.

Well, it won't work if the user doesn't use crda/iw to set the proper
regulatory domain, doesn't set the "old regulatory" kernel config option
_and_ has Intel wireless :)

I don't think we have to worry too much about all these special use
cases, we really want distros to pick up crda and provide location
information to the kernel.

> Also the case when we unplug the first card, does the regulatory hint
> gets reset and the next card could bring in a new one? I can see use
> cases where you don't wanna use the built-in card, because it is just
> too limited.

Not currently, no, it wouldn't get reset I think. Should be doable
though, in the current framework.

Care to look at it and come up with patches, also for the printk thing
you wanted?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Zhu Yi]

On Tue, 2008-10-14 at 14:15 -0700, Johannes Berg wrote:
> Well, the thing is that the iwlwifi drivers pretend to know the
> regulatory domain

Well, the device *pretends* to know the regulatory domain for global.
But it does know the one for itself.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Fri, 2008-10-10 at 11:22 +0800, Zhu Yi wrote:

> Does below scenario an expected behaviour?
> 
> 0. A system with iwl3945 BG card and iwl4965 AGN card.
> 1. insmod iwl3945 -> regulatory_hint(, 99, rd) return 0;
> 2. insmod iwl4965 -> regulatory_hint(, 99, rd2) return -EALREADY;
> 3. iwl4965 has no A band support!

Yeah, I think this is expected, and the solution is to install crda and
iw and set the regulatory domain manually to whatever country you're in
rather than your cards SKU.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Zhu Yi]

On Tue, 2008-10-14 at 03:19 -0600, Johannes Berg wrote:
> On Fri, 2008-10-10 at 11:22 +0800, Zhu Yi wrote:
> 
> > Does below scenario an expected behaviour?
> > 
> > 0. A system with iwl3945 BG card and iwl4965 AGN card.
> > 1. insmod iwl3945 -> regulatory_hint(, 99, rd) return 0;
> > 2. insmod iwl4965 -> regulatory_hint(, 99, rd2) return -EALREADY;
> > 3. iwl4965 has no A band support!
> 
> Yeah, I think this is expected, and the solution is to install crda and
> iw and set the regulatory domain manually to whatever country you're in
> rather than your cards SKU.

Let's use the solution at this time. Just a notion that the regdomain in
kernel doesn't sort out very well in some circumstance without user
intervention.

Thanks,
-yi

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Yi,

> > > Does below scenario an expected behaviour?
> > > 
> > > 0. A system with iwl3945 BG card and iwl4965 AGN card.
> > > 1. insmod iwl3945 -> regulatory_hint(, 99, rd) return 0;
> > > 2. insmod iwl4965 -> regulatory_hint(, 99, rd2) return -EALREADY;
> > > 3. iwl4965 has no A band support!
> > 
> > Yeah, I think this is expected, and the solution is to install crda and
> > iw and set the regulatory domain manually to whatever country you're in
> > rather than your cards SKU.
> 
> Let's use the solution at this time. Just a notion that the regdomain in
> kernel doesn't sort out very well in some circumstance without user
> intervention.

that is what Johannes and I agreed on. We do have to make this work when
no userspace is present or is limited due to the design of the embedded
system in question. In that case the first regulatory hint wins.

Johannes, we could just add a kernel warning if we have mismatched
regulatory hints and userspace was not involved until now. So at least
it shows up in dmesg and can be debugged easily if needed.

Regards

Marcel

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Wed, 2008-10-15 at 17:50 +0200, Marcel Holtmann wrote:

> > Let's use the solution at this time. Just a notion that the regdomain in
> > kernel doesn't sort out very well in some circumstance without user
> > intervention.
> 
> that is what Johannes and I agreed on. We do have to make this work when
> no userspace is present or is limited due to the design of the embedded
> system in question. In that case the first regulatory hint wins.

Yeah, we have to let one of them win, unless we want to add the
complexity with per-band hints as discussed in the other part of the
thread.

> Johannes, we could just add a kernel warning if we have mismatched
> regulatory hints and userspace was not involved until now. So at least
> it shows up in dmesg and can be debugged easily if needed.

We can probably do that, yeah, though we'd have to get the conditions
right to avoid showing that whenever you plug in a USB device to a
laptop that already has wireless built-in.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Marcel Holtmann]

Hi Johannes,

> > > Let's use the solution at this time. Just a notion that the regdomain in
> > > kernel doesn't sort out very well in some circumstance without user
> > > intervention.
> > 
> > that is what Johannes and I agreed on. We do have to make this work when
> > no userspace is present or is limited due to the design of the embedded
> > system in question. In that case the first regulatory hint wins.
> 
> Yeah, we have to let one of them win, unless we want to add the
> complexity with per-band hints as discussed in the other part of the
> thread.
> 
> > Johannes, we could just add a kernel warning if we have mismatched
> > regulatory hints and userspace was not involved until now. So at least
> > it shows up in dmesg and can be debugged easily if needed.
> 
> We can probably do that, yeah, though we'd have to get the conditions
> right to avoid showing that whenever you plug in a USB device to a
> laptop that already has wireless built-in.

I think it is fine to do so. Since plugging in an USB wireless card is
expected to work and if we limit it, lets give the user at least some
way to figure out why it is limited.

Especially when your internal one is a BG-card and you external one is
an A-card only (or combo). And you put it in to just access an
A-network.

Regards

Marcel

Re: New Regulatory Domain Api.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Wed, 2008-10-15 at 19:29 +0200, Marcel Holtmann wrote:

> I think it is fine to do so. Since plugging in an USB wireless card is
> expected to work and if we limit it, lets give the user at least some
> way to figure out why it is limited.
> 
> Especially when your internal one is a BG-card and you external one is
> an A-card only (or combo). And you put it in to just access an
> A-network.

Good point. I've never really considered that since we only added this
feature after understanding you at OLS :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: New Regulatory Domain Api.

[Joerg Pommnitz]

Hello all,
I always had some problems with the idea that the same regulatory settings apply to all cards in a system. This is certainly not true for the systems we ship: our system has two WLAN cards where one card is attached to an amplifier under special regulatory permission. This special permission is very strict and limits the use of the card to certain channels that are even outside the range normally used for 802.11. 

For CRDA to be useful to us we would need a way to limit one card to the common requirements for WLAN in the current environment and the other card to the special rules we got from our regulator.

-- 
Regards
       Joerg