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: <0109018eeba05ad9-f837b6c7-70cf-4a2a-9aeb-3ef245e18862-000000@ap-south-1.amazonses.com>
Date: Wed, 17 Apr 2024 10:35:38 +0000
From: Bhargav Raviprakash <bhargav.r@...s.com>
To: lee@...nel.org
Cc: arnd@...db.de, bhargav.r@...s.com, broonie@...nel.org, 
	conor+dt@...nel.org, devicetree@...r.kernel.org, eblanc@...libre.com, 
	gregkh@...uxfoundation.org, jpanis@...libre.com, kristo@...nel.org, 
	krzysztof.kozlowski+dt@...aro.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: [PATCH v6 03/11] mfd: tps6594: add regmap config in match data

Hello,

On Tue, 16 Apr 2024 13:25:04 +0100, Lee Jones wrote:

> > Hello,
> > 
> > On Wed, 14 Feb 2024 10:10:17 -0800, Lee Jones wrote:
> > > On Mon, 08 Apr 2024, Bhargav Raviprakash wrote:
> > > 
> > > > Introduces a new struct tps6594_match_data. This struct holds fields for
> > > > chip id and regmap config. Using this struct in of_device_id data field.
> > > > This helps in adding support for TPS65224 PMIC.
> > > > 
> > > > Signed-off-by: Bhargav Raviprakash <bhargav.r@...s.com>
> > > > Acked-by: Julien Panis <jpanis@...libre.com>
> > > > ---
> > > >  drivers/mfd/tps6594-i2c.c   | 24 ++++++++++++++++--------
> > > >  drivers/mfd/tps6594-spi.c   | 24 ++++++++++++++++--------
> > > >  include/linux/mfd/tps6594.h | 11 +++++++++++
> > > >  3 files changed, 43 insertions(+), 16 deletions(-)
> > > > 
> > > > diff --git a/drivers/mfd/tps6594-i2c.c b/drivers/mfd/tps6594-i2c.c
> > > > index c125b474b..9e2ed48b7 100644
> > > > --- a/drivers/mfd/tps6594-i2c.c
> > > > +++ b/drivers/mfd/tps6594-i2c.c
> > > > @@ -192,10 +192,16 @@ static const struct regmap_config tps6594_i2c_regmap_config = {
> > > >  	.write = tps6594_i2c_write,
> > > >  };
> > > >  
> > > > +static const struct tps6594_match_data match_data[] = {
> > > > +	[TPS6594] = {TPS6594, &tps6594_i2c_regmap_config},
> > > > +	[TPS6593] = {TPS6593, &tps6594_i2c_regmap_config},
> > > > +	[LP8764] = {LP8764, &tps6594_i2c_regmap_config},
> > > 
> > > Nit: There should be spaces after the '{' and before the '}'.
> > > 
> > 
> > Sure! will fix it in the next version.
> > 
> > > > +};
> > > > +
> > > >  static const struct of_device_id tps6594_i2c_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,tps6594-q1", .data = &match_data[TPS6594], },
> > > > +	{ .compatible = "ti,tps6593-q1", .data = &match_data[TPS6593], },
> > > > +	{ .compatible = "ti,lp8764-q1",  .data = &match_data[LP8764], },
> > > 
> > > Not keen on this.  Why do you pass the regmap data through here and
> > > leave everything else to be matched on device ID?  It would be better to
> > > keep passing the device ID through and match everything off of that.
> > > 
> > > 
> > > -- 
> > > Lee Jones [李琼斯]
> > 
> > Thanks for the feedback!
> > 
> > These changes were made because of the following message:
> > https://lore.kernel.org/all/7hcysy6ho6.fsf@baylibre.com/
> > 
> > Please let us know which one to follow.
> 
> Right, except this doesn't eliminate "any \"if (chip_id)\" checking".
> Instead you have a hodge-podge of passing a little bit of (Regmap) data
> via match and the rest via "if (chip_id)".  So either pass all platform
> type data via .data or just the chip ID.  My suggestion 99% of the time
> is the latter.

Got it. Thanks! Will revert back to .data having chip_id.

Regards,
Bhargav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ