summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-02-01tty: serial: fsl_lpuart: set rxiden in non dma casetoradex_5.4-2.1.x-imxMax Krummenacher
In the case of not using edma set the RXIDEN field. This sets the RDRF flag even if there are received characters in the FIFO and the receiver has been idle for the specified number of characters. Related-to: ELB-3517 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2021-02-01tty: serial: fsl_lpuart: fix uart baud divider overflowMax Krummenacher
For low baudrates the uart baudrate divider can overflow, i.e. the sbr register must stay within [1..8191]. With an input frequency of 80MHz and a baudrate of 1200 the following register settings are calculated. sbr: 16666, osr: 4 Fix this. Related-to: ELB-3517 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2021-01-07regulator: pfuze100: fix system hang on suspendOleksandr Suvorov
The shutdown() callback of i2c client device calls for both scenarios, power off and reboot the system. In case of rebooting, the PMIC is configured to power off the power rails when receiveing the PMIC_STBY_REQ request. It leads to powering the module down and system hanging while suspending the system after soft reboot. Remove the shutdown() callback. Moreover, it is not needed now as the power-down preparation of PMIC is done in the pfuze_power_off_prepare() function. Related-to: ELB-3473 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-12-28mfd: stmpe: Support disabling sub-functionsOleksandr Suvorov
Add support of sub-functions disabling. It allows one to define an stmpe sub-function device in devicetree, but keep it disabled. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-12-28Revert "mfd: stmpe: support disabling sub-functions"Oleksandr Suvorov
This solution is replaced with better upstream one. This reverts commit 4daa584ef919a58b90e1957012ffb6eaad5dc6bd. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-12-24pci: pci-imx6: fix kernel hanging on imx6qOleksandr Suvorov
The resume from a suspend state on SoC i.MX6Q leads to a kernel hanging. Adding a 10ms delay after clearing the bit TEST_POWERDOWN of IOMUXC_GPR1 regiater fixes this issue. There is not enough information about the testing "powerdown" mode on i.MX6Q, but we can do some assumption. According to "49.6.1.2 Power-On Reset" section of the "i.MX6D/6Q APRM", the time between bringing up the PHY power supplies and the reference clock is up and stable is (< 10ms) + (> 10mks) ~= 10ms. So using this value seems reasonable. Related-to: ELB-3012 Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-12-23media: imx8: ar0521 and ar1335 supportMarcel Ziswiler
Add drivers for e-con Systems AR0521 and AR1335 camera modules. Related to: PMS-387 Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2020-12-14net: stmmac: dwmac-imx: fix phy-supply null pointer issueMarcel Ziswiler
The following happens e.g. on the i.MX 8M Plus EVK which does not specify any phy-supply: [ 1.077851] imx-dwmac 30bf0000.ethernet: no regulator found [ 1.083445] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078 [ 1.092234] Mem abort info: [ 1.095033] ESR = 0x96000004 [ 1.098087] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.103402] SET = 0, FnV = 0 [ 1.106456] EA = 0, S1PTW = 0 [ 1.109603] Data abort info: [ 1.112489] ISV = 0, ISS = 0x00000004 [ 1.116329] CM = 0, WnR = 0 [ 1.119301] [0000000000000078] user address but active_mm is swapper [ 1.125660] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 1.131232] Modules linked in: [ 1.134291] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.4.77-05639-g581745444980 #10 [ 1.142032] Hardware name: NXP i.MX8MPlus EVK board (DT) [ 1.147344] pstate: 60000005 (nZCv daif -PAN -UAO) [ 1.152141] pc : regulator_enable+0x1c/0x78 [ 1.156326] lr : imx_dwmac_init+0x134/0x1a8 [ 1.160508] sp : ffff80001003bad0 Fixes: ca8811172bdc ("net: stmmac: dwmac-imx: add phy-supply") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
2020-12-08i2c: imx: implement master_xfer_atomic callbackStefan Lengfeld
Rework the read and write code paths in the driver to support operation in atomic contexts. To achieve this, the driver must not rely on IRQs and not call schedule(), e.g. via a sleep routine, in these cases. With this patch the driver supports normal operation, DMA transfers and now the polling mode or also called sleep-free or IRQ-less operation. It makes the code not simpler or easier to read, but atomic I2C transfers are needed on some hardware configurations, e.g. to trigger reboots on an external PMIC chip. Related-to: ELB-3308 Related-to: ELB-1403 Signed-off-by: Stefan Lengfeld <contact@stefanchrist.eu> [m.felsch@pengutronix.de: integrate https://patchwork.ozlabs.org/patch/1085943/ review feedback] [m.felsch@pengutronix.de: adapt commit message] Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Stefan Agner <stefan@agner.ch> Tested-by: Stefan Lengfeld <contact@stefanchrist.eu> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> (cherry picked from commit 3a5ee18d2a32bda6b9a1260136f6805848e3839d)
2020-11-26MLK-24410 phy: pcie: imx8mp: correct the clock mode of the pcie phyRichard Zhu
Correct the clock mode of PCIe PHY. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Fugang Duan <fugang.duan@nxp.com> (cherry picked from commit 2c23d9de9fc41d5436a7d3f8510fc95f3bf1c56b)
2020-11-26MLK-24171-5 PCI: imx8mp: verify the pcie internal pll reference clockRichard Zhu
- Verify the both internal PLL_SYS and external OSC reference clock modes on iMX8MP EVK board, and pass the PCIe compliance tests. - Remove the no-needed bypass setting. - PHY configration should be completed before CMN_RSTN is set to 1b1 - To manually initiate the speed change to make sure GEN2 is linked up: - Write to LINK_CONTROL2_LINK_STATUS2_REG.PCIE_CAP_TARGET_LINK_SPEED in the local device - De-assert GEN2_CTRL_OFF.DIRECT_SPEED_CHANGE in the local device - Assert GEN2_CTRL_OFF.DIRECT_SPEED_CHANGE in the local device Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Fugang Duan <fugang.duan@nxp.com> (cherry picked from commit 12589ba98b1145e2d2a9f439b20064197aea8ca9)
2020-11-26MLK-24171-4 reset: imx7: add perst for imx8mp pcieRichard Zhu
Add the PERST for iMX8MP PCIe. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Fugang Duan <fugang.duan@nxp.com> (cherry picked from commit 0a91df355e20aa53a4bcaa9d352952e5fa9e4ef6)
2020-11-26MLK-24171-3 phy: pcie: imx8mp: verify the pll sys ref clock sourceRichard Zhu
Verify the PCIe PLL_SYS reference clock source on EVK board. The external OSC clock is used as PCIe REF clock source in default. - sequence should be the following one. phy configuration--> CMN_RSTN--> wait for pll lock - add the calibrate callback to fit the correct init sequence of phy Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Fugang Duan <fugang.duan@nxp.com> (cherry picked from commit 9afaf7a465858970aee8858fb52067f2ef152c7f)
2020-11-26MLK-24170 PCI: imx: configure the l1 latency for imx8m pcie rcRichard Zhu
Configure the L1 latency of iMX8M's RC to less than 64us, otherwise, the L1/L1SS wouldn't be enabled by ASPM. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Fugang Duan <fugang.duan@nxp.com> (cherry picked from commit eb9fdb1d10c10dc4d4bbe9bc6fc060afe1485989)
2020-11-25mfd: stmpe: support disabling sub-functionsOleksandr Suvorov
Add support of sub-functions disabling. It allows one to define and turn on sub-function devices in different devicetree files. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-11-25net: stmmac: dwmac-imx: add phy-supplyMax Krummenacher
Add an support for an optional regulator which powers an attached phy. Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-11-19Merge commit '685021f75fc48afaf6de76280a601316cde827c2' into ↵Igor Opaniuk
toradex_5.4-2.1.x-imx
2020-11-19Merge tag 'v5.4.77' into 5.4-2.1.x-imxIgor Opaniuk
This is the 5.4.77 stable release Merge conflicts: Merged automatically, no conflicts Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
2020-11-17Merge branch 'toradex_5.4-2.1.x-imx' into HEADIgor Opaniuk
2020-11-13net: wireless: cfg80211: delete sched_scan error messagePhilippe Schenker
Do not print an error. This is no error in our use-case so just delete this error message that confuses users. As we now move back to full loglevel this is the only way to get rid of that message. fixes: d182137f18f24de3bc4b45c5a3d52e2f8f96a093 net: wireless: cfg80211: decrease importance of sched_scan message Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
2020-11-13Merge commit '70d1232fdbe28e4c765c4cfc3cc5c7580959d5e0' into ↵Igor Opaniuk
toradex_5.4-2.1.x-imx Update 5.4-2.1.x-imx to v5.4.74 from [1]. [1] https://github.com/Freescale/linux-fslc
2020-11-11MLK-24521: drm: bridge: hdmi: Prevent the driver from rejecting VIC 0 modesOliver F. Brown
iMX8QM can support the non CEA modes, iMX8M cannot support non CEA modes. So driver should allow non CEA modes for iMX8QM. Signed-off-by: Oliver F. Brown <oliver.brown@nxp.com> Reviewed-by: Liu Ying <victor.liu@nxp.com> (cherry picked from commit 863af2196cb53200f50b1d04c6eb90d04262b0e4) Related-to: ELB-3237 Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-11-10powercap: restrict energy meter to root accessLen Brown
commit 949dd0104c496fa7c14991a23c03c62e44637e71 upstream. Remove non-privileged user access to power data contained in /sys/class/powercap/intel-rapl*/*/energy_uj Non-privileged users currently have read access to power data and can use this data to form a security attack. Some privileged drivers/applications need read access to this data, but don't expose it to non-privileged users. For example, thermald uses this data to ensure that power management works correctly. Thus removing non-privileged access is preferred over completely disabling this power reporting capability with CONFIG_INTEL_RAPL=n. Fixes: 95677a9a3847 ("PowerCap: Fix mode for energy counter") Signed-off-by: Len Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10Merge tag 'v5.4.76' into 5.4-2.1.x-imxAndrey Zhizhikin
This is the 5.4.76 stable release Conflicts: - drivers/tty/serial/fsl_lpuart.c: Fix merge conflict of upstream patches [86875e1d6426] and [8febdfb5973d], which contradicted with patch [cde0cb39c0e8e] from NXP. Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2020-11-10PM: runtime: Resume the device earlier in __device_release_driver()Rafael J. Wysocki
commit 9226c504e364158a17a68ff1fe9d67d266922f50 upstream. Since the device is resumed from runtime-suspend in __device_release_driver() anyway, it is better to do that before looking for busy managed device links from it to consumers, because if there are any, device_links_unbind_consumers() will be called and it will cause the consumer devices' drivers to unbind, so the consumer devices will be runtime-resumed. In turn, resuming each consumer device will cause the supplier to be resumed and when the runtime PM references from the given consumer to it are dropped, it may be suspended. Then, the runtime-resume of the next consumer will cause the supplier to resume again and so on. Update the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support") Cc: All applicable <stable@vger.kernel.org> # All applicable Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10PM: runtime: Drop pm_runtime_clean_up_links()Rafael J. Wysocki
commit d6e36668598154820177bfd78c1621d8e6c580a2 upstream. After commit d12544fb2aa9 ("PM: runtime: Remove link state checks in rpm_get/put_supplier()") nothing prevents the consumer device's runtime PM from acquiring additional references to the supplier device after pm_runtime_clean_up_links() has run (or even while it is running), so calling this function from __device_release_driver() may be pointless (or even harmful). Moreover, it ignores stateless device links, so the runtime PM handling of managed and stateless device links is inconsistent because of it, so better get rid of it entirely. Fixes: d12544fb2aa9 ("PM: runtime: Remove link state checks in rpm_get/put_supplier()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10PM: runtime: Drop runtime PM references to supplier on link removalRafael J. Wysocki
commit e0e398e204634db8fb71bd89cf2f6e3e5bd09b51 upstream. While removing a device link, drop the supplier device's runtime PM usage counter as many times as needed to drop all of the runtime PM references to it from the consumer in addition to dropping the consumer's link count. Fixes: baa8809f6097 ("PM / runtime: Optimize the use of device links") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10drm/panfrost: Fix a deadlock between the shrinker and madvise pathBoris Brezillon
commit 7d2d6d01293e6d9b42a6cb410be4158571f7fe9d upstream. panfrost_ioctl_madvise() and panfrost_gem_purge() acquire the mappings and shmem locks in different orders, thus leading to a potential the mappings lock first. Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept") Cc: <stable@vger.kernel.org> Cc: Christian Hewitt <christianshewitt@gmail.com> Reported-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201101174016.839110-1-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10usb: mtu3: fix panic in mtu3_gadget_stop()Macpaul Lin
commit 20914919ad31849ee2b9cfe0428f4a20335c9e2a upstream. This patch fixes a possible issue when mtu3_gadget_stop() already assigned NULL to mtu->gadget_driver during mtu_gadget_disconnect(). [<ffffff9008161974>] notifier_call_chain+0xa4/0x128 [<ffffff9008161fd4>] __atomic_notifier_call_chain+0x84/0x138 [<ffffff9008162ec0>] notify_die+0xb0/0x120 [<ffffff900809e340>] die+0x1f8/0x5d0 [<ffffff90080d03b4>] __do_kernel_fault+0x19c/0x280 [<ffffff90080d04dc>] do_bad_area+0x44/0x140 [<ffffff90080d0f9c>] do_translation_fault+0x4c/0x90 [<ffffff9008080a78>] do_mem_abort+0xb8/0x258 [<ffffff90080849d0>] el1_da+0x24/0x3c [<ffffff9009bde01c>] mtu3_gadget_disconnect+0xac/0x128 [<ffffff9009bd576c>] mtu3_irq+0x34c/0xc18 [<ffffff90082ac03c>] __handle_irq_event_percpu+0x2ac/0xcd0 [<ffffff90082acae0>] handle_irq_event_percpu+0x80/0x138 [<ffffff90082acc44>] handle_irq_event+0xac/0x148 [<ffffff90082b71cc>] handle_fasteoi_irq+0x234/0x568 [<ffffff90082a8708>] generic_handle_irq+0x48/0x68 [<ffffff90082a96ac>] __handle_domain_irq+0x264/0x1740 [<ffffff90080819f4>] gic_handle_irq+0x14c/0x250 [<ffffff9008084cec>] el1_irq+0xec/0x194 [<ffffff90085b985c>] dma_pool_alloc+0x6e4/0xae0 [<ffffff9008d7f890>] cmdq_mbox_pool_alloc_impl+0xb0/0x238 [<ffffff9008d80904>] cmdq_pkt_alloc_buf+0x2dc/0x7c0 [<ffffff9008d80f60>] cmdq_pkt_add_cmd_buffer+0x178/0x270 [<ffffff9008d82320>] cmdq_pkt_perf_begin+0x108/0x148 [<ffffff9008d824d8>] cmdq_pkt_create+0x178/0x1f0 [<ffffff9008f96230>] mtk_crtc_config_default_path+0x328/0x7a0 [<ffffff90090246cc>] mtk_drm_idlemgr_kick+0xa6c/0x1460 [<ffffff9008f9bbb4>] mtk_drm_crtc_atomic_begin+0x1a4/0x1a68 [<ffffff9008e8df9c>] drm_atomic_helper_commit_planes+0x154/0x878 [<ffffff9008f2fb70>] mtk_atomic_complete.isra.16+0xe80/0x19c8 [<ffffff9008f30910>] mtk_atomic_commit+0x258/0x898 [<ffffff9008ef142c>] drm_atomic_commit+0xcc/0x108 [<ffffff9008ef7cf0>] drm_mode_atomic_ioctl+0x1c20/0x2580 [<ffffff9008ebc768>] drm_ioctl_kernel+0x118/0x1b0 [<ffffff9008ebcde8>] drm_ioctl+0x5c0/0x920 [<ffffff900863b030>] do_vfs_ioctl+0x188/0x1820 [<ffffff900863c754>] SyS_ioctl+0x8c/0xa0 Fixes: df2069acb005 ("usb: Add MediaTek USB3 DRD driver") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1604642069-20961-1-git-send-email-macpaul.lin@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10USB: Add NO_LPM quirk for Kingston flash driveAlan Stern
commit afaa2e745a246c5ab95103a65b1ed00101e1bc63 upstream. In Bugzilla #208257, Julien Humbert reports that a 32-GB Kingston flash drive spontaneously disconnects and reconnects, over and over. Testing revealed that disabling Link Power Management for the drive fixed the problem. This patch adds a quirk entry for that drive to turn off LPM permanently. CC: Hans de Goede <jwrdegoede@fedoraproject.org> CC: <stable@vger.kernel.org> Reported-and-tested-by: Julien Humbert <julroy67@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20201102145821.GA1478741@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10usb: dwc3: ep0: Fix delay status handlingThinh Nguyen
commit fa27e2f6c5e674f3f1225f9ca7a7821faaf393bb upstream. If we want to send a control status on our own time (through delayed_status), make sure to handle a case where we may queue the delayed status before the host requesting for it (when XferNotReady is generated). Otherwise, the driver won't send anything because it's not EP0_STATUS_PHASE yet. To resolve this, regardless whether dwc->ep0state is EP0_STATUS_PHASE, make sure to clear the dwc->delayed_status flag if dwc3_ep0_send_delayed_status() is called. The control status can be sent when the host requests it later. Cc: <stable@vger.kernel.org> Fixes: d97c78a1908e ("usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10tty: serial: fsl_lpuart: LS1021A has a FIFO size of 16 words, like LS1028AVladimir Oltean
commit c97f2a6fb3dfbfbbc88edc8ea62ef2b944e18849 upstream. Prior to the commit that this one fixes, the FIFO size was derived from the read-only register LPUARTx_FIFO[TXFIFOSIZE] using the following formula: TX FIFO size = 2 ^ (LPUARTx_FIFO[TXFIFOSIZE] - 1) The documentation for LS1021A is a mess. Under chapter 26.1.3 LS1021A LPUART module special consideration, it mentions TXFIFO_SZ and RXFIFO_SZ being equal to 4, and in the register description for LPUARTx_FIFO, it shows the out-of-reset value of TXFIFOSIZE and RXFIFOSIZE fields as "011", even though these registers read as "101" in reality. And when LPUART on LS1021A was working, the "101" value did correspond to "16 datawords", by applying the formula above, even though the documentation is wrong again (!!!!) and says that "101" means 64 datawords (hint: it doesn't). So the "new" formula created by commit f77ebb241ce0 has all the premises of being wrong for LS1021A, because it relied only on false data and no actual experimentation. Interestingly, in commit c2f448cff22a ("tty: serial: fsl_lpuart: add LS1028A support"), Michael Walle applied a workaround to this by manually setting the FIFO widths for LS1028A. It looks like the same values are used by LS1021A as well, in fact. When the driver thinks that it has a deeper FIFO than it really has, getty (user space) output gets truncated. Many thanks to Michael for pointing out where to look. Fixes: f77ebb241ce0 ("tty: serial: fsl_lpuart: correct the FIFO depth size") Suggested-by: Michael Walle <michael@walle.cc> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20201023013429.3551026-1-vladimir.oltean@nxp.com Reviewed-by：Fugang Duan <fugang.duan@nxp.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10tty: serial: fsl_lpuart: add LS1028A supportMichael Walle
commit c2f448cff22a7ed09281f02bde084b0ce3bc61ed upstream. The LS1028A uses little endian register access and has a different FIFO size encoding. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200306214433.23215-4-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10USB: serial: option: add Telit FN980 composition 0x1055Daniele Palmas
commit db0362eeb22992502764e825c79b922d7467e0eb upstream. Add the following Telit FN980 composition: 0x1055: tty, adb, tty, tty, tty, tty Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20201103124425.12940-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10USB: serial: option: add LE910Cx compositions 0x1203, 0x1230, 0x1231Daniele Palmas
commit 489979b4aab490b6b917c11dc02d81b4b742784a upstream. Add following Telit LE910Cx compositions: 0x1203: rndis, tty, adb, tty, tty, tty, tty 0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty 0x1231: rndis, tty, adb, audio, tty, tty, tty, tty Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20201031225458.10512-1-dnlplm@gmail.com [ johan: add comments after entries ] Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10USB: serial: option: add Quectel EC200T module supportZiyi Cao
commit a46b973bced1ba57420752bf38426acd9f6cbfa6 upstream. Add usb product id of the Quectel EC200T module. Signed-off-by: Ziyi Cao <kernel@septs.pw> Link: https://lore.kernel.org/r/17f8a2a3-ce0f-4be7-8544-8fdf286907d0@www.fastmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10USB: serial: cyberjack: fix write-URB completion raceJohan Hovold
commit 985616f0457d9f555fff417d0da56174f70cc14f upstream. The write-URB busy flag was being cleared before the completion handler was done with the URB, something which could lead to corrupt transfers due to a racing write request if the URB is resubmitted. Fixes: 507ca9bc0476 ("[PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.") Cc: stable <stable@vger.kernel.org> # 2.6.13 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10serial: txx9: add missing platform_driver_unregister() on error in ↵Qinglang Miao
serial_txx9_init commit 0c5fc92622ed5531ff324b20f014e9e3092f0187 upstream. Add the missing platform_driver_unregister() before return from serial_txx9_init in the error handling case when failed to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI defined. Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/") Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10serial: 8250_mtk: Fix uart_get_baud_rate warningClaire Chang
commit 912ab37c798770f21b182d656937072b58553378 upstream. Mediatek 8250 port supports speed higher than uartclk / 16. If the baud rates in both the new and the old termios setting are higher than uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered. Passing NULL as the old termios so uart_get_baud_rate() will use uartclk / 16 - 1 as the new baud rate which will be replaced by the original baud rate later by tty_termios_encode_baud_rate() in mtk8250_set_termios(). Fixes: 551e553f0d4a ("serial: 8250_mtk: Fix high-speed baud rates clamping") Signed-off-by: Claire Chang <tientzu@chromium.org> Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10s390/pkey: fix paes selftest failure with paes and pkey static buildHarald Freudenberger
commit 5b35047eb467c8cdd38a31beb9ac109221777843 upstream. When both the paes and the pkey kernel module are statically build into the kernel, the paes cipher selftests run before the pkey kernel module is initialized. So a static variable set in the pkey init function and used in the pkey_clr2protkey function is not initialized when the paes cipher's selftests request to call pckmo for transforming a clear key value into a protected key. This patch moves the initial setup of the static variable into the function pck_clr2protkey. So it's possible, to use the function for transforming a clear to a protected key even before the pkey init function has been called and the paes selftests may run successful. Reported-by: Alexander Egorenkov <Alexander.Egorenkov@ibm.com> Cc: <stable@vger.kernel.org> # 4.20 Fixes: f822ad2c2c03 ("s390/pkey: move pckmo subfunction available checks away from module init") Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10vt: Disable KD_FONT_OP_COPYDaniel Vetter
commit 3c4e0dff2095c579b142d5a0693257f1c58b4804 upstream. It's buggy: On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote: > We recently discovered a slab-out-of-bounds read in fbcon in the latest > kernel ( v5.10-rc2 for now ). The root cause of this vulnerability is that > "fbcon_do_set_font" did not handle "vc->vc_font.data" and > "vc->vc_font.height" correctly, and the patch > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this > issue. > > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and > use KD_FONT_OP_SET again to set a large font.height for tty1. After that, > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data > in "fbcon_do_set_font", while tty1 retains the original larger > height. Obviously, this will cause an out-of-bounds read, because we can > access a smaller vc_font.data with a larger vc_font.height. Further there was only one user ever. - Android's loadfont, busybox and console-tools only ever use OP_GET and OP_SET - fbset documentation only mentions the kernel cmdline font: option, not anything else. - systemd used OP_COPY before release 232 published in Nov 2016 Now unfortunately the crucial report seems to have gone down with gmane, and the commit message doesn't say much. But the pull request hints at OP_COPY being broken https://github.com/systemd/systemd/pull/3651 So in other words, this never worked, and the only project which foolishly every tried to use it, realized that rather quickly too. Instead of trying to fix security issues here on dead code by adding missing checks, fix the entire thing by removing the functionality. Note that systemd code using the OP_COPY function ignored the return value, so it doesn't matter what we're doing here really - just in case a lone server somewhere happens to be extremely unlucky and running an affected old version of systemd. The relevant code from font_copy_to_all_vcs() in systemd was: /* copy font from active VT, where the font was uploaded to */ cfo.op = KD_FONT_OP_COPY; cfo.height = vcs.v_active-1; /* tty1 == index 0 */ (void) ioctl(vcfd, KDFONTOP, &cfo); Note this just disables the ioctl, garbage collecting the now unused callbacks is left for -next. v2: Tetsuo found the old mail, which allowed me to find it on another archive. Add the link too. Acked-by: Peilin Ye <yepeilin.cs@gmail.com> Reported-by: Minh Yuan <yuanmingbuaa@gmail.com> References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html References: https://github.com/systemd/systemd/pull/3651 Cc: Greg KH <greg@kroah.com> Cc: Peilin Ye <yepeilin.cs@gmail.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://lore.kernel.org/r/20201108153806.3140315-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10Revert "coresight: Make sysfs functional on topologies with per core sink"Sasha Levin
This reverts commit 8fd52a21ab570e80f84f39e12affce42a5300e91. Guenter Roeck <linux@roeck-us.net> writes: I get the following build warning in v5.4.75. drivers/hwtracing/coresight/coresight-etm-perf.c: In function 'etm_setup_aux': drivers/hwtracing/coresight/coresight-etm-perf.c:226:37: warning: passing argument 1 of 'coresight_get_enabled_sink' makes pointer from integer without a cast Actually, the warning is fatal, since the call is sink = coresight_get_enabled_sink(true); However, the argument to coresight_get_enabled_sink() is now a pointer. The parameter change was introduced with commit 8fd52a21ab57 ("coresight: Make sysfs functional on topologies with per core sink"). In the upstream kernel, the call is removed with commit bb1860efc817 ("coresight: etm: perf: Sink selection using sysfs is deprecated"). That commit alone would, however, likely not solve the problem. It looks like at least two more commits would be needed. 716f5652a131 coresight: etm: perf: Fix warning caused by etm_setup_aux failure 8e264c52e1da coresight: core: Allow the coresight core driver to be built as a module 39a7661dcf65 coresight: Fix uninitialised pointer bug in etm_setup_aux() Looking into the coresight code, I see several additional commits affecting the sysfs interface since v5.4. I have no idea what would actually be needed for stable code in v5.4.y, short of applying them all. With all this in mind, I would suggest to revert commit 8fd52a21ab57 ("coresight: Make sysfs functional on topologies with per core sink") from v5.4.y, especially since it is not marked as bug fix or for stable. Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"Karol Herbst
[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ] we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/nouveau/nouveau: fix the start/end range for migrationRalph Campbell
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ] The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10usb: cdns3: gadget: suspicious implicit sign extensionPeter Chen
[ Upstream commit 5fca3f062879f8e5214c56f3e3e2be6727900f5d ] The code: trb->length = cpu_to_le32(TRB_BURST_LEN(priv_ep->trb_burst_size) | TRB_LEN(length)); TRB_BURST_LEN(priv_ep->trb_burst_size) may be overflow for int 32 if priv_ep->trb_burst_size is equal or larger than 0x80; Below is the Coverity warning: sign_extension: Suspicious implicit sign extension: priv_ep->trb_burst_size with type u8 (8 bits, unsigned) is promoted in priv_ep->trb_burst_size << 24 to type int (32 bits, signed), then sign-extended to type unsigned long (64 bits, unsigned). If priv_ep->trb_burst_size << 24 is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. To fix it, it needs to add an explicit cast to unsigned int type for ((p) << 24). Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10ACPI: NFIT: Fix comparison to '-ENXIO'Zhang Qilong
[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ] Initial value of rc is '-ENXIO', and we should use the initial value to check it. Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com> Reviewed-by: Vishal Verma <vishal.l.verma@intel.com> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/vc4: drv: Add error handding for bindHoegeun Kwon
[ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10nvmet: fix a NULL pointer dereference when tracing the flush commandChaitanya Kulkarni
[ Upstream commit 3c3751f2daf6675f6b5bee83b792354c272f5bd2 ] When target side trace in turned on and flush command is issued from the host it results in the following Oops. [ 856.789724] BUG: kernel NULL pointer dereference, address: 0000000000000068 [ 856.790686] #PF: supervisor read access in kernel mode [ 856.791262] #PF: error_code(0x0000) - not-present page [ 856.791863] PGD 6d7110067 P4D 6d7110067 PUD 66f0ad067 PMD 0 [ 856.792527] Oops: 0000 [#1] SMP NOPTI [ 856.792950] CPU: 15 PID: 7034 Comm: nvme Tainted: G OE 5.9.0nvme-5.9+ #71 [ 856.793790] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e3214 [ 856.794956] RIP: 0010:trace_event_raw_event_nvmet_req_init+0x13e/0x170 [nvmet] [ 856.795734] Code: 41 5c 41 5d c3 31 d2 31 f6 e8 4e 9b b8 e0 e9 0e ff ff ff 49 8b 55 00 48 8b 38 8b 0 [ 856.797740] RSP: 0018:ffffc90001be3a60 EFLAGS: 00010246 [ 856.798375] RAX: 0000000000000000 RBX: ffff8887e7d2c01c RCX: 0000000000000000 [ 856.799234] RDX: 0000000000000020 RSI: 0000000057e70ea2 RDI: ffff8887e7d2c034 [ 856.800088] RBP: ffff88869f710578 R08: ffff888807500d40 R09: 00000000fffffffe [ 856.800951] R10: 0000000064c66670 R11: 00000000ef955201 R12: ffff8887e7d2c034 [ 856.801807] R13: ffff88869f7105c8 R14: 0000000000000040 R15: ffff88869f710440 [ 856.802667] FS: 00007f6a22bd8780(0000) GS:ffff888813a00000(0000) knlGS:0000000000000000 [ 856.803635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 856.804367] CR2: 0000000000000068 CR3: 00000006d73e0000 CR4: 00000000003506e0 [ 856.805283] Call Trace: [ 856.805613] nvmet_req_init+0x27c/0x480 [nvmet] [ 856.806200] nvme_loop_queue_rq+0xcb/0x1d0 [nvme_loop] [ 856.806862] blk_mq_dispatch_rq_list+0x123/0x7b0 [ 856.807459] ? kvm_sched_clock_read+0x14/0x30 [ 856.808025] __blk_mq_sched_dispatch_requests+0xc7/0x170 [ 856.808708] blk_mq_sched_dispatch_requests+0x30/0x60 [ 856.809372] __blk_mq_run_hw_queue+0x70/0x100 [ 856.809935] __blk_mq_delay_run_hw_queue+0x156/0x170 [ 856.810574] blk_mq_run_hw_queue+0x86/0xe0 [ 856.811104] blk_mq_sched_insert_request+0xef/0x160 [ 856.811733] blk_execute_rq+0x69/0xc0 [ 856.812212] ? blk_mq_rq_ctx_init+0xd0/0x230 [ 856.812784] nvme_execute_passthru_rq+0x57/0x130 [nvme_core] [ 856.813461] nvme_submit_user_cmd+0xeb/0x300 [nvme_core] [ 856.814099] nvme_user_cmd.isra.82+0x11e/0x1a0 [nvme_core] [ 856.814752] blkdev_ioctl+0x1dc/0x2c0 [ 856.815197] block_ioctl+0x3f/0x50 [ 856.815606] __x64_sys_ioctl+0x84/0xc0 [ 856.816074] do_syscall_64+0x33/0x40 [ 856.816533] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 856.817168] RIP: 0033:0x7f6a222ed107 [ 856.817617] Code: 44 00 00 48 8b 05 81 cd 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 8 [ 856.819901] RSP: 002b:00007ffca848f058 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [ 856.820846] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f6a222ed107 [ 856.821726] RDX: 00007ffca848f060 RSI: 00000000c0484e43 RDI: 0000000000000003 [ 856.822603] RBP: 0000000000000003 R08: 000000000000003f R09: 0000000000000005 [ 856.823478] R10: 00007ffca848ece0 R11: 0000000000000202 R12: 00007ffca84912d3 [ 856.824359] R13: 00007ffca848f4d0 R14: 0000000000000002 R15: 000000000067e900 [ 856.825236] Modules linked in: nvme_loop(OE) nvmet(OE) nvme_fabrics(OE) null_blk nvme(OE) nvme_corel Move the nvmet_req_init() tracepoint after we parse the command in nvmet_req_init() so that we can get rid of the duplicate nvmet_find_namespace() call. Rename __assign_disk_name() -> __assign_req_name(). Now that we call tracepoint after parsing the command simplify the newly added __assign_req_name() which fixes this bug. Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10nvme-rdma: handle unexpected nvme completion data lengthzhenwei pi
[ Upstream commit 25c1ca6ecaba3b751d3f7ff92d5cddff3b05f8d0 ] Receiving a zero length message leads to the following warnings because the CQE is processed twice: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 0 at lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0xd9/0xe0 Call Trace: <IRQ> nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma] __ib_process_cq+0x76/0x150 [ib_core] ... Sanity check the received data length, to avoids this. Thanks to Chao Leng & Sagi for suggestions. Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10scsi: ibmvscsi: Fix potential race after loss of transportTyrel Datwyler
[ Upstream commit 665e0224a3d76f36da40bd9012270fa629aa42ed ] After a loss of transport due to an adapter migration or crash/disconnect from the host partner there is a tiny window where we can race adjusting the request_limit of the adapter. The request limit is atomically increased/decreased to track the number of inflight requests against the allowed limit of our VIOS partner. After a transport loss we set the request_limit to zero to reflect this state. However, there is a window where the adapter may attempt to queue a command because the transport loss event hasn't been fully processed yet and request_limit is still greater than zero. The hypercall to send the event will fail and the error path will increment the request_limit as a result. If the adapter processes the transport event prior to this increment the request_limit becomes out of sync with the adapter state and can result in SCSI commands being submitted on the now reset connection prior to an SRP Login resulting in a protocol violation. Fix this race by protecting request_limit with the host lock when changing the value via atomic_set() to indicate no transport. Link: https://lore.kernel.org/r/20201025001355.4527-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2025-01-12 08:06:57 +0000