[Fwd: RE: [PATCH] [staging] brcm80211: fix radio disabled on attempt to bring up interface]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I should include this list in future, apologies.

Jon.

--- Begin Message ---
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@xxxxxxxxxxxx>

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.


--- End Message ---
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel

[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux