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

[David Daney <ddaney.cavm@gmail.com>]

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@cavium.com>
>>