- 26 Jan, 2021 21 commits
-
-
Michael Chan authored
Once the firmware fatal condition is detected, we should cease comminication with the firmware and hardware quickly even if there are many completion entries in the completion rings. This will speed up the recovery process and prevent further I/Os that may cause further exceptions. Do not proceed in the NAPI poll function if fatal condition is detected. Call napi_complete() and return without arming interrupts. Cleanup of all rings and reset are imminent. Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Michael Chan authored
Combine the three netdev_warn() calls into a single call, printed at the NETIF_MSG_HW log level. Reviewed-by:
-
Michael Chan authored
In the event of a fatal firmware error, firmware will notify the host and then it will proceed to do core reset when it sees that all functions have disabled Bus Master. To prevent Master Aborts and other hard errors, we need to quiesce all activities in addition to disabling Bus Master before the chip goes into core reset. Reviewed-by:
-
Michael Chan authored
In the event of a fatal firmware error, we want to disable IRQ early in the recovery sequence. This change will allow it to be called safely again as part of the normal shutdown sequence. Reviewed-by:
-
Michael Chan authored
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:
Andy Gospodarek <gospo@broadcom.com> Reviewed-by:
-
Michael Chan authored
This code to check if we have reached the maximum wait time after firmware reset is used multiple times. Add a helper function to do this. Reviewed-by:
-
Vasundhara Volam authored
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:
-
Edwin Peer authored
Drawing a hard line on aborted resets prevents a NIC open in some scenarios that may otherwise be recoverable. For example, if a firmware recovery happened while a PF was down and an attempt was made to bring up an associated VF in this state, then it was impossible to ever bring up this VF without a rebind or reload of its driver. Attempt to reinitialize the firmware when an aborted reset (or failed init after a reset) is discovered during open - it may succeed. Also take care to allow the user to retry opening the NIC even after an aborted reset. Signed-off-by:
-
Edwin Peer authored
Firmware is capable of generating asynchronous debug notifications. The event data is opaque to the driver and is simply logged. Debug notifications can be enabled by turning on hardware status messages using the ethtool msglvl interface. Reviewed-by:
-
Vasundhara Volam authored
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:
-
Vasundhara Volam authored
If firmware is in reset or in bad state, it won't be able to return VPD data. Move bnxt_vpd_read_info() until after bnxt_fw_init_one_p1() successfully returns. By then we would have established proper communications with the firmware. Reviewed-by:
-
Michael Chan authored
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:
-
Edwin Peer authored
Add missing support for handling NO_MASTER crashes while ports are administratively down (ifdown). On some SoC platforms, the driver needs to assist the firmware to recover from a crash via OP-TEE. This is performed in a similar fashion to what is done during driver probe. Signed-off-by:
-
Michael Chan authored
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:
-
Michael Chan authored
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:
-
Jakub Kicinski authored
DENG Qingfang says: ==================== dsa: add MT7530 GPIO support MT7530's LED controller can be used as GPIO controller. Add support for it. ==================== Link: https://lore.kernel.org/r/20210125044322.6280-1-dqfext@gmail.comSigned-off-by:
-
DENG Qingfang authored
MT7530's LED controller can drive up to 15 LED/GPIOs. Add support for GPIO control and allow users to use its GPIOs by setting gpio-controller property in device tree. Signed-off-by:
DENG Qingfang <dqfext@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
DENG Qingfang authored
Add device tree binding to support MT7530 GPIO controller. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
DENG Qingfang authored
MT762x HW, except for MT7628, supports frame length up to 2048 (maximum length on GDM), so allow setting MTU up to 2030. Also set the default frame length to the hardware default 1518. Signed-off-by:
-
Jiapeng Zhong authored
coccicheck suggested using PTR_ERR_OR_ZERO() and looking at the code. Fix the following coccicheck warnings: ./net/bridge/br_multicast.c:1295:7-13: WARNING: PTR_ERR_OR_ZERO can be used. Reported-by:
Abaci <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Acked-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Link: https://lore.kernel.org/r/1611542381-91178-1-git-send-email-abaci-bugfix@linux.alibaba.comSigned-off-by:
-
Subbaraya Sundeep authored
Support SPI and sequence number fields of ESP/AH header to be hashed for RSS. By default ESP/AH fields are not considered for RSS and needs to be set explicitly as below: ethtool -U eth0 rx-flow-hash esp4 sdfn or ethtool -U eth0 rx-flow-hash ah4 sdfn or ethtool -U eth0 rx-flow-hash esp6 sdfn or ethtool -U eth0 rx-flow-hash ah6 sdfn To disable hashing of ESP fields: ethtool -U eth0 rx-flow-hash esp4 sd or ethtool -U eth0 rx-flow-hash ah4 sd or ethtool -U eth0 rx-flow-hash esp6 sd or ethtool -U eth0 rx-flow-hash ah6 sd Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Link: https://lore.kernel.org/r/1611378552-13288-1-git-send-email-sundeep.lkml@gmail.comSigned-off-by:
-
- 25 Jan, 2021 1 commit
-
-
Heiner Kallweit authored
When working on the PCI VPD code I also tested with a Broadcom BCM95719 card. tg3 uses internal NVRAM access with this card, so I forced it to PCI VPD mode for testing. PCI VPD access fails (i + PCI_VPD_LRDT_TAG_SIZE + j > len) because only TG3_NVM_VPD_LEN (256) bytes are read, but PCI VPD has 400 bytes on this card. So add a constant TG3_NVM_PCI_VPD_MAX_LEN that defines the maximum PCI VPD size. The actual VPD size is returned by pci_read_vpd(). In addition it's not worth looping over pci_read_vpd(). If we miss the 125ms timeout per VPD dword read then definitely something is wrong, and if the tg3 module loading is killed then there's also not much benefit in retrying the VPD read. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
- 24 Jan, 2021 6 commits
-
-
Jakub Kicinski authored
Kurt Kanzenbach says: ==================== net: dsa: hellcreek: Add TAPRIO offloading The switch has support for the 802.1Qbv Time Aware Shaper (TAS). Traffic schedules may be configured individually on each front port. Each port has eight egress queues. The traffic is mapped to a traffic class respectively via the PCP field of a VLAN tagged frame. Previous attempts: * https://lkml.kernel.org/netdev/20201121115703.23221-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20210116124922.32356-1-kurt@linutronix.de/ ==================== Link: https://lore.kernel.org/r/20210123105633.16753-1-kurt@linutronix.deSigned-off-by:
-
Kurt Kanzenbach authored
The switch has support for the 802.1Qbv Time Aware Shaper (TAS). Traffic schedules may be configured individually on each front port. Each port has eight egress queues. The traffic is mapped to a traffic class respectively via the PCP field of a VLAN tagged frame. The TAPRIO Qdisc already implements that. Therefore, this interface can simply be reused. Add .port_setup_tc() accordingly. The activation of a schedule on a port is split into two parts: * Programming the necessary gate control list (GCL) * Setup delayed work for starting the schedule The hardware supports starting a schedule up to eight seconds in the future. The TAPRIO interface provides an absolute base time. Therefore, periodic delayed work is leveraged to check whether a schedule may be started or not. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Loic Poulain authored
The 'wwan' devtype is meant for devices that require additional configuration to be used, like WWAN specific APN setup over AT/QMI commands, rmnet link creation, etc. This is the case for MHI (Modem host Interface) netdev which targets modem/WWAN endpoints. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1611328554-1414-1-git-send-email-loic.poulain@linaro.orgSigned-off-by:
-
Jakub Kicinski authored
Alexander Lobakin says: ==================== udp: allow forwarding of plain (non-fraglisted) UDP GRO packets This series allows to form UDP GRO packets in cases without sockets (for forwarding). To not change the current datapath, this is performed only when the new corresponding netdev feature is enabled via Ethtool (and fraglisted GRO is disabled). Prior to this point, only fraglisted UDP GRO was available. Plain UDP GRO shows better forwarding performance when a target NIC is capable of GSO UDP offload. Since v3 [2]: - rename introduced netdev feature to reflect that it targets forwarding and don't touch fraglisted GRO at all (Willem de Bruijn). Since v2 [1]: - convert to a series; - new: add new netdev_feature to explicitly enable/disable UDP GRO when there is no socket, defaults to off (Paolo Abeni). Since v1 [0]: - drop redundant 'if (sk)' check (Alexander Duyck); - add a ref in the commit message to one more commit that was an important step for UDP GRO forwarding. [0] https://lore.kernel.org/netdev/20210112211536.261172-1-alobakin@pm.me [1] https://lore.kernel.org/netdev/20210113103232.4761-1-alobakin@pm.me [2] https://lore.kernel.org/netdev/20210118193122.87271-1-alobakin@pm.me ==================== Link: https://lore.kernel.org/r/20210122181909.36340-1-alobakin@pm.meSigned-off-by:
-
Alexander Lobakin authored
Commit 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.") actually not only added a support for fraglisted UDP GRO, but also tweaked some logics the way that non-fraglisted UDP GRO started to work for forwarding too. Commit 2e4ef10f ("net: add GSO UDP L4 and GSO fraglists to the list of software-backed types") added GSO UDP L4 to the list of software GSO to allow virtual netdevs to forward them as is up to the real drivers. Tests showed that currently forwarding and NATing of plain UDP GRO packets are performed fully correctly, regardless if the target netdevice has a support for hardware/driver GSO UDP L4 or not. Add the last element and allow to form plain UDP GRO packets if we are on forwarding path, and the new NETIF_F_GRO_UDP_FWD is enabled on a receiving netdevice. If both NETIF_F_GRO_FRAGLIST and NETIF_F_GRO_UDP_FWD are set, fraglisted GRO takes precedence. This keeps the current behaviour and is generally more optimal for now, as the number of NICs with hardware USO offload is relatively small. Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Acked-by:
-
Alexander Lobakin authored
Introduce a new netdev feature, NETIF_F_GRO_UDP_FWD, to allow user to turn UDP GRO on and off for forwarding. Defaults to off to not change current datapath. Suggested-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
- 23 Jan, 2021 12 commits
-
-
Jakub Kicinski authored
Richard Cochran says: ==================== Remove unneeded PHY time stamping option. The NETWORK_PHY_TIMESTAMPING configuration option adds additional checks into the networking hot path, and it is only needed by two rather esoteric devices, namely the TI DP83640 PHYTER and the ZHAW InES 1588 IP core. Very few end users have these devices, and those that do have them are building specialized embedded systems. Unfortunately two unrelated drivers depend on this option, and two defconfigs enable it. It is probably my fault for not paying enough attention in reviews. This series corrects the gratuitous use of NETWORK_PHY_TIMESTAMPING. ==================== Link: https://lore.kernel.org/r/cover.1611198584.git.richardcochran@gmail.comSigned-off-by:
-
Richard Cochran authored
The mvpp2 is an Ethernet driver, and it implements MAC style time stamping of PTP frames. It has no need of the expensive option to enable PHY time stamping. Remove the incorrect dependency. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Richard Cochran authored
The mv88e6xxx is a DSA driver, and it implements DSA style time stamping of PTP frames. It has no need of the expensive option to enable PHY time stamping. Remove the bogus dependency. Signed-off-by:
Brandon Streiff <brandon.streiff@ni.com> Signed-off-by:
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: NAPI poll updates While reviewing the IPA NAPI polling code in detail I found two problems. This series fixes those, and implements a few other improvements to this part of the code. The first two patches are minor bug fixes that avoid extra passes through the poll function. The third simplifies code inside the polling loop a bit. The last two update how interrupts are disabled; previously it was possible for another I/O completion condition to be recorded before NAPI got scheduled. ==================== Link: https://lore.kernel.org/r/20210121114821.26495-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
Currently in gsi_isr_ieob(), event ring IEOB interrupts are disabled one at a time. The loop disables the IEOB interrupt for all event rings represented in the event mask. Instead, just disable them all at once. Disable them all *before* clearing the interrupt condition. This guarantees we'll schedule NAPI for each event once, before another IEOB interrupt could be signaled. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Rename gsi_irq_ieob_disable() to be gsi_irq_ieob_disable_one(). Introduce a new function gsi_irq_ieob_disable() that takes a mask of events to disable rather than a single event id. This will be used in the next patch. Rename gsi_irq_ieob_enable() to be gsi_irq_ieob_enable_one() to be consistent. Signed-off-by:
-
Alex Elder authored
Have gsi_channel_update() return the first transaction in the updated completed transaction list, or NULL if no new transactions have been added. Signed-off-by:
-
Alex Elder authored
Pay attention to the return value of napi_complete(), completing polling only if it returns true. Just use napi rather than &channel->napi as the argument passed to napi_complete(). Signed-off-by:
-
Alex Elder authored
There is an off-by-one problem in gsi_channel_poll(). The count of transactions completed is incremented each time through the loop *before* determining whether there is any more work to do. As a result, if we exit the loop early the counter its value is one more than the number of transactions actually processed. Instead, increment the count after processing, to ensure it reflects the number of processed transactions. The result is more naturally described as a for loop rather than a while loop, so change that. Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: Expose number of physical ports The switch ASIC has a limited capacity of physical ports that it can support. While each system is brought up with a different number of ports, this number can be increased via splitting up to the ASIC's limit. Expose physical ports as a devlink resource so that user space will have visibility into the maximum number of ports that can be supported and the current occupancy. With this resource it is possible, for example, to write generic (i.e., not platform dependent) tests for port splitting. Patch #1 adds the new resource and patch #2 adds a selftest. v2: * Add the physical ports resource as a generic devlink resource so that it could be re-used by other device drivers ==================== Link: https://lore.kernel.org/r/20210121131024.2656154-1-idosch@idosch.orgSigned-off-by:
-
Danielle Ratson authored
Query the maximum number of supported physical ports using devlink-resource and test that this number can be reached by splitting each of the splittable ports to its width. Test that an error is returned in case the maximum number is exceeded. Signed-off-by:
Danielle Ratson <danieller@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Danielle Ratson authored
The switch ASIC has a limited capacity of physical ('flavour physical' in devlink terminology) ports that it can support. While each system is brought up with a different number of ports, this number can be increased via splitting up to the ASIC's limit. Expose physical ports as a devlink resource so that user space will have visibility to the maximum number of ports that can be supported and the current occupancy. In addition, add a "Generic Resources" section in devlink-resource documentation so the different drivers will be aligned by the same resource name when exposing to user space. Signed-off-by:Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
