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:   Sun, 5 Mar 2023 10:47:04 +0000
From:   Lee Jones <lee@...nel.org>
To:     Jakob Hauser <jahau@...ketmail.com>
Cc:     Sebastian Reichel <sre@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Beomho Seo <beomho.seo@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Stephan Gerhold <stephan@...hold.net>,
        Raymond Hackley <raymondhackley@...tonmail.com>,
        linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout

On Tue, 28 Feb 2023, Jakob Hauser wrote:

> After reading the data from the DEVICE_ID register, mask 0x0f needs to be
> applied to extract the revision of the chip [1].
> 
> The other part of the DEVICE_ID register, mask 0xf0, is a vendor identification
> code. That's how it is set up at similar products of Richtek, e.g. RT9455 [2]
> page 21 top.
> 
> [1] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
> [2] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
> 
> Signed-off-by: Jakob Hauser <jahau@...ketmail.com>
> ---
>  drivers/mfd/rt5033.c               | 8 +++++---
>  include/linux/mfd/rt5033-private.h | 4 ++++
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> index 8029d444b794..d32467174cb5 100644
> --- a/drivers/mfd/rt5033.c
> +++ b/drivers/mfd/rt5033.c
> @@ -55,7 +55,8 @@ static const struct regmap_config rt5033_regmap_config = {
>  static int rt5033_i2c_probe(struct i2c_client *i2c)
>  {
>  	struct rt5033_dev *rt5033;
> -	unsigned int dev_id;
> +	unsigned int data;

In terms of nomenclature, this is a regression.

'data' is a terrible variable name.  Why not keep it as-is?

> +	unsigned int chip_rev;
>  	int ret;
>  
>  	rt5033 = devm_kzalloc(&i2c->dev, sizeof(*rt5033), GFP_KERNEL);
> @@ -73,12 +74,13 @@ static int rt5033_i2c_probe(struct i2c_client *i2c)
>  		return PTR_ERR(rt5033->regmap);
>  	}
>  
> -	ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &dev_id);
> +	ret = regmap_read(rt5033->regmap, RT5033_REG_DEVICE_ID, &data);
>  	if (ret) {
>  		dev_err(&i2c->dev, "Device not found\n");
>  		return -ENODEV;
>  	}
> -	dev_info(&i2c->dev, "Device found Device ID: %04x\n", dev_id);
> +	chip_rev = data & RT5033_CHIP_REV_MASK;
> +	dev_info(&i2c->dev, "Device found (rev. %d)\n", chip_rev);

Why not print both?

>  	ret = regmap_add_irq_chip(rt5033->regmap, rt5033->irq,
>  			IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h
> index 2d1895c3efbf..d18cd4572208 100644
> --- a/include/linux/mfd/rt5033-private.h
> +++ b/include/linux/mfd/rt5033-private.h
> @@ -71,6 +71,10 @@ enum rt5033_reg {














g
>  /* RT5033 CHGCTRL2 register */
>  #define RT5033_CHGCTRL2_CV_MASK		0xfc
>  
> +/* RT5033 DEVICE_ID register */
> +#define RT5033_VENDOR_ID_MASK		0xf0
> +#define RT5033_CHIP_REV_MASK		0x0f
> +
>  /* RT5033 CHGCTRL3 register */
>  #define RT5033_CHGCTRL3_CFO_EN_MASK	0x40
>  #define RT5033_CHGCTRL3_TIMER_MASK	0x38
> -- 
> 2.39.1
> 

-- 
Lee Jones [李琼斯]

Powered by blists - more mailing lists