Message-ID: <4c03b7cec4d4417ba3c60b9d8a333ddd4cfa79ac.camel@fi.rohmeurope.com>
Date:   Tue, 19 Nov 2019 07:21:13 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>
CC:     "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "hofrat@...dl.org" <hofrat@...dl.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "pavel@....cz" <pavel@....cz>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>
Subject: Re: [PATCH v5 15/16] leds: Add common LED binding parsing support
 to LED class/core

Hello Jacek,

On Mon, 2019-11-18 at 22:55 +0100, Jacek Anaszewski wrote:
> Hi Matti,
> 
> Thank you for the patch. If your driver does not depend
> on it then please send is separately.

The BD71828 depends on device-tree node look-up. It does not utilize
the common property parsing. I could of course do the child dt-node
walking in BD71828 driver - but it kind of breaks my motivation to do
the LED core improvement if I anyways need to do the parsing in BD71828
driver ;)

>  Besides, we would require
> to convert many of current LED drivers to verify how the
> proposed parsing mechanism will work with them.

I see the risk you are pointing out. And I actually think we could
default to old mechanism if of_match or match_property is not given
(for now). I could then see the existing drivers who use init_data -
and ensure those are initializing the new match_property and of_match
in init_data with 0. That would be quite trivial task.

That would allow us to convert and test existing drivers one-by-one
while allowing new drivers to offload the LED node look-up and common
property parsing to LED core. No risk, but less drivers to convert in
the future - and simpler drivers to maintain when all of them do not
need to duplicate node look-up or basic property parsing ;)

To make this more concrete:

We can only do the new DT node look-up if either
if (init_data->match_property.name && init_data->match_property.size)
or
if (init_data->of_match)
That would keep the node-lookup same for all existing drivers.

Eg, 
led_find_fwnode could for now just do:

struct fwnode_handle *led_find_fwnode(struct device *parent,
				      struct led_init_data *init_data)
{
	/*
        * This should never be called W/O init data.
	*/
	if (!init_data)
		return NULL;

	/*
	 * For old drivers which do not populate new match information
	 * just directly use the given init_data->fwnode no matter if
	 * it is NULL or not. - as old functionality did.
	 */
	if ( (!init_data->match_property.name ||
	      !init_data->match_property.size) && !init_data->of_match)
		return init_data->fwnode;

	/* match information was given - do node look-up */
	...
}

Furthermore, the common property parsing could also be (for now) done
only if match data is given:

	/*
	 * For now only allow core to parse DT properties if
	 * parsing is explicitly requested by driver or if core has
	 * found new match data from init_data and then set the flag
	 */
	if (INVENT_A_COOL_NEW_FLAG_NAME_HERE)
		led_add_props(led_cdev, &props);

or just simply: 
	if ((init_data->match_property.name &&
	    init_data->match_property.size) || init_data->of_match)
		led_add_props(led_cdev, &props);

(but this won't allow driver to ask for common parsing even if it was
verified for this drv to work - hence I like the flag better)

And if you don't feel confident I can even drop the "common property
parsing" from the series and leave only the "node look-up if match-data 
was given" to it.

Anyways, I would like to introduce this support while I am working with
the BD71828 driver which really has the LEDs - but I can modify the
patch series so that it only impacts to drivers which implement the new
match data in init_data and leave old drivers to be converted one-by-
one when they can be tested.

>  I've been testing
> my LED name composition series using QEMU and stubbing things in
> drivers where necessary and I propose to use the same approach
> in this case.

I don't plan to do any mass-conversion as it is somewhat risky. I can
do conversion to some of the drivers (simple ones which I can
understand without too much of pain) - and ask if anyone having access
to actual HW with LEDs could be kind enough to test the patch for the
device. Tested drivers can then be taken in-tree as examples. And who
knows, maybe there is some developers looking for a hobby project with
access to LED controller to help with the rest ;) I don't have the
ambition to change all of the LED drivers but I think I can give my 10
cents by contributing the mechanism and doing few examples :)

Anyways, please let me know if you think you could accept patch which
won't change existing driver functionality - but allows new drivers to
not duplicate the code. Else I'll just duplicate the lookup code in one
more driver and hope I don't have another PMIC with LED controller on
my table too soon...

(I am having "some" pressure to do few other tasks I recently got. So I
am afraid I won't have too much time to invest on LEDs this year :(
Thus setting up the qemu and starting with stubbing is really not an
option for me at this phase).

Br,
	Matti Vaittinen


> 
> Best regards,
> Jacek Anaszewski
> 
> On 11/18/19 8:03 AM, Matti Vaittinen wrote:
> > Qucik grep for 'for_each' or 'linux,default-trigger' or
> > 'default-state' under drivers/leds can tell quite a lot. It seems
> > multiple LED controller drivers implement the very similar looping
> > through the child nodes in order to locate the LED nodes and read
> > and support the common LED dt bindings. Implementing this same
> > stuff for all LED controllers gets old pretty fast.
> > 
> > This commit adds support for locating the LED node (based on known
> > node names - or linux,led-compatible property) and handling of
> > few common LED properties.
> > 
> > linux,default-trigger,
> > default-state (with the exception of keep),
> > 
> > (in addition to already handled
> > function-enumerator,
> > function,
> > color
> > and label).
> > 
> > Regarding the node look-up: If no init_data is given, then no
> > node-lookup is done and cdev name is used as such.
> > 
> > If init_data is goven but no starting point for node lookup - then
> > (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
> > is given then device's own node or passed starting point are used
> > as
> > such.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
> > ---
> > 
> > Changes from v4:
> > Fixed issues reported by Dan Carpenter and kbuild-bot.
> > (leftover kfree and uninitialized return value)
> > 
> >  drivers/leds/led-class.c |  88 ++++++++++++--
> >  drivers/leds/led-core.c  | 246 +++++++++++++++++++++++++++++++--
> > ------
> >  include/linux/leds.h     |  90 ++++++++++++--
> >  3 files changed, 359 insertions(+), 65 deletions(-)
> > 

Powered by blists - more mailing lists