Re: [PATCH V3 1/2] dt-bindings: leds: document new trigger-sources property

out-us : Maximum timeout in microseconds after which the > flash > @@ -69,6 +82,11 @@ gpio-leds { > linux,default-trigger = "heartbeat"; > gpios = < 0 GPIO_ACTIVE_HIGH>; > }; > + > + usb { > + gpios = < 1 GPIO_ACTIVE_HIGH>

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 02/03/2017 12:00 AM, Rafał Miłecki wrote: > On 02/02/2017 09:44 PM, Jacek Anaszewski wrote: >> On 02/01/2017 10:55 PM, Rafał Miłecki wrote: >>> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote: >>>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote: >>>>> O

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 02/01/2017 10:55 PM, Rafał Miłecki wrote: > On 02/01/2017 10:26 PM, Jacek Anaszewski wrote: >> On 02/01/2017 04:56 PM, Rafał Miłecki wrote: >>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: >>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote: >>>>

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 02/01/2017 04:56 PM, Rafał Miłecki wrote: > On 01/31/2017 10:34 PM, Jacek Anaszewski wrote: >> On 01/31/2017 05:11 PM, Rafał Miłecki wrote: >>> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: >>>> On 01/25/2017 10:03 AM, Rafał Miłecki wrote: >>>>>

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

Hi Rafał, On 01/31/2017 05:11 PM, Rafał Miłecki wrote: > On 01/25/2017 10:04 PM, Jacek Anaszewski wrote: >> On 01/25/2017 10:03 AM, Rafał Miłecki wrote: >>> On 21 January 2017 at 22:42, Jacek Anaszewski >>> <jacek.anaszew...@gmail.com> wrote: >>>>

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:03 AM, Rafał Miłecki wrote: > On 21 January 2017 at 22:42, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> On 01/21/2017 05:24 PM, Rafał Miłecki wrote: >>> On 20 January 2017 at 23:35, Jacek Anaszewski >>> <jacek.anaszew...@gmail.

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:08 AM, Rafał Miłecki wrote: > On 01/23/2017 05:45 PM, Rob Herring wrote: >> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: >>> Hi Rafał, >>> >>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote: >>>> From: Rafał Mi

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:18 AM, Rafał Miłecki wrote: > On 01/23/2017 09:51 PM, Jacek Anaszewski wrote: >> On 01/23/2017 05:45 PM, Rob Herring wrote: >>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: >>>> Hi Rafał, >>>> >>>> On 01/20

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/23/2017 05:45 PM, Rob Herring wrote: > On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote: >> Hi Rafał, >> >> On 01/20/2017 10:56 PM, Rafał Miłecki wrote: >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >>> Some LED

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/21/2017 05:24 PM, Rafał Miłecki wrote: > On 20 January 2017 at 23:35, Jacek Anaszewski > <jacek.anaszew...@gmail.com> wrote: >> On 01/20/2017 10:56 PM, Rafał Miłecki wrote: >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >>> Some LEDs c

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

; linux,default-trigger = "heartbeat"; > gpios = < 0 GPIO_ACTIVE_HIGH>; > }; > + > + usb { > + gpios = < 1 GPIO_ACTIVE_HIGH>; > + led-triggers = <_port1>, <_port1>; > + };

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On 12/08/2016 12:38 PM, Rafał Miłecki wrote: On 8 December 2016 at 09:40, Jacek Anaszewski <j.anaszew...@samsung.com> wrote: On 12/06/2016 06:29 PM, Rafał Miłecki wrote: On 6 December 2016 at 18:26, Pavel Machek <pa...@ucw.cz> wrote: On Fri 2016-12-02 09:48:18, Ralph Senn

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

e possible reasons? Exynos4412-trats2 uses Ethernet Gadget (with CDC Ethernet support) USB Gadget Driver for USB networking. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" 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

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-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at h

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

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

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

On 09/01/2016 04:36 PM, Alan Stern wrote: On Thu, 1 Sep 2016, Jacek Anaszewski wrote: 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

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

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

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 08/26/2016 09:50 PM, Pavel Machek wrote: On Thu 2016-08-25 20:48:04, Jacek Anaszewski 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 observ

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 #ech

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

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

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

.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-usb" 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 PROOF OF CONCEPT 2/1] trigger: ledtrig-usbport: read initial state from DT

data->led_cdev = led_cdev; INIT_LIST_HEAD(_data->ports); + usbport_trig_fill(usbport_data); usbport_data->nb.notifier_call = usbport_trig_notify, led_cdev->trigger_data = usbport_data; -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 1/4] leds: core: add generic support for RGB Color LED's

interesting idea. It also turns out that trigger based patterns could be also used for defining generic patterns for a group of monochrome LEDs. Yes, controlling monochrome LEDs synchronously is another task for patterns. Actually, N900 uses that to control 6 keyboard backlight LEDs synchronously.

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

sting idea. It also turns out that trigger based patterns could be also used for defining generic patterns for a group of monochrome LEDs. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 1/4] leds: core: add generic support for RGB Color LED's

I wonder if ioctl interface isn't the only option. Well, there's configs, which is more flexible, but... Best regards, Pavel -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "u

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

The same constraints would appear if we wanted to be able to define more than one pattern. It would be best to work out more flexible solution. I wonder if ioctl interface isn't the only option. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi Heiner, Thanks for the feedback. On 04/05/2016 10:43 PM, Heiner Kallweit wrote: Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski: On 04/05/2016 11:01 AM, Pavel Machek wrote: Hi! It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

LED class devices are in sync and that setting a trigger on any of them applies to the remaining two ones. It would have to be considered whether existing triggers could be made compatible with synchronized RGB LED class devices. I'm curious what do you think about the idea. Pavel, Heine

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

d yes, it involves three values in a file, but now it is array of led brightnesses, and that might actually be acceptable. (At least the values have uniform meaning). > Plus, it is not "issue you were opposed to" it is "something that is not permitted by sysfs maintainers".

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

On 04/01/2016 03:57 PM, Pavel Machek wrote: Hi! On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote: Hi Heiner and Pavel, On 03/29/2016 10:38 PM, Heiner Kallweit wrote: Am 29.03.2016 um 12:02 schrieb Pavel Machek: Hi! First, please Cc me on RGB color support. Add generic support for RGB

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

the other mail. I believe we should have separate R, G, B LED devices, and separate pattern controller. Best regards, Pavel -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

s between setting each colour component. It is also impossible to set arbitrary colour from a trigger. Similarly blinking with arbitrarily chosen colour from RGB palette is impossible if separate colour components are treated as separate LEDs. -- Best regards, Jacek Anaszewski -- To unsubscribe from thi

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

e pushing the solution upstream. Would you mind writing a message with an explanation of the issue to linux-api list? Please keep in mind also the information from the "Attributes" section of Documentation/filesystems/sysfs.txt. -- Best regards, Jacek Anaszewski -- To unsubscribe f

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

isting support...) Please note that HSV colour scheme allows to neatly project monochrome brightness semantics on the RGB realm. I.e. you can have fixed hue and saturation, and by changing the brightness component a perceived colour intensity can be altered. -- Best regards, Jacek Anaszewsk

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

the RGB extension in a not supported way (by setting flag LED_DEV_CAP_RGB and implementing brightness_get). Pavel -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linu

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

on whether we can bend the sysfs "one value per sysfs file" rule down to RGB LEDs needs. Of course other brilliant ideas on how to approach the problem are more than expected. -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscrib

Re: [PATCH v8 1/5] leds: core: add generic support for RGB LED's

ine LED_DEV_CAP_RGB(1 << 24) +#define LED_HW_PLUGGABLE (1 << 25) /* Set LED brightness level * Must not sleep. Use brightness_set_blocking for drivers Replaced v7 in devel branch. I've also changed two occurrences of "RGB LED class" to "LED RGB class" to comply with "LED Flash Class". -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's

it in linux-next through the whole next development cycle for the people to comment on. Thanks, Jacek Anaszewski On 03/04/2016 10:09 PM, Heiner Kallweit wrote: Add generic support for RGB LED's. Basic idea is to use enum led_brightness also for the hue and saturation color components.This

Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's

want to make it synchronous and compatible with LED triggers. HSV color scheme is also very convenient for adapting monochrome brightness semantics to the RGB realm. [1] http://www.spinics.net/lists/linux-leds/msg05477.html -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send

Re: [PATCH v5 4/4] leds: core: add support for RGB LED's

convert + * + * Returns: the resulting rgb value + */ +enum led_brightness led_hsv_to_rgb(enum led_brightness hsv); + /* * LED Triggers */ -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 1/4] leds: core: add generic support for RGB Color LED's

ED_DEV_CAP_RGB(1 << 25) Please keep CAP flags next to each other. You can change values of the existing flags, they're internal to kernel. /* Set LED brightness level * Must not sleep. Use brightness_set_blocking for drivers -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 3/4] leds: core: add documentation for color extension

Hi Heiner, Please split the sysfs-class-led part to a separate patch. On 03/02/2016 08:31 PM, Heiner Kallweit wrote: Document the color extension in Documentation/leds/leds-class.txt Signed-off-by: Heiner Kallweit --- v2: - introduced to patch series v3: - document

Re: [PATCH v5 3/4] leds: core: add documentation for color extension

ut now, as the functionality seems to be reaching its final shape, please update also: Documentation/ABI/testing/sysfs-class-led -- Best regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org Mor

Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types

ng opinion against removing range checks in such cases as he finds it clearer. I think it applies to patches 29-36. I am not sure about patches 26-28,37. Dropped 30/38 and 31/38 from LED tree then. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe