* Please apply to stable: cfg80211: add support for custom firmware regulatory solutions @ 2009-03-04 21:35 Luis R. Rodriguez 2009-03-05 17:54 ` reinette chatre 0 siblings, 1 reply; 9+ messages in thread From: Luis R. Rodriguez @ 2009-03-04 21:35 UTC (permalink / raw) To: stable@kernel.org Cc: John W. Linville, reinette chatre, wireless, Tim Gardner Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> 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 <lrodriguez@atheros.com> Acked-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-04 21:35 Please apply to stable: cfg80211: add support for custom firmware regulatory solutions Luis R. Rodriguez @ 2009-03-05 17:54 ` reinette chatre 2009-03-05 19:24 ` Luis R. Rodriguez 0 siblings, 1 reply; 9+ messages in thread From: reinette chatre @ 2009-03-05 17:54 UTC (permalink / raw) To: Luis R. Rodriguez Cc: stable@kernel.org, John W. Linville, wireless, Tim Gardner On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote: > Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> > 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 <lrodriguez@atheros.com> > Acked-by: Zhu Yi <yi.zhu@intel.com> > Signed-off-by: John W. Linville <linville@tuxdriver.com> 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 <lrodriguez@atheros.com> 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 <lrodriguez@atheros.com> Acked-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-05 17:54 ` reinette chatre @ 2009-03-05 19:24 ` Luis R. Rodriguez 2009-03-05 22:49 ` Tim Gardner 0 siblings, 1 reply; 9+ messages in thread From: Luis R. Rodriguez @ 2009-03-05 19:24 UTC (permalink / raw) To: reinette chatre Cc: stable@kernel.org, John W. Linville, wireless, Tim Gardner On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre <reinette.chatre@intel.com> wrote: > On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote: >> Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> >> 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 <lrodriguez@atheros.co= m> >> =C2=A0 =C2=A0Acked-by: Zhu Yi <yi.zhu@intel.com> >> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.com= > > > 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 <lrodriguez@atheros.com> > 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 <lrodriguez@atheros.com= > > =C2=A0 =C2=A0Acked-by: Zhu Yi <yi.zhu@intel.com> > =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.com> Doh yes that would be required or it would make this pointless. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-05 19:24 ` Luis R. Rodriguez @ 2009-03-05 22:49 ` Tim Gardner 2009-03-05 23:13 ` Luis R. Rodriguez 0 siblings, 1 reply; 9+ messages in thread From: Tim Gardner @ 2009-03-05 22:49 UTC (permalink / raw) To: Luis R. Rodriguez Cc: reinette chatre, stable@kernel.org, John W. Linville, wireless Luis R. Rodriguez wrote: > On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre > <reinette.chatre@intel.com> wrote: >> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote: >>> Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> >>> 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 <lrodriguez@atheros.com> >>> Acked-by: Zhu Yi <yi.zhu@intel.com> >>> Signed-off-by: John W. Linville <linville@tuxdriver.com> >> 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 <lrodriguez@atheros.com> >> 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 <lrodriguez@atheros.com> >> Acked-by: Zhu Yi <yi.zhu@intel.com> >> Signed-off-by: John W. Linville <linville@tuxdriver.com> > > 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 <johannes@sipsolutions.net> 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 <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> -- Tim Gardner tim.gardner@canonical.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-05 22:49 ` Tim Gardner @ 2009-03-05 23:13 ` Luis R. Rodriguez 2009-03-06 0:26 ` Tim Gardner 0 siblings, 1 reply; 9+ messages in thread From: Luis R. Rodriguez @ 2009-03-05 23:13 UTC (permalink / raw) To: tim.gardner Cc: reinette chatre, stable@kernel.org, John W. Linville, wireless On Thu, Mar 5, 2009 at 2:49 PM, Tim Gardner <tim.gardner@canonical.com>= wrote: > Luis R. Rodriguez wrote: >> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre >> <reinette.chatre@intel.com> wrote: >>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote: >>>> Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> >>>> 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 <yi.zhu@intel.com> >>>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.c= 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 <lrodriguez@atheros.com> >>> 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 <lrodriguez@atheros.c= om> >>> =C2=A0 =C2=A0Acked-by: Zhu Yi <yi.zhu@intel.com> >>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.co= 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 <johannes@sipsolutions.net> > 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 <johannes@sipsolutions.net> > =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-05 23:13 ` Luis R. Rodriguez @ 2009-03-06 0:26 ` Tim Gardner 2009-03-06 0:33 ` Luis R. Rodriguez 0 siblings, 1 reply; 9+ messages in thread From: Tim Gardner @ 2009-03-06 0:26 UTC (permalink / raw) To: Luis R. Rodriguez Cc: reinette chatre, stable@kernel.org, John W. Linville, wireless Luis R. Rodriguez wrote: > On Thu, Mar 5, 2009 at 2:49 PM, Tim Gardner <tim.gardner@canonical.com> wrote: >> Luis R. Rodriguez wrote: >>> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre >>> <reinette.chatre@intel.com> wrote: >>>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote: >>>>> Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> >>>>> 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 <lrodriguez@atheros.com> >>>>> Acked-by: Zhu Yi <yi.zhu@intel.com> >>>>> Signed-off-by: John W. Linville <linville@tuxdriver.com> >>>> 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 <lrodriguez@atheros.com> >>>> 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 <lrodriguez@atheros.com> >>>> Acked-by: Zhu Yi <yi.zhu@intel.com> >>>> Signed-off-by: John W. Linville <linville@tuxdriver.com> >>> 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 <johannes@sipsolutions.net> >> 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 <johannes@sipsolutions.net> >> Signed-off-by: John W. Linville <linville@tuxdriver.com> > > 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 tim.gardner@canonical.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-06 0:26 ` Tim Gardner @ 2009-03-06 0:33 ` Luis R. Rodriguez 2009-03-06 14:36 ` John W. Linville 0 siblings, 1 reply; 9+ messages in thread From: Luis R. Rodriguez @ 2009-03-06 0:33 UTC (permalink / raw) To: tim.gardner Cc: reinette chatre, stable@kernel.org, John W. Linville, wireless On Thu, Mar 5, 2009 at 4:26 PM, Tim Gardner <tim.gardner@canonical.com>= wrote: > Luis R. Rodriguez wrote: >> On Thu, Mar 5, 2009 at 2:49 PM, Tim Gardner <tim.gardner@canonical.c= om> wrote: >>> Luis R. Rodriguez wrote: >>>> On Thu, Mar 5, 2009 at 9:54 AM, reinette chatre >>>> <reinette.chatre@intel.com> wrote: >>>>> On Wed, 2009-03-04 at 13:35 -0800, Luis R. Rodriguez wrote: >>>>>> Forgot to Cc: stable@kernel.org 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 <lrodriguez@atheros.com> >>>>>> 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 <yi.zhu@intel.com> >>>>>> =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 <lrodriguez@atheros.com> >>>>> 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 <yi.zhu@intel.com> >>>>> =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 <johannes@sipsolutions.net> >>> 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 <johannes@sipsolutions.ne= t> >>> =C2=A0 =C2=A0Signed-off-by: John W. Linville <linville@tuxdriver.co= 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-06 0:33 ` Luis R. Rodriguez @ 2009-03-06 14:36 ` John W. Linville 2009-03-06 22:00 ` Luis R. Rodriguez 0 siblings, 1 reply; 9+ messages in thread From: John W. Linville @ 2009-03-06 14:36 UTC (permalink / raw) To: Luis R. Rodriguez Cc: tim.gardner, reinette chatre, stable@kernel.org, wireless 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 <tim.gardner@canonical.com> 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 linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Please apply to stable: cfg80211: add support for custom firmware regulatory solutions 2009-03-06 14:36 ` John W. Linville @ 2009-03-06 22:00 ` Luis R. Rodriguez 0 siblings, 0 replies; 9+ messages in thread From: Luis R. Rodriguez @ 2009-03-06 22:00 UTC (permalink / raw) To: John W. Linville Cc: tim.gardner, reinette chatre, stable@kernel.org, wireless On Fri, Mar 6, 2009 at 6:36 AM, John W. Linville <linville@tuxdriver.com> 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 <tim.gardner@canonical.com> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-03-06 22:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-03-04 21:35 Please apply to stable: cfg80211: add support for custom firmware regulatory solutions Luis R. Rodriguez 2009-03-05 17:54 ` reinette chatre 2009-03-05 19:24 ` Luis R. Rodriguez 2009-03-05 22:49 ` Tim Gardner 2009-03-05 23:13 ` Luis R. Rodriguez 2009-03-06 0:26 ` Tim Gardner 2009-03-06 0:33 ` Luis R. Rodriguez 2009-03-06 14:36 ` John W. Linville 2009-03-06 22:00 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).