- 11 May, 2020 33 commits
-
-
Christoph Hellwig authored
The msg_control field in struct msghdr can either contain a user pointer when used with the recvmsg system call, or a kernel pointer when used with sendmsg. To complicate things further kernel_recvmsg can stuff a kernel pointer in and then use set_fs to make the uaccess helpers accept it. Replace it with a union of a kernel pointer msg_control field, and a user pointer msg_control_user one, and allow kernel_recvmsg operate on a proper kernel pointer using a bitfield to override the normal choice of a user pointer for recvmsg. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Christoph Hellwig authored
Factor out two helpes to keep the code tidy. Signed-off-by:
-
Christoph Hellwig authored
Add a variant of CMSG_DATA that operates on user pointer to avoid sparse warnings about casting to/from user pointers. Also fix up CMSG_DATA to rely on the gcc extension that allows void pointer arithmetics to cut down on the amount of casts. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: Constify two tagger ops This patch series constifies the dsa_device_ops for ocelot and sja1105 ==================== Signed-off-by: -
Florian Fainelli authored
sja1105_netdev_ops should be const since that is what the DSA layer expects. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
ocelot_netdev_ops should be const since that is what the DSA layer expects. Signed-off-by:
-
David S. Miller authored
Edward Cree says: ==================== sfc: remove nic_data usage in common code efx->nic_data should only be used from NIC-specific code (i.e. nic_type functions and things they call), in files like ef10[_sriov].c and siena.c. This series refactors several nic_data usages from common code (mainly in mcdi_filters.c) into nic_type functions, in preparation for the upcoming ef100 driver which will use those functions but have its own struct layout for efx->nic_data distinct from ef10's. After this series, one nic_data usage (in ptp.c) remains; it wasn't clear to me how to fix it, and ef100 devices don't yet have PTP support (so the initial ef100 driver will not call that code). ==================== Signed-off-by: -
Edward Cree authored
Instead of having efx_mcdi_print_fwver() look at efx_nic_rev and conditionally poke around inside ef10-specific nic_data, add a new efx->type->print_additional_fwver() method to do this work. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Edward Cree authored
By making the caller of efx_mcdi_filter_table_probe() loop over the vlan_list calling efx_mcdi_filter_add_vlan(), instead of doing it in efx_mcdi_filter_table_probe(), the latter avoids looking in ef10- specific nic_data. Signed-off-by:
-
Edward Cree authored
It's both set and used solely by mcdi_filters.c, so there's no reason for it to be in ef10-specific nic_data. Signed-off-by:
-
Edward Cree authored
Store the mc_chaining bit in struct efx_mcdi_filter_table, so that common code in mcdi_filters.c doesn't need to get it from ef10-specific nic_data. Also, probe the firmware workaround just before the call to efx_mcdi_filter_table_probe(), rather than in a random other part of the driver bringup, to ensure that (a) it gets probed in time and (b) it gets reprobed as necessary on resets, no matter how the surrounding code gets reorganised and reordered. Signed-off-by:
-
Edward Cree authored
Common code in mcdi_filters.c uses these flags, so by moving them to either struct efx_nic (in the case of must_realloc_vis) or struct efx_mcdi_filter_table (for must_restore_rss_contexts and must_restore_filters), decouple this code from ef10's nic_data. Signed-off-by:
-
Edward Cree authored
Removes some efx_ef10_nic_data references from common code. Signed-off-by:
-
Tom Zhao authored
Various MCDI functions (especially in filter handling) need to check the datapath caps, but those live in nic_data (since they don't exist on Siena). Decouple from ef10-specific data structures by adding check_caps to the nic_type, to allow using these functions from non-ef10 drivers. Also add a convenience macro efx_has_cap() to reduce the amount of boilerplate involved in calling it. Signed-off-by:
-
Edward Cree authored
Remove some usage of ef10-specific nic_data structs from common MCDI functions, in preparation for using them from a non-EF10 driver. Signed-off-by:
-
David S. Miller authored
Bhupesh Sharma says: ==================== net: Optimize the qed* allocations inside kdump kernel Changes since v1: ---------------- - v1 can be seen here: http://lists.infradead.org/pipermail/kexec/2020-May/024935.html - Addressed review comments received on v1: * Removed unnecessary paranthesis. * Used a different macro for minimum RX/TX ring count value in kdump kernel. Since kdump kernel(s) run under severe memory constraint with the basic idea being to save the crashdump vmcore reliably when the primary kernel panics/hangs, large memory allocations done by a network driver can cause the crashkernel to panic with OOM. The qed* drivers take up approximately 214MB memory when run in the kdump kernel with the default configuration settings presently used in the driver. With an usual crashkernel size of 512M, this allocation is equal to almost half of the total crashkernel size allocated. See some logs obtained via memstrack tool (see [1]) below: dracut-pre-pivot[676]: ======== Report format module_summary: ======== dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages) dracut-pre-pivot[676]: Module qede using 65.3MB (1045 pages), peak allocation 65.3MB (1045 pages) This patchset tries to reduce the overall memory allocation profile of the qed* driver when they run in the kdump kernel. With these optimization we can see a saving of approx 85M in the kdump kernel: dracut-pre-pivot[671]: ======== Report format module_summary: ======== dracut-pre-pivot[671]: Module qed using 124.6MB (1993 pages), peak allocation 124.7MB (1995 pages) <..snip..> dracut-pre-pivot[671]: Module qede using 4.6MB (73 pages), peak allocation 4.6MB (74 pages) And the kdump kernel can save vmcore successfully via both ssh and nfs interfaces. This patchset contains two patches: [PATCH 1/2] - Reduces the default TX and RX ring count in kdump kernel. [PATCH 2/2] - Disables qed SRIOV feature in kdump kernel (as it is normally not a supported kdump target for saving vmcore). [1]. Memstrack tool: https://github.com/ryncsn/memstrack ==================== Signed-off-by:
-
Bhupesh Sharma authored
Since we have kdump kernel(s) running under severe memory constraint it makes sense to disable the qed SRIOV functionality when running the kdump kernel as kdump configurations on several distributions don't support SRIOV targets for saving the vmcore (see [1] for example). Currently the qed SRIOV functionality ends up consuming memory in the kdump kernel, when we don't really use the same. An example log seen in the kdump kernel with the SRIOV functionality enabled can be seen below (obtained via memstrack tool, see [2]): dracut-pre-pivot[676]: ======== Report format module_summary: ======== dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages) This patch disables the SRIOV functionality inside kdump kernel and with the same applied the memory consumption goes down: dracut-pre-pivot[671]: ======== Report format module_summary: ======== dracut-pre-pivot[671]: Module qed using 124.6MB (1993 pages), peak allocation 124.7MB (1995 pages) [1]. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/installing-and-configuring-kdump_managing-monitoring-and-updating-the-kernel#supported-kdump-targets_supported-kdump-configurations-and-targets [2]. Memstrack tool: https://github.com/ryncsn/memstrack Cc: kexec@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Ariel Elior <aelior@marvell.com> Cc: GR-everest-linux-l2@marvell.com Cc: Manish Chopra <manishc@marvell.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by:
-
Bhupesh Sharma authored
Normally kdump kernel(s) run under severe memory constraint with the basic idea being to save the crashdump vmcore reliably when the primary kernel panics/hangs. Currently the qed* ethernet driver ends up consuming a lot of memory in the kdump kernel, leading to kdump kernel panic when one tries to save the vmcore via ssh/nfs (thus utilizing the services of the underlying qed* network interfaces). An example OOM message log seen in the kdump kernel can be seen here [1], with crashkernel size reservation of 512M. Using tools like memstrack (see [2]), we can track the modules taking up the bulk of memory in the kdump kernel and organize the memory usage output as per 'highest allocator first'. An example log for the OOM case indicates that the qed* modules end up allocating approximately 216M memory, which is a large part of the total crashkernel size: dracut-pre-pivot[676]: ======== Report format module_summary: ======== dracut-pre-pivot[676]: Module qed using 149.6MB (2394 pages), peak allocation 149.6MB (2394 pages) dracut-pre-pivot[676]: Module qede using 65.3MB (1045 pages), peak allocation 65.3MB (1045 pages) This patch reduces the default RX and TX ring count from 1024 to 64 when running inside kdump kernel, which leads to a significant memory saving. An example log with the patch applied shows the reduced memory allocation in the kdump kernel: dracut-pre-pivot[674]: ======== Report format module_summary: ======== dracut-pre-pivot[674]: Module qed using 141.8MB (2268 pages), peak allocation 141.8MB (2268 pages) <..snip..> [dracut-pre-pivot[674]: Module qede using 4.8MB (76 pages), peak allocation 4.9MB (78 pages) Tested crashdump vmcore save via ssh/nfs protocol using underlying qed* network interface after applying this patch. [1] OOM log: ------------ kworker/0:6: page allocation failure: order:6, mode:0x60c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null) kworker/0:6 cpuset=/ mems_allowed=0 CPU: 0 PID: 145 Comm: kworker/0:6 Not tainted 4.18.0-109.el8.aarch64 #1 Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL025 01/18/2019 Workqueue: events work_for_cpu_fn Call trace: dump_backtrace+0x0/0x188 show_stack+0x24/0x30 dump_stack+0x90/0xb4 warn_alloc+0xf4/0x178 __alloc_pages_nodemask+0xcac/0xd58 alloc_pages_current+0x8c/0xf8 kmalloc_order_trace+0x38/0x108 qed_iov_alloc+0x40/0x248 [qed] qed_resc_alloc+0x224/0x518 [qed] qed_slowpath_start+0x254/0x928 [qed] __qede_probe+0xf8/0x5e0 [qede] qede_probe+0x68/0xd8 [qede] local_pci_probe+0x44/0xa8 work_for_cpu_fn+0x20/0x30 process_one_work+0x1ac/0x3e8 worker_thread+0x44/0x448 kthread+0x130/0x138 ret_from_fork+0x10/0x18 Cannot start slowpath qede: probe of 0000:05:00.1 failed with error -12 [2]. Memstrack tool: https://github.com/ryncsn/memstrack Cc: kexec@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Ariel Elior <aelior@marvell.com> Cc: GR-everest-linux-l2@marvell.com Cc: Manish Chopra <manishc@marvell.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Luo bin authored
add set_link_ksettings implementation and improve the implementation of get_link_ksettings Signed-off-by:
Luo bin <luobin9@huawei.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Jakub Kicinski authored
Vladimir Oltean says: ==================== This series adds support for boards where DSA switches of multiple types are cascaded together. Actually this type of setup was brought up before on netdev, and it looks like utilizing disjoint trees is the way to go: https://lkml.org/lkml/2019/7/7/225 The trouble with disjoint trees (prior to this patch series) is that only bridging of ports within the same hardware switch can be offloaded. After scratching my head for a while, it looks like the easiest way to support hardware bridging between different DSA trees is to bridge their DSA masters and extend the crosschip bridging operations. I have given some thought to bridging the DSA masters with the slaves themselves, but given the hardware topology described in the commit message of patch 4/4, virtually any number (and combination) of bridges (forwarding domains) can be created on top of those 3x4-port front-panel switches. So it becomes a lot less obvious, when the front-panel ports are enslaved to more than 1 bridge, which bridge should the DSA masters be enslaved to. So the least awkward approach was to just create a completely separate bridge for the DSA masters, whose entire purpose is to permit hardware forwarding between the discrete switches beneath it. This is a direct resend of v3, which was deferred due to lack of review. In the meantime Florian has reviewed and tested some of them. v1 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200429161952.17769-1-olteanv@gmail.com/ v2 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200430202542.11797-1-olteanv@gmail.com/ v3 was submitted here: https://patchwork.ozlabs.org/project/netdev/cover/20200503221228.10928-1-olteanv@gmail.com/ ==================== Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
sja1105 uses dsa_8021q for DSA tagging, a format which is VLAN at heart and which is compatible with cascading. A complete description of this tagging format is in net/dsa/tag_8021q.c, but a quick summary is that each external-facing port tags incoming frames with a unique pvid, and this special VLAN is transmitted as tagged towards the inside of the system, and as untagged towards the exterior. The tag encodes the switch id and the source port index. This means that cross-chip bridging for dsa_8021q only entails adding the dsa_8021q pvids of one switch to the RX filter of the other switches. Everything else falls naturally into place, as long as the bottom-end of ports (the leaves in the tree) is comprised exclusively of dsa_8021q-compatible (i.e. sja1105 switches). Otherwise, there would be a chance that a front-panel switch transmits a packet tagged with a dsa_8021q header, header which it wouldn't be able to remove, and which would hence "leak" out. The only use case I tested (due to lack of board availability) was when the sja1105 switches are part of disjoint trees (however, this doesn't change the fact that multiple sja1105 switches still need unique switch identifiers in such a system). But in principle, even "true" single-tree setups (with DSA links) should work just as fine, except for a small change which I can't test: dsa_towards_port should be used instead of dsa_upstream_port (I made the assumption that the routing port that any sja1105 should use towards its neighbours is the CPU port. That might not hold true in other setups). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
-
Vladimir Oltean authored
Somewhat similar to dsa_tree_find, dsa_switch_find returns a dsa_switch structure pointer by searching for its tree index and switch index (the parameters from dsa,member). To be used, for example, by drivers who implement .crosschip_bridge_join and need a reference to the other switch indicated to by the tree_index and sw_index arguments. Signed-off-by:
-
Vladimir Oltean authored
One way of utilizing DSA is by cascading switches which do not all have compatible taggers. Consider the following real-life topology: +---------------------------------------------------------------+ | LS1028A | | +------------------------------+ | | | DSA master for Felix | | | |(internal ENETC port 2: eno2))| | | +------------+------------------------------+-------------+ | | | Felix embedded L2 switch | | | | | | | | +--------------+ +--------------+ +--------------+ | | | | |DSA master for| |DSA master for| |DSA master for| | | | | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | | | | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | | +--+-+--------------+---+--------------+---+--------------+--+--+ +-----------------------+ +-----------------------+ +-----------------------+ | SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 | +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+ |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3| +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+ The above can be described in the device tree as follows (obviously not complete): mscc_felix { dsa,member = <0 0>; ports { port@4 { ethernet = <&enetc_port2>; }; }; }; sja1105_switch1 { dsa,member = <1 1>; ports { port@4 { ethernet = <&mscc_felix_port1>; }; }; }; sja1105_switch2 { dsa,member = <2 2>; ports { port@4 { ethernet = <&mscc_felix_port2>; }; }; }; sja1105_switch3 { dsa,member = <3 3>; ports { port@4 { ethernet = <&mscc_felix_port3>; }; }; }; Basically we instantiate one DSA switch tree for every hardware switch in the system, but we still give them globally unique switch IDs (will come back to that later). Having 3 disjoint switch trees makes the tagger drivers "just work", because net devices are registered for the 3 Felix DSA master ports, and they are also DSA slave ports to the ENETC port. So packets received on the ENETC port are stripped of their stacked DSA tags one by one. Currently, hardware bridging between ports on the same sja1105 chip is possible, but switching between sja1105 ports on different chips is handled by the software bridge. This is fine, but we can do better. In fact, the dsa_8021q tag used by sja1105 is compatible with cascading. In other words, a sja1105 switch can correctly parse and route a packet containing a dsa_8021q tag. So if we could enable hardware bridging on the Felix DSA master ports, cross-chip bridging could be completely offloaded. Such as system would be used as follows: ip link add dev br0 type bridge && ip link set dev br0 up for port in sw0p0 sw0p1 sw0p2 sw0p3 \ sw1p0 sw1p1 sw1p2 sw1p3 \ sw2p0 sw2p1 sw2p2 sw2p3; do ip link set dev $port master br0 done The above makes switching between ports on the same row be performed in hardware, and between ports on different rows in software. Now assume the Felix switch ports are called swp0, swp1, swp2. By running the following extra commands: ip link add dev br1 type bridge && ip link set dev br1 up for port in swp0 swp1 swp2; do ip link set dev $port master br1 done the CPU no longer sees packets which traverse sja1105 switch boundaries and can be forwarded directly by Felix. The br1 bridge would not be used for any sort of traffic termination. For this to work, we need to give drivers an opportunity to listen for bridging events on DSA trees other than their own, and pass that other tree index as argument. I have made the assumption, for the moment, that the other existing DSA notifiers don't need to be broadcast to other trees. That assumption might turn out to be incorrect. But in the meantime, introduce a dsa_broadcast function, similar in purpose to dsa_port_notify, which is used only by the bridging notifiers. Signed-off-by: -
Vladimir Oltean authored
Commit 8db0a2ee ("net: bridge: reject DSA-enabled master netdevices as bridge members") added a special check in br_if.c in order to check for a DSA master network device with a tagging protocol configured. This was done because back then, such devices, once enslaved in a bridge would become inoperative and would not pass DSA tagged traffic anymore due to br_handle_frame returning RX_HANDLER_CONSUMED. But right now we have valid use cases which do require bridging of DSA masters. One such example is when the DSA master ports are DSA switch ports themselves (in a disjoint tree setup). This should be completely equivalent, functionally speaking, from having multiple DSA switches hanging off of the ports of a switchdev driver. So we should allow the enslaving of DSA tagged master network devices. Instead of the regular br_handle_frame(), install a new function br_handle_frame_dummy() on these DSA masters, which returns RX_HANDLER_PASS in order to call into the DSA specific tagging protocol handlers, and lift the restriction from br_add_if. Suggested-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Suggested-by:
-
Jakub Kicinski authored
Huazhong Tan says: ==================== net: hns3: misc updates for -next This patchset includes some misc updates for the HNS3 ethernet driver. #1 & #2 add two cleanups. #3 provides an interface for the client to query the CMDQ's status. #4 adds a little optimization about debugfs. #5 prevents 1000M auto-negotiation off setting. ==================== Signed-off-by: -
Yufeng Mo authored
The 802.3 specification does not specify the behavior of auto-negotiation off with 1000M in PHY. Therefore, some PHY compatibility issues occur. This patch forbids the setting of this unreasonable mode by ethtool in driver. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Yufeng Mo authored
This patch optimizes the judgment of the input parameters of dump ncl config by checking the number and value of the input parameters apart. It's clearer and more reasonable. Signed-off-by:
-
Huazhong Tan authored
This patch provides a new interface for the client to query whether CMDQ is ready to work. Signed-off-by:
-
Huazhong Tan authored
According to the UM, command 0x0B03 and 0x0B13 are used to query the statistics about TX and RX, not the status, so modifies the unsuitable macro name of these two command. Signed-off-by:
-
Huazhong Tan authored
HCLGE_MISC_VECTOR_INT_STS and HCLGE_VECTOR_PF_OTHER_INT_STS_REG both represent the misc interrupt status register(0x20800), so removes HCLGE_VECTOR_PF_OTHER_INT_STS_REG and replaces it with HCLGE_MISC_VECTOR_INT_STS. Signed-off-by:
-
- 10 May, 2020 7 commits
-
-
Jakub Kicinski authored
Andrew Lunn says: ==================== Ethernet Cable test support any copper Ethernet PHY have support for performing diagnostics of the cable. Are the cable shorted, broken, not plugged into anything at the other end? And they can report roughly how far along the cable any fault is. Add infrastructure in ethtool and phylib support for triggering a cable test and reporting the results. The Marvell 1G PHY driver is then extended to make use of this infrastructure. For testing, a modified ethtool(1) can be found here: https://github.com/lunn/ethtool.git feature/cable-test-v4. This also contains extra code for TDR dump, which will be added to the kernel in a later patch series. Thanks to Chris Healy for extensive testing. v2: See individual patches but: Remove _REPLY messages Change length into a u32 Grammar fixes Rename functions for consistency Extack for cable test already running Remove ethnl_cable_test_act_ops Add status attributes Rename pairs from numbers to letters v3: See individual patches but: Remove ETHTOOL_MSG_CABLE_TEST_ACT_REPLY from documentation Remove unused cable_test_get_policy Fixed example in document Add ETHTOOL_A_CABLE_NEST_* enum Add ETHTOOL_MSG_CABLE_TEST_NTF to documentation Poison phydev->skb Return -EMSGSIZE when ethnl_bcastmsg_put() fails Return valid error code when nla_nest_start() fails Use u8 for results Actually put u32 length into message s/mavell/marvell/g Remove include of <uapi/linux/ethtool_netlink.h> EMSGSIZE when ethnl_bcastmsg_put() fails Print an error message on failure, since this is a void function. v4: See individual patches but: Remove unwanted blank line ENOTSUPP->EOPNOTSUPP Move EINVAL->EMSGSIZE fix to correct patch ==================== Signed-off-by:
-
Andrew Lunn authored
Given that it takes time to run a cable test, send a notify message at the start, as well as when it is completed. v3: EMSGSIZE when ethnl_bcastmsg_put() fails Print an error message on failure, since this is a void function. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Michal Kubecek <mkubecek@suse.cz> Reviewed-by:
-
Andrew Lunn authored
Since running a cable test is disruptive, put the interface into operative state testing while the test is running. Signed-off-by:
-
Andrew Lunn authored
The Marvell PHYs have a couple of different register sets for performing cable tests. Page 7 provides the simplest to use. v3: s/mavell/marvell/g Remove include of <uapi/linux/ethtool_netlink.h> Signed-off-by:
-
Andrew Lunn authored
The PHY drivers can use these helpers for reporting the results. The results get translated into netlink attributes which are added to the pre-allocated skbuf. v3: Poison phydev->skb Return -EMSGSIZE when ethnl_bcastmsg_put() fails Return valid error code when nla_nest_start() fails Use u8 for results Actually put u32 length into message v4: s/ENOTSUPP/EOPNOTSUPP/g Signed-off-by:
-
Andrew Lunn authored
Provide infrastructure for PHY drivers to report the cable test results. A netlink skb is associated to the phydev. Helpers will be added which can add results to this skb. Once the test has finished the results are sent to user space. When netlink ethtool is not part of the kernel configuration stubs are provided. It is also impossible to trigger a cable test, so the error code returned by the alloc function is of no consequence. v2: Include the status complete in the netlink notification message v4: Replace -EINVAL with -EMSGSIZE Signed-off-by:
-
Andrew Lunn authored
Make some helpers for building ethtool netlink messages available outside the compilation unit, so they can be used for building messages which are not simple get/set. Signed-off-by:
-
