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
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
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
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
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.
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
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
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
+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
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
10 matches
Mail list logo