From: Samuel Ortiz <sameo@openedhand.com>
To: Mark Brown <broonie@sirena.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.28] mfd: Correct WM8350 I2C return code usage
Date: Thu, 13 Nov 2008 00:06:36 +0100 [thread overview]
Message-ID: <20081112230636.GB17382@sortiz.org> (raw)
In-Reply-To: <20081112200007.GA31451@sirena.org.uk>
On Wed, Nov 12, 2008 at 08:00:07PM +0000, Mark Brown wrote:
> On Wed, Nov 12, 2008 at 07:49:57PM +0100, Samuel Ortiz wrote:
> > On Mon, Nov 10, 2008 at 01:41:17PM +0000, Mark Brown wrote:
>
> > > The vendor BSP used for the WM8350 development provided an I2C driver
> > > which incorrectly returned zero on succesful sends rather than the
> > > number of transmitted bytes, an error which was then propagated into the
> > > WM8350 I2C accessors.
>
> > Shouldnt we fix the accessors behaviour instead ?
> > Currently, that would mean fixing some of the wm8350-core static functions.
> > Slightly bigger patch, but that would keep the i2c interface consistent.
>
> I don't really understand what you mean by "keep the i2c interface
> consistent" here? The purpose of this abstraction is to abstract away
> the control interface used to communicate with the chip since it
> supports both I2C and SPI.
I understand that. I'm just saying that I would prefer wm8350->read_dev() to
return the actual bytes read, be it for SPI or I2C. Same for write_dev(), of
course.
With this patch you're breaking that expectation because the read|write_dev()
callers basically expect it to return 0 when the you've read|written the right
number of bytes.
I'd prefer to fix the callers code, so that we keep the expected semantics
for your read|write_dev() routines. For example with wm8350_clear_bits():
diff --git a/drivers/mfd/wm8350-core.c b/drivers/mfd/wm8350-core.c
index 0d47fb9..12ff3a6 100644
--- a/drivers/mfd/wm8350-core.c
+++ b/drivers/mfd/wm8350-core.c
@@ -199,19 +199,22 @@ static int wm8350_write(struct wm8350 *wm8350, u8 reg, int num_regs, u16 *src)
int wm8350_clear_bits(struct wm8350 *wm8350, u16 reg, u16 mask)
{
u16 data;
- int err;
+ int err = 0, ret;
mutex_lock(&io_mutex);
- err = wm8350_read(wm8350, reg, 1, &data);
- if (err) {
+ ret = wm8350_read(wm8350, reg, 1, &data);
+ if (ret != 1) {
dev_err(wm8350->dev, "read from reg R%d failed\n", reg);
+ err = -EIO;
goto out;
}
data &= ~mask;
- err = wm8350_write(wm8350, reg, 1, &data);
- if (err)
+ ret = wm8350_write(wm8350, reg, 1, &data);
+ if (ret != 1) {
dev_err(wm8350->dev, "write to reg R%d failed\n", reg);
+ err = -EIO;
+ }
out:
mutex_unlock(&io_mutex);
return err;
--
Intel Open Source Technology Centre
http://oss.intel.com/
next prev parent reply other threads:[~2008-11-12 23:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-10 13:41 Mark Brown
2008-11-12 18:49 ` Samuel Ortiz
2008-11-12 20:00 ` Mark Brown
2008-11-12 23:06 ` Samuel Ortiz [this message]
2008-11-12 23:43 ` Mark Brown
2008-11-16 22:30 ` Samuel Ortiz
-- strict thread matches above, loose matches on Subject: below --
2008-11-06 13:24 Mark Brown
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=20081112230636.GB17382@sortiz.org \
--to=sameo@openedhand.com \
--cc=broonie@sirena.org.uk \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®