[PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[dl9pf]

From: Behan Webster <behanw@converseincode.com>

The only real change is passing in event_mask to the formerly nested functions.
Otherwise it's just moving around function and macro code.

This is the only place in the Linux kernel where nested functions are still in
use. Nested functions aren't part of the C standards, and complicate the
generated code. Although the Linux Kernel has never set out to be entirely C
standard compliant, it is increasingly compliant to the standard which is
supported by other compilers such as Clang. The LLVMLinux project is working on
being able to compile the Linux kernel with Clang. The use of nested functions
blocks this effort.

Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>

CC: David Woodhouse <David.Woodhouse@intel.com>
CC: Matthew Garrett <matthew.garrett@nebula.com>
CC: ibm-acpi-devel@lists.sourceforge.net
CC: platform-driver-x86@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
 drivers/platform/x86/thinkpad_acpi.c | 86 +++++++++++++++++++-----------------
 1 file changed, 45 insertions(+), 41 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index defb6af..e6e068e 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2321,53 +2321,55 @@ static void hotkey_read_nvram(struct tp_nvram_state *n, const u32 m)
 	}
 }
 
-static void hotkey_compare_and_issue_event(struct tp_nvram_state *oldn,
-					   struct tp_nvram_state *newn,
-					   const u32 event_mask)
-{
-
 #define TPACPI_COMPARE_KEY(__scancode, __member) \
-	do { \
-		if ((event_mask & (1 << __scancode)) && \
-		    oldn->__member != newn->__member) \
-			tpacpi_hotkey_send_key(__scancode); \
-	} while (0)
+do { \
+	if ((event_mask & (1 << __scancode)) && \
+	    oldn->__member != newn->__member) \
+		tpacpi_hotkey_send_key(__scancode); \
+} while (0)
 
 #define TPACPI_MAY_SEND_KEY(__scancode) \
-	do { \
-		if (event_mask & (1 << __scancode)) \
-			tpacpi_hotkey_send_key(__scancode); \
-	} while (0)
+do { \
+	if (event_mask & (1 << __scancode)) \
+		tpacpi_hotkey_send_key(__scancode); \
+} while (0)
 
-	void issue_volchange(const unsigned int oldvol,
-			     const unsigned int newvol)
-	{
-		unsigned int i = oldvol;
+static void issue_volchange(const unsigned int oldvol,
+			    const unsigned int newvol,
+			    const u32 event_mask)
+{
+	unsigned int i = oldvol;
 
-		while (i > newvol) {
-			TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_VOLUMEDOWN);
-			i--;
-		}
-		while (i < newvol) {
-			TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_VOLUMEUP);
-			i++;
-		}
+	while (i > newvol) {
+		TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_VOLUMEDOWN);
+		i--;
+	}
+	while (i < newvol) {
+		TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_VOLUMEUP);
+		i++;
 	}
+}
 
-	void issue_brightnesschange(const unsigned int oldbrt,
-				    const unsigned int newbrt)
-	{
-		unsigned int i = oldbrt;
+static void issue_brightnesschange(const unsigned int oldbrt,
+				   const unsigned int newbrt,
+				   const u32 event_mask)
+{
+	unsigned int i = oldbrt;
 
-		while (i > newbrt) {
-			TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_FNEND);
-			i--;
-		}
-		while (i < newbrt) {
-			TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_FNHOME);
-			i++;
-		}
+	while (i > newbrt) {
+		TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_FNEND);
+		i--;
 	}
+	while (i < newbrt) {
+		TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_FNHOME);
+		i++;
+	}
+}
+
+static void hotkey_compare_and_issue_event(struct tp_nvram_state *oldn,
+					   struct tp_nvram_state *newn,
+					   const u32 event_mask)
+{
 
 	TPACPI_COMPARE_KEY(TP_ACPI_HOTKEYSCAN_THINKPAD, thinkpad_toggle);
 	TPACPI_COMPARE_KEY(TP_ACPI_HOTKEYSCAN_FNSPACE, zoom_toggle);
@@ -2402,7 +2404,8 @@ static void hotkey_compare_and_issue_event(struct tp_nvram_state *oldn,
 		    oldn->volume_level != newn->volume_level) {
 			/* recently muted, or repeated mute keypress, or
 			 * multiple presses ending in mute */
-			issue_volchange(oldn->volume_level, newn->volume_level);
+			issue_volchange(oldn->volume_level, newn->volume_level,
+				event_mask);
 			TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_MUTE);
 		}
 	} else {
@@ -2412,7 +2415,8 @@ static void hotkey_compare_and_issue_event(struct tp_nvram_state *oldn,
 			TPACPI_MAY_SEND_KEY(TP_ACPI_HOTKEYSCAN_VOLUMEUP);
 		}
 		if (oldn->volume_level != newn->volume_level) {
-			issue_volchange(oldn->volume_level, newn->volume_level);
+			issue_volchange(oldn->volume_level, newn->volume_level,
+				event_mask);
 		} else if (oldn->volume_toggle != newn->volume_toggle) {
 			/* repeated vol up/down keypress at end of scale ? */
 			if (newn->volume_level == 0)
@@ -2425,7 +2429,7 @@ static void hotkey_compare_and_issue_event(struct tp_nvram_state *oldn,
 	/* handle brightness */
 	if (oldn->brightness_level != newn->brightness_level) {
 		issue_brightnesschange(oldn->brightness_level,
-				       newn->brightness_level);
+				       newn->brightness_level, event_mask);
 	} else if (oldn->brightness_toggle != newn->brightness_toggle) {
 		/* repeated key presses that didn't change state */
 		if (newn->brightness_level == 0)
-- 
1.8.4.5

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[Christoph Hellwig]

On Wed, Feb 12, 2014 at 09:58:46PM +0100, dl9pf@gmx.de wrote:
> being able to compile the Linux kernel with Clang. The use of nested functions
> blocks this effort.

Is there any good way to make gcc warn about the use of nested functions?

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[Behan Webster]

On 02/12/14 13:11, Christoph Hellwig wrote:
> On Wed, Feb 12, 2014 at 09:58:46PM +0100, dl9pf@gmx.de wrote:
>> being able to compile the Linux kernel with Clang. The use of nested functions
>> blocks this effort.
> Is there any good way to make gcc warn about the use of nested functions?
Interesting idea.

'-Wtrampolines'
      Warn about trampolines generated for pointers to nested functions.

      A trampoline is a small piece of data or code that is created at
      run time on the stack when the address of a nested function is
      taken, and is used to call the nested function indirectly.  For
      some targets, it is made up of data only and thus requires no
      special treatment.  But, for most targets, it is made up of code
      and thus requires the stack to be made executable in order for the
      program to work properly.


That might work.

Behan

-- 
Behan Webster
behanw@converseincode.com

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[Måns Rullgård]

Behan Webster <behanw@converseincode.com> writes:

> On 02/12/14 13:11, Christoph Hellwig wrote:
>> On Wed, Feb 12, 2014 at 09:58:46PM +0100, dl9pf@gmx.de wrote:
>>> being able to compile the Linux kernel with Clang. The use of nested functions
>>> blocks this effort.
>> Is there any good way to make gcc warn about the use of nested functions?
> Interesting idea.
>
> '-Wtrampolines'
>      Warn about trampolines generated for pointers to nested functions.
>
>      A trampoline is a small piece of data or code that is created at
>      run time on the stack when the address of a nested function is
>      taken, and is used to call the nested function indirectly.  For
>      some targets, it is made up of data only and thus requires no
>      special treatment.  But, for most targets, it is made up of code
>      and thus requires the stack to be made executable in order for the
>      program to work properly.
>
> That might work.

That sounds like it will only warn if a trampoline is needed.  A nested
function whose address isn't taken, as is the case here, wouldn't
trigger this warning.

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[Richard Weinberger]

On Wed, Feb 12, 2014 at 10:20 PM, Behan Webster
<behanw@converseincode.com> wrote:
> On 02/12/14 13:11, Christoph Hellwig wrote:
>>
>> On Wed, Feb 12, 2014 at 09:58:46PM +0100, dl9pf@gmx.de wrote:
>>>
>>> being able to compile the Linux kernel with Clang. The use of nested
>>> functions
>>> blocks this effort.
>>
>> Is there any good way to make gcc warn about the use of nested functions?
>
> Interesting idea.
>
> '-Wtrampolines'
>      Warn about trampolines generated for pointers to nested functions.
>
>      A trampoline is a small piece of data or code that is created at
>      run time on the stack when the address of a nested function is
>      taken, and is used to call the nested function indirectly.  For
>      some targets, it is made up of data only and thus requires no
>      special treatment.  But, for most targets, it is made up of code
>      and thus requires the stack to be made executable in order for the
>      program to work properly.
>
>
> That might work.

I gave it a quick try, but gcc (4.7) did not bark.

-- 
Thanks,
//richard

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[David Rientjes]

On Wed, 12 Feb 2014, dl9pf@gmx.de wrote:

> From: Behan Webster <behanw@converseincode.com>
> 
> The only real change is passing in event_mask to the formerly nested functions.
> Otherwise it's just moving around function and macro code.
> 
> This is the only place in the Linux kernel where nested functions are still in
> use. Nested functions aren't part of the C standards, and complicate the
> generated code. Although the Linux Kernel has never set out to be entirely C
> standard compliant, it is increasingly compliant to the standard which is
> supported by other compilers such as Clang. The LLVMLinux project is working on
> being able to compile the Linux kernel with Clang. The use of nested functions
> blocks this effort.
> 

So this patch is only as a courtesy to clang and you're not complaining 
about things like __builtin() functions, typeof, or a ? : b conditional 
operators because clang happens to support them?

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[Al Viro]

On Wed, Feb 12, 2014 at 01:54:43PM -0800, David Rientjes wrote:

> So this patch is only as a courtesy to clang and you're not complaining 
> about things like __builtin() functions, typeof, or a ? : b conditional 
> operators because clang happens to support them?

That patch removes a disgusting construct; who cares how they'd discovered
it?  Consider it courtesy to reviewers, clang or no clang...

Folks, it's C; no need to bring Pascal misfeatures in, even if gcc happens
to accept them.

Re: [PATCH] x86, acpi: LLVMLinux: Remove nested functions from Thinkpad ACPI

[Henrique de Moraes Holschuh]

On Wed, 12 Feb 2014, dl9pf@gmx.de wrote:
> From: Behan Webster <behanw@converseincode.com>
> The only real change is passing in event_mask to the formerly nested functions.
> Otherwise it's just moving around function and macro code.
> 
> This is the only place in the Linux kernel where nested functions are still in
> use. Nested functions aren't part of the C standards, and complicate the
> generated code. Although the Linux Kernel has never set out to be entirely C
> standard compliant, it is increasingly compliant to the standard which is
> supported by other compilers such as Clang. The LLVMLinux project is working on
> being able to compile the Linux kernel with Clang. The use of nested functions
> blocks this effort.
> 
> Signed-off-by: Behan Webster <behanw@converseincode.com>
> Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
> 
> CC: David Woodhouse <David.Woodhouse@intel.com>
> CC: Matthew Garrett <matthew.garrett@nebula.com>
> CC: ibm-acpi-devel@lists.sourceforge.net
> CC: platform-driver-x86@vger.kernel.org
> CC: linux-kernel@vger.kernel.org

Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh