[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <443a5c04-4551-4a49-bc22-09a333ee82aa@lunn.ch>
Date: Wed, 8 Mar 2023 02:07:06 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
John Crispin <john@...ozen.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, Lee Jones <lee@...nel.org>,
linux-leds@...r.kernel.org
Subject: Re: [net-next PATCH 01/11] net: dsa: qca8k: add LEDs basic support
> Just checked them, interesting concept, guess we can think of something
> also for the interval setting. That would effectively make all the
> setting of the trigger set. Just my concern is that they may be too much
> specific to netdev trigger and may be problematic for other kind of hw
> control. (one main argument that was made for this feature was that some
> stuff were too much specific and actually not that generic)
I deliberately made this API return a struct device, not a struct
net_device. That should keep it generic. The LED could then be
attached to an disk device, an mtd device, or a tty device, each of
which have an ledtrig-*.c file.
Andrew
Powered by blists - more mailing lists