- 04 Aug, 2015 40 commits
-
-
Firo Yang authored
commit 4e023612 upstream. Warning like this: drivers/md/md.c: In function "update_array_info": drivers/md/md.c:6394:26: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] !mddev->persistent != info->not_persistent|| Fix it as Neil Brown said: mddev->persistent != !info->not_persistent || Signed-off-by:
Firo Yang <firogm@gmail.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Stevens, Nick authored
commit 347d7e45 upstream. The mcp3021 scaling code is dividing the VDD (full-scale) value in millivolts by the A2D resolution to obtain the scaling factor. When VDD is 3300mV (the standard value) and the resolution is 12-bit (4096 divisions), the result is a scale factor of 3300/4096, which is always one. Effectively, the raw A2D reading is always being returned because no scaling is applied. This patch fixes the issue and simplifies the register-to-volts calculation, removing the unneeded "output_scale" struct member. Signed-off-by:
Nick Stevens <Nick.Stevens@digi.com> [Guenter Roeck: Dropped unnecessary value check] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Lior Amsalem authored
commit 9136291f upstream. This patch fixes a bug in the XOR driver where the cleanup function can be called and free descriptors that never been processed by the engine (which result in data errors). The cleanup function will free descriptors based on the ownership bit in the descriptors. Fixes: ff7b0479 ("dmaengine: DMA engine driver for Marvell XOR engine") Signed-off-by:
Lior Amsalem <alior@marvell.com> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by:
Ofer Heifetz <oferh@marvell.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 6224beb1 upstream. Fengguang Wu's tests triggered a bug in the branch tracer's start up test when CONFIG_DEBUG_PREEMPT set. This was because that config adds some debug logic in the per cpu field, which calls back into the branch tracer. The branch tracer has its own recursive checks, but uses a per cpu variable to implement it. If retrieving the per cpu variable calls back into the branch tracer, you can see how things will break. Instead of using a per cpu variable, use the trace_recursion field of the current task struct. Simply set a bit when entering the branch tracing and clear it when leaving. If the bit is set on entry, just don't do the tracing. There's also the case with lockdep, as the local_irq_save() called before the recursion can also trigger code that can call back into the function. Changing that to a raw_local_irq_save() will protect that as well. This prevents the recursion and the inevitable crash that follows. Link: http://lkml.kernel.org/r/20150630141803.GA28071@wfg-t540p.sh.intel.comReported-by:
Fengguang Wu <fengguang.wu@intel.com> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 6b88f44e upstream. While debugging a WARN_ON() for filtering, I found that it is possible for the filter string to be referenced after its end. With the filter: # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter The filter_parse() function can call infix_get_op() which calls infix_advance() that updates the infix filter pointers for the cnt and tail without checking if the filter is already at the end, which will put the cnt to zero and the tail beyond the end. The loop then calls infix_next() that has ps->infix.cnt--; return ps->infix.string[ps->infix.tail++]; The cnt will now be below zero, and the tail that is returned is already passed the end of the filter string. So far the allocation of the filter string usually has some buffer that is zeroed out, but if the filter string is of the exact size of the allocated buffer there's no guarantee that the charater after the nul terminating character will be zero. Luckily, only root can write to the filter. Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit b4875bbe upstream. When testing the fix for the trace filter, I could not come up with a scenario where the operand count goes below zero, so I added a WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case that it can happen (although the filter would be wrong). # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter That is, a single operation without any operands will hit the path where the WARN_ON_ONCE() can trigger. Although this is harmless, and the filter is reported as a error. But instead of spitting out a warning to the kernel dmesg, just fail nicely and report it via the proper channels. Link: http://lkml.kernel.org/r/558C6082.90608@oracle.comReported-by:
Vince Weaver <vincent.weaver@maine.edu> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Arne Fitzenreiter authored
commit cda57b1b upstream. This device loses blocks, often the partition table area, on trim. Disable TRIM. http://pcengines.ch/msata16a.htmSigned-off-by:
Arne Fitzenreiter <arne_f@ipfire.org> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Arne Fitzenreiter authored
commit 71d126fd upstream. Some devices lose data on TRIM whether queued or not. This patch adds a horkage to disable TRIM. tj: Collapsed unnecessary if() nesting. Signed-off-by:
-
Hon Ching \\(Vicky\\) Lo authored
commit 9d75f089 upstream. tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq, the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address. Signed-off-by:
Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com> Signed-off-by:
Joy Latten <jmlatten@linux.vnet.ibm.com> Reviewed-by:
Ashley Lai <ashley@ahsleylai.com> Fixes: 132f7629 ("drivers/char/tpm: Add new device driver to support IBM vTPM") Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Eric Sandeen authored
commit 2ac56d3d upstream. If we create a CRC filesystem, mount it, and create a symlink with a path long enough that it can't live in the inode, we get a very strange result upon remount: # ls -l mnt total 4 lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM XSLM is the V5 symlink block header magic (which happens to be followed by a NUL, so the string looks terminated). xfs_readlink_bmap() advanced cur_chunk by the size of the header for CRC filesystems, but never actually used that pointer; it kept reading from bp->b_addr, which is the start of the block, rather than the start of the symlink data after the header. Looks like this problem goes back to v3.10. Fixing this gets us reading the proper link target, again. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Zhao Junwang authored
commit 01447e9f upstream. legacy setcrtc ioctl does take a 32 bit value which might indeed overflow the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't needed any more with this v2: -polish the annotation according to Daniel's comment Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Zhao Junwang <zhjwpku@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Alex Deucher authored
commit 5dfc71bc upstream. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Michel Dänzer authored
commit 233709d2 upstream. This can be the case when the GPU is powered off, e.g. via vgaswitcheroo or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin flushes the TLB after setting rdev->gart.ptr to non-NULL. Fixes panic on powering off R7xx GPUs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Jérôme Glisse authored
commit 2ba8d1bb upstream. In order for hibernation to reliably work we need to properly turn off the SDMA block, sadly after numerous attemps i haven't not found proper sequence for clean and full shutdown. So simply reset both SDMA block, this makes hibernation works reliably on sea island GPU family (CI) Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Signed-off-by:
Jérôme Glisse <jglisse@redhat.com> Reviewed-by:
-
Jérôme Glisse authored
commit 161569de upstream. In order for hibernation to reliably work we need to cleanup more thoroughly the compute ring. Hibernation is different from suspend resume as when we resume from hibernation the hardware is first fully initialize by regular kernel then freeze callback happens (which correspond to a suspend inside the radeon kernel driver) and turn off each of the block. It turns out we were not cleanly shutting down the compute ring. This patch fix that. Hibernation and suspend to ram were tested (several times) on : Bonaire Hawaii Mullins Kaveri Kabini Changed since v1: - Factor the ring stop logic into a function taking ring as arg. Signed-off-by:
-
Alex Deucher authored
commit 39fa10f7 upstream. Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by:
-
Frediano Ziglio authored
commit 8451cc96 upstream. If the function fails reference counter to the object is not decremented causing leaks. This is hard to spot as it happens only on very low memory situations. Signed-off-by:
Frediano Ziglio <fziglio@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Frediano Ziglio authored
commit 2fa19535 upstream. If objects are moved back from system memory to VRAM (and spice id created again) memory is already initialized so we need to set flag to not clear memory. If you don't do it after a while using desktop many images turns to black or transparents. Signed-off-by:
-
Tomas Winkler authored
commit 9098f84c upstream. Enclosing mmc_blk_put() is missing in power_ro_lock_show() sysfs handler, let's add it. Fixes: add710ea ("mmc: boot partition ro lock support") Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Joe Thornber authored
commit 1c751879 upstream. Allocate memory using GFP_NOIO when deleting a btree. dm_btree_del() can be called via an ioctl and we don't want to recurse into the FS or block layer. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Dennis Yang authored
commit 4c7e3093 upstream. redistribute3() shares entries out across 3 nodes. Some entries were being moved the wrong way, breaking the ordering. This manifested as a BUG() in dm-btree-remove.c:shift() when entries were removed from the btree. For additional context see: https://www.redhat.com/archives/dm-devel/2015-May/msg00113.htmlSigned-off-by:
Dennis Yang <shinrairis@gmail.com> Signed-off-by:
-
Joe Thornber authored
commit 6096d91a upstream. The metadata space map has a simplified 'bootstrap' mode that is operational when extending the space maps. Whilst in this mode it's possible for some refcount decrement operations to become queued (eg, as a result of shadowing one of the bitmap indexes). These decrements were not being applied when switching out of bootstrap mode. The effect of this bug was the leaking of a 4k metadata block. This is detected by the latest version of thin_check as a non fatal error. Signed-off-by:
-
Mikulas Patocka authored
commit dd4c1b7d upstream. If the number_of_areas argument was zero the kernel would crash on div-by-zero. Add better input validation. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
AMAN DEEP authored
commit 34968106 upstream. virt_dev->num_cached_rings counts on freed ring and is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring is added into cache and then num_rings_cache is incremented as below: virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; virt_dev->num_rings_cached++; here, free ring pointer is added to a current index and then index is incremented. So current index always points to empty location in the ring cache. For getting available free ring, current index should be decremented first and then corresponding ring buffer value should be taken from ring cache. But In function xhci_endpoint_init(), the num_rings_cached index is accessed before decrement. virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; virt_dev->num_rings_cached--; This is bug in manipulating the index of ring cache. And it should be as below: virt_dev->num_rings_cached--; virt_dev->eps[ep_index].new_ring = virt_dev->ring_cache[virt_dev->num_rings_cached]; virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL; Signed-off-by:
Aman Deep <aman.deep@samsung.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Johannes Thumshirn authored
commit d23f47d4 upstream. Destroy serial_minors IDR on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez <mcgrof@suse.com>) <SmPL> @ defines_module_init @ declarer name module_init, module_exit; declarer name DEFINE_IDR; identifier init; @@ module_init(init); @ defines_module_exit @ identifier exit; @@ module_exit(exit); @ declares_idr depends on defines_module_init && defines_module_exit @ identifier idr; @@ DEFINE_IDR(idr); @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... idr_destroy(&idr); ... } @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... +idr_destroy(&idr); } </SmPL> Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Claudio Cappelli authored
commit f6d7fb37 upstream. Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000. T: Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2020 ProdID=4000 Rev=03.00 S: Manufacturer=Network Connect S: Product=MT6225 C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by:
Claudio Cappelli <claudio.cappelli.linux@gmail.com> Suggested-by:
Lars Melin <larsm17@gmail.com> [johan: amend commit message with devices info ] Signed-off-by:
-
Peter Sanford authored
commit f98a7aa8 upstream. Add the USB serial console device ID for Aruba Networks 7xxx series controllers which have a USB port for their serial console. Signed-off-by:
Peter Sanford <peter@sanford.io> Signed-off-by:
-
Felipe Balbi authored
commit be9d3988 upstream. Currently, we're calling musb_start() twice for DRD ports in some situations. This has been observed to cause enumeration issues after suspend/resume cycles with AM335x. In order to fix the problem, we just have to fix the check on musb_has_gadget() so that it only returns true if current mode is Host and ignore the fact that we have or not a gadget driver loaded. Fixes: ae44df2e (usb: musb: call musb_start() only once in OTG mode) Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Dan Carpenter authored
commit 83ed07c5 upstream. Static checkers complain that the current condition is never true. It seems pretty likely that it's a typo and "URB" was intended instead of "USB". Fixes: 3d97ff63 ('usbdevfs: Use scatter-gather lists for large bulk transfers') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
John Youn authored
commit aebda618 upstream. This fixes an issue introduced in commit b23c8439 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would only use DEPSTARTCFG once per SetConfig. The trick is that we should use one DEPSTARTCFG per SetConfig *OR* SetInterface. SetInterface was completely missed from the original patch. This problem became aparent after commit 76e838c9 (usb: dwc3: gadget: return error if command sent to DEPCMD register fails) added checking of the return status of device endpoint commands. 'Set Endpoint Transfer Resource' command was caught failing occasionally. This is because the Transfer Resource Index was not getting reset during a SET_INTERFACE request. Finally, to fix the issue, was we have to do is make sure that our start_config_issued flag gets reset whenever we receive a SetInterface request. To verify the problem (and its fix), all we have to do is run test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'. Tested-by:
Huang Rui <ray.huang@amd.com> Tested-by:
Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com> Fixes: b23c8439 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs) Signed-off-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
-
Subbaraya Sundeep Bhatta authored
commit 76e838c9 upstream. We need to return error to caller if command is not sent to controller succesfully. Signed-off-by:
Subbaraya Sundeep Bhatta <sbhatta@xilinx.com> Fixes: 72246da4 (usb: Introduce DesignWare USB3 DRD Driver) Signed-off-by:
-
Subbaraya Sundeep Bhatta authored
commit 891b1dc0 upstream. We need to return error to caller if command is not sent to controller succesfully. Signed-off-by:
-
Mikulas Patocka authored
commit d531be2c upstream. I have a ST4000DM000 disk. If Linux is booted while the disk is spun down, the command that sets transfer mode causes the disk to spin up. The spin-up takes longer than the default 5s timeout, so the command fails and timeout is reported. Fix this by increasing the timeout to 15s, which is enough for the disk to spin up. Signed-off-by:
-
Aleksei Mamlin authored
commit 08c85d2a upstream. Enabling AA on HP 250GB SATA disk VB0250EAVER causes errors: [ 3.788362] ata3.00: failed to enable AA (error_mask=0x1) [ 3.789243] ata3.00: failed to enable AA (error_mask=0x1) Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk. tj: Collected FPDMA_AA entries and updated comment. Signed-off-by:
Aleksei Mamlin <mamlinav@gmail.com> Signed-off-by:
-
Zidan Wang authored
commit a077e81e upstream. the enum of "DAC Polarity" should be wm8960_enum[1]. Signed-off-by:
Zidan Wang <zidan.wang@freescale.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Axel Lin authored
commit ebb6ad73 upstream. VMID Control 0 BIT[2:1] is VMID Divider Enable and Select 00 = VMID disabled (for OFF mode) 01 = 2 x 50kΩ divider (for normal operation) 10 = 2 x 250kΩ divider (for low power standby) 11 = 2 x 5kΩ divider (for fast start-up) So WM8903_VMID_RES_250K should be 2 << 1, which is 4. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Axel Lin authored
commit 12c35005 upstream. WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than WM8955_PLL_CONTROL_2. Signed-off-by:
-
Axel Lin authored
commit 14ba3ec1 upstream. According to the datasheet: R10 (0Ah) VMID Impedance Control BIT 3:2 VMIDSEL DEFAULT 00 DESCRIPTION: VMID impedance selection control 00: 75kΩ output 01: 300kΩ output 10: 2.5kΩ output WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]), so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits. Signed-off-by:
-
Dan Carpenter authored
commit 474ff0ae upstream. My static checker complains that: sound/soc/fsl/imx-wm8962.c:196 imx_wm8962_probe() warn: we tested 'ret' before and it was 'false' The intent was that we use "ret" to check imx_audmux_v2_configure_port(). Fixes: 8de2ae2a ('ASoC: fsl: add imx-wm8962 machine driver') Signed-off-by:
-
Richard Fitzgerald authored
commit 15575ed5 upstream. The Arizona codec drivers had an incorrect dB scaling for the noise generator gain that started at 0dB and went upwards. Actually the highest setting is 0dB. Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
-
