UPSTREAM: vfs: fix subtle use-after-free of pipe_inode_info

The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:

        spin_lock(&inode->i_lock);
        if (!--pipe->files) {
                inode->i_pipe = NULL;
                kill = 1;
        }
        spin_unlock(&inode->i_lock);
        __pipe_unlock(pipe);
        if (kill)
                free_pipe_info(pipe);

where the final freeing is done last.

HOWEVER.  The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".

This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.

Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.

Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early.  And since there were two users of this
pattern, create a helper function for it.

Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").

Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org   # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

BUG=None
TEST=rambi build

Change-Id: I6186b6f34a84e6cebaa9df8ffd9e53b7e4c37065
(cherry picked from commit b0d8d2292160bb63de1972361ebed100c64b5b37)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179170
Reviewed-by: Benson Leung <bleung@chromium.org>
BACKPORT: gpio: improve error path in gpiolib

At several places the gpiolib will proceed to handle a GPIO
descriptor even if it's ->chip member is NULL and no gpiochip
is associated.

Fix this by checking that both the descriptor cookie *and*
the chip pointer are valid.

Also bail out earlier with more specific diagnostic messages
on missing operations for setting as input/output or debounce.

ChangeLog v1->v2:
- Also return -EIO on gpiod_set_debounce() with missing
  operations in the vtable
- Fix indentations.

Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Frank Rowand <frank.rowand@sonymobile.com>
Cc: Tim Bird <tim.bird@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit be1a4b13089b1e18da83a549d49163ccad3c19ba)

BUG=chrome-os-partner:24314
TEST=manual: try to export invalid gpio 1 and see it report invalid
GPIO but not panic.

Change-Id: Ic717ba11a4d19be9264b2749798389044f67b903
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179122
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
CHROMIUM: PM / QoS: add min/max online cpus as PM QoS parameter

Adding min/max online cpus as PM QoS parameter

Based on work by:
Alex Frid <afrid@nvidia.com>
Gaurav Sarode <gsarode@nvidia.com>

BUG=None
TEST=tested on Dalmore and Venice2

Change-Id: I85593ae07861ea15aff588699a549518165ba043
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174695
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: watchdog: touch_nmi_watchdog should only touch local cpu not every one

This is a patch from Don Zickus. It's not been merged to the upstream yet.

I ran into a scenario where while one cpu was stuck and should have panic'd
because of the NMI watchdog, it didn't.  The reason was another cpu was spewing
stack dumps on to the console.  Upon investigation, I noticed that when writing
to the console and also when dumping the stack, the watchdog is touched.

This causes all the cpus to reset their NMI watchdog flags and the 'stuck' cpu
just spins forever.

This change causes the semantics of touch_nmi_watchdog to be changed slightly.
Previously, I accidentally changed the semantics and we noticed there was a
codepath in which touch_nmi_watchdog could be touched from a preemtible area.
That caused a BUG() to happen when CONFIG_DEBUG_PREEMPT was enabled.  I believe
it was the acpi code.

My attempt here re-introduces the change to have the touch_nmi_watchdog() code
only touch the local cpu instead of all of the cpus.  But instead of using
__get_cpu_var(), I use the __raw_get_cpu_var() version.

This avoids the preemption problem.  However my reasoning wasn't because I was
trying to be lazy.  Instead I rationalized it as, well if preemption is enabled
then interrupts should be enabled to and the NMI watchdog will have no reason
to trigger.  So it won't matter if the wrong cpu is touched because the percpu
interrupt counters the NMI watchdog uses should still be incrementing.

BUG=chromium:305420
TEST=platform_KernelErrorPaths, verified on peppy

Change-Id: I3791d76be7fc13c8bf6d3e21bf6a487ce1f50210
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179418
Reviewed-by: Sameer Nanda <snanda@chromium.org>
UPSTREAM: mmc: sdhci: add hooks for platform specific tuning

The tuning of some platforms may not follow the standard host control
spec v3.0, e.g. Freescale uSDHC on i.MX6Q/DL.
Add a hook here to allow execute platform specific tuning instead of
standard host controller tuning.

The hook only replaces the tuning process, so it's placed after tuning
checking and before the real tuning process.

Some notes for the tuning hook:
1) it needs handle lock itself if it wants to access host controller
according platform specific implementation.
2) do not need to handle runtime pm since it executes with runtime pm
get already.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 4525181245c0f4005788c17315aee4371662ddea)

BUG=none
TEST=build and boot on Nyan

Change-Id: Ie677de6106998ad07ba6d1bec734cc5a06682e92
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180174
CHROMIUM: dma-coherent: support coherent memory declaration with no kernel mapping

Add DMA_MEMORY_NOMAP flag to avoid creation of kernel virtual mapping
during the declaration of DMA coherent memory.
This would allow managing carveout memories via dma-coherent API with no
impact on kernel VMALLOC space.

BUG=none
TEST=emerged kernel on nyan (T124 Norrin), and made sure it boots.

Change-Id: I3dd4eec726a8172a52095c1fb4d26d31af776d6b
Signed-off-by: Vandana Salve <vsalve@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180086
Tested-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Chew <achew@nvidia.com>
CHROMIUM: PM/domains: add delayed power off capability

- this commit adds a capability to delay the powering off
of the domain
- callers can use pm_genpd_set_poweroff_delay to set the
power off delay for a domain
- it also adds a pm_notifier per pm domain which cancels
the delayed power off work when system suspend is invoked
- this needs to be done since pm_wq is freezable and causes
resume to fail since no one cancels the delayed power off
work. as a result, this work is run after resume when pm_wq
is unfreezed causing unwanted issues

BUG=none
TEST=emerged kernel for nyan (T124 Norrin) and made sure kernel boots.

Change-Id: I96bc5c922ebb589751e4158ad4b4e0d8cee5add7
Signed-off-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180166
Tested-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Chew <achew@nvidia.com>
CHROMIUM: ARM: init: Fix memory setup in the case of CONFIG_SPARSEMEM

The code in mem_init() was assuming that pages in a memory bank had
contiguous "struct page" entries.  That doesn't appear to always be
the case with CONFIG_SPARSEMEM.  Remove the slight optimization and
just calculate the location of the struct page each time.

BUG=chrome-os-partner:24537
TEST=Boot a kernel with an initramfs (which makes the kernel 6.7 MiB
big) and see that it no longer crashes.
TEST=Time boot performance and see no degredation.

Change-Id: I49142fc877b7e385c0a2a564d1f38f6bf268a125
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180326
Reviewed-by: Olof Johansson <olofj@chromium.org>
(cherry picked from commit 137f3957b4f5d2261dba3bc39b3f98ea91d79761)
Reviewed-on: https://chromium-review.googlesource.com/180637
CHROMIUM: video: fb: add fb mode defines

Add FB video mode & flag definitions.

BUG=none
TEST=emerged kernel for nyan (Tegra124 Norrin) and made sure kernel boots.

Change-Id: I63c8448a82af6ccce0cee9a47765e06f91371dea
Signed-off-by: Christopher Freeman <cfreeman@nvidia.com>
Signed-off-by: Mark Zhang <markz@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180143
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: video: fbmon: Add hdmi_ext_modedb for 4Kx2K

Provide a new mode table to use to calculate Extended resolution (HDMI_VIC)

BUG=none
TEST=emerged kernel for nyan (Tegra124 Norrin) and made sure kernel boots.

Change-Id: Ib225fc2646cde376b4c475055f87f994bcc06cf1
Signed-off-by: Jon Mayo <jmayo@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180144
Tested-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: of: introduce of_property_for_each_phandle_with_args()

Iterating over a property containing a list of phandles with arguments
is a common operation for device drivers. This patch adds a new
of_property_for_each_phandle_with_args() macro to make the iteration
simpler.

Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>

Patch posted upstream at:
      Patchwork: http://patchwork.ozlabs.org/patch/300549/

BUG=none
TEST=applied this and the rest of the patches in the series, make sure
kernel works.

Change-Id: Iad6296a49d4af0d1c310518b5749d413826ed1ad
[abrestic: fixed build error with !CONFIG_OF]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180815
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
UPSTREAM: mmc: core: Update the ext-csd.rev check for eMMC5.1

With the new eMMC5.1 spec, there is a new EXT_CSD register with
the revision number(EXT_CSD_REV) 7. This patch updates the check
for ext-csd.rev number as 7.

Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 6636bad839d9936e73e48c4841eda83a58fcdb53)
Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chromium:330362
TEST=Builds clean. eMMC5.1 parts work.

Change-Id: I28be28bde631b6569b6cb2c3a1778557f565d71a
Reviewed-on: https://chromium-review.googlesource.com/181065
Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
CHROMIUM: iommu/of: introduce a global iommu device list

This list will enable finding a populated IOMMU device via a device
node. This can be used to see if an dependee IOMMU is populated or not
to keep correct device population order. Client devices need to wait an
IOMMU to be populated.

Suggested by Thierry Reding and copied his example code.

Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Thierry Reding <thierry.reding@gmail.com>

Patch posted upstream at:
      http://patchwork.ozlabs.org/patch/300561/

CQ-DEPEND=CL:180817
BUG=none
TEST=applied this and the rest of the patches in the series, make sure
kernel works.

Change-Id: I4c65e1f03a13766afdd3f1f0a627da36c0c78a04
Reviewed-on: https://chromium-review.googlesource.com/180816
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: iommu/of: check if dependee iommu is ready or not

IOMMU devices on the bus need to be poplulated first, then iommu
master devices are done later.

With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
whether a device can be an iommu msater or not. If a device can, we'll
defer to populate that device till an depending iommu device is
populated.

Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>

Patch posted upstream at:
      http://patchwork.ozlabs.org/patch/300560/

BUG=none
TEST=applied this and the rest of the patches in the series, make sure
kernel works.

Change-Id: If987cafa9741f58fe3b96f14517c5aa4c63bc118
Reviewed-on: https://chromium-review.googlesource.com/180817
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
CHROMIUM: driver/core: populate devices in order for IOMMUs

IOMMU devices on the bus need to be poplulated first, then iommu
master devices are done later.

With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to identify
whether a device can be an iommu msater or not. If a device can, we'll
defer to populate that device till an iommu device is populated. Then,
those deferred iommu master devices are populated and configured with
help of the already populated iommu device.

Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Patch posted upstream at:
      http://patchwork.ozlabs.org/patch/300558/

BUG=none
TEST=applied this and the rest of the patches in the series, make sure
kernel works.

Change-Id: I6f51975ee6a7b70c47ca323bb2ceebb141e4cfd1
Reviewed-on: https://chromium-review.googlesource.com/180818
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
CHROMIUM: iommu/core: add ops->{bound,unbind}_driver()

ops->{bound,unbind}_driver() functions are called at
BUS_NOTIFY_{BOUND,UNBIND}_DRIVER respectively.

This is necessary to control the device population order. IOMMU master
devices depend on an IOMMU device instanciation. IOMMU master devices
can be registered to an IOMMU only after it's successfully
populated. This IOMMU registration is done via
ops->bound_driver(). Currently this population can be deferred if
depending IOMMU device hasn't yet been populated in driver core. This
cannot be done via ops->add_device() since after add_device() device's
population/instanciation can be still deferred via probe().

Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>

Patch posted upstream at:
      http://patchwork.ozlabs.org/patch/300559/

BUG=none
TEST=applied this and the rest of the patches in the series, make sure
kernel works.

Change-Id: I76aeb0f6f85aa49da1410cd3e25e943c9e058c9f
Reviewed-on: https://chromium-review.googlesource.com/180819
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: devfreq: Round frequencies in transition stats

Transition statistics required that the new frequency was *exactly*
as it was in the table. However, we may unexpectedly select a
frequency that is not in the table (i.e. thermal limit forces us to
select a bit lower frequency, the original DVFS table does not hold
for the current PLL for some reason, etc.)

This patch modifies transition table to select the best candidate
from the frequency table.

BUG=none
TEST=emerged kernel for nyan(Tegra124 Norrin) and made sure kernel boots.

Change-Id: Iab573eb785f08f28e4717b7937fdcc9e7118bb08
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180247
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: pwm-backlight: export pwm_backlight_parse_dt

We need a pwm_bl's function to set "check_fb" fops.
Currently because backlight driver utilizes DT,
so there is no way to do that unless we make this change.

BUG=none
TEST=emerged kernel for nyan (Tegra124 Norrin) and made sure kernel boots.

Change-Id: I856c6d33214d82f259336f28a8945e724d26c860
Signed-off-by: Mark Zhang <markz@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/180276
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: zram: fix compilation error due to API change

The return type of the release function pointer in block_device_operations
changed from int to void. This updates the code to reflect that.

BUG=chrome-os-partner:24166
TEST=build 3.10 kernel

Change-Id: Id3eac83c82491d120cee2caeacb8d07b36c9f446
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181651
CHROMIUM: Input: add i2c/smbus driver for elan touchpad

This driver adds support for elan i2c/smbus touchpad found on some laptops PC

Signed-off-by: Duson Lin <dusonlin@emc.com.tw>
BUG=chrome-os-partner:24733
TEST=on chromebook with Elan touchpad, boot and touchpad works.

Change-Id: I82c252b60931a40fcca8a55846083ee9505c2d91
Reviewed-on: https://chromium-review.googlesource.com/180900
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: 政維 林 <dusonlin@emc.com.tw>
Commit-Queue: 政維 林 <dusonlin@emc.com.tw>