- 05 Feb, 2024 6 commits
-
-
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 <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
- 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: David S. Miller <davem@davemloft.net>
-
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: 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: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
- 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: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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 <kuba@kernel.org>
-
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: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240202004926.447803-4-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240202004926.447803-3-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240202004926.447803-2-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20240201173031.3654257-1-edumazet@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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 <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/27c336a8-ea47-483d-815b-02c45ae41da2@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Joe Salmeri <jmscdba@gmail.com> Link: https://lore.kernel.org/r/0c8e67ea-6505-43d1-bd51-94e7ecd6e222@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 02 Feb, 2024 18 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: Jiri Pirko <jiri@nvidia.com> ==================== Link: https://lore.kernel.org/r/20240201130943.19536-1-mkoutny@suse.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240201130943.19536-5-mkoutny@suse.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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ý <mkoutny@suse.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240201130943.19536-4-mkoutny@suse.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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ý <mkoutny@suse.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240201130943.19536-3-mkoutny@suse.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Michal Koutný <mkoutny@suse.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240201130943.19536-2-mkoutny@suse.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: David S. Miller <davem@davemloft.net>
-
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: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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: Geetha sowjanya <gakula@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Aaron Conole <aconole@redhat.com> Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: David S. Miller <davem@davemloft.net>
-
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 <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
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: Jakub Kicinski <kuba@kernel.org>
-