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: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NMatthew 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: NRashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: NMatthew 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: NRashika Kheria <rashika.kheria@gmail.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Given that Precision mobile workstations are top of the line Dell products,
I expect the functionality of rfkill there to be as reliable as on Latitudes
so whitelist Precisions.

https://bugzilla.kernel.org/show_bug.cgi?id=65731Reported-by: NCalum Lind <calumlind@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NDavid Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: NMatthew 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: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMatthew 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: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMatthew 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: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMatthew 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: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Reduce code size and simplify error path.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Fix to return error code instead always return 0 from function
dell_send_intensity().
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Follow-up to commit 294d31e8 ("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: NKarol Babioch <karol@babioch.de>
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NPrarit Bhargava <prarit@redhat.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: NMatthew 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: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NDavid Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Handle error conditions in intel_scu_ipc_command() and
pwr_reg_rdwr().
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NDavid Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Enabled ipc support for penwell, clovertrail & tangier platforms.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Since the same ipc driver can be used by many platforms, using
macros for defining ipc_base and i2c_base addresses is not
a scalable approach. So added a platform data structure to pass
this information.
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: NAlan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: NMatthew 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: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMatthew 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: NOlof Johansson <olof@lixom.net>
Signed-off-by: NMatthew 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: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NMatthew 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: NJoe Perches <joe@perches.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Signed-off-by: NStephen Gildea <stepheng+linux@gildea.com>
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NMatthew 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: NMattia Dongili <malattia@linux.it>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Some time is needed for the BIOS to do its work, but 250ms should be plenty.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew 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 a6c2390c.

Conflicts:
	drivers/platform/x86/dell-laptop.c
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.

[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since DEVICE_ACPI_HANDLE() is now literally identical to
ACPI_HANDLE(), replace it with the latter everywhere and drop its
definition from include/acpi.h.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix build error in asus_wmi.c when ASUS_WMI=y and ACPI_VIDEO=m
by preventing that combination.

  drivers/built-in.o: In function `asus_wmi_probe':
  asus-wmi.c:(.text+0x65ddb4): undefined reference to `acpi_video_unregister'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Do not touch keyboard backlight unless explicitly passed a module
parameter.  In this way we won't make wrong assumptions about what are
good default values since they actually are different from model to
model.

The only side effect is that we won't know what is the current value
until set via the sysfs attributes.
Signed-off-by: NMattia Dongili <malattia@linux.it>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>