- 02 Nov, 2022 9 commits
-
-
Jiawen Wu authored
Add mailbox commands to interact with firmware. Signed-off-by:
Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heng Qi authored
In the current processing logic, when xdp_redirect occurs, it transmits the xdp frame based on napi. If napi of the peer veth is not ready, the veth will drop the packets. This doesn't meet our expectations. In this context, we enable napi of the peer veth automatically when the veth loads the xdp. Then if the veth unloads the xdp, we need to correctly judge whether to disable napi of the peer veth, because the peer veth may have loaded xdp, or even the user has enabled GRO. Signed-off-by:
Heng Qi <henqqi@linux.alibaba.com> Reviewed-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by:
-
Dmitry Vyukov authored
Add remote KCOV annotations for NFC processing that is done in background threads. This enables efficient coverage-guided fuzzing of the NFC subsystem. The intention is to add annotations to background threads that process skb's that were allocated in syscall context (thus have a KCOV handle associated with the current fuzz test). This includes nci_recv_frame() that is called by the virtual nci driver in the syscall context. Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Bongsu Jeon <bongsu.jeon@samsung.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: netdev@vger.kernel.org Signed-off-by:
-
Shailend Chand authored
Previously, even if just one of the many fragments of a 9k packet required a copy, we'd copy the whole packet into a freshly-allocated 9k-sized linear SKB, and this led to performance issues. By having a pool of pages to copy into, each fragment can be independently handled, leading to a reduced incidence of allocation and copy. Signed-off-by:
Shailend Chand <shailend@google.com> Signed-off-by:
-
Shane Parslow authored
Add a new iosm wwan port that connects to the modem rpc interface. This interface provides a configuration channel, and in the case of the 7360, is the only way to configure the modem (as it does not support mbim). The new interface is compatible with existing software, such as open_xdatachannel.py from the xmm7360-pci project [1]. [1] https://github.com/xmm7360/xmm7360-pciSigned-off-by:
Shane Parslow <shaneparslow808@gmail.com> Reviewed-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
M Chetan Kumar authored
The Modem Logging (MDL) port provides an interface to collect modem logs for debugging purposes. MDL is supported by the relay interface, and the mtk_t7xx port infrastructure. MDL allows user-space apps to control logging via mbim command and to collect logs via the relay interface, while port infrastructure facilitates communication between the driver and the modem. Signed-off-by:
Moises Veleta <moises.veleta@linux.intel.com> Signed-off-by:
M Chetan Kumar <m.chetan.kumar@linux.intel.com> Signed-off-by:
Devegowda Chandrashekar <chandrashekar.devegowda@intel.com> Acked-by:
Ricardo Martinez <ricardo.martinez@linux.intel.com> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
-
M Chetan Kumar authored
Use union inside t7xx_port to group port type specific data members. Signed-off-by:
-
Eric Dumazet authored
After commits 36a6503f ("tcp: refine tcp_prune_ofo_queue() to not drop all packets") and 72cd43ba ("tcp: free batches of packets in tcp_prune_ofo_queue()") tcp_prune_ofo_queue() drops a fraction of ooo queue, to make room for incoming packet. However it makes no sense to drop packets that are before the incoming packet, in sequence space. In order to recover from packet losses faster, it makes more sense to only drop ooo packets which are after the incoming packet. Tested: packetdrill test: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [3800], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 0> +.1 < . 1:1(0) ack 1 win 1024 +0 accept(3, ..., ...) = 4 +.01 < . 200:300(100) ack 1 win 1024 +0 > . 1:1(0) ack 1 <nop,nop, sack 200:300> +.01 < . 400:500(100) ack 1 win 1024 +0 > . 1:1(0) ack 1 <nop,nop, sack 400:500 200:300> +.01 < . 600:700(100) ack 1 win 1024 +0 > . 1:1(0) ack 1 <nop,nop, sack 600:700 400:500 200:300> +.01 < . 800:900(100) ack 1 win 1024 +0 > . 1:1(0) ack 1 <nop,nop, sack 800:900 600:700 400:500 200:300> +.01 < . 1000:1100(100) ack 1 win 1024 +0 > . 1:1(0) ack 1 <nop,nop, sack 1000:1100 800:900 600:700 400:500> +.01 < . 1200:1300(100) ack 1 win 1024 +0 > . 1:1(0) ack 1 <nop,nop, sack 1200:1300 1000:1100 800:900 600:700> // this packet is dropped because we have no room left. +.01 < . 1400:1500(100) ack 1 win 1024 +.01 < . 1:200(199) ack 1 win 1024 // Make sure kernel did not drop 200:300 sequence +0 > . 1:1(0) ack 300 <nop,nop, sack 1200:1300 1000:1100 800:900 600:700> // Make room, since our RCVBUF is very small +0 read(4, ..., 299) = 299 +.01 < . 300:400(100) ack 1 win 1024 +0 > . 1:1(0) ack 500 <nop,nop, sack 1200:1300 1000:1100 800:900 600:700> +.01 < . 500:600(100) ack 1 win 1024 +0 > . 1:1(0) ack 700 <nop,nop, sack 1200:1300 1000:1100 800:900> +0 read(4, ..., 400) = 400 +.01 < . 700:800(100) ack 1 win 1024 +0 > . 1:1(0) ack 900 <nop,nop, sack 1200:1300 1000:1100> +.01 < . 900:1000(100) ack 1 win 1024 +0 > . 1:1(0) ack 1100 <nop,nop, sack 1200:1300> +.01 < . 1100:1200(100) ack 1 win 1024 // This checks that 1200:1300 has not been removed from ooo queue +0 > . 1:1(0) ack 1300 Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20221101035234.3910189-1-edumazet@google.comSigned-off-by:
-
Dr. David Alan Gilbert authored
inet[46]_pton check the input length against a sane length limit (INET[6]_ADDRSTRLEN), but the strlen value gets truncated due to being stored in an int, so there's a theoretical potential for a >4G string to pass the limit test. Use size_t since that's what strlen actually returns. I've had a hunt for callers that could hit this, but I've not managed to find anything that doesn't get checked with some other limit first; but it's possible that I've missed something in the depth of the storage target paths. Signed-off-by:
Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20221029014604.114024-1-linux@treblig.orgSigned-off-by:
-
- 01 Nov, 2022 17 commits
-
-
Jakub Kicinski authored
Eric Dumazet says: ==================== inet: add drop monitor support I recently tried to analyse flakes in ip_defrag selftest. This failed miserably. IPv4 and IPv6 reassembly units are causing false kfree_skb() notifications. It is time to deal with this issue. First two patches are changing core networking to better deal with eventual skb frag_list chains, in respect of kfree_skb/consume_skb status. Last three patches are adding three new drop reasons, and make sure skbs that have been reassembled into a large datagram are no longer viewed as dropped ones. After this, understanding why ip_defrag selftest is flaky is possible using standard drop monitoring tools. ==================== Link: https://lore.kernel.org/r/20221029154520.2747444-1-edumazet@google.comSigned-off-by:
-
Eric Dumazet authored
IPv4 reassembly unit can decide to drop frags based on /proc/sys/net/ipv4/ipfrag_max_dist sysctl. Add a specific drop reason to track this specific and weird case. Signed-off-by:
-
Eric Dumazet authored
Used to track skbs freed after a timeout happened in a reassmbly unit. Passing a @reason argument to inet_frag_rbtree_purge() allows to use correct consumed status for frags that have been successfully re-assembled. Signed-off-by:
-
Eric Dumazet authored
This is used to track when a duplicate segment received by various reassembly units is dropped. Signed-off-by:
-
Eric Dumazet authored
When an skb with a frag list is consumed, we currently pretend all skbs in the frag list were dropped. In order to fix this, add a @reason argument to skb_release_data() and skb_release_all(). Signed-off-by:
-
Eric Dumazet authored
This will allow to simply use in the future: kfree_skb_reason(skb, reason); Instead of repeating sequences like: if (dropped) kfree_skb_reason(skb, reason); else consume_skb(skb); For instance, following patch in the series is adding @reason to skb_release_data() and skb_release_all(), so that we can propagate a meaningful @reason whenever consume_skb()/kfree_skb() have to take care of a potential frag_list. Signed-off-by:
-
Florian Fainelli authored
RDMA overflows can happen if the Ethernet controller does not have enough bandwidth allocated at the memory controller level, report RDMA overflows and deal with saturation, similar to the RBUF overflow counter. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221028222141.3208429-1-f.fainelli@gmail.comSigned-off-by:
-
Sergei Antonov authored
If the FTMAC100 is used as a DSA master, then it is expected that frames which are MTU sized on the wire facing the external switch port (1500 octets in L2 payload, plus L2 header) also get a DSA tag when seen by the host port. This extra tag increases the length of the packet as the host port sees it, and the FTMAC100 is not prepared to handle frames whose length exceeds 1518 octets (including FCS) at all. Only a minimal rework is needed to support this configuration. Since MTU-sized DSA-tagged frames still fit within a single buffer (RX_BUF_SIZE), we just need to optimize the resource management rather than implement multi buffer RX. In ndo_change_mtu(), we toggle the FTMAC100_MACCR_RX_FTL bit to tell the hardware to drop (or not) frames with an L2 payload length larger than 1500. We need to replicate the MACCR configuration in ftmac100_start_hw() as well, since there is a hardware reset there which clears previous settings. The advantage of dynamically changing FTMAC100_MACCR_RX_FTL is that when dev->mtu is at the default value of 1500, large frames are automatically dropped in hardware and we do not spend CPU cycles dropping them. Suggested-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Sergei Antonov <saproj@gmail.com> Link: https://lore.kernel.org/r/20221028183220.155948-3-saproj@gmail.comSigned-off-by:
-
Vladimir Oltean authored
The driver uses the MAX_PKT_SIZE (1518) for both MTU reporting and for TX. However, the 2 places do not measure the same thing. On TX, skb->len measures the entire L2 packet length (without FCS, which software does not possess). So the comparison against 1518 there is correct. What is not correct is the reporting of dev->max_mtu as 1518. Since MTU measures L2 *payload* length (excluding L2 overhead) and not total L2 packet length, it means that the correct max_mtu supported by this device is the standard 1500. Anything higher than that will be dropped on RX currently. To fix this, subtract VLAN_ETH_HLEN from MAX_PKT_SIZE when reporting the max_mtu, since that is the difference between L2 payload length and total L2 length as seen by software. Signed-off-by:
-
Vladimir Oltean authored
Eliminate one check in the data path and move it elsewhere, to where our real limitation is. We'll want to start processing "too long" frames in the driver (currently there is a hardware MAC setting which drops theses). Signed-off-by:
-
Steffen Bätz authored
Currently, the .port_set_rgmii_delay hook is missing for the 88E6320 family, which causes failure to retrieve an IP address via DHCP. Add mv88e6320_port_set_rgmii_delay() that allows applying the RGMII delay for ports 2, 5, and 6, which are the only ports that can be used in RGMII mode. Tested on a custom i.MX8MN board connected to an 88E6320 switch. This change also applies safely to the 88E6321 variant. The only difference between 88E6320 versus 88E6321 is the temperature grade and pinout. They share exactly the same MDIO register map for ports 2, 5, and 6, which are the only ports that can be used in RGMII mode. Signed-off-by:
Steffen Bätz <steffen@innosonix.de> [fabio: Improved commit log and extended it to mv88e6321_ops] Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221028163158.198108-1-festevam@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Hangbin Liu says: ==================== rtnetlink: Honour NLM_F_ECHO flag in rtnl_{new, del}link Netlink messages are used for communicating between user and kernel space. When user space configures the kernel with netlink messages, it can set the NLM_F_ECHO flag to request the kernel to send the applied configuration back to the caller. This allows user space to retrieve configuration information that are filled by the kernel (either because these parameters can only be set by the kernel or because user space let the kernel choose a default value). The kernel has support this feature in some places like RTM_{NEW, DEL}ADDR, RTM_{NEW, DEL}ROUTE. This patch set handles NLM_F_ECHO flag and send link info back after rtnl_{new, del}link. ==================== Link: https://lore.kernel.org/r/20221028084224.3509611-1-liuhangbin@gmail.comSigned-off-by: -
Hangbin Liu authored
This patch use the new helper unregister_netdevice_many_notify() for rtnl_delete_link(), so that the kernel could reply unicast when userspace set NLM_F_ECHO flag to request the new created interface info. At the same time, the parameters of rtnl_delete_link() need to be updated since we need nlmsghdr and portid info. Suggested-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
-
Hangbin Liu authored
This patch pass the netlink header message in rtnl_newlink_create() to the new updated rtnl_configure_link(), so that the kernel could reply unicast when userspace set NLM_F_ECHO flag to request the new created interface info. Suggested-by:
-
Hangbin Liu authored
Add new helper unregister_netdevice_many_notify(), pass netlink message header and portid, which could be used to notify userspace when flag NLM_F_ECHO is set. Make the unregister_netdevice_many() as a wrapper of new function unregister_netdevice_many_notify(). Suggested-by:
-
Hangbin Liu authored
This patch pass netlink message header and portid to rtnl_configure_link() All the functions in this call chain need to add the parameters so we can use them in the last call rtnl_notify(), and notify the userspace about the new link info if NLM_F_ECHO flag is set. - rtnl_configure_link() - __dev_notify_flags() - rtmsg_ifinfo() - rtmsg_ifinfo_event() - rtmsg_ifinfo_build_skb() - rtmsg_ifinfo_send() - rtnl_notify() Also move __dev_notify_flags() declaration to net/core/dev.h, as Jakub suggested. Signed-off-by: -
Sean Anderson authored
When this device is deferred, there is often no way to determine what the cause was. Add some debug prints to make it easier to figure out what is blocking the probe. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Link: https://lore.kernel.org/r/20221027190005.400839-1-sean.anderson@seco.comSigned-off-by:
-
- 31 Oct, 2022 14 commits
-
-
Colin Ian King authored
Variable i is just being incremented and it's never used anywhere else. The variable and the increment are redundant so remove it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
David S. Miller authored
Jacob Keller says: ==================== ptp: convert drivers to .adjfine Many drivers implementing PTP have not yet migrated to the new .adjfine frequency adjustment implementation. A handful of these drivers use hardware with a simple increment value which is adjusted by multiplying by the adjustment factor and then dividing by 1 billion. This calculation is very easy to convert to .adjfine, by simply updating the divisor. Introduce new helper functions, diff_by_scaled_ppm and adjust_by_scaled_ppm which perform the most common calculations used by drivers for this purpose. The adjust_by_scaled_ppm takes the base increment and scaled PPM value, and calculates the new increment to use. A few drivers need the difference and direction rather than a raw increment value. The diff_by_scaled_ppm calculates the difference and returns true if it should be a subtraction, false otherwise. This most closely aligns with existing driver implementations. I previously submitted v1 of this series at [1], and got some feedback only on a handful of drivers. In the interest of merging the changes which have received feedback, I've dropped the following drivers out of this send: * ptp_phc * ptp_ipx46x * tg3 * hclge * stmac * cpts I plan to submit those drivers changes again at a later date. As before, there are some drivers which are not trivial to convert to the new helper functions. While they may be able to work, their implementation is different and I lack the hardware or datasheets to determine what the correct implementation would be. * drivers/net/ethernet/broadcom/bnx2x * drivers/net/ethernet/broadcom/bnxt * drivers/net/ethernet/cavium/liquidio * drivers/net/ethernet/chelsio/cxgb4 * drivers/net/ethernet/freescale * drivers/net/ethernet/qlogic/qed * drivers/net/ethernet/qlogic/qede * drivers/net/ethernet/sfc * drivers/net/ethernet/sfc/siena * drivers/net/ethernet/ti/am65-cpts.c * drivers/ptp/ptp_dte.c My end goal is to drop the .adjfreq implementation entirely, and to that end I plan on modifying these drivers in the future to directly use scaled_ppm_to_ppb as the simplest method to convert them. Changes since v2: * Rebased to allow landing in 6.2 * Added Richard's Acked-by Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Siva Reddy Kallam <siva.kallam@broadcom.com> Cc: Prashant Sreedharan <prashant@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Cc: Salil Mehta <salil.mehta@huawei.com> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: Tariq Toukan <tariqt@nvidia.com> Cc: Saeed Mahameed <saeedm@nvidia.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: Bryan Whitehead <bryan.whitehead@microchip.com> Cc: Sergey Shtylyov <s.shtylyov@omp.ru> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Jose Abreu <joabreu@synopsys.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Vivek Thampi <vithampi@vmware.com> Cc: VMware PV-Drivers Reviewers <pv-drivers@vmware.com> Cc: Jie Wang <wangjie125@huawei.com> Cc: Jacob Keller <jacob.e.keller@intel.com> Cc: Guangbin Huang <huangguangbin2@huawei.com> Cc: Eran Ben Elisha <eranbe@nvidia.com> Cc: Aya Levin <ayal@nvidia.com> Cc: Cai Huoqing <cai.huoqing@linux.dev> Cc: Biju Das <biju.das.jz@bp.renesas.com> Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Cc: Phil Edworthy <phil.edworthy@renesas.com> Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Wan Jiabing <wanjiabing@vivo.com> Cc: Lv Ruyi <lv.ruyi@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> ==================== Signed-off-by: -
Jacob Keller authored
The xgbe implementation of .adjfreq is implemented in terms of a straight forward "base * ppb / 1 billion" calculation. Convert this driver to .adjfine and use adjust_by_scaled_ppm to calculate the new addend value. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
-
Jacob Keller authored
The ravb implementation of .adjfreq is implemented in terms of a straight forward "base * ppb / 1 billion" calculation. Convert this driver to .adjfine and use the adjust_by_scaled_ppm helper function to calculate the new addend. Signed-off-by:
-
Jacob Keller authored
Update the lan743x driver to use the recently added diff_by_scaled_ppm helper function. This reduces the amount of code required in lan743x_ptp.c driver file. Signed-off-by:
-
Jacob Keller authored
The lan743x driver implements both .adjfreq and .adjfine, but the core PTP subsystem prefers .adjfine if implemented. There is no reason to carry a .adjfreq implementation, so we can remove it. Signed-off-by:
-
Jacob Keller authored
The mlx5 implementation of .adjfreq is implemented in terms of a straight forward "base * ppb / 1 billion" calculation. Convert this to the .adjfine interface and use adjust_by_scaled_ppm for the calculation of the new mult value. Note that the mlx5_ptp_adjfreq_real_time function expects input in terms of ppb, so use the scaled_ppm_to_ppb to convert before passing to this function. Signed-off-by:
Shirly Ohnona <shirlyo@nvidia.com> Acked-by:
-
Jacob Keller authored
The mlx4 implementation of .adjfreq is implemented in terms of a straight forward "base * ppb / 1 billion" calculation. Convert this driver to .adjfine and use adjust_by_scaled_ppm to perform the calculation. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
-
Jacob Keller authored
A few PTP drivers implement a .adjfreq handler which indicates the operation is not supported. Convert all of these to .adjfine. Signed-off-by:
-
Jacob Keller authored
Many drivers implement the .adjfreq or .adjfine PTP op function with the same basic logic: 1. Determine a base frequency value 2. Multiply this by the abs() of the requested adjustment, then divide by the appropriate divisor (1 billion, or 65,536 billion). 3. Add or subtract this difference from the base frequency to calculate a new adjustment. A few drivers need the difference and direction rather than the combined new increment value. I recently converted the Intel drivers to .adjfine and the scaled parts per million (65.536 parts per billion) logic. To avoid overflow with minimal loss of precision, mul_u64_u64_div_u64 was used. The basic logic used by all of these drivers is very similar, and leads to a lot of duplicate code to perform the same task. Rather than keep this duplicate code, introduce diff_by_scaled_ppm and adjust_by_scaled_ppm. These helper functions calculate the difference or adjustment necessary based on the scaled parts per million input. The diff_by_scaled_ppm function returns true if the difference should be subtracted, and false otherwise. Update the Intel drivers to use the new helper functions. Other vendor drivers will be converted to .adjfine and this helper function in the following changes. Signed-off-by: -
Jacob Keller authored
The ptp_find_pin_unlocked function and the ptp_system_timestamp structure didn't document their parameters and fields. Fix this. Signed-off-by:
-
Frank authored
Add a driver for the motorcomm yt8521 gigabit ethernet phy. We have verified the driver on StarFive VisionFive development board, which is developed by Shanghai StarFive Technology Co., Ltd.. On the board, yt8521 gigabit ethernet phy works in utp mode, RGMII interface, supports 1000M/100M/10M speeds, and wol(magic package). Signed-off-by:
Frank <Frank.Sae@motor-comm.com> Reviewed-by:
-
Yang Yingliang authored
test_callbacks and test_vctrl are only used in vcap_api_kunit.c now, change them to static. Fixes: 67d63751 ("net: microchip: sparx5: Adding KUNIT test for the VCAP API") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by:
-
Jakub Kicinski authored
New compilers don't like flexible array of flexible structs: include/net/geneve.h:62:34: warning: array of flexible structures Signed-off-by:
-
