Re: [RFC] b43: rework rfkill code
Matthew Garrett wrote: > I've reworked the rfkill code in b43. This ought to be more consistent > with the other drivers and it seems to work on the machines I've tested > it on here, but it'd be good to get some feedback. > > Firstly, I've replaced the polled input device. It's just some delayed > work now. It polls the hardware every second to determine whether the > radio has been hardware killed or not. If it has, it sets the rfkill > state to HARD_BLOCKED. If the radio is enabled and the previous state > was HARD_BLOCKED, it resets the state to UNBLOCKED. If the radio is > enabled and the previous state was SOFT_BLOCKED, it leaves the state as > is. > > I also removed some of the complexity from the rfkill toggle function, > since the rfkill core will handle the case of the user requesting a > change from HARD_BLOCKED without the driver needing to care. > > The final change is that I removed the code for changing the wireless > state in response to the txpower configuration in mac80211. Right now, I > can't see any way for this to work correctly - if the user disables the > radio via rfkill, mac80211 doesn't flag the radio as disabled. As a > result, the next time the configuration callback is called, b43 > reenables the radio again, even though the user has explicitly disabled > it. I don't think any of the other drivers handle this case, so I'm not > really sure what the best way to handle this in future is. The current > situation certainly seems broken. > > How does this look to people? All this discussion about hard vs soft rfkill makes my head hurt and I have stopped reading those posts. Correction to my earlier post. If the system is booted with the RF switch off, the LED is on, whereas it should be off. The original code works correctly. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [RFC] b43: rework rfkill code
Matthew Garrett wrote: > I've reworked the rfkill code in b43. This ought to be more consistent > with the other drivers and it seems to work on the machines I've tested > it on here, but it'd be good to get some feedback. > > Firstly, I've replaced the polled input device. It's just some delayed > work now. It polls the hardware every second to determine whether the > radio has been hardware killed or not. If it has, it sets the rfkill > state to HARD_BLOCKED. If the radio is enabled and the previous state > was HARD_BLOCKED, it resets the state to UNBLOCKED. If the radio is > enabled and the previous state was SOFT_BLOCKED, it leaves the state as > is. > > I also removed some of the complexity from the rfkill toggle function, > since the rfkill core will handle the case of the user requesting a > change from HARD_BLOCKED without the driver needing to care. > > The final change is that I removed the code for changing the wireless > state in response to the txpower configuration in mac80211. Right now, I > can't see any way for this to work correctly - if the user disables the > radio via rfkill, mac80211 doesn't flag the radio as disabled. As a > result, the next time the configuration callback is called, b43 > reenables the radio again, even though the user has explicitly disabled > it. I don't think any of the other drivers handle this case, so I'm not > really sure what the best way to handle this in future is. The current > situation certainly seems broken. > > How does this look to people? All this discussion about hard vs soft rfkill makes my head hurt and I have stopped reading those posts. With this patch, my b43 device and its LED still work. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: BCM4310 driver status
?ukasz Marsza? wrote: > I want to ask about the status of b43 driver for BCM4310 chipset wifi > card. I read the message from this list, from September 2008, in which > it had been written, that you are "just finishing rervese-engeenering". > If the documentation is finished I can give you some support in > programming or betatesting new driver. Unfortunately, I have not done much with the reverse engineering is the past few months. We don't have the specs yet, and I don't know when it will happen. This kind of decompilation is very tedious, and I have not been in the right frame of mind for it. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
BCM4310 driver status
I want to ask about the status of b43 driver for BCM4310 chipset wifi card. I read the message from this list, from September 2008, in which it had been written, that you are "just finishing rervese-engeenering". If the documentation is finished I can give you some support in programming or betatesting new driver. Sincerely, Lukasz Marszal ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
