linux-kernel - Re: [PATCH 3/6] mfd: 88pm860x: enhance lock on i2c transaction

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:	Fri, 13 May 2011 23:00:24 +0800
From:	Haojian Zhuang <haojian.zhuang@...il.com>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	Haojian Zhuang <haojian.zhuang@...vell.com>,
	linux-kernel@...r.kernel.org, lrg@...mlogic.co.uk,
	broonie@...nsource.wolfsonmicro.com, a.zummo@...ertech.it,
	khali@...ux-fr.org, ben-linux@...ff.org
Subject: Re: [PATCH 3/6] mfd: 88pm860x: enhance lock on i2c transaction

On Fri, May 13, 2011 at 10:20 PM, Samuel Ortiz <sameo@...ux.intel.com> wrote:
> Hi Haojian,
>
> On Fri, May 06, 2011 at 05:21:22PM +0800, Haojian Zhuang wrote:
>> Accessing test page in 88pm860x is a sequence of read/write on i2c bus.
>> Bus lock is used in each small i2c transaction. But it may result the
>> whole sequence interrupted by other i2c client transaction.
> Sure, but what you mainly want is your MFD i2c IO calls to be serialized, and
> that's already being taken care of by the current code.
> Are other i2c clients (non MFD ones) touching the same i2c registers than the
> MFD ones ?
>
Other process may not access the same register. But they may access same i2c
bus. What I did is used to protect bus operation.

Even accessing one register in test page is composed by a sequence of accessing
test page.

For example, read one byte of 0xbc in test page.
1) i2c read zero byte from 0xFA
2) i2c read zero byte from 0xFB
3) i2c read zero byte from 0xFF
4) i2c read one byte from 0xbc (desired operation)
5) i2c read zero byte from 0xFC

Step #1 to #3 is used to enter test page mode. Step 4 is used to read
desired data.
Step #5 is used to exit test page mode. If all these five steps are
using standard
i2c read operation, bus lock in i2c driver will be held and released
five times. If another
process is also accessing i2c bus, it may interrupt the sequence and
import error to
pmic.

So the potential issue is releasing bus lock too early. If I just add
bus lock protection
in test page operation, I'll meet dead lock issue since bus lock will
be used in standard
i2c operation. I have to implement my i2c frame and send it out directly.

Best Regards
Haojian
--
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/