linux-kernel - Re: [ath5k-devel] Bugs on aspire one A150

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Jan 2009 14:41:00 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	Bob Copeland <me@...copeland.com>, Andreas Mohr <andi@...as.de>,
	ath5k-devel@...ts.ath5k.org, linux-kernel@...r.kernel.org
Subject: Re: [ath5k-devel] Bugs on aspire one A150

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
--
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/