linux-kernel - Re: Question about patch "i2c: omap: resize fifos before each message"

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: <7602A84A-43B2-4C22-ACFA-FEA0640A6B7D@gmail.com>
Date:	Wed, 3 Dec 2014 22:01:33 +0300
From:	Alexander Kochetkov <al.kochet@...il.com>
To:	balbi@...com
Cc:	Kevin Hilman <khilman@...nel.org>,
	Tony Lindgren <tony@...mide.com>,
	Wolfram Sang <wsa@...-dreams.de>,
	linux-omap <linux-omap@...r.kernel.org>,
	linux-i2c@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question about patch "i2c: omap: resize fifos before each message"

03 дек. 2014 г., в 20:49, Felipe Balbi <balbi@...com> написал(а):

>  It can also be a master receiver and a
> slave transmitter. 
Agree, but this unrelated to races.

>  Note also that MST bit does *not* auto clear.

Yes, it *does* auto clear!
MST bit automatically clear when IP receive AL.
See TRM [1]. All other TRMs (omap3530, omap3430, 
omap4, omap5) has the same picture.

>From TRM:
2Ci.I2C_CON[10] MST bits are cleared by hardware

And MST bit clear after IP send STP (success transfer).

Did you see what value is in CON register after successful master transfer?
Apply my patch and see that.
It doesn't have MST bit set. That mean IP is in slave mode
(receiver or transmitter - doesn't matter) after *any* master transfer.

And simple test show that. IP respond to GC address (address 0).
And respond to SA address (if programmed).

And TRM[1] figure has comment for 'end' state:
"I2C controller goes into slave receiver mode."

And IP keeps into slave mode until 'suspend'.

Then, after 'resume' IP initialized into slave receiver mode. There is short 
time after resume and master start initialize new transfer.

So, then we start new transfer IP could start receiving slave command.

> Also,
> the IP won't do anything (considering it's always in master mode) until
> STT bit is set again
Yes, it do slave reception or tranmittion with STT bit set to 0.

You could set STT bit to 1, and then it got cleared to 0, you
now, that IP received Start condition with slave transfer.

You could leave STT bit set to 0, but IP still respond to slave transfer.
(at least the IP on dm3730).

And we can't set MST bit again after master transfer to leave IP in the
master mode. We must disable IP (clear EN bit) before transfers to
disable slave mode, or we must handle slave interrupts.
Because un handled  slave interrupt leave SCL low.

[1] AM-DM37x Multimedia Device Silicon Revision 1.x  - sprugn4r,
    p.2815, Figure 17-32. HS I2C Master Receiver Mode, 
    Interrupt Method, in F/S and HS Modes (I2C Mode)

--
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/