summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-04-14net: dsa: mt7530: Add support for EEE featuresRené van Dorst2-1/+56
This patch adds EEE support. Signed-off-by: René van Dorst <opensource@vdorst.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-14Merge drm/drm-fixes into drm-nextDaniel Vetter456-1872/+3351
msm-next pull request has a baseline with stuff from -fixes, roll forward first. Some simple conflicts in amdgpu, ttm and one in i915 where git gets confused and tries to add the same function twice. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-04-14Merge tag 'wireless-drivers-next-2021-04-13' of ↵David S. Miller50-871/+2709
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.13 First set of patches for v5.13. I have been offline for a couple of and I have a smaller pull request this time. The next one will be bigger. Nothing really special standing out. ath11k * add initial support for QCN9074, but not enabled yet due to firmware problems * enable radar detection for 160MHz secondary segment * handle beacon misses in station mode rtw88 * 8822c: support firmware crash dump mt7601u * enable TDLS support ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-14Merge tag 'fixes-for-5.12-rc7' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fix from Richard Weinberger: "Fix WAITRDY break condition and timeout in mtk nand driver" * tag 'fixes-for-5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: mtk: Fix WAITRDY break condition and timeout
2021-04-13remoteproc: qcom: wcss: Fix return value check in q6v5_wcss_init_mmio()Wei Yongjun1-2/+2
In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 0af65b9b915e ("remoteproc: qcom: wcss: Add non pas wcss Q6 support for QCS404") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210319094100.4185044-1-weiyongjun1@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-04-13remoteproc: pru: Fix and cleanup firmware interrupt mapping logicSuman Anna1-5/+17
The PRU firmware interrupt mappings are configured and unconfigured in .start() and .stop() callbacks respectively using the variables 'evt_count' and a 'mapped_irq' pointer. These variables are modified only during these callbacks but are not re-initialized/reset properly during unwind or failure paths. These stale values caused a kernel crash while stopping a PRU remoteproc running a different firmware with no events on a subsequent run after a previous run that was running a firmware with events. Fix this crash by ensuring that the evt_count is 0 and the mapped_irq pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these variables properly during any failures in the .start() callback. While at this, the pru_dispose_irq_mapping() callsites are all made to look the same, moving any conditional logic to inside the function. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") Reported-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210407155641.5501-4-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-04-13remoteproc: pru: Fix wrong success return value for fw eventsSuman Anna1-2/+4
The irq_create_fwspec_mapping() returns a proper virq value on success and 0 upon any failure. The pru_handle_intrmap() treats this as an error and disposes all firmware event mappings correctly, but is returning this incorrect value as is, letting the pru_rproc_start() interpret it as a success and boot the PRU. Fix this by returning an error value back upon any such failure. While at this, revise the error trace to print some meaningful info about the failed event. Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20210407155641.5501-3-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-04-13remoteproc: pru: Fixup interrupt-parent logic for fw eventsSuman Anna1-3/+12
The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses of_irq_find_parent() with PRU device node to get a handle to the PRUSS Interrupt Controller at present. This logic however requires that the PRU nodes always define a interrupt-parent property. This property is neither a required/defined property as per the PRU remoteproc binding, nor is relevant from a DT node point of view without any associated interrupts. The current logic finds a wrong interrupt controller and fails to perform proper mapping without any interrupt-parent property in the PRU nodes. Fix this logic to always find and use the sibling interrupt controller. Also, while at this, fix the acquired interrupt controller device node reference properly. Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration") Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20210407155641.5501-2-s-anna@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-04-13ice: Fix potential infinite loop when using u8 loop counterColin Ian King1-2/+2
A for-loop is using a u8 loop counter that is being compared to a u32 cmp_dcbcfg->numapp to check for the end of the loop. If cmp_dcbcfg->numapp is larger than 255 then the counter j will wrap around to zero and hence an infinite loop occurs. Fix this by making counter j the same type as cmp_dcbcfg->numapp. Addresses-Coverity: ("Infinite loop") Fixes: aeac8ce864d9 ("ice: Recognize 860 as iSCSI port in CEE mode") Signed-off-by: Colin Ian King <colin.king@canonical.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-04-13ixgbe: fix unbalanced device enable/disable in suspend/resumeYongxin Liu1-0/+5
pci_disable_device() called in __ixgbe_shutdown() decreases dev->enable_cnt by 1. pci_enable_device_mem() which increases dev->enable_cnt by 1, was removed from ixgbe_resume() in commit 6f82b2558735 ("ixgbe: use generic power management"). This caused unbalanced increase/decrease. So add pci_enable_device_mem() back. Fix the following call trace. ixgbe 0000:17:00.1: disabling already-disabled device Call Trace: __ixgbe_shutdown+0x10a/0x1e0 [ixgbe] ixgbe_suspend+0x32/0x70 [ixgbe] pci_pm_suspend+0x87/0x160 ? pci_pm_freeze+0xd0/0xd0 dpm_run_callback+0x42/0x170 __device_suspend+0x114/0x460 async_suspend+0x1f/0xa0 async_run_entry_fn+0x3c/0xf0 process_one_work+0x1dd/0x410 worker_thread+0x34/0x3f0 ? cancel_delayed_work+0x90/0x90 kthread+0x14c/0x170 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 Fixes: 6f82b2558735 ("ixgbe: use generic power management") Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-04-13ixgbe: Fix NULL pointer dereference in ethtool loopback testAlexander Duyck1-1/+8
The ixgbe driver currently generates a NULL pointer dereference when performing the ethtool loopback test. This is due to the fact that there isn't a q_vector associated with the test ring when it is setup as interrupts are not normally added to the test rings. To address this I have added code that will check for a q_vector before returning a napi_id value. If a q_vector is not present it will return a value of 0. Fixes: b02e5a0ebb17 ("xsk: Propagate napi_id to XDP socket Rx path") Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Acked-by: Björn Töpel <bjorn.topel@intel.com> Tested-by: Dave Switzer <david.switzer@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-04-13IB/hfi1: Rework AIP and VNIC dummy netdev usageMike Marciniszyn5-116/+105
All other users of the dummy netdevice embed the netdev in other structures: init_dummy_netdev(&mal->dummy_dev); init_dummy_netdev(&eth->dummy_dev); init_dummy_netdev(&ar->napi_dev); init_dummy_netdev(&irq_grp->napi_ndev); init_dummy_netdev(&wil->napi_ndev); init_dummy_netdev(&trans_pcie->napi_dev); init_dummy_netdev(&dev->napi_dev); init_dummy_netdev(&bus->mux_dev); The AIP and VNIC implementation turns that model inside out and used a kfree() to free what appears to be a netdev struct when in reality, it is a struct that enbodies the rx state as well as the dummy netdev used to support napi_poll across disparate receive contexts. The relationship is infered by the odd allocation: const int netdev_size = sizeof(*dd->dummy_netdev) + sizeof(struct hfi1_netdev_priv); <snip> dd->dummy_netdev = kcalloc_node(1, netdev_size, GFP_KERNEL, dd->node); Correct the issue by: - Correctly naming the alloc and free functions - Renaming hfi1_netdev_priv to hfi1_netdev_rx - Replacing dd dummy_netdev with a netdev_rx pointer - Embedding the net_device in hfi1_netdev_rx - Moving the init_dummy_netdev to the alloc routine - Adjusting wrappers to fit the new model Fixes: 6991abcb993c ("IB/hfi1: Add functions to receive accelerated ipoib packets") Link: https://lore.kernel.org/r/1617026056-50483-11-git-send-email-dennis.dalessandro@cornelisnetworks.com Reviewed-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-04-13Merge remote-tracking branch 'coresight/next-ETE-TRBE' into kvmarm-master/nextMarc Zyngier2-2/+2
Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-04-13USB: cdc-acm: add more Maxlinear/Exar models to ignore listMauro Carvalho Chehab1-3/+11
Now that the xr_serial got support for other models, add their USB IDs as well. The Maxlinear/Exar USB UARTs can be used in either ACM mode using the cdc-acm driver or in "custom driver" mode in which further features such as hardware and software flow control, GPIO control and in-band line-status reporting are available. In ACM mode the device always enables RTS/CTS flow control, something which could prevent transmission in case the CTS input isn't wired up correctly. Ensure that cdc_acm will not bind to these devices if the custom USB-serial driver is enabled. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/5155887a764cbc11f8da0217fe08a24a77d120b4.1616571453.git.mchehab+huawei@kernel.org [ johan: rewrite commit message, clean up entries ] Cc: Oliver Neukum <oneukum@suse.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: add copyright noticeJohan Hovold1-0/+1
Add another copyright notice for the work done in 2021. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: reset FIFOs on openJohan Hovold1-0/+51
Reset the transmit and receive FIFOs before enabling the UARTs as part of open() in order to flush any stale data. Note that the XR21V141X needs a type-specific implementation due to its UART Manager registers. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: add support for XR22801, XR22802, XR22804Johan Hovold1-0/+23
The XR22801, XR22802 and XR22804 are compound devices with an embedded hub and up to seven downstream USB devices including one, two or four UARTs respectively. The UART function is similar to XR21B142X but most registers are offset by 0x40, the register requests are different and are directed at the device rather than interface, and 5 and 6-bit words are not supported. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: add support for XR21B1411Johan Hovold1-16/+48
The single-port XR21B1411 is similar to the XR21B142X type but uses 12-bit registers and 16-bit register addresses, the register requests are different and are directed at the device rather than interface, and 5 and 6-bit words are not supported. The register layout is very similar to XR21B142X except that most registers are offset by 0xc00 (corresponding to a channel index of 12 in the MSB of wIndex). As the device is single-port so that the derived channel index is 0, the current register accessors can be reused after simply changing the address width. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: add support for XR21B1421, XR21B1422 and XR21B1424Johan Hovold1-76/+262
The XR21B1421, XR21B1422 and XR21B1424 are the one-, two- and four-port models of a second XR21B142X type of the Maxlinear/Exar USB UARTs. The XR21B142X type differs from XR21V141X in several ways, including: - register layout - register width (16-bit instead of 8-bit) - vendor register requests - UART enable/disable sequence - custom-driver mode flag - three additional GPIOs (9 instead of 6) As for XR21V141X, the XR21B142X vendor requests encode the channel index in the MSB of wIndex, but it lacks the UART Manager registers which have been replaced by regular UART registers. The new type also uses the interface number of the control interface (0, 2, 4, 6) as channel index instead of the channel number (0, 1, 2, 3). The XR21B142X lacks the divisor and format registers used by XR21V141X and instead uses the CDC SET_LINE_CONTROL request to configure the line settings. Note that the currently supported XR21V141X type lacks the custom-driver mode flag that prevents the device from entering CDC-ACM mode when a CDC requests is received. This specifically means that the SET_LINE_CONTROL request cannot be used with XR21V141X even though it is otherwise supported. The UART enable sequence for XR21B142X does not involve explicitly enabling the FIFOs, but according to datasheet the UART must be disabled when writing any register but GPIO_SET, GPIO_CLEAR, TX_BREAK and ERROR_STATUS. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: add type abstractionJohan Hovold1-43/+85
There are at least four types of Maxlinear/Exar USB UARTs which differ in various ways such as in their register layouts: XR21V141X XR21B142X XR21B1411 XR22804 It is not clear whether the device type can be inferred from the descriptors so encode it in the device-id table for now. Add a type structure that can be used to abstract the register layout and other features, and use it when accessing the XR21V141X UART registers that are shared by all types. Note that the currently supported XR21V141X type is the only type that has a set of UART Manager registers and that these will need to be handled specifically. Similarly, XR21V141X is the only type which has the divisor registers and that needs to use the format register when configuring the line settings. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: drop type prefix from shared definesJohan Hovold1-61/+61
In preparation for adding support for further types, drop the type prefix from defines that are not specific to XR21V141X. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: move pin configuration to probeJohan Hovold1-8/+37
There's no need to configure the pins on every open and judging from the vendor driver and datasheet it can be done before enabling the UART. Move pin configuration from open() to port probe and make sure to deassert DTR and RTS after configuring all pins as GPIO. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: rename GPIO-pin definesJohan Hovold1-17/+17
Rename the GPIO-pin defines so that they reflect how they are used. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: rename GPIO-mode definesJohan Hovold1-7/+7
Rename the GPIO mode defines so that they reflect the datasheet and how they are used. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: xr: add support for XR21V1412 and XR21V1414Johan Hovold1-4/+51
Add support for the two- and four-port variants of XR21V1410. Use the interface number of each control interface (e.g. 0, 2, 4, 6) to derive the zero-based channel index: XR21V1410 0 XR21V1412 0, 1 XR21V1414 0, 1, 2, 3 Note that the UART registers reside in separate blocks per channel, while the UART Manager functionality is implemented using per-channel registers. Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: clean up termios CSIZE handlingJohan Hovold1-8/+8
Remove the random white space from the CSIZE switch. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: use kernel types consistentlyJohan Hovold1-17/+17
Replace the remaining uses of user-space __XX types. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: add port-command helpersJohan Hovold1-50/+44
Add two port-command helpers to handle the UART module-id parameter instead of open coding. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: clean up vendor-request helpersJohan Hovold1-8/+7
Make the vendor-request helpers data parameters be void pointers and drop the caller casts. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: drop unnecessary packed attributesJohan Hovold1-4/+4
Drop unnecessary packed attributes from structures that don't need it. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: io_ti: drop unnecessary packed attributesJohan Hovold2-4/+4
Drop unnecessary packed attributes from structures that don't need it and use the __packed macro consistently. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: io_ti: use kernel types consistentlyJohan Hovold2-71/+71
Use kernel types consistently by replacing the remaining __uXX types. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: io_ti: add read-port-command helperJohan Hovold1-6/+9
Add a read-port-command helper analogous to the send-port-command helper to take care of the UART module id instead of open coding. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: io_ti: add send-port-command helperJohan Hovold1-28/+13
Add a send-port-command helper which takes care of determining the UART module id when sending commands instead of doing so at every call site. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: io_ti: clean up vendor-request helpersJohan Hovold1-7/+6
Clean up the vendor-request helpers by using kernel-types consistently and using void pointers for the data arguments, which allows removing a cast from one caller. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: drop drain delay for 3410Johan Hovold1-3/+14
Unlike the TUSB5052, the TUSB3410 has an LSR TEMT bit to tell if both the transmitter data and shift registers are empty. Make sure to check also the shift register on TUSB3410 when waiting for the transmit buffer to drain during close and drop the time-based one-char delay which is otherwise needed (e.g. 90 ms at 110 bps). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: ti_usb_3410_5052: reduce drain delay to one charJohan Hovold1-1/+5
The three-character drain delay was added by commit f1175daa5312 ("USB: ti_usb_3410_5052: kill custom closing_wait") when removing the custom closing-wait implementation, which used a fixed 20 ms poll period and drain delay. This was likely a bit too conservative as a one-character timeout (e.g. 33 ms at 300 bps) should be enough to compensate for the lack of a transmitter empty bit in the TUSB5052 line-status register. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: io_ti: document reason for drain delayJohan Hovold1-0/+4
Document that the device line-status register doesn't tell when the transmitter shift register has emptied and that this is why the one-character drain delay is needed. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13USB: serial: f81232: drop time-based drain delayJohan Hovold1-1/+0
The f81232 driver now waits for the transmit FIFO to drain during close so there is no need to keep the time-based drain delay, which would add up to two seconds on every close for low line speeds. Fixes: 98405f81036d ("USB: serial: f81232: add tx_empty function") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-04-13RDMA/qib: Remove useless qib_read_ureg() functionJiapeng Chong1-22/+0
Fix the following clang warning: drivers/infiniband/hw/qib/qib_iba7322.c:803:19: warning: unused function 'qib_read_ureg' [-Wunused-function]. Link: https://lore.kernel.org/r/1618305063-29007-1-git-send-email-jiapeng.chong@linux.alibaba.com Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-04-13RDMA/hns: Remove unnecessary flush operation for workqueueYixian Liu2-3/+0
As a flush operation is implemented inside destroy_workqueue(), there is no need to do flush operation before. Fixes: bfcc681bd09d ("IB/hns: Fix the bug when free mr") Fixes: 0425e3e6e0c7 ("RDMA/hns: Support flush cqe for hip08 in kernel space") Link: https://lore.kernel.org/r/1618305087-30799-1-git-send-email-liweihang@huawei.com Signed-off-by: Yixian Liu <liuyixian@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-04-13coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()Wei Yongjun1-1/+1
In case of error, the function devm_kasprintf() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210409094901.1903622-1-weiyongjun1@huawei.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2021-04-13coresight: core: Make symbol 'csdev_sink' staticWei Yongjun1-1/+1
The sparse tool complains as follows: drivers/hwtracing/coresight/coresight-core.c:26:1: warning: symbol '__pcpu_scope_csdev_sink' was not declared. Should it be static? As csdev_sink is not used outside of coresight-core.c after the introduction of coresight_[set|get]_percpu_sink() helpers, this change marks it static. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210409094900.1902783-1-weiyongjun1@huawei.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2021-04-13lightnvm: deprecated OCSSD support and schedule it for removal in Linux 5.15Christoph Hellwig2-1/+5
Lightnvm was an innovative idea to expose more low-level control over SSDs. But it failed to get properly standardized and remains a non-standarized extension to NVMe that requires vendor specific quirks for a few now mostly obsolete SSD devices. The standardized ZNS command set for NVMe has take over a lot of the approaches and allows for fully standardized operation. Remove the Linux code to support open channel SSDs as the few production deployments of the above mentioned SSDs are using userspace driver stacks instead of the fairly limited Linux support. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Javier González <javier@javigon.com> Signed-off-by: Matias Bjørling <mb@lightnvm.io> Link: https://lore.kernel.org/r/20210413105257.159260-5-matias.bjorling@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-13lightnvm: return the correct return valueTian Tao1-1/+1
When memdup_user returns an error, memdup_user has two different return values, use PTR_ERR to get the correct return value. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Matias Bjørling <matias.bjorling@wdc.com> Link: https://lore.kernel.org/r/20210413105257.159260-3-matias.bjorling@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-13lightnvm: use kobj_to_dev()Chaitanya Kulkarni1-1/+1
This fixs coccicheck warning: drivers/nvme//host/lightnvm.c:1243:60-61: WARNING opportunity for kobj_to_dev() Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Matias Bjørling <matias.bjorling@wdc.com> Link: https://lore.kernel.org/r/20210413105257.159260-2-matias.bjorling@wdc.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-04-13memory: mtk-smi: Add device-link between smi-larb and smi-commonYong Wu1-9/+10
Normally, If the smi-larb HW need work, we should enable the smi-common HW power and clock firstly. This patch adds device-link between the smi-larb dev and the smi-common dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync (smi-common-dev) will be called automatically. Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when probe. CC: Matthias Brugger <matthias.bgg@gmail.com> Suggested-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210410091128.31823-5-yong.wu@mediatek.com
2021-04-13memory: samsung: exynos5422-dmc: handle clk_set_parent() failureKrzysztof Kozlowski1-1/+3
clk_set_parent() can fail and ignoring such case could lead to invalid clock setup for given frequency. Addresses-Coverity: Unchecked return value Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20210407154535.70756-1-krzysztof.kozlowski@canonical.com
2021-04-13memory: renesas-rpc-if: fix possible NULL pointer dereference of resourceKrzysztof Kozlowski1-1/+1
The platform_get_resource_byname() can return NULL which would be immediately dereferenced by resource_size(). Instead dereference it after validating the resource. Addresses-Coverity: Dereference null return value Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210407154357.70200-1-krzysztof.kozlowski@canonical.com
2021-04-13Merge branch 'kvm-arm64/vlpi-save-restore' into kvmarm-master/nextMarc Zyngier1-2/+16
Signed-off-by: Marc Zyngier <maz@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-18 08:24:19 +0300