From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> To: Felix Brack <fb-GovowT2ENgg@public.gmane.org> Cc: Jacek Anaszewski <jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, riku.voipio-X3B1VOXEql0@public.gmane.org, linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org Subject: default-state LED property (was Re: [PATCH v2] Extend pca9532 device tree support) Date: Fri, 7 Apr 2017 13:57:54 +0200 [thread overview] Message-ID: <20170407115754.GA4756@amd> (raw) In-Reply-To: <ec012568-f540-4e87-d8c4-4065fbcd1c2a-GovowT2ENgg@public.gmane.org> [-- Attachment #1: Type: text/plain, Size: 2311 bytes --] Hi! > >> This seems to look for "pwm0" and "pwm1" strings, which do not seem to > >> be documented. > >> > >> Plus... is it useful to have default-state? We already have default > >> trigger. If we keep the value by default (on PC, we do something like > >> that) this patch should not be neccessary? > > > > Thanks for the heads-up. Dropping the patch for now. > > No, please do not drop the patch. > > > I guess that pwm0/1 got propagated to v2 by an omission. > > Yes, I agree. However the two strings do not break anything and behave > analog to the 'on' or 'keep' string. Though this code could be removed > if absolutely necessary. An alternative would be to add a description > for the strings. Just to be clear: these strings have nothing to with > the exposition of device specific registers to the DT. Well, they should be removed. No need to keep surprises in code. > > Regarding default-on: Felix, do you have any use case that require > > default-on set to "keep"? > > This patch is not about 'default-on' which is a value that could be > assigned to the property 'linux,default-trigger' (according to DT > bindings documentation file 'common.txt'). > My patch does not introduce anything new with the'keep' state, it rather > completes the existing bindings according to the description in > Documentation/devicetree/bindings/leds/common.txt which states: Hmm, that was introduce by 1d1a77ddc8acfa3d506f1958e09a12085e71fc69 . I don't quite like the patch -- it duplicates default-trigger functionality without good reason. IMO we should 1) keep the led state by default 2) deprecate the default-state property 3) use default-triggers to emulate the functionality if someone really needs it. > One of my use cases is to turn a LED on by U-Boot. This LED must remain > on until eventually, under certain conditions, some userland code > changes it's state. > Setting 'default-state' to 'keep' is how you can sort of tell the > kernel, or better the driver, 'not to initialize the LED' which would > turn it off. Yes, that's reasonable. Perhaps 'keep' should be the default. 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 --]
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz> To: Felix Brack <fb@ltec.ch> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>, rpurdie@rpsys.net, mark.rutland@arm.com, riku.voipio@iki.fi, linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linus.walleij@linaro.org, robh@kernel.org Subject: default-state LED property (was Re: [PATCH v2] Extend pca9532 device tree support) Date: Fri, 7 Apr 2017 13:57:54 +0200 [thread overview] Message-ID: <20170407115754.GA4756@amd> (raw) In-Reply-To: <ec012568-f540-4e87-d8c4-4065fbcd1c2a@ltec.ch> [-- Attachment #1: Type: text/plain, Size: 2311 bytes --] Hi! > >> This seems to look for "pwm0" and "pwm1" strings, which do not seem to > >> be documented. > >> > >> Plus... is it useful to have default-state? We already have default > >> trigger. If we keep the value by default (on PC, we do something like > >> that) this patch should not be neccessary? > > > > Thanks for the heads-up. Dropping the patch for now. > > No, please do not drop the patch. > > > I guess that pwm0/1 got propagated to v2 by an omission. > > Yes, I agree. However the two strings do not break anything and behave > analog to the 'on' or 'keep' string. Though this code could be removed > if absolutely necessary. An alternative would be to add a description > for the strings. Just to be clear: these strings have nothing to with > the exposition of device specific registers to the DT. Well, they should be removed. No need to keep surprises in code. > > Regarding default-on: Felix, do you have any use case that require > > default-on set to "keep"? > > This patch is not about 'default-on' which is a value that could be > assigned to the property 'linux,default-trigger' (according to DT > bindings documentation file 'common.txt'). > My patch does not introduce anything new with the'keep' state, it rather > completes the existing bindings according to the description in > Documentation/devicetree/bindings/leds/common.txt which states: Hmm, that was introduce by 1d1a77ddc8acfa3d506f1958e09a12085e71fc69 . I don't quite like the patch -- it duplicates default-trigger functionality without good reason. IMO we should 1) keep the led state by default 2) deprecate the default-state property 3) use default-triggers to emulate the functionality if someone really needs it. > One of my use cases is to turn a LED on by U-Boot. This LED must remain > on until eventually, under certain conditions, some userland code > changes it's state. > Setting 'default-state' to 'keep' is how you can sort of tell the > kernel, or better the driver, 'not to initialize the LED' which would > turn it off. Yes, that's reasonable. Perhaps 'keep' should be the default. 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:[~2017-04-07 11:57 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-30 13:33 [PATCH v2] Extend pca9532 device tree support Felix Brack 2017-04-02 14:41 ` Jacek Anaszewski [not found] ` <b54c77d5-b4f7-9517-8c5b-9200c766204a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-04-06 15:50 ` Pavel Machek 2017-04-06 15:50 ` Pavel Machek 2017-04-06 19:00 ` Jacek Anaszewski 2017-04-06 19:00 ` Jacek Anaszewski [not found] ` <a8509d26-6e35-e2f7-9784-90f3c54accbf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-04-07 8:22 ` Felix Brack 2017-04-07 8:22 ` Felix Brack [not found] ` <ec012568-f540-4e87-d8c4-4065fbcd1c2a-GovowT2ENgg@public.gmane.org> 2017-04-07 11:57 ` Pavel Machek [this message] 2017-04-07 11:57 ` default-state LED property (was Re: [PATCH v2] Extend pca9532 device tree support) Pavel Machek 2017-04-09 12:37 ` [PATCH v2] Extend pca9532 device tree support Jacek Anaszewski 2017-04-09 12:37 ` Jacek Anaszewski [not found] ` <2f3815ab-71e1-b63d-aba8-167e11f719de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2017-04-09 13:11 ` Felix Brack 2017-04-09 13:11 ` Felix Brack
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=20170407115754.GA4756@amd \ --to=pavel-+zi9xunit7i@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=fb-GovowT2ENgg@public.gmane.org \ --cc=jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=riku.voipio-X3B1VOXEql0@public.gmane.org \ --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.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: linkBe 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.