HID: usbkbd: fix inconsistent debugging output

It looks like this typo was introduced by a mistake in a copy-and-paste in
commit ddbe32491951.

Signed-off-by: Adam Cozzette <acozzette@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Rename rumble_* functions/variables to state_*

The commands used to modify the rumble motor state also modifies the LEDs at
the same time. The functionality used to modify this state in the driver has to
be shared between the rumble and LED part. It is therefore better to replace
the "rumble" part of the names with "state".

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Use BIT(x) macro to define quirks constants

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Rename buzz_* functions to sony_led_*

More controllers managed by the hid-sony module have 4 LEDs. These can share
most of the functionality provided by the buzz functions.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Move LED data to the main structure

It is not necessary to keep the LED information in an extra struct which is
only used by the Buzz device. It can also be used by other devices.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: sony: Add LED support for Sixaxis/Dualshock3 USB

The PS3 Sixaxis controller has 4 LEDs which can be controlled using the same
command as the rumble functionality. It seems not to be possible to only change
the LED without modifying the rumble motor state. Thus both have to be stored
on the host and retransmitted when either the LED or rumble state is changed.

Third party controllers may not support to disable all LEDs at once. These
controllers automatically switch to blinking of all LEDs when no LED is active
anymore.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Tested-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
PCI: Clear NumVFs when disabling SR-IOV in sriov_init()

When SR-IOV is disabled (VF Enable is cleared), NumVFs is not very useful,
so this patch clears it out to prevent confusing lspci output like that
below.  We already clear NumVFs in sriov_disable(), and this does the same
when we disable SR-IOV as part of parsing the SR-IOV capability.

  $ lspci -vvv -s 13:00.0
  13:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
      Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
          IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy+
          Initial VFs: 64, Total VFs: 64, Number of VFs: 64, ...

[bhelgaas: changelog]
Signed-off-by: ethan.zhao <ethan.kernel@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
HID: i2c-hid: disable interrupt on suspend

When an I2C HID device is powered of during system sleep, as a result of
removing its power resources (by the ACPI core) the interrupt line might go
low as well. This results inadvertent interrupt and wakes the system from
sleep immediately.

To prevent this we disable the device interrupt in the drivers suspend
method and enable it on resume. The device can still wake the system up if
it is wake capable (this also means that not all of its power will be
removed to keep the interrupt line high).

Reported-by: Jerome Blin <jerome.blin@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
PCI: mvebu: Drop writes to bridge Secondary Status register

There are no writable bits in the secondary status register, only RO and
RW1C (write-1-to-clear) bits.  The driver never sets any of the RW1C bits,
so the status register should always be 0, just remove the set from the
write path.

Someday the RW1C bits should be copied/cleared directly from registers in
the HW.

[bhelgaas: changelog tweaks]
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
PCI: mvebu: Obey bridge PCI_COMMAND_MEM and PCI_COMMAND_IO bits

When PCI_COMMAND_MEMORY/PCI_COMMAND_IO are cleared, the bridge should not
allocate windows or even look at the window limit/base registers.

Otherwise we may set up bogus windows while the PCI core code performs
discovery.  The core will leave PCI_COMMAND_IO cleared if it doesn't need
an IO window.

Have mvebu_pcie_handle_*_change respect the bits, and call the change
function whenever the bits changes.

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
PCI: mvebu: Support a bridge with no IO port window

Make pcie-io-aperture and the IO port MBUS ID in ranges optional.  If not
provided the bridge reports to Linux that IO space mapping is not supported
and refuses to configure an IO MBUS window.

This allows both complete disable (do not specify pcie-io-aperture) and
per-port disable (do not specify a IO target ranges entry for the port).

Most PCIe devices these days do not require IO support to function, so
having an option to disable it in the driver is useful.

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
KVM: Change maintainer email address

My Red Hat email address will stop working soon. Updated if with other
address.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
KVM: s390: Removed SIE_INTERCEPT_UCONTROL

The SIE_INTERCEPT_UCONTROL can be removed by moving the related code
from kvm_arch_vcpu_ioctl_run() to vcpu_post_run().

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: Removed VIRTIODESCSPACE

VIRTIODESCSPACE is completely unused nowadays and thus can be removed
without any problems.

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: Fix access to CR6 in TPI handler

The TPI handler currently uses vcpu->run->s.regs.crs[6] to get the current
value of CR6. I think this is wrong, because vcpu->run->s.regs.crs is
only updated when kvm_arch_vcpu_ioctl_run() drops back to userspace.
So let's change the TPI handler to use vcpu->arch.sie_block->gcr[6] instead.

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: Do not set CC3 for EQBS and SQBS

The EQBS and SQBS instructions do not set CC3 for invalid channels, but
should throw an operation exception instead when not available. Thus they
should not be handled by the handle_io_inst() wrapper but drop to userspace
instead (which will then inject the operation exception).

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: Always store status during SIGP STOP_AND_STORE_STATUS

The SIGP order STOP_AND_STORE_STATUS is defined to stop a CPU and store
its status. However, we only stored the status if the CPU was still
running, so make sure that the status is now also stored if the CPU was
already stopped. This fixes the problem that the CPU information was
not stored correctly in kdump files, rendering them unreadable.

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: Fix clock comparator field for STORE STATUS

Only the most 7 significant bytes of the clock comparator must be
saved to the status area, and the byte at offset 304 has to be zero.

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: fix diagnose code extraction

The diagnose code to be used is the contents of the base register (if not
zero), plus the displacement. The current code ignores the base register
contents. So let's fix that...

Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
KVM: s390: Add SIGP store-status-at-address order

The STORE STATUS AT ADDRESS order of SIGP was still missing.
Now it is supported, using the common kvm_s390_store_status()
function.

Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>