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]
Date:	Tue, 15 Nov 2011 19:02:39 +0000
From:	Tabi Timur-B04825 <B04825@...escale.com>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Guenter Roeck <guenter.roeck@...csson.com>,
	Ben Dooks <ben-linux@...ff.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tang Yuantian-B29983 <B29983@...escale.com>
Subject: Re: [PATCH] i2c/busses: (mpc) Add support for SMBUS_READ_BLOCK_DATA

On Tue, Nov 15, 2011 at 2:54 AM, Jean Delvare <khali@...ux-fr.org> wrote:

> This needs careful testing (which I can't do.)

I can test these patches, so please CC me on them.

> There may have been a
> reason why the read was done after the writes. Swapping the commands
> may be the wrong thing to do. The dummy read earlier in this function
> suggests that maybe changes to CCR do not take effect until you read
> from (or write to) the DR register.

Unfortunately, I don't know enough about the I2C protocol to answer
this, but I can provide this description on the DR register from the
reference manual:

         Transmission starts when an address and the R/W bit are
written to the data register and the I2C interface
         performs as the master. A data transfer is initiated when
data is written to the I2CDR. The most significant bit
         is sent first in both cases. In master receive mode, reading
the data register allows the read to occur, but also
         allows the I2C module to receive the next byte of data on the
I2C interface. In slave mode, the same function
         is available after it is addressed. Note that in both master
receive and slave receive modes, the very first read
         is always a dummy read.

> Can't the above be rewritten to keep the order of the commands as it
> was before? AFAICS it would only take one or two extra tests.

I think it's very important to keep the order as-is, if at all
possible.  This driver is very old and the hardware is used on all of
our SOCs, dating back several years.  It would be a nightmare to test
it all over again.

-- 
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ