Hi Al,
On Sat, 27 Oct 2012 18:10:36 +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> > On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> >
> > > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > > is simply not true. In particula
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who
On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
>
> > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> > struct foo {
> > ch
On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> You are wrong. Assumption that pointers are aligned to 32bit boundary
> is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> struct foo {
> char x;
> void *p;
> }; will have 1 byte occupied by x, follow
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who
On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > The original idea of using the hole in the i2c_msg structure is from
> > David Brownell, who was apparently familiar with such practice, so I
> > assumed it was OK
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> > > On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > > > You also miss one v
On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> > On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > > You also miss one very very very big point. This will break every I2C
> > > using usersp
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
> > > Hi Felipe, Shubhrajyoti,
> > >
> > > On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
>
On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
> > Hi Felipe, Shubhrajyoti,
> >
> > On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
> > > From: Shubhrajyoti D
> > >
> > > In case of a NACK, it's wise to
On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
> Hi Felipe, Shubhrajyoti,
>
> On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
> > From: Shubhrajyoti D
> >
> > In case of a NACK, it's wise to tell our clients
> > drivers about how many bytes were actually transferred.
> >
Hi Felipe, Shubhrajyoti,
On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
> From: Shubhrajyoti D
>
> In case of a NACK, it's wise to tell our clients
> drivers about how many bytes were actually transferred.
>
> Support this by adding an extra field to the struct
> i2c_msg which gets inc
From: Shubhrajyoti D
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg which gets incremented the amount of bytes
actually transferred.
Signed-off-by: Shubhrajyoti D
Signed-off-by
13 matches
Mail list logo
