Re: [PATCH 0/2] Fix lockdep warning in brcmsmac

[Seth Forshee <seth.forshee@canonical.com>]

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