- 30 8月, 2021 4 次提交
-
-
由 Edwin Peer 提交于
There are no longer any callers relying on the old API. Signed-off-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Edwin Peer 提交于
This change constitutes a major step towards supporting multiple firmware commands in flight by maintaining a separate response buffer for the duration of each request. These firmware commands are also known as Hardware Resource Manager (HWRM) commands. Using separate response buffers requires an API change in order for callers to be able to free the buffer when done. It is impossible to keep the existing APIs unchanged. The existing usage for a simple HWRM message request such as the following: struct input req = {0}; bnxt_hwrm_cmd_hdr_init(bp, &req, REQ_TYPE, -1, -1); rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); if (rc) /* error */ changes to: struct input *req; rc = hwrm_req_init(bp, req, REQ_TYPE); if (rc) /* error */ rc = hwrm_req_send(bp, req); /* consumes req */ if (rc) /* error */ The key changes are: 1. The req is no longer allocated on the stack. 2. The caller must call hwrm_req_init() to allocate a req buffer and check for a valid buffer. 3. The req buffer is automatically released when hwrm_req_send() returns. 4. If the caller wants to check the firmware response, the caller must call hwrm_req_hold() to take ownership of the response buffer and release it afterwards using hwrm_req_drop(). The caller is no longer required to explicitly hold the hwrm_cmd_lock mutex to read the response. 5. Because the firmware commands and responses all have different sizes, some safeguards are added to the code. This patch maintains legacy API compatibiltiy, implementing the old API in terms of the new. The follow-on patches will convert all callers to use the new APIs. v2: Fix redefined writeq with parisc .config Fix "cast from pointer to integer of different size" warning in hwrm_calc_sentinel() Signed-off-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Edwin Peer 提交于
Move all firmware messaging functions and definitions to new bnxt_hwrm.[ch]. The follow-on patches will make major modifications to these APIs. Signed-off-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Edwin Peer 提交于
The additional response buffer serves no useful purpose. There can be only one firmware command in flight due to the hwrm_cmd_lock mutex, which is taken for the entire duration of any command completion, KONG or otherwise. It is thus safe to share a single DMA buffer. Removing the code associated with the additional mapping will simplify matters in the next patch, which allocates response buffers from DMA pools on a per request basis. Signed-off-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 8月, 2021 2 次提交
-
-
由 Jakub Kicinski 提交于
Count packets dropped due to buffer or skb allocation errors. Report as part of rx_dropped. v2: drop the ethtool -S entry [Vladimir] Reviewed-by: NMichael Chan <michael.chan@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Jakub Kicinski 提交于
bnxt may discard packets if Rx completions are consumed in an attempt to let netpoll make progress. It should be extremely rare in practice but nonetheless such events should be counted. Since completion ring memory is allocated dynamically use a similar scheme to what is done for HW stats to save them. Report the stats in rx_dropped and per-netdev ethtool counter. Chances that users care which ring dropped are very low. v3: only save the stat to rx_dropped on reset, rx_total_netpoll_discards will now only show drops since last reset, similar to other "total_discard" counters. Reviewed-by: NMichael Chan <michael.chan@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 14 8月, 2021 1 次提交
-
-
由 Jakub Kicinski 提交于
skbs are freed on error and not put on the ring. We may, however, be in a situation where we're freeing the last skb of a batch, and there is a doorbell ring pending because of xmit_more() being true earlier. Make sure we ring the door bell in such situations. Since errors are rare don't pay attention to xmit_more() and just always flush the pending frames. The busy case should be safe to be left alone because it can only happen if start_xmit races with completions and they both enable the queue. In that case the kick can't be pending. Noticed while reading the code. Fixes: 4d172f21 ("bnxt_en: Implement xmit_more.") Reviewed-by: NMichael Chan <michael.chan@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 03 8月, 2021 2 次提交
-
-
由 Michael Chan 提交于
The current maximum RX ring size is defined assuming the RX jumbo ring (aka aggregation ring) is used. The RX jumbo ring is automicatically used when the MTU exceeds a threshold or when rx-gro-hw/lro is enabled. The RX jumbo ring is automatically sized up to 4 times the size of the RX ring size. The BNXT_MAX_RX_DESC_CNT constant is the upper limit on the size of the RX ring whether or not the RX jumbo ring is used. Obviously, the maximum amount of RX buffer space is significantly less when the RX jumbo ring is not used. To increase flexibility for the user who does not use the RX jumbo ring, we now define a bigger maximum RX ring size when the RX jumbo ring is not used. The maximum RX ring size is now up to 8K when the RX jumbo ring is not used. The maximum completion ring size also needs to be scaled up to accomodate the larger maximum RX ring size. Note that when the RX jumbo ring is re-enabled, the RX ring size will automatically drop if it exceeds the maximum. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
We currently store these page addresses and DMA addreses in static arrays. On systems with 4K pages, we support up to 64 pages per completion ring. The actual number of pages for each completion ring may be much less than 64. For example, when the RX ring size is set to the default 511 entries, only 16 completion ring pages are needed per ring. In the next patch, we'll be doubling the maximum number of completion pages. So we convert to allocate these arrays as needed instead of declaring them statically. Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: NSomnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 7月, 2021 2 次提交
-
-
由 Pavan Chebbi 提交于
FW can report to driver via ASYNC event if it encountered an invalid signal on any TSIO PIN. Driver will log this event for the user to take corrective action. Reviewed-by: NSomnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: NArvind Susarla <arvind.susarla@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Pavan Chebbi 提交于
1PPS (One Pulse Per Second) is a signal generated either by the NIC PHC or an external timing source. Integrating the support to configure and use 1PPS using the TSIO pins along with PTP timestamps will add Grand Master capability to the 5750X family chipsets. This patch initializes the driver data structures and registers the 1PPS with kernel, based on the TSIO pins' capability in the hardware. This will create a /dev/ppsX device which applications can use to receive PPS events. Later patches will define functions to configure and use the pins. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 6月, 2021 3 次提交
-
-
由 Pavan Chebbi 提交于
Setup the TXBD to enable TX timestamp if requested. At TX packet DMA completion, if we requested TX timestamp on that packet, we defer to .do_aux_work() to obtain the TX timestamp from the firmware before we free the TX SKB. v2: Use .do_aux_work() to get the TX timestamp from firmware. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Pavan Chebbi 提交于
If the RX packet is timestamped by the hardware, the RX completion record will contain the lower 32-bit of the timestamp. This needs to be combined with the upper 16-bit of the periodic timestamp that we get from the timer. The previous snapshot in ptp->old_timer is used to make sure that the snapshot is not ahead of the RX timestamp and we adjust for wrap-around if needed. v2: Make ptp->old_time read access safe on 32-bit CPUs. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Store PTP hardware info in a structure if hardware and firmware support PTP. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 18 5月, 2021 1 次提交
-
-
由 Michael Chan 提交于
There was a typo in the code that checks for 64K BNXT_PAGE_SHIFT in bnxt_hwrm_set_pg_attr(). Fix it and make the code more understandable with a new macro BNXT_SET_CTX_PAGE_ATTR(). Fixes: 1b9394e5 ("bnxt_en: Configure context memory on new devices.") Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 4月, 2021 4 次提交
-
-
由 Michael Chan 提交于
For UDP encapsultions, we only support the offloaded Vxlan port and Geneve port. All other ports included FOU and GUE are not supported so we need to turn off TSO and checksum features. v2: Reverse the check for supported UDP ports to be more straight forward. Reviewed-by: NSriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
If firmware is capable, set the IFF_SUPP_NOFCS flag to support the sockets option to transmit packets without FCS. This is mainly used for testing. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
In the current code, the driver will not shutdown the link during IFDOWN if there are still VFs sharing the port. Newer firmware will manage the link down decision when the port is shared by VFs, so we can just call firmware to shutdown the port unconditionally and let firmware make the final decision. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Copy the phy related feature flags from the firmware call HWRM_PORT_PHY_QCAPS to this new field. We can also remove the flags field in the bnxt_test_info structure. It's cleaner to have all PHY related flags in one location, directly copied from the firmware. To keep the BNXT_PHY_CFG_ABLE() macro logic the same, we need to make a slight adjustment to check that it is a PF. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 4月, 2021 1 次提交
-
-
由 Leon Romanovsky 提交于
Convert indirect probe call to its direct equivalent to create a symbol link between RDMA and netdev modules. This will give us an ability to remove custom module reference counting that doesn't belong to the driver. Link: https://lore.kernel.org/r/20210401065715.565226-3-leon@kernel.orgSigned-off-by: NLeon Romanovsky <leonro@nvidia.com> Acked-By: NDevesh Sharma <devesh.sharma@broadcom.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
-
- 23 3月, 2021 2 次提交
-
-
由 Michael Chan 提交于
Two enhancements: 1. Read the health status first before sending the first HWRM_VER_GET message to firmware instead of the other way around. This guarantees we got the accurate health status before we attempt to send the message. 2. We currently only retry sending the first HWRM_VER_GET message to the firmware if the firmware is in the process of booting. If the firmware is in error state and is doing core dump for example, the driver should also retry if the health register has the RECOVERING flag set. This flag indicates the firmware will undergo recovery soon. Modify the retry logic to retry for this case as well. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Pavan Chebbi 提交于
In situations where FW has crashed, the bnxt_hwrm_do_send_msg() call will have to wait until timeout for each firmware message. This generally takes about half a second for each firmware message. If we try to unload the driver n this state, the unload sequence will take a long time to complete. Improve this by checking the health register if it is available and abort the wait for the firmware response if the register shows that firmware is not healthy. The very first message HWRM_VER_GET is excluded from this check because that message is used to poll for firmware to come out of reset during error recovery. Signed-off-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 15 2月, 2021 3 次提交
-
-
由 Michael Chan 提交于
This is a new async message that the firmware can send to check if it can communicate with the driver. This is an added error detection scheme that firmware can use if it suspects errors in the PCIe interface. When the driver receives this async message, it will reply back echoing some data in the async message. If the firmware is not getting the reply with the proper data after some retries, error recovery will kick in. Reviewed-by: NAndy Gospodarek <gospo@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Reviewed-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Currently, the driver calls memset() to set all relevant context memory used by the chip to the initial value. This can take many milliseconds with the potentially large number of context pages allocated for the chip. To make this faster, we only need to initialize the "context kind" field of each block of context memory. This patch sets up the infrastructure to do that with the bnxt_mem_init structure. In the next patch, we'll add the logic to obtain the offset of the "context kind" from the firmware. This patch is not changing the current behavior of calling memset() to initialize all relevant context memory. Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
The main changes are the echo request/response from firmware for error detection and the NO_FCS feature to transmit frames without FCS. Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 1月, 2021 6 次提交
-
-
由 Michael Chan 提交于
Up until now, we don't need to keep track of this state because NAPI is always enabled once and disabled once during bring up and shutdown. For better error recovery in subsequent patches, we want to quiesce the device earlier during fatal error conditions. The normal shutdown sequence will disable NAPI again and the flag will prevent disabling NAPI twice. Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: NAndy Gospodarek <gospo@broadcom.com> Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Reviewed-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Acked-by: NWillem de Bruijn <willemb@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vasundhara Volam 提交于
Firmware may be in the middle of reset when the driver tries to do ifup. In that case, firmware will return a special error code and the driver will retry 10 times with 50 msecs delay after each retry. Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Acked-by: NWillem de Bruijn <willemb@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Vasundhara Volam 提交于
The timeout period for firmware messages is passed to the driver from the firmware in the response of the first command. This timeout period is multiplied by a factor for certain long running commands such as NVRAM commands. In some cases, the timeout period can become really long and it can cause hung task warnings if firmware has crashed or is not responding. To avoid such long delays, cap all firmware commands to a max timeout value of 40 seconds. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Acked-by: NWillem de Bruijn <willemb@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Michael Chan 提交于
The first HWRM_VER_GET message to firmware during probe may timeout if firmware is under reset. This can happen during hot-plug for example. On P5 and newer chips, we can check if firmware is in the boot stage by reading a status register. Retry 5 times if the status register shows that firmware is not ready and not in error state. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Acked-by: NWillem de Bruijn <willemb@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Michael Chan 提交于
Define macros to check for the various states in the lower 16 bits of the health register. Replace the C code that checks for these values with the newly defined macros. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Acked-by: NWillem de Bruijn <willemb@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Michael Chan 提交于
Updates to backing store APIs, QoS profiles, and push buffer initial index support. Since the new HWRM_FUNC_BACKING_STORE_CFG message size has increased, we need to add some compat. logic to fall back to the smaller legacy size if firmware cannot accept the larger message size. The new fields added to the structure are not used yet. Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Acked-by: NWillem de Bruijn <willemb@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 29 12月, 2020 1 次提交
-
-
由 Michael Chan 提交于
TQM rings are hardware resources that require host context memory managed by the driver. The driver supports up to 9 TQM rings and the number of rings to use is requested by firmware during run-time. Cap this number to the maximum supported to prevent accessing beyond the array. Future firmware may request more than 9 TQM rings. Define macros to remove the magic number 9 from the C code. Fixes: ac3158cb ("bnxt_en: Allocate TQM ring context memory according to fw specification.") Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 24 11月, 2020 1 次提交
-
-
由 Jakub Kicinski 提交于
linux/netdevice.h is included in very many places, touching any of its dependecies causes large incremental builds. Drop the linux/ethtool.h include, linux/netdevice.h just needs a forward declaration of struct ethtool_ops. Fix all the places which made use of this implicit include. Acked-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NShannon Nelson <snelson@pensando.io> Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Link: https://lore.kernel.org/r/20201120225052.1427503-1-kuba@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 27 10月, 2020 1 次提交
-
-
由 Vasundhara Volam 提交于
When a PCIe fatal error occurs, the internal latched BAR addresses in the chip get reset even though the BAR register values in config space are retained. pci_restore_state() will not rewrite the BAR addresses if the BAR address values are valid, causing the chip's internal BAR addresses to stay invalid. So we need to zero the BAR registers during PCIe fatal error to force pci_restore_state() to restore the BAR addresses. These write cycles to the BAR registers will cause the proper BAR addresses to latch internally. Fixes: 6316ea6d ("bnxt_en: Enable AER support.") Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 13 10月, 2020 1 次提交
-
-
由 Vasundhara Volam 提交于
Add a new bnxt_hwrm_nvm_get_dev_info() to query firmware version information via NVM_GET_DEV_INFO firmware command. Use it to get the running version of the NVM configuration information. This new function will also be used in subsequent patches to get the stored firmware versions. Reviewed-by: NAndy Gospodarek <gospo@broadcom.com> Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/1602493854-29283-8-git-send-email-michael.chan@broadcom.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 05 10月, 2020 3 次提交
-
-
由 Michael Chan 提交于
Currently, the driver will schedule RX ring reset when we get a buffer error in the RX completion record. These RX buffer errors can be due to normal out-of-buffer conditions or a permanent error in the RX ring. Because the driver cannot distinguish between these 2 conditions, we assume all these buffer errors require reset. This is very disruptive when it is just a normal out-of-buffer condition. Newer firmware will now monitor the rings for the permanent failure and will send a notification to the driver when it happens. This allows the driver to reset only when such a notification is received. In environments where we have predominently out-of-buffer conditions, we now can avoid these unnecessary resets. Reviewed-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Add a per ring rx_resets counter to count these RX resets. Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Edwin Peer 提交于
Firmware now supports device independent discovery of the status register location. This status register can provide more detailed information about firmware errors, especially if problems occur before the HWRM interface is functioning. Attempt to map this register if it is present and report the firmware status on firmware init failures. Signed-off-by: NEdwin Peer <edwin.peer@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 9月, 2020 2 次提交
-
-
由 Michael Chan 提交于
This feature allows the user to set the different FEC modes on the NIC port. Any new setting will take effect immediately after a link toggle. Reviewed-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Michael Chan 提交于
Implement .get_fecparam() method to report the configured and active FEC settings. Also report the supported and advertised FEC settings to the .get_link_ksettings() method. Reviewed-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-