linux-kernel - Re: [PATCH v3 5/6] soc: samsung: exynos-chipid: add google,gs101-otp support

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: <a7af16e25ad6403e867a32d9d0f26931ac40199d.camel@linaro.org>
Date: Mon, 22 Dec 2025 14:39:20 +0000
From: André Draszik <andre.draszik@...aro.org>
To: Tudor Ambarus <tudor.ambarus@...aro.org>, Rob Herring <robh@...nel.org>,
  Krzysztof Kozlowski	 <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Alim Akhtar	 <alim.akhtar@...sung.com>, Peter
 Griffin <peter.griffin@...aro.org>,  Srinivas Kandagatla	 <srini@...nel.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, semen.protsenko@...aro.org, 
	willmcvicker@...gle.com, kernel-team@...roid.com,
 devicetree@...r.kernel.org, 	linux-arm-kernel@...ts.infradead.org,
 linux-samsung-soc@...r.kernel.org, 	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/6] soc: samsung: exynos-chipid: add
 google,gs101-otp support

Hi Tudor,

On Mon, 2025-12-22 at 16:12 +0200, Tudor Ambarus wrote:
> Hi!
> 
> On 12/19/25 5:10 PM, André Draszik wrote:
> 
> cut
> 
> > >  static const char *exynos_product_id_to_name(unsigned int product_id)
> > > @@ -93,19 +99,53 @@ static int exynos_chipid_get_chipid_info(struct device *dev,
> > >  		return dev_err_probe(dev, ret, "failed to read Product ID\n");
> > >  	soc_info->product_id = val & EXYNOS_MASK;
> > >  
> > > -	if (data->rev_reg != EXYNOS_CHIPID_REG_PRO_ID) {
> > > -		ret = regmap_read(regmap, data->rev_reg, &val);
> > > +	if (data->sub_rev_reg == EXYNOS_CHIPID_REG_PRO_ID) {
> > > +		/* exynos4210 case */
> > > +		main_rev = (val >> data->main_rev_shift) & EXYNOS_REV_PART_MASK;
> > > +		sub_rev = (val >> data->sub_rev_shift) & EXYNOS_REV_PART_MASK;
> > > +	} else {
> > > +		unsigned int val2;
> > > +
> > > +		ret = regmap_read(regmap, data->sub_rev_reg, &val2);
> > >  		if (ret < 0)
> > >  			return dev_err_probe(dev, ret,
> > >  					     "failed to read revision\n");
> > > +
> > > +		if (data->main_rev_reg == EXYNOS_CHIPID_REG_PRO_ID)
> > > +			/* gs101 case */
> > > +			main_rev = (val >> data->main_rev_shift) & EXYNOS_REV_PART_MASK;
> > > +		else
> > > +			/* exynos850 case */
> > > +			main_rev = (val2 >> data->main_rev_shift) & EXYNOS_REV_PART_MASK;
> > > +
> > > +		sub_rev = (val2 >> data->sub_rev_shift) & EXYNOS_REV_PART_MASK;
> > 
> > The above looks a little fragile, comparing register offsets between different
> > hardware platforms and macros, but I guess it works for now and isn't really
> > much different to before.
> 
> Right, I thought we'll get this in faster if I keep the old style.
> 
> I can introduce a drv_data->get_chipid_info() method and add methods for exynos4210
> and exynos850 before adding the g101 support. It duplicated a bit the code when I
> tried it, and I chose to keep it as it is now. Happy to switch to a drv data method
> if you prefer, just say.

The above was simply an observation, and as mentioned it's not really worse than
before, therefore OK to leave from my pov.


Cheers,
A.