[PATCH next v3 5/6] power: rk8xx: properly print all supported PMICs name

[Quentin Schulz]

Hi all,

On 6/6/24 10:45 AM, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz at cherry.de>
> 
> The ID of the PMIC is stored in the 2 16b registers but the only part
> that matters right now is the 3 MSB, which make the 3 digits (in hex) of
> the part number.
> 
> Right now, only RK808 was properly displayed, with this all currently
> supported PMICs should display the proper part number.
> 
> Additionally, when the PMIC variant is not found, print that value
> instead of the masked unshifted value as all PMICs we support for now
> have their LSB ignored to represent the actual part number.
> 
> Tested on RK806 (RK3588 Jaguar), RK808 (RK3399 Puma) and RK809 (PX30
> Ringneck).
> 
> Reviewed-by: Kever Yang <kever.yang at rock-chips.com>
> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
> ---
>   drivers/power/pmic/rk8xx.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> index 12ff26a0855..617bb511e4e 100644
> --- a/drivers/power/pmic/rk8xx.c
> +++ b/drivers/power/pmic/rk8xx.c
> @@ -6,6 +6,7 @@
>   
>   #include <dm.h>
>   #include <dm/lists.h>
> +#include <bitfield.h>
>   #include <errno.h>
>   #include <log.h>
>   #include <linux/bitfield.h>
> @@ -277,10 +278,9 @@ static int rk8xx_probe(struct udevice *dev)
>   		return ret;
>   
>   	priv->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
> -	show_variant = priv->variant;
> +	show_variant = bitfield_extract_by_mask(priv->variant, RK8XX_ID_MSK);
>   	switch (priv->variant) {
>   	case RK808_ID:
> -		show_variant = 0x808;	/* RK808 hardware ID is 0 */

This line removal is actually incorrect, I should have left this in as 
we cannot use the same logic as other PMICs for RK808 as it returns 0, 
so 0 masked/shifted is still zero.

I saw that Kever has already sent a merge request for next with this 
patch, so we have two options: reject the merge and I send another patch 
for next branch, or Kever cancels the merge request, I send a v4 for 
this patch and Kever sends a new merge request? How do we want to 
proceed with this. I have a feeling the additional patch is going to be 
easier for everyone as 1) it's for next branch, 2) isn't breaking 
anything except some info message, which was already wrong (but for all 
non-RK808 PMICs :) ).

Cheers,
Quentin