extcon: max8997: Check the pointer of platform data to protect null pointer error

This patch check the pointer of platform data to protect
kernel panic when platform data is not used and code clean.

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
extcon: max77693: Fix bug of wrong pointer when platform data is not used

This patch fix wrong pointer of platform data. If each machine set
platform data for h/w path or delay time of workqueue, this driver
happen kernel panic related to null pointer.

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
extcon: max77693: Initialize register of MUIC device to bring up it without platform data

This patch set default value of MUIC register to bring up MUIC device.

If user don't set some initial value for MUIC device through platform data,
extcon-max77693 driver use 'default_init_data' to bring up base operation
of MAX77693 MUIC device.

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
mei: add mei_stop function to stop mei device

mei_stop calls mei_reset with disabling the interrupts.
It will have the same effect as the open code it replaces in the mei_remove.

The reset sequence on remove is required for the Lynx Point LP devices
to clean the reset state.

mei_stop is called from mei_pci_suspend and mei_remove functions

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mei: ME hardware reset needs to be synchronized

This fixes failure during initialization on Lynx Point LP devices.

ME driver needs to release the device from the reset
only after the FW has completed its flow and indicated
it by delivering an interrupt to the host.

This is the correct behavior for all the ME devices yet the
the previous versions are less susceptive to the implementation
that ignored FW reset completion indication.

We add mei_me_hw_reset_release function which is called
after reset from the interrupt thread or directly
from mei_reset during power down.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'extcon-3.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus

Chanwoo writes:

	extcon fixes for 3.9-rc3

	This is small fixes against 3.9-rc2.

	Fix to max77693 extcon driver:
	- Set default value of MUIC register to bring up it.
	  Fix to max8997 extcon driver:
	- Fix null pointer error duing probe when platform data
	  isn't used.
VMCI: Fix process-to-process DRGAMs.

When sending between processes, we always schedule a work item.  Our work info
struct has the message embedded in the middle, which means that we end up
overwriting subsequent fields when we copy the (variable-length) message into
it.  Move it to the end of the struct.

Acked-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Andy King <acking@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: atmel_serial_probe(): index of atmel_ports[] fix

Index of atmel_ports[ATMEL_MAX_UART] should be smaller
than ATMEL_MAX_UART.

Signed-off-by: Pawel Wieczorkiewicz <wpawel@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: 8250_pci: Add WCH CH352 quirk to avoid Xscale detection

The code in 8250.c for detecting ARM/XScale UARTs says:

  * Try writing and reading the UART_IER_UUE bit (b6).
  * If it works, this is probably one of the Xscale platform's
  * internal UARTs.

If the above passes, it then goes on to:

     * It's an Xscale.
     * We'll leave the UART_IER_UUE bit set to 1 (enabled).

However, the CH352 uses the UART_IER_UUE as the LOWPOWER function,
so it is readable and writable.  According to the datasheet:

    "LOWPOWER:When the bit is 1, close the internal benchmark
     clock of serial port to set into low-power status.

So it essentially gets mis-detected as Xscale, and gets
powered down in the process.  The device in question where
this was seen is listed by lspci as:

 Serial controller: Device 4348:3253 (rev 10) (prog-if 02 [16550])

Re-using the 353 quirk which just sets flags to fixed and type
to 16550 is suitable for fixing the 352 as well.

Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scm: Require CAP_SYS_ADMIN over the current pidns to spoof pids.

Don't allow spoofing pids over unix domain sockets in the corner
cases where a user has created a user namespace but has not yet
created a pid namespace.

Cc: stable@vger.kernel.org
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
staging: zcache: fix typo "64_BIT"

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sysfs: fix race between readdir and lseek

While readdir() is running, lseek() may set filp->f_pos as zero,
then may leave filp->private_data pointing to one sysfs_dirent
object without holding its reference counter, so the sysfs_dirent
object may be used after free in next readdir().

This patch holds inode->i_mutex to avoid the problem since
the lock is always held in readdir path.

Reported-by: Dave Jones <davej@redhat.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sysfs: handle failure path correctly for readdir()

In case of 'if (filp->f_pos ==  0 or 1)' of sysfs_readdir(),
the failure from filldir() isn't handled, and the reference counter
of the sysfs_dirent object pointed by filp->private_data will be
released without clearing filp->private_data, so use after free
bug will be triggered later.

This patch returns immeadiately under the situation for fixing the bug,
and it is reasonable to return from readdir() when filldir() fails.

Reported-by: Dave Jones <davej@redhat.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "crypto: talitos - add IPsec ESN support"

This reverts commit e763eb699be723fb41af818118068c6b3afdaf8d.

Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha))
(separate encryption and integrity algorithms) does not conform
to RFC4303.

ICV is generated by hashing the sequence
SPI, SeqNum-High, SeqNum-Low, IV, Payload
instead of
SPI, SeqNum-Low, IV, Payload, SeqNum-High.

Cc: <stable@vger.kernel.org> # 3.8, 3.7
Reported-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Revert "crypto: caam - add IPsec ESN support"

This reverts commit 891104ed008e8646c7860fe5bc70b0aac55dcc6c.

Current IPsec ESN implementation for authencesn(cbc(aes), hmac(sha))
(separate encryption and integrity algorithms) does not conform
to RFC4303.

ICV is generated by hashing the sequence
SPI, SeqNum-High, SeqNum-Low, IV, Payload
instead of
SPI, SeqNum-Low, IV, Payload, SeqNum-High.

Cc: <stable@vger.kernel.org> # 3.8, 3.7
Reported-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
omapfb: fix broken build on OMAP1

Fix the following build regression in 3.9-rc1 by including
<mach/hardware.h>:

drivers/video/omap/omapfb_main.c: In function 'set_fb_var':
drivers/video/omap/omapfb_main.c:505:3: error: implicit declaration of function 'cpu_is_omap15xx' [-Werror=implicit-function-declaration]

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts

This driver uses omap_dss_device that it gets from a board file through
SPI platfrom_data pointer to pass data from SPI to DSS portion of the
driver by using dev_set_drvdata(). However this trick no longer works,
as DSS core no longer uses omap_dss_device from a board file to create
the real device, so use a global pointer to accomplish this instead,
like other SPI panel drivers do.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapdss: features: fix supported outputs for OMAP4

The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:

- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
  output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
  yet, we require some muxing at the DSS level, and we also need to configure
  the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
  don't support that yet.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
cpufreq / intel_pstate: Add function to check that all MSRs are valid

Some VMs seem to try to implement some MSRs but not all the registers
the driver needs.  Check to make sure all the MSR that we need are
available. If any of the required MSRs are not available refuse to
load.

References: https://bugzilla.redhat.com/show_bug.cgi?id=922923
Reported-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq / intel_pstate: Fix calculation of current frequency

Use the correct pstate value to calculate the effective frequency.

References: https://bugzilla.redhat.com/show_bug.cgi?id=923942
Reported-by: Satish Balay <balay@fastmail.fm>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>