linux-kernel - Re: [PATCH 04/13] a2b: add AD24xx I2C interface driver

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: <rfpiw5sgrcqmfxtcjjvt33gsyv62i25xt54vo26d5ori2uptkl@b2az7r3z54gm>
Date: Tue, 21 May 2024 08:31:19 +0000
From: Alvin Šipraga <ALSI@...g-olufsen.dk>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Alvin Šipraga <alvin@...s.dk>, Mark Brown
	<broonie@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
	<brgl@...ev.pl>, Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela
	<perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Michael Turquette
	<mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Andi Shyti
	<andi.shyti@...nel.org>, Saravana Kannan <saravanak@...gle.com>, Emil
 Abildgaard Svendsen <EMAS@...g-olufsen.dk>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>, "linux-sound@...r.kernel.org"
	<linux-sound@...r.kernel.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, "linux-i2c@...r.kernel.org"
	<linux-i2c@...r.kernel.org>, Alvin Šipraga
	<ALSI@...g-olufsen.dk>
Subject: Re: [PATCH 04/13] a2b: add AD24xx I2C interface driver

On Fri, May 17, 2024 at 04:49:20PM GMT, Wolfram Sang wrote:
> 
> > +	/*
> > +	 * Enforce some basic assumptions this function makes about the
> > +	 * transfer. If this proves insufficient, some more complex logic will
> > +	 * be needed.
> > +	 */
> > +	if (num > 2 || (num == 2 && msgs[0].addr != msgs[1].addr))
> > +		return -EOPNOTSUPP;
> 
> As you populated 'ad24xx_i2c_adapter_quirks' in the I2C driver, you can
> drop this. The I2C core will do the checks for you.
>

The i2c_xfer function here is also available as a general A2B API, see
a2b.h:

  int a2b_node_i2c_xfer(struct a2b_node *node, struct i2c_msg *msgs, int num);

This is used by the beo-shape-node.c driver submitted later in this
series to perform a firmware update of a more peculiar A2B hardware.
In this case it doesn't factor through the codepath you mention, hence
this check.

It's conceivable that there will be other such cases in the future as
well. ADI for example prescribes a specific EEPROM address where device
identification data can be stored with a well-defined format. In the
event that the driver should support some kind of device type detection,
it will also have to perform some I2C transfers out-of-band like this.