| Message ID | 20221204104313.17478-2-philipp@uvos.xyz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/4] leds: cpcap: add support for the keyboard light channel | expand |
Hi, On Sun, Dec 04, 2022 at 11:43:11AM +0100, Carl Philipp Klemm wrote: > Previously led-cpcap devices where defined statically in mfd_cell > of the parent mdf device. This causes issues for devices like > xt875 that have less and different leds than xt894. Splitting the > device like this is posssible, as in reality the cpcap led ip block > is totaly independent from the mdf device and cpcap core. > > Signed-off-by: Carl Philipp Klemm <philipp@uvos.xyz> I don't follow. Can't you just use 'status = "disabled;"' for the unavailable nodes? -- Sebastian
Hi, > I don't follow. Can't you just use 'status = "disabled;"' for the > unavailable nodes? Sure but unless im missing something, adding some nodes to a dts, one for eatch led the device in question really has feals mutch better to me than going arround and setting every led channel disabled for eatch device that dosent use it. xt894 being the outlier here amoung the cpcap devices we intend to support (xt894, xt860, xt875, xt910, xt912, mb865, mz609 and mz617) in that it uses most of the extra led channels, most of these use at most one (xt875, xt910, xt912, mb865) or zero (mz609, mz617) extra channels. Carl
Hi, On Mon, Dec 05, 2022 at 07:15:48PM +0100, Carl Philipp Klemm wrote: > > I don't follow. Can't you just use 'status = "disabled;"' for the > > unavailable nodes? > > Sure but unless im missing something, adding some nodes to a dts, one > for eatch led the device in question really has feals mutch better to > me than going arround and setting every led channel disabled for eatch > device that dosent use it. xt894 being the outlier here amoung the > cpcap devices we intend to support (xt894, xt860, xt875, xt910, xt912, > mb865, mz609 and mz617) in that it uses most of the extra led channels, > most of these use at most one (xt875, xt910, xt912, mb865) or zero > (mz609, mz617) extra channels. Just mark them all status = 'disabled'; in the common include and then enable them on a per board basis. Just the same way as all the SoC peripherals are handled nowadays. -- Sebastian
diff --git a/drivers/leds/leds-cpcap.c b/drivers/leds/leds-cpcap.c index 11a9b857d8ea..7a1dd050fdf0 100644 --- a/drivers/leds/leds-cpcap.c +++ b/drivers/leds/leds-cpcap.c @@ -11,6 +11,7 @@ #include <linux/platform_device.h> #include <linux/regmap.h> #include <linux/regulator/consumer.h> +#include <linux/spi/spi.h> #define CPCAP_LED_NO_CURRENT 0x0001 @@ -170,6 +171,18 @@ static int cpcap_led_probe(struct platform_device *pdev) { struct cpcap_led *led; int err; + struct device_node *mfd_node; + struct device *cpcap_dev; + + mfd_node = of_parse_phandle(pdev->dev.of_node, "cpcap-phandle", 0); + if (!mfd_node) { + dev_err(&pdev->dev, "cpcap-phandle is missing in device tree\n"); + return -ENODEV; + } + + cpcap_dev = bus_find_device_by_of_node(&spi_bus_type, mfd_node); + if (IS_ERR_OR_NULL(cpcap_dev)) + return -EAGAIN; led = devm_kzalloc(&pdev->dev, sizeof(*led), GFP_KERNEL); if (!led) @@ -188,9 +201,11 @@ static int cpcap_led_probe(struct platform_device *pdev) return -ENODEV; } - led->regmap = dev_get_regmap(pdev->dev.parent, NULL); - if (!led->regmap) + led->regmap = dev_get_regmap(cpcap_dev, NULL); + if (!led->regmap) { + dev_err(led->dev, "Couldn't get regmap from cpcap mdf device"); return -ENODEV; + } led->vdd = devm_regulator_get(&pdev->dev, "vdd"); if (IS_ERR(led->vdd)) { diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c index 57b3378a8829..e1ae14e0e651 100644 --- a/drivers/mfd/motorola-cpcap.c +++ b/drivers/mfd/motorola-cpcap.c @@ -265,30 +265,6 @@ static const struct mfd_cell cpcap_mfd_devices[] = { }, { .name = "cpcap-usb-phy", .of_compatible = "motorola,mapphone-cpcap-usb-phy", - }, { - .name = "cpcap-led", - .id = 0, - .of_compatible = "motorola,cpcap-led-red", - }, { - .name = "cpcap-led", - .id = 1, - .of_compatible = "motorola,cpcap-led-green", - }, { - .name = "cpcap-led", - .id = 2, - .of_compatible = "motorola,cpcap-led-blue", - }, { - .name = "cpcap-led", - .id = 3, - .of_compatible = "motorola,cpcap-led-adl", - }, { - .name = "cpcap-led", - .id = 4, - .of_compatible = "motorola,cpcap-led-cp", - }, { - .name = "cpcap-led", - .id = 5, - .of_compatible = "motorola,cpcap-led-kl", }, { .name = "cpcap-codec", }
Previously led-cpcap devices where defined statically in mfd_cell of the parent mdf device. This causes issues for devices like xt875 that have less and different leds than xt894. Splitting the device like this is posssible, as in reality the cpcap led ip block is totaly independent from the mdf device and cpcap core. Signed-off-by: Carl Philipp Klemm <philipp@uvos.xyz> --- drivers/leds/leds-cpcap.c | 19 +++++++++++++++++-- drivers/mfd/motorola-cpcap.c | 24 ------------------------ 2 files changed, 17 insertions(+), 26 deletions(-)