> +/* FIXME: Blinking rate is shared by all LEDs on a PHY. Should we check whether > + * another LED is currently blinking with incompatible rate? It would be cleaner > + * if we in this case failed to offload blinking this LED. > + * But consider this situation: > + * 1. user sets LED[1] to blink with period 500ms for some reason. This would > + * start blinking LED[1] with perion 670ms here period. > + * 2. user sets netdev trigger to LED[0] to blink on activity, default there > + * is 100ms period, which would translate here to 84ms. This is > + * incompatible with the already blinking LED, so we fail to offload to HW, > + * and netdev trigger does software offloading instead. > + * 3. user unsets blinking od LED[1], so now we theoretically can offload > + * netdev trigger to LED[0], but we don't know about it, and so it is left > + * in SW triggering until user writes the settings again > + * This could be solved by the netdev trigger periodically trying to offload to > + * HW if we reported that it is theoretically possible (by returning -EAGAIN > + * instead of -EOPNOTSUPP, for example). Do we want to do this? > + */ I believe we should check & fallback to software if there's already incompatible rate in use. No need to periodically re-try to activate the offload. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek
Attachment:
signature.asc
Description: Digital signature
