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: <ZxpZfgsf-KldiX4w@black.fi.intel.com>
Date: Thu, 24 Oct 2024 17:28:14 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Rayyan Ansari <rayyan@...ari.sh>, linux-arm-msm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-iio@...r.kernel.org,
	Bjorn Andersson <andersson@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jonathan Cameron <jic23@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Robert Yang <decatf@...il.com>, Rob Herring <robh@...nel.org>,
	Sean Rhodes <sean@...rlabs.systems>
Subject: Re: [PATCH 2/3] iio: accel: kxcjk-1013: Add support for KX022-1020

On Mon, Jul 15, 2024 at 10:30:46AM +0200, Hans de Goede wrote:
> On 7/14/24 7:33 PM, Rayyan Ansari wrote:
> > Add compatible for the KX022-1020 accelerometer [1] using the
> > KX022-1023 [2] register map as both have an identical i2c interface.
> > 
> > [1]: https://kionixfs.azureedge.net/en/datasheet/KX022-1020%20Specifications%20Rev%2012.0.pdf
> > [2]: https://kionixfs.azureedge.net/en/datasheet/KX023-1025%20Specifications%20Rev%2012.0.pdf
> > 
> > Signed-off-by: Rayyan Ansari <rayyan@...ari.sh>
> 
> Thanks, patch looks good to me:
> 
> Reviewed-by: Hans de Goede <hdegoede@...hat.com>

Note, this patch broke kx231025 case...

> >  	KXCJ91008,
> >  	KXTJ21009,
> >  	KXTF9,
> > +	KX0221020,
> >  	KX0231025,
> >  	KX_MAX_CHIPS /* this must be last */
> >  };

...because this enum is used of ODR startup timeout settings which
are all moved now to be 0 and new ID inherited the timeouts from
the KX0231025 case.

Since I have been looking into the driver, and I have a few patches
coming, I propose to do the following (as it's still ODR data being
missed) to:
1) revert this one;
2) apply my set;
3) re-apply this with the fixed data.

Another approach can be done (but probably not by me) is to move the ID
to the proper location, add ODR startup timeouts or explain why it's not
needed and then apply my patch.

But, taking into account that we are almost at -rc5 and I want my stuff
not to be postponed, I tend to follow the first approach.

Opinions, comments?

P.S. FWIW, my set will include switching this driver to use chip_info
structure so the similar mistakes won't happen again, that's also why
I prefer the first approach I listed above.

-- 
With Best Regards,
Andy Shevchenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ