Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"info@metux.net" <info@metux.net>, "pavel@ucw.cz" <pavel@ucw.cz>,
	"dmurphy@ti.com" <dmurphy@ti.com>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
	"linux-rtc@vger.kernel.org" <linux-rtc@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"mchehab+samsung@kernel.org" <mchehab+samsung@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"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>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
	"a.zummo@towertech.it" <a.zummo@towertech.it>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"phil.edworthy@renesas.com" <phil.edworthy@renesas.com>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"hofrat@osadl.org" <hofrat@osadl.org>
Subject: Re: [PATCH v5 15/16] leds: Add common LED binding parsing support to LED class/core
Date: Wed, 20 Nov 2019 07:31:07 +0000
Message-ID: <6d6e42fb16bfc863631f84191123ad849d457113.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <d9521d73-82c5-46c3-fccc-333234914f4a@gmail.com>


On Tue, 2019-11-19 at 20:30 +0100, Jacek Anaszewski wrote:
> 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 :-)

I have no objections on doing few iterations of the patches. And I tend
to take care of problems my changes cause. So I am prepared to spend
the required time fixing the node look-up and common property parsing
for drivers I do break. What I am not prepared is to change and test
all of the existing drivers - so it's better to not promise such :)

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

Well, then I for sure wait for Pavel's take on this. In general I have
had some positive feedback about doing the DT node look-up and common
property parsing in a centralized manner in LED core. So maybe also
Pavel sees the value of adding this now for new drivers - instead of
adding one more driver with copy-paste node look-up code. I want to
thank you for all the comments though, it's nice that you have been
active on this topic!

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

I understand the preference of massive update - but I also know that if
we wait for someone to do a massive update and neglect improvements
done in small steps, then there is a risk that there won't be any
updates at all...

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

Yes - if you have the time to test all the drivers at once - and
assuming you  don't do some silly mistake there. Final verification
should always be done in HW. But as I said, I want to ensure all the
drivers I convert to new mechanism will work (the best I can) - and as
I can't test all the drivers I won't do mass-conversion. I have offered
a initial solution in the patch (and suggested reduced version to
mitigate the risk of breaking anything in this email) - and I see this
beneficial and as a good starting point enabling the rest of the
improvements. But as you said, we need also Pavel's take on this.

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

Yes. OTOH, if the mechanism is sub-optimal, then the beauty of open
source is that it can be improved. Preparing in advance for something
that never happens is also a waste. But I guess we don't need to
discuss this philosphy here :)

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

Who knows, maybe he can see this differently :) Thanks anyways!

Br,
	Matti Vaittinen

  reply index

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
2019-11-20  7:31         ` Vaittinen, Matti [this message]
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 publically 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=6d6e42fb16bfc863631f84191123ad849d457113.camel@fi.rohmeurope.com \
    --to=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=info@metux.net \
    --cc=jacek.anaszewski@gmail.com \
    --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

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git