Search Linux Wireless

Re: led support in mac80211 and drivers

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

 



John W. Linville wrote:
On Wed, Jan 16, 2008 at 08:38:48PM +0200, Tomas Winkler wrote:
That
driver switches between different modes based on bus->boardinfo.vendor.
But where are the other modules needing this flexibility? Are they being
developed in private by the companies that make the access points?

Different Laptop vendor and AP vendors. This information might be
written in many places, PCI subvendor, in EEROM etc sometimes it has
to be supplied from outside.

The question rather was: since there is really no user of the led infrastructure that needs the flexibility (the broadcom seems to have the leds on the same bus as the device itself) in the official kernel.. where are these drivers? Are they publicly available? Or are they in custom kernels? I can see the need for such infrastructure, but I don't see any actual users of it...

I thought about having an 'ieee80211_activity_listener' that could
subscribe to activity events of a ieee80211_hw device. One single
callback that would be called when there's activity or if the state of
the device has changed. Maybe something like this:

int (*callback)(... *hw, u8 state, u8 type);

where 'state' would be a bitmap of scanning/associated/etc and type the
'type' of activity (transmitting/receiving a frame). The callback then
would decide which leds to activate and how (blinking or not etc). Does
that sound better? At least it would be better than having to register
three leds in each low-level driver ;)
I'm not sure it's such big deal to subscribe to led more problem is
that I cannot subscribe same led to different triggers
so need another level
mac80211     | driver
Led Trigger ->| Logical Led -> (LED LOGIC/MAPPING) ->  HW LED
                    |

The problem here is that logic is already defined in Led pattern is
already defined int Led Trigger

Problem with your approach I cannot reach LEDs that are not connected
to NIC's PCIe pins.
>>
>> Other options that uses your idea is
>> mac80211        |  driver
>> mac callback ->| (LED LOGIC) - Led Trigger - > Led

I see that the whole wireless led interaction is a delicate matter. It's not easy to understand it fully (in such short time - however hard I try). You wouldn't believe how many times I've rewritten this email ;)

Do you have any numbers about how many platforms have leds on a different bus than the wlan device? Are those notebooks or embedded devices? In case of notebooks, I assume linux doesn't support the leds there, since I haven't found any code in the kernel that would use the mac80211 led subsystem to receive led activity notifications.

The 4965 chip supposedly supports three leds, but my notebook (thinkpad x61t) only has one. Other notebooks/platforms may have two/three. I imagine implementing different led behaviour based on how many leds there are and other platform differences will require lots of code (platform detection etc). And thus getting the led code right for everyone is very difficult. Is that the reason why any of the iwlwifi led patches hasn't been applied yet?

In the iwl4965 driver, implementing led support wholly inside the driver itself seems possible. And platforms that have leds on a different bus still can make their own led-driver and use the mac80211 subsystem to receive led activity notifications. All but the broadcom wireless drivers implement led support is such way. So I think that's the way to go.

In essence, on platforms that have the radio device and leds on the same bus, it's actually easier to implement led support inside the driver and not using the mac80211 led subsystem. The driver has all the needed info to control the leds (device state etc). The mac80211 led subsystem is only useful for platforms where the leds are on a different bus.

I must apologize, there's nothing wrong with the mac80211 led subsystem, it does what it was designed for. It's the many iwlwifi led patches that gave me a bad impression that the mac80211 led subsystem was somehow needed for led support, what a shame :( I'm sorry for the noise.


tom

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

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux