All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Marek Behún" <marek.behun@nic.cz>
Cc: netdev@vger.kernel.org, linux-leds@vger.kernel.org,
	"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 22:48:15 +0200	[thread overview]
Message-ID: <20200909204815.GB20388@amd> (raw)
In-Reply-To: <20200909162552.11032-3-marek.behun@nic.cz>

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]

Hi!

> Many an ethernet PHY (and other chips) supports various HW control modes
> for LEDs connected directly to them.

I guess this should be

"Many ethernet PHYs (and other chips) support various HW control modes
for LEDs connected directly to them."

> 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 +

I guess this should live in drivers/leds/trigger/ledtrig-hw.c . I'd
call the trigger just "hw"...

> +Contact:	Marek Behún <marek.behun@nic.cz>
> +		linux-leds@vger.kernel.org
> +Description:	(W) Set the HW control mode of this LED. The various available HW control modes
> +		    are specific per device to which the LED is connected to and per LED itself.
> +		(R) Show the available HW control modes and the currently selected one.

80 columns :-) (and please fix that globally, at least at places where
it is easy, like comments).

> +	return 0;
> +err_free:
> +	devm_kfree(dev, led);
> +	return ret;
> +}

No need for explicit free with devm_ infrastructure?

> +	cur_mode = led->ops->led_get_hw_mode(dev->parent, led);
> +
> +	for (mode = led->ops->led_iter_hw_mode(dev->parent, led, &iter);
> +	     mode;
> +	     mode = led->ops->led_iter_hw_mode(dev->parent, led, &iter)) {
> +		bool sel;
> +
> +		sel = cur_mode && !strcmp(mode, cur_mode);
> +
> +		len += scnprintf(buf + len, PAGE_SIZE - len, "%s%s%s ", sel ? "[" : "", mode,
> +				 sel ? "]" : "");
> +	}
> +
> +	if (buf[len - 1] == ' ')
> +		buf[len - 1] = '\n';

Can this ever be false? Are you accessing buf[-1] in such case?

> +int of_register_hw_controlled_leds(struct device *dev, const char *devicename,
> +				   const struct hw_controlled_led_ops *ops);
> +int hw_controlled_led_brightness_set(struct led_classdev *cdev, enum led_brightness brightness);
> +

Could we do something like hw_controlled_led -> hw_led to keep
verbosity down and line lengths reasonable? Or hwc_led?

> +extern struct led_hw_trigger_type hw_control_led_trig_type;
> +extern struct led_trigger hw_control_led_trig;
> +
> +#else /* !IS_ENABLED(CONFIG_LEDS_HW_CONTROLLED) */

CONFIG_LEDS_HWC? Or maybe CONFIG_LEDTRIG_HW?

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2020-09-09 20:48 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
2020-09-09 18:43       ` Randy Dunlap
2020-09-09 20:48   ` Pavel Machek [this message]
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=20200909204815.GB20388@amd \
    --to=pavel@ucw.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=marek.behun@nic.cz \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=megous@megous.com \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.