t it is empty.
Any ideas on the 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
On 12/08/2016 12:38 PM, Rafał Miłecki wrote:
On 8 December 2016 at 09:40, Jacek Anaszewski wrote:
On 12/06/2016 06:29 PM, Rafał Miłecki wrote:
On 6 December 2016 at 18:26, Pavel Machek wrote:
On Fri 2016-12-02 09:48:18, Ralph Sennhauser wrote:
On Thu, 1 Dec 2016 17:56:07 +0100
Rafał
gger = "heartbeat";
> gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> };
> +
> + usb {
> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> + led-triggers = <&ohci_port1>, <&ehci_port1>;
> + };
> };
>
> max77693-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
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
> On 20 January 2017 at 23:35, Jacek Anaszewski
> wrote:
>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>>> From: Rafał Miłecki
>>>
>>> Some LEDs can be related to particular devices described in DT. This
>&g
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
>>>
>>> Some LEDs can be related to particular d
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
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
On 01/25/2017 10:03 AM, Rafał Miłecki wrote:
> On 21 January 2017 at 22:42, Jacek Anaszewski
> wrote:
>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
>>> On 20 January 2017 at 23:35, Jacek Anaszewski
>>> wrote:
>>>> On 01/20/2017 10:56 PM, Rafa
ld 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 http://vger.kernel.org/majordomo-info.html
ms 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
More majordomo info at http://
_trig_activate(struct led_classdev
*led_cdev)
return;
usbport_data->led_cdev = led_cdev;
INIT_LIST_HEAD(&usbport_data->ports);
+ usbport_trig_fill(usbport_data);
usbport_data->nb.notifier_call = usbport_trig_notify,
led_cdev
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)
+{
+ retu
On 08/25/2016 10:29 AM, Rafał Miłecki wrote:
On 25 August 2016 at 10:03, Jacek Anaszewski wrote:
On 08/24/2016 07:52 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the specified USB port. This can
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 a
On 08/26/2016 05:58 PM, Rafał Miłecki wrote:
On 25 August 2016 at 20:48, 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
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 o
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 &
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 wrote:
On 31 August 2016 at 20:23, Alan Stern wrote:
On Tue, 30 Aug 2016, Rafał Miłecki wrote:
Not really as it
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
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
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 extension in more detail
v4
s: 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
*name;
enum led_brightness brightness;
@@ -50,6 +58,7 @@ struct led_classdev {
#define LED_SYSFS_DISABLE (1 << 22)
#define LED_DEV_CAP_FLASH (1 << 23)
#define LED_HW_PLUGGABLE (1 << 24)
+#define LED_DEV_CAP_RGB(1 <<
syscall, if we 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 fro
etter have 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
(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
ism specificity.
There is a question 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 l
e 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
But that's
quite different from existing 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.
lt more people before 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 Anasz
B)
separately. It incurs delays 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 Anaszew
te LEDs.
Yes, see the proposal in 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 fr
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
And 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&qu
o value would signify the the three 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 thi
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 with
e, we could run out of free attributes for some
use cases.
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
-
gine at a time.
It would be best to work out more flexible solution. I wonder if
ioctl interface isn't the only option.
Well, there's configs, which is more flexible, but...
Best regards,
Pavel
--
Best r
ut I believe we should support the
rest.
Yes, that's an interesting 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
, but I believe we should support the
rest.
Yes, that's an 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. Ac
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
>>> wrote:
>>>> On 01/21/2017 05:24 PM, Rafał Miłeck
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:
>>>>>
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:
>>>>>
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
ses 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 linux-usb" in
the body of a messag
oseconds after which the
> flash
> @@ -69,6 +82,11 @@ gpio-leds {
> linux,default-trigger = "heartbeat";
> gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> };
> +
> + usb {
> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> +
heduled for removal, but we
would have to set it after calling activate() in LED trigger core).
It would require more effort but would allow to avoid the addition
of a new op. I'd also remove "activated" property from struct
led_classdev and made it a flag in leds.h:
+#define LED_TRIGG
On 1/1/19 3:00 PM, Christian Lamparter wrote:
Hello Jacek,
On Friday, December 28, 2018 5:29:56 PM CET Jacek Anaszewski wrote:
On 12/25/18 9:49 PM, Christian Lamparter wrote:
The patch "usb: simplify usbport trigger" together with
"leds: triggers: add device attribute sup
48 matches
Mail list logo
