Forgot to Cc: [email protected] for this patch during its submission,
this is needed on 2.6.28 as otherwise there is an issue for Intel
cards which get their channels 5 GHz disabled if OLD_REG is set to no
(this is not the default) or the channels 12-14 are disabled if
OLD_REG is set to yes (default) set to no and the ieee80211_module
parameter is not used. The later issue is resolved by userspace as
well but we cannot yet expect 2.6.28 kernels to have enough userspace
interfaces to set the regulatory domain just yet. This is why OLD_REG
is still set to default with 2.6.28.
14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
Author: Luis R. Rodriguez <[email protected]>
Date: Wed Nov 12 14:22:03 2008 -0800
cfg80211: add support for custom firmware regulatory solutions
This adds API to cfg80211 to allow wireless drivers to inform
us if their firmware can handle regulatory considerations *and*
they cannot map these regulatory domains to an ISO / IEC 3166
alpha2. In these cases we skip the first regulatory hint instead
of expecting the driver to build their own regulatory structure,
providing us with an alpha2, or using the reg_notifier().
Signed-off-by: Luis R. Rodriguez <[email protected]>
Acked-by: Zhu Yi <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
On Thu, Mar 5, 2009 at 2:49 PM, Tim Gardner <[email protected]>=
wrote:
> Luis R. Rodriguez wrote:
>> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre
>> <[email protected]> wrote:
>>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote:
>>>> Forgot to Cc: [email protected] for this patch during its submissi=
on,
>>>> this is needed on 2.6.28 as otherwise there is an issue for Intel
>>>> cards which get their channels 5 GHz disabled if OLD_REG is set to=
no
>>>> (this is not the default) or the channels 12-14 are disabled if
>>>> OLD_REG is set to yes (default) set to no and the ieee80211_module
>>>> parameter is not used. The later issue is resolved by userspace as
>>>> well but we cannot yet expect 2.6.28 kernels to have enough usersp=
ace
>>>> interfaces to set the regulatory domain just yet. This is why OLD_=
REG
>>>> is still set to default with 2.6.28.
>>>>
>>>> 14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
>>>> Author: Luis R. Rodriguez <[email protected]>
>>>> Date: =C2=A0 Wed Nov 12 14:22:03 2008 -0800
>>>>
>>>> =C2=A0 =C2=A0cfg80211: add support for custom firmware regulatory =
solutions
>>>>
>>>> =C2=A0 =C2=A0This adds API to cfg80211 to allow wireless drivers t=
o inform
>>>> =C2=A0 =C2=A0us if their firmware can handle regulatory considerat=
ions *and*
>>>> =C2=A0 =C2=A0they cannot map these regulatory domains to an ISO / =
IEC 3166
>>>> =C2=A0 =C2=A0alpha2. In these cases we skip the first regulatory h=
int instead
>>>> =C2=A0 =C2=A0of expecting the driver to build their own regulatory=
structure,
>>>> =C2=A0 =C2=A0providing us with an alpha2, or using the reg_notifie=
r().
>>>>
>>>> =C2=A0 =C2=A0Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.=
com>
>>>> =C2=A0 =C2=A0Acked-by: Zhu Yi <[email protected]>
>>>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <[email protected]=
om>
>>> Could you please also add commit
>>> ea4a82dceec7b5782b1259079c8de508d0afe33a? This is the commit that
>>> enables the Intel cards to take advantage of the parameter introduc=
ed in
>>> previous commit.
>>>
>>> commit ea4a82dceec7b5782b1259079c8de508d0afe33a
>>> Author: Luis R. Rodriguez <[email protected]>
>>> Date: =C2=A0 Wed Nov 12 14:22:04 2008 -0800
>>>
>>> =C2=A0 =C2=A0iwlwifi: enable custom fw regulatory solution
>>>
>>> =C2=A0 =C2=A0This enables the custom firmware regulatory solution o=
ption
>>> =C2=A0 =C2=A0on iwlwifi drivers. These devices are uncapable of map=
ping their
>>> =C2=A0 =C2=A0EEPROM regulatory domain to a specific ISO / IEC alpha=
2.
>>> =C2=A0 =C2=A0Although the new 11n devices (>=3D iwl 5000) have only
>>> =C2=A0 =C2=A03 regultaory SKUs -- MOW, ABG (no N) and BG -- the old=
er
>>> =C2=A0 =C2=A0devices (3945 and 4965) have a more complex SKU arrang=
ement
>>> =C2=A0 =C2=A0and therefore its not practical to move this to the dr=
iver.
>>>
>>> =C2=A0 =C2=A0Signed-off-by: Luis R. Rodriguez <[email protected]=
om>
>>> =C2=A0 =C2=A0Acked-by: Zhu Yi <[email protected]>
>>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <[email protected]=
m>
>>
>> Doh yes that would be required or it would make this pointless.
>>
>> =C2=A0 Luis
>>
>
> Looks like it requires a preparatory commit:
>
> commit f3b407fba52e1b86ca286ee7c218a4fb00bd29e0
> Author: Johannes Berg <[email protected]>
> Date: =C2=A0 Tue Oct 21 09:57:41 2008 +0200
>
> =C2=A0 =C2=A0wireless: remove cfg80211_reg_mutex
>
> =C2=A0 =C2=A0This mutex is wrong, we use cfg80211_drv_mutex (which sh=
ould
> =C2=A0 =C2=A0possibly be renamed to just cfg80211_mutex) everywhere e=
xcept
> =C2=A0 =C2=A0in one place, fix that and get rid of the extra mutex.
>
> =C2=A0 =C2=A0Also get rid of a spurious regulatory_requests list defi=
nition.
>
> =C2=A0 =C2=A0Signed-off-by: Johannes Berg <[email protected]>
> =C2=A0 =C2=A0Signed-off-by: John W. Linville <[email protected]>
Ah crap. This may be too much for stable. Did you get a hang without
it? Or is it not applying cleanly? If the later then a port may be
required.
Luis
On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre
<[email protected]> wrote:
> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote:
>> Forgot to Cc: [email protected] for this patch during its submission=
,
>> this is needed on 2.6.28 as otherwise there is an issue for Intel
>> cards which get their channels 5 GHz disabled if OLD_REG is set to n=
o
>> (this is not the default) or the channels 12-14 are disabled if
>> OLD_REG is set to yes (default) set to no and the ieee80211_module
>> parameter is not used. The later issue is resolved by userspace as
>> well but we cannot yet expect 2.6.28 kernels to have enough userspac=
e
>> interfaces to set the regulatory domain just yet. This is why OLD_RE=
G
>> is still set to default with 2.6.28.
>>
>> 14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
>> Author: Luis R. Rodriguez <[email protected]>
>> Date: =C2=A0 Wed Nov 12 14:22:03 2008 -0800
>>
>> =C2=A0 =C2=A0cfg80211: add support for custom firmware regulatory so=
lutions
>>
>> =C2=A0 =C2=A0This adds API to cfg80211 to allow wireless drivers to =
inform
>> =C2=A0 =C2=A0us if their firmware can handle regulatory consideratio=
ns *and*
>> =C2=A0 =C2=A0they cannot map these regulatory domains to an ISO / IE=
C 3166
>> =C2=A0 =C2=A0alpha2. In these cases we skip the first regulatory hin=
t instead
>> =C2=A0 =C2=A0of expecting the driver to build their own regulatory s=
tructure,
>> =C2=A0 =C2=A0providing us with an alpha2, or using the reg_notifier(=
).
>>
>> =C2=A0 =C2=A0Signed-off-by: Luis R. Rodriguez <[email protected]=
m>
>> =C2=A0 =C2=A0Acked-by: Zhu Yi <[email protected]>
>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <[email protected]=
>
>
> Could you please also add commit
> ea4a82dceec7b5782b1259079c8de508d0afe33a? This is the commit that
> enables the Intel cards to take advantage of the parameter introduced=
in
> previous commit.
>
> commit ea4a82dceec7b5782b1259079c8de508d0afe33a
> Author: Luis R. Rodriguez <[email protected]>
> Date: =C2=A0 Wed Nov 12 14:22:04 2008 -0800
>
> =C2=A0 =C2=A0iwlwifi: enable custom fw regulatory solution
>
> =C2=A0 =C2=A0This enables the custom firmware regulatory solution opt=
ion
> =C2=A0 =C2=A0on iwlwifi drivers. These devices are uncapable of mappi=
ng their
> =C2=A0 =C2=A0EEPROM regulatory domain to a specific ISO / IEC alpha2.
> =C2=A0 =C2=A0Although the new 11n devices (>=3D iwl 5000) have only
> =C2=A0 =C2=A03 regultaory SKUs -- MOW, ABG (no N) and BG -- the older
> =C2=A0 =C2=A0devices (3945 and 4965) have a more complex SKU arrangem=
ent
> =C2=A0 =C2=A0and therefore its not practical to move this to the driv=
er.
>
> =C2=A0 =C2=A0Signed-off-by: Luis R. Rodriguez <[email protected]=
>
> =C2=A0 =C2=A0Acked-by: Zhu Yi <[email protected]>
> =C2=A0 =C2=A0Signed-off-by: John W. Linville <[email protected]>
Doh yes that would be required or it would make this pointless.
Luis
On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote:
> Forgot to Cc: [email protected] for this patch during its submission,
> this is needed on 2.6.28 as otherwise there is an issue for Intel
> cards which get their channels 5 GHz disabled if OLD_REG is set to no
> (this is not the default) or the channels 12-14 are disabled if
> OLD_REG is set to yes (default) set to no and the ieee80211_module
> parameter is not used. The later issue is resolved by userspace as
> well but we cannot yet expect 2.6.28 kernels to have enough userspace
> interfaces to set the regulatory domain just yet. This is why OLD_REG
> is still set to default with 2.6.28.
>
> 14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
> Author: Luis R. Rodriguez <[email protected]>
> Date: Wed Nov 12 14:22:03 2008 -0800
>
> cfg80211: add support for custom firmware regulatory solutions
>
> This adds API to cfg80211 to allow wireless drivers to inform
> us if their firmware can handle regulatory considerations *and*
> they cannot map these regulatory domains to an ISO / IEC 3166
> alpha2. In these cases we skip the first regulatory hint instead
> of expecting the driver to build their own regulatory structure,
> providing us with an alpha2, or using the reg_notifier().
>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
> Acked-by: Zhu Yi <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
Could you please also add commit
ea4a82dceec7b5782b1259079c8de508d0afe33a? This is the commit that
enables the Intel cards to take advantage of the parameter introduced in
previous commit.
commit ea4a82dceec7b5782b1259079c8de508d0afe33a
Author: Luis R. Rodriguez <[email protected]>
Date: Wed Nov 12 14:22:04 2008 -0800
iwlwifi: enable custom fw regulatory solution
This enables the custom firmware regulatory solution option
on iwlwifi drivers. These devices are uncapable of mapping their
EEPROM regulatory domain to a specific ISO / IEC alpha2.
Although the new 11n devices (>= iwl 5000) have only
3 regultaory SKUs -- MOW, ABG (no N) and BG -- the older
devices (3945 and 4965) have a more complex SKU arrangement
and therefore its not practical to move this to the driver.
Signed-off-by: Luis R. Rodriguez <[email protected]>
Acked-by: Zhu Yi <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
On Thu, Mar 5, 2009 at 4:26 PM, Tim Gardner <[email protected]>=
wrote:
> Luis R. Rodriguez wrote:
>> On Thu, Mar 5, 2009 at 2:49 PM, Tim Gardner <[email protected]=
om> wrote:
>>> Luis R. Rodriguez wrote:
>>>> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre
>>>> <[email protected]> wrote:
>>>>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote:
>>>>>> Forgot to Cc: [email protected] for this patch during its submis=
sion,
>>>>>> this is needed on 2.6.28 as otherwise there is an issue for Inte=
l
>>>>>> cards which get their channels 5 GHz disabled if OLD_REG is set =
to no
>>>>>> (this is not the default) or the channels 12-14 are disabled if
>>>>>> OLD_REG is set to yes (default) set to no and the ieee80211_modu=
le
>>>>>> parameter is not used. The later issue is resolved by userspace =
as
>>>>>> well but we cannot yet expect 2.6.28 kernels to have enough user=
space
>>>>>> interfaces to set the regulatory domain just yet. This is why OL=
D_REG
>>>>>> is still set to default with 2.6.28.
>>>>>>
>>>>>> 14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
>>>>>> Author: Luis R. Rodriguez <[email protected]>
>>>>>> Date: =C2=A0 Wed Nov 12 14:22:03 2008 -0800
>>>>>>
>>>>>> =C2=A0 =C2=A0cfg80211: add support for custom firmware regulator=
y solutions
>>>>>>
>>>>>> =C2=A0 =C2=A0This adds API to cfg80211 to allow wireless drivers=
to inform
>>>>>> =C2=A0 =C2=A0us if their firmware can handle regulatory consider=
ations *and*
>>>>>> =C2=A0 =C2=A0they cannot map these regulatory domains to an ISO =
/ IEC 3166
>>>>>> =C2=A0 =C2=A0alpha2. In these cases we skip the first regulatory=
hint instead
>>>>>> =C2=A0 =C2=A0of expecting the driver to build their own regulato=
ry structure,
>>>>>> =C2=A0 =C2=A0providing us with an alpha2, or using the reg_notif=
ier().
>>>>>>
>>>>>> =C2=A0 =C2=A0Signed-off-by: Luis R. Rodriguez <lrodriguez@athero=
s.com>
>>>>>> =C2=A0 =C2=A0Acked-by: Zhu Yi <[email protected]>
>>>>>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver=
=2Ecom>
>>>>> Could you please also add commit
>>>>> ea4a82dceec7b5782b1259079c8de508d0afe33a? This is the commit that
>>>>> enables the Intel cards to take advantage of the parameter introd=
uced in
>>>>> previous commit.
>>>>>
>>>>> commit ea4a82dceec7b5782b1259079c8de508d0afe33a
>>>>> Author: Luis R. Rodriguez <[email protected]>
>>>>> Date: =C2=A0 Wed Nov 12 14:22:04 2008 -0800
>>>>>
>>>>> =C2=A0 =C2=A0iwlwifi: enable custom fw regulatory solution
>>>>>
>>>>> =C2=A0 =C2=A0This enables the custom firmware regulatory solution=
option
>>>>> =C2=A0 =C2=A0on iwlwifi drivers. These devices are uncapable of m=
apping their
>>>>> =C2=A0 =C2=A0EEPROM regulatory domain to a specific ISO / IEC alp=
ha2.
>>>>> =C2=A0 =C2=A0Although the new 11n devices (>=3D iwl 5000) have on=
ly
>>>>> =C2=A0 =C2=A03 regultaory SKUs -- MOW, ABG (no N) and BG -- the o=
lder
>>>>> =C2=A0 =C2=A0devices (3945 and 4965) have a more complex SKU arra=
ngement
>>>>> =C2=A0 =C2=A0and therefore its not practical to move this to the =
driver.
>>>>>
>>>>> =C2=A0 =C2=A0Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros=
=2Ecom>
>>>>> =C2=A0 =C2=A0Acked-by: Zhu Yi <[email protected]>
>>>>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.=
com>
>>>> Doh yes that would be required or it would make this pointless.
>>>>
>>>> =C2=A0 Luis
>>>>
>>> Looks like it requires a preparatory commit:
>>>
>>> commit f3b407fba52e1b86ca286ee7c218a4fb00bd29e0
>>> Author: Johannes Berg <[email protected]>
>>> Date: =C2=A0 Tue Oct 21 09:57:41 2008 +0200
>>>
>>> =C2=A0 =C2=A0wireless: remove cfg80211_reg_mutex
>>>
>>> =C2=A0 =C2=A0This mutex is wrong, we use cfg80211_drv_mutex (which =
should
>>> =C2=A0 =C2=A0possibly be renamed to just cfg80211_mutex) everywhere=
except
>>> =C2=A0 =C2=A0in one place, fix that and get rid of the extra mutex.
>>>
>>> =C2=A0 =C2=A0Also get rid of a spurious regulatory_requests list de=
finition.
>>>
>>> =C2=A0 =C2=A0Signed-off-by: Johannes Berg <[email protected]=
t>
>>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <[email protected]=
m>
>>
>> Ah crap. This may be too much for stable. Did you get a hang without
>> it? Or is it not applying cleanly? If the later then a port may be
>> required.
>>
>> =C2=A0 Luis
>
> I spoke too soon. Its doesn't compile even with
> f3b407fba52e1b86ca286ee7c218a4fb00bd29e0 applied.
>
> What is the downside of just turning OLD_REG back on for 2.6.28?
You default to the "US" regulatory domain so channels 12-14 will not
be available by default. This is also why we offloaded regulatory crap
to userspace in the first place, so you won't have to upgrade your
kernel based on reg changes or fixes.
I'll send a patch to enable passive scan on channels 12-14 for the
world regulatory domain. That and the 5 GHz patch should at least let
you see channels 12-14 with a fix from userspace. This can also go
into 28 for the world regulatory domain and since it would be fixing
an issue maybe we should consider it.
Thoughts John?
Luis
On Fri, Mar 6, 2009 at 6:36 AM, John W. Linville <[email protected]> wrote:
> On Thu, Mar 05, 2009 at 04:33:37PM -0800, Luis R. Rodriguez wrote:
>> On Thu, Mar 5, 2009 at 4:26 PM, Tim Gardner <[email protected]> wrote:
>
>> > What is the downside of just turning OLD_REG back on for 2.6.28?
>>
>> You default to the "US" regulatory domain so channels 12-14 will not
>> be available by default. This is also why we offloaded regulatory crap
>> to userspace in the first place, so you won't have to upgrade your
>> kernel based on reg changes or fixes.
>>
>> I'll send a patch to enable passive scan on channels 12-14 for the
>> world regulatory domain. That and the 5 GHz patch should at least let
>> you see channels 12-14 with a fix from userspace. This can also go
>> into 28 for the world regulatory domain and since it would be fixing
>> an issue maybe we should consider it.
>>
>> Thoughts John?
>
> Honestly I don't think it is worth swizzling -stable for this.
OK then Tim -- best is to upgrade the userspace wireless-regdb once
the patches get merged.
Luis
Luis R. Rodriguez wrote:
> On Thu, Mar 5, 2009 at 2:49 PM, Tim Gardner <[email protected]> wrote:
>> Luis R. Rodriguez wrote:
>>> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre
>>> <[email protected]> wrote:
>>>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote:
>>>>> Forgot to Cc: [email protected] for this patch during its submission,
>>>>> this is needed on 2.6.28 as otherwise there is an issue for Intel
>>>>> cards which get their channels 5 GHz disabled if OLD_REG is set to no
>>>>> (this is not the default) or the channels 12-14 are disabled if
>>>>> OLD_REG is set to yes (default) set to no and the ieee80211_module
>>>>> parameter is not used. The later issue is resolved by userspace as
>>>>> well but we cannot yet expect 2.6.28 kernels to have enough userspace
>>>>> interfaces to set the regulatory domain just yet. This is why OLD_REG
>>>>> is still set to default with 2.6.28.
>>>>>
>>>>> 14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
>>>>> Author: Luis R. Rodriguez <[email protected]>
>>>>> Date: Wed Nov 12 14:22:03 2008 -0800
>>>>>
>>>>> cfg80211: add support for custom firmware regulatory solutions
>>>>>
>>>>> This adds API to cfg80211 to allow wireless drivers to inform
>>>>> us if their firmware can handle regulatory considerations *and*
>>>>> they cannot map these regulatory domains to an ISO / IEC 3166
>>>>> alpha2. In these cases we skip the first regulatory hint instead
>>>>> of expecting the driver to build their own regulatory structure,
>>>>> providing us with an alpha2, or using the reg_notifier().
>>>>>
>>>>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>>>>> Acked-by: Zhu Yi <[email protected]>
>>>>> Signed-off-by: John W. Linville <[email protected]>
>>>> Could you please also add commit
>>>> ea4a82dceec7b5782b1259079c8de508d0afe33a? This is the commit that
>>>> enables the Intel cards to take advantage of the parameter introduced in
>>>> previous commit.
>>>>
>>>> commit ea4a82dceec7b5782b1259079c8de508d0afe33a
>>>> Author: Luis R. Rodriguez <[email protected]>
>>>> Date: Wed Nov 12 14:22:04 2008 -0800
>>>>
>>>> iwlwifi: enable custom fw regulatory solution
>>>>
>>>> This enables the custom firmware regulatory solution option
>>>> on iwlwifi drivers. These devices are uncapable of mapping their
>>>> EEPROM regulatory domain to a specific ISO / IEC alpha2.
>>>> Although the new 11n devices (>= iwl 5000) have only
>>>> 3 regultaory SKUs -- MOW, ABG (no N) and BG -- the older
>>>> devices (3945 and 4965) have a more complex SKU arrangement
>>>> and therefore its not practical to move this to the driver.
>>>>
>>>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>>>> Acked-by: Zhu Yi <[email protected]>
>>>> Signed-off-by: John W. Linville <[email protected]>
>>> Doh yes that would be required or it would make this pointless.
>>>
>>> Luis
>>>
>> Looks like it requires a preparatory commit:
>>
>> commit f3b407fba52e1b86ca286ee7c218a4fb00bd29e0
>> Author: Johannes Berg <[email protected]>
>> Date: Tue Oct 21 09:57:41 2008 +0200
>>
>> wireless: remove cfg80211_reg_mutex
>>
>> This mutex is wrong, we use cfg80211_drv_mutex (which should
>> possibly be renamed to just cfg80211_mutex) everywhere except
>> in one place, fix that and get rid of the extra mutex.
>>
>> Also get rid of a spurious regulatory_requests list definition.
>>
>> Signed-off-by: Johannes Berg <[email protected]>
>> Signed-off-by: John W. Linville <[email protected]>
>
> Ah crap. This may be too much for stable. Did you get a hang without
> it? Or is it not applying cleanly? If the later then a port may be
> required.
>
> Luis
I spoke too soon. Its doesn't compile even with
f3b407fba52e1b86ca286ee7c218a4fb00bd29e0 applied.
What is the downside of just turning OLD_REG back on for 2.6.28?
rtg
--
Tim Gardner [email protected]
On Thu, Mar 05, 2009 at 04:33:37PM -0800, Luis R. Rodriguez wrote:
> On Thu, Mar 5, 2009 at 4:26 PM, Tim Gardner <[email protected]> wrote:
> > What is the downside of just turning OLD_REG back on for 2.6.28?
>
> You default to the "US" regulatory domain so channels 12-14 will not
> be available by default. This is also why we offloaded regulatory crap
> to userspace in the first place, so you won't have to upgrade your
> kernel based on reg changes or fixes.
>
> I'll send a patch to enable passive scan on channels 12-14 for the
> world regulatory domain. That and the 5 GHz patch should at least let
> you see channels 12-14 with a fix from userspace. This can also go
> into 28 for the world regulatory domain and since it would be fixing
> an issue maybe we should consider it.
>
> Thoughts John?
Honestly I don't think it is worth swizzling -stable for this.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Luis R. Rodriguez wrote:
> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre
> <[email protected]> wrote:
>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote:
>>> Forgot to Cc: [email protected] for this patch during its submission,
>>> this is needed on 2.6.28 as otherwise there is an issue for Intel
>>> cards which get their channels 5 GHz disabled if OLD_REG is set to no
>>> (this is not the default) or the channels 12-14 are disabled if
>>> OLD_REG is set to yes (default) set to no and the ieee80211_module
>>> parameter is not used. The later issue is resolved by userspace as
>>> well but we cannot yet expect 2.6.28 kernels to have enough userspace
>>> interfaces to set the regulatory domain just yet. This is why OLD_REG
>>> is still set to default with 2.6.28.
>>>
>>> 14b9815af3f4fe0e171ee0c4325c31d2a2c1570b
>>> Author: Luis R. Rodriguez <[email protected]>
>>> Date: Wed Nov 12 14:22:03 2008 -0800
>>>
>>> cfg80211: add support for custom firmware regulatory solutions
>>>
>>> This adds API to cfg80211 to allow wireless drivers to inform
>>> us if their firmware can handle regulatory considerations *and*
>>> they cannot map these regulatory domains to an ISO / IEC 3166
>>> alpha2. In these cases we skip the first regulatory hint instead
>>> of expecting the driver to build their own regulatory structure,
>>> providing us with an alpha2, or using the reg_notifier().
>>>
>>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>>> Acked-by: Zhu Yi <[email protected]>
>>> Signed-off-by: John W. Linville <[email protected]>
>> Could you please also add commit
>> ea4a82dceec7b5782b1259079c8de508d0afe33a? This is the commit that
>> enables the Intel cards to take advantage of the parameter introduced in
>> previous commit.
>>
>> commit ea4a82dceec7b5782b1259079c8de508d0afe33a
>> Author: Luis R. Rodriguez <[email protected]>
>> Date: Wed Nov 12 14:22:04 2008 -0800
>>
>> iwlwifi: enable custom fw regulatory solution
>>
>> This enables the custom firmware regulatory solution option
>> on iwlwifi drivers. These devices are uncapable of mapping their
>> EEPROM regulatory domain to a specific ISO / IEC alpha2.
>> Although the new 11n devices (>= iwl 5000) have only
>> 3 regultaory SKUs -- MOW, ABG (no N) and BG -- the older
>> devices (3945 and 4965) have a more complex SKU arrangement
>> and therefore its not practical to move this to the driver.
>>
>> Signed-off-by: Luis R. Rodriguez <[email protected]>
>> Acked-by: Zhu Yi <[email protected]>
>> Signed-off-by: John W. Linville <[email protected]>
>
> Doh yes that would be required or it would make this pointless.
>
> Luis
>
Looks like it requires a preparatory commit:
commit f3b407fba52e1b86ca286ee7c218a4fb00bd29e0
Author: Johannes Berg <[email protected]>
Date: Tue Oct 21 09:57:41 2008 +0200
wireless: remove cfg80211_reg_mutex
This mutex is wrong, we use cfg80211_drv_mutex (which should
possibly be renamed to just cfg80211_mutex) everywhere except
in one place, fix that and get rid of the extra mutex.
Also get rid of a spurious regulatory_requests list definition.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
--
Tim Gardner [email protected]