On Fri, Mar 7, 2014 at 9:10 PM, Pavel Machek <pavel@xxxxxx> wrote: > On Fri 2014-03-07 11:04:59, Linus Walleij wrote: >> On Fri, Feb 28, 2014 at 6:01 PM, Pavel Machek <pavel@xxxxxx> wrote: >> > On Thu 2014-02-27 21:08:01, Linus Walleij wrote: >> >> On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC <jenny.tc@xxxxxxxxx> wrote: >> >> >> >> > +++ b/include/linux/power/power_supply_charger.h >> >> >> >> > +#define MAX_CUR_VOLT_SAMPLES 3 >> >> > +#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ) >> >> >> >> Why are things defined in Jiffies like this insead of seconds, milliseconds >> >> etc? This will vary with the current operating frequency of the system, >> >> why should physical measurements do that? >> > >> > It is actually ok. The define is relative to jiffies, and that's what >> > interface expects. >> >> So consider the option that the interface is wrong. >> >> Stating something like a sample period in system-specific jiffies >> instead of period time T is just weird. What control systems >> guy would understand this? > > 30*HZ means 30 seconds in the kernel... what is hard to understand > about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. One reason is that this kind of code actually needs review from non-programmers, people like chemists and physicists. I know it may be far fetched so no strong preference for sure. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
