Marti Raudsepp [Wed, 20 Jan 2010 17:19:33 +0000 (19:19 +0200)]
[CPUFREQ] powernow-k8: On load failure, remind the user to enable support in BIOS setup
On Wed, 2010-01-20 at 16:56 +0100, Thomas Renninger wrote:
> But most often this happens if people upgrade their CPU and do not
> update their BIOS.
> Or the vendor does not recognise the new CPU even if the BIOS got
> updated.
Maybe some of those people just didn't realize it was disabled in BIOS?
If you tell users that it's a firmware bug then they'll probably just
give up.
> The itself message might be an enhancment, IMO it's not worth a patch.
Why do you think so? I spent an hour on hunting down the BIOS upgrade,
only to find that it didn't improve anything. It was a day later that I
realized that it might be a BIOS option; and the option was literally
the _last_ option in the whole BIOS setup. :)
The Pstate transition latency check was added for broken F10h BIOSen
which wrongly contain a value of 0 for transition and bus master
latency. Fam11h and later, however, (will) have similar transition
latency so extend that behavior for them too.
Matthew Garrett [Thu, 15 Jul 2010 15:44:00 +0000 (11:44 -0400)]
[CPUFREQ] Fix PCC driver error path
The PCC cpufreq driver unmaps the mailbox address range if any CPUs fail to
initialise, but doesn't do anything to remove the registered CPUs from the
cpufreq core resulting in failures further down the line. We're better off
simply returning a failure - the cpufreq core will unregister us cleanly if
we end up with no successfully registered CPUs. Tidy up the failure path
and also add a sanity check to ensure that the firmware gives us a realistic
frequency - the core deals badly with that being set to 0.
Matthew Garrett [Tue, 20 Jul 2010 17:52:00 +0000 (13:52 -0400)]
[CPUFREQ] pcc driver should check for pcch method before calling _OSC
The pcc specification documents an _OSC method that's incompatible with the
one defined as part of the ACPI spec. This shouldn't be a problem as both
are supposed to be guarded with a UUID. Unfortunately approximately nobody
(including HP, who wrote this spec) properly check the UUID on entry to the
_OSC call. Right now this could result in surprising behaviour if the pcc
driver performs an _OSC call on a machine that doesn't implement the pcc
specification. Check whether the PCCH method exists first in order to reduce
this probability.
395913d0b1db37092ea3d9d69b832183b1dd84c5 ("[CPUFREQ] remove rwsem lock
from CPUFREQ_GOV_STOP call (second call site)") is not needed, because
there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative
anymore. Lock should not be released until the work done.
Borislav Petkov [Tue, 25 May 2010 16:21:07 +0000 (18:21 +0200)]
edac, mc: Improve scrub rate handling
Fortify the interface to not accept negative values, remove
memctrl_int_store() as a result. Also, sanitize bandwidth setting by
making the argument a simple u32 instead of strange u32 pointer being
passed around for no obvious reason. Then, fix error handling and teach
it to return proper error values. Finally, make code more readable,
simplify debug messages.
Borislav Petkov [Mon, 8 Mar 2010 17:29:35 +0000 (18:29 +0100)]
amd64_edac: Fix DCT base address selector
The correct check is to verify whether in high range we're below 4GB
and not to extract the DctSelBaseAddr again. See "2.8.5 Routing DRAM
Requests" in the F10h BKDG.
Borislav Petkov [Mon, 15 Mar 2010 18:17:57 +0000 (19:17 +0100)]
edac: Remove EDAC_DEBUG_VERBOSE
This option differs from EDAC_DEBUG only by printing the file and
line of where the debug statement is placed, which contains unneeded
information. So remove it.
Borislav Petkov [Tue, 9 Mar 2010 11:46:00 +0000 (12:46 +0100)]
amd64_edac: Sanitize syndrome extraction
Remove the two syndrome extraction macros and add a single function
which does the same thing but with proper typechecking. While at it,
make sure to cache ECC syndrome size and dump it in debug output.
Arjan van de Ven [Mon, 26 Jul 2010 09:04:24 +0000 (10:04 +0100)]
Fix stack buffer size for IPC writev messages
The stack buffer for IPC messages was 16 bytes, limiting messages to a
size of 4 (each message is 32 bit).
However, the touch screen driver is trying to send messages of size 5....
(AC: Set to 20 bytes having checked the max size allowed)
Thomas Renninger [Thu, 29 Jul 2010 20:30:24 +0000 (22:30 +0200)]
acpi ec_sys: Be more cautious about ec write access
- Set Kconfig option default n
- Only allow root to read/write io file (sever bug!)
- Introduce write support module param -> default off
- Properly clean up if any debugfs files cannot be created
Axel Lin [Mon, 5 Jul 2010 07:29:00 +0000 (15:29 +0800)]
asus-laptop: fix asus_input_init error path
This patch includes below fixes:
1. return -ENOMEM instead of 0 if input_allocate_device fail.
2. fix wrong goto if sparse_keymap_setup fail.
3. fix wrong goto if input_register_device fail.
Pierre Ducroquet [Thu, 29 Jul 2010 09:56:59 +0000 (11:56 +0200)]
toshiba-acpi: Add support for Toshiba Illumination.
Add support for Toshiba Illumination. This is a set of LEDs installed on
some Toshiba laptops. It is controlled through ACPI, the commands has been
found through reverse engineering. It has been tested on a Toshiba Qosmio
G50-122.
Alek Du [Tue, 13 Jul 2010 09:56:25 +0000 (10:56 +0100)]
gpio: Add PMIC GPIO block support
Moorestown has PMIC chip which contains GPIO blocks. The PMIC chip is
connected to Langwell by SPI interface. So this GPIO driver will be regarded
as SPI GPIO expander though the actual GPIO access is through IPC and SRAM.
The SPI master contoller will probe this device driver by parsing SPIB table.
Cleaned up for new IPC, GPE removed and some printk and other tidying by
Alan Cox. Fixes for points noted by Matthew Garrett
Thomas Renninger [Fri, 16 Jul 2010 11:11:33 +0000 (13:11 +0200)]
ACPI: Register EC io ports in /proc/ioports
Formerly these have been exposed through /proc/..
Better register them where all IO ports should get registered
and scream loud if someone else claims to use them.
EC data and command port typically should show up like this
then:
...
0060-0060 : keyboard
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : EC command
0070-0071 : rtc0
...
Thomas Renninger [Fri, 16 Jul 2010 11:11:31 +0000 (13:11 +0200)]
ACPI: Provide /sys/kernel/debug/ec/...
This patch provides the same information through debugfs, which previously was
provided through /proc/acpi/embedded_controller/*/info
This is the gpe the EC is connected to and whether the global lock
gets used.
The io ports used are added to /proc/ioports in another patch.
Beside the fact that /proc/acpi is deprecated for quite some time,
this info is not needed for applications and thus can be moved
to debugfs instead of a public interface like /sys.
Thomas Renninger [Fri, 16 Jul 2010 11:11:34 +0000 (13:11 +0200)]
ACPI: Remove /proc/acpi/embedded_controller/..
Other patches in this series add the same info to /sys/... and
/proc/ioports.
The info removed should never have been used in an application,
eventually someone read it manually.
/proc/acpi is deprecated for more than a year anyway...
Axel Lin [Wed, 7 Jul 2010 00:21:48 +0000 (08:21 +0800)]
panasonic-laptop: fix acpi_pcc_write_sset return value
In current implementation, acpi_pcc_write_sset return 1
if write is successful, 0 if write is failed.
But all the callers consider acpi_pcc_write_sset return 0
if write is successful and return negtive if write is failed.
This patch changes the implementation of acpi_pcc_write_sset to
return 0 if write is successful, -EIO if write is failed.
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.
Axel Lin [Tue, 20 Jul 2010 22:19:55 +0000 (15:19 -0700)]
asus-laptop: fix wapf, wlan_status and bluetooth_status module_param permissions
The wapf module parameters defines the behavior of the Fn+Fx wlan key.
The wlan_status and bluetooth_status module parameters are for setting the
wlan/bluetooth status on boot.
All above module parameters are determinated only 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.
Axel Lin [Tue, 20 Jul 2010 22:19:50 +0000 (15:19 -0700)]
toshiba_acpi: make remove_device() and add_device() void
remove_device() and add_device() are not related to ACPI APIs, it does not
make sense to return acpi_status for both functions.
Current implementation of add_device() always AE_OK, thus the return value
checking for add_device() always return false for ACPI_FAILURE(status).
This patch makes add_device() to be void and remove the unnecessary return
value checking.
remove_proc_entry() won't fail, thus change remove_device() to be void.
Axel Lin [Tue, 20 Jul 2010 22:19:49 +0000 (15:19 -0700)]
acerhdf: fix resource reclaim in error path
Fix resource reclaim in below cases:
1. acerhdf_register_platform() does not properly handle
platform_device_alloc() failure and platform_device_add() failure This
patch adds error handing for acerhdf_register_platform().
2. acerhdf_register_platform() return err with acerhdf_dev == NULL.
as a result, acerhdf_unregister_platform() does not do resource reclaim
in acerhdf_init() error path. This patch adds error handing for
acerhdf_register_platform(), thus correct the error handing path in
acerhdf_init(). goto out_err instead of err_unreg if
acerhdf_register_platform() fail.
3. platform_device_del() should only used in error handling. Current
implementation missed a platform_device_put() in acerhdf_exit. This
patch fixes it by using platform_device_unregister() instead of
platform_device_del() in acerhdf_unregister_platform.
Axel Lin [Tue, 20 Jul 2010 22:19:47 +0000 (15:19 -0700)]
asus-laptop: fix incorrect return value for write_acpi_int_ret if handle is NULL
According to the comments of write_acpi_int_ret(), write_acpi_int_ret()
should return 0 if write is successful, -1 else. Thus if handle is NULL,
the write does not happen, it should return -1.
Axel Lin [Tue, 20 Jul 2010 22:19:42 +0000 (15:19 -0700)]
asus_acpi: fix coding style to improve readability
In the case of no match ( hotk->model == END_MODEL ), the only posible
case to return 0 is to have a Samsung P30 detected. This patch improves
readability by moving related code after if/else clause to be inside if
clause.
The driver now supports the Compal JHL90 (which I use) and it has some
added features. The biggest novelties are a battery interface
(power_supply) and a temperature and fan control interface (hmwon). It
also adds a power-off feature to the backlight subsystem and it exports a
few files that can enable/disable wake_on_XXX events.
Much of the original code of the old features is still there, but I've
changed some names to keep the naming more coherent with the added
functionalities. (Sorry for the huge patch)
Some technical stuff about the new driver:
First of all, I'm not sure if the extra features also work on the other
Compal boards. Currently they only get enabled if the DMI data indicates
you are on a JHL90 board.
Secondly, I've noticed a quirk in my fan controller. I have to re-send
the wanted pwm-level to the controller every so often. If I don't do
this, the fanspeed will slowly rise until after a couple of minutes it's
at full speed. (Note that every normal userland application will probably
update the pwm-level every so often anyway, based on temperature readings,
so this might not be an issue in practice) If this turns out to be a
problem with all the controllers, maybe we should implement a kernel timer
and have the driver re-send the pwm level every XX seconds to make this
transparent to userspace? (However, I couldn't immediately find a way to
do this cleanly.)
Additional information can be found in the source comments.
Randy Dunlap [Tue, 20 Jul 2010 22:19:39 +0000 (15:19 -0700)]
compal-laptop: uses hwmon interfaces, depends on HWMON
compal-laptop uses hwmon interfaces, so it should depend on HWMON.
compal-laptop.c:(.devinit.text+0x4071f): undefined reference to `hwmon_device_register'
compal-laptop.c:(.devexit.text+0x6ec0): undefined reference to `hwmon_device_unregister'
input_free_device() should only be used if input_register_device() was not
called yet or if it failed. This patch removes unnecessary
input_free_device calls.
acerhdf: driver didn't verify the pointers in which it got product information
Driver didn't verify the pointers in which it got product information back
from DMI; on QEMU one of the pointers came back null, which made the
driver crash and subsequently caused a kernel panic.
Peter Feuerer [Tue, 20 Jul 2010 22:19:32 +0000 (15:19 -0700)]
acerhdf: remove "chk_off" as it was only needed for T31 netbooks
Remove "chk_off" as it was only needed for T31 netbooks. But those
netbooks can also be handled just with "cmd_off" register (0x9e) for
reading the state back.
Axel Lin [Thu, 1 Jul 2010 02:18:01 +0000 (10:18 +0800)]
sony-laptop: use platform_device_unregister in sony_pf_remove
platform_device_unregister calls platform_device_del and platform_device_put,
thus this change is logically equivalent to original code.
I made this change because the documents in platform.c shows that:
platform_device_del and platform_device_put must _only_ be externally called
in error cases. All other usage is a bug.
Axel Lin [Wed, 30 Jun 2010 09:25:46 +0000 (17:25 +0800)]
dell-wmi: fix a memory leak
If dell_new_hk_type is true, dell_legacy_wmi_keymap will point to a memory
allocated in setup_new_hk_map().
In this case, the memory is not freed in current implementation.
This patch fixes the leak by kfree(dell_wmi_keymap) if dell_new_hk_type is true.
Jiri Slaby [Mon, 21 Jun 2010 15:40:15 +0000 (17:40 +0200)]
X86: intel_ips, check for kzalloc properly
Stanse found that there are two NULL checks missing in ips_monitor. So
check their value too and bail out appropriately if the allocation
failed.
While at it, add one more kfree to the fail path. It is not necessary
now, but may be needed in the future when a new allocation is added.
And for completeness.
Also remove unneeded initialization of the variables. They are all set
right after their declaration.
Axel Lin [Thu, 10 Jun 2010 08:06:40 +0000 (16:06 +0800)]
hp-wmi: add error handling for hp_wmi_init
Current implementation in hp_wmi_init does not check any error and always
return success.
This patch properly handles recource reclaim and return err in error path.
classmate-laptop: should check for NULL as retval for rfkill_alloc
rfkill_alloc returns NULL when it fails if RFKILL is enabled. When RFKILL is
disabled, its return value of ERR_PTR(-ENODEV) is OK to use as all rfkill
functions will work with it, as they are simply empty stubs.
Jesse Barnes [Thu, 20 May 2010 21:27:23 +0000 (14:27 -0700)]
IPS driver: add GPU busy and turbo checking
Be sure to enable GPU turbo by default at load time and check GPU busy
and MCP exceeded status correctly. Also fix up CPU power comparison and
work around buggy MCH temp reporting.
Jesse Barnes [Fri, 14 May 2010 22:41:14 +0000 (15:41 -0700)]
x86 platform driver: intelligent power sharing driver
Intel Core i3/5 platforms with integrated graphics support both CPU and
GPU turbo mode. CPU turbo mode is opportunistic: the CPU will use any
available power to increase core frequencies if thermal headroom is
available. The GPU side is more manual however; the graphics driver
must monitor GPU power and temperature and coordinate with a core
thermal driver to take advantage of available thermal and power headroom
in the package.
The intelligent power sharing (IPS) driver is intended to coordinate
this activity by monitoring MCP (multi-chip package) temperature and
power, allowing the CPU and/or GPU to increase their power consumption,
and thus performance, when possible. The goal is to maximize
performance within a given platform's TDP (thermal design point).
Jesse Barnes [Mon, 10 May 2010 21:26:20 +0000 (14:26 -0700)]
timer: add on-stack deferrable timer interfaces
In some cases (for instance with kernel threads) it may be desireable to
use on-stack deferrable timers to get their power saving benefits. Add
interfaces to support this for the IPS driver.
Randy Dunlap [Sun, 23 May 2010 23:33:17 +0000 (16:33 -0700)]
platform/x86: msi-laptop depends on SERIO_I8042
msi-laptop uses i8042_*() interfaces, so it should depend on
SERIO_I8042. E.g., when SERIO_I8042=m and MSI_LAPTOP=y:
msi-laptop.c:(.text+0x18a7fe): undefined reference to `i8042_install_filter'
msi-laptop.c:(.init.text+0xd69d): undefined reference to `i8042_remove_filter'
msi-laptop.c:(.exit.text+0x19c3): undefined reference to `i8042_remove_filter'
Randy Dunlap has reported that building classmate-laptop fails when
CONFIG_RFKILL=m and CONFIG_ACPI_CMPC=y. He suggested depending on
RFKILL, but, then, it will not be possible to select classmate-laptop
when RFKILL is off. There's no known problem with building and using
classmate-laptop with RFKILL off. So depend on RFKILL or RFKILL=n.
Thomas Renninger [Fri, 21 May 2010 14:42:40 +0000 (16:42 +0200)]
X86 platform: hp-wmi Better match the HP WMI query interface
- Improve error handling, by explictly return zero for success, error otherwise
- WMI query command can have arbitrary input sized params
- WMI query command can have specific output sized params (0, 4, 128,..) byte
I like to go on here, but this is a rather intrusive change that should
be looked at first. I am sure the one or other thing can be done better or
there might be typo/bug somewhere.
This did not get any testing yet, only compile tested.
Next steps could be:
- Eventually introduce hp_wmi_perform_{read,write}_query macros
- Introduce new wireless query interface (0x1B)
- more
Thomas Renninger [Fri, 21 May 2010 14:41:43 +0000 (16:41 +0200)]
x86 platform drivers: hp-wmi fix buffer size depending on ACPI version
Depending on ACPI version (1.0 -> 32 bit) an integer could be
32 or 64 bit long. _WED internal concatenates two integers and
the return value will be 8 byte (2* 32 bit) or 16 byte (2* 64 bit)
long, depending on the ACPI version.
Also the data send with the WMI event is defined to be splitted into:
- Event ID -> 4 bytes
- Event Data -> 4 bytes
This gets messed up with new ACPI versions.
But it's a HP BIOS bug that may get fixed in the future
-> Support both, 16 and 8 byte _WED buffers.
Also the wrong assumption that from the event data sent, only the
first byte is relevant got cleaned up that it fits event_id/event_data
as described above.