Re: [PATCH] i2c: i801: fix memleak on probe error
Hi Peter, Joining the discussion late as I was on vacation... On Mon, 23 Dec 2013 11:43:21 +0100, Peter Wu wrote: Nevermind this patch, it does not really fix the memleak because i2c_set_adapdata() calls dev_set_drvdata() which allocates memory. (I must have ran kmemleak too early, right after boot it did not give any warnings, now it does). I can confirm that your proposed patch doesn't fix anything. It makes no difference if pci_set_drvdata(dev, priv) is called earlier or later. RFC: what about dropping i2c_set_adapdata() from the probe function and replacing i2c_get_adapdata(adapter) by pci_get_drvdata(adapter-pci_dev) on top of this patch? I am not sure what the purpose is for i2c_set_adapdata, hence this question. The purpose of i2c_set_adapdata is to attach a data structure to a specific i2c_adapter device. In the case of the i2c-i801 driver, there's only one such (class) device per PCI device so we could indeed reuse the PCI device data pointer as you suggest above. But in the general case there can be several i2c_adapter devices and each needs its own data. Also for performance reasons we don't want to do that because pci_get_drvdata(adapter-pci_dev) is slower than i2c_get_adapdata(adapter) (due to the extra pointer deference.) As this happens repeatedly at run-time (in function i801_access) we want it to be as fast as possible. Note that we could (ab)use i2c_adapter.algo_data to store the i2c_adapter device-specific data. Some drivers are doing exactly that, for example i2c-nforce2. I suspect this legacy field is now somewhat redundant with i2c_set_adapdata() as I couldn't find any i2c bus driver using both. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] I2C: EMMA Mobile I2C master driver
On 11/12/13 11:59, Wolfram Sang wrote: No need to resend. I have it on my todo-list. Yet, by glimpsing at it I found some issues which need a proper review for which I didn't have the time so far. I hope to have it done by this week. Ping :) -Ian -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On Wed, Jan 08, 2014 at 11:15:05AM +0100, Gregory CLEMENT wrote:
Hi Wolfram,
On 08/01/2014 00:06, Wolfram Sang wrote:
On Tue, Jan 07, 2014 at 11:38:53AM -0700, Jason Gunthorpe wrote:
On Tue, Jan 07, 2014 at 05:35:03PM +0100, Gregory CLEMENT wrote:
+static struct property i2c_offload_broken = {
+ .name = offload-broken,
+};
+
+static void __init i2c_quirk(void)
+{
+ struct device_node *np;
+ u32 dev, rev;
+
+ /*
+ * Only revisons more recent than A0 support the offload
+ * mechanism. We can exit only if we are sure that we can
+ * get the SoC revision and it is more recent than A0.
+ */
+ if (mvebu_get_soc_id(rev, dev) == 0 dev MV78XX0_A0_REV)
+ return;
+
+ for_each_compatible_node(np, NULL, marvell,mv78230-i2c)
+ of_add_property(np, i2c_offload_broken);
I like this approach.
Sorry, but I don't.
However, when I first read this I thought it should be a -a0 specific
compatible string, not a 'offload-broken' property - any idea what the
DT consensus is here? I've seen both approach in use ..
I prefer the replacement of the compatible string. If it should really
be a seperate property, then it should be a vendor specific property. It
is not generic, at all.
Something like marvell,offload-broken would be acceptable?
A tad more, yes. Still, since this is a feature/quirk of the IP core
revision, it should be deduced from the compatible property IMO. It
cannot be configured anywhere, so it doesn't change on board level.
signature.asc
Description: Digital signature
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
static void __init armada_370_xp_dt_init(void)
{
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
I'd prefer to enable the quirk only on machines that we know may be affected,
i.e.
OpenBlocks AX3-4. That would make it easier in the future for everyone to figure
out whether they need to include the quirk in their kernels or not, depending
on whether they want to support these machines. Just a precaution in case we
end up having lots of quirks in the long run.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] ARM: mvebu: Add support to get the ID and the revision of a SoC
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
diff --git a/include/linux/mvebu-soc-id.h b/include/linux/mvebu-soc-id.h
new file mode 100644
index ..31654252fe35
--- /dev/null
+++ b/include/linux/mvebu-soc-id.h
+#ifdef CONFIG_ARCH_MVEBU
+int mvebu_get_soc_id(u32 *dev, u32 *rev);
+#else
+static inline int mvebu_get_soc_id(u32 *dev, u32 *rev)
+{
+ return -1;
+}
+#endif
+
+#endif /* __LINUX_MVEBU_SOC_ID_H */
With the quirk handling in patch 3, I think we should remove the public
interface
and EXPORT_SYMBOL(), as well as move this header file into mach-mvebu.
That said, we may want to add support for the soc_bus later on (not as part of
the
stable bug fix) to make it possible to query the soc version from user space
through
the standard sysfs files.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On 08/01/2014 12:29, Wolfram Sang wrote:
On Wed, Jan 08, 2014 at 11:15:05AM +0100, Gregory CLEMENT wrote:
Hi Wolfram,
On 08/01/2014 00:06, Wolfram Sang wrote:
On Tue, Jan 07, 2014 at 11:38:53AM -0700, Jason Gunthorpe wrote:
On Tue, Jan 07, 2014 at 05:35:03PM +0100, Gregory CLEMENT wrote:
+static struct property i2c_offload_broken = {
+ .name = offload-broken,
+};
+
+static void __init i2c_quirk(void)
+{
+ struct device_node *np;
+ u32 dev, rev;
+
+ /*
+ * Only revisons more recent than A0 support the offload
+ * mechanism. We can exit only if we are sure that we can
+ * get the SoC revision and it is more recent than A0.
+ */
+ if (mvebu_get_soc_id(rev, dev) == 0 dev MV78XX0_A0_REV)
+ return;
+
+ for_each_compatible_node(np, NULL, marvell,mv78230-i2c)
+ of_add_property(np, i2c_offload_broken);
I like this approach.
Sorry, but I don't.
However, when I first read this I thought it should be a -a0 specific
compatible string, not a 'offload-broken' property - any idea what the
DT consensus is here? I've seen both approach in use ..
I prefer the replacement of the compatible string. If it should really
be a seperate property, then it should be a vendor specific property. It
is not generic, at all.
Something like marvell,offload-broken would be acceptable?
A tad more, yes. Still, since this is a feature/quirk of the IP core
revision, it should be deduced from the compatible property IMO. It
cannot be configured anywhere, so it doesn't change on board level.
So you would prefer using the marvell,mv78230-a0-i2c comaptible string and
updating it with the follwing piece of code?
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index e2acff98e750..8c4ecf987e82 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -21,6 +21,8 @@
#include linux/clocksource.h
#include linux/dma-mapping.h
#include linux/mbus.h
+#include linux/mvebu-soc-id.h
+#include linux/slab.h
#include asm/hardware/cache-l2x0.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -45,8 +47,38 @@ static void __init armada_370_xp_timer_and_clk_init(void)
#endif
}
+static void __init i2c_quirk(void)
+{
+ struct device_node *np;
+ u32 dev, rev;
+ int i = 0;
+
+ /*
+* Only revisons more recent than A0 support the offload
+* mechanism. We can exit only if we are sure that we can
+* get the SoC revision and it is more recent than A0.
+*/
+ if (mvebu_get_soc_id(rev, dev) == 0 dev MV78XX0_A0_REV)
+ return;
+
+ for_each_compatible_node(np, NULL, marvell,mv78230-i2c) {
+ struct property *new_compat;
+
+ new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
+
+ new_compat-name = kstrdup(compatible, GFP_KERNEL);
+ new_compat-length = sizeof(marvell,mv78230-a0-i2c);
+ new_compat-value = kstrdup(marvell,mv78230-a0-i2c,
+ GFP_KERNEL);
+
+ of_update_property(np, new_compat);
+ }
+ return;
+}
+
static void __init armada_370_xp_dt_init(void)
{
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How should dev_[gs]et_drvdata be used?
On Tue, 24 Dec 2013 01:18:03 +0100, Peter Wu wrote:
On Monday 23 December 2013 10:37:21 Alex Williamson wrote:
On Mon, 2013-12-23 at 16:49 +0100, Peter Wu wrote:
[..]
There is still one thing I do not fully understand, how should
dev_set_drvdata and dev_get_drvdata be used? For the devices passed
to probe functions, the core takes care of setting to NULL on error.
Then device_unregister frees the memory, right?
Now, what if the dev_set_drvdata (or aliases such as pci_set_drvdata,
i2c_set_adapinfo, etc.) are manually called outside probe functions?
FWIW I don't think this is supposed to happen.
Or inside the probe function, but not for the device that is being
probed (such as is the case with the i801 i2c driver)?
This OTOH does happen. Is suspect any driver which instantiates class
devices will do exactly that. It's nothing i2c specific. For example
media drivers call video_set_drvdata() in their probe functions.
(...)
Clear examples of how to use dev_{s,g}et_drvdata correctly in i2c is
still wanted. I stepped in it yesterday, i2c seems to have its own
way to register new devices.
What makes you think so? It's as standard as I can imagine.
More specifically, how can the memory
associated with dev_set_drvdata be free'd on error paths if the
device is not registered with device_register (as is done in the
probe function of the i801 i2c driver)?
There are two pieces of data to consider here. The data structure which
is pointed to by dev_get_drvdata (or i2c_get_adapdata) is allocated
explicitly by the driver and must be freed explicitly by the driver
(unless devm_kzalloc is used, in which case the cleanup is automatic).
The data structure used internally by the driver core (dev-p) is
allocated transparently and is thus the core's responsibility to free.
I remember looking into this some time ago after someone reported a
possible memleak to me, and was not fully convinced that the core was
properly releasing dev-p in all cases. This may be the same problem
you are looking at right now.
I do not understand your claim that i2c_adapter class devices are not
registered with device_register. I2c bus drivers such as i2c-i801 call
i2c_add_adapter(), which calls i2c_register_adapter(), which calls
device_register().
Having looked at the code in deeper detail, I think I understand what
is going on. The problem is with:
i2c_set_adapdata(priv-adapter, priv);
at the beginning of i801_probe(). It triggers the allocation of dev-p
by the driver core. If we bail out at any point before i2c_add_adapter
(and subsequently device_register) is called, then that memory is never
freed.
Unfortunately it is not possible to move the i2c_set_adapdata() call
after i2c_add_adapter(), because the data pointer is needed by code
which runs as part of i2c_add_adapter().
We could move it right before the call to i2c_add_adapter(), to make
the problem window smaller, but this wouldn't solve the problem
completely, as i2c_add_adapter() itself can fail before
device_register() is called.
The only solution I can think of at this point is to stop using
i2c_set_adapdata() altogether, and use i2c_adapter.algo_data instead:
From: Jean Delvare kh...@linux-fr.org
Subject: i2c-i801: Use i2c_adapter.algo_data
Use i2c_adapter.algo_data instead of i2c_set/get_adapdata(). The
latter makes use of the driver core's private data mechanism, which
allocates memory. That memory is never released if an error happens
between the call to i2c_set_adapdata() and the actual i2c_adapter
registration.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Peter Wu lekenst...@gmail.com
---
drivers/i2c/busses/i2c-i801.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -671,7 +671,7 @@ static s32 i801_access(struct i2c_adapte
int hwpec;
int block = 0;
int ret, xact = 0;
- struct i801_priv *priv = i2c_get_adapdata(adap);
+ struct i801_priv *priv = adap-algo_data;
hwpec = (priv-features FEATURE_SMBUS_PEC) (flags I2C_CLIENT_PEC)
size != I2C_SMBUS_QUICK
@@ -774,7 +774,7 @@ static s32 i801_access(struct i2c_adapte
static u32 i801_func(struct i2c_adapter *adapter)
{
- struct i801_priv *priv = i2c_get_adapdata(adapter);
+ struct i801_priv *priv = adapter-algo_data;
return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
@@ -1117,7 +1117,7 @@ static int i801_probe(struct pci_dev *de
if (!priv)
return -ENOMEM;
- i2c_set_adapdata(priv-adapter, priv);
+ priv-adapter.algo_data = priv;
priv-adapter.owner = THIS_MODULE;
priv-adapter.class = i801_get_adapter_class(priv);
priv-adapter.algo = smbus_algorithm;
I can't think of any drawback, other than the feeling that switching
from a generic implementation to a specific
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
However, when I first read this I thought it should be a -a0 specific compatible string, not a 'offload-broken' property - any idea what the DT consensus is here? I've seen both approach in use .. I prefer the replacement of the compatible string. If it should really be a seperate property, then it should be a vendor specific property. It is not generic, at all. Something like marvell,offload-broken would be acceptable? A tad more, yes. Still, since this is a feature/quirk of the IP core revision, it should be deduced from the compatible property IMO. It cannot be configured anywhere, so it doesn't change on board level. So you would prefer using the marvell,mv78230-a0-i2c comaptible string and updating it with the follwing piece of code? This is the approach I favour, yes. Can't say much about the implementation. Looks OK, but dunno if this is minimal... signature.asc Description: Digital signature
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On 08/01/2014 13:52, Arnd Bergmann wrote:
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
static void __init armada_370_xp_dt_init(void)
{
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
I'd prefer to enable the quirk only on machines that we know may be affected,
i.e.
OpenBlocks AX3-4. That would make it easier in the future for everyone to
figure
out whether they need to include the quirk in their kernels or not, depending
on whether they want to support these machines. Just a precaution in case we
end up having lots of quirks in the long run.
You means something like the following code ?
static void __init armada_370_xp_dt_init(void)
{
+ if (of_machine_is_compatible(plathome,openblocks-ax3-4))
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On Wednesday 08 January 2014 14:42:45 Gregory CLEMENT wrote:
You means something like the following code ?
static void __init armada_370_xp_dt_init(void)
{
+ if (of_machine_is_compatible(plathome,openblocks-ax3-4))
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
Yes, that looks like a good way to do it.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On Wednesday 08 January 2014 14:39:59 Wolfram Sang wrote: However, when I first read this I thought it should be a -a0 specific compatible string, not a 'offload-broken' property - any idea what the DT consensus is here? I've seen both approach in use .. I prefer the replacement of the compatible string. If it should really be a seperate property, then it should be a vendor specific property. It is not generic, at all. Something like marvell,offload-broken would be acceptable? A tad more, yes. Still, since this is a feature/quirk of the IP core revision, it should be deduced from the compatible property IMO. It cannot be configured anywhere, so it doesn't change on board level. So you would prefer using the marvell,mv78230-a0-i2c comaptible string and updating it with the follwing piece of code? This is the approach I favour, yes. Can't say much about the implementation. Looks OK, but dunno if this is minimal... I would prefer the separate property in this case, but only because it's easier to add in the quirk than to change the compatible string, but it's not a strong preference and I don't mind getting overruled if you all favor the alternative. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
Hi Wolfram, On 08/01/2014 14:39, Wolfram Sang wrote: However, when I first read this I thought it should be a -a0 specific compatible string, not a 'offload-broken' property - any idea what the DT consensus is here? I've seen both approach in use .. I prefer the replacement of the compatible string. If it should really be a seperate property, then it should be a vendor specific property. It is not generic, at all. Something like marvell,offload-broken would be acceptable? A tad more, yes. Still, since this is a feature/quirk of the IP core revision, it should be deduced from the compatible property IMO. It cannot be configured anywhere, so it doesn't change on board level. So you would prefer using the marvell,mv78230-a0-i2c comaptible string and updating it with the follwing piece of code? This is the approach I favour, yes. Can't say much about the implementation. Looks OK, but dunno if this is minimal... Allocating memory in each loop could seem convoluted. In my first approach I just used a static struct but I got warning during boot about duplicated node. It seems we can use the same property struct for two different nodes. -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] ARM: mvebu: Add quirk for i2c
On 08/01/2014 14:45, Arnd Bergmann wrote: On Wednesday 08 January 2014 14:39:59 Wolfram Sang wrote: However, when I first read this I thought it should be a -a0 specific compatible string, not a 'offload-broken' property - any idea what the DT consensus is here? I've seen both approach in use .. I prefer the replacement of the compatible string. If it should really be a seperate property, then it should be a vendor specific property. It is not generic, at all. Something like marvell,offload-broken would be acceptable? A tad more, yes. Still, since this is a feature/quirk of the IP core revision, it should be deduced from the compatible property IMO. It cannot be configured anywhere, so it doesn't change on board level. So you would prefer using the marvell,mv78230-a0-i2c comaptible string and updating it with the follwing piece of code? This is the approach I favour, yes. Can't say much about the implementation. Looks OK, but dunno if this is minimal... I would prefer the separate property in this case, but only because it's easier to add in the quirk than to change the compatible string, but it's not a strong preference and I don't mind getting overruled if you all favor the alternative. Great, all the different part seems to be validated, I can now send the last version. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] ARM: mvebu: Add support to get the ID and the revision of a SoC
On 08/01/2014 13:55, Arnd Bergmann wrote:
On Tuesday 07 January 2014, Gregory CLEMENT wrote:
diff --git a/include/linux/mvebu-soc-id.h b/include/linux/mvebu-soc-id.h
new file mode 100644
index ..31654252fe35
--- /dev/null
+++ b/include/linux/mvebu-soc-id.h
+#ifdef CONFIG_ARCH_MVEBU
+int mvebu_get_soc_id(u32 *dev, u32 *rev);
+#else
+static inline int mvebu_get_soc_id(u32 *dev, u32 *rev)
+{
+return -1;
+}
+#endif
+
+#endif /* __LINUX_MVEBU_SOC_ID_H */
With the quirk handling in patch 3, I think we should remove the public
interface
and EXPORT_SYMBOL(), as well as move this header file into mach-mvebu.
That said, we may want to add support for the soc_bus later on (not as part
of the
stable bug fix) to make it possible to query the soc version from user space
through
the standard sysfs files.
We could do it later indeed. For having a more acceptable patch for stable I
will move
this header file into mach-mvebu.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
This commit add quirk in the mvebu platform code to check the SoC
version and then update the compatible string for the i2c controller
according to the revision of the SoC. Currently only some OpenBlocks
AX3-4 boards are known to use an A0 revision so the check is done only
for these boards.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Cc: sta...@vger.kernel.org
---
arch/arm/mach-mvebu/armada-370-xp.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index e2acff98e750..0f61a4f22fb5 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -21,6 +21,7 @@
#include linux/clocksource.h
#include linux/dma-mapping.h
#include linux/mbus.h
+#include linux/slab.h
#include asm/hardware/cache-l2x0.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -28,6 +29,7 @@
#include armada-370-xp.h
#include common.h
#include coherency.h
+#include mvebu-soc-id.h
static void __init armada_370_xp_map_io(void)
{
@@ -45,8 +47,38 @@ static void __init armada_370_xp_timer_and_clk_init(void)
#endif
}
+static void __init i2c_quirk(void)
+{
+ struct device_node *np;
+ u32 dev, rev;
+
+ /*
+* Only revisons more recent than A0 support the offload
+* mechanism. We can exit only if we are sure that we can
+* get the SoC revision and it is more recent than A0.
+*/
+ if (mvebu_get_soc_id(rev, dev) == 0 dev MV78XX0_A0_REV)
+ return;
+
+ for_each_compatible_node(np, NULL, marvell,mv78230-i2c) {
+ struct property *new_compat;
+
+ new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
+
+ new_compat-name = kstrdup(compatible, GFP_KERNEL);
+ new_compat-length = sizeof(marvell,mv78230-a0-i2c);
+ new_compat-value = kstrdup(marvell,mv78230-a0-i2c,
+ GFP_KERNEL);
+
+ of_update_property(np, new_compat);
+ }
+ return;
+}
+
static void __init armada_370_xp_dt_init(void)
{
+ if (of_machine_is_compatible(plathome,openblocks-ax3-4))
+ i2c_quirk();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
The first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and ead to a kernel hang during boot. The commit introduces a new the compatible string marvell,mv78230-a0-i2c for the i2c controller. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index 82e8f6f17179..9410ed72ec45 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -5,7 +5,7 @@ Required properties : - reg : Offset and length of the register set for the device - compatible : Should be marvell,mv64xxx-i2c or allwinner,sun4i-i2c - or marvell,mv78230-i2c + or marvell,mv78230-i2c or marvell,mv78230-a0-i2c - interrupts : The interrupt number Optional properties : -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The commit introduces a new the compatible string
marvell,mv78230-a0-i2c for the i2c controller. When this compatible
string is used the driver disables the offload mechanism and the
kernel no more hangs on these SoCs.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Reported-by: Andrew Lunn and...@lunn.ch
Cc: sta...@vger.kernel.org
---
drivers/i2c/busses/i2c-mv64xxx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 8be7e42aa4de..f424c0f89946 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -692,6 +692,10 @@ static const struct of_device_id
mv64xxx_i2c_of_match_table[] = {
{ .compatible = allwinner,sun4i-i2c, .data = mv64xxx_i2c_regs_sun4i},
{ .compatible = marvell,mv64xxx-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
{ .compatible = marvell,mv78230-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
+ {
+ .compatible = marvell,mv78230-a0-i2c,
+ .data = mv64xxx_i2c_regs_mv64xxx
+ },
{}
};
MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
@@ -783,6 +787,10 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
drv_data-errata_delay = true;
}
+ if (of_device_is_compatible(np, marvell,mv78230-a0-i2c)) {
+ drv_data-offload_enabled = false;
+ drv_data-errata_delay = true;
+ }
out:
return rc;
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/4] Fix i2c bus hang on A0 version of the Armada XP SoCs
Hi,
Here come the 5th version of the series fixing the i2c bus hang on A0
version of the Armada XP SoCs. It occurred on the early release of the
OpenBlocks AX3-4 boards. Indeed the first variants of Armada XP SoCs
(A0 stepping) have issues related to the i2c controller which prevent
to use the offload mechanism and lead to a kernel hang during boot.
The main change are the use of marvell,mv78230-a0-i2c and that the
function mvebu_get_soc_id() is now local to mach-mvebu.
The first patch add a mean to detect the SoCs version at run-time and
the second one use this feature in the driver.
The 3 first patches should be applied on 3.13-rc and on stable kernel
3.12 as it fixes a regression introduce by the commit 930ab3d403ae
i2c: mv64xxx: Add I2C Transaction Generator support.
The first patch could be latter be extend to also be used with dove,
kirkwood, orion5x and mv78x00 when there will be merged in mvebu and
even expose the SoC ID and revision to userspace.
Jason, do you still agree to take the series once Wolfram have given
his acked-by?
Thanks,
Gregory
Changelog:
v4 - v5:
- use the marvell,mv78230-a0-i2c compatible string instead of the
offload-broken property.
- move the mvebu-soc-id.h file into mach-mvebu
- no more export the mvebu_get_soc_id() function
- enable the quirk only on machines that we know may be affected, i.e.
OpenBlocks AX3-4.
v3 - v4:
- checked the offload-broken property instead of calling the
mvebu_get_soc_id() function in the mv64xxx_of_config() function.
- added the second patch to manage the quirk and update the device
node with the offload-broken if needed.
- removed the acked-by from Wolfram as the code have change in the 3rd
patch
In mvebu-soc-id.c:
- used EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
- used core_initcall instead of arch_initcall to be called earlier
enough.
v2 - v3:
- fixed typo in the comments added in i2c-mv64xxx.c
- used pr_fmt instead of %s __func__ in all the pr_* functions
- added a check on the pointer returned by of_get_next_child()
- added a return immediately after the 1st check to be able to get rid
of indenting the entire function code inside the if { ... } block.
v1 - v2:
- Changed the way to test the return of the function mvebu_get_soc_id
in order to make it clearer.
- Removed the superfluous parentheses
- Added Wolfram's acked-by on the 2nd patch
Gregory CLEMENT (4):
ARM: mvebu: Add support to get the ID and the revision of a SoC
ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible
.../devicetree/bindings/i2c/i2c-mv64xxx.txt| 2 +-
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/armada-370-xp.c| 32 ++
arch/arm/mach-mvebu/mvebu-soc-id.c | 119 +
arch/arm/mach-mvebu/mvebu-soc-id.h | 32 ++
drivers/i2c/busses/i2c-mv64xxx.c | 8 ++
6 files changed, 193 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-mvebu/mvebu-soc-id.c
create mode 100644 arch/arm/mach-mvebu/mvebu-soc-id.h
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/4] ARM: mvebu: Add support to get the ID and the revision of a SoC
All the mvebu SoCs have information related to their variant and
revision that can be read from the PCI control register.
This patch adds support for Armada XP and Armada 370. This reading of
the revision and the ID are done before the PCI initialization to
avoid any conflicts. Once these data are retrieved, the resources are
freed to let the PCI subsystem use it.
Cc: sta...@vger.kernel.org
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/mvebu-soc-id.c | 119 +
arch/arm/mach-mvebu/mvebu-soc-id.h | 32 ++
3 files changed, 152 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/mvebu-soc-id.c
create mode 100644 arch/arm/mach-mvebu/mvebu-soc-id.h
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 2d04f0e21870..878aebe98dcc 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -3,7 +3,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) :=
-I$(srctree)/$(src)/include \
AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
-obj-y += system-controller.o
+obj-y += system-controller.o mvebu-soc-id.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
obj-$(CONFIG_ARCH_MVEBU)+= coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.c
b/arch/arm/mach-mvebu/mvebu-soc-id.c
new file mode 100644
index ..fe4fc1cbdfaf
--- /dev/null
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.c
@@ -0,0 +1,119 @@
+/*
+ * ID and revision information for mvebu SoCs
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT gregory.clem...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * All the mvebu SoCs have information related to their variant and
+ * revision that can be read from the PCI control register. This is
+ * done before the PCI initialization to avoid any conflict. Once the
+ * ID and revision are retrieved, the mapping is freed.
+ */
+
+#define pr_fmt(fmt) mvebu-soc-id: fmt
+
+#include linux/clk.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/of.h
+#include linux/of_address.h
+#include mvebu-soc-id.h
+
+#define PCIE_DEV_ID_OFF0x0
+#define PCIE_DEV_REV_OFF 0x8
+
+#define SOC_ID_MASK0x
+#define SOC_REV_MASK 0xFF
+
+static u32 soc_dev_id;
+static u32 soc_rev;
+static bool is_id_valid;
+
+static const struct of_device_id mvebu_pcie_of_match_table[] = {
+ { .compatible = marvell,armada-xp-pcie, },
+ { .compatible = marvell,armada-370-pcie, },
+ {},
+};
+
+int mvebu_get_soc_id(u32 *dev, u32 *rev)
+{
+ if (is_id_valid) {
+ *dev = soc_dev_id;
+ *rev = soc_rev;
+ return 0;
+ } else
+ return -1;
+}
+
+static int __init mvebu_soc_id_init(void)
+{
+ struct device_node *np;
+ int ret = 0;
+ void __iomem *pci_base;
+ struct clk *clk;
+ struct device_node *child;
+
+ np = of_find_matching_node(NULL, mvebu_pcie_of_match_table);
+ if (!np)
+ return ret;
+
+ /*
+* ID and revision are available from any port, so we
+* just pick the first one
+*/
+ child = of_get_next_child(np, NULL);
+ if (child == NULL) {
+ pr_err(cannot get pci node\n);
+ ret = -ENOMEM;
+ goto clk_err;
+ }
+
+ clk = of_clk_get_by_name(child, NULL);
+ if (IS_ERR(clk)) {
+ pr_err(cannot get clock\n);
+ ret = -ENOMEM;
+ goto clk_err;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ pr_err(cannot enable clock\n);
+ goto clk_err;
+ }
+
+ pci_base = of_iomap(child, 0);
+ if (IS_ERR(pci_base)) {
+ pr_err(cannot map registers\n);
+ ret = -ENOMEM;
+ goto res_ioremap;
+ }
+
+ /* SoC ID */
+ soc_dev_id = readl(pci_base + PCIE_DEV_ID_OFF) 16;
+
+ /* SoC revision */
+ soc_rev = readl(pci_base + PCIE_DEV_REV_OFF) SOC_REV_MASK;
+
+ is_id_valid = true;
+
+ pr_info(MVEBU SoC ID=0x%X, Rev=0x%X\n, soc_dev_id, soc_rev);
+
+ iounmap(pci_base);
+
+res_ioremap:
+ clk_disable_unprepare(clk);
+
+clk_err:
+ of_node_put(child);
+ of_node_put(np);
+
+ return ret;
+}
+core_initcall(mvebu_soc_id_init);
+
diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.h
b/arch/arm/mach-mvebu/mvebu-soc-id.h
new file mode 100644
index ..31654252fe35
--- /dev/null
+++ b/arch/arm/mach-mvebu/mvebu-soc-id.h
@@ -0,0 +1,32 @@
+/*
+ * Marvell EBU SoC ID and
Re: [PATCH v5 0/4] Fix i2c bus hang on A0 version of the Armada XP SoCs
On Wednesday 08 January 2014 16:06:25 Gregory CLEMENT wrote: Hi, Here come the 5th version of the series fixing the i2c bus hang on A0 version of the Armada XP SoCs. It occurred on the early release of the OpenBlocks AX3-4 boards. Indeed the first variants of Armada XP SoCs (A0 stepping) have issues related to the i2c controller which prevent to use the offload mechanism and lead to a kernel hang during boot. The main change are the use of marvell,mv78230-a0-i2c and that the function mvebu_get_soc_id() is now local to mach-mvebu. The first patch add a mean to detect the SoCs version at run-time and the second one use this feature in the driver. The 3 first patches should be applied on 3.13-rc and on stable kernel 3.12 as it fixes a regression introduce by the commit 930ab3d403ae i2c: mv64xxx: Add I2C Transaction Generator support. The first patch could be latter be extend to also be used with dove, kirkwood, orion5x and mv78x00 when there will be merged in mvebu and even expose the SoC ID and revision to userspace. Jason, do you still agree to take the series once Wolfram have given his acked-by? Whole series Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
On Wed, Jan 08, 2014 at 04:06:28PM +0100, Gregory CLEMENT wrote:
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The commit introduces a new the compatible string
marvell,mv78230-a0-i2c for the i2c controller. When this compatible
string is used the driver disables the offload mechanism and the
kernel no more hangs on these SoCs.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Reported-by: Andrew Lunn and...@lunn.ch
Cc: sta...@vger.kernel.org
---
drivers/i2c/busses/i2c-mv64xxx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
b/drivers/i2c/busses/i2c-mv64xxx.c
index 8be7e42aa4de..f424c0f89946 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -692,6 +692,10 @@ static const struct of_device_id
mv64xxx_i2c_of_match_table[] = {
{ .compatible = allwinner,sun4i-i2c, .data = mv64xxx_i2c_regs_sun4i},
{ .compatible = marvell,mv64xxx-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
{ .compatible = marvell,mv78230-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
+ {
+ .compatible = marvell,mv78230-a0-i2c,
+ .data = mv64xxx_i2c_regs_mv64xxx
+ },
I think a oneliner entry like the entries above is easier to read, but
that is very minor...
Acked-by: Wolfram Sang w...@the-dreams.de
signature.asc
Description: Digital signature
Re: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
+ new_compat-name = kstrdup(compatible, GFP_KERNEL); + new_compat-length = sizeof(marvell,mv78230-a0-i2c); + new_compat-value = kstrdup(marvell,mv78230-a0-i2c, + GFP_KERNEL); + Very minor again: Strange whitespacing after = signature.asc Description: Digital signature
Re: [PATCH v5 3/4] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
On 08/01/2014 16:21, Wolfram Sang wrote:
On Wed, Jan 08, 2014 at 04:06:28PM +0100, Gregory CLEMENT wrote:
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The commit introduces a new the compatible string
marvell,mv78230-a0-i2c for the i2c controller. When this compatible
string is used the driver disables the offload mechanism and the
kernel no more hangs on these SoCs.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Reported-by: Andrew Lunn and...@lunn.ch
Cc: sta...@vger.kernel.org
---
drivers/i2c/busses/i2c-mv64xxx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
b/drivers/i2c/busses/i2c-mv64xxx.c
index 8be7e42aa4de..f424c0f89946 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -692,6 +692,10 @@ static const struct of_device_id
mv64xxx_i2c_of_match_table[] = {
{ .compatible = allwinner,sun4i-i2c, .data = mv64xxx_i2c_regs_sun4i},
{ .compatible = marvell,mv64xxx-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
{ .compatible = marvell,mv78230-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
+{
+.compatible = marvell,mv78230-a0-i2c,
+.data = mv64xxx_i2c_regs_mv64xxx
+},
I think a oneliner entry like the entries above is easier to read, but
that is very minor...
By using one line we would break the 80 character rule,
hat why I did in this way.
Acked-by: Wolfram Sang w...@the-dreams.de
Thanks!
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/4] ARM: mvebu: Add quirk for i2c for the OpenBlocks AX3-4 board
On 08/01/2014 16:22, Wolfram Sang wrote: +new_compat-name = kstrdup(compatible, GFP_KERNEL); +new_compat-length = sizeof(marvell,mv78230-a0-i2c); +new_compat-value = kstrdup(marvell,mv78230-a0-i2c, +GFP_KERNEL); + Very minor again: Strange whitespacing after = arg I missed it :( -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
+ {
+ .compatible = marvell,mv78230-a0-i2c,
+ .data = mv64xxx_i2c_regs_mv64xxx
+ },
I think a oneliner entry like the entries above is easier to read, but
that is very minor...
By using one line we would break the 80 character rule,
hat why I did in this way.
This rule is there to keep code readable. If it doesn't help
readability, it may/can/should be broken IMO. It's a mileage, though.
signature.asc
Description: Digital signature
Re: [PATCH v5 3/4] i2c: mv64xxx: Fix bus hang on A0 version of the Armada XP SoCs
On Wednesday 08 January 2014, Gregory CLEMENT wrote:
On 08/01/2014 16:21, Wolfram Sang wrote:
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
b/drivers/i2c/busses/i2c-mv64xxx.c
index 8be7e42aa4de..f424c0f89946 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -692,6 +692,10 @@ static const struct of_device_id
mv64xxx_i2c_of_match_table[] = {
{ .compatible = allwinner,sun4i-i2c, .data =
mv64xxx_i2c_regs_sun4i},
{ .compatible = marvell,mv64xxx-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
{ .compatible = marvell,mv78230-i2c, .data =
mv64xxx_i2c_regs_mv64xxx},
+{
+.compatible = marvell,mv78230-a0-i2c,
+.data = mv64xxx_i2c_regs_mv64xxx
+},
I think a oneliner entry like the entries above is easier to read, but
that is very minor...
By using one line we would break the 80 character rule,
hat why I did in this way.
It's more a guideline than a strict rule. I agree that one line would
be better here, but it's not important.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: viperboard: remove superfluous assignment
On Wednesday 08 January 2014 22:21:33, Wolfram Sang wrote:
cppcheck rightfully says:
drivers/i2c/busses/i2c-viperboard.c:169: style: Variable 'bytes_xfer' is
assigned a value that is never used.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-viperboard.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-viperboard.c
b/drivers/i2c/busses/i2c-viperboard.c index 6976e1c..7533fa3 100644
--- a/drivers/i2c/busses/i2c-viperboard.c
+++ b/drivers/i2c/busses/i2c-viperboard.c
@@ -118,8 +118,7 @@ static int vprbrd_i2c_addr(struct usb_device *usb_dev,
static int vprbrd_i2c_read(struct vprbrd *vb, struct i2c_msg *msg)
{
int ret;
- u16 remain_len, bytes_xfer, len1, len2,
- start = 0x;
+ u16 remain_len, len1, len2, start = 0x;
struct vprbrd_i2c_read_msg *rmsg =
(struct vprbrd_i2c_read_msg *)vb-buf;
@@ -166,7 +165,6 @@ static int vprbrd_i2c_read(struct vprbrd *vb, struct
i2c_msg *msg) rmsg-header.len3 = remain_len - 512;
rmsg-header.len4 = 0x00;
rmsg-header.len5 = 0x00;
- bytes_xfer = remain_len;
remain_len = 0;
} else if (remain_len = 1022) {
len1 = 512;
Acked-by: Lars Poeschel poesc...@lemonage.de
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I have a very lucrative Business
ATTN: Dear, I am Dr. Musa Hamed Executive Director of the Bank of Africa Plc B.O.A,Cotonou Benin Rep. I have a very lucrative Business proposal worth of 21,500,000.00 USD. An Iraqi named Hamadi Hashem a business man made a fixed deposit of 21,500,000.00 USD . Upon maturity several notices was sent to him, even during the war,eleven years ago (2003) up till this date. Again after the war another notification was sent and still no response came from him. it has been found out that Hamadi Hashem and his family had been killed during the war in bomb blast that hit their home at Mukaradeeb where his personal oil well was. I am prepared to split the funds with you 50%:50%.By placing you as the NEXT OF KIN to his deposit. Should you be interested in doing this deal with me, please send me the following information: (1) Your Name (2) Resident Address (3) Your Occupation (4) Your Phone Number (5) Date of Birth (6) Resident Country And I will prefer you to reach me privately and securely on my personal email address: dr.musahame...@yahoo.fr Tel: +229-988-400-97 I will provide you with further information as soon as I hear positively from you. Regards, Dr. Musa Hamed -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
