From patchwork Thu Oct 8 14:04:32 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wolfram Sang X-Patchwork-Id: 35445 X-Patchwork-Delegate: grant.likely@secretlab.ca Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from bilbo.ozlabs.org (localhost [127.0.0.1]) by ozlabs.org (Postfix) with ESMTP id C526AB7DDC for ; Fri, 9 Oct 2009 01:05:00 +1100 (EST) Received: by ozlabs.org (Postfix) id 77606B7B74; Fri, 9 Oct 2009 01:04:53 +1100 (EST) Delivered-To: linuxppc-dev@ozlabs.org Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [92.198.50.35]) by ozlabs.org (Postfix) with ESMTP id 1BE66B7B6F for ; Fri, 9 Oct 2009 01:04:53 +1100 (EST) Received: from [2001:6f8:1178:2:221:70ff:fe71:1890] (helo=pengutronix.de) by metis.ext.pengutronix.de with esmtp (Exim 4.63) (envelope-from ) id 1Mvtbs-0006vX-CK; Thu, 08 Oct 2009 16:04:48 +0200 From: Wolfram Sang To: linuxppc-dev@ozlabs.org Subject: [RFC] misc/at24: add experimental OF support for the generic eeprom driver Date: Thu, 8 Oct 2009 16:04:32 +0200 Message-Id: <1255010672-21656-1-git-send-email-w.sang@pengutronix.de> X-Mailer: git-send-email 1.6.3.3 X-SA-Exim-Connect-IP: 2001:6f8:1178:2:221:70ff:fe71:1890 X-SA-Exim-Mail-From: w.sang@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linuxppc-dev@ozlabs.org Cc: devicetree-discuss@ozlabs.org, linux-i2c@vger.kernel.org X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org As Anton introduced archdata support, I wondered if this is a suitable way to handle the platform_data/devicetree_property-dualism (at least for some drivers). If considered suitable, I would document the bindings properly. I really think that pagesize deserves its own property as it is specific to the hardware and I have seen devices with equal name and still having different pagesizes. Not too sure about 'read-only' though, I just copied it from flash-partitions :) Tested on a phyCORE-MPC5200-IO and build-tested on x86. Signed-off-by: Wolfram Sang Cc: Grant Likely Cc: Anton Vorontsov --- drivers/misc/eeprom/at24.c | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index db39f4a..4e543e6 100644 --- a/drivers/misc/eeprom/at24.c +++ b/drivers/misc/eeprom/at24.c @@ -22,6 +22,9 @@ #include #include #include +#ifdef CONFIG_OF_I2C +#include +#endif /* * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable. @@ -414,6 +417,25 @@ static ssize_t at24_macc_write(struct memory_accessor *macc, const char *buf, return at24_write(at24, buf, offset, count); } +#ifdef CONFIG_OF_I2C +static void at24_get_ofdata(struct i2c_client *client, struct at24_platform_data *chip) +{ + const u32 *val; + struct device_node *node = dev_archdata_get_node(&client->dev.archdata); + + if (node) { + if (of_get_property(node, "read-only", NULL)) + chip->flags |= AT24_FLAG_READONLY; + val = of_get_property(node, "pagesize", NULL); + if (val) + chip->page_size = *val; + } +} +#else +static void at24_get_ofdata(struct i2c_client *client, struct at24_platform_data *chip) +{ } +#endif + /*-------------------------------------------------------------------------*/ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id) @@ -444,6 +466,9 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id) */ chip.page_size = 1; + /* update chipdata if OF is present */ + at24_get_ofdata(client, &chip); + chip.setup = NULL; chip.context = NULL; }