- 05 Feb, 2024 10 commits
-
-
Breno Leitao authored
commit 1c870c63 ("net: fill in MODULE_DESCRIPTION()s for ocelot") got a suggestion from Vladimir Oltean after it had landed in net-next. Rewrite the module description according to Vladimir's suggestion. Fixes: 1c870c63 ("net: fill in MODULE_DESCRIPTION()s for ocelot") Suggested-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
Breno Leitao authored
lib/test_blackhole_dev.c sets a variable that is never read, causing this following building warning: lib/test_blackhole_dev.c:32:17: warning: variable 'ethh' set but not used [-Wunused-but-set-variable] Remove the variable struct ethhdr *ethh, which is unused. Fixes: 509e56b3 ("blackhole_dev: add a selftest") Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
David S. Miller authored
Matthieu Baerts says: ==================== mptcp: annotate lockless access This is a series of 5 patches from Paolo to annotate lockless access. The MPTCP locking schema is already quite complex. We need to clarify it and make the lockless access already there consistent, or later changes will be even harder to follow and understand. This series goes through all the msk fields accessed in the RX and TX path and makes the lockless annotation consistent with the in-use locking schema. As a bonus, this should fix data races eventually found by fuzzers -- even if we haven't seen many such reports so far. Patch 1/5 hints we could remove "local_key" and "remote_key" from the subflow context, and always use the ones from the msk socket, possibly reducing the context memory usage. That change is left over as a possible follow-up. ==================== Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by:
-
Paolo Abeni authored
The following MPTCP socket fields: - can_ack - fully_established - rcv_data_fin - snd_data_fin_enable - rcv_fastclose - use_64bit_ack are accessed without any lock, add the appropriate annotation. The schema is safe as each field can change its value at most once in the whole mptcp socket life cycle. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Mat Martineau <martineau@kernel.org> Signed-off-by:
-
Paolo Abeni authored
The token field is manipulated under the msk socket lock and accessed lockless in a few spots, add proper ONCE annotation Signed-off-by:
-
Paolo Abeni authored
The following fields: - ack_seq - snd_una - wnd_end - rmem_fwd_alloc are protected by the data lock end accessed lockless in a few spots. Ensure ONCE annotation for write (under such lock) and for lockless read. Signed-off-by:
-
Paolo Abeni authored
The mptcp-level TX path info (write_seq, bytes_sent, snd_nxt) are under the msk socket lock protection, and are accessed lockless in a few spots. Always mark the write operations with WRITE_ONCE, read operations outside the lock with READ_ONCE and drop the annotation for read under such lock. To simplify the annotations move mptcp_pending_data_fin_ack() from __mptcp_data_acked() to __mptcp_clean_una(), under the msk socket lock, where such call would belong. Signed-off-by:
-
Paolo Abeni authored
Both the local and the remote key follow the same locking schema, put in place the proper ONCE accessors. Signed-off-by:
-
Gerhard Engleder authored
Similar chunk of code is used in tsnep_rx_poll_zc() and tsnep_rx_reopen_xsk() to maintain the RX XDP_RING_NEED_WAKEUP flag. Consolidate the code to common helper function. Suggested-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
Eric Dumazet authored
We can change sctp_sk() to propagate its argument const qualifier, thanks to container_of_const(). Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Xin Long <lucien.xin@gmail.com> Acked-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
- 04 Feb, 2024 6 commits
-
-
Eric Dumazet authored
We can use a global dev_unreg_count counter instead of a per netns one. As a bonus we can factorize the changes done on it for bulk device removals. Signed-off-by:
-
Yunjian Wang authored
Implement the tun .get_channels functionality. This feature is necessary for some tools, such as libxdp, which need to retrieve the queue count. Signed-off-by:
Yunjian Wang <wangyunjian@huawei.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Yunjian Wang authored
This fixes the following code style problem: - WARNING: please, no spaces at the start of a line - CHECK: Please use a blank line after function/struct/union/enum declarations Signed-off-by: -
Heiner Kallweit authored
This adds support for the RTL8126A found on Asus z790 Maximus Formula. It was successfully tested w/o the firmware at 1000Mbps. Firmware file has been provided by Realtek and submitted to linux-firmware. 2.5G and 5G modes are untested. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Paolo points out that ifconfig is legacy and we should not use it. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
-
Horatiu Vultur authored
By default lan8841's 1588 clock frequency is 125MHz. But when adjusting the frequency, it is using the 1PPM format of the lan8814. Which is the wrong format as lan8814 has a 1588 clock frequency of 250MHz. So then for each 1PPM adjustment would adjust less than expected. Therefore fix this by using the correct 1PPM format for lan8841. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 03 Feb, 2024 10 commits
-
-
David S. Miller authored
Christian Marangi says: ==================== net: phy: qcom: qca808x: fixup qca808x LED This is a bit embarassing and totally my fault so sorry for that! While reworking the patch to phy_modify API, it was done a logic error and made the brightness_set function broken. It wasn't notice in last revisions test as the testing method was to verify if hw control was correctly working. Noticing this problem also made me notice an additional problem with the polarity. The introduced patch made the polarity configurable but I forgot to add the required code to enable Active High by default. (the PHY sets active low by default) This wasn't notice with hw control testing as the LED blink on traffic and polarity problem are not notice. It might be worth discussing if needed a change in implementation where the polarity function is always called but I think it's better this way where specific PHY apply fixup with the help of priv struct and on the config_init phase. ==================== Signed-off-by: -
Christian Marangi authored
qca808x PHY provide support for the led_polarity_set OP to configure and apply the active-low property but on PHY reset, the Active High bit is not set resulting in the LED driven as active-low. To fix this, check if active-low is not set in DT and enable Active High polarity by default to restore correct funcionality of the LED. Fixes: 7196062b ("net: phy: at803x: add LED support for qca808x") Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
-
Christian Marangi authored
In switching to using phy_modify_mmd and a more short version of the LED ON/OFF condition in later revision, it was made a logic error where value ? QCA808X_LED_FORCE_ON : QCA808X_LED_FORCE_OFF is always true as value is always OR with QCA808X_LED_FORCE_EN due to missing () resulting in the testing condition being QCA808X_LED_FORCE_EN | value. Add the () to apply the correct condition and restore correct functionality of the brightness ON/OFF. Fixes: 7196062b ("net: phy: at803x: add LED support for qca808x") Signed-off-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== tools: ynl: auto-gen for all genetlink families The code gen has caught up with all features required in genetlink families in Linux 6.8 already. We have also stopped committing auto- -generated user space code to the tree. Instead of listing all the families in the Makefile search the spec directory, and generate code for everything that's not legacy netlink. ==================== Link: https://lore.kernel.org/r/20240202004926.447803-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Instead of listing the genetlink families that we want to codegen for, always codegen for everyone. We can add an opt-out later but it seems like most families are not causing any issues, and yet folks forget to add them to the Makefile. Reviewed-by:
-
Jakub Kicinski authored
Add ovs_flow, ovs_vport and ovs_datapath to the families supported in C. ovs-flow has some circular nesting which is fun to deal with, but the necessary support has been added already in the previous release cycle. Add a sample that proves that dealing with fixed headers does actually work correctly. Reviewed-by:
-
Jakub Kicinski authored
The DPLL and mptcp_pm families are pretty clean, and YNL C codegen supports them fully with no changes. Add them to user space codegen so that C samples can be written, and we know immediately if changes to these families require YNL codegen work. Reviewed-by:
-
Eric Dumazet authored
Both addrconf_verify_work() and addrconf_dad_work() acquire rtnl, there is no point trying to have one thread per cpu. Signed-off-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20240201173031.3654257-1-edumazet@google.comSigned-off-by:
-
Heiner Kallweit authored
We don't have to store the EEE modes to be advertised in the driver, phylib does this for us and stores it in phydev->advertising_eee. phylib also takes care of properly handling the EEE advertisement. Signed-off-by:
-
Heiner Kallweit authored
A user reported that first consumer mainboards show up with a RTL8126A 5Gbps MAC/PHY. This adds support for the integrated PHY, which is also available stand-alone. From a PHY driver perspective it's treated the same as the 2.5Gbps PHY's, we just have to support the new PHY ID. Reported-by:
Joe Salmeri <jmscdba@gmail.com> Signed-off-by:
-
- 02 Feb, 2024 14 commits
-
-
Jakub Kicinski authored
Michal Koutný says: ==================== net/sched: Load modules via alias These modules may be loaded lazily without user's awareness and control. Add respective aliases to modules and request them under these aliases so that modprobe's blacklisting mechanism (through aliases) works for them. (The same pattern exists e.g. for filesystem modules.) For example (before the change): $ tc filter add dev lo parent 10: protocol ip prio 10 handle 1: cgroup # cls_cgroup module is loaded despite a `blacklist cls_cgroup` entry # in /etc/modprobe.d/*.conf After the change: $ tc filter add dev lo parent 10: protocol ip prio 10 handle 1: cgroup Error: TC classifier not found. We have an error talking to the kernel # explicit/acknowledged (privileged) action is needed $ modprobe cls_cgroup # blacklist entry won't apply to this direct modprobe, module is # loaded with awareness A considered alternative was invoking `modprobe -b` always from request_module(), however, dismissed as too intrusive and slightly confusing in favor of the precedented aliases (the commit 7f78e035 ("fs: Limit sys_mount to only request filesystem modules."). User experience suffers in both alternatives. Its improvement is orthogonal to blacklist honoring. v1: https://lore.kernel.org/r/20231121175640.9981-1-mkoutny@suse.com v2 https://lore.kernel.org/r/20231206192752.18989-1-mkoutny@suse.com v3 https://lore.kernel.org/r/20240112180646.13232-1-mkoutny@suse.com v4 https://lore.kernel.org/r/20240123135242.11430-1-mkoutny@suse.comAcked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by:
-
Michal Koutný authored
The module sch_ingress stands out among net/sched modules because it provides multiple act/sch functionalities in a single .ko. They have aliases to make autoloading work for any of the provided functionalities. Since the autoloading was changed to uniformly request any functionality under its alias, the non-systemic aliases can be removed now (i.e. assuming the alias were only used to ensure autoloading). Signed-off-by:
Michal Koutný <mkoutny@suse.com> Acked-by:
-
Michal Koutný authored
The cls_,sch_,act_ modules may be loaded lazily during network configuration but without user's awareness and control. Switch the lazy loading from canonical module names to a module alias. This allows finer control over lazy loading, the precedent from commit 7f78e035 ("fs: Limit sys_mount to only request filesystem modules.") explains it already: Using aliases means user space can control the policy of which filesystem^W net/sched modules are auto-loaded by editing /etc/modprobe.d/*.conf with blacklist and alias directives. Allowing simple, safe, well understood work-arounds to known problematic software. By default, nothing changes. However, if a specific module is blacklisted (its canonical name), it won't be modprobe'd when requested under its alias (i.e. kernel auto-loading). It would appear as if the given module was unknown. The module can still be loaded under its canonical name, which is an explicit (privileged) user action. Signed-off-by:
-
Michal Koutný authored
No functional change intended, aliases will be used in followup commits. Note for backporters: you may need to add aliases also for modules that are already removed in mainline kernel but still in your version. Patches were generated with the help of Coccinelle scripts like: cat >scripts/coccinelle/misc/tcf_alias.cocci <<EOD virtual patch virtual report @ haskernel @ @@ @ tcf_has_kind depends on report && haskernel @ identifier ops; constant K; @@ static struct tcf_proto_ops ops = { .kind = K, ... }; +char module_alias = K; EOD /usr/bin/spatch -D report --cocci-file scripts/coccinelle/misc/tcf_alias.cocci \ --dir . \ -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include \ -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi \ -I ./include/uapi -I ./include/generated/uapi \ --include ./include/linux/compiler-version.h --include ./include/linux/kconfig.h \ --jobs 8 --chunksize 1 2>/dev/null | \ sed 's/char module_alias = "\([^"]*\)";/MODULE_ALIAS_NET_CLS("\1");/' And analogously for: static struct tc_action_ops ops = { .kind = K, static struct Qdisc_ops ops = { .id = K, (Someone familiar would be able to fit those into one .cocci file without sed post processing.) Signed-off-by: -
Michal Koutný authored
The macros are preparation for adding module aliases en mass in a separate commit. Although it would be tempting to create aliases like cls-foo for name cls_foo, this could not be used because modprobe utilities treat '-' and '_' interchangeably. In the end, the naming follows pattern of proto modules in linux/net.h. Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - Improve error handling in DAT and uevent generator, by Markus Elfring (2 patches) - Drop usage of export.h, by Sven Eckelmann ==================== Signed-off-by: -
Kunwu Chan authored
Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Signed-off-by:
Kunwu Chan <chentao@kylinos.cn> Reviewed-by:
-
Ravi Gunasekaran authored
Update the list with the current maintainers of TI's CPSW ethernet peripheral. Signed-off-by:
Ravi Gunasekaran <r-gunasekaran@ti.com> Acked-by:
Roger Quadros <rogerq@kernel.org> Signed-off-by:
-
Kunwu Chan authored
commit 0a31bd5f ("KMEM_CACHE(): simplify slab cache creation") introduces a new macro. Use the new KMEM_CACHE() macro instead of direct kmem_cache_create to simplify the creation of SLAB caches. Signed-off-by:
-
David S. Miller authored
Geetha sowjanya says: ==================== Dynamically allocate BPIDs for LBK In current driver 64 BPIDs are reserved for LBK interfaces. These bpids are 1-to-1 mapped to LBK interface channel numbers. In some usecases one LBK interface required more than one bpids and in some case they may not require at all. These usescas can't be address with the current implementation as it always reserves only one bpid per LBK channel. This patch addresses this issue by creating free bpid pool from these 64 bpids instead of 1-to-1 mapping to the lbk channel. Now based on usecase LBK interface can request a bpid using (bp_enable()). v1 -> v2: - Modified commit message. - Dropped patch2, as for now rvu netdev have no usecase. Will be upstream along with the CPT driver. - Addressed review comments by Simon Horman. ==================== Signed-off-by: -
Geetha sowjanya authored
PCI device IDs of RVU device IDs are configurable and RVU PF0's (ie AF's) are currently assumed as VFs that identify loopback functionality ie LBKVFs. But in some cases these VFs can be setup for different functionality. Hence remove assumptions that AF's VFs are always LBK VFs by renaming 'is_afvf' as 'is_lbkvf' explicitly and also identify LBK VF using PCI dev ID. Similar change is done for other VF types. Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Reviewed-by:
-
Geetha sowjanya authored
In current driver 64 BPIDs are reserved for LBK interfaces. These bpids are 1-to-1 mapped to LBK interface channel numbers. In some usecases one LBK interface required more than one bpids and in some case they may not require at all. These usescase can't be address with the current implementation as it always reserves only one bpid per LBK channel. This patch addresses this issue by creating free bpid pool from these 64 bpids instead of 1-to-1 mapping to the lbk channel. Now based on usecase LBK interface can request a bpid using (bp_enable()). This patch also reduces the number of bpids for cgx interfaces to 8 and adds proper error code Signed-off-by:
-
Brad Cowie authored
Add a test case for regression in openvswitch nat that was fixed by commit e6345d28 ("netfilter: nf_nat: fix action not being set for all ct states"). Link: https://lore.kernel.org/netdev/20231221224311.130319-1-brad@faucet.nz/ Link: https://mail.openvswitch.org/pipermail/ovs-dev/2024-January/410476.htmlSuggested-by:
Aaron Conole <aconole@redhat.com> Signed-off-by:
Brad Cowie <brad@faucet.nz> Tested-by:
-
Alexander Stein authored
Add the led_polarity_set callback for setting LED polarity. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
-
