attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
2505 600 4 3109 c25 drivers/platform/x86/panasonic-laptop.o
File size After adding 'const':
text data bss dec hex filename
2569 536 4 3109 c25 drivers/platform/x86/panasonic-laptop.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
6932 1016 48 7996 1f3c drivers/platform/x86/alienware-wmi.o
File size After adding 'const':
text data bss dec hex filename
7060 888 48 7996 1f64 drivers/platform/x86/alienware-wmi.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
8710 5452 23 14185 3769 drivers/platform/x86/samsung-laptop.o
File size After adding 'const':
text data bss dec hex filename
8774 5388 23 14185 3769 drivers/platform/x86/samsung-laptop.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
6781 6144 34 12959 329f drivers/platform/x86/compal-laptop.o
File size After adding 'const':
text data bss dec hex filename
6845 6080 34 12959 329f drivers/platform/x86/compal-laptop.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work
with const attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
7474 1205 24 8703 21ff drivers/platform/x86/fujitsu-laptop.o
File size After adding 'const':
text data bss dec hex filename
7538 1141 24 8703 21ff drivers/platform/x86/fujitsu-laptop.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
platform/x86: fujitsu-laptop: add NULL check on devm_kzalloc() return value
Check return value from call to devm_kzalloc()
in order to prevent a NULL pointer dereference.
This issue was detected using Coccinelle and the following semantic patch:
@@
expression x;
identifier fld;
@@
* x = devm_kzalloc(...);
... when != x == NULL
x->fld
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Yang Jiaxun [Tue, 4 Jul 2017 14:39:19 +0000 (14:39 +0000)]
platform/x86: ideapad-laptop: Add several models to no_hw_rfkill
Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.
Fix it by adding those models to no_hw_rfkill_list.
Signed-off-by: Yang Jiaxun <yjx@flygoat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Sven Eckelmann [Sat, 1 Jul 2017 06:20:18 +0000 (08:20 +0200)]
platform/x86: ideapad-laptop: Add IdeaPad V510-15IKB to no_hw_rfkill
Like other Lenovo models the IdeaPad V510-15IKB does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.
Add the IdeaPad V510-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.
Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
platform/x86: intel_telemetry: Add debugfs entry for S0ix residency
This adds a debugfs consumer for the exported kernel API
intel_pmc_read_s0ix_residency. This debugfs entry reads S0ix residency
directly from the PMC hardware counters.
TEST:
- echo freeze > /sys/power/state
- Wake the system, read the S0ix residency i.e.
cat /sys/kernel/debug/telemetry/s0ix_residency_usec
platform/x86: intel_telemetry_debugfs: fix oops when load/unload module
This fixes an oops found while testing load/unload of the
intel_telemetry_debugfs module. module_init uses register_pm_notifier
for PM callbacks, but unregister_pm_notifier was missing from
module_exit.
Arvind Yadav [Fri, 30 Jun 2017 05:09:47 +0000 (10:39 +0530)]
platform/x86: sony-laptop: constify attribute_group and input index array
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group.
The content of sony_laptop_input_index does not change and is declared
as a static global array.
Constify spic_attribute_group and sony_laptop_input_index.
File size before:
text data bss dec hex filename
31273 5176 372 36821 8fd5 drivers/platform/x86/sony-laptop.o
File size After adding 'const':
text data bss dec hex filename
31337 5112 372 36821 8fd5 drivers/platform/x86/sony-laptop.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
[dvhart: updated commit message, includes fix suggested by Arnd Bergmann] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 16 Jun 2017 04:40:58 +0000 (06:40 +0200)]
platform/x86: fujitsu-laptop: rework debugging
Using a dedicated Kconfig option for enabling debugging means the user
may be forced to recompile their kernel in order to gather debugging
information, which is inconvenient. Replace custom debugging
infrastructure with standard logging functions, taking advantage of
dynamic debug. Replace a pr_info() call inside an ACPI callback with an
acpi_handle_info() call.
The first type of events should happen rarely, if ever at all. The rest
is interesting from driver development perspective as their presence in
the logs will mean the driver is unaware of certain events, handling of
which should be implemented.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 16 Jun 2017 04:40:57 +0000 (06:40 +0200)]
platform/x86: fujitsu-laptop: do not evaluate ACPI _INI methods
acpi_ns_initialize_devices(), which is called during system-wide ACPI
initialization, already detects and calls all _INI methods belonging to
objects present in ACPI tables. There is no need to call these methods
again every time the module is loaded because they only initialize
status flags and hotkey-related variables; status flags are effectively
constants, hotkey-related variables may be assigned non-zero values
before acpi_fujitsu_laptop_add() is called, but that does not really
matter as we drain the scancodes queued in the firmware's ring buffer
before doing anything else.
Remove sections of code which invoke and check evaluation status of the
_INI methods belonging to the ACPI devices handled by the driver.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 16 Jun 2017 04:40:56 +0000 (06:40 +0200)]
platform/x86: fujitsu-laptop: do not update ACPI device power status
Calling acpi_bus_update_power() for ACPI devices FUJ02B1 and FUJ02E3 is
pointless as they are not power manageable (neither _PS0 nor _PR0 is
defined for any of them), which causes their power state to be inherited
from their parent devices. Given the ACPI paths of these two devices
(\_SB.PCI0.LPCB.FJEX, \_SB.FEXT), their parent devices are also not
power manageable. These parent devices will thus have their power state
initialized to ACPI_STATE_D0, which in turn causes the power state for
both FUJ02B1 and FUJ02E3 to always be ACPI_STATE_D0 ("on").
Remove relevant acpi_bus_update_power() calls along with parts of debug
messages that they were supposed to have an effect on.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
In the case of brightness-related FUJ02B1 ACPI device, initializing the
input device associated with it identically as acpi-video initializes
its input device makes sense. However, using the same data for the
input device associated with the FUJ02E3 ACPI device makes little sense,
because the latter has nothing to do with video and assigning an
arbitrary product ID to it is redundant.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 16 Jun 2017 04:40:54 +0000 (06:40 +0200)]
platform/x86: fujitsu-laptop: use strcpy to set ACPI device names and classes
No formatting is needed when setting ACPI device name and class, so
switch to using strcpy() for this purpose.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Do not check whether the pointer passed to ACPI add callbacks is NULL as
it is earlier dereferenced anyway in the bus-level probe callback,
acpi_device_probe().
Do not check the value of acpi_disabled in fujitsu_init(), because it is
already done by acpi_bus_register_driver(), which is the first function
called by fujitsu_init().
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
platform/x86: dell-wmi-led: Adjust instance of wmi_evaluate_method calls to 0
Pali recently noticed that WMI instances are zero indexed.
The only reason that these calls all worked properly is because the ASL
didn't verify the instance number.
Signed-off-by: Louis Davis <louis.davis@dell.com> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Bhumika Goyal [Wed, 21 Jun 2017 07:04:17 +0000 (12:34 +0530)]
platform/x86: intel_menlow: Add const to thermal_cooling_device_ops structure
Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Bhumika Goyal [Wed, 21 Jun 2017 07:04:16 +0000 (12:34 +0530)]
platform/x86: acerhdf: Add const to thermal_cooling_device_ops structure
Declare thermal_cooling_device_ops structure as const as it is only passed
as an argument to the function thermal_cooling_device_register and this
argument is of type const. So, declare the structure as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Dell Latitude 3160 does not have keyboard backlight, but there is a
sysfs interface for it, which does nothing at all.
KBD_LED_ON_TOKEN is the only token can be found. Since it doesn't have
KBD_LED_OFF_TOKEN or KBD_LED_AUTO_*_TOKEN, it should be safe to assume
at least two tokens should be present to support keyboard backlight.
Not all models have ON token - they may have multiple AUTO tokens instead.
Models which do not use SMBIOS token to control keyboard backlight, also
have this issue. Brightness level is 0 on these models. Verified on Dell
Inspiron 3565.
Reports keyboard backlight is supported only when at least two modes are
present.
Lee, Chun-Yi [Tue, 20 Jun 2017 09:06:23 +0000 (17:06 +0800)]
platform/x86: acer-wmi: Using zero as first WMI instance number
Pali Rohár found that there have some wmi query/evaluation
code that they used 'one' as the first WMI instance number.
But the number is indexed from zero that it's must less than
the instance_count in _WDG.
This patch changes those instance number from one to zero.
Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andy@infradead.org> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Pali Rohár [Sat, 10 Jun 2017 10:57:11 +0000 (12:57 +0200)]
platform/x86: wmi: Fix printing info about WDG structure
object_id and notify_id are in one union structure and their meaning is
defined by flags. Therefore do not print notify_id for non-event block and
do not print object_id for event block. Remove also reserved member as it
does not have any defined meaning or type yet.
As object_id and notify_id union members overlaps and have different types,
it caused that kernel print to dmesg binary data. This patch eliminates it.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Add const to rfkill_ops structures that are only passed as an argument
to the functions rfkill_alloc or samsung_new_rfkill. These arguments are
of type const, so such structures can be annotated with const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add const to rfkill_ops structure as it is only passed as an argument
to the functions rfkill_alloc. This argument is of type const,
so annotate the structure with const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add const to rfkill_ops structures that are only passed as an argument
to the functions rfkill_alloc or samsung_new_rfkill. These arguments are
of type const, so such structures can be annotated with const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add copyright statements for Andy Lutomirski and Darren Hart (VMware)
for their contributions to the WMI bus infrastructure and the creation
of the wmi-bmof driver.
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org> Cc: Andy Lutomirski <luto@kernel.org>
If a machine reports a RF Button in the communication button device
bitmap, we need to remove it before calling Get Device Status otherwise
it will return the "Undefined device" (0xE2) error code.
Although this may be a BIOS bug, we don't really need to get or set the
RF Button status. The status indicator LED embedded in the button is
controlled by firmware logic, depending on the status of the wireless
radios present on the machine (WiFi || WWAN).
This commit fixes the wireless status indicator LED on the Acer
TravelMate P648-G2-MG, and cleans the following message from the kernel
log: "Get Current Device Status failed: 0xe2 - 0x0".
Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com> Reviewed-by: "Lee, Chun-Yi" <joeyli.kernel@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The struct pcc_keyinput is not used in panasonic-laptop and in
anywhere in kernel, and it can be removed.
Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Harald Welte <laforge@gnumonks.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
platform/x86: wmi-bmof: New driver to expose embedded Binary WMI MOF metadata
Many laptops (and maybe servers?) have embedded WMI Binary MOF metadata.
We do not yet have open-source tools for processing the data, although
one is in the works thanks to Pali:
https://github.com/pali/bmfdec
There is currently no interface to get the data in the first place. By
exposing it, we facilitate the development of new tools.
This is based on the original work of Andy Lutomirski <luto@kernel.org>,
but contains several modifications in response to various reviews.
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
platform/x86: wmi: Require query for data blocks, rename writable to setable
The Microsoft WMI documentation requires all data blocks to implement
the Query Control Method (WQxx). If we encounter a data block not
implementing this control method, issue a warning, and ignore the data
block. Remove the "readable" attribute as all data blocks must be
readable (query-able).
Be consistent with the language in the documentation, replace the
"writable" attribute with "setable".
Simplify (flatten) the control flow of wmi_create_device a bit while
we are updating it for the above changes.
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Andy Lutomirski [Fri, 27 Nov 2015 19:56:02 +0000 (11:56 -0800)]
platform/x86: wmi: Bind the platform device, not the ACPI node
We already have the PNP glue to instantiate platform devices for the
ACPI devices that WMI drives. WMI should therefore attach to the
platform device, not the ACPI node.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
As a platform driver, acpi_driver.notify will not be available,
so use acpi_install_notify_handler as we will be converting to a
platform driver.
This gives event drivers a simple way to handle events. It
also seems closer to what the Windows docs suggest that Windows
does: it sounds like, in Windows, the mapper is responsible for
called _WED before dispatching to the subdriver.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
[dvhart: merge two development commits and update commit message] Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
platform/x86: wmi: Instantiate all devices before adding them
At some point, we will want sub-drivers to get references to other
devices on the same WMI bus. This change is needed to avoid races.
This ends up simplifying the setup code and fixing some leaks, too.
This is based on the original work of Andy Lutomirski <luto@kernel.org>,
but includes several modifications, many in response to review from
Michał Kępień <kernel@kempniu.pl>:
Andy Lutomirski [Wed, 25 Nov 2015 22:03:43 +0000 (14:03 -0800)]
platform/x86: wmi: Probe data objects for read and write capabilities
The Dell XPS 13 9350 has one RW data object, one RO data object, and one
totally inaccessible data object. Check for the existence of the
accessor methods and report in sysfs.
The docs also permit WQxx getters for single-instance objects to
take no parameters. Probe for that as well to avoid ACPICA warnings
about mismatched signatures.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Lutomirski [Wed, 25 Nov 2015 18:01:37 +0000 (10:01 -0800)]
platform/x86: wmi: Split devices into types and add basic sysfs attributes
Divide the "data", "method" and "event" types. All devices get
"instance_count" and "expensive" attributes, data and method devices get
"object_id" attributes, and event devices get "notify_id" attributes.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Lutomirski [Wed, 25 Nov 2015 03:49:23 +0000 (19:49 -0800)]
platform/x86: wmi: Turn WMI into a bus driver
WMI is logically a bus: the WMI driver binds to an ACPI node (or
more than one), and each instance of the WMI driver enumerates its
children and hopes that drivers will attach to the children that are
useful.
This patch gives WMI a driver model bus type and the ability to
match to drivers. The bus itself is a device in the new "wmi_bus"
class, and all of the individual WMI devices are slotted into the
device hierarchy correctly.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Lutomirski [Wed, 25 Nov 2015 03:50:01 +0000 (19:50 -0800)]
platform/x86: wmi: Track wmi devices per ACPI device
Currently we free all devices when we detach from any ACPI node.
Instead, keep track of which node WMI devices are attached to and
free them only as needed. While we are at it, match up notifications
with the device they came from correctly.
This will make our behavior more straightforward on systems with
more than one WMI node in the ACPI tables (e.g. the Dell XPS 13
9350).
This also adds a warning when GUIDs are not unique.
NB: The guid_string parameter in guid_already_parsed was a
little-endian binary GUID, not a string.
Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Cc: linux-acpi@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Lutomirski [Wed, 17 Feb 2016 20:43:06 +0000 (12:43 -0800)]
platform/x86: dell-rbtn: Improve explanation about DELLABC6
According to Mario at Dell, the DELLABC6 device should not be used on a
Linux system. It also conflicts with Intel-HID and its interactions with
Network Manager. Document that we are aware of the device, but that we
are intentionally ignoring it.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
[dvhart: New commit message and minor comment wording fixes] Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: "Pali Rohár" <pali.rohar@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Lutomirski [Wed, 17 Feb 2016 20:38:07 +0000 (12:38 -0800)]
platform/x86: dell-wmi: Add a better description for "stealth mode"
This is based on Mario's explanation and observation of my laptop.
Suggested-by: "Pali Rohár" <pali.rohar@gmail.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Mario Limonciello <mario_limonciello@dell.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Lutomirski [Wed, 17 Feb 2016 20:34:34 +0000 (12:34 -0800)]
platform/x86: dell-wmi: Add a comment explaining the 0xb2 magic number
The hotkey table is 0xb2, add a comment for clarity.
Suggested-by: Darren Hart <dvhart@infradead.org> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:48 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: use device-specific data in remaining module code
To avoid using module-wide data in remaining module code, employ
acpi_driver_data() and dev_get_drvdata() to fetch device-specific data
to work on in each function. This makes the input local variables in
hotkey-related callbacks and the module-wide struct fujitsu_laptop
redundant, so remove them. Adjust whitespace to make checkpatch happy.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:47 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: use device-specific data in LED-related code
In order to perform their duties, all LED callbacks need a pointer to
the struct acpi_device representing the FUJ02E3 ACPI device. To limit
the use of the module-wide pointer, the same pointer should be extracted
from data that gets passed to LED callbacks as arguments. However, LED
core does not currently support supplying driver-specific pointers to
struct led_classdev callbacks, so the latter have to be implemented a
bit differently than backlight device callbacks and platform device
attribute callbacks. As the FUJ02E3 ACPI device is the parent device of
all LED class devices registered by fujitsu-laptop, struct acpi_device
representing the former can be extracted by following the parent link
present inside the struct device belonging to the struct led_classdev
passed as an argument to each LED callback.
To get rid of module-wide structures defining LED class devices,
allocate them dynamically using devm_kzalloc() and initialize them in
acpi_fujitsu_laptop_leds_register().
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:46 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: explicitly pass ACPI device to call_fext_func()
Prepare for not using module-wide data in call_fext_func() by explicitly
passing it a pointer to struct acpi_device while still using a
module-wide pointer in each call.
Doing this enables call_fext_func() to fetch the ACPI handle from its
argument, making the acpi_handle field of struct fujitsu_laptop useless,
so remove that field. While we are at it, the dev field of the same
structure is assigned in acpi_fujitsu_laptop_add() but not used for
anything, so remove it as well.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:45 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI device
fujitsu-laptop registers two ACPI drivers: one for ACPI device FUJ02B1
enabling backlight control and another for ACPI device FUJ02E3 which
handles various other stuff (hotkeys, LEDs, etc.) In a perfect world,
private data used by each of these drivers would be neatly encapsulated
in a structure specific to a given driver instance. Sadly, firmware
present on some Fujitsu laptops makes that impossible by exposing
backlight power control (which is what the FUJ02B1 ACPI device should
take care of) through the FUJ02E3 ACPI device. This means the backlight
driver needs a way to access an ACPI device it is not bound to. When
the backlight driver is extracted into a separate module, it will not be
able to rely on a module-wide variable any more and such access will
happen through an API exposed by fujitsu-laptop.
For all known firmwares out in the wild, it seems that whenever the
FUJ02B1 ACPI device is present, it is always accompanied by a single
instance of the FUJ02E3 ACPI device. We could independently grab an
ACPI handle to the FUJ02E3 ACPI device from the backlight driver, but
that would require using a hardcoded absolute path to that ACPI device,
which is subject to change. It is easier to simply store a module-wide
pointer to the last (most likely only) FUJ02E3 ACPI device found, make
the aforementioned API use it and cover our bases by warning the user if
firmware exposes multiple FUJ02E3 ACPI devices.
Introducing this pointer in advance allows us to get rid of the
acpi_handle field of struct fujitsu_bl and also enables a bit more
step-by-step migration to a device-specific implementation of
call_fext_func().
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:44 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: allocate fujitsu_laptop in acpi_fujitsu_laptop_add()
Only allocate memory for struct fujitsu_laptop when the FUJ02E3 ACPI
device is present. Use devm_kzalloc() for allocating memory to simplify
cleanup.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:43 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: use device-specific data in backlight code
To prevent using module-wide data in backlight-related code, employ
acpi_driver_data() and bl_get_data() where possible to fetch
device-specific data to work on in each function. This makes the input
local variable in acpi_fujitsu_bl_notify() and the acpi_handle field of
struct fujitsu_bl redundant, so remove them.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:42 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: allocate fujitsu_bl in acpi_fujitsu_bl_add()
Only allocate memory for struct fujitsu_bl when the FUJ02B1 ACPI device
is present. Use devm_kzalloc() for allocating memory to simplify
cleanup.
Due to the fact that the power property of the backlight device created
by the backlight driver is accessed from acpi_fujitsu_laptop_add(),
pointer to the allocated memory will remain stored in a module-wide
variable until the backlight driver is extracted into a separate module.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Michał Kępień [Fri, 19 May 2017 07:44:41 +0000 (09:44 +0200)]
platform/x86: fujitsu-laptop: distinguish current uses of device-specific data
In portions of the driver which use device-specific data, rename local
variables from fujitsu_bl and fujitsu_laptop to priv in order to clearly
distinguish these parts from code that uses module-wide data.
Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Hans de Goede [Fri, 26 May 2017 10:53:48 +0000 (12:53 +0200)]
platform/x86: intel_cht_int33fe: Set supplied-from property on max17047 dev
Devices with the intel_cht_int33fe ACPI device use a max17047 fuel-gauge
combined with a bq24272i charger, in order for the fuel-gauge driver to
correctly display charging / discharging status it needs to know which
charger is supplying the battery.
This commit sets the supplied-from device property to the name of the
bq24272i charger for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
platform/x86: intel_pmc_ipc: Mark ipc_data_readb() as __maybe_unused
The function is currently not used, however it is part of the API and
might be used in the future. Adding the attribute fixes the following
warning when building with clang:
drivers/platform/x86/intel_pmc_ipc.c:189:18: error: unused function
'ipc_data_readb' [-Werror,-Wunused-function]
Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Don't simply throw this to userspace via the sparse_keymap (which does not
have a mapping for scancode 1), as this causes KEY_UNKNOWN to be emitted,
which is a nuisance and of no use at all (it is not the right way to expose
this ACPI event to userspace, anyway, and the original intention of the commit
which added this (cfee5d63767b2e7997c1f36420d008abbe61565c) was only to suppress
an unhandled event log message).
Signed-off-by: Hao Wei Tee <angelsl@angelsl.xyz> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The latest Topstar BIOS updates (109_931P) advertise the "TPS0001"
device id by default, preventing the topstar-laptop module from being
loaded automatically.
Signed-off-by: Guillaume Douézan-Grard <gdouezangrard@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Hans de Goede [Fri, 12 May 2017 15:11:54 +0000 (17:11 +0200)]
platform/x86: peaq-wmi: Add new peaq-wmi driver
PEAQ is a new European OEM, I've bought one of their 2-in-1 x86 devices,
which is actually quite a nice device. Under Windows it has Dolby
software for "better" sound and you can select different equalizer
presets using a special button.
This WMI interface for this button is not really nice, as it does not do
notifies (it really does not I triple checked), but since I had already
figured out the entire WMI interface for this I decided to go the full
mile anyway and implement a WMI based input driver for this using
input_polldev since, well, we need to poll.
This commit adds support for this button making it report KEY_SOUND
input events. KEY_SOUND is already used in various places to switch
sound into theatre mode and things like that so it seems appropriate
here.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[dvhart: minor declaration ordering and commit log typo fixes] Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Andy Shevchenko [Tue, 9 May 2017 14:17:21 +0000 (17:17 +0300)]
platform/x86: thinkpad_acpi: Add a comment about 0 in module_param_call()
As per discussion [1] there are only few users of module_param_call() in
kernel which prevent to read module parameters back.
It thinkpad_acpi driver there is even no method do so. Thus, for now,
add just a comment to explain why 0 is used as permissions in
module_param_call().
[1]: https://patchwork.ozlabs.org/patch/713245/
Cc: Richard Weinberger <richard.weinberger@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
platform/x86: ideapad-laptop: Add sysfs interface for touchpad state
Lenovo Yoga (many variants: Yoga, Yoga2 Pro, Yoga2 13, Yoga3 Pro, Yoga 3
14, etc) has multiple modles that are a hybrid laptop, working in laptop
mode as well as tablet mode.
Currently, there is no easy interface to determine the touchpad status,
which in case of the Yoga family of machines, can also be useful to
assume tablet mode status.
Note: The ideapad-laptop driver does not provide a SW_TABLET_MODE either.
For a detailed discussion on why we want either of the interfaces,
please see:
https://bugs.launchpad.net/onboard/+bug/1366421/comments/43
This patch adds a sysfs interface for read/write access under:
/sys/bus/platform/devices/VPC2004\:00/touchpad_mode
Signed-off-by: Ritesh Raj Sarraf <rrs@debian.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Linus Torvalds [Sat, 13 May 2017 17:25:05 +0000 (10:25 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull some more input subsystem updates from Dmitry Torokhov:
"An updated xpad driver with a few more recognized device IDs, and a
new psxpad-spi driver, allowing connecting Playstation 1 and 2 joypads
via SPI bus"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: cros_ec_keyb - remove extraneous 'const'
Input: add support for PlayStation 1/2 joypads connected via SPI
Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth
Input: xpad - sync supported devices with xboxdrv
Input: xpad - sort supported devices by USB ID
Linus Torvalds [Sat, 13 May 2017 17:23:12 +0000 (10:23 -0700)]
Merge tag 'upstream-4.12-rc1' of git://git.infradead.org/linux-ubifs
Pull UBI/UBIFS updates from Richard Weinberger:
- new config option CONFIG_UBIFS_FS_SECURITY
- minor improvements
- random fixes
* tag 'upstream-4.12-rc1' of git://git.infradead.org/linux-ubifs:
ubi: Add debugfs file for tracking PEB state
ubifs: Fix a typo in comment of ioctl2ubifs & ubifs2ioctl
ubifs: Remove unnecessary assignment
ubifs: Fix cut and paste error on sb type comparisons
ubi: fastmap: Fix slab corruption
ubifs: Add CONFIG_UBIFS_FS_SECURITY to disable/enable security labels
ubi: Make mtd parameter readable
ubi: Fix section mismatch
Linus Torvalds [Sat, 13 May 2017 17:20:02 +0000 (10:20 -0700)]
Merge branch 'for-linus-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
Pull UML fixes from Richard Weinberger:
"No new stuff, just fixes"
* 'for-linus-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml:
um: Add missing NR_CPUS include
um: Fix to call read_initrd after init_bootmem
um: Include kbuild.h instead of duplicating its macros
um: Fix PTRACE_POKEUSER on x86_64
um: Set number of CPUs
um: Fix _print_addr()
Linus Torvalds [Sat, 13 May 2017 16:49:35 +0000 (09:49 -0700)]
Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
"15 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm, docs: update memory.stat description with workingset* entries
mm: vmscan: scan until it finds eligible pages
mm, thp: copying user pages must schedule on collapse
dax: fix PMD data corruption when fault races with write
dax: fix data corruption when fault races with write
ext4: return to starting transaction in ext4_dax_huge_fault()
mm: fix data corruption due to stale mmap reads
dax: prevent invalidation of mapped DAX entries
Tigran has moved
mm, vmalloc: fix vmalloc users tracking properly
mm/khugepaged: add missed tracepoint for collapse_huge_page_swapin
gcov: support GCC 7.1
mm, vmstat: Remove spurious WARN() during zoneinfo print
time: delete current_fs_time()
hwpoison, memcg: forcibly uncharge LRU pages
With investigation, skipping page of isolate_lru_pages makes reclaim
void because it returns zero nr_taken easily so LRU shrinking is
effectively nothing and just increases priority aggressively. Finally,
OOM happens.
The problem is that get_scan_count determines nr_to_scan with eligible
zones so although priority drops to zero, it couldn't reclaim any pages
if the LRU contains mostly ineligible pages.
Assumes sc->priority is 0 and LRU list is as follows.
N-N-N-N-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
(Ie, small eligible pages are in the head of LRU but others are
almost ineligible pages)
In that case, size becomes 4 so VM want to scan 4 pages but 4 pages from
tail of the LRU are not eligible pages. If get_scan_count counts
skipped pages, it doesn't reclaim any pages remained after scanning 4
pages so it ends up OOM happening.
This patch makes isolate_lru_pages try to scan pages until it encounters
eligible zones's pages.
[akpm@linux-foundation.org: clean up mind-bending `for' statement. Tweak comment text] Fixes: 3db65812d688 ("Revert "mm, vmscan: account for skipped pages as a partial scan"") Link: http://lkml.kernel.org/r/1494457232-27401-1-git-send-email-minchan@kernel.org Signed-off-by: Minchan Kim <minchan@kernel.org> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
grab_mapping_entry()
- we add huge zero page to the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6258 ("dax: Call ->iomap_begin without entry lock during dax fault") Link: http://lkml.kernel.org/r/20170510172700.18991-1-ross.zwisler@linux.intel.com Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jan Kara [Fri, 12 May 2017 22:46:57 +0000 (15:46 -0700)]
dax: fix data corruption when fault races with write
Currently DAX read fault can race with write(2) in the following way:
CPU1 - write(2) CPU2 - read fault
dax_iomap_pte_fault()
->iomap_begin() - sees hole
dax_iomap_rw()
iomap_apply()
->iomap_begin - allocates blocks
dax_iomap_actor()
invalidate_inode_pages2_range()
- there's nothing to invalidate
grab_mapping_entry()
- we add zero page in the radix tree
and map it to page tables
The result is that hole page is mapped into page tables (and thus zeros
are seen in mmap) while file has data written in that place.
Fix the problem by locking exception entry before mapping blocks for the
fault. That way we are sure invalidate_inode_pages2_range() call for
racing write will either block on entry lock waiting for the fault to
finish (and unmap stale page tables after that) or read fault will see
already allocated blocks by write(2).
Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956 Link: http://lkml.kernel.org/r/20170510085419.27601-5-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jan Kara [Fri, 12 May 2017 22:46:54 +0000 (15:46 -0700)]
ext4: return to starting transaction in ext4_dax_huge_fault()
DAX will return to locking exceptional entry before mapping blocks for a
page fault to fix possible races with concurrent writes. To avoid lock
inversion between exceptional entry lock and transaction start, start
the transaction already in ext4_dax_huge_fault().
Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956 Link: http://lkml.kernel.org/r/20170510085419.27601-4-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jan Kara [Fri, 12 May 2017 22:46:50 +0000 (15:46 -0700)]
mm: fix data corruption due to stale mmap reads
Currently, we didn't invalidate page tables during invalidate_inode_pages2()
for DAX. That could result in e.g. 2MiB zero page being mapped into
page tables while there were already underlying blocks allocated and
thus data seen through mmap were different from data seen by read(2).
The following sequence reproduces the problem:
- open an mmap over a 2MiB hole
- read from a 2MiB hole, faulting in a 2MiB zero page
- write to the hole with write(3p). The write succeeds but we
incorrectly leave the 2MiB zero page mapping intact.
- via the mmap, read the data that was just written. Since the zero
page mapping is still intact we read back zeroes instead of the new
data.
Fix the problem by unconditionally calling invalidate_inode_pages2_range()
in dax_iomap_actor() for new block allocations and by properly
invalidating page tables in invalidate_inode_pages2_range() for DAX
mappings.
Fixes: c6dcf52c23d2d3fb5235cec42d7dd3f786b87d55 Link: http://lkml.kernel.org/r/20170510085419.27601-3-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ross Zwisler [Fri, 12 May 2017 22:46:47 +0000 (15:46 -0700)]
dax: prevent invalidation of mapped DAX entries
Patch series "mm,dax: Fix data corruption due to mmap inconsistency",
v4.
This series fixes data corruption that can happen for DAX mounts when
page faults race with write(2) and as a result page tables get out of
sync with block mappings in the filesystem and thus data seen through
mmap is different from data seen through read(2).
The series passes testing with t_mmap_stale test program from Ross and
also other mmap related tests on DAX filesystem.
This patch (of 4):
dax_invalidate_mapping_entry() currently removes DAX exceptional entries
only if they are clean and unlocked. This is done via:
However, for page cache pages removed in invalidate_mapping_pages()
there is an additional criteria which is that the page must not be
mapped. This is noted in the comments above invalidate_mapping_pages()
and is checked in invalidate_inode_page().
For DAX entries this means that we can can end up in a situation where a
DAX exceptional entry, either a huge zero page or a regular DAX entry,
could end up mapped but without an associated radix tree entry. This is
inconsistent with the rest of the DAX code and with what happens in the
page cache case.
We aren't able to unmap the DAX exceptional entry because according to
its comments invalidate_mapping_pages() isn't allowed to block, and
unmap_mapping_range() takes a write lock on the mapping->i_mmap_rwsem.
Since we essentially never have unmapped DAX entries to evict from the
radix tree, just remove dax_invalidate_mapping_entry().
Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if appropriate") Link: http://lkml.kernel.org/r/20170510085419.27601-2-jack@suse.cz Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Jan Kara <jack@suse.cz> Reported-by: Jan Kara <jack@suse.cz> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> [4.10+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Michal Hocko [Fri, 12 May 2017 22:46:41 +0000 (15:46 -0700)]
mm, vmalloc: fix vmalloc users tracking properly
Commit 1f5307b1e094 ("mm, vmalloc: properly track vmalloc users") has
pulled asm/pgtable.h include dependency to linux/vmalloc.h and that
turned out to be a bad idea for some architectures. E.g. m68k fails
with
In file included from arch/m68k/include/asm/pgtable_mm.h:145:0,
from arch/m68k/include/asm/pgtable.h:4,
from include/linux/vmalloc.h:9,
from arch/m68k/kernel/module.c:9:
arch/m68k/include/asm/mcf_pgtable.h: In function 'nocache_page':
>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared (first use in this function)
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
as spotted by kernel build bot. nios2 fails for other reason
In file included from include/asm-generic/io.h:767:0,
from arch/nios2/include/asm/io.h:61,
from include/linux/io.h:25,
from arch/nios2/include/asm/pgtable.h:18,
from include/linux/mm.h:70,
from include/linux/pid_namespace.h:6,
from include/linux/ptrace.h:9,
from arch/nios2/include/uapi/asm/elf.h:23,
from arch/nios2/include/asm/elf.h:22,
from include/linux/elf.h:4,
from include/linux/module.h:15,
from init/main.c:16:
include/linux/vmalloc.h: In function '__vmalloc_node_flags':
include/linux/vmalloc.h:99:40: error: 'PAGE_KERNEL' undeclared (first use in this function); did you mean 'GFP_KERNEL'?
which is due to the newly added #include <asm/pgtable.h>, which on nios2
includes <linux/io.h> and thus <asm/io.h> and <asm-generic/io.h> which
again includes <linux/vmalloc.h>.
Tweaking that around just turns out a bigger headache than necessary.
This patch reverts 1f5307b1e094 and reimplements the original fix in a
different way. __vmalloc_node_flags can stay static inline which will
cover vmalloc* functions. We only have one external user
(kvmalloc_node) and we can export __vmalloc_node_flags_caller and
provide the caller directly. This is much simpler and it doesn't really
need any games with header files.
SeongJae Park [Fri, 12 May 2017 22:46:38 +0000 (15:46 -0700)]
mm/khugepaged: add missed tracepoint for collapse_huge_page_swapin
One return case of `__collapse_huge_page_swapin()` does not invoke
tracepoint while every other return case does. This commit adds a
tracepoint invocation for the case.
Link: http://lkml.kernel.org/r/20170507101813.30187-1-sj38.park@gmail.com Signed-off-by: SeongJae Park <sj38.park@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reza Arbab [Fri, 12 May 2017 22:46:32 +0000 (15:46 -0700)]
mm, vmstat: Remove spurious WARN() during zoneinfo print
After commit e2ecc8a79ed4 ("mm, vmstat: print non-populated zones in
zoneinfo"), /proc/zoneinfo will show unpopulated zones.
A memoryless node, having no populated zones at all, was previously
ignored, but will now trigger the WARN() in is_zone_first_populated().
Remove this warning, as its only purpose was to warn of a situation that
has since been enabled.
Aside: The "per-node stats" are still printed under the first populated
zone, but that's not necessarily the first stanza any more. I'm not
sure which criteria is more important with regard to not breaking
parsers, but it looks a little weird to the eye.
projects / karo-tx-linux.git / log