> +/* 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
signature.asc
Description: Digital signature
