Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 10/06/2017 01:48 PM, Pavel Machek wrote: > On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote: >> On 09/20/2017 01:29 PM, Pavel Machek wrote: >>>>>>> I'd leave the decision to the user. We could add a note to the >>>>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface >>>>>>> should be preferable choice for driving vibrate devices. >>>>>>> However only if following conditions are met: >>>>>> >>>>>> What I meant is that it is my decision, as a LED subsystem maintainer, >>>>>> to accept the addition of a note about some other subsystem offering >>>>>> an equivalent or even better substitute of the feature being available >>>>>> in the subsystem I am responsible for. And I will accept such a patch >>>>>> only if mentioned conditions are met. >>>>> >>>>> Having the wording in documentation does not in any way stops Android >>>>> folks from continuing [ab]using the transient trigger. But this is >>>>> their choice. The purpose of documentation is to document the best >>>>> practices, not all possible crazy solutions one can come up with. >>>> >>>> Yes. but if the information has been in place for years, we can't >>>> just remove it without giving an instruction on how to use the >>>> substitute. >>> >>> I gave you information how to use the substitute. >> >> That information was quite vague. I'd like to see a sample application >> in tools/input. > > So please write it. This is my demand as a reviewer. I've already laid out the conditions under which I'll accept the patch. It seems that you're proficient in the subject enough to cope with this task. >>> I already suggested patch to documentation. If you do the same, maybe >>> we can agree on documentation update. >> >> Your patch was just removing few lines of documentation. I'd expect more >> empathic approach to the current users, i.e.: >> >> - pointer to the sample application in tools/input showing how to >> setup gpio driven vibrate device with use of ff interface with >> 1kHz vibration frequency. > > Yes, my patch is removing dangerously misleading documentation about > LED subsystem. It's neither dangerous nor misleading. > Please apply it. Right after I'll get the patch with the tool showing how to use input subsystem to achieve the same effect as with use of ledtrig-transient. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 09/20/2017 01:29 PM, Pavel Machek wrote: >>>>> I'd leave the decision to the user. We could add a note to the >>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface >>>>> should be preferable choice for driving vibrate devices. >>>>> However only if following conditions are met: >>>> >>>> What I meant is that it is my decision, as a LED subsystem maintainer, >>>> to accept the addition of a note about some other subsystem offering >>>> an equivalent or even better substitute of the feature being available >>>> in the subsystem I am responsible for. And I will accept such a patch >>>> only if mentioned conditions are met. >>> >>> Having the wording in documentation does not in any way stops Android >>> folks from continuing [ab]using the transient trigger. But this is >>> their choice. The purpose of documentation is to document the best >>> practices, not all possible crazy solutions one can come up with. >> >> Yes. but if the information has been in place for years, we can't >> just remove it without giving an instruction on how to use the >> substitute. > > I gave you information how to use the substitute. That information was quite vague. I'd like to see a sample application in tools/input. > I already suggested patch to documentation. If you do the same, maybe > we can agree on documentation update. Your patch was just removing few lines of documentation. I'd expect more empathic approach to the current users, i.e.: - pointer to the sample application in tools/input showing how to setup gpio driven vibrate device with use of ff interface with 1kHz vibration frequency. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 09/19/2017 11:07 PM, Dmitry Torokhov wrote: > On Tue, Sep 19, 2017 at 1:45 PM, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> On 09/19/2017 12:29 AM, Dmitry Torokhov wrote: >>> On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski >>> <jacek.anaszew...@gmail.com> wrote: >>>> Hi, >>>> >>>> On 09/17/2017 08:22 PM, Pavel Machek wrote: >>>>> Hi! >>>>> >>>>>>> If your objection is that FF is not easily engaged from the shell - >>>>>>> yes, but I do not think that actual users who want to do vibration do >>>>>>> that via shell either. On the other hand, can you drop privileges and >>>>>>> still allow a certain process control your vibrator via LED interface? >>>>>>> With FF you can pass an FD to whoever you deem worthy and later revoke >>>>>>> access. >>>>>>> >>>>>>> IOW sysfs interfaces are nice for quick hacks, but when you want to >>>>>>> use them in real frameworks, where you need to think about proper >>>>>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit >>>>>>> better. >>>>>> >>>>>> I'd leave the decision to the user. We could add a note to the >>>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface >>>>>> should be preferable choice for driving vibrate devices. >>>>> >>>>> We don't want to leave decision to the user; because then we'll end up >>>>> with userland applications having to support _both_ interfaces. >>>> >>>> This state has lasted for five years now. I don't recall any >>>> complaints. Do you? >>> >>> I was telling Shuah 5 years ago that using LED for what she wanted was >>> not the right idea. I even made a patch for her implementing the >>> functionality they were after: https://lkml.org/lkml/2012/4/10/41 >>> >>> Unfortunately this still somehow made it into the kernel. I guess the >>> angle of having LEDs auto-shutoff makes sense still; using it for >>> haptics does not. >> >> Thanks for the pointer. >> >>>> >>>>> Plus, it is not really your decision. Dmitry is maintainer of input >>>>> subsystem, input was doing force feedback for 10+ years, and he >>>>> already made a decision. >>>> >>>> It seems that you applied a fait accompli method here. >>>> >>>> Actually could you share what the decision is? AFAIK we're not >>>> discussing here any patch for the input subsystem? >>> >>> No, we are discussing if it makes sense encouraging 2nd interface for >>> haptic. We are also discussing whether it makes sense to implement new >>> features in LED subsystem that seem to be only beneficial for this >>> interface (I assume the "normal" LEDs do not need that kind of >>> precision?). >> >> As you noticed in one of the previous messages, thanks to the leds-gpio >> driver we can drive a wide range of devices from the level of >> LED subsystem. > > Yes, you can create whatever. It goes normally as this: crap, we need > to ship something really soon, factory build is a week from now and we > have absolutely no time to think about proper interface. Hey, let's > quickly bolt on some quirk on an unrelated interface, it almost does > what we want. We do not care that out use case does not really fit > here, our custom one-off userspace will know how to deal with it. > >> LED trigger mechanism makes it even more versatile, >> and, in this area, even somehow akin to the GPIO subsystem. In the >> future we could think of making this trigger mechanism accessible by >> the two and thus any initiative aiming at enhancing it shouldn't be >> discouraged. > > If there is a use case that would benefit from this functionality: > certainly. Do you have one in mind? Few minutes of googling gave below results. People are doing that anyway so adding EXPERIMENTAL support in mainline maybe wouldn't be such a wrong idea. It seems that there would be many testers. [0] https://stackoverflow.com/questions/16534668/how-to-generate-a-steady-37khz-gpio-trigger-from-inside-linux-kernel [1] https://discuss.96boards.org/t/generate-high-frequency-square-wave-on-a-gpio-pin/2615/4 [2] https://stackoverflow.com/questions/4634991/how-to-generate-100khz-clock-signal-in-liunx-kernel-module-with-bit-banging [3] http://www.friendlyarm.net/forum/topic/3566 [4] http://codeandlife.com/2016/04/18/beaglebone-black-gpio-benchmark/ [5] https://www.raspberrypi.org/forums/viewtopic.php?t=56748 -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
Hi, On 09/20/2017 01:15 PM, Pavel Machek wrote: > On Mon 2017-09-18 22:43:40, Jacek Anaszewski wrote: >> Hi, >> >> On 09/17/2017 07:50 PM, Pavel Machek wrote: >>> Hi! >>> >>>>>> Do you think such an improvement could be harmful in some way, >>>>>> even if it was made optional? >>>>> >>>>> Of course, we can make LED timing accurate down to microseconds. It will >>>>> mean increased overhead -- for "improvement" human can not perceive. >>>>> >>>>> If someone has problems with LED delays not being accurate enough... we >>>>> may want to fix it. But that is not the case here, is it? >>>> >>>> AFAIR David was mentioning that the hr_timer support is perceivable >>> >>> He said that hr_timer support is perceivable _when he is driving >>> vibration motor_. Which he should not do in the first place. >>> >>> Yes, if the difference is perceivable with LED in non-crazy >>> configuration (*), we can take the patch. Is it? Do we have someone >>> not from Google observing it? >>> >>> (*) emulating PWM using blink trigger counts as "crazy" :-) >> >> How about adding CONFIG_LED_TRIGGERS_HR_TIMER_SUPPORT, guarding the >> hr timer support in triggers (timer trigger could also benefit from it) >> with it, and adding "(EXPERIMENTAL)" tag to the config description? > > Why would we want to add code in the LED subsystem that is useless for > LEDs? It could be used for software pwm trigger, there has been at least one an attempt to add such [0]. [0] https://lkml.org/lkml/2015/4/27/493 -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 09/19/2017 12:29 AM, Dmitry Torokhov wrote: > On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> Hi, >> >> On 09/17/2017 08:22 PM, Pavel Machek wrote: >>> Hi! >>> >>>>> If your objection is that FF is not easily engaged from the shell - >>>>> yes, but I do not think that actual users who want to do vibration do >>>>> that via shell either. On the other hand, can you drop privileges and >>>>> still allow a certain process control your vibrator via LED interface? >>>>> With FF you can pass an FD to whoever you deem worthy and later revoke >>>>> access. >>>>> >>>>> IOW sysfs interfaces are nice for quick hacks, but when you want to >>>>> use them in real frameworks, where you need to think about proper >>>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit >>>>> better. >>>> >>>> I'd leave the decision to the user. We could add a note to the >>>> Documentation/leds/ledtrig-transient.txt that force feedback interface >>>> should be preferable choice for driving vibrate devices. >>> >>> We don't want to leave decision to the user; because then we'll end up >>> with userland applications having to support _both_ interfaces. >> >> This state has lasted for five years now. I don't recall any >> complaints. Do you? > > I was telling Shuah 5 years ago that using LED for what she wanted was > not the right idea. I even made a patch for her implementing the > functionality they were after: https://lkml.org/lkml/2012/4/10/41 > > Unfortunately this still somehow made it into the kernel. I guess the > angle of having LEDs auto-shutoff makes sense still; using it for > haptics does not. Thanks for the pointer. >> >>> Plus, it is not really your decision. Dmitry is maintainer of input >>> subsystem, input was doing force feedback for 10+ years, and he >>> already made a decision. >> >> It seems that you applied a fait accompli method here. >> >> Actually could you share what the decision is? AFAIK we're not >> discussing here any patch for the input subsystem? > > No, we are discussing if it makes sense encouraging 2nd interface for > haptic. We are also discussing whether it makes sense to implement new > features in LED subsystem that seem to be only beneficial for this > interface (I assume the "normal" LEDs do not need that kind of > precision?). As you noticed in one of the previous messages, thanks to the leds-gpio driver we can drive a wide range of devices from the level of LED subsystem. LED trigger mechanism makes it even more versatile, and, in this area, even somehow akin to the GPIO subsystem. In the future we could think of making this trigger mechanism accessible by the two and thus any initiative aiming at enhancing it shouldn't be discouraged. >>>> However only if following conditions are met: >>>> - force feedback driver supports gpio driven devices >>>> - there is sample application in tools/input showing how to >>>> setup gpio driven vibrate device with use of ff interface >>>> - it will be possible to setup vibrate interval with 1ms accuracy, >>>> similarly to what the discussed patch allows to do >>> >>> I agree these would be nice. Interested parties are welcome to help >>> there. But I don't think this should have any impact on LED >>> susbystem. Force feedback just does not belong to LED subsystem. >> >> You cut off important piece of my text from the beginning of this >> paragraph. It was: >> >>> I'd leave the decision to the user. We could add a note to the >>> Documentation/leds/ledtrig-transient.txt that force feedback interface >>> should be preferable choice for driving vibrate devices. >>> However only if following conditions are met: >> >> What I meant is that it is my decision, as a LED subsystem maintainer, >> to accept the addition of a note about some other subsystem offering >> an equivalent or even better substitute of the feature being available >> in the subsystem I am responsible for. And I will accept such a patch >> only if mentioned conditions are met. > > Having the wording in documentation does not in any way stops Android > folks from continuing [ab]using the transient trigger. But this is > their choice. The purpose of documentation is to document the best > practices, not all possible crazy solutions one can come up with. Yes. but if the information has been in place for years, we can't just remove it without giving an instruction on how to use the substitute. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
Hi, On 09/17/2017 08:22 PM, Pavel Machek wrote: > Hi! > >>> If your objection is that FF is not easily engaged from the shell - >>> yes, but I do not think that actual users who want to do vibration do >>> that via shell either. On the other hand, can you drop privileges and >>> still allow a certain process control your vibrator via LED interface? >>> With FF you can pass an FD to whoever you deem worthy and later revoke >>> access. >>> >>> IOW sysfs interfaces are nice for quick hacks, but when you want to >>> use them in real frameworks, where you need to think about proper >>> namespaces, isolation, etc, etc, other kinds of interfaces might suit >>> better. >> >> I'd leave the decision to the user. We could add a note to the >> Documentation/leds/ledtrig-transient.txt that force feedback interface >> should be preferable choice for driving vibrate devices. > > We don't want to leave decision to the user; because then we'll end up > with userland applications having to support _both_ interfaces. This state has lasted for five years now. I don't recall any complaints. Do you? > Plus, it is not really your decision. Dmitry is maintainer of input > subsystem, input was doing force feedback for 10+ years, and he > already made a decision. It seems that you applied a fait accompli method here. Actually could you share what the decision is? AFAIK we're not discussing here any patch for the input subsystem? >> However only if following conditions are met: >> - force feedback driver supports gpio driven devices >> - there is sample application in tools/input showing how to >> setup gpio driven vibrate device with use of ff interface >> - it will be possible to setup vibrate interval with 1ms accuracy, >> similarly to what the discussed patch allows to do > > I agree these would be nice. Interested parties are welcome to help > there. But I don't think this should have any impact on LED > susbystem. Force feedback just does not belong to LED subsystem. You cut off important piece of my text from the beginning of this paragraph. It was: > I'd leave the decision to the user. We could add a note to the > Documentation/leds/ledtrig-transient.txt that force feedback interface > should be preferable choice for driving vibrate devices. > However only if following conditions are met: What I meant is that it is my decision, as a LED subsystem maintainer, to accept the addition of a note about some other subsystem offering an equivalent or even better substitute of the feature being available in the subsystem I am responsible for. And I will accept such a patch only if mentioned conditions are met. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
Hi, On 09/17/2017 07:50 PM, Pavel Machek wrote: > Hi! > >>>> Do you think such an improvement could be harmful in some way, >>>> even if it was made optional? >>> >>> Of course, we can make LED timing accurate down to microseconds. It will >>> mean increased overhead -- for "improvement" human can not perceive. >>> >>> If someone has problems with LED delays not being accurate enough... we >>> may want to fix it. But that is not the case here, is it? >> >> AFAIR David was mentioning that the hr_timer support is perceivable > > He said that hr_timer support is perceivable _when he is driving > vibration motor_. Which he should not do in the first place. > > Yes, if the difference is perceivable with LED in non-crazy > configuration (*), we can take the patch. Is it? Do we have someone > not from Google observing it? > > Pavel > (*) emulating PWM using blink trigger counts as "crazy" :-) How about adding CONFIG_LED_TRIGGERS_HR_TIMER_SUPPORT, guarding the hr timer support in triggers (timer trigger could also benefit from it) with it, and adding "(EXPERIMENTAL)" tag to the config description? -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
Hi, On 09/16/2017 03:58 AM, Pavel Machek wrote: > Hi! > >>>>>> These patch series add the LED_BRIGHTNESS_FAST flag support for >>>>>> ledtrig-transient to use hrtimer so that platforms with high-resolution >>>>>> timer >>>>>> support can have better accuracy in the trigger duration timing. The >>>>>> need for > ... >>> If we want to say "lets move all vibrations from input to LED >>> subsystem"... I don't think that is good idea, but its a valid >>> discussion. Some good reasons would be needed. >>> >>> But having half devices use one interface and half use different one >>> is just bad... especially when only reason to do it that way is >>> "David wants to do it that way, android library made a mistake and he >>> now wants it to propagate to whole world". >> >> This is not the only reason. Adding hr_timer support to >> ledtrig-transient (and similarly to ledtrig-timer) would allow >> to increase the accuracy and stability of delay_on/delay_off >> intervals at low values. >> >> Do you think such an improvement could be harmful in some way, >> even if it was made optional? > > Of course, we can make LED timing accurate down to microseconds. It will > mean increased overhead -- for "improvement" human can not perceive. > > If someone has problems with LED delays not being accurate enough... we > may want to fix it. But that is not the case here, is it? AFAIR David was mentioning that the hr_timer support is perceivable -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 09/16/2017 12:30 AM, Dmitry Torokhov wrote: > On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pa...@ucw.cz> wrote: >>>> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote: >>>>> Hi David and Pavel, >>>>> >>>>> On 09/13/2017 10:20 PM, Pavel Machek wrote: >>>>>> Hi! >>>>>> >>>>>>> These patch series add the LED_BRIGHTNESS_FAST flag support for >>>>>>> ledtrig-transient to use hrtimer so that platforms with high-resolution >>>>>>> timer >>>>>>> support can have better accuracy in the trigger duration timing. The >>>>>>> need for >>>>>>> this support is driven by the fact that Android has removed the >>>>>>> timed_ouput [1] >>>>>>> and is now using led-trigger for handling vibrator control which >>>>>>> requires the >>>>>>> timer to be accurate up to a millisecond. However, this flag support >>>>>>> would also >>>>>>> allow hrtimer to co-exist with the ktimer without causing warning to the >>>>>>> existing drivers [2]. >>>>>> >>>>>> NAK. >>>>>> >>>>>> LEDs do not need extra overhead, and vibrator control should not go >>>>>> through LED subsystem. >>>>>> >>>>>> Input subsystem includes support for vibrations and force >>>>>> feedback. Please use that instead. >>>>> >>>>> I think that most vital criterion here is the usability of the >>>>> interface. If it can be harnessed for doing the work seemingly >>>>> unrelated to the primary subsystem's purpose, that's fine. >>>>> Moreover, it is extremely easy to use in comparison to the force >>>>> feedback one. >>>> >>>> Well, no. >>>> >>>> Kernel is supposed to provide hardware abstraction, that means it >>>> should hide differences between different devices. >>>> >>>> And we already have devices using input as designed. We don't want to >>>> have situation where "on phones A, D and E, vibrations are handled via >>>> input, while on B, C and F, they are handled via /sys/class/leds". >>>> >>>> If we want to have discussion "how to make vibrations in input >>>> easier to use", well that's fair. But I don't think it is particulary hard. >>>> >>> >>> I would like to know more about why you find the FF interface hard, >> >> led-transient trigger can be activated using only following bash >> commands: >> >> # echo 1 > state >> # echo 1000 > duration >> # while [ 1 ]; do echo 1 > activate; sleep 3; done >> >> Could you share sample sequence of commands to use ff driver? > > Cut what you need from this: > https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c > > If your objection is that FF is not easily engaged from the shell - > yes, but I do not think that actual users who want to do vibration do > that via shell either. On the other hand, can you drop privileges and > still allow a certain process control your vibrator via LED interface? > With FF you can pass an FD to whoever you deem worthy and later revoke > access. > > IOW sysfs interfaces are nice for quick hacks, but when you want to > use them in real frameworks, where you need to think about proper > namespaces, isolation, etc, etc, other kinds of interfaces might suit > better. I'd leave the decision to the user. We could add a note to the Documentation/leds/ledtrig-transient.txt that force feedback interface should be preferable choice for driving vibrate devices. However only if following conditions are met: - force feedback driver supports gpio driven devices - there is sample application in tools/input showing how to setup gpio driven vibrate device with use of ff interface - it will be possible to setup vibrate interval with 1ms accuracy, similarly to what the discussed patch allows to do >> >>> given that for rumble you need calls - one ioctl to set up rumble >>> parameters, and a write to start the playback. The FF core should take >>> care of handling duration of the effect, ramping it up and decaying, >>> if desired, and we make sure to automatically stop effects when >
Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: > On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pa...@ucw.cz> wrote: >> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote: >>> Hi David and Pavel, >>> >>> On 09/13/2017 10:20 PM, Pavel Machek wrote: >>>> Hi! >>>> >>>>> These patch series add the LED_BRIGHTNESS_FAST flag support for >>>>> ledtrig-transient to use hrtimer so that platforms with high-resolution >>>>> timer >>>>> support can have better accuracy in the trigger duration timing. The need >>>>> for >>>>> this support is driven by the fact that Android has removed the >>>>> timed_ouput [1] >>>>> and is now using led-trigger for handling vibrator control which requires >>>>> the >>>>> timer to be accurate up to a millisecond. However, this flag support >>>>> would also >>>>> allow hrtimer to co-exist with the ktimer without causing warning to the >>>>> existing drivers [2]. >>>> >>>> NAK. >>>> >>>> LEDs do not need extra overhead, and vibrator control should not go >>>> through LED subsystem. >>>> >>>> Input subsystem includes support for vibrations and force >>>> feedback. Please use that instead. >>> >>> I think that most vital criterion here is the usability of the >>> interface. If it can be harnessed for doing the work seemingly >>> unrelated to the primary subsystem's purpose, that's fine. >>> Moreover, it is extremely easy to use in comparison to the force >>> feedback one. >> >> Well, no. >> >> Kernel is supposed to provide hardware abstraction, that means it >> should hide differences between different devices. >> >> And we already have devices using input as designed. We don't want to >> have situation where "on phones A, D and E, vibrations are handled via >> input, while on B, C and F, they are handled via /sys/class/leds". >> >> If we want to have discussion "how to make vibrations in input >> easier to use", well that's fair. But I don't think it is particulary hard. >> > > I would like to know more about why you find the FF interface hard, led-transient trigger can be activated using only following bash commands: # echo 1 > state # echo 1000 > duration # while [ 1 ]; do echo 1 > activate; sleep 3; done Could you share sample sequence of commands to use ff driver? > given that for rumble you need calls - one ioctl to set up rumble > parameters, and a write to start the playback. The FF core should take > care of handling duration of the effect, ramping it up and decaying, > if desired, and we make sure to automatically stop effects when > userspace closes the fd (because of ordinary exit or crash or FD being > revoked). > >> If we want to say "lets move all vibrations from input to LED >> subsystem"... I don't think that is good idea, but its a valid >> discussion. Some good reasons would be needed. >> >> But having half devices use one interface and half use different one >> is just bad... > > Completely agree here. I just merged PWM vibra driver from Sebastian > Reichel, we already had regulator-haptic driver, do we need gpio-based > one? Or make regulator-based one working with fixed regulators? Just to clarify: the background of this discussion is the question whether we should remove the following lines from Documentation/leds/ledtrig-transient.txt: -As a specific example of this use-case, let's look at vibrate feature on -phones. Vibrate function on phones is implemented using PWM pins on SoC or -PMIC. There is a need to activate one shot timer to control the vibrate -feature, to prevent user space crashes leaving the phone in vibrate mode -permanently causing the battery to drain. whether we should remove the following use case example from In effect Pavel has objections to increasing ledtrig-transient interval accuracy by adding hr_timer support to it, because vibrate devices, as one of the use cases, can benefit from it. So there are two issues: 1. Addition of hr_timer support to LED trigger. 2. Removal of vibrate devices use case from ledtrig-transient doc. I am in favour of 1. and against 2. since we're not gaining anything by hiding information about some kernel functionality when it will still be there. It also doesn't define the location of any vibrate device drivers, since sheer leds-gpio driver can be used for that purpose. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
On 09/14/2017 09:38 PM, David Lin wrote: > On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> I would change one more thing in this patch, though. The hr_timer engine >> should be made optional and not used by default for fast LEDs. >> It could be made configurable by exposing additional sysfs file from >> ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value. > > Do you mean in additional to checking the LED_BRIGHTNESS_FAST flag, > userspace has to explicitly enable it via sysfs for ledtrig to select > hrtimer? This seems to be redundant to me. Could you please explain > your concerns and the benefit of doing this? Thanks. My concern is that fast LED users would be automatically imposed a hr_timer overhead, which they may not need. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros
Hi David,
Thanks for the patch.
On 09/13/2017 07:53 PM, David Lin wrote:
> This is for readability as well as to avoid checkpatch warnings when
> adding new bit flag information in the future.
>
> Signed-off-by: David Lin <dtw...@google.com>
> ---
> include/linux/leds.h | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index bf6db4fe895b..5579c64c8fd6 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -40,16 +40,16 @@ struct led_classdev {
> int flags;
>
> /* Lower 16 bits reflect status */
> -#define LED_SUSPENDED(1 << 0)
> -#define LED_UNREGISTERING(1 << 1)
> +#define LED_SUSPENDEDBIT(0)
> +#define LED_UNREGISTERINGBIT(1)
> /* Upper 16 bits reflect control information */
> -#define LED_CORE_SUSPENDRESUME (1 << 16)
> -#define LED_SYSFS_DISABLE(1 << 17)
> -#define LED_DEV_CAP_FLASH(1 << 18)
> -#define LED_HW_PLUGGABLE (1 << 19)
> -#define LED_PANIC_INDICATOR (1 << 20)
> -#define LED_BRIGHT_HW_CHANGED(1 << 21)
> -#define LED_RETAIN_AT_SHUTDOWN (1 << 22)
> +#define LED_CORE_SUSPENDRESUME BIT(16)
> +#define LED_SYSFS_DISABLEBIT(17)
> +#define LED_DEV_CAP_FLASHBIT(18)
> +#define LED_HW_PLUGGABLE BIT(19)
> +#define LED_PANIC_INDICATOR BIT(20)
> +#define LED_BRIGHT_HW_CHANGEDBIT(21)
> +#define LED_RETAIN_AT_SHUTDOWN BIT(22)
>
> /* set_brightness_work / blink_timer flags, atomic, private. */
> unsigned long work_flags;
>
This one should not raise any doubts.
Applied to the for-4.15 branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
Hi David and Pavel, On 09/13/2017 10:20 PM, Pavel Machek wrote: > Hi! > >> These patch series add the LED_BRIGHTNESS_FAST flag support for >> ledtrig-transient to use hrtimer so that platforms with high-resolution timer >> support can have better accuracy in the trigger duration timing. The need for >> this support is driven by the fact that Android has removed the timed_ouput >> [1] >> and is now using led-trigger for handling vibrator control which requires the >> timer to be accurate up to a millisecond. However, this flag support would >> also >> allow hrtimer to co-exist with the ktimer without causing warning to the >> existing drivers [2]. > > NAK. > > LEDs do not need extra overhead, and vibrator control should not go > through LED subsystem. > > Input subsystem includes support for vibrations and force > feedback. Please use that instead. I think that most vital criterion here is the usability of the interface. If it can be harnessed for doing the work seemingly unrelated to the primary subsystem's purpose, that's fine. Moreover, it is extremely easy to use in comparison to the force feedback one. I would change one more thing in this patch, though. The hr_timer engine should be made optional and not used by default for fast LEDs. It could be made configurable by exposing additional sysfs file from ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration
Hi, On 08/31/2017 10:09 AM, Pavel Machek wrote: > On Wed 2017-08-30 22:44:00, Jacek Anaszewski wrote: >> Hi, >> >> On 08/29/2017 10:38 PM, Pavel Machek wrote: >>> Hi! >>> >>>>> -As a specific example of this use-case, let's look at vibrate feature on >>>>> -phones. Vibrate function on phones is implemented using PWM pins on SoC >>>>> or >>>>> -PMIC. There is a need to activate one shot timer to control the vibrate >>>>> -feature, to prevent user space crashes leaving the phone in vibrate mode >>>>> -permanently causing the battery to drain. >>>> >>>> I'm not sure if it is a good idea to remove this description. Users will >>>> still be able to use transient trigger this way. It has been around for >>>> five years already and there are users which employ it in this >>>> particular way [0]. > > Actually, I checked, and no ARM mainline board does that. There might be user space clients like the Android one [0]. >>> I am. Yes, people were doing that, but no, vibration motor is not a >>> LED. PWM behaviour is different, for example, motor is likely to stop >>> at low PWM values. We do not want people to do that. >> >> Could you elaborate on how it can be harmful? > > Well, you can safely route low current to the LEDs. What will it to do > vibration motor, if you leave it on forever? Can the motor safely be > run forever on high current? Not sure. It's actually one of the main advantages of the "transient" trigger - you have to re-activate it after the end of each transition cycle, If you execute the following sequence of commands, then you're getting 1s blink every 3s as long as the while loop is iterating. If you break the loop the LED output state will be always brought down after the duration period, No risk that output will be left in the high state unless transient state was deliberately set to 0. # echo 1 > state # echo 1000 > duration # while [ 1 ] ;do echo 1 > activate ; sleep 3; done >> I really don't see any merit in removing this from documentation. > > There's right API to use for vibrations, and that's force-feedback > support in input/. Not here. Is is as easy to use as this one? It seems that it requires an application to call ioctl's. >> You can convince me by collecting some acks from involved people. >> I'd like to especially see Rob's opinion. Adding Rob to this thread. > > Rob is device tree maintainer. This has little to do with device tree. I added him because his is the author of the Android patch [0], that mentions using transient trigger for the LED device named "vibrator". >>>> Apart from that it's the only documented kernel API for vibrate devices >>>> AFAICT. >>> >>> Input subsystem has force-feedback protocol, which is very often just >>> vibrations. Documentation/input/ff.rst . Nokia N900 phone actually >>> uses that API. >> >> Word "vibration" doesn't appear there, so what this patch does >> is remove explicit advertisement of kernel support for vibrate >> devices without redirecting people to the replacement. > > Well... this is LED documentation. If there's other documentation > missing somewhere else... we can fix it :-). We can fix it, but not necessarily remove the valuable information from this one :-) [0] https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9 -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration
Hi, On 08/29/2017 10:38 PM, Pavel Machek wrote: > Hi! > >>> -As a specific example of this use-case, let's look at vibrate feature on >>> -phones. Vibrate function on phones is implemented using PWM pins on SoC or >>> -PMIC. There is a need to activate one shot timer to control the vibrate >>> -feature, to prevent user space crashes leaving the phone in vibrate mode >>> -permanently causing the battery to drain. >> >> I'm not sure if it is a good idea to remove this description. Users will >> still be able to use transient trigger this way. It has been around for >> five years already and there are users which employ it in this >> particular way [0]. > > I am. Yes, people were doing that, but no, vibration motor is not a > LED. PWM behaviour is different, for example, motor is likely to stop > at low PWM values. We do not want people to do that. Could you elaborate on how it can be harmful? I really don't see any merit in removing this from documentation. You can convince me by collecting some acks from involved people. I'd like to especially see Rob's opinion. Adding Rob to this thread. >> Apart from that it's the only documented kernel API for vibrate devices >> AFAICT. > > Input subsystem has force-feedback protocol, which is very often just > vibrations. Documentation/input/ff.rst . Nokia N900 phone actually > uses that API. Word "vibration" doesn't appear there, so what this patch does is remove explicit advertisement of kernel support for vibrate devices without redirecting people to the replacement. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration
Hi Pavel, Thanks for the patch. On 08/28/2017 11:50 AM, Pavel Machek wrote: > > Spell "LED" consistently with uppercase. > > We do not want people to use LED subsystem for vibrations; there's > already support for that in input subsystem. Remove notes about > vibrations not to confuse people. > > Signed-off-by: Pavel Machek <pa...@ucw.cz> > > > diff --git a/Documentation/leds/ledtrig-transient.txt > b/Documentation/leds/ledtrig-transient.txt > index 3bd38b4..f412603 100644 > --- a/Documentation/leds/ledtrig-transient.txt > +++ b/Documentation/leds/ledtrig-transient.txt > @@ -1,7 +1,7 @@ > LED Transient Trigger > = > > -The leds timer trigger does not currently have an interface to activate > +The LED timer trigger does not currently have an interface to activate > a one shot timer. The current support allows for setting two timers, one for > specifying how long a state to be on, and the second for how long the state > to be off. The delay_on value specifies the time period an LED should stay > @@ -16,17 +16,11 @@ set a timer to hold a state, however when user space > application crashes or > goes away without deactivating the timer, the hardware will be left in that > state permanently. > > -As a specific example of this use-case, let's look at vibrate feature on > -phones. Vibrate function on phones is implemented using PWM pins on SoC or > -PMIC. There is a need to activate one shot timer to control the vibrate > -feature, to prevent user space crashes leaving the phone in vibrate mode > -permanently causing the battery to drain. I'm not sure if it is a good idea to remove this description. Users will still be able to use transient trigger this way. It has been around for five years already and there are users which employ it in this particular way [0]. Apart from that it's the only documented kernel API for vibrate devices AFAICT. > Transient trigger addresses the need for one shot timer activation. The > -transient trigger can be enabled and disabled just like the other leds > +transient trigger can be enabled and disabled just like the other LED > triggers. > > -When an led class device driver registers itself, it can specify all leds > +When an LED class device driver registers itself, it can specify all LED > triggers it supports and a default trigger. During registration, activation > routine for the default trigger gets called. During registration of an led > class device, the LED state does not change. > @@ -42,12 +36,12 @@ that are active at the time driver gets suspended, > continue to run, without > being able to actually change the LED state. Once driver is resumed, triggers > start functioning again. > > -LED state changes are controlled using brightness which is a common led > +LED state changes are controlled using brightness which is a common LED > class device property. When brightness is set to 0 from user space via > echo 0 > brightness, it will result in deactivating the current trigger. > > Transient trigger uses standard register and unregister interfaces. During > -trigger registration, for each led class device that specifies this trigger > +trigger registration, for each LED class device that specifies this trigger > as its default trigger, trigger activation routine will get called. During > registration, the LED state does not change, unless there is another trigger > active, in which case LED state changes to LED_OFF. > @@ -56,12 +50,12 @@ During trigger unregistration, LED state gets changed to > LED_OFF. > > Transient trigger activation routine doesn't change the LED state. It > creates its properties and does its initialization. Transient trigger > -deactivation routine, will cancel any timer that is active before it cleans > +deactivation routine will cancel any timer that is active before it cleans > up and removes the properties it created. It will restore the LED state to > non-transient state. When driver gets suspended, irrespective of the > transient > state, the LED state changes to LED_OFF. > > -Transient trigger can be enabled and disabled from user space on led class > +Transient trigger can be enabled and disabled from user space on LED class > devices, that support this trigger as shown below: > > echo transient > trigger > @@ -144,7 +138,6 @@ repeat the following step as needed: > echo none > trigger > > This trigger is intended to be used for for the following example use cases: > - - Control of vibrate (phones, tablets etc.) hardware by user space app. > - Use of LED by user space app as activity indicator. > - Use of LED by user space app as a kind of watchdog indicator -- as > lon
Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer
On 05/08/2017 11:06 PM, Pavel Machek wrote: > On Sun 2017-04-30 14:36:58, David Lin wrote: >> Hi, >> >> These patch series add the LED_BRIGHTNESS_FAST flag support for >> ledtrig-transient to use hrtimer so that platforms with high-resolution timer >> support can have better accuracy in the trigger duration timing. The need for >> this support is driven by the fact that Android has removed the timed_ouput >> [1] >> and is now using led-trigger for handling vibrator control which requires the >> timer to be accurate up to a millisecond. However, this flag support would >> also >> allow hrtimer to co-exist with the ktimer without causing warning to the >> existing drivers [2]. > > Yes, and objection still stands: You are misusing LED subsystem for > vibration motors. We already have support for haptic feedback in input > subsystem. Regardless of whether it is a misuse or not (ledtrig-transient documentation suggests that it is one of use cases) we have to keep it as it has been around for a long time and it has userspace users [0]. Moreover there seems to be broad consensus about it among kernel people [1]. [0] https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b [1] https://patchwork.kernel.org/patch/8664831/ -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] led: ledtrig-transient: add support for hrtimer
Hi David,
Thanks for the patch. I have one reservation below.
On 04/30/2017 11:37 PM, David Lin wrote:
> This patch adds a hrtimer to ledtrig-transient so that when driver is
> registered with LED_BRIGHTNESS_FAST, the hrtimer is used for the better
> time accuracy in handling the duration.
>
> Signed-off-by: David Lin <dtw...@google.com>
> ---
> drivers/leds/trigger/ledtrig-transient.c | 59
> +---
> 1 file changed, 54 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/leds/trigger/ledtrig-transient.c
> b/drivers/leds/trigger/ledtrig-transient.c
> index 7e6011bd3646..63be54772596 100644
> --- a/drivers/leds/trigger/ledtrig-transient.c
> +++ b/drivers/leds/trigger/ledtrig-transient.c
> @@ -24,15 +24,18 @@
> #include
> #include
> #include
> +#include
> #include
> #include "../leds.h"
>
> struct transient_trig_data {
> + struct led_classdev *led_cdev;
> int activate;
> int state;
> int restore_state;
> unsigned long duration;
> struct timer_list timer;
> + struct hrtimer hrtimer;
> };
>
> static void transient_timer_function(unsigned long data)
> @@ -44,6 +47,54 @@ static void transient_timer_function(unsigned long data)
> led_set_brightness_nosleep(led_cdev, transient_data->restore_state);
> }
>
> +static enum hrtimer_restart transient_hrtimer_function(struct hrtimer *timer)
> +{
> + struct transient_trig_data *transient_data =
> + container_of(timer, struct transient_trig_data, hrtimer);
> +
> + transient_timer_function((unsigned long)transient_data->led_cdev);
> +
> + return HRTIMER_NORESTART;
> +}
> +
> +static inline void transient_timer_setup(struct led_classdev *led_cdev)
> +{
> + struct transient_trig_data *tdata = led_cdev->trigger_data;
> +
> + if (led_cdev->flags & LED_BRIGHTNESS_FAST) {
> + tdata->led_cdev = led_cdev;
> + hrtimer_init(>hrtimer, CLOCK_MONOTONIC,
> + HRTIMER_MODE_REL);
> + tdata->hrtimer.function = transient_hrtimer_function;
> + } else {
> + setup_timer(>timer, transient_timer_function,
> + (unsigned long)led_cdev);
> + }
> +}
> +
> +static inline void transient_timer_start(struct led_classdev *led_cdev)
> +{
> + struct transient_trig_data *tdata = led_cdev->trigger_data;
> +
> + if (led_cdev->flags & LED_BRIGHTNESS_FAST) {
> + hrtimer_start(>hrtimer, ms_to_ktime(tdata->duration),
> + HRTIMER_MODE_REL);
> + } else {
> + mod_timer(>timer,
> + jiffies + msecs_to_jiffies(tdata->duration));
> + }
> +}
> +
> +static inline void transient_timer_cancel(struct led_classdev *led_cdev)
> +{
> + struct transient_trig_data *tdata = led_cdev->trigger_data;
> +
> + if (led_cdev->flags & LED_BRIGHTNESS_FAST)
> + hrtimer_cancel(>hrtimer);
> + else
> + del_timer_sync(>timer);
> +}
These functions don't seem to be good candidates for marking them with
inline modifier due to below reasons:
- they have more than three lines of code
- their parameters are not compiletime constants
- the functions are static and used only once - in this case
gcc is capable of inlining them automatically without help
This is concise excerpt from the Documentation/process/coding-style.rst,
chapter 15.
> static ssize_t transient_activate_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> @@ -70,7 +121,7 @@ static ssize_t transient_activate_store(struct device *dev,
>
> /* cancel the running timer */
> if (state == 0 && transient_data->activate == 1) {
> - del_timer(_data->timer);
> + transient_timer_cancel(led_cdev);
> transient_data->activate = state;
> led_set_brightness_nosleep(led_cdev,
> transient_data->restore_state);
> @@ -84,8 +135,7 @@ static ssize_t transient_activate_store(struct device *dev,
> led_set_brightness_nosleep(led_cdev, transient_data->state);
> transient_data->restore_state =
> (transient_data->state == LED_FULL) ? LED_OFF : LED_FULL;
> - mod_timer(_data->timer,
> - jiffies + msecs_to_jiffies(transient_data->duration));
> + transient_timer_start(led_cdev);
> }
>
> /* state == 0 && transient_data->activate == 0
> @@ -182,8 +232,7 @@ static
Re: [PATCH 1/3] leds: Replace flags bit shift with BIT() macros
Hi David,
On 04/30/2017 11:36 PM, David Lin wrote:
> This is for readability as well as to avoid checkpatch warnings when
> adding new bit flag information in the future.
>
> Signed-off-by: David Lin <dtw...@google.com>
> ---
> include/linux/leds.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 64c56d454f7d..f9d10a9efcbe 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -43,12 +43,12 @@ struct led_classdev {
> #define LED_SUSPENDED(1 << 0)
> #define LED_UNREGISTERING(1 << 1)
Could we update also these bits?
> /* Upper 16 bits reflect control information */
> -#define LED_CORE_SUSPENDRESUME (1 << 16)
> -#define LED_SYSFS_DISABLE(1 << 17)
> -#define LED_DEV_CAP_FLASH(1 << 18)
> -#define LED_HW_PLUGGABLE (1 << 19)
> -#define LED_PANIC_INDICATOR (1 << 20)
> -#define LED_BRIGHT_HW_CHANGED(1 << 21)
> +#define LED_CORE_SUSPENDRESUME BIT(16)
> +#define LED_SYSFS_DISABLEBIT(17)
> +#define LED_DEV_CAP_FLASHBIT(18)
> +#define LED_HW_PLUGGABLE BIT(19)
> +#define LED_PANIC_INDICATOR BIT(20)
> +#define LED_BRIGHT_HW_CHANGEDBIT(21)
>
> /* set_brightness_work / blink_timer flags, atomic, private. */
> unsigned long work_flags;
>
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5] leds: trigger: Introduce a USB port trigger
On 09/15/2016 03:33 PM, Rafał Miłecki wrote: On 15 September 2016 at 14:56, Pavel Machek <pa...@ucw.cz> wrote: On Fri 2016-09-09 13:31:10, Rafał Miłecki wrote: On 9 September 2016 at 13:05, Greg KH <gre...@linuxfoundation.org> wrote: On Fri, Sep 09, 2016 at 05:34:40PM +0800, Peter Chen wrote: On Thu, Sep 08, 2016 at 06:08:24PM +0200, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1). There was a long discussion on design of this driver. Its current state is a result of picking them most adjustable solution as others couldn't handle all cases. 1) It wasn't possible for the driver to register separated trigger for each USB port. Some physical USB ports are handled by more than one controller and so by more than one USB port. E.g. USB 2.0 physical port may be handled by OHCI's port and EHCI's port. It's also not possible to assign more than 1 trigger to a single LED and implementing such feature would be tricky due to syncing triggers and sysfs conflicts with old triggers. 2) Another idea was to register trigger per USB hub. This wouldn't allow handling devices with multiple USB LEDs and controllers (hubs) controlling more than 1 physical port. It's common for hubs to have few ports and each may have its own LED. This final trigger is highly flexible. It allows selecting any USB ports for any LED. It was also modified (compared to the initial version) to allow choosing ports rather than having user /guess/ proper names. It was successfully tested on SmartRG SR400ac which has 3 USB LEDs, 2 physical ports and 3 controllers. Another planned feature is support for LED reacting to the USB activity. This can be implemented with another sysfs file for setting mode. The default mode wouldn't change so there won't be ABI breakage and such feature can be safely implemented later. It has such driver at: drivers/usb/common/led.c Ugh, I thought I had seen something like this before... Rafał, can you just use this in-kernel code instead? I really don't think I can because of all the reasons I carefully listed in the commit message. Have you took a look at that simple driver? It does nothing I need. Its design doesn't allow implementing features I clearly listed in the commit message. In any case, the new driver should probably go near the old one, at the very least. I can do that. Anyone objects? It's OK with me. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] leds: trigger: Introduce an USB port trigger
On 09/03/2016 05:17 PM, Alan Stern wrote: On Sat, 3 Sep 2016, Jacek Anaszewski wrote: Maybe it would make more sense, in this case, to allow only three possibilities for a USB port activity trigger. Toggle the LED whenever: There is activity on the specified port, or There is any activity on any port on the specified hub, or There is any USB activity on any port. That ought to cover most of the normal use cases, and it would be simple enough to implement. What would be the benefit of having a USB port activity trigger, for which we would be specifying the port to observe, but in the same time we would react on any activity on any port (cases 1 and 3)? I meant these three cases to be mutually exclusive. For a given LED, you could have only one of those trigger types (like mentioned above, only one trigger per LED). For example, you might accept any one of: echo usb1-4.2 >/sys/class/led/foo/trigger echo hub1-4 >/sys/class/led/foo/trigger echo usb >/sys/class/led/foo/trigger Yes, it would be possible to have a port-specific trigger for one LED and an overall USB activity trigger for another LED. I don't know how useful this would be -- you could probably imagine some unlikely scenario. The point is that doing things this way wouldn't require any API violations, and it would allow users to do almost all of the things they are likely to want. We'd have to define single API for generating USB trigger event, so as not enforce addition of three different API calls to the USB drivers. Of course this trigger represents yet another type of triggers, that don't require exposing an API for generating events, but instead register as listeners to some notifiers. I missed that initially. The USB core would need only one LED-API call, which it would make upon the completion of an URB. The trigger code should be able to handle all the rest (i.e., see which LEDs should be triggered by that URB). This is assured by the LED trigger core. The type of USB events that the LED should react upon could be defined by parsing the value written to the sysfs file. There is only one type of event: completion of an URB. Triggers would differ depending only on the device/port that the URB was aimed at. _That_ information could be defined by parsing the value written to the sysfs file. This of course implies, that we should have single LED USB port trigger. The remaining issue is the sysfs interface design for defining and presenting multiple USB ports. I'm still in favour of a single attribute with space separated list. This scheme is commonly used in existing interfaces. No such interface is needed if you do things the way I outlined above. Each trigger would require the user to specify either one port, one hub, or nothing at all. Multiple ports would not be used. The patch assumes that it is possible to register trigger for many ports. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] leds: trigger: Introduce an USB port trigger
On 09/02/2016 04:33 PM, Alan Stern wrote: On Fri, 2 Sep 2016, Jacek Anaszewski wrote: I'm pretty sure noone ever planned to have more than 1 trigger assigned to a single LED. I just realized there will be a problem with proposed solution: sysfs files conflict. ... Currently we support only triggers dedicated to specific type of devices. Even in case of triggers that don't expose custom sysfs attributes, registered with led_trigger_register_simple(), device drivers have to generate trigger event with dedicated function, e.g: - ledtrig-cpu: void ledtrig_cpu(enum cpu_led_event ledevt) - ledtrig-disk: void ledtrig_disk_activity(void) - ledtrig-mtd: void ledtrig_mtd_activity(void) If one wanted to have the LED notified by different type of devices, then they would have to implement a trigger that would exposed all required types of API. Unfortunately, there are many possible combinations of triggers and that doesn't sound sane to add a new one when someone will find it useful. Of course it would entail adding a call to the new trigger API in the drivers, which doesn't seem like something acceptable in the mainline. Maybe it would make more sense, in this case, to allow only three possibilities for a USB port activity trigger. Toggle the LED whenever: There is activity on the specified port, or There is any activity on any port on the specified hub, or There is any USB activity on any port. That ought to cover most of the normal use cases, and it would be simple enough to implement. What would be the benefit of having a USB port activity trigger, for which we would be specifying the port to observe, but in the same time we would react on any activity on any port (cases 1 and 3)? I meant these three cases to be mutually exclusive. For a given LED, you could have only one of those trigger types (like mentioned above, only one trigger per LED). For example, you might accept any one of: echo usb1-4.2 >/sys/class/led/foo/trigger echo hub1-4 >/sys/class/led/foo/trigger echo usb >/sys/class/led/foo/trigger Yes, it would be possible to have a port-specific trigger for one LED and an overall USB activity trigger for another LED. I don't know how useful this would be -- you could probably imagine some unlikely scenario. The point is that doing things this way wouldn't require any API violations, and it would allow users to do almost all of the things they are likely to want. We'd have to define single API for generating USB trigger event, so as not enforce addition of three different API calls to the USB drivers. The type of USB events that the LED should react upon could be defined by parsing the value written to the sysfs file. This of course implies, that we should have single LED USB port trigger. The remaining issue is the sysfs interface design for defining and presenting multiple USB ports. I'm still in favour of a single attribute with space separated list. This scheme is commonly used in existing interfaces. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] leds: trigger: Introduce an USB port trigger
On 09/01/2016 07:25 AM, Rafał Miłecki wrote: On 31 August 2016 at 21:00, Rafał Miłecki <zaj...@gmail.com> wrote: On 31 August 2016 at 20:23, Alan Stern <st...@rowland.harvard.edu> wrote: On Tue, 30 Aug 2016, Rafał Miłecki wrote: Not really as it won't cover some pretty common use cases. Many home routers have few USB ports (2-5) and only 1 USB LED. It has to be possible to assign few USB ports to a single LED (trigger). That way LED should be turned on (and kept on) if there is at least 1 USB device connected. You obviously can't do: echo "usb1-1 usb1-2 usb2-1" > /sys/class/leds/foo/trigger This was already brought up by Rob (who mentioned CPU trigger) and I replied him pretty much the same way in: https://lkml.org/lkml/2016/7/29/38 (reply starts with "Anyway, the serious limitation I see"). The code for a bunch of triggers must already be written. What would the user do if he wanted to flash a single LED in response to both CPU activity and MTD activity? If not echo "cpu mtd" >/sys/class/leds/foo/trigger then what? Well, it sounds like a new feature then. Shall we add an extra API with a request function for turning LED on? It could internally count how many requests were raised and keep LED on as long as there is at least 1 left. I guess we should implement it in trigger "subsystem" (if I can call it so). Does it sound like a good plan? I'm pretty sure noone ever planned to have more than 1 trigger assigned to a single LED. I just realized there will be a problem with proposed solution: sysfs files conflict. Consider 2 existing triggers for a moment: 1) oneshot: it creates following sysfs files: /sys/class/leds/foo/delay_on /sys/class/leds/foo/delay_off /sys/class/leds/foo/invert /sys/class/leds/foo/shot 2) timer: it creates following sysfs files: /sys/class/leds/foo/delay_on /sys/class/leds/foo/delay_off Activating both of them will probably cause a WARNING in sysfs. They can't coexist :( We should probably have per-trigger subdirs, e.g.: /sys/class/leds/foo/trigger-oneshot/delay_on /sys/class/leds/foo/trigger-oneshot/delay_off /sys/class/leds/foo/trigger-oneshot/invert /sys/class/leds/foo/trigger-oneshot/shot /sys/class/leds/foo/trigger-timer/delay_on /sys/class/leds/foo/trigger-timer/delay_off but implementing it now would break the ABI. One workaround I can see is doing triggers V2, they: 1) Would put sysfs files in /sys/class/leds/foo/trigger-bar/ 2) Use new API for *requesting* LED to be on/off 3) There would be a counter of requests in V2 API 4) Multiple triggers V2 would be allowed to be used (assigned) at the same time Currently we support only triggers dedicated to specific type of devices. Even in case of triggers that don't expose custom sysfs attributes, registered with led_trigger_register_simple(), device drivers have to generate trigger event with dedicated function, e.g: - ledtrig-cpu: void ledtrig_cpu(enum cpu_led_event ledevt) - ledtrig-disk: void ledtrig_disk_activity(void) - ledtrig-mtd: void ledtrig_mtd_activity(void) If one wanted to have the LED notified by different type of devices, then they would have to implement a trigger that would exposed all required types of API. Unfortunately, there are many possible combinations of triggers and that doesn't sound sane to add a new one when someone will find it useful. Of course it would entail adding a call to the new trigger API in the drivers, which doesn't seem like something acceptable in the mainline. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PACTH v4 1/3] mm, proc: Implement /proc//totmaps
ee4abd00 8000 0001c000 ee471f80 c01ddca0 0004 ee478124 1f60: 0001 ee4abd00 ee4abd00 8000 0001c000 c01ddd64 1f80: 8000 0001c000 0003 0003 c0107ac4 1fa0: c0107900 8000 0001c000 0003 0001c000 8000 0001c000 1fc0: 8000 0001c000 0003 0003 8000 005e 1fe0: bec0eb0c c694 b6f4248c 6010 0003 fdfb [] (down_read) from [] (totmaps_proc_show+0x2c/0x1e8) [] (totmaps_proc_show) from [] (seq_read+0x1c8/0x4b8) [] (seq_read) from [] (__vfs_read+0x2c/0x110) [] (__vfs_read) from [] (vfs_read+0x8c/0x110) [] (vfs_read) from [] (SyS_read+0x40/0x8c) [] (SyS_read) from [] (ret_fast_syscall+0x0/0x3c) It seems that some protection is needed for such processes, so that totmaps would return empty string then, like in case of smaps. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] Documentation: move oneshot trigger attributes documentation to ABI
Hi Rafał, On 08/26/2016 04:19 PM, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> Documentation of sysfs interface should be in ABI in the first place. This moves relevant part of documentation and mentions where to look for it. Fix trivial typos whilst we are at it. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2: s/Default/Defaults/ s/ / / s/change/changes/ --- Documentation/ABI/testing/sysfs-class-led | 3 +- .../ABI/testing/sysfs-class-led-trigger-oneshot| 36 ++ Documentation/leds/ledtrig-oneshot.txt | 20 ++-- 3 files changed, 40 insertions(+), 19 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-oneshot diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 3646ec8..86ace28 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -24,7 +24,8 @@ Description: of led events. You can change triggers in a similar manner to the way an IO scheduler is chosen. Trigger specific parameters can appear in - /sys/class/leds/ once a given trigger is selected. + /sys/class/leds/ once a given trigger is selected. For + their documentation see sysfs-class-led-trigger-*. What: /sys/class/leds//inverted Date: January 2011 diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-oneshot b/Documentation/ABI/testing/sysfs-class-led-trigger-oneshot new file mode 100644 index 000..378a3a4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-oneshot @@ -0,0 +1,36 @@ +What: /sys/class/leds//delay_on +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Specifies for how many milliseconds the LED has to stay at + LED_FULL brightness after it has been armed. + Defaults to 100 ms. + +What: /sys/class/leds//delay_off +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Specifies for how many milliseconds the LED has to stay at + LED_OFF brightness after it has been armed. + Defaults to 100 ms. + +What: /sys/class/leds//invert +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Reverse the blink logic. If set to 0 (default) blink on for + delay_on ms, then blink off for delay_off ms, leaving the LED + normally off. If set to 1, blink off for delay_off ms, then + blink on for delay_on ms, leaving the LED normally on. + Setting this value also immediately changes the LED state. + +What: /sys/class/leds//shot +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Write any non-empty string to signal an events, this starts a + blink sequence if not already running. diff --git a/Documentation/leds/ledtrig-oneshot.txt b/Documentation/leds/ledtrig-oneshot.txt index 07cd1fa..fe57474 100644 --- a/Documentation/leds/ledtrig-oneshot.txt +++ b/Documentation/leds/ledtrig-oneshot.txt @@ -21,24 +21,8 @@ below: echo oneshot > trigger -This adds the following sysfs attributes to the LED: - - delay_on - specifies for how many milliseconds the LED has to stay at - LED_FULL brightness after it has been armed. - Default to 100 ms. - - delay_off - specifies for how many milliseconds the LED has to stay at - LED_OFF brightness after it has been armed. - Default to 100 ms. - - invert - reverse the blink logic. If set to 0 (default) blink on for delay_on - ms, then blink off for delay_off ms, leaving the LED normally off. If - set to 1, blink off for delay_off ms, then blink on for delay_on ms, - leaving the LED normally on. - Setting this value also immediately change the LED state. - - shot - write any non-empty string to signal an events, this starts a blink - sequence if not already running. +This adds sysfs attributes to the LED that are documented in: +Documentation/ABI/testing/sysfs-class-led-trigger-oneshot Example use-case: network devices, initialization: Applied, thanks. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
On 08/26/2016 05:58 PM, Rafał Miłecki wrote: On 25 August 2016 at 20:48, Jacek Anaszewski <jacek.anaszew...@gmail.com> wrote: On 08/25/2016 04:30 PM, Alan Stern wrote: On Thu, 25 Aug 2016, Jacek Anaszewski wrote: I'd see it as follows: #cat available_ports #1-1 1-2 2-1 #echo "1-1" > new_port #cat observed_ports #1-1 #echo "2-1" > new_port #cat observed_ports #1-1 2-1 We've already had few discussions about the sysfs designs trying to break the one-value-per-file rule for LED class device, and there was always strong resistance against. This scheme has multiple values in both the available_ports and observed_ports files. :-( Not that I have any better suggestions... Right, I forgot to add a note here, that this follows space separated list pattern similarly as in case of triggers attribute. Of course other suggestions are welcome. So ppl have doubts about multiple values in a single sysfs file (whatever we call it: "ports" or "observed_ports"). Greg clearly said: sysfs is "one value per file", here you are listing a bunch of things in one sysfs file. Please don't do that. What about my idea of using "ports" subdirectory and having each port as separated file inside that subdir? I think there are two ways of doing this: 1) Having "ports" subdir with 0x chmod files, one per each port specified as observable In this solution we need "new_port" and "remove_port" that can be used for management of observable ports. I think Jacek wasn't happy with this chmod and he believes Greg meant R/W files. It looks odd to me. In this case it would also abuse "one value per file" rule - the files would have no value, and only their names would carry an information. 2) Having "ports" subdir with RW files, one per each existing physical port In this situation we don't need "new_port" or "remove_port". If we want port to be observable we just do: echo 1 > 1-1 Implementing this solution needs reading more details from USB subsystem. The situation here is clear IMO - the number of USB ports in the system can change dynamically. I'm not sure if this can be handled easily with sysfs, where we usually expose an interface for known set of settings. struct attribute arrays are usually defined statically at the compile time and filled with the variables, that are created with DEVICE_ATTR macro. Do you find any of solutions with "ports" subdir better than dealing with new-line/space separated values in a single sysfs file? -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: move oneshot trigger attributes documentation to ABI
Hi Rafał, Thanks for the patch. We could possibly correct one linguistic issue whilst we are at it. Please take a look below. On 08/25/2016 11:38 AM, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> Documentation of sysfs interface should be in ABI in the first place. This moves relevant part of documentation and mentions where to look for it. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- Documentation/ABI/testing/sysfs-class-led | 3 +- .../ABI/testing/sysfs-class-led-trigger-oneshot| 37 ++ Documentation/leds/ledtrig-oneshot.txt | 20 ++-- 3 files changed, 41 insertions(+), 19 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-oneshot diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 3646ec8..86ace28 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -24,7 +24,8 @@ Description: of led events. You can change triggers in a similar manner to the way an IO scheduler is chosen. Trigger specific parameters can appear in - /sys/class/leds/ once a given trigger is selected. + /sys/class/leds/ once a given trigger is selected. For + their documentation see sysfs-class-led-trigger-*. What: /sys/class/leds//inverted Date: January 2011 diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-oneshot b/Documentation/ABI/testing/sysfs-class-led-trigger-oneshot new file mode 100644 index 000..401cbe6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-oneshot @@ -0,0 +1,37 @@ +What: /sys/class/leds//delay_on +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Specifies for how many milliseconds the LED has to stay at + LED_FULL brightness after it has been armed. + Default to 100 ms. s/Default/Defaults/ + + +What: /sys/class/leds//delay_off +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Specifies for how many milliseconds the LED has to stay at + LED_OFF brightness after it has been armed. + Default to 100 ms. s/Default/Defaults/ + +What: /sys/class/leds//invert +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Reverse the blink logic. If set to 0 (default) blink on for + delay_on ms, then blink off for delay_off ms, leaving the LED + normally off. If set to 1, blink off for delay_off ms, then + blink on for delay_on ms, leaving the LED normally on. + Setting this value also immediately change the LED state. + +What: /sys/class/leds//shot +Date: Jun 2012 +KernelVersion: 3.6 +Contact: linux-l...@vger.kernel.org +Description: + Write any non-empty string to signal an events, this starts a + blink sequence if not already running. diff --git a/Documentation/leds/ledtrig-oneshot.txt b/Documentation/leds/ledtrig-oneshot.txt index 07cd1fa..fe57474 100644 --- a/Documentation/leds/ledtrig-oneshot.txt +++ b/Documentation/leds/ledtrig-oneshot.txt @@ -21,24 +21,8 @@ below: echo oneshot > trigger -This adds the following sysfs attributes to the LED: - - delay_on - specifies for how many milliseconds the LED has to stay at - LED_FULL brightness after it has been armed. - Default to 100 ms. - - delay_off - specifies for how many milliseconds the LED has to stay at - LED_OFF brightness after it has been armed. - Default to 100 ms. - - invert - reverse the blink logic. If set to 0 (default) blink on for delay_on - ms, then blink off for delay_off ms, leaving the LED normally off. If - set to 1, blink off for delay_off ms, then blink on for delay_on ms, - leaving the LED normally on. - Setting this value also immediately change the LED state. - - shot - write any non-empty string to signal an events, this starts a blink - sequence if not already running. +This adds sysfs attributes to the LED that are documented in: +Documentation/ABI/testing/sysfs-class-led-trigger-oneshot Example use-case: network devices, initialization: -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
On 08/25/2016 04:30 PM, Alan Stern wrote: On Thu, 25 Aug 2016, Jacek Anaszewski wrote: I'd see it as follows: #cat available_ports #1-1 1-2 2-1 #echo "1-1" > new_port #cat observed_ports #1-1 #echo "2-1" > new_port #cat observed_ports #1-1 2-1 We've already had few discussions about the sysfs designs trying to break the one-value-per-file rule for LED class device, and there was always strong resistance against. This scheme has multiple values in both the available_ports and observed_ports files. :-( Not that I have any better suggestions... Right, I forgot to add a note here, that this follows space separated list pattern similarly as in case of triggers attribute. Of course other suggestions are welcome. Also a description of the device connected to the port would be a nice feature, however I am not certain about the feasibility thereof. What kind of description do you mean? Where should it be used / where should it appear? Product name/symbol. Actually it should be USB subsystem responsibility to provide the means for querying the product name by port id, if it is possible at all. cat /sys/bus/usb/devices/PORT/product cat /sys/bus/usb/devices/PORT/manufacturer These will work if there is a device registered under PORT. I've found only idProduct and idVendor files. They indeed uniquely identify the device, but the numbers are not human readable. Is there a way to retrieve the corresponding names in kernel? Does the lsusb command do the mapping in the user space or maybe it takes the names from kernel? -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
On 08/25/2016 10:29 AM, Rafał Miłecki wrote: On 25 August 2016 at 10:03, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: On 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires specifying USB port in a Linux format (e.g. echo 1-1 > new_port). During work on this trigger there was a plan to add DT bindings for it, but there wasn't an agreement on the format yet. This can be worked on later, a sysfs interface is needed anyway for platforms not using DT. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- V2: Trying to add DT support, idea postponed as it will take more time to discuss the bindings. V3: Fix typos in commit and Documentation (thanks Jacek!) Use "ports" sysfs file for adding and removing USB ports (thx Jacek) Check if there is USB device connected after adding new USB port Fix memory leak or two V3.5: Fix e-mail address (thanks Matthias) Simplify conditions in usbport_trig_notify (thx Matthias) Make "ports" a subdirectory with file per port, to match one value per file sysfs rule (thanks Greg) As "ports" couldn't be used for adding and removing ports anymore, there are now "new_port" and "remove_port". Having them makes this API also common with e.g. pci and usb buses. Now writing new_port with "1-1" produces a file named "1-1" in the ports directory with 000 permissions. I think that what Greg had on mind by referring to "one value per file" rule was a set of files representing ports, like "1-1 1-2 2-1", and each file should be readable/writeable. For instance "echo 1 > 1-1" would enable the trigger for the port 1-1 and "echo 0 > 1-1" would disable it. The problem is that we don't know the number of required ports at compilation time and the sysfs attributes would have to be dynamically created on driver instantiation. What is more, as the USB ports can dynamically appear/disappear in the system, the files would have to be created/removed accordingly during LED class device lifetime, which is not the best design for the sysfs interface I think. Therefore, maybe it would be good to follow the "triggers" sysfs attribute pattern, where it lists the available LED triggers? The question is whether there is some mechanism available for notifying addition/removal of a USB port? Every port is part of some hub and every hub (even root one) is a USB device. So I could just get struct usb_device and check its "maxchild" property. If e.g. I get USB device "1-1" with maxchild 4, I know there are: 1-1.1 1-1.2 1-1.3 1-1.4 So the sysfs structure you suggested would be possible, I just don't know if it's preferred one or not. It would require an ack from Greg. I'd see it as follows: #cat available_ports #1-1 1-2 2-1 #echo "1-1" > new_port #cat observed_ports #1-1 #echo "2-1" > new_port #cat observed_ports #1-1 2-1 We've already had few discussions about the sysfs designs trying to break the one-value-per-file rule for LED class device, and there was always strong resistance against. Cc Pavel. Confirmation: yes, right now I create simple files with chmod 000 for every port added to the usbport observable list. Also a description of the device connected to the port would be a nice feature, however I am not certain about the feasibility thereof. What kind of description do you mean? Where should it be used / where should it appear? Product name/symbol. Actually it should be USB subsystem responsibility to provide the means for querying the product name by port id, if it is possible at all. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger
ctivated)
+ return;
+
+ list_for_each_entry_safe(port, tmp, _data->ports, list) {
+ usbport_trig_remove_port(usbport_data, port);
+ }
+
+ usb_unregister_notify(_data->nb);
+
+ device_remove_file(led_cdev->dev, _attr_remove_port);
+ device_remove_file(led_cdev->dev, _attr_new_port);
+
+ kobject_put(usbport_data->ports_dir);
+
+ kfree(usbport_data);
+
+ led_cdev->activated = false;
+}
+
+static struct led_trigger usbport_led_trigger = {
+ .name = "usbport",
+ .activate = usbport_trig_activate,
+ .deactivate = usbport_trig_deactivate,
+};
+
+static int __init usbport_trig_init(void)
+{
+ return led_trigger_register(_led_trigger);
+}
+
+static void __exit usbport_trig_exit(void)
+{
+ led_trigger_unregister(_led_trigger);
+}
+
+module_init(usbport_trig_init);
+module_exit(usbport_trig_exit);
+
+MODULE_AUTHOR("Rafał Miłecki <ra...@milecki.pl>");
+MODULE_DESCRIPTION("USB port trigger");
+MODULE_LICENSE("GPL");
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] leds: trigger: Introduce an USB port trigger
trig_init(void)
+{
+ return led_trigger_register(_led_trigger);
+}
+
+static void __exit usbport_trig_exit(void)
+{
+ led_trigger_unregister(_led_trigger);
+}
+
+module_init(usbport_trig_init);
+module_exit(usbport_trig_exit);
+
+MODULE_AUTHOR("Rafał Miłecki <rafal.mile...@gmail.com>");
+MODULE_DESCRIPTION("USB port trigger");
+MODULE_LICENSE("GPL");
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] leds: documentation: 'ide-disk' to 'disk-activity'
Hi Stephan,
On 06/24/2016 07:16 PM, Stephan Linz wrote:
Cc: Joseph Jezak <jos...@gentoo.org>
Cc: Jörg Sommer <jo...@alea.gnuu.de>
Cc: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Stephan Linz <l...@li-pro.net>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
---
Changes in v6:
- Reorganize v5.
Changes in v5:
- Keep documentation for the old 'ide-disk' device tree
binding, but mark as deprecated and refer to the new
trigger 'disk-activity'.
Changes in v4:
- Keep the 'ide-disk' trigger and add a second one
for 'disk-activity'.
Changes in v3:
- Port to kernel 4.x
- Split into platform independent and dependent parts.
v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
Documentation/devicetree/bindings/leds/common.txt| 4 +++-
Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
Documentation/laptops/asus-laptop.txt| 2 +-
Documentation/leds/leds-class.txt| 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..93ef6e6 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -26,7 +26,9 @@ Optional properties for child nodes:
"default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
"heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "disk-activity" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated),
+ in new implementations use "disk-activity"
"timer" - LED flashes at a fixed, configurable rate
- led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..5b1b43a 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -33,9 +33,9 @@ Examples:
leds {
compatible = "gpio-leds";
hdd {
- label = "IDE Activity";
+ label = "Disk Activity";
gpios = <_pio 0 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
fault {
diff --git a/Documentation/laptops/asus-laptop.txt
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
echo 1 > /sys/class/leds/asus::mail/brightness
will switch the mail LED on.
You can also know if they are on/off by reading their content and use
- kernel triggers like ide-disk or heartbeat.
+ kernel triggers like disk-activity or heartbeat.
Backlight
-
diff --git a/Documentation/leds/leds-class.txt
b/Documentation/leds/leds-class.txt
index 44f5e6b..f1f7ec9 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero
brightness settings.
The class also introduces the optional concept of an LED trigger. A trigger
is a kernel based source of led events. Triggers can either be simple or
complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the
disk-activity,
nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
optimises away.
Applied, thanks.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] leds: documentation: 'ide-disk' to 'disk-activity'
Hi Stephan,
On 06/23/2016 09:38 PM, Stephan Linz wrote:
Cc: Joseph Jezak <jos...@gentoo.org>
Cc: Jörg Sommer <jo...@alea.gnuu.de>
Cc: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Stephan Linz <l...@li-pro.net>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
---
Changes in v5:
- Keep documentation for the old 'ide-disk' device tree
binding, but mark as deprecated and refer to the new
trigger 'disk-activity'.
Changes in v4:
- Keep the 'ide-disk' trigger and add a second one
for 'disk-activity'.
Changes in v3:
- Port to kernel 4.x
- Split into platform independent and dependent parts.
v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
Documentation/devicetree/bindings/leds/common.txt| 5 -
Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
Documentation/laptops/asus-laptop.txt| 2 +-
Documentation/leds/leds-class.txt| 2 +-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..1c32e31 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -25,8 +25,11 @@ Optional properties for child nodes:
system
"default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
+ "disk-activity" - LED indicates disk activity, the old name "ide-disk" is
+ still valid for backward compatibility
"heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated), do not use for
+ new implementation, use the new "disk-activity" name instead
I'd like to reorganize this change.
I think that the two affected properties should be placed next to
each other. I'd also remove the remark about ide-disk at disk-activity,
since we're leaving ide-disk, with added reference to disk-activity.
How about following:
+ "disk-activity" - LED indicates disk activity
- "ide-disk" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated),
in new implementations use "disk-activity"
"timer" - LED flashes at a fixed, configurable rate
- led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..5b1b43a 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -33,9 +33,9 @@ Examples:
leds {
compatible = "gpio-leds";
hdd {
- label = "IDE Activity";
+ label = "Disk Activity";
gpios = <_pio 0 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
fault {
diff --git a/Documentation/laptops/asus-laptop.txt
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
echo 1 > /sys/class/leds/asus::mail/brightness
will switch the mail LED on.
You can also know if they are on/off by reading their content and use
- kernel triggers like ide-disk or heartbeat.
+ kernel triggers like disk-activity or heartbeat.
Backlight
-
diff --git a/Documentation/leds/leds-class.txt
b/Documentation/leds/leds-class.txt
index 44f5e6b..f1f7ec9 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero
brightness settings.
The class also introduces the optional concept of an LED trigger. A trigger
is a kernel based source of led events. Triggers can either be simple or
complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the
disk-activity,
nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
optimises away.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] leds: documentation: 'ide-disk' to 'disk-activity'
On 06/22/2016 06:05 PM, Stephan Linz wrote: Hi Jacek, Am 22.06.2016 um 09:55 schrieb Jacek Anaszewski: On 06/21/2016 05:05 PM, Mark Rutland wrote: On Thu, Jun 09, 2016 at 12:29:37AM +0200, Stephan Linz wrote: Cc: Joseph Jezak <jos...@gentoo.org> Cc: Nico Macrionitis <ac...@cruxppc.org> Cc: Jörg Sommer <jo...@alea.gnuu.de> Signed-off-by: Stephan Linz <l...@li-pro.net> --- Documentation/devicetree/bindings/leds/common.txt| 2 +- Documentation/devicetree/bindings/leds/leds-gpio.txt | 2 +- Documentation/laptops/asus-laptop.txt| 2 +- Documentation/leds/leds-class.txt| 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index af10678..1e97169 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -26,7 +26,7 @@ Optional properties for child nodes: "default-on" - LED will turn on (but for leds-gpio see "default-state" property in Documentation/devicetree/bindings/gpio/led.txt) "heartbeat" - LED "double" flashes at a load average based rate - "ide-disk" - LED indicates disk activity + "disk-activity" - LED indicates disk activity "timer" - LED flashes at a fixed, configurable rate We should not break the binding. Code must continue to support "ide-disk", though we can mark it deprecated in the binding documentation, and update the in-kernel dts files to use "disk-activity". The code in the version 4 of the patchset supports also "ide-disk". Stephan, could you send a new version of this patch, with preserved "ide-disk" property, marked as deprecated? Yes, I can. I'll submit a new v5 patch set. You can pick out then the right patch for the LED for-next branch, okay? You don't need to submit whole patch set, only the affected patch. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] leds: documentation: 'ide-disk' to 'disk-activity'
On 06/21/2016 05:05 PM, Mark Rutland wrote: On Thu, Jun 09, 2016 at 12:29:37AM +0200, Stephan Linz wrote: Cc: Joseph Jezak <jos...@gentoo.org> Cc: Nico Macrionitis <ac...@cruxppc.org> Cc: Jörg Sommer <jo...@alea.gnuu.de> Signed-off-by: Stephan Linz <l...@li-pro.net> --- Documentation/devicetree/bindings/leds/common.txt| 2 +- Documentation/devicetree/bindings/leds/leds-gpio.txt | 2 +- Documentation/laptops/asus-laptop.txt| 2 +- Documentation/leds/leds-class.txt| 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index af10678..1e97169 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -26,7 +26,7 @@ Optional properties for child nodes: "default-on" - LED will turn on (but for leds-gpio see "default-state" property in Documentation/devicetree/bindings/gpio/led.txt) "heartbeat" - LED "double" flashes at a load average based rate - "ide-disk" - LED indicates disk activity + "disk-activity" - LED indicates disk activity "timer" - LED flashes at a fixed, configurable rate We should not break the binding. Code must continue to support "ide-disk", though we can mark it deprecated in the binding documentation, and update the in-kernel dts files to use "disk-activity". The code in the version 4 of the patchset supports also "ide-disk". Stephan, could you send a new version of this patch, with preserved "ide-disk" property, marked as deprecated? -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 10/46] leds: pwm: use pwm_get_args() where appropriate
Hi Boris,
On 03/30/2016 10:03 PM, Boris Brezillon wrote:
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
drivers/leds/leds-pwm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 4783bac..b48231c 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -91,6 +91,7 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
struct led_pwm *led, struct device_node *child)
{
struct led_pwm_data *led_data = >leds[priv->num_leds];
+ struct pwm_args pargs = { };
int ret;
led_data->active_low = led->active_low;
@@ -117,7 +118,8 @@ static int led_pwm_add(struct device *dev, struct
led_pwm_priv *priv,
else
led_data->cdev.brightness_set_blocking = led_pwm_set_blocking;
- led_data->period = pwm_get_period(led_data->pwm);
+ pwm_get_args(led_data->pwm, );
+ led_data->period = pargs.period;
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;
Acked-by: Jacek Anaszewski <j.anaszew...@samsung.com>
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
