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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux