strange LED behaviour on WGT634U

Description

With the latest version r11461 the LEDs on my router show a strange behaviour:

1.
The switch LEDs for port 1 and WAN port turn orange when the kernel initializes the switch at startup. They are green during CFE phase and stayed green with my old version of openwrt (5xxx).
I did not see any functional defect, though - port 1 is working at 100 MBps.

2.
The power LED flashes amber during operation. It's not the flashing algorithm of the diag module. The timing is pulse - short - pulse - long.
Repeated queries of /proc/diag/led/power return usually 1, but sometimes 0, probably when you hit the pulse.
When I set the /proc/diag/led/power to f(lash), it flashes irregular and I always read f afterwards.
The flashing appears also when the kmod-diag is not installed, so I assume something else triggers this flashing.

This looks like it comes from the CONFIG_LEDS_TRIGGER_HEARTBEAT=y configuration option in the kernel config: trunk/target/linux/generic-2.6/config-default

This is also set in all the other configs (found using grep):
trunk/target/linux/generic-2.6/config-2.6.22:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.23:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.24:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.25:CONFIG_LEDS_TRIGGER_HEARTBEAT=y
trunk/target/linux/generic-2.6/config-2.6.26:CONFIG_LEDS_TRIGGER_HEARTBEAT=y

The origin of this issue is NOT gpio code. The fault was introduced in r10531.

The switch_robo kernel module was updated from 0.01 to 0.02. Actual file is /trunk/package/switch/src/switch-robo.c In the process, a function called robo_switch_enable has the following lines when the switch is successfully enabled:

/* WAN port LED */
robo_write16(ROBO_CTRL_PAGE, 0x16, 0x1F);

Apparently one of the values for writing to the control page is incorrect. I don't have the technical specs for the chip to figure out what should really be there.

I figured out the heartbeat issue and it turns out to be a trivial fix. In the kernel documentation there is a file Documentation/leds-class.txt that discusses LED control. The sysfs entry for the triggers is shown by doing:

# cat /sys/devices/platform/leds-gpio/leds/power/trigger

and you get the response similar to:

none timer [heartbeat] default-on morse

Each of those items represents a choice for what can trigger the power LED. The current choice is in brackets, which by default is the [heartbeat]. If you want to change what can trigger the LED you can just echo the choice name into the trigger file like this:

# echo none > /sys/devices/platform/leds-gpio/leds/power/trigger

The different triggers do the following:

none - turns off the power (yellow) LED

timer - responds to system timer event

heartbeat - causes the power LED to pulse

default-on - turns the power LED on all the time

morse - flashes the LED in Morse code

If you set the LED trigger to "none" you can then control it through the /proc interface like so:

Looking at this spec: ​http://voodoowarez.com/bcm5365p.pdf, page 00h addr 16h is in the reserved address range between 0x10 and 0x20 (page 103).
It's probably not a good idea to write there for the wgt634u.

Add Comment

This ticket has been modified since you started editing. You should review the
other modifications which have been appended above,
and any conflicts shown in the preview below.
You can nevertheless proceed and submit your changes if you wish so.