Message-ID: <20230306091843.GE9667@google.com>
Date:   Mon, 6 Mar 2023 09:18:43 +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 Sun, 05 Mar 2023, Jakob Hauser wrote:

> Hi Lee,
> 
> On 05.03.23 11:47, Lee Jones wrote:
> > 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?
> 
> While not having a datasheet for RT5033 available, in similar products like
> RT9455 the register is called "Device ID", the first part of that is
> "VENDOR_ID" and the second part "CHIP_REV", [1] page 23 top. Or in RT5036
> preliminary data sheet the register is called "ID", the first part
> "VENDOR_ID" and the second part "CHIP_REV_ID", [2] page 27 top.
> 
> I wanted to avoid confusion between "dev_id" and "chip_rev". Therefore in
> the patch it's written as getting some "data" from the register and extract
> "chip_rev" from that data.
> 
> I could change it to "reg_data"? Or something in that direction? I still
> think that getting "chip_rev" out of "dev_id" would be confusing.

You're reading from a register called RT5033_REG_DEVICE_ID.  I don't see
any reason why the variable you read into can't reflect that.

> [1] https://www.richtek.com/assets/product_file/RT9455/DS9455-00.pdf
> [2] https://media.digikey.com/pdf/Data%20Sheets/Richtek%20PDF/RT5036%20%20Preliminary.pdf
> 
> > 
> > > +	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?
> 
> As described above, the data "dev_id" consists of a first part which is a
> vendor ID and a second part which is the chip revision.
> 
> The vendor ID is of no interest here. These bits[7:4] contain binary value
> 1000 (decimal value 8) and I'd expect that to be the same on all RT5033
> devices.
> 
> Contrary to this, the chip revision is an important information. The
> downstream Android driver applies some quirks depending on the chip
> revision. This seemed not yet necessary in the upstream driver. So far I've
> seen chip rev. 6 on samsung-serranove & samsung-e7 and chip rev. 5 on
> samsung-grandmax & samsung-fortuna, the behavior of the chip revisions are
> slightly different.
> 
> Accordingly, the downstream Android driver as well reads [3] and prints [4]
> the chip revision only – confusingly calling it "rev id".
> [3] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L484
> [4] https://github.com/msm8916-mainline/linux-downstream/blob/GT-I9195I/drivers/mfd/rt5033_core.c#L486
> 
> > >   	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
> 
> What does the "g" mean, was this on purpose? I didn't get the meaning of it.
> 
> > >   /* 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
> > > 
> > 
> 
> Kind regards,
> Jakob

-- 
Lee Jones [李琼斯]

Powered by blists - more mailing lists