Found by a coccicheck script.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Symbol is only used in that file and can be static.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Allocate the irq data only in the loop.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

It is no need to check the packet[0] for sanity check when doing
elantech_packet_check_v4() function for fw_version = 0x470f01 touchpad.

Signed-off by: Duson Lin <dusonlin@emc.com.tw>
Reviewed-by: NUlrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

remove_one() was not incrementing the key for the beginning of the
range, so not all entries were being removed.  This resulted in
discards that were not unmapping all blocks.

Fixes: 4ec331c3 ("dm btree: add dm_btree_remove_leaves()")
Signed-off-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

In

commit 99264a61
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 15 19:34:43 2015 +0200

    drm/vblank: Fixup and document timestamp update/read barriers

I've switched vblank->count from atomic_t to unsigned long and
accidentally created an integer comparison bug in
drm_vblank_count_and_time since vblanke->count might overflow the u32
local copy and hence the retry loop never succeed.

Fix this by consistently using u32.

Cc: Michel Dänzer <michel@daenzer.net>
Reported-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.

The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new);
since the struct config block won't shrink in newer versions it should
be harmless to copy the maximum known size in such cases, so that's
what we do, but emitting the warning is probably sensible anyway.

In the longer run it might make sense to modify the parser code to
use a version/feature mapping, rather than hardcoding things like this,
but for now the variants are fairly managable.

This fixes a regression introduced in

commit 90e4f159
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Mar 25 18:45:58 2015 +0200

    drm/i915: Fix the VBT child device parsing for BSW

since we're hitting a DRM_ERROR on older platforms with this.

v2: Stricter size checks
Signed-off-by: NDavid Weinehall <david.weinehall@linux.intel.com>
[danvet: Fixup format string.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spec requires a device reset during cleanup, so do it and avoid warn
in virtio core. And detach unused buffers to avoid memory leak.
Signed-off-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The fw_version and feature_verion should be set correctly when the
firmwares are loaded by SMU on Tonga/Carrzio/Iceland
Signed-off-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Signed-off-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Expose feature version to user space for RLC/MEC/MEC2 ucode as well

v2: fix coding style
Signed-off-by: NJammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

gfx_v7_0_print_status contains a for loop on variable queue which does
not update this variable between each iteration.  This is bug is
reported by clang while building allmodconfig LLVMLinux on x86_64:

    drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5126:19: error: variable
    'queue' used in loop condition not modified in loop body
    [-Werror,-Wloop-analysis]
                for (queue = 0; queue < 8; i++) {
                                ^~~~~

Fix this by incrementing variable queue instead of i in this loop.
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Always set num_rbs to 2 for CZ.  The 1 RB parts are often harvest
configs.  The will get sorted out in mesa when we program
PA_SC_RASTER_CONFIG[_1].
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix following:
[    8.862274] ERROR: Bad of_node_put() on /ocp/i2c@48070000/twl@48/audio
[    8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175
[    8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[    8.883514] [<c00159e0>] (unwind_backtrace) from [<c0012488>] (show_stack+0x10/0x14)
[    8.891693] [<c0012488>] (show_stack) from [<c05cb810>] (dump_stack+0x78/0x94)
[    8.899322] [<c05cb810>] (dump_stack) from [<c02cfd5c>] (kobject_release+0x68/0x7c)
[    8.907409] [<c02cfd5c>] (kobject_release) from [<bf0040c4>] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra])
[    8.917877] [<bf0040c4>] (twl4030_vibra_probe [twl4030_vibra]) from [<c03816ac>] (platform_drv_probe+0x48/0x90)
[    8.928497] [<c03816ac>] (platform_drv_probe) from [<c037feb4>] (really_probe+0xd4/0x238)
[    8.937103] [<c037feb4>] (really_probe) from [<c0380160>] (driver_probe_device+0x30/0x48)
[    8.945678] [<c0380160>] (driver_probe_device) from [<c03801e0>] (__driver_attach+0x68/0x8c)
[    8.954589] [<c03801e0>] (__driver_attach) from [<c037ea60>] (bus_for_each_dev+0x50/0x84)
[    8.963226] [<c037ea60>] (bus_for_each_dev) from [<c037f828>] (bus_add_driver+0xcc/0x1e4)
[    8.971832] [<c037f828>] (bus_add_driver) from [<c0380b60>] (driver_register+0x9c/0xe0)
[    8.980255] [<c0380b60>] (driver_register) from [<c00097e0>] (do_one_initcall+0x100/0x1b8)
[    8.988983] [<c00097e0>] (do_one_initcall) from [<c00b8008>] (do_init_module+0x58/0x1c0)
[    8.997497] [<c00b8008>] (do_init_module) from [<c00b8cac>] (SyS_init_module+0x54/0x64)
[    9.005950] [<c00b8cac>] (SyS_init_module) from [<c000ed20>] (ret_fast_syscall+0x0/0x54)
[    9.015838] input: twl4030:vibrator as /devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:audio/input/input2

node passed to of_find_node_by_name is put inside that function and new node
is returned if found. Free returned node not already freed node.
Signed-off-by: NMarek Belisko <marek@goldelico.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So technically there's no need for a driver to export
the OF table since currently it's not used.

In fact, the I2C device ID table is mandatory for I2C drivers since
a i2c_device_id is passed to the driver's probe function even if the
I2C core used the OF table to match the driver.

And since the I2C core uses different tables, OF-only drivers needs to
have duplicated data that has to be kept in sync and also the dev node
compatible manufacturer prefix is stripped when reporting the MODALIAS.

To avoid the above, the I2C core behavior may be changed in the future
to not require an I2C device table for OF-only drivers and report the
OF module alias. So, it's better to also export the OF table to prevent
breaking module autoloading if that happens.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The I2C core always reports the MODALIAS uevent as "i2c:<client name"
regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

CPU fan speed going up and down on Dell Studio XPS 8100 for
unknown reasons. Without further debugging on the affected
machine, it is not possible to find the problem.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=100121Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Tested-by: NJan C Peters <jcpeters89@gmail.com>
Cc: stable@vger.kernel.org # v4.0+, will need backport
[groeck: cleaned up description, comments]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The commit 8c7a075d
"drm/i2c: tda998x: use drm_hdmi_avi_infoframe_from_display_mode()"
also uses hdmi_avi_infoframe_pack() to create the AVI infoframe.
This function sets the checksum of the frame and this breaks
the second calculation of the checksum done in tda998x_write_if().

Fixes: 8c7a075d ("drm/i2c: tda998x: use drm_hdmi_avi_infoframe_from_display_mode()")
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Including access_ok.h causes the ia64:allmodconfig build (and maybe others)
to fail with

include/linux/unaligned/le_struct.h:6:19: error:
	redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:7:19: note:
	previous definition of 'get_unaligned_le16' was here
include/linux/unaligned/le_struct.h:26:20: error:
	redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: note:
	previous definition of 'put_unaligned_le32' was here
include/linux/unaligned/le_struct.h:31:20: error:
	redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:47:20: note:
	previous definition of 'put_unaligned_le64' was here

Include unaligned.h instead and leave it up to the architecture to decide
how to implement unaligned accesses.

Fixes: 8c4f1364 ("Staging: lustre: Use put_unaligned_le64")
Cc: Vaishali Thakkar <vthakkar1994@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

An event channel bound to a CPU that was offlined may still be linked
on that CPU's queue.  If this event channel is closed and reused,
subsequent events will be lost because the event channel is never
unlinked and thus cannot be linked onto the correct queue.

When a channel is closed and the event is still linked into a queue,
ensure that it is unlinked before completing.

If the CPU to which the event channel bound is online, spin until the
event is handled by that CPU. If that CPU is offline, it can't handle
the event, so clear the event queue during the close, dropping the
events.

This fixes the missing interrupts (and subsequent disk stalls etc.)
when offlining a CPU.
Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

We've had a few issues with atomic where subtle bugs in the encoder
picking logic lead to accidental self-stealing of the encoder,
resulting in a NULL connector_state->crtc in update_connector_routing
and subsequent.

Linus applied some duct-tape for an mst regression in

commit 27667f47
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jul 29 22:18:16 2015 -0700

    i915: temporary fix for DP MST docking station NULL pointer dereference

But that was incomplete (the code will still oops when debuggin is
enabled) and mangled the state even further. So instead WARN and bail
out as the more future-proof option.

Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Apparently been in there since forever and fairly easy to hit when
hotplugging really fast. I can do that since my mst hub has a manual
button to flick the hpd line for reprobing. The resulting WARNING spam
isn't pretty.

Cc: Dave Airlie <airlied@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

In

commit 8c7b5ccb
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue Apr 21 17:13:19 2015 +0300

    drm/i915: Use atomic helpers for computing changed flags

we've switched over to the atomic version to compute the
crtc->encoder->connector routing from the i915 variant. That one
relies upon the ->best_encoder callback, but the i915-private version
relied upon intel_find_encoder. Which didn't matter except for dp mst,
where the encoder depends upon the selected crtc.

Fix this functional bug by implemented a correct atomic-state based
encoder selector for dp mst.

Note that we can't get rid of the legacy best_encoder callback since
the fbdev emulation uses that still. That means it's incorrect there
still, but that's been the case ever since i915 dp mst support was
merged so not a regression. Best to fix that by converting fbdev over
to atomic too.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

With legacy helpers all the routing was already set up when calling
best_encoder and so could be inspected. But with atomic it's staged,
hence we need a new atomic compliant callback for drivers which need
to inspect the requested state and can't just decided the best encoder
statically.

This is needed to fix up i915 dp mst where we need to pick the right
encoder depending upon the requested CRTC for the connector.

v2: Don't forget to amend the kerneldoc

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

A DM regression on 32 bit systems was reported against v4.2-rc3 here:
https://lkml.org/lkml/2015/7/29/401

Fix this by reverting both commit 1c220c69 ("dm: fix casting bug in
dm_merge_bvec()") and 148e51ba ("dm: improve documentation and code
clarity in dm_merge_bvec").  This combined revert is done to eliminate
the possibility of a partial revert in stable@ kernels.

In hindsight the correct fix, at the time 1c220c69 was applied to fix
the regression that 148e51ba introduced, should've been to simply revert
148e51ba.
Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
Tested-by: NAdam Williamson <awilliam@redhat.com>
Acked-by: NJoe Thornber <ejt@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.19+

conf->beacon_rate can be NULL on association. So check conf->beacon_rate

BSS_CHANGED_BEACON_INFO needs to flagged in changed as the beacon_rate
will appear later.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Cc: <stable@vger.kernel.org> # v3.19+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When xhci_mem_cleanup() is called, it's possible that the command
timer isn't initialized and scheduled. For those cases, to delete
the command timer causes soft-lockup as below stack dump shows.

The patch avoids deleting the command timer if it's not scheduled
with the help of timer_pending().

NMI watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [kworker/40:1:8140]
      :
NIP [c000000000150b30] lock_timer_base.isra.34+0x90/0xa0
LR [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
Call Trace:
[c000000f67c975e0] [c0000000015b84f8] mon_ops+0x0/0x8 (unreliable)
[c000000f67c97620] [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
[c000000f67c97660] [c000000000150cf0] del_timer_sync+0x60/0x80
[c000000f67c97690] [c00000000070ac0c] xhci_mem_cleanup+0x5c/0x5e0
[c000000f67c97740] [c00000000070c2e8] xhci_mem_init+0x1158/0x13b0
[c000000f67c97860] [c000000000700978] xhci_init+0x88/0x110
[c000000f67c978e0] [c000000000701644] xhci_gen_setup+0x2b4/0x590
[c000000f67c97970] [c0000000006d4410] xhci_pci_setup+0x40/0x190
[c000000f67c979f0] [c0000000006b1af8] usb_add_hcd+0x418/0xba0
[c000000f67c97ab0] [c0000000006cb15c] usb_hcd_pci_probe+0x1dc/0x5c0
[c000000f67c97b50] [c0000000006d3ba4] xhci_pci_probe+0x64/0x1f0
[c000000f67c97ba0] [c0000000004fe9ac] local_pci_probe+0x6c/0x130
[c000000f67c97c30] [c0000000000e5ce8] work_for_cpu_fn+0x38/0x60
[c000000f67c97c60] [c0000000000eacb8] process_one_work+0x198/0x470
[c000000f67c97cf0] [c0000000000eb6ac] worker_thread+0x37c/0x5a0
[c000000f67c97d80] [c0000000000f2730] kthread+0x110/0x130
[c000000f67c97e30] [c000000000009660] ret_from_kernel_thread+0x5c/0x7c

Cc: <stable@vger.kernel.org>
Reported-by: NPriya M. A <priyama2@in.ibm.com>
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to check that a TRB is part of the current segment
before calculating its DMA address.

Previously a ring segment didn't use a full memory page, and every
new ring segment got a new memory page, so the off by one
error in checking the upper bound was never seen.

Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
didn't catch the case when a TRB was the first element of the next segment.

This is triggered if the virtual memory pages for a ring segment are
next to each in increasing order where the ring buffer wraps around and
causes errors like:

[  106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
[  106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0

The trb-end address is one outside the end-seg address.

Cc: <stable@vger.kernel.org>
Tested-by: NArkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It turns out that only Dell laptops have the separate button bits for
v2 dualpoint sticks and that commit 92bac83d ("Input: alps - non
interleaved V2 dualpoint has separate stick button bits") causes
regressions on Toshiba laptops.

This commit adds a check for Dell laptops to the code for handling these
extra button bits, fixing this regression.

This patch has been tested on a Dell Latitude D620 to make sure that it
does not reintroduce the original problem.
Reported-and-tested-by: NDouglas Christman <douglaschristman@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add a proper module alias so the driver can be autoloaded when the
parent axp20x mfd driver registers its cells.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NCarlo Caione <carlo@caione.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Patch 17dd3f0f: "[PATCH] drivers/input/joystick: convert to dynamic
input_dev allocation" from Sep 15, 2005, leads to the following static
checker warning:

        drivers/input/joystick/turbografx.c:235 tgfx_probe()
        error: buffer overflow 'tgfx_buttons' 5 <= 5

drivers/input/joystick/turbografx.c
   195          for (i = 0; i < n_devs; i++) {
   196                  if (n_buttons[i] < 1)
   197                          continue;
   198
   199                  if (n_buttons[i] > 6) {
                            ^^^^^^^^^^^^^^^^
Possibly off by one.  >= 6.

Let's change the upper value to ARRAY_SIZE(tgfx_buttons) to ensure we do
not reach past the end of the array.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

This patch fixes a bug in the error pathway of
usb_add_gadget_udc_release() in udc-core.c.  If the udc registration
fails, the gadget registration is not fully undone; there's a
put_device(&gadget->dev) call but no device_del().

CC: <stable@vger.kernel.org>
Acked-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The majority of SMP platforms handle their IPIs through do_IRQ()
which calls irq_{enter/exit}(). When a call function IPI is received,
smp_call_function_interrupt() is called which also calls
irq_{enter,exit}(), meaning irq_count is raised twice.

When tick broadcasting is used (which is implemented via a call
function IPI), this incorrectly causes all CPU idle time on the core
receiving broadcast ticks to be accounted as time spent servicing
IRQs, as account_process_tick() will account as such if irq_count is
greater than 1. This results in 100% CPU usage being reported on a
core which receives its ticks via broadcast.

This patch removes the SMP smp_call_function_interrupt() wrapper which
calls irq_{enter,exit}(). Platforms which handle their IPIs through
do_IRQ() now call generic_smp_call_function_interrupt() directly to
avoid incrementing irq_count a second time. Platforms which don't
(loongson, sgi-ip27, sibyte) call generic_smp_call_function_interrupt()
wrapped in irq_{enter,exit}().
Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10770/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

71eeedcf (MIPS: Lemote 2F: Fix build caused
by recent mass rename.) only fixed one instance of this issue in arch/mips
but missed a 2nd one in drivers/cpufreq/loongson2_cpufreq.c.

[ralf@linux-mips.org: dropped the one segment for the already fixed
instance and changed the other avoiding an include <path.h> without a /
because that's generally is a bad idea.]
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Patchwork: https://patchwork.linux-mips.org/patch/10659/

I have a report of drop_one_stripe() called from
raid5_cache_scan() apparently finding ->max_nr_stripes == 0.

This should not be allowed.

So add a test to keep max_nr_stripes above min_nr_stripes.

Also use a 'mask' rather than a 'mod' in drop_one_stripe
to ensure 'hash' is valid even if max_nr_stripes does reach zero.


Fixes: edbe83ab ("md/raid5: allow the stripe_cache to grow and shrink.")
Cc: stable@vger.kernel.org (4.1 - please release with 2d5b569b)
Reported-by: NTomas Papan <tomas.papan@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.com>

In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
mdu_bitmap_file_t called "file".

5769         file = kmalloc(sizeof(*file), GFP_NOIO);
5770         if (!file)
5771                 return -ENOMEM;

This structure is copied to user space at the end of the function.

5786         if (err == 0 &&
5787             copy_to_user(arg, file, sizeof(*file)))
5788                 err = -EFAULT

But if bitmap is disabled only the first byte of "file" is initialized
with zero, so it's possible to read some bytes (up to 4095) of kernel
space memory from user space. This is an information leak.

5775         /* bitmap disabled, zero the first byte and copy out */
5776         if (!mddev->bitmap_info.file)
5777                 file->pathname[0] = '\0';
Signed-off-by: NBenjamin Randazzo <benjamin@randazzo.fr>
Signed-off-by: NNeilBrown <neilb@suse.com>

This patch removes the unused code related to struct exynos_tmu_platform_data
because exynos_tmu_probe() don't handle the struct exynos_tmu_platform_data *pdata.

Test HW: Exynos4412 - Trats2 board

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Tested-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

The exynos thermal driver use the of_thermal_*() API to parse the basic data
for thermal management from devicetree file. So, if CONFIG_EXYNOS_THERMAL is
selected without CONFIG_THERMAL_OF, kernel can build it without any problem.
But, exynos thermal driver is not working with following error log. This patch
add the dependency of CONFIG_THERMAL_OF instead of CONFIG_OF.

[    1.458644] get_th_reg: Cannot get trip points from of-thermal.c!
[    1.459096] get_th_reg: Cannot get trip points from of-thermal.c!
[    1.465211] exynos4412_tmu_initialize: No CRITICAL trip point defined at of-thermal.c!

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>

During probe the regulator (if present) was enabled but not disabled in
case of failure. So an unsuccessful probe lead to enabling the
regulator which was actually not needed because the device was not
enabled.

Additionally each deferred probe lead to increase of regulator enable
count so it would not be effectively disabled during removal of the
device.

Test HW: Exynos4412 - Trats2 board
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 498d22f6 ("thermal: exynos: Support for TMU regulator defined at device tree")
Cc: <stable@vger.kernel.org>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Tested-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>