Message-ID: <66db70ea-9605-58c3-6f2c-2195128193ea@rocketmail.com>
Date:   Mon, 6 Mar 2023 23:57:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.2
Subject: Re: [PATCH 02/10] mfd: rt5033: Fix chip revision readout
To:     Lee Jones <lee@kernel.org>
Cc:     Sebastian Reichel <sre@kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Mark Brown <broonie@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Beomho Seo <beomho.seo@samsung.com>,
        Chanwoo Choi <cw00.choi@samsung.com>,
        Stephan Gerhold <stephan@gerhold.net>,
        Raymond Hackley <raymondhackley@protonmail.com>,
        linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht
References: <cover.1677620677.git.jahau@rocketmail.com>
 <a667a64d0cbeef00baed2d4b117ba9f50eaf3988.1677620677.git.jahau@rocketmail.com>
 <20230305104704.GG2574592@google.com>
 <96c54beb-228c-d606-5b9c-613ee2bc5e70@rocketmail.com>
 <20230306091843.GE9667@google.com>
Content-Language: en-US
From:   Jakob Hauser <jahau@rocketmail.com>
In-Reply-To: <20230306091843.GE9667@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Lee,

On 06.03.23 10:18, Lee Jones wrote:
> 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@rocketmail.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.

OK, I'll use "dev_id" and "chip_rev" for the variable names.

...

Kind regards,
Jakob