[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c8e43260-1535-6171-b9e6-f2593178a3e2@gmail.com>
Date: Thu, 3 Sep 2020 09:32:21 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Kurt Kanzenbach <kurt@...utronix.de>, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org, Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH v4 5/7] net: dsa: hellcreek: Add PTP status LEDs
On 9/1/2020 5:50 AM, Kurt Kanzenbach wrote:
> The switch has two controllable I/Os which are usually connected to LEDs. This
> is useful to immediately visually see the PTP status.
>
> These provide two signals:
>
> * is_gm
>
> This LED can be activated if the current device is the grand master in that
> PTP domain.
>
> * sync_good
>
> This LED can be activated if the current device is in sync with the network
> time.
>
> Expose these via the LED framework to be controlled via user space
> e.g. linuxptp.
>
> Signed-off-by: Kurt Kanzenbach <kurt@...utronix.de>
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
There appears to be quite some boilerplate code to deal with the default
trigger, default LED label that could presumably live in the LED
subsystem, nonetheless:
Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
--
Florian
Powered by blists - more mailing lists