2020-06-15 20:18:08

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 00/15] Multicolor Framework v27

Hello

This is the multi color LED framework. This framework presents clustered
colored LEDs into an array and allows the user space to adjust the brightness
of the cluster using a single file write. The individual colored LEDs
intensities are controlled via a single file that is an array of LEDs

Dan

Dan Murphy (15):
dt: bindings: Add multicolor class dt bindings documention
leds: Add multicolor ID to the color ID list
leds: multicolor: Introduce a multicolor class definition
dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
leds: lp50xx: Add the LP50XX family of the RGB LED driver
dt-bindings: leds: Convert leds-lp55xx to yaml
ARM: dts: n900: Add reg property to the LP5523 channel node
ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
leds: lp55xx: Convert LED class registration to devm_*
leds: lp55xx: Add multicolor framework support to lp55xx
leds: lp5523: Update the lp5523 code to add multicolor brightness
function
leds: lp5521: Add multicolor framework multicolor brightness support
leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros
leds: lp5523: Fix various formatting issues in the code

.../ABI/testing/sysfs-class-led-multicolor | 36 +
.../bindings/leds/leds-class-multicolor.yaml | 37 +
.../devicetree/bindings/leds/leds-lp50xx.yaml | 130 +++
.../devicetree/bindings/leds/leds-lp55xx.txt | 228 -----
.../devicetree/bindings/leds/leds-lp55xx.yaml | 218 +++++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 +-
arch/arm/boot/dts/omap3-n900.dts | 29 +-
arch/arm/boot/dts/ste-href.dtsi | 22 +-
drivers/leds/Kconfig | 24 +
drivers/leds/Makefile | 2 +
drivers/leds/led-class-multicolor.c | 210 +++++
drivers/leds/led-core.c | 1 +
drivers/leds/leds-lp50xx.c | 783 ++++++++++++++++++
drivers/leds/leds-lp5521.c | 43 +-
drivers/leds/leds-lp5523.c | 62 +-
drivers/leds/leds-lp5562.c | 22 +-
drivers/leds/leds-lp55xx-common.c | 212 +++--
drivers/leds/leds-lp55xx-common.h | 16 +-
drivers/leds/leds-lp8501.c | 23 +-
include/dt-bindings/leds/common.h | 3 +-
include/linux/led-class-multicolor.h | 121 +++
include/linux/platform_data/leds-lp55xx.h | 8 +
24 files changed, 1978 insertions(+), 355 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 drivers/leds/leds-lp50xx.c
create mode 100644 include/linux/led-class-multicolor.h

--
2.26.2


2020-06-15 20:18:14

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 01/15] dt: bindings: Add multicolor class dt bindings documention

Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.

CC: Rob Herring <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
.../bindings/leds/leds-class-multicolor.yaml | 37 +++++++++++++++++++
include/dt-bindings/leds/common.h | 3 +-
2 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
new file mode 100644
index 000000000000..b55e1f1308a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for the multicolor LED class.
+
+maintainers:
+ - Dan Murphy <[email protected]>
+
+description: |
+ Bindings for multi color LEDs show how to describe current outputs of
+ either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV
+ etc.) or standalone LEDs, to achieve logically grouped multi-color LED
+ modules. This is achieved by adding multi-led nodes layer to the
+ monochrome LED bindings.
+ The nodes and properties defined in this document are unique to the multicolor
+ LED class. Common LED nodes and properties are inherited from the common.txt
+ within this documentation directory.
+
+patternProperties:
+ "^multi-led@([0-9a-f])$":
+ type: object
+ description: Represents the LEDs that are to be grouped.
+ properties:
+ color:
+ const: 8 # LED_COLOR_ID_MULTI
+ description: |
+ For multicolor LED support this property should be defined as
+ LED_COLOR_ID_MULTI which can be found in include/linux/leds/common.h.
+
+ $ref: "common.yaml#"
+
+ required:
+ - color
+...
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 0ce7dfc00dcb..a463ce6a8794 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -30,7 +30,8 @@
#define LED_COLOR_ID_VIOLET 5
#define LED_COLOR_ID_YELLOW 6
#define LED_COLOR_ID_IR 7
-#define LED_COLOR_ID_MAX 8
+#define LED_COLOR_ID_MULTI 8
+#define LED_COLOR_ID_MAX 9

/* Standard LED functions */
/* Keyboard LEDs, usually it would be input4::capslock etc. */
--
2.26.2

2020-06-15 20:18:29

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 03/15] leds: multicolor: Introduce a multicolor class definition

Introduce a multicolor class that groups colored LEDs
within a LED node.

The multi color class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.

Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
.../ABI/testing/sysfs-class-led-multicolor | 36 +++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++++++++
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile | 1 +
drivers/leds/led-class-multicolor.c | 210 ++++++++++++++++++
include/linux/led-class-multicolor.h | 121 ++++++++++
7 files changed, 467 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 include/linux/led-class-multicolor.h

diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor
new file mode 100644
index 000000000000..cd96cfb4093b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
@@ -0,0 +1,36 @@
+What: /sys/class/leds/<led>/brightness
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <[email protected]>
+Description: read/write
+ Writing to this file will update all LEDs within the group to a
+ calculated percentage of what each color LED intensity is set
+ to. The percentage is calculated for each grouped LED via the
+ equation below:
+
+ led_brightness = brightness * multi_intensity/max_brightness
+
+ For additional details please refer to
+ Documentation/leds/leds-class-multicolor.rst.
+
+ The value of the LED is from 0 to
+ /sys/class/leds/<led>/max_brightness.
+
+What: /sys/class/leds/<led>/multi_index
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <[email protected]>
+Description: read
+ The multi_index array, when read, will output the LED colors
+ as an array of strings as they are indexed in the
+ multi_intensity file.
+
+What: /sys/class/leds/<led>/multi_intensity
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <[email protected]>
+Description: read/write
+ Intensity level for the LED color within an array of integers.
+ The intensities for each color must be entered based on the
+ multi_index array. The max_intensity should not exceed
+ /sys/class/leds/<led>/max_brightness.
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index 060f4e485897..bc70c6aa7138 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -9,6 +9,7 @@ LEDs

leds-class
leds-class-flash
+ leds-class-multicolor
ledtrig-oneshot
ledtrig-transient
ledtrig-usbport
diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst
new file mode 100644
index 000000000000..2dcde711c51c
--- /dev/null
+++ b/Documentation/leds/leds-class-multicolor.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+MultiColor LED handling under Linux
+====================================
+
+Description
+===========
+The multicolor class groups monochrome LEDs and allows controlling two
+aspects of the final combined color: hue and lightness. The former is
+controlled via the multi_intensity array file and the latter is controlled
+via brightness file.
+
+Multicolor Class Control
+========================
+The multicolor class presents files that groups the colors as indexes in an
+array. These files are children under the LED parent node created by the
+led_class framework. The led_class framework is documented in led-class.rst
+within this documentation directory.
+
+Each colored LED will be indexed under the multi_* files. The order of the
+colors will be arbitrary. The multi_index file can be read to determine the
+color name to indexed value.
+
+The multi_index file is an array that contains the string list of the colors as
+they are defined in each multi_* array file.
+
+The multi_intensity is an array that can be read or written to for the
+individual color intensities. All elements within this array must be written in
+order for the color LED intensities to be updated.
+
+Directory Layout Example
+========================
+root:/sys/class/leds/multicolor:status# ls -lR
+-rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness
+-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
+-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
+-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
+
+Multicolor Class Brightness Control
+===================================
+The multicolor class framework will calculate each monochrome LEDs intensity.
+
+The brightness level for each LED is calculated based on the color LED
+intensity setting divided by the global max_brightness setting multiplied by
+the requested brightness.
+
+led_brightness = brightness * multi_intensity/max_brightness
+
+Example:
+A user first writes the multi_intensity file with the brightness levels
+for each LED that are necessary to achieve a certain color output from a
+multicolor LED group.
+
+cat /sys/class/leds/multicolor:status/multi_index
+green blue red
+
+echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity
+
+red -
+ intensity = 138
+ max_brightness = 255
+green -
+ intensity = 43
+ max_brightness = 255
+blue -
+ intensity = 226
+ max_brightness = 255
+
+The user can control the brightness of that multicolor LED group by writing the
+global 'brightness' control. Assuming a max_brightness of 255 the user
+may want to dim the LED color group to half. The user would write a value of
+128 to the global brightness file then the values written to each LED will be
+adjusted base on this value.
+
+cat /sys/class/leds/multicolor:status/max_brightness
+255
+echo 128 > /sys/class/leds/multicolor:status/brightness
+
+adjusted_red_value = 128 * 138/255 = 69
+adjusted_green_value = 128 * 43/255 = 21
+adjusted_blue_value = 128 * 226/255 = 113
+
+Reading the global brightness file will return the current brightness value of
+the color LED group.
+
+cat /sys/class/leds/multicolor:status/brightness
+128
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9cdc4cfc5d11..a55942976164 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH
for the flash related features of a LED device. It can be built
as a module.

+config LEDS_CLASS_MULTI_COLOR
+ tristate "LED MultiColor Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the multicolor LED sysfs class in /sys/class/leds.
+ It wraps LED class and adds multicolor LED specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for multicolor LEDs that are grouped together. This class is not
+ intended for single color LEDs. It can be built as a module.
+
config LEDS_BRIGHTNESS_HW_CHANGED
bool "LED Class brightness_hw_changed attribute support"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d0dff504f108..53bf92f30258 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
+obj-$(CONFIG_LEDS_CLASS_MULTI_COLOR) += led-class-multicolor.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o

# LED Platform Drivers (keep this sorted, M-| sort)
diff --git a/drivers/leds/led-class-multicolor.c b/drivers/leds/led-class-multicolor.c
new file mode 100644
index 000000000000..c108f4860fd7
--- /dev/null
+++ b/drivers/leds/led-class-multicolor.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+// LED Multi Color class interface
+// Copyright (C) 2019-20 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Dan Murphy <[email protected]>
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/led-class-multicolor.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#include "leds.h"
+
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev *led_cdev = &mcled_cdev->led_cdev;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++)
+ mcled_cdev->subled_info[i].brightness = brightness *
+ mcled_cdev->subled_info[i].intensity /
+ led_cdev->max_brightness;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(led_mc_calc_color_components);
+
+static ssize_t multi_intensity_store(struct device *dev,
+ struct device_attribute *intensity_attr,
+ const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int nrchars, offset = 0;
+ int intensity_value[LED_COLOR_ID_MAX];
+ int i;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ ret = sscanf(buf + offset, "%i%n",
+ &intensity_value[i], &nrchars);
+ if (ret != 1) {
+ dev_dbg(led_cdev->dev,
+ "Incorrect number of LEDs expected %i values intensity was not applied\n",
+ mcled_cdev->num_colors);
+ ret = -EINVAL;
+ goto err_out;
+ }
+ offset += nrchars;
+ }
+
+ /* account for the space at the end of the buffer */
+ offset++;
+ if (offset < size) {
+ dev_dbg(led_cdev->dev,
+ "Incorrect number of LEDs expected %i values intensity was not applied\n",
+ mcled_cdev->num_colors);
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ for (i = 0; i < mcled_cdev->num_colors; i++)
+ mcled_cdev->subled_info[i].intensity = intensity_value[i];
+
+ led_set_brightness(led_cdev, led_cdev->brightness);
+ ret = size;
+err_out:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t multi_intensity_show(struct device *dev,
+ struct device_attribute *intensity_attr,
+ char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int len = 0;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ len += sprintf(buf + len, "%d",
+ mcled_cdev->subled_info[i].intensity);
+ if (i < mcled_cdev->num_colors)
+ len += sprintf(buf + len, " ");
+ }
+
+ len += sprintf(buf + len, "\n");
+ return len;
+}
+static DEVICE_ATTR_RW(multi_intensity);
+
+static ssize_t multi_index_show(struct device *dev,
+ struct device_attribute *multi_index_attr,
+ char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int len = 0;
+ int index;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ index = mcled_cdev->subled_info[i].color_index;
+ len += sprintf(buf + len, "%s", led_colors[index]);
+ if (i < mcled_cdev->num_colors)
+ len += sprintf(buf + len, " ");
+ }
+
+ len += sprintf(buf + len, "\n");
+ return len;
+}
+static DEVICE_ATTR_RO(multi_index);
+
+static struct attribute *led_multicolor_attrs[] = {
+ &dev_attr_multi_intensity.attr,
+ &dev_attr_multi_index.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(led_multicolor);
+
+int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ struct led_classdev *led_cdev;
+
+ if (!mcled_cdev)
+ return -EINVAL;
+
+ if (!mcled_cdev->num_colors)
+ return -EINVAL;
+
+ if (mcled_cdev->num_colors > LED_COLOR_ID_MAX)
+ return -EINVAL;
+
+ led_cdev = &mcled_cdev->led_cdev;
+ mcled_cdev->led_cdev.groups = led_multicolor_groups;
+
+ return led_classdev_register_ext(parent, led_cdev, init_data);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_register_ext);
+
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev)
+{
+ if (!mcled_cdev)
+ return;
+
+ led_classdev_unregister(&mcled_cdev->led_cdev);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_unregister);
+
+static void devm_led_classdev_multicolor_release(struct device *dev, void *res)
+{
+ led_classdev_multicolor_unregister(*(struct led_classdev_mc **)res);
+}
+
+int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ struct led_classdev_mc **dr;
+ int ret;
+
+ dr = devres_alloc(devm_led_classdev_multicolor_release,
+ sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ ret = led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ init_data);
+ if (ret) {
+ devres_free(dr);
+ return ret;
+ }
+
+ *dr = mcled_cdev;
+ devres_add(parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_multicolor_register_ext);
+
+static int devm_led_classdev_multicolor_match(struct device *dev,
+ void *res, void *data)
+{
+ struct led_classdev_mc **p = res;
+
+ if (WARN_ON(!p || !*p))
+ return 0;
+
+ return *p == data;
+}
+
+void devm_led_classdev_multicolor_unregister(struct device *dev,
+ struct led_classdev_mc *mcled_cdev)
+{
+ WARN_ON(devres_release(dev,
+ devm_led_classdev_multicolor_release,
+ devm_led_classdev_multicolor_match, mcled_cdev));
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_multicolor_unregister);
+
+MODULE_AUTHOR("Dan Murphy <[email protected]>");
+MODULE_DESCRIPTION("Multi Color LED class interface");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/led-class-multicolor.h b/include/linux/led-class-multicolor.h
new file mode 100644
index 000000000000..50bd986497f0
--- /dev/null
+++ b/include/linux/led-class-multicolor.h
@@ -0,0 +1,121 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* LED Multicolor class interface
+ * Copyright (C) 2019-20 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#ifndef _LINUX_MULTICOLOR_LEDS_H_INCLUDED
+#define _LINUX_MULTICOLOR_LEDS_H_INCLUDED
+
+#include <linux/leds.h>
+#include <dt-bindings/leds/common.h>
+
+struct mc_subled {
+ int color_index;
+ int brightness;
+ int intensity;
+ int channel;
+};
+
+struct led_classdev_mc {
+ /* led class device */
+ struct led_classdev led_cdev;
+ int num_colors;
+
+ struct mc_subled *subled_info;
+};
+
+static inline struct led_classdev_mc *lcdev_to_mccdev(
+ struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct led_classdev_mc, led_cdev);
+}
+
+#if IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR)
+/**
+ * led_classdev_multicolor_register_ext - register a new object of led_classdev
+ * class with support for multicolor LEDs
+ * @parent: the multicolor LED to register
+ * @mcled_cdev: the led_classdev_mc structure for this device
+ * @init_data: the LED class Multi color device initialization data
+ *
+ * Returns: 0 on success or negative error value on failure
+ */
+int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data);
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+}
+
+/**
+ * led_classdev_multicolor_unregister - unregisters an object of led_classdev
+ * class with support for multicolor LEDs
+ * @mcled_cdev: the multicolor LED to unregister
+ *
+ * Unregister a previously registered via led_classdev_multicolor_register
+ * object
+ */
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev);
+
+/* Calculate brightness for the monochrome LED cluster */
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness);
+
+int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data);
+
+static inline int devm_led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ NULL);
+}
+
+void devm_led_classdev_multicolor_unregister(struct device *parent,
+ struct led_classdev_mc *mcled_cdev);
+#else
+
+static inline int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ return -EINVAL;
+}
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+}
+
+static inline void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev) {};
+static inline int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness)
+{
+ return -EINVAL;
+}
+
+static inline int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ return -EINVAL;
+}
+
+static inline int devm_led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ NULL);
+}
+
+static inline void devm_led_classdev_multicolor_unregister(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR) */
+#endif /* _LINUX_MULTICOLOR_LEDS_H_INCLUDED */
--
2.26.2

2020-06-15 20:18:52

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 05/15] leds: lp50xx: Add the LP50XX family of the RGB LED driver

Introduce the LP5036/30/24/18/12/9 RGB LED driver.
The difference in these parts are the number of
LED outputs where the:

LP5036 can control 36 LEDs
LP5030 can control 30 LEDs
LP5024 can control 24 LEDs
LP5018 can control 18 LEDs
LP5012 can control 12 LEDs
LP5009 can control 9 LEDs

The device has the ability to group LED output into control banks
so that multiple LED banks can be controlled with the same mixing and
brightness. Inversely the LEDs can also be controlled independently.

Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp50xx.c | 783 +++++++++++++++++++++++++++++++++++++
3 files changed, 795 insertions(+)
create mode 100644 drivers/leds/leds-lp50xx.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a55942976164..d3a792cac814 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -374,6 +374,17 @@ config LEDS_LP3952
To compile this driver as a module, choose M here: the
module will be called leds-lp3952.

+config LEDS_LP50XX
+ tristate "LED Support for TI LP5036/30/24/18/12/9 LED driver chip"
+ depends on LEDS_CLASS && REGMAP_I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
+ help
+ If you say yes here you get support for the Texas Instruments
+ LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-lp50xx.
+
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 53bf92f30258..5ac6ed3ed075 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o
+obj-$(CONFIG_LEDS_LP50XX) += leds-lp50xx.o
obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o
obj-$(CONFIG_LEDS_LP5562) += leds-lp5562.o
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
new file mode 100644
index 000000000000..407c2f42bac2
--- /dev/null
+++ b/drivers/leds/leds-lp50xx.c
@@ -0,0 +1,783 @@
+// SPDX-License-Identifier: GPL-2.0
+// TI LP50XX LED chip family driver
+// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+#include <linux/led-class-multicolor.h>
+
+#include "leds.h"
+
+#define LP50XX_DEV_CFG0 0x00
+#define LP50XX_DEV_CFG1 0x01
+#define LP50XX_LED_CFG0 0x02
+
+/* LP5009 and LP5012 registers */
+#define LP5012_BNK_BRT 0x03
+#define LP5012_BNKA_CLR 0x04
+#define LP5012_BNKB_CLR 0x05
+#define LP5012_BNKC_CLR 0x06
+#define LP5012_LED0_BRT 0x07
+#define LP5012_LED1_BRT 0x08
+#define LP5012_LED2_BRT 0x09
+#define LP5012_LED3_BRT 0x0a
+#define LP5012_OUT0_CLR 0x0b
+#define LP5012_OUT1_CLR 0x0c
+#define LP5012_OUT2_CLR 0x0d
+#define LP5012_OUT3_CLR 0x0e
+#define LP5012_OUT4_CLR 0x0f
+#define LP5012_OUT5_CLR 0x10
+#define LP5012_OUT6_CLR 0x11
+#define LP5012_OUT7_CLR 0x12
+#define LP5012_OUT8_CLR 0x13
+#define LP5012_OUT9_CLR 0x14
+#define LP5012_OUT10_CLR 0x15
+#define LP5012_OUT11_CLR 0x16
+#define LP5012_RESET 0x17
+
+/* LP5018 and LP5024 registers */
+#define LP5024_BNK_BRT 0x03
+#define LP5024_BNKA_CLR 0x04
+#define LP5024_BNKB_CLR 0x05
+#define LP5024_BNKC_CLR 0x06
+#define LP5024_LED0_BRT 0x07
+#define LP5024_LED1_BRT 0x08
+#define LP5024_LED2_BRT 0x09
+#define LP5024_LED3_BRT 0x0a
+#define LP5024_LED4_BRT 0x0b
+#define LP5024_LED5_BRT 0x0c
+#define LP5024_LED6_BRT 0x0d
+#define LP5024_LED7_BRT 0x0e
+
+#define LP5024_OUT0_CLR 0x0f
+#define LP5024_OUT1_CLR 0x10
+#define LP5024_OUT2_CLR 0x11
+#define LP5024_OUT3_CLR 0x12
+#define LP5024_OUT4_CLR 0x13
+#define LP5024_OUT5_CLR 0x14
+#define LP5024_OUT6_CLR 0x15
+#define LP5024_OUT7_CLR 0x16
+#define LP5024_OUT8_CLR 0x17
+#define LP5024_OUT9_CLR 0x18
+#define LP5024_OUT10_CLR 0x19
+#define LP5024_OUT11_CLR 0x1a
+#define LP5024_OUT12_CLR 0x1b
+#define LP5024_OUT13_CLR 0x1c
+#define LP5024_OUT14_CLR 0x1d
+#define LP5024_OUT15_CLR 0x1e
+#define LP5024_OUT16_CLR 0x1f
+#define LP5024_OUT17_CLR 0x20
+#define LP5024_OUT18_CLR 0x21
+#define LP5024_OUT19_CLR 0x22
+#define LP5024_OUT20_CLR 0x23
+#define LP5024_OUT21_CLR 0x24
+#define LP5024_OUT22_CLR 0x25
+#define LP5024_OUT23_CLR 0x26
+#define LP5024_RESET 0x27
+
+/* LP5030 and LP5036 registers */
+#define LP5036_LED_CFG1 0x03
+#define LP5036_BNK_BRT 0x04
+#define LP5036_BNKA_CLR 0x05
+#define LP5036_BNKB_CLR 0x06
+#define LP5036_BNKC_CLR 0x07
+#define LP5036_LED0_BRT 0x08
+#define LP5036_LED1_BRT 0x09
+#define LP5036_LED2_BRT 0x0a
+#define LP5036_LED3_BRT 0x0b
+#define LP5036_LED4_BRT 0x0c
+#define LP5036_LED5_BRT 0x0d
+#define LP5036_LED6_BRT 0x0e
+#define LP5036_LED7_BRT 0x0f
+#define LP5036_LED8_BRT 0x10
+#define LP5036_LED9_BRT 0x11
+#define LP5036_LED10_BRT 0x12
+#define LP5036_LED11_BRT 0x13
+
+#define LP5036_OUT0_CLR 0x14
+#define LP5036_OUT1_CLR 0x15
+#define LP5036_OUT2_CLR 0x16
+#define LP5036_OUT3_CLR 0x17
+#define LP5036_OUT4_CLR 0x18
+#define LP5036_OUT5_CLR 0x19
+#define LP5036_OUT6_CLR 0x1a
+#define LP5036_OUT7_CLR 0x1b
+#define LP5036_OUT8_CLR 0x1c
+#define LP5036_OUT9_CLR 0x1d
+#define LP5036_OUT10_CLR 0x1e
+#define LP5036_OUT11_CLR 0x1f
+#define LP5036_OUT12_CLR 0x20
+#define LP5036_OUT13_CLR 0x21
+#define LP5036_OUT14_CLR 0x22
+#define LP5036_OUT15_CLR 0x23
+#define LP5036_OUT16_CLR 0x24
+#define LP5036_OUT17_CLR 0x25
+#define LP5036_OUT18_CLR 0x26
+#define LP5036_OUT19_CLR 0x27
+#define LP5036_OUT20_CLR 0x28
+#define LP5036_OUT21_CLR 0x29
+#define LP5036_OUT22_CLR 0x2a
+#define LP5036_OUT23_CLR 0x2b
+#define LP5036_OUT24_CLR 0x2c
+#define LP5036_OUT25_CLR 0x2d
+#define LP5036_OUT26_CLR 0x2e
+#define LP5036_OUT27_CLR 0x2f
+#define LP5036_OUT28_CLR 0x30
+#define LP5036_OUT29_CLR 0x31
+#define LP5036_OUT30_CLR 0x32
+#define LP5036_OUT31_CLR 0x33
+#define LP5036_OUT32_CLR 0x34
+#define LP5036_OUT33_CLR 0x35
+#define LP5036_OUT34_CLR 0x36
+#define LP5036_OUT35_CLR 0x37
+#define LP5036_RESET 0x38
+
+#define LP50XX_SW_RESET 0xff
+#define LP50XX_CHIP_EN BIT(6)
+
+/* There are 3 LED outputs per bank */
+#define LP50XX_LEDS_PER_MODULE 3
+
+#define LP5009_MAX_LED_MODULES 2
+#define LP5012_MAX_LED_MODULES 4
+#define LP5018_MAX_LED_MODULES 6
+#define LP5024_MAX_LED_MODULES 8
+#define LP5030_MAX_LED_MODULES 10
+#define LP5036_MAX_LED_MODULES 12
+
+#define LP5009_MAX_LEDS (LP5009_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5012_MAX_LEDS (LP5012_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5018_MAX_LEDS (LP5018_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5024_MAX_LEDS (LP5024_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5030_MAX_LEDS (LP5030_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5036_MAX_LEDS (LP5036_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+
+static const struct reg_default lp5012_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5012_BNK_BRT, 0xff},
+ {LP5012_BNKA_CLR, 0x0f},
+ {LP5012_BNKB_CLR, 0x0f},
+ {LP5012_BNKC_CLR, 0x0f},
+ {LP5012_LED0_BRT, 0x0f},
+ {LP5012_LED1_BRT, 0xff},
+ {LP5012_LED2_BRT, 0xff},
+ {LP5012_LED3_BRT, 0xff},
+ {LP5012_OUT0_CLR, 0x0f},
+ {LP5012_OUT1_CLR, 0x00},
+ {LP5012_OUT2_CLR, 0x00},
+ {LP5012_OUT3_CLR, 0x00},
+ {LP5012_OUT4_CLR, 0x00},
+ {LP5012_OUT5_CLR, 0x00},
+ {LP5012_OUT6_CLR, 0x00},
+ {LP5012_OUT7_CLR, 0x00},
+ {LP5012_OUT8_CLR, 0x00},
+ {LP5012_OUT9_CLR, 0x00},
+ {LP5012_OUT10_CLR, 0x00},
+ {LP5012_OUT11_CLR, 0x00},
+ {LP5012_RESET, 0x00}
+};
+
+static const struct reg_default lp5024_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5024_BNK_BRT, 0xff},
+ {LP5024_BNKA_CLR, 0x0f},
+ {LP5024_BNKB_CLR, 0x0f},
+ {LP5024_BNKC_CLR, 0x0f},
+ {LP5024_LED0_BRT, 0x0f},
+ {LP5024_LED1_BRT, 0xff},
+ {LP5024_LED2_BRT, 0xff},
+ {LP5024_LED3_BRT, 0xff},
+ {LP5024_LED4_BRT, 0xff},
+ {LP5024_LED5_BRT, 0xff},
+ {LP5024_LED6_BRT, 0xff},
+ {LP5024_LED7_BRT, 0xff},
+ {LP5024_OUT0_CLR, 0x0f},
+ {LP5024_OUT1_CLR, 0x00},
+ {LP5024_OUT2_CLR, 0x00},
+ {LP5024_OUT3_CLR, 0x00},
+ {LP5024_OUT4_CLR, 0x00},
+ {LP5024_OUT5_CLR, 0x00},
+ {LP5024_OUT6_CLR, 0x00},
+ {LP5024_OUT7_CLR, 0x00},
+ {LP5024_OUT8_CLR, 0x00},
+ {LP5024_OUT9_CLR, 0x00},
+ {LP5024_OUT10_CLR, 0x00},
+ {LP5024_OUT11_CLR, 0x00},
+ {LP5024_OUT12_CLR, 0x00},
+ {LP5024_OUT13_CLR, 0x00},
+ {LP5024_OUT14_CLR, 0x00},
+ {LP5024_OUT15_CLR, 0x00},
+ {LP5024_OUT16_CLR, 0x00},
+ {LP5024_OUT17_CLR, 0x00},
+ {LP5024_OUT18_CLR, 0x00},
+ {LP5024_OUT19_CLR, 0x00},
+ {LP5024_OUT20_CLR, 0x00},
+ {LP5024_OUT21_CLR, 0x00},
+ {LP5024_OUT22_CLR, 0x00},
+ {LP5024_OUT23_CLR, 0x00},
+ {LP5024_RESET, 0x00}
+};
+
+static const struct reg_default lp5036_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5036_LED_CFG1, 0x0},
+ {LP5036_BNK_BRT, 0xff},
+ {LP5036_BNKA_CLR, 0x0f},
+ {LP5036_BNKB_CLR, 0x0f},
+ {LP5036_BNKC_CLR, 0x0f},
+ {LP5036_LED0_BRT, 0x0f},
+ {LP5036_LED1_BRT, 0xff},
+ {LP5036_LED2_BRT, 0xff},
+ {LP5036_LED3_BRT, 0xff},
+ {LP5036_LED4_BRT, 0xff},
+ {LP5036_LED5_BRT, 0xff},
+ {LP5036_LED6_BRT, 0xff},
+ {LP5036_LED7_BRT, 0xff},
+ {LP5036_OUT0_CLR, 0x0f},
+ {LP5036_OUT1_CLR, 0x00},
+ {LP5036_OUT2_CLR, 0x00},
+ {LP5036_OUT3_CLR, 0x00},
+ {LP5036_OUT4_CLR, 0x00},
+ {LP5036_OUT5_CLR, 0x00},
+ {LP5036_OUT6_CLR, 0x00},
+ {LP5036_OUT7_CLR, 0x00},
+ {LP5036_OUT8_CLR, 0x00},
+ {LP5036_OUT9_CLR, 0x00},
+ {LP5036_OUT10_CLR, 0x00},
+ {LP5036_OUT11_CLR, 0x00},
+ {LP5036_OUT12_CLR, 0x00},
+ {LP5036_OUT13_CLR, 0x00},
+ {LP5036_OUT14_CLR, 0x00},
+ {LP5036_OUT15_CLR, 0x00},
+ {LP5036_OUT16_CLR, 0x00},
+ {LP5036_OUT17_CLR, 0x00},
+ {LP5036_OUT18_CLR, 0x00},
+ {LP5036_OUT19_CLR, 0x00},
+ {LP5036_OUT20_CLR, 0x00},
+ {LP5036_OUT21_CLR, 0x00},
+ {LP5036_OUT22_CLR, 0x00},
+ {LP5036_OUT23_CLR, 0x00},
+ {LP5036_OUT24_CLR, 0x00},
+ {LP5036_OUT25_CLR, 0x00},
+ {LP5036_OUT26_CLR, 0x00},
+ {LP5036_OUT27_CLR, 0x00},
+ {LP5036_OUT28_CLR, 0x00},
+ {LP5036_OUT29_CLR, 0x00},
+ {LP5036_OUT30_CLR, 0x00},
+ {LP5036_OUT31_CLR, 0x00},
+ {LP5036_OUT32_CLR, 0x00},
+ {LP5036_OUT33_CLR, 0x00},
+ {LP5036_OUT34_CLR, 0x00},
+ {LP5036_OUT35_CLR, 0x00},
+ {LP5036_RESET, 0x00}
+};
+
+static const struct regmap_config lp5012_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5012_RESET,
+ .reg_defaults = lp5012_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5012_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct regmap_config lp5024_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5024_RESET,
+ .reg_defaults = lp5024_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5024_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct regmap_config lp5036_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5036_RESET,
+ .reg_defaults = lp5036_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5036_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+enum lp50xx_model {
+ LP5009,
+ LP5012,
+ LP5018,
+ LP5024,
+ LP5030,
+ LP5036,
+};
+
+/*
+ * struct lp50xx_chip_info -
+ * @num_leds: number of LED outputs available on the device
+ * @led_brightness0_reg: first brightness register of the device
+ * @mix_out0_reg: first color mix register of the device
+ * @bank_brt_reg: bank brightness register
+ * @bank_mix_reg: color mix register
+ * @reset_reg: device reset register
+ */
+struct lp50xx_chip_info {
+ const struct regmap_config *lp50xx_regmap_config;
+ int model_id;
+ u8 max_modules;
+ u8 num_leds;
+ u8 led_brightness0_reg;
+ u8 mix_out0_reg;
+ u8 bank_brt_reg;
+ u8 bank_mix_reg;
+ u8 reset_reg;
+};
+
+static const struct lp50xx_chip_info lp50xx_chip_info_tbl[] = {
+ [LP5009] = {
+ .model_id = LP5009,
+ .max_modules = LP5009_MAX_LED_MODULES,
+ .num_leds = LP5009_MAX_LEDS,
+ .led_brightness0_reg = LP5012_LED0_BRT,
+ .mix_out0_reg = LP5012_OUT0_CLR,
+ .bank_brt_reg = LP5012_BNK_BRT,
+ .bank_mix_reg = LP5012_BNKA_CLR,
+ .reset_reg = LP5012_RESET,
+ .lp50xx_regmap_config = &lp5012_regmap_config,
+ },
+ [LP5012] = {
+ .model_id = LP5012,
+ .max_modules = LP5012_MAX_LED_MODULES,
+ .num_leds = LP5012_MAX_LEDS,
+ .led_brightness0_reg = LP5012_LED0_BRT,
+ .mix_out0_reg = LP5012_OUT0_CLR,
+ .bank_brt_reg = LP5012_BNK_BRT,
+ .bank_mix_reg = LP5012_BNKA_CLR,
+ .reset_reg = LP5012_RESET,
+ .lp50xx_regmap_config = &lp5012_regmap_config,
+ },
+ [LP5018] = {
+ .model_id = LP5018,
+ .max_modules = LP5018_MAX_LED_MODULES,
+ .num_leds = LP5018_MAX_LEDS,
+ .led_brightness0_reg = LP5024_LED0_BRT,
+ .mix_out0_reg = LP5024_OUT0_CLR,
+ .bank_brt_reg = LP5024_BNK_BRT,
+ .bank_mix_reg = LP5024_BNKA_CLR,
+ .reset_reg = LP5024_RESET,
+ .lp50xx_regmap_config = &lp5024_regmap_config,
+ },
+ [LP5024] = {
+ .model_id = LP5024,
+ .max_modules = LP5024_MAX_LED_MODULES,
+ .num_leds = LP5024_MAX_LEDS,
+ .led_brightness0_reg = LP5024_LED0_BRT,
+ .mix_out0_reg = LP5024_OUT0_CLR,
+ .bank_brt_reg = LP5024_BNK_BRT,
+ .bank_mix_reg = LP5024_BNKA_CLR,
+ .reset_reg = LP5024_RESET,
+ .lp50xx_regmap_config = &lp5024_regmap_config,
+ },
+ [LP5030] = {
+ .model_id = LP5030,
+ .max_modules = LP5030_MAX_LED_MODULES,
+ .num_leds = LP5030_MAX_LEDS,
+ .led_brightness0_reg = LP5036_LED0_BRT,
+ .mix_out0_reg = LP5036_OUT0_CLR,
+ .bank_brt_reg = LP5036_BNK_BRT,
+ .bank_mix_reg = LP5036_BNKA_CLR,
+ .reset_reg = LP5036_RESET,
+ .lp50xx_regmap_config = &lp5036_regmap_config,
+ },
+ [LP5036] = {
+ .model_id = LP5036,
+ .max_modules = LP5036_MAX_LED_MODULES,
+ .num_leds = LP5036_MAX_LEDS,
+ .led_brightness0_reg = LP5036_LED0_BRT,
+ .mix_out0_reg = LP5036_OUT0_CLR,
+ .bank_brt_reg = LP5036_BNK_BRT,
+ .bank_mix_reg = LP5036_BNKA_CLR,
+ .reset_reg = LP5036_RESET,
+ .lp50xx_regmap_config = &lp5036_regmap_config,
+ },
+};
+
+struct lp50xx_led {
+ struct led_classdev led_dev;
+ struct led_classdev_mc mc_cdev;
+ struct lp50xx *priv;
+ unsigned long bank_modules;
+ int led_intensity[LP50XX_LEDS_PER_MODULE];
+ u8 ctrl_bank_enabled;
+ int led_number;
+};
+
+/**
+ * struct lp50xx -
+ * @enable_gpio: hardware enable gpio
+ * @regulator: LED supply regulator pointer
+ * @client: pointer to the I2C client
+ * @regmap: device register map
+ * @dev: pointer to the devices device struct
+ * @lock: lock for reading/writing the device
+ * @chip_info: chip specific information (ie num_leds)
+ * @num_of_banked_leds: holds the number of banked LEDs
+ * @leds: array of LED strings
+ */
+struct lp50xx {
+ struct gpio_desc *enable_gpio;
+ struct regulator *regulator;
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutex lock;
+ const struct lp50xx_chip_info *chip_info;
+ int num_of_banked_leds;
+
+ /* This needs to be at the end of the struct */
+ struct lp50xx_led leds[];
+};
+
+static struct lp50xx_led *mcled_cdev_to_led(struct led_classdev_mc *mc_cdev)
+{
+ return container_of(mc_cdev, struct lp50xx_led, mc_cdev);
+}
+
+static int lp50xx_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
+ struct lp50xx_led *led = mcled_cdev_to_led(mc_dev);
+ const struct lp50xx_chip_info *led_chip = led->priv->chip_info;
+ u8 led_offset, reg_val;
+ int ret = 0;
+ int i;
+
+ mutex_lock(&led->priv->lock);
+ if (led->ctrl_bank_enabled)
+ reg_val = led_chip->bank_brt_reg;
+ else
+ reg_val = led_chip->led_brightness0_reg +
+ led->led_number;
+
+ ret = regmap_write(led->priv->regmap, reg_val, brightness);
+ if (ret) {
+ dev_err(&led->priv->client->dev,
+ "Cannot write brightness value %d\n", ret);
+ goto out;
+ }
+
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ if (led->ctrl_bank_enabled) {
+ reg_val = led_chip->bank_mix_reg + i;
+ } else {
+ led_offset = (led->led_number * 3) + i;
+ reg_val = led_chip->mix_out0_reg + led_offset;
+ }
+
+ ret = regmap_write(led->priv->regmap, reg_val,
+ mc_dev->subled_info[i].intensity);
+ if (ret) {
+ dev_err(&led->priv->client->dev,
+ "Cannot write intensity value %d\n", ret);
+ goto out;
+ }
+ }
+out:
+ mutex_unlock(&led->priv->lock);
+ return ret;
+}
+
+static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[])
+{
+ u8 led_config_lo, led_config_hi;
+ u32 bank_enable_mask = 0;
+ int ret;
+ int i;
+
+ for (i = 0; i < priv->chip_info->max_modules; i++) {
+ if (led_banks[i])
+ bank_enable_mask |= (1 << led_banks[i]);
+ }
+
+ led_config_lo = (u8)(bank_enable_mask & 0xff);
+ led_config_hi = (u8)(bank_enable_mask >> 8) & 0xff;
+
+ ret = regmap_write(priv->regmap, LP50XX_LED_CFG0, led_config_lo);
+ if (ret)
+ return ret;
+
+ if (priv->chip_info->model_id >= LP5030)
+ ret = regmap_write(priv->regmap, LP5036_LED_CFG1,
+ led_config_hi);
+
+ return ret;
+}
+
+static int lp50xx_reset(struct lp50xx *priv)
+{
+ if (priv->enable_gpio)
+ return gpiod_direction_output(priv->enable_gpio, 1);
+ else
+ return regmap_write(priv->regmap, priv->chip_info->reset_reg,
+ LP50XX_SW_RESET);
+}
+
+static int lp50xx_enable_disable(struct lp50xx *priv, u8 enable_disable)
+{
+ return regmap_write(priv->regmap, LP50XX_DEV_CFG0, enable_disable);
+}
+
+static int lp50xx_probe_dt(struct lp50xx *priv)
+{
+ u32 led_banks[LP5036_MAX_LED_MODULES] = {0};
+ struct fwnode_handle *child = NULL;
+ struct fwnode_handle *led_node = NULL;
+ struct led_init_data init_data = {};
+ struct led_classdev *led_cdev;
+ struct mc_subled *mc_led_info;
+ struct lp50xx_led *led;
+ int num_colors;
+ u32 color_id;
+ int led_number;
+ size_t i = 0;
+ int ret = -EINVAL;
+
+ priv->enable_gpio = devm_gpiod_get_optional(priv->dev,
+ "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(priv->enable_gpio)) {
+ ret = PTR_ERR(priv->enable_gpio);
+ dev_err(&priv->client->dev, "Failed to get enable gpio: %d\n",
+ ret);
+ return ret;
+ }
+
+ priv->regulator = devm_regulator_get(priv->dev, "vled");
+ if (IS_ERR(priv->regulator))
+ priv->regulator = NULL;
+
+ device_for_each_child_node(priv->dev, child) {
+ led = &priv->leds[i];
+ ret = fwnode_property_count_u32(child, "reg");
+ if (ret < 0) {
+ dev_err(&priv->client->dev,
+ "reg property is invalid\n");
+ return -EINVAL;
+ }
+ if (ret > 1) {
+ priv->num_of_banked_leds = ret;
+ if (priv->num_of_banked_leds >
+ priv->chip_info->max_modules) {
+ dev_err(&priv->client->dev,
+ "reg property is invalid\n");
+ ret = -EINVAL;
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ ret = fwnode_property_read_u32_array(child,
+ "reg",
+ led_banks,
+ ret);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "reg property is missing\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ ret = lp50xx_set_banks(priv, led_banks);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "Cannot setup banked LEDs\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+ led->ctrl_bank_enabled = 1;
+
+ } else {
+ ret = fwnode_property_read_u32(child, "reg",
+ &led_number);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "led reg property missing\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ if (led_number > priv->chip_info->num_leds) {
+ dev_err(&priv->client->dev,
+ "led-sources property is invalid\n");
+ ret = -EINVAL;
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ led->led_number = led_number;
+ }
+
+ init_data.fwnode = child;
+ fwnode_property_read_string(child, "linux,default-trigger",
+ &led->led_dev.default_trigger);
+ num_colors = 0;
+
+ /* There are only 3 LEDs per module otherwise they should be
+ * banked which also is presented as 3 LEDs
+ */
+ mc_led_info = devm_kcalloc(priv->dev, LP50XX_LEDS_PER_MODULE,
+ sizeof(*mc_led_info), GFP_KERNEL);
+ if (!mc_led_info)
+ return -ENOMEM;
+
+ fwnode_for_each_child_node(child, led_node) {
+ ret = fwnode_property_read_u32(led_node, "color",
+ &color_id);
+ if (ret)
+ dev_err(priv->dev, "Cannot read color\n");
+
+ mc_led_info[num_colors].color_index = color_id;
+ num_colors++;
+ }
+
+ led->priv = priv;
+ led->mc_cdev.num_colors = num_colors;
+ led->mc_cdev.subled_info = mc_led_info;
+ led_cdev = &led->mc_cdev.led_cdev;
+ led_cdev->brightness_set_blocking = lp50xx_brightness_set;
+ ret = devm_led_classdev_multicolor_register_ext(&priv->client->dev,
+ &led->mc_cdev,
+ &init_data);
+ if (ret) {
+ dev_err(&priv->client->dev, "led register err: %d\n",
+ ret);
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+ i++;
+ }
+
+child_out:
+ return ret;
+}
+
+static int lp50xx_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct lp50xx *led;
+ int count;
+ int ret;
+
+ count = device_get_child_node_count(&client->dev);
+ if (!count) {
+ dev_err(&client->dev, "LEDs are not defined in device tree!");
+ return -ENODEV;
+ }
+
+ led = devm_kzalloc(&client->dev, struct_size(led, leds, count),
+ GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ mutex_init(&led->lock);
+ led->client = client;
+ led->dev = &client->dev;
+ led->chip_info = &lp50xx_chip_info_tbl[id->driver_data];
+ i2c_set_clientdata(client, led);
+ led->regmap = devm_regmap_init_i2c(client,
+ led->chip_info->lp50xx_regmap_config);
+ if (IS_ERR(led->regmap)) {
+ ret = PTR_ERR(led->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = lp50xx_reset(led);
+ if (ret)
+ return ret;
+
+ ret = lp50xx_probe_dt(led);
+ if (ret)
+ return ret;
+
+ return lp50xx_enable_disable(led, LP50XX_CHIP_EN);
+}
+
+static int lp50xx_remove(struct i2c_client *client)
+{
+ struct lp50xx *led = i2c_get_clientdata(client);
+ int ret;
+
+ ret = lp50xx_enable_disable(led, LP50XX_CHIP_EN);
+ if (ret) {
+ dev_err(&led->client->dev, "Failed to disable regulator\n");
+ return ret;
+ }
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ mutex_destroy(&led->lock);
+
+ return 0;
+}
+
+static const struct i2c_device_id lp50xx_id[] = {
+ { "lp5009", LP5009 },
+ { "lp5012", LP5012 },
+ { "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,lp5009", .data = (void *)LP5009 },
+ { .compatible = "ti,lp5012", .data = (void *)LP5012 },
+ { .compatible = "ti,lp5018", .data = (void *)LP5018 },
+ { .compatible = "ti,lp5024", .data = (void *)LP5024 },
+ { .compatible = "ti,lp5030", .data = (void *)LP5030 },
+ { .compatible = "ti,lp5036", .data = (void *)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 LP50XX LED driver");
+MODULE_AUTHOR("Dan Murphy <[email protected]>");
+MODULE_LICENSE("GPL v2");
--
2.26.2

2020-06-15 20:18:56

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 06/15] dt-bindings: leds: Convert leds-lp55xx to yaml

Convert the leds-lp55xx.txt to yaml binding.

Signed-off-by: Dan Murphy <[email protected]>
---
.../devicetree/bindings/leds/leds-lp55xx.txt | 228 ------------------
.../devicetree/bindings/leds/leds-lp55xx.yaml | 218 +++++++++++++++++
2 files changed, 218 insertions(+), 228 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
deleted file mode 100644
index 1b66a413fb9d..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-Binding for TI/National Semiconductor LP55xx Led Drivers
-
-Required properties:
-- compatible: one of
- national,lp5521
- national,lp5523
- ti,lp55231
- ti,lp5562
- ti,lp8501
-
-- reg: I2C slave address
-- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
-
-Each child has own specific current settings
-- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
-- max-cur: Maximun current at each led channel.
-
-Optional properties:
-- enable-gpio: GPIO attached to the chip's enable pin
-- label: Used for naming LEDs
-- pwr-sel: LP8501 specific property. Power selection for output channels.
- 0: D1~9 are connected to VDD
- 1: D1~6 with VDD, D7~9 with VOUT
- 2: D1~6 with VOUT, D7~9 with VDD
- 3: D1~9 are connected to VOUT
-
-Alternatively, each child can have a specific channel name and trigger:
-- chan-name (optional): name of channel
-- linux,default-trigger (optional): see
- Documentation/devicetree/bindings/leds/common.txt
-
-example 1) LP5521
-3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
-'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
-on channel 0.
-
-lp5521@32 {
- compatible = "national,lp5521";
- reg = <0x32>;
- label = "lp5521_pri";
- clock-mode = /bits/ 8 <2>;
-
- chan0 {
- led-cur = /bits/ 8 <0x2f>;
- max-cur = /bits/ 8 <0x5f>;
- linux,default-trigger = "heartbeat";
- };
-
- chan1 {
- led-cur = /bits/ 8 <0x2f>;
- max-cur = /bits/ 8 <0x5f>;
- };
-
- chan2 {
- led-cur = /bits/ 8 <0x2f>;
- max-cur = /bits/ 8 <0x5f>;
- };
-};
-
-example 2) LP5523
-9 LED channels with specific name. Internal clock used.
-The I2C slave address is configurable with ASEL1 and ASEL0 pins.
-Available addresses are 32/33/34/35h.
-
-ASEL1 ASEL0 Address
--------------------------
- GND GND 32h
- GND VEN 33h
- VEN GND 34h
- VEN VEN 35h
-
-lp5523@32 {
- compatible = "national,lp5523";
- reg = <0x32>;
- clock-mode = /bits/ 8 <1>;
-
- chan0 {
- chan-name = "d1";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan1 {
- chan-name = "d2";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan2 {
- chan-name = "d3";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan3 {
- chan-name = "d4";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan4 {
- chan-name = "d5";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan5 {
- chan-name = "d6";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan6 {
- chan-name = "d7";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan7 {
- chan-name = "d8";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan8 {
- chan-name = "d9";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-};
-
-example 3) LP5562
-4 channels are defined.
-
-lp5562@30 {
- compatible = "ti,lp5562";
- reg = <0x30>;
- clock-mode = /bits/8 <2>;
-
- chan0 {
- chan-name = "R";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-
- chan1 {
- chan-name = "G";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-
- chan2 {
- chan-name = "B";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-
- chan3 {
- chan-name = "W";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-};
-
-example 4) LP8501
-9 channels are defined. The 'pwr-sel' is LP8501 specific property.
-Others are same as LP5523.
-
-lp8501@32 {
- compatible = "ti,lp8501";
- reg = <0x32>;
- clock-mode = /bits/ 8 <2>;
- pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
-
- chan0 {
- chan-name = "d1";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan1 {
- chan-name = "d2";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan2 {
- chan-name = "d3";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan3 {
- chan-name = "d4";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan4 {
- chan-name = "d5";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan5 {
- chan-name = "d6";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan6 {
- chan-name = "d7";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan7 {
- chan-name = "d8";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan8 {
- chan-name = "d9";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
new file mode 100644
index 000000000000..c39003c16536
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
@@ -0,0 +1,218 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI/National Semiconductor LP55xx and LP8501 LED Drivers
+
+maintainers:
+ - Jacek Anaszewski <[email protected]>
+ - Pavel Machek <[email protected]>
+
+description: |
+ Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel
+ LED Drivers.
+
+ For more product information please see the link below:
+ https://www.ti.com/lit/gpn/lp5521
+ https://www.ti.com/lit/gpn/lp5523
+ https://www.ti.com/lit/gpn/lp55231
+ https://www.ti.com/lit/gpn/lp5562
+ https://www.ti.com/lit/gpn/lp8501
+
+properties:
+ compatible:
+ enum:
+ - national,lp5521
+ - national,lp5523
+ - ti,lp55231
+ - ti,lp5562
+ - ti,lp8501
+
+ reg:
+ maxItems: 1
+ description: I2C slave address
+
+ clock-mode:
+ $ref: /schemas/types.yaml#definitions/uint8
+ description: |
+ Input clock mode
+ enum:
+ - 0 # automode
+ - 1 # internal
+ - 2 # external
+
+ enable-gpio:
+ maxItems: 1
+ description: |
+ GPIO attached to the chip's enable pin
+
+ pwr-sel:
+ $ref: /schemas/types.yaml#definitions/uint8
+ description: |
+ LP8501 specific property. Power selection for output channels.
+ enum:
+ - 0 # D1~9 are connected to VDD
+ - 1 # D1~6 with VDD, D7~9 with VOUT
+ - 2 # D1~6 with VOUT, D7~9 with VDD
+ - 3 # D1~9 are connected to VOUT
+
+patternProperties:
+ "(^led@[0-9a-f]$|led)":
+ type: object
+ $ref: common.yaml#
+ properties:
+ led-cur:
+ $ref: /schemas/types.yaml#definitions/uint8
+ description: |
+ Current setting at each LED channel (mA x10, 0 if LED is not connected)
+
+ max-cur:
+ $ref: /schemas/types.yaml#definitions/uint8
+ description: Maximun current at each LED channel.
+
+ reg:
+ description: |
+ Output channel for the LED. This is zero based channel identifier and
+ the data sheet is a one based channel identifier.
+ reg value to output to LED output number
+ enum:
+ - 0 # LED output D1
+ - 1 # LED output D2
+ - 2 # LED output D3
+ - 3 # LED output D4
+ - 4 # LED output D5
+ - 5 # LED output D6
+ - 6 # LED output D7
+ - 7 # LED output D8
+ - 8 # LED output D9
+
+ chan-name:
+ $ref: /schemas/types.yaml#definitions/string
+ description: name of channel
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lp8501";
+ reg = <0x32>;
+ clock-mode = /bits/ 8 <2>;
+ pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
+
+ led@0 {
+ reg = <0>;
+ chan-name = "d1";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@1 {
+ reg = <1>;
+ chan-name = "d2";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@2 {
+ reg = <2>;
+ chan-name = "d3";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@3 {
+ reg = <3>;
+ chan-name = "d4";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@4 {
+ reg = <4>;
+ chan-name = "d5";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@5 {
+ reg = <5>;
+ chan-name = "d6";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@6 {
+ reg = <6>;
+ chan-name = "d7";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@7 {
+ reg = <7>;
+ chan-name = "d8";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@8 {
+ reg = <8>;
+ chan-name = "d9";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+ };
+
+ led-controller@33 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "national,lp5523";
+ reg = <0x33>;
+ clock-mode = /bits/ 8 <0>;
+
+ multi-led@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STANDBY;
+ linux,default-trigger = "heartbeat";
+
+ led@0 {
+ led-cur = /bits/ 8 <50>;
+ max-cur = /bits/ 8 <100>;
+ reg = <0x0>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@1 {
+ led-cur = /bits/ 8 <50>;
+ max-cur = /bits/ 8 <100>;
+ reg = <0x1>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+
+ led@6 {
+ led-cur = /bits/ 8 <50>;
+ max-cur = /bits/ 8 <100>;
+ reg = <0x6>;
+ color = <LED_COLOR_ID_RED>;
+ };
+ };
+ };
+ };
+
+...
--
2.26.2

2020-06-15 20:19:02

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 09/15] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes

Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.

Signed-off-by: Dan Murphy <[email protected]>
CC: Linus Walleij <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
arch/arm/boot/dts/ste-href.dtsi | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
index 33e3b0b3c53d..ff47cbf6ed3b 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -58,16 +58,21 @@ lp5521@33 {
reg = <0x33>;
label = "lp5521_pri";
clock-mode = /bits/ 8 <2>;
- chan0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ chan@0 {
+ reg = <0>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
linux,default-trigger = "heartbeat";
};
- chan1 {
+ chan@1 {
+ reg = <1>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
@@ -77,15 +82,20 @@ lp5521@34 {
reg = <0x34>;
label = "lp5521_sec";
clock-mode = /bits/ 8 <2>;
- chan0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ chan@0 {
+ reg = <0>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan1 {
+ chan@1 {
+ reg = <1>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
--
2.26.2

2020-06-15 20:19:10

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 10/15] leds: lp55xx: Convert LED class registration to devm_*

Convert the LED class registration calls to the LED devm_*
registration calls.

Acked-by: Jacek Anaszewski <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/leds-lp5521.c | 9 +++------
drivers/leds/leds-lp5523.c | 9 +++------
drivers/leds/leds-lp5562.c | 9 +++------
drivers/leds/leds-lp55xx-common.c | 15 +--------------
drivers/leds/leds-lp55xx-common.h | 2 --
drivers/leds/leds-lp8501.c | 9 +++------
6 files changed, 13 insertions(+), 40 deletions(-)

diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 6f0272249dc8..6d2163c0f625 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -541,19 +541,17 @@ static int lp5521_probe(struct i2c_client *client,

ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;

ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}

return 0;

-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -566,7 +564,6 @@ static int lp5521_remove(struct i2c_client *client)

lp5521_stop_all_engines(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);

return 0;
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index d0b931a136b9..15e7051392f5 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -908,19 +908,17 @@ static int lp5523_probe(struct i2c_client *client,

ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;

ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}

return 0;

-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -933,7 +931,6 @@ static int lp5523_remove(struct i2c_client *client)

lp5523_stop_all_engines(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);

return 0;
diff --git a/drivers/leds/leds-lp5562.c b/drivers/leds/leds-lp5562.c
index edb57c42e8b1..1c94422408b0 100644
--- a/drivers/leds/leds-lp5562.c
+++ b/drivers/leds/leds-lp5562.c
@@ -554,19 +554,17 @@ static int lp5562_probe(struct i2c_client *client,

ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;

ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}

return 0;

-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -580,7 +578,6 @@ static int lp5562_remove(struct i2c_client *client)
lp5562_stop_engine(chip);

lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);

return 0;
diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index 44ced02b49f9..882ef39e4965 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -181,7 +181,7 @@ static int lp55xx_init_led(struct lp55xx_led *led,
led->cdev.name = name;
}

- ret = led_classdev_register(dev, &led->cdev);
+ ret = devm_led_classdev_register(dev, &led->cdev);
if (ret) {
dev_err(dev, "led register err: %d\n", ret);
return ret;
@@ -490,23 +490,10 @@ int lp55xx_register_leds(struct lp55xx_led *led, struct lp55xx_chip *chip)
return 0;

err_init_led:
- lp55xx_unregister_leds(led, chip);
return ret;
}
EXPORT_SYMBOL_GPL(lp55xx_register_leds);

-void lp55xx_unregister_leds(struct lp55xx_led *led, struct lp55xx_chip *chip)
-{
- int i;
- struct lp55xx_led *each;
-
- for (i = 0; i < chip->num_leds; i++) {
- each = led + i;
- led_classdev_unregister(&each->cdev);
- }
-}
-EXPORT_SYMBOL_GPL(lp55xx_unregister_leds);
-
int lp55xx_register_sysfs(struct lp55xx_chip *chip)
{
struct device *dev = &chip->cl->dev;
diff --git a/drivers/leds/leds-lp55xx-common.h b/drivers/leds/leds-lp55xx-common.h
index 783ed5103ce5..b9b1041e8143 100644
--- a/drivers/leds/leds-lp55xx-common.h
+++ b/drivers/leds/leds-lp55xx-common.h
@@ -189,8 +189,6 @@ extern void lp55xx_deinit_device(struct lp55xx_chip *chip);
/* common LED class device functions */
extern int lp55xx_register_leds(struct lp55xx_led *led,
struct lp55xx_chip *chip);
-extern void lp55xx_unregister_leds(struct lp55xx_led *led,
- struct lp55xx_chip *chip);

/* common device attributes functions */
extern int lp55xx_register_sysfs(struct lp55xx_chip *chip);
diff --git a/drivers/leds/leds-lp8501.c b/drivers/leds/leds-lp8501.c
index 2638dbf0e8ac..a58019cdb8c3 100644
--- a/drivers/leds/leds-lp8501.c
+++ b/drivers/leds/leds-lp8501.c
@@ -344,19 +344,17 @@ static int lp8501_probe(struct i2c_client *client,

ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;

ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}

return 0;

-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -369,7 +367,6 @@ static int lp8501_remove(struct i2c_client *client)

lp8501_stop_engine(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);

return 0;
--
2.26.2

2020-06-15 20:19:57

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 08/15] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node

Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.

Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
CC: Shawn Guo <[email protected]>
CC: Sascha Hauer <[email protected]>
CC: Pengutronix Kernel Team <[email protected]>
CC: Fabio Estevam <[email protected]>
CC: NXP Linux Team <[email protected]>
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index 2b9423d55c37..77aa90640052 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -258,29 +258,35 @@ leds: led-controller@30 {
reg = <0x30>;
clock-mode = /bits/ 8 <1>;
status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;

- chan0 {
+ chan@0 {
chan-name = "R";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
+ reg = <0>;
};

- chan1 {
+ chan@1 {
chan-name = "G";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
+ reg = <1>;
};

- chan2 {
+ chan@2 {
chan-name = "B";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
+ reg = <2>;
};

- chan3 {
+ chan@3 {
chan-name = "W";
led-cur = /bits/ 8 <0x0>;
max-cur = /bits/ 8 <0x0>;
+ reg = <3>;
};
};

--
2.26.2

2020-06-15 20:19:59

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 07/15] ARM: dts: n900: Add reg property to the LP5523 channel node

Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.

Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
CC: Tony Lindgren <[email protected]>
CC: "Benoît Cousson" <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
arch/arm/boot/dts/omap3-n900.dts | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 4089d97405c9..ebe93b06b4f7 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -618,63 +618,74 @@ indicator {
};

lp5523: lp5523@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "national,lp5523";
reg = <0x32>;
clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */

- chan0 {
+ chan@0 {
chan-name = "lp5523:kb1";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <0>;
};

- chan1 {
+ chan@1 {
chan-name = "lp5523:kb2";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <1>;
};

- chan2 {
+ chan@2 {
chan-name = "lp5523:kb3";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <2>;
};

- chan3 {
+ chan@3 {
chan-name = "lp5523:kb4";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <3>;
};

- chan4 {
+ chan@4 {
chan-name = "lp5523:b";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <4>;
};

- chan5 {
+ chan@5 {
chan-name = "lp5523:g";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <5>;
};

- chan6 {
+ chan@6 {
chan-name = "lp5523:r";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <6>;
};

- chan7 {
+ chan@7 {
chan-name = "lp5523:kb5";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <7>;
};

- chan8 {
+ chan@8 {
chan-name = "lp5523:kb6";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <8>;
};
};

--
2.26.2

2020-06-15 20:20:11

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 12/15] leds: lp5523: Update the lp5523 code to add multicolor brightness function

Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
in a single function.

Acked-by: Pavel Machek <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5523.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8fe94f3571e2..869b299a9eed 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -408,6 +408,7 @@ config LEDS_LP5521
config LEDS_LP5523
tristate "LED Support for TI/National LP5523/55231 LED driver chip"
depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
select LEDS_LP55XX_COMMON
help
If you say yes here you get support for TI/National Semiconductor
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index b076c16df9ab..9776dc72a764 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -791,6 +791,25 @@ static ssize_t store_master_fader_leds(struct device *dev,
return ret;
}

+static int lp5523_multicolor_brightness(struct lp55xx_led *led)
+{
+ struct lp55xx_chip *chip = led->chip;
+ int ret;
+ int i;
+
+ mutex_lock(&chip->lock);
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ ret = lp55xx_write(chip,
+ LP5523_REG_LED_PWM_BASE +
+ led->mc_cdev.subled_info[i].channel,
+ led->mc_cdev.subled_info[i].brightness);
+ if (ret)
+ break;
+ }
+ mutex_unlock(&chip->lock);
+ return ret;
+}
+
static int lp5523_led_brightness(struct lp55xx_led *led)
{
struct lp55xx_chip *chip = led->chip;
@@ -857,6 +876,7 @@ static struct lp55xx_device_config lp5523_cfg = {
.max_channel = LP5523_MAX_LEDS,
.post_init_device = lp5523_post_init_device,
.brightness_fn = lp5523_led_brightness,
+ .multicolor_brightness_fn = lp5523_multicolor_brightness,
.set_led_current = lp5523_set_led_current,
.firmware_cb = lp5523_firmware_loaded,
.run_engine = lp5523_run_engine,
--
2.26.2

2020-06-15 20:20:18

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 02/15] leds: Add multicolor ID to the color ID list

Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.

Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/led-core.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index f1f718dbe0f8..846248a0693d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -34,6 +34,7 @@ const char * const led_colors[LED_COLOR_ID_MAX] = {
[LED_COLOR_ID_VIOLET] = "violet",
[LED_COLOR_ID_YELLOW] = "yellow",
[LED_COLOR_ID_IR] = "ir",
+ [LED_COLOR_ID_MULTI] = "multicolor",
};
EXPORT_SYMBOL_GPL(led_colors);

--
2.26.2

2020-06-15 20:20:18

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 14/15] leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros

Fix the checkpatch warnings for the use of the file permission macros.
In converting the file permissions to the DEVICE_ATTR_XX macros the
call back function names needed to be updated within the code.

This means that the lp55xx_ needed to be dropped in the name to keep in
harmony with the ABI documentation.

Acked-by: Pavel Machek <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/leds-lp55xx-common.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index d33564aef563..59c3234ba1d7 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -83,7 +83,7 @@ static int lp55xx_post_init_device(struct lp55xx_chip *chip)
return cfg->post_init_device(chip);
}

-static ssize_t lp55xx_show_current(struct device *dev,
+static ssize_t led_current_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -92,7 +92,7 @@ static ssize_t lp55xx_show_current(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%d\n", led->led_current);
}

-static ssize_t lp55xx_store_current(struct device *dev,
+static ssize_t led_current_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -116,7 +116,7 @@ static ssize_t lp55xx_store_current(struct device *dev,
return len;
}

-static ssize_t lp55xx_show_max_current(struct device *dev,
+static ssize_t max_current_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -125,9 +125,8 @@ static ssize_t lp55xx_show_max_current(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%d\n", led->max_current);
}

-static DEVICE_ATTR(led_current, S_IRUGO | S_IWUSR, lp55xx_show_current,
- lp55xx_store_current);
-static DEVICE_ATTR(max_current, S_IRUGO , lp55xx_show_max_current, NULL);
+static DEVICE_ATTR_RW(led_current);
+static DEVICE_ATTR_RO(max_current);

static struct attribute *lp55xx_led_attrs[] = {
&dev_attr_led_current.attr,
@@ -271,7 +270,7 @@ static int lp55xx_request_firmware(struct lp55xx_chip *chip)
GFP_KERNEL, chip, lp55xx_firmware_loaded);
}

-static ssize_t lp55xx_show_engine_select(struct device *dev,
+static ssize_t select_engine_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -281,7 +280,7 @@ static ssize_t lp55xx_show_engine_select(struct device *dev,
return sprintf(buf, "%d\n", chip->engine_idx);
}

-static ssize_t lp55xx_store_engine_select(struct device *dev,
+static ssize_t select_engine_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -323,7 +322,7 @@ static inline void lp55xx_run_engine(struct lp55xx_chip *chip, bool start)
chip->cfg->run_engine(chip, start);
}

-static ssize_t lp55xx_store_engine_run(struct device *dev,
+static ssize_t run_engine_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -348,9 +347,8 @@ static ssize_t lp55xx_store_engine_run(struct device *dev,
return len;
}

-static DEVICE_ATTR(select_engine, S_IRUGO | S_IWUSR,
- lp55xx_show_engine_select, lp55xx_store_engine_select);
-static DEVICE_ATTR(run_engine, S_IWUSR, NULL, lp55xx_store_engine_run);
+static DEVICE_ATTR_RW(select_engine);
+static DEVICE_ATTR_WO(run_engine);

static struct attribute *lp55xx_engine_attributes[] = {
&dev_attr_select_engine.attr,
--
2.26.2

2020-06-15 20:20:28

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 15/15] leds: lp5523: Fix various formatting issues in the code

Fix checkpatch errors and warnings for the LP5523.c device
driver.

Acked-by: Pavel Machek <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/leds-lp5523.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 9776dc72a764..f55d97258d5e 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -23,13 +23,13 @@

#define LP5523_PROGRAM_LENGTH 32 /* bytes */
/* Memory is used like this:
- 0x00 engine 1 program
- 0x10 engine 2 program
- 0x20 engine 3 program
- 0x30 engine 1 muxing info
- 0x40 engine 2 muxing info
- 0x50 engine 3 muxing info
-*/
+ * 0x00 engine 1 program
+ * 0x10 engine 2 program
+ * 0x20 engine 3 program
+ * 0x30 engine 1 muxing info
+ * 0x40 engine 2 muxing info
+ * 0x50 engine 3 muxing info
+ */
#define LP5523_MAX_LEDS 9

/* Registers */
@@ -326,7 +326,7 @@ static int lp5523_update_program_memory(struct lp55xx_chip *chip,
const u8 *data, size_t size)
{
u8 pattern[LP5523_PROGRAM_LENGTH] = {0};
- unsigned cmd;
+ unsigned int cmd;
char c[3];
int nrchars;
int ret;
@@ -468,6 +468,7 @@ static int lp5523_mux_parse(const char *buf, u16 *mux, size_t len)
static void lp5523_mux_to_array(u16 led_mux, char *array)
{
int i, pos = 0;
+
for (i = 0; i < LP5523_MAX_LEDS; i++)
pos += sprintf(array + pos, "%x", LED_ACTIVE(led_mux, i));

@@ -506,7 +507,7 @@ static int lp5523_load_mux(struct lp55xx_chip *chip, u16 mux, int nr)
if (ret)
return ret;

- ret = lp55xx_write(chip, LP5523_REG_PROG_MEM , (u8)(mux >> 8));
+ ret = lp55xx_write(chip, LP5523_REG_PROG_MEM, (u8)(mux >> 8));
if (ret)
return ret;

--
2.26.2

2020-06-15 20:20:36

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 04/15] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers

Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
can control RGB LEDs individually or as part of a control bank group.
These devices have the ability to adjust the mixing control for the RGB
LEDs to obtain different colors independent of the overall brightness of
the LED grouping.

Datasheet:
http://www.ti.com/lit/ds/symlink/lp5012.pdf
http://www.ti.com/lit/ds/symlink/lp5024.pdf
http://www.ti.com/lit/ds/symlink/lp5036.pdf

Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
.../devicetree/bindings/leds/leds-lp50xx.yaml | 130 ++++++++++++++++++
1 file changed, 130 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
new file mode 100644
index 000000000000..de5225b54a45
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for LP50XX RGB LED from Texas Instruments.
+
+maintainers:
+ - Dan Murphy <[email protected]>
+
+description: |
+ The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
+ a LED group or control them individually.
+
+ The difference in these RGB LED drivers is the number of supported RGB
+ modules.
+
+ For more product information please see the link below:
+ http://www.ti.com/lit/ds/symlink/lp5012.pdf
+ http://www.ti.com/lit/ds/symlink/lp5024.pdf
+ http://www.ti.com/lit/ds/symlink/lp5036.pdf
+
+properties:
+ compatible:
+ enum:
+ - ti,lp5009
+ - ti,lp5012
+ - ti,lp5018
+ - ti,lp5024
+ - ti,lp5030
+ - ti,lp5036
+
+ reg:
+ maxItems: 1
+ description:
+ I2C slave address
+ lp5009/12 - 0x14, 0x15, 0x16, 0x17
+ lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
+ lp5030/36 - 0x30, 0x31, 0x32, 0x33
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO pin to enable/disable the device.
+
+ vled-supply:
+ description: LED supply.
+
+patternProperties:
+ '^multi-led@[0-9a-f]$':
+ type: object
+ allOf:
+ - $ref: leds-class-multicolor.yaml#
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 12
+ description:
+ This property denotes the LED module number(s) that is used on the
+ for the child node. The LED modules can either be used stand alone
+ or grouped into a module bank.
+
+ patternProperties:
+ "(^led-[0-9a-f]$|led)":
+ type: object
+ $ref: common.yaml#
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@14 {
+ compatible = "ti,lp5009";
+ reg = <0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-gpios = <&gpio1 16>;
+
+ multi-led@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_CHARGING;
+
+ led-0 {
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led-2 {
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
+ multi-led@2 {
+ #address-cells = <1>;
+ #size-cells = <2>;
+ reg = <0x2 0x3 0x5>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STANDBY;
+
+ led-6 {
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led-7 {
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led-8 {
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+ };
+
+...
--
2.26.2

2020-06-15 20:21:06

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 13/15] leds: lp5521: Add multicolor framework multicolor brightness support

Add the multicolor brightness call back to support the multicolor
framework. This function allows setting the brightness across
grouped LED channels in a single call.

Acked-by: Pavel Machek <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5521.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 869b299a9eed..4970bbde6ea3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -398,6 +398,7 @@ config LEDS_LP55XX_COMMON
config LEDS_LP5521
tristate "LED Support for N.S. LP5521 LED driver chip"
depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
select LEDS_LP55XX_COMMON
help
If you say yes here you get support for the National Semiconductor
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 6ff81d6be789..ef8c3bfa8f3c 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -349,6 +349,25 @@ static int lp5521_run_selftest(struct lp55xx_chip *chip, char *buf)
return 0;
}

+static int lp5521_multicolor_brightness(struct lp55xx_led *led)
+{
+ struct lp55xx_chip *chip = led->chip;
+ int ret;
+ int i;
+
+ mutex_lock(&chip->lock);
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ ret = lp55xx_write(chip,
+ LP5521_REG_LED_PWM_BASE +
+ led->mc_cdev.subled_info[i].channel,
+ led->mc_cdev.subled_info[i].brightness);
+ if (ret)
+ break;
+ }
+ mutex_unlock(&chip->lock);
+ return ret;
+}
+
static int lp5521_led_brightness(struct lp55xx_led *led)
{
struct lp55xx_chip *chip = led->chip;
@@ -490,6 +509,7 @@ static struct lp55xx_device_config lp5521_cfg = {
.max_channel = LP5521_MAX_LEDS,
.post_init_device = lp5521_post_init_device,
.brightness_fn = lp5521_led_brightness,
+ .multicolor_brightness_fn = lp5521_multicolor_brightness,
.set_led_current = lp5521_set_led_current,
.firmware_cb = lp5521_firmware_loaded,
.run_engine = lp5521_run_engine,
--
2.26.2

2020-06-15 20:29:48

by Pavel Machek

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 00/15] Multicolor Framework v27

Hi!

> This is the multi color LED framework. This framework presents clustered
> colored LEDs into an array and allows the user space to adjust the brightness
> of the cluster using a single file write. The individual colored LEDs
> intensities are controlled via a single file that is an array of
> LEDs

Please don't do this. Pinging whoever you think is blocking the merge
is okay, but resending big series just because people are busy over
the merge window is not cool.

Thanks,

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (656.00 B)
signature.asc (201.00 B)
Download all attachments

2020-06-15 20:37:01

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 00/15] Multicolor Framework v27

Pavel

On 6/15/20 3:27 PM, Pavel Machek wrote:
> Hi!
>
>> This is the multi color LED framework. This framework presents clustered
>> colored LEDs into an array and allows the user space to adjust the brightness
>> of the cluster using a single file write. The individual colored LEDs
>> intensities are controlled via a single file that is an array of
>> LEDs
> Please don't do this. Pinging whoever you think is blocking the merge
> is okay, but resending big series just because people are busy over
> the merge window is not cool.

Actually that is not the case.? I missed adding Rob H to the series so I
resent the patches to add Rob in.

There was no intent to resend because I thought it was blocked.

I know we are in a merge window and thoroughly understand that ppl are busy.

If I thought it was blocked I would have just bumped the first patch.

Dan


> Thanks,
>
> Pavel

2020-06-15 21:33:44

by Dan Murphy

[permalink] [raw]
Subject: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Add multicolor framework support for the lp55xx family.

Acked-by: Pavel Machek <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5521.c | 14 +-
drivers/leds/leds-lp5523.c | 14 +-
drivers/leds/leds-lp5562.c | 13 +-
drivers/leds/leds-lp55xx-common.c | 177 +++++++++++++++++++---
drivers/leds/leds-lp55xx-common.h | 14 +-
drivers/leds/leds-lp8501.c | 14 +-
include/linux/platform_data/leds-lp55xx.h | 8 +
8 files changed, 208 insertions(+), 47 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index d3a792cac814..8fe94f3571e2 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -388,6 +388,7 @@ config LEDS_LP50XX
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
+ depends on OF
select FW_LOADER
select FW_LOADER_USER_HELPER
help
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 6d2163c0f625..6ff81d6be789 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -505,9 +505,16 @@ static int lp5521_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;

+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp5521_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -516,10 +523,6 @@ static int lp5521_probe(struct i2c_client *client,
}
}

- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
-
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
if (!led)
@@ -527,7 +530,6 @@ static int lp5521_probe(struct i2c_client *client,

chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp5521_cfg;

mutex_init(&chip->lock);

diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 15e7051392f5..b076c16df9ab 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -872,9 +872,16 @@ static int lp5523_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;

+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp5523_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -883,10 +890,6 @@ static int lp5523_probe(struct i2c_client *client,
}
}

- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
-
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
if (!led)
@@ -894,7 +897,6 @@ static int lp5523_probe(struct i2c_client *client,

chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp5523_cfg;

mutex_init(&chip->lock);

diff --git a/drivers/leds/leds-lp5562.c b/drivers/leds/leds-lp5562.c
index 1c94422408b0..7ecdd199d7ef 100644
--- a/drivers/leds/leds-lp5562.c
+++ b/drivers/leds/leds-lp5562.c
@@ -520,9 +520,16 @@ static int lp5562_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;

+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp5562_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -531,9 +538,6 @@ static int lp5562_probe(struct i2c_client *client,
}
}

- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;

led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
@@ -542,7 +546,6 @@ static int lp5562_probe(struct i2c_client *client,

chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp5562_cfg;

mutex_init(&chip->lock);

diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index 882ef39e4965..d33564aef563 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -35,6 +35,11 @@ static struct lp55xx_led *dev_to_lp55xx_led(struct device *dev)
return cdev_to_lp55xx_led(dev_get_drvdata(dev));
}

+static struct lp55xx_led *mcled_cdev_to_led(struct led_classdev_mc *mc_cdev)
+{
+ return container_of(mc_cdev, struct lp55xx_led, mc_cdev);
+}
+
static void lp55xx_reset_device(struct lp55xx_chip *chip)
{
struct lp55xx_device_config *cfg = chip->cfg;
@@ -131,6 +136,18 @@ static struct attribute *lp55xx_led_attrs[] = {
};
ATTRIBUTE_GROUPS(lp55xx_led);

+static int lp55xx_set_mc_brightness(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
+ struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
+ struct lp55xx_device_config *cfg = led->chip->cfg;
+
+ led_mc_calc_color_components(&led->mc_cdev, brightness);
+ return cfg->multicolor_brightness_fn(led);
+
+}
+
static int lp55xx_set_brightness(struct led_classdev *cdev,
enum led_brightness brightness)
{
@@ -147,9 +164,12 @@ static int lp55xx_init_led(struct lp55xx_led *led,
struct lp55xx_platform_data *pdata = chip->pdata;
struct lp55xx_device_config *cfg = chip->cfg;
struct device *dev = &chip->cl->dev;
+ int max_channel = cfg->max_channel;
+ struct mc_subled *mc_led_info;
+ struct led_classdev *led_cdev;
char name[32];
+ int i, j = 0;
int ret;
- int max_channel = cfg->max_channel;

if (chan >= max_channel) {
dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
@@ -159,10 +179,43 @@ static int lp55xx_init_led(struct lp55xx_led *led,
if (pdata->led_config[chan].led_current == 0)
return 0;

+ if (pdata->led_config[chan].name) {
+ led->cdev.name = pdata->led_config[chan].name;
+ } else {
+ snprintf(name, sizeof(name), "%s:channel%d",
+ pdata->label ? : chip->cl->name, chan);
+ led->cdev.name = name;
+ }
+
+ if (pdata->led_config[chan].num_colors > 1) {
+ mc_led_info = devm_kcalloc(dev,
+ pdata->led_config[chan].num_colors,
+ sizeof(*mc_led_info), GFP_KERNEL);
+ if (!mc_led_info)
+ return -ENOMEM;
+
+ led_cdev = &led->mc_cdev.led_cdev;
+ led_cdev->name = led->cdev.name;
+ led_cdev->brightness_set_blocking = lp55xx_set_mc_brightness;
+ led->mc_cdev.num_colors = pdata->led_config[chan].num_colors;
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ mc_led_info[i].color_index =
+ pdata->led_config[chan].color_id[i];
+ mc_led_info[i].channel =
+ pdata->led_config[chan].output_num[i];
+ j++;
+ }
+
+ led->mc_cdev.subled_info = mc_led_info;
+ } else {
+ led->cdev.brightness_set_blocking = lp55xx_set_brightness;
+ }
+
+ led->cdev.groups = lp55xx_led_groups;
+ led->cdev.default_trigger = pdata->led_config[chan].default_trigger;
led->led_current = pdata->led_config[chan].led_current;
led->max_current = pdata->led_config[chan].max_current;
led->chan_nr = pdata->led_config[chan].chan_nr;
- led->cdev.default_trigger = pdata->led_config[chan].default_trigger;

if (led->chan_nr >= max_channel) {
dev_err(dev, "Use channel numbers between 0 and %d\n",
@@ -170,18 +223,11 @@ static int lp55xx_init_led(struct lp55xx_led *led,
return -EINVAL;
}

- led->cdev.brightness_set_blocking = lp55xx_set_brightness;
- led->cdev.groups = lp55xx_led_groups;
-
- if (pdata->led_config[chan].name) {
- led->cdev.name = pdata->led_config[chan].name;
- } else {
- snprintf(name, sizeof(name), "%s:channel%d",
- pdata->label ? : chip->cl->name, chan);
- led->cdev.name = name;
- }
+ if (pdata->led_config[chan].num_colors > 1)
+ ret = devm_led_classdev_multicolor_register(dev, &led->mc_cdev);
+ else
+ ret = devm_led_classdev_register(dev, &led->cdev);

- ret = devm_led_classdev_register(dev, &led->cdev);
if (ret) {
dev_err(dev, "led register err: %d\n", ret);
return ret;
@@ -525,14 +571,105 @@ void lp55xx_unregister_sysfs(struct lp55xx_chip *chip)
}
EXPORT_SYMBOL_GPL(lp55xx_unregister_sysfs);

+static int lp55xx_parse_common_child(struct device_node *np,
+ struct lp55xx_led_config *cfg,
+ int led_number, int *chan_nr)
+{
+ int ret;
+
+ of_property_read_string(np, "chan-name",
+ &cfg[led_number].name);
+ of_property_read_u8(np, "led-cur",
+ &cfg[led_number].led_current);
+ of_property_read_u8(np, "max-cur",
+ &cfg[led_number].max_current);
+
+ ret = of_property_read_u32(np, "reg", chan_nr);
+ if (ret)
+ return ret;
+
+ if (*chan_nr < 0 || *chan_nr > cfg->max_channel)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int lp55xx_parse_multi_led_child(struct device_node *child,
+ struct lp55xx_led_config *cfg,
+ int child_number, int color_number)
+{
+ int chan_nr, color_id, ret;
+
+ ret = lp55xx_parse_common_child(child, cfg, child_number, &chan_nr);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(child, "color", &color_id);
+ if (ret)
+ return ret;
+
+ cfg[child_number].color_id[color_number] = color_id;
+ cfg[child_number].output_num[color_number] = chan_nr;
+
+ return 0;
+}
+
+static int lp55xx_parse_multi_led(struct device_node *np,
+ struct lp55xx_led_config *cfg,
+ int child_number)
+{
+ struct device_node *child;
+ int num_colors = 0, ret;
+
+ for_each_child_of_node(np, child) {
+ ret = lp55xx_parse_multi_led_child(child, cfg, child_number,
+ num_colors);
+ if (ret)
+ return ret;
+ num_colors++;
+ }
+
+ cfg[child_number].num_colors = num_colors;
+
+ return 0;
+}
+
+static int lp55xx_parse_logical_led(struct device_node *np,
+ struct lp55xx_led_config *cfg,
+ int child_number)
+{
+ int led_color, ret;
+ int chan_nr = 0;
+
+ cfg[child_number].default_trigger =
+ of_get_property(np, "linux,default-trigger", NULL);
+
+ ret = of_property_read_u32(np, "color", &led_color);
+ if (ret)
+ return ret;
+
+ if (led_color == LED_COLOR_ID_MULTI)
+ return lp55xx_parse_multi_led(np, cfg, child_number);
+
+ ret = lp55xx_parse_common_child(np, cfg, child_number, &chan_nr);
+ if (ret < 0)
+ return ret;
+
+ cfg[child_number].chan_nr = chan_nr;
+
+ return ret;
+}
+
struct lp55xx_platform_data *lp55xx_of_populate_pdata(struct device *dev,
- struct device_node *np)
+ struct device_node *np,
+ struct lp55xx_chip *chip)
{
struct device_node *child;
struct lp55xx_platform_data *pdata;
struct lp55xx_led_config *cfg;
int num_channels;
int i = 0;
+ int ret;

pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -550,16 +687,12 @@ struct lp55xx_platform_data *lp55xx_of_populate_pdata(struct device *dev,

pdata->led_config = &cfg[0];
pdata->num_channels = num_channels;
+ cfg->max_channel = chip->cfg->max_channel;

for_each_child_of_node(np, child) {
- cfg[i].chan_nr = i;
-
- of_property_read_string(child, "chan-name", &cfg[i].name);
- of_property_read_u8(child, "led-cur", &cfg[i].led_current);
- of_property_read_u8(child, "max-cur", &cfg[i].max_current);
- cfg[i].default_trigger =
- of_get_property(child, "linux,default-trigger", NULL);
-
+ ret = lp55xx_parse_logical_led(child, cfg, i);
+ if (ret)
+ return ERR_PTR(-EINVAL);
i++;
}

diff --git a/drivers/leds/leds-lp55xx-common.h b/drivers/leds/leds-lp55xx-common.h
index b9b1041e8143..2f38c5b33830 100644
--- a/drivers/leds/leds-lp55xx-common.h
+++ b/drivers/leds/leds-lp55xx-common.h
@@ -12,6 +12,8 @@
#ifndef _LEDS_LP55XX_COMMON_H
#define _LEDS_LP55XX_COMMON_H

+#include <linux/led-class-multicolor.h>
+
enum lp55xx_engine_index {
LP55XX_ENGINE_INVALID,
LP55XX_ENGINE_1,
@@ -93,6 +95,7 @@ struct lp55xx_reg {
* @max_channel : Maximum number of channels
* @post_init_device : Chip specific initialization code
* @brightness_fn : Brightness function
+ * @multicolor_brightness_fn : Multicolor brightness function
* @set_led_current : LED current set function
* @firmware_cb : Call function when the firmware is loaded
* @run_engine : Run internal engine for pattern
@@ -106,9 +109,12 @@ struct lp55xx_device_config {
/* define if the device has specific initialization process */
int (*post_init_device) (struct lp55xx_chip *chip);

- /* access brightness register */
+ /* set LED brightness */
int (*brightness_fn)(struct lp55xx_led *led);

+ /* set multicolor LED brightness */
+ int (*multicolor_brightness_fn)(struct lp55xx_led *led);
+
/* current setting function */
void (*set_led_current) (struct lp55xx_led *led, u8 led_current);

@@ -159,6 +165,8 @@ struct lp55xx_chip {
* struct lp55xx_led
* @chan_nr : Channel number
* @cdev : LED class device
+ * @mc_cdev : Multi color class device
+ * @color_components: Multi color LED map information
* @led_current : Current setting at each led channel
* @max_current : Maximun current at each led channel
* @brightness : Brightness value
@@ -167,6 +175,7 @@ struct lp55xx_chip {
struct lp55xx_led {
int chan_nr;
struct led_classdev cdev;
+ struct led_classdev_mc mc_cdev;
u8 led_current;
u8 max_current;
u8 brightness;
@@ -196,6 +205,7 @@ extern void lp55xx_unregister_sysfs(struct lp55xx_chip *chip);

/* common device tree population function */
extern struct lp55xx_platform_data
-*lp55xx_of_populate_pdata(struct device *dev, struct device_node *np);
+*lp55xx_of_populate_pdata(struct device *dev, struct device_node *np,
+ struct lp55xx_chip *chip);

#endif /* _LEDS_LP55XX_COMMON_H */
diff --git a/drivers/leds/leds-lp8501.c b/drivers/leds/leds-lp8501.c
index a58019cdb8c3..ac2c31db4a65 100644
--- a/drivers/leds/leds-lp8501.c
+++ b/drivers/leds/leds-lp8501.c
@@ -308,9 +308,16 @@ static int lp8501_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;

+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp8501_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -319,10 +326,6 @@ static int lp8501_probe(struct i2c_client *client,
}
}

- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
-
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
if (!led)
@@ -330,7 +333,6 @@ static int lp8501_probe(struct i2c_client *client,

chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp8501_cfg;

mutex_init(&chip->lock);

diff --git a/include/linux/platform_data/leds-lp55xx.h b/include/linux/platform_data/leds-lp55xx.h
index 96a787100fda..d85275aea38c 100644
--- a/include/linux/platform_data/leds-lp55xx.h
+++ b/include/linux/platform_data/leds-lp55xx.h
@@ -12,17 +12,25 @@
#ifndef _LEDS_LP55XX_H
#define _LEDS_LP55XX_H

+#include <linux/led-class-multicolor.h>
+
/* Clock configuration */
#define LP55XX_CLOCK_AUTO 0
#define LP55XX_CLOCK_INT 1
#define LP55XX_CLOCK_EXT 2

+#define LP55XX_MAX_GROUPED_CHAN 4
+
struct lp55xx_led_config {
const char *name;
const char *default_trigger;
u8 chan_nr;
u8 led_current; /* mA x10, 0 if led is not connected */
u8 max_current;
+ int num_colors;
+ unsigned int max_channel;
+ int color_id[LED_COLOR_ID_MAX];
+ int output_num[LED_COLOR_ID_MAX];
};

struct lp55xx_predef_pattern {
--
2.26.2

2020-06-17 16:53:54

by kernel test robot

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Hi Dan,

I love your patch! Yet something to improve:

[auto build test ERROR on pavel-linux-leds/for-next]
[cannot apply to j.anaszewski-leds/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url: https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
base: git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git for-next
config: ia64-randconfig-r015-20200617 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=ia64

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>

All errors (new ones prefixed by >>, old ones prefixed by <<):

ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_set_mc_brightness':
>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to `led_mc_calc_color_components'
ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function `devm_led_classdev_multicolor_register':
>> include/linux/led-class-multicolor.h:74: undefined reference to `devm_led_classdev_multicolor_register_ext'

vim +146 drivers/leds/leds-lp55xx-common.c

138
139 static int lp55xx_set_mc_brightness(struct led_classdev *cdev,
140 enum led_brightness brightness)
141 {
142 struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
143 struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
144 struct lp55xx_device_config *cfg = led->chip->cfg;
145
> 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
147 return cfg->multicolor_brightness_fn(led);
148

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]


Attachments:
(No filename) (2.16 kB)
.config.gz (26.05 kB)
Download all attachments

2020-06-17 19:26:49

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Pavel/Jacek

On 6/17/20 11:28 AM, kernel test robot wrote:
> Hi Dan,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on pavel-linux-leds/for-next]
> [cannot apply to j.anaszewski-leds/for-next]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url: https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
> base: git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git for-next
> config: ia64-randconfig-r015-20200617 (attached as .config)
> compiler: ia64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=ia64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <[email protected]>
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_set_mc_brightness':
>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to `led_mc_calc_color_components'
> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function `devm_led_classdev_multicolor_register':
>>> include/linux/led-class-multicolor.h:74: undefined reference to `devm_led_classdev_multicolor_register_ext'
> vim +146 drivers/leds/leds-lp55xx-common.c
>
> 138
> 139 static int lp55xx_set_mc_brightness(struct led_classdev *cdev,
> 140 enum led_brightness brightness)
> 141 {
> 142 struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
> 143 struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
> 144 struct lp55xx_device_config *cfg = led->chip->cfg;
> 145
> > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
> 147 return cfg->multicolor_brightness_fn(led);
> 148

Well this was a mess to figure out.

The only fix I can figure out here is to remove the

??? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR

from each child device and add

??? select LEDS_CLASS_MULTI_COLOR

to the LP55XX_COMMON

This way the Multi color framework will inherit the symbol that was set
by the COMMON flag which is inherited by majority from the child flags.

Dan

2020-06-17 21:43:57

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Dan,

On 6/17/20 9:22 PM, Dan Murphy wrote:
> Pavel/Jacek
>
> On 6/17/20 11:28 AM, kernel test robot wrote:
>> Hi Dan,
>>
>> I love your patch! Yet something to improve:
>>
>> [auto build test ERROR on pavel-linux-leds/for-next]
>> [cannot apply to j.anaszewski-leds/for-next]
>> [if your patch is applied to the wrong git tree, please drop us a note
>> to help
>> improve the system. BTW, we also suggest to use '--base' option to
>> specify the
>> base tree in git format-patch, please see
>> https://stackoverflow.com/a/37406982]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>
>> base:
>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>> for-next
>> config: ia64-randconfig-r015-20200617 (attached as .config)
>> compiler: ia64-linux-gcc (GCC) 9.3.0
>> reproduce (this is a W=1 build):
>> ???????? wget
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>> -O ~/bin/make.cross
>> ???????? chmod +x ~/bin/make.cross
>> ???????? # save the attached .config to linux build tree
>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>> make.cross ARCH=ia64
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <[email protected]>
>>
>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>
>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>> `lp55xx_set_mc_brightness':
>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>> `led_mc_calc_color_components'
>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>> `devm_led_classdev_multicolor_register':
>>>> include/linux/led-class-multicolor.h:74: undefined reference to
>>>> `devm_led_classdev_multicolor_register_ext'
>> vim +146 drivers/leds/leds-lp55xx-common.c
>>
>> ??? 138
>> ??? 139??? static int lp55xx_set_mc_brightness(struct led_classdev *cdev,
>> ??? 140??????????????????????? enum led_brightness brightness)
>> ??? 141??? {
>> ??? 142??????? struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>> ??? 145
>> ? > 146??????? led_mc_calc_color_components(&led->mc_cdev, brightness);
>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>> ??? 148
>
> Well this was a mess to figure out.
>
> The only fix I can figure out here is to remove the
>
> ??? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>
> from each child device and add
>
> ??? select LEDS_CLASS_MULTI_COLOR
>
> to the LP55XX_COMMON
>
> This way the Multi color framework will inherit the symbol that was set
> by the COMMON flag which is inherited by majority from the child flags.

Did you try this?

--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -398,6 +398,7 @@ config LEDS_LP50XX
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National
LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
depends on OF
select FW_LOADER
select FW_LOADER_USER_HELPER


--
Best regards,
Jacek Anaszewski

2020-06-17 22:36:30

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/17/20 9:22 PM, Dan Murphy wrote:
>> Pavel/Jacek
>>
>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>> Hi Dan,
>>>
>>> I love your patch! Yet something to improve:
>>>
>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>> [cannot apply to j.anaszewski-leds/for-next]
>>> [if your patch is applied to the wrong git tree, please drop us a
>>> note to help
>>> improve the system. BTW, we also suggest to use '--base' option to
>>> specify the
>>> base tree in git format-patch, please see
>>> https://stackoverflow.com/a/37406982]
>>>
>>> url:
>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>
>>> base:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>> for-next
>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>> reproduce (this is a W=1 build):
>>> ???????? wget
>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>> -O ~/bin/make.cross
>>> ???????? chmod +x ~/bin/make.cross
>>> ???????? # save the attached .config to linux build tree
>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>> make.cross ARCH=ia64
>>>
>>> If you fix the issue, kindly add following tag as appropriate
>>> Reported-by: kernel test robot <[email protected]>
>>>
>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>
>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>> `lp55xx_set_mc_brightness':
>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>> `led_mc_calc_color_components'
>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>> `devm_led_classdev_multicolor_register':
>>>>> include/linux/led-class-multicolor.h:74: undefined reference to
>>>>> `devm_led_classdev_multicolor_register_ext'
>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>
>>> ??? 138
>>> ??? 139??? static int lp55xx_set_mc_brightness(struct led_classdev
>>> *cdev,
>>> ??? 140??????????????????????? enum led_brightness brightness)
>>> ??? 141??? {
>>> ??? 142??????? struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>> ??? 145
>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>> ??? 148
>>
>> Well this was a mess to figure out.
>>
>> The only fix I can figure out here is to remove the
>>
>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>
>> from each child device and add
>>
>> ???? select LEDS_CLASS_MULTI_COLOR
>>
>> to the LP55XX_COMMON
>>
>> This way the Multi color framework will inherit the symbol that was
>> set by the COMMON flag which is inherited by majority from the child
>> flags.
>
> Did you try this?
>
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -398,6 +398,7 @@ config LEDS_LP50XX
> ?config LEDS_LP55XX_COMMON
> ??????? tristate "Common Driver for TI/National
> LP5521/5523/55231/5562/8501"
> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
> LEDS_LP8501
> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
> ??????? depends on OF
> ??????? select FW_LOADER
> ??????? select FW_LOADER_USER_HELPER
>
>
Yes I did

That gave unmet dependencies.

WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] || LEDS_LP5523
[=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) && (LEDS_CLASS_MULTI_COLOR
[=m] || !LEDS_CLASS_MULTI_COLOR [=m]) && OF [=y]
? Selected by [y]:
? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
? Selected by [m]:
? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y] &&
(LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])

2020-06-18 22:53:16

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Dan,

On 6/18/20 11:44 PM, Dan Murphy wrote:
> Jacek
>
> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>> Jacek
>>>
>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>> Dan,
>>>>
>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>> Pavel/Jacek
>>>>>
>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>> Hi Dan,
>>>>>>
>>>>>> I love your patch! Yet something to improve:
>>>>>>
>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>> [if your patch is applied to the wrong git tree, please drop us a
>>>>>> note to help
>>>>>> improve the system. BTW, we also suggest to use '--base' option to
>>>>>> specify the
>>>>>> base tree in git format-patch, please see
>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>
>>>>>> url:
>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>
>>>>>> base:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>> for-next
>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>> reproduce (this is a W=1 build):
>>>>>> ???????? wget
>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>> -O ~/bin/make.cross
>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>> ???????? # save the attached .config to linux build tree
>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>> make.cross ARCH=ia64
>>>>>>
>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>
>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>
>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>>>> `led_mc_calc_color_components'
>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>> include/linux/led-class-multicolor.h:74: undefined reference to
>>>>>>>> `devm_led_classdev_multicolor_register_ext'
>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>
>>>>>> ??? 138
>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct led_classdev
>>>>>> *cdev,
>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>> ??? 141??? {
>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>> lcdev_to_mccdev(cdev);
>>>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>>>> ??? 145
>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>> ??? 148
>>>>>
>>>>> Well this was a mess to figure out.
>>>>>
>>>>> The only fix I can figure out here is to remove the
>>>>>
>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>
>>>>> from each child device and add
>>>>>
>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>
>>>>> to the LP55XX_COMMON
>>>>>
>>>>> This way the Multi color framework will inherit the symbol that was
>>>>> set by the COMMON flag which is inherited by majority from the
>>>>> child flags.
>>>>
>>>> Did you try this?
>>>>
>>>> --- a/drivers/leds/Kconfig
>>>> +++ b/drivers/leds/Kconfig
>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>> ?config LEDS_LP55XX_COMMON
>>>> ??????? tristate "Common Driver for TI/National
>>>> LP5521/5523/55231/5562/8501"
>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>> LEDS_LP8501
>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>> ??????? depends on OF
>>>> ??????? select FW_LOADER
>>>> ??????? select FW_LOADER_USER_HELPER
>>>>
>>>>
>>> Yes I did
>>>
>>> That gave unmet dependencies.
>>>
>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] || LEDS_LP5523
>>> [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) && OF [=y]
>>> ?? Selected by [y]:
>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>> ?? Selected by [m]:
>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>> && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>
>>
>> When I was testing that yesterday I also had the same warning at some
>> point of testing different Kconfig setups, but with what I showed above
>> it ceased to appear. Now every time I am doing "make oldconfig" the
>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>> from the test bot.
>>
> That is not what I saw in my testing especially after doing a distclean

Could you please give your exact steps after "make distclean" and
copying test bot config to the kernel root directory?

Also, please share the toolchain you're using for tests.

--
Best regards,
Jacek Anaszewski

2020-06-18 23:30:57

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/18/20 11:44 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>> Jacek
>>>>
>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>> Dan,
>>>>>
>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>> Pavel/Jacek
>>>>>>
>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> I love your patch! Yet something to improve:
>>>>>>>
>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>> [if your patch is applied to the wrong git tree, please drop us a
>>>>>>> note to help
>>>>>>> improve the system. BTW, we also suggest to use '--base' option
>>>>>>> to specify the
>>>>>>> base tree in git format-patch, please see
>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>
>>>>>>> url:
>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>
>>>>>>> base:
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git for-next
>>>>>>>
>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>> reproduce (this is a W=1 build):
>>>>>>> ???????? wget
>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>> -O ~/bin/make.cross
>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>> make.cross ARCH=ia64
>>>>>>>
>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>
>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>
>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>>>>> `led_mc_calc_color_components'
>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined reference to
>>>>>>>>> `devm_led_classdev_multicolor_register_ext'
>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>
>>>>>>> ??? 138
>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>> led_classdev *cdev,
>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>> ??? 141??? {
>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>>>>> ??? 145
>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>> ??? 148
>>>>>>
>>>>>> Well this was a mess to figure out.
>>>>>>
>>>>>> The only fix I can figure out here is to remove the
>>>>>>
>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>
>>>>>> from each child device and add
>>>>>>
>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>
>>>>>> to the LP55XX_COMMON
>>>>>>
>>>>>> This way the Multi color framework will inherit the symbol that
>>>>>> was set by the COMMON flag which is inherited by majority from the
>>>>>> child flags.
>>>>>
>>>>> Did you try this?
>>>>>
>>>>> --- a/drivers/leds/Kconfig
>>>>> +++ b/drivers/leds/Kconfig
>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>> ?config LEDS_LP55XX_COMMON
>>>>> ??????? tristate "Common Driver for TI/National
>>>>> LP5521/5523/55231/5562/8501"
>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>>> LEDS_LP8501
>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>> ??????? depends on OF
>>>>> ??????? select FW_LOADER
>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>
>>>>>
>>>> Yes I did
>>>>
>>>> That gave unmet dependencies.
>>>>
>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] || LEDS_LP5523
>>>> [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) && OF
>>>> [=y]
>>>> ?? Selected by [y]:
>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>> ?? Selected by [m]:
>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>> [=y] && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>
>>>
>>> When I was testing that yesterday I also had the same warning at some
>>> point of testing different Kconfig setups, but with what I showed above
>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>>> from the test bot.
>>>
>> That is not what I saw in my testing especially after doing a distclean
>
> Could you please give your exact steps after "make distclean" and
> copying test bot config to the kernel root directory?
>
> Also, please share the toolchain you're using for tests.

Actually at this stage the toolchain is of lesser relevance.

I've tried once more and indeed the problem shows up.

It is caused by the driver entries doing

"select LEDS_LP55XX_COMMON".

Select sets config to "y" so it conflicts with
"depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
in the "config LEDS_LP55XX_COMMON".

Your proposed fix will block the possibility of building
LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
are enabled so this is also not an option.

Solving this riddle will require some more thinking.
I haven't analyzed it in detail but maybe "imply" statement from
kconfig-language.rst could help somehow here.

--
Best regards,
Jacek Anaszewski

2020-06-19 00:40:15

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Dan,

On 6/18/20 12:33 AM, Dan Murphy wrote:
> Jacek
>
> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>> Pavel/Jacek
>>>
>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>> Hi Dan,
>>>>
>>>> I love your patch! Yet something to improve:
>>>>
>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>> [if your patch is applied to the wrong git tree, please drop us a
>>>> note to help
>>>> improve the system. BTW, we also suggest to use '--base' option to
>>>> specify the
>>>> base tree in git format-patch, please see
>>>> https://stackoverflow.com/a/37406982]
>>>>
>>>> url:
>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>
>>>> base:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>> for-next
>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>> reproduce (this is a W=1 build):
>>>> ???????? wget
>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>> -O ~/bin/make.cross
>>>> ???????? chmod +x ~/bin/make.cross
>>>> ???????? # save the attached .config to linux build tree
>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>> make.cross ARCH=ia64
>>>>
>>>> If you fix the issue, kindly add following tag as appropriate
>>>> Reported-by: kernel test robot <[email protected]>
>>>>
>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>
>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>> `lp55xx_set_mc_brightness':
>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>> `led_mc_calc_color_components'
>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>> `devm_led_classdev_multicolor_register':
>>>>>> include/linux/led-class-multicolor.h:74: undefined reference to
>>>>>> `devm_led_classdev_multicolor_register_ext'
>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>
>>>> ??? 138
>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct led_classdev
>>>> *cdev,
>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>> ??? 141??? {
>>>> ??? 142??????? struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>> ??? 145
>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>> ??? 148
>>>
>>> Well this was a mess to figure out.
>>>
>>> The only fix I can figure out here is to remove the
>>>
>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>
>>> from each child device and add
>>>
>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>
>>> to the LP55XX_COMMON
>>>
>>> This way the Multi color framework will inherit the symbol that was
>>> set by the COMMON flag which is inherited by majority from the child
>>> flags.
>>
>> Did you try this?
>>
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>> ?config LEDS_LP55XX_COMMON
>> ??????? tristate "Common Driver for TI/National
>> LP5521/5523/55231/5562/8501"
>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>> LEDS_LP8501
>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>> ??????? depends on OF
>> ??????? select FW_LOADER
>> ??????? select FW_LOADER_USER_HELPER
>>
>>
> Yes I did
>
> That gave unmet dependencies.
>
> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
> ? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] || LEDS_LP5523
> [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) && (LEDS_CLASS_MULTI_COLOR
> [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) && OF [=y]
> ? Selected by [y]:
> ? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
> ? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
> ? Selected by [m]:
> ? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y] &&
> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>

When I was testing that yesterday I also had the same warning at some
point of testing different Kconfig setups, but with what I showed above
it ceased to appear. Now every time I am doing "make oldconfig" the
CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
from the test bot.

--
Best regards,
Jacek Anaszewski

2020-06-19 00:42:53

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/18/20 12:33 AM, Dan Murphy wrote:
>> Jacek
>>
>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>> Pavel/Jacek
>>>>
>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>> Hi Dan,
>>>>>
>>>>> I love your patch! Yet something to improve:
>>>>>
>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>> [if your patch is applied to the wrong git tree, please drop us a
>>>>> note to help
>>>>> improve the system. BTW, we also suggest to use '--base' option to
>>>>> specify the
>>>>> base tree in git format-patch, please see
>>>>> https://stackoverflow.com/a/37406982]
>>>>>
>>>>> url:
>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>
>>>>> base:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>> for-next
>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>> reproduce (this is a W=1 build):
>>>>> ???????? wget
>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>> -O ~/bin/make.cross
>>>>> ???????? chmod +x ~/bin/make.cross
>>>>> ???????? # save the attached .config to linux build tree
>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>> make.cross ARCH=ia64
>>>>>
>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>
>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>
>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>> `lp55xx_set_mc_brightness':
>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>>> `led_mc_calc_color_components'
>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>> `devm_led_classdev_multicolor_register':
>>>>>>> include/linux/led-class-multicolor.h:74: undefined reference to
>>>>>>> `devm_led_classdev_multicolor_register_ext'
>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>
>>>>> ??? 138
>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct led_classdev
>>>>> *cdev,
>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>> ??? 141??? {
>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>> lcdev_to_mccdev(cdev);
>>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>>> ??? 145
>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>> ??? 148
>>>>
>>>> Well this was a mess to figure out.
>>>>
>>>> The only fix I can figure out here is to remove the
>>>>
>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>
>>>> from each child device and add
>>>>
>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>
>>>> to the LP55XX_COMMON
>>>>
>>>> This way the Multi color framework will inherit the symbol that was
>>>> set by the COMMON flag which is inherited by majority from the
>>>> child flags.
>>>
>>> Did you try this?
>>>
>>> --- a/drivers/leds/Kconfig
>>> +++ b/drivers/leds/Kconfig
>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>> ?config LEDS_LP55XX_COMMON
>>> ??????? tristate "Common Driver for TI/National
>>> LP5521/5523/55231/5562/8501"
>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>> LEDS_LP8501
>>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>> ??????? depends on OF
>>> ??????? select FW_LOADER
>>> ??????? select FW_LOADER_USER_HELPER
>>>
>>>
>> Yes I did
>>
>> That gave unmet dependencies.
>>
>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] || LEDS_LP5523
>> [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) && OF [=y]
>> ?? Selected by [y]:
>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>> ?? Selected by [m]:
>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>> && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>
>
> When I was testing that yesterday I also had the same warning at some
> point of testing different Kconfig setups, but with what I showed above
> it ceased to appear. Now every time I am doing "make oldconfig" the
> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
> from the test bot.
>
That is not what I saw in my testing especially after doing a distclean

Dan

2020-06-19 03:10:22

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>> Jacek
>>>
>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>> Dan,
>>>>
>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>> Jacek
>>>>>
>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>> Dan,
>>>>>>
>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>> Pavel/Jacek
>>>>>>>
>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>> Hi Dan,
>>>>>>>>
>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>
>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>> [if your patch is applied to the wrong git tree, please drop us
>>>>>>>> a note to help
>>>>>>>> improve the system. BTW, we also suggest to use '--base' option
>>>>>>>> to specify the
>>>>>>>> base tree in git format-patch, please see
>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>
>>>>>>>> url:
>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>
>>>>>>>> base:
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>> for-next
>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>> ???????? wget
>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>> -O ~/bin/make.cross
>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>>> make.cross ARCH=ia64
>>>>>>>>
>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>
>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>
>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>>>>>> `led_mc_calc_color_components'
>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined reference
>>>>>>>>>> to `devm_led_classdev_multicolor_register_ext'
>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>
>>>>>>>> ??? 138
>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>> led_classdev *cdev,
>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>> ??? 141??? {
>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>>>>>> ??? 145
>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>> ??? 148
>>>>>>>
>>>>>>> Well this was a mess to figure out.
>>>>>>>
>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>
>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>>
>>>>>>> from each child device and add
>>>>>>>
>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>
>>>>>>> to the LP55XX_COMMON
>>>>>>>
>>>>>>> This way the Multi color framework will inherit the symbol that
>>>>>>> was set by the COMMON flag which is inherited by majority from
>>>>>>> the child flags.
>>>>>>
>>>>>> Did you try this?
>>>>>>
>>>>>> --- a/drivers/leds/Kconfig
>>>>>> +++ b/drivers/leds/Kconfig
>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>> LP5521/5523/55231/5562/8501"
>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>>>> LEDS_LP8501
>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>> ??????? depends on OF
>>>>>> ??????? select FW_LOADER
>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>
>>>>>>
>>>>> Yes I did
>>>>>
>>>>> That gave unmet dependencies.
>>>>>
>>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) &&
>>>>> OF [=y]
>>>>> ?? Selected by [y]:
>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>>> ?? Selected by [m]:
>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>> [=y] && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>
>>>>
>>>> When I was testing that yesterday I also had the same warning at some
>>>> point of testing different Kconfig setups, but with what I showed
>>>> above
>>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>>>> from the test bot.
>>>>
>>> That is not what I saw in my testing especially after doing a distclean
>>
>> Could you please give your exact steps after "make distclean" and
>> copying test bot config to the kernel root directory?
>>
>> Also, please share the toolchain you're using for tests.
>
> Actually at this stage the toolchain is of lesser relevance.
>
> I've tried once more and indeed the problem shows up.
>
> It is caused by the driver entries doing
>
> "select LEDS_LP55XX_COMMON".
>
> Select sets config to "y" so it conflicts with
> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
> in the "config LEDS_LP55XX_COMMON".
>
> Your proposed fix will block the possibility of building
> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
> are enabled so this is also not an option.
>
> Solving this riddle will require some more thinking.
> I haven't analyzed it in detail but maybe "imply" statement from
> kconfig-language.rst could help somehow here.
>
I tried imply on various applications.? Nothing solved it.

Like you said the child devices select the common and majority rules on
how the COMMON is built.

The proposed fix will only block building the MC as a module if the
COMMON and children are modules.

Dan


2020-06-19 16:39:07

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>> Jacek
>>>
>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>> Dan,
>>>>
>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>> Jacek
>>>>>
>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>> Dan,
>>>>>>
>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>> Pavel/Jacek
>>>>>>>
>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>> Hi Dan,
>>>>>>>>
>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>
>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>> [if your patch is applied to the wrong git tree, please drop us
>>>>>>>> a note to help
>>>>>>>> improve the system. BTW, we also suggest to use '--base' option
>>>>>>>> to specify the
>>>>>>>> base tree in git format-patch, please see
>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>
>>>>>>>> url:
>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>
>>>>>>>> base:
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>> for-next
>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>> ???????? wget
>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>> -O ~/bin/make.cross
>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>>> make.cross ARCH=ia64
>>>>>>>>
>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>
>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>
>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>>>>>> `led_mc_calc_color_components'
>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined reference
>>>>>>>>>> to `devm_led_classdev_multicolor_register_ext'
>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>
>>>>>>>> ??? 138
>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>> led_classdev *cdev,
>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>> ??? 141??? {
>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>>>>>> ??? 145
>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>> ??? 148
>>>>>>>
>>>>>>> Well this was a mess to figure out.
>>>>>>>
>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>
>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>>
>>>>>>> from each child device and add
>>>>>>>
>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>
>>>>>>> to the LP55XX_COMMON
>>>>>>>
>>>>>>> This way the Multi color framework will inherit the symbol that
>>>>>>> was set by the COMMON flag which is inherited by majority from
>>>>>>> the child flags.
>>>>>>
>>>>>> Did you try this?
>>>>>>
>>>>>> --- a/drivers/leds/Kconfig
>>>>>> +++ b/drivers/leds/Kconfig
>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>> LP5521/5523/55231/5562/8501"
>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>>>> LEDS_LP8501
>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>> ??????? depends on OF
>>>>>> ??????? select FW_LOADER
>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>
>>>>>>
>>>>> Yes I did
>>>>>
>>>>> That gave unmet dependencies.
>>>>>
>>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) &&
>>>>> OF [=y]
>>>>> ?? Selected by [y]:
>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>>> ?? Selected by [m]:
>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>> [=y] && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>
>>>>
>>>> When I was testing that yesterday I also had the same warning at some
>>>> point of testing different Kconfig setups, but with what I showed
>>>> above
>>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>>>> from the test bot.
>>>>
>>> That is not what I saw in my testing especially after doing a distclean
>>
>> Could you please give your exact steps after "make distclean" and
>> copying test bot config to the kernel root directory?
>>
>> Also, please share the toolchain you're using for tests.
>
> Actually at this stage the toolchain is of lesser relevance.
>
> I've tried once more and indeed the problem shows up.
>
> It is caused by the driver entries doing
>
> "select LEDS_LP55XX_COMMON".
>
> Select sets config to "y" so it conflicts with
> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
> in the "config LEDS_LP55XX_COMMON".
>
> Your proposed fix will block the possibility of building
> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
> are enabled so this is also not an option.
>
> Solving this riddle will require some more thinking.
> I haven't analyzed it in detail but maybe "imply" statement from
> kconfig-language.rst could help somehow here.

The multicolor framework will build as a module if the LED_CLASS is
defined as a module.

See attached test_defconfig

defconfig contents

CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_CLASS_MULTI_COLOR=m
CONFIG_LEDS_LP50XX=m
CONFIG_LEDS_LP55XX_COMMON=y
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_LP5562=m
CONFIG_LEDS_LP8501=m

Output is

CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_CLASS_MULTI_COLOR=m
CONFIG_LEDS_LP50XX=m
CONFIG_LEDS_LP55XX_COMMON=m
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_LP5562=m
CONFIG_LEDS_LP8501=m

If any of the children are built in then the MC framework must be built
in as well.

Dan



Attachments:
test_defconfig (107.13 kB)

2020-06-20 04:54:03

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Dan,

On 6/19/20 6:35 PM, Dan Murphy wrote:
> Jacek
>
> On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
>> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>>> Jacek
>>>>
>>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>>> Dan,
>>>>>
>>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>>> Jacek
>>>>>>
>>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>>> Dan,
>>>>>>>
>>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>>> Pavel/Jacek
>>>>>>>>
>>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>>> Hi Dan,
>>>>>>>>>
>>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>>
>>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>>> [if your patch is applied to the wrong git tree, please drop us
>>>>>>>>> a note to help
>>>>>>>>> improve the system. BTW, we also suggest to use '--base' option
>>>>>>>>> to specify the
>>>>>>>>> base tree in git format-patch, please see
>>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>>
>>>>>>>>> url:
>>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>>
>>>>>>>>> base:
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>>> for-next
>>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>>> ???????? wget
>>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>>> -O ~/bin/make.cross
>>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>>>> make.cross ARCH=ia64
>>>>>>>>>
>>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>>
>>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>>
>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference to
>>>>>>>>>>> `led_mc_calc_color_components'
>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined reference
>>>>>>>>>>> to `devm_led_classdev_multicolor_register_ext'
>>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>>
>>>>>>>>> ??? 138
>>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>>> led_classdev *cdev,
>>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>>> ??? 141??? {
>>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>>> ??? 143??????? struct lp55xx_led *led = mcled_cdev_to_led(mc_dev);
>>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg = led->chip->cfg;
>>>>>>>>> ??? 145
>>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>>> ??? 148
>>>>>>>>
>>>>>>>> Well this was a mess to figure out.
>>>>>>>>
>>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>>
>>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>>>
>>>>>>>> from each child device and add
>>>>>>>>
>>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>>
>>>>>>>> to the LP55XX_COMMON
>>>>>>>>
>>>>>>>> This way the Multi color framework will inherit the symbol that
>>>>>>>> was set by the COMMON flag which is inherited by majority from
>>>>>>>> the child flags.
>>>>>>>
>>>>>>> Did you try this?
>>>>>>>
>>>>>>> --- a/drivers/leds/Kconfig
>>>>>>> +++ b/drivers/leds/Kconfig
>>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>>> LP5521/5523/55231/5562/8501"
>>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>>>>> LEDS_LP8501
>>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>> ??????? depends on OF
>>>>>>> ??????? select FW_LOADER
>>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>>
>>>>>>>
>>>>>> Yes I did
>>>>>>
>>>>>> That gave unmet dependencies.
>>>>>>
>>>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) &&
>>>>>> OF [=y]
>>>>>> ?? Selected by [y]:
>>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C [=y]
>>>>>> ?? Selected by [m]:
>>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>> [=y] && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>
>>>>>
>>>>> When I was testing that yesterday I also had the same warning at some
>>>>> point of testing different Kconfig setups, but with what I showed
>>>>> above
>>>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>>>>> from the test bot.
>>>>>
>>>> That is not what I saw in my testing especially after doing a distclean
>>>
>>> Could you please give your exact steps after "make distclean" and
>>> copying test bot config to the kernel root directory?
>>>
>>> Also, please share the toolchain you're using for tests.
>>
>> Actually at this stage the toolchain is of lesser relevance.
>>
>> I've tried once more and indeed the problem shows up.
>>
>> It is caused by the driver entries doing
>>
>> "select LEDS_LP55XX_COMMON".
>>
>> Select sets config to "y" so it conflicts with
>> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
>> in the "config LEDS_LP55XX_COMMON".
>>
>> Your proposed fix will block the possibility of building
>> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
>> are enabled so this is also not an option.
>>
>> Solving this riddle will require some more thinking.
>> I haven't analyzed it in detail but maybe "imply" statement from
>> kconfig-language.rst could help somehow here.
>
> The multicolor framework will build as a module if the LED_CLASS is
> defined as a module.
>
> See attached test_defconfig

But it will be impossible to enable CONFIG_LEDS_LP50XX without
CONFIG_LEDS_CLASS_MULTI_COLOR if you will remove

depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR.

This is actually why the above entry was needed.

LP55XX drivers have to work also without multicolor class.

>
> defconfig contents
>
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_CLASS_MULTI_COLOR=m
> CONFIG_LEDS_LP50XX=m
> CONFIG_LEDS_LP55XX_COMMON=y
> CONFIG_LEDS_LP5523=m
> CONFIG_LEDS_LP5562=m
> CONFIG_LEDS_LP8501=m
>
> Output is
>
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_CLASS_MULTI_COLOR=m
> CONFIG_LEDS_LP50XX=m
> CONFIG_LEDS_LP55XX_COMMON=m
> CONFIG_LEDS_LP5523=m
> CONFIG_LEDS_LP5562=m
> CONFIG_LEDS_LP8501=m
>
> If any of the children are built in then the MC framework must be built
> in as well.
>
> Dan
>
>

--
Best regards,
Jacek Anaszewski

2020-06-21 14:17:53

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/19/20 6:35 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
>>> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>>>> Dan,
>>>>
>>>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>>>> Jacek
>>>>>
>>>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>>>> Dan,
>>>>>>
>>>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>>>> Jacek
>>>>>>>
>>>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>>>> Dan,
>>>>>>>>
>>>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>>>> Pavel/Jacek
>>>>>>>>>
>>>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>>>> Hi Dan,
>>>>>>>>>>
>>>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>>>
>>>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>>>> [if your patch is applied to the wrong git tree, please drop
>>>>>>>>>> us a note to help
>>>>>>>>>> improve the system. BTW, we also suggest to use '--base'
>>>>>>>>>> option to specify the
>>>>>>>>>> base tree in git format-patch, please see
>>>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>>>
>>>>>>>>>> url:
>>>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>>>
>>>>>>>>>> base:
>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>>>> for-next
>>>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>>>> ???????? wget
>>>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>>>> -O ~/bin/make.cross
>>>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>>>>> make.cross ARCH=ia64
>>>>>>>>>>
>>>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>>>
>>>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>>>
>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference
>>>>>>>>>>>> to `led_mc_calc_color_components'
>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined
>>>>>>>>>>>> reference to `devm_led_classdev_multicolor_register_ext'
>>>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>>>
>>>>>>>>>> ??? 138
>>>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>>>> led_classdev *cdev,
>>>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>>>> ??? 141??? {
>>>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>>>> ??? 143??????? struct lp55xx_led *led =
>>>>>>>>>> mcled_cdev_to_led(mc_dev);
>>>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg =
>>>>>>>>>> led->chip->cfg;
>>>>>>>>>> ??? 145
>>>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>>>> ??? 148
>>>>>>>>>
>>>>>>>>> Well this was a mess to figure out.
>>>>>>>>>
>>>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>>>
>>>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>
>>>>>>>>> from each child device and add
>>>>>>>>>
>>>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>>>
>>>>>>>>> to the LP55XX_COMMON
>>>>>>>>>
>>>>>>>>> This way the Multi color framework will inherit the symbol
>>>>>>>>> that was set by the COMMON flag which is inherited by majority
>>>>>>>>> from the child flags.
>>>>>>>>
>>>>>>>> Did you try this?
>>>>>>>>
>>>>>>>> --- a/drivers/leds/Kconfig
>>>>>>>> +++ b/drivers/leds/Kconfig
>>>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>>>> LP5521/5523/55231/5562/8501"
>>>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>>>>>> LEDS_LP8501
>>>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>> ??????? depends on OF
>>>>>>>> ??????? select FW_LOADER
>>>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>>>
>>>>>>>>
>>>>>>> Yes I did
>>>>>>>
>>>>>>> That gave unmet dependencies.
>>>>>>>
>>>>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) &&
>>>>>>> OF [=y]
>>>>>>> ?? Selected by [y]:
>>>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>>> [=y]
>>>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>>> [=y]
>>>>>>> ?? Selected by [m]:
>>>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>>> [=y] && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR
>>>>>>> [=m])
>>>>>>>
>>>>>>
>>>>>> When I was testing that yesterday I also had the same warning at
>>>>>> some
>>>>>> point of testing different Kconfig setups, but with what I showed
>>>>>> above
>>>>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>>>>>> from the test bot.
>>>>>>
>>>>> That is not what I saw in my testing especially after doing a
>>>>> distclean
>>>>
>>>> Could you please give your exact steps after "make distclean" and
>>>> copying test bot config to the kernel root directory?
>>>>
>>>> Also, please share the toolchain you're using for tests.
>>>
>>> Actually at this stage the toolchain is of lesser relevance.
>>>
>>> I've tried once more and indeed the problem shows up.
>>>
>>> It is caused by the driver entries doing
>>>
>>> "select LEDS_LP55XX_COMMON".
>>>
>>> Select sets config to "y" so it conflicts with
>>> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
>>> in the "config LEDS_LP55XX_COMMON".
>>>
>>> Your proposed fix will block the possibility of building
>>> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
>>> are enabled so this is also not an option.
>>>
>>> Solving this riddle will require some more thinking.
>>> I haven't analyzed it in detail but maybe "imply" statement from
>>> kconfig-language.rst could help somehow here.
>>
>> The multicolor framework will build as a module if the LED_CLASS is
>> defined as a module.
>>
>> See attached test_defconfig
>
> But it will be impossible to enable CONFIG_LEDS_LP50XX without
> CONFIG_LEDS_CLASS_MULTI_COLOR if you will remove
>
> depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR.
>
I was not removing the dependency for the LP50xx only the LP55xx.


> This is actually why the above entry was needed.
>
> LP55XX drivers have to work also without multicolor class.
>
Well I am not sure how else to resolve this problem.? Because the LP55xx
has multi level dependencies.

Only the LP55xx_common has the dependency on the MC framework. The
device drivers do not.

The issue is the mixing and matching of the MC fw as a module vs the
LP55XX_COMMON as a built-in.

Dan

2020-06-21 20:27:08

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Dan,

On 6/21/20 4:12 PM, Dan Murphy wrote:
> Jacek
>
> On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 6/19/20 6:35 PM, Dan Murphy wrote:
>>> Jacek
>>>
>>> On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
>>>> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>>>>> Dan,
>>>>>
>>>>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>>>>> Jacek
>>>>>>
>>>>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>>>>> Dan,
>>>>>>>
>>>>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>>>>> Jacek
>>>>>>>>
>>>>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>>>>> Dan,
>>>>>>>>>
>>>>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>>>>> Pavel/Jacek
>>>>>>>>>>
>>>>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>
>>>>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>>>>
>>>>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>>>>> [if your patch is applied to the wrong git tree, please drop
>>>>>>>>>>> us a note to help
>>>>>>>>>>> improve the system. BTW, we also suggest to use '--base'
>>>>>>>>>>> option to specify the
>>>>>>>>>>> base tree in git format-patch, please see
>>>>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>>>>
>>>>>>>>>>> url:
>>>>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>>>>
>>>>>>>>>>> base:
>>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>>>>> for-next
>>>>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>>>>> ???????? wget
>>>>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>>>>> -O ~/bin/make.cross
>>>>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>>>>>> make.cross ARCH=ia64
>>>>>>>>>>>
>>>>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>>>>
>>>>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>>>>
>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>>>>> `lp55xx_set_mc_brightness':
>>>>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference
>>>>>>>>>>>>> to `led_mc_calc_color_components'
>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in function
>>>>>>>>>>> `devm_led_classdev_multicolor_register':
>>>>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined
>>>>>>>>>>>>> reference to `devm_led_classdev_multicolor_register_ext'
>>>>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>>>>
>>>>>>>>>>> ??? 138
>>>>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>>>>> led_classdev *cdev,
>>>>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>>>>> ??? 141??? {
>>>>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>>>>> ??? 143??????? struct lp55xx_led *led =
>>>>>>>>>>> mcled_cdev_to_led(mc_dev);
>>>>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg =
>>>>>>>>>>> led->chip->cfg;
>>>>>>>>>>> ??? 145
>>>>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev, brightness);
>>>>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>>>>> ??? 148
>>>>>>>>>>
>>>>>>>>>> Well this was a mess to figure out.
>>>>>>>>>>
>>>>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>>>>
>>>>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>
>>>>>>>>>> from each child device and add
>>>>>>>>>>
>>>>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>
>>>>>>>>>> to the LP55XX_COMMON
>>>>>>>>>>
>>>>>>>>>> This way the Multi color framework will inherit the symbol
>>>>>>>>>> that was set by the COMMON flag which is inherited by majority
>>>>>>>>>> from the child flags.
>>>>>>>>>
>>>>>>>>> Did you try this?
>>>>>>>>>
>>>>>>>>> --- a/drivers/leds/Kconfig
>>>>>>>>> +++ b/drivers/leds/Kconfig
>>>>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>>>>> LP5521/5523/55231/5562/8501"
>>>>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
>>>>>>>>> LEDS_LP8501
>>>>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>> ??????? depends on OF
>>>>>>>>> ??????? select FW_LOADER
>>>>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Yes I did
>>>>>>>>
>>>>>>>> That gave unmet dependencies.
>>>>>>>>
>>>>>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m]) &&
>>>>>>>> OF [=y]
>>>>>>>> ?? Selected by [y]:
>>>>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>>>> [=y]
>>>>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>>>> [=y]
>>>>>>>> ?? Selected by [m]:
>>>>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] && I2C
>>>>>>>> [=y] && (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR
>>>>>>>> [=m])
>>>>>>>>
>>>>>>>
>>>>>>> When I was testing that yesterday I also had the same warning at
>>>>>>> some
>>>>>>> point of testing different Kconfig setups, but with what I showed
>>>>>>> above
>>>>>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>>>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the config
>>>>>>> from the test bot.
>>>>>>>
>>>>>> That is not what I saw in my testing especially after doing a
>>>>>> distclean
>>>>>
>>>>> Could you please give your exact steps after "make distclean" and
>>>>> copying test bot config to the kernel root directory?
>>>>>
>>>>> Also, please share the toolchain you're using for tests.
>>>>
>>>> Actually at this stage the toolchain is of lesser relevance.
>>>>
>>>> I've tried once more and indeed the problem shows up.
>>>>
>>>> It is caused by the driver entries doing
>>>>
>>>> "select LEDS_LP55XX_COMMON".
>>>>
>>>> Select sets config to "y" so it conflicts with
>>>> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
>>>> in the "config LEDS_LP55XX_COMMON".
>>>>
>>>> Your proposed fix will block the possibility of building
>>>> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
>>>> are enabled so this is also not an option.
>>>>
>>>> Solving this riddle will require some more thinking.
>>>> I haven't analyzed it in detail but maybe "imply" statement from
>>>> kconfig-language.rst could help somehow here.
>>>
>>> The multicolor framework will build as a module if the LED_CLASS is
>>> defined as a module.
>>>
>>> See attached test_defconfig
>>
>> But it will be impossible to enable CONFIG_LEDS_LP50XX without
>> CONFIG_LEDS_CLASS_MULTI_COLOR if you will remove
>>
>> depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR.
>>
> I was not removing the dependency for the LP50xx only the LP55xx.

It was my typo, I meant LP55XX.

>
>> This is actually why the above entry was needed.
>>
>> LP55XX drivers have to work also without multicolor class.
>>
> Well I am not sure how else to resolve this problem.? Because the LP55xx
> has multi level dependencies.
>
> Only the LP55xx_common has the dependency on the MC framework. The
> device drivers do not.
>
> The issue is the mixing and matching of the MC fw as a module vs the
> LP55XX_COMMON as a built-in.

The simplest solution is to avoid selecting LP55XX_COMMON in favor
of making child drivers depending on it. Of course, maybe there exists
some trickier option to keep the selection, but I would have to play
a bit more with it to be sure.

--
Best regards,
Jacek Anaszewski

2020-06-22 12:47:32

by Jacek Anaszewski

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Dan,

On 6/21/20 10:24 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/21/20 4:12 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 6/19/20 6:35 PM, Dan Murphy wrote:
>>>> Jacek
>>>>
>>>> On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
>>>>> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>>>>>> Dan,
>>>>>>
>>>>>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>>>>>> Jacek
>>>>>>>
>>>>>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>>>>>> Dan,
>>>>>>>>
>>>>>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>>>>>> Jacek
>>>>>>>>>
>>>>>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>>>>>> Dan,
>>>>>>>>>>
>>>>>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>>>>>> Pavel/Jacek
>>>>>>>>>>>
>>>>>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>>
>>>>>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>>>>>
>>>>>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>>>>>> [if your patch is applied to the wrong git tree, please drop
>>>>>>>>>>>> us a note to help
>>>>>>>>>>>> improve the system. BTW, we also suggest to use '--base'
>>>>>>>>>>>> option to specify the
>>>>>>>>>>>> base tree in git format-patch, please see
>>>>>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>>>>>
>>>>>>>>>>>> url:
>>>>>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>>>>>
>>>>>>>>>>>> base:
>>>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>>>>>> for-next
>>>>>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>>>>>> ???????? wget
>>>>>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>>>>>> -O ~/bin/make.cross
>>>>>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0
>>>>>>>>>>>> make.cross ARCH=ia64
>>>>>>>>>>>>
>>>>>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>>>>>
>>>>>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>>>>>
>>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in
>>>>>>>>>>>> function `lp55xx_set_mc_brightness':
>>>>>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined reference
>>>>>>>>>>>>>> to `led_mc_calc_color_components'
>>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in
>>>>>>>>>>>> function `devm_led_classdev_multicolor_register':
>>>>>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined
>>>>>>>>>>>>>> reference to `devm_led_classdev_multicolor_register_ext'
>>>>>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>>>>>
>>>>>>>>>>>> ??? 138
>>>>>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>>>>>> led_classdev *cdev,
>>>>>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>>>>>> ??? 141??? {
>>>>>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>>>>>> ??? 143??????? struct lp55xx_led *led =
>>>>>>>>>>>> mcled_cdev_to_led(mc_dev);
>>>>>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg =
>>>>>>>>>>>> led->chip->cfg;
>>>>>>>>>>>> ??? 145
>>>>>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev,
>>>>>>>>>>>> brightness);
>>>>>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>>>>>> ??? 148
>>>>>>>>>>>
>>>>>>>>>>> Well this was a mess to figure out.
>>>>>>>>>>>
>>>>>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>>>>>
>>>>>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>>
>>>>>>>>>>> from each child device and add
>>>>>>>>>>>
>>>>>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>>
>>>>>>>>>>> to the LP55XX_COMMON
>>>>>>>>>>>
>>>>>>>>>>> This way the Multi color framework will inherit the symbol
>>>>>>>>>>> that was set by the COMMON flag which is inherited by
>>>>>>>>>>> majority from the child flags.
>>>>>>>>>>
>>>>>>>>>> Did you try this?
>>>>>>>>>>
>>>>>>>>>> --- a/drivers/leds/Kconfig
>>>>>>>>>> +++ b/drivers/leds/Kconfig
>>>>>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>>>>>> LP5521/5523/55231/5562/8501"
>>>>>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562
>>>>>>>>>> || LEDS_LP8501
>>>>>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>> ??????? depends on OF
>>>>>>>>>> ??????? select FW_LOADER
>>>>>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Yes I did
>>>>>>>>>
>>>>>>>>> That gave unmet dependencies.
>>>>>>>>>
>>>>>>>>> WARNING: unmet direct dependencies detected for LEDS_LP55XX_COMMON
>>>>>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>>>> && OF [=y]
>>>>>>>>> ?? Selected by [y]:
>>>>>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>> I2C [=y]
>>>>>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>> I2C [=y]
>>>>>>>>> ?? Selected by [m]:
>>>>>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>> I2C [=y] && (LEDS_CLASS_MULTI_COLOR [=m] ||
>>>>>>>>> !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>>>>
>>>>>>>>
>>>>>>>> When I was testing that yesterday I also had the same warning at
>>>>>>>> some
>>>>>>>> point of testing different Kconfig setups, but with what I
>>>>>>>> showed above
>>>>>>>> it ceased to appear. Now every time I am doing "make oldconfig" the
>>>>>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the
>>>>>>>> config
>>>>>>>> from the test bot.
>>>>>>>>
>>>>>>> That is not what I saw in my testing especially after doing a
>>>>>>> distclean
>>>>>>
>>>>>> Could you please give your exact steps after "make distclean" and
>>>>>> copying test bot config to the kernel root directory?
>>>>>>
>>>>>> Also, please share the toolchain you're using for tests.
>>>>>
>>>>> Actually at this stage the toolchain is of lesser relevance.
>>>>>
>>>>> I've tried once more and indeed the problem shows up.
>>>>>
>>>>> It is caused by the driver entries doing
>>>>>
>>>>> "select LEDS_LP55XX_COMMON".
>>>>>
>>>>> Select sets config to "y" so it conflicts with
>>>>> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
>>>>> in the "config LEDS_LP55XX_COMMON".
>>>>>
>>>>> Your proposed fix will block the possibility of building
>>>>> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
>>>>> are enabled so this is also not an option.
>>>>>
>>>>> Solving this riddle will require some more thinking.
>>>>> I haven't analyzed it in detail but maybe "imply" statement from
>>>>> kconfig-language.rst could help somehow here.
>>>>
>>>> The multicolor framework will build as a module if the LED_CLASS is
>>>> defined as a module.
>>>>
>>>> See attached test_defconfig
>>>
>>> But it will be impossible to enable CONFIG_LEDS_LP50XX without
>>> CONFIG_LEDS_CLASS_MULTI_COLOR if you will remove
>>>
>>> depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR.
>>>
>> I was not removing the dependency for the LP50xx only the LP55xx.
>
> It was my typo, I meant LP55XX.
>
>>
>>> This is actually why the above entry was needed.
>>>
>>> LP55XX drivers have to work also without multicolor class.
>>>
>> Well I am not sure how else to resolve this problem.? Because the
>> LP55xx has multi level dependencies.
>>
>> Only the LP55xx_common has the dependency on the MC framework. The
>> device drivers do not.
>>
>> The issue is the mixing and matching of the MC fw as a module vs the
>> LP55XX_COMMON as a built-in.
>
> The simplest solution is to avoid selecting LP55XX_COMMON in favor
> of making child drivers depending on it. Of course, maybe there exists
> some trickier option to keep the selection, but I would have to play
> a bit more with it to be sure.

Yep, this seems to be the only viable solution.

My proposed change to the Kconfig:

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index adfa762cb291..10de7d237ffd 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -397,10 +397,10 @@ config LEDS_LP50XX

config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National
LP5521/5523/55231/5562/8501"
- depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
depends on OF
select FW_LOADER
select FW_LOADER_USER_HELPER
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
help
This option supports common operations for
LP5521/5523/55231/5562/8501
devices.
@@ -408,8 +408,7 @@ config LEDS_LP55XX_COMMON
config LEDS_LP5521
tristate "LED Support for N.S. LP5521 LED driver chip"
depends on LEDS_CLASS && I2C
- depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
- select LEDS_LP55XX_COMMON
+ depends on LEDS_LP55XX_COMMON
help
If you say yes here you get support for the National
Semiconductor
LP5521 LED driver. It is 3 channel chip with programmable
engines.
@@ -419,8 +418,7 @@ config LEDS_LP5521
config LEDS_LP5523
tristate "LED Support for TI/National LP5523/55231 LED driver chip"
depends on LEDS_CLASS && I2C
- depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
- select LEDS_LP55XX_COMMON
+ depends on LEDS_LP55XX_COMMON
help
If you say yes here you get support for TI/National Semiconductor
LP5523/55231 LED driver.
@@ -431,7 +429,7 @@ config LEDS_LP5523
config LEDS_LP5562
tristate "LED Support for TI LP5562 LED driver chip"
depends on LEDS_CLASS && I2C
- select LEDS_LP55XX_COMMON
+ depends on LEDS_LP55XX_COMMON
help
If you say yes here you get support for TI LP5562 LED driver.
It is 4 channels chip with programmable engines.
@@ -441,7 +439,7 @@ config LEDS_LP5562
config LEDS_LP8501
tristate "LED Support for TI LP8501 LED driver chip"
depends on LEDS_CLASS && I2C
- select LEDS_LP55XX_COMMON
+ depends on LEDS_LP55XX_COMMON
help
If you say yes here you get support for TI LP8501 LED driver.
It is 9 channel chip with programmable engines.


--
Best regards,
Jacek Anaszewski

2020-06-22 12:47:36

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/22/20 7:42 AM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/21/20 10:24 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 6/21/20 4:12 PM, Dan Murphy wrote:
>>> Jacek
>>>
>>> On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
>>>> Dan,
>>>>
>>>> On 6/19/20 6:35 PM, Dan Murphy wrote:
>>>>> Jacek
>>>>>
>>>>> On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
>>>>>> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>>>>>>> Dan,
>>>>>>>
>>>>>>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>>>>>>> Jacek
>>>>>>>>
>>>>>>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>>>>>>> Dan,
>>>>>>>>>
>>>>>>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>>>>>>> Jacek
>>>>>>>>>>
>>>>>>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>>>>>>> Dan,
>>>>>>>>>>>
>>>>>>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>>>>>>> Pavel/Jacek
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>>>>>>> [if your patch is applied to the wrong git tree, please
>>>>>>>>>>>>> drop us a note to help
>>>>>>>>>>>>> improve the system. BTW, we also suggest to use '--base'
>>>>>>>>>>>>> option to specify the
>>>>>>>>>>>>> base tree in git format-patch, please see
>>>>>>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>>>>>>
>>>>>>>>>>>>> url:
>>>>>>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>>>>>>
>>>>>>>>>>>>> base:
>>>>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>>>>>>> for-next
>>>>>>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>>>>>>> ???????? wget
>>>>>>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>>>>>>> -O ~/bin/make.cross
>>>>>>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day
>>>>>>>>>>>>> COMPILER=gcc-9.3.0 make.cross ARCH=ia64
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>>>>>>
>>>>>>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by
>>>>>>>>>>>>> <<):
>>>>>>>>>>>>>
>>>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in
>>>>>>>>>>>>> function `lp55xx_set_mc_brightness':
>>>>>>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined
>>>>>>>>>>>>>>> reference to `led_mc_calc_color_components'
>>>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in
>>>>>>>>>>>>> function `devm_led_classdev_multicolor_register':
>>>>>>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined
>>>>>>>>>>>>>>> reference to `devm_led_classdev_multicolor_register_ext'
>>>>>>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>>>>>>
>>>>>>>>>>>>> ??? 138
>>>>>>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>>>>>>> led_classdev *cdev,
>>>>>>>>>>>>> ??? 140??????????????????????? enum led_brightness
>>>>>>>>>>>>> brightness)
>>>>>>>>>>>>> ??? 141??? {
>>>>>>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>>>>>>> ??? 143??????? struct lp55xx_led *led =
>>>>>>>>>>>>> mcled_cdev_to_led(mc_dev);
>>>>>>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg =
>>>>>>>>>>>>> led->chip->cfg;
>>>>>>>>>>>>> ??? 145
>>>>>>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev,
>>>>>>>>>>>>> brightness);
>>>>>>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>>>>>>> ??? 148
>>>>>>>>>>>>
>>>>>>>>>>>> Well this was a mess to figure out.
>>>>>>>>>>>>
>>>>>>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>>>>>>
>>>>>>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>>>
>>>>>>>>>>>> from each child device and add
>>>>>>>>>>>>
>>>>>>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>>>
>>>>>>>>>>>> to the LP55XX_COMMON
>>>>>>>>>>>>
>>>>>>>>>>>> This way the Multi color framework will inherit the symbol
>>>>>>>>>>>> that was set by the COMMON flag which is inherited by
>>>>>>>>>>>> majority from the child flags.
>>>>>>>>>>>
>>>>>>>>>>> Did you try this?
>>>>>>>>>>>
>>>>>>>>>>> --- a/drivers/leds/Kconfig
>>>>>>>>>>> +++ b/drivers/leds/Kconfig
>>>>>>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>>>>>>> LP5521/5523/55231/5562/8501"
>>>>>>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562
>>>>>>>>>>> || LEDS_LP8501
>>>>>>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>> ??????? depends on OF
>>>>>>>>>>> ??????? select FW_LOADER
>>>>>>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Yes I did
>>>>>>>>>>
>>>>>>>>>> That gave unmet dependencies.
>>>>>>>>>>
>>>>>>>>>> WARNING: unmet direct dependencies detected for
>>>>>>>>>> LEDS_LP55XX_COMMON
>>>>>>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>>>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>>>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>>>>> && OF [=y]
>>>>>>>>>> ?? Selected by [y]:
>>>>>>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>>> I2C [=y]
>>>>>>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>>> I2C [=y]
>>>>>>>>>> ?? Selected by [m]:
>>>>>>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>>> I2C [=y] && (LEDS_CLASS_MULTI_COLOR [=m] ||
>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When I was testing that yesterday I also had the same warning
>>>>>>>>> at some
>>>>>>>>> point of testing different Kconfig setups, but with what I
>>>>>>>>> showed above
>>>>>>>>> it ceased to appear. Now every time I am doing "make
>>>>>>>>> oldconfig" the
>>>>>>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the
>>>>>>>>> config
>>>>>>>>> from the test bot.
>>>>>>>>>
>>>>>>>> That is not what I saw in my testing especially after doing a
>>>>>>>> distclean
>>>>>>>
>>>>>>> Could you please give your exact steps after "make distclean" and
>>>>>>> copying test bot config to the kernel root directory?
>>>>>>>
>>>>>>> Also, please share the toolchain you're using for tests.
>>>>>>
>>>>>> Actually at this stage the toolchain is of lesser relevance.
>>>>>>
>>>>>> I've tried once more and indeed the problem shows up.
>>>>>>
>>>>>> It is caused by the driver entries doing
>>>>>>
>>>>>> "select LEDS_LP55XX_COMMON".
>>>>>>
>>>>>> Select sets config to "y" so it conflicts with
>>>>>> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
>>>>>> in the "config LEDS_LP55XX_COMMON".
>>>>>>
>>>>>> Your proposed fix will block the possibility of building
>>>>>> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
>>>>>> are enabled so this is also not an option.
>>>>>>
>>>>>> Solving this riddle will require some more thinking.
>>>>>> I haven't analyzed it in detail but maybe "imply" statement from
>>>>>> kconfig-language.rst could help somehow here.
>>>>>
>>>>> The multicolor framework will build as a module if the LED_CLASS
>>>>> is defined as a module.
>>>>>
>>>>> See attached test_defconfig
>>>>
>>>> But it will be impossible to enable CONFIG_LEDS_LP50XX without
>>>> CONFIG_LEDS_CLASS_MULTI_COLOR if you will remove
>>>>
>>>> depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR.
>>>>
>>> I was not removing the dependency for the LP50xx only the LP55xx.
>>
>> It was my typo, I meant LP55XX.
>>
>>>
>>>> This is actually why the above entry was needed.
>>>>
>>>> LP55XX drivers have to work also without multicolor class.
>>>>
>>> Well I am not sure how else to resolve this problem.? Because the
>>> LP55xx has multi level dependencies.
>>>
>>> Only the LP55xx_common has the dependency on the MC framework. The
>>> device drivers do not.
>>>
>>> The issue is the mixing and matching of the MC fw as a module vs the
>>> LP55XX_COMMON as a built-in.
>>
>> The simplest solution is to avoid selecting LP55XX_COMMON in favor
>> of making child drivers depending on it. Of course, maybe there exists
>> some trickier option to keep the selection, but I would have to play
>> a bit more with it to be sure.
>
> Yep, this seems to be the only viable solution.
>
> My proposed change to the Kconfig:
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index adfa762cb291..10de7d237ffd 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -397,10 +397,10 @@ config LEDS_LP50XX
>
> ?config LEDS_LP55XX_COMMON
> ??????? tristate "Common Driver for TI/National
> LP5521/5523/55231/5562/8501"
> -?????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 ||
> LEDS_LP8501
> ??????? depends on OF
> ??????? select FW_LOADER
> ??????? select FW_LOADER_USER_HELPER
> +?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
> ??????? help
> ????????? This option supports common operations for
> LP5521/5523/55231/5562/8501
> ????????? devices.
> @@ -408,8 +408,7 @@ config LEDS_LP55XX_COMMON
> ?config LEDS_LP5521
> ??????? tristate "LED Support for N.S. LP5521 LED driver chip"
> ??????? depends on LEDS_CLASS && I2C
> -?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
> -?????? select LEDS_LP55XX_COMMON
> +?????? depends on LEDS_LP55XX_COMMON
> ??????? help
> ????????? If you say yes here you get support for the National
> Semiconductor
> ????????? LP5521 LED driver. It is 3 channel chip with programmable
> engines.
> @@ -419,8 +418,7 @@ config LEDS_LP5521
> ?config LEDS_LP5523
> ??????? tristate "LED Support for TI/National LP5523/55231 LED driver
> chip"
> ??????? depends on LEDS_CLASS && I2C
> -?????? depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
> -?????? select LEDS_LP55XX_COMMON
> +?????? depends on LEDS_LP55XX_COMMON
> ??????? help
> ????????? If you say yes here you get support for TI/National
> Semiconductor
> ????????? LP5523/55231 LED driver.
> @@ -431,7 +429,7 @@ config LEDS_LP5523
> ?config LEDS_LP5562
> ??????? tristate "LED Support for TI LP5562 LED driver chip"
> ??????? depends on LEDS_CLASS && I2C
> -?????? select LEDS_LP55XX_COMMON
> +?????? depends on LEDS_LP55XX_COMMON
> ??????? help
> ????????? If you say yes here you get support for TI LP5562 LED driver.
> ????????? It is 4 channels chip with programmable engines.
> @@ -441,7 +439,7 @@ config LEDS_LP5562
> ?config LEDS_LP8501
> ??????? tristate "LED Support for TI LP8501 LED driver chip"
> ??????? depends on LEDS_CLASS && I2C
> -?????? select LEDS_LP55XX_COMMON
> +?????? depends on LEDS_LP55XX_COMMON
> ??????? help
> ????????? If you say yes here you get support for TI LP8501 LED driver.
> ????????? It is 9 channel chip with programmable engines.
>
>
I made the same exact change and I am testing this now.? Need to see how
the u8500_defconfig builds as that is the only defconfig that uses the
LP5521 in tree.

I will need to add the LP55XX_COMMON in that defconfig but verifying the
build works once I do.

Dan

2020-06-22 13:07:34

by Dan Murphy

[permalink] [raw]
Subject: Re: [RESEND PATCH v27 11/15] leds: lp55xx: Add multicolor framework support to lp55xx

Jacek

On 6/21/20 3:24 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 6/21/20 4:12 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 6/19/20 5:10 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 6/19/20 6:35 PM, Dan Murphy wrote:
>>>> Jacek
>>>>
>>>> On 6/18/20 6:26 PM, Jacek Anaszewski wrote:
>>>>> On 6/19/20 12:09 AM, Jacek Anaszewski wrote:
>>>>>> Dan,
>>>>>>
>>>>>> On 6/18/20 11:44 PM, Dan Murphy wrote:
>>>>>>> Jacek
>>>>>>>
>>>>>>> On 6/18/20 4:21 PM, Jacek Anaszewski wrote:
>>>>>>>> Dan,
>>>>>>>>
>>>>>>>> On 6/18/20 12:33 AM, Dan Murphy wrote:
>>>>>>>>> Jacek
>>>>>>>>>
>>>>>>>>> On 6/17/20 4:41 PM, Jacek Anaszewski wrote:
>>>>>>>>>> Dan,
>>>>>>>>>>
>>>>>>>>>> On 6/17/20 9:22 PM, Dan Murphy wrote:
>>>>>>>>>>> Pavel/Jacek
>>>>>>>>>>>
>>>>>>>>>>> On 6/17/20 11:28 AM, kernel test robot wrote:
>>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>>
>>>>>>>>>>>> I love your patch! Yet something to improve:
>>>>>>>>>>>>
>>>>>>>>>>>> [auto build test ERROR on pavel-linux-leds/for-next]
>>>>>>>>>>>> [cannot apply to j.anaszewski-leds/for-next]
>>>>>>>>>>>> [if your patch is applied to the wrong git tree, please
>>>>>>>>>>>> drop us a note to help
>>>>>>>>>>>> improve the system. BTW, we also suggest to use '--base'
>>>>>>>>>>>> option to specify the
>>>>>>>>>>>> base tree in git format-patch, please see
>>>>>>>>>>>> https://stackoverflow.com/a/37406982]
>>>>>>>>>>>>
>>>>>>>>>>>> url:
>>>>>>>>>>>> https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v27/20200616-042217
>>>>>>>>>>>>
>>>>>>>>>>>> base:
>>>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git
>>>>>>>>>>>> for-next
>>>>>>>>>>>> config: ia64-randconfig-r015-20200617 (attached as .config)
>>>>>>>>>>>> compiler: ia64-linux-gcc (GCC) 9.3.0
>>>>>>>>>>>> reproduce (this is a W=1 build):
>>>>>>>>>>>> ???????? wget
>>>>>>>>>>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>>>>>>>>>>> -O ~/bin/make.cross
>>>>>>>>>>>> ???????? chmod +x ~/bin/make.cross
>>>>>>>>>>>> ???????? # save the attached .config to linux build tree
>>>>>>>>>>>> ???????? COMPILER_INSTALL_PATH=$HOME/0day
>>>>>>>>>>>> COMPILER=gcc-9.3.0 make.cross ARCH=ia64
>>>>>>>>>>>>
>>>>>>>>>>>> If you fix the issue, kindly add following tag as appropriate
>>>>>>>>>>>> Reported-by: kernel test robot <[email protected]>
>>>>>>>>>>>>
>>>>>>>>>>>> All errors (new ones prefixed by >>, old ones prefixed by <<):
>>>>>>>>>>>>
>>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in
>>>>>>>>>>>> function `lp55xx_set_mc_brightness':
>>>>>>>>>>>>>> drivers/leds/leds-lp55xx-common.c:146: undefined
>>>>>>>>>>>>>> reference to `led_mc_calc_color_components'
>>>>>>>>>>>> ia64-linux-ld: drivers/leds/leds-lp55xx-common.o: in
>>>>>>>>>>>> function `devm_led_classdev_multicolor_register':
>>>>>>>>>>>>>> include/linux/led-class-multicolor.h:74: undefined
>>>>>>>>>>>>>> reference to `devm_led_classdev_multicolor_register_ext'
>>>>>>>>>>>> vim +146 drivers/leds/leds-lp55xx-common.c
>>>>>>>>>>>>
>>>>>>>>>>>> ??? 138
>>>>>>>>>>>> ??? 139??? static int lp55xx_set_mc_brightness(struct
>>>>>>>>>>>> led_classdev *cdev,
>>>>>>>>>>>> ??? 140??????????????????????? enum led_brightness brightness)
>>>>>>>>>>>> ??? 141??? {
>>>>>>>>>>>> ??? 142??????? struct led_classdev_mc *mc_dev =
>>>>>>>>>>>> lcdev_to_mccdev(cdev);
>>>>>>>>>>>> ??? 143??????? struct lp55xx_led *led =
>>>>>>>>>>>> mcled_cdev_to_led(mc_dev);
>>>>>>>>>>>> ??? 144??????? struct lp55xx_device_config *cfg =
>>>>>>>>>>>> led->chip->cfg;
>>>>>>>>>>>> ??? 145
>>>>>>>>>>>> ? > 146 led_mc_calc_color_components(&led->mc_cdev,
>>>>>>>>>>>> brightness);
>>>>>>>>>>>> ??? 147??????? return cfg->multicolor_brightness_fn(led);
>>>>>>>>>>>> ??? 148
>>>>>>>>>>>
>>>>>>>>>>> Well this was a mess to figure out.
>>>>>>>>>>>
>>>>>>>>>>> The only fix I can figure out here is to remove the
>>>>>>>>>>>
>>>>>>>>>>> ???? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>>
>>>>>>>>>>> from each child device and add
>>>>>>>>>>>
>>>>>>>>>>> ???? select LEDS_CLASS_MULTI_COLOR
>>>>>>>>>>>
>>>>>>>>>>> to the LP55XX_COMMON
>>>>>>>>>>>
>>>>>>>>>>> This way the Multi color framework will inherit the symbol
>>>>>>>>>>> that was set by the COMMON flag which is inherited by
>>>>>>>>>>> majority from the child flags.
>>>>>>>>>>
>>>>>>>>>> Did you try this?
>>>>>>>>>>
>>>>>>>>>> --- a/drivers/leds/Kconfig
>>>>>>>>>> +++ b/drivers/leds/Kconfig
>>>>>>>>>> @@ -398,6 +398,7 @@ config LEDS_LP50XX
>>>>>>>>>> ?config LEDS_LP55XX_COMMON
>>>>>>>>>> ??????? tristate "Common Driver for TI/National
>>>>>>>>>> LP5521/5523/55231/5562/8501"
>>>>>>>>>> ??????? depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562
>>>>>>>>>> || LEDS_LP8501
>>>>>>>>>> +?????? depends on LEDS_CLASS_MULTI_COLOR ||
>>>>>>>>>> !LEDS_CLASS_MULTI_COLOR
>>>>>>>>>> ??????? depends on OF
>>>>>>>>>> ??????? select FW_LOADER
>>>>>>>>>> ??????? select FW_LOADER_USER_HELPER
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Yes I did
>>>>>>>>>
>>>>>>>>> That gave unmet dependencies.
>>>>>>>>>
>>>>>>>>> WARNING: unmet direct dependencies detected for
>>>>>>>>> LEDS_LP55XX_COMMON
>>>>>>>>> ?? Depends on [m]: NEW_LEDS [=y] && (LEDS_LP5521 [=n] ||
>>>>>>>>> LEDS_LP5523 [=m] || LEDS_LP5562 [=y] || LEDS_LP8501 [=y]) &&
>>>>>>>>> (LEDS_CLASS_MULTI_COLOR [=m] || !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>>>> && OF [=y]
>>>>>>>>> ?? Selected by [y]:
>>>>>>>>> ?? - LEDS_LP5562 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>> I2C [=y]
>>>>>>>>> ?? - LEDS_LP8501 [=y] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>> I2C [=y]
>>>>>>>>> ?? Selected by [m]:
>>>>>>>>> ?? - LEDS_LP5523 [=m] && NEW_LEDS [=y] && LEDS_CLASS [=y] &&
>>>>>>>>> I2C [=y] && (LEDS_CLASS_MULTI_COLOR [=m] ||
>>>>>>>>> !LEDS_CLASS_MULTI_COLOR [=m])
>>>>>>>>>
>>>>>>>>
>>>>>>>> When I was testing that yesterday I also had the same warning
>>>>>>>> at some
>>>>>>>> point of testing different Kconfig setups, but with what I
>>>>>>>> showed above
>>>>>>>> it ceased to appear. Now every time I am doing "make oldconfig"
>>>>>>>> the
>>>>>>>> CONFIG_LEDS_LP55XX_COMMON=y entry gets changed to =m with the
>>>>>>>> config
>>>>>>>> from the test bot.
>>>>>>>>
>>>>>>> That is not what I saw in my testing especially after doing a
>>>>>>> distclean
>>>>>>
>>>>>> Could you please give your exact steps after "make distclean" and
>>>>>> copying test bot config to the kernel root directory?
>>>>>>
>>>>>> Also, please share the toolchain you're using for tests.
>>>>>
>>>>> Actually at this stage the toolchain is of lesser relevance.
>>>>>
>>>>> I've tried once more and indeed the problem shows up.
>>>>>
>>>>> It is caused by the driver entries doing
>>>>>
>>>>> "select LEDS_LP55XX_COMMON".
>>>>>
>>>>> Select sets config to "y" so it conflicts with
>>>>> "depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR"
>>>>> in the "config LEDS_LP55XX_COMMON".
>>>>>
>>>>> Your proposed fix will block the possibility of building
>>>>> LED_CLASS_MULTI_COLOR as a module when LP55XX drivers
>>>>> are enabled so this is also not an option.
>>>>>
>>>>> Solving this riddle will require some more thinking.
>>>>> I haven't analyzed it in detail but maybe "imply" statement from
>>>>> kconfig-language.rst could help somehow here.
>>>>
>>>> The multicolor framework will build as a module if the LED_CLASS is
>>>> defined as a module.
>>>>
>>>> See attached test_defconfig
>>>
>>> But it will be impossible to enable CONFIG_LEDS_LP50XX without
>>> CONFIG_LEDS_CLASS_MULTI_COLOR if you will remove
>>>
>>> depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR.
>>>
>> I was not removing the dependency for the LP50xx only the LP55xx.
>
> It was my typo, I meant LP55XX.
>
>>
>>> This is actually why the above entry was needed.
>>>
>>> LP55XX drivers have to work also without multicolor class.
>>>
>> Well I am not sure how else to resolve this problem.? Because the
>> LP55xx has multi level dependencies.
>>
>> Only the LP55xx_common has the dependency on the MC framework. The
>> device drivers do not.
>>
>> The issue is the mixing and matching of the MC fw as a module vs the
>> LP55XX_COMMON as a built-in.
>
> The simplest solution is to avoid selecting LP55XX_COMMON in favor
> of making child drivers depending on it. Of course, maybe there exists
> some trickier option to keep the selection, but I would have to play
> a bit more with it to be sure.
>
That actually makes more sense then what is there now.

The children depend on the COMMON and the COMMON depends on the MC.

Not sure why select was used originally.

But this will prompt another patch to update the u8500_defconfig to
include the common.

Dan