On Saturday 10 January 2009, Andrew Price wrote: > Add a check for LED_MODE_DEFAULT so that we initialise the link LED. > > Signed-off-by: Andrew Price <andy@xxxxxxxxxxxxxxxxx> > --- > > I'm submitting this patch just as an RFC as I have no idea whether it works > with all rt2500pci devices. With my card, value holds 0 after the call to > rt2x00_get_field16() and so the added check for LED_MODE_DEFAULT (which is 0) > is needed for the link LED to work. > > My card is a "RaLink RT2500 802.11g Cardbus/mini-PCI [1814:0201]" Belkin > F5D7010 according to lspci. > > Any advice would be much appreciated. Does this patch look reasonable? Are > there any docs/specs which I could read to learn how this should be handled? > > P.S. This is not related to my previous LED patch. This one is for the other > LED which has never worked as far as I can remember, until now :-) Ok, I just checked legacy driver and LED_MODE_DEFAULT indeed can be considered as LED_MODE_TXRX_ACTIVITY. Could you resend this patch as normal patch, but with the same change for rt2400pci and rt2500usb. Thanks, > diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c > index d3bc218..651cb4f 100644 > --- a/drivers/net/wireless/rt2x00/rt2500pci.c > +++ b/drivers/net/wireless/rt2x00/rt2500pci.c > @@ -1524,7 +1524,7 @@ static int rt2500pci_init_eeprom(struct rt2x00_dev *rt2x00dev) > value = rt2x00_get_field16(eeprom, EEPROM_ANTENNA_LED_MODE); > > rt2500pci_init_led(rt2x00dev, &rt2x00dev->led_radio, LED_TYPE_RADIO); > - if (value == LED_MODE_TXRX_ACTIVITY) > + if (value == LED_MODE_TXRX_ACTIVITY || value == LED_MODE_DEFAULT) > rt2500pci_init_led(rt2x00dev, &rt2x00dev->led_qual, > LED_TYPE_ACTIVITY); > #endif /* CONFIG_RT2X00_LIB_LEDS */ -- 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
