- 29 Jul, 2020 40 commits
-
-
Tarun Singh authored
Mask bits before accessing the profile type field. Signed-off-by:
Tarun Singh <tarun.k.singh@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Paul M Stillwell Jr authored
If a user sets the value of the TX or RX descriptors to some non-default value using 'ethtool -G' then we need to not overwrite the values when we rebuild the VSI. The VSI rebuild could happen as a result of a user setting the number of queues via the 'ethtool -L' command. Fix this by checking to see if the value we have stored is non-zero and if it is then don't change the value. Signed-off-by:
Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by:
-
Kiran Patil authored
Return ICE_ERR_DOES_NOT_EXIST return code if admin command error code is ICE_AQ_RC_ENOENT (not exist). ice_aq_sw_rules is used when switch rule is getting added/deleted/updated. In case of delete/update switch rule, admin command can return ICE_AQ_RC_ENOENT error code if such rule does not exist, hence return ICE_ERR_DOES_NOT_EXIST error code from ice_aq_sw_rule, so that caller of this function can decide how to handle ICE_ERR_DOES_NOT_EXIST. Signed-off-by:
Kiran Patil <kiran.patil@intel.com> Tested-by:
-
Nick Nunley authored
During a PCI FLR the MSI-X Enable flag in the VF PCI MSI-X capability register will be cleared. This can lead to issues when a VF is assigned to a VM because in these cases the VF driver receives no indication of the PF PCI error/reset and additionally it is incapable of restoring the cleared flag in the hypervisor configuration space without fully reinitializing the driver interrupt functionality. Since the VF driver is unable to easily resolve this condition on its own, restore the VF MSI-X flag during the PF PCI reset handling. Signed-off-by:
Nick Nunley <nicholas.d.nunley@intel.com> Tested-by:
-
Dave Ertman authored
When the driver experiences a link event (especially link up) there can be multiple events generated. Some of these are link fault and still have a state of DOWN set. The problem happens when the link comes UP during the PF driver handling one of the LINK DOWN events. The status of the link is updated and is now seen as UP, so when the actual LINK UP event comes, the port information has already been updated to be seen as UP, even though none of the UP activities have been completed. After the link information has been updated in the link handler and evaluated for MEDIA PRESENT, if the state of the link has been changed to UP, treat the DOWN event as an UP event since the link is now UP. Signed-off-by:
Dave Ertman <david.m.ertman@intel.com> Tested-by:
-
Dave Ertman authored
After a GLOBR, the link was broken so that a link up situation was being seen as a link down. The problem was that the rebuild process was updating the port_info link status without doing any of the other things that need to be done when link changes. This was causing the port_info struct to have current "UP" information so that any further UP interrupts were skipped as redundant. The rebuild flow should *not* be updating the port_info struct link information, so eliminate this and leave it to the link event handling code. Signed-off-by:
-
Dave Ertman authored
There is a bug where the LFC settings are not being preserved through a link event. The registers in question are the ones that are touched (and restored) when a set_local_mib AQ command is performed. On a link-up event, make sure that a set_local_mib is being performed. Move the function ice_aq_set_lldp_mib() from the DCB specific ice_dcb.c to ice_common.c so that the driver always has access to this AQ command. Signed-off-by:
-
David S. Miller authored
Jisheng Zhang says: ==================== net: stmmac: improve WOL Currently, stmmac driver relies on the HW PMT to support WOL. We want to support phy based WOL. patch1 is a small improvement to disable WAKE_MAGIC for PMT case if no pmt_magic_frame. patch2 and patch3 are two prepation patches. patch4 implement the phy based WOL patch5 tries to save a bit energy if WOL is enabled. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Jisheng Zhang authored
When WoL is enabled and the machine is powered off, the PHY remains waiting for wakeup events at max speed, which is a waste of energy. Slow down the PHY speed before stopping the ethernet if WoL is enabled, Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
-
Jisheng Zhang authored
Currently, the stmmac driver WOL implementation relies on MAC's PMT feature. We have a case: the MAC HW doesn't enable PMT, instead, we rely on the phy to support WOL. Implement the support for this case. Signed-off-by:
-
Jisheng Zhang authored
This is to prepare WOL support with phy. Compared with WOL implementation which relies on the MAC's PMT features, in phy supported WOL case, device_may_wakeup() may also be true, but we should not call mac's pmt() function if HW doesn't enable PMT. And during resume, we should call phylink_start() if PMT is disabled. Signed-off-by:
-
Jisheng Zhang authored
If !device_can_wakeup(), there's no need to futher check. And return -EOPNOTSUPP rather than -EINVAL if !device_can_wakeup(). Signed-off-by:
-
Jisheng Zhang authored
Remove WAKE_MAGIC from supported modes if the HW capability register shows no support for pmt_magic_frame. Signed-off-by:
-
David S. Miller authored
Linus Walleij says: ==================== RTL8366 VLAN callback fixes While we are pondering how to make the core set up the VLANs the right way, let's merge the uncontroversial fixes. ==================== Signed-off-by: -
Linus Walleij authored
Alter the rtl8366_vlan_add() to call rtl8366_set_vlan() inside the loop that goes over all VIDs since we now properly support calling that function more than once. Augment the loop to postincrement as this is more intuitive. The loop moved past the last VID but called rtl8366_set_vlan() with the port number instead of the VID, assuming a 1-to-1 correspondence between ports and VIDs. This was also a bug. Cc: DENG Qingfang <dqfext@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Fixes: d8652956 ("net: dsa: realtek-smi: Add Realtek SMI driver") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
The RTL8366 would not handle adding new members (ports) to a VLAN: the code assumed that ->port_vlan_add() was only called once for a single port. When intializing the switch with .configure_vlan_while_not_filtering set to true, the function is called numerous times for adding all ports to VLAN1, which was something the code could not handle. Alter rtl8366_set_vlan() to just |= new members and untagged flags to 4k and MC VLAN table entries alike. This makes it possible to just add new ports to a VLAN. Put in some helpful debug code that can be used to find any further bugs here. Cc: DENG Qingfang <dqfext@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Reviewed-by:
-
Brian Vazquez authored
This avoids another inderect call per RX packet which save us around 20-40 ns. Changelog: v1 -> v2: - Move declaraions to fib_rules.h to remove warnings Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Brian Vazquez <brianvv@google.com> Signed-off-by:
-
Cong Wang authored
When red_init() fails, red_destroy() is called to clean up. If the timer is not initialized yet, del_timer_sync() will complain. So we have to move timer_setup() before any failure. Reported-and-tested-by: syzbot+6e95a4fabf88dc217145@syzkaller.appspotmail.com Fixes: aee9caa0 ("net: sched: sch_red: Add qevents "early_drop" and "mark"") Cc: Petr Machata <petrm@mellanox.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
David S. Miller authored
Luo bin says: ==================== hinic: add some error messages for debug patch #1: support to handle hw abnormal event patch #2: improve the error messages when functions return failure and dump relevant registers in some exception handling processes ==================== Signed-off-by: -
Luo bin authored
improve the error message when functions return failure and dump relevant registers in some exception handling processes Signed-off-by:
Luo bin <luobin9@huawei.com> Signed-off-by:
-
Luo bin authored
add support to handle hw abnormal event such as hardware failure, cable unplugged,link error Signed-off-by:
-
David S. Miller authored
Jacob Keller says: ==================== introduce PLDM firmware update library This series goal is to enable support for updating the ice hardware flash using the devlink flash command. The ice firmware update files are distributed using the file format described by the "PLDM for Firmware Update" standard: https://www.dmtf.org/documents/pmci/pldm-firmware-update-specification-100 Because this file format is standard, this series introduces a new library that handles the generic logic for parsing the PLDM file header. The library uses a design that is very similar to the Mellanox mlxfw module. That is, a simple ops table is setup and device drivers instantiate an instance of the pldmfw library with the device specific operations. Doing so allows for each device to implement the low level behavior for how to interact with its firmware. This series includes the library and an implementation for the ice hardware. I've removed all of the parameters, and the proposed changes to support overwrite mode. I'll be working on the overwrite mask suggestion from Jakub as a follow-up series. Because the PLDM file format is a standard and not something that is specific to the Intel hardware, I opted to place this update library in lib/pldmfw. I should note that while I tried to make the library generic, it does not attempt to mimic the complete "Update Agent" as defined in the standard. This is mostly due to the fact that the actual interfaces exposed to software for the ice hardware would not allow this. This series depends on some work just recently and is based on top of the patch series sent by Tony published at: https://lore.kernel.org/netdev/20200723234720.1547308-1-anthony.l.nguyen@intel.com/T/#t Changes since v2 RFC * Removed overwrite mode patches, as this can become a follow up series with a separate discussion * Fixed a minor bug in the pldm_timestamp structure not being packed. * Dropped Cc for other driver maintainers, as this series no longer includes changes to the core flash update command. * Re-ordered patches slightly. Changes since v1 RFC * Removed the "allow_downgrade_on_flash_update" parameter. Instead, the driver will always attempt to flash the device, even when firmware indicates that it would be a downgrade. A dev_warn is used to indicate when this occurs. * Removed the "ignore_pending_flash_update". Instead, the driver will always check for and cancel any previous pending update. A devlink flash status message will be sent when this cancellation occurs. * Removed the "reset_after_flash_update" parameter. This will instead be implemented as part of a devlink reset interface, work left for a future change. * Replaced the "flash_update_preservation_level" parameter with a new "overwrite" mode attribute on the flash update command. For ice, this mode will select the preservation level. For all other drivers, I modified them to check that the mode is "OVERWRITE_NOTHING", and have Cc'd the maintainers to get their input. ==================== Signed-off-by:
-
Jacob Keller authored
Use the newly added pldmfw library to implement device flash update for the Intel ice networking device driver. This support uses the devlink flash update interface. The main parts of the flash include the Option ROM, the netlist module, and the main NVM data. The PLDM firmware file contains modules for each of these components. Using the pldmfw library, the provided firmware file will be scanned for the three major components, "fw.undi" for the Option ROM, "fw.mgmt" for the main NVM module containing the primary device firmware, and "fw.netlist" containing the netlist module. The flash is separated into two banks, the active bank containing the running firmware, and the inactive bank which we use for update. Each module is updated in a staged process. First, the inactive bank is erased, preparing the device for update. Second, the contents of the component are copied to the inactive portion of the flash. After all components are updated, the driver signals the device to switch the active bank during the next EMP reset (which would usually occur during the next reboot). Although the firmware AdminQ interface does report an immediate status for each command, the NVM erase and NVM write commands receive status asynchronously. The driver must not continue writing until previous erase and write commands have finished. The real status of the NVM commands is returned over the receive AdminQ. Implement a simple interface that uses a wait queue so that the main update thread can sleep until the completion status is reported by firmware. For erasing the inactive banks, this can take quite a while in practice. To help visualize the process to the devlink application and other applications based on the devlink netlink interface, status is reported via the devlink_flash_update_status_notify. While we do report status after each 4k block when writing, there is no real status we can report during erasing. We simply must wait for the complete module erasure to finish. With this implementation, basic flash update for the ice hardware is supported. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Jacob Keller authored
After a flash update, the pending status of the update can be determined from the device capabilities. Read the appropriate device capability and store whether there is a pending update awaiting a reboot. Signed-off-by:
-
Cudzilo, Szymon T authored
Add structures, identifiers, and helper functions for several AdminQ commands related to performing a firmware update for the ice hardware. These will be used in future code for implementing the devlink .flash_update handler. Signed-off-by:
Cudzilo, Szymon T <szymon.t.cudzilo@intel.com> Signed-off-by:
-
Jacek Naczyk authored
Extends function parsing response from Discover Device Capability AQC to check if the device supports unified NVM update flow. Signed-off-by:
Jacek Naczyk <jacek.naczyk@intel.com> Signed-off-by:
-
Jacob Keller authored
The pldmfw library is used to implement common logic needed to flash devices based on firmware files using the format described by the PLDM for Firmware Update standard. This library consists of logic to parse the PLDM file format from a firmware file object, as well as common logic for sending the relevant PLDM header data to the device firmware. A simple ops table is provided so that device drivers can implement device specific hardware interactions while keeping the common logic to the pldmfw library. This library will be used by the Intel ice networking driver as part of implementing device flash update via devlink. The library aims to be vendor and device agnostic. For this reason, it has been placed in lib/pldmfw, in the hopes that other devices which use the PLDM firmware file format may benefit from it in the future. However, do note that not all features defined in the PLDM standard have been implemented. Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Exchange MPTCP DATA_FIN/DATA_ACK before TCP FIN This series allows the MPTCP-level connection to be closed with the peers exchanging DATA_FIN and DATA_ACK according to the state machine in appendix D of RFC 8684. The process is very similar to the TCP disconnect state machine. The prior code sends DATA_FIN only when TCP FIN packets are sent, and does not allow for the MPTCP-level connection to be half-closed. Patch 8 ("mptcp: Use full MPTCP-level disconnect state machine") is the core of the series. Earlier patches in the series have some small fixes and helpers in preparation, and the final four small patches do some cleanup. ==================== Signed-off-by: -
Mat Martineau authored
The MPTCP socket's write_seq member can be read without the msk lock held, so use WRITE_ONCE() to store it. Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Mat Martineau authored
The MPTCP socket's write_seq member should be read with READ_ONCE() when the msk lock is not held. Signed-off-by:
-
Mat Martineau authored
Bare TCP ack skbs are freed right after MPTCP sees them, so the work to allocate, zero, and populate the MPTCP skb extension is wasted. Detect these skbs and do not add skb extensions to them. Signed-off-by:
-
Mat Martineau authored
The MPTCP state machine handles disconnections on non-fallback connections, but the mptcp_sock still needs to get notified when fallback subflows disconnect. Signed-off-by:
-
Mat Martineau authored
RFC 8684 appendix D describes the connection state machine for MPTCP. This patch implements the DATA_FIN / DATA_ACK exchanges and MPTCP-level socket state changes described in that appendix, rather than simply sending DATA_FIN along with TCP FIN when disconnecting subflows. DATA_FIN is now sent and acknowledged before shutting down the subflows. Received DATA_FIN information (if not part of a data packet) is written to the MPTCP socket when the incoming DSS option is parsed by the subflow, and the MPTCP worker is scheduled to process the flag. DATA_FIN received as part of a full DSS mapping will be handled when the mapping is processed. The DATA_FIN is acknowledged by the worker if the reader is caught up. If there is still data to be moved to the MPTCP-level queue, ack_seq will be incremented to account for the DATA_FIN when it reaches the end of the stream and a DATA_ACK will be sent to the peer. Signed-off-by:
-
Mat Martineau authored
After DATA_FIN has been sent, the peer will acknowledge it. An ack of the relevant MPTCP-level sequence number will update the MPTCP connection state appropriately. Signed-off-by:
-
Mat Martineau authored
This will be used to transition to the appropriate state on close and determine if a DATA_FIN needs to be sent for that state transition. Signed-off-by:
-
Mat Martineau authored
Incoming DATA_FIN headers need to propagate the presence of the DATA_FIN bit and the associated sequence number to the MPTCP layer, even when arriving on a bare ACK that does not get added to the receive queue. Add structure members to store the DATA_FIN information and helpers to set and check those values. Signed-off-by:
-
Mat Martineau authored
Since DATA_FIN information is the same for every subflow, store it only in the mptcp_sock. Signed-off-by:
-
Mat Martineau authored
mptcp_close() acquires the msk lock, so it clearly should not be held before the function is called. Signed-off-by:
-
Mat Martineau authored
A MPTCP socket where sending has been shut down should not attempt to send additional data, since DATA_FIN has already been sent. Signed-off-by:
-
Mat Martineau authored
RFC 8684-compliant DATA_FIN needs to be sent and ack'd before subflows are closed with TCP FIN, so write DATA_FIN DSS headers whenever their transmission has been enabled by the MPTCP connection-level socket. Signed-off-by:
-
