| Message ID | 20240306025801.8814-3-hpa@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | KTD2026 indicator LED for X86 Xiaomi Pad2 | expand |
On Wed, 6 Mar 2024, Kate Hsuan wrote: > This LED controller also installed on a Xiaomi pad2 and it is a x86 > platform. The original driver is based on device tree and can't be > used for this ACPI based system. This patch migrated the driver to > use fwnode to access the properties. Moreover, the fwnode API > supports device tree so this work won't effect the original > implementations. > > Signed-off-by: Kate Hsuan <hpa@redhat.com> FWIW, Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Am Mittwoch, dem 06.03.2024 um 10:58 +0800 schrieb Kate Hsuan: > This LED controller also installed on a Xiaomi pad2 and it is a x86 > platform. The original driver is based on device tree and can't be > used for this ACPI based system. This patch migrated the driver to > use fwnode to access the properties. Moreover, the fwnode API > supports device tree so this work won't effect the original > implementations. > > Signed-off-by: Kate Hsuan <hpa@redhat.com> Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5
Wed, Mar 06, 2024 at 10:58:01AM +0800, Kate Hsuan kirjoitti: > This LED controller also installed on a Xiaomi pad2 and it is a x86 > platform. The original driver is based on device tree and can't be > used for this ACPI based system. This patch migrated the driver to > use fwnode to access the properties. Moreover, the fwnode API > supports device tree so this work won't effect the original > implementations. ... > + fwnode_for_each_available_child_node(np, child) { Please, rename np to fwnode to avoid confusion. > + num_channels++; > + } ... > - for_each_available_child_of_node(np, child) { > + fwnode_for_each_available_child_node(np, child) { > u32 mono_color; > u32 reg; > int ret; > > - ret = of_property_read_u32(child, "reg", ®); > + ret = fwnode_property_read_u32(child, "reg", ®); > if (ret != 0 || reg >= chip->num_leds) { > dev_err(chip->dev, "invalid 'reg' of %pOFn\n", child); Must be %pfw now. > - of_node_put(child); > + fwnode_handle_put(child); > return -EINVAL; Side note: This shouldn't shadow error code when ret != 0. > } ... > - ret = of_property_read_u32(child, "color", &mono_color); > + ret = fwnode_property_read_u32(child, "color", &mono_color); > if (ret < 0 && ret != -EINVAL) { > dev_err(chip->dev, "failed to parse 'color' of %pOF\n", child); Must be %pfw now. > - of_node_put(child); > + fwnode_handle_put(child); > return ret; > } ... > - ret = of_property_read_u32(np, "reg", ®); > + ret = fwnode_property_read_u32(np, "reg", ®); > if (ret != 0 || reg >= chip->num_leds) { > dev_err(chip->dev, "invalid 'reg' of %pOFn\n", np); Must be %pfw now. > return -EINVAL; > /* Color property is optional in single color case */ > - ret = of_property_read_u32(np, "color", &color); > + ret = fwnode_property_read_u32(np, "color", &color); > if (ret < 0 && ret != -EINVAL) { > dev_err(chip->dev, "failed to parse 'color' of %pOF\n", np); Must be %pfw now. > return ret; > } ... > + struct fwnode_handle *child, *np; Do not use np for sturct fwnode_handle. It will be quite confusing. ... > - chip->num_leds = (int)(unsigned long)of_device_get_match_data(chip->dev); > + count = device_get_child_node_count(dev); > Redundant blank line. > - count = of_get_available_child_count(np); > if (!count || count > chip->num_leds) > return -EINVAL; ... > + chip->num_leds = (unsigned long)i2c_get_match_data(client); No warnings during compilation? ... > +static const struct i2c_device_id ktd202x_id[] = { > + {"ktd2026", KTD2026_NUM_LEDS}, > + {"ktd2027", KTD2027_NUM_LEDS}, > + {}, N ocomma for the terminator entry. > +}; > +MODULE_DEVICE_TABLE(i2c, ktd202x_id); ... > +#ifndef CONFIG_ACPI Please, no. Drop them. > static const struct of_device_id ktd202x_match_table[] = { > { .compatible = "kinetic,ktd2026", .data = (void *)KTD2026_NUM_LEDS }, > { .compatible = "kinetic,ktd2027", .data = (void *)KTD2027_NUM_LEDS }, > {}, > }; > MODULE_DEVICE_TABLE(of, ktd202x_match_table); > +#endif > > static struct i2c_driver ktd202x_driver = { > .driver = { > .name = "leds-ktd202x", > +#ifndef CONFIG_ACPI > .of_match_table = ktd202x_match_table, > +#endif This is quite unusual besides being ugly. > }, > .probe = ktd202x_probe, > .remove = ktd202x_remove, > .shutdown = ktd202x_shutdown, > + .id_table = ktd202x_id, > };
Hi Thank you for reviewing. On Tue, Mar 12, 2024 at 7:04 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > Wed, Mar 06, 2024 at 10:58:01AM +0800, Kate Hsuan kirjoitti: > > This LED controller also installed on a Xiaomi pad2 and it is a x86 > > platform. The original driver is based on device tree and can't be > > used for this ACPI based system. This patch migrated the driver to > > use fwnode to access the properties. Moreover, the fwnode API > > supports device tree so this work won't effect the original > > implementations. > > ... > > > + fwnode_for_each_available_child_node(np, child) { > > Please, rename np to fwnode to avoid confusion. > > > + num_channels++; > > + } > > ... > > > - for_each_available_child_of_node(np, child) { > > + fwnode_for_each_available_child_node(np, child) { > > u32 mono_color; > > u32 reg; > > int ret; > > > > - ret = of_property_read_u32(child, "reg", ®); > > + ret = fwnode_property_read_u32(child, "reg", ®); > > if (ret != 0 || reg >= chip->num_leds) { > > dev_err(chip->dev, "invalid 'reg' of %pOFn\n", child); > > Must be %pfw now. > > > - of_node_put(child); > > + fwnode_handle_put(child); > > > return -EINVAL; > > Side note: This shouldn't shadow error code when ret != 0. > > > } > > ... > > > - ret = of_property_read_u32(child, "color", &mono_color); > > + ret = fwnode_property_read_u32(child, "color", &mono_color); > > if (ret < 0 && ret != -EINVAL) { > > dev_err(chip->dev, "failed to parse 'color' of %pOF\n", child); > > Must be %pfw now. > > > - of_node_put(child); > > + fwnode_handle_put(child); > > return ret; > > } > > ... > > > - ret = of_property_read_u32(np, "reg", ®); > > + ret = fwnode_property_read_u32(np, "reg", ®); > > if (ret != 0 || reg >= chip->num_leds) { > > dev_err(chip->dev, "invalid 'reg' of %pOFn\n", np); > > Must be %pfw now. > > > return -EINVAL; > > > /* Color property is optional in single color case */ > > - ret = of_property_read_u32(np, "color", &color); > > + ret = fwnode_property_read_u32(np, "color", &color); > > if (ret < 0 && ret != -EINVAL) { > > dev_err(chip->dev, "failed to parse 'color' of %pOF\n", np); > > Must be %pfw now. > > > return ret; > > } > > ... > > > + struct fwnode_handle *child, *np; > > Do not use np for sturct fwnode_handle. It will be quite confusing. > > ... > > > - chip->num_leds = (int)(unsigned long)of_device_get_match_data(chip->dev); > > + count = device_get_child_node_count(dev); > > > > > Redundant blank line. > > > - count = of_get_available_child_count(np); > > if (!count || count > chip->num_leds) > > return -EINVAL; > > ... > > > + chip->num_leds = (unsigned long)i2c_get_match_data(client); > > No warnings during compilation? Yes, the compiler doesn't complain about it. > > ... > > > +static const struct i2c_device_id ktd202x_id[] = { > > + {"ktd2026", KTD2026_NUM_LEDS}, > > + {"ktd2027", KTD2027_NUM_LEDS}, > > + {}, > > N ocomma for the terminator entry. > > > +}; > > +MODULE_DEVICE_TABLE(i2c, ktd202x_id); > > ... > > > +#ifndef CONFIG_ACPI > > Please, no. Drop them. Okay, I've dropped them in v5 patch. > > > static const struct of_device_id ktd202x_match_table[] = { > > { .compatible = "kinetic,ktd2026", .data = (void *)KTD2026_NUM_LEDS }, > > { .compatible = "kinetic,ktd2027", .data = (void *)KTD2027_NUM_LEDS }, > > {}, > > }; > > MODULE_DEVICE_TABLE(of, ktd202x_match_table); > > +#endif > > > > static struct i2c_driver ktd202x_driver = { > > .driver = { > > .name = "leds-ktd202x", > > +#ifndef CONFIG_ACPI > > .of_match_table = ktd202x_match_table, > > +#endif > > This is quite unusual besides being ugly. > > > }, > > .probe = ktd202x_probe, > > .remove = ktd202x_remove, > > .shutdown = ktd202x_shutdown, > > + .id_table = ktd202x_id, > > }; > > -- > With Best Regards, > Andy Shevchenko > >
On Fri, Mar 22, 2024 at 7:45 AM Kate Hsuan <hpa@redhat.com> wrote: > On Tue, Mar 12, 2024 at 7:04 AM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: ... > > > + chip->num_leds = (unsigned long)i2c_get_match_data(client); > > > > No warnings during compilation? > Yes, the compiler doesn't complain about it. And for 32-bit mode as well? ... P.S. You have commented only on the two comments. What about the rest?
diff --git a/drivers/leds/rgb/Kconfig b/drivers/leds/rgb/Kconfig index a6a21f564673..f245dbd9a163 100644 --- a/drivers/leds/rgb/Kconfig +++ b/drivers/leds/rgb/Kconfig @@ -17,7 +17,6 @@ config LEDS_GROUP_MULTICOLOR config LEDS_KTD202X tristate "LED support for KTD202x Chips" depends on I2C - depends on OF select REGMAP_I2C help This option enables support for the Kinetic KTD2026/KTD2027 diff --git a/drivers/leds/rgb/leds-ktd202x.c b/drivers/leds/rgb/leds-ktd202x.c index 514965795a10..fb0d7c102dea 100644 --- a/drivers/leds/rgb/leds-ktd202x.c +++ b/drivers/leds/rgb/leds-ktd202x.c @@ -99,7 +99,7 @@ struct ktd202x { struct device *dev; struct regmap *regmap; bool enabled; - int num_leds; + unsigned long num_leds; struct ktd202x_led leds[] __counted_by(num_leds); }; @@ -381,16 +381,18 @@ static int ktd202x_blink_mc_set(struct led_classdev *cdev, mc->num_colors); } -static int ktd202x_setup_led_rgb(struct ktd202x *chip, struct device_node *np, +static int ktd202x_setup_led_rgb(struct ktd202x *chip, struct fwnode_handle *np, struct ktd202x_led *led, struct led_init_data *init_data) { + struct fwnode_handle *child; struct led_classdev *cdev; - struct device_node *child; struct mc_subled *info; - int num_channels; + int num_channels = 0; int i = 0; - num_channels = of_get_available_child_count(np); + fwnode_for_each_available_child_node(np, child) { + num_channels++; + } if (!num_channels || num_channels > chip->num_leds) return -EINVAL; @@ -398,22 +400,22 @@ static int ktd202x_setup_led_rgb(struct ktd202x *chip, struct device_node *np, if (!info) return -ENOMEM; - for_each_available_child_of_node(np, child) { + fwnode_for_each_available_child_node(np, child) { u32 mono_color; u32 reg; int ret; - ret = of_property_read_u32(child, "reg", ®); + ret = fwnode_property_read_u32(child, "reg", ®); if (ret != 0 || reg >= chip->num_leds) { dev_err(chip->dev, "invalid 'reg' of %pOFn\n", child); - of_node_put(child); + fwnode_handle_put(child); return -EINVAL; } - ret = of_property_read_u32(child, "color", &mono_color); + ret = fwnode_property_read_u32(child, "color", &mono_color); if (ret < 0 && ret != -EINVAL) { dev_err(chip->dev, "failed to parse 'color' of %pOF\n", child); - of_node_put(child); + fwnode_handle_put(child); return ret; } @@ -433,14 +435,14 @@ static int ktd202x_setup_led_rgb(struct ktd202x *chip, struct device_node *np, return devm_led_classdev_multicolor_register_ext(chip->dev, &led->mcdev, init_data); } -static int ktd202x_setup_led_single(struct ktd202x *chip, struct device_node *np, +static int ktd202x_setup_led_single(struct ktd202x *chip, struct fwnode_handle *np, struct ktd202x_led *led, struct led_init_data *init_data) { struct led_classdev *cdev; u32 reg; int ret; - ret = of_property_read_u32(np, "reg", ®); + ret = fwnode_property_read_u32(np, "reg", ®); if (ret != 0 || reg >= chip->num_leds) { dev_err(chip->dev, "invalid 'reg' of %pOFn\n", np); return -EINVAL; @@ -454,7 +456,7 @@ static int ktd202x_setup_led_single(struct ktd202x *chip, struct device_node *np return devm_led_classdev_register_ext(chip->dev, &led->cdev, init_data); } -static int ktd202x_add_led(struct ktd202x *chip, struct device_node *np, unsigned int index) +static int ktd202x_add_led(struct ktd202x *chip, struct fwnode_handle *np, unsigned int index) { struct ktd202x_led *led = &chip->leds[index]; struct led_init_data init_data = {}; @@ -463,14 +465,14 @@ static int ktd202x_add_led(struct ktd202x *chip, struct device_node *np, unsigne int ret; /* Color property is optional in single color case */ - ret = of_property_read_u32(np, "color", &color); + ret = fwnode_property_read_u32(np, "color", &color); if (ret < 0 && ret != -EINVAL) { dev_err(chip->dev, "failed to parse 'color' of %pOF\n", np); return ret; } led->chip = chip; - init_data.fwnode = of_fwnode_handle(np); + init_data.fwnode = np; if (color == LED_COLOR_ID_RGB) { cdev = &led->mcdev.led_cdev; @@ -492,26 +494,30 @@ static int ktd202x_add_led(struct ktd202x *chip, struct device_node *np, unsigne static int ktd202x_probe_dt(struct ktd202x *chip) { - struct device_node *np = dev_of_node(chip->dev), *child; + struct fwnode_handle *child, *np; + struct device *dev = chip->dev; int count; int i = 0; - chip->num_leds = (int)(unsigned long)of_device_get_match_data(chip->dev); + count = device_get_child_node_count(dev); - count = of_get_available_child_count(np); if (!count || count > chip->num_leds) return -EINVAL; + np = dev_fwnode(chip->dev); + if (!np) + return -ENODEV; + regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_RSTR_RESET); /* Allow the device to execute the complete reset */ usleep_range(200, 300); - for_each_available_child_of_node(np, child) { + fwnode_for_each_available_child_node(np, child) { int ret = ktd202x_add_led(chip, child, i); if (ret) { - of_node_put(child); + fwnode_handle_put(child); return ret; } i++; @@ -568,6 +574,8 @@ static int ktd202x_probe(struct i2c_client *client) return ret; } + chip->num_leds = (unsigned long)i2c_get_match_data(client); + ret = ktd202x_probe_dt(chip); if (ret < 0) { regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators); @@ -602,21 +610,33 @@ static void ktd202x_shutdown(struct i2c_client *client) regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_RSTR_RESET); } +static const struct i2c_device_id ktd202x_id[] = { + {"ktd2026", KTD2026_NUM_LEDS}, + {"ktd2027", KTD2027_NUM_LEDS}, + {}, +}; +MODULE_DEVICE_TABLE(i2c, ktd202x_id); + +#ifndef CONFIG_ACPI static const struct of_device_id ktd202x_match_table[] = { { .compatible = "kinetic,ktd2026", .data = (void *)KTD2026_NUM_LEDS }, { .compatible = "kinetic,ktd2027", .data = (void *)KTD2027_NUM_LEDS }, {}, }; MODULE_DEVICE_TABLE(of, ktd202x_match_table); +#endif static struct i2c_driver ktd202x_driver = { .driver = { .name = "leds-ktd202x", +#ifndef CONFIG_ACPI .of_match_table = ktd202x_match_table, +#endif }, .probe = ktd202x_probe, .remove = ktd202x_remove, .shutdown = ktd202x_shutdown, + .id_table = ktd202x_id, }; module_i2c_driver(ktd202x_driver);
This LED controller also installed on a Xiaomi pad2 and it is a x86 platform. The original driver is based on device tree and can't be used for this ACPI based system. This patch migrated the driver to use fwnode to access the properties. Moreover, the fwnode API supports device tree so this work won't effect the original implementations. Signed-off-by: Kate Hsuan <hpa@redhat.com> --- drivers/leds/rgb/Kconfig | 1 - drivers/leds/rgb/leds-ktd202x.c | 60 ++++++++++++++++++++++----------- 2 files changed, 40 insertions(+), 21 deletions(-)