linux-stable.git/drivers, branch v5.4.76

PM: runtime: Resume the device earlier in __device_release_driver()

2020-11-10T11:37:34+00:00

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 
Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Cc: All applicable  # All applicable
Tested-by: Xiang Chen 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

PM: runtime: Drop pm_runtime_clean_up_links()

2020-11-10T11:37:34+00:00

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 
Cc: 5.1+  # 5.1+
Tested-by: Xiang Chen 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

PM: runtime: Drop runtime PM references to supplier on link removal

2020-11-10T11:37:34+00:00

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 
Cc: 5.1+  # 5.1+
Tested-by: Xiang Chen 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Fix a deadlock between the shrinker and madvise path

2020-11-10T11:37:33+00:00

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: 
Cc: Christian Hewitt 
Reported-by: Christian Hewitt 
Signed-off-by: Boris Brezillon 
Reviewed-by: Steven Price 
Link: https://patchwork.freedesktop.org/patch/msgid/20201101174016.839110-1-boris.brezillon@collabora.com
Signed-off-by: Greg Kroah-Hartman

usb: mtu3: fix panic in mtu3_gadget_stop()

2020-11-10T11:37:33+00:00

commit 20914919ad31849ee2b9cfe0428f4a20335c9e2a upstream.

This patch fixes a possible issue when mtu3_gadget_stop()
already assigned NULL to mtu->gadget_driver during mtu_gadget_disconnect().

[] notifier_call_chain+0xa4/0x128
[] __atomic_notifier_call_chain+0x84/0x138
[] notify_die+0xb0/0x120
[] die+0x1f8/0x5d0
[] __do_kernel_fault+0x19c/0x280
[] do_bad_area+0x44/0x140
[] do_translation_fault+0x4c/0x90
[] do_mem_abort+0xb8/0x258
[] el1_da+0x24/0x3c
[] mtu3_gadget_disconnect+0xac/0x128
[] mtu3_irq+0x34c/0xc18
[] __handle_irq_event_percpu+0x2ac/0xcd0
[] handle_irq_event_percpu+0x80/0x138
[] handle_irq_event+0xac/0x148
[] handle_fasteoi_irq+0x234/0x568
[] generic_handle_irq+0x48/0x68
[] __handle_domain_irq+0x264/0x1740
[] gic_handle_irq+0x14c/0x250
[] el1_irq+0xec/0x194
[] dma_pool_alloc+0x6e4/0xae0
[] cmdq_mbox_pool_alloc_impl+0xb0/0x238
[] cmdq_pkt_alloc_buf+0x2dc/0x7c0
[] cmdq_pkt_add_cmd_buffer+0x178/0x270
[] cmdq_pkt_perf_begin+0x108/0x148
[] cmdq_pkt_create+0x178/0x1f0
[] mtk_crtc_config_default_path+0x328/0x7a0
[] mtk_drm_idlemgr_kick+0xa6c/0x1460
[] mtk_drm_crtc_atomic_begin+0x1a4/0x1a68
[] drm_atomic_helper_commit_planes+0x154/0x878
[] mtk_atomic_complete.isra.16+0xe80/0x19c8
[] mtk_atomic_commit+0x258/0x898
[] drm_atomic_commit+0xcc/0x108
[] drm_mode_atomic_ioctl+0x1c20/0x2580
[] drm_ioctl_kernel+0x118/0x1b0
[] drm_ioctl+0x5c0/0x920
[] do_vfs_ioctl+0x188/0x1820
[] SyS_ioctl+0x8c/0xa0

Fixes: df2069acb005 ("usb: Add MediaTek USB3 DRD driver")
Signed-off-by: Macpaul Lin 
Acked-by: Chunfeng Yun 
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

USB: Add NO_LPM quirk for Kingston flash drive

2020-11-10T11:37:33+00:00

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 
CC: 
Reported-and-tested-by: Julien Humbert 
Signed-off-by: Alan Stern 
Link: https://lore.kernel.org/r/20201102145821.GA1478741@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: ep0: Fix delay status handling

2020-11-10T11:37:33+00:00

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: 
Fixes: d97c78a1908e ("usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command")
Signed-off-by: Thinh Nguyen 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

tty: serial: fsl_lpuart: LS1021A has a FIFO size of 16 words, like LS1028A

2020-11-10T11:37:33+00:00

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 
Signed-off-by: Vladimir Oltean 
Link: https://lore.kernel.org/r/20201023013429.3551026-1-vladimir.oltean@nxp.com
Reviewed-by：Fugang Duan 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: serial: fsl_lpuart: add LS1028A support

2020-11-10T11:37:33+00:00

commit c2f448cff22a7ed09281f02bde084b0ce3bc61ed upstream.

The LS1028A uses little endian register access and has a different FIFO
size encoding.

Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20200306214433.23215-4-michael@walle.cc
Signed-off-by: Greg Kroah-Hartman

USB: serial: option: add Telit FN980 composition 0x1055

2020-11-10T11:37:33+00:00

commit db0362eeb22992502764e825c79b922d7467e0eb upstream.

Add the following Telit FN980 composition:

0x1055: tty, adb, tty, tty, tty, tty

Signed-off-by: Daniele Palmas 
Link: https://lore.kernel.org/r/20201103124425.12940-1-dnlplm@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman