linux-kernel - Re: [PATCH v4 4/8] mfd: hi6421-pmic: add support for HiSilicon Hi6421v530

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:   Tue, 6 Jun 2017 14:54:46 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Guodong Xu <guodong.xu@...aro.org>
Cc:     robh+dt@...nel.org, mark.rutland@....com, xuwei5@...ilicon.com,
        catalin.marinas@....com, will.deacon@....com, lgirdwood@...il.com,
        broonie@...nel.org, khilman@...libre.com, arnd@...db.de,
        gregory.clement@...e-electrons.com, horms+renesas@...ge.net.au,
        olof@...om.net, thomas.petazzoni@...e-electrons.com,
        yamada.masahiro@...ionext.com, riku.voipio@...aro.org,
        treding@...dia.com, krzk@...nel.org, eric@...olt.net,
        damm+renesas@...nsource.se, ard.biesheuvel@...aro.org,
        linus.walleij@...aro.org, geert+renesas@...der.be,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, hw.wangxiaoyin@...ilicon.com
Subject: Re: [PATCH v4 4/8] mfd: hi6421-pmic: add support for HiSilicon
 Hi6421v530

On Tue, 06 Jun 2017, Guodong Xu wrote:

> Add support for HiSilicon Hi6421v530 PMIC. Hi6421v530 communicates with
> main SoC via memory-mapped I/O.
> 
> Hi6421v530 and Hi6421 are PMIC chips from the same vendor, HiSilicon,
> but at different revisions. They share the same memory-mapped I/O
> design. They differ in integrated devices, such as regulator details,
> LDO voltage points.
> 
> Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@...ilicon.com>
> Signed-off-by: Guodong Xu <guodong.xu@...aro.org>
> ---
>  drivers/mfd/hi6421-pmic-core.c  | 68 ++++++++++++++++++++++++++++++-----------
>  include/linux/mfd/hi6421-pmic.h |  5 +++
>  2 files changed, 55 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mfd/hi6421-pmic-core.c b/drivers/mfd/hi6421-pmic-core.c
> index b1139d4..4568a43 100644
> --- a/drivers/mfd/hi6421-pmic-core.c
> +++ b/drivers/mfd/hi6421-pmic-core.c

[...]

>  static int hi6421_pmic_probe(struct platform_device *pdev)
>  {
>  	struct hi6421_pmic *pmic;
>  	struct resource *res;
> +	const struct of_device_id *id;
> +	const struct mfd_cell *subdevs;
>  	void __iomem *base;
> -	int ret;
> +	int n_subdevs, ret;
> +
> +	id = of_match_device(of_hi6421_pmic_match, &pdev->dev);
> +	if (!id)
> +		return -EINVAL;
>  
>  	pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
>  	if (!pmic)
> @@ -57,18 +80,33 @@ static int hi6421_pmic_probe(struct platform_device *pdev)
>  		return PTR_ERR(pmic->regmap);
>  	}
>  
> -	/* set over-current protection debounce 8ms */
> -	regmap_update_bits(pmic->regmap, HI6421_OCP_DEB_CTRL_REG,
> +	platform_set_drvdata(pdev, pmic);
> +
> +	switch ((unsigned long)id->data) {

Whilst this is not a blocker, it would be nicer to place this into a
'type' variable, in order to clarify what data you are using.

> +	case HI6421:
> +		/* set over-current protection debounce 8ms */
> +		regmap_update_bits(pmic->regmap, HI6421_OCP_DEB_CTRL_REG,
>  				(HI6421_OCP_DEB_SEL_MASK
>  				 | HI6421_OCP_EN_DEBOUNCE_MASK
>  				 | HI6421_OCP_AUTO_STOP_MASK),
>  				(HI6421_OCP_DEB_SEL_8MS
>  				 | HI6421_OCP_EN_DEBOUNCE_ENABLE));
>  
> -	platform_set_drvdata(pdev, pmic);
> +		subdevs = hi6421_devs;
> +		n_subdevs = ARRAY_SIZE(hi6421_devs);
> +		break;
> +	case HI6421_V530:
> +		subdevs = hi6421v530_devs;
> +		n_subdevs = ARRAY_SIZE(hi6421v530_devs);
> +		break;
> +	default:
> +		dev_err(&pdev->dev, "Unknown device type %ld\n",
> +						(unsigned long)id->data);
> +		return -EINVAL;
> +	}
>  
> -	ret = devm_mfd_add_devices(&pdev->dev, 0, hi6421_devs,
> -				   ARRAY_SIZE(hi6421_devs), NULL, 0, NULL);
> +	ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
> +				   subdevs, n_subdevs, NULL, 0, NULL);
>  	if (ret) {
>  		dev_err(&pdev->dev, "Failed to add child devices: %d\n", ret);
>  		return ret;
> @@ -77,16 +115,10 @@ static int hi6421_pmic_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static const struct of_device_id of_hi6421_pmic_match_tbl[] = {
> -	{ .compatible = "hisilicon,hi6421-pmic", },
> -	{ },
> -};
> -MODULE_DEVICE_TABLE(of, of_hi6421_pmic_match_tbl);
> -
>  static struct platform_driver hi6421_pmic_driver = {
>  	.driver = {
> -		.name	= "hi6421_pmic",
> -		.of_match_table = of_hi6421_pmic_match_tbl,
> +		.name = "hi6421_pmic",
> +		.of_match_table = of_hi6421_pmic_match,
>  	},
>  	.probe	= hi6421_pmic_probe,
>  };
> diff --git a/include/linux/mfd/hi6421-pmic.h b/include/linux/mfd/hi6421-pmic.h
> index 587273e..2457438 100644
> --- a/include/linux/mfd/hi6421-pmic.h
> +++ b/include/linux/mfd/hi6421-pmic.h
> @@ -38,4 +38,9 @@ struct hi6421_pmic {
>  	struct regmap		*regmap;
>  };
>  
> +enum hi6421_type {
> +	HI6421      = 1,
> +	HI6421_V530 = 2,
> +};
> +

As programmers we usually start counting at 0.  Then you can rely on
the C standard to populate the remaining values.

Something like:

enum hi6421_type {
	HI6421 = 0,
	HI6421_V530,
};

... is more normal.

>  #endif		/* __HI6421_PMIC_H */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog