All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Sander <tim@krieglstein.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] i2c-tiny-usb: add new usb to i2c bridge
Date: Tue, 05 Jan 2016 13:23:12 +0100	[thread overview]
Message-ID: <3104807.PJOGURGZId@dabox> (raw)
In-Reply-To: <1451979870.31764.19.camel@redhat.com>

Hi Gerd

Thanks for your review.

Am Dienstag, 5. Januar 2016, 08:44:30 schrieb Gerd Hoffmann:
> > +    case 0x4107:
> > +        /* this seems to be a byte type access */
> > +        if (i2c_start_transfer(s->i2cbus, /*address*/index, 0)) {
> > +            trace_usb_i2c_tiny_i2c_start_transfer_failed();
> > +            p->actual_length = 0; /* write failure */
> > +            break;
> > +        }
> > +        for (i = 0; i < length; i++) {
> > +            trace_usb_i2c_tiny_write(request, index, i, data[i]);
> > +            i2c_send(s->i2cbus, data[i]);
> > +        }
> > +        p->actual_length = length;
> > +        i2c_end_transfer(s->i2cbus);
> > +        break;
> 
> I think most of the tracepoints should be moved into i2c code (or just
> dropped in case we already have tracepoints there).
I don't think that there are any tracepoints in there.

> One (high-level) tracepoint per transfer request makes sense in the usb
> code, i.e. trace_usb_i2c_transfer_{read,write}, so one can see in the
> trace log which usb request triggered which i2c transaction.
> 
> > +    case 0xc101:
> > +        {
> > +        /* thats what the real thing reports, FIXME: can we do better
> > here? */
> 
> Hmm, didn't we agree on adding a note about what the "real thing" we
> mimic here is, to the comment at the start of the file?
Ok, that was a missunderstanding. I thought you wanted a description on top of 
the patch i was sending but  having a description in the file makes sense and i 
will add it.

> > +        uint32_t func = htole32(I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL);
> 
> Can we move 'func' to the start of the function too, like we did with
> 'i'?
will do.
 
> > +    case 0xc106:
> > +        trace_usb_i2c_tiny_unknown_request(index, request, value,
> > length);
> > +        trace_usb_i2c_tiny_unknown_request(data[0], data[1], data[2],
> > data[3]);
> > +        if (i2c_start_transfer(s->i2cbus, /*address*/ index, 1)) {
> > +            trace_usb_i2c_tiny_i2c_start_transfer_failed();
> > +            p->actual_length = 0;
> > +            break;
> > +        }
> 
> Doesn't look like this request is unknown ...
> 
> > +        for (i = 0; i < length; i++) {
> > +            data[i] = i2c_recv(s->i2cbus);
> 
> Can this fail?
I think failure is just returning 255 as a value? AFAIK thats what real i2c 
hardware returns.

Best regards
Tim

  reply	other threads:[~2016-01-05 12:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04 17:30 [Qemu-devel] [PATCH] i2c-tiny-usb: add new usb to i2c bridge Tim Sander
2016-01-05  7:44 ` Gerd Hoffmann
2016-01-05 12:23   ` Tim Sander [this message]
2016-01-07  9:48     ` Peter Crosthwaite
  -- strict thread matches above, loose matches on Subject: below --
2016-01-06 14:58 Tim Sander
2016-01-07 10:14 ` Peter Crosthwaite
2016-01-13 16:07   ` Tim Sander
2016-01-13 20:59     ` Peter Crosthwaite
2015-11-26 16:35 [Qemu-devel] [PATCH RFC] i2c-tiny-usb Tim Sander
2015-11-27 12:53 ` Paolo Bonzini
2015-12-09 16:40   ` [Qemu-devel] i2c data address question was " Tim Sander
2015-12-16 15:56     ` [Qemu-devel] [PATCH] i2c-tiny-usb: add new usb to i2c bridge Tim Sander
2015-12-17 16:15       ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3104807.PJOGURGZId@dabox \
    --to=tim@krieglstein.org \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.