#
5d7cf67f |
|
08-Aug-2023 |
Alan Stern <stern@rowland.harvard.edu> |
Fix nomenclature for USB and PCI wireless devices A mouse that uses a USB connection is called a "USB mouse" device (or "USB mouse" for short), not a "mouse USB" device. By analogy, a WiFi adapter that connects to the host computer via USB is a "USB wireless" device, not a "wireless USB" device. (The latter term more properly refers to a defunct Wireless USB specification, which described a technology for sending USB protocol messages over an ultra wideband radio link.) Similarly for a WiFi adapter card that plugs into a PCIe slot: It is a "PCIe wireless" device, not a "wireless PCIe" device. Rephrase the text in the kernel source where the word ordering is wrong. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/57da7c80-0e48-41b5-8427-884a02648f55@rowland.harvard.edu
|
#
6c0eb5ba |
|
13-Nov-2022 |
Dawei Li <set_pte_at@outlook.com> |
ACPI: make remove callback of ACPI driver void For bus-based driver, device removal is implemented as: 1 device_remove()-> 2 bus->remove()-> 3 driver->remove() Driver core needs no inform from callee(bus driver) about the result of remove callback. In that case, commit fc7a6209d571 ("bus: Make remove callback return void") forces bus_type::remove be void-returned. Now we have the situation that both 1 & 2 of calling chain are void-returned, so it does not make much sense for 3(driver->remove) to return non-void to its caller. So the basic idea behind this change is making remove() callback of any bus-based driver to be void-returned. This change, for itself, is for device drivers based on acpi-bus. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dawei Li <set_pte_at@outlook.com> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for drivers/platform/surface/* Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8d05fc03 |
|
30-Sep-2022 |
Barnabás Pőcze <pobrn@protonmail.com> |
platform/x86: use PLATFORM_DEVID_NONE instead of -1 Use the `PLATFORM_DEVID_NONE` constant instead of hard-coding -1 when creating a platform device. No functional changes are intended. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Link: https://lore.kernel.org/r/20220930104857.2796923-1-pobrn@protonmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
#
e257dd34 |
|
07-May-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
platform/x86: eeepc-laptop: Drop duplicate check for led_classdev_unregister() led_classdev_unregister() already has the very same check, so, drop a duplicate in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
86295c70 |
|
17-Oct-2019 |
Kefeng Wang <wangkefeng.wang@huawei.com> |
platform/x86: eeepc-laptop: Use pr_warn instead of pr_warning As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of pr_warning"), removing pr_warning so all logging messages use a consistent <prefix>_warn style. Let's do it. Link: http://lkml.kernel.org/r/20191018031850.48498-18-wangkefeng.wang@huawei.com To: linux-kernel@vger.kernel.org Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andy@infradead.org> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
|
#
c942fddf |
|
27-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 Based on 3 normalized pattern(s): 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 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 [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] 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 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 [author] [graeme] [gregory] [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i] [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema] [hk] [hemahk]@[ti] [com] 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 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 1105 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
125450f8 |
|
08-Sep-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: hotplug: Embed hotplug_slot When the PCI hotplug core and its first user, cpqphp, were introduced in February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot struct for its internal use plus a hotplug_slot struct to be registered with the hotplug core and linked the two with pointers: https://git.kernel.org/tglx/history/c/a8a2069f432c Nowadays, the predominant pattern in the tree is to embed ("subclass") such structures in one another and cast to the containing struct with container_of(). But it wasn't until July 2002 that container_of() was introduced with historic commit ec4f214232cf: https://git.kernel.org/tglx/history/c/ec4f214232cf pnv_php, introduced in 2016, did the right thing and embedded struct hotplug_slot in its internal struct pnv_php_slot, but all other drivers cargo-culted cpqphp's design and linked separate structs with pointers. Embedding structs is preferrable to linking them with pointers because it requires fewer allocations, thereby reducing overhead and simplifying error paths. Casting an embedded struct to the containing struct becomes a cheap subtraction rather than a dereference. And having fewer pointers reduces the risk of them pointing nowhere either accidentally or due to an attack. Convert all drivers to embed struct hotplug_slot in their internal slot struct. The "private" pointer in struct hotplug_slot thereby becomes unused, so drop it. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
|
#
a7da2161 |
|
08-Sep-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: hotplug: Drop hotplug_slot_info Ever since the PCI hotplug core was introduced in 2002, drivers had to allocate and register a struct hotplug_slot_info for every slot: https://git.kernel.org/tglx/history/c/a8a2069f432c Apparently the idea was that drivers furnish the hotplug core with an up-to-date card presence status, power status, latch status and attention indicator status as well as notify the hotplug core of changes thereof. However only 4 out of 12 hotplug drivers bother to notify the hotplug core with pci_hp_change_slot_info() and the hotplug core never made any use of the information: There is just a single macro in pci_hotplug_core.c, GET_STATUS(), which uses the hotplug_slot_info if the driver lacks the corresponding callback in hotplug_slot_ops. The macro is called when the user reads the attribute via sysfs. Now, if the callback isn't defined, the attribute isn't exposed in sysfs in the first place (see e.g. has_power_file()). There are only two situations when the hotplug_slot_info would actually be accessed: * If the driver defines ->enable_slot or ->disable_slot but not ->get_power_status. * If the driver defines ->set_attention_status but not ->get_attention_status. There is no driver doing the former and just a single driver doing the latter, namely pnv_php.c. Amend it with a ->get_attention_status callback. With that, the hotplug_slot_info becomes completely unused by the PCI hotplug core. But a few drivers use it internally as a cache: cpcihp uses it to cache the latch_status and adapter_status. cpqhp uses it to cache the adapter_status. pnv_php and rpaphp use it to cache the attention_status. shpchp uses it to cache all four values. Amend these drivers to cache the information in their private slot struct. shpchp's slot struct already contains members to cache the power_status and adapter_status, so additional members are only needed for the other two values. In the case of cpqphp, the cached value is only accessed in a single place, so instead of caching it, read the current value from the hardware. Caution: acpiphp, cpci, cpqhp, shpchp, asus-wmi and eeepc-laptop populate the hotplug_slot_info with initial values on probe. That code is herewith removed. There is a theoretical chance that the code has side effects without which the driver fails to function, e.g. if the ACPI method to read the adapter status needs to be executed at least once on probe. That seems unlikely to me, still maintainers should review the changes carefully for this possibility. Rafael adds: "I'm not aware of any case in which it will break anything, [...] but if that happens, it may be necessary to add the execution of the control methods in question directly to the initialization part." Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Sebastian Ott <sebott@linux.ibm.com> # drivers/pci/hotplug/s390* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
|
#
81c4b5bf |
|
08-Sep-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: hotplug: Constify hotplug_slot_ops Hotplug drivers cannot declare their hotplug_slot_ops const, making them attractive targets for attackers, because upon registration of a hotplug slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members in that struct. Fix by moving these members to struct hotplug_slot and constify every driver's hotplug_slot_ops except for pciehp. pciehp constructs its hotplug_slot_ops at runtime based on the PCIe port's capabilities, hence cannot declare them const. It can be converted to __write_rarely once that's mainlined: http://www.openwall.com/lists/kernel-hardening/2016/11/16/3 Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> # drivers/pci/hotplug/rpa* Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Oliver OHalloran <oliveroh@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org>
|
#
51bbf9be |
|
19-Jul-2018 |
Lukas Wunner <lukas@wunner.de> |
PCI: hotplug: Demidlayer registration with the core When a hotplug driver calls pci_hp_register(), all steps necessary for registration are carried out in one go, including creation of a kobject and addition to sysfs. That's a problem for pciehp once it's converted to enable/disable the slot exclusively from the IRQ thread: The thread needs to be spawned after creation of the kobject (because it uses the kobject's name), but before addition to sysfs (because it will handle enable/disable requests submitted via sysfs). pci_hp_deregister() does offer a ->release callback that's invoked after deletion from sysfs and before destruction of the kobject. But because pci_hp_register() doesn't offer a counterpart, hotplug drivers' ->probe and ->remove code becomes asymmetric, which is error prone as recently discovered use-after-free bugs in pciehp's ->remove hook have shown. In a sense, this appears to be a case of the midlayer antipattern: "The core thesis of the "midlayer mistake" is that midlayers are bad and should not exist. That common functionality which it is so tempting to put in a midlayer should instead be provided as library routines which can [be] used, augmented, or ignored by each bottom level driver independently. Thus every subsystem that supports multiple implementations (or drivers) should provide a very thin top layer which calls directly into the bottom layer drivers, and a rich library of support code that eases the implementation of those drivers. This library is available to, but not forced upon, those drivers." -- Neil Brown (2009), https://lwn.net/Articles/336262/ The presence of midlayer traits in the PCI hotplug core might be ascribed to its age: When it was introduced in February 2002, the blessings of a library approach might not have been well known: https://git.kernel.org/tglx/history/c/a8a2069f432c For comparison, the driver core does offer split functions for creating a kobject (device_initialize()) and addition to sysfs (device_add()) as an alternative to carrying out everything at once (device_register()). This was introduced in October 2002: https://git.kernel.org/tglx/history/c/8b290eb19962 The odd ->release callback in the PCI hotplug core was added in 2003: https://git.kernel.org/tglx/history/c/69f8d663b595 Clearly, a library approach would not force every hotplug driver to implement a ->release callback, but rather allow the driver to remove the sysfs files, release its data structures and finally destroy the kobject. Alternatively, a driver may choose to remove everything with pci_hp_deregister(), then release its data structures. To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a split-up version of pci_hp_register(). Likewise, offer pci_hp_del() and pci_hp_destroy() as a split-up version of pci_hp_deregister(). Eliminate the ->release callback and move its code into each driver's teardown routine. Declare pci_hp_deregister() void, in keeping with the usual kernel pattern that enablement can fail, but disablement cannot. It only returned an error if the caller passed in a NULL pointer or a slot which has never or is no longer registered or is sharing its name with another slot. Those would be bugs, so WARN about them. Few hotplug drivers actually checked the return value and those that did only printed a useless error message to dmesg. Remove that. For most drivers the conversion was straightforward since it doesn't matter whether the code in the ->release callback is executed before or after destruction of the kobject. But in the case of ibmphp, it was unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to NULL needs to happen before the kobject is destroyed, so I erred on the side of caution and ensured that the order stays the same. Another nontrivial case is pnv_php, I've found the list and kref logic difficult to understand, however my impression was that it is safe to delete the list element and drop the references until after the kobject is destroyed. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86 Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Len Brown <lenb@kernel.org> Cc: Scott Murray <scott@spiteful.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andy@infradead.org>
|
#
447a5647 |
|
21-Mar-2018 |
Joe Perches <joe@perches.com> |
treewide: Align function definition open/close braces Some functions definitions have either the initial open brace and/or the closing brace outside of column 1. Move those braces to column 1. This allows various function analyzers like gnu complexity to work properly for these modified functions. Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Takashi Iwai <tiwai@suse.de> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
130bbe63 |
|
23-Jun-2017 |
Arvind Yadav <arvind.yadav.cs@gmail.com> |
platform/x86: eeepc-laptop: constify platform_attribute_group File size before: text data bss dec hex filename 9934 1136 2 11072 2b40 drivers/platform/x86/eeepc-laptop.o File size After adding 'const': text data bss dec hex filename 9998 1072 2 11072 2b40 drivers/platform/x86/eeepc-laptop.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
999ddbdf |
|
10-Feb-2017 |
Pau Espin Pedrol <pespin.shar@gmail.com> |
platform/x86: eeepc-laptop: Skip unknown key messages 0x50 0x51 Otherwise those are printed several times when (un)plugging the AC connector. Signed-off-by: Pau Espin Pedrol <pespin.shar@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
#
de3c91c1 |
|
09-Mar-2017 |
Michał Kępień <kernel@kempniu.pl> |
platform/x86: eeepc-laptop: remove sparse_keymap_free() calls As sparse_keymap_setup() now uses a managed memory allocation for the keymap copy it creates, the latter is freed automatically. Remove all calls to sparse_keymap_free(). Signed-off-by: Michał Kępień <kernel@kempniu.pl> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
21db4b1d |
|
16-Jun-2015 |
Hans de Goede <hdegoede@redhat.com> |
eeepc-laptop: Port to new backlight interface selection API Port the backlight selection logic to the new backlight interface selection API. This commit also removes various obsolete pr_xxx messages related to backlight interface selection. These are obsolete because they assume there is only a vendor or acpi backlight driver and no other choice. Also they are not necessary, if the user wants to know which backlight interfaces are registered a simple "ls /sys/class/backlight" suffices. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
00981810 |
|
24-Nov-2014 |
Markus Elfring <elfring@users.sourceforge.net> |
platform: x86: Deletion of checks before backlight_device_unregister() The backlight_device_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> For msi-wmi.c: Acked-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
fb1d97a2 |
|
02-Nov-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: clean up control flow in eeepc_acpi_notify eeepc_acpi_notify increases the indentation level to a whopping four. If we revise the conditions a bit, we can reduce that to a more soothing two and satisfy the indentation guidelines in Documentation/CodingStyle. Remove an unwanted space while we're in the neighbourhood. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
efef8729 |
|
22-Oct-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: don't assume get_acpi succeeds In eeepc_hotk_thaw, we assume that get_acpi() will effectively return a bool. However, it is possible that get_acpi() returns an error instead. We should not be writing error values to the ACPI device, even though it's quite possible that we couldn't contact the ACPI device in the first place. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
148a5dd5 |
|
22-Oct-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: document fan_pwm conversions eeepc_get_fan_pwm and eeepc_set_fan_pwm convert the PWM value read from the fan to a range lmsensors understands. Unfortunately this is only clear if you are familiar with how lmsensors handles duty cycles. Introduce two conversion functions that document the goal of these conversions. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
a5de681c |
|
22-Oct-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: replace magic numbers with defines eeepc_[gs]et_fan_ctrl uses some magic numbers. These numbers mean something more than just the number. Describe them with macros instead of comments in one of the functions. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
792bd2a5 |
|
22-Oct-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: define rfkill notifier nodes only once The rfkill notifier node names are used in three different places. As a matter of style, it is better to store them somewhere and have the compiler warn us about typos in the function arguments. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
9f662b20 |
|
22-Oct-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: don't break user visible strings As per Documentation/CodingStyle ch. 2, it is preferred that we don't break user visible strings, in order to allow users to grep for them. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
248d4903 |
|
22-Oct-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: flatten control flow In eeepc_rfkill_hotplug there's an if statement with a big tail that ends right before the out_unlock label. We might as well invert the condition and jump to out_unlock in that case, pretty much like the rest of the code does. This removes an indentation level for a large chunk of code and also stops suggesting there might be an else clause. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
3493f414 |
|
20-Oct-2014 |
Wolfram Sang <wsa@kernel.org> |
platform: x86: drop owner assignment from platform_drivers A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
#
557b4549 |
|
20-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: clean up control flow in *_rfkill_notifier Handle errors immediately in eeepc_register_rfkill_notifier and eeepc_unregister_rfkill_notifier. This clears up the control flow for the reader. It also removes unnecessary indentation. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
d4869038 |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: store_cpufv: return error if set_acpi fails The result of set_acpi is left unchecked, but it may return errors. If one occurs, send the error to the caller. There's no reason to lie about it, if set_acpi fails. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
a5c155b1 |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: check proper return values in get_cpufv In get_cpufv the return value of get_acpi is stored in the cpufv struct. Right before this value is checked for errors, it is and'ed with 0xff. This means c->cur can never be less than zero. Besides that, the actual error value is ignored. c->num is also and'ed with 0xff, which means we can ignore values below zero. Check the result of get_acpi() right away. While at it, propagate the error if we got one. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
48d4a5b2 |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: make fan1_input really read-only In the instantiation of the fan1_input device attribute, NULL is passed as set function to store_sys_hwmon. The function pointer is never checked before dereferencing it. This is fine if we can guarantee that it will never be called with an invalid pointer, but we can't. If someone from user space decides to change the permissions on this attribute and write to it, kernel will crash. Introduce EEEPC_CREATE_SENSOR_ATTR_RO() to instantiate a read-only attribute, and declare fan1_input with it. This ensures store_sys_hwmon is never called with NULL parameters. If someone tries to write the attribute, the system will at least keep its sanity. This also causes EEEPC_CREATE_SENSOR_ATTR() to be only used for R/W attributes.This enables us to drop the _mode argument from the macro and use DEVICE_ATTR_RW() internally while we're at it. Append _RW to the name for readability. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
28ac85f7 |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: pull out SENSOR_STORE_FUNC and SENSOR_SHOW_FUNC macros Pull out EEEPC_SENSOR_STORE_FUNC and EEEPC_SENSOR_SHOW_FUNC. These macros define functions that call store_sys_hwmon() and show_sys_hwmon() respectively. This helps prevent duplication later on. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
6fe3a77f |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: tell sysfs that the disp attribute is write-only The disp attribute is write-only, but sysfs doesn't know this. Currently show_sys_acpi() is mimicking sysfs behavior, if the underlying acpi call should fail. This was introduced in 6dff29b63a5bf2eaf3 "eeepc-laptop: disp attribute should be write-only". This is not ideal; behaving like sysfs is better left to sysfs. Introduce EEEPC_CREATE_DEVICE_ATTR_WO() to instantiate a write-only attribute, and declare the disp attribute with it. Sysfs makes sure userspace can only write to disp at all times. This removes the need for mimicking the sysfs behavior in show_sys_acpi() and store_sys_acpi(), but we'll stick with -EIO, as changing sysfs return values should not be taken lightly. This change also causes EEEPC_CREATE_DEVICE_ATTR() to be used only for R/W attributes. This enables us to drop the _mode argument from the macro and use DEVICE_ATTR_RW() internally while we're at it. Append _RW to the name for readability. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
97971325 |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: pull out ACPI_STORE_FUNC and ACPI_SHOW_FUNC macros Pull out macros EEEPC_ACPI_STORE_FUNC and EEEPC_ACPI_SHOW_FUNC. These macros define functions that call store_sys_acpi() and show_sys_acpi() respectively. This helps prevent duplication later on. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
bb382dba |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: use DEVICE_ATTR* to instantiate device_attributes Device attributes are instantiated manually, while we have DEVICE_ATTR* macros available to do much of the work for us. Let's use them. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
8c72fc8b |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: change sysfs function names to API expectations The eeepc-laptop driver follows the function naming convention <action>_<attrname>(), while the sysfs macros are built around the convention <attrname>_<action>(). Rename the sysfs functions to the convention used by sysfs. This makes it easier to use the available API later on. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
39a3e17e |
|
17-Sep-2014 |
Frans Klaver <fransklaver@gmail.com> |
eeepc-laptop: clean up coding style Correct indentation and brace usage to comply with Documentation/CodingStyle. Signed-off-by: Frans Klaver <fransklaver@gmail.com> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
95369a73 |
|
17-Sep-2014 |
Paul Bolle <pebolle@tiscali.nl> |
eeepc-laptop: simplify parse_arg() parse_arg() has three possible return values: -EINVAL if sscanf(), in short, fails; zero if "count" is zero; and "count" in all other cases But "count" will never be zero. See, parse_arg() is called by the various store functions. And the callchain of these functions starts with sysfs_kf_write(). And that function checks for a zero "count". So we can stop checking for a zero "count", drop the "count" argument entirely, and transform parse_arg() into a function that returns zero on success or a negative error. That, in turn, allows to make those store functions just return "count" on success. The net effect is that the code becomes a bit easier to understand. A nice side effect is that this GCC warning is silenced too: drivers/platform/x86/eeepc-laptop.c: In function ‘store_sys_acpi’: drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be used uninitialized in this function [-Wmaybe-uninitialized] int rv, value; Which is, of course, the reason to have a look at parse_arg(). Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
#
1ec9d399 |
|
17-Jun-2014 |
Paul Bolle <pebolle@tiscali.nl> |
eeepc-laptop: rename _set and _get arguments in macro The _set and _get arguments to the EEEPC_CREATE_SENSOR_ATTR() macro are confusingly named: _set should be _get and vice versa. Rename these arguments. Drop the trailing semicolon from that macro, while we're at it. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
#
c893d133 |
|
29-May-2014 |
Yijing Wang <wangyijing@huawei.com> |
PCI: Make pci_bus_add_device() void pci_bus_add_device() always returns 0, so there's no point in returning anything at all. Make it a void function and remove the tests of the return value from the callers. [bhelgaas: changelog, remove unused "err" from i82875p_setup_overfl_dev()] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
f0c34c97 |
|
23-Nov-2013 |
Guenter Roeck <linux@roeck-us.net> |
eeepc-laptop: Convert to use devm_hwmon_device_register_with_groups Simplify the code and avoid race condition caused by creating sysfs attributes after creating the hwmon device. Also replace SENSOR_DEVICE_ATTR with DEVICE_ATTR since the extra argument is not used and SENSOR_DEVICE_ATTR is not needed. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
#
8b9ec1da |
|
10-Jan-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
platform / x86: Use global PCI rescan-remove locking Multiple race conditions are possible between the rfkill hotplug in the asus-wmi and eeepc-laptop drivers and the generic PCI bus rescan and device removal that can be triggered via sysfs. To avoid those race conditions make asus-wmi and eeepc-laptop use global PCI rescan-remove locking around the rfkill hotplug. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
|
#
8b48463f |
|
02-Dec-2013 |
Lv Zheng <lv.zheng@intel.com> |
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b222cca6 |
|
23-Oct-2013 |
Joe Perches <joe@perches.com> |
platform:x86: Remove OOM message after input_allocate_device Emitting an OOM message isn't necessary after input_allocate_device as there's a generic OOM and a dump_stack already done. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
#
fca41991 |
|
02-Sep-2013 |
Zhang Rui <rui.zhang@intel.com> |
eeepc-laptop: convert acpi_evaluate_object() to acpi_execute_simple_method() acpi_execute_simple_method() is a new ACPI API introduced to invoke an ACPI control method that has single integer parameter and no return value. Convert acpi_evaluate_object() to acpi_execute_simple_method() in drivers/platform/x86/eeepc-laptop.c Signed-off-by: Zhang Rui <rui.zhang@intel.com> CC: Matthew Garrett <matthew.garrett@nebula.com> CC: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1696d9dc |
|
15-Jul-2013 |
Thomas Renninger <trenn@suse.de> |
ACPI: Remove the old /proc/acpi/event interface It is quite some time that this one has been deprecated. Get rid of it. Should some really important user be overseen, it may be reverted and the userspace program worked on first, but it is time to do something to get rid of this old stuff... Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Matthew Garrett <matthew.garrett@nebula.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c73bad74 |
|
09-Jan-2013 |
Guenter Roeck <linux@roeck-us.net> |
platform/x86: (eeepc-laptop) Replace SENSORS_LIMIT with clamp_val SENSORS_LIMIT and clamp_val have the same functionality, so retire SENSORS_LIMIT as it is no longer needed. The change reduces text size by 26 bytes and bss size by 16 bytes on x86_86 builds. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Jean Delvare <khali@linux-fr.org>
|
#
51fac838 |
|
23-Jan-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI: Remove useless type argument of driver .remove() operation The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
|
#
b859f159 |
|
21-Dec-2012 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Drivers: platform: x86: remove __dev* attributes. CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Joey Lee <jlee@novell.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Peter Feuerer <peter@piie.net> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Cc: Robert Gerlach <khnz@gmx.de> Cc: Ike Panhc <ike.pan@canonical.com> Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f661848b |
|
13-Sep-2012 |
Jiang Liu <liuj97@gmail.com> |
eeepc-laptop: fix device reference count leakage in eeepc_rfkill_hotplug() Fix a device reference count leakage issue in function eeepc_rfkill_hotplug(). Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
ce6c468f |
|
15-Dec-2011 |
Corentin Chary <corentin.chary@gmail.com> |
eeepc-laptop: log unknown keys Signed-off-by: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
210647af |
|
25-Feb-2012 |
Yinghai Lu <yinghai@kernel.org> |
PCI: Rename pci_remove_bus_device to pci_stop_and_remove_bus_device The old pci_remove_bus_device actually did stop and remove. Make the name reflect that to reduce confusion. This patch is done by sed scripts and changes back some incorrect __pci_remove_bus_device changes. Suggested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
5d6afd15 |
|
08-Aug-2011 |
Axel Lin <axel.lin@gmail.com> |
platform-drivers-x86: eeepc-laptop: fix wrong test for successful registered led_classdev device_create returns &struct device pointer on success, or ERR_PTR() on error. Thus if led_classdev_register fails, led_cdev->dev is always not NULL. If IS_ERR(eeepc->tpd_led.dev) is ture, it means led_classdev_register fails. If (asus->tpd_led.dev) is NULL, it means we call eeepc_led_exit before calling led_classdev_register for &eeepc->tpd_led. We only want to call led_classdev_unregister for sucessfully registered led_classdev, then we should check (!IS_ERR_OR_NULL(eeepc->tpd_led.dev)). Signed-off-by: Axel Lin <axel.lin@gmail.com> Acked-by: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
22441ffe |
|
29-Mar-2011 |
Joe Perches <joe@perches.com> |
eeepc: Use pr_warn Just a trivial pr_warning to pr_warn conversion while adding a few missing newlines. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
14fdb152 |
|
09-May-2011 |
Matthew Garrett <mjg@redhat.com> |
eeepc-laptop: Use ACPI handle to identify rfkill port The ACPI notification we get from rfkill events on these machines gives us all the information we need to identify the port that's changed. Do so rather than assuming that it's always bus 1. Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
c8440336 |
|
17-Mar-2011 |
Lucas De Marchi <lucas.de.marchi@gmail.com> |
platform-drivers: x86: fix common misspellings Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
bb7ca747 |
|
22-Mar-2011 |
Matthew Garrett <mjg@redhat.com> |
backlight: add backlight type There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
62a75d83 |
|
29-Nov-2010 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: add a getter for touchpad led Allow te get the current led state in a more accurate way. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
acc2472e |
|
16-Nov-2010 |
Lionel Debroux <lionel_debroux@yahoo.fr> |
backlight: constify backlight_ops backlight_device_register has been expecting a const "ops" argument, and using it as such, since 9905a43b2d563e6f89e4c63c4278ada03f2ebb14. Let's make the remaining backlight_ops instances const. Inspired by hunks of the grsecurity patch, updated for newer kernels. Signed-off-by: Lionel Debroux <lionel_debroux@yahoo.fr> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
71e687dc |
|
24-Aug-2010 |
Corentin Chary <corentincj@iksaif.net> |
platform-x86: sync eeepc-laptop and asus-laptop Makes asus-laptop and eeepc-laptop _init/_exit functions looks exactly the same as they do the same thing. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
bfa47960 |
|
20-Jul-2010 |
Axel Lin <axel.lin@gmail.com> |
eeepc-laptop: fix hotplug_disabled module_param permissions The hotplug_disabled module parameter is determinated at the module load time. Change the value after the module is loaded does not make sense and has no effect at all, thus set the permissions to 0444 instead of 0644. Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Matthew Garrett <mjg@redhat.com> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
#
c9db3efe |
|
10-Apr-2010 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: add missing sparse_keymap_free Also remove legacy keymap which was not used since we use sparse_keymap. Signed-off-by: Corentin Chary <corentincj@iksaif.net>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
a19a6ee6 |
|
17-Feb-2010 |
Matthew Garrett <mjg@redhat.com> |
backlight: Allow properties to be passed at registration Values such as max_brightness should be set before backlights are registered, but the current API doesn't allow that. Add a parameter to backlight_device_register and update drivers to ensure that they set this correctly. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
bc9d24a3 |
|
22-Feb-2010 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: check wireless hotplug events Before we mark the wireless device as unplugged, check PCI config space to see whether the wireless device is really disabled (and vice versa). This works around newer models which don't want the hotplug code, where we end up disabling the wired network device. My old 701 still works correctly with this. I can also simulate an afflicted model by changing the hardcoded PCI bus/slot number in the driver, and it seems to work nicely (although it is a bit noisy). In future this type of hotplug support will be implemented by the PCI core. The existing blacklist and the new warning message will be removed at that point. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
|
#
ced69c59 |
|
20-Feb-2010 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: disable wireless hotplug for 1005PE The wireless hotplug code is not needed on this model, and it disables the wired ethernet card. (Like on the 1005HA and 1201N). References: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/003281.html> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Reported-by: Ansgar Burchardt <ansgar@43-1.org> CC: stable@kernel.org
|
#
4194e2f5 |
|
06-Jan-2010 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: disable wireless hotplug for 1201N Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
322a1356 |
|
06-Jan-2010 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: add hotplug_disable parameter Some new models need to disable wireless hotplug. For the moment, we don't know excactly what models need that, except 1005HA. Users will be able to use that param as a workaround. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
642e0447 |
|
06-Jan-2010 |
Dmitry Torokhov <dtor@mail.ru> |
eeepc-laptop: switch to using sparse keymap library Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
10ae4b56 |
|
06-Jan-2010 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: dmi blacklist to disable pci hotplug code This is a short term workaround for Eeepc 1005HA. refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
da8ba01d |
|
06-Jan-2010 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: disable cpu speed control on EeePC 701 The EeePC 4G ("701") implements CFVS, but it is not supported by the pre-installed OS, and the original option to change it in the BIOS setup screen was removed in later versions. Judging by the lack of "Super Hybrid Engine" on Asus product pages, this applies to all "701" models (4G/4G Surf/2G Surf). So Asus made a deliberate decision not to support it on this model. We have several reports that using it can cause the system to hang [1]. That said, it does not happen all the time. Some users do not experience it at all (and apparently wish to continue "right-clocking"). Check for the EeePC 701 using DMI. If met, then disable writes to the "cpufv" sysfs attribute and log an explanatory message. Add a "cpufv_disabled" attribute which allow users to override this policy. Writing to this attribute will log a second message. The sysfs attribute is more useful than a module option, because it makes it easier for userspace scripts to provide consistent behaviour (according to user configuration), regardless of whether the kernel includes this change. [1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
47145210 |
|
14-Dec-2009 |
Alexey Dobriyan <adobriyan@gmail.com> |
const: constify remaining dev_pm_ops Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
325fb8e9 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: re-add check for eeepc->backlight == NULL As Corentin points out, we do not create a backlight device if the ACPI video driver is able to provide equivalent functionality. So we do need to check before we try to update the backlight device. We now ignore brightness events completely if we have not created a backlight device. This is slightly more cautious than the original check. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f90be874 |
|
03-Dec-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: fix coding style fix styles problems introduced by commit e86bda235a08b6a8e64c1e8bb9d175f6961554e3 Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b39b85e74 |
|
03-Dec-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: map keys found on newer eeepc Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
854c7836 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: callbacks should use "driver data" parameter or field Callback methods should not refer to a variable like "eeepc" (formally "ehotk"). Instead, they should extract the data they need either from a "driver data" parameter, or the "driver data" field of the object which they operate on. The "eeepc" variable can then be removed. In practice, drivers under "drivers/platform" can get away without using driver data, because it doesn't make sense to have more than one instance of them. However this makes it harder to review them for correctness. This is especially true for core ACPI developers who have not previously been exposed to this anti-pattern :-). This will serve as an example of best practice for new driver writers (whether they find it themselves, or have it pointed out during review :-). The hwmon sub-device is a special case. It uses ec_{read,write} which are defined to communicate with the (first) EC, so it does not require any driver data. It should still only be instantiated in the context of an ASUS010 device because we don't have a safe way to probe for it. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> CC: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a7624b63 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: revise names eeepc-laptop now does a lot more than just hotkeys. Replace the "hotk" names used throughout the driver with some slightly more appropriate names. The actual strings used in kernel messages and sysfs are left unchanged. e.g. EEEPC_HOTK_FILE -> EEEPC_LAPTOP_FILE EEEPC_HOTK_HID -> EEEPC_ACPI_HID eeepc_hotk_notify -> eeepc_acpi_notify struct eeepc_hotk -> struct eeepc_laptop ehotk -> eeepc I'm about to refactor the entire driver to remove the global "ehotk" variable, and I don't wish to add "struct eeepc_hotk *ehotk" to functions which have nothing to do with hotkeys. Also - fix the name of "eepc_get_entry_by_keycode()" - remove the unused definition of NOTIFY_WLAN_ON. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
52bbe3c7 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: code movement Move e.g. backlight_init() and backlight_exit() together along with the other backlight functions, instead of grouping init() and exit() functions. Move e.g. backlight_ops to follow the functions it refers to, and remove the forward declarations. The code itself should remain unchanged. The eeepc-laptop driver implements a number of interfaces like the backlight class driver. This change makes it easier to examine the implementation of one interface at at a time, without having to search through the file to find init() and exit() functions etc. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
9db106be |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: move platform device initialisation to a separate function This moves the sysfs_create_group() call just after the declaration of the platform device attributes. It should make it easier to examine the implementation of the platform device attributes in isolation from the rest of the code. (The next commit will apply this pattern to all of the sub-devices as well). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk Signed-off-by: Len Brown <len.brown@intel.com>
|
#
22072e92 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: move platform driver registration out of eeepc_hotk_add() Strictly speaking we should register the platform driver exactly once, whether there are zero, one, or multiple matching acpi devices. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
bf9598bc |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: refactor notifications Separate out input_notify(), in a similar way to how notify_brn() is already separated. This will allow all the functions which refer to the input device to be grouped together. This includes a small behaviour change - we now synthesize brightness up/down key events even if the brightness is already at the maximum/minimum value. This is consistent with the new uevent interface. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
463b4e47 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: simplify how the hwmon device reads values from the EC The hwmon device uses ec_write() to write values to the EC. So for consistency it should use ec_read() to read values. The extra layers of indirection used did not add any value. This may mean we no longer take the ACPI global lock for such reads (if the EC operation region requires the lock and the EC does not). But there is no point locking each one-byte read individually, when write operations do not use the lock at all. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6b188a7b |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: simplify acpi initialization We don't need to store init_flags after using them. And we don't use the result of INIT, so we don't need to allocate a buffer for it. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
951037ea |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: no need to check argument of set_brightness() We already tell the backlight class our maximum brightness value; it will validate the user requested values for us. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a2a1d36c |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: remove redundant NULL checks eeepc_hotk_notify() cannot be called with ehotk == NULL or bd == NULL. We check both variables for allocation failure and would bail out before the notifier is registered. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
13f70029 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix set_acpi() to return non-zero on failure If the control method does not exist, return -ENODEV for consistency with get_acpi() Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dc56ad9b |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix potential leak (led_init() failure) If we bail out because we can't create the led class device, we need to ensure the led workqueue is cleaned up. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2b56f1c1 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix led initialization order Create the workqueue thread used by tpd_led_set() *before* we register the led device. (And vice versa for unregistration). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
48718688 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix value of pwm1_enable to match documentation Documentation/hwmon/sysfs-interface tells us that automatic fan speed control should be represented by a value of 2 or above for pwm1_enable. Fix eeepc_get_fan_ctrl() to return 2 for automatic fan control. Setting "1" for manual control is already consistent with the documentation, so this remains unchanged. Let's preserve the ABI for this specific driver, so that writing "0" will still invoke automatic control. (The documentation says setting "0" should leave the fan at full speed all the time. This mode is not directly supported by our hardware. Full speed is rather noisy on my 701 and the automatic control has never used it. If you really want this e.g. to prolong the life of an EeePC used as a server, you can always use manual mode. hwmon has always been fairly machine-specific, and you're in a tiny minority (or elite :-). I'm sure you're smart enough to notice that the fan doesn't turn on to full speed when you try this mode, either by ear or checking fan_input1. We could even claim to be honouring the spirit of the documentation. "0" really means "safe mode". EeePCs default to automatic mode, ie that is what Asus will actually test. Since we do not provide any way to tamper with the temperature threshold, automatic mode _is_ the safe option). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
eacec303 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: set acpi_driver.owner The owner field provides the link between drivers and modules in sysfs, but no ACPI driver was setting it. After setting the owner field, we can see which module provides which driver and vice versa by looking at /sys/bus/acpi/driver/*/module and /sys/module/*/drivers/acpi:*. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2adb8bd3 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: Remove uneccesary acpi_disabled check acpi_bus_register_driver() already checks acpi_disabled, so acpi bus drivers don't need to. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
fbe3d894 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: Remove redundant NULL checks The acpi device callbacks add, start, remove, suspend and resume can never be called with a NULL acpi_device. Each callsite in acpi/scan.c has to dereference the device in order to get the ops structure, e.g. struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; if (acpi_drv && acpi_drv->ops.suspend) return acpi_drv->ops.suspend(acpi_dev, state); Remove all checks for acpi_dev == NULL within these callbacks. Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of these checks could fail unless the driver does something strange (which none of them do), the acpi core did something terribly wrong, or we have a memory corruption issue. If this does happen then it's best to dereference the pointer and crash noisily. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3c0eb510 |
|
03-Dec-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: add touchpad led This led can be found on Eeepc 1005 series. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6dff29b6 |
|
03-Dec-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: disp attribute should be write-only Currently, reading from the disp attribute fails with "No such device", which is misleading. According to CMSG table on acpi4asus project site, no models have a getter method corresponding to SDSP. Change the file permission to disallow reads. If some joker changes the permission to permit reads, then return -EIO to be consistent with sysfs' behaviour when no show() method is provided. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
80f0c895 |
|
16-Oct-2009 |
Luca Niccoli <lultimouomo@gmail.com> |
eeepc-laptop: don't enable camera at startup if it's already on. Switching the camera takes 500ms, checking if it's on is almost free... The BIOS remembers the setting through reboots, so there's good chance the camera is already enabled. Signed-off-by: Luca Niccoli <lultimouomo@gmail.com> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
58ce48a9 |
|
16-Oct-2009 |
Corentin Chary <corentincj@iksaif.net> |
Revert "eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated" rt2860sta is fine with the patch as is, but iwl3945 isn't (eeepc_rfkill_set() needs to call eeepc_rfkill_hotplug(true) – which means that we're back to causing the rt2860sta panic This reverts commit b56ab33d68638e6aafdbfc694025e8354a628f49. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b56ab33d |
|
12-Oct-2009 |
Darren Salt <linux@youmustbejoking.demon.co.uk> |
eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated This works around what I think is actually a bug in rt2860sta which is triggered when the hardware "disappears" from beneath the driver, i.e. when wireless is toggled off via ACPI. It does so by ensuring that the rfkill soft-block flag is set before the hardware is disabled. I do not know whether this patch is required if rt2800pci is in use instead of rt2860sta; at the time of submission of this patch, I've not been able to test this. (Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390) Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dcb73eed |
|
12-Oct-2009 |
Rakib Mullick <rakib.mullick@gmail.com> |
eeepc-laptop: Properly annote eeepc_enable_camera(). Currently the annotation for function eeepc_enable_camera() is __init, and refers to a function eeepc_hotk_add() which is non-init. Use __devinit for both functions which is more appropriate and fixes a section mismatch warning. We were warned by the following warning: LD drivers/platform/x86/built-in.o WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section mismatch in reference from the function eeepc_hotk_add() to the function .init.text:eeepc_enable_camera() The function eeepc_hotk_add() references the function __init eeepc_enable_camera(). This is often because eeepc_hotk_add lacks a __init annotation or the annotation of eeepc_enable_camera is wrong. Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d822d5c2 |
|
14-Jul-2009 |
Matthew Garrett <mjg@redhat.com> |
backlight/eeepc-laptop: Update the backlight state when we change brightness Trigger a status update when the user hits a brightness key, allowing userspace to present appropriate UI. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
52cc96bd |
|
29-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: allow rfkill hotplug to work on the 900A model The 900A provides hotplug notifications on a different ACPI object to other models. Reported-by: Trevor <trevor.chart@gmail.com> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a8258069 |
|
29-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix rfkill memory leak on unload rfkill_unregister() should always be followed by rfkill_destroy() Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
aeb41b85 |
|
28-Aug-2009 |
Len Brown <len.brown@intel.com> |
eeepc-laptop: whitespace for checkpatch.pl checkpatch doesn't like tab+space for a return statement. WARNING: suspect code indent for conditional statements (8, 17) + if (!device) + return -EINVAL; Signed-off-by: Len Brown <len.brown@intel.com>
|
#
d1ec9c3d |
|
27-Aug-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: add rfkill support for the Wimax in ASUS Eee PC 1000HG Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c200da5d |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: switch to dev_pm_ops This also involves switching the resume handler from the acpi device to the platform device. Using the more fine grained handlers allows two improvements: 1. We only need to recheck rfkill state after resume from hibernation. 2. The wireless LED workaround accounts for up to 1.1s out of 1.7s resuming devices (when wireless is enabled). We can limit the workaround to thaw(), so that it only delays suspend to disk. The workaround is only likely to help when hibernation is aborted. Suspend to ram cannot be aborted by the user. Device suspend errors may well happen before eeepc-laptop would even be frozen. Suspend errors which happen after that could be pretty funky anyway. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c1edd99f |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: correct the description of the hibernation abort bug Actually it is only the LED which is affected. The bios bug does not disable the wifi. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a4746101 |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: check the 3G rfkill state on resume All the rfkill devices are treated as "persistent", 3G is no exception. This means their state may change over hibernation. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
ffb03575 |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: remove redundant rfkill_set_sw_state in resume handler rfkill_set_sw_state() will already be called by eeepc_rfkill_hotplug(). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f2a9d5e8 |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: make input device a child of the platform device Sysfs showed the ehotk input device as a "virtual" device - lies! The input device is provided by a physical device, the eeepc platform. This requires that we move the creation of the input device to come after platform device is created. Input initialization is moved from ehotk_check() [sic] to a new function called eeepc_input_init(). This brings the input device into line with the other eeepc-laptop devices. Also, refuse to load if we fail to register the input device. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1e779854 |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix ordering of init and exit functions 1. input and backlight devices were registered after acpi notifications are enabled. This left a window where eeepc_hotk_notify() might find these devices in an inconsistent (half-initialized) state. -> Move all device registration into eeepc_hotk_add(), which is called before enabling acpi notifications. 2. input and backlight devices were unregistered before acpi notifications are disabled. This left a window where eeepc_hotk_notify() might find these devices in an inconsistent (half-destroyed) state. -> Move all device unregistration into eeepc_hotk_remove(), which is called after disabling acpi notifications. 3. The acpi driver was not freed if an error occured further down in eeepc_laptop_init(). -> The rest of eeepc_laptop_init() has been moved to eeepc_hotk_add(), so this is no longer a problem. 4. The acpi driver was unregistered before the platform driver. This left a window where a sysfs access could attempt to read the ehotk structure after it had been freed by eeepc_hotk_remove(). -> The acpi driver is now unregistered as the last step in eeepc_laptop_exit(), so this is no longer a problem. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
07e84aa9 |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix pci hotplug race on load and unload Wifi rfkill state changes can race with pci hotplug cleanup. A simple fix is to refresh the hotplug state just before deregistering the pci hotplug slot. There is also potential for a hotplug notification to fire too early during setup, while the structures it uses are still being initialised. (This could only happen if the BIOS performs hotplug itself; a bug triggered by removing the battery while hibernated). Avoid this by registering the notifier later. The same refresh mechanism is used to handle rfkill state changes which can now race with registration. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dcf443b5 |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: use a mutex to serialize pci hotplug (resume vs. notify) Commit d0265f0 "eeepc-laptop: fix hot-unplug on resume" used a workqueue to protect pci hotplug against multiple simultaneous calls during resume. It seems to work, but a mutex would be more appropriate. This is in preparation to fix the potential pci hotplug race on unload. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
6d41839e |
|
27-Aug-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: don't touch the pci slot if it was claimed by a different driver The whole point of registering as a PCI hotplug driver was to prevent conflict with pciehp. At the moment it happens to work because eeepc-laptop is loaded first, but it doesn't work the other way round. If pciehp is loaded first then we fail to claim the slot - we need to respect this and not handle hotplug events. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7334546a |
|
29-Jun-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix hot-unplug on resume OOPS on resume when the wireless adaptor is disabled during suspend was introduced by "eeepc-laptop: read rfkill soft-blocked state on resume". Unable to handle kernel NULL pointer dereference Process s2disk Tainted: G W IP: klist_put Call trace: ? klist_del ? device_del ? device_unregister ? pci_stop_dev ? pci_stop_bus ? pci_remove_device ? eeepc_rfkill_hotplug [eeepc_laptop] ? eeepc_hotk_resume [eeepc_laptop] ? acpi_device_resume ? device_resume ? hibernation_snapshot It appears the PCI device is removed twice. The eeepc_rfkill_hotplug() call from the resume handler is racing against the call from the ACPI notifier callback. The ACPI notification is triggered by the resume handler when it refreshes the value of CM_ASL_WLAN. The fix is to serialize hotplug calls using a workqueue. http://bugzilla.kernel.org/show_bug.cgi?id=13825 Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3cd530b5 |
|
25-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: add rfkill support for the 3G modem in Eee PC 901 Go Signed-off-by: Janne Grunau <j@jannau.net> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
dbfa3ba9 |
|
25-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: get the right value for CMSG CMSG is an ACPI method used to find features available on an Eee PC. But some features are never repported, even if present. If the getter of a feature is present, this patch will set the corresponding bit in cmsg. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
f36509e7 |
|
25-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: makes get_acpi() returns -ENODEV If there is there is no getter defined, get_acpi() will return -ENODEV. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
1ddec2f9 |
|
25-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: right parent device Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7de39389 |
|
25-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: rfkill refactoring Refactor rfkill code, because we'll add another rfkill for wwan3g later. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
19b53289 |
|
25-Jun-2009 |
Joe Perches <joe@perches.com> |
eeepc-laptop.c: use pr_fmt and pr_<level> Convert the unusual printk(EEEPC_<level> uses to the more standard pr_fmt and pr_<level>(. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2b121bc2 |
|
25-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: Register as a pci-hotplug device The eee contains a logically (but not physically) hotpluggable PCIe slot. Currently this is handled by adding or removing the PCI device in response to rfkill events, but if a user has forced pciehp to bind to it (with the force=1 argument) then both drivers will try to handle the event and hilarity (in the form of oopses) will ensue. This can be avoided by having eee-laptop register the slot as a hotplug slot. Only one of pciehp and eee-laptop will successfully register this, avoiding the problem. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Tested-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b31d0fde |
|
16-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: cpufv updates Limit cpufv input to acceptables values. Add an available_cpufv file to show available presets. Change cpufv ouput format from %d to %#x, it won't break compatibility with existing userspace tools, but it provide a more human readable output. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b7b700d4 |
|
16-Jun-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: sync eeepc-laptop with asus_acpi In the default Eee PC distribution, there is a modified asus_acpi driver. eeepc-laptop is a cleaned version of this driver. Sync ASL enum and getter/setters with asus_acpi. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
cede2cb6 |
|
16-Jun-2009 |
Pekka Enberg <penberg@cs.helsinki.fi> |
eeepc-laptop: enable camera by default If we leave the camera disabled by default, userspace programs (e.g. Skype, Cheese) leave the user out in the cold saying that the machine "has no camera." Therefore, it's better to enable camera by default and let people who really don't want it just disable the thing. To reduce power usage you should enable USB autosuspend: echo -n auto > /sys/bus/usb/drivers/uvcvideo/*:*/../power/level Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
96e9cfeb |
|
16-Jun-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: read rfkill soft-blocked state on resume This will respect state changes over hibernation, e.g. if the user disables the wireless in the BIOS setup screen. It reveals an issue where ACPI silently kills the wireless on suspend. Normally, the BIOS restores the correct state from non-volatile storage on boot. But when hibernation is aborted, the wireless would remain killed. Fortunately we can work around this in the resume handler by simply writing back the same value we read from NVS. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
#
06d5caf4 |
|
16-Jun-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
rfkill: don't restore software blocked state on persistent devices The setting of the "persistent" flag is also made more explicit using a new rfkill_init_sw_state() function, instead of special-casing rfkill_set_sw_state() when it is called before registration. Suspend is a bit of a corner case so we try to get away without adding another hack to rfkill-input - it's going to be removed soon. If the state does change over suspend, users will simply have to prod rfkill-input twice in order to toggle the state. Userspace policy agents will be able to implement a more consistent user experience. For example, they can avoid the above problem if they toggle devices individually. Then there would be no "global state" to get out of sync. Currently there are only two rfkill drivers with persistent soft-blocked state. thinkpad-acpi already checks the software state on resume. eeepc-laptop will require modification. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> CC: Marcel Holtmann <marcel@holtmann.org> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
#
d9b9bd7b |
|
30-Apr-2009 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
ACPI: eeepc-laptop: use .notify method instead of installing handler directly This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. This driver relies on seeing system notify events, not device-specific ones (because it used ACPI_SYSTEM_NOTIFY). We use the ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events, then just ignore any device events we get. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Corentin Chary <corentincj@iksaif.net> CC: acpi4asus-user@lists.sourceforge.net CC: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b3fa1329 |
|
08-Jun-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
rfkill: remove set_global_sw_state rfkill_set_global_sw_state() (previously rfkill_set_default()) will no longer be exported by the rewritten rfkill core. Instead, platform drivers which can provide persistent soft-rfkill state across power-down/reboot should indicate their initial state by calling rfkill_set_sw_state() before registration. Otherwise, they will be initialized to a default value during registration by a set_block call. We remove existing calls to rfkill_set_sw_state() which happen before registration, since these had no effect in the old model. If these drivers do have persistent state, the calls can be put back (subject to testing :-). This affects hp-wmi and acer-wmi. Drivers with persistent state will affect the global state only if rfkill-input is enabled. This is required, otherwise booting with wireless soft-blocked and pressing the wireless-toggle key once would have no apparent effect. This special case will be removed in future along with rfkill-input, in favour of a more flexible userspace daemon (see Documentation/feature-removal-schedule.txt). Now rfkill_global_states[n].def is only used to preserve global states over EPO, it is renamed to ".sav". Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
#
19d337df |
|
02-Jun-2009 |
Johannes Berg <johannes@sipsolutions.net> |
rfkill: rewrite This patch completely rewrites the rfkill core to address the following deficiencies: * all rfkill drivers need to implement polling where necessary rather than having one central implementation * updating the rfkill state cannot be done from arbitrary contexts, forcing drivers to use schedule_work and requiring lots of code * rfkill drivers need to keep track of soft/hard blocked internally -- the core should do this * the rfkill API has many unexpected quirks, for example being asymmetric wrt. alloc/free and register/unregister * rfkill can call back into a driver from within a function the driver called -- this is prone to deadlocks and generally should be avoided * rfkill-input pointlessly is a separate module * drivers need to #ifdef rfkill functions (unless they want to depend on or select RFKILL) -- rfkill should provide inlines that do nothing if it isn't compiled in * the rfkill structure is not opaque -- drivers need to initialise it correctly (lots of sanity checking code required) -- instead force drivers to pass the right variables to rfkill_alloc() * the documentation is hard to read because it always assumes the reader is completely clueless and contains way TOO MANY CAPS * the rfkill code needlessly uses a lot of locks and atomic operations in locked sections * fix LED trigger to actually change the LED when the radio state changes -- this wasn't done before Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
#
bd32005e |
|
27-Apr-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: unregister_rfkill_notifier on failure If there is a failure during eeepc_hotk_add() we need to remove the acpi_notify_handler. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
158ca1d7 |
|
27-Apr-2009 |
Grigori Goronzy <greg@chown.ath.cx> |
eeepc-laptop: support for super hybrid engine (SHE) The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage. The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial. Signed-off-by: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
978605c4 |
|
27-Apr-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: Work around rfkill firmware bug 1) Buggy firmware can change the RFKILL state by itself. This is easily detected. The RFKILL API states that in such cases, we should call rfkill_force_state() to notify the core. I have reported the bug to Asus. I believe this is the right thing to do for robustness, even if this particular firmware bug is fixed. 2) The same bug causes the wireless toggle key to be reported as 0x11 instead of 0x10. 0x11 is otherwise unused, so it should be safe to add this as a new keycode. The bug is triggered by removing the laptop battery while hibernated. On resume, the wireless toggle key causes the firmware to toggle the wireless state itself. (Also, the key is reported as 0x11 when the current wireless state is OFF). This is very poor behaviour because the OS can't predict whether the firmware is controlling the RFKILL state. Without this workaround, the bug means users have to press the wireless toggle key twice to enable, due to the OS/firmware conflict. (Assuming rfkill-input or equivalent is being used). The workaround avoids this. I believe that acpid scripts which toggle the value of the sysfs state file when the toggle key is pressed will be rendered ineffective by the bug, regardless of this workaround. If they simply toggle the state, when the firmware has already toggled it, then you will never see a state change. Tested on "EEEPC 4G" only. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
64b86b65 |
|
27-Apr-2009 |
Darren Salt <linux@youmustbejoking.demon.co.uk> |
eeepc-laptop: report brightness control events via the input layer This maps the brightness control events to one of two keys, either KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed. Some mapping has to be done due to the fact that the BIOS reports them as <base value> + <current brightness index>; the selection is done according to the sign of the change in brightness (if this is 0, no keypress is reported). (Ref. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html) Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
fbc97e4c |
|
27-Apr-2009 |
Alan Jenkins <alan-jenkins@tuffmail.co.uk> |
eeepc-laptop: fix wlan rfkill state change during init When an rfkill device is registered, the rfkill core will change its state to the system default. So we need to prepare for state changes *before* we register it. That means installing the eeepc-specific ACPI callback which handles the hotplug of the wireless network adaptor. This problem doesn't occur during normal operation. You have to 1) Boot with wireless enabled. eeepc-laptop should load automatically. 2) modprobe -r eeepc-laptop 3) modprobe eeepc-laptop On boot, the default rfkill state will be set to enabled. With the current core code, step 2) will disable the wireless. Therefore in step 3), the wireless will change state during registration, from disabled to enabled. But without this fix, the PCI device for the wireless adaptor will not appear. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7950b71c |
|
15-Feb-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: restore acpi_generate_proc_event() Restore acpi_generate_proc_event() for backward compatibility with old acpi scripts. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
7695fb04 |
|
06-Feb-2009 |
Darren Salt <linux@youmustbejoking.demon.co.uk> |
eeepc-laptop: fix oops when changing backlight brightness during eeepc-laptop init I got the following oops while changing the backlight brightness during startup. When it happens, it prevents use of the hotkeys, Fn-Fx, and the lid button. It's a clear use-before-init, as I verified by testing with an appropriately-placed "else printk". BUG: unable to handle kernel NULL pointer dereference at 00000000 *pde = 00000000 Oops: 0002 [#1] PREEMPT SMP Pid: 160, comm: kacpi_notify Not tainted (2.6.28.1-eee901 #4) 901 EIP: 0060:[<c0264e68>] [<c0264e68>] eeepc_hotk_notify+26/da EFLAGS: 00010246 CPU: 1 Using defaults from ksymoops -t elf32-i386 -a i386 EAX: 00000009 EBX: 00000000 ECX: 00000009 EDX: f70dbf64 ESI: 00000029 EDI: f7335188 EBP: c02112c9 ESP: f70dbf80 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 f70731e0 f73acd50 c02164ac f7335180 f70aa040 c02112e6 f733518c c012b62f f70aa044 f70aa040 c012bdba f70aa04c 00000000 c012be6e 00000000 f70bdf80 c012e198 f70dbfc4 f70dbfc4 f70aa040 c012bdba 00000000 c012e0c9 c012e091 Call Trace: [<c02164ac>] ? acpi_ev_notify_dispatch+4c/55 [<c02112e6>] ? acpi_os_execute_deferred+1d/25 [<c012b62f>] ? run_workqueue+71/f1 [<c012bdba>] ? worker_thread+0/bf [<c012be6e>] ? worker_thread+b4/bf [<c012e198>] ? autoremove_wake_function+0/2b [<c012bdba>] ? worker_thread+0/bf [<c012e0c9>] ? kthread+38/5f [<c012e091>] ? kthread+0/5f [<c0103abf>] ? kernel_thread_helper+7/10 Code: 00 00 00 00 c3 83 3d 60 5c 50 c0 00 56 89 d6 53 0f 84 c4 00 00 00 8d 42 e0 83 f8 0f 77 0f 8b 1d 68 5c 50 c0 89 d8 e8 a9 fa ff ff <89> 03 8b 1d 60 5c 50 c0 89 f2 83 e2 7f 0f b7 4c 53 10 8d 41 01 Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
2b25c9f0 |
|
20-Jan-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: use netlink interface To be prepared for /proc/acpi/event removal we export events also through generic netlink interface. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
5740294c |
|
20-Jan-2009 |
Matthew Garrett <mjg@redhat.com> |
eeepc-laptop: Implement rfkill hotplugging in eeepc-laptop The Eee implements rfkill by logically unplugging the wireless card from the PCI bus. Despite sending ACPI notifications, this does not appear to be implemented using standard ACPI hotplug - nor does the firmware provide the _OSC method required to support native PCIe hotplug. The only sensible choice appears to be to handle the hotplugging directly in the eeepc-laptop driver. Tested successfully on a 700, 900 and 901. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
c9ddf8fe |
|
20-Jan-2009 |
Matthew Garrett <mjg59@srcf.ucam.org> |
eeepc-laptop: Check return values from rfkill_register Error out if rfkill registration fails, and also set the default system state appropriately on boot Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
b5f6f265 |
|
20-Jan-2009 |
Matthew Garrett <mjg59@srcf.ucam.org> |
eeepc-laptop: Add support for extended hotkeys Newer Eees have extra hotkeys above the function keys. This patch adds support for sending them through the input layer. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
a9df80c5 |
|
20-Jan-2009 |
Corentin Chary <corentincj@iksaif.net> |
eeepc-laptop: split eeepc_backlight_exit() eeepc_backlight_exit() was doing rfkill and input stuff, which is a nonsense. This patch add two specific exit functions, one for input and one for rfkill. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
3af9bfcb |
|
03-Dec-2008 |
Jonathan McDowell <noodles@earth.li> |
eeepc-laptop: enable Bluetooth ACPI details Although rfkill support for the EEE bluetooth device has been added to 2.6.28-rc the appropriate ACPI accessor definitions were not added, so the support was non functional. The patch below adds the get and set accessors and has been verified to work on an EEE 901. Signed-off-by: Jonathan McDowell <noodles@earth.li> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
|
#
41b16dce |
|
30-Nov-2008 |
Len Brown <len.brown@intel.com> |
create drivers/platform/x86/ from drivers/misc/ Move x86 platform specific drivers from drivers/misc/ to a new home under drivers/platform/x86/. The community has been maintaining x86 vendor-specific platform specific drivers under /drivers/misc/ for a few years. The oldest ones started life under drivers/acpi. They moved out of drivers/acpi/ because they don't actually implement the ACPI specification, but either simply use ACPI, or implement vendor-specific ACPI extensions. In the future we anticipate... drivers/misc/ will go away. other architectures will create drivers/platform/<arch> Signed-off-by: Len Brown <len.brown@intel.com>
|