On Tue, Nov 13, 2018 at 8:55 PM Jacek Anaszewski
wrote:
> LED core has had a protection
> against name clash since the commit:
>
> commit a96aa64cb5723d941de879a9cd1fea025d6acb1b
> Author: Ricardo Ribalda Delgado
> Date: Mon Mar 30 10:45:59 2015 -0700
>
> leds/led-class: Handle LEDs with t
On Tue 2018-11-13 22:38:49, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Mon, Nov 12, 2018 at 11:07 PM Pavel Machek wrote:
> > Not really, I'm afraid. Hard drives have no red LEDs on them (and the
> > LED would not be visible, anyway) so the "device" symlink in such case
> > would point to some k
Hi Pavel,
On Mon, Nov 12, 2018 at 11:07 PM Pavel Machek wrote:
> Not really, I'm afraid. Hard drives have no red LEDs on them (and the
> LED would not be visible, anyway) so the "device" symlink in such case
> would point to some kind of i2c LED controller.
I've seen hard drives with LEDs on the
On 11/12/2018 11:06 PM, Pavel Machek wrote:
> On Mon 2018-11-12 21:11:32, Jacek Anaszewski wrote:
>> On 11/12/2018 08:05 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>> My system looks like this:
>>>
>>> input16::capslocktpacpi::bay_activetpacpi::standby
>>> input16::numlock tpa
On 11/12/2018 10:23 PM, Linus Walleij wrote:
> On Sun, Nov 11, 2018 at 1:03 PM Pavel Machek wrote:
>
>>> -"devicename:colour:function"
>>> +"colour:function"
>>
>> I don't think we want to do it in all cases.
>>
>> So, on my cellphone seeing lp5523:green:led is indeed not useful.
>>
>> But on not
Hi!
> > Couldn't we have here multiple variants that would then be chosen based
> > on device tree definition?
>
> It needs to be subsystem specific or something.
> What you say make sense for things based on device
> tree.
>
> The problem hit me on an Intel laptop with several
> USB keyboards.
On Mon 2018-11-12 21:11:32, Jacek Anaszewski wrote:
> On 11/12/2018 08:05 PM, Pavel Machek wrote:
> > Hi!
> >
> > My system looks like this:
> >
> > input16::capslocktpacpi::bay_activetpacpi::standby
> > input16::numlock tpacpi::dock_active tpacpi::thinklight
> >
On Mon, Nov 12, 2018 at 1:02 AM Vesa Jääskeläinen wrote:
> Couldn't we have here multiple variants that would then be chosen based
> on device tree definition?
It needs to be subsystem specific or something.
What you say make sense for things based on device
tree.
The problem hit me on an Intel
On Sun, Nov 11, 2018 at 1:03 PM Pavel Machek wrote:
> > -"devicename:colour:function"
> > +"colour:function"
>
> I don't think we want to do it in all cases.
>
> So, on my cellphone seeing lp5523:green:led is indeed not useful.
>
> But on notebook with usb keyboard attached, you need to keep the
On 11/12/2018 08:05 PM, Pavel Machek wrote:
> Hi!
>
> My system looks like this:
>
> input16::capslocktpacpi::bay_activetpacpi::standby
> input16::numlock tpacpi::dock_active tpacpi::thinklight
> input16::scrolllock tpacpi::dock_batt tpacpi::thinkvantage
Hi!
> >>> My system looks like this:
> >>>
> >>> input16::capslocktpacpi::bay_activetpacpi::standby
> >>> input16::numlock tpacpi::dock_active tpacpi::thinklight
> >>> input16::scrolllock tpacpi::dock_batt tpacpi::thinkvantage
> >>> input5::capslock tpacpi::dock_status1
Hi,
On 11/12/2018 11:35 AM, Pavel Machek wrote:
> Hi!
>
It's overcomplicating the naming again. In every case you can tweak
the function name to eth0_link, eth1_link etc.
>>>
>>> Well, but in such case it would be good to keep existing scheme.
>>>
>>> My system looks like this:
>>>
>>>
On 11/12/2018 01:01 AM, Vesa Jääskeläinen wrote:
> Hi,
>
> On 11/11/2018 23.14, Jacek Anaszewski wrote:
>> On 11/11/2018 09:16 PM, Pavel Machek wrote:
>>> Hi!
>>>
>> diff --git a/Documentation/leds/leds-class.txt
>> b/Documentation/leds/leds-class.txt
>> index 836cb16..e9009c4 100644
>
Hi!
> >> It's overcomplicating the naming again. In every case you can tweak
> >> the function name to eth0_link, eth1_link etc.
> >
> > Well, but in such case it would be good to keep existing scheme.
> >
> > My system looks like this:
> >
> > input16::capslocktpacpi::bay_activetpacpi:
Hi,
On 11/11/2018 23.14, Jacek Anaszewski wrote:
On 11/11/2018 09:16 PM, Pavel Machek wrote:
Hi!
diff --git a/Documentation/leds/leds-class.txt
b/Documentation/leds/leds-class.txt
index 836cb16..e9009c4 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@
On 11/11/2018 09:16 PM, Pavel Machek wrote:
> Hi!
>
diff --git a/Documentation/leds/leds-class.txt
b/Documentation/leds/leds-class.txt
index 836cb16..e9009c4 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -43,7 +43,7 @@ LED
Hi!
> >> diff --git a/Documentation/leds/leds-class.txt
> >> b/Documentation/leds/leds-class.txt
> >> index 836cb16..e9009c4 100644
> >> --- a/Documentation/leds/leds-class.txt
> >> +++ b/Documentation/leds/leds-class.txt
> >> @@ -43,7 +43,7 @@ LED Device Naming
> >>
> >> Is currently of the f
Hi Pavel,
On 11/11/2018 01:02 PM, Pavel Machek wrote:
> Hi!
>
>> Add public led_compose_name() API for composing LED class device
>> name basing on fwnode_handle data. The function composes device name
>> according to either a new pattern or the legacy
>> pattern. The decision on using the
>> p
Hi!
> Add public led_compose_name() API for composing LED class device
> name basing on fwnode_handle data. The function composes device name
> according to either a new pattern or the legacy
> pattern. The decision on using the
> particular pattern is made basing on whether fwnode contains new
Hi Jacek,
On 9 November 2018 at 04:47, Jacek Anaszewski
wrote:
> Hi Baolin,
>
> Thanks for the review.
>
> On 11/07/2018 08:20 AM, Baolin Wang wrote:
>> Hi Jacek,
>>
>> On 7 November 2018 at 06:07, Jacek Anaszewski
>> wrote:
>>> Add public led_compose_name() API for composing LED class device
>>
Dan,
On 11/08/2018 07:06 PM, Dan Murphy wrote:
> On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
>> Add public led_compose_name() API for composing LED class device
>> name basing on fwnode_handle data. The function composes device name
>> according to either a new pattern or the legacy
>> patte
Hi Baolin,
Thanks for the review.
On 11/07/2018 08:20 AM, Baolin Wang wrote:
> Hi Jacek,
>
> On 7 November 2018 at 06:07, Jacek Anaszewski
> wrote:
>> Add public led_compose_name() API for composing LED class device
>> name basing on fwnode_handle data. The function composes device name
>> acco
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Add public led_compose_name() API for composing LED class device
> name basing on fwnode_handle data. The function composes device name
> according to either a new pattern or the legacy
> pattern. The decision on using the
> particular pattern is
Hi Jacek,
On 7 November 2018 at 06:07, Jacek Anaszewski
wrote:
> Add public led_compose_name() API for composing LED class device
> name basing on fwnode_handle data. The function composes device name
> according to either a new pattern or the legacy
> pattern. The decision on using the
> parti
Add public led_compose_name() API for composing LED class device
name basing on fwnode_handle data. The function composes device name
according to either a new pattern or the legacy
pattern. The decision on using the
particular pattern is made basing on whether fwnode contains new
"function" and
25 matches
Mail list logo