aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge branch 'ipmi' into releaseLen Brown2009-12-16
|\
| * ipmi: add PNP discovery (ACPI namespace via PNPACPI)Bjorn Helgaas2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows ipmi_si_intf.c to claim IPMI devices described in the ACPI namespace. Using PNP makes it simpler to parse the IRQ/IO/memory resources of the device. We look at any SPMI tables before looking for devices in the namespace. This is based on ipmi_pci_probe(). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ipmi: refer to table as "SPMI", not "ACPI"Bjorn Helgaas2009-12-15
| | | | | | | | | | | | | | | | | | This discovery method uses the SPMI table, not the ACPI namespace. In the future, we will look in the namespace, so let's refer to the table as "SPMI" and save "ACPI" for the namespace. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ipmi: remove unused PCI probe codeBjorn Helgaas2009-12-15
| | | | | | | | | | Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * PNP: add interface to retrieve ACPI device from a PNPACPI deviceBjorn Helgaas2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | Add pnp_acpi_device(pnp_dev), which takes a PNP device and returns the associated ACPI device (or NULL, if the device is not a PNPACPI device). This allows us to write a PNP driver that can manage both traditional PNPBIOS and ACPI devices, treating ACPI-only functionality as an optional extension. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * PNPACPI: save struct acpi_device, not just acpi_handleBjorn Helgaas2009-12-11
| | | | | | | | | | | | | | | | Some drivers need to look at things in the acpi_device structure besides the handle. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'dell-wmi' into releaseLen Brown2009-12-16
|\ \
| * | dell-wmi: Add support for new Dell systemsRezwanul Kabir2009-12-10
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer Dell systems support HotKey features differently from legacy systems. A new vendor specifc HotKey SMBIOS table (Type 0xB2) is defined. This table contains a mapping between scancode and the corresponding predefined keyfunction ( i.e. keycode).. Also, a new ACPI-WMI event type (called KeyIDList) with a value of 0x0010 is defined. Any BIOS containing 0xB2 table will send hotkey notifications using KeyIDList event. This is Rezwanul's patch, updated to ensure that brightness events are not sent if the backlight is controlled via ACPI and with the default keycode for the display output switching altered to match desktop expectations. Signed-off-by: Rezwanul Kabir <Rezwanul_Kabir@dell.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'debug-aml' into releaseLen Brown2009-12-16
|\ \
| * | ACPI: add kernel tainting after overriding an ACPI control methodZhang Rui2009-12-15
| | | | | | | | | | | | | | | | | | | | | Add kernel tainting after overriding an ACPI control method successfully. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: support customizing ACPI control methods at runtimeZhang Rui2009-12-11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new debugfs I/F (/sys/kernel/debug/acpi/custom_method) for ACPI, which can be used to customize the ACPI control methods at runtime. We can use this to debug the AML code level bugs instead of overriding the whole DSDT table, without rebuilding/rebooting kernel any more. Detailed description about how to use this debugfs I/F is stated in Documentation/acpi/method-customizing.txt Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'bugzilla-14782' into releaseLen Brown2009-12-16
|\ \
| * | ACPI: Use the return result of ACPI lid notifier chain correctlyZhao Yakui2009-12-16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some laptops it will return NOTIFY_OK(non-zero) when calling the ACPI LID notifier. Then it is used as the result of ACPI LID resume function, which will complain the following warning message in course of suspend/resume: >PM: Device PNP0C0D:00 failed to resume: error 1 This patch is to eliminate the above warning message. http://bugzilla.kernel.org/show_bug.cgi?id=14782 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'ost' into releaseLen Brown2009-12-16
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: include/acpi/processor.h Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Notify the _PPC evaluation status to the platformZhao Yakui2009-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the ACPI spec(section 8.4.4.3) OSPM should convey the _PPC evaluations status to the platform if there exists the _OST object. The _OST contains two arguments: The first is the PERFORMANCE notificatin event. The second is the status of _PPC object. OSPM will convey the _PPC evaluation status to the platform. Of course when the module parameter of "ignore_ppc" is added, OSPM won't evaluate the _PPC object. But it will call the _OST object. At the same time the _OST object will be evaluated only when the PERFORMANCE notification event is received. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'thinkpad-2.6.33' into releaseLen Brown2009-12-16
|\ \ \
| * | | thinkpad-acpi: bump version to 0.24Henrique de Moraes Holschuh2009-12-16
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: convert to seq_fileAlexey Dobriyan2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: basic ALSA mixer support (v2)Henrique de Moraes Holschuh2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the basic ALSA mixer functionality. The mixer is event-driven, and will work fine on IBM ThinkPads. I expect Lenovo ThinkPads will cause some trouble with the event interface. Heavily based on work by Lorne Applebaum <lorne.applebaum@gmail.com> and ideas from Matthew Garrett <mjg@redhat.com>. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: disable volume controlHenrique de Moraes Holschuh2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable volume control by default. It can be enabled at module load time by a module parameter (volume_control=1). The audio control mixer that thinkpad-acpi interacts with is fully functional without any drivers, and operated by hotkeys. The idea behind the console audio control is that the human operator is the only one that can interact with it. The ThinkVantage suite in Windows does not allow any software-based overrides, and only does OSD (on-screen-display) functions. The Linux driver will, with the addition of the ALSA interface, try to follow and enforce the ThinkVantage UI design: The user is supposed to use the keyboard hotkeys to interact with the console audio control. The kernel and the desktop environment is supposed to cooperate to provide proper user feedback through on-screen-display functions. Distros are urged to not to enable volume control by default. Enabling this must be a local admin's decision. This is the reason why there is no Kconfig option. Keep in mind that all ThinkPads have a normal, main mixer (AC97 or HDA) for regular software-based audio control. We are not talking about that mixer here. Advanced users are, of course, free to enable volume control and do as they please. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: support MUTE-only ThinkPadsHenrique de Moraes Holschuh2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lenovo removed the extra mixer since the T61 and thereabouts. Newer Lenovo models only have the mute gate function, and leave the volume control to the HDA mixer. Until a way to automatically query the firmware about its audio control capabilities is discovered (there might not be any), use a white/black list. We will likely need to ask T60 (old and new model) and Z60/Z61 users whether they have volume control to populate the black/white list. Meanwhile, provide a volume_capabilities parameter that can be used to override the defaults. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: volume subdriver rewriteHenrique de Moraes Holschuh2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't trust the coupled EC writes and SMI calls the current volume control code does very much, although it is exactly what the IBM DSDTs seem to do (they never do more than a single step though). Change the driver to stop issuing SMIs, and just drive the EC directly to the desired level (DSDTs seem to confirm this will work even on very old models like the 570 and 600e/x). We checkpoint directly to NVRAM (this can be turned off) at suspend/shutdown/driver unload, which from what I can see in tbp, should also work on every ThinkPad. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Lorne Applebaum <lorne.applebaum@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: log initial state of rfkill switchesHenrique de Moraes Holschuh2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already log the initial state of the hardware rfkill switch (WLSW), might as well log the state of the softswitches as well. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Josip Rodin <joy+kernel@entuzijast.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: sync input device EV_SW initial stateHenrique de Moraes Holschuh2009-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before we register the input device, sync the input layer EV_SW state through a call to input_report_switch(), to avoid issuing a gratuitous event for the initial state of these switches. This fixes some annoyances caused by the interaction with rfkill and EV_SW SW_RFKILL_ALL events. Reported-by: Kevin Locke <kevin@kevinlocke.name> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: use input_set_capabilityHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use input_set_capability() instead of set_bit. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: log temperatures on termal alarm (v2)Henrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Log temperatures on any of the EC thermal alarms. It could be useful to help tracking down what is happening... Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: expose module parametersHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Export the normal (non-command) module paramenters as mode 0444, so that they will show up in sysfs. These parameters must not be changed at runtime as a rule, with very few exceptions. Reported-by: Ferenc Wagner <wferi@niif.hu> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: adopt input deviceHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Properly init the parent field of the input device. Thanks to Alan Jenkins, who noted this problem in a different driver. Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: silence bogus complain during rmmodHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix this bogus warning during module shutdown, when backlight event reporting is enabled: "thinkpad_acpi: required events 0x00018000 not enabled!" Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: issue backlight class eventsHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take advantage of the new events capabilities of the backlight class to notify userspace of backlight changes. This depends on "backlight: Allow drivers to update the core, and generate events on changes", by Matthew Garrett. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Matthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: fix some version quirksHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Update some of the BIOS/EC version quirks. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: preserve rfkill state across suspend/resumeHenrique de Moraes Holschuh2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the rfkill rework in 2.6.31, the driver is always resuming with the radios disabled. Change thinkpad-acpi to ask the firmware to resume with the radios in the last state. This fixes the Bluetooth and WWAN rfkill switches. Note that it means we respect the firmware's oddities. Should the user toggle the hardware rfkill switch on and off, it might cause the radios to resume enabled. UWB is an unknown quantity since it has nowhere the same level of firmware support (no control over state storage in NVRAM, for example), and might need further fixing. Testers welcome. This change fixes a regression from 2.6.30. Reported-by: Jerone Young <jerone.young@canonical.com> Reported-by: Ian Molton <ian.molton@collabora.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Tested-by: Ian Molton <ian.molton@collabora.co.uk> Cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thinkpad-acpi: fix default brightness_mode for R50e/R51Henrique de Moraes Holschuh2009-12-09
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to a report, the R50e wants EC-based brightness control, even if it uses an Intel GPU. The current driver default was reported to not work at all. This bug can be worked around by the "brightness_mode=3" module parameter. Change the default of the R50e and R51 2xxx models (which use the same EC firmware, 1V) to TPACPI_BRGHT_Q_EC, but keep TPACPI_BRGHT_Q_ASK set for now, as I'd like to get more reports. This fixes a regression caused by commit 59fe4fe34d7afdf63208124f313be9056feaa2f4, "thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM" Kernel 2.6.31 also needs this fix. Reported-by: Ferenc Wagner <wferi@niif.hu> Tested-by: Ferenc Wagner <wferi@niif.hu> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'thermal-2.6.33' into releaseLen Brown2009-12-15
|\ \ \
| * | | thermal: disable polling if passive_delay and polling_delay are both unsetFrans Pop2009-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise polling will continue for the thermal zone even when it is no longer needed, for example because forced passive cooling was disabled. Signed-off-by: Frans Pop <elendil@planet.nl> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thermal: Only set passive_delay for forced_passive coolingFrans Pop2009-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting polling_delay is useless as passive_delay has priority, so the value shown in proc isn't the actual polling delay. It also gives the impression to the user that he can change the polling interval through proc, while in fact he can't. Also, unset passive_delay when the forced passive trip point is unbound to allow polling to be disabled. Signed-off-by: Frans Pop <elendil@planet.nl> Acked-by: Matthew Garrett <mjg@redhat.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | thermal: add sanity check for the passive attributeFrans Pop2009-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Values below 1000 milli-celsius don't make sense and can cause the system to go into a thermal heart attack: the actual temperature will always be lower and thus the system will be throttled down to its lowest setting. An additional problem is that values below 1000 will show as 0 in /proc/acpi/thermal/TZx/trip_points:passive. cat passive 0 echo -n 90 >passive bash: echo: write error: Invalid argument echo -n 90000 >passive cat passive 90000 Signed-off-by: Frans Pop <elendil@planet.nl> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | acpi: thermal: display forced passive trip points in procFrans Pop2009-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users can force a passive trip point for a thermal zone that does not have _PSV defined in ACPI by setting the passive attribute in sysfs. It's useful to display such trip points in /proc/acpi/thermal_zone. .../TZ1/cooling_mode:<setting not supported> .../TZ1/polling_frequency:polling frequency: 10 seconds .../TZ1/state:state: ok .../TZ1/temperature:temperature: 53 C .../TZ1/trip_points:critical (S5): 110 C .../TZ1/trip_points:passive (forced): 95 C And if not set (passive is 0): .../TZ1/trip_points:passive (forced):<not set> Signed-off-by: Frans Pop <elendil@planet.nl> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | Merge branch 'hp-wmi' into releaseLen Brown2009-12-15
|\ \ \ \
| * | | | hp-wmi: improve rfkill supportAlan Jenkins2009-12-09
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Add support for reading the hardware blocked state. Previously we read a combination of the hardware and software blocked states, reporting it as the software blocked state. This caused some confusing behaviour. 2) The software state is persistent, mark it as such. 3) Check rfkill in the resume handler. Both the hard and soft blocked states may change over hibernation. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Tested-by: Maciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | Merge branch 'dell-laptop' into releaseLen Brown2009-12-15
|\ \ \ \
| * | | | dell-laptop: remove duplicate Kconfig entry under drivers/miscAlan Jenkins2009-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This showed up as an unselectable option when using xconfig and searching for "dell". It must been overlooked when dell-laptop was moved to drivers/platform/x86. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | dell-laptop: add __init to init functionsAlan Jenkins2009-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | dell-laptop: create a platform device as a parent for the rfkill devices etc.Alan Jenkins2009-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dell-laptop may not need to export any sysfs files, but it should still create a platform device as a parent for the rfkill and backlight devices. Otherwise sysfs will display these as "virtual" devices, with no connection to either physical hardware or the dell-laptop module. Apparently this is useful for hardware detection. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | dell-laptop: fix rfkill memory leak on unload and failure pathsAlan Jenkins2009-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rfkill_unregister() should always be followed by rfkill_destroy(). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | dell-laptop: fix a use-after-free error on the failure pathAlan Jenkins2009-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dell_setup_rfkill() already cleans up the rfkill devices on failure. So if it returns an error, we should not try to unregister the rfkill devices. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | dell-laptop: Fix rfkill state queriesMatthew Garrett2009-12-09
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code in dell-laptop is confused about the hardware rfkill state. Fix it up such that it's always reported correctly. Signed-off-by: Matthew Garrett <mjg@redhat.com> Tested-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | Merge branch 'bugzilla-14700' into releaseLen Brown2009-12-15
|\ \ \ \
| * | | | ACPI: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.Zhao Yakui2009-12-14
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE. The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly. So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f. http://bugzilla.kernel.org/show_bug.cgi?id=14700 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Acked-by: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> cc: stable@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
* | | | Merge branch 'asus' into releaseLen Brown2009-12-15
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: Documentation/feature-removal-schedule.txt drivers/platform/x86/eeepc-laptop.c Signed-off-by: Len Brown <len.brown@intel.com>