This patch finishes off adding full support for the TiVo Slide remote,
which is a mostly pure HID device from the perspective of the kernel.
There are a few mappings that use a vendor-specific usage page, and a
few keys in the consumer usage page that I think make sense to remap
slightly, to better fit their key labels' intended use. Doing this in a
stand-alone hid-tivo.c makes the modifications only matter for this
specific device.

What's actually connected to the computer is a Broadcom-made usb dongle,
which has an embedded hub, bluetooth adapter, mouse and keyboard
devices. You pair with the dongle, then the remote sends data that its
converted into HID on the keyboard interface (the mouse interface
doesn't do anything interesting, so far as I can tell).

lsusb for this device:
Bus 004 Device 005: ID 0a5c:2190 Broadcom Corp.
Bus 004 Device 004: ID 0a5c:4503 Broadcom Corp.
Bus 004 Device 003: ID 150a:1201
Bus 004 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

Speaking of the keyboard interface, the remote actually does contain a
keyboard as well. The top slides away, revealing a reasonably functional
qwerty keyboard (not unlike many slide cell phones), thus the product
name.

CC: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add support for the camera key. The hotkey for
Asus S.H.E(Super Hybrid Engine) mode is mapped to KEY_KEY_PROG1
just for notifying the userspace.
Signed-off-by: NKeng-Yu Lin <kengyu@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Asus All-In-One PC has a wireless keyboard with wifi toggle,
brightness up, brightness down and display off hotkeys.

This patch adds suppoort for these hotkeys.
Signed-off-by: NKeng-Yu Lin <kengyu@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

More drivers where net_device_ops should be const.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ethtool_ops table of function pointers should be const.
Fix all the usb network drivers.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When a PCI device is transferred to another domain and it is still
in usage (from the internal perspective), mention which other
domain is using it to aid in debugging.

[v2: Truncate the verbose message per Jan Beulich suggestion]
[v3: Suggestions from Ian Campbell on the wording]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: NJan Beulich <jbeulich@suse.com>

The driver uses __napi_complete and napi_gro_receive. Without it, the
driver hits the BUG_ON(n->gro_list) assertion hard in __napi_complete.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Tested-by: NMarin Glibic <zhilla2@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

* if you do dput() of root dentry, do *not* follow that with iput() of root
inode.
* while we are at it, don't do that dput() at all - you are leaving the pointer
in ->s_root and your ->kill_sb() will be very unhappy with that.  It will do
proper dput(), though, so the easiest way is to leave that to it entirely.
* freeing ->s_fs_info is also best left to ->kill_sb() (which will do it
anyway), especially since we leave the pointer in place.
* that xchg() in ->kill_sb() is not a bug per se, but it's a plain and simple
masturbation with fewer excuses than Onan had...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The AHCI controller found in the STA2X11 chip uses BAR number 0
instead of 5. Also, the chip's fixup code sets a special DMA mask
for all of its PCI functions, and the mask must be preserved here.
Signed-off-by: NAlessandro Rubini <rubini@gnudd.com>
Acked-by: NGiancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The author of this driver clearly wasn't familiar with the BMIDE specification
(also known as SFF-8038i) when he implemented the bmdma_status() method: first,
the interrupt bit of the BMIDE status register corresponds to nothing else but
INTRQ signal (ATAPI_DEV_INT here); second, the error bit is only set if the
controller encounters issue doing the bus master transfers, not on the IDE DMA
burst termination interrupts like here (moreover, setting the error bit doesn't
cause an interrupt).  We now need to disable all those unused interrupts...

(The only thing I couldn't figure out is how to flush the FIFO to memory once
the interrupt happens as required by the mentioned spec.)
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The ata port is brought back to full power state during system resume.
So its runtime PM status will have to be updated to reflect
the actual post-system sleep status.

This also fixes below warning during system suspend/resume.

WARNING: at /work/linux/drivers/ata/libata-eh.c:4034
ata_scsi_port_error_handler+0x89/0x557()

4034         WARN_ON(!(ap->pflags & ATA_PFLAG_SUSPENDED));
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

[Patch description from Alan Stern]

If a child device was runtime-suspended when a system suspend began,
then there will be nothing to prevent its parent from
runtime-suspending as soon as it is woken up during the system resume.
Then when the time comes to resume the child, the resume will fail
because the parent is already back at low power.

On the other hand, there are some devices which should remain at low
power across an entire suspend-resume cycle.  The details depend on the
device and the platform.

This suggests that the PM core is not the right place to solve the
problem. One possible solution is for the subsystem or device driver
to call pm_runtime_get_sync(dev->parent) at the start of the
system-resume procedure and pm_runtime_put_sync(dev->parent) at the
end.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Add platform hooks for custom suspend() and resume() functions. The
generic suspend/resume code in drivers/ata/ahci_platform.c is adapted
from the PCI version in drivers/ata/ahci.c.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Commit b3a70601 (libata: Add a
drivers/ide style DMA disable) neglected to remove the line in
ata_do_set_mode() it has obviously made useless/duplicated.  Do this
now, and make a line added back then wrapped properly...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

CONFIG_OF_IRQ is not available on some platforms and using of_irq_*
breaks the build. Since resources are already populated in the platform
device, get the irq from there instead.
Reported-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This patch converts the drivers in drivers/ata/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.

Cc: Viresh Kumar <viresh.kumar@st.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Sylvain Munaut <tnt@246tNt.com>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Florian Fainelli <florian@openwrt.org>
Cc: Mark Miesfeld <mmiesfeld@amcc.com>
Cc: Ashish Kalra <ashish.kalra@freescale.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

* Fix cable detection to also account for the slave device cable bit.

* Disable UDMA when programming MWDMA in cs5536_set_dmamode().

* Don't change UDMA settings in cs5536_set_piomode().

* Add cs5536_program_dtc() helper.

* Cleanup and uninline cs5536_[read,write]() methods.

Cc: Martin K. Petersen <mkp@mkp.net>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

atapi_pio_bytes() uses bare numbers for the ATAPI interrupt reason bits despite
these are #define'd in <linux/ata.h>.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Add ata port runtime suspend/resume/idle callbacks.
Set ->eh_noresume to skip the runtime PM calls on scsi host
in the error handler to avoid dead lock.
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Change ata_host_request_pm to ata_port_request_pm which performs
port suspend/resume.

Add ata port type driver which implements port PM callbacks.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

sd_shutdown is called during reboot/poweroff.
It may fail if parent device, for example, ata port, was runtime suspended.

Fix it by checking runtime PM status of sd.
Exit immediately if sd was runtime suspended already.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The only high-level SCSI driver that currently implements runtime PM is
sd, and sd treats runtime suspend exactly the same as the SUSPEND and
HIBERNATE stages of system sleep, but not the same as the FREEZE stage.

Therefore, when entering the SUSPEND or HIBERNATE stages of system
sleep, we can skip the callback to the driver if the device is already
in runtime suspend.  When entering the FREEZE stage, however, we should
first issue a runtime resume.  The overhead of doing this is
negligible, because a suspended drive would be spun up during the THAW
stage of hibernation anyway.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

With previous change, now the ata port runtime suspend will happen as:

disk suspend --> scsi target suspend --> scsi host suspend --> ata port
suspend

ata port(parent device) suspend need to schedule scsi EH which will resume
scsi host(child device). Then the child device resume will in turn make
parent device resume first. This is kind of recursive.

This patch adds a new flag Scsi_Host::eh_noresume.
ata port will set this flag to skip the runtime PM calls on scsi host.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Currently, the device tree of ata port and scsi host looks as below,

        /sys/devices/pci0000:00/0000:00:1f.2    (ahci controller)
        |-- ata1                                (ata port)
        |-- host0                               (scsi host)
           |-- target0:0:0                      (scsi target)
               |-- 0:0:0:0                      (disk)

This patch makes ata port as parent device of scsi host, then it becomes

        /sys/devices/pci0000:00/0000:00:1f.2    (ahci controller)
        |-- ata1                                (ata port)
            |-- host0                           (scsi host)
                |-- target0:0:0                 (scsi target)
                    |-- 0:0:0:0                 (disk)

With this change, the ata port runtime PM is easier.
For example, the ata port runtime suspend will happen as,

disk suspend --> scsi target suspend --> scsi host suspend --> ata port
suspend.
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This is another attempt at fixing the same problem that 270dac35
(libata: ahci_start_engine compliant to AHCI spec) tried to solve.
Unfortunately, 270dac35 created regressions for a lot more common
controllers and got reverted.

This specific AHCI IP block becomes a brick if the DMA engine is
started while DRQ is set.  It is not possible to avoid the condition
completely but the most common occurrence is caused by spurious use of
ahci_start_engine() from ahci_start_port() during init sequence.

DMA engine is started after both soft and hard resets and
ahci_start_port() is always followed by resets, so there is no reason
to start DMA engine from ahci_start_port().

This patch removes ahci_start_engine() invocation from
ahci_start_port().  This change makes failure path of
ahci_port_suspend() leave engine stopped without following resets.
This is resolved by replacing ahci_start_port() call with
ata_port_freeze() which forces resets afterwards, which is the better
behavior anyway.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NBrian Norris <computersforpeace@gmail.com>
Reported-by: NJian Peng <jipeng2005@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :

We allocate memory:

	...
	struct user_sgmap* usg;
	usg = kmalloc(actual_fibsize - sizeof(struct aac_srb)
	  + sizeof(struct sgmap), GFP_KERNEL);

and then neglect to free it:

	...
	for (i = 0; i < usg->count; i++) {
		u64 addr;
		void* p;
		if (usg->sg[i].count >
		    ((dev->adapter_info.options &
		     AAC_OPT_NEW_COMM) ?
		      (dev->scsi_host_ptr->max_sectors << 9) :
		      65536)) {
			rcode = -EINVAL;
			goto cleanup;
	... this 'goto' makes 'usg' go out of scope and leak the memory we
	    allocated.

Other exits properly kfree(usg), it's just here it is neglected.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Apple keyboards require a FEATURE report to query the battery state,
even though they list as an input.  Without this, it returns an error.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

hidinput_get_battery_property() now directly polls the device for the
current battery strength, so there's no need for battery_val, or the
code to set it on the input event path.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

It just isn't a battery which is powering the computer.  upower needs
a more nuanced understanding of this.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Some devices seem to report batteries as FEATUREs, others as INPUTs.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Some devices always report percentage, despite having 0/255 as their
min/max, so add a quirk for them.
Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>

I've sent an email earlier asking for help with a GetFeature code, and now I
have a second patch on top of Jeremy's to provide the battery functionality
for devices that support reporting it.

If I understood correctly when talking to Jeremy he said his device
never actually reported the status as an input event (sorry if I didn't
understand it correctly), and after reading HID specs I believe it's
really because it was meant to be probed, I have an Apple Keyboard and
Magic Trackpad both bluetooth batteries operated, so using PacketLogger
I saw that Mac OSX always ask the battery status using the so called
GetFeature.

What my patch does is basically:
- store the report id that matches the battery_strength
- setup the battery if 0x6.0x20 is found, even if that is reported as a feature
  (as it was meant to be but only the MagicTrackpad does)
- when upower or someone access /sys/class/power_supply/hid-*/capacity it
  will probe the device and return it's status.

It works great for both devices, but I have two concerns:
- the report_features function has a duplicated code
- it would be nice if it was possible for specific drivers to provide their own
  probe as there might be some strange devices... (but maybe it's
already possible)

I've talked to the upower dev and he fixed it to be able to show the
right percentage.

Here how the uevent file (in /sys/class/power_supply/hid-*/) looks like:
POWER_SUPPLY_NAME=hid-00:22:41:D9:18:E7-battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_CAPACITY=66
POWER_SUPPLY_MODEL_NAME=MacAdmin’s keyboard
POWER_SUPPLY_STATUS=Discharging

POWER_SUPPLY_NAME=hid-70:CD:60:F5:FF:3F-battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_CAPACITY=62
POWER_SUPPLY_MODEL_NAME=nexx’s Trackpad
POWER_SUPPLY_STATUS=Discharging
Signed-off-by: NDaniel Nicoletti <dantti12@gmail.com>

The full warning is:
"pciback 0000:05:00.0: device has been assigned to 2 domain! Over-writting the ownership, but beware."

which is correct - the previous domain that was using the device
forgot to unregister the ownership. This patch fixes this by
calling the unregister ownership function when the PCI device is
relinquished from the guest domain.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

operation instead of doing it per guest creation/disconnection. Without
this we could have potentially unloaded the vf driver from the
xen pciback control even if the driver was binded to the xen-pciback.
This will hold on to it until the user "unbind"s the PCI device using
SysFS.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The energy detect enable/disable code in the driver uses some
register defines in this header unconditionally, so guarding
the smscphy.h header include with CONFIG_SMSC_PHY leads to
build failures in some configurations.
Reported-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>