Re: [PATCH 2/2] i2c: Dynamically assign adapter id if it wasn't explictlyspecified

From: David Daney
Date: Thu Mar 22 2012 - 14:08:10 EST


On 03/22/2012 10:48 AM, Karol Lewandowski wrote:
On 22.03.2012 17:58, David Daney wrote:

[...]

diff --git a/drivers/i2c/busses/i2c-octeon.c
b/drivers/i2c/busses/i2c-octeon.c
index ee139a5..8470232 100644
--- a/drivers/i2c/busses/i2c-octeon.c
+++ b/drivers/i2c/busses/i2c-octeon.c
@@ -581,7 +581,7 @@ static int __devinit octeon_i2c_probe(struct
platform_device *pdev)

i2c->adap = octeon_i2c_ops;
i2c->adap.dev.parent =&pdev->dev;
- i2c->adap.nr = pdev->id>= 0 ? pdev->id : 0;
+ i2c->adap.nr = pdev->id;

I guess the OCTEON bit seems sane enough. I don't fully understand why
this needs changing, because OCTEON platform code always passes a
non-negative pdev->id.


i2c controllers instantiated from device tree seem to have -1 as id.
Thus, trying to register more than one controller will fail as both
will try to register on bus 0.

However, I've just found that you got rid of this line altogether and
switched to dynamic id allocation (i2c_add_adapter() instead of
_numbered_ variant) in "MIPS: Octeon: Use Device Tree." RFC.
Found here:

http://thread.gmane.org/gmane.linux.kernel/1104062

In the light of above my (octeon-)fixup becomes redundant.

Shall I repost this patch without octeon changes or is ok anyway?

My preference would be to omit the OCTEON portion from your patch. As you noted, I plan to blow all that code away in the very near future, and the patch is not needed for correctness as far as I can see.

David Daney



Thanks!

But since you asked for it:

Acked-by: David Daney<david.daney@xxxxxxxxxx>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/