Messages in this thread | | | Date | Thu, 22 Mar 2012 11:07:35 -0700 | From | David Daney <> | Subject | Re: [PATCH 2/2] i2c: Dynamically assign adapter id if it wasn't explictly specified |
| |
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> >>
| |