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/
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 us
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
>>> <jac
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
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
orce 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 equi
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
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 c
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 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:
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 L
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;
&g
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
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 vibrat
tion" 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
nes, 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
> long as the app is alive, it can keep the LED illuminated, if it dies
>
[0]
https://android.
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 l
data->duration));
> + transient_timer_start(led_cdev);
> }
>
> /* state == 0 && transient_data->activate == 0
> @@ -182,8 +232,7 @@ static void transient_trig_activate(struct led_classdev
> *led_cdev)
> if (rc)
> goto err_out_state;
>
> - setup_timer(>timer, transient_timer_function,
> - (unsigned long) led_cdev);
> + transient_timer_setup(led_cdev);
> led_cdev->activated = true;
>
> return;
>
--
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
+#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
ould 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 h
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
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
s 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 th
c_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
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
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
#ech
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
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
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
.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
_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);
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>
S
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>
S
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...@cruxpp
ated 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?
--
Bes
ed_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 fro
36 matches
Mail list logo
