linux-kernel - Re: [PATCH v1 1/2] regulator: rtmv20: Adds support for Richtek RTMV20 load switch regulator

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]

Date:   Thu, 24 Sep 2020 17:11:13 +0100
From:   Mark Brown <broonie@...nel.org>
To:     cy_huang <u0084500@...il.com>
Cc:     lgirdwood@...il.com, robh+dt@...nel.org,
        linux-kernel@...r.kernel.org, cy_huang@...htek.com,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v1 1/2] regulator: rtmv20: Adds support for Richtek
 RTMV20 load switch regulator

On Thu, Sep 24, 2020 at 11:04:50PM +0800, cy_huang wrote:

> +static int rtmv20_apply_properties(struct rtmv20_priv *priv)
> +{
> +	const struct {
> +		int offset;
> +		int len;
> +		unsigned int reg;
> +		unsigned int mask;
> +	} props[] = {
> +		PROP_REG_DECL(ld_pulse_delay, RTMV20_REG_PULSEDELAY, RTMV20_DELAY_MASK),

I can't help but feel that this looks like a register cache would be a
simpler way of achieving this.

> +		switch (props[i].len) {
> +		case RTMV20_2BYTE_ACCES:
> +		case RTMV20_1BYTE_ACCES:

It feels like this should all be abstracted in the regmap with custom
reg_read() and reg_write() operations - or have two regmaps for the two
different register sizes.  Having the register sizes and endianness
handling outside of regmap code seems like an abstraction failure.

> +	/* If chip is not enabled, only kept the value, instead */
> +	if (!priv->is_chip_enabled)
> +		return 0;
> +
> +	return regmap_update_bits(priv->regmap, rdev->desc->csel_reg, rdev->desc->csel_mask, sel);

This sort of stuff works a lot better with a register cache.

> +static int rtmv20_lsw_enable(struct regulator_dev *rdev)
> +{
> +	struct rtmv20_priv *priv = rdev_get_drvdata(rdev);
> +	int ret;
> +
> +	gpiod_set_value(priv->enable_gpio, 1);
> +	/* Wait for I2C can be accessed */
> +	usleep_range(RTMV20_I2CRDY_TIMEUS, RTMV20_I2CRDY_TIMEUS + 100);
> +
> +	/* If enable gpio from low to high, the whole registers will be reset, applied here */

Please keep to 80 columns.

> +	ret = regmap_read(priv->regmap, RTMV20_REG_LDIRQ, &val);
> +	if (ret) {
> +		dev_err(priv->dev, "Failed to get irq flags\n");
> +		return IRQ_NONE;
> +	}
> +
> +	if (val & OTPEVT_MASK)
> +		regulator_notifier_call_chain(priv->rdev, REGULATOR_EVENT_OVER_TEMP, NULL);
> +
> +	if (val & OCPEVT_MASK)
> +		regulator_notifier_call_chain(priv->rdev, REGULATOR_EVENT_OVER_CURRENT, NULL);
> +
> +	if (val & FAILEVT_MASK)
> +		regulator_notifier_call_chain(priv->rdev, REGULATOR_EVENT_FAIL, NULL);
> +
> +	return IRQ_HANDLED;
> +}

It looks like this is clear on read but shouln't there be at least some
display of unknown values?

> +	/* After chip check, keep in shutdown mode for low quiescent current */
> +	gpiod_set_value(priv->enable_gpio, 0);

Don't do this, the driver should not adjust the system state unless
explicitly told to do so - we don't know if any state changes are safe
on a given board.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)