[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1286911059.20957.5.camel@constitution.bos.jonmasters.org>
Date: Tue, 12 Oct 2010 15:17:39 -0400
From: Jon Masters <jonathan@...masters.org>
To: Brett Rudley <brudley@...adcom.com>
Cc: "jcm@...masters.org" <jcm@...masters.org>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
Henry Ptasinski <henryp@...adcom.com>,
Nohee Ko <noheek@...adcom.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] [staging] brcm80211: fix radio disabled on attempt to
bring up interface
On Tue, 2010-10-12 at 11:34 -0700, Brett Rudley wrote:
> > The brcm80211 driver does not correctly handle the case that the wireless
> > radio hardware is physically disabled during interface initialization. An
> > attempt is made to check whether the radio is disabled, and in the case
> > that it is, a background worker is setup to monitor for the radio coming
> > online, but the interface queues are incorrectly brought up anyway. The
> > value BCME_RADIOOFF should be returned in wlc_up in such error case.
> Signed-off-by: Brett Rudley <brudley@...adcom.com>
Thanks. The patch actually didn't use full paths to the staging tree
(was relative to the driver directory) because it was crazy late and my
brain was tired by the time I found the problem. You'll sort it out.
Anyway. So rfkill works with soft block/unblock, but doesn't seem to
correctly report the state of the physical button on this laptop. I
don't think that's your domain (as I said, I freely admit that I need to
find some time, sometime, to understand how rfkill is supposed to work).
What I do think is your domain is the fact that suspend/resume with this
driver isn't working. The system does suspend, and it does resume, but
the driver gets itself in a twist and never talks to the outside world
again - just keeps logging an error. I'll send you some debug info
tonight or in the next few days so we can get that fixed up too.
Can I ask, also, do you plan on cleaning up the WLC HIGH/LOW stuff or
adding some comments to the code so that people realize this is for
PCI/USB dongle stuff? I spent some time going through the code trying to
figure out what the WL_LOCK/UNLOCK stuff was about and why it was
missing in the case of a PCI device :) It seems like this driver is
partly based on generic code used in other drivers, and that's fine, but
I suspect some of it will need more cleanup before it is merged.
Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists