platform/x86: intel-vbtn: Remove redundant inclusions

Replace License short header by SPDX identifier.

Signed-off-by Andy Shevchenko <[email protected]>

---
 drivers/platform/x86/intel-vbtn.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

drivers/platform/x86/intel-vbtn.c +1 -11

index 69bc39f8d61d..b703d6f5b099 100644
@@ -1,19 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  *  Intel Virtual Button driver for Windows 8.1+
  *
  *  Copyright (C) 2016 AceLan Kao <[email protected]>
  *  Copyright (C) 2016 Alex Hung <[email protected]>
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
  */
 
 #include <linux/acpi.h>

Signature · 1 line

2.15.1

Some headers are not needed since the driver can be built as module. Remove them.

While here, sort headers alphabetically.

Signed-off-by Andy Shevchenko <[email protected]>

---
 drivers/platform/x86/intel-vbtn.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

drivers/platform/x86/intel-vbtn.c +3 -5

index 101c100a3929..69bc39f8d61d 100644
@@ -16,15 +16,13 @@
  *
  */
 
+#include <linux/acpi.h>
+#include <linux/input.h>
+#include <linux/input/sparse-keymap.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
-#include <linux/init.h>
-#include <linux/input.h>
 #include <linux/platform_device.h>
-#include <linux/input/sparse-keymap.h>
-#include <linux/acpi.h>
 #include <linux/suspend.h>
-#include <acpi/acpi_bus.h>
 
 /* When NOT in tablet mode, VGBS returns with the flag 0x40 */
 #define TABLET_MODE_FLAG 0x40

Signature · 1 line

2.15.1

Quoted 2 lines · Andy Shevchenko

Some headers are not needed since the driver can be built as module. Remove them.

Removing init because it's included by module.h, and removing acpi_bus.h because it's included by acpi.h - but not because it can be built as a module - right? Just checking, the wording in the commit msg seemed odd to me.

These removals seem appropriate to me, but so we have it recorded here - in general, including headers that you explicitly make use of is good practice, and not depending on others to include them. But in this case, the implicit includes are reasonable expectations as they are tightly coupled with the parent include.

Reviewed-by Darren Hart (VMware) <[email protected]>

Quoted 8 lines · Darren Hart

Quoted 2 lines · Andy Shevchenko

Some headers are not needed since the driver can be built as module. Remove them.

Removing init because it's included by module.h, and removing acpi_bus.h because it's included by acpi.h - but not because it can be built as a module - right? Just checking, the wording in the commit msg seemed odd to me.

Correct. I'll rephrase this in place.

Quoted 5 lines

These removals seem appropriate to me, but so we have it recorded here - in general, including headers that you explicitly make use of is good practice, and not depending on others to include them. But in this case, the implicit includes are reasonable expectations as they are tightly coupled with the parent include.

There are two classes of headers (at least?):
- let say "user-visible" ones, which drivers usually include like you pointed above
- low level ones, which in most cases are not supposed to be included directly

So, for first class I agree with you, and acpi_bus.h in this case can be considered as an example of second class.

Quoted 15 lines · Andy Shevchenko

Quoted 12 lines · Darren Hart

Quoted 3 lines · Andy Shevchenko

Some headers are not needed since the driver can be built as module.
Remove them.

Removing init because it's included by module.h, and removing acpi_bus.h
because it's included by acpi.h - but not because it can be built as a
module - right? Just checking, the wording in the commit msg seemed odd
to me.

Quoted 1 line

Correct. I'll rephrase this in place.

Quoted 17 lines

Quoted 9 lines

These removals seem appropriate to me, but so we have it recorded here -
in general, including headers that you explicitly make use of is good
practice, and not depending on others to include them. But in this case,
the implicit includes are reasonable expectations as they are tightly
coupled with the parent include.

There are two classes of headers (at least?):
- let say "user-visible" ones, which drivers usually include like you
pointed above
- low level ones, which in most cases are not supposed to be included directly

Quoted 3 lines

So, for first class I agree with you, and acpi_bus.h in this case can
be considered as an example of second class.

Agreed, acpi_bus.h is tightly coupled with acpi.h. The practice I've seen from others and want to discourage / avoid is including acpi.h and
then deleting ... say... spinlock.h because somewhere somehow acpi.h also pulls it in. They are not tightly coupled conceptually, so spinlock.h should remain in the include list if the file uses spinlocks
directly. I think we're in violent agreement here :-)