- 18 Oct, 2021 29 commits
-
-
Jakub Kicinski authored
mlx5_tout_ms() returns a u64, we can't directly divide it. This is not a problem here, @timeout which is the value that actually matters here is already a ulong, so this implies storing return value of mlx5_tout_ms() on a ulong should be fine. This fixes: ERROR: modpost: "__udivdi3" [drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko] undefined! Fixes: 32def412 ("net/mlx5: Read timeout values from DTOR") Link: https://lore.kernel.org/r/20211018172608.1069754-1-kuba@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Erik Ekman authored
Everything except the first 32 bits was lost when the pause flags were added. This makes the 50000baseCR2 mode flag (bit 34) not appear. I have tested this with a 10G card (SFN5122F-R7) by modifying it to return a non-legacy link mode (10000baseCR). Signed-off-by:
Erik Ekman <erik@kryo.se> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ansuel Smith authored
Fix delay settings applied to wrong cpu in parse_port_config. The delay values is set to the wrong index as the cpu_port_index is incremented too early. Start the cpu_port_index to -1 so the correct value is applied to address also the case with invalid phy mode and not available port. Signed-off-by:
Ansuel Smith <ansuelsmth@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter/IPVS updates for net-next The following patchset contains Netfilter/IPVS for net-next: 1) Add new run_estimation toggle to IPVS to stop the estimation_timer logic, from Dust Li. 2) Relax superfluous dynset check on NFT_SET_TIMEOUT. 3) Add egress hook, from Lukas Wunner. 4) Nowadays, almost all hook functions in x_table land just call the hook evaluation loop. Remove remaining hook wrappers from iptables and IPVS. From Florian Westphal. ==================== Signed-off-by: -
David S. Miller authored
Alvin Šipraga says: ==================== net: dsa: add support for RTL8365MB-VC This series adds support for Realtek's RTL8365MB-VC, a 4+1 port 10/100/1000M Ethernet switch. The driver - rtl8365mb - was developed by Michael Ramussen and myself. This version of the driver is relatively slim, implementing only the standalone port functionality and no offload capabilities. It is based on a previous RFC series [1] from August, and the main difference is the removal of some spurious VLAN operations. Otherwise I have simply addressed most of the feedback. Please see the respective patches for more detail. In parallel I am working on offloading the bridge layer capabilities, but I would like to get the basic stuff upstreamed as soon as possible. v3 -> v4: - get irq before setting virq parents (fixes kernel test robot warning) - remove pad-to-72-bytes logic in tagger xmit (fixes DENG Qingfang's suggestion); no longer needed as we set CPU minimum RX size to 64 bytes - use mutex to protect MIB counter access instead of a spinlock (fixes Jakub's feedback on v3 statistics refactoring) v2 -> v3: - move IRQ setup earlier in probe per Florian's suggestion - fix compilation error on some archs due to FIELD_PREP use in v1 - follow Jakub's suggestion and use the standard ethtool stats API; NOTE: new patch in the series for relevant DSA plumbing - following the stats change, it became apparent that the rtl8366 helper library is no longer that helpful; scrap it and implement the ethtool ops specifically for this chip v1 -> v2: - drop DSA port type checks during MAC configuration - use OF properties to configure RGMII TX/RX delay - don't set default fwd_offload_mark if packet is trapped to CPU - remove port mapping macros - update device tree bindings documentation with an example - cosmetic changes to the tagging driver using FIELD_* macros [1] https://lore.kernel.org/netdev/20210822193145.1312668-1-alvin@pqrs.dk/ ==================== Signed-off-by: -
Alvin Šipraga authored
The RTL8365MB-VC ethernet switch controller has 4 internal PHYs for its user-facing ports. All that is needed is to let the PHY driver core pick up the IRQ made available by the switch driver. Signed-off-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Alvin Šipraga authored
This patch adds a realtek-smi subdriver for the RTL8365MB-VC 4+1 port 10/100/1000M switch controller. The driver has been developed based on a GPL-licensed OS-agnostic Realtek vendor driver known as rtl8367c found in the OpenWrt source tree. Despite the name, the RTL8365MB-VC has an entirely different register layout to the already-supported RTL8366RB ASIC. Notwithstanding this, the structure of the rtl8365mb subdriver is loosely based on the rtl8366rb subdriver. Like the 'rb, it establishes its own irqchip to handle cascaded PHY link status interrupts. The RTL8365MB-VC switch is capable of offloading a large number of features from the software, but this patch introduces only the most basic DSA driver functionality. The ports always function as standalone ports, with bridging handled in software. One more thing. Realtek's nomenclature for switches makes it hard to know exactly what other ASICs might be supported by this driver. The vendor driver goes by the name rtl8367c, but as far as I can tell, no chip actually exists under this name. As such, the subdriver is named rtl8365mb to emphasize the potentially limited support. But it is clear from the vendor sources that a number of other more advanced switches share a similar register layout, and further support should not be too hard to add given access to the relevant hardware. With this in mind, the subdriver has been written with as few assumptions about the particular chip as is reasonable. But the RTL8365MB-VC is the only hardware I have available, so some further work is surely needed. Co-developed-by:
Michael Rasmussen <mir@bang-olufsen.dk> Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by:
-
Alvin Šipraga authored
This commit implements a basic version of the 8 byte tag protocol used in the Realtek RTL8365MB-VC unmanaged switch, which carries with it a protocol version of 0x04. The implementation itself only handles the parsing of the EtherType value and Realtek protocol version, together with the source or destination port fields. The rest is left unimplemented for now. The tag format is described in a confidential document provided to my company by Realtek Semiconductor Corp. Permission has been granted by the vendor to publish this driver based on that material, together with an extract from the document describing the tag format and its fields. It is hoped that this will help future implementors who do not have access to the material but who wish to extend the functionality of drivers for chips which use this protocol. In addition, two possible values of the REASON field are specified, based on experiments on my end. Realtek does not specify what value this field can take. Signed-off-by:
-
Alvin Šipraga authored
rtl8365mb is a new realtek-smi subdriver for the RTL8365MB-VC 4+1 port 10/100/1000M Ethernet switch controller. Its compatible string is "realtek,rtl8365mb". Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Alvin Šipraga authored
Move things around a little so that this tag driver is alphabetically ordered. The Kconfig file is sorted based on the tristate text. Suggested-by:
-
Alvin Šipraga authored
Jakub pointed out that we have a new ethtool API for reporting device statistics in a standardized way, via .get_eth_{phy,mac,ctrl}_stats. Add a small amount of plumbing to allow DSA drivers to take advantage of this when exposing statistics. Suggested-by: -
Alvin Šipraga authored
Add a new EtherType ETH_P_REALTEK to the if_ether.h uapi header. The EtherType 0x8899 is used in a number of different protocols from Realtek Semiconductor Corp [1], so no general assumptions should be made when trying to decode such packets. Observed protocols include: 0x1 - Realtek Remote Control protocol [2] 0x2 - Echo protocol [2] 0x3 - Loop detection protocol [2] 0x4 - RTL8365MB 4- and 8-byte switch CPU tag protocols [3] 0x9 - RTL8306 switch CPU tag protocol [4] 0xA - RTL8366RB switch CPU tag protocol [4] [1] https://lore.kernel.org/netdev/CACRpkdYQthFgjwVzHyK3DeYUOdcYyWmdjDPG=Rf9B3VrJ12Rzg@mail.gmail.com/ [2] https://www.wireshark.org/lists/ethereal-dev/200409/msg00090.html [3] https://lore.kernel.org/netdev/20210822193145.1312668-4-alvin@pqrs.dk/ [4] https://lore.kernel.org/netdev/20200708122537.1341307-2-linus.walleij@linaro.org/Suggested-by:
-
Jakub Kicinski authored
Commit 406f42fa ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Signed-off-by:
-
Arnd Bergmann authored
Building the VF and PF side of this driver differently, with one being a loadable module and the other one built-in results in a link failure for the common PTP driver: ld.lld: error: undefined symbol: __this_module >>> referenced by otx2_ptp.c >>> net/ethernet/marvell/octeontx2/nic/otx2_ptp.o:(otx2_ptp_init) in archive drivers/built-in.a >>> referenced by otx2_ptp.c >>> net/ethernet/marvell/octeontx2/nic/otx2_ptp.o:(otx2_ptp_init) in archive drivers/built-in.a Move the otx2_ptp.c code into a separate module that gets built for both configurations, making it built-in if at least one of the other two is built-in. Fixes: 43510ef4 ("octeontx2-nicvf: Add PTP hardware clock support to NIX VF") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David S. Miller authored
Kunihiko Hayashi says: ==================== net: ethernet: ave: Introduce UniPhier NX1 SoC support This series includes the patches to add basic support for new UniPhier NX1 SoC. NX1 SoC also has the same kinds of controls as the other UniPhier SoCs. ==================== Signed-off-by: -
Kunihiko Hayashi authored
Add basic support for UniPhier NX1 SoC. This includes a compatible string and SoC-dependent data. Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by:
-
Kunihiko Hayashi authored
Update AVE binding document for UniPhier NX1 SoC. Signed-off-by:
-
Uwe Kleine-König authored
Up to now w5100_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of platform and spi remove callbacks is ignored anyway. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
Up to now ks8851_remove_common() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of platform and spi remove callbacks is ignored anyway. Signed-off-by:
-
David S. Miller authored
Sebastian Andrzej Siewior says: ==================== Try to simplify the gnet_stats and remove qdisc->running sequence counter. The first few patches is a follow up to https://lore.kernel.org/all/20211007175000.2334713-1-bigeasy@linutronix.de/ The remaining patches (#5+) remove the seqcount_t (Qdisc::running) from the Qdisc. The statistics (Qdisc::bstats and Qdisc::cpu_bstats) use u64_stats_t and the "running state" is now represented by a bit in Qdisc::state. By removing the seqcount_t from Qdisc and decoupling the bstats statistics from the seqcount_t it is possible to query the statistics even if the Qdisc is running instead of waiting until it is idle again. The try-lock like usage of the seqcount_t in qdisc_run_begin() is problematic on PREEMPT_RT. Inside the qdisc_run_begin/end() qdisc->running sequence counter write sections, at sch_direct_xmit(), the seqcount write serialization lock is released then re-acquired. This is fine for !RT, because the writer is in a BH disabled region and there is a no in-IRQ reader. For RT though, BH sections are preemptible. The earlier introduced seqcount_LOCKNAME_t mechanism, which for RT the reader acquires then relesaes the write serailization lock to avoid infinite spinning if it preempts a seqcount write section, cannot work: the qdisc->running write serialization lock is already intermittingly released inside the seqcount write section. ==================== Signed-off-by: -
Ahmed S. Darwish authored
The Qdisc::running sequence counter has two uses: 1. Reliably reading qdisc's tc statistics while the qdisc is running (a seqcount read/retry loop at gnet_stats_add_basic()). 2. As a flag, indicating whether the qdisc in question is running (without any retry loops). For the first usage, the Qdisc::running sequence counter write section, qdisc_run_begin() => qdisc_run_end(), covers a much wider area than what is actually needed: the raw qdisc's bstats update. A u64_stats sync point was thus introduced (in previous commits) inside the bstats structure itself. A local u64_stats write section is then started and stopped for the bstats updates. Use that u64_stats sync point mechanism for the bstats read/retry loop at gnet_stats_add_basic(). For the second qdisc->running usage, a __QDISC_STATE_RUNNING bit flag, accessed with atomic bitops, is sufficient. Using a bit flag instead of a sequence counter at qdisc_run_begin/end() and qdisc_is_running() leads to the SMP barriers implicitly added through raw_read_seqcount() and write_seqcount_begin/end() getting removed. All call sites have been surveyed though, and no required ordering was identified. Now that the qdisc->running sequence counter is no longer used, remove it. Note, using u64_stats implies no sequence counter protection for 64-bit architectures. This can lead to the qdisc tc statistics "packets" vs. "bytes" values getting out of sync on rare occasions. The individual values will still be valid. Signed-off-by:Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Ahmed S. Darwish authored
The only factor differentiating per-CPU bstats data type (struct gnet_stats_basic_cpu) from the packed non-per-CPU one (struct gnet_stats_basic_packed) was a u64_stats sync point inside the former. The two data types are now equivalent: earlier commits added a u64_stats sync point to the latter. Combine both data types into "struct gnet_stats_basic_sync". This eliminates redundancy and simplifies the bstats read/write APIs. Use u64_stats_t for bstats "packets" and "bytes" data types. On 64-bit architectures, u64_stats sync points do not use sequence counter protection. Signed-off-by:
-
Ahmed S. Darwish authored
The Qdisc::running sequence counter, used to protect Qdisc::bstats reads from parallel writes, is in the process of being removed. Qdisc::bstats read/writes will synchronize using an internal u64_stats sync point instead. Modify all bstats writes to use _bstats_update(). This ensures that the internal u64_stats sync point is always acquired and released as appropriate. Signed-off-by:
-
Ahmed S. Darwish authored
The not-per-CPU variant of qdisc tc (traffic control) statistics, Qdisc::gnet_stats_basic_packed bstats, is protected with Qdisc::running sequence counter. This sequence counter is used for reliably protecting bstats reads from parallel writes. Meanwhile, the seqcount's write section covers a much wider area than bstats update: qdisc_run_begin() => qdisc_run_end(). That read/write section asymmetry can lead to needless retries of the read section. To prepare for removing the Qdisc::running sequence counter altogether, introduce a u64_stats sync point inside bstats instead. Modify _bstats_update() to start/end the bstats u64_stats write section. For bisectability, and finer commits granularity, the bstats read section is still protected with a Qdisc::running read/retry loop and qdisc_run_begin/end() still starts/ends that seqcount write section. Once all call sites are modified to use _bstats_update(), the Qdisc::running seqcount will be removed and bstats read/retry loop will be modified to utilize the internal u64_stats sync point. Note, using u64_stats implies no sequence counter protection for 64-bit architectures. This can lead to the statistics "packets" vs. "bytes" values getting out of sync on rare occasions. The individual values will still be valid. [bigeasy: Minor commit message edits, init all gnet_stats_basic_packed.] Signed-off-by:
-
Ahmed S. Darwish authored
Allow to directly set a u64_stats_t value which is used to provide an init function which sets it directly to zero intead of memset() the value. Add u64_stats_set() to the u64_stats API. [bigeasy: commit message. ] Signed-off-by:
-
Sebastian Andrzej Siewior authored
The gnet_stats_queue::qlen member is only used in the SMP-case. qdisc_qstats_qlen_backlog() needs to add qdisc_qlen() to qstats.qlen to have the same value as that provided by qdisc_qlen_sum(). gnet_stats_copy_queue() needs to overwritte the resulting qstats.qlen field whith the caller submitted qlen value. It might be differ from the submitted value. Let both functions use gnet_stats_add_queue() and remove unused __gnet_stats_copy_queue(). Signed-off-by:
-
Sebastian Andrzej Siewior authored
gnet_stats_add_basic() and gnet_stats_add_queue() add up the statistics so they can be used directly for both the per-CPU and global case. gnet_stats_add_queue() copies either Qdisc's per-CPU gnet_stats_queue::qlen or the global member. The global gnet_stats_queue::qlen isn't touched in the per-CPU case so there is no need to consider it in the global-case. In the per-CPU case, the sum of global gnet_stats_queue::qlen and the per-CPU gnet_stats_queue::qlen was assigned to sch->q.qlen and sch->qstats.qlen. Now both fields are copied individually. Signed-off-by:
-
Sebastian Andrzej Siewior authored
This function will replace __gnet_stats_copy_queue(). It reads all arguments and adds them into the passed gnet_stats_queue argument. In contrast to __gnet_stats_copy_queue() it also copies the qlen member. Signed-off-by:
-
Sebastian Andrzej Siewior authored
__gnet_stats_copy_basic() always assigns the value to the bstats argument overwriting the previous value. The later added per-CPU version always accumulated the values in the returning gnet_stats_basic_packed argument. Based on review there are five users of that function as of today: - est_fetch_counters(), ___gnet_stats_copy_basic() memsets() bstats to zero, single invocation. - mq_dump(), mqprio_dump(), mqprio_dump_class_stats() memsets() bstats to zero, multiple invocation but does not use the function due to !qdisc_is_percpu_stats(). Add the values in __gnet_stats_copy_basic() instead overwriting. Rename the function to gnet_stats_add_basic() to make it more obvious. Signed-off-by:
-
- 17 Oct, 2021 1 commit
-
-
Lukas Wunner authored
Unlike gcc, clang warns about unused static inlines that are not in an include file: net/netfilter/core.c:344:20: error: unused function 'nf_ingress_hook' [-Werror,-Wunused-function] static inline bool nf_ingress_hook(const struct nf_hook_ops *reg, int pf) ^ net/netfilter/core.c:353:20: error: unused function 'nf_egress_hook' [-Werror,-Wunused-function] static inline bool nf_egress_hook(const struct nf_hook_ops *reg, int pf) ^ According to commit 6863f564 ("kbuild: allow Clang to find unused static inline functions for W=1 build"), the proper resolution is to mark the affected functions as __maybe_unused. An alternative approach would be to move them to include/linux/netfilter_netdev.h, but since Pablo didn't do that in commit ddcfa710 ("netfilter: add nf_ingress_hook() helper function"), I'm guessing __maybe_unused is preferred. This fixes both the warning introduced by Pablo in v5.10 as well as the one recently introduced by myself with commit 42df6e1d ("netfilter: Introduce egress hook"). Fixes: ddcfa710 ("netfilter: add nf_ingress_hook() helper function") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
- 16 Oct, 2021 10 commits
-
-
Kyungrok Chung authored
Make use of netdev helper functions to improve code readability. Replace 'dev->priv_flags & IFF_EBRIDGE' with netif_is_bridge_master(dev). Signed-off-by:
Kyungrok Chung <acadx0@gmail.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
David S. Miller authored
Karsten Graul says: ==================== net/smc: introduce SMC-Rv2 support Please apply the following patch series for smc to netdev's net-next tree. SMC-Rv2 support (see https://www.ibm.com/support/pages/node/6326337) provides routable RoCE support for SMC-R, eliminating the current same-subnet restriction, by exploiting the UDP encapsulation feature of the RoCE adapter hardware. v2: resend of the v1 patch series, and CC linux-rdma this time v3: rebase after net tree was merged into net-next ==================== Signed-off-by:
-
Karsten Graul authored
With SMC-Rv2 the GID is an IP address that can be deleted from the device. When an IB_EVENT_GID_CHANGE event is provided then iterate over all active links and check if their GID is still defined. Otherwise stop the affected link. Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
Karsten Graul authored
Implement the netlink support for SMC-Rv2 related attributes that are provided to user space. Signed-off-by:
-
Karsten Graul authored
Add support for large v2 LLC control messages in smc_llc.c. The new large work request buffer allows to combine control messages into one packet that had to be spread over several packets before. Add handling of the new v2 LLC messages. Signed-off-by:
-
Karsten Graul authored
In the work request layer define one large v2 buffer for each link group that is used to transmit and receive large LLC control messages. Add the completion queue handling for this buffer. Signed-off-by:
-
Karsten Graul authored
In smc_ib.c, scan for RoCE devices that support UDP encapsulation. Find an eligible device and check that there is a route to the remote peer. Signed-off-by:
-
Karsten Graul authored
The CLC decline message changed with SMC-Rv2 and supports up to 4 additional diagnosis codes. Signed-off-by:
-
Karsten Graul authored
Implement the server side of the SMC-Rv2 processing. Process incoming CLC messages, find eligible devices and check for a valid route to the remote peer. Signed-off-by:
-
Karsten Graul authored
Send a CLC proposal message, and the remote side process this type of message and determine the target GID. Check for a valid route to this GID, and complete the connection establishment. Signed-off-by:
-
