Hi all,
On 1/20/19 7:42 AM, Vesa Jääskeläinen wrote:
Hi Dan,
On 18/01/2019 15.58, Dan Murphy wrote:
Jacek
On 1/18/19 7:45 AM, Dan Murphy wrote:
Jacek
On 1/17/19 3:10 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/16/19 7:41 PM, Dan Murphy wrote:
Hello
On 1/16/19 4:55 AM, Pavel Machek wrote
On 1/20/19 4:30 PM, Jacek Anaszewski wrote:
On 1/19/19 10:36 PM, Pavel Machek wrote:
Hi!
[...]
I want to make sure userspace understands this has linear relation to
output power. I'd like to avoid mentioning color because there power
output is not linear with "RGB"
s/pwm/colo
.driver = {
+ .name = "max77650-leds",
s/leds/led/
+ },
+ .probe = max77650_leds_probe,
+};
+module_platform_driver(max77650_leds_driver);
+
+MODULE_DESCRIPTION("MAXIM 77650/77651 LED driver");
+MODULE_AUTHOR("Bartosz Golaszewski ");
+MODULE_LICENSE("GPL");
s/GPL/GPL v2/
[0] https://lkml.org/lkml/2017/11/2/715
--
Best regards,
Jacek Anaszewski
s/led2/led@2/
+ reg = <2>;
+ label = "max77650:green:usr2";
+ };
Please remove "max77650:" from labels and add it in the driver.
+ };
--
Best regards,
Jacek Anaszewski
Dan,
On 1/18/19 2:45 PM, Dan Murphy wrote:
Jacek
On 1/17/19 3:10 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/16/19 7:41 PM, Dan Murphy wrote:
Hello
On 1/16/19 4:55 AM, Pavel Machek wrote:
Hi!
On 1/15/19 4:22 PM, Pavel Machek wrote:
Hi!
+The 24-bit RGB value passed in follows the pattern
in practice? Would it allow to convert RGB values
of the color displayed on the monitor to LED RGB class intensities,
allowing to achieve similar color on the LED?
--
Best regards,
Jacek Anaszewski
land needs to do non-trivial math to get colors it wants
- not sure how to migrate existing devices
Thoughts? Other possible interfaces?
[0] https://www.mouser.com/ds/2/348/bd2802gu-e-210449.pdf
--
Best regards,
Jacek Anaszewski
-for-5.0-rc3
for you to fetch changes up to 248b57015f35c94d4eae2fdd8c6febf5cd703900:
leds: lp5523: fix a missing check of return value of lp55xx_read (2019-01-17
22:27:39 +0100)
Thanks,
Jacek Anaszewski
LED fix for 5.0-rc3
ues - it shall
use software HSV->RGB algorithm for setting color registers
- any other custom color ranges defined in DT, but it can be covered
later
- other options?
Best regards,
Jacek Anaszewski
It was agreed to continue forward with this particular implementation.
At least thats wha
the ideas shared in this thread and have
finally LED RGB class materialized.
--
Best regards,
Jacek Anaszewski
ges since v1:
1. Rebase on Jacek's patches.
2. Add patch 3/5 for fixup of Jacek's solution.
3. Drop first two patches from the series (applied).
4. Patch 5/5: Use LED_INIT_DEFAULT_TRIGGER (suggested by Jacek Anaszewski).
5. Patch 5/5: Return-on-error and log warning (suggested by Pavel Machek).
dev_err(>client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ mutex_destroy(>lock);
+
+ return 0;
+}
+
+static const struct i2c_device_id lp50xx_id[] = {
+ { "lp5018", LP5018 },
+ { "lp5024", LP5024 },
+ { "lp5030", LP5030 },
+ { "lp5036", LP5036 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lp50xx_id);
+
+static const struct of_device_id of_lp50xx_leds_match[] = {
+ { .compatible = "ti,lp5018", },
+ { .compatible = "ti,lp5024", },
+ { .compatible = "ti,lp5030", },
+ { .compatible = "ti,lp5036", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lp50xx_leds_match);
+
+static struct i2c_driver lp50xx_driver = {
+ .driver = {
+ .name = "lp50xx",
+ .of_match_table = of_lp50xx_leds_match,
+ },
+ .probe = lp50xx_probe,
+ .remove = lp50xx_remove,
+ .id_table = lp50xx_id,
+};
+module_i2c_driver(lp50xx_driver);
+
+MODULE_DESCRIPTION("Texas Instruments LP5024 LED driver");
+MODULE_AUTHOR("Dan Murphy ");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
ti,led-module = <4>;
+ };
+
+ led@3 {
+ reg = <3>;
+ label = "led7_mod";
+ ti,led-module = <7>;
+ };
+
+ led@4 {
+ reg = <4>;
+ label = "led6_mod";
+ ti,led-module = <6>;
+ };
+
+ led@5 {
+ reg = <5>;
+ label = "led8_mod";
+ ti,led-module = <8>;
+ };
+};
+
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/symlink/lp5024.pdf
+http://www.ti.com/lit/ds/symlink/lp5036.pdf
--
Best regards,
Jacek Anaszewski
hich
was the first thing that came to my mind when reading your message.
--
Best regards,
Jacek Anaszewski
Hi Dan,
On 1/14/19 1:27 PM, Dan Murphy wrote:
Jacek
On 1/12/19 1:48 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/12/19 6:09 PM, Dan Murphy wrote:
Jacek
On 1/11/19 3:52 PM, Jacek Anaszewski wrote:
Dan,
On 1/11/19 1:38 PM, Dan Murphy wrote:
Jacek
Sorry I missed some replies
On 1/10/19 4:03
with brightness_model thing if this is
something that is good path?
What do you think?
--
Best regards,
Jacek Anaszewski
Hi Vesa,
On 1/9/19 7:46 AM, Vesa Jääskeläinen wrote:
Hi Jacek,
On 07/01/2019 23.13, Jacek Anaszewski wrote:
Hi Vesa,
On 1/5/19 1:39 AM, Vesa Jääskeläinen wrote:
Hi Jacek,
On 04/01/2019 23.37, Jacek Anaszewski wrote:
But, aside from that hypothetic issue, we need a solution
Hi Dan,
On 1/12/19 6:09 PM, Dan Murphy wrote:
Jacek
On 1/11/19 3:52 PM, Jacek Anaszewski wrote:
Dan,
On 1/11/19 1:38 PM, Dan Murphy wrote:
Jacek
Sorry I missed some replies
On 1/10/19 4:03 PM, Jacek Anaszewski wrote:
On 1/10/19 9:43 PM, Dan Murphy wrote:
Jacek
On 1/10/19 1:57 PM, Jacek
Dan,
On 1/11/19 1:38 PM, Dan Murphy wrote:
Jacek
Sorry I missed some replies
On 1/10/19 4:03 PM, Jacek Anaszewski wrote:
On 1/10/19 9:43 PM, Dan Murphy wrote:
Jacek
On 1/10/19 1:57 PM, Jacek Anaszewski wrote:
Dan,
On 1/10/19 8:22 PM, Dan Murphy wrote:
Jacek
On 1/10/19 12:44 PM, Jacek
On 1/10/19 9:43 PM, Dan Murphy wrote:
Jacek
On 1/10/19 1:57 PM, Jacek Anaszewski wrote:
Dan,
On 1/10/19 8:22 PM, Dan Murphy wrote:
Jacek
On 1/10/19 12:44 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/9/19 10:31 PM, Dan Murphy wrote:
Jacek
On 1/9/19 3:28 PM, Jacek Anaszewski wrote:
On 1/9/19
On 1/10/19 8:58 PM, Dan Murphy wrote:
On 1/10/19 1:23 PM, Jacek Anaszewski wrote:
Dan,
On 1/10/19 1:46 PM, Dan Murphy wrote:
Jacek
On 1/8/19 3:25 PM, Dan Murphy wrote:
Jacek
On 1/8/19 3:18 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/7/19 10:14 PM, Dan Murphy wrote:
Jacek
On 1/7/19 2:59 PM
Dan,
On 1/10/19 8:22 PM, Dan Murphy wrote:
Jacek
On 1/10/19 12:44 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/9/19 10:31 PM, Dan Murphy wrote:
Jacek
On 1/9/19 3:28 PM, Jacek Anaszewski wrote:
On 1/9/19 10:12 PM, Dan Murphy wrote:
On 1/9/19 2:12 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/8
Dan,
On 1/10/19 1:46 PM, Dan Murphy wrote:
Jacek
On 1/8/19 3:25 PM, Dan Murphy wrote:
Jacek
On 1/8/19 3:18 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/7/19 10:14 PM, Dan Murphy wrote:
Jacek
On 1/7/19 2:59 PM, Jacek Anaszewski wrote:
Dan,
On 1/7/19 8:36 PM, Dan Murphy wrote:
Jacek
On 1/7
Hi Dan,
On 1/9/19 10:31 PM, Dan Murphy wrote:
Jacek
On 1/9/19 3:28 PM, Jacek Anaszewski wrote:
On 1/9/19 10:12 PM, Dan Murphy wrote:
On 1/9/19 2:12 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/8/19 10:22 PM, Dan Murphy wrote:
On 1/8/19 3:16 PM, Jacek Anaszewski wrote:
On 1/8/19 9:53 PM, Dan
On 1/9/19 10:12 PM, Dan Murphy wrote:
On 1/9/19 2:12 PM, Jacek Anaszewski wrote:
Hi Dan,
On 1/8/19 10:22 PM, Dan Murphy wrote:
On 1/8/19 3:16 PM, Jacek Anaszewski wrote:
On 1/8/19 9:53 PM, Dan Murphy wrote:
Jacek
On 1/8/19 2:33 PM, Jacek Anaszewski wrote:
Dan,
On 12/19/18 5:26 PM, Dan
if (ctx->jpeg->variant->version == SJPEG_S5P)
mask = ~0x06; /* 422, 420 */
}
Reviewed-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
Hi Krzysztof,
Thank you for the update.
Patch set looks good to me.
Now we're missing only ack from Rob for this patch.
Best regards,
Jacek Anaszewski
On 1/9/19 3:44 PM, Krzysztof Kozlowski wrote:
Document new led-pattern property for initialization of LED triggers.
The property format
Hi Dan,
On 1/8/19 10:22 PM, Dan Murphy wrote:
On 1/8/19 3:16 PM, Jacek Anaszewski wrote:
On 1/8/19 9:53 PM, Dan Murphy wrote:
Jacek
On 1/8/19 2:33 PM, Jacek Anaszewski wrote:
Dan,
On 12/19/18 5:26 PM, Dan Murphy wrote:
Introduce the bindings for the Texas Instruments LP5024 and the LP5018
Hi Dan,
On 1/7/19 10:14 PM, Dan Murphy wrote:
Jacek
On 1/7/19 2:59 PM, Jacek Anaszewski wrote:
Dan,
On 1/7/19 8:36 PM, Dan Murphy wrote:
Jacek
On 1/7/19 1:13 PM, Jacek Anaszewski wrote:
On 1/6/19 4:52 PM, Jacek Anaszewski wrote:
Hi Pavel,
On 1/5/19 11:12 PM, Pavel Machek wrote:
Hi
On 1/8/19 9:53 PM, Dan Murphy wrote:
Jacek
On 1/8/19 2:33 PM, Jacek Anaszewski wrote:
Dan,
On 12/19/18 5:26 PM, Dan Murphy wrote:
Introduce the bindings for the Texas Instruments LP5024 and the LP5018
RGB LED device driver. The LP5024/18 can control RGB LEDs individually
or as part
8 },
+ { "lp5024", LP5024 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lp5024_id);
+
+static const struct of_device_id of_lp5024_leds_match[] = {
+ { .compatible = "ti,lp5018", },
+ { .compatible = "ti,lp5024", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lp5024_leds_match);
+
+static struct i2c_driver lp5024_driver = {
+ .driver = {
+ .name = "lp5024",
+ .of_match_table = of_lp5024_leds_match,
+ },
+ .probe = lp5024_probe,
+ .remove = lp5024_remove,
+ .id_table = lp5024_id,
+};
+module_i2c_driver(lp5024_driver);
+
+MODULE_DESCRIPTION("Texas Instruments LP5024 LED driver");
+MODULE_AUTHOR("Dan Murphy ");
+MODULE_LICENSE("GPL v2");
--
Best regards,
Jacek Anaszewski
describes control bank?
Also, does it make sense to have only two LEDs in the bank?
+ };
+
+}
+
+For more product information please see the link below:
+http://www.ti.com/lit/ds/symlink/lp5024.pdf
--
Best regards,
Jacek Anaszewski
Hi Vesa,
On 1/5/19 1:39 AM, Vesa Jääskeläinen wrote:
Hi Jacek,
On 04/01/2019 23.37, Jacek Anaszewski wrote:
But, aside from that hypothetic issue, we need a solution for
LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity
via a single register write. How would you propose
Dan,
On 1/7/19 8:36 PM, Dan Murphy wrote:
Jacek
On 1/7/19 1:13 PM, Jacek Anaszewski wrote:
On 1/6/19 4:52 PM, Jacek Anaszewski wrote:
Hi Pavel,
On 1/5/19 11:12 PM, Pavel Machek wrote:
Hi!
Grab yourself an RGB LED and play with it; you'll see what the
problems are. It is hard to explain
On 1/6/19 4:52 PM, Jacek Anaszewski wrote:
Hi Pavel,
On 1/5/19 11:12 PM, Pavel Machek wrote:
Hi!
Grab yourself an RGB LED and play with it; you'll see what the
problems are. It is hard to explain colors over email...
Video [0] gives some overview of lp5024 capabilities.
I don't see any
g/tiduee6/tiduee6.pdf
[1] http://www.everlight.com/file/ProductFile/19-337-R6GHBHC-A01-2T.pdf
--
Best regards,
Jacek Anaszewski
://www.youtube.com/watch?v=qdt-alh8i6E
--
Best regards,
Jacek Anaszewski
/2019/1/3/550
--
Best regards,
Jacek Anaszewski
k.
When user asks for white, it has to be white. Exact color temperature
does not matter. When user asks for pink, it has to be pink. Again,
exact color does not matter; different monitors display slightly
different colors, too
--
Best regards,
Jacek Anaszewski
Hi Vesa,
On 1/4/19 12:19 AM, Vesa Jääskeläinen wrote:
Hi Jacek,
Comments below.
On 04/01/2019 0.05, Jacek Anaszewski wrote:
Hi Vesa,
Thank you for sharing your ideas.
Please find my comment below.
On 1/1/19 2:45 PM, Vesa Jääskeläinen wrote:
Hi All,
On 20/12/2018 14.40, Vesa Jääskeläinen
ill be made
available after setting relevant color space, like "hsv", or
other color presets defined in DT
I think it will be flexible enough to meet everyone's needs.
Current triggers would work only when brightness file is available.
This is ad hoc design so it can have so
nt of_led_classdev_register(struct device *parent,
struct device_node *np,
struct led_classdev *led_cdev);
--
Best regards,
Jacek Anaszewski
On 1/1/19 7:11 PM, Dan Murphy wrote:
Jacek
Thanks for the reply!
All
Happy New Year!
Happy New Year!
On 1/1/19 8:42 AM, Jacek Anaszewski wrote:
On 12/31/18 8:15 PM, Dan Murphy wrote:
On 12/31/18 9:47 AM, Jacek Anaszewski wrote:
On 12/31/18 4:43 PM, Jacek Anaszewski wrote:
On 12/30/18
On 12/31/18 8:15 PM, Dan Murphy wrote:
On 12/31/18 9:47 AM, Jacek Anaszewski wrote:
On 12/31/18 4:43 PM, Jacek Anaszewski wrote:
On 12/30/18 6:35 PM, Pavel Machek wrote:
On Sun 2018-12-30 18:09:35, Jacek Anaszewski wrote:
On 12/29/18 8:07 PM, Pavel Machek wrote:
Hi!
With the "color&q
currently to play with it even if I had one.
In order to gain a full understanding of your idea of RGB to LED
intensity conversion, we'd need to see the full algorithm.
It feels like imposing some restrictions on user regarding
the available scope of colors to set.
--
Best regards,
Jacek Anaszewski
On 12/31/18 4:43 PM, Jacek Anaszewski wrote:
On 12/30/18 6:35 PM, Pavel Machek wrote:
On Sun 2018-12-30 18:09:35, Jacek Anaszewski wrote:
On 12/29/18 8:07 PM, Pavel Machek wrote:
Hi!
With the "color" sysfs file it will make more sense to allow for
user
defined color palettes.
On 12/30/18 6:35 PM, Pavel Machek wrote:
On Sun 2018-12-30 18:09:35, Jacek Anaszewski wrote:
On 12/29/18 8:07 PM, Pavel Machek wrote:
Hi!
With the "color" sysfs file it will make more sense to allow for user
defined color palettes.
I think defining these values in the device tr
ver would write all
color components to the hardware only on write to the file corresponding
to the main_color. Also LED Trigger core would be taught to map
brightness value to the main_color for RGB LEDs.
Of course a new internal kernel API for setting color would
have to be provided for use by dedicated RGB triggers.
--
Best regards,
Jacek Anaszewski
On 12/21/18 2:05 PM, Dan Murphy wrote:
On 12/21/2018 01:32 AM, Jacek Anaszewski wrote:
On 12/20/18 9:31 PM, Jacek Anaszewski wrote:
On 12/19/18 10:50 PM, Dan Murphy wrote:
On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
Hi Dan and Pavel,
On 12/19/18 9:41 PM, Dan Murphy wrote:
Pavel
On 12
n enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f,
SJPEG_FMT_FLAG_DEC_OUTPUT);
}
Reviewed-by: Jacek Anaszewski
--
Best regards,
Jacek Anaszewski
return ret;
+ }
return size;
-out:
- dev_err(chip->dev, "%s:i2c access fail to register\n", __func__);
- return ret;
-out_strtoint:
- dev_err(chip->dev, "%s: fail to change str to int\n", __func__);
- return ret;
}
static DEVICE_ATTR(strobe_pin, S_IWUSR, NULL, lm3642_strobe_pin_store);
While we are at it I'd also switch to device managed LED registration
API.
--
Best regards,
Jacek Anaszewski
_read(chip, LP5523_REG_STATUS, );
+ if (ret)
+ return ret;
status &= LP5523_ENG_STATUS_MASK;
if (status != LP5523_ENG_STATUS_MASK) {
Applied to fixes-for-4.21 branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
++
As pointed out by 0day-ci this has to be in leds-core.c.
I'll fix it.
Right, please also remove "classdev" from the new API name.
--
Best regards,
Jacek Anaszewski
ock
#cat
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3:1.0/0003:1C4F:0002.0001/uevent
DRIVER=hid-generic
HID_ID=0003:1C4F:0002
HID_NAME=SIGMACHIP USB Keyboard
HID_PHYS=usb-:00:14.0-3/input0
HID_UNIQ=
MODALIAS=hid:b0003g0001v1C4Fp0002
Having all the above it se
+0100)
Thanks,
Jacek Anaszewski
LEDs for 4.21-rc1
Jacek Anaszewski (2):
led: triggers: Break the for loop after default trigger is found
led: triggers: Add
On 12/20/18 9:31 PM, Jacek Anaszewski wrote:
On 12/19/18 10:50 PM, Dan Murphy wrote:
On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
Hi Dan and Pavel,
On 12/19/18 9:41 PM, Dan Murphy wrote:
Pavel
On 12/19/2018 02:10 PM, Pavel Machek wrote:
On Wed 2018-12-19 13:41:18, Dan Murphy wrote
On 12/19/18 10:50 PM, Dan Murphy wrote:
On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
Hi Dan and Pavel,
On 12/19/18 9:41 PM, Dan Murphy wrote:
Pavel
On 12/19/2018 02:10 PM, Pavel Machek wrote:
On Wed 2018-12-19 13:41:18, Dan Murphy wrote:
Pavel
Thanks for the review.
On 12/19/2018 01
ttps://lkml.org/lkml/2018/11/9/938
--
Best regards,
Jacek Anaszewski
On 12/12/18 1:16 PM, Pavel Machek wrote:
On Mon 2018-12-10 22:03:18, Jacek Anaszewski wrote:
Hi Krzysztof,
Thank you for the update.
On 12/10/18 10:29 AM, Krzysztof Kozlowski wrote:
Hi,
I rebased on top of Jacek's patches and, as I could not find them on git kernel
tree, I included them
amendments to 2/5:
- removed extra empty line
- fixed language in the commit message as proposed by Pavel
2. Add patch 3/5 for fixup of Jacek's solution.
3. Drop first two patches from the series (applied).
4. Patch 5/5: Use LED_INIT_DEFAULT_TRIGGER (suggested by Jacek Anaszewski).
5. Patch 5/5
On 12/8/18 7:44 PM, Jacek Anaszewski wrote:
Hi Krzysztof,
Thank you for the patch set.
Applied 1/4 and 2/4.
I'll hold on merging 3/4 until we sort out the issues
I have with this one. Please refer to my comment below.
On 12/7/18 1:32 PM, Krzysztof Kozlowski wrote:
Allow initialization
-by: Jacek Anaszewski
---
drivers/leds/led-triggers.c | 2 ++
include/linux/leds.h| 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 52b12e601ebe..9421222ca7a0 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led
It is of no avail to continue iterating through registered
triggers in the led_trigger_set_default() after the trigger to set
has been found. Add "break" statement to fix this omission.
Signed-off-by: Jacek Anaszewski
---
drivers/leds/led-triggers.c | 4 +++-
1 file changed, 3 insert
return 0;
}
--
Best regards,
Jacek Anaszewski
return 0;
}
--
Best regards,
Jacek Anaszewski
return ERR_PTR(ret);
}
- led_dat->cdev.dev->of_node = np;
priv->num_leds++;
}
Applied.
--
Best regards,
Jacek Anaszewski
return ERR_PTR(ret);
}
- led_dat->cdev.dev->of_node = np;
priv->num_leds++;
}
Applied.
--
Best regards,
Jacek Anaszewski
Hi Julia,
Thank you for the patch, but it doesn't apply to LED tree.
The patch causing the problem is out-of-LED-tree.
Best regards,
Jacek Anaszewski
On 12/6/18 9:28 PM, Julia Lawall wrote:
Hello,
The code seems to be wrong in several ways. If the continue is wanted,
the of_node_put
Hi Julia,
Thank you for the patch, but it doesn't apply to LED tree.
The patch causing the problem is out-of-LED-tree.
Best regards,
Jacek Anaszewski
On 12/6/18 9:28 PM, Julia Lawall wrote:
Hello,
The code seems to be wrong in several ways. If the continue is wanted,
the of_node_put
comparisons. This should not matter for any FDT based
system which this is.
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: linux-l...@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/leds/leds-88pm860x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds
comparisons. This should not matter for any FDT based
system which this is.
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: linux-l...@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/leds/leds-88pm860x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds
However, I've just tried to verify how it works, but
I can't find the way to get the of_node phandle from sysfs.
The "of_node" link in per-device dirs in /sys/devices point
to the directories containing DT properties of the node, but
I see no way to obtain the node phandle.
> Sure, it's not that efficient,
> but it does work and it's only done once. Basically, as long as the
> linkage is there, we can make it work. I think using
> 'associated-device' might work better for the current implementation
> of Linux LED support, but leds/led-names would be more inline with
> other DT bindings. The current Linux implementation shouldn't dictate
> the binding design.
[0] https://lkml.org/lkml/2018/11/13/103
--
Best regards,
Jacek Anaszewski
However, I've just tried to verify how it works, but
I can't find the way to get the of_node phandle from sysfs.
The "of_node" link in per-device dirs in /sys/devices point
to the directories containing DT properties of the node, but
I see no way to obtain the node phandle.
> Sure, it's not that efficient,
> but it does work and it's only done once. Basically, as long as the
> linkage is there, we can make it work. I think using
> 'associated-device' might work better for the current implementation
> of Linux LED support, but leds/led-names would be more inline with
> other DT bindings. The current Linux implementation shouldn't dictate
> the binding design.
[0] https://lkml.org/lkml/2018/11/13/103
--
Best regards,
Jacek Anaszewski
On 11/13/2018 09:57 PM, Jacek Anaszewski wrote:
> On 11/12/2018 07:27 PM, Rob Herring wrote:
>> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>>> Introduce dedicated properties for conveying information about
>>> LED function and color. Mark old &qu
On 11/13/2018 09:57 PM, Jacek Anaszewski wrote:
> On 11/12/2018 07:27 PM, Rob Herring wrote:
>> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>>> Introduce dedicated properties for conveying information about
>>> LED function and color. Mark old &qu
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:
>>>>>>>
>>>>>&g
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:
>>>>>>>
>>>>>&g
On 11/12/2018 07:27 PM, Rob Herring wrote:
> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>> Introduce dedicated properties for conveying information about
>> LED function and color. Mark old "label" property as deprecated.
>>
>> Signed-of
On 11/12/2018 07:27 PM, Rob Herring wrote:
> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>> Introduce dedicated properties for conveying information about
>> LED function and color. Mark old "label" property as deprecated.
>>
>> Signed-of
Uytterhoeven
Signed-off-by: Bryan Wu
> In this case I suggest "serialnumber:color:capslock" and
> similar.
>
> The important point is the string must be unique for each
> plugged device.
--
Best regards,
Jacek Anaszewski
Uytterhoeven
Signed-off-by: Bryan Wu
> In this case I suggest "serialnumber:color:capslock" and
> similar.
>
> The important point is the string must be unique for each
> plugged device.
--
Best regards,
Jacek Anaszewski
Hi Vesa,
On 11/13/2018 08:10 AM, Vesa Jääskeläinen wrote:
> Hi Jacek,
>
> On 12/11/2018 18.02, Jacek Anaszewski wrote:
>>>> Support for RGB LEDs, or other variations of LED synchronization
>>>> have been approached several times, but without satisfying result
Hi Vesa,
On 11/13/2018 08:10 AM, Vesa Jääskeläinen wrote:
> Hi Jacek,
>
> On 12/11/2018 18.02, Jacek Anaszewski wrote:
>>>> Support for RGB LEDs, or other variations of LED synchronization
>>>> have been approached several times, but without satisfying result
nk LED to its device. device = "name" would be good start...)
>>
>> Why would you need such link?
>
> Because userspace needs that information?
>
> Say you have raid array, with "error" leds for each drive (your list
> already contains "hdderr"). Now userland detects problem with hdparm
> on /dev/sdi. It would like to turn on corresponding LED.
>
> How do you propose we do that?
Similarly as in case of USB keyboard.
--
Best regards,
Jacek Anaszewski
nk LED to its device. device = "name" would be good start...)
>>
>> Why would you need such link?
>
> Because userspace needs that information?
>
> Say you have raid array, with "error" leds for each drive (your list
> already contains "hdderr"). Now userland detects problem with hdparm
> on /dev/sdi. It would like to turn on corresponding LED.
>
> How do you propose we do that?
Similarly as in case of USB keyboard.
--
Best regards,
Jacek Anaszewski
n:link,
> eth0:yellow:activity and not some kind of hack.
eth0 is not something you can be certain of at the stage of defining DT
node.
> Ideally, colors would come from fixed list, functions would come from
> fixed list, and device part would come from name used elsewhere in the
> kernel.
>
> (And yes, it probably means we should have something in device tree to
> link LED to its device. device = "name" would be good start...)
Why would you need such link?
--
Best regards,
Jacek Anaszewski
n:link,
> eth0:yellow:activity and not some kind of hack.
eth0 is not something you can be certain of at the stage of defining DT
node.
> Ideally, colors would come from fixed list, functions would come from
> fixed list, and device part would come from name used elsewhere in the
> kernel.
>
> (And yes, it probably means we should have something in device tree to
> link LED to its device. device = "name" would be good start...)
Why would you need such link?
--
Best regards,
Jacek Anaszewski
Hi Vesa,
On 11/10/2018 06:19 PM, Vesa Jääskeläinen wrote:
> Hi Jacek,
>
> On 09/11/2018 22.42, Jacek Anaszewski wrote:
>> Hi Vesa,
>>
>> On 11/09/2018 09:32 AM, Vesa Jääskeläinen wrote:
>>> On 07/11/2018 0.07, Jacek Anaszewski wrote:
>>>> Introduc
Hi Vesa,
On 11/10/2018 06:19 PM, Vesa Jääskeläinen wrote:
> Hi Jacek,
>
> On 09/11/2018 22.42, Jacek Anaszewski wrote:
>> Hi Vesa,
>>
>> On 11/09/2018 09:32 AM, Vesa Jääskeläinen wrote:
>>> On 07/11/2018 0.07, Jacek Anaszewski wrote:
>>>> Introduc
Hi Vesa,
On 11/12/2018 01:25 AM, Vesa Jääskeläinen wrote:
> Hi Jacek,
>
> On 07/11/2018 0.07, Jacek Anaszewski wrote:
>> Add common LED function definitions for use in Device Tree.
>> The function names were extracted from existing dts files
>> after eliminating od
Hi Vesa,
On 11/12/2018 01:25 AM, Vesa Jääskeläinen wrote:
> Hi Jacek,
>
> On 07/11/2018 0.07, Jacek Anaszewski wrote:
>> Add common LED function definitions for use in Device Tree.
>> The function names were extracted from existing dts files
>> after eliminating od
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/D
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/D
e it seems to overlap with "pwr" probably.
>>>> +#define LED_FUNCTION_WIFI "wifi"
>>>> +#define LED_FUNCTION_WIRELESS "wireless"
>>>> +#define LED_FUNCTION_WLAN "wlan"
>>>
>>> Same as wifi and wireless, I guess, deprecate some?
>>
>> I'd remove "wireless" and "wlan".
>
> Actually I'd keep wlan, but... :-).
It may depend of the regional preferences.
> We may want to do add some comments there, and sort it "most
> common/recommended first" or something.
>
> Best regards (and thanks for doing the work),
I'm doing it also for myself to avoid extra lines for
explaining the LED naming quirks every time a new driver
is submitted :-)
--
Best regards,
Jacek Anaszewski
e it seems to overlap with "pwr" probably.
>>>> +#define LED_FUNCTION_WIFI "wifi"
>>>> +#define LED_FUNCTION_WIRELESS "wireless"
>>>> +#define LED_FUNCTION_WLAN "wlan"
>>>
>>> Same as wifi and wireless, I guess, deprecate some?
>>
>> I'd remove "wireless" and "wlan".
>
> Actually I'd keep wlan, but... :-).
It may depend of the regional preferences.
> We may want to do add some comments there, and sort it "most
> common/recommended first" or something.
>
> Best regards (and thanks for doing the work),
I'm doing it also for myself to avoid extra lines for
explaining the LED naming quirks every time a new driver
is submitted :-)
--
Best regards,
Jacek Anaszewski
pacpi::unknown_led3
>
> I agree that we should get rid of "tpacpi:" part in some cases. But
> it does not make sense to get rid of "input16:" part -- it tells you
> if the LED is on USB or on built-in keyboard.
>
> Ideally, tpacpi::thinklight would be input5::frontlight (as it is
> frontlight for the keyboard).
>
> Yes we should simplify, but it still needs to work in all cases.
Well, label is not being removed. You still can use it an the old
fashion, even when using new led_compose_name().
Maybe removing the description of the old LED naming from
Documentation/leds/leds-class.txt was too drastic move.
I'll keep it next to the new one, and only add a note that
it is kept only for backwards compatibility.
--
Best regards,
Jacek Anaszewski
pacpi::unknown_led3
>
> I agree that we should get rid of "tpacpi:" part in some cases. But
> it does not make sense to get rid of "input16:" part -- it tells you
> if the LED is on USB or on built-in keyboard.
>
> Ideally, tpacpi::thinklight would be input5::frontlight (as it is
> frontlight for the keyboard).
>
> Yes we should simplify, but it still needs to work in all cases.
Well, label is not being removed. You still can use it an the old
fashion, even when using new led_compose_name().
Maybe removing the description of the old LED naming from
Documentation/leds/leds-class.txt was too drastic move.
I'll keep it next to the new one, and only add a note that
it is kept only for backwards compatibility.
--
Best regards,
Jacek Anaszewski
Hi Pavel.
On 11/11/2018 03:29 PM, Pavel Machek wrote:
> On Tue 2018-11-06 23:07:13, Jacek Anaszewski wrote:
>> Refer to new "function" and "color" properties and mark "label"
>> as deprecated.
>>
>> Signed-off-by: Jacek Anaszewski
&g
Hi Pavel.
On 11/11/2018 03:29 PM, Pavel Machek wrote:
> On Tue 2018-11-06 23:07:13, Jacek Anaszewski wrote:
>> Refer to new "function" and "color" properties and mark "label"
>> as deprecated.
>>
>> Signed-off-by: Jacek Anaszewski
&g
thernet-status"
>> +#define LED_FUNCTION_FAIL "fail"
>> +#define LED_FUNCTION_FAULT "fault"
>> +#define LED_FUNCTION_FLASH "flash"
>> +#define LED_FUNCTION_FRONT "front"
>> +#define LED_FUNCTION_FUNC "func"
501 - 600 of 3275 matches
Mail list logo
