On Tuesday, February 04, 2014 04:24:13 PM Sebastian Capella wrote:
> Quoting Rafael J. Wysocki (2014-02-04 16:28:13)
> > On Tuesday, February 04, 2014 04:06:42 PM Sebastian Capella wrote:
> > > Quoting Rafael J. Wysocki (2014-02-04 16:03:29)
> > > > On Tuesday, February 04, 2014 03:22:22 PM Sebastian Capella wrote:
> > > > > Quoting Sebastian Capella (2014-02-04 14:37:33)
> > > > > > Quoting Rafael J. Wysocki (2014-02-04 13:36:29)
> > > > > > > > static int __init resumedelay_setup(char *str)
> > > > > > > > {
> > > > > > > > - resume_delay = simple_strtoul(str, NULL, 0);
> > > > > > > > + int ret = kstrtoint(str, 0, &resume_delay);
> > > > > > > > + /* mask must_check warn; on failure, leaves resume_delay
> > > > > > > > unchanged */
> > > > > > > > + (void)ret;
> > > > >
> > > > > One unintended consequence of this change is that it'll now accept a
> > > > > negative integer parameter.
> > > >
> > > > Well, what about using kstrtouint(), then?
> > > I was thinking of doing something like:
> > >
> > > int delay, res;
> > > res = kstrtoint(str, 0, &delay);
> > > if (!res && delay >= 0)
> > > resume_delay = delay;
> > > return 1;
> >
> > It uses simple_strtoul() for a reason. You can change the type of
> > resume_delay
> > to match, but the basic question is:
> >
> > Why exactly do you want to change that thing?
>
> This entire patch is a result of a single checkpatch warning from a printk
> that I indented.
>
> I was hoping to be helpful by removing all of the warnings from this
> file, since I was going to have a separate cleanup patch for the printk.
>
> I can see this is not a good direction.
>
> Would it be better also to leave the file's printks as they were and drop
> the cleanup patch completely?
Well, I had considered changing them to pr_something, but decided that it
wasn't worth the effort. Quite frankly, I'd leave the code as is. :-)
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
