[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6cad314f-3cef-ec74-b55e-cccae28da4ab@gmail.com>
Date: Tue, 5 Dec 2017 21:38:31 +0100
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Ben Whitten <ben.whitten@...il.com>, rpurdie@...ys.net,
pavel@....cz
Cc: linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH/RFC v2] leds: trigger: Introduce a NETDEV trigger
Hi Ben,
On 12/05/2017 12:19 PM, Ben Whitten wrote:
> From: Ben Whitten <ben.whitten@...il.com>
>
> 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
Powered by blists - more mailing lists