linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <marek.behun@nic.cz>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: netdev@vger.kernel.org, linux-leds@vger.kernel.org,
	"Pavel Machek" <pavel@ucw.cz>, "Dan Murphy" <dmurphy@ti.com>,
	"Ondřej Jirman" <megous@megous.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Andrew Lunn" <andrew@lunn.ch>,
	linux-kernel@vger.kernel.org,
	"Matthias Schiffer" <matthias.schiffer@ew.tq-group.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware
Date: Wed, 9 Sep 2020 20:31:21 +0200	[thread overview]
Message-ID: <20200909203121.73bfcfa1@dellmb.labs.office.nic.cz> (raw)
In-Reply-To: <84bfc0ce-752d-9d1f-1043-fabe4cc25b15@infradead.org>

On Wed, 9 Sep 2020 11:20:00 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:

> Hi,
> 
> On 9/9/20 9:25 AM, Marek Behún wrote:
> > Many an ethernet PHY (and other chips) supports various HW control
> > modes for LEDs connected directly to them.
> > 
> > This patch adds a generic API for registering such LEDs when
> > described in device tree. This API also exposes generic way to
> > select between these hardware control modes.
> > 
> > This API registers a new private LED trigger called dev-hw-mode.
> > When this trigger is enabled for a LED, the various HW control
> > modes which are supported by the device for given LED can be
> > get/set via hw_mode sysfs file.
> > 
> > Signed-off-by: Marek Behún <marek.behun@nic.cz>
> > ---
> >  .../sysfs-class-led-trigger-dev-hw-mode       |   8 +
> >  drivers/leds/Kconfig                          |  10 +
> >  drivers/leds/Makefile                         |   1 +
> >  drivers/leds/leds-hw-controlled.c             | 227
> > ++++++++++++++++++ include/linux/leds-hw-controlled.h            |
> > 74 ++++++ 5 files changed, 320 insertions(+)
> >  create mode 100644
> > Documentation/ABI/testing/sysfs-class-led-trigger-dev-hw-mode
> > create mode 100644 drivers/leds/leds-hw-controlled.c create mode
> > 100644 include/linux/leds-hw-controlled.h 
> 
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 1c181df24eae4..5e47ab21aafb4 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -49,6 +49,16 @@ config LEDS_BRIGHTNESS_HW_CHANGED
> >  
> >  	  See Documentation/ABI/testing/sysfs-class-led for
> > details. 
> > +config LEDS_HW_CONTROLLED
> > +	bool "API for LEDs that can be controlled by hardware"
> > +	depends on LEDS_CLASS  
> 
> 	depends on OF || COMPILE_TEST
> ?
> 

I specifically did not add OF dependency so that this can be also used
on non-OF systems. A device driver may register such LED itself...
That's why hw_controlled_led_brightness_set symbol is exported.

Do you think I shouldn't do it?

> > +	select LEDS_TRIGGERS
> > +	help
> > +	  This option enables support for a generic API via which
> > other drivers
> > +	  can register LEDs that can be put into hardware
> > controlled mode, eg.  
> 
> 	                                                                   e.g.
> 

This will need to be changed on multiple places, thanks.

> > +	  a LED connected to an ethernet PHY can be configured to
> > blink on  
> 
> 	  an LED
> 

This as well

> > +	  network activity.
> > +
> >  comment "LED drivers"
> >  
> >  config LEDS_88PM860X  
> 
> 
> > diff --git a/include/linux/leds-hw-controlled.h
> > b/include/linux/leds-hw-controlled.h new file mode 100644
> > index 0000000000000..2c9b8a06def18
> > --- /dev/null
> > +++ b/include/linux/leds-hw-controlled.h
> > @@ -0,0 +1,74 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Generic API for LEDs that can be controlled by hardware (eg. by
> > an ethernet PHY chip)
> > + *
> > + * Copyright (C) 2020 Marek Behun <marek.behun@nic.cz>
> > + */
> > +#ifndef _LINUX_LEDS_HW_CONTROLLED_H_
> > +#define _LINUX_LEDS_HW_CONTROLLED_H_
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/leds.h>
> > +
> > +struct hw_controlled_led {
> > +	struct led_classdev cdev;
> > +	const struct hw_controlled_led_ops *ops;
> > +	struct mutex lock;
> > +
> > +	/* these members are filled in by OF if OF is enabled */
> > +	int addr;
> > +	bool active_low;
> > +	bool tristate;
> > +
> > +	/* also filled in by OF, but changed by led_set_hw_mode
> > operation */
> > +	const char *hw_mode;
> > +
> > +	void *priv;
> > +};
> > +#define led_cdev_to_hw_controlled_led(l) container_of(l, struct
> > hw_controlled_led, cdev) +
> > +/* struct hw_controlled_led_ops: Operations on LEDs that can be
> > controlled by HW
> > + *
> > + * All the following operations must be implemented:
> > + * @led_init: Should initialize the LED from OF data (and sanity
> > check whether they are correct).
> > + *            This should also change led->cdev.max_brightness, if
> > the value differs from default,
> > + *            which is 1.
> > + * @led_brightness_set: Sets brightness.
> > + * @led_iter_hw_mode: Iterates available HW control mode names for
> > this LED.
> > + * @led_set_hw_mode: Sets HW control mode to value specified by
> > given name.
> > + * @led_get_hw_mode: Returns current HW control mode name.
> > + */  
> 
> Convert that struct info to kernel-doc?
> 

Will look into this.
Thanks.

> > +struct hw_controlled_led_ops {
> > +	int (*led_init)(struct device *dev, struct
> > hw_controlled_led *led);
> > +	int (*led_brightness_set)(struct device *dev, struct
> > hw_controlled_led *led,
> > +				  enum led_brightness brightness);
> > +	const char *(*led_iter_hw_mode)(struct device *dev, struct
> > hw_controlled_led *led,
> > +					void **iter);
> > +	int (*led_set_hw_mode)(struct device *dev, struct
> > hw_controlled_led *led,
> > +			       const char *mode);
> > +	const char *(*led_get_hw_mode)(struct device *dev, struct
> > hw_controlled_led *led); +};
> > +  
> 
> > +
> > +#endif /* _LINUX_LEDS_HW_CONTROLLED_H_ */  
> 
> thanks.


  reply	other threads:[~2020-09-09 18:31 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 16:25 [PATCH net-next + leds v2 0/7] PLEASE REVIEW: Add support for LEDs on Marvell PHYs Marek Behún
2020-09-09 16:25 ` [PATCH net-next + leds v2 1/7] dt-bindings: leds: document binding for HW controlled LEDs Marek Behún
2020-09-09 18:27   ` Andrew Lunn
2020-09-09 18:33     ` Marek Behún
2020-09-09 20:59       ` Rob Herring
2020-09-09 21:07         ` Marek Behun
2020-09-09 21:31           ` Rob Herring
2020-09-09 21:43             ` Marek Behun
2020-09-09 20:56   ` Rob Herring
2020-09-09 21:15   ` Rob Herring
2020-09-09 21:58     ` Marek Behun
2020-09-09 16:25 ` [PATCH net-next + leds v2 2/7] leds: add generic API for LEDs that can be controlled by hardware Marek Behún
2020-09-09 18:20   ` Randy Dunlap
2020-09-09 18:31     ` Marek Behún [this message]
2020-09-09 18:43       ` Randy Dunlap
2020-09-09 20:48   ` Pavel Machek
2020-09-09 21:20     ` Marek Behun
2020-09-09 21:40       ` Pavel Machek
2020-09-09 22:15         ` Marek Behun
2020-09-09 22:20           ` Pavel Machek
2020-09-09 16:25 ` [PATCH net-next + leds v2 3/7] net: phy: add simple incrementing phyindex member to phy_device struct Marek Behún
2020-09-10 12:20   ` Pavel Machek
2020-09-09 16:25 ` [PATCH net-next + leds v2 4/7] dt-bindings: net: ethernet-phy: add description for PHY LEDs Marek Behún
2020-09-09 16:25 ` [PATCH net-next + leds v2 5/7] net: phy: add support for LEDs controlled by ethernet PHY chips Marek Behún
2020-09-10 12:22   ` Pavel Machek
2020-09-09 16:25 ` [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs Marek Behún
2020-09-10 12:23   ` Pavel Machek
2020-09-10 13:15     ` Andrew Lunn
2020-09-10 14:15       ` Marek Behún
2020-09-10 14:46         ` Andrew Lunn
2020-09-10 15:00         ` Andrew Lunn
2020-09-11  7:12           ` Matthias Schiffer
2020-09-11 12:42             ` Andrew Lunn
2020-09-11 12:52             ` Marek Behún
2020-09-10 20:23         ` Pavel Machek
2020-09-10 20:31           ` Andrew Lunn
2020-09-10 20:39             ` Pavel Machek
2020-09-10 20:41           ` Marek Behun
2020-09-10 18:24       ` Pavel Machek
2020-09-10 18:31         ` Andrew Lunn
2020-09-10 18:34           ` Russell King - ARM Linux admin
2020-09-10 20:31             ` Marek Behun
2020-09-10 21:44               ` Russell King - ARM Linux admin
2020-09-11 12:53                 ` Marek Behún
2020-09-09 16:25 ` [PATCH net-next + mvebu v2 7/7] arm64: dts: armada-3720-turris-mox: add nodes for ethernet PHY LEDs Marek Behún
2020-09-10 12:25   ` Pavel Machek
2020-09-09 21:42 ` [PATCH net-next + leds v2 0/7] PLEASE REVIEW: Add support for LEDs on Marvell PHYs Andrew Lunn
2020-09-09 22:11   ` Marek Behun
2020-09-09 22:39     ` Andrew Lunn

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=20200909203121.73bfcfa1@dellmb.labs.office.nic.cz \
    --to=marek.behun@nic.cz \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=dmurphy@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=megous@megous.com \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rdunlap@infradead.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: 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).