- 15 Jun, 2021 9 commits
-
-
Peng Li authored
This patch removes trailing whitespaces. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peng Li authored
According to the chackpatch.pl, else should follow close brace '}', braces {} should be used on all arms of this statement. Signed-off-by: -
Peng Li authored
Networking block comments don't use an empty /* line, use /* Comment... Block comments use * on subsequent lines. Block comments use a trailing */ on a separate line. This patch fixes the comments style issues. Signed-off-by:
-
Peng Li authored
According to the chackpatch.pl, comparison to NULL could be written "!skb". Signed-off-by:
-
Peng Li authored
According to the chackpatch.pl, EXPORT_SYMBOL(foo); should immediately follow its function/variable. Signed-off-by:
-
Peng Li authored
This patch fixes the checkpatch error about missing a blank line after declarations. Signed-off-by:
-
Peng Li authored
This patch removes some redundant blank lines. Signed-off-by:
-
Boris Sukholitko authored
The following flower filters fail to match packets: tc filter add dev eth0 ingress protocol 0x8864 flower \ action simple sdata hi64 tc filter add dev eth0 ingress protocol 802.1q flower \ vlan_ethtype 0x8864 action simple sdata "hi vlan" The protocol 0x8864 (ETH_P_PPP_SES) is a tunnel protocol. As such, it is being dissected by __skb_flow_dissect and it's internal protocol is being set as key->basic.n_proto. IOW, the existence of ETH_P_PPP_SES tunnel is transparent to the callers of __skb_flow_dissect. OTOH, in the filters above, cls_flower configures its key->basic.n_proto to the ETH_P_PPP_SES value configured by the user. Matching on this key fails because of __skb_flow_dissect "transparency" mentioned above. In the following, I would argue that the problem lies with cls_flower, unnessary attempting key->basic.n_proto match. There are 3 close places in fl_set_key in cls_flower setting up mask->basic.n_proto. They are (in reverse order of appearance in the code) due to: (a) No vlan is given: use TCA_FLOWER_KEY_ETH_TYPE parameter (b) One vlan tag is given: use TCA_FLOWER_KEY_VLAN_ETH_TYPE (c) Two vlans are given: use TCA_FLOWER_KEY_CVLAN_ETH_TYPE The match in case (a) is unneeded because flower has no its own eth_type parameter. It was removed by Jamal Hadi Salim in commit 488b41d020fb06428b90289f70a41210718f52b7 in iproute2. For TCA_FLOWER_KEY_ETH_TYPE the userspace uses the generic tc filter protocol field. Therefore the match for the case (a) is done by tc itself. The matches in cases (b), (c) are unneeded because the protocol will appear in and will be matched by flow_dissector_key_vlan.vlan_tpid. Therefore in the best case, key->basic.n_proto will try to repeat vlan key match again. The below patch removes mask->basic.n_proto setting and resets it to 0 in case (c). Signed-off-by:
Boris Sukholitko <boris.sukholitko@broadcom.com> Signed-off-by:
-
Matteo Croce authored
On RX an SKB is allocated and the received buffer is copied into it. But on some architectures, the memcpy() needs the source and destination buffers to have the same alignment to be efficient. This is not our case, because SKB data pointer is misaligned by two bytes to compensate the ethernet header. Align the RX buffer the same way as the SKB one, so the copy is faster. An iperf3 RX test gives a decent improvement on a RISC-V machine: before: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 733 MBytes 615 Mbits/sec 88 sender [ 5] 0.00-10.01 sec 730 MBytes 612 Mbits/sec receiver after: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec receiver And the memcpy() overhead during the RX drops dramatically. before: Overhead Shared O Symbol 43.35% [kernel] [k] memcpy 33.77% [kernel] [k] __asm_copy_to_user 3.64% [kernel] [k] sifive_l2_flush64_range after: Overhead Shared O Symbol 45.40% [kernel] [k] __asm_copy_to_user 28.09% [kernel] [k] memcpy 4.27% [kernel] [k] sifive_l2_flush64_range Signed-off-by:
Matteo Croce <mcroce@microsoft.com> Signed-off-by:
-
- 14 Jun, 2021 31 commits
-
-
Loic Poulain authored
There is not strong reason to have both WWAN and WWAN_CORE symbols, Let's build the WWAN core framework when WWAN is selected, in the same way as for other subsystems. This fixes issue with mhi_net selecting WWAN_CORE without WWAN and reported by kernel test robot: Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for WWAN_CORE Depends on NETDEVICES && WWAN Selected by - MHI_NET && NETDEVICES && NET_CORE && MHI_BUS Fixes: 9a44c1cc ("net: Add a WWAN subsystem") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Vladimir Oltean authored
After the blamed patch, __skb_flow_dissect() on the DSA master stopped adjusting for the length of the DSA headers. This is because it was told to adjust only if the needed_headroom is zero, aka if there is no DSA header. Of course, the adjustment should be done only if there _is_ a DSA header. Modify the comment too so it is clearer. Fixes: 4e500251 ("net: dsa: generalize overhead for taggers that use both headers and trailers") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
The struct sja1105_regs tables are not modified during the runtime of the driver, so they can be made constant. In fact, struct sja1105_info already holds a const pointer to these. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Fixes and improvements to TJA1103 PHY driver This series contains: - an erratum workaround for the TJA1103 PHY integrated in SJA1110 - an adaptation of the driver so it prints less unnecessary information when probing on SJA1110 - a PTP RX timestamping bug fix and a clarification patch Targeting net-next since the PHY support is currently in net-next only. Changes in v3: Added one more patch which improves the readability of nxp_c45_reconstruct_ts. Changes in v2: Added a comment to the hardware workaround procedure. ==================== Signed-off-by: -
Vladimir Oltean authored
The SJA1110 switch integrates TJA1103 PHYs, but in SJA1110 switch rev B silicon, there is a bug in that the registers for selecting the 100base-T1 autoneg master/slave roles are not writable. To enable write access to the master/slave registers, these additional PHY writes are necessary during initialization. The issue has been corrected in later SJA1110 silicon versions and is not present in the standalone PHY variants, but applying the workaround unconditionally in the driver should not do any harm. Suggested-by:
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Vladimir Oltean authored
The reconstruction procedure for partial timestamps reads the current PTP time and fills in the low 2 bits of the second portion, as well as the nanoseconds portion, from the actual hardware packet timestamp. Critically, the reconstruction procedure works because it assumes that the current PTP time is strictly larger than the hardware timestamp was: it detects a 2-bit wraparound of the 'seconds' portion by checking whether the 'seconds' portion of the partial hardware timestamp is larger than the 'seconds' portion of the current time. That can only happen if the hardware timestamp was captured by the PHY during the last phase of a 'modulo 4 seconds' interval, and the current PTP time was read by the driver during the initial phase of the next 'modulo 4 seconds' interval. The partial RX timestamps are added to priv->rx_queue in nxp_c45_rxtstamp() and they are processed potentially in parallel by the aux worker thread in nxp_c45_do_aux_work(). This means that it is possible for nxp_c45_do_aux_work() to process more than one RX timestamp during the same schedule. There is one premature optimization that will cause issues: for RX timestamping, the driver reads the current time only once, and it uses that to reconstruct all PTP RX timestamps in the queue. For the second and later timestamps, this will be an issue if we are processing two RX timestamps which are to the left and to the right, respectively, of a 4-bit wraparound of the 'seconds' portion of the PTP time, and the current PTP time is also pre-wraparound. 0.000000000 4.000000000 8.000000000 12.000000000 |..................|..................|..................|............> ^ ^ ^ ^ time | | | | | | | process hwts 1 and hwts 2 | | | | | hwts 2 | | | read current PTP time | hwts 1 What will happen in that case is that hwts 2 (post-wraparound) will use a stale current PTP time that is pre-wraparound. But nxp_c45_reconstruct_ts will not detect this condition, because it is not coded up for it, so it will reconstruct hwts 2 with a current time from the previous 4 second interval (i.e. 0.something instead of 4.something). This is solvable by making sure that the full 64-bit current time is always read after the PHY has taken the partial RX timestamp. We do this by reading the current PTP time for every timestamp in the RX queue. Fixes: 514def5d ("phy: nxp-c45-tja11xx: add timestamping support") Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by: -
Vladimir Oltean authored
nxp_c45_reconstruct_ts() takes a partial hardware timestamp in @hwts, with 2 bits of the 'seconds' portion, and a full PTP time in @ts. It patches in the lower bits of @hwts into @ts, and to ensure that the reconstructed timestamp is correct, it checks whether the lower 2 bits of @hwts are not in fact higher than the lower 2 bits of @ts. This is not logically possible because, according to the calling convention, @ts was collected later in time than @hwts, but due to two's complement arithmetic it can actually happen, because the current PTP time might have wrapped around between when @hwts was collected and when @ts was, yielding the lower 2 bits of @ts smaller than those of @hwts. To correct for that situation which is expected to happen under normal conditions, the driver subtracts exactly one wraparound interval from the reconstructed timestamp, since the upper bits of that need to correspond to what the upper bits of @hwts were, not to what the upper bits of @ts were. Readers might be confused because the driver denotes the amount of bits that the partial hardware timestamp has to offer as TS_SEC_MASK (timestamp mask for seconds). But it subtracts a seemingly unrelated BIT(2), which is in fact more subtle: if the hardware timestamp provides 2 bits of partial 'seconds' timestamp, then the wraparound interval is 2^2 == BIT(2). But nonetheless, it is better to express the wraparound interval in terms of a definition we already have, so replace BIT(2) with 1 + GENMASK(1, 0) which produces the same result but is clearer. Suggested-by:
-
Vladimir Oltean authored
The SJA1110 switch integrates these PHYs, and they do not have support for timestamping. This message becomes quite overwhelming: [ 10.056596] NXP C45 TJA1103 spi1.0-base-t1:01: the phy does not support PTP [ 10.112625] NXP C45 TJA1103 spi1.0-base-t1:02: the phy does not support PTP [ 10.167461] NXP C45 TJA1103 spi1.0-base-t1:03: the phy does not support PTP [ 10.223510] NXP C45 TJA1103 spi1.0-base-t1:04: the phy does not support PTP [ 10.278239] NXP C45 TJA1103 spi1.0-base-t1:05: the phy does not support PTP [ 10.332663] NXP C45 TJA1103 spi1.0-base-t1:06: the phy does not support PTP [ 15.390828] NXP C45 TJA1103 spi1.2-base-t1:01: the phy does not support PTP [ 15.445224] NXP C45 TJA1103 spi1.2-base-t1:02: the phy does not support PTP [ 15.499673] NXP C45 TJA1103 spi1.2-base-t1:03: the phy does not support PTP [ 15.554074] NXP C45 TJA1103 spi1.2-base-t1:04: the phy does not support PTP [ 15.608516] NXP C45 TJA1103 spi1.2-base-t1:05: the phy does not support PTP [ 15.662996] NXP C45 TJA1103 spi1.2-base-t1:06: the phy does not support PTP So reduce its log level to debug. Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
David S. Miller authored
Zhou Yanjie says: ==================== Add Ingenic SoCs MAC support. v2->v3: 1.Add "ingenic,mac.yaml" for Ingenic SoCs. 2.Change tx clk delay and rx clk delay from hardware value to ps. 3.return -EINVAL when a unsupported value is encountered when parsing the binding. 4.Simplify the code of the RGMII part of X2000 SoC according to Andrew Lunn’s suggestion. 5.Follow the example of "dwmac-mediatek.c" to improve the code that handles delays according to Andrew Lunn’s suggestion. ==================== Signed-off-by: -
周琰杰 (Zhou Yanjie) authored
Add support for Ingenic SoC MAC glue layer support for the stmmac device driver. This driver is used on for the MAC ethernet controller found in the JZ4775 SoC, the X1000 SoC, the X1600 SoC, the X1830 SoC, and the X2000 SoC. Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Reviewed-by:
-
周琰杰 (Zhou Yanjie) authored
Add the dwmac bindings for the JZ4775 SoC, the X1000 SoC, the X1600 SoC, the X1830 SoC and the X2000 SoC from Ingenic. Signed-off-by:
-
David S. Miller authored
Oleksandr Mazur says: ==================== Marvell Prestera driver implementation of devlink functionality. This patch series implement Prestera Switchdev driver devlink traps, that are registered within the driver, as well as extend current devlink functionality by adding new hard drop statistics counter, that could be retrieved on-demand: the counter shows number of packets that have been dropped by the underlying device and haven't been passed to the devlink subsystem. The core prestera-devlink functionality is implemented in the prestera_devlink.c. The patch series also extends the existing devlink kernel API: - devlink: add trap_drop_counter_get callback for driver to register - make it possible to keep track of how many packets have been dropped (hard) by the switch device, before the packets even made it to the devlink subsystem (e.g. dropped due to RXDMA buffer overflow). The core features that extend current functionality of prestera Switchdev driver: - add logic for driver traps and drops registration (also traps with DROP action). - add documentation for prestera driver traps and drops group. PATCH v2: 1) Rebase whole series on top of latest mater; 2) Remove storm control-related patches, as they're out of devlink scope; ==================== Signed-off-by: -
Oleksandr Mazur authored
Add documentation for the devlink feature prestera switchdev driver supports: add description for the support of the driver-specific devlink traps (include both traps with action TRAP and action DROP); Signed-off-by:
Oleksandr Mazur <oleksandr.mazur@plvision.eu> Signed-off-by:
-
Oleksandr Mazur authored
Add traps that have init_action being set to DROP. Add 'trap_drop_counter_get' (devlink API) callback implementation, that is used to get number of packets that have been dropped by the HW (traps with action 'DROP'). Add new FW command CPU_CODE_COUNTERS_GET. Signed-off-by:
-
Oleksandr Mazur authored
Add devlink traps registration (with corresponding groups) for all the traffic types that driver traps to the CPU; prestera_rxtx: report each packet trapped to the CPU (RX) to the prestera_devlink; Signed-off-by:
-
Oleksandr Mazur authored
Add hard drop counter check testcase, to make sure netdevsim driver properly handles the devlink hard drop counters get/set callbacks. Signed-off-by:
-
Oleksandr Mazur authored
Whenever query statistics is issued for trap with DROP action, devlink subsystem would also fill-in statistics 'dropped' field. In case if device driver did't register callback for hard drop statistics querying, 'dropped' field will be omitted and not filled. Add trap_drop_counter_get callback implementation to the netdevsim. Add new test cases for netdevsim, to test both the callback functionality, as well as drop statistics alteration check. Signed-off-by:
-
Oleksandr Mazur authored
testing: selftests: net: forwarding: add devlink-required functionality to test (hard) dropped stats field Add devlink_trap_drop_packets_get function, as well as test that are used to verify devlink (hard) dropped stats functionality works. Signed-off-by:
-
Oleksandr Mazur authored
Whenever query statistics is issued for trap, devlink subsystem would also fill-in statistics 'dropped' field. This field indicates the number of packets HW dropped and failed to report to the device driver, and thus - to the devlink subsystem itself. In case if device driver didn't register callback for hard drop statistics querying, 'dropped' field will be omitted and not filled. Signed-off-by:
-
Loic Poulain authored
Author forgot to remove that flag. Fixes: f7af616c ("net: iosm: infrastructure") Reported-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Lijun Pan authored
The 3rd argument is u32 by function definition while it is __be32 by function declaration. Signed-off-by:
Lijun Pan <lijunp213@gmail.com> Signed-off-by:
-
David S. Miller authored
Oleksij Rempel says: ==================== provide cable test support for the ksz886x switch changes v5: - drop resume() patch - add Reviewed-by tags. - rework dsa_slave_phy_connect() patch changes v4: - use fallthrough; - use EOPNOTSUPP instead of ENOTSUPP - drop flags variable in dsa_slave_phy_connect patch - extend description for the "net: phy: micrel: apply resume errat" patch - fix "use consistent alignments" patch changes v3: - remove RFC tag changes v2: - use generic MII_* defines where possible - rework phylink validate - remove phylink get state function - reorder cabletest patches to make PHY flag patch in the right order - fix MDI-X detection This patches provide support for cable testing on the ksz886x switches. Since it has one special port, we needed to add phylink with validation and extra quirk for the PHY to signal, that one port will not provide valid cable testing reports. ==================== Signed-off-by: -
Oleksij Rempel authored
This patch support for cable test for the ksz886x switches and the ksz8081 PHY. The patch was tested on a KSZ8873RLL switch with following results: - port 1: - provides invalid values, thus return -ENOTSUPP (Errata: DS80000830A: "LinkMD does not work on Port 1", http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8873-Errata-DS80000830A.pdf) - port 2: - can detect distance - can detect open on each wire of pair A (wire 1 and 2) - can detect open only on one wire of pair B (only wire 3) - can detect short between wires of a pair (wires 1 + 2 or 3 + 6) - short between pairs is detected as open. For example short between wires 2 + 3 is detected as open. Signed-off-by:Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
-
Oleksij Rempel authored
The current get_phy_flags() is only processed when we connect to a PHY via a designed phy-handle property via phylink_of_phy_connect(), but if we fallback on the internal MDIO bus created by a switch and take the dsa_slave_phy_connect() path then we would not be processing that flag and using it at PHY connection time. Suggested-by:
-
Oleksij Rempel authored
Add mapping for LINK_MD register to enable cable testing functionality. Signed-off-by:
-
Oleksij Rempel authored
Add support for MDI-X status and configuration Signed-off-by:
-
Oleksij Rempel authored
Add support for MDI-X status and configuration Signed-off-by:
-
Oleksij Rempel authored
This patch changes the alignments to one space between "#define" and the macro. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
-
Michael Grzeschik authored
This patch adds the phylink support to the ksz8795 driver to provide configuration exceptions on quirky KSZ8863 and KSZ8873 ports. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by:
-
Michael Grzeschik authored
Some micrel devices share the same PHY register defines. This patch moves them to one common header so other drivers can reuse them. And reuse generic MII_* defines where possible. Signed-off-by:
-
Taehee Yoo authored
If link mtu is too big, mld_newpack() allocates high-order page. But most mld packets don't need high-order page. So, it might waste unnecessary pages. To avoid this, it makes mld_newpack() try to allocate order-0 page. Suggested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
-
