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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
