From: Pavel Machek <pavel@ucw.cz>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: mazziesaccount@gmail.com,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Dan Murphy <dmurphy@ti.com>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Lee Jones <lee.jones@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-rtc@vger.kernel.org
Subject: Re: [PATCH v7 11/12] leds: Add common LED binding parsing support to LED class/core
Date: Sat, 21 Dec 2019 20:37:58 +0100 [thread overview]
Message-ID: <20191221193758.GJ32732@amd> (raw)
In-Reply-To: <c7abf8d15ea54fee504fbec5666d013c26d3b62a.1576745635.git.matti.vaittinen@fi.rohmeurope.com>
[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]
Hi!
> Qucik grep for 'for_each' or 'linux,default-trigger' or
quick.
> If init_data is goven but no starting point for node lookup - then
is given.
> (parent) device's own DT node is used. If no led-compatible is given,
> then of_match is searched for. If neither led-compatible not of_match
nor of_match.
> is given then device's own node or passed starting point are used as
> such.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> ---
>
> No changes since v6
>
> drivers/leds/led-class.c | 99 +++++++++++++--
> drivers/leds/led-core.c | 258 ++++++++++++++++++++++++++++++++-------
> include/linux/leds.h | 94 ++++++++++++--
> 3 files changed, 385 insertions(+), 66 deletions(-)
Quite a lot of code added here. Can I trust you that we we'll delete
320 lines by converting driver or two?
> +static void led_add_props(struct led_classdev *ld, struct led_properties *props)
> +{
> + if (props->default_trigger)
> + ld->default_trigger = props->default_trigger;
> + /*
> + * According to binding docs the LED is by-default turned OFF unless
> + * default_state is used to indicate it should be ON or that state
> + * should be kept as is
> + */
> + if (props->default_state) {
> + ld->brightness = LED_OFF;
> + if (!strcmp(props->default_state, "on"))
> + ld->brightness = LED_FULL;
Max brightness is not always == LED_FULL these days.
> @@ -322,6 +398,10 @@ int led_classdev_register_ext(struct device *parent,
> led_cdev->name);
>
> return 0;
> +err_out:
> + if (led_cdev->fwnode_owned)
> + fwnode_handle_put(fw);
> + return ret;
> }
led_cdev->fwnode_owned = false here?
> +/**
> + * led_find_fwnode - find fwnode for led
> + * @parent LED controller device
> + * @init_data led init data with match information
> + *
> + * Scans the firmware nodes and returns node matching the given init_data.
> + * NOTE: Function increases refcount for found node. Caller must decrease
> + * refcount using fwnode_handle_put when finished with node.
> + */
> +struct fwnode_handle *led_find_fwnode(struct device *parent,
> + struct led_init_data *init_data)
> +{
> + struct fwnode_handle *fw;
> +
> + /*
> + * This should never be called W/O init data. We could always return
without
> + * For now we do only do node look-up for drivers which populate
> + * the new match properties. We could and perhaps should do
> + * fw = dev_fwnode(parent); if given fwnode is NULL. But in order to
> + * not break existing setups we keep the old behaviour and just directly
not to break.
> + /*
> + * Simple things are pretty. I think simplest is to use DT node-name
> + * for matching the node with LED - same way regulators use the node
> + * name to match with desc.
> + *
> + * This may not work with existing LED DT entries if the node name has
> + * been freely selectible. In order to this to work the binding doc
selectable?
> + /**
> + * Please note, logic changed - if invalid property is found we bail
> + * early out without parsing the rest of the properties. Originally
> + * this was the case only for 'label' property. I don't know the
> + * rationale behind original logic allowing invalid properties to be
> + * given. If there is a reason then we should reconsider this.
> + * Intuitively it feels correct to just yell and quit if we hit value we
> + * don't understand - but intuition may be wrong at times :)
> + */
Is this supposed to be linuxdoc?
> +/**
> + * led_find_fwnode - find fwnode matching given LED init data
> + * @parent: LED controller device this LED is driven by
> + * @init_data: the LED class device initialization data
> + *
> + * Find the fw node matching given LED init data.
> + * NOTE: Function increases refcount for found node. Caller must decrease
> + * refcount using fwnode_handle_put when finished with node.
> + *
> + * Returns: node handle or NULL if matching fw node was not found
> + */
> +struct fwnode_handle *led_find_fwnode(struct device *parent,
> + struct led_init_data *init_data);
> +
If function _gets_ the node and increments its usage count, is it
normally called "get"?
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 --]
next prev parent reply other threads:[~2019-12-21 19:38 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 9:44 [PATCH v7 00/12] Support ROHM BD71828 PMIC Matti Vaittinen
2019-12-19 9:44 ` [PATCH v7 01/12] dt-bindings: leds: ROHM BD71282 PMIC LED driver Matti Vaittinen
2019-12-21 19:26 ` Pavel Machek
2019-12-19 9:46 ` [PATCH v7 02/12] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2019-12-19 9:58 ` Vaittinen, Matti
2019-12-19 14:36 ` Lee Jones
2019-12-20 6:33 ` Vaittinen, Matti
2019-12-20 10:55 ` Lee Jones
2019-12-19 9:46 ` [PATCH v7 03/12] mfd: rohm PMICs - use platform_device_id to match MFD sub-devices Matti Vaittinen
2019-12-19 9:49 ` [PATCH v7 04/12] mfd: bd718x7: Add compatible for BD71850 Matti Vaittinen
2019-12-19 9:50 ` [PATCH v7 05/12] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-12-19 9:51 ` [PATCH v7 06/12] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-12-19 9:52 ` [PATCH v7 07/12] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-12-24 6:54 ` Stephen Boyd
2019-12-19 9:52 ` [PATCH v7 08/12] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-12-19 9:53 ` [PATCH v7 09/12] rtc: bd70528: add BD71828 support Matti Vaittinen
2019-12-19 9:53 ` [PATCH v7 10/12] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-12-19 9:54 ` [PATCH v7 11/12] leds: Add common LED binding parsing support to LED class/core Matti Vaittinen
2019-12-21 19:37 ` Pavel Machek [this message]
2019-12-23 10:35 ` Vaittinen, Matti
2019-12-27 11:29 ` Vaittinen, Matti
2019-12-27 11:51 ` Vaittinen, Matti
2019-12-30 7:36 ` Vaittinen, Matti
2019-12-19 9:54 ` [PATCH v7 12/12] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
2019-12-21 19:48 ` Pavel Machek
2019-12-27 9:43 ` Vaittinen, Matti
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=20191221193758.GJ32732@amd \
--to=pavel@ucw.cz \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mazziesaccount@gmail.com \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@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.