On Thu, 23 Apr 2015 10:55:40 +0530
Vasant Hegde hegdevas...@linux.vnet.ibm.com wrote:
On 04/23/2015 03:15 AM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
.../...
From what I can see from the driver code the LEDs are set with:
opal_leds_set_ind(token, loc_code, led_mask
- solid
- attention indicator - solid
How does LED operation differ for fault and attention modes?
Does a LED have different intensity?
I'd rather avoid creating separate LED class devices for each mode.
For blinking we could use existing timer trigger.
--
Best Regards,
Jacek
Resending, as there were some problems with delivering this message.
Original Message
Subject: Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
Date: Thu, 16 Apr 2015 13:34:17 +0200
From: Jacek Anaszewski j.anaszew...@samsung.com
To: Vasant Hegde hegdevas
On Fri, 24 Apr 2015 14:18:30 +1000
Stewart Smith stew...@linux.vnet.ibm.com wrote:
Jacek Anaszewski j.anaszewsk...@gmail.com writes:
These device tree comes from out firmware ... which is immutable .
How the firmware is related to kernel? These bindings are for
kernel
On Fri, 24 Apr 2015 11:00:41 +0530
Hi Vasant,
Vasant Hegde hegdevas...@linux.vnet.ibm.com wrote:
On 04/23/2015 07:43 PM, Jacek Anaszewski wrote:
On Thu, 23 Apr 2015 10:55:40 +0530
Vasant Hegde hegdevas...@linux.vnet.ibm.com wrote:
Hi Jacek,
.../...
These device tree comes
On 21.04.2015 07:50, Vasant Hegde wrote:
On 04/20/2015 08:57 PM, Jacek Anaszewski wrote:
Hi Vasant,
Jacek,
Thanks for the review.
You are welcome.
Thanks for the update.
On 04/20/2015 10:01 AM, Vasant Hegde wrote:
This patch implements LED driver for PowerNV platform using
Hi Vasant,
On 20.04.2015 17:53, Vasant Hegde wrote:
On 04/20/2015 08:50 PM, Jacek Anaszewski wrote:
On 04/20/2015 02:34 PM, Vasant Hegde wrote:
On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
Hi Vasant,
I'd like to clarify some details regarding your explanation.
On 04/15/2015 12:15 PM
On 04/20/2015 02:34 PM, Vasant Hegde wrote:
On 04/20/2015 05:15 PM, Jacek Anaszewski wrote:
Hi Vasant,
I'd like to clarify some details regarding your explanation.
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
[...]
In Power Systems LEDs are overloaded (meaning same LED is used for identify
(powernv_led_driver);
+
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(PowerNV LED driver);
+MODULE_AUTHOR(Vasant Hegde hegdevas...@linux.vnet.ibm.com);
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
(opal_flash_write, OPAL_FLASH_WRITE);
OPAL_CALL(opal_flash_erase, OPAL_FLASH_ERASE);
+OPAL_CALL(opal_leds_get_ind, OPAL_LEDS_GET_INDICATOR);
+OPAL_CALL(opal_leds_set_ind, OPAL_LEDS_SET_INDICATOR);
--
Best Regards,
Jacek
);
--
To unsubscribe from this list: send the line unsubscribe linux-leds in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc
Hi Vasant,
On 04/24/2015 12:15 PM, Jacek Anaszewski wrote:
[...]
For attention and fault LEDs only brightness attribute would matter.
Sure.
DT bindings would look as follows:
opal-leds {
compatible = ibm,opal-leds;
U78C9.001.RST0027-P1-C1:fault
On 04/27/2015 11:53 AM, Benjamin Herrenschmidt wrote:
On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
I was not aware that some other entity than the driver could be
interested in the information provided by DT node. I will no longer
object, provided that we will get an ack from DT
Hi Benjamin,
Thanks for your explanation.
On 04/27/2015 12:07 AM, Benjamin Herrenschmidt wrote:
On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote:
How the firmware is related to kernel? These bindings are for kernel,
not for the firmware.
There should be no relation. DT bindings
On 04/28/2015 08:59 AM, Stewart Smith wrote:
Jacek Anaszewski j.anaszewsk...@gmail.com writes:
Is the DT node we are discussing used by some other drivers than the
LED class driver? Or is it required in this form by other components of
your platform?
OS kernels are the chief consumers, Linux
Hi Vasant,
On 04/16/2015 08:52 AM, Vasant Hegde wrote:
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
.../...
I mean, we have to retain the state of LED across system
On 04/16/2015 12:26 PM, Vasant Hegde wrote:
On 04/16/2015 02:21 PM, Jacek Anaszewski wrote:
Hi Vasant,
On 04/16/2015 08:52 AM, Vasant Hegde wrote:
On 04/15/2015 06:42 PM, Jacek Anaszewski wrote:
On 04/15/2015 12:15 PM, Vasant Hegde wrote:
On 04/15/2015 02:12 PM, Jacek Anaszewski wrote:
Hi
-leds in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
. Ben himself asked to wait for the ack in the
message [1]. We are waiting for almost two months now :)
[1] http://www.spinics.net/lists/linux-leds/msg03557.html
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
Acked-by: Jacek Anaszewski j.anaszew...@samsung.com
---
.../devicetree/bindings
Hi Vasant,
On 07/28/2015 07:40 PM, Jacek Anaszewski wrote:
Vasant,
On 28.07.2015 15:40, Vasant Hegde wrote:
On 07/27/2015 03:20 PM, Jacek Anaszewski wrote:
Hi Vasant,
On 27.07.2015 05:41, Vasant Hegde wrote:
On 07/27/2015 03:11 AM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
Two
On 28.07.2015 12:14, Benjamin Herrenschmidt wrote:
On Tue, 2015-07-28 at 08:38 +0200, Jacek Anaszewski wrote:
+/* Register the classdev */
+rc = devm_led_classdev_register(dev, powernv_led-cdev);
+if (rc) {
+dev_err(dev, %s: Classdev registration failed for %s\n
Vasant,
On 28.07.2015 15:40, Vasant Hegde wrote:
On 07/27/2015 03:20 PM, Jacek Anaszewski wrote:
Hi Vasant,
On 27.07.2015 05:41, Vasant Hegde wrote:
On 07/27/2015 03:11 AM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
Two trivial details left. Please find them below.
Thanks
);
+}
Braces are not needed here,
+
+return rc;
+}
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi Vasant,
On 27.07.2015 05:41, Vasant Hegde wrote:
On 07/27/2015 03:11 AM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
Two trivial details left. Please find them below.
Thanks for the review/Ack. I'll fix below issues and resend patchset.
I will ask Benh/Michael to take this patchset
Vasant,
On 23.07.2015 10:08, Vasant Hegde wrote:
On 07/23/2015 01:25 PM, Jacek Anaszewski wrote:
Hi Vasant,
Jacek,
.../...
+/* PowerNV LED data */
+struct powernv_led_data {
+struct led_classdevcdev;
+char*loc_code;/* LED location code */
+int
Hi Vasant,
Two trivial details left. Please find them below.
Since for two next weeks I will be unable even to compile-test
this patch set I propose to merge it via powerpc tree.
Having both mentioned issues addressed, for this patch:
Acked-by: Jacek Anaszewski j.anaszew...@samsung.com
,
+ },
+};
+
+module_platform_driver(powernv_led_driver);
+
+MODULE_LICENSE(GPL v2);
+MODULE_DESCRIPTION(PowerNV LED driver);
+MODULE_AUTHOR(Vasant Hegde hegdevas...@linux.vnet.ibm.com);
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev
to be consistent with what you declare in the beginnig
then it should be:
MODULE_LICENSE(GPL v2)
+MODULE_DESCRIPTION(PowerNV LED driver);
+MODULE_AUTHOR(Vasant Hegde hegdevas...@linux.vnet.ibm.com);
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev
);
+
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(PowerNV LED driver);
+MODULE_AUTHOR(Vasant Hegde hegdevas...@linux.vnet.ibm.com);
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
Hi Vasan,
On 07/16/2015 08:54 AM, Vasant Hegde wrote:
On 07/14/2015 02:30 PM, Jacek Anaszewski wrote:
Hi Vasant,
Jacek,
Thanks for the update. I think that we have still room
for improvements, please look at my comments below.
Thanks for the detailed review.
You're welcome
Hi Vasant,
I've revised your patch and found few more issues.
Please refer to my comments below.
On 17.07.2015 18:20, Vasant Hegde wrote:
On 07/17/2015 08:55 PM, Jacek Anaszewski wrote:
Hi Vasant,
Hi Jacek,
.../...
As per the LED class framework, the 'brightness_set' function should
On 19.07.2015 23:40, Jacek Anaszewski wrote:
[...]
+/* Platform driver probe */
+static int powernv_led_probe(struct platform_device *pdev)
+{
+int num_leds;
+struct device_node *led_node;
+struct powernv_leds_priv *priv;
+
+led_node = of_find_node_by_path(/ibm,opal/leds
Vasant,
On 21.07.2015 08:55, Vasant Hegde wrote:
On 07/21/2015 11:24 AM, Vasant Hegde wrote:
On 07/20/2015 03:10 AM, Jacek Anaszewski wrote:
Hi Vasant,
Jacek,
I've revised your patch and found few more issues.
Please refer to my comments below.
Thanks.
.../...
Please don't exceed
Hi Vasant,
On 21.07.2015 07:54, Vasant Hegde wrote:
On 07/20/2015 03:10 AM, Jacek Anaszewski wrote:
Hi Vasant,
Jacek,
I've revised your patch and found few more issues.
Please refer to my comments below.
Thanks.
.../...
Please don't exceed 75 character line length limit.
Ok. I
Since brightness setting can sleep for this driver, implement
brightness_set_blocking op, instead of brightness_set.
It makes this driver compatible with LED triggers.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Vasant Hegde <hegdevas...@linux.vnet.ibm.com>
---
Since brightness setting can sleep for this driver, implement
brightness_set_blocking op, instead of brightness_set.
It makes this driver compatible with LED triggers.
Signed-off-by: Jacek Anaszewski <j.anaszew...@samsung.com>
Cc: Vasant Hegde <hegdevas...@linux.vnet.ibm.com>
---
Hi all,
For consistency reasons this patch should be merged through LED tree,
but I need an ack from relevant maintainer. Benjamin, Michael, Paul?
Thanks,
Jacek Anaszewski
On 06/10/2016 07:59 AM, Stephan Linz wrote:
- dts: rename 'ide-disk' to 'disk-activity'
- defconfig: rename
Hi Andrew,
Thanks for the patch.
Please address the issue [1] raised by test bot and resubmit.
Thanks,
Jacek Anaszewski
[1] https://lkml.org/lkml/2016/6/13/1091
On 06/13/2016 10:02 PM, Andrew F. Davis wrote:
When CONFIG_NEW_LEDS is not set make will still descend into the leds
directory
On 06/21/2016 01:48 PM, Andrew F. Davis wrote:
On 06/21/2016 02:09 AM, Jacek Anaszewski wrote:
Hi Andrew,
This patch doesn't apply, please rebase onto recent LED tree.
On 06/21/2016 12:13 AM, Andrew F. Davis wrote:
Some systems use 'gpio_led_register_device' to make an in-memory copy
On 06/18/2016 12:46 AM, Andrew F. Davis wrote:
On 06/15/2016 01:48 AM, Jacek Anaszewski wrote:
Hi Andrew,
Thanks for the patch.
Please address the issue [1] raised by test bot and resubmit.
Thanks,
Jacek Anaszewski
[1] https://lkml.org/lkml/2016/6/13/1091
It looks like some systems use
ic inline struct platform_device *gpio_led_register_device(
+ int id, const struct gpio_led_platform_data *pdata)
+{
+ return 0;
+}
+#endif
enum cpu_led_event {
CPU_LED_IDLE_START, /* CPU enters idle */
--
Best regards,
v name\n",
> - __func__);
> + if (!powernv_led->cdev.name)
> return -ENOMEM;
> - }
>
> powernv_led->cdev.brightness_set_blocking = powernv_brightness_set;
> powernv_led->cdev.brightness_get = powernv_brightness_get;
>
Applied.
--
Best regards,
Jacek Anaszewski
wernv_led_classdev(pdev, led_node, powernv_led_common);
> + rc = powernv_led_classdev(pdev, led_node, powernv_led_common);
> +out:
> + of_node_put(led_node);
> + return rc;
> }
>
> /* Platform driver remove */
>
I've fixed those trivial problems and applied the patch
to the for-next branch of linux-leds.git.
--
Best regards,
Jacek Anaszewski
On 7/7/20 8:04 PM, Randy Dunlap wrote:
Drop the doubled word "for".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: Dan Murphy
Cc: linux-l...@vger.kernel.org
---
Documentation/leds/ledtrig-transient.rst |
45 matches
Mail list logo
