These functions mix the use of result and error. In acpi_fujitsu_add,
result does not seem useful; it would seem reasonable to propagate the
return value of acpi_bus_update_power in an error case. On the other hand,
in the case of acpi_fujitsu_hotkey_add, there is an initialization of
result that can lead to what looks like a failure case, but that does not
abort the function. The variable result is kept for this case.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Installing the i8042 filter is not useful on machines where rfkill is not
whitelisted, so move the filter installation into dell_setup_rfkill,
after the whitelist check.
This avoids doing a needless and potentially troublesome rfkill query
(dell_send_request(buf, 17, 11)) when the wireless Fn key gets pressed on
non whitelisted laptops.
This patch was written as a result of:
https://bugzilla.redhat.com/show_bug.cgi?id=1045807
It is not yet clear if this is related, but it is a good idea to not register
the i8042 filter in general.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Current Intel SOC cores use a MailBox Interface (MBI) to provide access to unit
devices connected to the system fabric. This driver implements access to this
interface on BayTrail platforms. This is a requirement for drivers that need
access to unit registers on the platform (e.g. accessing the PUNIT for power
management features such as RAPL). Serialized access is handled by all exported
routines with spinlocks.
The API includes 3 functions for access to unit registers:
int bt_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
int bt_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
int bt_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
port: indicating the unit being accessed
opcode: the read or write port specific opcode
offset: the register offset within the port
mdr: the register data to be read, written, or modified
mask: bit locations in mdr to change
Returns nonzero on error
Note: GPU code handles access to the GFX unit. Therefore access to that unit
with this driver is disallowed to avoid conflicts.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This patch includes appropriate header file linux/mxm-wmi.h in
x86/mxm-wmi.c because functions mxm_wmi_call_mxds(), mxm_wmi_call_mxmx()
and mxm_wmi_supported() have their prototype declaration in
linux/mxm-wmi.h.
Thus, it also eliminates the following warnings in x86/mxm-wmi.c:
drivers/platform/x86/mxm-wmi.c:43:5: warning: no previous prototype for ‘mxm_wmi_call_mxds’ [-Wmissing-prototypes]
drivers/platform/x86/mxm-wmi.c:68:5: warning: no previous prototype for ‘mxm_wmi_call_mxmx’ [-Wmissing-prototypes]
drivers/platform/x86/mxm-wmi.c:93:6: warning: no previous prototype for ‘mxm_wmi_supported’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This patch marks the functions lis3lv02d_acpi_init(),
lis3lv02d_acpi_read() and lis3lv02d_acpi_write() as static in
x86/hp_accel.c because they are not used outside this file.
Thus, it also eliminates the following warnings in x86/hp_accel.c:
drivers/platform/x86/hp_accel.c:91:5: warning: no previous prototype for ‘lis3lv02d_acpi_init’ [-Wmissing-prototypes]
drivers/platform/x86/hp_accel.c:109:5: warning: no previous prototype for ‘lis3lv02d_acpi_read’ [-Wmissing-prototypes]
drivers/platform/x86/hp_accel.c:132:5: warning: no previous prototype for ‘lis3lv02d_acpi_write’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This patch removes the unnecessary enum for platform type to handle the
array of pdatas. We can set pdata directly to pci_device_id struct
instead.
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Simplify the code and avoid race conditions due to late sysfs attribute
registration. Also replace SENSOR_DEVICE_ATTR with DEVICE_ATTR;
the additional parameter is not used and thus unnecessary.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Simplify the code and create hwmon attributes as well as hwmon device in one go.
With the new hwmon API, hwmon attributes are now attached to the hwmon device.
Therefore, split hwmon and device attributes into two separate groups.
Platform attributes are still attached to the platform device.
Also use devm_kzalloc to allocate local data structures for further
simplification.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The extra argument to SENSOR_DEVICE_ATTR is not used. It is therefore not
necessary to use SENSOR_DEVICE_ATTR in the first place. Replace it with
DEVICE_ATTR.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
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>
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>
* acpi-cleanup: (22 commits)
ACPI / tables: Return proper error codes from acpi_table_parse() and fix comment.
ACPI / tables: Check if id is NULL in acpi_table_parse()
ACPI / proc: Include appropriate header file in proc.c
ACPI / EC: Remove unused functions and add prototype declaration in internal.h
ACPI / dock: Include appropriate header file in dock.c
ACPI / PCI: Include appropriate header file in pci_link.c
ACPI / PCI: Include appropriate header file in pci_slot.c
ACPI / EC: Mark the function acpi_ec_add_debugfs() as static in ec_sys.c
ACPI / NVS: Include appropriate header file in nvs.c
ACPI / OSL: Mark the function acpi_table_checksum() as static
ACPI / processor: initialize a variable to silence compiler warning
ACPI / processor: use ACPI_COMPANION() to get ACPI device
ACPI: correct minor typos
ACPI / sleep: Drop redundant acpi_disabled check
ACPI / dock: Drop redundant acpi_disabled check
ACPI / table: Replace '1' with specific error return values
ACPI: remove trailing whitespace
ACPI / IBFT: Fix incorrect <acpi/acpi.h> inclusion in iSCSI boot firmware module
ACPI / i915: Fix incorrect <acpi/acpi.h> inclusions via <linux/acpi_io.h>
SFI / ACPI: Fix warnings reported during builds with W=1
...
Conflicts:
drivers/acpi/nvs.c
drivers/hwmon/asus_atk0110.c
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>
We have registered platform driver and device when module
init, and need unregister them when module exit.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Olof Johansson <olof@lixom.net>
Follow-up to commit 294d31e822 ("sony-laptop: don't change keyboard
backlight settings"): avoid messing up the state on resume. Leave it to
what was before suspending as it's anyway likely that we still don't
know what value we should write to the EC registers. This fix is also
required in 3.12
Cc: stable@vger.kernel.org
Tested-by: Karol Babioch <karol@babioch.de>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Not used outside of the file, so declaration should be static. Picked up by
sparse:
drivers/platform/chrome/chromeos_laptop.c:44:12: warning: symbol
'i2c_adapter_names' was not declared. Should it be static?
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Benson Leung <bleung@chromium.org>
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Further refactor chromeos_laptop, adding a probe function.
Init will call dmi_check_system, but will only use the match to select
a chromeos_laptop structure of the current board.
Probe will add the devices, and on errors return -EPROBE_DEFER.
If i2c adapters are loaded after chromeos_laptop inits, the deferred
probe will instantiate the peripherals when the bus appears.
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
The previous code had a single DMI matching entry
for each device on a board. Instead provide a single
DMI entry for each board which references a structure
about each board that lists the associated peripherals.
This allows for a lower number of DMI matching sequences
as well making it easier to add new boards.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
I just fixed this same bug in arch/powerpc/kernel/vio.c and took a quick
look for other similar errors in the kernel.
modalias_show() should return an empty string on error, not errno.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This patch adds support for ipc command interrupt mode.
Also added platform data option to select 'irq_mode'
irq_mode = 1: configure the driver to receive IOC interrupt
for each successful ipc_command.
irq_mode = 0: makes driver use polling method to
track the command completion status.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
SNDRV_CARDS can be specified via Kconfig since 3.11 kernel, so this
can be over 32bit integer range, which leads to a build error.
Cc: <stable@vger.kernel.org> [v3.11+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
It makes sense to split out the Chromebook/Chromebox hardware platform
drivers to a separate subdirectory, since some of it will be shared
between ARM and x86.
This moves over the existing chromeos_laptop driver without making
any other changes, and adds appropriate Kconfig entries for the new
directory. It also adds a MAINTAINERS entry for the new subdir.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Some HP BIOS has dummy WMI 0x05 cmd and it causes wireless set cmd to fail.
This patch fixes the problem by detecting "2009 BIOS or later" flag which
determines whether WMI 0x1b is supported and is used to replace WMI 0x05.
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
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>
Some BIOS versions/Vaio models apparently ship with two nearly identical
functions to handle backlight related controls.
The only difference seems to be:
If (LEqual (BUF1, 0x40))
{
Store (0x40, P80H)
Store (BUF2, Local0)
- And (Local0, One, Local0)
+ And (Local0, 0x03, Local0)
Store (Local0, ^^H_EC.KLPC)
}
Avoid erroring out on initialization and messing things up on cleanup
for now since we never call into these methods with anything different
than 1 or 0.
This issue was found on a Sony VPCSE1V9E/BIOS R2087H4.
Cc: Marco Krüger <krgsch@gmail.com>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
All my testing has been on laptops with a hw killswitch, so to be on the
safe side disable rfkill functionality on models without a hw killswitch for
now. Once we gather some feedback on laptops without a hw killswitch this
decision maybe reconsidered.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Setting force_rfkill will cause the dell-laptop rfkill code to skip its
whitelist checks, this will allow individual users to override the whitelist,
as well as to gather info from users to improve the checks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Some time is needed for the BIOS to do its work, but 250ms should be plenty.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Instead when hw-blocked always write 1 to the blocked bit for the radio in
question. This is necessary to properly set all the blocked bits for hw-switch
controlled radios to 1 after power-on and resume.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This is necessary for 3 reasons:
1) To apply sw_state changes made while hw-blocked
2) To set all the blocked bits for hw-switch controlled radios to 1 when the
switch gets changed to off, this is necessary on some models to actually
turn the radio status LEDs off.
3) On some models non hw-switch controlled radios will have their block bit
cleared (potentially undoing a soft-block) on hw-switch toggle, this
restores the sw-block in this case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
This makes dell-laptop's rfkill code consistent with other drivers which
allow sw_state changes while hw blocked.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
On machines with a hardware switch, the blocking settings can not be changed
through a Fn + wireless-key combo, so there is no reason to read back the
blocking state from the BIOS.
Reading back is not only not necessary it is actually harmful, since on some
machines the blocking state will be cleared to all 0 after a wireless switch
toggle, even for radios not controlled by the hw-switch (yeah firmware bugs).
This causes "magic" changes to the sw_state. This is inconsistent with other
rfkill drivers which preserve the sw_state over a hw kill on / off.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The query callback should only update the hw_state, see the comment in
net/rfkill/core.c in rfkill_set_block, which is its only caller.
rfkill_set_block will modify the sw_state directly after calling query so
calling set_sw_state is an expensive NOP.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
To ensure we don't enter any hw-switch related code paths on machines without
a hw-switch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
The rfkill functionality was removed from the dell-laptop driver because it
was causing problems on various non Latitude models, and the blacklist kept
growing and growing. In the thread discussing this Dell mentioned that they
only QA the rfkill acpi interface on Latitudes and indeed there have been
no blacklist entries for Latitudes.
Note that the blacklist contained no Vostros either, and most Vostros have
a hardware switch too, so we could consider supporting Vostros with a
hardware switch too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Without rfkill functionality in dell-laptop I have the following problems:
-If the hardware radio switch is set to disable the radio, then userspace
will still think it can use wireless and bluetooth.
-The wwan / 3g modem cannot be soft blocked without the dell-laptop rfkill
functionality
I know the rfkill functionality was removed from the dell-laptop driver because
it caused more problems then it fixed, and the blacklist for it was growing out
of control.
But in the thread discussing this Dell mentioned that they only QA the rfkill
acpi interface on Latitudes and indeed there have been no blacklist entries
for Latitudes. Therefor I would like to bring the rfkill functionality back
only for Latitudes. This patch is a straight-forward revert. The next patch
in this set will drop the blacklist and replace it with a Latitude check.
This reverts commit a6c2390cd6.
Conflicts:
drivers/platform/x86/dell-laptop.c
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Pull more ACPI and power management updates from Rafael Wysocki:
- ACPI-based device hotplug fixes for issues introduced recently and a
fix for an older error code path bug in the ACPI PCI host bridge
driver
- Fix for recently broken OMAP cpufreq build from Viresh Kumar
- Fix for a recent hibernation regression related to s2disk
- Fix for a locking-related regression in the ACPI EC driver from
Puneet Kumar
- System suspend error code path fix related to runtime PM and runtime
PM documentation update from Ulf Hansson
- cpufreq's conservative governor fix from Xiaoguang Chen
- New processor IDs for intel_idle and turbostat and removal of an
obsolete Kconfig option from Len Brown
- New device IDs for the ACPI LPSS (Low-Power Subsystem) driver and
ACPI-based PCI hotplug (ACPIPHP) cleanup from Mika Westerberg
- Removal of several ACPI video DMI blacklist entries that are not
necessary any more from Aaron Lu
- Rework of the ACPI companion representation in struct device and code
cleanup related to that change from Rafael J Wysocki, Lan Tianyu and
Jarkko Nikula
- Fixes for assigning names to ACPI-enumerated I2C and SPI devices from
Jarkko Nikula
* tag 'pm+acpi-2-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (24 commits)
PCI / hotplug / ACPI: Drop unused acpiphp_debug declaration
ACPI / scan: Set flags.match_driver in acpi_bus_scan_fixed()
ACPI / PCI root: Clear driver_data before failing enumeration
ACPI / hotplug: Fix PCI host bridge hot removal
ACPI / hotplug: Fix acpi_bus_get_device() return value check
cpufreq: governor: Remove fossil comment in the cpufreq_governor_dbs()
ACPI / video: clean up DMI table for initial black screen problem
ACPI / EC: Ensure lock is acquired before accessing ec struct members
PM / Hibernate: Do not crash kernel in free_basic_memory_bitmaps()
ACPI / AC: Remove struct acpi_device pointer from struct acpi_ac
spi: Use stable dev_name for ACPI enumerated SPI slaves
i2c: Use stable dev_name for ACPI enumerated I2C slaves
ACPI: Provide acpi_dev_name accessor for struct acpi_device device name
ACPI / bind: Use (put|get)_device() on ACPI device objects too
ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
cpufreq: OMAP: Fix compilation error 'r & ret undeclared'
PM / Runtime: Fix error path for prepare
PM / Runtime: Update documentation around probe|remove|suspend
cpufreq: conservative: set requested_freq to policy max when it is over policy max
...
