- 27 Sep, 2020 18 commits
-
-
Amit Cohen authored
MTWE (Management Temperature Warning Event) is triggered for sensors whose temperature event enable bit is enabled in the MTMP register. Enable events for all the modules that have a temperature sensor. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
MTWE (Management Temperature Warning Event) is triggered when module's temperature is higher than its threshold. Register for MTWE events and increase the module's overheat counter when its corresponding sensor goes above the configured threshold. Signed-off-by:
-
Amit Cohen authored
Initialize an array that stores per-module overheat state and a counter indicating how many times the module was in overheat state. Export a function to query the counter according to module number. Will be used later on by the switch driver (i.e., mlxsw_spectrum) to expose module's overheat counter as part of ethtool statistics. Initialize mlxsw_env after driver initialization to be able to query number of modules from MGPIR register. Signed-off-by:
-
Amit Cohen authored
The MTMP register controls various temperature settings on a per-sensor basis. Subsequent patches are going to alter some of these settings for sensors found on port modules in response to certain events. In order to prevent the current callers that write to MTMP from overriding these settings, have them first query the register and then change only the relevant register fields. Signed-off-by:
-
Amit Cohen authored
PMAOS register configures and retrieves the per module status. The register is used also for enabling event for status change. It will be used to enable PMPE (Port Module Plug/Unplug) event. Signed-off-by:
-
Amit Cohen authored
PMPE register reports any operational status change of a module. It will be used for enabling temperature warning event when a module is plugged in. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Amit Cohen authored
Add MTWE (Management Temperature Warning Event) register, which is used for over temperature warning. Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: updates for -next To facilitate code maintenance and compatibility, #1 and #2 add device version to replace pci revision, #3 to #9 adds support for querying device capabilities and specifications, then the driver can use these query results to implement corresponding features (some features will be implemented later). And #10 is a minor cleanup since too many parameters for hclge_shaper_para_calc(). ==================== Signed-off-by: -
Huazhong Tan authored
As function hclge_shaper_para_calc() has too many arguments to add more, so encapsulate its three arguments ir_b, ir_u, ir_s into a structure. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
The device specifications querying is unsupported by the old firmware, in this case, these specifications are 0. However, some specifications should not be 0 or will cause problem. So after querying from firmware, some device specifications are needed to check their value and set to default value if their values are 0. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Guangbin Huang authored
The max tm rate is a fixed value(100Gb/s) now as it is defined by a macro. In order to support other rates in different kinds of device, it is better to use specification queried from firmware to replace this macro. As function hclge_shaper_para_calc() has too many arguments to add more, so encapsulate its three arguments ir_b, ir_u, ir_s into a structure. Signed-off-by:
-
Guangbin Huang authored
To improve code maintainability and compatibility, new commands HCLGE_OPC_QUERY_DEV_SPECS for PF and HCLGEVF_OPC_QUERY_DEV_SPECS for VF are introduced to query device specifications, instead of statically defining specifications by checking the hardware version or other methods. Signed-off-by:
-
Guangbin Huang authored
Adds debugfs to dump each device capability whether is supported. Signed-off-by:
-
Guangbin Huang authored
In order to improve code maintainability and compatibility, the capabilities of new features are queried from firmware. The member flag in struct hnae3_ae_dev indicates not only capabilities, but some initialized status. As capabilities bits queried from firmware is too many, it is better to use new member to indicate them. So adds member capabs in struce hnae3_ae_dev. Signed-off-by:
-
Guangbin Huang authored
Currently, the revision of the pci device is used to identify whether FEC is supported, which is not good for maintainability and compatibility. So use a capability flag to do that. Signed-off-by:
-
Guangbin Huang authored
In order to improve code maintainability and compatibility, add support to query the device capability by expanding the existing version query command. The device capability refers to the features supported by the device. Signed-off-by:
-
Guangbin Huang authored
Fibre device of PCI revision 0x20 don't support autoneg, and the ops get_autoneg() return AUTONEG_DISABLE so function hns3_nway_reset() will return earlier than judging PCI revision. Function hclge_handle_rocee_ras_error() don't need to judge PCI revision again because its caller hclge_handle_hw_ras_error() has judged once. Signed-off-by:
-
Guangbin Huang authored
To better identify the device version, struct hnae3_handle adds a member dev_version to replace pci revision. The dev_version consists of hardware version and PCI revision. The hardware version is queried from firmware by an existing firmware version query command. Signed-off-by:
-
- 26 Sep, 2020 22 commits
-
-
Jakub Kicinski authored
The "ethtool" debugfs directory holds per-netdev knobs, so move it from the device instance directory to the port directory. This fixes the following warning when creating multiple ports: debugfs: Directory 'ethtool' with parent 'netdevsim1' already present! Fixes: ff1f7c17 ("netdevsim: add pause frame stats") Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Generic adjustment for flow dissector in DSA This is the v2 of a series initially submitted in May: https://www.spinics.net/lists/netdev/msg651866.html The end goal is to get rid of the unintuitive code for the flow dissector that currently exists in the taggers. It can all be replaced by a single, common function. Some background work needs to be done for that. Especially the ocelot driver poses some problems, since it has a different tag length between RX and TX, and I didn't want to make DSA aware of that, since I could instead make the tag lengths equal. Changes in v3: - Added an optimization (08/15) that makes the generic case not need to call the .flow_dissect function pointer. Basically .flow_dissect now currently only exists for sja1105. - Moved the .promisc_on_master property to the tagger structure. - Added the .tail_tag property to the tagger structure. - Disabled "suppresscc = all" from my .gitconfig. ==================== Signed-off-by:
-
Vladimir Oltean authored
Remove the .flow_dissect procedure, so the flow dissector will call the generic variant which works for this tagging protocol. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: DENG Qingfang <dqfext@gmail.com> Cc: Mauri Sandberg <sandberg@mailfence.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
The sja1105 is a bit of a special snowflake, in that not all frames are transmitted/received in the same way. L2 link-local frames are received with the source port/switch ID information put in the destination MAC address. For the rest, a tag_8021q header is used. So only the latter frames displace the rest of the headers and need to use the generic flow dissector procedure. Signed-off-by:
-
Vladimir Oltean authored
Remove the .flow_dissect procedure, so the flow dissector will call the generic variant which works for this tagging protocol. Cc: John Crispin <john@phrozen.org> Cc: Alexander Lobakin <alobakin@pm.me> Signed-off-by:
-
Vladimir Oltean authored
Remove the .flow_dissect procedure, so the flow dissector will call the generic variant which works for this tagging protocol. Cc: DENG Qingfang <dqfext@gmail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: John Crispin <john@phrozen.org> Signed-off-by:
-
Vladimir Oltean authored
Remove the .flow_dissect procedure, so the flow dissector will call the generic variant which works for this tagging protocol. Cc: Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vladimir Oltean authored
Remove the .flow_dissect procedure, so the flow dissector will call the generic variant which works for this tagging protocol. Cc: Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vladimir Oltean authored
There are 2 Broadcom tags in use, one places the DSA tag before the Ethernet destination MAC address, and the other before the EtherType. Nonetheless, both displace the rest of the headers, so this tagger can use the generic flow dissector procedure which accounts for that. The ASCII art drawing is a good reference though, so keep it but move it somewhere else. Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
With the recent mitigations against speculative execution exploits, indirect function calls are more expensive and it would be good to avoid them where possible. In the case of DSA, most switch taggers will shift the EtherType and next headers by a fixed amount equal to that tag's length in bytes. So we can use a generic procedure to determine that, without calling into custom tagger code. However we still leave the flow_dissect method inside struct dsa_device_ops as an override for the generic function. Suggested-by:
-
Vladimir Oltean authored
The Marvell 88E6060 uses tag_trailer.c and the KSZ8795, KSZ9477 and KSZ9893 switches also use tail tags. Tell that to the DSA core, since this makes a difference for the flow dissector. Most switches break the parsing of frame headers, but these ones don't, so no flow dissector adjustment needs to be done for them. Signed-off-by:
-
Vladimir Oltean authored
For all DSA formats that don't use tail tags, it looks like behind the obscure number crunching they're all doing the same thing: locating the real EtherType behind the DSA tag. Nonetheless, this is not immediately obvious, so create a generic helper for those DSA taggers that put the header before the EtherType. Another assumption for the generic function is that the DSA tags are of equal length on RX and on TX. Prior to the previous patch, this was not true for ocelot and for gswip. The problem was resolved for ocelot, but for gswip it still remains, so that can't use this helper yet. Signed-off-by:
-
Vladimir Oltean authored
There is no tagger that returns anything other than zero, so just change the return type appropriately. Signed-off-by:
-
Vladimir Oltean authored
There are 2 goals that we follow: - Reduce the header size - Make the header size equal between RX and TX The issue that required long prefix on RX was the fact that the ocelot DSA tag, being put before Ethernet as it is, would overlap with the area that a DSA master uses for RX filtering (destination MAC address mainly). Now that we can ask DSA to put the master in promiscuous mode, in theory we could remove the prefix altogether and call it a day, but it looks like we can't. Using no prefix on ingress, some packets (such as ICMP) would be received, while others (such as PTP) would not be received. This is because the DSA master we use (enetc) triggers parse errors ("MAC rx frame errors") presumably because it sees Ethernet frames with a bad length. And indeed, when using no prefix, the EtherType (bytes 12-13 of the frame, bits 96-111) falls over the REW_VAL field from the extraction header, aka the PTP timestamp. When turning the short (32-bit) prefix on, the EtherType overlaps with bits 64-79 of the extraction header, which are a reserved area transmitted as zero by the switch. The packets are not dropped by the DSA master with a short prefix. Actually, the frames look like this in tcpdump (below is a PTP frame, with an extra dsa_8021q tag - dadb 0482 - added by a downstream sja1105). 89:0c:a9:f2:01:00 > 88:80:00:0a:00:1d, 802.3, length 0: LLC, \ dsap Unknown (0x10) Individual, ssap ProWay NM (0x0e) Response, \ ctrl 0x0004: Information, send seq 2, rcv seq 0, \ Flags [Response], length 78 0x0000: 8880 000a 001d 890c a9f2 0100 0000 100f ................ 0x0010: 0400 0000 0180 c200 000e 001f 7b63 0248 ............{c.H 0x0020: dadb 0482 88f7 1202 0036 0000 0000 0000 .........6...... 0x0030: 0000 0000 0000 0000 0000 001f 7bff fe63 ............{..c 0x0040: 0248 0001 1f81 0500 0000 0000 0000 0000 .H.............. 0x0050: 0000 0000 0000 0000 0000 0000 ............ So the short prefix is our new default: we've shortened our RX frames by 12 octets, increased TX by 4, and headers are now equal between RX and TX. Note that we still need promiscuous mode for the DSA master to not drop it. Signed-off-by: -
Vladimir Oltean authored
Currently PTP is broken when ports are in standalone mode (the tagger keeps printing this message): sja1105 spi0.1: Expected meta frame, is 01-80-c2-00-00-0e in the DSA master multicast filter? Sure, one might say "simply add 01-80-c2-00-00-0e to the master's RX filter" but things become more complicated because: - Actually all frames in the 01-80-c2-xx-xx-xx and 01-1b-19-xx-xx-xx range are trapped to the CPU automatically - The switch mangles bytes 3 and 4 of the MAC address via the incl_srcpt ("include source port [in the DMAC]") option, which is how source port and switch id identification is done for link-local traffic on RX. But this means that an address installed to the RX filter would, at the end of the day, not correspond to the final address seen by the DSA master. Assume RX filtering lists on DSA masters are typically too small to include all necessary addresses for PTP to work properly on sja1105, and just request promiscuous mode unconditionally. Just an example: Assuming the following addresses are trapped to the CPU: 01-80-c2-00-00-00 to 01-80-c2-00-00-ff 01-1b-19-00-00-00 to 01-1b-19-00-00-ff These are 512 addresses. Now let's say this is a board with 3 switches, and 4 ports per switch. The 512 addresses become 6144 addresses that must be managed by the DSA master's RX filtering lists. This may be refined in the future, but for now, it is simply not worth it to add the additional addresses to the master's RX filter, so simply request it to become promiscuous as soon as the driver probes. Signed-off-by: -
Vladimir Oltean authored
Currently DSA assumes that taggers don't mess with the destination MAC address of the frames on RX. That is not always the case. Some DSA headers are placed before the Ethernet header (ocelot), and others simply mangle random bytes from the destination MAC address (sja1105 with its incl_srcpt option). Currently the DSA master goes to promiscuous mode automatically when the slave devices go too (such as when enslaved to a bridge), but in standalone mode this is a problem that needs to be dealt with. So give drivers the possibility to signal that their tagging protocol will get randomly dropped otherwise, and let DSA deal with fixing that. Signed-off-by:
-
Vladimir Oltean authored
Remove the ocelot_configure_cpu() function, which was in fact bringing up 2 ports: the CPU port module, which both switchdev and DSA have, and the NPI port, which only DSA has. The (non-Ethernet) CPU port module is at a fixed index in the analyzer, whereas the NPI port is selected through the "ethernet" property in the device tree. Therefore, the function to set up an NPI port is DSA-specific, so we move it there, simplifying the ocelot switch library a little bit. Cc: Horatiu Vultur <horatiu.vultur@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: UNGLinuxDriver <UNGLinuxDriver@microchip.com> Signed-off-by:
-
Jakub Kicinski authored
This reverts commit 546c044c. Nothing prevents user from sending frames to "external" VxLAN devices. In fact kernel itself may generate icmp chatter. This is fine, such frames should be dropped. The point of the "missing encapsulation" warning was that frames with missing encap should not make it into vxlan_xmit_one(). And vxlan_xmit() drops them cleanly, so let it just do that. Without this revert the warning is triggered by the udp_tunnel_nic.sh test, but the minimal repro is: $ ip link add vxlan0 type vxlan \ group 239.1.1.1 \ dev lo \ dstport 1234 \ external $ ip li set dev vxlan0 up [ 419.165981] vxlan0: Missing encapsulation instructions [ 419.166551] WARNING: CPU: 0 PID: 1041 at drivers/net/vxlan.c:2889 vxlan_xmit+0x15c0/0x1fc0 [vxlan] Signed-off-by:
-
David S. Miller authored
Jacob Keller says: ==================== devlink flash update overwrite mask This series introduces support for a new attribute to the flash update command: DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK. This attribute is a bitfield which allows userspace to specify what set of subfields to overwrite when performing a flash update for a device. The intention is to support the ability to control the behavior of overwriting the configuration and identifying fields in the Intel ice device flash update process. This is necessary as the firmware layout for the ice device includes some settings and configuration within the same flash section as the main firmware binary. This series, and the accompanying iproute2 series, introduce support for the attribute. Once applied, the overwrite support can be be invoked via devlink: # overwrite settings devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings # overwrite identifiers and settings devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings overwrite identifiers To aid in the safe addition of new parameters, first some refactoring is done to the .flash_update function: its parameters are converted from a series of function arguments into a structure. This makes it easier to add the new parameter without changing the signature of the .flash_update handler in the future. Additionally, a "supported_flash_update_params" field is added to devlink_ops. This field is similar to the ethtool "supported_coalesc_params" field. The devlink core will now check that the DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT bit is set before forwarding the component attribute. Similarly, the new overwrite attribute will also require a supported bit. Doing these refactors will aid in adding any other attributes in the future, and creates a good pattern for other interfaces to use in the future. By requiring drivers to opt-in, we reduce the risk of accidentally breaking drivers when ever we add an additional parameter. We also reduce boiler plate code in drivers which do not support the parameters. Changes since v9: * rebased to current net-next, no other changes Changes since v7 * resend, hopefully avoiding the SMTP server issues I experienced on Friday Changes since v6 * Rebased to current net-next to resolve conflicts * Added changes to the ionic driver that recently merged flash update support * Fixed the changes for mlxsw to apply to core instead of spectrum.c after the recent refactor. * Picked up the review tags from Jakub Changes since v5 * Fix *all* of the BIT usage to use _BITUL() (thanks Jakub!) Changes since v4 * Renamed nla_overwrite to nla_overwrite_mask at Jiri's suggestion * Added "by this device" to the netlink error messages for unsupported attributes * Removed use of BIT() in the uapi header * Fixed the commit message for the netdevsim patch * Picked up Jakub's reviewed ==================== Signed-off-by: -
Jacob Keller authored
Support the recently added DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK parameter in the ice flash update handler. Convert the overwrite mask bitfield into the appropriate preservation level used by the firmware when updating. Because there is no equivalent preservation level for overwriting only identifiers, this combination is rejected by the driver as not supported with an appropriate extended ACK message. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
-
Jacob Keller authored
The devlink interface recently gained support for a new "overwrite mask" parameter that allows specifying how various sub-sections of a flash component are modified when updating. Add support for this to netdevsim, to enable easily testing the interface. Make the allowed overwrite mask values controllable via a debugfs parameter. This enables testing a flow where the driver rejects an unsupportable overwrite mask. Signed-off-by:
-
Jacob Keller authored
Sections of device flash may contain settings or device identifying information. When performing a flash update, it is generally expected that these settings and identifiers are not overwritten. However, it may sometimes be useful to allow overwriting these fields when performing a flash update. Some examples include, 1) customizing the initial device config on first programming, such as overwriting default device identifying information, or 2) reverting a device configuration to known good state provided in the new firmware image, or 3) in case it is suspected that current firmware logic for managing the preservation of fields during an update is broken. Although some devices are able to completely separate these types of settings and fields into separate components, this is not true for all hardware. To support controlling this behavior, a new DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK is defined. This is an nla_bitfield32 which will define what subset of fields in a component should be overwritten during an update. If no bits are specified, or of the overwrite mask is not provided, then an update should not overwrite anything, and should maintain the settings and identifiers as they are in the previous image. If the overwrite mask has the DEVLINK_FLASH_OVERWRITE_SETTINGS bit set, then the device should be configured to overwrite any of the settings in the requested component with settings found in the provided image. Similarly, if the DEVLINK_FLASH_OVERWRITE_IDENTIFIERS bit is set, the device should be configured to overwrite any device identifiers in the requested component with the identifiers from the image. Multiple overwrite modes may be combined to indicate that a combination of the set of fields that should be overwritten. Drivers which support the new overwrite mask must set the DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK in the supported_flash_update_params field of their devlink_ops. Signed-off-by:
-
