On 12:50 Mon 20 Feb , Russell King - ARM Linux wrote: > On Mon, Feb 20, 2012 at 11:22:31AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 10:08 Mon 20 Feb , Russell King - ARM Linux wrote: > > > On Mon, Feb 20, 2012 at 10:58:13AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > > On 18:17 Mon 13 Feb , Karol Lewandowski wrote: > > > > > > + - udelay: delay between GPIO operations (may depend on each platform) > > > > > > + - timeout: timeout to get data (ms) > > > > > > > > > > > > > > > If these are really needed then I would prefer to have these fully > > > > > qualified (with unit type "-ms/-millisecs" appended). > > > > > > > > > > Regulator framework, with its "-microvolt/-microamp", serve here as > > > > > prime example of being quite descriptive (one doesn't neet to look up > > > > > the docs). Please see: > > > > > > > > > > http://permalink.gmane.org/gmane.linux.ports.arm.omap/67637 > > > > timeout are usualy in ms I don't really see the need of -ms or so > > > > > > Which is obviously total crap for udelay, which would be in _micro_seconds. > > agreed but here on i2c gpio I never see timetout as udelay so I don't see > > the mandatory to force the name in the binding > > > > futhermore it's maybe linux specific > > Stop grabbing at straws. There's nothing linux specific about the units > of specification. > > What is linux specific is specifying the _delay_ rather than specifying > the bus frequency. So as soon as you're trying to justify not adding > the units because they may be linux specific, you've already lost that > argument by using a delay rather than a bus frequency. You can't have > it both ways. > > Moreover, mixing microseconds and milliseconds in the properties for a > device is absolutely insane. > > So, which ever way, your patch as it currently stands is wrong and broken. no what I said is the binding timeout is maybe linux specific for i2c gpio Best Regards, J. -- 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
