On Thu, 2009-01-01 at 14:41 +0100, Andreas Mohr wrote: > Hi, > > On Wed, Dec 31, 2008 at 06:51:31PM +0200, Maxim Levitsky wrote: > > On Wed, 2008-12-31 at 09:03 -0500, Bob Copeland wrote: > > > On Wed, Dec 31, 2008 at 10:18:45AM +0100, Andreas Mohr wrote: > > > > Hi, > > > > > > > > > Sure, will test, I am also sure that this will work. > > > > > > > > A110L, 2.6.28, success (also inverted here, traffic blanks it). > > > > > > Thanks for testing. > > > > > > By inverted, do you mean that it is off when it should be on and > > > vice-versa? If so, you can change it to 'sc->led_on = 0' instead > > > of 1. Let me know if I should make that change in the patch. > > > > > > > Actually, I even thought that this is right behavior, here on iwl3945 > > led is always on, and blinks while traffic is send, also same on > > windows, but feel free to invert the polarity. > > It's not: > Inversion of the led_on flag does make LED state work properly > and is the right thing to do since an LED > _as seen by the authoritative LED layer_ > __has__ to have proper on/off configuration, > regardless of whether having a WLAN LED on-by-default and > off-on-traffic _in the WLAN layer_ is desireable. > (witness wrong state of default-on and heartbeat triggers) > > Or, IOW: logical state has to be maintained properly, > at _each layer_ that is involved. > > > What does bother me is, that led state gets inverted dynamically, that > > is system starts with default 'led always on', but after some time > > switches to 'always led off' and after sometime again switches back. > > This does seem to be software problem, at least according to sysfs > > interace. > > linux/net/mac80211/led.c/ieee80211_led_rx() does simple on/off alternation > via a counter increment modulo, thus somewhat weird LED state toggling > does seem a natural outcome given the current implementation. > > I believe the 80211 layer itself should provide some generic LED > handling which then provide for reliable and _identical_ displaying of > WLAN LEDs. It's not a good idea to have individual drivers > mess with custom rssi-indicating LED type implementations, > this should be centralized to have one template for an RSSI LED. > > More notes: > . checks of AR5K_NUM_GPIO most certainly are buggy: off-by-1 > (range sems to be 0-5, _not_ 1-6) > . prepend "Acer" to "Aspire One" in this patch > since Acer is major AR5007EG customer > . testing GPIOs other than 3 (0-6) didn't succeed in making the other > LED work - what is the behaviour with Linpus, is there an rfkill LED > there? > > Andreas Mohr
Completely agree with you. Nether does second led works here, even with Win XP that this netbook came with. I suspect, that this is usual outcome of an acer tradition, I mean shipping notebooks with all bluetooch equipment except the actual device (I mean my notebook has a BT led, BT button, but not a BT device) I suspect that this led is intended for BT. Also there is a wireless sign near wireless led, and none near the other led, and I guess there should have been a BT sign. Best regards, Maxim Levitsky _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel