This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.

AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:

1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
   in low power state is enabled.

Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.

Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:

1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
   make them cleaner;
2. AMD chipset information will be probed only once and then stored.
   Currently they're probed during every OHCI/EHCI initialization, move
   the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
   code, every host controller enable/disable PLL only according to
   its own status, and may enable PLL while there is still isoc transfer on
   other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Make sure we are running on a MX35 processor.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently, for ISO and INT, a protocol driver must chose the value for
wMaxPacketSize arbitrarily. The value may be too low, resulting in lesser
than efficient operation or high enough to not work with all UDC drivers.

Take un-initialized wMaxPacketSize as a hint to provide maximum
possible packetsize for the selected endpoint. The protocol may
then choose a value not bigger than that.
Signed-off-by: NJassi Brar <jassi.brar@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Added mct_u232_ioctl (implements TIOCMIWAIT command),
mct_u232_get_icount (implements TIOCGICOUNT command) and
mct_u232_msr_to_icount functions. MCT U232 P9 is one of a few usb to
serail adapters which converts USB +/-5v voltage levels to COM +/-15
voltages. So it can also power COM interfaced devices. This makes it
very usable for legacy COM interfaced data-acquisition hardware. I
tested new implementation with AWARE Electronics RM-60 radiation meter,
which sends pulse via RNG COM line whenever new particle is registered.
Signed-off-by: NVadim Tsozik <tsozik@yahoo.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB2.0 device controller driver for Faraday fubs300
Signed-off-by: NYuan-Hsin Chen <yhchen@faraday-tech.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add a set of new tests similar to the existing ones but using
transfer buffers at an "odd" address [ie offset of +1 from
the buffer obtained by kmalloc() or usb_alloc_coherent()]

The new tests are:
#17 : bulk out (like #1) using kmalloc and DMA mapping by USB core.
#18 : bulk in (like #2) using kmalloc and DMA mapping by USB core.
#19 : bulk out (like #1) using usb_alloc_coherent()
#20 : bulk in (like #2) using usb_alloc_coherent()
#21 : control write (like #14)
#22 : isochonous out (like #15)
#23 : isochonous in (like #16)
Signed-off-by: NMartin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ums_realtek is used to support the power-saving function
for Realtek RTS51xx USB card readers.
Signed-off-by: Nwwang <wei_wang@realsil.com.cn>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The 2232H high speed baud rates also support fractional baud
rate divisors, but when the performing the divisions before
the multiplication, the fractional bits are lost.
Signed-off-by: NDaniel Glöckner <dg@emlix.com>
Acked-by: NMark Adamson <mark.adamson@ftdichip.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

With cmwq, there's no reason to use separate workqueues.  Drop
uea_softc->work_q and use system_wq instead.  The used work item is
sync flushed on driver detach.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NFerenc Wagner <wferi@niif.hu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Change a typo from "desciptor" to "descriptor".
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixing all coding style issues in buffer.c
Signed-off-by: NTobias Ollmann <tobias.ollmann@gmx.at>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This converts error codes specific to USB to generic error codes
that can be returned to user space. Tests showed that it is so small
that it is better inlined.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix error test in fan_{read,write}_reg()
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

It turns out that some device drivers map pages from the ACPI NVS region
during resume using ioremap(), which conflicts with ioremap_cache() used
for mapping those pages by the NVS save/restore code in nvs.c.

Make the NVS pages mapped by the code in nvs.c be unmapped before device
drivers' resume routines run.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit ca9b600b ("ACPI / PM: Make suspend_nvs_save() use
acpi_os_map_memory()") attempted to prevent the code in osl.c and nvs.c
from using different ioremap() variants by making the latter use
acpi_os_map_memory() for mapping the NVS pages.  However, that also
requires acpi_os_unmap_memory() to be used for unmapping them, which
causes synchronize_rcu() to be executed many times in a row
unnecessarily and introduces substantial delays during resume on some
systems.

Instead of using acpi_os_map_memory() for mapping the NVS pages in nvs.c
introduce acpi_os_ioremap() calling ioremap_cache() and make the code in
both osl.c and nvs.c use it.
Reported-by: NJeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix collision with kernel-supplied #define:

  drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined
  arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definition
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Replicate changes made to drivers/leds/ledtrig-backlight.c.

Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.

This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel.  A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).

Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

During system suspend, the "wait for ring buffer to empty" loop would
always time out after three seconds, because the faster cached ring
buffer head read would always return zero.  Force the slow-and-careful
PIO read on all but the first iterations of the loop to fix it.

This also removes the unused (and useless) 'actual_head' variable that
tried to approximate doing this, but did it incorrectly.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

thanks to Clemens' and Maxim's fixes to firewire-ohci and -net in the
last two kernel releases.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This makes it possible to resume communication with a node that dropped
off the bus for a brief period.  Otherwise communication will only be
possible after ARP cache entry timeouts.
Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (rebased)

Regression since commit 10389536, "firewire: core: check for 1394a
compliant IRM, fix inaccessibility of Sony camcorder":

The camcorder Canon MV5i generates lots of bus resets when asynchronous
requests are sent to it (e.g. Config ROM read requests or FCP Command
write requests) if the camcorder is not root node.  This causes drop-
outs in videos or makes the camcorder entirely inaccessible.
https://bugzilla.redhat.com/show_bug.cgi?id=633260

Fix this by allowing any Canon device, even if it is a pre-1394a IRM
like MV5i are, to remain root node (if it is at least Cycle Master
capable).  With the FireWire controller cards that I tested, MV5i always
becomes root node when plugged in and left to its own devices.

Reported-by: Ralf Lange
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org> # 2.6.32.y and newer

This partially reverts commit da8aeb92
("ACPI / Battery: Update information on info notification and resume"),
which causes a hang on resume on at least some machines.

This bug was bisected on an ASUS EeePC 901, which hangs at resume time
if we do that "acpi_battery_refresh(battery)" in the battery resume
function.

Rafael suspects we'll still need to refresh the sysfs files upon resume,
but that that can be done from a PM notifier (that will run after
thawing user space).
Bisected-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Len Brown <len.brown@intel.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We sometimes need to map between the virtio device and
the given pci device. One such use is OS installer that
gets the boot pci device from BIOS and needs to
find the relevant block device. Since it can't,
installation fails.

Instead of creating a top-level devices/virtio-pci
directory, create each device under the corresponding
pci device node.  Symlinks to all virtio-pci
devices can be found under the pci driver link in
bus/pci/drivers/virtio-pci/devices, and all virtio
devices under drivers/bus/virtio/devices.
Signed-off-by: NMilton Miller <miltonm@bga.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NGleb Natapov <gleb@redhat.com>
Tested-by: N"Daniel P. Berrange" <berrange@redhat.com>
Cc: stable@kernel.org

arch/x86/lguest/boot.c: In function ‘lguest_init_IRQ’:
arch/x86/lguest/boot.c:824: error: macro "__this_cpu_write" requires 2 arguments, but only 1 given
arch/x86/lguest/boot.c:824: error: ‘__this_cpu_write’ undeclared (first use in this function)
arch/x86/lguest/boot.c:824: error: (Each undeclared identifier is reported only once
arch/x86/lguest/boot.c:824: error: for each function it appears in.)

drivers/lguest/x86/core.c: In function ‘copy_in_guest_info’:
drivers/lguest/x86/core.c:94: error: lvalue required as left operand of assignment
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Use this_cpu_ops in a couple of places in lguest.
Signed-off-by: NChristoph Lameter <cl@linux.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

When the lirc drivers were converted over to using memdup_user, I
mistakenly also removed corresponding calls to kfree. Add those back. I
also screwed up on the allocation error check in lirc_serial, using if
(PTR_ERR()) instead of if (IS_ERR()), which broke transmit.
Reported-by: NJiri Fojtasek <jiri.fojtasek@hlohovec.net>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The current hdpvr code kmalloc's a new buffer for every i2c read and
write. Rather than do that, lets allocate a buffer in the driver's
device struct and just use that every time.

The size I've chosen for the buffer is the maximum size I could
ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit
of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up
to 128).

Note that this might also remedy user reports of very sluggish behavior
of IR receive with hdpvr hardware.

v2: make sure (len <= (dev->i2c_buf)) [Jean Delvare]
Reported-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.

First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.

Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.

[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixes an egregious bug in mceusb driver, where the receiver was being
put into idle mode far sooner than it should have, thanks to storing a
timeout value that in us where it should be ns. Basically, the receiver
kept going into idle mode before a trailing space had been fully
received, which was causing problems for some protocols, most notably
manifesting as lirc userspace never receiving a trailing space for any
rc5 signals.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix a bug in v4l2_device_unregister where the sd pointer can be dereferenced
after it was freed.

Normally the i2c adapter is removed before this function is called. Removing
the adapter will also unregister all subdevs on that adapter, so generally
v4l2_device_unregister has nothing to do. However, in the case of a platform
i2c bus that bus is generally not freed.

In that case, after freeing the i2c subdevice the code will fall into the
second block when it tests if the subdev is a SPI device. But by that time
the subdev is already freed and the kernel oopses.

The fix is trivial: continue with the loop after freeing the i2c or spi
subdevice.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Reported-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Zeroing video_device.dev causes a memory leak if video_set_drvdata
was called before video_register_device was called. video_set_drvdata
calls dev_set_drvdata which allocates video_device.dev.p.

memsetting this will prevent freeing of that memory.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

After a detach zero the whole device state to ensure a clean slate
on the next attach.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

v4l2_queryctrl sets the step value based on the control type. That would
be fine if it used the control type stored in the V4L2 kernel control
object, not the one stored in the userspace ioctl structure that has
just been memset to 0. Fix this.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When queryctrl is called with a V4L2_CID_PRIVATE_BASE control ID, then
currently it is replaced by the real internal ID. This is not according to
the spec so keep the V4L2_CID_PRIVATE_BASE ID in this case.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

VIDIOC_S_CTRL did not check against read-only controls. Even worse, for
controls of type CTRL_CLASS it would cause a kernel oops since those controls
do not have a s_ctrl op.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.

Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Acked-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts a portion of commit

	44243fc2

A commit for which I errantly recommended that defaults for I2C address
0x71 not be set by ir-kbd-i2c.c

The pvrusb2 and bttv drivers currently rely on ir-kbd-i2c setting
defaults for that address.  Until I can get those bridge drivers fixed
to properly send IR_i2c_init_data for boards with Zilog Z8 chips,
just add back the default settings for I2C address 0x71.
Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>