LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: "Marek Behún" <firstname.lastname@example.org> To: Andrew Lunn <email@example.com> Cc: Ansuel Smith <firstname.lastname@example.org>, Vivien Didelot <email@example.com>, Florian Fainelli <firstname.lastname@example.org>, Vladimir Oltean <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, Rob Herring <firstname.lastname@example.org>, Jonathan Corbet <email@example.com>, Pavel Machek <firstname.lastname@example.org>, John Crispin <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [RFC PATCH v2 1/5] leds: trigger: add API for HW offloading of triggers Date: Mon, 8 Nov 2021 18:56:37 +0100 [thread overview] Message-ID: <20211108185637.21b63d40@thinkpad> (raw) In-Reply-To: <YYliclrZuxG/laIh@lunn.ch> On Mon, 8 Nov 2021 18:46:26 +0100 Andrew Lunn <email@example.com> wrote: > > 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 > > Hi Marek > > The problem here is, you are not making much progress. People are > giving up on you ever getting this done, and doing their own > implementation. Ansuel code is not mature enough yet, it has problems, > but he is responsive, he is dealing with comments, progress is being > made. At some point, it is going to be good enough, and it will get > merged, unless you actual get your code to a point it can be merged. > > Andrew Hello Andrew, you are right that this has been taking too long on my side. I am sorry for that. I guess I will have to work on this again ASAP or we will end up with solution that I don't like. Nonetheless, what is your opinion about offloading netdev trigger vs introducing another trigger? Marek
next prev parent reply other threads:[~2021-11-08 17:56 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 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 [this message] 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=20211108185637.21b63d40@thinkpad \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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: linkBe 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).