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 |
return powernv_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
gt; + 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
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
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,
Jacek Anaszewski
__
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
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 but
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'
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
Cc: Vasant Hegde
---
drivers/leds/leds-powernv.c | 16 ++--
1 file changed, 10
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
Cc: Vasant Hegde
---
drivers/leds/leds-powernv.c | 16 ++--
1 file changed, 10
ned-off-by: Anshuman Khandual
Acked-by: Stewart Smith
Tested-by: Stewart Smith
Acked-by: Jacek Anaszewski
---
.../devicetree/bindings/leds/leds-powernv.txt | 26 ++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
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
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 for the
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 fai
v, "%s: Classdev registration failed for %s\n",
+__func__, powernv_led->cdev.name);
+ }
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 pat
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
On 25.07.2015 07:21, Vasant
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
uot;PowerNV led module unregistered\n");
+ return 0;
+}
+
+/* Platform driver property match */
+static const struct of_device_id powernv_led_match[] = {
+ {
+ .compatible = "ibm,opal-v3-led",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, powernv
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
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 limi
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
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'
{
+ .compatible = "ibm,opal-v3-led",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, powernv_led_match);
+
+static struct platform_driver powernv_led_driver = {
+ .probe = powernv_led_probe,
+ .remove = powernv_led_remove,
+ .driver = {
+ .name = "powernv-led-driver",
+ .owner = THIS_MODULE,
+ .of_match_table = powernv_led_match,
+ },
+};
+
+module_platform_driver(powernv_led_driver);
+
+MODULE_LICENSE("GPL");
If you want 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 ");
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 we
v_led);
+ flush_work(&powernv_led->work_led);
+ }
You are missing mutex_destroy here.
+
+ dev_info(&pdev->dev, "PowerNV led module unregistered\n");
+ return 0;
+}
+
+/* Platform driver property match */
+static const struct of_device_
ssues. 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.ozlab
MODULE_DEVICE_TABLE(of, powernv_led_match);
+
+static struct platform_driver powernv_led_driver = {
+ .probe = powernv_led_probe,
+ .remove = powernv_led_remove,
+ .driver = {
+ .name = "powernv-led-driver",
+ .owner = THIS_MODULE,
+ .of_match_table = powernv_led_match,
+ },
+};
+
+module_platform_driver(powernv_led_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("PowerNV LED driver");
+MODULE_AUTHOR("Vasant Hegde ");
--
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-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 04/28/2015 08:59 AM, Stewart Smith wrote:
Jacek Anaszewski 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 being the overwhelmingly
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 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-P
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 Fri, 24 Apr 2015 14:18:30 +1000
Stewart Smith wrote:
> Jacek Anaszewski writes:
> >> These device tree comes from out firmware ... which is immutable .
> >
> > How the firmware is related to kernel? These bindings are for
> > kernel, not for the firmware.
>
On Fri, 24 Apr 2015 11:00:41 +0530
Hi Vasant,
Vasant Hegde wrote:
> On 04/23/2015 07:43 PM, Jacek Anaszewski wrote:
> > On Thu, 23 Apr 2015 10:55:40 +0530
> > Vasant Hegde wrote:
> >
>
> Hi Jacek,
>
> .../...
>
> >>
> >> These devi
On Thu, 23 Apr 2015 10:55:40 +0530
Vasant Hegde 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
> 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:
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
struct powernv_led_data, link);
+ list_del(&powernv_led->link);
+ kfree(powernv_led);
+ }
+
+ dev_info(&pdev->dev, "PowerNV led module unregistered\n");
+ return 0;
+}
+
+/* Platform driver property match */
+static const struct of_device_id powernv_led_match[] = {
+ {
+ .compatible = "ibm,opal-v3-led",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, powernv_led_match);
+
+static struct platform_driver powernv_led_driver = {
+ .probe = powernv_led_probe,
+ .remove = powernv_led_remove,
+ .driver = {
+ .name = "powernv-led-driver",
+ .owner = THIS_MODULE,
+ .of_match_table = powernv_led_match,
+ },
+};
+
+module_platform_driver(powernv_led_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("PowerNV LED driver");
+MODULE_AUTHOR("Vasant Hegde ");
--
Best Regards,
Jacek Anaszewski
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ITE);
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 Anaszewski
___
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 ide
- blinking
- fault - 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 tim
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
To: Vasant Hegde
CC: linuxppc-dev@lists.ozlabs.org
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
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
memory leak\n");
+
+ if (!list_empty(&powernv_led_cmd_list))
+ pr_warn("Request list not empty, memory leak\n");
+
+ if (!list_empty(&powernv_led_list))
+ pr_warn("Classdev list not empty, memory leak\n");
+
+ return 0;
+}
+
+/
45 matches
Mail list logo
