- 07 Mar, 2024 7 commits
-
-
Chen Ni authored
Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error. Signed-off-by:
Chen Ni <nichen@iscas.ac.cn> Reviewed-by:
Simon Horman <horms@kernel.org> Fixes: 19a38d8e ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support") Link: https://lore.kernel.org/r/20240305075927.261284-1-nichen@iscas.ac.cnSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Mickaël Salaün authored
Always run fixture setup in the grandchild process, and by default also run the teardown in the same process. However, this change makes it possible to run the teardown in a parent process when _metadata->teardown_parent is set to true (e.g. in fixture setup). Fix TEST_SIGNAL() by forwarding grandchild's signal to its parent. Fix seccomp tests by running the test setup in the parent of the test thread, as expected by the related test code. Fix Landlock tests by waiting for the grandchild before processing _metadata. Use of exit(3) in tests should be OK because the environment in which the vfork(2) call happen is already dedicated to the running test (with flushed stdio, setpgrp() call), see __run_test() and the call to fork(2) just before running the setup/test/teardown. Even if the test configures its own exit handlers, they will not be run by the parent because it never calls exit(3), and the test function either ends with a call to _exit(2) or a signal. Cc: Günther Noack <gnoack@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Will Drewry <wad@chromium.org> Fixes: 0710a1a7 ("selftests/harness: Merge TEST_F_FORK() into TEST_F()") Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Mickaël Salaün <mic@digikod.net> Reported-by:
Mark Brown <broonie@kernel.org> Tested-by:
-
Jakub Kicinski authored
Matthieu Baerts says: ==================== mptcp: some clean-up patches Here are some clean-up patches for MPTCP: - Patch 1 drops duplicated header inclusions. - Patch 2 updates PM 'set_flags' interface, to make it more similar to others. - Patch 3 adds some error messages for the PM 'set_flags' command to help the userspace understanding what's wrong in case of error. - Patch 4 simplifies __lookup_addr() function from pm_netlink.c. Except for the 3rd patch, the behaviour is not supposed to be modified. ==================== Link: https://lore.kernel.org/r/20240305-upstream-net-next-20240304-mptcp-misc-cleanup-v1-0-c436ba5e569b@kernel.orgSigned-off-by:
-
Geliang Tang authored
When the lookup_by_id parameter of __lookup_addr() is true, it's the same as __lookup_addr_by_id(), it can be replaced by __lookup_addr_by_id() directly. So drop this parameter, let __lookup_addr() only looks up address on the local address list by comparing addresses in it, not address ids. Signed-off-by:
Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by:
-
Geliang Tang authored
In addition to returning the error value, this patch also sets an error messages with GENL_SET_ERR_MSG or NL_SET_ERR_MSG_ATTR both for pm_netlink.c and pm_userspace.c. It will help the userspace to identify the issue. Signed-off-by:
-
Geliang Tang authored
This patch updates set_flags interfaces, make it more similar to the interfaces of dump_addr and get_addr: mptcp_pm_set_flags(struct sk_buff *skb, struct genl_info *info) mptcp_pm_nl_set_flags(struct sk_buff *skb, struct genl_info *info) mptcp_userspace_pm_set_flags(struct sk_buff *skb, struct genl_info *info) Signed-off-by:
-
Geliang Tang authored
The headers net/tcp.h, net/genetlink.h and uapi/linux/mptcp.h are included in protocol.h already, no need to include them again directly. This patch removes these duplicate header inclusions. Signed-off-by:
-
- 06 Mar, 2024 33 commits
-
-
Juntong Deng authored
Currently getsockopt does not support IP_ROUTER_ALERT and IPV6_ROUTER_ALERT, and we are unable to get the values of these two socket options through getsockopt. This patch adds getsockopt support for IP_ROUTER_ALERT and IPV6_ROUTER_ALERT. Signed-off-by:
Juntong Deng <juntong.deng@outlook.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== tools: ynl: add --dbg-small-recv for easier kernel testing When testing netlink dumps I usually hack some user space up to constrain its user space buffer size (iproute2, ethtool or ynl). Netlink will try to fill the messages up, so since these apps use large buffers by default, the dumps are rarely fragmented. I was hoping to figure out a way to create a selftest for dump testing, but so far I have no idea how to do that in a useful and generic way. Until someone does that, make manual dump testing easier with YNL. Create a special option for limiting the buffer size, so I don't have to make the same edits each time, and maybe others will benefit, too :) Example: $ ./cli.py [...] --dbg-small-recv >/dev/null Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 3968 bytes, 31 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 532 bytes, 5 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 Now let's make the DONE not fit in the last message: $ ./cli.py [...] --dbg-small-recv 4499 >/dev/null Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 4480 bytes, 35 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 20 bytes, 1 messages nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 A real test would also have to check the messages are complete and not duplicated. That part has to be done manually right now. Note that the first message is always conservatively sized by the kernel. Still, I think this is good enough to be useful. v2: - patch 2: - move the recv_size setting up - change the default to 0 so that cli.py doesn't have to worry what the "unset" value is v1: https://lore.kernel.org/all/20240301230542.116823-1-kuba@kernel.org/ ==================== Signed-off-by: -
Jakub Kicinski authored
Most "production" netlink clients use large buffers to make dump efficient, which means that handling of dump continuation in the kernel is not very well tested. Add an option for debugging / testing handling of dumps. It enables printing of extra netlink-level debug and lowers the recv() buffer size in one go. When used without any argument (--dbg-small-recv) it picks a very small default (4000), explicit size can be set, too (--dbg-small-recv 5000). Example: $ ./cli.py [...] --dbg-small-recv Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 3968 bytes, 31 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 532 bytes, 5 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 (the [...] are edits to shorten the commit message). Note that the first message of the dump is sized conservatively by the kernel. Signed-off-by:
Donald Hunter <donald.hunter@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
For manual debug, allow printing the netlink level messages to stderr. Reviewed-by:
-
Jakub Kicinski authored
Make the size of the buffer we use for recv() configurable. The details of the buffer sizing in netlink are somewhat arcane, we could spend a lot of time polishing this API. Let's just leave some hopefully helpful comments for now. This is a for-developers-only feature, anyway. Signed-off-by:
-
Jakub Kicinski authored
We add the new line even if message has no error or extack, which leads to print(nl_msg) ending with two new lines. Reviewed-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== tools: ynl: clean up make clean First change renames the clean target which removes build results, to a more common name. Second one add missing .PHONY targets. Third one ensures that clean deletes __pycache__. v2: add patch 2 v1: https://lore.kernel.org/all/20240301235609.147572-1-kuba@kernel.org/ ==================== Signed-off-by:
-
Jakub Kicinski authored
Build process uses python to generate the user space code. Remove __pycache__ on make clean. Signed-off-by:
-
Jakub Kicinski authored
Donald points out most YNL makefiles are missing distclean in .PHONY, even tho generated/Makefile does list it. Suggested-by:
-
Jakub Kicinski authored
The make target to remove all generated files used to be called "hardclean" because it deleted files which were tracked by git. We no longer track generated user space files, so use the more common "distclean" name. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-03-04 (ice) This series contains updates to ice driver only. Jake changes the driver to use relative VSI index for VF VSIs as the VF driver has no direct use of the VSI number on ice hardware. He also reworks some Tx/Rx functions to clarify their uses, cleans up some style issues, and utilizes kernel helper functions. Maciej removes a redundant call to disable Tx queues on ifdown and removes some unnecessary devm usages. ==================== Signed-off-by: -
David S. Miller authored
Niklas Söderlund says: ==================== ravb: Align Rx descriptor setup and maintenance When RZ/G2L support was added the Rx code path was split in two, one to support R-Car and one to support RZ/G2L. One reason for this is that R-Car uses the extended Rx descriptor format, while RZ/G2L uses the normal descriptor format. In many aspects this is not needed as the extended descriptor format is just a normal descriptor with extra metadata (timestamsp) appended. And the R-Car SoCs can also use normal descriptors if hardware timestamps were not desired. This split has led to RZ/G2L gaining support for split descriptors in the Rx path while R-Car still lacks this. This series is the first step in trying to merge the R-Car and RZ/G2L Rx paths so features and bugs corrected in one will benefit the other. The first patch in the series clarifies that the driver now supports either normal or extended descriptors, not both at the same time by grouping them in a union. This is the foundation that later patches will build on the aligning the two Rx paths. Patches 2-5 deals with correcting small issues in the Rx frame and descriptor sizes that either were incorrect at the time they were added in 2017 (my bad) or concepts built on-top of this initial incorrect design. While finally patch 6 merges the R-Car and RZ/G2L for Rx descriptor setup and maintenance. When this work has landed I plan to follow up with more work aligning the rest of the Rx code paths and hopefully bring split descriptor support to the R-Car SoCs. ==================== Signed-off-by: -
Niklas Söderlund authored
The R-Car and RZ/G2L Rx code paths were split in two separate implementations when support for RZ/G2L was added due to the fact that R-Car uses the extended descriptor format while RZ/G2L uses normal descriptors. This has led to a duplication of Rx logic with the only difference being the different Rx descriptors types used. The implementation however neglects to take into account that extended descriptors are normal descriptors with additional metadata at the end to carry hardware timestamp information. The hardware timestamp information is only consumed in the R-Car Rx loop and all the maintenance code around the Rx ring can be shared between the two implementations if the difference in descriptor length is carefully considered. This change merges the two implementations for Rx ring maintenance by adding a method to access both types of descriptors as normal descriptors, as this part covers all the fields needed for Rx ring maintenance the only difference between using normal or extended descriptor is the size of the memory region to allocate/free and the step size between each descriptor in the ring. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by:
-
Niklas Söderlund authored
To make it possible to merge the R-Car and RZ/G2L code paths move the maximum usable size of a single Rx descriptor data slice into the hardware information instead of using two different defines in the two different code paths. Signed-off-by:
-
Niklas Söderlund authored
Remove the define describing the RZ/G2L maximum frame size and only use the information in the hardware information struct. This will make it easier to merge the R-Car and RZ/G2L code paths. There is no functional change as both the define and the maximum frame length in the hardware information is set to 8K. Signed-off-by:
-
Niklas Söderlund authored
The EtherAVB device requires the SKB data to be aligned to 128 bytes. The alignment is done by allocating an skb 128 bytes larger than the maximum frame size supported by the device and adjusting the headroom to fit the requirement. This code has been refactored a few times and small issues have been added along the way. The issues are not harmful but prevent merging parts of the Rx code which have been split in two implementations with the addition of RZ/G2L support, a device that supports larger frame sizes. This change removes the need for duplicated and somewhat inaccurate hardware alignment constrains stored in the hardware information struct by creating a helper to handle the allocation of an skb and alignment of an skb data. For the R-Car class of devices the maximum frame size is 4K and each descriptor is limited to 2K of data. The current implementation does not support split descriptors, this limits the frame size to 2K. The current hardware information however records the descriptor size just under 2K due to bad understanding of the device when larger MTUs where added. For the RZ/G2L device the maximum frame size is 8K and each descriptor is limited to 4K of data. The current hardware information records this correctly, but it gets the alignment constrains wrong as just aligns it by 128, it does not extend it by 128 bytes to allow the full frame to be stored. This works because the RZ/G2L device supports split descriptors and allocates each skb to 8K and aligns each 4K descriptor in this space. Signed-off-by:
-
Niklas Söderlund authored
The struct member rx_max_buf_size was added before split descriptor support was added. It is unclear if the value describes the full skb frame buffer or the data descriptor buffer which can be combined into a single skb. Rename it to make it clear it referees to the maximum frame size and can cover multiple descriptors. Signed-off-by:
-
Niklas Söderlund authored
The Rx ring can either be made up of normal or extended descriptors, not a mix of the two at the same time. Make this explicit by grouping the two variables in a rx_ring union. The extension of the storage for more than one queue of normal descriptors from a single to NUM_RX_QUEUE queues have no practical effect. But aids in making the code readable as the code that uses it already piggyback on other members of struct ravb_private that are arrays of max length NUM_RX_QUEUE, e.g. rx_desc_dma. This will also make further refactoring easier. While at it, rename the normal descriptor Rx ring to make it clear it's not strictly related to the GbEthernet E-MAC IP found in RZ/G2L, normal descriptors could be used on R-Car SoCs too. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
From: Tony Nguyen <anthony.l.nguyen@intel.com> To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Tony Nguyen <anthony.l.nguyen@intel.com>, alan.brady@intel.com Tony Nguyen says: ==================== idpf: refactor virtchnl messages Alan Brady says: The motivation for this series has two primary goals. We want to enable support of multiple simultaneous messages and make the channel more robust. The way it works right now, the driver can only send and receive a single message at a time and if something goes really wrong, it can lead to data corruption and strange bugs. To start the series, we introduce an idpf_virtchnl.h file. This reduces the burden on idpf.h which is overloaded with struct and function declarations. The conversion works by conceptualizing a send and receive as a "virtchnl transaction" (idpf_vc_xn) and introducing a "transaction manager" (idpf_vc_xn_manager). The vcxn_mngr will init a ring of transactions from which the driver will pop from a bitmap of free transactions to track in-flight messages. Instead of needing to handle a complicated send/recv for every a message, the driver now just needs to fill out a xn_params struct and hand it over to idpf_vc_xn_exec which will take care of all the messy bits. Once a message is sent and receives a reply, we leverage the completion API to signal the received buffer is ready to be used (assuming success, or an error code otherwise). At a low-level, this implements the "sw cookie" field of the virtchnl message descriptor to enable this. We have 16 bits we can put whatever we want and the recipient is required to apply the same cookie to the reply for that message. We use the first 8 bits as an index into the array of transactions to enable fast lookups and we use the second 8 bits as a salt to make sure each cookie is unique for that message. As transactions are received in arbitrary order, it's possible to reuse a transaction index and the salt guards against index conflicts to make certain the lookup is correct. As a primitive example, say index 1 is used with salt 1. The message times out without receiving a reply so index 1 is renewed to be ready for a new transaction, we report the timeout, and send the message again. Since index 1 is free to be used again now, index 1 is again sent but now salt is 2. This time we do get a reply, however it could be that the reply is _actually_ for the previous send index 1 with salt 1. Without the salt we would have no way of knowing for sure if it's the correct reply, but with we will know for certain. Through this conversion we also get several other benefits. We can now more appropriately handle asynchronously sent messages by providing space for a callback to be defined. This notably allows us to handle MAC filter failures better; previously we could potentially have stale, failed filters in our list, which shouldn't really have a major impact but is obviously not correct. I also managed to remove fairly significant more lines than I added which is a win in my book. Additionally, this converts some variables to use auto-variables where appropriate. This makes the alloc paths much cleaner and less prone to memory leaks. We also fix a few virtchnl related bugs while we're here. ==================== Signed-off-by: -
David S. Miller authored
Jakub Kicinski says: ==================== netlink: handle EMSGSIZE errors in the core Ido discovered some time back that we usually force NLMSG_DONE to be delivered in a separate recv() syscall, even if it would fit into the same skb as data messages. He made nexthop try to fit DONE with data in commit 8743aeff ("nexthop: Fix infinite nexthop bucket dump when using maximum nexthop ID"), and nobody has complained so far. We have since also tried to follow the same pattern in new genetlink families, but explaining to people, or even remembering the correct handling ourselves is tedious. Let the netlink socket layer consume -EMSGSIZE errors. Practically speaking most families use this error code as "dump needs more space", anyway. v2: - init err to 0 in last patch v1: https://lore.kernel.org/all/20240301012845.2951053-1-kuba@kernel.org/ ==================== Signed-off-by:
-
Jakub Kicinski authored
Make sure ctrl_fill_info() returns sensible error codes and propagate them out to netlink core. Let netlink core decide when to return skb->len and when to treat the exit as an error. Netlink core does better job at it, if we always return skb->len the core doesn't know when we're done dumping and NLMSG_DONE ends up in a separate read(). Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Jakub Kicinski authored
Previous change added -EMSGSIZE handling to af_netlink, we don't have to hide these errors any longer. Theoretically the error handling changes from: if (err == -EMSGSIZE) to if (err == -EMSGSIZE && skb->len) everywhere, but in practice it doesn't matter. All messages fit into NLMSG_GOODSIZE, so overflow of an empty skb cannot happen. Reviewed-by:
-
Jakub Kicinski authored
Eric points out that our current suggested way of handling EMSGSIZE errors ((err == -EMSGSIZE) ? skb->len : err) will break if we didn't fit even a single object into the buffer provided by the user. This should not happen for well behaved applications, but we can fix that, and free netlink families from dealing with that completely by moving error handling into the core. Let's assume from now on that all EMSGSIZE errors in dumps are because we run out of skb space. Families can now propagate the error nla_put_*() etc generated and not worry about any return value magic. If some family really wants to send EMSGSIZE to user space, assuming it generates the same error on the next dump iteration the skb->len should be 0, and user space should still see the EMSGSIZE. This should simplify families and prevent mistakes in return values which lead to DONE being forced into a separate recv() call as discovered by Ido some time ago. Reviewed-by:
-
Jakub Kicinski authored
selftest harness uses various exit codes to signal test results. Avoid calling exit() directly, otherwise tests may get broken by harness refactoring (like the commit under Fixes). SKIP() will instruct the harness that the test shouldn't run, it used to not be the case, but that has been fixed. So just return, no need to exit. Note that for hmm-tests this actually changes the result from pass to skip. Which seems fair, the test is skipped, after all. Reported-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20240304233621.646054-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Oleksij Rempel says: ==================== net: ethernet: Rework EEE with Andrew's permission I'll continue mainlining this patches: ============================================================== Most MAC drivers get EEE wrong. The API to the PHY is not very obvious, which is probably why. Rework the API, pushing most of the EEE handling into phylib core, leaving the MAC drivers to just enable/disable support for EEE in there change_link call back. MAC drivers are now expect to indicate to phylib if they support EEE. This will allow future patches to configure the PHY to advertise no EEE link modes when EEE is not supported. The information could also be used to enable SmartEEE if the PHY supports it. With these changes, the uAPI configuration eee_enable becomes a global on/off. tx-lpi must also be enabled before EEE is enabled. This fits the discussion here: https://lore.kernel.org/netdev/af880ce8-a7b8-138e-1ab9-8c89e662eecf@gmail.com/T/ This patchset puts in place all the infrastructure, and converts one MAC driver to the new API. Following patchsets will convert other MAC drivers, extend support into phylink, and when all MAC drivers are converted to the new scheme, clean up some unneeded code. ==================== Link: https://lore.kernel.org/r/20240302195306.3207716-1-o.rempel@pengutronix.deSigned-off-by:
-
Andrew Lunn authored
The enabling/disabling of EEE in the MAC should happen as a result of auto negotiation. So move the enable/disable into fec_enet_adjust_link() which gets called by phylib when there is a change in link status. fec_enet_set_eee() now just stores away the LPI timer value. Everything else is passed to phylib, so it can correctly setup the PHY. fec_enet_get_eee() relies on phylib doing most of the work, the MAC driver just adds the LPI timer value. Call phy_support_eee() if the quirk is present to indicate the MAC actually supports EEE. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> (On iMX8MP debix) Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Wei Fang <wei.fang@nxp.com> Link: https://lore.kernel.org/r/20240302195306.3207716-8-o.rempel@pengutronix.deSigned-off-by:
-
Andrew Lunn authored
FEC is about to get its EEE code re-written. To allow this, move fec_enet_eee_mode_set() before fec_enet_adjust_link() which will need to call it. Signed-off-by:
-
Andrew Lunn authored
In order for EEE to operate, both the MAC and the PHY need to support it, similar to how pause works. With some exception - a number of PHYs have SmartEEE or AutoGrEEEn support in order to provide some EEE-like power savings with non-EEE capable MACs. Copy the pause concept and add the call phy_support_eee() which the MAC makes after connecting the PHY to indicate it supports EEE. phylib will then advertise EEE when auto-neg is performed. Signed-off-by:
-
Andrew Lunn authored
The MAC driver changes its EEE hardware configuration in its adjust_link callback. This is called when auto-neg completes. Disabling EEE via eee_enabled false will trigger an autoneg, and as a result the adjust_link callback will be called with phydev->enable_tx_lpi set to false. Similarly, eee_enabled set to true and with a change of advertised link modes will result in a new autoneg, and a call the adjust_link call. If set_eee is called with only a change to tx_lpi_enabled which does not trigger an auto-neg, it is necessary to call the adjust_link callback so that the MAC is reconfigured to take this change into account. When setting phydev->enable_tx_lpi, take both eee_enabled and tx_lpi_enabled into account, so the MAC drivers just needs to act on phydev->enable_tx_lpi and not the whole EEE configuration. The same check should be done for tx_lpi_timer too. Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
Andrew Lunn authored
Have phylib keep track of the EEE configuration. This simplifies the MAC drivers, in that they don't need to store it. Future patches to phylib will also make use of this information to further simplify the MAC drivers. Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Andrew Lunn authored
MAC drivers which support EEE need to know the results of the EEE auto-neg in order to program the hardware to perform EEE or not. The oddly named phy_init_eee() can be used to determine this, it returns 0 if EEE should be used, or a negative error code, e.g. -EOPPROTONOTSUPPORT if the PHY does not support EEE or negotiate resulted in it not being used. However, many MAC drivers get this wrong. Add phydev->enable_tx_lpi which indicates the result of the autoneg for EEE, including if EEE is administratively disabled with ethtool. The MAC driver can then access this in the same way as link speed and duplex in the adjust link callback. If enable_tx_lpi is true, the MAC should send low power indications and does not need to consider anything else with respect to EEE. Reviewed-by:
-
Russell King authored
Add helpers that phylib and phylink can use to manage EEE configuration and determine whether the MAC should be permitted to use LPI based on that configuration. Signed-off-by:
-
Heiner Kallweit authored
This function is used with the set_eee() ethtool operation. Certain fields of struct ethtool_keee() are relevant only for the get_eee() operation. In addition, in case of the ioctl interface, we have no guarantee that userspace sends sane values in struct ethtool_eee. Therefore explicitly ignore all fields not needed for set_eee(). This protects from drivers trying to use unchecked and unreliable data, relying on specific userspace behavior. Note: Such unsafe driver behavior has been found and fixed in the tg3 driver. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
