- 13 Feb, 2018 1 commit
-
-
Michael Neuling authored
commit 191eccb1 upstream. A new hypervisor call has been defined to communicate various characteristics of the CPU to guests. Add definitions for the hcall number, flags and a wrapper function. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [Balbir fixed conflicts in backport] Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 Feb, 2018 39 commits
-
-
Greg Kroah-Hartman authored
-
Stefan Agner authored
commit d593574a upstream. Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Fabio Estevam authored
commit 38b1f0fb upstream. The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS lines, so only allow such wakeup method when the system actually has RTS/CTS support. Fixes: bc85734b ("serial: imx: allow waking up on RTSD") Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Martin Kaiser <martin@kaiser.cx> Acked-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Shuah Khan authored
Upstream commit 1c9de5bf ("usbip: vhci-hcd: Add USB3 SuperSpeed support") vhci_hcd clears all the bits port_status bits instead of clearing just the USB_PORT_STAT_POWER bit when it handles ClearPortFeature: USB_PORT_FEAT_POWER. This causes vhci_hcd attach to fail in a bad state, leaving device unusable by the client. The device is still attached and however client can't use it. The problem was fixed as part of larger change to add USB3 Super Speed support. This patch backports just the change to clear the USB_PORT_STAT_POWER. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 11fb3799 upstream. The current code tries to test for bits that are masked out by usb_endpoint_maxp(). Instead, use the proper accessor to access the new high bandwidth bits. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Oliver Neukum authored
commit cbeef22f upstream. Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then hang in the scsi_remove_host call. This is esp. bad because our disconnect handler hanging for ever also stops the USB subsys from enumerating any new USB devices, causes commands like lsusb to hang, etc. In practice this happens when unplugging some uas devices because the hub code may see the device as needing a warm-reset and calls usb_reset_device before seeing the disconnect. In this case uas_configure_endpoints fails with -ENODEV. We do not want to print an error for this, so this commit also silences the shost_printk for -ENODEV. ENDQUOTE However, if we do that we better drop any unconditional execution and report to the SCSI subsystem that we have undergone a reset but we are not operational now. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hemant Kumar authored
commit ce5bf9a5 upstream. Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg KH <gregkh@linux-foundation.org> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Dmitry Shmidt <dimitrysh@google.com> Cc: Badhri <badhri@google.com> Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by:
Hemant Kumar <hemantk@codeaurora.org> [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Johan Hovold authored
commit 46fe895e upstream. Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI devices. D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0cad ProdID=9011 Rev=24.16 S: Manufacturer=Motorola Solutions Inc. S: Product=Motorola Solutions TETRA PEI interface C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Note that these devices do not support the CDC SET_CONTROL_LINE_STATE request (for any interface). Reported-by:
Max Schulze <max.schulze@posteo.de> Tested-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Shuah Khan authored
commit ef824501 upstream. usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Signed-off-by:
-
Shuah Khan authored
commit ef54cf0c upstream. usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Signed-off-by:
-
Jia-Ju Bai authored
commit c7b8f778 upstream. According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Oliver Neukum authored
commit df1cc78a upstream. This devices drops random bytes from messages if you talk to it too fast. Signed-off-by:
-
Hans de Goede authored
commit f0386c08 upstream. When disconnected sometimes the cdc-acm driver logs errors like these: [20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19 [20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19 [20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19 [20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19 [20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19 [20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19 [20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19 Silence these by not logging errors when the result is -ENODEV. Signed-off-by:
-
Greg Kroah-Hartman authored
commit d08dd3f3 upstream. This adds a new device id for Chilitag devices to the pl2303 driver. Reported-by:
"Chu.Mike [朱堅宜]" <Mike-Chu@prolific.com.tw> Acked-by:
-
OKAMOTO Yoshiaki authored
commit 69341bd1 upstream. FS040U modem is manufactured by omega, and sold by Fujisoft. This patch adds ID of the modem to use option1 driver. Interface 3 is used as qmi_wwan, so the interface is ignored. Signed-off-by:
Yoshiaki Okamoto <yokamoto@allied-telesis.co.jp> Signed-off-by:
Hiroyuki Yamamoto <hyamamo@allied-telesis.co.jp> Acked-by:
-
Gaurav Kohli authored
commit b027e229 upstream. There can be a race, if receive_buf call comes before tty initialization completes in n_tty_open and tty->disc_data may be NULL. CPU0 CPU1 ---- ---- 000|n_tty_receive_buf_common() n_tty_open() -001|n_tty_receive_buf2() tty_ldisc_open.isra.3() -002|tty_ldisc_receive_buf(inline) tty_ldisc_setup() Using ldisc semaphore lock in tty_init_dev till disc_data initializes completely. Signed-off-by:
Gaurav Kohli <gkohli@codeaurora.org> Reviewed-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Dmitry Eremin authored
commit 9b046013 upstream. The logic of the original commit 4d99b258 ("staging: lustre: avoid intensive reconnecting for ko2iblnd") was assumed conditional free of struct kib_conn if the second argument free_conn in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true. But this hunk of code was dropped from original commit. As result the logic works wrong and current code use struct kib_conn after free. > drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c > 3317 kiblnd_destroy_conn(conn, !peer); > ^^^^ Freed always (but should be conditionally) > 3318 > 3319 spin_lock_irqsave(lock, flags); > 3320 if (!peer) > 3321 continue; > 3322 > 3323 conn->ibc_peer = peer; > ^^^^^^^^^^^^^^ Use after free > 3324 if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE) > 3325 list_add_tail(&conn->ibc_list, > ^^^^^^^^^^^^^^ Use after free > 3326 &kiblnd_data.kib_reconn_list); > 3327 else > 3328 list_add_tail(&conn->ibc_list, > ^^^^^^^^^^^^^^ Use after free > 3329 &kiblnd_data.kib_reconn_wait); To avoid confusion this fix moved the freeing a struct kib_conn outside of the function kiblnd_destroy_conn() and free as it was intended in original commit. Fixes: 4d99b258 ("staging: lustre: avoid intensive reconnecting for ko2iblnd") Signed-off-by:
Dmitry Eremin <Dmitry.Eremin@intel.com> Reviewed-by:
Andreas Dilger <andreas.dilger@intel.com> Signed-off-by:
-
Stefan Schake authored
[ Upstream commit ce9caf2f ] We were calling enable_irq on bind, where it was already enabled previously by the IRQ helper. Additionally, dev->irq is not set correctly until after postinstall and so was always zero here, triggering a warning in 4.15. Fix both by moving the enable to the power management resume path, where we know there was a previous disable invocation during suspend. Fixes: 253696cc ("drm/vc4: Account for interrupts in flight") Signed-off-by:
Stefan Schake <stschake@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/1514563543-32511-1-git-send-email-stschake@gmail.comTested-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Larry Finger authored
[ Upstream commit b77992d2 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit b2fc059f ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7c ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Icenowy Zheng authored
[ Upstream commit 04226916 ] A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Acked-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 5f1aa51c ] Booting a kernel results in the kernel warning us about the following PPI interrupts configuration: [ 0.105127] smp: Bringing up secondary CPUs ... [ 0.110545] GIC: PPI11 is secure or misconfigured [ 0.110551] GIC: PPI13 is secure or misconfigured Fix this by using the appropriate edge configuration for PPI11 and PPI13, this is similar to what was fixed for Northstar (BCM5301X) in commit 0e34079c ("ARM: dts: BCM5301X: Correct GIC_PPI interrupt flags"). Fixes: 7b2e987d ("ARM: NSP: add minimal Northstar Plus device tree") Fixes: 1a9d53ca ("ARM: dts: NSP: Add TWD Support to DT") Acked-by:
Jon Mason <jon.mason@broadcom.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit d1b275ff ] The MONITOR type is missing in the interface type switch. Add it. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 72753590 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa497613 ("ufs: Add regulator enable support") Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Guilherme G. Piccoli authored
[ Upstream commit e4717292 ] As part of the scsi EH path, aacraid performs a reinitialization of the adapter, which encompass freeing resources and IRQs, NULLifying lots of pointers, and then initialize it all over again. We've identified a problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ is enabled on kernel config file. Happens that, in case this flag was set, right after free_irq() effectively clears the interrupt, it checks if it was requested as IRQF_SHARED. In positive case, it performs another call to the IRQ handler on driver. Problem is: since aacraid currently free some resources *before* freeing the IRQ, once free_irq() path calls the handler again (due to CONFIG_DEBUG_SHIRQ), aacraid crashes due to NULL pointer dereference with the following trace: aac_src_intr_message+0xf8/0x740 [aacraid] __free_irq+0x33c/0x4a0 free_irq+0x78/0xb0 aac_free_irq+0x13c/0x150 [aacraid] aac_reset_adapter+0x2e8/0x970 [aacraid] aac_eh_reset+0x3a8/0x5d0 [aacraid] scsi_try_host_reset+0x74/0x180 scsi_eh_ready_devs+0xc70/0x1510 scsi_error_handler+0x624/0xa20 This patch prevents the crash by changing the order of the deinitialization in this path of aacraid: first we clear the IRQ, then we free other resources. No functional change intended. Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Reviewed-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
-
Carlos Maiolino authored
[ Upstream commit 373b0589 ] Once the inode item writeback errors is already fixed, it's time to fix the same problem in dquot code. Although there were no reports of users hitting this bug in dquot code (at least none I've seen), the bug is there and I was already planning to fix it when the correct approach to fix the inodes part was decided. This patch aims to fix the same problem in dquot code, regarding failed buffers being unable to be resubmitted once they are flush locked. Tested with the recently test-case sent to fstests list by Hou Tao. Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 22a6c837 ] Fix some complaints from the UBSAN about signed integer addition overflows. Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 8677b1ac ] If we don't find a matching device node, we must free the memory allocated in 'omap_dmm' a few lines above. Fixes: 7cb0d6c1 ("drm/omap: fix TILER on OMAP5") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Andrey Gusakov authored
[ Upstream commit 4dbd6c03 ] Use drm_dp_channel_eq_ok helper Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Andrey Gusakov <andrey.gusakov@cogentembedded.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-7-git-send-email-andrey.gusakov@cogentembedded.comSigned-off-by:
-
Andrey Gusakov authored
[ Upstream commit 9217c1ab ] First four bytes should go to DP0_AUXWDATA0. Due to bug if len > 4 first four bytes was writen to DP0_AUXWDATA1 and all data get shifted by 4 bytes. Fix it. Acked-by:
-
Andrey Gusakov authored
[ Upstream commit 66d1c3b9 ] Fields in HTIM01 and HTIM02 regs should be even. Recomended thresh_dly value is max_tu_symbol. Remove set of VPCTRL0.VSDELAY as it is related to DSI input interface. Currently driver supports only DPI. Acked-by:
-
Andrey Gusakov authored
[ Upstream commit f3b8adbe ] Remove shift from TU_SIZE_RECOMMENDED define as it used to calculate max_tu_symbols. Acked-by:
-
Andrey Gusakov authored
[ Upstream commit 99fc8e96 ] Pixel clock limitation for DPI is 154 MHz. Do not accept modes with higher pixel clock rate. Reviewed-by:
-
Andrey Gusakov authored
[ Upstream commit cffd2b16 ] Do not fail data rates higher than 2.7 and more than 2 lanes. Try to fall back to 2.7Gbps and 2 lanes. Acked-by:
-
Yisheng Xie authored
[ Upstream commit bde5f6bc ] kmemleak_scan() will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] Call Trace: kmemleak_scan+0x21a/0x4c0 kmemleak_write+0x312/0x350 full_proxy_write+0x5a/0xa0 __vfs_write+0x33/0x150 vfs_write+0xad/0x1a0 SyS_write+0x52/0xc0 do_syscall_64+0x61/0x1a0 entry_SYSCALL64_slow_path+0x25/0x25 Fix this by adding cond_resched every MAX_SCAN_SIZE. Link: http://lkml.kernel.org/r/1511439788-20099-1-git-send-email-xieyisheng1@huawei.comSigned-off-by:
Yisheng Xie <xieyisheng1@huawei.com> Suggested-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 4ba161a7 ] Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Tested-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Tetsuo Handa authored
[ Upstream commit 88bc0ede ] register_shrinker() might return -ENOMEM error since Linux 3.12. Call panic() as with other failure checks in this function if register_shrinker() failed. Fixes: 1d3d4437 ("vmscan: per-node deferred work") Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Jan Kara <jack@suse.com> Cc: Michal Hocko <mhocko@suse.com> Reviewed-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 15bfe05c ] On 64-bit (e.g. powerpc64/allmodconfig): drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer. Note that several other fields in struct cdmac_bd are also too small to hold physical addresses on 64-bit platforms. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Christian König authored
[ Upstream commit 6edc6910 ] Never try to move pinned BOs during CS. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
