- 04 Jan, 2021 6 commits
-
-
Arnd Bergmann authored
Without crc32 support, this driver fails to link: arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_eem.o: in function `eem_unwrap': f_eem.c:(.text+0x11cc): undefined reference to `crc32_le' arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_ncm.o:f_ncm.c:(.text+0x1e40): more undefined references to `crc32_le' follow Fixes: 6d3865f9 ("usb: gadget: NCM: Add transmit multi-frame.") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210103214224.1996535-1-arnd@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
The pullup does not need to be enabled at below situations: - For platforms which the hardware pullup starts after setting register even they do not see the VBUS. If the pullup is always enabled for these platforms, it will consume more power and break the USB IF compliance tests [1]. - For platforms which need to do BC 1.2 charger detection after seeing the VBUS. Pullup D+ will break the charger detection flow. - For platforms which the system suspend is allowed when the connection with host is there but the bus is not at suspend. For these platforms, it is better to disable pullup when entering the system suspend otherwise the host may confuse the device behavior after controller is in low power mode. Disable pullup is considered as a disconnection event from host side. [1] USB-IF Full and Low Speed Compliance Test Procedure F Back-voltage Testing Section 7.2.1 of the USB specification requires that no device shall supply (source) current on VBUS at its upstream facing port at any time. From VBUS on its upstream facing port, a device may only draw (sink) current. They may not provide power to the pull-up resistor on D+/D- unless VBUS is present (see Section 7.1.5). Signed-off-by:
Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20201230051114.21370-1-peter.chen@nxp.comSigned-off-by:
-
Eddie Hung authored
There is a use-after-free issue, if access udc_name in function gadget_dev_desc_UDC_store after another context free udc_name in function unregister_gadget. Context 1: gadget_dev_desc_UDC_store()->unregister_gadget()-> free udc_name->set udc_name to NULL Context 2: gadget_dev_desc_UDC_show()-> access udc_name Call trace: dump_backtrace+0x0/0x340 show_stack+0x14/0x1c dump_stack+0xe4/0x134 print_address_description+0x78/0x478 __kasan_report+0x270/0x2ec kasan_report+0x10/0x18 __asan_report_load1_noabort+0x18/0x20 string+0xf4/0x138 vsnprintf+0x428/0x14d0 sprintf+0xe4/0x12c gadget_dev_desc_UDC_show+0x54/0x64 configfs_read_file+0x210/0x3a0 __vfs_read+0xf0/0x49c vfs_read+0x130/0x2b4 SyS_read+0x114/0x208 el0_svc_naked+0x34/0x38 Add mutex_lock to protect this kind of scenario. Signed-off-by:
Eddie Hung <eddie.hung@mediatek.com> Signed-off-by:
Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by:
-
Wesley Cheng authored
usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start operation, which may leave EP0 disabled and event IRQs disabled when re-activating the function. Move the enabling/disabling of USB EP0 and device event IRQs to be performed in the pullup routine. Fixes: ae7e8610 ("usb: dwc3: Stop active transfers before halting the controller") Tested-by:
Michael Tretter <m.tretter@pengutronix.de> Cc: stable <stable@vger.kernel.org> Reported-by:
Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1609282837-21666-1-git-send-email-wcheng@codeaurora.orgSigned-off-by:
-
Randy Dunlap authored
Fix shift out-of-bounds in vhci_hcd.c: UBSAN: shift-out-of-bounds in ../drivers/usb/usbip/vhci_hcd.c:399:41 shift exponent 768 is too large for 32-bit type 'int' Fixes: 03cd00d5 ("usbip: vhci-hcd: Set the vhci structure up to work") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by: syzbot+297d20e437b79283bf6d@syzkaller.appspotmail.com Cc: Yuyang Du <yuyang.du@intel.com> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201229071309.18418-1-rdunlap@infradead.orgSigned-off-by:
-
Johan Hovold authored
Stack-allocated buffers cannot be used for DMA (on all architectures). Replace the HP-channel macro with a helper function that allocates a dedicated transfer buffer so that it can continue to be used with arguments from the stack. Note that the buffer is cleared on allocation as usblp_ctrl_msg() returns success also on short transfers (the buffer is only used for debugging). Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210104145302.2087-1-johan@kernel.orgSigned-off-by:
-
- 30 Dec, 2020 1 commit
-
-
Alan Stern authored
The dummy-hcd driver was written under the assumption that all the parameters in URBs sent to its root hub would be valid. With URBs sent from userspace via usbfs, that assumption can be violated. In particular, the driver doesn't fully check the port-feature values stored in the wValue entry of Clear-Port-Feature and Set-Port-Feature requests. Values that are too large can cause the driver to perform an invalid left shift of more than 32 bits. Ironically, two of those left shifts are unnecessary, because they implement Set-Port-Feature requests that hubs are not required to support, according to section 11.24.2.13 of the USB-2.0 spec. This patch adds the appropriate checks for the port feature selector values and removes the unnecessary feature settings. It also rejects requests to set the TEST feature or to set or clear the INDICATOR and C_OVERCURRENT features, as none of these are relevant to dummy-hcd's root-hub emulation. CC: <stable@vger.kernel.org> Reported-and-tested-by: syzbot+5925509f78293baa7331@syzkaller.appspotmail.com Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20201230162044.GA727759@rowland.harvard.eduSigned-off-by:
-
- 28 Dec, 2020 18 commits
-
-
Jerome Brunet authored
With commit 913e4a90 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth") wMaxPacketSize is computed dynamically but the value is never reset. Because of this, the actual maximum packet size can only decrease each time the audio gadget is instantiated. Reset the endpoint maximum packet size and mark wMaxPacketSize as dynamic to solve the problem. Fixes: 913e4a90 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201221173531.215169-2-jbrunet@baylibre.comSigned-off-by:
-
Serge Semin authored
First of all the commit e0082698 ("usb: dwc3: ulpi: conditionally resume ULPI PHY") introduced the Suspend USB2.0 HS/FS/LS PHY regression, as by design of the fix any attempt to read/write from/to the PHY control registers will completely disable the PHY suspension, which consequently will increase the USB bus power consumption. Secondly the fix won't work well for the very first attempt of the ULPI PHY control registers IO, because after disabling the USB2.0 PHY suspension functionality it will still take some time for the bus to resume from the sleep state if one has been reached before it. So the very first PHY register read/write operation will take more time than the busy-loop provides and the IO timeout error might be returned anyway. Here we suggest to fix the denoted problems in the following way. First of all let's not disable the Suspend USB2.0 HS/FS/LS PHY functionality so to make the controller and the USB2.0 bus more power efficient. Secondly instead of that we'll extend the PHY IO op wait procedure with 1 - 1.2 ms sleep if the PHY suspension is enabled (1ms should be enough as by LPM specification it is at most how long it takes for the USB2.0 bus to resume from L1 (Sleep) state). Finally in case if the USB2.0 PHY suspension functionality has been disabled on the DWC USB3 controller setup procedure we'll compensate the USB bus resume process latency by extending the busy-loop attempts counter. Fixes: e0082698 ("usb: dwc3: ulpi: conditionally resume ULPI PHY") Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201210085008.13264-4-Sergey.Semin@baikalelectronics.ru Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Serge Semin authored
Originally the procedure of the ULPI transaction finish detection has been developed as a simple busy-loop with just decrementing counter and no delays. It's wrong since on different systems the loop will take a different time to complete. So if the system bus and CPU are fast enough to overtake the ULPI bus and the companion PHY reaction, then we'll get to take a false timeout error. Fix this by converting the busy-loop procedure to take the standard bus speed, address value and the registers access mode into account for the busy-loop delay calculation. Here is the way the fix works. It's known that the ULPI bus is clocked with 60MHz signal. In accordance with [1] the ULPI bus protocol is created so to spend 5 and 6 clock periods for immediate register write and read operations respectively, and 6 and 7 clock periods - for the extended register writes and reads. Based on that we can easily pre-calculate the time which will be needed for the controller to perform a requested IO operation. Note we'll still preserve the attempts counter in case if the DWC USB3 controller has got some internals delays. [1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1, October 20, 2004, pp. 30 - 36. Fixes: 88bc9d19 ("usb: dwc3: add ULPI interface support") Acked-by: -
Serge Semin authored
In accordance with [1] the DWC_usb3 core sets the GUSB2PHYACCn.VStsDone bit when the PHY vendor control access is done and clears it when the application initiates a new transaction. The doc doesn't say anything about the GUSB2PHYACCn.VStsBsy flag serving for the same purpose. Moreover we've discovered that the VStsBsy flag can be cleared before the VStsDone bit. So using the former as a signal of the PHY control registers completion might be dangerous. Let's have the VStsDone flag utilized instead then. [1] Synopsys DesignWare Cores SuperSpeed USB 3.0 xHCI Host Controller Databook, 2.70a, December 2013, p.388 Fixes: 88bc9d19 ("usb: dwc3: add ULPI interface support") Acked-by: -
Johan Hovold authored
Make sure to always cancel the control URB in write() so that it can be reused after a timeout or spurious CMD_ACK. Currently any further write requests after a timeout would fail after triggering a WARN() in usb_submit_urb() when attempting to submit the already active URB. Reported-by: syzbot+e87ebe0f7913f71f2ea5@syzkaller.appspotmail.com Fixes: 6bc235a2 ("USB: add driver for Meywa-Denki & Kayac YUREX") Cc: stable <stable@vger.kernel.org> # 2.6.37 Signed-off-by:
-
Yu Kuai authored
if of_find_device_by_node() succeed, usbmisc_get_init_data() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation. Fixes: ef12da91 ("usb: chipidea: imx: properly check for usbmisc") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201117011430.642589-1-yukuai3@huawei.comSigned-off-by:
-
Manish Narani authored
Fix the MTU size issue with RX packet size as the host sends the packet with extra bytes containing ethernet header. This causes failure when user sets the MTU size to the maximum i.e. 15412. In this case the ethernet packet received will be of length 15412 plus the ethernet header length. This patch fixes the issue where there is a check that RX packet length must not be more than max packet length. Fixes: bba787a8 ("usb: gadget: ether: Allow jumbo frames") Signed-off-by:
Manish Narani <manish.narani@xilinx.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1605597215-122027-1-git-send-email-manish.narani@xilinx.comSigned-off-by:
-
Yang Yingliang authored
If usb_otg_descriptor_alloc() failed, it need return ENOMEM. Fixes: 578aa8a2 ("usb: gadget: acm_ms: allocate and init otg descriptor by otg capabilities") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201117092955.4102785-1-yangyingliang@huawei.comSigned-off-by:
-
Sriharsha Allenki authored
There is a spinlock lockup as part of composite_disconnect when it tries to acquire cdev->lock as part of usb_gadget_deactivate. This is because the usb_gadget_deactivate is called from usb_function_deactivate with the same spinlock held. This would result in the below call stack and leads to stall. rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: 3-...0: (1 GPs behind) idle=162/1/0x4000000000000000 softirq=10819/10819 fqs=2356 (detected by 2, t=5252 jiffies, g=20129, q=3770) Task dump for CPU 3: task:uvc-gadget_wlhe state:R running task stack: 0 pid: 674 ppid: 636 flags:0x00000202 Call trace: __switch_to+0xc0/0x170 _raw_spin_lock_irqsave+0x84/0xb0 composite_disconnect+0x28/0x78 configfs_composite_disconnect+0x68/0x70 usb_gadget_disconnect+0x10c/0x128 usb_gadget_deactivate+0xd4/0x108 usb_function_deactivate+0x6c/0x80 uvc_function_disconnect+0x20/0x58 uvc_v4l2_release+0x30/0x88 v4l2_release+0xbc/0xf0 __fput+0x7c/0x230 ____fput+0x14/0x20 task_work_run+0x88/0x140 do_notify_resume+0x240/0x6f0 work_pending+0x8/0x200 Fix this by doing an unlock on cdev->lock before the usb_gadget_deactivate call from usb_function_deactivate. The same lockup can happen in the usb_gadget_activate path. Fix that path as well. Reported-by:
Sriharsha Allenki <sallenki@codeaurora.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201202130220.24926-1-sallenki@codeaurora.orgSigned-off-by:
-
Zqiang authored
When printer driver is loaded, the printer_func_bind function is called, in this function, the interface descriptor be allocated memory, if after that, the error occurred, the interface descriptor memory need to be free. Reviewed-by:
Zqiang <qiang.zhang@windriver.com> Link: https://lore.kernel.org/r/20201210020148.6691-1-qiang.zhang@windriver.comSigned-off-by:
-
Zheng Zengkai authored
dwc3_meson_g12a_probe() does not invoke clk_bulk_disable_unprepare() on one error handling path. This patch fixes that. Fixes: 347052e3 ("usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and A1 SoCs") Reported-by:
Zheng Zengkai <zhengzengkai@huawei.com> Cc: stable <stable@vger.kernel.org> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20201215025459.91794-1-zhengzengkai@huawei.comSigned-off-by:
-
Michael Grzeschik authored
The commit 0472bf06 ("xhci: Prevent U1/U2 link pm states if exit latency is too long") was constraining the xhci code not to allow U1/U2 sleep states if the latency to wake up from the U-states reached the service interval of an periodic endpoint. This fix was not taking into account that in case the quirk XHCI_INTEL_HOST is set, the wakeup time will be calculated and configured differently. It checks for u1_params.mel/u2_params.mel as a limit. But the code could decide to write another MEL into the hardware. This leads to broken cases where not enough bandwidth is available for other devices: usb 1-2: can't set config #1, error -28 This patch is fixing that case by checking for timeout_ns after the wakeup time was calculated depending on the quirks. Fixes: 0472bf06 ("xhci: Prevent U1/U2 link pm states if exit latency is too long") Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201215193147.11738-1-m.grzeschik@pengutronix.deSigned-off-by:
-
Madhusudanarao Amara authored
Warm reboot scenarios some times type C Mux driver gets Mux configuration request as HPD=1,IRQ=1. In that scenario typeC Mux driver need to configure Mux as follows as per IOM requirement: (1). Confgiure Mux HPD = 1, IRQ = 0 (2). Configure Mux with HPD = 1, IRQ = 1 IOM expects TypeC Mux configuration as follows: (1). HPD=1, IRQ=0 (2). HPD=1, IRQ=1 if IOM gets mux config request (2) without configuring (1), it will ignore the request. The impact of this is there is no DP_alt mode display. Fixes: 43d596e3 ("usb: typec: intel_pmc_mux: Check the port status before connect") Cc: stable@vger.kernel.org Reviewed-by:
Madhusudanarao Amara <madhusudanarao.amara@intel.com> Link: https://lore.kernel.org/r/20201216140918.49197-1-madhusudanarao.amara@intel.comSigned-off-by:
-
Tetsuo Handa authored
syzbot is reporting UAF at usb_submit_urb() [1], for service_outstanding_interrupt() is not checking WDM_DISCONNECTING before calling usb_submit_urb(). Close the race by doing same checks wdm_read() does upon retry. Also, while wdm_read() checks WDM_DISCONNECTING with desc->rlock held, service_interrupt_work() does not hold desc->rlock. Thus, it is possible that usb_submit_urb() is called from service_outstanding_interrupt() from service_interrupt_work() after WDM_DISCONNECTING was set and kill_urbs() from wdm_disconnect() completed. Thus, move kill_urbs() in wdm_disconnect() to after cancel_work_sync() (which makes sure that service_interrupt_work() is no longer running) completed. Although it seems to be safe to dereference desc->intf->dev in service_outstanding_interrupt() even if WDM_DISCONNECTING was already set because desc->rlock or cancel_work_sync() prevents wdm_disconnect() from reaching list_del() before service_outstanding_interrupt() completes, let's not emit error message if WDM_DISCONNECTING is set by wdm_disconnect() while usb_submit_urb() is in progress. [1] https://syzkaller.appspot.com/bug?extid=9e04e2df4a32fb661dafReported-by:
syzbot <syzbot+9e04e2df4a32fb661daf@syzkaller.appspotmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/620e2ee0-b9a3-dbda-a25b-a93e0ed03ec5@i-love.sakura.ne.jpSigned-off-by:
-
Fabio Estevam authored
Since 5.10-rc1 i.MX is a devicetree-only platform, and this driver was only used by the old non-DT i.MX devices. Remove the driver as it has no users left. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
-
Aswath Govindraju authored
Add compatible string in j721e-usb binding file as the same USB subsystem is present in AM64. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20201215042549.7956-1-a-govindraju@ti.comSigned-off-by:
-
Roger Quadros authored
Updates my email address for Cadence USB3 driver. Signed-off-by:
Roger Quadros <rogerq@ti.com> Link: https://lore.kernel.org/r/20201218105736.17667-1-rogerq@ti.comSigned-off-by:
-
Sean Young authored
This device is supported by the IR Toy driver. Reported-by:
Georgi Bakalski <georgi.bakalski@gmail.com> Signed-off-by:
Sean Young <sean@mess.org> Acked-by:
Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201227134502.4548-2-sean@mess.orgSigned-off-by:
-
- 27 Dec, 2020 8 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Since commit 36e2c742 ("fs: don't allow splice read/write without explicit ops") we've required that file operation structures explicitly enable splice support, rather than falling back to the default handlers. Most /proc files use the indirect 'struct proc_ops' to describe their file operations, and were fixed up to support splice earlier in commits 40be821d..b24c30c6, but the mountinfo files interact with the VFS directly using their own 'struct file_operations' and got missed as a result. This adds the necessary support for splice to work for /proc/*/mountinfo and friends. Reported-by:
Joan Bruguera Micó <joanbrugueram@gmail.com> Reported-by:
Jussi Kivilinna <jussi.kivilinna@iki.fi> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209971 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://github.com/jonmason/ntbLinus Torvalds authored
Pull NTB fixes from Jon Mason: "Bug fix for IDT NTB and Intel NTB LTR management support" * tag 'ntb-5.11' of git://github.com/jonmason/ntb: ntb: intel: add Intel NTB LTR vendor support for gen4 NTB ntb: idt: fix error check in ntb_hw_idt.c
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fixes from Herbert Xu: "Fix a number of autobuild failures due to missing Kconfig dependencies" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: qat - add CRYPTO_AES to Kconfig dependencies crypto: keembay - Add dependency on HAS_IOMEM crypto: keembay - CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAY
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull objtool fix from Ingo Molnar: "Fix a segfault that occurs when built with Clang" * tag 'objtool-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Fix seg fault with Clang non-section symbols
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fixes from Ingo Molnar: "Misc fixes/updates: - Fix static keys usage in module __init sections - Add separate MAINTAINERS entry for static branches/calls - Fix lockdep splat with CONFIG_PREEMPTIRQ_EVENTS=y tracing" * tag 'locking-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: softirq: Avoid bad tracing / lockdep interaction jump_label/static_call: Add MAINTAINERS jump_label: Fix usage in module __init
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Ingo Molnar: "Update/fix two CPU sanity checks in the hotplug and the boot code, and fix a typo in the Kconfig help text. [ Context: the first two commits are the result of an ongoing annotation+review work of (intentional) tick_do_timer_cpu() data races reported by KCSAN, but the annotations aren't fully cooked yet ]" * tag 'timers-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping: Fix spelling mistake in Kconfig "fullfill" -> "fulfill" tick/sched: Remove bogus boot "safety" check tick: Remove pointless cpu valid check in hotplug code -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fix from Ingo Molnar: "Fix a context switch performance regression" * tag 'sched-urgent-2020-12-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched: Optimize finish_lock_switch()
-
- 26 Dec, 2020 5 commits
-
-
Linus Torvalds authored
Commit c9a3c4e6 ("mfd: ab8500-debugfs: Remove extraneous curly brace") removed a left-over curly brace that caused build failures, but Joe Perches points out that the subsequent 'seq_putc()' should also be removed, because the commit that caused all these problems already added the final '\n' to the seq_printf() above it. Reported-by:
Joe Perches <joe@perches.com> Fixes: 886c8121 ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc") Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fixes from Bjorn Helgaas: - Fix a tegra enumeration regression (Rob Herring) - Fix a designware-host check that warned on *success*, not failure (Alexander Lobakin) * tag 'pci-v5.11-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: dwc: Fix inverted condition of DMA mask setup warning PCI: tegra: Fix host link initialization
-
Nathan Chancellor authored
Clang errors: drivers/mfd/ab8500-debugfs.c:1526:2: error: non-void function does not return a value [-Werror,-Wreturn-type] } ^ drivers/mfd/ab8500-debugfs.c:1528:2: error: expected identifier or '(' return 0; ^ drivers/mfd/ab8500-debugfs.c:1529:1: error: extraneous closing brace ('}') } ^ 3 errors generated. The cleanup in ab8500_interrupts_show left a curly brace around, remove it to fix the error. Fixes: 886c8121 ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc") Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Alexander Lobakin authored
Commit 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation") added dma_mask_set() call to explicitly set 32-bit DMA mask for MSI message mapping, but for now it throws a warning on ret == 0, while dma_set_mask() returns 0 in case of success. Fix this by inverting the condition. [bhelgaas: join string to make it greppable] Fixes: 660c4865 ("PCI: dwc: Set 32-bit DMA mask for MSI target address allocation") Link: https://lore.kernel.org/r/20201222150708.67983-1-alobakin@pm.meSigned-off-by:
Alexander Lobakin <alobakin@pm.me> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com>
-
Rob Herring authored
Commit b9ac0f9d ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code") broke enumeration of downstream devices on Tegra: In non-working case (next-20201211): 0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1) 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13) 0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1) In working case (v5.10-rc7): 0001:00:00.0 PCI bridge: Molex Incorporated Device 1ad2 (rev a1) 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13) 0005:00:00.0 PCI bridge: Molex Incorporated Device 1ad0 (rev a1) 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab) 0005:02:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab) 0005:03:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab) The problem seems to be dw_pcie_setup_rc() is now called twice before and after the link up handling. The fix is to move Tegra's link up handling to .start_link() function like other DWC drivers. Tegra is a bit more complicated than others as it re-inits the whole DWC controller to retry the link. With this, the initialization ordering is restored to match the prior sequence. Fixes: b9ac0f9d ("PCI: dwc: Move dw_pcie_setup_rc() to DWC common code") Link: https://lore.kernel.org/r/20201218143905.1614098-1-robh@kernel.orgReported-by:
Mian Yousaf Kaukab <ykaukab@suse.de> Tested-by:
-
- 25 Dec, 2020 2 commits
-
-
Linus Torvalds authored
clang (quite rightly) complains fairly loudly about the newly added mpc1_get_mpc_out_mux() function returning an uninitialized value if the 'opp_id' checks don't pass. This may not happen in practice, but the code really shouldn't return garbage if the sanity checks don't pass. So just initialize 'val' to zero to avoid the issue. Fixes: 110b055b ("drm/amd/display: add getter routine to retrieve mpcc mux") Cc: Josip Pavic <Josip.Pavic@amd.com> Cc: Bindu Ramamurthy <bindu.r@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linuxLinus Torvalds authored
Pull more perf tools updates from Arnaldo Carvalho de Melo: - Refactor 'perf stat' per CPU/socket/die/thread aggregation fixing use cases in ARM machines. - Fix memory leak when synthesizing SDT probes in 'perf probe'. - Update kernel header copies related to KVM, epol_pwait. msr-index and powerpc and s390 syscall tables. * tag 'perf-tools-2020-12-24' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (24 commits) perf probe: Fix memory leak when synthesizing SDT probes perf stat aggregation: Add separate thread member perf stat aggregation: Add separate core member perf stat aggregation: Add separate die member perf stat aggregation: Add separate socket member perf stat aggregation: Add separate node member perf stat aggregation: Start using cpu_aggr_id in map perf cpumap: Drop in cpu_aggr_map struct perf cpumap: Add new map type for aggregation perf stat: Replace aggregation ID with a struct perf cpumap: Add new struct for cpu aggregation perf cpumap: Use existing allocator to avoid using malloc perf tests: Improve topology test to check all aggregation types perf tools: Update s390's syscall.tbl copy from the kernel sources perf tools: Update powerpc's syscall.tbl copy from the kernel sources perf s390: Move syscall.tbl check into check-headers.sh perf powerpc: Move syscall.tbl check to check-headers.sh tools headers UAPI: Synch KVM's svm.h header with the kernel tools kvm headers: Update KVM headers from the kernel sources tools headers UAPI: Sync KVM's vmx.h header with the kernel sources ...
-
