On Wed, Jan 23, 2019 at 11:18:54AM +0100, Simon Horman wrote: > On Sat, Jan 19, 2019 at 12:36:42PM +0100, Wolfram Sang wrote: > > I think it is clear enough if we have the explanation once and make it > > clear it is applicable for both SCL and SDA. > > > > Signed-off-by: Wolfram Sang <[email protected]> > > --- > > drivers/i2c/busses/i2c-gpio.c | 15 ++++----------- > > 1 file changed, 4 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c > > index c008d209f0b8..b9d43bc2853f 100644 > > --- a/drivers/i2c/busses/i2c-gpio.c > > +++ b/drivers/i2c/busses/i2c-gpio.c > > @@ -286,10 +286,10 @@ static int i2c_gpio_probe(struct platform_device > > *pdev) > > > > /* > > * First get the GPIO pins; if it fails, we'll defer the probe. > > - * If the SDA line is marked from platform data or device tree as > > - * "open drain" it means something outside of our control is making > > - * this line being handled as open drain, and we should just handle > > - * it as any other output. Else we enforce open drain as this is > > + * If the SCL/SDA lines are marked from platform data or device tree > > + * as "open drain" it means something outside of our control is making > > + * these lines being handled as open drain, and we should just handle > > + * them as any other output. Else we enforce open drain as this is > > * required for an I2C bus. > > <2c> > If the SCL/SDA lines are marked "open drain" by platform data or > device tree then this means that something outside of our control is > marking these lines to be handled as open drain, and we should just > handle them as we handle any other output. Else we enforce open > drain as this is required for an I2C bus. > </2c>
Cool, thanks Simon. Should I add your SoB when sending V2?
signature.asc
Description: PGP signature
