From: Roger Quadros <rogerq@kernel.org>
To: Shree Ramamoorthy <s-ramamoorthy@ti.com>,
aaro.koskinen@iki.fi, andreas@kemnade.info, khilman@baylibre.com,
tony@atomide.com, lee@kernel.org, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: m-leonard@ti.com, praneeth@ti.com, christophe.jaillet@wanadoo.fr
Subject: Re: [PATCH v2 2/2] mfd: tps65215: Remove regmap_read check
Date: Tue, 7 Jan 2025 14:47:38 +0200 [thread overview]
Message-ID: <107f9bb2-341c-48ef-ae4d-ef45e61fce6c@kernel.org> (raw)
In-Reply-To: <630b8727-cffa-4118-93e4-2dd8ce97ebde@ti.com>
On 07/01/2025 00:18, Shree Ramamoorthy wrote:
> Hi,
>
> On 1/4/2025 12:16 PM, Roger Quadros wrote:
>>
>> On 04/01/2025 00:57, Shree Ramamoorthy wrote:
>>> The chipid macro/variable and regmap_read function call is not needed
>>> because the TPS65219_REG_TI_DEV_ID register value is not a consistent value
>>> across TPS65219 PMIC config versions. Reading from the DEV_ID register
>>> without a consistent value to compare it to isn't useful. There isn't a
>>> way to verify the match data ID is the same ID read from the DEV_ID device
>>> register. 0xF0 isn't a DEV_ID value consistent across TPS65219 NVM
>>> configurations.
>>>
>>> For TPS65215, there is a consistent value in bits 5-0 of the DEV_ID
>>> register. However, there are other error checks in place within probe()
>>> that apply to both PMICs rather than keeping this isolated check for one
>>> PMIC.
>>>
>>> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com>
>> In that case this could be squashed with 1?
>
> Since this change does not have to do with TPS65215 support directly
> and is a different type of change, I wanted to keep this patch separate.
> I can instead have this patch be first, then the MFD add TPS65215 support
> will follow this to avoid any confusion about regmap_read being modified then removed.
>
OK thanks.
>>> ---
>>> drivers/mfd/tps65219.c | 6 ------
>>> include/linux/mfd/tps65219.h | 2 --
>>> 2 files changed, 8 deletions(-)
>>>
>>> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
>>> index 816b271990a2..d3267bf7cd77 100644
>>> --- a/drivers/mfd/tps65219.c
>>> +++ b/drivers/mfd/tps65219.c
>>> @@ -382,12 +382,6 @@ static int tps65219_probe(struct i2c_client *client)
>>> if (ret)
>>> return ret;
>>>
>>> - ret = regmap_read(tps->regmap, TPS65219_REG_TI_DEV_ID, &tps->chip_id);
>>> - if (ret) {
>>> - dev_err(tps->dev, "Failed to read device ID: %d\n", ret);
>>> - return ret;
>>> - }
>>> -
>>> ret = devm_mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO,
>>> pmic->cells, pmic->n_cells,
>>> NULL, 0, regmap_irq_get_domain(tps->irq_data));
>>> diff --git a/include/linux/mfd/tps65219.h b/include/linux/mfd/tps65219.h
>>> index 9892b6e4c85c..535115bfa4a4 100644
>>> --- a/include/linux/mfd/tps65219.h
>>> +++ b/include/linux/mfd/tps65219.h
>>> @@ -15,8 +15,6 @@
>>> #include <linux/regmap.h>
>>> #include <linux/regulator/driver.h>
>>>
>>> -/* TPS chip id list */
>>> -#define TPS65219 0xF0
>>> /* Chip id list*/
>>> enum pmic_id {
>>> TPS65215,
>> Looking at TRM, TPS65215 device_id is 0x15 and TPS6521901 device_id is 0x00.
>>
>> shouldn't we use that here as well?
>
> The device_id value set varies across TPS65219 hardware versions.
Do you foresee any software quirks being applied for specific versions of
TPS65219? If not then probably not worth the effort to keep track of all the
versions.
> Having the device_id as the chip_id differentiator will fail for TPS65219,
> even though the system engineers have now kept the TPS65215 device_id value
> consistent across all hardware versions.
>
--
cheers,
-roger
next prev parent reply other threads:[~2025-01-07 12:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 22:57 [PATCH v2 0/2] Add TI TPS65215 PMIC MFD Support Shree Ramamoorthy
2025-01-03 22:57 ` [PATCH v2 1/2] mfd: tps65215: Add support for TI TPS65215 PMIC Shree Ramamoorthy
2025-01-04 11:30 ` Christophe JAILLET
2025-01-06 22:13 ` Shree Ramamoorthy
2025-01-04 18:10 ` Roger Quadros
2025-01-06 22:20 ` Shree Ramamoorthy
2025-01-03 22:57 ` [PATCH v2 2/2] mfd: tps65215: Remove regmap_read check Shree Ramamoorthy
2025-01-04 18:16 ` Roger Quadros
2025-01-06 22:18 ` Shree Ramamoorthy
2025-01-07 12:47 ` Roger Quadros [this message]
2025-01-07 18:45 ` Shree Ramamoorthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=107f9bb2-341c-48ef-ae4d-ef45e61fce6c@kernel.org \
--to=rogerq@kernel.org \
--cc=aaro.koskinen@iki.fi \
--cc=andreas@kemnade.info \
--cc=christophe.jaillet@wanadoo.fr \
--cc=khilman@baylibre.com \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=m-leonard@ti.com \
--cc=praneeth@ti.com \
--cc=s-ramamoorthy@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox