mbox series

[v2,0/3] KTD2026 indicator LED for X86 Xiaomi Pad2

Message ID 20240216160526.235594-1-hpa@redhat.com
Headers show
Series KTD2026 indicator LED for X86 Xiaomi Pad2 | expand

Message

Kate Hsuan Feb. 16, 2024, 4:05 p.m. UTC
The v2 patch includes:
1. Typo and style fixes.
2. The patch 0003 skips all the regulator setup for Xiaomi pad2 since
   KTD2026 on Xiaomi pad2 is already powered by BP25890RTWR. So, the
   sleep can be removed when removing the module.

Kate Hsuan (3):
  platform: x86-android-tablets: other: Add swnode for Xiaomi pad2
    indicator LED
  leds: rgb: leds-ktd202x: Get device properties through fwnode to
    support ACPI
  leds: rgb: leds-ktd202x: Skip requlator settings for Xiaomi pad2

 drivers/leds/rgb/Kconfig                      |  1 -
 drivers/leds/rgb/leds-ktd202x.c               | 73 +++++++++++-----
 .../platform/x86/x86-android-tablets/other.c  | 85 +++++++++++++++++++
 .../x86/x86-android-tablets/shared-psy-info.h |  2 +
 4 files changed, 141 insertions(+), 20 deletions(-)

Comments

Ilpo Järvinen Feb. 19, 2024, 1:28 p.m. UTC | #1
On Sat, 17 Feb 2024, Kate Hsuan wrote:

> The controller is already powered by BP25890RTWR on Xiaomi Pad2 so the
> regulator settings can be ignored.
> 
> Signed-off-by: Kate Hsuan <hpa@redhat.com>
> ---
>  drivers/leds/rgb/leds-ktd202x.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/leds/rgb/leds-ktd202x.c b/drivers/leds/rgb/leds-ktd202x.c
> index 8eb79c342fb6..6fd0794988e9 100644
> --- a/drivers/leds/rgb/leds-ktd202x.c
> +++ b/drivers/leds/rgb/leds-ktd202x.c
> @@ -14,7 +14,9 @@
>  #include <linux/of.h>
>  #include <linux/of_device.h>
>  #include <linux/regmap.h>
> +#ifndef CONFIG_ACPI
>  #include <linux/regulator/consumer.h>
> +#endif

Why you need #ifndef here?
  
>  #define KTD2026_NUM_LEDS 3
>  #define KTD2027_NUM_LEDS 4
> @@ -105,18 +107,22 @@ struct ktd202x {
>  
>  static int ktd202x_chip_disable(struct ktd202x *chip)
>  {
> +#ifndef CONFIG_ACPI
>  	int ret;
> +#endif
>  
>  	if (!chip->enabled)
>  		return 0;
>  
>  	regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_ENABLE_CTRL_SLEEP);
>  
> +#ifndef CONFIG_ACPI
>  	ret = regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
>  	if (ret) {
>  		dev_err(chip->dev, "Failed to disable regulators: %d\n", ret);
>  		return ret;
>  	}
> +#endif
>  
>  	chip->enabled = false;
>  	return 0;
> @@ -129,11 +135,13 @@ static int ktd202x_chip_enable(struct ktd202x *chip)
>  	if (chip->enabled)
>  		return 0;
>  
> +#ifndef CONFIG_ACPI
>  	ret = regulator_bulk_enable(ARRAY_SIZE(chip->regulators), chip->regulators);
>  	if (ret) {
>  		dev_err(chip->dev, "Failed to enable regulators: %d\n", ret);
>  		return ret;
>  	}
> +#endif
>  	chip->enabled = true;
>  
>  	ret = regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_ENABLE_CTRL_WAKE);
> @@ -560,6 +568,7 @@ static int ktd202x_probe(struct i2c_client *client)
>  		return ret;
>  	}
>  
> +#ifndef CONFIG_ACPI
>  	chip->regulators[0].supply = "vin";
>  	chip->regulators[1].supply = "vio";
>  	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(chip->regulators), chip->regulators);
> @@ -573,10 +582,12 @@ static int ktd202x_probe(struct i2c_client *client)
>  		dev_err_probe(dev, ret, "Failed to enable regulators.\n");
>  		return ret;
>  	}
> +#endif
>  
>  	chip->num_leds = (int) (unsigned long)i2c_get_match_data(client);
>  
>  	ret = ktd202x_probe_dt(chip);
> +#ifndef CONFIG_ACPI
>  	if (ret < 0) {
>  		regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
>  		return ret;
> @@ -587,6 +598,10 @@ static int ktd202x_probe(struct i2c_client *client)
>  		dev_err_probe(dev, ret, "Failed to disable regulators.\n");
>  		return ret;
>  	}
> +#else
> +	if (ret < 0)
> +		return ret;
> +#endif
>  
>  	mutex_init(&chip->mutex);

To me this entire approach looks quite ugly. It would be much cleaner to 
have something along these lines:

#ifndef CONFIG_ACPI
static int ktd202x_regulators_disable(struct ktd202x *chip)
{
	int ret;

	ret = regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
	if (ret)
		dev_err(chip->dev, "Failed to disable regulators: %d\n", ret);

	return ret;
}
...
#else
static inline int ktd202x_regulators_disable(struct ktd202x *chip) { return 0; }
...
#endif

And call that function without any #ifdefs from the other code.
Ilpo Järvinen Feb. 19, 2024, 1:57 p.m. UTC | #2
On Sat, 17 Feb 2024, Kate Hsuan wrote:

> The v2 patch includes:
> 1. Typo and style fixes.
> 2. The patch 0003 skips all the regulator setup for Xiaomi pad2 since
>    KTD2026 on Xiaomi pad2 is already powered by BP25890RTWR. So, the
>    sleep can be removed when removing the module.
> 
> Kate Hsuan (3):
>   platform: x86-android-tablets: other: Add swnode for Xiaomi pad2
>     indicator LED
>   leds: rgb: leds-ktd202x: Get device properties through fwnode to
>     support ACPI
>   leds: rgb: leds-ktd202x: Skip requlator settings for Xiaomi pad2

So what's the expectation here? I take the first patch and the two other 
go through the LED subsys?
Hans de Goede Feb. 19, 2024, 2:04 p.m. UTC | #3
Hi Kate, Ilpo,

On 2/19/24 14:28, Ilpo Järvinen wrote:
> On Sat, 17 Feb 2024, Kate Hsuan wrote:
> 
>> The controller is already powered by BP25890RTWR on Xiaomi Pad2 so the
>> regulator settings can be ignored.
>>
>> Signed-off-by: Kate Hsuan <hpa@redhat.com>
>> ---
>>  drivers/leds/rgb/leds-ktd202x.c | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/leds/rgb/leds-ktd202x.c b/drivers/leds/rgb/leds-ktd202x.c
>> index 8eb79c342fb6..6fd0794988e9 100644
>> --- a/drivers/leds/rgb/leds-ktd202x.c
>> +++ b/drivers/leds/rgb/leds-ktd202x.c
>> @@ -14,7 +14,9 @@
>>  #include <linux/of.h>
>>  #include <linux/of_device.h>
>>  #include <linux/regmap.h>
>> +#ifndef CONFIG_ACPI
>>  #include <linux/regulator/consumer.h>
>> +#endif
> 
> Why you need #ifndef here?
>   
>>  #define KTD2026_NUM_LEDS 3
>>  #define KTD2027_NUM_LEDS 4
>> @@ -105,18 +107,22 @@ struct ktd202x {
>>  
>>  static int ktd202x_chip_disable(struct ktd202x *chip)
>>  {
>> +#ifndef CONFIG_ACPI
>>  	int ret;
>> +#endif
>>  
>>  	if (!chip->enabled)
>>  		return 0;
>>  
>>  	regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_ENABLE_CTRL_SLEEP);
>>  
>> +#ifndef CONFIG_ACPI
>>  	ret = regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
>>  	if (ret) {
>>  		dev_err(chip->dev, "Failed to disable regulators: %d\n", ret);
>>  		return ret;
>>  	}
>> +#endif
>>  
>>  	chip->enabled = false;
>>  	return 0;
>> @@ -129,11 +135,13 @@ static int ktd202x_chip_enable(struct ktd202x *chip)
>>  	if (chip->enabled)
>>  		return 0;
>>  
>> +#ifndef CONFIG_ACPI
>>  	ret = regulator_bulk_enable(ARRAY_SIZE(chip->regulators), chip->regulators);
>>  	if (ret) {
>>  		dev_err(chip->dev, "Failed to enable regulators: %d\n", ret);
>>  		return ret;
>>  	}
>> +#endif
>>  	chip->enabled = true;
>>  
>>  	ret = regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_ENABLE_CTRL_WAKE);
>> @@ -560,6 +568,7 @@ static int ktd202x_probe(struct i2c_client *client)
>>  		return ret;
>>  	}
>>  
>> +#ifndef CONFIG_ACPI
>>  	chip->regulators[0].supply = "vin";
>>  	chip->regulators[1].supply = "vio";
>>  	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(chip->regulators), chip->regulators);
>> @@ -573,10 +582,12 @@ static int ktd202x_probe(struct i2c_client *client)
>>  		dev_err_probe(dev, ret, "Failed to enable regulators.\n");
>>  		return ret;
>>  	}
>> +#endif
>>  
>>  	chip->num_leds = (int) (unsigned long)i2c_get_match_data(client);
>>  
>>  	ret = ktd202x_probe_dt(chip);
>> +#ifndef CONFIG_ACPI
>>  	if (ret < 0) {
>>  		regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
>>  		return ret;
>> @@ -587,6 +598,10 @@ static int ktd202x_probe(struct i2c_client *client)
>>  		dev_err_probe(dev, ret, "Failed to disable regulators.\n");
>>  		return ret;
>>  	}
>> +#else
>> +	if (ret < 0)
>> +		return ret;
>> +#endif
>>  
>>  	mutex_init(&chip->mutex);
> 
> To me this entire approach looks quite ugly. It would be much cleaner to 
> have something along these lines:
> 
> #ifndef CONFIG_ACPI
> static int ktd202x_regulators_disable(struct ktd202x *chip)
> {
> 	int ret;
> 
> 	ret = regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
> 	if (ret)
> 		dev_err(chip->dev, "Failed to disable regulators: %d\n", ret);
> 
> 	return ret;
> }
> ...
> #else
> static inline int ktd202x_regulators_disable(struct ktd202x *chip) { return 0; }
> ...
> #endif
> 
> And call that function without any #ifdefs from the other code.

I believe that skipping the regulator stuff in the ACPI case is not
the right solution here.

There likely is some underlying issue which also happens on non ACPI
hw, but I guess no-one has ever tried to remove the module there.

I have the same tablet as on which Kate is testing this. So I plan
to make some time to reproduce this and see if I can come up with
a proper fix.

Regards,

Hans
Hans de Goede Feb. 19, 2024, 2:07 p.m. UTC | #4
Hi Kate,

On 2/16/24 17:05, Kate Hsuan wrote:
> There is a KTD2026 LED controller to manage the indicator LED for Xiaomi
> pad2. The ACPI for it is not properly made so the kernel can't get
> a correct description of it.
> 
> This work add a description for this RGB LED controller and also set a
> trigger to indicate the chaging event (bq27520-0-charging). When it is
> charging, the indicator LED will be turn on.
> 
> Signed-off-by: Kate Hsuan <hpa@redhat.com>
> ---
>  .../platform/x86/x86-android-tablets/other.c  | 85 +++++++++++++++++++
>  .../x86/x86-android-tablets/shared-psy-info.h |  2 +
>  2 files changed, 87 insertions(+)
> 
> diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
> index bc6bbf7ec6ea..542ef6667b7b 100644
> --- a/drivers/platform/x86/x86-android-tablets/other.c
> +++ b/drivers/platform/x86/x86-android-tablets/other.c
> @@ -12,6 +12,7 @@
>  #include <linux/gpio/machine.h>
>  #include <linux/input.h>
>  #include <linux/platform_device.h>
> +#include <dt-bindings/leds/common.h>
>  
>  #include "shared-psy-info.h"
>  #include "x86-android-tablets.h"
> @@ -593,6 +594,87 @@ const struct x86_dev_info whitelabel_tm800a550l_info __initconst = {
>  	.gpiod_lookup_tables = whitelabel_tm800a550l_gpios,
>  };
>  
> +/*
> + * The fwnode for ktd2026 on Xaomi pad2. It composed of a RGB LED node
> + * with three subnodes for each color (B/G/R). The RGB LED node is named
> + * "multi-led" to align with the name in the device tree.
> + */
> +
> +/* main fwnode for ktd2026 */
> +static const struct software_node ktd2026_node = {
> +};
> +
> +static const struct property_entry ktd2026_rgb_led_props[] = {
> +	PROPERTY_ENTRY_U32("reg", 0),
> +	PROPERTY_ENTRY_U32("color", LED_COLOR_ID_RGB),
> +	PROPERTY_ENTRY_STRING("function", "indicator"),
> +	PROPERTY_ENTRY_STRING("linux,default-trigger",
> +			      "bq27520-0-charging"),
> +
> +	{ }
> +};

What is the result of setting this default trigger on
the multi-color LED class device ?

Will the LED now turn on at whatever color it was last
set (presumably white?) when charging and turn off
again when charging is complete, or the charger is plugged out ?

Regards,

Hans




> +
> +static const struct software_node ktd2026_rgb_led_node = {
> +	.name = "multi-led",
> +	.properties = ktd2026_rgb_led_props,
> +	.parent = &ktd2026_node,
> +};
> +
> +/* B */
> +static const struct property_entry ktd2026_red_led_props[] = {
> +	PROPERTY_ENTRY_U32("reg", 0),
> +	PROPERTY_ENTRY_U32("color", LED_COLOR_ID_BLUE),
> +	{ }
> +};
> +
> +static const struct software_node ktd2026_red_led_node = {
> +	.properties = ktd2026_red_led_props,
> +	.parent = &ktd2026_rgb_led_node,
> +};
> +
> +/* G */
> +static const struct property_entry ktd2026_green_led_props[] = {
> +	PROPERTY_ENTRY_U32("reg", 1),
> +	PROPERTY_ENTRY_U32("color", LED_COLOR_ID_GREEN),
> +	{ }
> +};
> +
> +static const struct software_node ktd2026_green_led_node = {
> +	.properties = ktd2026_green_led_props,
> +	.parent = &ktd2026_rgb_led_node,
> +};
> +
> +/* R */
> +static const struct property_entry ktd2026_blue_led_props[] = {
> +	PROPERTY_ENTRY_U32("reg", 2),
> +	PROPERTY_ENTRY_U32("color", LED_COLOR_ID_RED),
> +	{ }
> +};
> +
> +static const struct software_node ktd2026_blue_led_node = {
> +	.properties = ktd2026_blue_led_props,
> +	.parent = &ktd2026_rgb_led_node,
> +};
> +
> +static const struct software_node *ktd2026_node_group[] = {
> +	&ktd2026_node,
> +	&ktd2026_rgb_led_node,
> +	&ktd2026_red_led_node,
> +	&ktd2026_green_led_node,
> +	&ktd2026_blue_led_node,
> +	NULL
> +};
> +
> +static int __init xiaomi_mipad2_init(void)
> +{
> +	return software_node_register_node_group(ktd2026_node_group);
> +}
> +
> +static void xiaomi_mipad2_exit(void)
> +{
> +	software_node_unregister_node_group(ktd2026_node_group);
> +}
> +
>  /*
>   * If the EFI bootloader is not Xiaomi's own signed Android loader, then the
>   * Xiaomi Mi Pad 2 X86 tablet sets OSID in the DSDT to 1 (Windows), causing
> @@ -616,6 +698,7 @@ static const struct x86_i2c_client_info xiaomi_mipad2_i2c_clients[] __initconst
>  			.type = "ktd2026",
>  			.addr = 0x30,
>  			.dev_name = "ktd2026",
> +			.swnode = &ktd2026_node,
>  		},
>  		.adapter_path = "\\_SB_.PCI0.I2C3",
>  	},
> @@ -624,4 +707,6 @@ static const struct x86_i2c_client_info xiaomi_mipad2_i2c_clients[] __initconst
>  const struct x86_dev_info xiaomi_mipad2_info __initconst = {
>  	.i2c_client_info = xiaomi_mipad2_i2c_clients,
>  	.i2c_client_count = ARRAY_SIZE(xiaomi_mipad2_i2c_clients),
> +	.init = xiaomi_mipad2_init,
> +	.exit = xiaomi_mipad2_exit,
>  };
> diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
> index c2d2968cddc2..8c33ec47ee12 100644
> --- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
> +++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
> @@ -29,4 +29,6 @@ extern const char * const bq24190_modules[];
>  extern const struct platform_device_info int3496_pdevs[];
>  extern struct gpiod_lookup_table int3496_reference_gpios;
>  
> +extern const struct software_node ktd2026_leds_node;
> +
>  #endif
Kate Hsuan Feb. 20, 2024, 3:22 a.m. UTC | #5
Hi Hans,

On Mon, Feb 19, 2024 at 10:07 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Kate,
>
> On 2/16/24 17:05, Kate Hsuan wrote:
> > There is a KTD2026 LED controller to manage the indicator LED for Xiaomi
> > pad2. The ACPI for it is not properly made so the kernel can't get
> > a correct description of it.
> >
> > This work add a description for this RGB LED controller and also set a
> > trigger to indicate the chaging event (bq27520-0-charging). When it is
> > charging, the indicator LED will be turn on.
> >
> > Signed-off-by: Kate Hsuan <hpa@redhat.com>
> > ---
> >  .../platform/x86/x86-android-tablets/other.c  | 85 +++++++++++++++++++
> >  .../x86/x86-android-tablets/shared-psy-info.h |  2 +
> >  2 files changed, 87 insertions(+)
> >
> > diff --git a/drivers/platform/x86/x86-android-tablets/other.c b/drivers/platform/x86/x86-android-tablets/other.c
> > index bc6bbf7ec6ea..542ef6667b7b 100644
> > --- a/drivers/platform/x86/x86-android-tablets/other.c
> > +++ b/drivers/platform/x86/x86-android-tablets/other.c
> > @@ -12,6 +12,7 @@
> >  #include <linux/gpio/machine.h>
> >  #include <linux/input.h>
> >  #include <linux/platform_device.h>
> > +#include <dt-bindings/leds/common.h>
> >
> >  #include "shared-psy-info.h"
> >  #include "x86-android-tablets.h"
> > @@ -593,6 +594,87 @@ const struct x86_dev_info whitelabel_tm800a550l_info __initconst = {
> >       .gpiod_lookup_tables = whitelabel_tm800a550l_gpios,
> >  };
> >
> > +/*
> > + * The fwnode for ktd2026 on Xaomi pad2. It composed of a RGB LED node
> > + * with three subnodes for each color (B/G/R). The RGB LED node is named
> > + * "multi-led" to align with the name in the device tree.
> > + */
> > +
> > +/* main fwnode for ktd2026 */
> > +static const struct software_node ktd2026_node = {
> > +};
> > +
> > +static const struct property_entry ktd2026_rgb_led_props[] = {
> > +     PROPERTY_ENTRY_U32("reg", 0),
> > +     PROPERTY_ENTRY_U32("color", LED_COLOR_ID_RGB),
> > +     PROPERTY_ENTRY_STRING("function", "indicator"),
> > +     PROPERTY_ENTRY_STRING("linux,default-trigger",
> > +                           "bq27520-0-charging"),
> > +
> > +     { }
> > +};
>
> What is the result of setting this default trigger on
> the multi-color LED class device ?

Thank you for reviewing it.

>
> Will the LED now turn on at whatever color it was last
> set (presumably white?)

You are right. It is white.

> when charging and turn off
> again when charging is complete, or the charger is plugged out ?

The behavior is simple. It is lit up when the charger is connected. It
is turned off when the charger is disconnected.
Many triggers can be used.
bq27520-0-charging-or-full
[bq27520-0-charging]
bq27520-0-full
bq27520-0-charging-blink-full-solid

I think bq27520-0-charging-or-full or
bq27520-0-charging-blink-full-solid can be used in the v3 patch.
(The battery status is always "charging" for my Xiaomi pad2. Even the
battery is 100%. When the pad is off and then connect the charger, it
will be turned on immediately. The LED will be lit up after the kernel
module is loaded)

>
> Regards,
>
> Hans
>
>
>
>
> > +
> > +static const struct software_node ktd2026_rgb_led_node = {
> > +     .name = "multi-led",
> > +     .properties = ktd2026_rgb_led_props,
> > +     .parent = &ktd2026_node,
> > +};
> > +
> > +/* B */
> > +static const struct property_entry ktd2026_red_led_props[] = {
> > +     PROPERTY_ENTRY_U32("reg", 0),
> > +     PROPERTY_ENTRY_U32("color", LED_COLOR_ID_BLUE),
> > +     { }
> > +};
> > +
> > +static const struct software_node ktd2026_red_led_node = {
> > +     .properties = ktd2026_red_led_props,
> > +     .parent = &ktd2026_rgb_led_node,
> > +};
> > +
> > +/* G */
> > +static const struct property_entry ktd2026_green_led_props[] = {
> > +     PROPERTY_ENTRY_U32("reg", 1),
> > +     PROPERTY_ENTRY_U32("color", LED_COLOR_ID_GREEN),
> > +     { }
> > +};
> > +
> > +static const struct software_node ktd2026_green_led_node = {
> > +     .properties = ktd2026_green_led_props,
> > +     .parent = &ktd2026_rgb_led_node,
> > +};
> > +
> > +/* R */
> > +static const struct property_entry ktd2026_blue_led_props[] = {
> > +     PROPERTY_ENTRY_U32("reg", 2),
> > +     PROPERTY_ENTRY_U32("color", LED_COLOR_ID_RED),
> > +     { }
> > +};
> > +
> > +static const struct software_node ktd2026_blue_led_node = {
> > +     .properties = ktd2026_blue_led_props,
> > +     .parent = &ktd2026_rgb_led_node,
> > +};
> > +
> > +static const struct software_node *ktd2026_node_group[] = {
> > +     &ktd2026_node,
> > +     &ktd2026_rgb_led_node,
> > +     &ktd2026_red_led_node,
> > +     &ktd2026_green_led_node,
> > +     &ktd2026_blue_led_node,
> > +     NULL
> > +};
> > +
> > +static int __init xiaomi_mipad2_init(void)
> > +{
> > +     return software_node_register_node_group(ktd2026_node_group);
> > +}
> > +
> > +static void xiaomi_mipad2_exit(void)
> > +{
> > +     software_node_unregister_node_group(ktd2026_node_group);
> > +}
> > +
> >  /*
> >   * If the EFI bootloader is not Xiaomi's own signed Android loader, then the
> >   * Xiaomi Mi Pad 2 X86 tablet sets OSID in the DSDT to 1 (Windows), causing
> > @@ -616,6 +698,7 @@ static const struct x86_i2c_client_info xiaomi_mipad2_i2c_clients[] __initconst
> >                       .type = "ktd2026",
> >                       .addr = 0x30,
> >                       .dev_name = "ktd2026",
> > +                     .swnode = &ktd2026_node,
> >               },
> >               .adapter_path = "\\_SB_.PCI0.I2C3",
> >       },
> > @@ -624,4 +707,6 @@ static const struct x86_i2c_client_info xiaomi_mipad2_i2c_clients[] __initconst
> >  const struct x86_dev_info xiaomi_mipad2_info __initconst = {
> >       .i2c_client_info = xiaomi_mipad2_i2c_clients,
> >       .i2c_client_count = ARRAY_SIZE(xiaomi_mipad2_i2c_clients),
> > +     .init = xiaomi_mipad2_init,
> > +     .exit = xiaomi_mipad2_exit,
> >  };
> > diff --git a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
> > index c2d2968cddc2..8c33ec47ee12 100644
> > --- a/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
> > +++ b/drivers/platform/x86/x86-android-tablets/shared-psy-info.h
> > @@ -29,4 +29,6 @@ extern const char * const bq24190_modules[];
> >  extern const struct platform_device_info int3496_pdevs[];
> >  extern struct gpiod_lookup_table int3496_reference_gpios;
> >
> > +extern const struct software_node ktd2026_leds_node;
> > +
> >  #endif
>
Kate Hsuan Feb. 20, 2024, 4:21 a.m. UTC | #6
Hi Hans and llpo,

On Mon, Feb 19, 2024 at 10:04 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Kate, Ilpo,
>
> On 2/19/24 14:28, Ilpo Järvinen wrote:
> > On Sat, 17 Feb 2024, Kate Hsuan wrote:
> >
> >> The controller is already powered by BP25890RTWR on Xiaomi Pad2 so the
> >> regulator settings can be ignored.
> >>
> >> Signed-off-by: Kate Hsuan <hpa@redhat.com>
> >> ---
> >>  drivers/leds/rgb/leds-ktd202x.c | 15 +++++++++++++++
> >>  1 file changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/leds/rgb/leds-ktd202x.c b/drivers/leds/rgb/leds-ktd202x.c
> >> index 8eb79c342fb6..6fd0794988e9 100644
> >> --- a/drivers/leds/rgb/leds-ktd202x.c
> >> +++ b/drivers/leds/rgb/leds-ktd202x.c
> >> @@ -14,7 +14,9 @@
> >>  #include <linux/of.h>
> >>  #include <linux/of_device.h>
> >>  #include <linux/regmap.h>
> >> +#ifndef CONFIG_ACPI
> >>  #include <linux/regulator/consumer.h>
> >> +#endif
> >
> > Why you need #ifndef here?
> >
> >>  #define KTD2026_NUM_LEDS 3
> >>  #define KTD2027_NUM_LEDS 4
> >> @@ -105,18 +107,22 @@ struct ktd202x {
> >>
> >>  static int ktd202x_chip_disable(struct ktd202x *chip)
> >>  {
> >> +#ifndef CONFIG_ACPI
> >>      int ret;
> >> +#endif
> >>
> >>      if (!chip->enabled)
> >>              return 0;
> >>
> >>      regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_ENABLE_CTRL_SLEEP);
> >>
> >> +#ifndef CONFIG_ACPI
> >>      ret = regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
> >>      if (ret) {
> >>              dev_err(chip->dev, "Failed to disable regulators: %d\n", ret);
> >>              return ret;
> >>      }
> >> +#endif
> >>
> >>      chip->enabled = false;
> >>      return 0;
> >> @@ -129,11 +135,13 @@ static int ktd202x_chip_enable(struct ktd202x *chip)
> >>      if (chip->enabled)
> >>              return 0;
> >>
> >> +#ifndef CONFIG_ACPI
> >>      ret = regulator_bulk_enable(ARRAY_SIZE(chip->regulators), chip->regulators);
> >>      if (ret) {
> >>              dev_err(chip->dev, "Failed to enable regulators: %d\n", ret);
> >>              return ret;
> >>      }
> >> +#endif
> >>      chip->enabled = true;
> >>
> >>      ret = regmap_write(chip->regmap, KTD202X_REG_RESET_CONTROL, KTD202X_ENABLE_CTRL_WAKE);
> >> @@ -560,6 +568,7 @@ static int ktd202x_probe(struct i2c_client *client)
> >>              return ret;
> >>      }
> >>
> >> +#ifndef CONFIG_ACPI
> >>      chip->regulators[0].supply = "vin";
> >>      chip->regulators[1].supply = "vio";
> >>      ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(chip->regulators), chip->regulators);
> >> @@ -573,10 +582,12 @@ static int ktd202x_probe(struct i2c_client *client)
> >>              dev_err_probe(dev, ret, "Failed to enable regulators.\n");
> >>              return ret;
> >>      }
> >> +#endif
> >>
> >>      chip->num_leds = (int) (unsigned long)i2c_get_match_data(client);
> >>
> >>      ret = ktd202x_probe_dt(chip);
> >> +#ifndef CONFIG_ACPI
> >>      if (ret < 0) {
> >>              regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
> >>              return ret;
> >> @@ -587,6 +598,10 @@ static int ktd202x_probe(struct i2c_client *client)
> >>              dev_err_probe(dev, ret, "Failed to disable regulators.\n");
> >>              return ret;
> >>      }
> >> +#else
> >> +    if (ret < 0)
> >> +            return ret;
> >> +#endif
> >>
> >>      mutex_init(&chip->mutex);
> >
> > To me this entire approach looks quite ugly. It would be much cleaner to
> > have something along these lines:
> >
> > #ifndef CONFIG_ACPI
> > static int ktd202x_regulators_disable(struct ktd202x *chip)
> > {
> >       int ret;
> >
> >       ret = regulator_bulk_disable(ARRAY_SIZE(chip->regulators), chip->regulators);
> >       if (ret)
> >               dev_err(chip->dev, "Failed to disable regulators: %d\n", ret);
> >
> >       return ret;
> > }
> > ...
> > #else
> > static inline int ktd202x_regulators_disable(struct ktd202x *chip) { return 0; }
> > ...
> > #endif
> >
> > And call that function without any #ifdefs from the other code.
>
> I believe that skipping the regulator stuff in the ACPI case is not
> the right solution here.
>
> There likely is some underlying issue which also happens on non ACPI
> hw, but I guess no-one has ever tried to remove the module there.
>
> I have the same tablet as on which Kate is testing this. So I plan
> to make some time to reproduce this and see if I can come up with
> a proper fix.
>
> Regards,
>
> Hans
>

Thank you for reviewing it.

This patch is used to prevent the WARN_ON() shown in the following URL.
https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L2396

I'll drop this patch in the v3 patch. And I can also try to
investigate the issue of the regulator.


--
BR,
Kate
Kate Hsuan Feb. 20, 2024, 4:34 a.m. UTC | #7
Hi llpo,

On Mon, Feb 19, 2024 at 9:57 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Sat, 17 Feb 2024, Kate Hsuan wrote:
>
> > The v2 patch includes:
> > 1. Typo and style fixes.
> > 2. The patch 0003 skips all the regulator setup for Xiaomi pad2 since
> >    KTD2026 on Xiaomi pad2 is already powered by BP25890RTWR. So, the
> >    sleep can be removed when removing the module.
> >
> > Kate Hsuan (3):
> >   platform: x86-android-tablets: other: Add swnode for Xiaomi pad2
> >     indicator LED
> >   leds: rgb: leds-ktd202x: Get device properties through fwnode to
> >     support ACPI
> >   leds: rgb: leds-ktd202x: Skip requlator settings for Xiaomi pad2
>
> So what's the expectation here?
Thank you for reviewing it.

Sorry for the confusion.
This patch enabled the KTD2026 LED controller on a Xiaomi Pad2. The
controller controls an indicator LED which indicates the status of the
charging or other events.
Since it is an x86-based Android tablet, we need to set the device
information through swnode and revise the driver to use fwnode APIs.

> I take the first patch and the two other
> go through the LED subsys?

Yes. the first patch is for platform-driver-x86 and the second is for
the LED subsystem. If someone would like to test it, they could easily
get the necessary part of this work.

>
> --
>  i.
>