Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-11-02 Thread Felipe Balbi
Hi, On Thu, Nov 01, 2012 at 11:23:16PM +0100, Wolfram Sang wrote: On Thu, Oct 25, 2012 at 12:00:48PM +0300, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-11-01 Thread Wolfram Sang
On Thu, Oct 25, 2012 at 12:00:48PM +0300, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-27 Thread Santosh Shilimkar
On Saturday 27 October 2012 04:31 AM, Paul Walmsley wrote: Hi Felipe just two quick comments On Thu, 25 Oct 2012, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-27 Thread Paul Walmsley
On Sat, 27 Oct 2012, Santosh Shilimkar wrote: Another alternative, which I will recommend to just make use of the read*/wrire* instead __raw versions. The barriers are taken care already and driver point of view, it is transparent. Those barriers will disappear if

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-27 Thread Santosh Shilimkar
On Saturday 27 October 2012 09:29 PM, Paul Walmsley wrote: On Sat, 27 Oct 2012, Santosh Shilimkar wrote: Another alternative, which I will recommend to just make use of the read*/wrire* instead __raw versions. The barriers are taken care already and driver point of view, it is transparent.

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-26 Thread Paul Walmsley
Hi Felipe just two quick comments On Thu, 25 Oct 2012, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1

[PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-25 Thread Felipe Balbi
if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-25 Thread Shubhrajyoti Datta
On Thu, Oct 25, 2012 at 2:30 PM, Felipe Balbi ba...@ti.com wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-25 Thread Kevin Hilman
+Paul Felipe Balbi ba...@ti.com writes: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. Any chance this would help with the bug Paul found with I2C timeouts on beagle userspace startup? Kevin This bug was found

Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered

2012-10-25 Thread Felipe Balbi
Hi, On Thu, Oct 25, 2012 at 09:38:06AM -0700, Kevin Hilman wrote: +Paul Felipe Balbi ba...@ti.com writes: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. Any chance this would help with the bug Paul found