On Sat, Apr 11, 2009 at 5:36 PM, Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > Hin-Tak Leung wrote: >> On Sat, Apr 11, 2009 at 5:23 AM, Hin-Tak Leung <hintak.leung@xxxxxxxxx> wrote: >> >> Oh, I forgot to mention that to test this code against >> compat-wireless, appending "CONFIG_RTL8187_LEDS=y" to config.mk does >> the job. >> >> I am wonder if we actually needs an extra Kconfig for this - at least >> in my case, the code has no ill effect with device which hasn't got an >> RX/TX LED. (other than possibly a small theoretical performance loss >> from do extra non-useful work). > > I do have to compile the LED code only if the kernel has support for them, > otherwise the registration entry points would be missing. The necessary > conditions would be more complicated, thus I put them in one place in the > Kconfig and let the source only be dependent on CONFIG_RTL8187_LEDS. Thanks for the explanation. Depending (silently) on other kernel requirements is certainly fine. I am just thinking we can keep it simple, and wondering if we need another user-configurable option. BTW, I had a hard lock-up on suspend - it hasn't happened for months... while the module doesn't suspend properly, I have unload-on-sleep configured and it has work mostly fine for some months. The vendor code is quite lacking in suspend/resume support, and if you are going to prepare another iteration of the LED patch, please give this a thought. on possible problem with this. -- 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
