netdev - Re: [PATCH] zd1211rw-d80211: Use LED class

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]

Message-ID: <20061213225452.GC20700@p15091797.pureserver.info>
Date:	Wed, 13 Dec 2006 23:54:52 +0100
From:	Ulrich Kunitz <kune@...ne-taler.de>
To:	Michael Wu <flamingice@...rmilk.net>
Cc:	Daniel Drake <dsd@...too.org>, netdev@...r.kernel.org,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: [PATCH] zd1211rw-d80211: Use LED class

Michael,

please detach a little bit from LEDs.

A trigger is a generic concept. It doesn't need to have a special
binding to what it triggers. It could be a buzzer, it could be
an LED, it could be text output on an LCD.

So we could have link status change trigger, for which functions
could be registered. There is no reason for the upper layer d80211
code to know, that it triggers an LED. A netlink event generator
could only be one of the users of those generic triggers.

My other opinion is that I find it overkill to handle the LED on a
WLAN adapter as an independent device instantiating a device class
in Linux. I mean on the other hands we break APIs for four or
eight bytes and here we spend a whole device strucuture and sysfs
directory for something the wlan device firmware represents with a
single bit. To call the housekeeping functions overkill under
these circumstances appears not to be very rational.

It should also be mentioned that the LEDs on the ZD1211 devices
are not independent devices, because they are partly controlled
by the firmware. That's exactly where some of the issues with your
patch are.

Let the device drivers do the blinking, but give them a chance to
know about status changes at the MAC layer, without mandating to
implement a LED device. Using the same triggers by a netlink event
generator, would make the code even simpler.

-- 
Uli Kunitz
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html