Hi Ben, On 12/05/2017 12:19 PM, Ben Whitten wrote: > From: Ben Whitten <ben.whitten@xxxxxxxxx> > > The patch was converted to led_blink_oneshot, in doing so we find that the > behaviour has changed. As I dont want to break 'userspace' led behaviour this > patch shouldn't be merged as is. Open to suggestions. > > Given an interval of 50ms and heavy throughput, the previous implementation > produced a blink with 100ms period and 50% dutycycle. The led_blink_oneshot > version produces a blink with 140ms period and 57% dutycycle. Please check if the LED class driver you're testing the trigger with implements blink_set op. If yes it would be good to check if it doesn't align the delay intervals to the hardware capabilities instead of failing and relying on a LED core software blink fallback. > I assume a fudge factor on the oneshot delay to bring the period back to 100ms > would be device specific so not suitable. > > Kind regards, > Ben Whitten (1): > leds: trigger: Introduce a NETDEV trigger > > .../ABI/testing/sysfs-class-led-trigger-netdev | 45 ++ > drivers/leds/trigger/Kconfig | 7 + > drivers/leds/trigger/Makefile | 1 + > drivers/leds/trigger/ledtrig-netdev.c | 507 +++++++++++++++++++++ > 4 files changed, 560 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-netdev > create mode 100644 drivers/leds/trigger/ledtrig-netdev.c > -- Best regards, Jacek Anaszewski
