linux-kernel - Re: [RFC PATCH 2/2] mfd: rohm-bd71828: Add power off functionality

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <472c6eaf-6cbc-484c-bc94-571d115176aa@gmail.com>
Date: Mon, 25 Mar 2024 13:31:15 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andreas Kemnade <andreas@...nade.info>, lee@...nel.org,
 robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, imx@...ts.linux.dev
Subject: Re: [RFC PATCH 2/2] mfd: rohm-bd71828: Add power off functionality

On 3/24/24 22:12, Andreas Kemnade wrote:
> Since the chip can power off the system, add the corresponding
> functionality.
> Based on https://github.com/kobolabs/Kobo-Reader/raw/master/hw/imx6sll-clara2e/kernel.tar.bz2
> No information source about the magic numbers found.

Oh, interesting repository :) Thanks for linking to it! I didn't know 
someone had reworked this driver...

I have access to the data-sheets so I also have some pieces of 
information. I hope I can clarify part of the puzzle. Unfortunately I 
have no information about the magic delays. I guess I could try asking 
though.

Oh, it seems to me this handler is only working on BD71828, not on 
BD71815. So, it should be tied to the ROHM_CHIP_TYPE_BD71828.

> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
> ---
>   drivers/mfd/rohm-bd71828.c | 31 ++++++++++++++++++++++++++++++-
>   1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index 594718f7e8e1..5a55aa3620d0 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -464,6 +464,24 @@ static int set_clk_mode(struct device *dev, struct regmap *regmap,
>   				  OUT32K_MODE_CMOS);
>   }
>   
> +static struct i2c_client *bd71828_dev;

I'm not sure why to store pointer to the device and not a pointer to the 
regmap?

> +static void bd71828_power_off(void)
> +{
> +	i2c_smbus_write_byte_data(bd71828_dev, 0x03, 0xff);

0x03 is a "reset reason" - register. Spec I have states that the 
register should clear when a reset occurs - but it also says the bits 
are "write '1' to clear". So, for some reason(?), this clears the 
previous reset reason. I am unsure why i2c_smbus_write_byte_data() and 
not regmap()?

> +	mdelay(500);
> +	i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_INT_DCIN2, 0x02);

This clears the DCIN monitoring status bit from the IRQ status register. 
I don't understand the purpose though.

> +	mdelay(500);
> +	while (true) {
> +		i2c_smbus_write_byte_data(bd71828_dev, BD71828_REG_PS_CTRL_1, 0x02);

This write to PS_CTRL_1 initiates a state transition. 0x2 equals to HBNT 
state. Eg, in usual cases this should be a start of the power-off sequence.

> +		mdelay(500);
> +	}
> +}

If you have the hardware to test this on, then it'd be great to see if 
clearing the reset reason and IRQ status could be dropped. I can't 
immediately think of a reason for those.

> +static void bd71828_remove_poweroff(void *data)
> +{
> +	bd71828_dev = NULL;

This does not smell correct to me. Should we remove the 
bd71828_power_off() from the pm_power_off instead?

> +}
> +
>   static int bd71828_i2c_probe(struct i2c_client *i2c)
>   {
>   	struct regmap_irq_chip_data *irq_data;
> @@ -542,7 +560,18 @@ static int bd71828_i2c_probe(struct i2c_client *i2c)
>   	ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO, mfd, cells,
>   				   NULL, 0, regmap_irq_get_domain(irq_data));
>   	if (ret)
> -		dev_err_probe(&i2c->dev, ret, "Failed to create subdevices\n");
> +		return	dev_err_probe(&i2c->dev, ret, "Failed to create subdevices\n");
> +
> +	if (of_device_is_system_power_controller(i2c->dev.of_node)) {
> +		if (!pm_power_off) {
> +			bd71828_dev = i2c;
> +			pm_power_off = bd71828_power_off;
> +			ret = devm_add_action_or_reset(&i2c->dev,
> +						       bd71828_remove_poweroff,
> +						       NULL);
> +		} else
> +			dev_warn(&i2c->dev, "Poweroff callback already assigned\n");
> +	}
>   
>   	return ret;
>   }

Thanks for doing the digging Andreas! I think supporting the power-off 
for devices using this PMIC is nice!

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~