On Wed, Nov 26, 2014 at 03:25:29PM +0300, Alexander Kochetkov wrote:
>
> 22 нояб. 2014 г., в 21:12, Wolfram Sang написал(а):
>
> > IMO a repeated start is to ensure that two messages arrive at the slave
> > without interruption from another master. I can't think why a slave
> > should know which
22 нояб. 2014 г., в 21:12, Wolfram Sang написал(а):
> IMO a repeated start is to ensure that two messages arrive at the slave
> without interruption from another master. I can't think why a slave
> should know which type of start that was. In fact, if it does that would
> raise an eyebrow for me
> My bad, will minimize the overhead in the future.
Thanks!
> I think usable semantics could be that a slave driver can indicate at any
> point during an I2C read transaction that the next X bytes should be
> returned from a buffer and for a write transaction, that the next X bytes
> should be b
On Sat, Nov 22, 2014 at 7:12 PM, Wolfram Sang wrote:
> Hi,
>
> Please quote only relevant parts of the message (like I did). This
> improves readability a lot.
>
My bad, will minimize the overhead in the future.
>>
>> Would it make sense to have:
>> WRITE_START
>> WRITE_NEXT
>> WRITE_STOP
>> WRI
> > > When the eeprom driver is probed and the adapter driver notices a read
> > > request for the respective i2c address, this callback is called with
> > > event=I2C_SLAVE_REQ_READ_START. Returning 0 here and provide the first
> > > byte to send make the adapter ack the read request and send the
Hello Wolfram,
On Sat, Nov 22, 2014 at 07:26:30PM +0100, Wolfram Sang wrote:
>
> > this mail is thematically more a reply to patch 1 and maybe just serves
> > my understanding of the slave support.
>
> Sure. This shows how badly needed the documentation is :)
>
> ...
> > > + break;
> >
Hallo Wolfram,
On Sat, Nov 22, 2014 at 07:14:06PM +0100, Wolfram Sang wrote:
> > > > + case I2C_SLAVE_REQ_READ_END:
> > > > + eeprom->buffer_idx++;
> > > You don't check here for buffer_idx >= ARRAY_SIZE(buffer)?
> > > Ditto in the I2C_SLAVE_REQ_WRITE_END case.
> > I just notic
> this mail is thematically more a reply to patch 1 and maybe just serves
> my understanding of the slave support.
Sure. This shows how badly needed the documentation is :)
...
> > + break;
> > +
> > + case I2C_SLAVE_STOP:
> > + eeprom->first_write = true;
> > + b
Hi Uwe,
please don't quote so much :)
> > > + case I2C_SLAVE_REQ_READ_END:
> > > + eeprom->buffer_idx++;
> > You don't check here for buffer_idx >= ARRAY_SIZE(buffer)?
> > Ditto in the I2C_SLAVE_REQ_WRITE_END case.
> I just noticed that buffer_idx is an u8, so it overflows at 255+1. So
>
Hi,
Please quote only relevant parts of the message (like I did). This
improves readability a lot.
> > +static int i2c_slave_eeprom_slave_cb(struct i2c_client *client,
> > +enum i2c_slave_event event, u8 *val)
> > +{
> > + struct eeprom_data *eeprom = i2c
On Fri, Nov 21, 2014 at 08:19:41AM +0100, Uwe Kleine-König wrote:
> Hello Wolfram,
>
> this mail is thematically more a reply to patch 1 and maybe just serves
> my understanding of the slave support.
>
> On Tue, Nov 18, 2014 at 05:04:54PM +0100, Wolfram Sang wrote:
> > From: Wolfram Sang
> >
>
Hello Wolfram,
this mail is thematically more a reply to patch 1 and maybe just serves
my understanding of the slave support.
On Tue, Nov 18, 2014 at 05:04:54PM +0100, Wolfram Sang wrote:
> From: Wolfram Sang
>
> The first user of the i2c-slave interface is an eeprom simulator. It is
> a shared
On Tue, Nov 18, 2014 at 5:04 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> The first user of the i2c-slave interface is an eeprom simulator. It is
> a shared memory which can be accessed by the remote master via I2C and
> locally via sysfs.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Changes si
From: Wolfram Sang
The first user of the i2c-slave interface is an eeprom simulator. It is
a shared memory which can be accessed by the remote master via I2C and
locally via sysfs.
Signed-off-by: Wolfram Sang
---
Changes since RFC:
* fix build error for modules
* don't hardcode size
* add boun
14 matches
Mail list logo
