From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>,
"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"phil.edworthy@renesas.com" <phil.edworthy@renesas.com>,
"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
"dmurphy@ti.com" <dmurphy@ti.com>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"mchehab+samsung@kernel.org" <mchehab+samsung@kernel.org>,
"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mturquette@baylibre.com" <mturquette@baylibre.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"wsa+renesas@sang-engineering.com"
<wsa+renesas@sang-engineering.com>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"a.zummo@towertech.it" <a.zummo@towertech.it>,
"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
"hofrat@osadl.org" <hofrat@osadl.org>,
"lee.jones@linaro.org" <lee.jones@linaro.org>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"broonie@kernel.org" <broonie@kernel.org>,
"sboyd@kernel.org" <sboyd@kernel.org>
Subject: Re: [PATCH v5 15/16] leds: Add common LED binding parsing support to LED class/core
Date: Tue, 19 Nov 2019 20:30:44 +0100 [thread overview]
Message-ID: <d9521d73-82c5-46c3-fccc-333234914f4a@gmail.com> (raw)
In-Reply-To: <4c03b7cec4d4417ba3c60b9d8a333ddd4cfa79ac.camel@fi.rohmeurope.com>
Hi Matti,
On 11/19/19 8:21 AM, Vaittinen, Matti wrote:
> 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 ;)
If you do not plan on spending too much time on contributing this
set then I propose adhering to the currently used parsing schema :-)
And you have to know that from this development cycle I handed
over LED tree maintenance to Pavel Machek, so you will require
to have his acceptance in the first place.
>> 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 ;)
I personally would prefer to do the massive driver update to using
the new mechanism. I know that this is time consuming but we are not
in a hurry.
> 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
You do not need hardware to test DT parsing as I mentioned before,
so I don't see too much risk involved.
> 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 :)
If you want to introduce good, robust mechanism, then it should be
tested against widest possible spectrum of use cases.
> 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).
As mentioned before - I no longer apply patches so you will need to
consult Pavel, but I bet he will have similar opinion.
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2019-11-19 19:31 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-18 6:53 [PATCH v5 00/16] Support ROHM BD71828 PMIC Matti Vaittinen
2019-11-18 6:53 ` [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen
2019-11-18 16:25 ` Mark Brown
2019-11-18 18:03 ` Vaittinen, Matti
2019-11-19 18:13 ` Mark Brown
2019-11-19 18:51 ` Vaittinen, Matti
2019-11-19 19:36 ` Mark Brown
2019-11-29 7:48 ` Vaittinen, Matti
2019-11-29 12:09 ` Mark Brown
2019-12-02 7:57 ` Vaittinen, Matti
2019-12-02 13:11 ` Mark Brown
2019-12-02 14:02 ` Vaittinen, Matti
2019-12-04 12:47 ` Mark Brown
2019-12-04 13:13 ` Vaittinen, Matti
2019-12-04 14:14 ` Mark Brown
2019-12-10 10:39 ` Vaittinen, Matti
2019-12-10 11:14 ` Vaittinen, Matti
2019-12-10 12:11 ` Mark Brown
2019-12-10 12:41 ` Vaittinen, Matti
2019-12-10 12:45 ` Mark Brown
2019-12-10 13:07 ` Vaittinen, Matti
2019-11-22 22:48 ` Rob Herring
2019-11-18 6:54 ` [PATCH v5 02/16] dt-bindings: leds: ROHM BD71282 PMIC LED driver Matti Vaittinen
2019-11-22 23:00 ` Rob Herring
2019-11-18 6:54 ` [PATCH v5 03/16] dt-bindings: mfd: Document ROHM BD71828 bindings Matti Vaittinen
2019-11-22 23:05 ` Rob Herring
2019-11-18 6:55 ` [PATCH v5 04/16] mfd: rohm PMICs - use platform_device_id to match MFD sub-devices Matti Vaittinen
2019-11-18 6:55 ` [PATCH v5 05/16] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-11-18 6:56 ` [PATCH v5 06/16] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-11-18 6:56 ` [PATCH v5 07/16] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-11-18 6:57 ` [PATCH v5 08/16] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-11-18 6:57 ` [PATCH v5 09/16] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-11-18 16:20 ` Mark Brown
2019-11-19 9:12 ` Vaittinen, Matti
2019-11-18 6:58 ` [PATCH v5 10/16] gpio: devres: Add devm_gpiod_get_parent_array Matti Vaittinen
2019-11-19 14:43 ` Linus Walleij
2019-11-19 17:54 ` Vaittinen, Matti
2019-11-21 14:13 ` Linus Walleij
2019-11-18 6:59 ` [PATCH v5 11/16] docs: driver-model: Add missing managed GPIO array get functions Matti Vaittinen
2019-11-18 6:59 ` [PATCH v5 12/16] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-11-18 7:00 ` [PATCH v5 13/16] rtc: bd70528 add BD71828 support Matti Vaittinen
2019-12-10 13:24 ` Alexandre Belloni
2019-11-18 7:01 ` [PATCH v5 14/16] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-11-18 9:22 ` Bartosz Golaszewski
2019-11-18 7:03 ` [PATCH v5 15/16] leds: Add common LED binding parsing support to LED class/core Matti Vaittinen
2019-11-18 21:55 ` Jacek Anaszewski
2019-11-19 7:21 ` Vaittinen, Matti
2019-11-19 19:30 ` Jacek Anaszewski [this message]
2019-11-20 7:31 ` Vaittinen, Matti
2019-11-19 14:23 ` Vaittinen, Matti
2019-11-18 7:03 ` [PATCH v5 16/16] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
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=d9521d73-82c5-46c3-fccc-333234914f4a@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=Matti.Vaittinen@fi.rohmeurope.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=hkallweit1@gmail.com \
--cc=hofrat@osadl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-doc@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=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=mazziesaccount@gmail.com \
--cc=mchehab+samsung@kernel.org \
--cc=mturquette@baylibre.com \
--cc=pavel@ucw.cz \
--cc=phil.edworthy@renesas.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/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).