From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Samuel Ortiz <sameo@linux.intel.com>
Cc: linux-kernel@vger.kernel.org,
Sascha Hauer <s.hauer@pengutronix.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [PATCH] mfd/mc13783: near complete rewrite
Date: Fri, 6 Nov 2009 00:53:50 +0100 [thread overview]
Message-ID: <20091105235349.GA22519@pengutronix.de> (raw)
In-Reply-To: <20091105223103.GB22366@sortiz.org>
Hello,
On Thu, Nov 05, 2009 at 11:31:04PM +0100, Samuel Ortiz wrote:
> > The idea here is that I could setup, send and receive multi-transfer
> > messages with a single buffer array. Then the return value would tell me how
> > much to advance in the buffer for the next result. Maybe that's just
> > paranoid over-engineering.
> I'm glad we agree :) This routine is just not neede, for the mere fact that it
> does nothing. Unless you have bigger plans for this driver, right now you're
> doing simple SPI register reads and writes, afaict.
OK, I moved the functionality of {prep,eval}_{read,write} to
reg_{read,write} now and removed the BUG_ONs. Incremental patch below.
> > > > + /* error in message.status implies error return from spi_sync */
> > > > + BUG_ON(!ret && m.status);
> > > So, you really want to crash your board because of an SPI inconsistency ?
> > > Seems like an overkill to me.
> > This only bugs if spi_sync succeeds even though the message wasn't
> > transfered correctly. Sascha's driver had:
> >
> > if (spi_sync(spi, &m) != 0 || m.status != 0)
> > return -EINVAL;
> >
> > If I understand spi_sync correctly m.status != 0 implies spi_sync
> > returning != 0, so the above should be equivalent to:
> >
> > if (spi_sync(spi, &m) != 0)
> > return -EINVAL;
> >
> > So my BUG_ON is only for the case that Sascha saw something I missed.
> Oh, dont get me wrong: I'm not saying the check is bogus, I'm just saying that
> I would just have a WARN_ON() here. I wouldnt be happy if my board would crash
> because of an SPI read error.
An SPI read error won't trigger that. In this case ret is < 0, and so
(!ret && m.status) is false.
The incremental diff based on the earlier post can be found below. I
will follow up with the updated patch.
Best regards
Uwe
drivers/mfd/mc13783-core.c | 95 ++++++++++++--------------------------------
1 files changed, 26 insertions(+), 69 deletions(-)
diff --git a/drivers/mfd/mc13783-core.c b/drivers/mfd/mc13783-core.c
index 45713a4..99267ed 100644
--- a/drivers/mfd/mc13783-core.c
+++ b/drivers/mfd/mc13783-core.c
@@ -2,6 +2,9 @@
* Copyright 2009 Pengutronix
* Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
*
+ * loosely based on an earlier driver that has
+ * Copyright 2009 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
+ *
* This program is free software; you can redistribute it and/or modify it under
* the terms of the GNU General Public License version 2 as published by the
* Free Software Foundation.
@@ -112,7 +115,7 @@ void mc13783_lock(struct mc13783 *mc13783)
{
if (!mutex_trylock(&mc13783->lock)) {
dev_dbg(&mc13783->spidev->dev, "wait for %s from %pf\n",
- __func__, __builtin_return_address(0));
+ __func__, __builtin_return_address(0));
mutex_lock(&mc13783->lock);
}
@@ -129,75 +132,25 @@ void mc13783_unlock(struct mc13783 *mc13783)
}
EXPORT_SYMBOL(mc13783_unlock);
-static int mc13783_prep_read_transfer(struct mc13783 *mc13783,
- struct spi_transfer *t, u32 *buf,
- unsigned int offset, u32 *val)
-{
- if (offset > MC13783_NUMREGS)
- return -EINVAL;
-
- buf[0] = offset << 25;
-
- memset(t, 0, sizeof(*t));
-
- t->tx_buf = buf;
- t->rx_buf = buf;
- t->len = sizeof(u32);
-
- return 1;
-}
-
-static int mc13783_eval_read_transfer(struct mc13783 *mc13783,
- struct spi_transfer *t, u32 *buf,
- unsigned int offset, u32 *val)
-{
- BUG_ON(t->tx_buf != buf || t->rx_buf != buf);
-
- *val = buf[0] & 0xffffff;
-
- return 1;
-}
-
-static int mc13783_prep_write_transfer(struct mc13783 *mc13783,
- struct spi_transfer *t, u32 *buf,
- unsigned int offset, u32 val)
-{
- if (offset > MC13783_NUMREGS || val > 0xffffff)
- return -EINVAL;
-
- buf[0] = 1 << 31 | offset << 25 | val;
-
- memset(t, 0, sizeof(*t));
-
- t->tx_buf = buf;
- t->rx_buf = buf;
- t->len = sizeof(u32);
-
- return 1;
-}
-
-static int mc13783_eval_write_transfer(struct mc13783 *mc13783,
- struct spi_transfer *t, u32 *buf,
- unsigned int offset, u32 val)
-{
- BUG_ON(t->tx_buf != buf || t->rx_buf != buf);
-
- return 1;
-}
-
+#define MC13783_REGOFFSET_SHIFT 25
int mc13783_reg_read(struct mc13783 *mc13783, unsigned int offset, u32 *val)
{
- u32 buf;
struct spi_transfer t;
struct spi_message m;
int ret;
BUG_ON(!mutex_is_locked(&mc13783->lock));
- ret = mc13783_prep_read_transfer(mc13783, &t, &buf, offset, val);
+ if (offset > MC13783_NUMREGS)
+ return -EINVAL;
- if (ret < 0)
- return ret;
+ *val = offset << MC13783_REGOFFSET_SHIFT;
+
+ memset(&t, 0, sizeof(t));
+
+ t.tx_buf = val;
+ t.rx_buf = val;
+ t.len = sizeof(u32);
spi_message_init(&m);
spi_message_add_tail(&t, &m);
@@ -210,11 +163,11 @@ int mc13783_reg_read(struct mc13783 *mc13783, unsigned int offset, u32 *val)
if (ret)
return ret;
- ret = mc13783_eval_read_transfer(mc13783, &t, &buf, offset, val);
+ *val &= 0xffffff;
dev_vdbg(&mc13783->spidev->dev, "[0x%02x] -> 0x%06x\n", offset, *val);
- return ret < 0 ? ret : 0;
+ return 0;
}
EXPORT_SYMBOL(mc13783_reg_read);
@@ -229,10 +182,16 @@ int mc13783_reg_write(struct mc13783 *mc13783, unsigned int offset, u32 val)
dev_vdbg(&mc13783->spidev->dev, "[0x%02x] <- 0x%06x\n", offset, val);
- ret = mc13783_prep_write_transfer(mc13783, &t, &buf, offset, val);
+ if (offset > MC13783_NUMREGS || val > 0xffffff)
+ return -EINVAL;
+
+ buf = 1 << 31 | offset << MC13783_REGOFFSET_SHIFT | val;
- if (ret < 0)
- return ret;
+ memset(&t, 0, sizeof(t));
+
+ t.tx_buf = &buf;
+ t.rx_buf = &buf;
+ t.len = sizeof(u32);
spi_message_init(&m);
spi_message_add_tail(&t, &m);
@@ -244,9 +203,7 @@ int mc13783_reg_write(struct mc13783 *mc13783, unsigned int offset, u32 val)
if (ret)
return ret;
- ret = mc13783_eval_write_transfer(mc13783, &t, &buf, offset, val);
-
- return ret < 0 ? ret : 0;
+ return 0;
}
EXPORT_SYMBOL(mc13783_reg_write);
--
1.6.5.2
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2009-11-05 23:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-23 20:38 [PATCH] mfd/mc13783: near complete rewrite Uwe Kleine-König
2009-10-24 8:35 ` [PATCH] [RTC] Add Freescale MC13783 RTC driver Uwe Kleine-König
2009-11-01 20:34 ` Uwe Kleine-König
2009-11-04 18:12 ` Valentin Longchamp
2009-11-05 15:06 ` Valentin Longchamp
2009-11-10 8:32 ` [PATCH RESENT] " Uwe Kleine-König
2009-11-10 9:30 ` Alessandro Zummo
2009-11-10 11:10 ` Uwe Kleine-König
2009-11-22 21:49 ` Uwe Kleine-König
2009-11-03 19:20 ` [PATCH] " Uwe Kleine-König
2009-11-01 21:06 ` [PATCH] mfd/mc13783: near complete rewrite Uwe Kleine-König
2009-11-02 11:51 ` Mark Brown
2009-11-02 13:58 ` Uwe Kleine-König
2009-11-02 14:09 ` Mark Brown
2009-11-02 14:32 ` Uwe Kleine-König
2009-11-02 15:12 ` Mark Brown
2009-11-02 20:56 ` [PATCH] mfd/mc13783: change type of irq handlers to irq_handler_t Uwe Kleine-König
2009-11-03 19:31 ` [PATCH] mfd/mc13783: near complete rewrite Uwe Kleine-König
2009-11-04 18:35 ` Samuel Ortiz
2009-11-04 22:28 ` Uwe Kleine-König
2009-11-05 22:31 ` Samuel Ortiz
2009-11-05 23:53 ` Uwe Kleine-König [this message]
2009-11-05 23:56 ` Uwe Kleine-König
2009-11-06 0:28 ` Samuel Ortiz
2009-11-10 8:18 ` [PATCH 1/2] regulator/mc13783: rename source file to match other drivers Uwe Kleine-König
2009-11-10 8:18 ` [PATCH 2/2] regulator/mc13783: various cleanups Uwe Kleine-König
2009-11-10 13:08 ` Mark Brown
2009-11-11 14:11 ` Liam Girdwood
2009-11-11 14:16 ` Uwe Kleine-König
2009-11-11 14:30 ` Liam Girdwood
2009-11-10 11:44 ` [PATCH 1/2] regulator/mc13783: rename source file to match other drivers Mark Brown
2009-11-11 14:09 ` Liam Girdwood
2009-11-24 21:44 ` [PATCH] mfd/mc13783: near complete rewrite Uwe Kleine-König
2009-11-24 23:26 ` Samuel Ortiz
2009-12-02 18:54 ` Uwe Kleine-König
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=20091105235349.GA22519@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sameo@linux.intel.com \
/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