| Age | Commit message (Collapse) | Author |
|---|
|
Toradex BSP 5.x uses the video/fbdev stack of display drivers.
Remove unused nodes for gpu/drm/imx stack of drivers.
Related-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
With the driver now supporting the phy-supply property, remove the
regulator-boot-on property.
The driver does not support the 'sleep' state pinctrl. Remove it.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
The PHY connected to the FEC doesn't have a seperate switchable rail.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Add an support for an optional regulator which powers an attached phy.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
CONFIG_CRYPTO_XTS is selcted (as 'y') by CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This adds back drivers enabled in the following 3 commits
commit e7704de31f0b ("arm64: defconfig: add zram support")
commit 08d125a06697 ("arm64: defconfig: add sound drivers for Gumstix AutoBSP")
commit f2bf706a88d6 ("arm64: defconfig: add bluetooth drivers for Gumstix AutoBSP")
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Only the Development Board gives access to the native hdmi signals.
Move the nodes into imx8mp-verdin-dev.dtsi.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
RX and TX seem to be swapped and the function is currently not
implemented. Mux the pins as GPIOs to ensure to not have two
connected outputs.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Use the correct clk as the mclk.
Additionally set the mux pad values to a more sensible value, i.e.
for inputs enable the pullup.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This device is described in an overlay. Removing this node here
fixes the kernel stuck if the colibri-imx7-aster_atmel-mxt_overlay is
applied.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
According to the decision to use overlays just for enabling
subsystems, add back the definition of Atmel MXT touchscreen device.
Related-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
The VGA interface and all related stuff enable in an overlay.
Remains them disabled in the main devicetree.
Realetd-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
Now HDMI interface is driven with an overlay, so that it is not needed to
configure hdmi_ddc on a board level.
Move all i2cddc/hdmi_ddc stuff to the module level and disable it by
default.
Related-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
The HDMI interface and all related stuff enable in an overlay.
Remains them disabled in the main devicetree.
Realetd-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
This device enables in an overlay. Remains it disabled here.
Realetd-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
PWM-part of the backlight device is the same for all Toradex boards.
Move all backlight properties to the module-level devicetree.
Remain the device disabled - it should be enabled in corresponding
overlays.
Related-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
The LCD (parallel RGB) and LVDS interfaces and all related stuff are
driven with overlays. This stuff is already disabled for Evaluation board.
Disable it for all versions of Ixora board as well.
Realetd-to: ELB-3240
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
On the i.MX 8M Plus the 3rd LCDIF drives an on-SoC Samsung HDMI PHY
giving us native HDMI functionality.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
On the i.MX 8M Plus the 3rd LCDIF drives an on-SoC Samsung HDMI PHY
giving us native HDMI functionality.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
At least the following of the configured devices work:
- Console
- eMMC
- ETH0
- ETH1
- SD_1
- USB_1 as peripheral, USB_2 as host
- CAN_1, CAN_2
Everything else is either known to not work or untested.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Enable CONFIG_STMMAC_ETH for the additional MAC in the i.MX8 M Plus.
Enable CONFIG_VLAN_8021Q/CONFIG_TSN for new features that MAC supports.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
toradex_5.4-2.1.x-imx
|
|
Update 5.4-2.1.x-imx to v5.4.77 from stable
|
|
This is the 5.4.77 stable release
Merge conflicts:
Merged automatically, no conflicts
Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
|
|
Use the predefined resource name of the PMIC thermal sensor.
Related-to: ELB-3037
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
|
|
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>
|
|
This reverts commit 2c7781c5d5d0b0c8b4c67f945fdf7e8992fb36b5.
We decided to go back to full loglevel so customers can see all messages
on boot.
Related-to: ELB-3183
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
|
|
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
|
|
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>
|
|
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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>
|
|
The VPU subsystem uses hardware Messaging Units (MU) for inter processor
communication with the controlling OS. The driver for the MU is implemented
as a Linux mailbox.
Enable the VPU MU in the device-tree.
Related-to: ELB-3196
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Update 5.4-2.1.x-imx to v5.4.76 from stable
|
|
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>
|
|
The touchscreen Atmel MXT TS is integrated to display panels.
Remove its definition from the main device trees.
Also release pingroups used in atmel mxt ts overlay from iomuxc driver.
Related-to: ELB-2943
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
|
|
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Link: https://lore.kernel.org/r/20201109125022.614792961@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b64d814257b027e29a474bcd660f6372490138c7 upstream.
Espressobin boards have 3 ethernet ports and some of them got assigned more
then one MAC address. MAC addresses are stored in U-Boot environment.
Since commit a2c7023f7075c ("net: dsa: read mac address from DT for slave
device") kernel can use MAC addresses from DT for particular DSA port.
Currently Espressobin DTS file contains alias just for ethernet0.
This patch defines additional ethernet aliases in Espressobin DTS files, so
bootloader can fill correct MAC address for DSA switch ports if more MAC
addresses were specified.
DT alias ethernet1 is used for wan port, DT aliases ethernet2 and ethernet3
are used for lan ports for both Espressobin revisions (V5 and V7).
Fixes: 5253cb8c00a6f ("arm64: dts: marvell: espressobin: add ethernet alias")
Cc: <stable@vger.kernel.org> # a2c7023f7075c: dsa: read mac address
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
[pali: Backported Espressobin rev V5 changes to 5.4 and 4.19 versions]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7bdb157cdebbf95a1cd94ed2e01b338714075d00 upstream.
As shown through runtime testing, the "filename" allocation is not
always freed in perf_event_parse_addr_filter().
There are three possible ways that this could happen:
- It could be allocated twice on subsequent iterations through the loop,
- or leaked on the success path,
- or on the failure path.
Clean up the code flow to make it obvious that 'filename' is always
freed in the reallocation path and in the two return paths as well.
We rely on the fact that kfree(NULL) is NOP and filename is initialized
with NULL.
This fixes the leak. No other side effects expected.
[ Dan Carpenter: cleaned up the code flow & added a changelog. ]
[ Ingo Molnar: updated the changelog some more. ]
Fixes: 375637bc5249 ("perf/core: Introduce address range filtering")
Signed-off-by: "kiyin(尹亮)" <kiyin@tencent.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
Cc: Anthony Liguori <aliguori@amazon.com>
--
kernel/events/core.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
837a6e7f5cdb ("fs: add generic UNRESVSP and ZERO_RANGE ioctl handlers") changed
ioctls XFS_IOC_UNRESVSP XFS_IOC_UNRESVSP64 and XFS_IOC_ZERO_RANGE to be generic
instead of xfs specific.
Because of this change, 36f11775da75 ("xfs: properly serialise fallocate against
AIO+DIO") needed adaptation, as 5.4 still uses the xfs specific ioctls.
Without this, xfstests xfs/242 and xfs/290 fail. Both of these tests test
XFS_IOC_ZERO_RANGE.
Fixes: 36f11775da75 ("xfs: properly serialise fallocate against AIO+DIO")
Tested-by: Andy Strohman <astroh@amazon.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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>
|
|
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>
|
|
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>
|
|
commit 328d2168ca524d501fc4b133d6be076142bd305c upstream.
Currently stack unwinder is a while(1) loop which relies on the dwarf
unwinder to signal termination, which in turn relies on dwarf info to do
so. This in theory could cause an infinite loop if the dwarf info was
somehow messed up or the register contents were etc.
This fix thus detects the excessive looping and breaks the loop.
| Mem: 26184K used, 1009136K free, 0K shrd, 0K buff, 14416K cached
| CPU: 0.0% usr 72.8% sys 0.0% nic 27.1% idle 0.0% io 0.0% irq 0.0% sirq
| Load average: 4.33 2.60 1.11 2/74 139
| PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
| 133 2 root SWN 0 0.0 3 22.9 [rcu_torture_rea]
| 132 2 root SWN 0 0.0 0 22.0 [rcu_torture_rea]
| 131 2 root SWN 0 0.0 3 21.5 [rcu_torture_rea]
| 126 2 root RW 0 0.0 2 5.4 [rcu_torture_wri]
| 129 2 root SWN 0 0.0 0 0.2 [rcu_torture_fak]
| 137 2 root SW 0 0.0 0 0.2 [rcu_torture_cbf]
| 127 2 root SWN 0 0.0 0 0.1 [rcu_torture_fak]
| 138 115 root R 1464 0.1 2 0.1 top
| 130 2 root SWN 0 0.0 0 0.1 [rcu_torture_fak]
| 128 2 root SWN 0 0.0 0 0.1 [rcu_torture_fak]
| 115 1 root S 1472 0.1 1 0.0 -/bin/sh
| 104 1 root S 1464 0.1 0 0.0 inetd
| 1 0 root S 1456 0.1 2 0.0 init
| 78 1 root S 1456 0.1 0 0.0 syslogd -O /var/log/messages
| 134 2 root SW 0 0.0 2 0.0 [rcu_torture_sta]
| 10 2 root IW 0 0.0 1 0.0 [rcu_preempt]
| 88 2 root IW 0 0.0 1 0.0 [kworker/1:1-eve]
| 66 2 root IW 0 0.0 2 0.0 [kworker/2:2-eve]
| 39 2 root IW 0 0.0 2 0.0 [kworker/2:1-eve]
| unwinder looping too long, aborting !
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
