From: "Marek Behún" <kabel@kernel.org>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Pavel Machek <pavel@ucw.cz>,
John Crispin <john@phrozen.org>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-leds@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/5] leds: trigger: add API for HW offloading of triggers
Date: Mon, 8 Nov 2021 17:13:12 +0100 [thread overview]
Message-ID: <20211108171312.0318b960@thinkpad> (raw)
In-Reply-To: <YYk/Pbm9ZZ/Ikckg@Ansuel-xps.localdomain>
On Mon, 8 Nov 2021 16:16:13 +0100
Ansuel Smith <ansuelsmth@gmail.com> wrote:
> On Mon, Nov 08, 2021 at 03:04:23PM +0100, Andrew Lunn wrote:
> > > +static inline int led_trigger_offload(struct led_classdev *led_cdev)
> > > +{
> > > + int ret;
> > > +
> > > + if (!led_cdev->trigger_offload)
> > > + return -EOPNOTSUPP;
> > > +
> > > + ret = led_cdev->trigger_offload(led_cdev, true);
> > > + led_cdev->offloaded = !ret;
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static inline void led_trigger_offload_stop(struct led_classdev *led_cdev)
> > > +{
> > > + if (!led_cdev->trigger_offload)
> > > + return;
> > > +
> > > + if (led_cdev->offloaded) {
> > > + led_cdev->trigger_offload(led_cdev, false);
> > > + led_cdev->offloaded = false;
> > > + }
> > > +}
> > > +#endif
> >
> > I think there should be two calls into the cdev driver, not this
> > true/false parameter. trigger_offload_start() and
> > trigger_offload_stop().
> >
>
> To not add too much function to the struct, can we introduce one
> function that both enable and disable the hw mode?
Dear Ansuel,
what is the purpose of adding trigger_offload() methods to LED, if you
are not going to add support to offload the netdev trigger? That was
the entire purpose when I wrote that patch.
If you just want to create a new trigger that will make the PHY chip do
the blinking, there is no need at all for the offloading patch.
And you will also get a NACK from me and also Pavel (LED subsystem
maintainer).
The current plan is to:
- add support for offloading existing LED triggers to HW (LED
controllers (PHY chips, for example))
- make netdev trigger try offloading itself to HW via this new API (if
it fails, netdev trigger will blink the LED in SW as it does now)
- create LED classdevices in a PHY driver that have the offload()
methods implemented. The offload method looks at what trigger is
being enabled for the LED, and it if it is a netdev trigger with such
settings that are possible to offload, it will be offloaded.
This whole thing makes use of the existing sysfs ABI.
So for example if I do
cd /sys/class/net/eth0/phydev/leds/<LED>
echo netdev >trigger
echo eth0 >device_name
echo 1 >rx
echo 1 >tx
The netdev trigger is activated, and it calls the offload() method.
The offload() method is implemented in the PHY driver, and it checks
that it can offload these settings (blink on rx/tx), and will enable
this.
- extend netdev trigger to support more settings:
- indicate link for specific link modes only (for example 1g, 100m)
- ...
- extend PHY drivers to support offloading of these new settings
Marek
next prev parent reply other threads:[~2021-11-08 16:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 0:24 [RFC PATCH v2 0/5] Adds support for PHY LEDs with offload triggers Ansuel Smith
2021-11-08 0:24 ` [RFC PATCH v2 1/5] leds: trigger: add API for HW offloading of triggers Ansuel Smith
2021-11-08 2:29 ` Randy Dunlap
2021-11-08 14:04 ` Andrew Lunn
2021-11-08 15:16 ` Ansuel Smith
2021-11-08 16:13 ` Marek Behún [this message]
2021-11-08 16:46 ` Ansuel Smith
2021-11-08 17:35 ` Marek Behún
2021-11-08 17:58 ` Ansuel Smith
2021-11-08 18:41 ` Marek Behún
2021-11-08 19:08 ` Ansuel Smith
2021-11-08 19:17 ` Marek Behún
2021-11-08 17:46 ` Andrew Lunn
2021-11-08 17:56 ` Marek Behún
2021-11-08 19:53 ` Andrew Lunn
2021-11-08 20:03 ` Vladimir Oltean
2021-11-08 20:11 ` Marek Behún
2021-11-08 20:15 ` Ansuel Smith
2021-11-08 17:37 ` Andrew Lunn
2021-11-08 0:24 ` [RFC PATCH v2 2/5] leds: add function to configure offload leds Ansuel Smith
2021-11-08 2:22 ` Randy Dunlap
2021-11-08 0:24 ` [RFC PATCH v2 3/5] leds: trigger: add offload-phy-activity trigger Ansuel Smith
2021-11-08 2:24 ` Randy Dunlap
2021-11-08 14:17 ` Andrew Lunn
2021-11-08 15:19 ` Ansuel Smith
2021-11-08 0:24 ` [RFC PATCH v2 4/5] net: dsa: qca8k: add LEDs support Ansuel Smith
2021-11-08 2:26 ` Randy Dunlap
2021-11-08 0:25 ` [RFC PATCH v2 5/5] dt-bindings: net: dsa: qca8k: add LEDs definition example Ansuel Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211108171312.0318b960@thinkpad \
--to=kabel@kernel.org \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).