aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/platform/x86/fujitsu-laptop.c
AgeCommit message (Collapse)Author
2017-09-27platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not presntVille Syrjälä
My Fujitsu-Siemens Lifebook S6120 doesn't have the FUJ02E3 device, but it does have FUJ02B1. That means we do register the backlight device (and it even seems to work), but the code will oops as soon as we try to set the backlight brightness because it's trying to call call_fext_func() with a NULL device. Let's just skip those function calls when the FUJ02E3 device is not present. Cc: Jonathan Woithe <jwoithe@just42.net> Cc: Andy Shevchenko <andy@infradead.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # 4.13.x Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-07-11platform/x86: fujitsu-laptop: constify attribute_group structures.Arvind Yadav
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>
2017-07-07platform/x86: fujitsu-laptop: add NULL check on devm_kzalloc() return valueGustavo A. R. Silva
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>
2017-06-30platform/x86: fujitsu-laptop: rework debuggingMichał Kępień
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 following mapping was used: - FUJLAPTOP_DBG_ERROR -> acpi_handle_err() - FUJLAPTOP_DBG_WARN -> acpi_handle_info() / dev_info() - FUJLAPTOP_DBG_INFO -> acpi_handle_debug() - FUJLAPTOP_DBG_TRACE -> acpi_handle_debug() / dev_dbg() This means that some events which used to only be logged when the user explicitly requested it will now be logged by default: - ACPI method evaluation errors, - unknown ACPI notification codes, - unknown hotkey scancodes. 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>
2017-06-30platform/x86: fujitsu-laptop: do not evaluate ACPI _INI methodsMichał Kępień
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>
2017-06-30platform/x86: fujitsu-laptop: do not update ACPI device power statusMichał Kępień
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>
2017-06-30platform/x86: fujitsu-laptop: sanitize hotkey input device identificationMichał Kępień
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>
2017-06-30platform/x86: fujitsu-laptop: use strcpy to set ACPI device names and classesMichał Kępień
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>
2017-06-30platform/x86: fujitsu-laptop: remove redundant safety checksMichał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: use device-specific data in remaining module codeMichał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: use device-specific data in LED-related codeMichał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: explicitly pass ACPI device to call_fext_func()Michał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: track the last instantiated FUJ02E3 ACPI deviceMichał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: allocate fujitsu_laptop in ↵Michał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: use device-specific data in backlight codeMichał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: allocate fujitsu_bl in acpi_fujitsu_bl_add()Michał Kępień
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>
2017-06-03platform/x86: fujitsu-laptop: distinguish current uses of device-specific dataMichał Kępień
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>
2017-04-19platform/x86: fujitsu-laptop: simplify error handling in ↵Michał Kępień
acpi_fujitsu_laptop_add() As LED class devices registered by fujitsu-laptop no longer depend on the platform device, two function calls inside acpi_fujitsu_laptop_add() can be rearranged in order to simplify error handling. 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>
2017-04-19platform/x86: fujitsu-laptop: do not log LED registration failuresMichał Kępień
If acpi_fujitsu_laptop_leds_register() returns an error, the latter will become the return value of acpi_fujitsu_laptop_add(), which in turn will be reported by driver core. Simplify code by replacing pr_err() calls with return statements. Return 0 instead of result when no errors occur in order to make the code easier to read. 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>
2017-04-19platform/x86: fujitsu-laptop: switch to managed LED class devicesMichał Kępień
Use devm_led_classdev_register() for registering LED class devices in order to simplify cleanup and remove LED-related fields with the "_registered" suffix from struct fujitsu_laptop. This also fixes a cleanup bug: with non-managed LED class devices, if e.g. two supported LEDs are detected, the first one gets registered successfully but the second one does not, acpi_fujitsu_laptop_add() will return an error, but the successfully registered LED will never get unregistered. Change the parent device for LED class devices to the FUJ02E3 ACPI device due to this being the logically correct relationship as LED class devices do not depend on any facility provided by the platform device registered by fujitsu-laptop, which was their parent until now. Each managed LED class device is automatically unregistered when the last reference to its parent device is dropped. Taking the parent change described above into account, LED class devices registered by fujitsu-laptop will be unregistered after acpi_fujitsu_laptop_remove() is called. During unregistration, LED brightness is reset to LED_OFF by LED core, so do not set the acpi_handle field of struct fujitsu_laptop to NULL inside acpi_fujitsu_laptop_remove() to prevent call_fext_func() from generating errors upon module removal. 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>
2017-04-19platform/x86: fujitsu-laptop: reorganize LED-related codeMichał Kępień
Move around LED definitions and callbacks to eliminate the need for forward declarations and ensure code is organized LED-wise, not action-wise. Reorder assignments inside designated initializers so that they are in the same order as struct led_classdev fields in include/linux/leds.h. 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>
2017-04-19platform/x86: fujitsu-laptop: refactor LED registrationMichał Kępień
Move a long section of code responsible for registering LEDs out of acpi_fujitsu_laptop_add() to improve readability and ensure proper cleanup of platform device and kfifo e.g. when two supported LEDs are detected, the first one gets registered successfully but the second one does not. This makes the result variable in acpi_fujitsu_laptop_add() redundant, so remove it. 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>
2017-04-19platform/x86: fujitsu-laptop: select LEDS_CLASSMichał Kępień
Follow common subsystem practice of selecting LEDS_CLASS instead of riddling module code with #ifdefs. 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>
2017-04-13platform/x86: fujitsu-laptop: remove redundant fields from struct fujitsu_blMichał Kępień
The dev field of struct fujitsu_bl is assigned in acpi_fujitsu_bl_add(), but never used afterwards. brightness_changed is set in get_lcd_level() and then its value is only printed in a debug message, so it does not influence execution flow. Remove both fields as they are redundant. Update the aforementioned debug message. 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>
2017-04-13platform/x86: fujitsu-laptop: account for backlight power when determining ↵Michał Kępień
brightness The comment for the get_brightness backlight device callback in include/linux/backlight.h states that it should "return the current backlight brightness (accounting for power, fb_blank etc.)". fujitsu-laptop violates that premise by simply returning the value to which ACPI function GBLL evaluates to. Make sure 0 is returned when backlight power is turned off. 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>
2017-04-13platform/x86: fujitsu-laptop: do not log set_lcd_level() failures in ↵Michał Kępień
bl_update_status() Any set_lcd_level() call can fail for one of two reasons: either requested brightness is outside the allowed range or the ACPI method used for setting brightness level is not available. For bl_update_status(), the first case is handled by backlight core, which means bl_update_status() will not even be called if requested brightness is outside the allowed range. The second case will be logged anyway by set_lcd_level() itself, so there is no point in generating another message in bl_update_status(). Remove the superfluous debug message along with a local variable that is now 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>
2017-04-13platform/x86: fujitsu-laptop: ignore errors when setting backlight powerMichał Kępień
Not all Fujitsu laptops support controlling backlight power through the FUJ02E3 ACPI device. Remove the debug message informing about a failed attempt to set backlight power as it may be confusing and the return value of call_fext_func() is logged anyway. 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>
2017-04-13platform/x86: fujitsu-laptop: make disable_brightness_adjust a booleanMichał Kępień
Due to the way the disable_brightness_adjust module parameter is currently handled in acpi_fujitsu_bl_add(), it can only be set to either 0 or 1, which effectively makes it a boolean. Emphasize that by changing module parameter type to bool. Do not announce parameter value in a debug message as it can be dynamically changed via sysfs and its current value can also be read from there. Clean up module parameter description. 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>
2017-04-13platform/x86: fujitsu-laptop: clean up use_alt_lcd_levels handlingMichał Kępień
The value of each module parameter can be changed on the fly via sysfs. However, the current way of handling use_alt_lcd_levels prevents the user from dynamically switching from a value of 0 or 1 back to autodetection as the latter is only performed upon ACPI device instantiation. Fix this by moving autodetection (in a simplified form) to set_lcd_level() and changing module parameter type to int. Do not announce autodetection results in a debug message as current value of use_alt_lcd_levels can simply be read from sysfs. Clarify module parameter description. 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>
2017-04-13platform/x86: fujitsu-laptop: sync brightness in set_lcd_level()Michał Kępień
When using brightness keys and backlight device's sysfs interface alternately, an incorrect input event might be generated for a brightness key press. Consider the following sequence of events: 1. Set backlight brightness to 6 using brightness keys. 2. Write 4 to /sys/class/backlight/fujitsu-laptop/brightness. 3. Press the "brightness up" key. The input event generated in this scenario would be KEY_BRIGHTNESSDOWN, because before step 3 brightness_level would still be at 6. As the new brightness level is established using GBLL, it would evaluate to 5 (SBLL/SBL2 sets it to 4 in step 2 and pressing the "brightness up" key increases it by 1). This in turn would cause acpi_fujitsu_bl_notify() to observe a 6 -> 5 change, i.e. a decrease in brightness, while screen brightness would in fact be increased. Fix this by updating brightness_level in set_lcd_level. 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>
2017-04-13platform/x86: fujitsu-laptop: simplify set_lcd_level()Michał Kępień
acpi_execute_simple_method() takes a method parameter which tells it to look for the given method underneath the given handle, so calling acpi_get_handle() beforehand is redundant. Replace the call to acpi_get_handle() with a call to acpi_execute_simple_method(), thus eliminating the need for a local variable storing the handle. Update debug message to reflect this change. Also do not assign a default value to status as it has no influence on execution flow. 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>
2017-04-13platform/x86: fujitsu-laptop: merge set_lcd_level_alt() into set_lcd_level()Michał Kępień
Depending on the value of the use_alt_lcd_levels module parameter, one of two functions is used for setting LCD brightness level. These functions are almost identical and only differ in the name of the ACPI method they call. Instead of checking the value of use_alt_lcd_levels at each call site, move that check to set_lcd_level() and get rid of set_lcd_level_alt(). 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>
2017-04-13platform/x86: fujitsu-laptop: switch to a managed backlight deviceMichał Kępień
Use a managed backlight device to get rid of acpi_fujitsu_bl_remove(). Change the parent of the backlight device from NULL to the FUJ02B1 ACPI device as the latter is required for the backlight device to work. 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>
2017-04-13platform/x86: fujitsu-laptop: only handle backlight when appropriateMichał Kępień
The backlight part of fujitsu-laptop is only used by laptops which are incapable of using the standard ACPI video interface for handling brightness changes. Conversely, on laptops which are capable of using the latter, no vendor-specific ACPI calls should be made unless explicitly requested by the user. Bail out immediately from acpi_fujitsu_bl_add() unless using the vendor-specific interface was either explicitly requested by the user or automatically selected by the kernel. 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>
2017-04-13platform/x86: fujitsu-laptop: update debug message logged by call_fext_func()Michał Kępień
Update debug message logged when the acpi_evaluate_integer() call inside call_fext_func() fails so that it covers a broader set of possible errors. 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>
2017-04-13platform/x86: fujitsu-laptop: rename call_fext_func() argumentsMichał Kępień
Rename call_fext_func() arguments so that each argument's name signifies its role: - cmd -> func: sub-function to call (flags, buttons etc.), - arg0 -> op: operation to perform (get, set, get capabilities etc.), - arg1 -> feature: feature to act on (e.g. which LED), if relevant, - arg2 -> state: state to set (e.g. LED on or off), if relevant. 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>
2017-04-13platform/x86: fujitsu-laptop: simplify call_fext_func()Michał Kępień
acpi_evaluate_integer() takes a pathname parameter which contains the name of the entity to evaluate underneath the given handle, so calling acpi_get_handle() beforehand is redundant. Replace the call to acpi_get_handle() with a call to acpi_evaluate_integer(), thus eliminating the need for a local variable storing the handle. 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>
2017-04-13platform/x86: fujitsu-laptop: clean up local variables in call_fext_func()Michał Kępień
Set values of FUNC call parameters in a designated initializer. Do not initialize status and handle variables as the values these are initialized to have no influence on execution flow. Use an array variable instead of the address of the first element of that array. 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>
2017-04-13platform/x86: fujitsu-laptop: remove keycode fields from struct fujitsu_blMichał Kępień
Remove the keycode[1-5] fields from struct fujitsu_bl as they are not needed any more as a result of the sparse keymap migration. 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>
2017-04-13platform/x86: fujitsu-laptop: model-dependent sparse keymap overridesMichał Kępień
Some laptop models need to have different keycodes assigned to hotkey scancodes. Change the sparse keymap upon a DMI match, before the hotkey input device is setup. Instead of using three different callbacks in the DMI match table, simplify code by using the driver_data field of struct dmi_system_id to supply the requested keymap to a common callback. Also merge keymaps for S6410 and S6420 as they are identical. Rename fujitsu_dmi_table to fujitsu_laptop_dmi_table to emphasize it is no longer used by the backlight part of fujitsu-laptop. 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>
2017-04-13platform/x86: fujitsu-laptop: use a sparse keymap for hotkey event generationMichał Kępień
Simplify hotkey event generation by using a sparse keymap. As sparse keymap operates on scancodes instead of keycodes, adjust variable names and debug messages accordingly. This patch only handles the default keymap for clarity. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> [dvhart: correct flag passed to call_fext_func in acpi_fujitsu_laptop_notify] Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-04-13platform/x86: fujitsu-laptop: switch to a managed hotkey input deviceMichał Kępień
Use a managed input device for hotkey events in order to simplify two error paths and one cleanup function while also reducing the number of local variables required. Remove double assignment 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>
2017-04-13platform/x86: fujitsu-laptop: refactor hotkey input device setupMichał Kępień
Simplify error handling in acpi_fujitsu_laptop_add() by moving code responsible for setting up the input device to a separate function. 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>
2017-04-13platform/x86: fujitsu-laptop: use a sparse keymap for brightness key eventsMichał Kępień
Simplify brightness key event generation by using a sparse keymap. 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>
2017-04-13platform/x86: fujitsu-laptop: switch to a managed backlight input deviceMichał Kępień
Use a managed input device for brightness events in order to simplify two error paths and one cleanup function while also reducing the number of local variables required. Remove double assignment 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>
2017-04-13platform/x86: fujitsu-laptop: refactor backlight input device setupMichał Kępień
Simplify error handling in acpi_fujitsu_bl_add() by moving code responsible for setting up the input device to a separate function. 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>
2017-03-23platform/x86: fujitsu-laptop: remove pf_device field from struct fujitsu_blMichał Kępień
Both struct fujitsu_bl and struct fujitsu_laptop have a pf_device field. Up until now the latter has been redundant, which is logically incorrect because the primary function of the platform device created by fujitsu-laptop is to provide laptop-related (not brightness-related) attributes to userspace. Remove the pf_device field from struct fujitsu_bl and make all module code use the pf_device field of struct fujitsu_laptop instead. Suggested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Jonathan Woithe <jwoithe@just42.net> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-03-23platform/x86: fujitsu-laptop: only register platform device if FUJ02E3 is ↵Michał Kępień
present The platform device registered by fujitsu-laptop is registered unconditionally while sysfs attributes attached to it depend on the FUJ02E3 ACPI device being present. Fix this by moving platform device creation and removal to acpi_fujitsu_laptop_add() and acpi_fujitsu_laptop_remove(), respectively. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Jonathan Woithe <jwoithe@just42.net> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-03-23platform/x86: fujitsu-laptop: add and remove platform device in separate ↵Michał Kępień
functions Platform device handling adds a lot of complexity to fujitsu_init(), which hinders its readability. Extract code responsible for adding and removing the platform device to separate functions. Adjust whitespace to make checkpatch happy. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Jonathan Woithe <jwoithe@just42.net> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2017-03-23platform/x86: fujitsu-laptop: simplify platform device attribute definitionsMichał Kępień
Use the DEVICE_ATTR_RO() macro to get rid of ignore_store() and shorten attribute definitions. Adjust whitespace to make checkpatch happy. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Tested-by: Jonathan Woithe <jwoithe@just42.net> Reviewed-by: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>