mbox series

[0/3] rockchip: rk8xx: fix broken [np]ldo callbacks

Message ID 20240605-pmic-rk8xx-v1-0-2349fdf68aa0@cherry.de
Headers show
Series rockchip: rk8xx: fix broken [np]ldo callbacks | expand

Message

Quentin Schulz June 5, 2024, 9:33 a.m. UTC
This is for master branch, merge ASAP as it's known to break at least
Chromebook Jerry.

@Simon, can you please check that this fixes your CB?

The wrong udevice was passed to the functions, making them call the
pmic callbacks on the parent of the pmic udevice instead of the pmic
udevice itself.

While at it, ensure consistency by having all internal functions use
pmic udevice instead of the regulator udevice.

Finally, clarify operator precedence in ternary condition as reported by
my linter.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Quentin Schulz (3):
      regulator: rk8xx: fix incorrect device used for _ldo_[sg]et_suspend_value
      regulator: rk8xx: pass pmic udevice instead of regulator to all internal functions
      regulator: rk8xx: clarify operator precedence

 drivers/power/regulator/rk8xx.c | 54 ++++++++++++++++++++---------------------
 1 file changed, 27 insertions(+), 27 deletions(-)
---
base-commit: c0ea27bccfb7d2d37fd36806ac2a2f7389099420
change-id: 20240605-pmic-rk8xx-52f2286be334

Best regards,

Comments

Anand Moon June 5, 2024, 1:11 p.m. UTC | #1
Hi Quentin,

On Wed, 5 Jun 2024 at 15:03, Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> This is for master branch, merge ASAP as it's known to break at least
> Chromebook Jerry.
>
> @Simon, can you please check that this fixes your CB?
>
> The wrong udevice was passed to the functions, making them call the
> pmic callbacks on the parent of the pmic udevice instead of the pmic
> udevice itself.
>
> While at it, ensure consistency by having all internal functions use
> pmic udevice instead of the regulator udevice.
>
> Finally, clarify operator precedence in ternary condition as reported by
> my linter.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

I see we have not been able to follow configs on a few of the board's for RK3588

CONFIG_CMD_REGULATOR=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_RK8XX=y

could you enable the options with imply for all the rockchip boards?

Thanks
-Anand

> ---
> Quentin Schulz (3):
>       regulator: rk8xx: fix incorrect device used for _ldo_[sg]et_suspend_value
>       regulator: rk8xx: pass pmic udevice instead of regulator to all internal functions
>       regulator: rk8xx: clarify operator precedence
>
>  drivers/power/regulator/rk8xx.c | 54 ++++++++++++++++++++---------------------
>  1 file changed, 27 insertions(+), 27 deletions(-)
> ---
> base-commit: c0ea27bccfb7d2d37fd36806ac2a2f7389099420
> change-id: 20240605-pmic-rk8xx-52f2286be334
>
> Best regards,
> --
> Quentin Schulz <quentin.schulz@cherry.de>
>
Quentin Schulz June 5, 2024, 4 p.m. UTC | #2
Hi Anand,

On 6/5/24 3:11 PM, Anand Moon wrote:
> Hi Quentin,
> 
> On Wed, 5 Jun 2024 at 15:03, Quentin Schulz <foss+uboot@0leil.net> wrote:
>>
>> This is for master branch, merge ASAP as it's known to break at least
>> Chromebook Jerry.
>>
>> @Simon, can you please check that this fixes your CB?
>>
>> The wrong udevice was passed to the functions, making them call the
>> pmic callbacks on the parent of the pmic udevice instead of the pmic
>> udevice itself.
>>
>> While at it, ensure consistency by having all internal functions use
>> pmic udevice instead of the regulator udevice.
>>
>> Finally, clarify operator precedence in ternary condition as reported by
>> my linter.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> 
> I see we have not been able to follow configs on a few of the board's for RK3588
> 
> CONFIG_CMD_REGULATOR=y
> CONFIG_PMIC_RK8XX=y
> CONFIG_REGULATOR_RK8XX=y
> 
> could you enable the options with imply for all the rockchip boards?
> 

This patch series is a bug fix (ok, plus some cosmetic stuff) for master 
before the next release in July, the suggested change is not a bug fix 
so feel free to send a patch for the next branch instead :)

I'm personally not too keen in adding a lot of "imply" but I am no 
authority there, so whatever the maintainer(s) prefer :)

Thanks,
Quentin