- 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:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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:
Jiri Pirko <jiri@nvidia.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 24 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:
Xin Long <lucien.xin@gmail.com> 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:
Simon Horman <horms@kernel.org> Signed-off-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:
-
David S. Miller authored
Christian Marangi says: ==================== net: mdio-ipq4019: fix wrong default MDC rate This was a long journey to arrive and discover this problem. To not waste too much char, there is a race problem with PHY and driver probe. This was observed with Aquantia PHY firmware loading. With some hacks the race problem was workarounded but an interesting thing was notice. It took more than a minute for the firmware to load via MDIO. This was strange as the same operation was done by UBoot in at max 5 second and the same data was loaded. A similar problem was observed on a mtk board that also had an Aquantia PHY where the load was very slow. It was notice that the cause was the MDIO bus running at a very low speed and the firmware was missing a property (present in mtk sdk) that set the right frequency to the MDIO bus. It was fun to find that THE VERY SAME PROBLEM is present on IPQ in a different form. The MDIO apply internally a division to the feed clock resulting in the bus running at 390KHz instead of 6.25Mhz. Searching around the web for some documentation and some include and analyzing the uboot codeflow resulted in the divider being set wrongly at /256 instead of /16 as the value was actually never set. Applying the value restore the original load time for the Aquantia PHY. This series mainly handle this by adding support for the "clock-frequency" property. Changes v3: - Add Reviewed-by tag - Fix english grammar error in comment - Drop DTS patch Changes v2: - Use DIV_ROUND_UP - Introduce logic to chose a default value for 802.3 spec 2.5MHz ==================== Signed-off-by: -
Christian Marangi authored
The IPQ4019 MDIO internally divide the clock feed by AHB based on the MDIO_MODE reg. On reset or power up, the default value for the divider is 0xff that reflect the divider set to /256. This makes the MDC run at a very low rate, that is, considering AHB is always fixed to 100Mhz, a value of 390KHz. This hasn't have been a problem as MDIO wasn't used for time sensitive operation, it is now that on IPQ807x is usually mounted with PHY that requires MDIO to load their firmware (example Aquantia PHY). To handle this problem and permit to set the correct designed MDC frequency for the SoC add support for the standard "clock-frequency" property for the MDIO node. The divider supports value from /1 to /256 and the common value are to set it to /16 to reflect 6.25Mhz or to /8 on newer platform to reflect 12.5Mhz. To scan if the requested rate is supported by the divider, loop with each supported divider and stop when the requested rate match the final rate with the current divider. An error is returned if the rate doesn't match any value. On MDIO reset, the divider is restored to the requested value to prevent any kind of downclocking caused by the divider reverting to a default value. To follow 802.3 spec of 2.5MHz of default value, if divider is set at /256 and "clock-frequency" is not set in DT, assume nobody set the divider and try to find the closest MDC rate to 2.5MHz. (in the case of AHB set to 100MHz, it's 1.5625MHz) While at is also document other bits of the MDIO_MODE reg to have a clear idea of what is actually applied there. Documentation of some BITs is skipped as they are marked as reserved and their usage is not clear (RES 11:9 GENPHY 16:13 RES1 19:17) Signed-off-by:
-
Christian Marangi authored
Document support for clock-frequency and add details on why this property is needed and what values are supported. From internal documentation, while other values are supported, the correct function of the MDIO bus is not assured hence add only the suggested supported values to the property enum. Signed-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: simplify TX power handling In order to deliver a packet to the IPA hardware, we must ensure it is powered. We request power by calling pm_runtime_get(), and its return value tells us the power state. We can't block in ipa_start_xmit(), so if power isn't enabled we prevent further transmit attempts by calling netif_stop_queue(). Power will eventually become enabled, at which point we call netif_wake_queue() to allow the transmit to be retried. When it does, the power should be enabled, so the packet delivery can proceed. The logic that handles this is convoluted, and was put in place to address a race condition pointed out by Jakub Kicinski during review. The fix addressed that race, as well as another one that was found while investigating it: b8e36e13 ("net: ipa: fix TX queue race") I have wanted to simplify this code ever since, and I'm pleased to report that this series implements a much better solution that avoids both race conditions. The first race occurs between the ->ndo_start_xmit thread and the runtime resume thread. If we find power is not enabled when requested in ipa_start_xmit(), we stop queueing. But there's a chance the runtime resume will enable queuing just before that, leaving queueing stopped forever. A flag is used to ensure that does not occur. A second flag is used to prevent NETDEV_TX_BUSY from being returned repeatedly during the small window between enabling queueing and finishing power resume. This can happen if resume was underway when pm_runtime_get() was called and completes immediately afterward. This condition only exists because of the use of the first flag. The fix is to disable transmit for *every* call to ipa_start_xmit(), disabling it *before* calling pm_runtime_get(). This leaves three cases: - If the return value indicates power is not active (or is in transition), queueing remains disabled--thereby avoiding the race between disabling it and a concurrent power thread enabling it. - If pm_runtime_get() returns an error, we drop the packet and re-enable queueing. - Finally, if the hardware is powered, we re-enable queueing before delivering the packet to the hardware. So the first race is avoided. And as a result, the second condition will not occur. The first patch adds pointers to the TX and RX IPA endpoints in the netdev private data. The second patch has netif_stop_queue() be called for all packets; if pm_runtime_get() indicates power is enabled (or an error), netif_wake_queue() is called to enable it again. The third and fourth patches get rid of the STARTED and STOPPED IPA power flags, as well as the power spinlock, because they are no longer needed. The last three patches just eliminate some trivial functions, open-coding them instead. ==================== Link: https://lore.kernel.org/r/20240130192305.250915-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
All ipa_power_modem_queue_wake() does is call netif_wake_queue() on the modem netdev. There is no need to wrap that call in a trivial function (and certainly not one defined in "ipa_power.c"). So get rid of ipa_power_modem_queue_wake(), and replace its one caller with a direct call to netif_wake_queue(). Determine the netdev pointer to use from the private TX endpoint's netdev pointer. Signed-off-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20240130192305.250915-8-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
All ipa_power_modem_queue_active() does now is call netif_wake_queue(). Just call netif_wake_queue() in the two places it's needed, and get rid of ipa_power_modem_queue_active(). Signed-off-by:
-
Alex Elder authored
All ipa_power_modem_queue_stop() does now is call netif_stop_queue(). Just call netif_stop_queue() in the one place it's needed, and get rid of ipa_power_modem_queue_stop(). Signed-off-by:
-
Alex Elder authored
Currently the STOPPED IPA power flag is used to indicate that the transmit queue has been stopped. Previously this was used to avoid setting the STARTED flag unless the queue had already been stopped. It meant transmit queuing would be enabled on resume if it was stopped by the transmit path--and if so, it ensured it only got enabled once. We only stop the transmit queue in the transmit path. The STARTED flag has been removed, and it causes no real harm to enable transmits when they're already enabled. So we can get rid of the STOPPED flag and call netif_wake_queue() unconditionally. This makes the IPA power spinlock unnecessary, so it can be removed as well. Signed-off-by:
-
Alex Elder authored
A transmit on the modem netdev can only complete if the IPA hardware is powered. Currently, if a transmit request arrives when the hardware was not powered, further transmits are be stopped to allow power-up to complete. Once power-up completes, transmits are once again enabled. Runtime resume can complete at the same time a transmit request is being handled, and previously there was a race between stopping and restarting transmits. The STARTED flag was used to ensure the stop request in the transmit path was skipped if the start request in the runtime resume path had already occurred. Now, the queue is *always* stopped in the transmit path, *before* determining whether power is ACTIVE. If power is found to already be active (or if the socket buffer is gets dropped), transmit is re-enabled. Otherwise it will (always) be enabled after runtime resume completes. The race between transmit and runtime resume no longer exists, so there is no longer any need to maintain the STARTED flag. Signed-off-by:
-
Alex Elder authored
There are a number of flags used in the IPA driver to attempt to manage race conditions that can occur between runtime resume and netdev transmit. If we disable TX before requesting power, we can avoid these races entirely, simplifying things considerably. This patch implements the main change, disabling transmit always in the net_device->ndo_start_xmit() callback, then re-enabling it again whenever we find power is active (or when we drop the skb). The patches that follow will refactor the "old" code to the point that most of it can be eliminated. Signed-off-by:
-
