On Wed, May 25, 2011 at 5:20 AM, Jonathan Cameron <jic23@xxxxxxxxx> wrote:
Hi Jonathan,
> So after all this, I'd leave it as it currently is! Sorry for the wild
> goose chase.
I think I lost you somewhere in there, but I'm glad it turned out that
I was doing it right!
> Subject to responses to RFC on delay control, I'm happy with this driver.
> Good work and I look forward to lots more drivers in the future.
Thanks! Don't worry, we have plenty more accelerometers to merge
drivers for eventually!
I saw the git pull request from yesterday; does this mean there's no
chance to make it in this merge window? I know Dmitry will be
traveling next week, but we are really hoping to be able to give our
customer a 'final' version within a few business days if at all
possible.
>> + if (!tj9->hw_initialized) {
>> + mdelay(40);
> nitpick - is it alright to sleep for longer? If slow msleep is
> a better bet as lets the processor get on with something useful
> in the meantime.
Good point. The 40ms is based on the power-up time in the product
specification, which itself is just a minimum value. In reality, the
time between power on and communication could be significantly longer
with no impact to the hardware. So yes, this can be changed to msleep
with no issues.
>> + unsigned long val;
>> + int ret = kstrtoul(buf, 10, &val);
>> + if (ret < 0)
>> + return ret;
> You could use the just merged strtobool
I implemented this change and it compiled with no issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
