Hey Andrey,
Thanks for the review :) see some comments below.
>> + /* Don't read anything on error or if 0 bytes were requested */
>> + if (size > 0) {
>> + adapter = i2c_get_adapter(i2c_read_req->bus);
>> + if (!adapter) {
>> +
On Thu, Aug 23, 2018 at 10:54:58PM +0200, Aleksander Morgado wrote:
> >> +struct ratp_bb_i2c_read_request {
> >> + struct ratp_bb header;
> >> + uint16_t buffer_offset;
> >> + uint8_t bus;
> >> + uint8_t addr;
> >
> > I wonder how we see the RATP support. If it's for adhoc
>> +struct ratp_bb_i2c_read_request {
>> + struct ratp_bb header;
>> + uint16_t buffer_offset;
>> + uint8_t bus;
>> + uint8_t addr;
>
> I wonder how we see the RATP support. If it's for adhoc debugging then
> bus/addr is fine. The caller should have no expectations that the bus
>
On Tue, Aug 21, 2018 at 05:19:58PM +0200, Aleksander Morgado wrote:
> Introduce two new RATP commands that allow running i2c read/write
> operations, very similar in format to the already existing md/mw
> RATP commands.
>
> The messages are defined with a fixed 16-bit long register field, but
>
On Tue, Aug 21, 2018 at 8:20 AM Aleksander Morgado
wrote:
>
> Introduce two new RATP commands that allow running i2c read/write
> operations, very similar in format to the already existing md/mw
> RATP commands.
>
> The messages are defined with a fixed 16-bit long register field, but
> it will
Introduce two new RATP commands that allow running i2c read/write
operations, very similar in format to the already existing md/mw
RATP commands.
The messages are defined with a fixed 16-bit long register field, but
it will only be treated as a 16-bit address if I2C_FLAG_WIDE_ADDRESS
is set in
