Hi Guenter,
On Wed, Jul 29, 2015 at 9:58 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On 07/29/2015 12:33 PM, Moore, Robert wrote:
-----Original Message-----
From: Guenter Roeck [mailto:linux@xxxxxxxxxxxx]
Sent: Wednesday, July 29, 2015 11:39 AM
To: Moore, Robert; rjw@xxxxxxxxxxxxx
Cc: lenb@xxxxxxxxxx; Zheng, Lv; linux-acpi@xxxxxxxxxxxxxxx; linux-
kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx
Subject: Re: [PATCH v2] acpi: Use kstrtoul() instead of
strtoul()/simple_strtoul()
On 07/29/2015 10:51 AM, Moore, Robert wrote:
-----Original Message-----
From: Guenter Roeck [mailto:linux@xxxxxxxxxxxx]
Sent: Monday, July 27, 2015 5:32 PM
To: rjw@xxxxxxxxxxxxx
Cc: lenb@xxxxxxxxxx; Moore, Robert; Zheng, Lv;
linux-acpi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
devel@xxxxxxxxxx; Guenter Roeck
Subject: [PATCH v2] acpi: Use kstrtoul() instead of
strtoul()/simple_strtoul()
simple_strtoul() is deprecated; replace with kstrtoul() and
kstrtouint().
The ACPICA code is os-independent and cannot use these functions (at
least not directly).
Odd argument, given that kstrtoul() is used already in the acpi code.
They are not in the os-independent ACPICA code. The ACPI-related drivers
are another story, since they are OS-dendent.
That this OS independent code mandates functions such as strtoul(),
which may not exist in a target OS, and that it maps strtoul() to
simple_strtoul() in a global include file, doesn't seem to be
correct either and is asking for repeated trouble. I would have
hoped that at the very least such mappings would be implemented
in local include files.
The header is obviously OS-dependent and it does what it does just
because simple_strtoul() is available and serves the purpose.
As I said in the previous message, the strtoul() used by ACPICA might
be redefined in terms of kstroul().
And the change in sysfs.c is still OK. Do you want me to apply this
change only?