Bug has been fixed for some time in the outofstaging tree, but
didn't propogate back to here.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Free channels in case read fails with error.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch type casts the switch control variable to 32 bits in order to
prevent a call __ucmpdi2 generated by some versions of gcc.

This fixes an undefined reference to `__ucmpdi2' when compiled for arch/blackfin
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It wasn't being used, and had a hacked-up export symbol table which
wasn't very nice either.
Reported-by: James Morris <jmorris@namei.org>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The m68k core irq code stopped honoring these flags during the irq
restructuring in 2006.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Following the move to put the driver into one file, comments were added to identify which source file each set of functions originated from.
These no longer made sense after functions were moved around to remove some forward declarations, so remove them.

A function comment was previously not moved along with its function, now they are reunited.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

FIXME: it should be possible to get rid of ET1310_PCI_L0L1LATENCY as well.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

pci_{save, restore}_state are balanced in .suspend and .resume.
They are not used anywhere else in the driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Wrong status code and unbalanced phy_connect.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

 Use kmemdup rather than duplicating its implementation

 The semantic patch that makes this change is available
 in scripts/coccinelle/api/memdup.cocci.

 More information about semantic patching is available at
 http://coccinelle.lip6.fr/Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It is unsafe to free buffers in line6_pcm_stop(), which is not allowed
to sleep, since urbs cannot be killed completely there and only
unlinked.  This means I/O may still be in progress and the URB
completion function still gets invoked.  This may result in memory
corruption when buffer_in is freed but I/O is still pending.

Additionally, line6_pcm_start() is not supposed to sleep so it should
not use kmalloc(GFP_KERNEL).

These issues can be resolved by performing buffer allocation/freeing in
the .hw_params/.hw_free callbacks instead.  The ALSA documentation also
recommends doing buffer allocation/freeing in these callbacks.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The POD HD300 isochronous endpoints have different max packet sizes for
read and write.  Using the read endpoint max packet size may be too
large for the write endpoint.  Instead we should use the minimum of both
endpoints to be sure the size is acceptable.

In theory we could decouple read and write packet sizes but the driver
currently uses a single size which I chose not to mess with since other
features like software monitoring may depend on a single packet size for
both endpoints.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The driver leaves MIDI processing up to userspace for the POD HD300
device.  Add a missing case statement to skip MIDI postprocessing in the
driver.  This change has no effect other than silencing a printk:

  line6usb driver bug: missing case in linux/drivers/staging/line6/midi.c:179
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The Pod HD device family uses new MIDI SysEx messages and therefore
cannot reuse the existing Pod code.  Instead of hardcoding Pod HD MIDI
messages into the driver, leave MIDI up to userspace.  This driver
simply presents MIDI and pcm ALSA devices.

This device is similar to the Pod except that it has 48 kHz audio and
does not respond to Pod SysEx messages.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If the first call to line6_midibuf_init() fails we'll leak a little
bit of memory. If the second call fails we'll leak a bit more. This
happens when we return from the function and the local variable
'line6midi' goes out of scope.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

MEI_CLIENTS_MAX is 255 and host_client_id is u8 therefore
for check to work we need to first assign the return value
of find_first_zero_bit to unsigned long variable

Fix warning

drivers/staging/mei/main.c: In function mei_open
drivers/staging/mei/main.c:260:2: warning: comparison is always false due to limited range of data type
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Misc device provides everything MEI needs for registration,
it doesn't required separate driver class.
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

wd_ops and wd_info structures are local to wd.c so mark them static

Cc: Oren Weil <oren.jer.weil@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It now clashes with upstream DRM which we don't want to block.

We don't want to delete this code just yet as we want to keep it for
comparison and reference when debugging, but soon it will be a removal
candidate as well
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: linux-next@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

* git://github.com/rustyrussell/linux:
  virtio-pci: make reset operation safer
  virtio-mmio: Correct the name of the guest features selector
  virtio: add HAS_IOMEM dependency to MMIO platform bus driver

virtio pci device reset actually just does an I/O
write, which in PCI is really posted, that is it
can complete on CPU before the device has received it.

Further, interrupts might have been pending on
another CPU, so device callback might get invoked after reset.

This conflicts with how drivers use reset, which is typically:
	reset
	unregister
a callback running after reset completed can race with
unregister, potentially leading to use after free bugs.

Fix by flushing out the write, and flushing pending interrupts.

This assumes that device is never reset from
its vq/config callbacks, or in parallel with being
added/removed, document this assumption.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Guest features selector spelling mistake.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Fix this compile error on s390:

  CC [M]  drivers/virtio/virtio_mmio.o
drivers/virtio/virtio_mmio.c: In function 'vm_get_features':
drivers/virtio/virtio_mmio.c:107:2: error: implicit declaration of function 'writel'

Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

* 'upstream-linus' of git://github.com/jgarzik/libata-dev:
  libata: fix build without BMDMA
  [libata] ahci_platform: fix DT probing

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci:
  PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs
  PCI: pciehp: wait 100 ms after Link Training check
  PCI: pciehp: wait 1000 ms before Link Training check
  PCI: pciehp: Retrieve link speed after link is trained
  PCI: Let PCI_PRI depend on PCI
  PCI: Fix compile errors with PCI_ATS and !PCI_IOV
  PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: Extend array bounds for all filename chars
  eCryptfs: Flush file in vma close
  eCryptfs: Prevent file create race condition

From mhalcrow's original commit message:

    Characters with ASCII values greater than the size of
    filename_rev_map[] are valid filename characters.
    ecryptfs_decode_from_filename() will access kernel memory beyond
    that array, and ecryptfs_parse_tag_70_packet() will then decrypt
    those characters. The attacker, using the FNEK of the crafted file,
    can then re-encrypt the characters to reveal the kernel memory past
    the end of the filename_rev_map[] array. I expect low security
    impact since this array is statically allocated in the text area,
    and the amount of memory past the array that is accessible is
    limited by the largest possible ASCII filename character.

This patch solves the issue reported by mhalcrow but with an
implementation suggested by Linus to simply extend the length of
filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
0x00, which is how invalid characters less than 0x7A were previously
being handled.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Michael Halcrow <mhalcrow@google.com>
Cc: stable@kernel.org

Dirty pages weren't being written back when an mmap'ed eCryptfs file was
closed before the mapping was unmapped. Since f_ops->flush() is not
called by the munmap() path, the lower file was simply being released.
This patch flushes the eCryptfs file in the vm_ops->close() path.

https://launchpad.net/bugs/870326Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Cc: stable@kernel.org [2.6.39+]

The file creation path prematurely called d_instantiate() and
unlock_new_inode() before the eCryptfs inode info was fully
allocated and initialized and before the eCryptfs metadata was written
to the lower file.

This could result in race conditions in subsequent file and inode
operations leading to unexpected error conditions or a null pointer
dereference while attempting to use the unallocated memory.

https://launchpad.net/bugs/813146Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Cc: stable@kernel.org

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest:
  ktest: Check parent options for iterated tests

* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
  i2c: Make i2cdev_notifier_call static
  i2c: Delete ANY_I2C_BUS
  i2c: Fix device name for 10-bit slave address
  i2c-algo-bit: Generate correct i2c address sequence for 10-bit target

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: TPS65910: Fix VDD1/2 voltage selector count

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (31 commits)
  drm: integer overflow in drm_mode_dirtyfb_ioctl()
  drivers/gpu/vga/vgaarb.c: add missing kfree
  drm/radeon/kms/atom: unify i2c gpio table handling
  drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real
  ttm: Don't return the bo reserved on error path
  drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS
  drm/i915: Fix inconsistent backlight level during disabled
  drm, i915: Fix memory leak in i915_gem_busy_ioctl().
  drm/i915: Use DPCD value for max DP lanes.
  drm/i915: Initiate DP link training only on the lanes we'll be using
  drm/i915: Remove trailing white space
  drm/i915: Try harder during dp pattern 1 link training
  drm/i915: Make DP prepare/commit consistent with DP dpms
  drm/i915: Let panel power sequencing hardware do its job
  drm/i915: Treat PCH eDP like DP in most places
  drm/i915: Remove link_status field from intel_dp structure
  drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control
  drm/i915: Module parameters using '-1' as default must be signed type
  drm/i915: Turn on another required clock gating bit on gen6.
  drm/i915: Turn on a required 3D clock gating bit on Sandybridge.
  ...

Count of selector voltage is required for regulator_set_voltage
to work via set_voltage_sel. VDD1/2 currently have it as zero,
so regulator_set_voltage won't work for VDD1/2.
Update count (n_voltages) for VDD1/2.

Output Voltage = (step value * 12.5 mV + 562.5 mV) * gain

With above expr, number of voltages that can be selected is
step value count * gain count

constant for gain count will be called VDD1_2_NUM_VOLT_COARSE

existing constant for step value count is VDD1_2_NUM_VOLTS,
use VDD1_2_NUM_VOLT_FINE instead to make clear that step value
is not the only component in deciding selectable voltage count
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

The function i2cdev_notifier_call is used only in i2c-dev file
making it static.
Also removes the following sparse warning

drivers/i2c/i2c-dev.c:582:5: warning: symbol 'i2cdev_notifier_call'
was not declared. Should it be static?
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

Last piece of code using ANY_I2C_BUS was deleted almost 2 years ago,
so ANY_I2C_BUS can go away as well.
Signed-off-by: Jean Delvare <khali@linux-fr.org>