On Wed, 13 Feb 2013 14:09:08 -0700, Stephen Warren wrote: > On 02/13/2013 11:02 AM, Doug Anderson wrote: > > The force_nr parameter to i2c_add_mux_adapter() uses 0 to signify that > > we don't want to force the bus number of the adapter. This is > > non-ideal because: > > * 0 is actually a valid bus number to request > > * i2c_add_numbered_adapter() (which i2c_add_mux_adapter() calls) uses > > -1 to mean the same thing. That means extra logic in > > i2c_add_mux_adapter(). > > > > Fix i2c_add_mux_adapter() to use -1 and update all mux drivers > > accordingly. > > > > Signed-off-by: Doug Anderson <[email protected]> > > --- > > Notes: > > - If there's a good reason that force_nr uses 0 for auto then feel > > free to drop this patch. I've place it at the end of the series to > > make it easy to just drop it. > > IIRC (and I only vaguely do...) it's because: > > > diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c > > b/drivers/i2c/muxes/i2c-mux-gpio.c > > index 9f50ef0..301ed0b 100644 > > --- a/drivers/i2c/muxes/i2c-mux-gpio.c > > +++ b/drivers/i2c/muxes/i2c-mux-gpio.c > > @@ -208,7 +208,7 @@ static int i2c_mux_gpio_probe(struct platform_device > > *pdev) > > } > > > > for (i = 0; i < mux->data.n_values; i++) { > > - u32 nr = mux->data.base_nr ? (mux->data.base_nr + i) : 0; > > + int nr = mux->data.base_nr ? (mux->data.base_nr + i) : -1; > > Here, mux->data.base_nr is platform data (or copied directly from it), > and any field in a platform data struct stored in a global variable not > explicitly initialized would be 0, hence 0 would typically mean "no > explicit bus number desired". Since a mux can't exist without a parent > I2C bus, it's unlikely anyone would want a mux to be I2C bus 0, but > rather the parent to have that number.
Yes, as I recall this is exactly the reason why the current code is the way it is. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
