As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
calling freq_reg_info() without holding cfg80211_lock. Currently
freq_reg_info() is the only way for a wireless driver to tell whether
OFDM is allowed on the current channel, but cfg80211_lock is outside the
scope of the wireless drivers.
Since other regulatory restrictions are communicated in the channel
definition, it makes sense to do the same for OFDM. These patches add a
new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
indicated OFDM operation is prohibited. brcmsmac is modifified to use
this flag instead of consuming the regulatory data directly.
Thanks,
Seth
Seth Forshee (2):
cfg80211: add channel flag to restrict OFDM
brcmsmac: use channel flags to restrict OFDM
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 5 +----
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 3 ++-
include/net/cfg80211.h | 2 ++
net/wireless/reg.c | 2 ++
4 files changed, 7 insertions(+), 5 deletions(-)
On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
> As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
> calling freq_reg_info() without holding cfg80211_lock. Currently
> freq_reg_info() is the only way for a wireless driver to tell whether
> OFDM is allowed on the current channel, but cfg80211_lock is outside the
> scope of the wireless drivers.
>
> Since other regulatory restrictions are communicated in the channel
> definition, it makes sense to do the same for OFDM. These patches add a
> new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
> indicated OFDM operation is prohibited. brcmsmac is modifified to use
> this flag instead of consuming the regulatory data directly.
>
> Thanks,
> Seth
>
>
> Seth Forshee (2):
> cfg80211: add channel flag to restrict OFDM
> brcmsmac: use channel flags to restrict OFDM
I would love to test these, but at the moment I can't. Oddly, the very
same machine I hit the problem with originally is no longer presenting
any devices on the bcma bus. The driver is loaded, brcmsmac is loaded,
but neither output the devices that showed up in my original email.
This is with both the kernel I originally reported the problem with, and
other kernels. Nothing shows up for the BCM4313 in lspci either.
I did power it off and then back on today after I hit the original
problem, but I'd expect the hardware in the box to still show up on a
power on... Is there some specific module load order, or something
else I can do to try and get the device to show up?
I did build a kernel with your patches applied, so at least I know they
build. If I can get this machine to probe the chip again, I'll be happy
to test.
At the moment, I'm just very confused and slightly afraid it's going to
just refuse to work at all.
josh
On 08/01/2012 10:58 PM, Seth Forshee wrote:
> As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
> calling freq_reg_info() without holding cfg80211_lock. Currently
> freq_reg_info() is the only way for a wireless driver to tell whether
> OFDM is allowed on the current channel, but cfg80211_lock is outside the
> scope of the wireless drivers.
>
> Since other regulatory restrictions are communicated in the channel
> definition, it makes sense to do the same for OFDM. These patches add a
> new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
> indicated OFDM operation is prohibited. brcmsmac is modifified to use
> this flag instead of consuming the regulatory data directly.
>
> Thanks,
> Seth
I will try the patches on a lockdep-enabled kernel.
Gr. AvS
brcmsmac cannot call freq_reg_info() during channel changes as it does
not hold cfg80211_lock, and as a result it generates a lockdep warning.
freq_reg_info() is being used to determine whether OFDM is allowed on
the current channel, so we can avoid the errant call by using the new
IEEE80211_CHAN_NO_OFDM for this purpose instead.
Reported-by: Josh Boyer <[email protected]>
Signed-off-by: Seth Forshee <[email protected]>
---
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 5 +----
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 3 ++-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/channel.c b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
index 9a4c63f..7ed7d75 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/channel.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
@@ -382,9 +382,7 @@ brcms_c_channel_set_chanspec(struct brcms_cm_info *wlc_cm, u16 chanspec,
{
struct brcms_c_info *wlc = wlc_cm->wlc;
struct ieee80211_channel *ch = wlc->pub->ieee_hw->conf.channel;
- const struct ieee80211_reg_rule *reg_rule;
struct txpwr_limits txpwr;
- int ret;
brcms_c_channel_reg_limits(wlc_cm, chanspec, &txpwr);
@@ -393,8 +391,7 @@ brcms_c_channel_set_chanspec(struct brcms_cm_info *wlc_cm, u16 chanspec,
);
/* set or restore gmode as required by regulatory */
- ret = freq_reg_info(wlc->wiphy, ch->center_freq, 0, ®_rule);
- if (!ret && (reg_rule->flags & NL80211_RRF_NO_OFDM))
+ if (ch->flags & IEEE80211_CHAN_NO_OFDM)
brcms_c_set_gmode(wlc, GMODE_LEGACY_B, false);
else
brcms_c_set_gmode(wlc, wlc->protection->gmode_user, false);
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
index 9e79d47..192ad5c 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
@@ -121,7 +121,8 @@ static struct ieee80211_channel brcms_2ghz_chantable[] = {
IEEE80211_CHAN_NO_HT40PLUS),
CHAN2GHZ(14, 2484,
IEEE80211_CHAN_PASSIVE_SCAN | IEEE80211_CHAN_NO_IBSS |
- IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS)
+ IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS |
+ IEEE80211_CHAN_NO_OFDM)
};
static struct ieee80211_channel brcms_5ghz_nphy_chantable[] = {
--
1.7.9.5
On 08/01/2012 10:58 PM, Seth Forshee wrote:
> Seth Forshee (2):
> cfg80211: add channel flag to restrict OFDM
> brcmsmac: use channel flags to restrict OFDM
>
> drivers/net/wireless/brcm80211/brcmsmac/channel.c | 5 +----
> .../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 3 ++-
> include/net/cfg80211.h | 2 ++
> net/wireless/reg.c | 2 ++
> 4 files changed, 7 insertions(+), 5 deletions(-)
Does the trick. No more warnings on lockdep kernel. For both you can add
Tested-by: Arend van Spriel <[email protected]>
Gr. AvS
On Wed, Aug 01, 2012 at 08:53:20PM -0500, Seth Forshee wrote:
> On Wed, Aug 01, 2012 at 08:23:54PM -0400, Josh Boyer wrote:
> > On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
> > > As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
> > > calling freq_reg_info() without holding cfg80211_lock. Currently
> > > freq_reg_info() is the only way for a wireless driver to tell whether
> > > OFDM is allowed on the current channel, but cfg80211_lock is outside the
> > > scope of the wireless drivers.
> > >
> > > Since other regulatory restrictions are communicated in the channel
> > > definition, it makes sense to do the same for OFDM. These patches add a
> > > new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
> > > indicated OFDM operation is prohibited. brcmsmac is modifified to use
> > > this flag instead of consuming the regulatory data directly.
> > >
> > > Thanks,
> > > Seth
> > >
> > >
> > > Seth Forshee (2):
> > > cfg80211: add channel flag to restrict OFDM
> > > brcmsmac: use channel flags to restrict OFDM
> >
> > I would love to test these, but at the moment I can't. Oddly, the very
> > same machine I hit the problem with originally is no longer presenting
> > any devices on the bcma bus. The driver is loaded, brcmsmac is loaded,
> > but neither output the devices that showed up in my original email.
> > This is with both the kernel I originally reported the problem with, and
> > other kernels. Nothing shows up for the BCM4313 in lspci either.
> >
> > I did power it off and then back on today after I hit the original
> > problem, but I'd expect the hardware in the box to still show up on a
> > power on... Is there some specific module load order, or something
> > else I can do to try and get the device to show up?
> >
> > I did build a kernel with your patches applied, so at least I know they
> > build. If I can get this machine to probe the chip again, I'll be happy
> > to test.
> >
> > At the moment, I'm just very confused and slightly afraid it's going to
> > just refuse to work at all.
>
> Do you have 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819? That fixed a bug
> that had caused some very odd behavior, like changing PCI device ids.
> Recovering after booting a bad kernel required a cold boot to a kernel
> with the fix; a warm reboot wasn't enough.
The kernel I'm testing should have that commit in it. I'll try a cold
boot to it to make sure.
josh
On Wed, Aug 01, 2012 at 03:58:42PM -0500, Seth Forshee wrote:
> Currently the only way for wireless drivers to tell whether or not OFDM
> is allowed on the current channel is to check the regulatory
> information. However, this requires hodling cfg80211_mutex, which is not
> visible to the drivers.
>
> Other regulatory restrictions are provided as flags in the channel
> definition, so let's do similarly with OFDM. This patch adds a new flag,
> IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
> allowed. This flag is set on any channels for which regulatory indicates
> that OFDM is prohibited.
>
> Signed-off-by: Seth Forshee <[email protected]>
Acked-by: Luis R. Rodriguez <[email protected]>
Luis
On Thu, Aug 02, 2012 at 10:45:29AM -0400, Josh Boyer wrote:
> I'll go test Seth's patches now. I hate computers.
And with Seth's patches, I no longer see the cfg80211 warning
backtrace. It's likely too late, but feel free to add:
Tested-by: Josh Boyer <[email protected]>
Thanks again everyone.
josh
On Thu, Aug 02, 2012 at 08:02:30AM -0400, Josh Boyer wrote:
> On Wed, Aug 01, 2012 at 08:53:20PM -0500, Seth Forshee wrote:
> > On Wed, Aug 01, 2012 at 08:23:54PM -0400, Josh Boyer wrote:
> > > On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
> > > > As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
> > > > calling freq_reg_info() without holding cfg80211_lock. Currently
> > > > freq_reg_info() is the only way for a wireless driver to tell whether
> > > > OFDM is allowed on the current channel, but cfg80211_lock is outside the
> > > > scope of the wireless drivers.
> > > >
> > > > Since other regulatory restrictions are communicated in the channel
> > > > definition, it makes sense to do the same for OFDM. These patches add a
> > > > new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
> > > > indicated OFDM operation is prohibited. brcmsmac is modifified to use
> > > > this flag instead of consuming the regulatory data directly.
> > > >
> > > > Thanks,
> > > > Seth
> > > >
> > > >
> > > > Seth Forshee (2):
> > > > cfg80211: add channel flag to restrict OFDM
> > > > brcmsmac: use channel flags to restrict OFDM
> > >
> > > I would love to test these, but at the moment I can't. Oddly, the very
> > > same machine I hit the problem with originally is no longer presenting
> > > any devices on the bcma bus. The driver is loaded, brcmsmac is loaded,
> > > but neither output the devices that showed up in my original email.
> > > This is with both the kernel I originally reported the problem with, and
> > > other kernels. Nothing shows up for the BCM4313 in lspci either.
> > >
> > > I did power it off and then back on today after I hit the original
> > > problem, but I'd expect the hardware in the box to still show up on a
> > > power on... Is there some specific module load order, or something
> > > else I can do to try and get the device to show up?
> > >
> > > I did build a kernel with your patches applied, so at least I know they
> > > build. If I can get this machine to probe the chip again, I'll be happy
> > > to test.
> > >
> > > At the moment, I'm just very confused and slightly afraid it's going to
> > > just refuse to work at all.
> >
> > Do you have 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819? That fixed a bug
> > that had caused some very odd behavior, like changing PCI device ids.
> > Recovering after booting a bad kernel required a cold boot to a kernel
> > with the fix; a warm reboot wasn't enough.
>
> The kernel I'm testing should have that commit in it. I'll try a cold
> boot to it to make sure.
That didn't help. I've tried multiple module load orderings without
anything being shown on the bcma bus. The modules all load, but no
devices are created. It's as if the hardware was removed or something.
Puzzling.
josh
On Thu, Aug 02, 2012 at 08:24:20AM +0200, Johannes Berg wrote:
> On Wed, 2012-08-01 at 15:58 -0500, Seth Forshee wrote:
> > Currently the only way for wireless drivers to tell whether or not OFDM
> > is allowed on the current channel is to check the regulatory
> > information. However, this requires hodling cfg80211_mutex, which is not
> > visible to the drivers.
> >
> > Other regulatory restrictions are provided as flags in the channel
> > definition, so let's do similarly with OFDM. This patch adds a new flag,
> > IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
> > allowed. This flag is set on any channels for which regulatory indicates
> > that OFDM is prohibited.
>
> Looks good, this needs to go into 3.6, right?
Yes, it should go into 3.6.
On Wed, 2012-08-01 at 15:58 -0500, Seth Forshee wrote:
> Currently the only way for wireless drivers to tell whether or not OFDM
> is allowed on the current channel is to check the regulatory
> information. However, this requires hodling cfg80211_mutex, which is not
> visible to the drivers.
>
> Other regulatory restrictions are provided as flags in the channel
> definition, so let's do similarly with OFDM. This patch adds a new flag,
> IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
> allowed. This flag is set on any channels for which regulatory indicates
> that OFDM is prohibited.
Looks good, this needs to go into 3.6, right?
johannes
On Thu, Aug 02, 2012 at 04:00:42PM +0200, Arend van Spriel wrote:
> On 08/02/2012 03:45 PM, Josh Boyer wrote:
> > #
> > # Broadcom specific AMBA
> > #
> > CONFIG_BCMA=m
> > CONFIG_BCMA_BLOCKIO=y
> > CONFIG_BCMA_HOST_PCI_POSSIBLE=y
> > CONFIG_BCMA_HOST_PCI=y
> > CONFIG_BCMA_DRIVER_GMAC_CMN=y
> > # CONFIG_BCMA_DEBUG is not set
>
> As you indicated not seeing anything on the bcma bus (in kernel log, you
> mean?) I was wondering about BCMA_HOST_PCI flag, but that looks fine.
> Not sure why you have BCMA_DRIVER_GMAC_CMN enabled. Grabbing straws.
>
> I actually had a similar behaviour and noticed a PCI bridge port was
> missing. Do you see that also with lspci?
Hm. I can't recall the full lspci output before this problem showed up,
but I do have dmesg output from before and now. Comparing them, I see:
[ 0.639235] pci_bus 0000:02: busn_res: [bus 02] is inserted under [bus 00-ff]
[ 0.639284] pci 0000:02:00.0: [14e4:4727] type 00 class 0x028000
[ 0.639321] pci 0000:02:00.0: reg 10: [mem 0xfe500000-0xfe503fff 64bit]
[ 0.639550] pci 0000:02:00.0: supports D1 D2
[ 0.639551] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
[ 0.641078] pci 0000:00:1c.0: PCI bridge to [bus 02]
[ 0.641091] pci 0000:00:1c.0: bridge window [mem 0xfe500000-0xfe5fffff]
from before, and:
[ 0.636241] pci_bus 0000:02: busn_res: [bus 02] is inserted under [bus 00-ff]
[ 0.636244] pci 0000:00:1c.0: PCI bridge to [bus 02]
[ 0.636342] pci_bus 0000:03: busn_res: [bus 03] is inserted under [bus 00-ff]
now. So it seems 1434:4727 is missing now. How very very odd.
<5 minutes later>
OK, so I physically unplugged the machine from the wall and let it sit
for 5 minutes. When I plugged it back in, that PCI bridge port magically
reappeared. I guess that's good news. Thanks for suffering through
with me.
I'll go test Seth's patches now. I hate computers.
josh
On 08/02/2012 02:51 PM, Josh Boyer wrote:
> That didn't help. I've tried multiple module load orderings without
> anything being shown on the bcma bus. The modules all load, but no
> devices are created. It's as if the hardware was removed or something.
> Puzzling.
>
> josh
Can you share the kerne configuration?
Gr. AvS
On Thu, 2012-08-02 at 08:04 -0500, Seth Forshee wrote:
> On Thu, Aug 02, 2012 at 08:24:20AM +0200, Johannes Berg wrote:
> > On Wed, 2012-08-01 at 15:58 -0500, Seth Forshee wrote:
> > > Currently the only way for wireless drivers to tell whether or not OFDM
> > > is allowed on the current channel is to check the regulatory
> > > information. However, this requires hodling cfg80211_mutex, which is not
> > > visible to the drivers.
> > >
> > > Other regulatory restrictions are provided as flags in the channel
> > > definition, so let's do similarly with OFDM. This patch adds a new flag,
> > > IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
> > > allowed. This flag is set on any channels for which regulatory indicates
> > > that OFDM is prohibited.
> >
> > Looks good, this needs to go into 3.6, right?
>
> Yes, it should go into 3.6.
Alright, applied.
johannes
On Thu, Aug 02, 2012 at 03:44:10PM +0200, Hauke Mehrtens wrote:
> On 08/02/2012 02:51 PM, Josh Boyer wrote:
> > On Thu, Aug 02, 2012 at 08:02:30AM -0400, Josh Boyer wrote:
> >> On Wed, Aug 01, 2012 at 08:53:20PM -0500, Seth Forshee wrote:
> >>> On Wed, Aug 01, 2012 at 08:23:54PM -0400, Josh Boyer wrote:
> >>>> On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
> >>>>> As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
> >>>>> calling freq_reg_info() without holding cfg80211_lock. Currently
> >>>>> freq_reg_info() is the only way for a wireless driver to tell whether
> >>>>> OFDM is allowed on the current channel, but cfg80211_lock is outside the
> >>>>> scope of the wireless drivers.
> >>>>>
> >>>>> Since other regulatory restrictions are communicated in the channel
> >>>>> definition, it makes sense to do the same for OFDM. These patches add a
> >>>>> new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
> >>>>> indicated OFDM operation is prohibited. brcmsmac is modifified to use
> >>>>> this flag instead of consuming the regulatory data directly.
> >>>>>
> >>>>> Thanks,
> >>>>> Seth
> >>>>>
> >>>>>
> >>>>> Seth Forshee (2):
> >>>>> cfg80211: add channel flag to restrict OFDM
> >>>>> brcmsmac: use channel flags to restrict OFDM
> >>>>
> >>>> I would love to test these, but at the moment I can't. Oddly, the very
> >>>> same machine I hit the problem with originally is no longer presenting
> >>>> any devices on the bcma bus. The driver is loaded, brcmsmac is loaded,
> >>>> but neither output the devices that showed up in my original email.
> >>>> This is with both the kernel I originally reported the problem with, and
> >>>> other kernels. Nothing shows up for the BCM4313 in lspci either.
> >>>>
> >>>> I did power it off and then back on today after I hit the original
> >>>> problem, but I'd expect the hardware in the box to still show up on a
> >>>> power on... Is there some specific module load order, or something
> >>>> else I can do to try and get the device to show up?
> >>>>
> >>>> I did build a kernel with your patches applied, so at least I know they
> >>>> build. If I can get this machine to probe the chip again, I'll be happy
> >>>> to test.
> >>>>
> >>>> At the moment, I'm just very confused and slightly afraid it's going to
> >>>> just refuse to work at all.
> >>>
> >>> Do you have 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819? That fixed a bug
> >>> that had caused some very odd behavior, like changing PCI device ids.
> >>> Recovering after booting a bad kernel required a cold boot to a kernel
> >>> with the fix; a warm reboot wasn't enough.
> >>
> >> The kernel I'm testing should have that commit in it. I'll try a cold
> >> boot to it to make sure.
> >
> > That didn't help. I've tried multiple module load orderings without
> > anything being shown on the bcma bus. The modules all load, but no
> > devices are created. It's as if the hardware was removed or something.
> > Puzzling.
> >
> > josh
>
> Are you sure you have the commit
> 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819 in your tree, this commit is
> *not* in wireless-testing it is just in wireless-next-2.6 and linus tree
> for 3.6-rc1. If lspci does not show the device, it has nothing to do
> with some modules being loaded or not, at least when non of then is
> controlling your PCIe bus. It could also be that a cold boot is not
> enough to reset your device, what device are you using the BCM4313 in?
Yes, I'm sure. I'm booting essentially Linus' latest git tree. Now,
during a bisect I was doing yesterday it's quite possible I booted
something that did not have that commit, but the last 3 kernels I have
tried definitely had it and all were from cold boots. The newest kernel
as of this morning is at 1a9b4993b70fb1884716902774dc9025b457760d.
The BCM4313 is in a Dell XPS 8300 box.
josh
Currently the only way for wireless drivers to tell whether or not OFDM
is allowed on the current channel is to check the regulatory
information. However, this requires hodling cfg80211_mutex, which is not
visible to the drivers.
Other regulatory restrictions are provided as flags in the channel
definition, so let's do similarly with OFDM. This patch adds a new flag,
IEEE80211_CHAN_NO_OFDM, to tell drivers that OFDM on a channel is not
allowed. This flag is set on any channels for which regulatory indicates
that OFDM is prohibited.
Signed-off-by: Seth Forshee <[email protected]>
---
include/net/cfg80211.h | 2 ++
net/wireless/reg.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 493fa0c..3d254e1 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -96,6 +96,7 @@ enum ieee80211_band {
* is not permitted.
* @IEEE80211_CHAN_NO_HT40MINUS: extension channel below this channel
* is not permitted.
+ * @IEEE80211_CHAN_NO_OFDM: OFDM is not allowed on this channel.
*/
enum ieee80211_channel_flags {
IEEE80211_CHAN_DISABLED = 1<<0,
@@ -104,6 +105,7 @@ enum ieee80211_channel_flags {
IEEE80211_CHAN_RADAR = 1<<3,
IEEE80211_CHAN_NO_HT40PLUS = 1<<4,
IEEE80211_CHAN_NO_HT40MINUS = 1<<5,
+ IEEE80211_CHAN_NO_OFDM = 1<<6,
};
#define IEEE80211_CHAN_NO_HT40 \
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 2303ee7..0f3a8a1 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -680,6 +680,8 @@ static u32 map_regdom_flags(u32 rd_flags)
channel_flags |= IEEE80211_CHAN_NO_IBSS;
if (rd_flags & NL80211_RRF_DFS)
channel_flags |= IEEE80211_CHAN_RADAR;
+ if (rd_flags & NL80211_RRF_NO_OFDM)
+ channel_flags |= IEEE80211_CHAN_NO_OFDM;
return channel_flags;
}
--
1.7.9.5
On Wed, Aug 01, 2012 at 08:23:54PM -0400, Josh Boyer wrote:
> On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
> > As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
> > calling freq_reg_info() without holding cfg80211_lock. Currently
> > freq_reg_info() is the only way for a wireless driver to tell whether
> > OFDM is allowed on the current channel, but cfg80211_lock is outside the
> > scope of the wireless drivers.
> >
> > Since other regulatory restrictions are communicated in the channel
> > definition, it makes sense to do the same for OFDM. These patches add a
> > new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
> > indicated OFDM operation is prohibited. brcmsmac is modifified to use
> > this flag instead of consuming the regulatory data directly.
> >
> > Thanks,
> > Seth
> >
> >
> > Seth Forshee (2):
> > cfg80211: add channel flag to restrict OFDM
> > brcmsmac: use channel flags to restrict OFDM
>
> I would love to test these, but at the moment I can't. Oddly, the very
> same machine I hit the problem with originally is no longer presenting
> any devices on the bcma bus. The driver is loaded, brcmsmac is loaded,
> but neither output the devices that showed up in my original email.
> This is with both the kernel I originally reported the problem with, and
> other kernels. Nothing shows up for the BCM4313 in lspci either.
>
> I did power it off and then back on today after I hit the original
> problem, but I'd expect the hardware in the box to still show up on a
> power on... Is there some specific module load order, or something
> else I can do to try and get the device to show up?
>
> I did build a kernel with your patches applied, so at least I know they
> build. If I can get this machine to probe the chip again, I'll be happy
> to test.
>
> At the moment, I'm just very confused and slightly afraid it's going to
> just refuse to work at all.
Do you have 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819? That fixed a bug
that had caused some very odd behavior, like changing PCI device ids.
Recovering after booting a bad kernel required a cold boot to a kernel
with the fix; a warm reboot wasn't enough.
Seth
On Thu, Aug 02, 2012 at 03:42:07PM +0200, Arend van Spriel wrote:
> On 08/02/2012 02:51 PM, Josh Boyer wrote:
> > That didn't help. I've tried multiple module load orderings without
> > anything being shown on the bcma bus. The modules all load, but no
> > devices are created. It's as if the hardware was removed or something.
> > Puzzling.
> >
> > josh
>
> Can you share the kerne configuration?
Attached. That is from the kernel that has Seth's patches. The kernel
that showed the original problem has an identical config.
josh
On 08/02/2012 03:45 PM, Josh Boyer wrote:
> #
> # Broadcom specific AMBA
> #
> CONFIG_BCMA=m
> CONFIG_BCMA_BLOCKIO=y
> CONFIG_BCMA_HOST_PCI_POSSIBLE=y
> CONFIG_BCMA_HOST_PCI=y
> CONFIG_BCMA_DRIVER_GMAC_CMN=y
> # CONFIG_BCMA_DEBUG is not set
As you indicated not seeing anything on the bcma bus (in kernel log, you
mean?) I was wondering about BCMA_HOST_PCI flag, but that looks fine.
Not sure why you have BCMA_DRIVER_GMAC_CMN enabled. Grabbing straws.
I actually had a similar behaviour and noticed a PCI bridge port was
missing. Do you see that also with lspci?
Gr. AvS
On 08/02/2012 02:51 PM, Josh Boyer wrote:
> On Thu, Aug 02, 2012 at 08:02:30AM -0400, Josh Boyer wrote:
>> On Wed, Aug 01, 2012 at 08:53:20PM -0500, Seth Forshee wrote:
>>> On Wed, Aug 01, 2012 at 08:23:54PM -0400, Josh Boyer wrote:
>>>> On Wed, Aug 01, 2012 at 03:58:41PM -0500, Seth Forshee wrote:
>>>>> As reported by Josh Boyer, brcmsmac is producing lockdep warnings by
>>>>> calling freq_reg_info() without holding cfg80211_lock. Currently
>>>>> freq_reg_info() is the only way for a wireless driver to tell whether
>>>>> OFDM is allowed on the current channel, but cfg80211_lock is outside the
>>>>> scope of the wireless drivers.
>>>>>
>>>>> Since other regulatory restrictions are communicated in the channel
>>>>> definition, it makes sense to do the same for OFDM. These patches add a
>>>>> new flag, IEEE80211_CHAN_NO_OFDM, which is set by regulatory to
>>>>> indicated OFDM operation is prohibited. brcmsmac is modifified to use
>>>>> this flag instead of consuming the regulatory data directly.
>>>>>
>>>>> Thanks,
>>>>> Seth
>>>>>
>>>>>
>>>>> Seth Forshee (2):
>>>>> cfg80211: add channel flag to restrict OFDM
>>>>> brcmsmac: use channel flags to restrict OFDM
>>>>
>>>> I would love to test these, but at the moment I can't. Oddly, the very
>>>> same machine I hit the problem with originally is no longer presenting
>>>> any devices on the bcma bus. The driver is loaded, brcmsmac is loaded,
>>>> but neither output the devices that showed up in my original email.
>>>> This is with both the kernel I originally reported the problem with, and
>>>> other kernels. Nothing shows up for the BCM4313 in lspci either.
>>>>
>>>> I did power it off and then back on today after I hit the original
>>>> problem, but I'd expect the hardware in the box to still show up on a
>>>> power on... Is there some specific module load order, or something
>>>> else I can do to try and get the device to show up?
>>>>
>>>> I did build a kernel with your patches applied, so at least I know they
>>>> build. If I can get this machine to probe the chip again, I'll be happy
>>>> to test.
>>>>
>>>> At the moment, I'm just very confused and slightly afraid it's going to
>>>> just refuse to work at all.
>>>
>>> Do you have 1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819? That fixed a bug
>>> that had caused some very odd behavior, like changing PCI device ids.
>>> Recovering after booting a bad kernel required a cold boot to a kernel
>>> with the fix; a warm reboot wasn't enough.
>>
>> The kernel I'm testing should have that commit in it. I'll try a cold
>> boot to it to make sure.
>
> That didn't help. I've tried multiple module load orderings without
> anything being shown on the bcma bus. The modules all load, but no
> devices are created. It's as if the hardware was removed or something.
> Puzzling.
>
> josh
Are you sure you have the commit
1f03bf06e4e3b8ed9a69e7fc4cdb1be4c6c6c819 in your tree, this commit is
*not* in wireless-testing it is just in wireless-next-2.6 and linus tree
for 3.6-rc1. If lspci does not show the device, it has nothing to do
with some modules being loaded or not, at least when non of then is
controlling your PCIe bus. It could also be that a cold boot is not
enough to reset your device, what device are you using the BCM4313 in?
Hauke