- 09 Dec, 2015 40 commits
-
-
John Youn authored
commit 94218ee3 upstream. Certain Synopsys prototyping PHY boards are not able to meet timings constraints for LPM. This allows the PHY to meet those timings by leaving the PHY clock running during suspend. Signed-off-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
John Youn authored
commit ec791d14 upstream. Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls whether the PHY receives the suspend signal from the controller. Signed-off-by:
-
John Youn authored
commit bb7f3d6d upstream. Add platform data and set usb3_lpm_capable and has_lpm_erratum. Signed-off-by:
-
John Youn authored
commit 690fb371 upstream. This patch allows the dwc3 driver to run on the new Synopsys USB 3.1 IP core, albeit in USB 3.0 mode only. The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register interface and programming model as the existing USB 3.0 controller IP (DWC_usb3). However the GSNPSID and version numbers are different. Add checking for the new ID to pass driver probe. Also, since the DWC_usb31 version number is lower in value than the full GSNPSID of the DWC_usb3 IP, we set the high bit to identify DWC_usb31 and to ensure the values are higher. Finally, add a documentation note about the revision numbering scheme. Any future revision checks (for STARS, workarounds, and new features) should take into consideration how it applies to both the 3.1/3.0 IP. Signed-off-by:
-
John Youn authored
commit e8095a25 upstream. This adds the PCI product ID for the Synopsys USB 3.1 IP core (DWC_usb31) on a HAPS-based PCI development platform. Signed-off-by:
-
John Youn authored
commit 41adc59c upstream. This ID is for the Synopsys DWC_usb3 core with AXI interface on PCIe HAPS platform. This core has the debug registers mapped at a separate BAR in order to support enhanced hibernation. Signed-off-by:
-
Li Jun authored
commit 85da852d upstream. This patch is to support load and unload gadget driver in full OTG mode. Signed-off-by:
Li Jun <jun.li@freescale.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Tested-by:
Jiada Wang <jiada_wang@mentor.com> Signed-off-by:
-
Ben McCauley authored
commit b9e51b2b upstream. In some SoCs, dwc3 is implemented as a USB2.0 only core, meaning that it can't ever achieve SuperSpeed. Currect driver always sets gadget.max_speed to USB_SPEED_SUPER unconditionally. This can causes issues to some Host stacks where the host will issue a GetBOS() request and we will reply with a BOS containing Superspeed Capability Descriptor. At least Windows seems to be upset by this fact and prints a warning that we should connect $this device to another port. [ balbi@ti.com : rewrote entire commit, including source code comment to make a lot clearer what the problem is ] Signed-off-by:
Ben McCauley <ben.mccauley@garmin.com> Signed-off-by:
-
Douglas Gilbert authored
commit d134c48d upstream. Following changes that appeared in lk 4.0.0, the gadget udc driver for some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families) incorrectly deduced full-speed USB link speed even when the hardware had negotiated a high-speed link. The fix is to make sure that the UDPHS Interrupt Enable Register value does not mask the SPEED bit in the Interrupt Status Register. For a mass storage gadget this problem lead to failures when the host had a USB 3 port with the xhci_hcd driver. If the host was a USB 2 port using the ehci_hcd driver then the mass storage gadget worked (but probably at a lower speed than it should have). Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Fixes: 9870d895 ("usb: atmel_usba_udc: Mask status with enabled irqs") Signed-off-by:
-
Mian Yousaf Kaukab authored
commit 81e9d14a upstream. Defect 7374 workaround enables all GPEP as endpoint 0. Restore endpoint number when defect 7374 workaround is disabled. Otherwise, check to match USB endpoint number to hardware endpoint number in net2280_enable() fails. Reported-by:
Paul Jones <p.jones@teclyn.com> Signed-off-by:
Mian Yousaf Kaukab <yousaf.kaukab@intel.com> Signed-off-by:
-
Ville Syrjälä authored
commit d115d705 upstream. This reverts commit 8f2c9544. As it breaks g_ether on my Baytrail FFRD8 device. Everything starts out fine, but after a bit of data has been transferred it just stops flowing. Note that I do get a bunch of these "NOHZ: local_softirq_pending 08" when booting the machine, but I'm not really sure if they're related to this problem. Cc: Felipe Balbi <balbi@ti.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
David Hildenbrand authored
commit 5967c17b upstream. We should never allow to enable/disable any facilities for the guest when other VCPUs were already created. kvm_arch_vcpu_(load|put) relies on SIMD not changing during runtime. If somebody would create and run VCPUs and then decides to enable SIMD, undefined behaviour could be possible (e.g. vector save area not being set up). Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
David Hildenbrand authored
commit b85de33a upstream. Commit 383d0b05 ("KVM: s390: handle pending local interrupts via bitmap") introduced a possible memory overwrite from user space. User space could pass an invalid emergency signal code (sending VCPU) and therefore exceed the bitmap. Let's take care of this case and check that the id is in the valid range. Reviewed-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> Signed-off-by:
-
David Hildenbrand authored
commit 152e9f65 upstream. For now, VCPUs were always created sequentially with incrementing VCPU ids. Therefore, the index in the VCPUs array matched the id. As sequential creation might change with cpu hotplug, let's use the correct lookup function to find a VCPU by id, not array index. Let's also use kvm_lookup_vcpu() for validation of the sending VCPU on external call injection. Reviewed-by:
-
David Hildenbrand authored
commit db27a7a3 upstream. Let's provide a function to lookup a VCPU by id. Reviewed-by:
-
David Hildenbrand authored
commit c5c2c393 upstream. We seemed to have missed a few corner cases in commit f6c137ff ("KVM: s390: randomize sca address"). The SCA has a maximum size of 2112 bytes. By setting the sca_offset to some unlucky numbers, we exceed the page. 0x7c0 (1984) -> Fits exactly 0x7d0 (2000) -> 16 bytes out 0x7e0 (2016) -> 32 bytes out 0x7f0 (2032) -> 48 bytes out One VCPU entry is 32 bytes long. For the last two cases, we actually write data to the other page. 1. The address of the VCPU. 2. Injection/delivery/clearing of SIGP externall calls via SIGP IF. Especially the 2. happens regularly. So this could produce two problems: 1. The guest losing/getting external calls. 2. Random memory overwrites in the host. So this problem happens on every 127 + 128 created VM with 64 VCPUs. Acked-by:
-
Sebastian Ott authored
commit 7cc8944e upstream. zpci_err_insn writes stale stack content to the debugfs. Ensure that the struct in zpci_err_insn is ordered in a way that we don't have uninitialized holes in it. In addition to that add the packed attribute. Fixes: 3d8258e4 (s390/pci: move debug messages to debugfs) Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
commit 55a423b6 upstream. git commit 155e839a "s390/kernel: dynamically allocate FP register save area" introduced a regression in regard to ptrace. If the vector register extension is not present or unused the ptrace peek of a floating pointer register return incorrect data and the ptrace poke to a floating pointer register overwrites the task structure starting at task->thread.fpu.fprs. Signed-off-by:
-
Rajkumar Manoharan authored
commit f680f70a upstream. The number of spatial streams that are derived from chain mask for 4x4 devices is using wrong bitmask and conditional check. This is affecting downlink throughput for QCA99x0 devices. Earlier cfg_tx_chainmask is not filled by default until user configured it and so get_nss_from_chainmask never be called. This issue is exposed by recent commit 166de3f1 ("ath10k: remove supported chain mask"). By default maximum supported chain mask is filled in cfg_tx_chainmask. Fixes: 5572a95b ("ath10k: apply chainmask settings to vdev on creation") Signed-off-by:
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Vivek Natarajan authored
commit 72f8cef5 upstream. The current number of spatial streams used by the client is advertised as a separate IE in assoc request. Use this information to set the NSS operating mode. Fixes: 45c9abc0 ("ath10k: implement more versatile set_bitrate_mask"). Signed-off-by:
Vivek Natarajan <nataraja@qti.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
commit 5af82fa6 upstream. This was missed in the original commit adding the flag and ath10k only printed "bit10": ath10k_pci 0000:02:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2.4.70.6-2 api 3 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features no-p2p,bit10 Also add a build test to avoid this happening again. Fixes: ccec9038 ("ath10k: enable raw encap mode and software crypto engine") Signed-off-by:
-
Jonas Gorski authored
commit 11091fb0 upstream. The DEBUG_FS=n #defines for the dbg_show functions were missed when renaming the driver from msm_ to pm8xxx_, causing it to break the build when DEBUG_FS isn't enabled: CC [M] drivers/pinctrl/qcom/pinctrl-ssbi-gpio.o drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c:597:14: error: ‘pm8xxx_gpio_dbg_showâ€
™ undeclared here (not in a function) .dbg_show = pm8xxx_gpio_dbg_show, Fix this by renaming them correctly. Fixes: b4c45fe9 ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers") Signed-off-by:Jonas Gorski <jogo@openwrt.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Masahiro Yamada authored
commit bac7f4c1 upstream. While IECTRL is disabled, input signals are pulled-down internally. If pin-muxing is set up first, glitch signals (Low to High transition) might be input to hardware blocks. Bad case scenario: [1] The hardware block is already running before pinctrl is handled. (the reset is de-asserted by default or by a firmware, for example) [2] The pin-muxing is set up. The input signals to hardware block are pulled-down by the chip-internal biasing. [3] The pins are input-enabled. The signals from the board reach the hardware block. Actually, one invalid character is input to the UART blocks for such SoCs as PH1-LD4, PH1-sLD8, where UART devices start to run at the power on reset. To avoid such problems, pins should be input-enabled before muxing. Fixes: 6e908892 ("pinctrl: UniPhier: add UniPhier pinctrl core support") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by:
Dai Okamura <okamura.dai@socionext.com> Signed-off-by:
-
Mark Rutland authored
commit cb083816 upstream. A kernel built with DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA doesn't have .text aligned to a page boundary, though fixup_executable works at page-granularity thanks to its use of create_mapping. If .text is not page-aligned, the first page it exists in may be marked non-executable, leading to failures when an attempt is made to execute code in said page. This patch upgrades ALIGN_DEBUG_RO and ALIGN_DEBUG_RO_MIN to force page alignment for DEBUG_RO_DATA && !CONFIG_DEBUG_ALIGN_RODATA kernels, ensuring that all sections with specific RWX permission requirements are mapped with the correct permissions. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Reported-by:
Jeremy Linton <jeremy.linton@arm.com> Reviewed-by:
Laura Abbott <laura@labbott.name> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Suzuki Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Fixes: da141706 ("arm64: add better page protections to arm64") Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Robin Murphy authored
commit 5accd17d upstream. For reasons not entirely apparent, but now enshrined in history, the architectural mapping of AArch32 banked registers to AArch64 registers actually orders SP_<mode> and LR_<mode> backwards compared to the intuitive r13/r14 order, for all modes except FIQ. Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding subtle bugs with KVM and AArch32 guests. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Mirza Krak authored
commit 7cecd9ab upstream. According to SJA1000 data sheet error-warning (EI) interrupt is not cleared by setting the controller in to reset-mode. Then if we have the following case: - system is suspended (echo mem > /sys/power/state) and SJA1000 is left in operating state - A bus error condition occurs which activates EI interrupt, system is still suspended which means EI interrupt will be not be handled nor cleared. If the above two events occur, on resume there is no way to return the SJA1000 to operating state, except to cycle power to it. By simply reading the IR register on start we will clear any previous conditions that could be present. Signed-off-by:
Mirza Krak <mirza.krak@hostmobility.com> Reported-by:
Christian Magnusson <Christian.Magnusson@semcon.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marek Vasut authored
commit 562b103a upstream. The sizeof() is invoked on an incorrect variable, likely due to some copy-paste error, and this might result in memory corruption. Fix this. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: netdev@vger.kernel.org Signed-off-by:
-
Johan Hedberg authored
commit 8ce783dc upstream. The hci_conn objects don't have a dedicated lock themselves but rely on the caller to hold the hci_dev lock for most types of access. The hci_conn_timeout() function has so far sent certain HCI commands based on the hci_conn state which has been possible without holding the hci_dev lock. The recent changes to do LE scanning before connect attempts added even more operations to hci_conn and hci_dev from hci_conn_timeout, thereby exposing potential race conditions with the hci_dev and hci_conn states. As an example of such a race, here there's a timeout but an l2cap_sock_connect() call manages to race with the cleanup routine: [Oct21 08:14] l2cap_chan_timeout: chan ee4b12c0 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b12c0 state BT_CONNECT [ +0.000002] l2cap_chan_del: chan ee4b12c0, conn f3141580, err 111, state BT_CONNECT [ +0.000002] l2cap_sock_teardown_cb: chan ee4b12c0 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b12c0 orig refcnt 4 [ +0.000010] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000013] l2cap_chan_put: chan ee4b12c0 orig refcnt 3 [ +0.000063] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000049] hci_conn_params_del: addr ee:0d:30:09:53:1f (type 1) [ +0.000002] hci_chan_list_flush: hcon f53d56e0 [ +0.000001] hci_chan_del: hci0 hcon f53d56e0 chan f4e7ccc0 [ +0.004528] l2cap_sock_create: sock e708fc00 [ +0.000023] l2cap_chan_create: chan ee4b1770 [ +0.000001] l2cap_chan_hold: chan ee4b1770 orig refcnt 1 [ +0.000002] l2cap_sock_init: sk ee4b3390 [ +0.000029] l2cap_sock_bind: sk ee4b3390 [ +0.000010] l2cap_sock_setsockopt: sk ee4b3390 [ +0.000037] l2cap_sock_connect: sk ee4b3390 [ +0.000002] l2cap_chan_connect: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f (type 2) psm 0x00 [ +0.000002] hci_get_route: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f [ +0.000001] hci_dev_hold: hci0 orig refcnt 8 [ +0.000003] hci_conn_hold: hcon f53d56e0 orig refcnt 0 Above the l2cap_chan_connect() shouldn't have been able to reach the hci_conn f53d56e0 anymore but since hci_conn_timeout didn't do proper locking that's not the case. The end result is a reference to hci_conn that's not in the conn_hash list, resulting in list corruption when trying to remove it later: [Oct21 08:15] l2cap_chan_timeout: chan ee4b1770 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b1770 state BT_CONNECT [ +0.000003] l2cap_chan_del: chan ee4b1770, conn f3141580, err 111, state BT_CONNECT [ +0.000001] l2cap_sock_teardown_cb: chan ee4b1770 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b1770 orig refcnt 4 [ +0.000002] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000015] l2cap_chan_put: chan ee4b1770 orig refcnt 3 [ +0.000038] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000003] hci_chan_list_flush: hcon f53d56e0 [ +0.000002] hci_conn_hash_del: hci0 hcon f53d56e0 [ +0.000001] ------------[ cut here ]------------ [ +0.000461] WARNING: CPU: 0 PID: 1782 at lib/list_debug.c:56 __list_del_entry+0x3f/0x71() [ +0.000839] list_del corruption, f53d56e0->prev is LIST_POISON2 (00000200) The necessary fix is unfortunately more complicated than just adding hci_dev_lock/unlock calls to the hci_conn_timeout() call path. Particularly, the hci_conn_del() API, which expects the hci_dev lock to be held, performs a cancel_delayed_work_sync(&hcon->disc_work) which would lead to a deadlock if the hci_conn_timeout() call path tries to acquire the same lock. This patch solves the problem by deferring the cleanup work to a separate work callback. To protect against the hci_dev or hci_conn going away meanwhile temporary references are taken with the help of hci_dev_hold() and hci_conn_get(). Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Johan Hedberg authored
commit a6ad2a6b upstream. The commit 89cbb063 introduced support for deferred connection parameter removal when unpairing by removing them only once an existing connection gets disconnected. However, it failed to address the scenario when we're *not* connected and do an unpair operation. What makes things worse is that most user space BlueZ versions will first issue a disconnect request and only then unpair, meaning the buggy code will be triggered every time. This effectively causes the kernel to resume scanning and reconnect to a device for which we've removed all keys and GATT database information. This patch fixes the issue by adding the missing call to the hci_conn_params_del() function to a branch which handles the case of no existing connection. Signed-off-by:
-
Dmitry Tunin authored
commit 18e0afab upstream. T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=817b Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1506615Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
-
Dmitry Tunin authored
commit cd355ff0 upstream. This adapter works with the existing linux-firmware. T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=021c Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1502781Signed-off-by:
-
David Herrmann authored
commit 660f0fc0 upstream. The HIDP specs define an idle-timeout which automatically disconnects a device. This has always been implemented in the HIDP layer and forced a synchronous shutdown of the hidp-scheduler. This works just fine, but lacks a forced disconnect on the underlying l2cap channels. This has been broken since: commit 5205185d Author: David Herrmann <dh.herrmann@gmail.com> Date: Sat Apr 6 20:28:47 2013 +0200 Bluetooth: hidp: remove old session-management The old session-management always forced an l2cap error on the ctrl/intr channels when shutting down. The new session-management skips this, as we don't want to enforce channel policy on the caller. In other words, if user-space removes an HIDP device, the underlying channels (which are *owned* and *referenced* by user-space) are still left active. User-space needs to call shutdown(2) or close(2) to release them. Unfortunately, this does not work with idle-timeouts. There is no way to signal user-space that the HIDP layer has been stopped. The API simply does not support any event-passing except for poll(2). Hence, we restore old behavior and force EUNATCH on the sockets if the HIDP layer is disconnected due to idle-timeouts (behavior of explicit disconnects remains unmodified). User-space can still call getsockopt(..., SO_ERROR, ...) ..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can still be re-used (which nobody does so far, though). Therefore, the API still supports the new behavior, but with this patch it's also compatible to the old implicit channel shutdown. Reported-by:
Mark Haun <haunma@keteu.org> Reported-by:
Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Larry Finger authored
commit 1e6e6328 upstream. This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file was checked to verify that the addition is correct. Reported-by:
Frans van de Wiel <fvdw@fvdw.eu> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Frans van de Wiel <fvdw@fvdw.eu> Signed-off-by:
-
Dan Carpenter authored
commit 1f9c6e1b upstream. There were several bugs here. 1) The done label was in the wrong place so we didn't copy any information out when there was no command given. 2) We were using PAGE_SIZE as the size of the buffer instead of "PAGE_SIZE - pos". 3) snprintf() returns the number of characters that would have been printed if there were enough space. If there was not enough space (and we had fixed the memory corruption bug #2) then it would result in an information leak when we do simple_read_from_buffer(). I've changed it to use scnprintf() instead. I also removed the initialization at the start of the function, because I thought it made the code a little more clear. Fixes: 5e6e3a92 ('wireless: mwifiex: initial commit for Marvell mwifiex driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Amitkumar Karwar authored
commit 14d9c11c upstream. Preallocated PCIe buffer is being reused for all PCIe interface events. Physical address of the buffer is shared with firmware so that it can perform DMA on it. As event length is specified in the header, there should not be a problem if the buffer gets overwritten. We will save some cycles by avoiding memset everytime while submitting the buffer to firmware. Fixes: 2728cecd(mwifiex: corrections in PCIe event skb) Signed-off-by:
-
Aniket Nagarnaik authored
commit 17e524b1 upstream. This NULL pointer dereference is observed during suspend resume stress test. All pending commands are cancelled when system goes into suspend state. There a corner case in which host may receive response for last scan command after this and try to trigger extra active scan for hidden SSIDs. The issue is fixed by adding a NULL check to skip that extra scan. Fixes: 2375fa2b (mwifiex: fix unable to connect hidden SSID..) Signed-off-by:
Aniket Nagarnaik <aniketn@marvell.com> Signed-off-by:
-
Tony Lindgren authored
commit 75c08f17 upstream. Commit 68bab866 ("mfd: twl6040: Optional clk32k clock handling") added clock handling for the 32k clock from palmas-clk. However, that patch did not consider a typical situation where twl6040 is built-in, and palmas-clk is a loadable module like we have in omap2plus_defconfig. If palmas-clk is not loaded before twl6040 probes, we will get a "clk32k is not handled" warning during booting. This means that any drivers relying on this clock will mysteriously fail, including omap5-uevm WLAN and audio. Note that for WLAN, we probably should also eventually get the clk32kgaudio for MMC3 directly as that's shared between audio and WLAN SDIO at least for omap5-uevm. It seems the WLAN chip cannot get it as otherwise MMC3 won't get properly probed. Fixes: 68bab866 ("mfd: twl6040: Optional clk32k clock handling") Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Linus Walleij authored
commit 7bdccef3 upstream. A static code checker found a memory leak in the Versatile ICST code. Fix it. Fixes: a183da63 "clk: versatile: respect parent rate in ICST clock" Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Simran Rai authored
commit 63243a4d upstream. This patch affects the clocks that use fractional ndivider in their PLL output frequency calculation. Instead of 2^20 divide factor, the clock's ndiv integer shift was used. Fixed the bug by replacing ndiv integer shift with 2^20 factor. Signed-off-by:
Simran Rai <ssimran@broadcom.com> Signed-off-by:
Ray Jui <rjui@broadcom.com> Reviewed-by:
Scott Branden <sbranden@broadcom.com> Fixes: 5fe225c1 ("clk: iproc: add initial common clock support") Signed-off-by:
Michael Turquette <mturquette@baylibre.com> Signed-off-by:
-
Ingo Molnar authored
commit b2f73922 upstream. So the /proc/PID/stat 'wchan' field (the 30th field, which contains the absolute kernel address of the kernel function a task is blocked in) leaks absolute kernel addresses to unprivileged user-space: seq_put_decimal_ull(m, ' ', wchan); The absolute address might also leak via /proc/PID/wchan as well, if KALLSYMS is turned off or if the symbol lookup fails for some reason: static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns, struct pid *pid, struct task_struct *task) { unsigned long wchan; char symname[KSYM_NAME_LEN]; wchan = get_wchan(task); if (lookup_symbol_name(wchan, symname) < 0) { if (!ptrace_may_access(task, PTRACE_MODE_READ)) return 0; seq_printf(m, "%lu", wchan); } else { seq_printf(m, "%s", symname); } return 0; } This isn't ideal, because for example it trivially leaks the KASLR offset to any local attacker: fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35) ffffffff8123b380 Most real-life uses of wchan are symbolic: ps -eo pid:10,tid:10,wchan:30,comm and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat: triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan | tail -1 open("/proc/30833/wchan", O_RDONLY) = 6 There's one compatibility quirk here: procps relies on whether the absolute value is non-zero - and we can provide that functionality by outputing "0" or "1" depending on whether the task is blocked (whether there's a wchan address). These days there appears to be very little legitimate reason user-space would be interested in the absolute address. The absolute address is mostly historic: from the days when we didn't have kallsyms and user-space procps had to do the decoding itself via the System.map. So this patch sets all numeric output to "0" or "1" and keeps only symbolic output, in /proc/PID/wchan. ( The absolute sleep address can generally still be profiled via perf, by tasks with sufficient privileges. ) Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: kasan-dev <kasan-dev@googlegroups.com> Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/20150930135917.GA3285@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
