From: Felipe Balbi <balbi@ti.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Shubhrajyoti <shubhrajyoti@ti.com>,
linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, ben-linux@fluff.org,
tony@atomide.com, w.sang@pengutronix.de
Subject: Re: [RFC PATCH 3/3] i2c: inititalise the actual transferred to zero
Date: Mon, 2 Jul 2012 14:54:23 +0300 [thread overview]
Message-ID: <20120702115422.GC2730@arwen.pp.htv.fi> (raw)
In-Reply-To: <20120629151832.0cb26bea@endymion.delvare>
[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]
Hi,
On Fri, Jun 29, 2012 at 03:18:32PM +0200, Jean Delvare wrote:
> On Fri, 29 Jun 2012 18:42:08 +0530, Shubhrajyoti wrote:
> > On Friday 29 June 2012 06:27 PM, Jean Delvare wrote:
> > > drivers/gpu/drm/nouveau/nouveau_bios.c:3535:3: warning: (near initialization for ‘msg[1].actual’) [enabled by default]
> > >
> > > This needs to be all fixed (converted to C99-style struct
> > > initialization) before your patch is considered for inclusion. And
> > > there may be more that my config did not spot.
> > Yes,agree.
> >
> > The idea of this patch was if the idea is agreed upon then.
> > then fixing all the callers could be worked on.
>
> This is worth fixing anyway, C99-style initialization is always good to
> move to.
>
> > However do you agree with this approach?
>
> Well you've seen the caveats I mentioned, this will be no easy ride. If
> you are willing to take the risk, spend the time documenting the
> change, and help people if there are issues, then I'm OK. At least as
> long as someone else doesn't come saying it's a very bad idea ;)
This approach is a hard-requirement for devices which will pose any
interface/feedback with user. We have been working with a piezo driver
from TI (drv2665) and it will be used (in most cases at least) to give
the user a feedback based on e.g. touchscreen event.
Imagine drv2665 responds with a NAK while we're in the middle of driving
a wave through it (keep in mind a wave could take seconds to finish,
depending on the usecase), if we don't have a way to tell users that we
have writen X bytes, how should we make sure to continue driving the
wave from the exact byte where we got a NAK ?
If can't make sure that detail is true, then such usecases (as piezo
drivers) will never work.
Another approach would be to not add any field to struct i2c_msg but
instead return either the amount of bytes transferred, or an error case.
This would mean a series that would:
1) fix all users of struct i2c_master_send() and the like to check for
errors as if (ret < 0) instead of if (ret);
2) fix all i2c buses to return the amount of bytes written instead of
zero or error case
3) fix Documentation to state that we're now returning the amount of
bytes, instead of zero or errno.
I'm not sure what will have minimum impact to userland, though. What do
you say Jean ? What would you prefer ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-07-02 11:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 11:05 [RFC PATCH 0/3] I2C: Report the actual transferred bytes Shubhrajyoti D
[not found] ` <1340967927-27354-1-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
2012-06-29 11:05 ` [RFC PATCH 1/3] i2c: add 'actual' field to struct i2c_msg Shubhrajyoti D
[not found] ` <1340967927-27354-2-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
2012-06-29 12:33 ` Jean Delvare
2012-07-02 13:27 ` Jean Delvare
2012-06-29 11:05 ` [RFC PATCH 2/3] i2c: omap: implement handling for 'actual' bytes transferred Shubhrajyoti D
2012-06-29 11:05 ` [RFC PATCH 3/3] i2c: inititalise the actual transferred to zero Shubhrajyoti D
2012-06-29 12:40 ` Jean Delvare
[not found] ` <20120629144002.3b4a31ee-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-06-29 12:57 ` Jean Delvare
2012-06-29 13:12 ` Shubhrajyoti
[not found] ` <4FEDA9A8.1050504-l0cyMroinI0@public.gmane.org>
2012-06-29 13:18 ` Jean Delvare
2012-07-02 11:54 ` Felipe Balbi [this message]
[not found] ` <20120702115422.GC2730-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-07-02 13:20 ` Jean Delvare
2012-07-16 8:17 ` Felipe Balbi
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=20120702115422.GC2730@arwen.pp.htv.fi \
--to=balbi@ti.com \
--cc=ben-linux@fluff.org \
--cc=khali@linux-fr.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=shubhrajyoti@ti.com \
--cc=tony@atomide.com \
--cc=w.sang@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).