- 15 Jul, 2024 40 commits
-
-
Alexander Duyck authored
Program the Rx TCAM to control L2 forwarding. Since we are in full control of the NIC we need to make sure we include BMC forwarding in the rules. When host is not present BMC will program the TCAM to get onto the network but once we take ownership it's up to Linux driver to make sure BMC L2 addresses are handled correctly. Co-developed-by:
Sanman Pradhan <sanmanpradhan@meta.com> Signed-off-by:
Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/172079943202.1778861.4410412697614789017.stgit@ahduyck-xeon-server.home.arpaSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alexander Duyck authored
Handle Rx packets with basic csum and Rx hash offloads. NIC writes back to the completion ring a head buffer descriptor (data buffer allocated from header pages), variable number of payload descriptors (data buffers in payload pages), an optional metadata descriptor (type 2) and finally the primary metadata descriptor (type 3). This format makes scatter support fairly easy - start gathering the pages when we see head page, gather until we see the primary metadata descriptor, do the processing. Use XDP infra to collect the packet fragments as we traverse the descriptors. XDP itself is not supported yet, but it will be soon. Signed-off-by:
-
Alexander Duyck authored
Handle Tx of simple packets. Support checksum offload and gather. Use .ndo_features_check to make sure packet geometry will be supported by the HW, i.e. we can fit the header lengths into the descriptor fields. The device writes to the completion rings the position of the tail (consumer) pointer. Read all those writebacks, obviously the last one will be the most recent, complete skbs up to that point. Signed-off-by:
-
Alexander Duyck authored
Add basic support for detecting the link and reporting it at the netdev layer. For now we will just use the values reporeted by the firmware as the link configuration and assume that is the current configuration of the MAC and PCS. With this we start the stubbing out of the phylink interface that will be used to provide the configuration interface for ethtool in a future patch set. The phylink interface isn't an exact fit. As such we are currently working around several issues in this patch set that we plan to address in the future such as: 1. Support for FEC 2. Support for multiple lanes to handle 50GbaseR2 vs 50GbaseR1 3. Support for BMC CC: Russell King <linux@armlinux.org.uk> CC: Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Alexander Duyck authored
After the driver loads we need to get some initial capabilities from the firmware to determine what the device is capable of and what functionality needs to be enabled. Specifically we receive information about the current state of the link and if a BMC is present. After that when we bring the interface up we will need the ability to take ownership from the FW. To do that we will need to notify it that we are taking control before we start configuring the traffic classifier and MAC. Once we have ownership we need to notify the firmware that we are still present and active. To do that we will send a regular heartbeat to the FW. If the FW doesn't receive the heartbeat in a timely fashion it will retake control of the RPC and MAC and assume that the host has gone offline. Signed-off-by:
-
Alexander Duyck authored
Implement control path parts of Rx queue handling. The NIC consumes memory in pages. It takes a full page and places packets into it in a configurable manner (with the ability to define headroom / tailroom as well as head alignment requirements). As mentioned in prior patches there are two page submissions queues one for packet headers and second (optional) for packet payloads. For now feed both queues from a single page pool. Use the page pool "fragment" API, as we can't predict upfront how the page will be sliced. Signed-off-by:
-
Alexander Duyck authored
Implement basic management operations for Tx queues. Allocate memory for submission and completion rings. Learn how to start the queues, stop them, and wait for HW to be idle. We call HW rings "descriptor rings" (stored in ring->desc), and SW context rings "buffer rings" (stored in ring->*_buf union). This is the first patch which actually touches CSRs so add CSR helpers. No actual datapath / packet handling here, yet. Signed-off-by:
-
Alexander Duyck authored
Allocate a netdev and figure out basics like how many queues we need, MAC address, MTU bounds. Kick off a service task to do various periodic things like health checking. The service task only runs when device is open. We have four levels of objects here: - ring - A HW ring with head / tail pointers, - triad - Two submission and one completion ring, - NAPI - NAPI, with one IRQ and any number of Rx and Tx triads, - Netdev - The ultimate container of the rings and napi vectors. The "triad" is the only less-than-usual construct. On Rx we have two "free buffer" submission rings, one for packet headers and one for packet data. On Tx we have separate rings for XDP Tx and normal Tx. So we ended up with ring triplets in both directions. We keep NAPIs on a local list, even though core already maintains a list. Later on having a separate list will matter for live reconfig. We introduce the list already, the churn would not be worth it. Signed-off-by:
-
Alexander Duyck authored
Add a mechanism for sending messages to and receiving messages from the FW. The FW has fairly limited functionality, so the mechanism doesn't have to support high message rate. Use device mailbox registers to form two rings, one "to" and one "from" the device. The rings are just a convention between driver and FW, not a HW construct. We don't expect messages larger than 4k so use page-sized buffers. Signed-off-by:
-
Alexander Duyck authored
Add FW message formatting and parsing. The TLV format should look very familiar to those familiar with netlink. Since we don't have to deal with backward compatibility we tweaked the format a little to make it easier to deal with, and more appropriate for tightly coupled interfaces like driver<>FW communication. Signed-off-by:
-
Alexander Duyck authored
As a part of enabling the device the first step is to configure the AXI and Ethernet interfaces to allow for basic traffic. This consists of configuring several registers related to the PCIe and Ethernet FIFOs as well as configuring the handlers for moving traffic between entities. Signed-off-by:
-
Alexander Duyck authored
At the core of the fbnic device will be the devlink interface. This interface will eventually provide basic functionality in the event that there are any issues with the network interface. Add support for allocating the MSI-X vectors and setting up the BAR mapping. With this we can start enabling various subsystems and start brining up additional interfaces such the AXI fabric and the firmware mailbox. Signed-off-by:
-
Alexander Duyck authored
Create a bare-bones PCI driver for Meta's NIC. Subsequent changes will flesh it out. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/172079935646.1778861.9710282776096050607.stgit@ahduyck-xeon-server.home.arpaSigned-off-by:
-
Alexander Duyck authored
Add Meta as a vendor ID for PCI devices so we can use the macro for future drivers. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/172079935272.1778861.13619056509276833225.stgit@ahduyck-xeon-server.home.arpaSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== aux-sysfs-irqs Shay Says: ========== Introduce auxiliary bus IRQs sysfs Today, PCI PFs and VFs, which are anchored on the PCI bus, display their IRQ information in the <pci_device>/msi_irqs/<irq_num> sysfs files. PCI subfunctions (SFs) are similar to PFs and VFs and these SFs are anchored on the auxiliary bus. However, these PCI SFs lack such IRQ information on the auxiliary bus, leaving users without visibility into which IRQs are used by the SFs. This absence makes it impossible to debug situations and to understand the source of interrupts/SFs for performance tuning and debug. Additionally, the SFs are multifunctional devices supporting RDMA, network devices, clocks, and more, similar to their peer PCI PFs and VFs. Therefore, it is desirable to have SFs' IRQ information available at the bus/device level. To overcome the above limitations, this short series extends the auxiliary bus to display IRQ information in sysfs, similar to that of PFs and VFs. It adds an 'irqs' directory under the auxiliary device and includes an <irq_num> sysfs file within it. For example: $ ls /sys/bus/auxiliary/devices/mlx5_core.sf.1/irqs/ 50 51 52 53 54 55 56 57 58 Patch summary: patch-1 adds auxiliary bus to support irqs used by auxiliary device patch-2 mlx5 driver using exposing irqs for PCI SF devices via auxiliary bus ========== * tag 'aux-sysfs-irqs' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Expose SFs IRQs driver core: auxiliary bus: show auxiliary device IRQs RDMA/mlx5: Add Qcounters req_transport_retries_exceeded/req_rnr_retries_exceeded net/mlx5: Reimplement write combining test ==================== Link: https://patch.msgid.link/20240711213140.256997-1-saeed@kernel.orgSigned-off-by: -
Jakub Kicinski authored
Asbjørn Sloth Tønnesen says: ==================== flower: rework TCA_FLOWER_KEY_ENC_FLAGS usage This series reworks the recently added TCA_FLOWER_KEY_ENC_FLAGS attribute, to be more like TCA_FLOWER_KEY_FLAGS, and use the unused u32 flags field in FLOW_DISSECTOR_KEY_ENC_CONTROL, instead of adding a new flags field as FLOW_DISSECTOR_KEY_ENC_FLAGS. I have defined the new FLOW_DIS_F_* and TCA_FLOWER_KEY_FLAGS_* flags to co-exist with the existing flags, so the meaning of the flags field in struct flow_dissector_key_control is not depending on the context it is used in. If we run out of bits then we can always split them up later, if we really want to. Future flags might also be valid in both contexts. iproute2 RFC v2 patch: https://lore.kernel.org/560bcd549ca8ab24b1ad5abe352580a621f6d426.1720790774.git.dcaratti@redhat.com/ v3: https://lore.kernel.org/20240709163825.1210046-1-ast@fiberby.net/ v2: https://lore.kernel.org/20240705133348.728901-1-ast@fiberby.net/ v1: https://lore.kernel.org/20240703104600.455125-1-ast@fiberby.net/ RFC: https://lore.kernel.org/20240611235355.177667-1-ast@fiberby.net/ ==================== Link: https://patch.msgid.link/20240713021911.1631517-1-ast@fiberby.netSigned-off-by:
-
Asbjørn Sloth Tønnesen authored
NL_REQ_ATTR_CHECK() is used in fl_set_key_flags() to set extended attributes about the origin of an error, this patch propagates tca[TCA_OPTIONS] through. Before this patch: $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/tc.yaml \ --do newtfilter --json '{ "chain": 0, "family": 0, "handle": 4, "ifindex": 22, "info": 262152, "kind": "flower", "options": { "flags": 0, "key-enc-flags": 8, "key-eth-type": 2048 }, "parent": 4294967283 }' Netlink error: Invalid argument nl_len = 68 (52) nl_flags = 0x300 nl_type = 2 error: -22 extack: {'msg': 'Missing flags mask', 'miss-type': 111} After this patch: [same cmd] Netlink error: Invalid argument nl_len = 76 (60) nl_flags = 0x300 nl_type = 2 error: -22 extack: {'msg': 'Missing flags mask', 'miss-type': 111, 'miss-nest': 56} Suggested-by:Asbjørn Sloth Tønnesen <ast@fiberby.net> Link: https://patch.msgid.link/20240713021911.1631517-14-ast@fiberby.netSigned-off-by:
-
Asbjørn Sloth Tønnesen authored
Make sure to set encapsulated control flags also for non-IP packets, such that it's possible to allow matching on e.g. TUNNEL_OAM on a geneve packet carrying a non-IP packet. Suggested-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Now that TCA_FLOWER_KEY_ENC_FLAGS is unused, as it's former data is stored behind TCA_FLOWER_KEY_ENC_CONTROL, then remove the last bits of FLOW_DISSECTOR_KEY_ENC_FLAGS. FLOW_DISSECTOR_KEY_ENC_FLAGS is unreleased, and have been in net-next since 2024-06-04. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Describe key-enc-flags and key-enc-flags-mask. These are defined similarly to key-flags and key-flags-mask. Suggested-by:
Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20240713021911.1631517-11-ast@fiberby.netSigned-off-by:
-
Asbjørn Sloth Tønnesen authored
This patch changes how TCA_FLOWER_KEY_ENC_FLAGS is used, so that it is used with TCA_FLOWER_KEY_FLAGS_* flags, in the same way as TCA_FLOWER_KEY_FLAGS is currently used. Where TCA_FLOWER_KEY_FLAGS uses {key,mask}->control.flags, then TCA_FLOWER_KEY_ENC_FLAGS now uses {key,mask}->enc_control.flags, therefore {key,mask}->enc_flags is now unused. As the generic fl_set_key_flags/fl_dump_key_flags() is used with encap set to true, then fl_{set,dump}_key_enc_flags() is removed. This breaks unreleased userspace API (net-next since 2024-06-04). Signed-off-by: -
Asbjørn Sloth Tønnesen authored
Prepare to set and dump the tunnel flags. This code won't see any of these flags yet, as these flags aren't allowed by the NLA_POLICY_MASK, and the functions doesn't get called with encap set to true yet. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Set the new FLOW_DIS_F_TUNNEL_* encapsulated control flags, based on if their counter-part is set in tun_flags. These flags are not userspace visible yet, as the code to dump encapsulated control flags will first be added, and later activated in the following patches. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Rename skb_flow_dissect_set_enc_addr_type() to skb_flow_dissect_set_enc_control(), and make it set both addr_type and flags in FLOW_DISSECTOR_KEY_ENC_CONTROL. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
This policy guards fl_set_key_flags() from seeing flags not used in the context of TCA_FLOWER_KEY_FLAGS. In order For the policy check to be performed with the correct endianness, then we also needs to change the attribute type to NLA_BE32 (Thanks Davide). TCA_FLOWER_KEY_FLAGS{,_MASK} already has a be32 comment in include/uapi/linux/pkt_cls.h. Signed-off-by: -
Asbjørn Sloth Tønnesen authored
Prepare fl_set_key_flags/fl_dump_key_flags() for use with TCA_FLOWER_KEY_ENC_FLAGS{,_MASK}. This patch adds an encap argument, similar to fl_set_key_ip/ fl_dump_key_ip(), and determine the flower keys based on the encap argument, and use them in the rest of the two functions. Since these functions are so far, only called with encap set false, then there is no functional change. Signed-off-by: -
Asbjørn Sloth Tønnesen authored
Define new TCA_FLOWER_KEY_FLAGS_* flags for use in struct flow_dissector_key_control, covering the same flags as currently exposed through TCA_FLOWER_KEY_ENC_FLAGS. Put the new flags under FLOW_DIS_F_*. The idea is that we can later, move the existing flags under FLOW_DIS_F_* as well. The ynl flag names have been taken from the RFC iproute2 patch. Signed-off-by:
-
Asbjørn Sloth Tønnesen authored
Describe the flower control flags, and use them for key-flags and key-flags-mask. The flag names have been taken from iproute2. Suggested-by:
-
Asbjørn Sloth Tønnesen authored
Redefine the flower control flags as an enum, so they are included in BTF info. Make the kernel-side enum a more explicit superset of TCA_FLOWER_KEY_FLAGS_*, new flags still need to be added to both enums, but at least the bit position only has to be defined once. FLOW_DIS_ENCAPSULATION is never set for mask, so it can't be exposed to userspace in an unsupported flags mask error message, so it will be placed one bit position above the last uAPI flag. Suggested-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Suggested-by:
-
Jakub Kicinski authored
This reverts commit f7023b3d. Russell indicates that assuming 32bits are sufficient isn't necessarily safe. Link: https://lore.kernel.org/20240711154741.174745-1-thorsten.blum@toblux.com/Signed-off-by:
-
Christophe JAILLET authored
'struct llc_sap_state_trans' are not modified in this driver. Constifying this structure moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 339 456 24 819 333 net/llc/llc_s_st.o After: ===== text data bss dec hex filename 683 144 0 827 33b net/llc/llc_s_st.o Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/9d17587639195ee94b74ff06a11ef97d1833ee52.1720973710.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Christophe JAILLET authored
'struct llc_conn_state_trans' are not modified in this driver. Constifying this structure moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 13923 10896 32 24851 6113 net/llc/llc_c_st.o After: ===== text data bss dec hex filename 21859 3328 0 25187 6263 net/llc/llc_c_st.o Signed-off-by:
-
Christian Eggers authored
Name it 'addr' instead of 'port' or 'phy'. Signed-off-by:
Christian Eggers <ceggers@arri.de> Link: https://patch.msgid.link/20240715123050.21202-1-ceggers@arri.deSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'for-net-next-2024-07-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Luiz Augusto von Dentz says: ==================== bluetooth-next pull request for net-next: - qca: use the power sequencer for QCA6390 - btusb: mediatek: add ISO data transmission functions - hci_bcm4377: Add BCM4388 support - btintel: Add support for BlazarU core - btintel: Add support for Whale Peak2 - btnxpuart: Add support for AW693 A1 chipset - btnxpuart: Add support for IW615 chipset - btusb: Add Realtek RTL8852BE support ID 0x13d3:0x3591 * tag 'for-net-next-2024-07-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (71 commits) Bluetooth: btmtk: Mark all stub functions as inline Bluetooth: hci_qca: Fix build error Bluetooth: hci_qca: use the power sequencer for wcn7850 and wcn6855 Bluetooth: hci_qca: make pwrseq calls the default if available Bluetooth: hci_qca: unduplicate calls to hci_uart_register_device() Bluetooth: hci_qca: schedule a devm action for disabling the clock dt-bindings: bluetooth: qualcomm: describe the inputs from PMU for wcn7850 Bluetooth: btnxpuart: Fix warnings for suspend and resume functions Bluetooth: btnxpuart: Add system suspend and resume handlers Bluetooth: btnxpuart: Add support for IW615 chipset Bluetooth: btnxpuart: Add support for AW693 A1 chipset Bluetooth: btintel: Add support for Whale Peak2 Bluetooth: btintel: Add support for BlazarU core Bluetooth: btusb: mediatek: add ISO data transmission functions Bluetooth: btmtk: move btusb_recv_acl_mtk to btmtk.c Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c Bluetooth: btusb: add callback function in btusb suspend/resume Bluetooth: btmtk: rename btmediatek_data Bluetooth: btusb: mediatek: return error for failed reg access ... ==================== Link: https://patch.msgid.link/20240715142543.303944-1-luiz.dentz@gmail.comSigned-off-by:
-
Jakub Kicinski authored
First part of "net: Make timestamping selectable" from Kory Maincent. Change the driver-facing type already to lower rebasing pain. Link: https://lore.kernel.org/20240709-feature_ptp_netnext-v17-0-b5317f50df2a@bootlin.com/Signed-off-by:
-
Kory Maincent authored
In prevision to add new UAPI for hwtstamp we will be limited to the struct ethtool_ts_info that is currently passed in fixed binary format through the ETHTOOL_GET_TS_INFO ethtool ioctl. It would be good if new kernel code already started operating on an extensible kernel variant of that structure, similar in concept to struct kernel_hwtstamp_config vs struct hwtstamp_config. Since struct ethtool_ts_info is in include/uapi/linux/ethtool.h, here we introduce the kernel-only structure in include/linux/ethtool.h. The manual copy is then made in the function called by ETHTOOL_GET_TS_INFO. Acked-by:
Shannon Nelson <shannon.nelson@amd.com> Acked-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20240709-feature_ptp_netnext-v17-6-b5317f50df2a@bootlin.comSigned-off-by:
-
Kory Maincent authored
Prepare for future support of saving hwtstamp source in PTP xarray by introducing HWTSTAMP_SOURCE_UNSPEC to hwtstamp_source enum, setting it to 0 to match old behavior of no source defined. Signed-off-by:
-
Kory Maincent authored
Change the API to select MAC default time stamping instead of the PHY. Indeed the PHY is closer to the wire therefore theoretically it has less delay than the MAC timestamping but the reality is different. Due to lower time stamping clock frequency, latency in the MDIO bus and no PHC hardware synchronization between different PHY, the PHY PTP is often less precise than the MAC. The exception is for PHY designed specially for PTP case but these devices are not very widespread. For not breaking the compatibility default_timestamp flag has been introduced in phy_device that is set by the phy driver to know we are using the old API behavior. Reviewed-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by:
-
Nathan Chancellor authored
Several recent patches added static stubs to btmtk.h without the inline keyword, which causes instances of -Wunused-function when those stubs are not used anywhere in a file that includes the header: In file included from drivers/bluetooth/btusb.c:28: drivers/bluetooth/btmtk.h:254:13: warning: 'btmtk_fw_get_filename' defined but not used [-Wunused-function] 254 | static void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, | ^~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtk.h:249:12: warning: 'btmtk_process_coredump' defined but not used [-Wunused-function] 249 | static int btmtk_process_coredump(struct hci_dev *hdev, struct sk_buff *skb) | ^~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtk.h:243:12: warning: 'btmtk_register_coredump' defined but not used [-Wunused-function] 243 | static int btmtk_register_coredump(struct hci_dev *hdev, const char *name, | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtk.h:233:12: warning: 'btmtk_setup_firmware' defined but not used [-Wunused-function] 233 | static int btmtk_setup_firmware(struct hci_dev *hdev, const char *fwname, | ^~~~~~~~~~~~~~~~~~~~ drivers/bluetooth/btmtk.h:227:12: warning: 'btmtk_setup_firmware_79xx' defined but not used [-Wunused-function] 227 | static int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname, | ^~~~~~~~~~~~~~~~~~~~~~~~~ Add inline to all the stubs in btmtk.h (even ones that do not currently have any warnings associated with them) to ensure there are never unused function warnings from these stubs, as is customary for the kernel. Signed-off-by:Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Luiz Augusto von Dentz authored
This fixes the following build error introduced by b80f4e3b ("Bluetooth: hci_qca: schedule a devm action for disabling the clock"): drivers/bluetooth/hci_qca.c: In function ‘qca_serdev_remove’: drivers/bluetooth/hci_qca.c:2501:2: error: label at end of compound statement 2501 | default: | ^~~~~~~ Fixes: b80f4e3b ("Bluetooth: hci_qca: schedule a devm action for disabling the clock") Signed-off-by:
-
