linux-kernel - Re: [RESEND PATCH v1 05/13] mfd: tps6594-spi: Add TI TPS65224 PMIC SPI

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] [day] [month] [year] [list]

Message-Id: <20240222084309.6008-1-bhargav.r@ltts.com>
Date: Thu, 22 Feb 2024 14:13:09 +0530
From: Bhargav Raviprakash <bhargav.r@...s.com>
To: khilman@...nel.org
Cc: arnd@...db.de,
	bhargav.r@...s.com,
	broonie@...nel.org,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	gregkh@...uxfoundation.org,
	jpanis@...libre.com,
	kristo@...nel.org,
	krzysztof.kozlowski+dt@...aro.org,
	lee@...nel.org,
	lgirdwood@...il.com,
	linus.walleij@...aro.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	m.nirmaladevi@...s.com,
	nm@...com,
	robh+dt@...nel.org,
	vigneshr@...com
Subject: Re: [RESEND PATCH v1 05/13] mfd: tps6594-spi: Add TI TPS65224 PMIC SPI

Hello Kevin,
On Wed, 14 Feb 2024 10:10:17 -0800, Kevin wrote:
> Bhargav Raviprakash <bhargav.r@...s.com> writes:
> 
> > Add support for TPS65224 PMIC in the TPS6594 driver as they share
> > significant functional overlap.
> >
> > Signed-off-by: Bhargav Raviprakash <bhargav.r@...s.com>
> > ---
> >  drivers/mfd/tps6594-spi.c | 16 ++++++++++------
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mfd/tps6594-spi.c b/drivers/mfd/tps6594-spi.c
> > index 5afb1736f..7ec66d31b 100644
> > --- a/drivers/mfd/tps6594-spi.c
> > +++ b/drivers/mfd/tps6594-spi.c
> > @@ -1,6 +1,6 @@
> >  // SPDX-License-Identifier: GPL-2.0
> >  /*
> > - * SPI access driver for TI TPS6594/TPS6593/LP8764 PMICs
> > + * SPI access driver for TI TPS65224/TPS6594/TPS6593/LP8764 PMICs
> >   *
> >   * Copyright (C) 2023 BayLibre Incorporated - https://www.baylibre.com/
> >   */
> > @@ -66,7 +66,7 @@ static int tps6594_spi_reg_write(void *context, unsigned int reg, unsigned int v
> >  	return spi_write(spi, buf, count);
> >  }
> >  
> > -static const struct regmap_config tps6594_spi_regmap_config = {
> > +static struct regmap_config tps6594_spi_regmap_config = {
> >  	.reg_bits = 16,
> >  	.val_bits = 8,
> >  	.max_register = TPS6594_REG_DWD_FAIL_CNT_REG,
> > @@ -81,6 +81,7 @@ static const struct of_device_id tps6594_spi_of_match_table[] = {
> >  	{ .compatible = "ti,tps6594-q1", .data = (void *)TPS6594, },
> >  	{ .compatible = "ti,tps6593-q1", .data = (void *)TPS6593, },
> >  	{ .compatible = "ti,lp8764-q1",  .data = (void *)LP8764,  },
> > +	{ .compatible = "ti,tps65224-q1", .data = (void *)TPS65224, },
> >  	{}
> >  };
> >  MODULE_DEVICE_TABLE(of, tps6594_spi_of_match_table);
> > @@ -101,15 +102,18 @@ static int tps6594_spi_probe(struct spi_device *spi)
> >  	tps->reg = spi_get_chipselect(spi, 0);
> >  	tps->irq = spi->irq;
> >  
> > -	tps->regmap = devm_regmap_init(dev, NULL, spi, &tps6594_spi_regmap_config);
> > -	if (IS_ERR(tps->regmap))
> > -		return dev_err_probe(dev, PTR_ERR(tps->regmap), "Failed to init regmap\n");
> > -
> >  	match = of_match_device(tps6594_spi_of_match_table, dev);
> >  	if (!match)
> >  		return dev_err_probe(dev, -EINVAL, "Failed to find matching chip ID\n");
> >  	tps->chip_id = (unsigned long)match->data;
> >  
> > +	if (tps->chip_id == TPS65224)
> > +		tps6594_spi_regmap_config.volatile_table = &tps65224_volatile_table;
> 
> Similar to my comment on the i2c series, but to be more specific:
> 
> Rather than use the .data pointer in the of_match_table as simply a
> chip_id, instead make that into a struct that can contain chip-specific
> values/pointers etc, and then each compatible can have a custom struct
> (if needed.)
> 
> This way, at probe/match time, all the chip-specific data is setup using
> that struct, so that at runtime, there doesn't need to be any "if
> (chip_id)" checking.
> 
> Kevin

Thanks for the feedback!
We will implement the same in the next version.

Regards,
Bhargav