Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
On 06-08-21 22:33 Maxime Austruy wrote:
> zd_chip_led_status is only used by zd_chip_led_flip which itself is not
> used, yet. While it's not vital to fix bugs in those functions, it is
> nice to have a clean code base, so please consider this patch for
> inclusion. It addresses the following problems:
> . if read_led_reg fails or if the callsite of zd_chip_led_status passes
> a bogus status, we return with chip->mutex locked,
> . zd_chip_led_status returns the wrong return value when successful,
> . zd_chip_led_flip doesn't properly check the return value of
> Signed-off-by: Maxime Austruy <maxime@...>
Thank you Maxime. However I've fixed it on my own and I support
blinking now. This patch contains comparable code:
On 06-08-23 13:34 Maxime Austruy wrote:
> Cool. Btw, are there any plans to move this code to the devicescape
> 802.11 stack? I saw some patches flying around on netdev@... that add
> support for LED to it. I'm guessing that this implements the blinking
> that you added but in a generic way: every wireless nic driver just has
> to provide a turn led on/off interface.
Nobody has started on the descape stack, but it is certainly
something which needs to be done in the future.
However we cannot use this on/off interface, because every on/off
switch would require it's own USB transaction. The ZD1211 chip has
a firmware-controlled mode, which doesn't come with this price.
From: Daniel Drake <dsd@ge...> - 2006-08-26 14:53:32
Ulrich Kunitz wrote:
> Nobody has started on the descape stack, but it is certainly
> something which needs to be done in the future.
Luis Rodriguez at least started on this, but has not published any code
to my knowledge.