linux-kernel - Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout

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: <96c54beb-228c-d606-5b9c-613ee2bc5e70@rocketmail.com>
Date:   Sun, 5 Mar 2023 17:10:05 +0100
From:   Jakob Hauser <jahau@...ketmail.com>
To:     Lee Jones <lee@...nel.org>
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

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.

[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