Date: Wed, 1 Aug 2012 20:53:20 -0500
From: Seth Forshee <seth.forshee@canonical.com>
To: Josh Boyer <jwboyer@redhat.com>
Cc: linux-wireless@vger.kernel.org,
	"John W. Linville" <linville@tuxdriver.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	"Luis R. Rodriguez" <rodrigue@qca.qualcomm.com>,
	Arend van Spriel <arend@broadcom.com>,
	Brett Rudley <brudley@broadcom.com>,
	Roland Vossen <rvossen@broadcom.com>,
	brcm80211-dev-list@broadcom.com
Subject: Re: [PATCH 0/2] Fix lockdep warning in brcmsmac
Message-ID: <20120802015320.GA25933@thinkpad-t410> (sfid-20120802_035331_998346_BC257402)
References: <1343854723-21987-1-git-send-email-seth.forshee@canonical.com>
 <20120802002353.GD1785@zod.bos.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20120802002353.GD1785@zod.bos.redhat.com>
Sender: linux-wireless-owner@vger.kernel.org

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