- Feb 08, 2021
-
-
Suman Anna authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within the MAIN domain on the TI AM642 SK board. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc devices, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables to allocate the memory for firmware memory segments. The addresses chosen are the same as the respective processors on the AM64x EVM board to maintain firmware compatibility between the two boards. Note that the R5F1 carveouts are needed only if the R5F cluster is running in Split (non Single-CPU) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Suman Anna <s-anna@ti.com>
-
Suman Anna authored
Add the required 'mboxes' property to all the R5F processors on the TI AM642 SK board. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Tested-by:
-
Suman Anna authored
Add the sub-mailbox nodes that are used to communicate between MPU and various remote processors present in the AM64x SoCs for the AM642 SK board. These include the R5F remote processors in the two dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; and a M4 processor in the MCU safety island. These sub-mailbox nodes utilize the System Mailbox clusters 2, 4 and 6. The remaining clusters 3, 5 and 7 are currently not used, and so are disabled. Clusters 0 and 1 were never added to the dts file as they do not support interrupts towards the A53 core. The sub-mailbox nodes added match the hard-coded mailbox configuration used within the TI RTOS IPC software packages. The R5F processor sub-systems are assumed to be running in Split mode, so a sub-mailbox node is used by each of the R5F cores. Only the sub-mailbox node for the first R5F core in each cluster is used in case of a Single-CPU mode for that R5F cluster. The nodes are all identical to those added on the AM64x EVM board to maintain firmware compatibility between the two boards. NOTE: The cluster nodes only have the Mailbox IP interrupt outputs that are routed to the GIC_SPI. The sub-mailbox nodes' irq-id are indexing into the listed interrupts, with the usr-id using the actual interrupt output line number from the Mailbox IP. Tested-by:
-
LCPD Auto Merger authored
TI-Feature: connectivity TI-Branch: connectivity-ti-linux-5.4.y * 'connectivity-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/connectivity : usb: cdns3: Add support for TI's AM64 SoC arm64: dts: ti: k3-j7200-main: Remove sdhci-caps-mask to add support for SDR104 mode in MMCSD1 subsystem arm64: dts: ti: k3-j7200-main: Add support for HS200 and HS400 modes in MMCSD0 subsystem net: ethernet: ti: cpsw: fix crash in dual_emac mode with one ext port Signed-off-by:
LCPD Auto Merger <lcpd_integration@list.ti.com>
-
- Feb 07, 2021
-
-
Add support for USB controller present on the AM64x SoC. Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
arm64: dts: ti: k3-j7200-main: Remove sdhci-caps-mask to add support for SDR104 mode in MMCSD1 subsystem Remove sdhci-caps-mask property as SDR104 speed mode is now supported in MMCSD1 subsystem of J7200 SoC[1]. [1] - https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf Signed-off-by:
-
HS200 and HS400 modes at 1.8 V card voltage, are now supported in MMCSD0 subsystem of J7200 SoC[1]. Set respective tags to indicate it. [1] - https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf Signed-off-by:
-
The CPSW driver will crash with NULL pointer exception in dual_emac mode when there is only one ext. port physically connected and DT property "slaves" set to <1>. Fix crash, by adding missing check to prevent creating second netdev when "slaves = <1>". Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
- Feb 05, 2021
-
-
LCPD Auto Merger authored
TI-Feature: platform_base TI-Branch: platform-ti-linux-5.4.y * 'platform-ti-linux-5.4.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform : arm64: dts: ti: Add support for AM642 SK dt-bindings: arm: ti: Add bindings for AM642 SK Signed-off-by:
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. It supports the following interfaces: * 2 GB LPDDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode * x1 USB 3.0 Type-A port * x1 UHS-1 capable µSD card slot * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 * 512 Mbit OSPI flash * x2 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin Raspberry Pi compatible GPIO header * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) * 54-pin header for Programmable Realtime Unit (PRU) IO pins * Interface for remote automation. Includes: * power measurement and reset control * boot mode change Add basic support for AM642 SK. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com>
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. Add DT binding documentation for AM642 SK. Signed-off-by:
-
- Feb 03, 2021
-
-
Dan Murphy authored
Merge tag 'v5.4.93' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-5.4.y This is the 5.4.93 stable release * tag 'v5.4.93' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable : (122 commits) Linux 5.4.93 tcp: fix TCP_USER_TIMEOUT with zero window tcp: do not mess with cloned skbs in tcp_add_backlog() net: dsa: b53: fix an off by one in checking "vlan->vid" net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled net: mscc: ocelot: allow offloading of bridge on top of LAG ipv6: set multicast flag on the multicast route net_sched: reject silly cell_log in qdisc_get_rtab() net_sched: avoid shift-out-of-bounds in tcindex_set_parms() ipv6: create multicast route with RTPROT_KERNEL udp: mask TOS bits in udp_v4_early_demux() kasan: fix incorrect arguments passing in kasan_add_zero_shadow kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too lightnvm: fix memory leak when submit fails sh_eth: Fix power down vs. is_opened flag ordering net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext sh: dma: fix kconfig dependency for G2_DMA netfilter: rpfilter: mask ecn bits before fib lookup x86/cpu/amd: Set __max_die_per_package on AMD ... Signed-off-by:
Dan Murphy <dmurphy@ti.com>
-
- Jan 27, 2021
-
-
Greg Kroah-Hartman authored
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/20210126111748.320806573@linuxfoundation.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Enke Chen authored
commit 9d9b1ee0 upstream. The TCP session does not terminate with TCP_USER_TIMEOUT when data remain untransmitted due to zero window. The number of unanswered zero-window probes (tcp_probes_out) is reset to zero with incoming acks irrespective of the window size, as described in tcp_probe_timer(): RFC 1122 4.2.2.17 requires the sender to stay open indefinitely as long as the receiver continues to respond probes. We support this by default and reset icsk_probes_out with incoming ACKs. This counter, however, is the wrong one to be used in calculating the duration that the window remains closed and data remain untransmitted. Thanks to Jonathan Maxwell <jmaxwell37@gmail.com> for diagnosing the actual issue. In this patch a new timestamp is introduced for the socket in order to track the elapsed time for the zero-window probes that have not been answered with any non-zero window ack. Fixes: 9721e709 ("tcp: simplify window probe aborting on USER_TIMEOUT") Reported-by:
William McCall <william.mccall@gmail.com> Co-developed-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Enke Chen <enchen@paloaltonetworks.com> Reviewed-by:
Yuchung Cheng <ycheng@google.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210115223058.GA39267@localhost.localdomain Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Eric Dumazet authored
commit b160c285 upstream. Heiner Kallweit reported that some skbs were sent with the following invalid GSO properties : - gso_size > 0 - gso_type == 0 This was triggerring a WARN_ON_ONCE() in rtl8169_tso_csum_v2. Juerg Haefliger was able to reproduce a similar issue using a lan78xx NIC and a workload mixing TCP incoming traffic and forwarded packets. The problem is that tcp_add_backlog() is writing over gso_segs and gso_size even if the incoming packet will not be coalesced to the backlog tail packet. While skb_try_coalesce() would bail out if tail packet is cloned, this overwriting would lead to corruptions of other packets cooked by lan78xx, sharing a common super-packet. The strategy used by lan78xx is to use a big skb, and split it into all received packets using skb_clone() to avoid copies. The drawback of this strategy is that all the small skb share a common struct skb_shared_info. This patch rewrites TCP gso_size/gso_segs handling to only happen on the tail skb, since skb_try_coalesce() made sure it was not cloned. Fixes: 4f693b55 ("tcp: implement coalescing on backlog queue") Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Tested-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=209423 Link: https://lore.kernel.org/r/20210119164900.766957-1-eric.dumazet@gmail.com Signed-off-by:
-
Dan Carpenter authored
commit 8e4052c3 upstream. The > comparison should be >= to prevent accessing one element beyond the end of the dev->vlans[] array in the caller function, b53_vlan_add(). The "dev->vlans" array is allocated in the b53_switch_init() function and it has "dev->num_vlans" elements. Fixes: a2482d2c ("net: dsa: b53: Plug in VLAN support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda Signed-off-by:
-
Tariq Toukan authored
commit a3eb4e9d upstream. With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be logically done when RXCSUM offload is off. Fixes: 14136564 ("net: Add TLS RX offload feature") Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Boris Pismenny <borisp@nvidia.com> Link: https://lore.kernel.org/r/20210117151538.9411-1-tariqt@nvidia.com Signed-off-by:
-
Vladimir Oltean authored
commit 79267ae2 upstream. The blamed commit was too aggressive, and it made ocelot_netdevice_event react only to network interface events emitted for the ocelot switch ports. In fact, only the PRECHANGEUPPER should have had that check. When we ignore all events that are not for us, we miss the fact that the upper of the LAG changes, and the bonding interface gets enslaved to a bridge. This is an operation we could offload under certain conditions. Fixes: 7afb3e57 ("net: mscc: ocelot: don't handle netdev events for other netdevs") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210118135210.2666246-1-olteanv@gmail.com Signed-off-by:
-
Matteo Croce authored
commit ceed9038 upstream. The multicast route ff00::/8 is created with type RTN_UNICAST: $ ip -6 -d route unicast ::1 dev lo proto kernel scope global metric 256 pref medium unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium unicast ff00::/8 dev eth0 proto kernel scope global metric 256 pref medium Set the type to RTN_MULTICAST which is more appropriate. Fixes: e8478e80 ("net/ipv6: Save route type in rt6_info") Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Signed-off-by:
-
Eric Dumazet authored
commit e4bedf48 upstream. iproute2 probably never goes beyond 8 for the cell exponent, but stick to the max shift exponent for signed 32bit. UBSAN reported: UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22 shift exponent 130 is too large for 32-bit type 'int' CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x183/0x22e lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395 __detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389 qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435 cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180 qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246 tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662 rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564 netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x5a2/0x900 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x319/0x400 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Acked-by:
Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.dumazet@gmail.com Signed-off-by:
-
Eric Dumazet authored
commit bcd0cf19 upstream. tc_index being 16bit wide, we need to check that TCA_TCINDEX_SHIFT attribute is not silly. UBSAN: shift-out-of-bounds in net/sched/cls_tcindex.c:260:29 shift exponent 255 is too large for 32-bit type 'int' CPU: 0 PID: 8516 Comm: syz-executor228 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 valid_perfect_hash net/sched/cls_tcindex.c:260 [inline] tcindex_set_parms.cold+0x1b/0x215 net/sched/cls_tcindex.c:425 tcindex_change+0x232/0x340 net/sched/cls_tcindex.c:546 tc_new_tfilter+0x13fb/0x21b0 net/sched/cls_api.c:2127 rtnetlink_rcv_msg+0x8b6/0xb80 net/core/rtnetlink.c:5555 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2336 ___sys_sendmsg+0xf3/0x170 net/socket.c:2390 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2423 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Matteo Croce authored
commit a826b043 upstream. The ff00::/8 multicast route is created without specifying the fc_protocol field, so the default RTPROT_BOOT value is used: $ ip -6 -d route unicast ::1 dev lo proto kernel scope global metric 256 pref medium unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium As the documentation says, this value identifies routes installed during boot, but the route is created when interface is set up. Change the value to RTPROT_KERNEL which is a better value. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Guillaume Nault authored
commit 8d2b51b0 upstream. udp_v4_early_demux() is the only function that calls ip_mc_validate_source() with a TOS that hasn't been masked with IPTOS_RT_MASK. This results in different behaviours for incoming multicast UDPv4 packets, depending on if ip_mc_validate_source() is called from the early-demux path (udp_v4_early_demux) or from the regular input path (ip_route_input_noref). ECN would normally not be used with UDP multicast packets, so the practical consequences should be limited on that side. However, IPTOS_RT_MASK is used to also masks the TOS' high order bits, to align with the non-early-demux path behaviour. Reproducer: Setup two netns, connected with veth: $ ip netns add ns0 $ ip netns add ns1 $ ip -netns ns0 link set dev lo up $ ip -netns ns1 link set dev lo up $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10 peer 192.0.2.11/32 dev veth01 $ ip -netns ns1 address add 192.0.2.11 peer 192.0.2.10/32 dev veth10 In ns0, add route to multicast address 224.0.2.0/24 using source address 198.51.100.10: $ ip -netns ns0 address add 198.51.100.10/32 dev lo $ ip -netns ns0 route add 224.0.2.0/24 dev veth01 src 198.51.100.10 In ns1, define route to 198.51.100.10, only for packets with TOS 4: $ ip -netns ns1 route add 198.51.100.10/32 tos 4 dev veth10 Also activate rp_filter in ns1, so that incoming packets not matching the above route get dropped: $ ip netns exec ns1 sysctl -wq net.ipv4.conf.veth10.rp_filter=1 Now try to receive packets on 224.0.2.11: $ ip netns exec ns1 socat UDP-RECVFROM:1111,ip-add-membership=224.0.2.11:veth10,ignoreeof - In ns0, send packet to 224.0.2.11 with TOS 4 and ECT(0) (that is, tos 6 for socat): $ echo test0 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6 The "test0" message is properly received by socat in ns1, because early-demux has no cached dst to use, so source address validation is done by ip_route_input_mc(), which receives a TOS that has the ECN bits masked. Now send another packet to 224.0.2.11, still with TOS 4 and ECT(0): $ echo test1 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6 The "test1" message isn't received by socat in ns1, because, now, early-demux has a cached dst to use and calls ip_mc_validate_source() immediately, without masking the ECN bits. Fixes: bc044e8d ("udp: perform source validation for mcast early demux") Signed-off-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Lecopzer Chen authored
commit 5dabd171 upstream. kasan_remove_zero_shadow() shall use original virtual address, start and size, instead of shadow address. Link: https://lkml.kernel.org/r/20210103063847.5963-1-lecopzer@gmail.com Fixes: 0207df4f ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by:
Lecopzer Chen <lecopzer.chen@mediatek.com> Reviewed-by:
Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Lecopzer Chen authored
commit a11a496e upstream. During testing kasan_populate_early_shadow and kasan_remove_zero_shadow, if the shadow start and end address in kasan_remove_zero_shadow() is not aligned to PMD_SIZE, the remain unaligned PTE won't be removed. In the test case for kasan_remove_zero_shadow(): shadow_start: 0xffffffb802000000, shadow end: 0xffffffbfbe000000 3-level page table: PUD_SIZE: 0x40000000 PMD_SIZE: 0x200000 PAGE_SIZE: 4K 0xffffffbf80000000 ~ 0xffffffbfbdf80000 will not be removed because in kasan_remove_pud_table(), kasan_pmd_table(*pud) is true but the next address is 0xffffffbfbdf80000 which is not aligned to PUD_SIZE. In the correct condition, this should fallback to the next level kasan_remove_pmd_table() but the condition flow always continue to skip the unaligned part. Fix by correcting the condition when next and addr are neither aligned. Link: https://lkml.kernel.org/r/20210103135621.83129-1-lecopzer@gmail.com Fixes: 0207df4f ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by:
-
Alexander Lobakin authored
commit 66c55602 upstream. Commit 3226b158 ("net: avoid 32 x truesize under-estimation for tiny skbs") ensured that skbs with data size lower than 1025 bytes will be kmalloc'ed to avoid excessive page cache fragmentation and memory consumption. However, the fix adressed only __napi_alloc_skb() (primarily for virtio_net and napi_get_frags()), but the issue can still be achieved through __netdev_alloc_skb(), which is still used by several drivers. Drivers often allocate a tiny skb for headers and place the rest of the frame to frags (so-called copybreak). Mirror the condition to __netdev_alloc_skb() to handle this case too. Since v1 [0]: - fix "Fixes:" tag; - refine commit message (mention copybreak usecase). [0] https://lore.kernel.org/netdev/20210114235423.232737-1-alobakin@pm.me Fixes: a1c7fff7 ("net: netdev_alloc_skb() use build_skb()") Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Link: https://lore.kernel.org/r/20210115150354.85967-1-alobakin@pm.me Signed-off-by:
-
Pan Bian authored
commit 97784481 upstream. The allocated page is not released if error occurs in nvm_submit_io_sync_raw(). __free_page() is moved ealier to avoid possible memory leak issue. Fixes: aff3fb18 ("lightnvm: move bad block and chunk state logic to core") Signed-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Geert Uytterhoeven authored
commit f6a2e94b upstream. sh_eth_close() does a synchronous power down of the device before marking it closed. Revert the order, to make sure the device is never marked opened while suspended. While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as there is no reason to do a synchronous power down. Fixes: 7fa2955f ("sh_eth: Fix sleeping function called from invalid context") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Sergei Shtylyov <sergei.shtylyov@gmail.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+renesas@glider.be Signed-off-by:
-
Rasmus Villemoes authored
commit 87fe0436 upstream. mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069 (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by:
Tobias Waldekranz <tobias@waldekranz.com> Tested-by:
-
Necip Fazil Yildiran authored
commit f477a538 upstream. When G2_DMA is enabled and SH_DMA is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for SH_DMA_API Depends on [n]: SH_DMA [=n] Selected by [y]: - G2_DMA [=y] && SH_DREAMCAST [=y] The reason is that G2_DMA selects SH_DMA_API without depending on or selecting SH_DMA while SH_DMA_API depends on SH_DMA. When G2_DMA was first introduced with commit 40f49e7e ("sh: dma: Make G2 DMA configurable."), this wasn't an issue since SH_DMA_API didn't have such dependency, and this way was the only way to enable it since SH_DMA_API was non-visible. However, later SH_DMA_API was made visible and dependent on SH_DMA with commit d8902adc ("dmaengine: sh: Add Support SuperH DMA Engine driver"). Let G2_DMA depend on SH_DMA_API instead to avoid Kbuild issues. Fixes: d8902adc ("dmaengine: sh: Add Support SuperH DMA Engine driver") Signed-off-by:
Necip Fazil Yildiran <fazilyildiran@gmail.com> Signed-off-by:
Rich Felker <dalias@libc.org> Signed-off-by:
-
Guillaume Nault authored
commit 2e5a6266 upstream. RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt() treats Not-ECT or ECT(1) packets in a different way than those with ECT(0) or CE. Reproducer: Create two netns, connected with a veth: $ ip netns add ns0 $ ip netns add ns1 $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10/32 dev veth01 $ ip -netns ns1 address add 192.0.2.11/32 dev veth10 Add a route to ns1 in ns0: $ ip -netns ns0 route add 192.0.2.11/32 dev veth01 In ns1, only packets with TOS 4 can be routed to ns0: $ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10 Ping from ns0 to ns1 works regardless of the ECN bits, as long as TOS is 4: $ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT ... 0% packet loss ... $ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1) ... 0% packet loss ... $ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0) ... 0% packet loss ... $ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE ... 0% packet loss ... Now use iptable's rpfilter module in ns1: $ ip netns exec ns1 iptables-legacy -t raw -A PREROUTING -m rpfilter --invert -j DROP Not-ECT and ECT(1) packets still pass: $ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT ... 0% packet loss ... $ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1) ... 0% packet loss ... But ECT(0) and ECN packets are dropped: $ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0) ... 100% packet loss ... $ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE ... 100% packet loss ... After this patch, rpfilter doesn't drop ECT(0) and CE packets anymore. Fixes: 8f97339d ("netfilter: add ipv4 reverse path filter match") Signed-off-by:
-
Yazen Ghannam authored
commit 76e2fc63 upstream. Set the maximum DIE per package variable on AMD using the NodesPerProcessor topology value. This will be used by RAPL, among others, to determine the maximum number of DIEs on the system in order to do per-DIE manipulations. [ bp: Productize into a proper patch. ] Fixes: 028c221e ("x86/CPU/AMD: Save AMD NodeId as cpu_die_id") Reported-by:
Johnathan Smithinovic <johnathan.smithinovic@gmx.at> Reported-by:
Rafael Kitover <rkitover@gmail.com> Signed-off-by:
Yazen Ghannam <Yazen.Ghannam@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
-
Paul Cercueil authored
commit 9a85c09a upstream. - JZ4760 and JZ4760B have a similar register layout as the JZ4740, and don't use the new register layout, which was introduced with the JZ4770 SoC and not the JZ4760 or JZ4760B SoCs. - The JZ4740 code path only expected two function modes to be configurable for each pin, and wouldn't work with more than two. Fix it for the JZ4760, which has four configurable function modes. Fixes: 0257595a ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and JZ4760B.") Cc: <stable@vger.kernel.org> # 5.3 Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20201211232810.261565-1-paul@crapouillou.net Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit 3d1cf435 upstream. If the device passed as the target (second argument) to device_is_dependent() is not completely registered (that is, it has been initialized, but not added yet), but the parent pointer of it is set, it may be missing from the list of the parent's children and device_for_each_child() called by device_is_dependent() cannot be relied on to catch that dependency. For this reason, modify device_is_dependent() to check the ancestors of the target device by following its parent pointer in addition to the device_for_each_child() walk. Fixes: 9ed98953 ("driver core: Functional dependencies tracking support") Reported-by:
Stephan Gerhold <stephan@gerhold.net> Tested-by:
Saravana Kannan <saravanak@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
JC Kuo authored
commit da7e0c3c upstream. Occasionally, we are seeing some SuperSpeed devices resumes right after being directed to U3. This commits add 500us delay to ensure LFPS detector is disabled before sending ACK to firmware. [ 16.099363] tegra-xusb 70090000.usb: entering ELPG [ 16.104343] tegra-xusb 70090000.usb: 2-1 isn't suspended: 0x0c001203 [ 16.114576] tegra-xusb 70090000.usb: not all ports suspended: -16 [ 16.120789] tegra-xusb 70090000.usb: entering ELPG failed The register write passes through a few flop stages of 32KHz clock domain. NVIDIA ASIC designer reviewed RTL and suggests 500us delay. Cc: stable@vger.kernel.org Signed-off-by:
JC Kuo <jckuo@nvidia.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210115161907.2875631-3-mathias.nyman@linux.intel.com Signed-off-by:
-
Mathias Nyman authored
commit 576667ba upstream. Once the command ring doorbell is rung the xHC controller will parse all command TRBs on the command ring that have the cycle bit set properly. If the driver just started writing the next command TRB to the ring when hardware finished the previous TRB, then HW might fetch an incomplete TRB as long as its cycle bit set correctly. A command TRB is 16 bytes (128 bits) long. Driver writes the command TRB in four 32 bit chunks, with the chunk containing the cycle bit last. This does however not guarantee that chunks actually get written in that order. This was detected in stress testing when canceling URBs with several connected USB devices. Two consecutive "Set TR Dequeue pointer" commands got queued right after each other, and the second one was only partially written when the controller parsed it, causing the dequeue pointer to be set to bogus values. This was seen as error messages: "Mismatch between completed Set TR Deq Ptr command & xHCI internal state" Solution is to add a write memory barrier before writing the cycle bit. Cc: <stable@vger.kernel.org> Tested-by:
Ross Zwisler <zwisler@google.com> Signed-off-by:
-
Patrik Jakobsson authored
commit ef02684c upstream. The bdc pci driver is going to be removed due to it not existing in the wild. This patch turns off compilation of the driver so that stable kernels can also pick up the change. This helps the out-of-tree facetimehd webcam driver as the pci id conflicts with bdc. Cc: Al Cooper <alcooperx@gmail.com> Cc: <stable@vger.kernel.org> Acked-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobsson@gmail.com Signed-off-by:
-
Thinh Nguyen authored
commit c28095bc upstream. Use lock to guard against concurrent access for soft-connect/disconnect operations when writing to soft_connect sysfs. Fixes: 2ccea03a ("usb: gadget: introduce UDC Class") Cc: stable@vger.kernel.org Acked-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.Thinh.Nguyen@synopsys.com Signed-off-by:
-
Ryan Chen authored
commit 4e0dcf62 upstream. The vhub engine has two dma mode, one is descriptor list, another is single stage DMA. Each mode has different stop register setting. Descriptor list operation (bit2) : 0 disable reset, 1: enable reset Single mode operation (bit0) : 0 : disable, 1: enable Fixes: 7ecca2a4 ("usb/gadget: Add driver for Aspeed SoC virtual hub") Cc: stable <stable@vger.kernel.org> Acked-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
Ryan Chen <ryan_chen@aspeedtech.com> Link: https://lore.kernel.org/r/20210108081238.10199-2-ryan_chen@aspeedtech.com Signed-off-by:
-
Longfang Liu authored
commit 643a4df7 upstream. The system that use Synopsys USB host controllers goes to suspend when using USB audio player. This causes the USB host controller continuous send interrupt signal to system, When the number of interrupts exceeds 100000, the system will forcibly close the interrupts and output a calltrace error. When the system goes to suspend, the last interrupt is reported to the driver. At this time, the system has set the state to suspend. This causes the last interrupt to not be processed by the system and not clear the interrupt flag. This uncleared interrupt flag constantly triggers new interrupt event. This causing the driver to receive more than 100,000 interrupts, which causes the system to forcibly close the interrupt report and report the calltrace error. so, when the driver goes to sleep and changes the system state to suspend, the interrupt flag needs to be cleared. Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongfang@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
