mirror of
https://github.com/torvalds/linux
synced 2024-10-04 18:33:42 +00:00
Networking changes for 6.4.
Core ---- - Introduce a config option to tweak MAX_SKB_FRAGS. Increasing the default value allows for better BIG TCP performances. - Reduce compound page head access for zero-copy data transfers. - RPS/RFS improvements, avoiding unneeded NET_RX_SOFTIRQ when possible. - Threaded NAPI improvements, adding defer skb free support and unneeded softirq avoidance. - Address dst_entry reference count scalability issues, via false sharing avoidance and optimize refcount tracking. - Add lockless accesses annotation to sk_err[_soft]. - Optimize again the skb struct layout. - Extends the skb drop reasons to make it usable by multiple subsystems. - Better const qualifier awareness for socket casts. BPF --- - Add skb and XDP typed dynptrs which allow BPF programs for more ergonomic and less brittle iteration through data and variable-sized accesses. - Add a new BPF netfilter program type and minimal support to hook BPF programs to netfilter hooks such as prerouting or forward. - Add more precise memory usage reporting for all BPF map types. - Adds support for using {FOU,GUE} encap with an ipip device operating in collect_md mode and add a set of BPF kfuncs for controlling encap params. - Allow BPF programs to detect at load time whether a particular kfunc exists or not, and also add support for this in light skeleton. - Bigger batch of BPF verifier improvements to prepare for upcoming BPF open-coded iterators allowing for less restrictive looping capabilities. - Rework RCU enforcement in the verifier, add kptr_rcu and enforce BPF programs to NULL-check before passing such pointers into kfunc. - Add support for kptrs in percpu hashmaps, percpu LRU hashmaps and in local storage maps. - Enable RCU semantics for task BPF kptrs and allow referenced kptr tasks to be stored in BPF maps. - Add support for refcounted local kptrs to the verifier for allowing shared ownership, useful for adding a node to both the BPF list and rbtree. - Add BPF verifier support for ST instructions in convert_ctx_access() which will help new -mcpu=v4 clang flag to start emitting them. - Add ARM32 USDT support to libbpf. - Improve bpftool's visual program dump which produces the control flow graph in a DOT format by adding C source inline annotations. Protocols --------- - IPv4: Allow adding to IPv4 address a 'protocol' tag. Such value indicates the provenance of the IP address. - IPv6: optimize route lookup, dropping unneeded R/W lock acquisition. - Add the handshake upcall mechanism, allowing the user-space to implement generic TLS handshake on kernel's behalf. - Bridge: support per-{Port, VLAN} neighbor suppression, increasing resilience to nodes failures. - SCTP: add support for Fair Capacity and Weighted Fair Queueing schedulers. - MPTCP: delay first subflow allocation up to its first usage. This will allow for later better LSM interaction. - xfrm: Remove inner/outer modes from input/output path. These are not needed anymore. - WiFi: - reduced neighbor report (RNR) handling for AP mode - HW timestamping support - support for randomized auth/deauth TA for PASN privacy - per-link debugfs for multi-link - TC offload support for mac80211 drivers - mac80211 mesh fast-xmit and fast-rx support - enable Wi-Fi 7 (EHT) mesh support Netfilter --------- - Add nf_tables 'brouting' support, to force a packet to be routed instead of being bridged. - Update bridge netfilter and ovs conntrack helpers to handle IPv6 Jumbo packets properly, i.e. fetch the packet length from hop-by-hop extension header. This is needed for BIT TCP support. - The iptables 32bit compat interface isn't compiled in by default anymore. - Move ip(6)tables builtin icmp matches to the udptcp one. This has the advantage that icmp/icmpv6 match doesn't load the iptables/ip6tables modules anymore when iptables-nft is used. - Extended netlink error report for netdevice in flowtables and netdev/chains. Allow for incrementally add/delete devices to netdev basechain. Allow to create netdev chain without device. Driver API ---------- - Remove redundant Device Control Error Reporting Enable, as PCI core has already error reporting enabled at enumeration time. - Move Multicast DB netlink handlers to core, allowing devices other then bridge to use them. - Allow the page_pool to directly recycle the pages from safely localized NAPI. - Implement lockless TX queue stop/wake combo macros, allowing for further code de-duplication and sanitization. - Add YNL support for user headers and struct attrs. - Add partial YNL specification for devlink. - Add partial YNL specification for ethtool. - Add tc-mqprio and tc-taprio support for preemptible traffic classes. - Add tx push buf len param to ethtool, specifies the maximum number of bytes of a transmitted packet a driver can push directly to the underlying device. - Add basic LED support for switch/phy. - Add NAPI documentation, stop relaying on external links. - Convert dsa_master_ioctl() to netdev notifier. This is a preparatory work to make the hardware timestamping layer selectable by user space. - Add transceiver support and improve the error messages for CAN-FD controllers. New hardware / drivers ---------------------- - Ethernet: - AMD/Pensando core device support - MediaTek MT7981 SoC - MediaTek MT7988 SoC - Broadcom BCM53134 embedded switch - Texas Instruments CPSW9G ethernet switch - Qualcomm EMAC3 DWMAC ethernet - StarFive JH7110 SoC - NXP CBTX ethernet PHY - WiFi: - Apple M1 Pro/Max devices - RealTek rtl8710bu/rtl8188gu - RealTek rtl8822bs, rtl8822cs and rtl8821cs SDIO chipset - Bluetooth: - Realtek RTL8821CS, RTL8851B, RTL8852BS - Mediatek MT7663, MT7922 - NXP w8997 - Actions Semi ATS2851 - QTI WCN6855 - Marvell 88W8997 - Can: - STMicroelectronics bxcan stm32f429 Drivers ------- - Ethernet NICs: - Intel (1G, icg): - add tracking and reporting of QBV config errors. - add support for configuring max SDU for each Tx queue. - Intel (100G, ice): - refactor mailbox overflow detection to support Scalable IOV - GNSS interface optimization - Intel (i40e): - support XDP multi-buffer - nVidia/Mellanox: - add the support for linux bridge multicast offload - enable TC offload for egress and engress MACVLAN over bond - add support for VxLAN GBP encap/decap flows offload - extend packet offload to fully support libreswan - support tunnel mode in mlx5 IPsec packet offload - extend XDP multi-buffer support - support MACsec VLAN offload - add support for dynamic msix vectors allocation - drop RX page_cache and fully use page_pool - implement thermal zone to report NIC temperature - Netronome/Corigine: - add support for multi-zone conntrack offload - Solarflare/Xilinx: - support offloading TC VLAN push/pop actions to the MAE - support TC decap rules - support unicast PTP - Other NICs: - Broadcom (bnxt): enforce software based freq adjustments only on shared PHC NIC - RealTek (r8169): refactor to addess ASPM issues during NAPI poll. - Micrel (lan8841): add support for PTP_PF_PEROUT - Cadence (macb): enable PTP unicast - Engleder (tsnep): add XDP socket zero-copy support - virtio-net: implement exact header length guest feature - veth: add page_pool support for page recycling - vxlan: add MDB data path support - gve: add XDP support for GQI-QPL format - geneve: accept every ethertype - macvlan: allow some packets to bypass broadcast queue - mana: add support for jumbo frame - Ethernet high-speed switches: - Microchip (sparx5): Add support for TC flower templates. - Ethernet embedded switches: - Broadcom (b54): - configure 6318 and 63268 RGMII ports - Marvell (mv88e6xxx): - faster C45 bus scan - Microchip: - lan966x: - add support for IS1 VCAP - better TX/RX from/to CPU performances - ksz9477: add ETS Qdisc support - ksz8: enhance static MAC table operations and error handling - sama7g5: add PTP capability - NXP (ocelot): - add support for external ports - add support for preemptible traffic classes - Texas Instruments: - add CPSWxG SGMII support for J7200 and J721E - Intel WiFi (iwlwifi): - preparation for Wi-Fi 7 EHT and multi-link support - EHT (Wi-Fi 7) sniffer support - hardware timestamping support for some devices/firwmares - TX beacon protection on newer hardware - Qualcomm 802.11ax WiFi (ath11k): - MU-MIMO parameters support - ack signal support for management packets - RealTek WiFi (rtw88): - SDIO bus support - better support for some SDIO devices (e.g. MAC address from efuse) - RealTek WiFi (rtw89): - HW scan support for 8852b - better support for 6 GHz scanning - support for various newer firmware APIs - framework firmware backwards compatibility - MediaTek WiFi (mt76): - P2P support - mesh A-MSDU support - EHT (Wi-Fi 7) support - coredump support Signed-off-by: Paolo Abeni <pabeni@redhat.com> -----BEGIN PGP SIGNATURE----- iQJGBAABCAAwFiEEg1AjqC77wbdLX2LbKSR5jcyPE6QFAmRI/mUSHHBhYmVuaUBy ZWRoYXQuY29tAAoJECkkeY3MjxOkgO0QAJGxpuN67YgYV0BIM+/atWKEEexJYG7B 9MMpU4jMO3EW/pUS5t7VRsBLUybLYVPmqCZoHodObDfnu59jiPOegb6SikJv/ZwJ Zw62PVk5MvDnQjlu4e6kDcGwkplteN08TlgI+a49BUTedpdFitrxHAYGW8f2fRO6 cK2XSld+ZucMoym5vRwf8yWS1BwdxnslPMxDJ+/8ZbWBZv44qAnG2vMB/kIx7ObC Vel/4m6MzTwVsLYBsRvcwMVbNNlZ9GuhztlTzEbfGA4ZhTadIAMgb5VTWXB84Ws7 Aic5wTdli+q+x6/2cxhbyeoVuB9HHObYmLBAciGg4GNljP5rnQBY3X3+KVZ/x9TI HQB7CmhxmAZVrO9pLARFV+ECrMTH2/dy3NyrZ7uYQ3WPOXJi8hJZjOTO/eeEGL7C eTjdz0dZBWIBK2gON/6s4nExXVQUTEF2ZsPi52jTTClKjfe5pz/ddeFQIWaY1DTm pInEiWPAvd28JyiFmhFNHsuIBCjX/Zqe2JuMfMBeBibDAC09o/OGdKJYUI15AiRf F46Pdb7use/puqfrYW44kSAfaPYoBiE+hj1RdeQfen35xD9HVE4vdnLNeuhRlFF9 aQfyIRHYQofkumRDr5f8JEY66cl9NiKQ4IVW1xxQfYDNdC6wQqREPG1md7rJVMrJ vP7ugFnttneg =ITVa -----END PGP SIGNATURE----- Merge tag 'net-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next Pull networking updates from Paolo Abeni: "Core: - Introduce a config option to tweak MAX_SKB_FRAGS. Increasing the default value allows for better BIG TCP performances - Reduce compound page head access for zero-copy data transfers - RPS/RFS improvements, avoiding unneeded NET_RX_SOFTIRQ when possible - Threaded NAPI improvements, adding defer skb free support and unneeded softirq avoidance - Address dst_entry reference count scalability issues, via false sharing avoidance and optimize refcount tracking - Add lockless accesses annotation to sk_err[_soft] - Optimize again the skb struct layout - Extends the skb drop reasons to make it usable by multiple subsystems - Better const qualifier awareness for socket casts BPF: - Add skb and XDP typed dynptrs which allow BPF programs for more ergonomic and less brittle iteration through data and variable-sized accesses - Add a new BPF netfilter program type and minimal support to hook BPF programs to netfilter hooks such as prerouting or forward - Add more precise memory usage reporting for all BPF map types - Adds support for using {FOU,GUE} encap with an ipip device operating in collect_md mode and add a set of BPF kfuncs for controlling encap params - Allow BPF programs to detect at load time whether a particular kfunc exists or not, and also add support for this in light skeleton - Bigger batch of BPF verifier improvements to prepare for upcoming BPF open-coded iterators allowing for less restrictive looping capabilities - Rework RCU enforcement in the verifier, add kptr_rcu and enforce BPF programs to NULL-check before passing such pointers into kfunc - Add support for kptrs in percpu hashmaps, percpu LRU hashmaps and in local storage maps - Enable RCU semantics for task BPF kptrs and allow referenced kptr tasks to be stored in BPF maps - Add support for refcounted local kptrs to the verifier for allowing shared ownership, useful for adding a node to both the BPF list and rbtree - Add BPF verifier support for ST instructions in convert_ctx_access() which will help new -mcpu=v4 clang flag to start emitting them - Add ARM32 USDT support to libbpf - Improve bpftool's visual program dump which produces the control flow graph in a DOT format by adding C source inline annotations Protocols: - IPv4: Allow adding to IPv4 address a 'protocol' tag. Such value indicates the provenance of the IP address - IPv6: optimize route lookup, dropping unneeded R/W lock acquisition - Add the handshake upcall mechanism, allowing the user-space to implement generic TLS handshake on kernel's behalf - Bridge: support per-{Port, VLAN} neighbor suppression, increasing resilience to nodes failures - SCTP: add support for Fair Capacity and Weighted Fair Queueing schedulers - MPTCP: delay first subflow allocation up to its first usage. This will allow for later better LSM interaction - xfrm: Remove inner/outer modes from input/output path. These are not needed anymore - WiFi: - reduced neighbor report (RNR) handling for AP mode - HW timestamping support - support for randomized auth/deauth TA for PASN privacy - per-link debugfs for multi-link - TC offload support for mac80211 drivers - mac80211 mesh fast-xmit and fast-rx support - enable Wi-Fi 7 (EHT) mesh support Netfilter: - Add nf_tables 'brouting' support, to force a packet to be routed instead of being bridged - Update bridge netfilter and ovs conntrack helpers to handle IPv6 Jumbo packets properly, i.e. fetch the packet length from hop-by-hop extension header. This is needed for BIT TCP support - The iptables 32bit compat interface isn't compiled in by default anymore - Move ip(6)tables builtin icmp matches to the udptcp one. This has the advantage that icmp/icmpv6 match doesn't load the iptables/ip6tables modules anymore when iptables-nft is used - Extended netlink error report for netdevice in flowtables and netdev/chains. Allow for incrementally add/delete devices to netdev basechain. Allow to create netdev chain without device Driver API: - Remove redundant Device Control Error Reporting Enable, as PCI core has already error reporting enabled at enumeration time - Move Multicast DB netlink handlers to core, allowing devices other then bridge to use them - Allow the page_pool to directly recycle the pages from safely localized NAPI - Implement lockless TX queue stop/wake combo macros, allowing for further code de-duplication and sanitization - Add YNL support for user headers and struct attrs - Add partial YNL specification for devlink - Add partial YNL specification for ethtool - Add tc-mqprio and tc-taprio support for preemptible traffic classes - Add tx push buf len param to ethtool, specifies the maximum number of bytes of a transmitted packet a driver can push directly to the underlying device - Add basic LED support for switch/phy - Add NAPI documentation, stop relaying on external links - Convert dsa_master_ioctl() to netdev notifier. This is a preparatory work to make the hardware timestamping layer selectable by user space - Add transceiver support and improve the error messages for CAN-FD controllers New hardware / drivers: - Ethernet: - AMD/Pensando core device support - MediaTek MT7981 SoC - MediaTek MT7988 SoC - Broadcom BCM53134 embedded switch - Texas Instruments CPSW9G ethernet switch - Qualcomm EMAC3 DWMAC ethernet - StarFive JH7110 SoC - NXP CBTX ethernet PHY - WiFi: - Apple M1 Pro/Max devices - RealTek rtl8710bu/rtl8188gu - RealTek rtl8822bs, rtl8822cs and rtl8821cs SDIO chipset - Bluetooth: - Realtek RTL8821CS, RTL8851B, RTL8852BS - Mediatek MT7663, MT7922 - NXP w8997 - Actions Semi ATS2851 - QTI WCN6855 - Marvell 88W8997 - Can: - STMicroelectronics bxcan stm32f429 Drivers: - Ethernet NICs: - Intel (1G, icg): - add tracking and reporting of QBV config errors - add support for configuring max SDU for each Tx queue - Intel (100G, ice): - refactor mailbox overflow detection to support Scalable IOV - GNSS interface optimization - Intel (i40e): - support XDP multi-buffer - nVidia/Mellanox: - add the support for linux bridge multicast offload - enable TC offload for egress and engress MACVLAN over bond - add support for VxLAN GBP encap/decap flows offload - extend packet offload to fully support libreswan - support tunnel mode in mlx5 IPsec packet offload - extend XDP multi-buffer support - support MACsec VLAN offload - add support for dynamic msix vectors allocation - drop RX page_cache and fully use page_pool - implement thermal zone to report NIC temperature - Netronome/Corigine: - add support for multi-zone conntrack offload - Solarflare/Xilinx: - support offloading TC VLAN push/pop actions to the MAE - support TC decap rules - support unicast PTP - Other NICs: - Broadcom (bnxt): enforce software based freq adjustments only on shared PHC NIC - RealTek (r8169): refactor to addess ASPM issues during NAPI poll - Micrel (lan8841): add support for PTP_PF_PEROUT - Cadence (macb): enable PTP unicast - Engleder (tsnep): add XDP socket zero-copy support - virtio-net: implement exact header length guest feature - veth: add page_pool support for page recycling - vxlan: add MDB data path support - gve: add XDP support for GQI-QPL format - geneve: accept every ethertype - macvlan: allow some packets to bypass broadcast queue - mana: add support for jumbo frame - Ethernet high-speed switches: - Microchip (sparx5): Add support for TC flower templates - Ethernet embedded switches: - Broadcom (b54): - configure 6318 and 63268 RGMII ports - Marvell (mv88e6xxx): - faster C45 bus scan - Microchip: - lan966x: - add support for IS1 VCAP - better TX/RX from/to CPU performances - ksz9477: add ETS Qdisc support - ksz8: enhance static MAC table operations and error handling - sama7g5: add PTP capability - NXP (ocelot): - add support for external ports - add support for preemptible traffic classes - Texas Instruments: - add CPSWxG SGMII support for J7200 and J721E - Intel WiFi (iwlwifi): - preparation for Wi-Fi 7 EHT and multi-link support - EHT (Wi-Fi 7) sniffer support - hardware timestamping support for some devices/firwmares - TX beacon protection on newer hardware - Qualcomm 802.11ax WiFi (ath11k): - MU-MIMO parameters support - ack signal support for management packets - RealTek WiFi (rtw88): - SDIO bus support - better support for some SDIO devices (e.g. MAC address from efuse) - RealTek WiFi (rtw89): - HW scan support for 8852b - better support for 6 GHz scanning - support for various newer firmware APIs - framework firmware backwards compatibility - MediaTek WiFi (mt76): - P2P support - mesh A-MSDU support - EHT (Wi-Fi 7) support - coredump support" * tag 'net-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (2078 commits) net: phy: hide the PHYLIB_LEDS knob net: phy: marvell-88x2222: remove unnecessary (void*) conversions tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp. net: amd: Fix link leak when verifying config failed net: phy: marvell: Fix inconsistent indenting in led_blink_set lan966x: Don't use xdp_frame when action is XDP_TX tsnep: Add XDP socket zero-copy TX support tsnep: Add XDP socket zero-copy RX support tsnep: Move skb receive action to separate function tsnep: Add functions for queue enable/disable tsnep: Rework TX/RX queue initialization tsnep: Replace modulo operation with mask net: phy: dp83867: Add led_brightness_set support net: phy: Fix reading LED reg property drivers: nfc: nfcsim: remove return value check of `dev_dir` net: phy: dp83867: Remove unnecessary (void*) conversions net: ethtool: coalesce: try to make user settings stick twice net: mana: Check if netdev/napi_alloc_frag returns single page net: mana: Rename mana_refill_rxoob and remove some empty lines net: veth: add page_pool stats ...
This commit is contained in:
commit
6e98b09da9
|
@ -418,7 +418,6 @@ That is, the recovery API only requires that:
|
||||||
- drivers/next/e100.c
|
- drivers/next/e100.c
|
||||||
- drivers/net/e1000
|
- drivers/net/e1000
|
||||||
- drivers/net/e1000e
|
- drivers/net/e1000e
|
||||||
- drivers/net/ixgb
|
|
||||||
- drivers/net/ixgbe
|
- drivers/net/ixgbe
|
||||||
- drivers/net/cxgb3
|
- drivers/net/cxgb3
|
||||||
- drivers/net/s2io.c
|
- drivers/net/s2io.c
|
||||||
|
|
|
@ -314,7 +314,7 @@ Q: What is the compatibility story for special BPF types in map values?
|
||||||
Q: Users are allowed to embed bpf_spin_lock, bpf_timer fields in their BPF map
|
Q: Users are allowed to embed bpf_spin_lock, bpf_timer fields in their BPF map
|
||||||
values (when using BTF support for BPF maps). This allows to use helpers for
|
values (when using BTF support for BPF maps). This allows to use helpers for
|
||||||
such objects on these fields inside map values. Users are also allowed to embed
|
such objects on these fields inside map values. Users are also allowed to embed
|
||||||
pointers to some kernel types (with __kptr and __kptr_ref BTF tags). Will the
|
pointers to some kernel types (with __kptr_untrusted and __kptr BTF tags). Will the
|
||||||
kernel preserve backwards compatibility for these features?
|
kernel preserve backwards compatibility for these features?
|
||||||
|
|
||||||
A: It depends. For bpf_spin_lock, bpf_timer: YES, for kptr and everything else:
|
A: It depends. For bpf_spin_lock, bpf_timer: YES, for kptr and everything else:
|
||||||
|
@ -324,7 +324,7 @@ For struct types that have been added already, like bpf_spin_lock and bpf_timer,
|
||||||
the kernel will preserve backwards compatibility, as they are part of UAPI.
|
the kernel will preserve backwards compatibility, as they are part of UAPI.
|
||||||
|
|
||||||
For kptrs, they are also part of UAPI, but only with respect to the kptr
|
For kptrs, they are also part of UAPI, but only with respect to the kptr
|
||||||
mechanism. The types that you can use with a __kptr and __kptr_ref tagged
|
mechanism. The types that you can use with a __kptr_untrusted and __kptr tagged
|
||||||
pointer in your struct are NOT part of the UAPI contract. The supported types can
|
pointer in your struct are NOT part of the UAPI contract. The supported types can
|
||||||
and will change across kernel releases. However, operations like accessing kptr
|
and will change across kernel releases. However, operations like accessing kptr
|
||||||
fields and bpf_kptr_xchg() helper will continue to be supported across kernel
|
fields and bpf_kptr_xchg() helper will continue to be supported across kernel
|
||||||
|
|
|
@ -128,7 +128,8 @@ into the bpf-next tree will make their way into net-next tree. net and
|
||||||
net-next are both run by David S. Miller. From there, they will go
|
net-next are both run by David S. Miller. From there, they will go
|
||||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||||
process of net and net-next being merged into the mainline tree, see
|
process of net and net-next being merged into the mainline tree, see
|
||||||
the :ref:`netdev-FAQ`
|
the documentation on netdev subsystem at
|
||||||
|
Documentation/process/maintainer-netdev.rst.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -147,7 +148,8 @@ request)::
|
||||||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
||||||
---------------------------------------------------------------------------------
|
---------------------------------------------------------------------------------
|
||||||
|
|
||||||
A: The process is the very same as described in the :ref:`netdev-FAQ`,
|
A: The process is the very same as described in the netdev subsystem
|
||||||
|
documentation at Documentation/process/maintainer-netdev.rst,
|
||||||
so please read up on it. The subject line must indicate whether the
|
so please read up on it. The subject line must indicate whether the
|
||||||
patch is a fix or rather "next-like" content in order to let the
|
patch is a fix or rather "next-like" content in order to let the
|
||||||
maintainers know whether it is targeted at bpf or bpf-next.
|
maintainers know whether it is targeted at bpf or bpf-next.
|
||||||
|
@ -206,8 +208,9 @@ ii) run extensive BPF test suite and
|
||||||
Once the BPF pull request was accepted by David S. Miller, then
|
Once the BPF pull request was accepted by David S. Miller, then
|
||||||
the patches end up in net or net-next tree, respectively, and
|
the patches end up in net or net-next tree, respectively, and
|
||||||
make their way from there further into mainline. Again, see the
|
make their way from there further into mainline. Again, see the
|
||||||
:ref:`netdev-FAQ` for additional information e.g. on how often they are
|
documentation for netdev subsystem at
|
||||||
merged to mainline.
|
Documentation/process/maintainer-netdev.rst for additional information
|
||||||
|
e.g. on how often they are merged to mainline.
|
||||||
|
|
||||||
Q: How long do I need to wait for feedback on my BPF patches?
|
Q: How long do I need to wait for feedback on my BPF patches?
|
||||||
-------------------------------------------------------------
|
-------------------------------------------------------------
|
||||||
|
@ -230,7 +233,8 @@ Q: Are patches applied to bpf-next when the merge window is open?
|
||||||
-----------------------------------------------------------------
|
-----------------------------------------------------------------
|
||||||
A: For the time when the merge window is open, bpf-next will not be
|
A: For the time when the merge window is open, bpf-next will not be
|
||||||
processed. This is roughly analogous to net-next patch processing,
|
processed. This is roughly analogous to net-next patch processing,
|
||||||
so feel free to read up on the :ref:`netdev-FAQ` about further details.
|
so feel free to read up on the netdev docs at
|
||||||
|
Documentation/process/maintainer-netdev.rst about further details.
|
||||||
|
|
||||||
During those two weeks of merge window, we might ask you to resend
|
During those two weeks of merge window, we might ask you to resend
|
||||||
your patch series once bpf-next is open again. Once Linus released
|
your patch series once bpf-next is open again. Once Linus released
|
||||||
|
@ -394,7 +398,8 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
||||||
netdev@vger.kernel.org
|
netdev@vger.kernel.org
|
||||||
|
|
||||||
The process in general is the same as on netdev itself, see also the
|
The process in general is the same as on netdev itself, see also the
|
||||||
:ref:`netdev-FAQ`.
|
the documentation on networking subsystem at
|
||||||
|
Documentation/process/maintainer-netdev.rst.
|
||||||
|
|
||||||
Q: Do you also backport to kernels not currently maintained as stable?
|
Q: Do you also backport to kernels not currently maintained as stable?
|
||||||
----------------------------------------------------------------------
|
----------------------------------------------------------------------
|
||||||
|
@ -410,7 +415,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
|
||||||
What should I do?
|
What should I do?
|
||||||
|
|
||||||
A: The same rules apply as with netdev patch submissions in general, see
|
A: The same rules apply as with netdev patch submissions in general, see
|
||||||
the :ref:`netdev-FAQ`.
|
the netdev docs at Documentation/process/maintainer-netdev.rst.
|
||||||
|
|
||||||
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
||||||
ask the BPF maintainers to queue the patches instead. This can be done
|
ask the BPF maintainers to queue the patches instead. This can be done
|
||||||
|
@ -684,7 +689,6 @@ when:
|
||||||
|
|
||||||
|
|
||||||
.. Links
|
.. Links
|
||||||
.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
|
|
||||||
.. _selftests:
|
.. _selftests:
|
||||||
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
|
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
|
||||||
|
|
||||||
|
|
|
@ -20,6 +20,12 @@ Arithmetic instructions
|
||||||
For CPU versions prior to 3, Clang v7.0 and later can enable ``BPF_ALU`` support with
|
For CPU versions prior to 3, Clang v7.0 and later can enable ``BPF_ALU`` support with
|
||||||
``-Xclang -target-feature -Xclang +alu32``. In CPU version 3, support is automatically included.
|
``-Xclang -target-feature -Xclang +alu32``. In CPU version 3, support is automatically included.
|
||||||
|
|
||||||
|
Jump instructions
|
||||||
|
=================
|
||||||
|
|
||||||
|
If ``-O0`` is used, Clang will generate the ``BPF_CALL | BPF_X | BPF_JMP`` (0x8d)
|
||||||
|
instruction, which is not supported by the Linux kernel verifier.
|
||||||
|
|
||||||
Atomic operations
|
Atomic operations
|
||||||
=================
|
=================
|
||||||
|
|
||||||
|
|
|
@ -51,7 +51,7 @@ For example:
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
struct cpumask_map_value {
|
struct cpumask_map_value {
|
||||||
struct bpf_cpumask __kptr_ref * cpumask;
|
struct bpf_cpumask __kptr * cpumask;
|
||||||
};
|
};
|
||||||
|
|
||||||
struct array_map {
|
struct array_map {
|
||||||
|
@ -117,18 +117,13 @@ For example:
|
||||||
As mentioned and illustrated above, these ``struct bpf_cpumask *`` objects can
|
As mentioned and illustrated above, these ``struct bpf_cpumask *`` objects can
|
||||||
also be stored in a map and used as kptrs. If a ``struct bpf_cpumask *`` is in
|
also be stored in a map and used as kptrs. If a ``struct bpf_cpumask *`` is in
|
||||||
a map, the reference can be removed from the map with bpf_kptr_xchg(), or
|
a map, the reference can be removed from the map with bpf_kptr_xchg(), or
|
||||||
opportunistically acquired with bpf_cpumask_kptr_get():
|
opportunistically acquired using RCU:
|
||||||
|
|
||||||
.. kernel-doc:: kernel/bpf/cpumask.c
|
|
||||||
:identifiers: bpf_cpumask_kptr_get
|
|
||||||
|
|
||||||
Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
|
|
||||||
|
|
||||||
.. code-block:: c
|
.. code-block:: c
|
||||||
|
|
||||||
/* struct containing the struct bpf_cpumask kptr which is stored in the map. */
|
/* struct containing the struct bpf_cpumask kptr which is stored in the map. */
|
||||||
struct cpumasks_kfunc_map_value {
|
struct cpumasks_kfunc_map_value {
|
||||||
struct bpf_cpumask __kptr_ref * bpf_cpumask;
|
struct bpf_cpumask __kptr * bpf_cpumask;
|
||||||
};
|
};
|
||||||
|
|
||||||
/* The map containing struct cpumasks_kfunc_map_value entries. */
|
/* The map containing struct cpumasks_kfunc_map_value entries. */
|
||||||
|
@ -144,7 +139,7 @@ Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
|
||||||
/**
|
/**
|
||||||
* A simple example tracepoint program showing how a
|
* A simple example tracepoint program showing how a
|
||||||
* struct bpf_cpumask * kptr that is stored in a map can
|
* struct bpf_cpumask * kptr that is stored in a map can
|
||||||
* be acquired using the bpf_cpumask_kptr_get() kfunc.
|
* be passed to kfuncs using RCU protection.
|
||||||
*/
|
*/
|
||||||
SEC("tp_btf/cgroup_mkdir")
|
SEC("tp_btf/cgroup_mkdir")
|
||||||
int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path)
|
int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path)
|
||||||
|
@ -158,26 +153,21 @@ Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
|
||||||
if (!v)
|
if (!v)
|
||||||
return -ENOENT;
|
return -ENOENT;
|
||||||
|
|
||||||
|
bpf_rcu_read_lock();
|
||||||
/* Acquire a reference to the bpf_cpumask * kptr that's already stored in the map. */
|
/* Acquire a reference to the bpf_cpumask * kptr that's already stored in the map. */
|
||||||
kptr = bpf_cpumask_kptr_get(&v->cpumask);
|
kptr = v->cpumask;
|
||||||
if (!kptr)
|
if (!kptr) {
|
||||||
/* If no bpf_cpumask was present in the map, it's because
|
/* If no bpf_cpumask was present in the map, it's because
|
||||||
* we're racing with another CPU that removed it with
|
* we're racing with another CPU that removed it with
|
||||||
* bpf_kptr_xchg() between the bpf_map_lookup_elem()
|
* bpf_kptr_xchg() between the bpf_map_lookup_elem()
|
||||||
* above, and our call to bpf_cpumask_kptr_get().
|
* above, and our load of the pointer from the map.
|
||||||
* bpf_cpumask_kptr_get() internally safely handles this
|
|
||||||
* race, and will return NULL if the cpumask is no longer
|
|
||||||
* present in the map by the time we invoke the kfunc.
|
|
||||||
*/
|
*/
|
||||||
|
bpf_rcu_read_unlock();
|
||||||
return -EBUSY;
|
return -EBUSY;
|
||||||
|
}
|
||||||
|
|
||||||
/* Free the reference we just took above. Note that the
|
bpf_cpumask_setall(kptr);
|
||||||
* original struct bpf_cpumask * kptr is still in the map. It will
|
bpf_rcu_read_unlock();
|
||||||
* be freed either at a later time if another context deletes
|
|
||||||
* it from the map, or automatically by the BPF subsystem if
|
|
||||||
* it's still present when the map is destroyed.
|
|
||||||
*/
|
|
||||||
bpf_cpumask_release(kptr);
|
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
|
@ -11,7 +11,8 @@ Documentation conventions
|
||||||
=========================
|
=========================
|
||||||
|
|
||||||
For brevity, this document uses the type notion "u64", "u32", etc.
|
For brevity, this document uses the type notion "u64", "u32", etc.
|
||||||
to mean an unsigned integer whose width is the specified number of bits.
|
to mean an unsigned integer whose width is the specified number of bits,
|
||||||
|
and "s32", etc. to mean a signed integer of the specified number of bits.
|
||||||
|
|
||||||
Registers and calling convention
|
Registers and calling convention
|
||||||
================================
|
================================
|
||||||
|
@ -38,14 +39,11 @@ eBPF has two instruction encodings:
|
||||||
* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
|
* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
|
||||||
constant) value after the basic instruction for a total of 128 bits.
|
constant) value after the basic instruction for a total of 128 bits.
|
||||||
|
|
||||||
The basic instruction encoding is as follows, where MSB and LSB mean the most significant
|
The fields conforming an encoded basic instruction are stored in the
|
||||||
bits and least significant bits, respectively:
|
following order::
|
||||||
|
|
||||||
============= ======= ======= ======= ============
|
opcode:8 src_reg:4 dst_reg:4 offset:16 imm:32 // In little-endian BPF.
|
||||||
32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
|
opcode:8 dst_reg:4 src_reg:4 offset:16 imm:32 // In big-endian BPF.
|
||||||
============= ======= ======= ======= ============
|
|
||||||
imm offset src_reg dst_reg opcode
|
|
||||||
============= ======= ======= ======= ============
|
|
||||||
|
|
||||||
**imm**
|
**imm**
|
||||||
signed integer immediate value
|
signed integer immediate value
|
||||||
|
@ -63,6 +61,18 @@ imm offset src_reg dst_reg opcode
|
||||||
**opcode**
|
**opcode**
|
||||||
operation to perform
|
operation to perform
|
||||||
|
|
||||||
|
Note that the contents of multi-byte fields ('imm' and 'offset') are
|
||||||
|
stored using big-endian byte ordering in big-endian BPF and
|
||||||
|
little-endian byte ordering in little-endian BPF.
|
||||||
|
|
||||||
|
For example::
|
||||||
|
|
||||||
|
opcode offset imm assembly
|
||||||
|
src_reg dst_reg
|
||||||
|
07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little
|
||||||
|
dst_reg src_reg
|
||||||
|
07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big
|
||||||
|
|
||||||
Note that most instructions do not use all of the fields.
|
Note that most instructions do not use all of the fields.
|
||||||
Unused fields shall be cleared to zero.
|
Unused fields shall be cleared to zero.
|
||||||
|
|
||||||
|
@ -72,18 +82,23 @@ The 64 bits following the basic instruction contain a pseudo instruction
|
||||||
using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
|
using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
|
||||||
and imm containing the high 32 bits of the immediate value.
|
and imm containing the high 32 bits of the immediate value.
|
||||||
|
|
||||||
================= ==================
|
This is depicted in the following figure::
|
||||||
64 bits (MSB) 64 bits (LSB)
|
|
||||||
================= ==================
|
basic_instruction
|
||||||
basic instruction pseudo instruction
|
.-----------------------------.
|
||||||
================= ==================
|
| |
|
||||||
|
code:8 regs:8 offset:16 imm:32 unused:32 imm:32
|
||||||
|
| |
|
||||||
|
'--------------'
|
||||||
|
pseudo instruction
|
||||||
|
|
||||||
Thus the 64-bit immediate value is constructed as follows:
|
Thus the 64-bit immediate value is constructed as follows:
|
||||||
|
|
||||||
imm64 = (next_imm << 32) | imm
|
imm64 = (next_imm << 32) | imm
|
||||||
|
|
||||||
where 'next_imm' refers to the imm value of the pseudo instruction
|
where 'next_imm' refers to the imm value of the pseudo instruction
|
||||||
following the basic instruction.
|
following the basic instruction. The unused bytes in the pseudo
|
||||||
|
instruction are reserved and shall be cleared to zero.
|
||||||
|
|
||||||
Instruction classes
|
Instruction classes
|
||||||
-------------------
|
-------------------
|
||||||
|
@ -228,28 +243,58 @@ Jump instructions
|
||||||
otherwise identical operations.
|
otherwise identical operations.
|
||||||
The 'code' field encodes the operation as below:
|
The 'code' field encodes the operation as below:
|
||||||
|
|
||||||
======== ===== ========================= ============
|
======== ===== === =========================================== =========================================
|
||||||
code value description notes
|
code value src description notes
|
||||||
======== ===== ========================= ============
|
======== ===== === =========================================== =========================================
|
||||||
BPF_JA 0x00 PC += off BPF_JMP only
|
BPF_JA 0x0 0x0 PC += offset BPF_JMP only
|
||||||
BPF_JEQ 0x10 PC += off if dst == src
|
BPF_JEQ 0x1 any PC += offset if dst == src
|
||||||
BPF_JGT 0x20 PC += off if dst > src unsigned
|
BPF_JGT 0x2 any PC += offset if dst > src unsigned
|
||||||
BPF_JGE 0x30 PC += off if dst >= src unsigned
|
BPF_JGE 0x3 any PC += offset if dst >= src unsigned
|
||||||
BPF_JSET 0x40 PC += off if dst & src
|
BPF_JSET 0x4 any PC += offset if dst & src
|
||||||
BPF_JNE 0x50 PC += off if dst != src
|
BPF_JNE 0x5 any PC += offset if dst != src
|
||||||
BPF_JSGT 0x60 PC += off if dst > src signed
|
BPF_JSGT 0x6 any PC += offset if dst > src signed
|
||||||
BPF_JSGE 0x70 PC += off if dst >= src signed
|
BPF_JSGE 0x7 any PC += offset if dst >= src signed
|
||||||
BPF_CALL 0x80 function call
|
BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_
|
||||||
BPF_EXIT 0x90 function / program return BPF_JMP only
|
BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_
|
||||||
BPF_JLT 0xa0 PC += off if dst < src unsigned
|
BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_
|
||||||
BPF_JLE 0xb0 PC += off if dst <= src unsigned
|
BPF_EXIT 0x9 0x0 return BPF_JMP only
|
||||||
BPF_JSLT 0xc0 PC += off if dst < src signed
|
BPF_JLT 0xa any PC += offset if dst < src unsigned
|
||||||
BPF_JSLE 0xd0 PC += off if dst <= src signed
|
BPF_JLE 0xb any PC += offset if dst <= src unsigned
|
||||||
======== ===== ========================= ============
|
BPF_JSLT 0xc any PC += offset if dst < src signed
|
||||||
|
BPF_JSLE 0xd any PC += offset if dst <= src signed
|
||||||
|
======== ===== === =========================================== =========================================
|
||||||
|
|
||||||
The eBPF program needs to store the return value into register R0 before doing a
|
The eBPF program needs to store the return value into register R0 before doing a
|
||||||
BPF_EXIT.
|
``BPF_EXIT``.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
``BPF_JSGE | BPF_X | BPF_JMP32`` (0x7e) means::
|
||||||
|
|
||||||
|
if (s32)dst s>= (s32)src goto +offset
|
||||||
|
|
||||||
|
where 's>=' indicates a signed '>=' comparison.
|
||||||
|
|
||||||
|
Helper functions
|
||||||
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Helper functions are a concept whereby BPF programs can call into a
|
||||||
|
set of function calls exposed by the underlying platform.
|
||||||
|
|
||||||
|
Historically, each helper function was identified by an address
|
||||||
|
encoded in the imm field. The available helper functions may differ
|
||||||
|
for each program type, but address values are unique across all program types.
|
||||||
|
|
||||||
|
Platforms that support the BPF Type Format (BTF) support identifying
|
||||||
|
a helper function by a BTF ID encoded in the imm field, where the BTF ID
|
||||||
|
identifies the helper name and type.
|
||||||
|
|
||||||
|
Program-local functions
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
Program-local functions are functions exposed by the same BPF program as the
|
||||||
|
caller, and are referenced by offset from the call instruction, similar to
|
||||||
|
``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to
|
||||||
|
the caller.
|
||||||
|
|
||||||
Load and store instructions
|
Load and store instructions
|
||||||
===========================
|
===========================
|
||||||
|
@ -371,14 +416,56 @@ and loaded back to ``R0``.
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
|
Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
|
||||||
encoding for an extra imm64 value.
|
encoding defined in `Instruction encoding`_, and use the 'src' field of the
|
||||||
|
basic instruction to hold an opcode subtype.
|
||||||
|
|
||||||
There is currently only one such instruction.
|
The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions
|
||||||
|
with opcode subtypes in the 'src' field, using new terms such as "map"
|
||||||
|
defined further below:
|
||||||
|
|
||||||
``BPF_LD | BPF_DW | BPF_IMM`` means::
|
========================= ====== === ========================================= =========== ==============
|
||||||
|
opcode construction opcode src pseudocode imm type dst type
|
||||||
|
========================= ====== === ========================================= =========== ==============
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
|
||||||
|
========================= ====== === ========================================= =========== ==============
|
||||||
|
|
||||||
dst = imm64
|
where
|
||||||
|
|
||||||
|
* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_)
|
||||||
|
* map_by_idx(imm) means to convert a 32-bit index into an address of a map
|
||||||
|
* map_val(map) gets the address of the first value in a given map
|
||||||
|
* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id
|
||||||
|
* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions
|
||||||
|
* the 'imm type' can be used by disassemblers for display
|
||||||
|
* the 'dst type' can be used for verification and JIT compilation purposes
|
||||||
|
|
||||||
|
Maps
|
||||||
|
~~~~
|
||||||
|
|
||||||
|
Maps are shared memory regions accessible by eBPF programs on some platforms.
|
||||||
|
A map can have various semantics as defined in a separate document, and may or
|
||||||
|
may not have a single contiguous memory region, but the 'map_val(map)' is
|
||||||
|
currently only defined for maps that do have a single contiguous memory region.
|
||||||
|
|
||||||
|
Each map can have a file descriptor (fd) if supported by the platform, where
|
||||||
|
'map_by_fd(imm)' means to get the map with the specified file descriptor. Each
|
||||||
|
BPF program can also be defined to use a set of maps associated with the
|
||||||
|
program at load time, and 'map_by_idx(imm)' means to get the map with the given
|
||||||
|
index in the set associated with the BPF program containing the instruction.
|
||||||
|
|
||||||
|
Platform Variables
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Platform variables are memory regions, identified by integer ids, exposed by
|
||||||
|
the runtime and accessible by BPF programs on some platforms. The
|
||||||
|
'var_addr(imm)' operation means to get the address of the memory region
|
||||||
|
identified by the given id.
|
||||||
|
|
||||||
Legacy BPF Packet access instructions
|
Legacy BPF Packet access instructions
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
|
|
|
@ -100,6 +100,23 @@ Hence, whenever a constant scalar argument is accepted by a kfunc which is not a
|
||||||
size parameter, and the value of the constant matters for program safety, __k
|
size parameter, and the value of the constant matters for program safety, __k
|
||||||
suffix should be used.
|
suffix should be used.
|
||||||
|
|
||||||
|
2.2.2 __uninit Annotation
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
This annotation is used to indicate that the argument will be treated as
|
||||||
|
uninitialized.
|
||||||
|
|
||||||
|
An example is given below::
|
||||||
|
|
||||||
|
__bpf_kfunc int bpf_dynptr_from_skb(..., struct bpf_dynptr_kern *ptr__uninit)
|
||||||
|
{
|
||||||
|
...
|
||||||
|
}
|
||||||
|
|
||||||
|
Here, the dynptr will be treated as an uninitialized dynptr. Without this
|
||||||
|
annotation, the verifier will reject the program if the dynptr passed in is
|
||||||
|
not initialized.
|
||||||
|
|
||||||
.. _BPF_kfunc_nodef:
|
.. _BPF_kfunc_nodef:
|
||||||
|
|
||||||
2.3 Using an existing kernel function
|
2.3 Using an existing kernel function
|
||||||
|
@ -162,20 +179,12 @@ both are orthogonal to each other.
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
|
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
|
||||||
passed in to it. There can be only one referenced pointer that can be passed in.
|
passed in to it. There can be only one referenced pointer that can be passed
|
||||||
All copies of the pointer being released are invalidated as a result of invoking
|
in. All copies of the pointer being released are invalidated as a result of
|
||||||
kfunc with this flag.
|
invoking kfunc with this flag. KF_RELEASE kfuncs automatically receive the
|
||||||
|
protection afforded by the KF_TRUSTED_ARGS flag described below.
|
||||||
|
|
||||||
2.4.4 KF_KPTR_GET flag
|
2.4.4 KF_TRUSTED_ARGS flag
|
||||||
----------------------
|
|
||||||
|
|
||||||
The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument
|
|
||||||
as a pointer to kptr, safely increments the refcount of the object it points to,
|
|
||||||
and returns a reference to the user. The rest of the arguments may be normal
|
|
||||||
arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with
|
|
||||||
KF_ACQUIRE and KF_RET_NULL flags.
|
|
||||||
|
|
||||||
2.4.5 KF_TRUSTED_ARGS flag
|
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
|
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
|
||||||
|
@ -187,7 +196,7 @@ exception described below).
|
||||||
There are two types of pointers to kernel objects which are considered "valid":
|
There are two types of pointers to kernel objects which are considered "valid":
|
||||||
|
|
||||||
1. Pointers which are passed as tracepoint or struct_ops callback arguments.
|
1. Pointers which are passed as tracepoint or struct_ops callback arguments.
|
||||||
2. Pointers which were returned from a KF_ACQUIRE or KF_KPTR_GET kfunc.
|
2. Pointers which were returned from a KF_ACQUIRE kfunc.
|
||||||
|
|
||||||
Pointers to non-BTF objects (e.g. scalar pointers) may also be passed to
|
Pointers to non-BTF objects (e.g. scalar pointers) may also be passed to
|
||||||
KF_TRUSTED_ARGS kfuncs, and may have a non-zero offset.
|
KF_TRUSTED_ARGS kfuncs, and may have a non-zero offset.
|
||||||
|
@ -214,13 +223,13 @@ In other words, you must:
|
||||||
2. Specify the type and name of the trusted nested field. This field must match
|
2. Specify the type and name of the trusted nested field. This field must match
|
||||||
the field in the original type definition exactly.
|
the field in the original type definition exactly.
|
||||||
|
|
||||||
2.4.6 KF_SLEEPABLE flag
|
2.4.5 KF_SLEEPABLE flag
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
The KF_SLEEPABLE flag is used for kfuncs that may sleep. Such kfuncs can only
|
The KF_SLEEPABLE flag is used for kfuncs that may sleep. Such kfuncs can only
|
||||||
be called by sleepable BPF programs (BPF_F_SLEEPABLE).
|
be called by sleepable BPF programs (BPF_F_SLEEPABLE).
|
||||||
|
|
||||||
2.4.7 KF_DESTRUCTIVE flag
|
2.4.6 KF_DESTRUCTIVE flag
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
||||||
The KF_DESTRUCTIVE flag is used to indicate functions calling which is
|
The KF_DESTRUCTIVE flag is used to indicate functions calling which is
|
||||||
|
@ -229,18 +238,20 @@ rebooting or panicking. Due to this additional restrictions apply to these
|
||||||
calls. At the moment they only require CAP_SYS_BOOT capability, but more can be
|
calls. At the moment they only require CAP_SYS_BOOT capability, but more can be
|
||||||
added later.
|
added later.
|
||||||
|
|
||||||
2.4.8 KF_RCU flag
|
2.4.7 KF_RCU flag
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
The KF_RCU flag is used for kfuncs which have a rcu ptr as its argument.
|
The KF_RCU flag is a weaker version of KF_TRUSTED_ARGS. The kfuncs marked with
|
||||||
When used together with KF_ACQUIRE, it indicates the kfunc should have a
|
KF_RCU expect either PTR_TRUSTED or MEM_RCU arguments. The verifier guarantees
|
||||||
single argument which must be a trusted argument or a MEM_RCU pointer.
|
that the objects are valid and there is no use-after-free. The pointers are not
|
||||||
The argument may have reference count of 0 and the kfunc must take this
|
NULL, but the object's refcount could have reached zero. The kfuncs need to
|
||||||
into consideration.
|
consider doing refcnt != 0 check, especially when returning a KF_ACQUIRE
|
||||||
|
pointer. Note as well that a KF_ACQUIRE kfunc that is KF_RCU should very likely
|
||||||
|
also be KF_RET_NULL.
|
||||||
|
|
||||||
.. _KF_deprecated_flag:
|
.. _KF_deprecated_flag:
|
||||||
|
|
||||||
2.4.9 KF_DEPRECATED flag
|
2.4.8 KF_DEPRECATED flag
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
|
The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
|
||||||
|
@ -451,13 +462,50 @@ struct_ops callback arg. For example:
|
||||||
struct task_struct *acquired;
|
struct task_struct *acquired;
|
||||||
|
|
||||||
acquired = bpf_task_acquire(task);
|
acquired = bpf_task_acquire(task);
|
||||||
|
if (acquired)
|
||||||
|
/*
|
||||||
|
* In a typical program you'd do something like store
|
||||||
|
* the task in a map, and the map will automatically
|
||||||
|
* release it later. Here, we release it manually.
|
||||||
|
*/
|
||||||
|
bpf_task_release(acquired);
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
References acquired on ``struct task_struct *`` objects are RCU protected.
|
||||||
|
Therefore, when in an RCU read region, you can obtain a pointer to a task
|
||||||
|
embedded in a map value without having to acquire a reference:
|
||||||
|
|
||||||
|
.. code-block:: c
|
||||||
|
|
||||||
|
#define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
|
||||||
|
private(TASK) static struct task_struct *global;
|
||||||
|
|
||||||
|
/**
|
||||||
|
* A trivial example showing how to access a task stored
|
||||||
|
* in a map using RCU.
|
||||||
|
*/
|
||||||
|
SEC("tp_btf/task_newtask")
|
||||||
|
int BPF_PROG(task_rcu_read_example, struct task_struct *task, u64 clone_flags)
|
||||||
|
{
|
||||||
|
struct task_struct *local_copy;
|
||||||
|
|
||||||
|
bpf_rcu_read_lock();
|
||||||
|
local_copy = global;
|
||||||
|
if (local_copy)
|
||||||
|
/*
|
||||||
|
* We could also pass local_copy to kfuncs or helper functions here,
|
||||||
|
* as we're guaranteed that local_copy will be valid until we exit
|
||||||
|
* the RCU read region below.
|
||||||
|
*/
|
||||||
|
bpf_printk("Global task %s is valid", local_copy->comm);
|
||||||
|
else
|
||||||
|
bpf_printk("No global task found");
|
||||||
|
bpf_rcu_read_unlock();
|
||||||
|
|
||||||
|
/* At this point we can no longer reference local_copy. */
|
||||||
|
|
||||||
/*
|
|
||||||
* In a typical program you'd do something like store
|
|
||||||
* the task in a map, and the map will automatically
|
|
||||||
* release it later. Here, we release it manually.
|
|
||||||
*/
|
|
||||||
bpf_task_release(acquired);
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -515,81 +563,17 @@ bpf_task_release() respectively, so we won't provide examples for them.
|
||||||
|
|
||||||
----
|
----
|
||||||
|
|
||||||
You may also acquire a reference to a ``struct cgroup`` kptr that's already
|
Other kfuncs available for interacting with ``struct cgroup *`` objects are
|
||||||
stored in a map using bpf_cgroup_kptr_get():
|
bpf_cgroup_ancestor() and bpf_cgroup_from_id(), allowing callers to access
|
||||||
|
the ancestor of a cgroup and find a cgroup by its ID, respectively. Both
|
||||||
.. kernel-doc:: kernel/bpf/helpers.c
|
return a cgroup kptr.
|
||||||
:identifiers: bpf_cgroup_kptr_get
|
|
||||||
|
|
||||||
Here's an example of how it can be used:
|
|
||||||
|
|
||||||
.. code-block:: c
|
|
||||||
|
|
||||||
/* struct containing the struct task_struct kptr which is actually stored in the map. */
|
|
||||||
struct __cgroups_kfunc_map_value {
|
|
||||||
struct cgroup __kptr_ref * cgroup;
|
|
||||||
};
|
|
||||||
|
|
||||||
/* The map containing struct __cgroups_kfunc_map_value entries. */
|
|
||||||
struct {
|
|
||||||
__uint(type, BPF_MAP_TYPE_HASH);
|
|
||||||
__type(key, int);
|
|
||||||
__type(value, struct __cgroups_kfunc_map_value);
|
|
||||||
__uint(max_entries, 1);
|
|
||||||
} __cgroups_kfunc_map SEC(".maps");
|
|
||||||
|
|
||||||
/* ... */
|
|
||||||
|
|
||||||
/**
|
|
||||||
* A simple example tracepoint program showing how a
|
|
||||||
* struct cgroup kptr that is stored in a map can
|
|
||||||
* be acquired using the bpf_cgroup_kptr_get() kfunc.
|
|
||||||
*/
|
|
||||||
SEC("tp_btf/cgroup_mkdir")
|
|
||||||
int BPF_PROG(cgroup_kptr_get_example, struct cgroup *cgrp, const char *path)
|
|
||||||
{
|
|
||||||
struct cgroup *kptr;
|
|
||||||
struct __cgroups_kfunc_map_value *v;
|
|
||||||
s32 id = cgrp->self.id;
|
|
||||||
|
|
||||||
/* Assume a cgroup kptr was previously stored in the map. */
|
|
||||||
v = bpf_map_lookup_elem(&__cgroups_kfunc_map, &id);
|
|
||||||
if (!v)
|
|
||||||
return -ENOENT;
|
|
||||||
|
|
||||||
/* Acquire a reference to the cgroup kptr that's already stored in the map. */
|
|
||||||
kptr = bpf_cgroup_kptr_get(&v->cgroup);
|
|
||||||
if (!kptr)
|
|
||||||
/* If no cgroup was present in the map, it's because
|
|
||||||
* we're racing with another CPU that removed it with
|
|
||||||
* bpf_kptr_xchg() between the bpf_map_lookup_elem()
|
|
||||||
* above, and our call to bpf_cgroup_kptr_get().
|
|
||||||
* bpf_cgroup_kptr_get() internally safely handles this
|
|
||||||
* race, and will return NULL if the task is no longer
|
|
||||||
* present in the map by the time we invoke the kfunc.
|
|
||||||
*/
|
|
||||||
return -EBUSY;
|
|
||||||
|
|
||||||
/* Free the reference we just took above. Note that the
|
|
||||||
* original struct cgroup kptr is still in the map. It will
|
|
||||||
* be freed either at a later time if another context deletes
|
|
||||||
* it from the map, or automatically by the BPF subsystem if
|
|
||||||
* it's still present when the map is destroyed.
|
|
||||||
*/
|
|
||||||
bpf_cgroup_release(kptr);
|
|
||||||
|
|
||||||
return 0;
|
|
||||||
}
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
Another kfunc available for interacting with ``struct cgroup *`` objects is
|
|
||||||
bpf_cgroup_ancestor(). This allows callers to access the ancestor of a cgroup,
|
|
||||||
and return it as a cgroup kptr.
|
|
||||||
|
|
||||||
.. kernel-doc:: kernel/bpf/helpers.c
|
.. kernel-doc:: kernel/bpf/helpers.c
|
||||||
:identifiers: bpf_cgroup_ancestor
|
:identifiers: bpf_cgroup_ancestor
|
||||||
|
|
||||||
|
.. kernel-doc:: kernel/bpf/helpers.c
|
||||||
|
:identifiers: bpf_cgroup_from_id
|
||||||
|
|
||||||
Eventually, BPF should be updated to allow this to happen with a normal memory
|
Eventually, BPF should be updated to allow this to happen with a normal memory
|
||||||
load in the program itself. This is currently not possible without more work in
|
load in the program itself. This is currently not possible without more work in
|
||||||
the verifier. bpf_cgroup_ancestor() can be used as follows:
|
the verifier. bpf_cgroup_ancestor() can be used as follows:
|
||||||
|
|
|
@ -2,23 +2,32 @@
|
||||||
|
|
||||||
.. _libbpf:
|
.. _libbpf:
|
||||||
|
|
||||||
|
======
|
||||||
libbpf
|
libbpf
|
||||||
======
|
======
|
||||||
|
|
||||||
|
If you are looking to develop BPF applications using the libbpf library, this
|
||||||
|
directory contains important documentation that you should read.
|
||||||
|
|
||||||
|
To get started, it is recommended to begin with the :doc:`libbpf Overview
|
||||||
|
<libbpf_overview>` document, which provides a high-level understanding of the
|
||||||
|
libbpf APIs and their usage. This will give you a solid foundation to start
|
||||||
|
exploring and utilizing the various features of libbpf to develop your BPF
|
||||||
|
applications.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|
||||||
|
libbpf_overview
|
||||||
API Documentation <https://libbpf.readthedocs.io/en/latest/api.html>
|
API Documentation <https://libbpf.readthedocs.io/en/latest/api.html>
|
||||||
program_types
|
program_types
|
||||||
libbpf_naming_convention
|
libbpf_naming_convention
|
||||||
libbpf_build
|
libbpf_build
|
||||||
|
|
||||||
This is documentation for libbpf, a userspace library for loading and
|
|
||||||
interacting with bpf programs.
|
|
||||||
|
|
||||||
All general BPF questions, including kernel functionality, libbpf APIs and
|
All general BPF questions, including kernel functionality, libbpf APIs and their
|
||||||
their application, should be sent to bpf@vger.kernel.org mailing list.
|
application, should be sent to bpf@vger.kernel.org mailing list. You can
|
||||||
You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the
|
`subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the mailing list
|
||||||
mailing list search its `archive <https://lore.kernel.org/bpf/>`_.
|
search its `archive <https://lore.kernel.org/bpf/>`_. Please search the archive
|
||||||
Please search the archive before asking new questions. It very well might
|
before asking new questions. It may be that this was already addressed or
|
||||||
be that this was already addressed or answered before.
|
answered before.
|
||||||
|
|
228
Documentation/bpf/libbpf/libbpf_overview.rst
Normal file
228
Documentation/bpf/libbpf/libbpf_overview.rst
Normal file
|
@ -0,0 +1,228 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0
|
||||||
|
|
||||||
|
===============
|
||||||
|
libbpf Overview
|
||||||
|
===============
|
||||||
|
|
||||||
|
libbpf is a C-based library containing a BPF loader that takes compiled BPF
|
||||||
|
object files and prepares and loads them into the Linux kernel. libbpf takes the
|
||||||
|
heavy lifting of loading, verifying, and attaching BPF programs to various
|
||||||
|
kernel hooks, allowing BPF application developers to focus only on BPF program
|
||||||
|
correctness and performance.
|
||||||
|
|
||||||
|
The following are the high-level features supported by libbpf:
|
||||||
|
|
||||||
|
* Provides high-level and low-level APIs for user space programs to interact
|
||||||
|
with BPF programs. The low-level APIs wrap all the bpf system call
|
||||||
|
functionality, which is useful when users need more fine-grained control
|
||||||
|
over the interactions between user space and BPF programs.
|
||||||
|
* Provides overall support for the BPF object skeleton generated by bpftool.
|
||||||
|
The skeleton file simplifies the process for the user space programs to access
|
||||||
|
global variables and work with BPF programs.
|
||||||
|
* Provides BPF-side APIS, including BPF helper definitions, BPF maps support,
|
||||||
|
and tracing helpers, allowing developers to simplify BPF code writing.
|
||||||
|
* Supports BPF CO-RE mechanism, enabling BPF developers to write portable
|
||||||
|
BPF programs that can be compiled once and run across different kernel
|
||||||
|
versions.
|
||||||
|
|
||||||
|
This document will delve into the above concepts in detail, providing a deeper
|
||||||
|
understanding of the capabilities and advantages of libbpf and how it can help
|
||||||
|
you develop BPF applications efficiently.
|
||||||
|
|
||||||
|
BPF App Lifecycle and libbpf APIs
|
||||||
|
==================================
|
||||||
|
|
||||||
|
A BPF application consists of one or more BPF programs (either cooperating or
|
||||||
|
completely independent), BPF maps, and global variables. The global
|
||||||
|
variables are shared between all BPF programs, which allows them to cooperate on
|
||||||
|
a common set of data. libbpf provides APIs that user space programs can use to
|
||||||
|
manipulate the BPF programs by triggering different phases of a BPF application
|
||||||
|
lifecycle.
|
||||||
|
|
||||||
|
The following section provides a brief overview of each phase in the BPF life
|
||||||
|
cycle:
|
||||||
|
|
||||||
|
* **Open phase**: In this phase, libbpf parses the BPF
|
||||||
|
object file and discovers BPF maps, BPF programs, and global variables. After
|
||||||
|
a BPF app is opened, user space apps can make additional adjustments
|
||||||
|
(setting BPF program types, if necessary; pre-setting initial values for
|
||||||
|
global variables, etc.) before all the entities are created and loaded.
|
||||||
|
|
||||||
|
* **Load phase**: In the load phase, libbpf creates BPF
|
||||||
|
maps, resolves various relocations, and verifies and loads BPF programs into
|
||||||
|
the kernel. At this point, libbpf validates all the parts of a BPF application
|
||||||
|
and loads the BPF program into the kernel, but no BPF program has yet been
|
||||||
|
executed. After the load phase, it’s possible to set up the initial BPF map
|
||||||
|
state without racing with the BPF program code execution.
|
||||||
|
|
||||||
|
* **Attachment phase**: In this phase, libbpf
|
||||||
|
attaches BPF programs to various BPF hook points (e.g., tracepoints, kprobes,
|
||||||
|
cgroup hooks, network packet processing pipeline, etc.). During this
|
||||||
|
phase, BPF programs perform useful work such as processing
|
||||||
|
packets, or updating BPF maps and global variables that can be read from user
|
||||||
|
space.
|
||||||
|
|
||||||
|
* **Tear down phase**: In the tear down phase,
|
||||||
|
libbpf detaches BPF programs and unloads them from the kernel. BPF maps are
|
||||||
|
destroyed, and all the resources used by the BPF app are freed.
|
||||||
|
|
||||||
|
BPF Object Skeleton File
|
||||||
|
========================
|
||||||
|
|
||||||
|
BPF skeleton is an alternative interface to libbpf APIs for working with BPF
|
||||||
|
objects. Skeleton code abstract away generic libbpf APIs to significantly
|
||||||
|
simplify code for manipulating BPF programs from user space. Skeleton code
|
||||||
|
includes a bytecode representation of the BPF object file, simplifying the
|
||||||
|
process of distributing your BPF code. With BPF bytecode embedded, there are no
|
||||||
|
extra files to deploy along with your application binary.
|
||||||
|
|
||||||
|
You can generate the skeleton header file ``(.skel.h)`` for a specific object
|
||||||
|
file by passing the BPF object to the bpftool. The generated BPF skeleton
|
||||||
|
provides the following custom functions that correspond to the BPF lifecycle,
|
||||||
|
each of them prefixed with the specific object name:
|
||||||
|
|
||||||
|
* ``<name>__open()`` – creates and opens BPF application (``<name>`` stands for
|
||||||
|
the specific bpf object name)
|
||||||
|
* ``<name>__load()`` – instantiates, loads,and verifies BPF application parts
|
||||||
|
* ``<name>__attach()`` – attaches all auto-attachable BPF programs (it’s
|
||||||
|
optional, you can have more control by using libbpf APIs directly)
|
||||||
|
* ``<name>__destroy()`` – detaches all BPF programs and
|
||||||
|
frees up all used resources
|
||||||
|
|
||||||
|
Using the skeleton code is the recommended way to work with bpf programs. Keep
|
||||||
|
in mind, BPF skeleton provides access to the underlying BPF object, so whatever
|
||||||
|
was possible to do with generic libbpf APIs is still possible even when the BPF
|
||||||
|
skeleton is used. It's an additive convenience feature, with no syscalls, and no
|
||||||
|
cumbersome code.
|
||||||
|
|
||||||
|
Other Advantages of Using Skeleton File
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
* BPF skeleton provides an interface for user space programs to work with BPF
|
||||||
|
global variables. The skeleton code memory maps global variables as a struct
|
||||||
|
into user space. The struct interface allows user space programs to initialize
|
||||||
|
BPF programs before the BPF load phase and fetch and update data from user
|
||||||
|
space afterward.
|
||||||
|
|
||||||
|
* The ``skel.h`` file reflects the object file structure by listing out the
|
||||||
|
available maps, programs, etc. BPF skeleton provides direct access to all the
|
||||||
|
BPF maps and BPF programs as struct fields. This eliminates the need for
|
||||||
|
string-based lookups with ``bpf_object_find_map_by_name()`` and
|
||||||
|
``bpf_object_find_program_by_name()`` APIs, reducing errors due to BPF source
|
||||||
|
code and user-space code getting out of sync.
|
||||||
|
|
||||||
|
* The embedded bytecode representation of the object file ensures that the
|
||||||
|
skeleton and the BPF object file are always in sync.
|
||||||
|
|
||||||
|
BPF Helpers
|
||||||
|
===========
|
||||||
|
|
||||||
|
libbpf provides BPF-side APIs that BPF programs can use to interact with the
|
||||||
|
system. The BPF helpers definition allows developers to use them in BPF code as
|
||||||
|
any other plain C function. For example, there are helper functions to print
|
||||||
|
debugging messages, get the time since the system was booted, interact with BPF
|
||||||
|
maps, manipulate network packets, etc.
|
||||||
|
|
||||||
|
For a complete description of what the helpers do, the arguments they take, and
|
||||||
|
the return value, see the `bpf-helpers
|
||||||
|
<https://man7.org/linux/man-pages/man7/bpf-helpers.7.html>`_ man page.
|
||||||
|
|
||||||
|
BPF CO-RE (Compile Once – Run Everywhere)
|
||||||
|
=========================================
|
||||||
|
|
||||||
|
BPF programs work in the kernel space and have access to kernel memory and data
|
||||||
|
structures. One limitation that BPF applications come across is the lack of
|
||||||
|
portability across different kernel versions and configurations. `BCC
|
||||||
|
<https://github.com/iovisor/bcc/>`_ is one of the solutions for BPF
|
||||||
|
portability. However, it comes with runtime overhead and a large binary size
|
||||||
|
from embedding the compiler with the application.
|
||||||
|
|
||||||
|
libbpf steps up the BPF program portability by supporting the BPF CO-RE concept.
|
||||||
|
BPF CO-RE brings together BTF type information, libbpf, and the compiler to
|
||||||
|
produce a single executable binary that you can run on multiple kernel versions
|
||||||
|
and configurations.
|
||||||
|
|
||||||
|
To make BPF programs portable libbpf relies on the BTF type information of the
|
||||||
|
running kernel. Kernel also exposes this self-describing authoritative BTF
|
||||||
|
information through ``sysfs`` at ``/sys/kernel/btf/vmlinux``.
|
||||||
|
|
||||||
|
You can generate the BTF information for the running kernel with the following
|
||||||
|
command:
|
||||||
|
|
||||||
|
::
|
||||||
|
|
||||||
|
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
|
||||||
|
|
||||||
|
The command generates a ``vmlinux.h`` header file with all kernel types
|
||||||
|
(:doc:`BTF types <../btf>`) that the running kernel uses. Including
|
||||||
|
``vmlinux.h`` in your BPF program eliminates dependency on system-wide kernel
|
||||||
|
headers.
|
||||||
|
|
||||||
|
libbpf enables portability of BPF programs by looking at the BPF program’s
|
||||||
|
recorded BTF type and relocation information and matching them to BTF
|
||||||
|
information (vmlinux) provided by the running kernel. libbpf then resolves and
|
||||||
|
matches all the types and fields, and updates necessary offsets and other
|
||||||
|
relocatable data to ensure that BPF program’s logic functions correctly for a
|
||||||
|
specific kernel on the host. BPF CO-RE concept thus eliminates overhead
|
||||||
|
associated with BPF development and allows developers to write portable BPF
|
||||||
|
applications without modifications and runtime source code compilation on the
|
||||||
|
target machine.
|
||||||
|
|
||||||
|
The following code snippet shows how to read the parent field of a kernel
|
||||||
|
``task_struct`` using BPF CO-RE and libbf. The basic helper to read a field in a
|
||||||
|
CO-RE relocatable manner is ``bpf_core_read(dst, sz, src)``, which will read
|
||||||
|
``sz`` bytes from the field referenced by ``src`` into the memory pointed to by
|
||||||
|
``dst``.
|
||||||
|
|
||||||
|
.. code-block:: C
|
||||||
|
:emphasize-lines: 6
|
||||||
|
|
||||||
|
//...
|
||||||
|
struct task_struct *task = (void *)bpf_get_current_task();
|
||||||
|
struct task_struct *parent_task;
|
||||||
|
int err;
|
||||||
|
|
||||||
|
err = bpf_core_read(&parent_task, sizeof(void *), &task->parent);
|
||||||
|
if (err) {
|
||||||
|
/* handle error */
|
||||||
|
}
|
||||||
|
|
||||||
|
/* parent_task contains the value of task->parent pointer */
|
||||||
|
|
||||||
|
In the code snippet, we first get a pointer to the current ``task_struct`` using
|
||||||
|
``bpf_get_current_task()``. We then use ``bpf_core_read()`` to read the parent
|
||||||
|
field of task struct into the ``parent_task`` variable. ``bpf_core_read()`` is
|
||||||
|
just like ``bpf_probe_read_kernel()`` BPF helper, except it records information
|
||||||
|
about the field that should be relocated on the target kernel. i.e, if the
|
||||||
|
``parent`` field gets shifted to a different offset within
|
||||||
|
``struct task_struct`` due to some new field added in front of it, libbpf will
|
||||||
|
automatically adjust the actual offset to the proper value.
|
||||||
|
|
||||||
|
Getting Started with libbpf
|
||||||
|
===========================
|
||||||
|
|
||||||
|
Check out the `libbpf-bootstrap <https://github.com/libbpf/libbpf-bootstrap>`_
|
||||||
|
repository with simple examples of using libbpf to build various BPF
|
||||||
|
applications.
|
||||||
|
|
||||||
|
See also `libbpf API documentation
|
||||||
|
<https://libbpf.readthedocs.io/en/latest/api.html>`_.
|
||||||
|
|
||||||
|
libbpf and Rust
|
||||||
|
===============
|
||||||
|
|
||||||
|
If you are building BPF applications in Rust, it is recommended to use the
|
||||||
|
`Libbpf-rs <https://github.com/libbpf/libbpf-rs>`_ library instead of bindgen
|
||||||
|
bindings directly to libbpf. Libbpf-rs wraps libbpf functionality in
|
||||||
|
Rust-idiomatic interfaces and provides libbpf-cargo plugin to handle BPF code
|
||||||
|
compilation and skeleton generation. Using Libbpf-rs will make building user
|
||||||
|
space part of the BPF application easier. Note that the BPF program themselves
|
||||||
|
must still be written in plain C.
|
||||||
|
|
||||||
|
Additional Documentation
|
||||||
|
========================
|
||||||
|
|
||||||
|
* `Program types and ELF Sections <https://libbpf.readthedocs.io/en/latest/program_types.html>`_
|
||||||
|
* `API naming convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html>`_
|
||||||
|
* `Building libbpf <https://libbpf.readthedocs.io/en/latest/libbpf_build.html>`_
|
||||||
|
* `API documentation Convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html#api-documentation-convention>`_
|
|
@ -12,6 +12,36 @@ Byte swap instructions
|
||||||
|
|
||||||
``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
|
``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
|
||||||
|
|
||||||
|
Jump instructions
|
||||||
|
=================
|
||||||
|
|
||||||
|
``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function
|
||||||
|
integer would be read from a specified register, is not currently supported
|
||||||
|
by the verifier. Any programs with this instruction will fail to load
|
||||||
|
until such support is added.
|
||||||
|
|
||||||
|
Maps
|
||||||
|
====
|
||||||
|
|
||||||
|
Linux only supports the 'map_val(map)' operation on array maps with a single element.
|
||||||
|
|
||||||
|
Linux uses an fd_array to store maps associated with a BPF program. Thus,
|
||||||
|
map_by_idx(imm) uses the fd at that index in the array.
|
||||||
|
|
||||||
|
Variables
|
||||||
|
=========
|
||||||
|
|
||||||
|
The following 64-bit immediate instruction specifies that a variable address,
|
||||||
|
which corresponds to some integer stored in the 'imm' field, should be loaded:
|
||||||
|
|
||||||
|
========================= ====== === ========================================= =========== ==============
|
||||||
|
opcode construction opcode src pseudocode imm type dst type
|
||||||
|
========================= ====== === ========================================= =========== ==============
|
||||||
|
BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
|
||||||
|
========================= ====== === ========================================= =========== ==============
|
||||||
|
|
||||||
|
On Linux, this integer is a BTF ID.
|
||||||
|
|
||||||
Legacy BPF Packet access instructions
|
Legacy BPF Packet access instructions
|
||||||
=====================================
|
=====================================
|
||||||
|
|
||||||
|
|
|
@ -11,9 +11,9 @@ maps are accessed from BPF programs via BPF helpers which are documented in the
|
||||||
`man-pages`_ for `bpf-helpers(7)`_.
|
`man-pages`_ for `bpf-helpers(7)`_.
|
||||||
|
|
||||||
BPF maps are accessed from user space via the ``bpf`` syscall, which provides
|
BPF maps are accessed from user space via the ``bpf`` syscall, which provides
|
||||||
commands to create maps, lookup elements, update elements and delete
|
commands to create maps, lookup elements, update elements and delete elements.
|
||||||
elements. More details of the BPF syscall are available in
|
More details of the BPF syscall are available in `ebpf-syscall`_ and in the
|
||||||
:doc:`/userspace-api/ebpf/syscall` and in the `man-pages`_ for `bpf(2)`_.
|
`man-pages`_ for `bpf(2)`_.
|
||||||
|
|
||||||
Map Types
|
Map Types
|
||||||
=========
|
=========
|
||||||
|
@ -79,3 +79,4 @@ Find and delete element by key in a given map using ``attr->map_fd``,
|
||||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||||
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
|
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
|
||||||
.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
|
.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
|
||||||
|
.. _ebpf-syscall: https://docs.kernel.org/userspace-api/ebpf/syscall.html
|
||||||
|
|
|
@ -20,6 +20,7 @@ properties:
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
- mediatek,mt7622-wed
|
- mediatek,mt7622-wed
|
||||||
|
- mediatek,mt7981-wed
|
||||||
- mediatek,mt7986-wed
|
- mediatek,mt7986-wed
|
||||||
- const: syscon
|
- const: syscon
|
||||||
|
|
||||||
|
|
|
@ -1,27 +0,0 @@
|
||||||
MediaTek SGMIISYS controller
|
|
||||||
============================
|
|
||||||
|
|
||||||
The MediaTek SGMIISYS controller provides various clocks to the system.
|
|
||||||
|
|
||||||
Required Properties:
|
|
||||||
|
|
||||||
- compatible: Should be:
|
|
||||||
- "mediatek,mt7622-sgmiisys", "syscon"
|
|
||||||
- "mediatek,mt7629-sgmiisys", "syscon"
|
|
||||||
- "mediatek,mt7981-sgmiisys_0", "syscon"
|
|
||||||
- "mediatek,mt7981-sgmiisys_1", "syscon"
|
|
||||||
- "mediatek,mt7986-sgmiisys_0", "syscon"
|
|
||||||
- "mediatek,mt7986-sgmiisys_1", "syscon"
|
|
||||||
- #clock-cells: Must be 1
|
|
||||||
|
|
||||||
The SGMIISYS controller uses the common clk binding from
|
|
||||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
|
||||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
sgmiisys: sgmiisys@1b128000 {
|
|
||||||
compatible = "mediatek,mt7622-sgmiisys", "syscon";
|
|
||||||
reg = <0 0x1b128000 0 0x1000>;
|
|
||||||
#clock-cells = <1>;
|
|
||||||
};
|
|
|
@ -20,6 +20,7 @@ properties:
|
||||||
- st,stm32-syscfg
|
- st,stm32-syscfg
|
||||||
- st,stm32-power-config
|
- st,stm32-power-config
|
||||||
- st,stm32-tamp
|
- st,stm32-tamp
|
||||||
|
- st,stm32f4-gcan
|
||||||
- const: syscon
|
- const: syscon
|
||||||
- items:
|
- items:
|
||||||
- const: st,stm32-tamp
|
- const: st,stm32-tamp
|
||||||
|
@ -42,6 +43,7 @@ if:
|
||||||
contains:
|
contains:
|
||||||
enum:
|
enum:
|
||||||
- st,stm32mp157-syscfg
|
- st,stm32mp157-syscfg
|
||||||
|
- st,stm32f4-gcan
|
||||||
then:
|
then:
|
||||||
required:
|
required:
|
||||||
- clocks
|
- clocks
|
||||||
|
|
|
@ -16,7 +16,7 @@ description: |
|
||||||
operation modes at 10/100 Mb/s data transfer rates.
|
operation modes at 10/100 Mb/s data transfer rates.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
title: Allwinner A10 EMAC Ethernet Controller
|
title: Allwinner A10 EMAC Ethernet Controller
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Chen-Yu Tsai <wens@csie.org>
|
- Chen-Yu Tsai <wens@csie.org>
|
||||||
|
|
|
@ -11,7 +11,7 @@ maintainers:
|
||||||
- Maxime Ripard <mripard@kernel.org>
|
- Maxime Ripard <mripard@kernel.org>
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
# Select every compatible, including the deprecated ones. This way, we
|
# Select every compatible, including the deprecated ones. This way, we
|
||||||
# will be able to report a warning when we have that compatible, since
|
# will be able to report a warning when we have that compatible, since
|
||||||
|
|
|
@ -66,7 +66,7 @@ required:
|
||||||
- tx-fifo-depth
|
- tx-fifo-depth
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -2,8 +2,8 @@
|
||||||
# Copyright 2019 BayLibre, SAS
|
# Copyright 2019 BayLibre, SAS
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
|
$id: http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Amlogic Meson DWMAC Ethernet controller
|
title: Amlogic Meson DWMAC Ethernet controller
|
||||||
|
|
||||||
|
|
|
@ -15,7 +15,7 @@ description: |+
|
||||||
MAC.
|
MAC.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -0,0 +1,45 @@
|
||||||
|
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/bluetooth/nxp,88w8987-bt.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: NXP Bluetooth chips
|
||||||
|
|
||||||
|
description:
|
||||||
|
This binding describes UART-attached NXP bluetooth chips. These chips
|
||||||
|
are dual-radio chips supporting WiFi and Bluetooth. The bluetooth
|
||||||
|
works on standard H4 protocol over 4-wire UART. The RTS and CTS lines
|
||||||
|
are used during FW download. To enable power save mode, the host
|
||||||
|
asserts break signal over UART-TX line to put the chip into power save
|
||||||
|
state. De-asserting break wakes up the BT chip.
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- nxp,88w8987-bt
|
||||||
|
- nxp,88w8997-bt
|
||||||
|
|
||||||
|
fw-init-baudrate:
|
||||||
|
description:
|
||||||
|
Chip baudrate after FW is downloaded and initialized.
|
||||||
|
This property depends on the module vendor's
|
||||||
|
configuration. If this property is not specified,
|
||||||
|
115200 is set as default.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
serial {
|
||||||
|
bluetooth {
|
||||||
|
compatible = "nxp,88w8987-bt";
|
||||||
|
fw-init-baudrate = <3000000>;
|
||||||
|
};
|
||||||
|
};
|
|
@ -23,6 +23,7 @@ properties:
|
||||||
- qcom,wcn3998-bt
|
- qcom,wcn3998-bt
|
||||||
- qcom,qca6390-bt
|
- qcom,qca6390-bt
|
||||||
- qcom,wcn6750-bt
|
- qcom,wcn6750-bt
|
||||||
|
- qcom,wcn6855-bt
|
||||||
|
|
||||||
enable-gpios:
|
enable-gpios:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
@ -133,6 +134,22 @@ allOf:
|
||||||
- vddrfa1p7-supply
|
- vddrfa1p7-supply
|
||||||
- vddrfa1p2-supply
|
- vddrfa1p2-supply
|
||||||
- vddasd-supply
|
- vddasd-supply
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
enum:
|
||||||
|
- qcom,wcn6855-bt
|
||||||
|
then:
|
||||||
|
required:
|
||||||
|
- enable-gpios
|
||||||
|
- swctrl-gpios
|
||||||
|
- vddio-supply
|
||||||
|
- vddbtcxmx-supply
|
||||||
|
- vddrfacmn-supply
|
||||||
|
- vddrfa0p8-supply
|
||||||
|
- vddrfa1p2-supply
|
||||||
|
- vddrfa1p7-supply
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
- |
|
- |
|
||||||
|
|
|
@ -10,7 +10,7 @@ maintainers:
|
||||||
- Florian Fainelli <f.fainelli@gmail.com>
|
- Florian Fainelli <f.fainelli@gmail.com>
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -66,7 +66,7 @@ required:
|
||||||
- phy-mode
|
- phy-mode
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
unevaluatedProperties: false
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
|
|
@ -121,7 +121,7 @@ required:
|
||||||
- compatible
|
- compatible
|
||||||
|
|
||||||
dependencies:
|
dependencies:
|
||||||
brcm,requires-autobaud-mode: [ 'shutdown-gpios' ]
|
brcm,requires-autobaud-mode: [ shutdown-gpios ]
|
||||||
|
|
||||||
if:
|
if:
|
||||||
not:
|
not:
|
||||||
|
|
|
@ -63,6 +63,9 @@ properties:
|
||||||
boot loader. This property should only be used the used operating system
|
boot loader. This property should only be used the used operating system
|
||||||
doesn't support the clocks and clock-names property.
|
doesn't support the clocks and clock-names property.
|
||||||
|
|
||||||
|
power-domains:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
xceiver-supply:
|
xceiver-supply:
|
||||||
description: Regulator that powers the CAN transceiver.
|
description: Regulator that powers the CAN transceiver.
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,85 @@
|
||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/can/st,stm32-bxcan.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: STMicroelectronics bxCAN controller
|
||||||
|
|
||||||
|
description: STMicroelectronics BxCAN controller for CAN bus
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Dario Binacchi <dario.binacchi@amarulasolutions.com>
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: can-controller.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- st,stm32f4-bxcan
|
||||||
|
|
||||||
|
st,can-primary:
|
||||||
|
description:
|
||||||
|
Primary and secondary mode of the bxCAN peripheral is only relevant
|
||||||
|
if the chip has two CAN peripherals. In that case they share some
|
||||||
|
of the required logic.
|
||||||
|
To avoid misunderstandings, it should be noted that ST documentation
|
||||||
|
uses the terms master/slave instead of primary/secondary.
|
||||||
|
type: boolean
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
interrupts:
|
||||||
|
items:
|
||||||
|
- description: transmit interrupt
|
||||||
|
- description: FIFO 0 receive interrupt
|
||||||
|
- description: FIFO 1 receive interrupt
|
||||||
|
- description: status change error interrupt
|
||||||
|
|
||||||
|
interrupt-names:
|
||||||
|
items:
|
||||||
|
- const: tx
|
||||||
|
- const: rx0
|
||||||
|
- const: rx1
|
||||||
|
- const: sce
|
||||||
|
|
||||||
|
resets:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
st,gcan:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
|
description:
|
||||||
|
The phandle to the gcan node which allows to access the 512-bytes
|
||||||
|
SRAM memory shared by the two bxCAN cells (CAN1 primary and CAN2
|
||||||
|
secondary) in dual CAN peripheral configuration.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- interrupts
|
||||||
|
- resets
|
||||||
|
- clocks
|
||||||
|
- st,gcan
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/clock/stm32fx-clock.h>
|
||||||
|
#include <dt-bindings/mfd/stm32f4-rcc.h>
|
||||||
|
|
||||||
|
can1: can@40006400 {
|
||||||
|
compatible = "st,stm32f4-bxcan";
|
||||||
|
reg = <0x40006400 0x200>;
|
||||||
|
interrupts = <19>, <20>, <21>, <22>;
|
||||||
|
interrupt-names = "tx", "rx0", "rx1", "sce";
|
||||||
|
resets = <&rcc STM32F4_APB1_RESET(CAN1)>;
|
||||||
|
clocks = <&rcc 0 STM32F4_APB1_CLOCK(CAN1)>;
|
||||||
|
st,can-primary;
|
||||||
|
st,gcan = <&gcan>;
|
||||||
|
};
|
|
@ -35,15 +35,15 @@ properties:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
tx-fifo-depth:
|
tx-fifo-depth:
|
||||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
description: CAN Tx fifo depth (Zynq, Axi CAN).
|
description: CAN Tx fifo depth (Zynq, Axi CAN).
|
||||||
|
|
||||||
rx-fifo-depth:
|
rx-fifo-depth:
|
||||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode)
|
description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode)
|
||||||
|
|
||||||
tx-mailbox-count:
|
tx-mailbox-count:
|
||||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
description: CAN Tx mailbox buffer count (CAN FD)
|
description: CAN Tx mailbox buffer count (CAN FD)
|
||||||
|
|
||||||
required:
|
required:
|
||||||
|
|
|
@ -19,6 +19,7 @@ properties:
|
||||||
- const: brcm,bcm53115
|
- const: brcm,bcm53115
|
||||||
- const: brcm,bcm53125
|
- const: brcm,bcm53125
|
||||||
- const: brcm,bcm53128
|
- const: brcm,bcm53128
|
||||||
|
- const: brcm,bcm53134
|
||||||
- const: brcm,bcm5365
|
- const: brcm,bcm5365
|
||||||
- const: brcm,bcm5395
|
- const: brcm,bcm5395
|
||||||
- const: brcm,bcm5389
|
- const: brcm,bcm5389
|
||||||
|
@ -57,8 +58,11 @@ properties:
|
||||||
- items:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
- brcm,bcm3384-switch
|
- brcm,bcm3384-switch
|
||||||
|
- brcm,bcm6318-switch
|
||||||
- brcm,bcm6328-switch
|
- brcm,bcm6328-switch
|
||||||
|
- brcm,bcm6362-switch
|
||||||
- brcm,bcm6368-switch
|
- brcm,bcm6368-switch
|
||||||
|
- brcm,bcm63268-switch
|
||||||
- const: brcm,bcm63xx-switch
|
- const: brcm,bcm63xx-switch
|
||||||
|
|
||||||
required:
|
required:
|
||||||
|
|
|
@ -76,12 +76,6 @@ properties:
|
||||||
supports reporting the number of packets in-flight in a switch queue
|
supports reporting the number of packets in-flight in a switch queue
|
||||||
type: boolean
|
type: boolean
|
||||||
|
|
||||||
"#address-cells":
|
|
||||||
const: 1
|
|
||||||
|
|
||||||
"#size-cells":
|
|
||||||
const: 0
|
|
||||||
|
|
||||||
ports:
|
ports:
|
||||||
type: object
|
type: object
|
||||||
|
|
||||||
|
@ -99,11 +93,9 @@ properties:
|
||||||
required:
|
required:
|
||||||
- reg
|
- reg
|
||||||
- interrupts
|
- interrupts
|
||||||
- "#address-cells"
|
|
||||||
- "#size-cells"
|
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "dsa.yaml#"
|
- $ref: dsa.yaml#
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -145,8 +137,6 @@ examples:
|
||||||
- |
|
- |
|
||||||
switch@f0b00000 {
|
switch@f0b00000 {
|
||||||
compatible = "brcm,bcm7445-switch-v4.0";
|
compatible = "brcm,bcm7445-switch-v4.0";
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
reg = <0xf0b00000 0x40000>,
|
reg = <0xf0b00000 0x40000>,
|
||||||
<0xf0b40000 0x110>,
|
<0xf0b40000 0x110>,
|
||||||
<0xf0b40340 0x30>,
|
<0xf0b40340 0x30>,
|
||||||
|
|
|
@ -11,16 +11,23 @@ maintainers:
|
||||||
- Landen Chao <Landen.Chao@mediatek.com>
|
- Landen Chao <Landen.Chao@mediatek.com>
|
||||||
- DENG Qingfang <dqfext@gmail.com>
|
- DENG Qingfang <dqfext@gmail.com>
|
||||||
- Sean Wang <sean.wang@mediatek.com>
|
- Sean Wang <sean.wang@mediatek.com>
|
||||||
|
- Daniel Golle <daniel@makrotopia.org>
|
||||||
|
|
||||||
description: |
|
description: |
|
||||||
There are two versions of MT7530, standalone and in a multi-chip module.
|
There are three versions of MT7530, standalone, in a multi-chip module and
|
||||||
|
built-into a SoC.
|
||||||
|
|
||||||
MT7530 is a part of the multi-chip module in MT7620AN, MT7620DA, MT7620DAN,
|
MT7530 is a part of the multi-chip module in MT7620AN, MT7620DA, MT7620DAN,
|
||||||
MT7620NN, MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs.
|
MT7620NN, MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs.
|
||||||
|
|
||||||
|
The MT7988 SoC comes with a built-in switch similar to MT7531 as well as four
|
||||||
|
Gigabit Ethernet PHYs. The switch registers are directly mapped into the SoC's
|
||||||
|
memory map rather than using MDIO. The switch got an internally connected 10G
|
||||||
|
CPU port and 4 user ports connected to the built-in Gigabit Ethernet PHYs.
|
||||||
|
|
||||||
MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs
|
MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs
|
||||||
and the switch registers are directly mapped into SoC's memory map rather than
|
and the switch registers are directly mapped into SoC's memory map rather than
|
||||||
using MDIO. The DSA driver currently doesn't support this.
|
using MDIO. The DSA driver currently doesn't support MT7620 variants.
|
||||||
|
|
||||||
There is only the standalone version of MT7531.
|
There is only the standalone version of MT7531.
|
||||||
|
|
||||||
|
@ -81,6 +88,10 @@ properties:
|
||||||
Multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs
|
Multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs
|
||||||
const: mediatek,mt7621
|
const: mediatek,mt7621
|
||||||
|
|
||||||
|
- description:
|
||||||
|
Built-in switch of the MT7988 SoC
|
||||||
|
const: mediatek,mt7988-switch
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
|
@ -93,7 +104,7 @@ properties:
|
||||||
|
|
||||||
gpio-controller:
|
gpio-controller:
|
||||||
type: boolean
|
type: boolean
|
||||||
description:
|
description: |
|
||||||
If defined, LED controller of the MT7530 switch will run on GPIO mode.
|
If defined, LED controller of the MT7530 switch will run on GPIO mode.
|
||||||
|
|
||||||
There are 15 controllable pins.
|
There are 15 controllable pins.
|
||||||
|
@ -112,7 +123,7 @@ properties:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
io-supply:
|
io-supply:
|
||||||
description:
|
description: |
|
||||||
Phandle to the regulator node necessary for the I/O power.
|
Phandle to the regulator node necessary for the I/O power.
|
||||||
See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt for
|
See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt for
|
||||||
details for the regulator setup on these boards.
|
details for the regulator setup on these boards.
|
||||||
|
@ -124,7 +135,7 @@ properties:
|
||||||
switch is a part of the multi-chip module.
|
switch is a part of the multi-chip module.
|
||||||
|
|
||||||
reset-gpios:
|
reset-gpios:
|
||||||
description:
|
description: |
|
||||||
GPIO to reset the switch. Use this if mediatek,mcm is not used.
|
GPIO to reset the switch. Use this if mediatek,mcm is not used.
|
||||||
This property is optional because some boards share the reset line with
|
This property is optional because some boards share the reset line with
|
||||||
other components which makes it impossible to probe the switch if the
|
other components which makes it impossible to probe the switch if the
|
||||||
|
@ -268,6 +279,17 @@ allOf:
|
||||||
required:
|
required:
|
||||||
- mediatek,mcm
|
- mediatek,mcm
|
||||||
|
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
const: mediatek,mt7988-switch
|
||||||
|
then:
|
||||||
|
$ref: "#/$defs/mt7530-dsa-port"
|
||||||
|
properties:
|
||||||
|
gpio-controller: false
|
||||||
|
mediatek,mcm: false
|
||||||
|
reset-names: false
|
||||||
|
|
||||||
unevaluatedProperties: false
|
unevaluatedProperties: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
|
|
|
@ -18,6 +18,8 @@ description:
|
||||||
PHY it is connected to. In this config, an internal mdio-bus is registered and
|
PHY it is connected to. In this config, an internal mdio-bus is registered and
|
||||||
the MDIO master is used for communication. Mixed external and internal
|
the MDIO master is used for communication. Mixed external and internal
|
||||||
mdio-bus configurations are not supported by the hardware.
|
mdio-bus configurations are not supported by the hardware.
|
||||||
|
Each phy has at most 3 LEDs connected and can be declared
|
||||||
|
using the standard LEDs structure.
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -66,7 +68,7 @@ properties:
|
||||||
With the legacy mapping the reg corresponding to the internal
|
With the legacy mapping the reg corresponding to the internal
|
||||||
mdio is the switch reg with an offset of -1.
|
mdio is the switch reg with an offset of -1.
|
||||||
|
|
||||||
$ref: "dsa.yaml#"
|
$ref: dsa.yaml#
|
||||||
|
|
||||||
patternProperties:
|
patternProperties:
|
||||||
"^(ethernet-)?ports$":
|
"^(ethernet-)?ports$":
|
||||||
|
@ -117,6 +119,7 @@ unevaluatedProperties: false
|
||||||
examples:
|
examples:
|
||||||
- |
|
- |
|
||||||
#include <dt-bindings/gpio/gpio.h>
|
#include <dt-bindings/gpio/gpio.h>
|
||||||
|
#include <dt-bindings/leds/common.h>
|
||||||
|
|
||||||
mdio {
|
mdio {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
|
@ -226,6 +229,25 @@ examples:
|
||||||
label = "lan1";
|
label = "lan1";
|
||||||
phy-mode = "internal";
|
phy-mode = "internal";
|
||||||
phy-handle = <&internal_phy_port1>;
|
phy-handle = <&internal_phy_port1>;
|
||||||
|
|
||||||
|
leds {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
led@0 {
|
||||||
|
reg = <0>;
|
||||||
|
color = <LED_COLOR_ID_WHITE>;
|
||||||
|
function = LED_FUNCTION_LAN;
|
||||||
|
default-state = "keep";
|
||||||
|
};
|
||||||
|
|
||||||
|
led@1 {
|
||||||
|
reg = <1>;
|
||||||
|
color = <LED_COLOR_ID_AMBER>;
|
||||||
|
function = LED_FUNCTION_LAN;
|
||||||
|
default-state = "keep";
|
||||||
|
};
|
||||||
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
port@2 {
|
port@2 {
|
||||||
|
|
|
@ -62,7 +62,7 @@ properties:
|
||||||
|
|
||||||
mdio:
|
mdio:
|
||||||
type: object
|
type: object
|
||||||
$ref: "mdio.yaml#"
|
$ref: mdio.yaml#
|
||||||
description: optional node for embedded MDIO controller
|
description: optional node for embedded MDIO controller
|
||||||
|
|
||||||
required:
|
required:
|
||||||
|
|
|
@ -205,7 +205,7 @@ properties:
|
||||||
duplex is assumed.
|
duplex is assumed.
|
||||||
|
|
||||||
pause:
|
pause:
|
||||||
$ref: /schemas/types.yaml#definitions/flag
|
$ref: /schemas/types.yaml#/definitions/flag
|
||||||
description:
|
description:
|
||||||
Indicates that pause should be enabled.
|
Indicates that pause should be enabled.
|
||||||
|
|
||||||
|
@ -222,6 +222,41 @@ properties:
|
||||||
required:
|
required:
|
||||||
- speed
|
- speed
|
||||||
|
|
||||||
|
leds:
|
||||||
|
description:
|
||||||
|
Describes the LEDs associated by Ethernet Controller.
|
||||||
|
These LEDs are not integrated in the PHY and PHY doesn't have any
|
||||||
|
control on them. Ethernet Controller regs are used to control
|
||||||
|
these defined LEDs.
|
||||||
|
|
||||||
|
type: object
|
||||||
|
|
||||||
|
properties:
|
||||||
|
'#address-cells':
|
||||||
|
const: 1
|
||||||
|
|
||||||
|
'#size-cells':
|
||||||
|
const: 0
|
||||||
|
|
||||||
|
patternProperties:
|
||||||
|
'^led@[a-f0-9]+$':
|
||||||
|
$ref: /schemas/leds/common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
description:
|
||||||
|
This define the LED index in the PHY or the MAC. It's really
|
||||||
|
driver dependent and required for ports that define multiple
|
||||||
|
LED for the same port.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- reg
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
dependencies:
|
dependencies:
|
||||||
pcs-handle-names: [pcs-handle]
|
pcs-handle-names: [pcs-handle]
|
||||||
|
|
||||||
|
|
|
@ -83,7 +83,7 @@ properties:
|
||||||
0: Disable 2.4 Vpp operating mode.
|
0: Disable 2.4 Vpp operating mode.
|
||||||
1: Request 2.4 Vpp operating mode from link partner.
|
1: Request 2.4 Vpp operating mode from link partner.
|
||||||
Absence of this property will leave configuration to default values.
|
Absence of this property will leave configuration to default values.
|
||||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
enum: [0, 1]
|
enum: [0, 1]
|
||||||
|
|
||||||
broken-turn-around:
|
broken-turn-around:
|
||||||
|
@ -197,6 +197,35 @@ properties:
|
||||||
PHY's that have configurable TX internal delays. If this property is
|
PHY's that have configurable TX internal delays. If this property is
|
||||||
present then the PHY applies the TX delay.
|
present then the PHY applies the TX delay.
|
||||||
|
|
||||||
|
leds:
|
||||||
|
type: object
|
||||||
|
|
||||||
|
properties:
|
||||||
|
'#address-cells':
|
||||||
|
const: 1
|
||||||
|
|
||||||
|
'#size-cells':
|
||||||
|
const: 0
|
||||||
|
|
||||||
|
patternProperties:
|
||||||
|
'^led@[a-f0-9]+$':
|
||||||
|
$ref: /schemas/leds/common.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
description:
|
||||||
|
This define the LED index in the PHY or the MAC. It's really
|
||||||
|
driver dependent and required for ports that define multiple
|
||||||
|
LED for the same port.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- reg
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- reg
|
- reg
|
||||||
|
|
||||||
|
@ -204,6 +233,8 @@ additionalProperties: true
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
- |
|
- |
|
||||||
|
#include <dt-bindings/leds/common.h>
|
||||||
|
|
||||||
ethernet {
|
ethernet {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <0>;
|
#size-cells = <0>;
|
||||||
|
@ -219,5 +250,17 @@ examples:
|
||||||
reset-gpios = <&gpio1 4 1>;
|
reset-gpios = <&gpio1 4 1>;
|
||||||
reset-assert-us = <1000>;
|
reset-assert-us = <1000>;
|
||||||
reset-deassert-us = <2000>;
|
reset-deassert-us = <2000>;
|
||||||
|
|
||||||
|
leds {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
led@0 {
|
||||||
|
reg = <0>;
|
||||||
|
color = <LED_COLOR_ID_WHITE>;
|
||||||
|
function = LED_FUNCTION_LAN;
|
||||||
|
default-state = "keep";
|
||||||
|
};
|
||||||
|
};
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
|
@ -40,6 +40,10 @@ patternProperties:
|
||||||
type: object
|
type: object
|
||||||
description: Ethernet switch ports
|
description: Ethernet switch ports
|
||||||
|
|
||||||
|
required:
|
||||||
|
- "#address-cells"
|
||||||
|
- "#size-cells"
|
||||||
|
|
||||||
oneOf:
|
oneOf:
|
||||||
- required:
|
- required:
|
||||||
- ports
|
- ports
|
||||||
|
@ -51,7 +55,7 @@ additionalProperties: true
|
||||||
$defs:
|
$defs:
|
||||||
base:
|
base:
|
||||||
description: An ethernet switch without any extra port properties
|
description: An ethernet switch without any extra port properties
|
||||||
$ref: '#/'
|
$ref: '#'
|
||||||
|
|
||||||
patternProperties:
|
patternProperties:
|
||||||
"^(ethernet-)?port@[0-9]+$":
|
"^(ethernet-)?port@[0-9]+$":
|
||||||
|
|
|
@ -144,6 +144,9 @@ properties:
|
||||||
description:
|
description:
|
||||||
Regulator that powers the Ethernet PHY.
|
Regulator that powers the Ethernet PHY.
|
||||||
|
|
||||||
|
power-domains:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
fsl,num-tx-queues:
|
fsl,num-tx-queues:
|
||||||
$ref: /schemas/types.yaml#/definitions/uint32
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
description:
|
description:
|
||||||
|
|
|
@ -14,7 +14,7 @@ description:
|
||||||
located under the 'dpmacs' node for the fsl-mc bus DTS node.
|
located under the 'dpmacs' node for the fsl-mc bus DTS node.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -2,8 +2,8 @@
|
||||||
# Copyright 2018 Linaro Ltd.
|
# Copyright 2018 Linaro Ltd.
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml#"
|
$id: http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Intel IXP46x PTP Timer (TSYNC)
|
title: Intel IXP46x PTP Timer (TSYNC)
|
||||||
|
|
||||||
|
|
|
@ -2,13 +2,13 @@
|
||||||
# Copyright 2018 Linaro Ltd.
|
# Copyright 2018 Linaro Ltd.
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml#"
|
$id: http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Intel IXP4xx ethernet
|
title: Intel IXP4xx ethernet
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Linus Walleij <linus.walleij@linaro.org>
|
- Linus Walleij <linus.walleij@linaro.org>
|
||||||
|
@ -28,7 +28,7 @@ properties:
|
||||||
description: Ethernet MMIO address range
|
description: Ethernet MMIO address range
|
||||||
|
|
||||||
queue-rx:
|
queue-rx:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the RX queue node
|
- description: phandle to the RX queue node
|
||||||
|
@ -36,7 +36,7 @@ properties:
|
||||||
description: phandle to the RX queue on the NPE
|
description: phandle to the RX queue on the NPE
|
||||||
|
|
||||||
queue-txready:
|
queue-txready:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the TX READY queue node
|
- description: phandle to the TX READY queue node
|
||||||
|
@ -48,7 +48,7 @@ properties:
|
||||||
phy-handle: true
|
phy-handle: true
|
||||||
|
|
||||||
intel,npe-handle:
|
intel,npe-handle:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the NPE this ethernet instance is using
|
- description: phandle to the NPE this ethernet instance is using
|
||||||
|
|
|
@ -2,8 +2,8 @@
|
||||||
# Copyright 2021 Linaro Ltd.
|
# Copyright 2021 Linaro Ltd.
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml#"
|
$id: http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Intel IXP4xx V.35 WAN High Speed Serial Link (HSS)
|
title: Intel IXP4xx V.35 WAN High Speed Serial Link (HSS)
|
||||||
|
|
||||||
|
@ -24,7 +24,7 @@ properties:
|
||||||
description: The HSS instance
|
description: The HSS instance
|
||||||
|
|
||||||
intel,npe-handle:
|
intel,npe-handle:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
items:
|
items:
|
||||||
- description: phandle to the NPE this HSS instance is using
|
- description: phandle to the NPE this HSS instance is using
|
||||||
|
@ -33,7 +33,7 @@ properties:
|
||||||
and the instance to use in the second cell
|
and the instance to use in the second cell
|
||||||
|
|
||||||
intel,queue-chl-rxtrig:
|
intel,queue-chl-rxtrig:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the RX trigger queue on the NPE
|
- description: phandle to the RX trigger queue on the NPE
|
||||||
|
@ -41,7 +41,7 @@ properties:
|
||||||
description: phandle to the RX trigger queue on the NPE
|
description: phandle to the RX trigger queue on the NPE
|
||||||
|
|
||||||
intel,queue-chl-txready:
|
intel,queue-chl-txready:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the TX ready queue on the NPE
|
- description: phandle to the TX ready queue on the NPE
|
||||||
|
@ -49,7 +49,7 @@ properties:
|
||||||
description: phandle to the TX ready queue on the NPE
|
description: phandle to the TX ready queue on the NPE
|
||||||
|
|
||||||
intel,queue-pkt-rx:
|
intel,queue-pkt-rx:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the RX queue on the NPE
|
- description: phandle to the RX queue on the NPE
|
||||||
|
@ -57,7 +57,7 @@ properties:
|
||||||
description: phandle to the packet RX queue on the NPE
|
description: phandle to the packet RX queue on the NPE
|
||||||
|
|
||||||
intel,queue-pkt-tx:
|
intel,queue-pkt-tx:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
maxItems: 4
|
maxItems: 4
|
||||||
items:
|
items:
|
||||||
items:
|
items:
|
||||||
|
@ -66,7 +66,7 @@ properties:
|
||||||
description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE
|
description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE
|
||||||
|
|
||||||
intel,queue-pkt-rxfree:
|
intel,queue-pkt-rxfree:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
maxItems: 4
|
maxItems: 4
|
||||||
items:
|
items:
|
||||||
items:
|
items:
|
||||||
|
@ -76,7 +76,7 @@ properties:
|
||||||
RXFREE3 queues on the NPE
|
RXFREE3 queues on the NPE
|
||||||
|
|
||||||
intel,queue-pkt-txdone:
|
intel,queue-pkt-txdone:
|
||||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the TXDONE queue on the NPE
|
- description: phandle to the TXDONE queue on the NPE
|
||||||
|
|
|
@ -20,7 +20,7 @@ description: |+
|
||||||
definition.
|
definition.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/marvell-bluetooth.yaml#"
|
$id: http://devicetree.org/schemas/net/marvell-bluetooth.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Marvell Bluetooth chips
|
title: Marvell Bluetooth chips
|
||||||
|
|
||||||
|
@ -15,11 +15,29 @@ maintainers:
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
const: mrvl,88w8897
|
enum:
|
||||||
|
- mrvl,88w8897
|
||||||
|
- mrvl,88w8997
|
||||||
|
|
||||||
|
max-speed:
|
||||||
|
description: see Documentation/devicetree/bindings/serial/serial.yaml
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- compatible
|
- compatible
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
const: mrvl,88w8997
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
max-speed: true
|
||||||
|
else:
|
||||||
|
properties:
|
||||||
|
max-speed: false
|
||||||
|
|
||||||
additionalProperties: false
|
additionalProperties: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
|
|
|
@ -12,7 +12,7 @@ maintainers:
|
||||||
- Russell King <linux@armlinux.org.uk>
|
- Russell King <linux@armlinux.org.uk>
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -21,6 +21,7 @@ properties:
|
||||||
- mediatek,mt7623-eth
|
- mediatek,mt7623-eth
|
||||||
- mediatek,mt7622-eth
|
- mediatek,mt7622-eth
|
||||||
- mediatek,mt7629-eth
|
- mediatek,mt7629-eth
|
||||||
|
- mediatek,mt7981-eth
|
||||||
- mediatek,mt7986-eth
|
- mediatek,mt7986-eth
|
||||||
- ralink,rt5350-eth
|
- ralink,rt5350-eth
|
||||||
|
|
||||||
|
@ -78,6 +79,11 @@ properties:
|
||||||
description:
|
description:
|
||||||
List of phandles to wireless ethernet dispatch nodes.
|
List of phandles to wireless ethernet dispatch nodes.
|
||||||
|
|
||||||
|
mediatek,wed-pcie:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/phandle
|
||||||
|
description:
|
||||||
|
Phandle to the mediatek wed-pcie controller.
|
||||||
|
|
||||||
dma-coherent: true
|
dma-coherent: true
|
||||||
|
|
||||||
mdio-bus:
|
mdio-bus:
|
||||||
|
@ -91,7 +97,7 @@ properties:
|
||||||
const: 0
|
const: 0
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -123,6 +129,8 @@ allOf:
|
||||||
|
|
||||||
mediatek,wed: false
|
mediatek,wed: false
|
||||||
|
|
||||||
|
mediatek,wed-pcie: false
|
||||||
|
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -160,6 +168,8 @@ allOf:
|
||||||
description:
|
description:
|
||||||
Phandle to the mediatek pcie-mirror controller.
|
Phandle to the mediatek pcie-mirror controller.
|
||||||
|
|
||||||
|
mediatek,wed-pcie: false
|
||||||
|
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -206,6 +216,44 @@ allOf:
|
||||||
|
|
||||||
mediatek,wed: false
|
mediatek,wed: false
|
||||||
|
|
||||||
|
mediatek,wed-pcie: false
|
||||||
|
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
const: mediatek,mt7981-eth
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
interrupts:
|
||||||
|
minItems: 4
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
minItems: 15
|
||||||
|
maxItems: 15
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
items:
|
||||||
|
- const: fe
|
||||||
|
- const: gp2
|
||||||
|
- const: gp1
|
||||||
|
- const: wocpu0
|
||||||
|
- const: sgmii_ck
|
||||||
|
- const: sgmii_tx250m
|
||||||
|
- const: sgmii_rx250m
|
||||||
|
- const: sgmii_cdr_ref
|
||||||
|
- const: sgmii_cdr_fb
|
||||||
|
- const: sgmii2_tx250m
|
||||||
|
- const: sgmii2_rx250m
|
||||||
|
- const: sgmii2_cdr_ref
|
||||||
|
- const: sgmii2_cdr_fb
|
||||||
|
- const: netsys0
|
||||||
|
- const: netsys1
|
||||||
|
|
||||||
|
mediatek,sgmiisys:
|
||||||
|
minItems: 2
|
||||||
|
maxItems: 2
|
||||||
|
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -242,11 +290,6 @@ allOf:
|
||||||
minItems: 2
|
minItems: 2
|
||||||
maxItems: 2
|
maxItems: 2
|
||||||
|
|
||||||
mediatek,wed-pcie:
|
|
||||||
$ref: /schemas/types.yaml#/definitions/phandle
|
|
||||||
description:
|
|
||||||
Phandle to the mediatek wed-pcie controller.
|
|
||||||
|
|
||||||
patternProperties:
|
patternProperties:
|
||||||
"^mac@[0-1]$":
|
"^mac@[0-1]$":
|
||||||
type: object
|
type: object
|
||||||
|
|
|
@ -15,7 +15,7 @@ description:
|
||||||
modes with flow-control as well as CRC offloading and VLAN tags.
|
modes with flow-control as well as CRC offloading and VLAN tags.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -73,7 +73,7 @@ properties:
|
||||||
"^port@[0-9a-f]+$":
|
"^port@[0-9a-f]+$":
|
||||||
type: object
|
type: object
|
||||||
|
|
||||||
$ref: "/schemas/net/ethernet-controller.yaml#"
|
$ref: /schemas/net/ethernet-controller.yaml#
|
||||||
unevaluatedProperties: false
|
unevaluatedProperties: false
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
|
|
|
@ -99,7 +99,7 @@ properties:
|
||||||
|
|
||||||
microchip,bandwidth:
|
microchip,bandwidth:
|
||||||
description: Specifies bandwidth in Mbit/s allocated to the port.
|
description: Specifies bandwidth in Mbit/s allocated to the port.
|
||||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
maximum: 25000
|
maximum: 25000
|
||||||
|
|
||||||
microchip,sd-sgpio:
|
microchip,sd-sgpio:
|
||||||
|
@ -107,7 +107,7 @@ properties:
|
||||||
Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs
|
Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs
|
||||||
This is optional, and only needed if the default used index is
|
This is optional, and only needed if the default used index is
|
||||||
is not correct.
|
is not correct.
|
||||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
minimum: 0
|
minimum: 0
|
||||||
maximum: 383
|
maximum: 383
|
||||||
|
|
||||||
|
|
|
@ -10,7 +10,7 @@ maintainers:
|
||||||
- Alexandre Belloni <alexandre.belloni@bootlin.com>
|
- Alexandre Belloni <alexandre.belloni@bootlin.com>
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -28,7 +28,7 @@ properties:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
reset-n-io:
|
reset-n-io:
|
||||||
$ref: "/schemas/types.yaml#/definitions/phandle-array"
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
description: |
|
description: |
|
||||||
Output GPIO pin used to reset the chip (active low)
|
Output GPIO pin used to reset the chip (active low)
|
||||||
|
|
|
@ -31,7 +31,7 @@ required:
|
||||||
- compatible
|
- compatible
|
||||||
|
|
||||||
dependencies:
|
dependencies:
|
||||||
interrupts: [ 'reg' ]
|
interrupts: [ reg ]
|
||||||
|
|
||||||
additionalProperties: false
|
additionalProperties: false
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,55 @@
|
||||||
|
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/pcs/mediatek,sgmiisys.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: MediaTek SGMIISYS Controller
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Matthias Brugger <matthias.bgg@gmail.com>
|
||||||
|
|
||||||
|
description:
|
||||||
|
The MediaTek SGMIISYS controller provides a SGMII PCS and some clocks
|
||||||
|
to the ethernet subsystem to which it is attached.
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
items:
|
||||||
|
- enum:
|
||||||
|
- mediatek,mt7622-sgmiisys
|
||||||
|
- mediatek,mt7629-sgmiisys
|
||||||
|
- mediatek,mt7981-sgmiisys_0
|
||||||
|
- mediatek,mt7981-sgmiisys_1
|
||||||
|
- mediatek,mt7986-sgmiisys_0
|
||||||
|
- mediatek,mt7986-sgmiisys_1
|
||||||
|
- const: syscon
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
'#clock-cells':
|
||||||
|
const: 1
|
||||||
|
|
||||||
|
mediatek,pnswap:
|
||||||
|
description: Invert polarity of the SGMII data lanes
|
||||||
|
type: boolean
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- '#clock-cells'
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
soc {
|
||||||
|
#address-cells = <2>;
|
||||||
|
#size-cells = <2>;
|
||||||
|
sgmiisys: syscon@1b128000 {
|
||||||
|
compatible = "mediatek,mt7622-sgmiisys", "syscon";
|
||||||
|
reg = <0 0x1b128000 0 0x1000>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
};
|
||||||
|
};
|
|
@ -13,7 +13,7 @@ description: Regulator based PoDL PSE controller. The device must be referenced
|
||||||
by the PHY node to control power injection to the Ethernet cable.
|
by the PHY node to control power injection to the Ethernet cable.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "pse-controller.yaml#"
|
- $ref: pse-controller.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -1,66 +0,0 @@
|
||||||
Qualcomm Ethernet ETHQOS device
|
|
||||||
|
|
||||||
This documents dwmmac based ethernet device which supports Gigabit
|
|
||||||
ethernet for version v2.3.0 onwards.
|
|
||||||
|
|
||||||
This device has following properties:
|
|
||||||
|
|
||||||
Required properties:
|
|
||||||
|
|
||||||
- compatible: Should be one of:
|
|
||||||
"qcom,qcs404-ethqos"
|
|
||||||
"qcom,sm8150-ethqos"
|
|
||||||
|
|
||||||
- reg: Address and length of the register set for the device
|
|
||||||
|
|
||||||
- reg-names: Should contain register names "stmmaceth", "rgmii"
|
|
||||||
|
|
||||||
- clocks: Should contain phandle to clocks
|
|
||||||
|
|
||||||
- clock-names: Should contain clock names "stmmaceth", "pclk",
|
|
||||||
"ptp_ref", "rgmii"
|
|
||||||
|
|
||||||
- interrupts: Should contain phandle to interrupts
|
|
||||||
|
|
||||||
- interrupt-names: Should contain interrupt names "macirq", "eth_lpi"
|
|
||||||
|
|
||||||
Rest of the properties are defined in stmmac.txt file in same directory
|
|
||||||
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
ethernet: ethernet@7a80000 {
|
|
||||||
compatible = "qcom,qcs404-ethqos";
|
|
||||||
reg = <0x07a80000 0x10000>,
|
|
||||||
<0x07a96000 0x100>;
|
|
||||||
reg-names = "stmmaceth", "rgmii";
|
|
||||||
clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii";
|
|
||||||
clocks = <&gcc GCC_ETH_AXI_CLK>,
|
|
||||||
<&gcc GCC_ETH_SLAVE_AHB_CLK>,
|
|
||||||
<&gcc GCC_ETH_PTP_CLK>,
|
|
||||||
<&gcc GCC_ETH_RGMII_CLK>;
|
|
||||||
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
|
|
||||||
interrupt-names = "macirq", "eth_lpi";
|
|
||||||
snps,reset-gpio = <&tlmm 60 GPIO_ACTIVE_LOW>;
|
|
||||||
snps,reset-active-low;
|
|
||||||
|
|
||||||
snps,txpbl = <8>;
|
|
||||||
snps,rxpbl = <2>;
|
|
||||||
snps,aal;
|
|
||||||
snps,tso;
|
|
||||||
|
|
||||||
phy-handle = <&phy1>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
|
|
||||||
mdio {
|
|
||||||
#address-cells = <0x1>;
|
|
||||||
#size-cells = <0x0>;
|
|
||||||
compatible = "snps,dwmac-mdio";
|
|
||||||
phy1: phy@4 {
|
|
||||||
device_type = "ethernet-phy";
|
|
||||||
reg = <0x4>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
};
|
|
111
Documentation/devicetree/bindings/net/qcom,ethqos.yaml
Normal file
111
Documentation/devicetree/bindings/net/qcom,ethqos.yaml
Normal file
|
@ -0,0 +1,111 @@
|
||||||
|
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/qcom,ethqos.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Qualcomm Ethernet ETHQOS device
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Bhupesh Sharma <bhupesh.sharma@linaro.org>
|
||||||
|
|
||||||
|
description:
|
||||||
|
dwmmac based Qualcomm ethernet devices which support Gigabit
|
||||||
|
ethernet (version v2.3.0 and onwards).
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: snps,dwmac.yaml#
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- qcom,qcs404-ethqos
|
||||||
|
- qcom,sc8280xp-ethqos
|
||||||
|
- qcom,sm8150-ethqos
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 2
|
||||||
|
|
||||||
|
reg-names:
|
||||||
|
items:
|
||||||
|
- const: stmmaceth
|
||||||
|
- const: rgmii
|
||||||
|
|
||||||
|
interrupts:
|
||||||
|
items:
|
||||||
|
- description: Combined signal for various interrupt events
|
||||||
|
- description: The interrupt that occurs when Rx exits the LPI state
|
||||||
|
|
||||||
|
interrupt-names:
|
||||||
|
items:
|
||||||
|
- const: macirq
|
||||||
|
- const: eth_lpi
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
maxItems: 4
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
items:
|
||||||
|
- const: stmmaceth
|
||||||
|
- const: pclk
|
||||||
|
- const: ptp_ref
|
||||||
|
- const: rgmii
|
||||||
|
|
||||||
|
iommus:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- clocks
|
||||||
|
- clock-names
|
||||||
|
- reg-names
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||||
|
#include <dt-bindings/clock/qcom,gcc-qcs404.h>
|
||||||
|
#include <dt-bindings/gpio/gpio.h>
|
||||||
|
|
||||||
|
ethernet: ethernet@7a80000 {
|
||||||
|
compatible = "qcom,qcs404-ethqos";
|
||||||
|
reg = <0x07a80000 0x10000>,
|
||||||
|
<0x07a96000 0x100>;
|
||||||
|
reg-names = "stmmaceth", "rgmii";
|
||||||
|
clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii";
|
||||||
|
clocks = <&gcc GCC_ETH_AXI_CLK>,
|
||||||
|
<&gcc GCC_ETH_SLAVE_AHB_CLK>,
|
||||||
|
<&gcc GCC_ETH_PTP_CLK>,
|
||||||
|
<&gcc GCC_ETH_RGMII_CLK>;
|
||||||
|
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
interrupt-names = "macirq", "eth_lpi";
|
||||||
|
|
||||||
|
rx-fifo-depth = <4096>;
|
||||||
|
tx-fifo-depth = <4096>;
|
||||||
|
|
||||||
|
snps,tso;
|
||||||
|
snps,reset-gpio = <&tlmm 60 GPIO_ACTIVE_LOW>;
|
||||||
|
snps,reset-active-low;
|
||||||
|
snps,reset-delays-us = <0 10000 10000>;
|
||||||
|
|
||||||
|
pinctrl-names = "default";
|
||||||
|
pinctrl-0 = <ðernet_defaults>;
|
||||||
|
|
||||||
|
phy-handle = <&phy1>;
|
||||||
|
phy-mode = "rgmii";
|
||||||
|
mdio {
|
||||||
|
#address-cells = <0x1>;
|
||||||
|
#size-cells = <0x0>;
|
||||||
|
|
||||||
|
compatible = "snps,dwmac-mdio";
|
||||||
|
phy1: phy@4 {
|
||||||
|
compatible = "ethernet-phy-ieee802.3-c22";
|
||||||
|
device_type = "ethernet-phy";
|
||||||
|
reg = <0x4>;
|
||||||
|
|
||||||
|
#phy-cells = <0>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
|
@ -49,6 +49,7 @@ properties:
|
||||||
- qcom,sc7280-ipa
|
- qcom,sc7280-ipa
|
||||||
- qcom,sdm845-ipa
|
- qcom,sdm845-ipa
|
||||||
- qcom,sdx55-ipa
|
- qcom,sdx55-ipa
|
||||||
|
- qcom,sdx65-ipa
|
||||||
- qcom,sm6350-ipa
|
- qcom,sm6350-ipa
|
||||||
- qcom,sm8350-ipa
|
- qcom,sm8350-ipa
|
||||||
|
|
||||||
|
|
|
@ -51,7 +51,7 @@ required:
|
||||||
- "#size-cells"
|
- "#size-cells"
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
|
|
|
@ -14,7 +14,7 @@ description:
|
||||||
used to communicate with the gmac phy connected.
|
used to communicate with the gmac phy connected.
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -53,7 +53,9 @@ examples:
|
||||||
reg = <0x10>;
|
reg = <0x10>;
|
||||||
|
|
||||||
ports {
|
ports {
|
||||||
/* ... */
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
/* ... */
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
|
@ -4,24 +4,30 @@
|
||||||
$id: http://devicetree.org/schemas/net/realtek-bluetooth.yaml#
|
$id: http://devicetree.org/schemas/net/realtek-bluetooth.yaml#
|
||||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: RTL8723BS/RTL8723CS/RTL8822CS Bluetooth
|
title: RTL8723BS/RTL8723CS/RTL8821CS/RTL8822CS Bluetooth
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Vasily Khoruzhick <anarsoul@gmail.com>
|
- Vasily Khoruzhick <anarsoul@gmail.com>
|
||||||
- Alistair Francis <alistair@alistair23.me>
|
- Alistair Francis <alistair@alistair23.me>
|
||||||
|
|
||||||
description:
|
description:
|
||||||
RTL8723CS/RTL8723CS/RTL8822CS is WiFi + BT chip. WiFi part is connected over
|
RTL8723CS/RTL8723CS/RTL8821CS/RTL8822CS is a WiFi + BT chip. WiFi part
|
||||||
SDIO, while BT is connected over serial. It speaks H5 protocol with few
|
is connected over SDIO, while BT is connected over serial. It speaks
|
||||||
extra commands to upload firmware and change module speed.
|
H5 protocol with few extra commands to upload firmware and change
|
||||||
|
module speed.
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
enum:
|
oneOf:
|
||||||
- realtek,rtl8723bs-bt
|
- enum:
|
||||||
- realtek,rtl8723cs-bt
|
- realtek,rtl8723bs-bt
|
||||||
- realtek,rtl8723ds-bt
|
- realtek,rtl8723cs-bt
|
||||||
- realtek,rtl8822cs-bt
|
- realtek,rtl8723ds-bt
|
||||||
|
- realtek,rtl8822cs-bt
|
||||||
|
- items:
|
||||||
|
- enum:
|
||||||
|
- realtek,rtl8821cs-bt
|
||||||
|
- const: realtek,rtl8822cs-bt
|
||||||
|
|
||||||
device-wake-gpios:
|
device-wake-gpios:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
|
@ -61,7 +61,7 @@ required:
|
||||||
- mdio
|
- mdio
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
# SPDX-License-Identifier: GPL-2.0
|
# SPDX-License-Identifier: GPL-2.0
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/rockchip-dwmac.yaml#"
|
$id: http://devicetree.org/schemas/net/rockchip-dwmac.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Rockchip 10/100/1000 Ethernet driver(GMAC)
|
title: Rockchip 10/100/1000 Ethernet driver(GMAC)
|
||||||
|
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/sff,sfp.yaml#"
|
$id: http://devicetree.org/schemas/net/sff,sfp.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
|
title: Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
|
||||||
Transceiver
|
Transceiver
|
||||||
|
|
|
@ -30,6 +30,7 @@ select:
|
||||||
- snps,dwmac-4.10a
|
- snps,dwmac-4.10a
|
||||||
- snps,dwmac-4.20a
|
- snps,dwmac-4.20a
|
||||||
- snps,dwmac-5.10a
|
- snps,dwmac-5.10a
|
||||||
|
- snps,dwmac-5.20
|
||||||
- snps,dwxgmac
|
- snps,dwxgmac
|
||||||
- snps,dwxgmac-2.10
|
- snps,dwxgmac-2.10
|
||||||
|
|
||||||
|
@ -65,6 +66,9 @@ properties:
|
||||||
- ingenic,x2000-mac
|
- ingenic,x2000-mac
|
||||||
- loongson,ls2k-dwmac
|
- loongson,ls2k-dwmac
|
||||||
- loongson,ls7a-dwmac
|
- loongson,ls7a-dwmac
|
||||||
|
- qcom,qcs404-ethqos
|
||||||
|
- qcom,sc8280xp-ethqos
|
||||||
|
- qcom,sm8150-ethqos
|
||||||
- renesas,r9a06g032-gmac
|
- renesas,r9a06g032-gmac
|
||||||
- renesas,rzn1-gmac
|
- renesas,rzn1-gmac
|
||||||
- rockchip,px30-gmac
|
- rockchip,px30-gmac
|
||||||
|
@ -87,8 +91,10 @@ properties:
|
||||||
- snps,dwmac-4.10a
|
- snps,dwmac-4.10a
|
||||||
- snps,dwmac-4.20a
|
- snps,dwmac-4.20a
|
||||||
- snps,dwmac-5.10a
|
- snps,dwmac-5.10a
|
||||||
|
- snps,dwmac-5.20
|
||||||
- snps,dwxgmac
|
- snps,dwxgmac
|
||||||
- snps,dwxgmac-2.10
|
- snps,dwxgmac-2.10
|
||||||
|
- starfive,jh7110-dwmac
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
minItems: 1
|
minItems: 1
|
||||||
|
@ -105,7 +111,7 @@ properties:
|
||||||
minItems: 1
|
minItems: 1
|
||||||
items:
|
items:
|
||||||
- const: macirq
|
- const: macirq
|
||||||
- const: eth_wake_irq
|
- enum: [eth_wake_irq, eth_lpi]
|
||||||
- const: eth_lpi
|
- const: eth_lpi
|
||||||
|
|
||||||
clocks:
|
clocks:
|
||||||
|
@ -131,12 +137,16 @@ properties:
|
||||||
- ptp_ref
|
- ptp_ref
|
||||||
|
|
||||||
resets:
|
resets:
|
||||||
maxItems: 1
|
minItems: 1
|
||||||
description:
|
items:
|
||||||
MAC Reset signal.
|
- description: GMAC stmmaceth reset
|
||||||
|
- description: AHB reset
|
||||||
|
|
||||||
reset-names:
|
reset-names:
|
||||||
const: stmmaceth
|
minItems: 1
|
||||||
|
items:
|
||||||
|
- const: stmmaceth
|
||||||
|
- const: ahb
|
||||||
|
|
||||||
power-domains:
|
power-domains:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
@ -555,7 +565,7 @@ dependencies:
|
||||||
snps,reset-delays-us: ["snps,reset-gpio"]
|
snps,reset-delays-us: ["snps,reset-gpio"]
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
- if:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -572,9 +582,11 @@ allOf:
|
||||||
- ingenic,x1600-mac
|
- ingenic,x1600-mac
|
||||||
- ingenic,x1830-mac
|
- ingenic,x1830-mac
|
||||||
- ingenic,x2000-mac
|
- ingenic,x2000-mac
|
||||||
|
- qcom,sc8280xp-ethqos
|
||||||
- snps,dwmac-3.50a
|
- snps,dwmac-3.50a
|
||||||
- snps,dwmac-4.10a
|
- snps,dwmac-4.10a
|
||||||
- snps,dwmac-4.20a
|
- snps,dwmac-4.20a
|
||||||
|
- snps,dwmac-5.20
|
||||||
- snps,dwxgmac
|
- snps,dwxgmac
|
||||||
- snps,dwxgmac-2.10
|
- snps,dwxgmac-2.10
|
||||||
- st,spear600-gmac
|
- st,spear600-gmac
|
||||||
|
@ -625,10 +637,14 @@ allOf:
|
||||||
- ingenic,x1600-mac
|
- ingenic,x1600-mac
|
||||||
- ingenic,x1830-mac
|
- ingenic,x1830-mac
|
||||||
- ingenic,x2000-mac
|
- ingenic,x2000-mac
|
||||||
|
- qcom,qcs404-ethqos
|
||||||
|
- qcom,sc8280xp-ethqos
|
||||||
|
- qcom,sm8150-ethqos
|
||||||
- snps,dwmac-4.00
|
- snps,dwmac-4.00
|
||||||
- snps,dwmac-4.10a
|
- snps,dwmac-4.10a
|
||||||
- snps,dwmac-4.20a
|
- snps,dwmac-4.20a
|
||||||
- snps,dwmac-5.10a
|
- snps,dwmac-5.10a
|
||||||
|
- snps,dwmac-5.20
|
||||||
- snps,dwxgmac
|
- snps,dwxgmac
|
||||||
- snps,dwxgmac-2.10
|
- snps,dwxgmac-2.10
|
||||||
- st,spear600-gmac
|
- st,spear600-gmac
|
||||||
|
|
144
Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
Normal file
144
Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
Normal file
|
@ -0,0 +1,144 @@
|
||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
# Copyright (C) 2022 StarFive Technology Co., Ltd.
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/starfive,jh7110-dwmac.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: StarFive JH7110 DWMAC glue layer
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Emil Renner Berthing <kernel@esmil.dk>
|
||||||
|
- Samin Guo <samin.guo@starfivetech.com>
|
||||||
|
|
||||||
|
select:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
enum:
|
||||||
|
- starfive,jh7110-dwmac
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
items:
|
||||||
|
- enum:
|
||||||
|
- starfive,jh7110-dwmac
|
||||||
|
- const: snps,dwmac-5.20
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
items:
|
||||||
|
- description: GMAC main clock
|
||||||
|
- description: GMAC AHB clock
|
||||||
|
- description: PTP clock
|
||||||
|
- description: TX clock
|
||||||
|
- description: GTX clock
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
items:
|
||||||
|
- const: stmmaceth
|
||||||
|
- const: pclk
|
||||||
|
- const: ptp_ref
|
||||||
|
- const: tx
|
||||||
|
- const: gtx
|
||||||
|
|
||||||
|
interrupts:
|
||||||
|
minItems: 3
|
||||||
|
maxItems: 3
|
||||||
|
|
||||||
|
interrupt-names:
|
||||||
|
minItems: 3
|
||||||
|
maxItems: 3
|
||||||
|
|
||||||
|
resets:
|
||||||
|
items:
|
||||||
|
- description: MAC Reset signal.
|
||||||
|
- description: AHB Reset signal.
|
||||||
|
|
||||||
|
reset-names:
|
||||||
|
items:
|
||||||
|
- const: stmmaceth
|
||||||
|
- const: ahb
|
||||||
|
|
||||||
|
starfive,tx-use-rgmii-clk:
|
||||||
|
description:
|
||||||
|
Tx clock is provided by external rgmii clock.
|
||||||
|
type: boolean
|
||||||
|
|
||||||
|
starfive,syscon:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
|
items:
|
||||||
|
- items:
|
||||||
|
- description: phandle to syscon that configures phy mode
|
||||||
|
- description: Offset of phy mode selection
|
||||||
|
- description: Shift of phy mode selection
|
||||||
|
description:
|
||||||
|
A phandle to syscon with two arguments that configure phy mode.
|
||||||
|
The argument one is the offset of phy mode selection, the
|
||||||
|
argument two is the shift of phy mode selection.
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
- clocks
|
||||||
|
- clock-names
|
||||||
|
- interrupts
|
||||||
|
- interrupt-names
|
||||||
|
- resets
|
||||||
|
- reset-names
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- $ref: snps,dwmac.yaml#
|
||||||
|
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
ethernet@16030000 {
|
||||||
|
compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
|
||||||
|
reg = <0x16030000 0x10000>;
|
||||||
|
clocks = <&clk 3>, <&clk 2>, <&clk 109>,
|
||||||
|
<&clk 6>, <&clk 111>;
|
||||||
|
clock-names = "stmmaceth", "pclk", "ptp_ref",
|
||||||
|
"tx", "gtx";
|
||||||
|
resets = <&rst 1>, <&rst 2>;
|
||||||
|
reset-names = "stmmaceth", "ahb";
|
||||||
|
interrupts = <7>, <6>, <5>;
|
||||||
|
interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
|
||||||
|
phy-mode = "rgmii-id";
|
||||||
|
snps,multicast-filter-bins = <64>;
|
||||||
|
snps,perfect-filter-entries = <8>;
|
||||||
|
rx-fifo-depth = <2048>;
|
||||||
|
tx-fifo-depth = <2048>;
|
||||||
|
snps,fixed-burst;
|
||||||
|
snps,no-pbl-x8;
|
||||||
|
snps,tso;
|
||||||
|
snps,force_thresh_dma_mode;
|
||||||
|
snps,axi-config = <&stmmac_axi_setup>;
|
||||||
|
snps,en-tx-lpi-clockgating;
|
||||||
|
snps,txpbl = <16>;
|
||||||
|
snps,rxpbl = <16>;
|
||||||
|
starfive,syscon = <&aon_syscon 0xc 0x12>;
|
||||||
|
phy-handle = <&phy0>;
|
||||||
|
|
||||||
|
mdio {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
compatible = "snps,dwmac-mdio";
|
||||||
|
|
||||||
|
phy0: ethernet-phy@0 {
|
||||||
|
reg = <0>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
stmmac_axi_setup: stmmac-axi-config {
|
||||||
|
snps,lpi_en;
|
||||||
|
snps,wr_osr_lmt = <4>;
|
||||||
|
snps,rd_osr_lmt = <4>;
|
||||||
|
snps,blen = <256 128 64 32 0 0 0>;
|
||||||
|
};
|
||||||
|
};
|
|
@ -2,8 +2,8 @@
|
||||||
# Copyright 2019 BayLibre, SAS
|
# Copyright 2019 BayLibre, SAS
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/stm32-dwmac.yaml#"
|
$id: http://devicetree.org/schemas/net/stm32-dwmac.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: STMicroelectronics STM32 / MCU DWMAC glue layer controller
|
title: STMicroelectronics STM32 / MCU DWMAC glue layer controller
|
||||||
|
|
||||||
|
@ -26,7 +26,7 @@ select:
|
||||||
- compatible
|
- compatible
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "snps,dwmac.yaml#"
|
- $ref: snps,dwmac.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
@ -73,7 +73,7 @@ properties:
|
||||||
- ptp_ref
|
- ptp_ref
|
||||||
|
|
||||||
st,syscon:
|
st,syscon:
|
||||||
$ref: "/schemas/types.yaml#/definitions/phandle-array"
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
items:
|
items:
|
||||||
- items:
|
- items:
|
||||||
- description: phandle to the syscon node which encompases the glue register
|
- description: phandle to the syscon node which encompases the glue register
|
||||||
|
|
|
@ -62,10 +62,10 @@ properties:
|
||||||
|
|
||||||
interrupt-names:
|
interrupt-names:
|
||||||
items:
|
items:
|
||||||
- const: "rx_thresh"
|
- const: rx_thresh
|
||||||
- const: "rx"
|
- const: rx
|
||||||
- const: "tx"
|
- const: tx
|
||||||
- const: "misc"
|
- const: misc
|
||||||
|
|
||||||
pinctrl-names: true
|
pinctrl-names: true
|
||||||
|
|
||||||
|
@ -154,7 +154,7 @@ patternProperties:
|
||||||
type: object
|
type: object
|
||||||
description:
|
description:
|
||||||
CPSW MDIO bus.
|
CPSW MDIO bus.
|
||||||
$ref: "ti,davinci-mdio.yaml#"
|
$ref: ti,davinci-mdio.yaml#
|
||||||
|
|
||||||
|
|
||||||
required:
|
required:
|
||||||
|
|
|
@ -13,7 +13,7 @@ description:
|
||||||
TI SoC Davinci/Keystone2 MDIO Controller
|
TI SoC Davinci/Keystone2 MDIO Controller
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "mdio.yaml#"
|
- $ref: mdio.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -2,8 +2,8 @@
|
||||||
# Copyright (C) 2020 Texas Instruments Incorporated
|
# Copyright (C) 2020 Texas Instruments Incorporated
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/ti,dp83822.yaml#"
|
$id: http://devicetree.org/schemas/net/ti,dp83822.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: TI DP83822 ethernet PHY
|
title: TI DP83822 ethernet PHY
|
||||||
|
|
||||||
|
@ -21,7 +21,7 @@ description: |
|
||||||
http://www.ti.com/lit/ds/symlink/dp83822i.pdf
|
http://www.ti.com/lit/ds/symlink/dp83822i.pdf
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-phy.yaml#"
|
- $ref: ethernet-phy.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
reg:
|
reg:
|
||||||
|
|
|
@ -2,13 +2,13 @@
|
||||||
# Copyright (C) 2019 Texas Instruments Incorporated
|
# Copyright (C) 2019 Texas Instruments Incorporated
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/ti,dp83867.yaml#"
|
$id: http://devicetree.org/schemas/net/ti,dp83867.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: TI DP83867 ethernet PHY
|
title: TI DP83867 ethernet PHY
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-controller.yaml#"
|
- $ref: ethernet-controller.yaml#
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Andrew Davis <afd@ti.com>
|
- Andrew Davis <afd@ti.com>
|
||||||
|
|
|
@ -2,13 +2,13 @@
|
||||||
# Copyright (C) 2019 Texas Instruments Incorporated
|
# Copyright (C) 2019 Texas Instruments Incorporated
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/ti,dp83869.yaml#"
|
$id: http://devicetree.org/schemas/net/ti,dp83869.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: TI DP83869 ethernet PHY
|
title: TI DP83869 ethernet PHY
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: "ethernet-phy.yaml#"
|
- $ref: ethernet-phy.yaml#
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Andrew Davis <afd@ti.com>
|
- Andrew Davis <afd@ti.com>
|
||||||
|
|
|
@ -54,11 +54,12 @@ properties:
|
||||||
|
|
||||||
compatible:
|
compatible:
|
||||||
enum:
|
enum:
|
||||||
|
- ti,am642-cpsw-nuss
|
||||||
- ti,am654-cpsw-nuss
|
- ti,am654-cpsw-nuss
|
||||||
- ti,j7200-cpswxg-nuss
|
- ti,j7200-cpswxg-nuss
|
||||||
- ti,j721e-cpsw-nuss
|
- ti,j721e-cpsw-nuss
|
||||||
- ti,j721e-cpswxg-nuss
|
- ti,j721e-cpswxg-nuss
|
||||||
- ti,am642-cpsw-nuss
|
- ti,j784s4-cpswxg-nuss
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
@ -126,8 +127,18 @@ properties:
|
||||||
description: CPSW port number
|
description: CPSW port number
|
||||||
|
|
||||||
phys:
|
phys:
|
||||||
maxItems: 1
|
minItems: 1
|
||||||
description: phandle on phy-gmii-sel PHY
|
items:
|
||||||
|
- description: CPSW MAC's PHY.
|
||||||
|
- description: Serdes PHY. Serdes PHY is required only if
|
||||||
|
the Serdes has to be configured in the
|
||||||
|
Single-Link configuration.
|
||||||
|
|
||||||
|
phy-names:
|
||||||
|
minItems: 1
|
||||||
|
items:
|
||||||
|
- const: mac
|
||||||
|
- const: serdes
|
||||||
|
|
||||||
label:
|
label:
|
||||||
description: label associated with this port
|
description: label associated with this port
|
||||||
|
@ -187,7 +198,9 @@ allOf:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
contains:
|
contains:
|
||||||
const: ti,j721e-cpswxg-nuss
|
enum:
|
||||||
|
- ti,j721e-cpswxg-nuss
|
||||||
|
- ti,j784s4-cpswxg-nuss
|
||||||
then:
|
then:
|
||||||
properties:
|
properties:
|
||||||
ethernet-ports:
|
ethernet-ports:
|
||||||
|
@ -205,8 +218,9 @@ allOf:
|
||||||
compatible:
|
compatible:
|
||||||
contains:
|
contains:
|
||||||
enum:
|
enum:
|
||||||
- ti,j721e-cpswxg-nuss
|
|
||||||
- ti,j7200-cpswxg-nuss
|
- ti,j7200-cpswxg-nuss
|
||||||
|
- ti,j721e-cpswxg-nuss
|
||||||
|
- ti,j784s4-cpswxg-nuss
|
||||||
then:
|
then:
|
||||||
properties:
|
properties:
|
||||||
ethernet-ports:
|
ethernet-ports:
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml#"
|
$id: http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: Toshiba Visconti DWMAC Ethernet controller
|
title: Toshiba Visconti DWMAC Ethernet controller
|
||||||
|
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
%YAML 1.2
|
%YAML 1.2
|
||||||
---
|
---
|
||||||
$id: "http://devicetree.org/schemas/net/vertexcom-mse102x.yaml#"
|
$id: http://devicetree.org/schemas/net/vertexcom-mse102x.yaml#
|
||||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
title: The Vertexcom MSE102x (SPI)
|
title: The Vertexcom MSE102x (SPI)
|
||||||
|
|
||||||
|
|
|
@ -111,6 +111,11 @@ properties:
|
||||||
$ref: /schemas/leds/common.yaml#
|
$ref: /schemas/leds/common.yaml#
|
||||||
additionalProperties: false
|
additionalProperties: false
|
||||||
properties:
|
properties:
|
||||||
|
led-active-low:
|
||||||
|
description:
|
||||||
|
LED is enabled with ground signal.
|
||||||
|
type: boolean
|
||||||
|
|
||||||
led-sources:
|
led-sources:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
|
|
|
@ -1,215 +0,0 @@
|
||||||
* Qualcomm Atheros ath10k wireless devices
|
|
||||||
|
|
||||||
Required properties:
|
|
||||||
- compatible: Should be one of the following:
|
|
||||||
* "qcom,ath10k"
|
|
||||||
* "qcom,ipq4019-wifi"
|
|
||||||
* "qcom,wcn3990-wifi"
|
|
||||||
|
|
||||||
PCI based devices uses compatible string "qcom,ath10k" and takes calibration
|
|
||||||
data along with board specific data via "qcom,ath10k-calibration-data".
|
|
||||||
Rest of the properties are not applicable for PCI based devices.
|
|
||||||
|
|
||||||
AHB based devices (i.e. ipq4019) uses compatible string "qcom,ipq4019-wifi"
|
|
||||||
and also uses most of the properties defined in this doc (except
|
|
||||||
"qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data"
|
|
||||||
to carry pre calibration data.
|
|
||||||
|
|
||||||
In general, entry "qcom,ath10k-pre-calibration-data" and
|
|
||||||
"qcom,ath10k-calibration-data" conflict with each other and only one
|
|
||||||
can be provided per device.
|
|
||||||
|
|
||||||
SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
|
|
||||||
|
|
||||||
- reg: Address and length of the register set for the device.
|
|
||||||
- reg-names: Must include the list of following reg names,
|
|
||||||
"membase"
|
|
||||||
- interrupts: reference to the list of 17 interrupt numbers for "qcom,ipq4019-wifi"
|
|
||||||
compatible target.
|
|
||||||
reference to the list of 12 interrupt numbers for "qcom,wcn3990-wifi"
|
|
||||||
compatible target.
|
|
||||||
Must contain interrupt-names property per entry for
|
|
||||||
"qcom,ath10k", "qcom,ipq4019-wifi" compatible targets.
|
|
||||||
|
|
||||||
- interrupt-names: Must include the entries for MSI interrupt
|
|
||||||
names ("msi0" to "msi15") and legacy interrupt
|
|
||||||
name ("legacy") for "qcom,ath10k", "qcom,ipq4019-wifi"
|
|
||||||
compatible targets.
|
|
||||||
|
|
||||||
Optional properties:
|
|
||||||
- resets: Must contain an entry for each entry in reset-names.
|
|
||||||
See ../reset/reseti.txt for details.
|
|
||||||
- reset-names: Must include the list of following reset names,
|
|
||||||
"wifi_cpu_init"
|
|
||||||
"wifi_radio_srif"
|
|
||||||
"wifi_radio_warm"
|
|
||||||
"wifi_radio_cold"
|
|
||||||
"wifi_core_warm"
|
|
||||||
"wifi_core_cold"
|
|
||||||
- clocks: List of clock specifiers, must contain an entry for each required
|
|
||||||
entry in clock-names.
|
|
||||||
- clock-names: Should contain the clock names "wifi_wcss_cmd", "wifi_wcss_ref",
|
|
||||||
"wifi_wcss_rtc" for "qcom,ipq4019-wifi" compatible target and
|
|
||||||
"cxo_ref_clk_pin" and optionally "qdss" for "qcom,wcn3990-wifi"
|
|
||||||
compatible target.
|
|
||||||
- qcom,msi_addr: MSI interrupt address.
|
|
||||||
- qcom,msi_base: Base value to add before writing MSI data into
|
|
||||||
MSI address register.
|
|
||||||
- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
|
|
||||||
variant list with the same bus and device
|
|
||||||
specific ids
|
|
||||||
- qcom,ath10k-calibration-data : calibration data + board specific data
|
|
||||||
as an array, the length can vary between
|
|
||||||
hw versions.
|
|
||||||
- qcom,ath10k-pre-calibration-data : pre calibration data as an array,
|
|
||||||
the length can vary between hw versions.
|
|
||||||
- <supply-name>-supply: handle to the regulator device tree node
|
|
||||||
optional "supply-name" are "vdd-0.8-cx-mx",
|
|
||||||
"vdd-1.8-xo", "vdd-1.3-rfa", "vdd-3.3-ch0",
|
|
||||||
and "vdd-3.3-ch1".
|
|
||||||
- memory-region:
|
|
||||||
Usage: optional
|
|
||||||
Value type: <phandle>
|
|
||||||
Definition: reference to the reserved-memory for the msa region
|
|
||||||
used by the wifi firmware running in Q6.
|
|
||||||
- iommus:
|
|
||||||
Usage: optional
|
|
||||||
Value type: <prop-encoded-array>
|
|
||||||
Definition: A list of phandle and IOMMU specifier pairs.
|
|
||||||
- ext-fem-name:
|
|
||||||
Usage: Optional
|
|
||||||
Value type: string
|
|
||||||
Definition: Name of external front end module used. Some valid FEM names
|
|
||||||
for example: "microsemi-lx5586", "sky85703-11"
|
|
||||||
and "sky85803" etc.
|
|
||||||
- qcom,snoc-host-cap-8bit-quirk:
|
|
||||||
Usage: Optional
|
|
||||||
Value type: <empty>
|
|
||||||
Definition: Quirk specifying that the firmware expects the 8bit version
|
|
||||||
of the host capability QMI request
|
|
||||||
- qcom,xo-cal-data: xo cal offset to be configured in xo trim register.
|
|
||||||
|
|
||||||
- qcom,msa-fixed-perm: Boolean context flag to disable SCM call for statically
|
|
||||||
mapped msa region.
|
|
||||||
|
|
||||||
- qcom,coexist-support : should contain eithr "0" or "1" to indicate coex
|
|
||||||
support by the hardware.
|
|
||||||
- qcom,coexist-gpio-pin : gpio pin number information to support coex
|
|
||||||
which will be used by wifi firmware.
|
|
||||||
|
|
||||||
* Subnodes
|
|
||||||
The ath10k wifi node can contain one optional firmware subnode.
|
|
||||||
Firmware subnode is needed when the platform does not have TustZone.
|
|
||||||
The firmware subnode must have:
|
|
||||||
|
|
||||||
- iommus:
|
|
||||||
Usage: required
|
|
||||||
Value type: <prop-encoded-array>
|
|
||||||
Definition: A list of phandle and IOMMU specifier pairs.
|
|
||||||
|
|
||||||
|
|
||||||
Example (to supply PCI based wifi block details):
|
|
||||||
|
|
||||||
In this example, the node is defined as child node of the PCI controller.
|
|
||||||
|
|
||||||
pci {
|
|
||||||
pcie@0 {
|
|
||||||
reg = <0 0 0 0 0>;
|
|
||||||
#interrupt-cells = <1>;
|
|
||||||
#size-cells = <2>;
|
|
||||||
#address-cells = <3>;
|
|
||||||
device_type = "pci";
|
|
||||||
|
|
||||||
wifi@0,0 {
|
|
||||||
reg = <0 0 0 0 0>;
|
|
||||||
qcom,ath10k-calibration-data = [ 01 02 03 ... ];
|
|
||||||
ext-fem-name = "microsemi-lx5586";
|
|
||||||
};
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
Example (to supply ipq4019 SoC wifi block details):
|
|
||||||
|
|
||||||
wifi0: wifi@a000000 {
|
|
||||||
compatible = "qcom,ipq4019-wifi";
|
|
||||||
reg = <0xa000000 0x200000>;
|
|
||||||
resets = <&gcc WIFI0_CPU_INIT_RESET>,
|
|
||||||
<&gcc WIFI0_RADIO_SRIF_RESET>,
|
|
||||||
<&gcc WIFI0_RADIO_WARM_RESET>,
|
|
||||||
<&gcc WIFI0_RADIO_COLD_RESET>,
|
|
||||||
<&gcc WIFI0_CORE_WARM_RESET>,
|
|
||||||
<&gcc WIFI0_CORE_COLD_RESET>;
|
|
||||||
reset-names = "wifi_cpu_init",
|
|
||||||
"wifi_radio_srif",
|
|
||||||
"wifi_radio_warm",
|
|
||||||
"wifi_radio_cold",
|
|
||||||
"wifi_core_warm",
|
|
||||||
"wifi_core_cold";
|
|
||||||
clocks = <&gcc GCC_WCSS2G_CLK>,
|
|
||||||
<&gcc GCC_WCSS2G_REF_CLK>,
|
|
||||||
<&gcc GCC_WCSS2G_RTC_CLK>;
|
|
||||||
clock-names = "wifi_wcss_cmd",
|
|
||||||
"wifi_wcss_ref",
|
|
||||||
"wifi_wcss_rtc";
|
|
||||||
interrupts = <0 0x20 0x1>,
|
|
||||||
<0 0x21 0x1>,
|
|
||||||
<0 0x22 0x1>,
|
|
||||||
<0 0x23 0x1>,
|
|
||||||
<0 0x24 0x1>,
|
|
||||||
<0 0x25 0x1>,
|
|
||||||
<0 0x26 0x1>,
|
|
||||||
<0 0x27 0x1>,
|
|
||||||
<0 0x28 0x1>,
|
|
||||||
<0 0x29 0x1>,
|
|
||||||
<0 0x2a 0x1>,
|
|
||||||
<0 0x2b 0x1>,
|
|
||||||
<0 0x2c 0x1>,
|
|
||||||
<0 0x2d 0x1>,
|
|
||||||
<0 0x2e 0x1>,
|
|
||||||
<0 0x2f 0x1>,
|
|
||||||
<0 0xa8 0x0>;
|
|
||||||
interrupt-names = "msi0", "msi1", "msi2", "msi3",
|
|
||||||
"msi4", "msi5", "msi6", "msi7",
|
|
||||||
"msi8", "msi9", "msi10", "msi11",
|
|
||||||
"msi12", "msi13", "msi14", "msi15",
|
|
||||||
"legacy";
|
|
||||||
qcom,msi_addr = <0x0b006040>;
|
|
||||||
qcom,msi_base = <0x40>;
|
|
||||||
qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
|
|
||||||
qcom,coexist-support = <1>;
|
|
||||||
qcom,coexist-gpio-pin = <0x33>;
|
|
||||||
};
|
|
||||||
|
|
||||||
Example (to supply wcn3990 SoC wifi block details):
|
|
||||||
|
|
||||||
wifi@18000000 {
|
|
||||||
compatible = "qcom,wcn3990-wifi";
|
|
||||||
reg = <0x18800000 0x800000>;
|
|
||||||
reg-names = "membase";
|
|
||||||
clocks = <&clock_gcc clk_rf_clk2_pin>;
|
|
||||||
clock-names = "cxo_ref_clk_pin";
|
|
||||||
interrupts =
|
|
||||||
<GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
|
|
||||||
<GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>;
|
|
||||||
vdd-0.8-cx-mx-supply = <&pm8998_l5>;
|
|
||||||
vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
|
|
||||||
vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
|
|
||||||
vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
|
|
||||||
vdd-3.3-ch1-supply = <&vreg_l26a_3p3>;
|
|
||||||
memory-region = <&wifi_msa_mem>;
|
|
||||||
iommus = <&apps_smmu 0x0040 0x1>;
|
|
||||||
qcom,msa-fixed-perm;
|
|
||||||
wifi-firmware {
|
|
||||||
iommus = <&apps_iommu 0xc22 0x1>;
|
|
||||||
};
|
|
||||||
};
|
|
358
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
Normal file
358
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
Normal file
|
@ -0,0 +1,358 @@
|
||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/wireless/qcom,ath10k.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Qualcomm Technologies ath10k wireless devices
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Kalle Valo <kvalo@kernel.org>
|
||||||
|
|
||||||
|
description:
|
||||||
|
Qualcomm Technologies, Inc. IEEE 802.11ac devices.
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- qcom,ath10k # SDIO-based devices
|
||||||
|
- qcom,ipq4019-wifi
|
||||||
|
- qcom,wcn3990-wifi # SNoC-based devices
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
reg-names:
|
||||||
|
items:
|
||||||
|
- const: membase
|
||||||
|
|
||||||
|
interrupts:
|
||||||
|
minItems: 12
|
||||||
|
maxItems: 17
|
||||||
|
|
||||||
|
interrupt-names:
|
||||||
|
minItems: 12
|
||||||
|
maxItems: 17
|
||||||
|
|
||||||
|
memory-region:
|
||||||
|
maxItems: 1
|
||||||
|
description:
|
||||||
|
Reference to the MSA memory region used by the Wi-Fi firmware
|
||||||
|
running on the Q6 core.
|
||||||
|
|
||||||
|
iommus:
|
||||||
|
minItems: 1
|
||||||
|
maxItems: 2
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
minItems: 1
|
||||||
|
maxItems: 3
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
minItems: 1
|
||||||
|
maxItems: 3
|
||||||
|
|
||||||
|
resets:
|
||||||
|
maxItems: 6
|
||||||
|
|
||||||
|
reset-names:
|
||||||
|
items:
|
||||||
|
- const: wifi_cpu_init
|
||||||
|
- const: wifi_radio_srif
|
||||||
|
- const: wifi_radio_warm
|
||||||
|
- const: wifi_radio_cold
|
||||||
|
- const: wifi_core_warm
|
||||||
|
- const: wifi_core_cold
|
||||||
|
|
||||||
|
ext-fem-name:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/string
|
||||||
|
description: Name of external front end module used.
|
||||||
|
enum:
|
||||||
|
- microsemi-lx5586
|
||||||
|
- sky85703-11
|
||||||
|
- sky85803
|
||||||
|
|
||||||
|
wifi-firmware:
|
||||||
|
type: object
|
||||||
|
additionalProperties: false
|
||||||
|
description: |
|
||||||
|
The ath10k Wi-Fi node can contain one optional firmware subnode.
|
||||||
|
Firmware subnode is needed when the platform does not have Trustzone.
|
||||||
|
properties:
|
||||||
|
iommus:
|
||||||
|
maxItems: 1
|
||||||
|
required:
|
||||||
|
- iommus
|
||||||
|
|
||||||
|
qcom,ath10k-calibration-data:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||||
|
description:
|
||||||
|
Calibration data + board-specific data as a byte array. The length
|
||||||
|
can vary between hardware versions.
|
||||||
|
|
||||||
|
qcom,ath10k-calibration-variant:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/string
|
||||||
|
description:
|
||||||
|
Unique variant identifier of the calibration data in board-2.bin
|
||||||
|
for designs with colliding bus and device specific ids
|
||||||
|
|
||||||
|
qcom,ath10k-pre-calibration-data:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||||
|
description:
|
||||||
|
Pre-calibration data as a byte array. The length can vary between
|
||||||
|
hardware versions.
|
||||||
|
|
||||||
|
qcom,coexist-support:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/uint8
|
||||||
|
enum: [0, 1]
|
||||||
|
description:
|
||||||
|
Indicate coex support by the hardware.
|
||||||
|
|
||||||
|
qcom,coexist-gpio-pin:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
|
description:
|
||||||
|
COEX GPIO number provided to the Wi-Fi firmware.
|
||||||
|
|
||||||
|
qcom,msa-fixed-perm:
|
||||||
|
type: boolean
|
||||||
|
description:
|
||||||
|
Whether to skip executing an SCM call that reassigns the memory
|
||||||
|
region ownership.
|
||||||
|
|
||||||
|
qcom,smem-states:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||||
|
description: State bits used by the AP to signal the WLAN Q6.
|
||||||
|
items:
|
||||||
|
- description: Signal bits used to enable/disable low power mode
|
||||||
|
on WCN in the case of WoW (Wake on Wireless).
|
||||||
|
|
||||||
|
qcom,smem-state-names:
|
||||||
|
description: The names of the state bits used for SMP2P output.
|
||||||
|
items:
|
||||||
|
- const: wlan-smp2p-out
|
||||||
|
|
||||||
|
qcom,snoc-host-cap-8bit-quirk:
|
||||||
|
type: boolean
|
||||||
|
description:
|
||||||
|
Quirk specifying that the firmware expects the 8bit version
|
||||||
|
of the host capability QMI request
|
||||||
|
|
||||||
|
qcom,xo-cal-data:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
|
description:
|
||||||
|
XO cal offset to be configured in XO trim register.
|
||||||
|
|
||||||
|
vdd-0.8-cx-mx-supply:
|
||||||
|
description: Main logic power rail
|
||||||
|
|
||||||
|
vdd-1.8-xo-supply:
|
||||||
|
description: Crystal oscillator supply
|
||||||
|
|
||||||
|
vdd-1.3-rfa-supply:
|
||||||
|
description: RFA supply
|
||||||
|
|
||||||
|
vdd-3.3-ch0-supply:
|
||||||
|
description: Primary Wi-Fi antenna supply
|
||||||
|
|
||||||
|
vdd-3.3-ch1-supply:
|
||||||
|
description: Secondary Wi-Fi antenna supply
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
allOf:
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
enum:
|
||||||
|
- qcom,ipq4019-wifi
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
interrupts:
|
||||||
|
minItems: 17
|
||||||
|
maxItems: 17
|
||||||
|
|
||||||
|
interrupt-names:
|
||||||
|
items:
|
||||||
|
- const: msi0
|
||||||
|
- const: msi1
|
||||||
|
- const: msi2
|
||||||
|
- const: msi3
|
||||||
|
- const: msi4
|
||||||
|
- const: msi5
|
||||||
|
- const: msi6
|
||||||
|
- const: msi7
|
||||||
|
- const: msi8
|
||||||
|
- const: msi9
|
||||||
|
- const: msi10
|
||||||
|
- const: msi11
|
||||||
|
- const: msi12
|
||||||
|
- const: msi13
|
||||||
|
- const: msi14
|
||||||
|
- const: msi15
|
||||||
|
- const: legacy
|
||||||
|
|
||||||
|
clocks:
|
||||||
|
items:
|
||||||
|
- description: Wi-Fi command clock
|
||||||
|
- description: Wi-Fi reference clock
|
||||||
|
- description: Wi-Fi RTC clock
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
items:
|
||||||
|
- const: wifi_wcss_cmd
|
||||||
|
- const: wifi_wcss_ref
|
||||||
|
- const: wifi_wcss_rtc
|
||||||
|
|
||||||
|
required:
|
||||||
|
- clocks
|
||||||
|
- clock-names
|
||||||
|
- interrupts
|
||||||
|
- interrupt-names
|
||||||
|
- resets
|
||||||
|
- reset-names
|
||||||
|
|
||||||
|
- if:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
enum:
|
||||||
|
- qcom,wcn3990-wifi
|
||||||
|
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
clocks:
|
||||||
|
minItems: 1
|
||||||
|
items:
|
||||||
|
- description: XO reference clock
|
||||||
|
- description: Qualcomm Debug Subsystem clock
|
||||||
|
|
||||||
|
clock-names:
|
||||||
|
minItems: 1
|
||||||
|
items:
|
||||||
|
- const: cxo_ref_clk_pin
|
||||||
|
- const: qdss
|
||||||
|
|
||||||
|
interrupts:
|
||||||
|
items:
|
||||||
|
- description: CE0
|
||||||
|
- description: CE1
|
||||||
|
- description: CE2
|
||||||
|
- description: CE3
|
||||||
|
- description: CE4
|
||||||
|
- description: CE5
|
||||||
|
- description: CE6
|
||||||
|
- description: CE7
|
||||||
|
- description: CE8
|
||||||
|
- description: CE9
|
||||||
|
- description: CE10
|
||||||
|
- description: CE11
|
||||||
|
|
||||||
|
interrupt-names: false
|
||||||
|
|
||||||
|
required:
|
||||||
|
- interrupts
|
||||||
|
|
||||||
|
examples:
|
||||||
|
# SNoC
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||||
|
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||||
|
|
||||||
|
wifi@18800000 {
|
||||||
|
compatible = "qcom,wcn3990-wifi";
|
||||||
|
reg = <0x18800000 0x800000>;
|
||||||
|
reg-names = "membase";
|
||||||
|
memory-region = <&wlan_msa_mem>;
|
||||||
|
clocks = <&rpmcc RPM_SMD_RF_CLK2_PIN>;
|
||||||
|
clock-names = "cxo_ref_clk_pin";
|
||||||
|
interrupts = <GIC_SPI 413 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
<GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
iommus = <&anoc2_smmu 0x1900>,
|
||||||
|
<&anoc2_smmu 0x1901>;
|
||||||
|
qcom,snoc-host-cap-8bit-quirk;
|
||||||
|
vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
|
||||||
|
vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
|
||||||
|
vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
|
||||||
|
vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
|
||||||
|
vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
|
||||||
|
|
||||||
|
wifi-firmware {
|
||||||
|
iommus = <&apps_smmu 0x1c02 0x1>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
# AHB
|
||||||
|
- |
|
||||||
|
#include <dt-bindings/clock/qcom,gcc-ipq4019.h>
|
||||||
|
|
||||||
|
wifi@a000000 {
|
||||||
|
compatible = "qcom,ipq4019-wifi";
|
||||||
|
reg = <0xa000000 0x200000>;
|
||||||
|
resets = <&gcc WIFI0_CPU_INIT_RESET>,
|
||||||
|
<&gcc WIFI0_RADIO_SRIF_RESET>,
|
||||||
|
<&gcc WIFI0_RADIO_WARM_RESET>,
|
||||||
|
<&gcc WIFI0_RADIO_COLD_RESET>,
|
||||||
|
<&gcc WIFI0_CORE_WARM_RESET>,
|
||||||
|
<&gcc WIFI0_CORE_COLD_RESET>;
|
||||||
|
reset-names = "wifi_cpu_init",
|
||||||
|
"wifi_radio_srif",
|
||||||
|
"wifi_radio_warm",
|
||||||
|
"wifi_radio_cold",
|
||||||
|
"wifi_core_warm",
|
||||||
|
"wifi_core_cold";
|
||||||
|
clocks = <&gcc GCC_WCSS2G_CLK>,
|
||||||
|
<&gcc GCC_WCSS2G_REF_CLK>,
|
||||||
|
<&gcc GCC_WCSS2G_RTC_CLK>;
|
||||||
|
clock-names = "wifi_wcss_cmd",
|
||||||
|
"wifi_wcss_ref",
|
||||||
|
"wifi_wcss_rtc";
|
||||||
|
interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 33 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 34 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 35 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 36 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 37 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 38 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 39 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 40 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 41 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 42 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 43 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 44 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 45 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 46 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 47 IRQ_TYPE_EDGE_RISING>,
|
||||||
|
<GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
interrupt-names = "msi0",
|
||||||
|
"msi1",
|
||||||
|
"msi2",
|
||||||
|
"msi3",
|
||||||
|
"msi4",
|
||||||
|
"msi5",
|
||||||
|
"msi6",
|
||||||
|
"msi7",
|
||||||
|
"msi8",
|
||||||
|
"msi9",
|
||||||
|
"msi10",
|
||||||
|
"msi11",
|
||||||
|
"msi12",
|
||||||
|
"msi13",
|
||||||
|
"msi14",
|
||||||
|
"msi15",
|
||||||
|
"legacy";
|
||||||
|
};
|
|
@ -0,0 +1,58 @@
|
||||||
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
|
# Copyright (c) 2023 Linaro Limited
|
||||||
|
%YAML 1.2
|
||||||
|
---
|
||||||
|
$id: http://devicetree.org/schemas/net/wireless/qcom,ath11k-pci.yaml#
|
||||||
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||||
|
|
||||||
|
title: Qualcomm Technologies ath11k wireless devices (PCIe)
|
||||||
|
|
||||||
|
maintainers:
|
||||||
|
- Kalle Valo <kvalo@kernel.org>
|
||||||
|
|
||||||
|
description: |
|
||||||
|
Qualcomm Technologies IEEE 802.11ax PCIe devices
|
||||||
|
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
enum:
|
||||||
|
- pci17cb,1103 # WCN6855
|
||||||
|
|
||||||
|
reg:
|
||||||
|
maxItems: 1
|
||||||
|
|
||||||
|
qcom,ath11k-calibration-variant:
|
||||||
|
$ref: /schemas/types.yaml#/definitions/string
|
||||||
|
description: |
|
||||||
|
string to uniquely identify variant of the calibration data for designs
|
||||||
|
with colliding bus and device ids
|
||||||
|
|
||||||
|
required:
|
||||||
|
- compatible
|
||||||
|
- reg
|
||||||
|
|
||||||
|
additionalProperties: false
|
||||||
|
|
||||||
|
examples:
|
||||||
|
- |
|
||||||
|
pcie {
|
||||||
|
#address-cells = <3>;
|
||||||
|
#size-cells = <2>;
|
||||||
|
|
||||||
|
pcie@0 {
|
||||||
|
device_type = "pci";
|
||||||
|
reg = <0x0 0x0 0x0 0x0 0x0>;
|
||||||
|
#address-cells = <3>;
|
||||||
|
#size-cells = <2>;
|
||||||
|
ranges;
|
||||||
|
|
||||||
|
bus-range = <0x01 0xff>;
|
||||||
|
|
||||||
|
wifi@0 {
|
||||||
|
compatible = "pci17cb,1103";
|
||||||
|
reg = <0x10000 0x0 0x0 0x0 0x0>;
|
||||||
|
|
||||||
|
qcom,ath11k-calibration-variant = "LE_X13S";
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
|
@ -70,3 +70,33 @@ Good: "platform:*:charging" (allwinner sun50i)
|
||||||
* Screen
|
* Screen
|
||||||
|
|
||||||
Good: ":backlight" (Motorola Droid 4)
|
Good: ":backlight" (Motorola Droid 4)
|
||||||
|
|
||||||
|
* Ethernet LEDs
|
||||||
|
|
||||||
|
Currently two types of Network LEDs are support, those controlled by
|
||||||
|
the PHY and those by the MAC. In theory both can be present at the
|
||||||
|
same time for one Linux netdev, hence the names need to differ between
|
||||||
|
MAC and PHY.
|
||||||
|
|
||||||
|
Do not use the netdev name, such as eth0, enp1s0. These are not stable
|
||||||
|
and are not unique. They also don't differentiate between MAC and PHY.
|
||||||
|
|
||||||
|
** MAC LEDs
|
||||||
|
|
||||||
|
Good: f1070000.ethernet:white:WAN
|
||||||
|
Good: mdio_mux-0.1:00:green:left
|
||||||
|
Good: 0000:02:00.0:yellow:top
|
||||||
|
|
||||||
|
The first part must uniquely name the MAC controller. Then follows the
|
||||||
|
colour. WAN/LAN should be used for a single LED. If there are
|
||||||
|
multiple LEDs, use left/right, or top/bottom to indicate their
|
||||||
|
position on the RJ45 socket.
|
||||||
|
|
||||||
|
** PHY LEDs
|
||||||
|
|
||||||
|
Good: f1072004.mdio-mii:00: white:WAN
|
||||||
|
Good: !mdio-mux!mdio@2!switch@0!mdio:01:green:right
|
||||||
|
Good: r8169-0-200:00:yellow:bottom
|
||||||
|
|
||||||
|
The first part must uniquely name the PHY. This often means uniquely
|
||||||
|
identifying the MDIO bus controller, and the address on the bus.
|
||||||
|
|
|
@ -33,10 +33,10 @@ properties:
|
||||||
protocol:
|
protocol:
|
||||||
description: Schema compatibility level. Default is "genetlink".
|
description: Schema compatibility level. Default is "genetlink".
|
||||||
enum: [ genetlink, genetlink-c ]
|
enum: [ genetlink, genetlink-c ]
|
||||||
# Start genetlink-c
|
|
||||||
uapi-header:
|
uapi-header:
|
||||||
description: Path to the uAPI header, default is linux/${family-name}.h
|
description: Path to the uAPI header, default is linux/${family-name}.h
|
||||||
type: string
|
type: string
|
||||||
|
# Start genetlink-c
|
||||||
c-family-name:
|
c-family-name:
|
||||||
description: Name of the define for the family name.
|
description: Name of the define for the family name.
|
||||||
type: string
|
type: string
|
||||||
|
|
|
@ -33,10 +33,10 @@ properties:
|
||||||
protocol:
|
protocol:
|
||||||
description: Schema compatibility level. Default is "genetlink".
|
description: Schema compatibility level. Default is "genetlink".
|
||||||
enum: [ genetlink, genetlink-c, genetlink-legacy ] # Trim
|
enum: [ genetlink, genetlink-c, genetlink-legacy ] # Trim
|
||||||
# Start genetlink-c
|
|
||||||
uapi-header:
|
uapi-header:
|
||||||
description: Path to the uAPI header, default is linux/${family-name}.h
|
description: Path to the uAPI header, default is linux/${family-name}.h
|
||||||
type: string
|
type: string
|
||||||
|
# Start genetlink-c
|
||||||
c-family-name:
|
c-family-name:
|
||||||
description: Name of the define for the family name.
|
description: Name of the define for the family name.
|
||||||
type: string
|
type: string
|
||||||
|
@ -218,6 +218,11 @@ properties:
|
||||||
description: Max length for a string or a binary attribute.
|
description: Max length for a string or a binary attribute.
|
||||||
$ref: '#/$defs/len-or-define'
|
$ref: '#/$defs/len-or-define'
|
||||||
sub-type: *attr-type
|
sub-type: *attr-type
|
||||||
|
# Start genetlink-legacy
|
||||||
|
struct:
|
||||||
|
description: Name of the struct type used for the attribute.
|
||||||
|
type: string
|
||||||
|
# End genetlink-legacy
|
||||||
|
|
||||||
# Make sure name-prefix does not appear in subsets (subsets inherit naming)
|
# Make sure name-prefix does not appear in subsets (subsets inherit naming)
|
||||||
dependencies:
|
dependencies:
|
||||||
|
@ -256,6 +261,14 @@ properties:
|
||||||
async-enum:
|
async-enum:
|
||||||
description: Name for the enum type with notifications/events.
|
description: Name for the enum type with notifications/events.
|
||||||
type: string
|
type: string
|
||||||
|
# Start genetlink-legacy
|
||||||
|
fixed-header: &fixed-header
|
||||||
|
description: |
|
||||||
|
Name of the structure defining the optional fixed-length protocol
|
||||||
|
header. This header is placed in a message after the netlink and
|
||||||
|
genetlink headers and before any attributes.
|
||||||
|
type: string
|
||||||
|
# End genetlink-legacy
|
||||||
list:
|
list:
|
||||||
description: List of commands
|
description: List of commands
|
||||||
type: array
|
type: array
|
||||||
|
@ -288,6 +301,9 @@ properties:
|
||||||
type: array
|
type: array
|
||||||
items:
|
items:
|
||||||
enum: [ strict, dump ]
|
enum: [ strict, dump ]
|
||||||
|
# Start genetlink-legacy
|
||||||
|
fixed-header: *fixed-header
|
||||||
|
# End genetlink-legacy
|
||||||
do: &subop-type
|
do: &subop-type
|
||||||
description: Main command handler.
|
description: Main command handler.
|
||||||
type: object
|
type: object
|
||||||
|
|
|
@ -33,6 +33,9 @@ properties:
|
||||||
protocol:
|
protocol:
|
||||||
description: Schema compatibility level. Default is "genetlink".
|
description: Schema compatibility level. Default is "genetlink".
|
||||||
enum: [ genetlink ]
|
enum: [ genetlink ]
|
||||||
|
uapi-header:
|
||||||
|
description: Path to the uAPI header, default is linux/${family-name}.h
|
||||||
|
type: string
|
||||||
|
|
||||||
definitions:
|
definitions:
|
||||||
description: List of type and constant definitions (enums, flags, defines).
|
description: List of type and constant definitions (enums, flags, defines).
|
||||||
|
|
198
Documentation/netlink/specs/devlink.yaml
Normal file
198
Documentation/netlink/specs/devlink.yaml
Normal file
|
@ -0,0 +1,198 @@
|
||||||
|
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
|
||||||
|
|
||||||
|
name: devlink
|
||||||
|
|
||||||
|
protocol: genetlink-legacy
|
||||||
|
|
||||||
|
doc: Partial family for Devlink.
|
||||||
|
|
||||||
|
attribute-sets:
|
||||||
|
-
|
||||||
|
name: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: bus-name
|
||||||
|
type: string
|
||||||
|
value: 1
|
||||||
|
-
|
||||||
|
name: dev-name
|
||||||
|
type: string
|
||||||
|
-
|
||||||
|
name: port-index
|
||||||
|
type: u32
|
||||||
|
|
||||||
|
# TODO: fill in the attributes in between
|
||||||
|
|
||||||
|
-
|
||||||
|
name: info-driver-name
|
||||||
|
type: string
|
||||||
|
value: 98
|
||||||
|
-
|
||||||
|
name: info-serial-number
|
||||||
|
type: string
|
||||||
|
-
|
||||||
|
name: info-version-fixed
|
||||||
|
type: nest
|
||||||
|
multi-attr: true
|
||||||
|
nested-attributes: dl-info-version
|
||||||
|
-
|
||||||
|
name: info-version-running
|
||||||
|
type: nest
|
||||||
|
multi-attr: true
|
||||||
|
nested-attributes: dl-info-version
|
||||||
|
-
|
||||||
|
name: info-version-stored
|
||||||
|
type: nest
|
||||||
|
multi-attr: true
|
||||||
|
nested-attributes: dl-info-version
|
||||||
|
-
|
||||||
|
name: info-version-name
|
||||||
|
type: string
|
||||||
|
-
|
||||||
|
name: info-version-value
|
||||||
|
type: string
|
||||||
|
|
||||||
|
# TODO: fill in the attributes in between
|
||||||
|
|
||||||
|
-
|
||||||
|
name: reload-failed
|
||||||
|
type: u8
|
||||||
|
value: 136
|
||||||
|
|
||||||
|
# TODO: fill in the attributes in between
|
||||||
|
|
||||||
|
-
|
||||||
|
name: reload-action
|
||||||
|
type: u8
|
||||||
|
value: 153
|
||||||
|
|
||||||
|
# TODO: fill in the attributes in between
|
||||||
|
|
||||||
|
-
|
||||||
|
name: dev-stats
|
||||||
|
type: nest
|
||||||
|
value: 156
|
||||||
|
nested-attributes: dl-dev-stats
|
||||||
|
-
|
||||||
|
name: reload-stats
|
||||||
|
type: nest
|
||||||
|
nested-attributes: dl-reload-stats
|
||||||
|
-
|
||||||
|
name: reload-stats-entry
|
||||||
|
type: nest
|
||||||
|
multi-attr: true
|
||||||
|
nested-attributes: dl-reload-stats-entry
|
||||||
|
-
|
||||||
|
name: reload-stats-limit
|
||||||
|
type: u8
|
||||||
|
-
|
||||||
|
name: reload-stats-value
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: remote-reload-stats
|
||||||
|
type: nest
|
||||||
|
nested-attributes: dl-reload-stats
|
||||||
|
-
|
||||||
|
name: reload-action-info
|
||||||
|
type: nest
|
||||||
|
nested-attributes: dl-reload-act-info
|
||||||
|
-
|
||||||
|
name: reload-action-stats
|
||||||
|
type: nest
|
||||||
|
nested-attributes: dl-reload-act-stats
|
||||||
|
-
|
||||||
|
name: dl-dev-stats
|
||||||
|
subset-of: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: reload-stats
|
||||||
|
type: nest
|
||||||
|
-
|
||||||
|
name: remote-reload-stats
|
||||||
|
type: nest
|
||||||
|
-
|
||||||
|
name: dl-reload-stats
|
||||||
|
subset-of: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: reload-action-info
|
||||||
|
type: nest
|
||||||
|
-
|
||||||
|
name: dl-reload-act-info
|
||||||
|
subset-of: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: reload-action
|
||||||
|
type: u8
|
||||||
|
-
|
||||||
|
name: reload-action-stats
|
||||||
|
type: nest
|
||||||
|
-
|
||||||
|
name: dl-reload-act-stats
|
||||||
|
subset-of: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: reload-stats-entry
|
||||||
|
type: nest
|
||||||
|
-
|
||||||
|
name: dl-reload-stats-entry
|
||||||
|
subset-of: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: reload-stats-limit
|
||||||
|
type: u8
|
||||||
|
-
|
||||||
|
name: reload-stats-value
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: dl-info-version
|
||||||
|
subset-of: devlink
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: info-version-name
|
||||||
|
type: string
|
||||||
|
-
|
||||||
|
name: info-version-value
|
||||||
|
type: string
|
||||||
|
|
||||||
|
operations:
|
||||||
|
enum-model: directional
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: get
|
||||||
|
doc: Get devlink instances.
|
||||||
|
attribute-set: devlink
|
||||||
|
|
||||||
|
do:
|
||||||
|
request:
|
||||||
|
value: 1
|
||||||
|
attributes: &dev-id-attrs
|
||||||
|
- bus-name
|
||||||
|
- dev-name
|
||||||
|
reply: &get-reply
|
||||||
|
value: 3
|
||||||
|
attributes:
|
||||||
|
- bus-name
|
||||||
|
- dev-name
|
||||||
|
- reload-failed
|
||||||
|
- reload-action
|
||||||
|
- dev-stats
|
||||||
|
dump:
|
||||||
|
reply: *get-reply
|
||||||
|
|
||||||
|
# TODO: fill in the operations in between
|
||||||
|
|
||||||
|
-
|
||||||
|
name: info-get
|
||||||
|
doc: Get device information, like driver name, hardware and firmware versions etc.
|
||||||
|
attribute-set: devlink
|
||||||
|
|
||||||
|
do:
|
||||||
|
request:
|
||||||
|
value: 51
|
||||||
|
attributes: *dev-id-attrs
|
||||||
|
reply:
|
||||||
|
value: 51
|
||||||
|
attributes:
|
||||||
|
- bus-name
|
||||||
|
- dev-name
|
File diff suppressed because it is too large
Load diff
124
Documentation/netlink/specs/handshake.yaml
Normal file
124
Documentation/netlink/specs/handshake.yaml
Normal file
|
@ -0,0 +1,124 @@
|
||||||
|
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
|
||||||
|
#
|
||||||
|
# Author: Chuck Lever <chuck.lever@oracle.com>
|
||||||
|
#
|
||||||
|
# Copyright (c) 2023, Oracle and/or its affiliates.
|
||||||
|
#
|
||||||
|
|
||||||
|
name: handshake
|
||||||
|
|
||||||
|
protocol: genetlink
|
||||||
|
|
||||||
|
doc: Netlink protocol to request a transport layer security handshake.
|
||||||
|
|
||||||
|
definitions:
|
||||||
|
-
|
||||||
|
type: enum
|
||||||
|
name: handler-class
|
||||||
|
value-start: 0
|
||||||
|
entries: [ none, tlshd, max ]
|
||||||
|
-
|
||||||
|
type: enum
|
||||||
|
name: msg-type
|
||||||
|
value-start: 0
|
||||||
|
entries: [ unspec, clienthello, serverhello ]
|
||||||
|
-
|
||||||
|
type: enum
|
||||||
|
name: auth
|
||||||
|
value-start: 0
|
||||||
|
entries: [ unspec, unauth, psk, x509 ]
|
||||||
|
|
||||||
|
attribute-sets:
|
||||||
|
-
|
||||||
|
name: x509
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: cert
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: privkey
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: accept
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: sockfd
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: handler-class
|
||||||
|
type: u32
|
||||||
|
enum: handler-class
|
||||||
|
-
|
||||||
|
name: message-type
|
||||||
|
type: u32
|
||||||
|
enum: msg-type
|
||||||
|
-
|
||||||
|
name: timeout
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: auth-mode
|
||||||
|
type: u32
|
||||||
|
enum: auth
|
||||||
|
-
|
||||||
|
name: peer-identity
|
||||||
|
type: u32
|
||||||
|
multi-attr: true
|
||||||
|
-
|
||||||
|
name: certificate
|
||||||
|
type: nest
|
||||||
|
nested-attributes: x509
|
||||||
|
multi-attr: true
|
||||||
|
-
|
||||||
|
name: done
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: status
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: sockfd
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: remote-auth
|
||||||
|
type: u32
|
||||||
|
multi-attr: true
|
||||||
|
|
||||||
|
operations:
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: ready
|
||||||
|
doc: Notify handlers that a new handshake request is waiting
|
||||||
|
notify: accept
|
||||||
|
-
|
||||||
|
name: accept
|
||||||
|
doc: Handler retrieves next queued handshake request
|
||||||
|
attribute-set: accept
|
||||||
|
flags: [ admin-perm ]
|
||||||
|
do:
|
||||||
|
request:
|
||||||
|
attributes:
|
||||||
|
- handler-class
|
||||||
|
reply:
|
||||||
|
attributes:
|
||||||
|
- sockfd
|
||||||
|
- message-type
|
||||||
|
- timeout
|
||||||
|
- auth-mode
|
||||||
|
- peer-identity
|
||||||
|
- certificate
|
||||||
|
-
|
||||||
|
name: done
|
||||||
|
doc: Handler reports handshake completion
|
||||||
|
attribute-set: done
|
||||||
|
do:
|
||||||
|
request:
|
||||||
|
attributes:
|
||||||
|
- status
|
||||||
|
- sockfd
|
||||||
|
- remote-auth
|
||||||
|
|
||||||
|
mcast-groups:
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: none
|
||||||
|
-
|
||||||
|
name: tlshd
|
153
Documentation/netlink/specs/ovs_datapath.yaml
Normal file
153
Documentation/netlink/specs/ovs_datapath.yaml
Normal file
|
@ -0,0 +1,153 @@
|
||||||
|
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
|
||||||
|
|
||||||
|
name: ovs_datapath
|
||||||
|
version: 2
|
||||||
|
protocol: genetlink-legacy
|
||||||
|
|
||||||
|
doc:
|
||||||
|
OVS datapath configuration over generic netlink.
|
||||||
|
|
||||||
|
definitions:
|
||||||
|
-
|
||||||
|
name: ovs-header
|
||||||
|
type: struct
|
||||||
|
members:
|
||||||
|
-
|
||||||
|
name: dp-ifindex
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: user-features
|
||||||
|
type: flags
|
||||||
|
entries:
|
||||||
|
-
|
||||||
|
name: unaligned
|
||||||
|
doc: Allow last Netlink attribute to be unaligned
|
||||||
|
-
|
||||||
|
name: vport-pids
|
||||||
|
doc: Allow datapath to associate multiple Netlink PIDs to each vport
|
||||||
|
-
|
||||||
|
name: tc-recirc-sharing
|
||||||
|
doc: Allow tc offload recirc sharing
|
||||||
|
-
|
||||||
|
name: dispatch-upcall-per-cpu
|
||||||
|
doc: Allow per-cpu dispatch of upcalls
|
||||||
|
-
|
||||||
|
name: datapath-stats
|
||||||
|
type: struct
|
||||||
|
members:
|
||||||
|
-
|
||||||
|
name: hit
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: missed
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: lost
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: flows
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: megaflow-stats
|
||||||
|
type: struct
|
||||||
|
members:
|
||||||
|
-
|
||||||
|
name: mask-hit
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: masks
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: padding
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: cache-hits
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: pad1
|
||||||
|
type: u64
|
||||||
|
|
||||||
|
attribute-sets:
|
||||||
|
-
|
||||||
|
name: datapath
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: name
|
||||||
|
type: string
|
||||||
|
-
|
||||||
|
name: upcall-pid
|
||||||
|
doc: upcall pid
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: stats
|
||||||
|
type: binary
|
||||||
|
struct: datapath-stats
|
||||||
|
-
|
||||||
|
name: megaflow-stats
|
||||||
|
type: binary
|
||||||
|
struct: megaflow-stats
|
||||||
|
-
|
||||||
|
name: user-features
|
||||||
|
type: u32
|
||||||
|
enum: user-features
|
||||||
|
enum-as-flags: true
|
||||||
|
-
|
||||||
|
name: pad
|
||||||
|
type: unused
|
||||||
|
-
|
||||||
|
name: masks-cache-size
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: per-cpu-pids
|
||||||
|
type: binary
|
||||||
|
sub-type: u32
|
||||||
|
|
||||||
|
operations:
|
||||||
|
fixed-header: ovs-header
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: dp-get
|
||||||
|
doc: Get / dump OVS data path configuration and state
|
||||||
|
value: 3
|
||||||
|
attribute-set: datapath
|
||||||
|
do: &dp-get-op
|
||||||
|
request:
|
||||||
|
attributes:
|
||||||
|
- name
|
||||||
|
reply:
|
||||||
|
attributes:
|
||||||
|
- name
|
||||||
|
- upcall-pid
|
||||||
|
- stats
|
||||||
|
- megaflow-stats
|
||||||
|
- user-features
|
||||||
|
- masks-cache-size
|
||||||
|
- per-cpu-pids
|
||||||
|
dump: *dp-get-op
|
||||||
|
-
|
||||||
|
name: dp-new
|
||||||
|
doc: Create new OVS data path
|
||||||
|
value: 1
|
||||||
|
attribute-set: datapath
|
||||||
|
do:
|
||||||
|
request:
|
||||||
|
attributes:
|
||||||
|
- dp-ifindex
|
||||||
|
- name
|
||||||
|
- upcall-pid
|
||||||
|
- user-features
|
||||||
|
-
|
||||||
|
name: dp-del
|
||||||
|
doc: Delete existing OVS data path
|
||||||
|
value: 2
|
||||||
|
attribute-set: datapath
|
||||||
|
do:
|
||||||
|
request:
|
||||||
|
attributes:
|
||||||
|
- dp-ifindex
|
||||||
|
- name
|
||||||
|
|
||||||
|
mcast-groups:
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: ovs_datapath
|
139
Documentation/netlink/specs/ovs_vport.yaml
Normal file
139
Documentation/netlink/specs/ovs_vport.yaml
Normal file
|
@ -0,0 +1,139 @@
|
||||||
|
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
|
||||||
|
|
||||||
|
name: ovs_vport
|
||||||
|
version: 2
|
||||||
|
protocol: genetlink-legacy
|
||||||
|
|
||||||
|
doc:
|
||||||
|
OVS vport configuration over generic netlink.
|
||||||
|
|
||||||
|
definitions:
|
||||||
|
-
|
||||||
|
name: ovs-header
|
||||||
|
type: struct
|
||||||
|
members:
|
||||||
|
-
|
||||||
|
name: dp-ifindex
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: vport-type
|
||||||
|
type: enum
|
||||||
|
entries: [ unspec, netdev, internal, gre, vxlan, geneve ]
|
||||||
|
-
|
||||||
|
name: vport-stats
|
||||||
|
type: struct
|
||||||
|
members:
|
||||||
|
-
|
||||||
|
name: rx-packets
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: tx-packets
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: rx-bytes
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: tx-bytes
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: rx-errors
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: tx-errors
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: rx-dropped
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: tx-dropped
|
||||||
|
type: u64
|
||||||
|
|
||||||
|
attribute-sets:
|
||||||
|
-
|
||||||
|
name: vport-options
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: dst-port
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: extension
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: upcall-stats
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: success
|
||||||
|
type: u64
|
||||||
|
value: 0
|
||||||
|
-
|
||||||
|
name: fail
|
||||||
|
type: u64
|
||||||
|
-
|
||||||
|
name: vport
|
||||||
|
attributes:
|
||||||
|
-
|
||||||
|
name: port-no
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: type
|
||||||
|
type: u32
|
||||||
|
enum: vport-type
|
||||||
|
-
|
||||||
|
name: name
|
||||||
|
type: string
|
||||||
|
-
|
||||||
|
name: options
|
||||||
|
type: nest
|
||||||
|
nested-attributes: vport-options
|
||||||
|
-
|
||||||
|
name: upcall-pid
|
||||||
|
type: binary
|
||||||
|
sub-type: u32
|
||||||
|
-
|
||||||
|
name: stats
|
||||||
|
type: binary
|
||||||
|
struct: vport-stats
|
||||||
|
-
|
||||||
|
name: pad
|
||||||
|
type: unused
|
||||||
|
-
|
||||||
|
name: ifindex
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: netnsid
|
||||||
|
type: u32
|
||||||
|
-
|
||||||
|
name: upcall-stats
|
||||||
|
type: nest
|
||||||
|
nested-attributes: upcall-stats
|
||||||
|
|
||||||
|
operations:
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: vport-get
|
||||||
|
doc: Get / dump OVS vport configuration and state
|
||||||
|
value: 3
|
||||||
|
attribute-set: vport
|
||||||
|
fixed-header: ovs-header
|
||||||
|
do: &vport-get-op
|
||||||
|
request:
|
||||||
|
attributes:
|
||||||
|
- dp-ifindex
|
||||||
|
- name
|
||||||
|
reply: &dev-all
|
||||||
|
attributes:
|
||||||
|
- dp-ifindex
|
||||||
|
- port-no
|
||||||
|
- type
|
||||||
|
- name
|
||||||
|
- upcall-pid
|
||||||
|
- stats
|
||||||
|
- ifindex
|
||||||
|
- netnsid
|
||||||
|
- upcall-stats
|
||||||
|
dump: *vport-get-op
|
||||||
|
|
||||||
|
mcast-groups:
|
||||||
|
list:
|
||||||
|
-
|
||||||
|
name: ovs_vport
|
|
@ -229,8 +229,7 @@ frames for a while. This has a potential to avoid the costly round of
|
||||||
enabling interrupts, handling an incoming IRQ in ISR, re-enabling the
|
enabling interrupts, handling an incoming IRQ in ISR, re-enabling the
|
||||||
softirq and switching context back to softirq.
|
softirq and switching context back to softirq.
|
||||||
|
|
||||||
More detailed documentation of NAPI may be found on the pages of Linux
|
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
|
||||||
Foundation `<https://wiki.linuxfoundation.org/networking/napi>`_.
|
|
||||||
|
|
||||||
Integrating the core to Xilinx Zynq
|
Integrating the core to Xilinx Zynq
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
|
|
|
@ -0,0 +1,139 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0+
|
||||||
|
|
||||||
|
========================================================
|
||||||
|
Linux Driver for the AMD/Pensando(R) DSC adapter family
|
||||||
|
========================================================
|
||||||
|
|
||||||
|
Copyright(c) 2023 Advanced Micro Devices, Inc
|
||||||
|
|
||||||
|
Identifying the Adapter
|
||||||
|
=======================
|
||||||
|
|
||||||
|
To find if one or more AMD/Pensando PCI Core devices are installed on the
|
||||||
|
host, check for the PCI devices::
|
||||||
|
|
||||||
|
# lspci -d 1dd8:100c
|
||||||
|
b5:00.0 Processing accelerators: Pensando Systems Device 100c
|
||||||
|
b6:00.0 Processing accelerators: Pensando Systems Device 100c
|
||||||
|
|
||||||
|
If such devices are listed as above, then the pds_core.ko driver should find
|
||||||
|
and configure them for use. There should be log entries in the kernel
|
||||||
|
messages such as these::
|
||||||
|
|
||||||
|
$ dmesg | grep pds_core
|
||||||
|
pds_core 0000:b5:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link)
|
||||||
|
pds_core 0000:b5:00.0: FW: 1.60.0-73
|
||||||
|
pds_core 0000:b6:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link)
|
||||||
|
pds_core 0000:b6:00.0: FW: 1.60.0-73
|
||||||
|
|
||||||
|
Driver and firmware version information can be gathered with devlink::
|
||||||
|
|
||||||
|
$ devlink dev info pci/0000:b5:00.0
|
||||||
|
pci/0000:b5:00.0:
|
||||||
|
driver pds_core
|
||||||
|
serial_number FLM18420073
|
||||||
|
versions:
|
||||||
|
fixed:
|
||||||
|
asic.id 0x0
|
||||||
|
asic.rev 0x0
|
||||||
|
running:
|
||||||
|
fw 1.51.0-73
|
||||||
|
stored:
|
||||||
|
fw.goldfw 1.15.9-C-22
|
||||||
|
fw.mainfwa 1.60.0-73
|
||||||
|
fw.mainfwb 1.60.0-57
|
||||||
|
|
||||||
|
Info versions
|
||||||
|
=============
|
||||||
|
|
||||||
|
The ``pds_core`` driver reports the following versions
|
||||||
|
|
||||||
|
.. list-table:: devlink info versions implemented
|
||||||
|
:widths: 5 5 90
|
||||||
|
|
||||||
|
* - Name
|
||||||
|
- Type
|
||||||
|
- Description
|
||||||
|
* - ``fw``
|
||||||
|
- running
|
||||||
|
- Version of firmware running on the device
|
||||||
|
* - ``fw.goldfw``
|
||||||
|
- stored
|
||||||
|
- Version of firmware stored in the goldfw slot
|
||||||
|
* - ``fw.mainfwa``
|
||||||
|
- stored
|
||||||
|
- Version of firmware stored in the mainfwa slot
|
||||||
|
* - ``fw.mainfwb``
|
||||||
|
- stored
|
||||||
|
- Version of firmware stored in the mainfwb slot
|
||||||
|
* - ``asic.id``
|
||||||
|
- fixed
|
||||||
|
- The ASIC type for this device
|
||||||
|
* - ``asic.rev``
|
||||||
|
- fixed
|
||||||
|
- The revision of the ASIC for this device
|
||||||
|
|
||||||
|
Parameters
|
||||||
|
==========
|
||||||
|
|
||||||
|
The ``pds_core`` driver implements the following generic
|
||||||
|
parameters for controlling the functionality to be made available
|
||||||
|
as auxiliary_bus devices.
|
||||||
|
|
||||||
|
.. list-table:: Generic parameters implemented
|
||||||
|
:widths: 5 5 8 82
|
||||||
|
|
||||||
|
* - Name
|
||||||
|
- Mode
|
||||||
|
- Type
|
||||||
|
- Description
|
||||||
|
* - ``enable_vnet``
|
||||||
|
- runtime
|
||||||
|
- Boolean
|
||||||
|
- Enables vDPA functionality through an auxiliary_bus device
|
||||||
|
|
||||||
|
Firmware Management
|
||||||
|
===================
|
||||||
|
|
||||||
|
The ``flash`` command can update a the DSC firmware. The downloaded firmware
|
||||||
|
will be saved into either of firmware bank 1 or bank 2, whichever is not
|
||||||
|
currently in use, and that bank will used for the next boot::
|
||||||
|
|
||||||
|
# devlink dev flash pci/0000:b5:00.0 \
|
||||||
|
file pensando/dsc_fw_1.63.0-22.tar
|
||||||
|
|
||||||
|
Health Reporters
|
||||||
|
================
|
||||||
|
|
||||||
|
The driver supports a devlink health reporter for FW status::
|
||||||
|
|
||||||
|
# devlink health show pci/0000:2b:00.0 reporter fw
|
||||||
|
pci/0000:2b:00.0:
|
||||||
|
reporter fw
|
||||||
|
state healthy error 0 recover 0
|
||||||
|
# devlink health diagnose pci/0000:2b:00.0 reporter fw
|
||||||
|
Status: healthy State: 1 Generation: 0 Recoveries: 0
|
||||||
|
|
||||||
|
Enabling the driver
|
||||||
|
===================
|
||||||
|
|
||||||
|
The driver is enabled via the standard kernel configuration system,
|
||||||
|
using the make command::
|
||||||
|
|
||||||
|
make oldconfig/menuconfig/etc.
|
||||||
|
|
||||||
|
The driver is located in the menu structure at:
|
||||||
|
|
||||||
|
-> Device Drivers
|
||||||
|
-> Network device support (NETDEVICES [=y])
|
||||||
|
-> Ethernet driver support
|
||||||
|
-> AMD devices
|
||||||
|
-> AMD/Pensando Ethernet PDS_CORE Support
|
||||||
|
|
||||||
|
Support
|
||||||
|
=======
|
||||||
|
|
||||||
|
For general Linux networking support, please use the netdev mailing
|
||||||
|
list, which is monitored by AMD/Pensando personnel::
|
||||||
|
|
||||||
|
netdev@vger.kernel.org
|
|
@ -14,6 +14,7 @@ Contents:
|
||||||
3com/vortex
|
3com/vortex
|
||||||
amazon/ena
|
amazon/ena
|
||||||
altera/altera_tse
|
altera/altera_tse
|
||||||
|
amd/pds_core
|
||||||
aquantia/atlantic
|
aquantia/atlantic
|
||||||
chelsio/cxgb
|
chelsio/cxgb
|
||||||
cirrus/cs89x0
|
cirrus/cs89x0
|
||||||
|
@ -31,7 +32,6 @@ Contents:
|
||||||
intel/fm10k
|
intel/fm10k
|
||||||
intel/igb
|
intel/igb
|
||||||
intel/igbvf
|
intel/igbvf
|
||||||
intel/ixgb
|
|
||||||
intel/ixgbe
|
intel/ixgbe
|
||||||
intel/ixgbevf
|
intel/ixgbevf
|
||||||
intel/i40e
|
intel/i40e
|
||||||
|
|
|
@ -151,8 +151,7 @@ NAPI
|
||||||
|
|
||||||
NAPI (Rx polling mode) is supported in the e100 driver.
|
NAPI (Rx polling mode) is supported in the e100 driver.
|
||||||
|
|
||||||
See https://wiki.linuxfoundation.org/networking/napi for more
|
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
|
||||||
information on NAPI.
|
|
||||||
|
|
||||||
Multiple Interfaces on Same Ethernet Broadcast Network
|
Multiple Interfaces on Same Ethernet Broadcast Network
|
||||||
------------------------------------------------------
|
------------------------------------------------------
|
||||||
|
@ -181,8 +180,6 @@ Support
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
http://sourceforge.net/projects/e1000
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -451,13 +451,8 @@ Support
|
||||||
=======
|
=======
|
||||||
|
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
http://support.intel.com
|
||||||
http://support.intel.com
|
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
http://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on the supported
|
If an issue is identified with the released source code on the supported
|
||||||
kernel with a supported adapter, email the specific information related
|
kernel with a supported adapter, email the specific information related
|
||||||
to the issue to e1000-devel@lists.sf.net
|
to the issue to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -371,13 +371,8 @@ NOTE: Wake on LAN is only supported on port A for the following devices:
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -130,13 +130,8 @@ the Intel Ethernet Controller XL710.
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -399,8 +399,8 @@ operate only in full duplex and only at their native speed.
|
||||||
NAPI
|
NAPI
|
||||||
----
|
----
|
||||||
NAPI (Rx polling mode) is supported in the i40e driver.
|
NAPI (Rx polling mode) is supported in the i40e driver.
|
||||||
For more information on NAPI, see
|
|
||||||
https://wiki.linuxfoundation.org/networking/napi
|
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
|
||||||
|
|
||||||
Flow Control
|
Flow Control
|
||||||
------------
|
------------
|
||||||
|
@ -759,13 +759,8 @@ enabled when setting up DCB on your switch.
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -319,13 +319,8 @@ This is caused by the way the Linux kernel reports this stressed condition.
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://support.intel.com
|
https://support.intel.com
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on the supported kernel
|
If an issue is identified with the released source code on the supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -817,10 +817,10 @@ NOTE:
|
||||||
|
|
||||||
NAPI
|
NAPI
|
||||||
----
|
----
|
||||||
This driver supports NAPI (Rx polling mode).
|
|
||||||
For more information on NAPI, see
|
|
||||||
https://wiki.linuxfoundation.org/networking/napi
|
|
||||||
|
|
||||||
|
This driver supports NAPI (Rx polling mode).
|
||||||
|
|
||||||
|
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
|
||||||
|
|
||||||
MACVLAN
|
MACVLAN
|
||||||
-------
|
-------
|
||||||
|
@ -1026,12 +1026,9 @@ Support
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
||||||
|
|
||||||
Trademarks
|
Trademarks
|
||||||
|
|
|
@ -201,13 +201,8 @@ NOTE: This feature is exclusive to i210 models.
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -53,13 +53,8 @@ https://www.kernel.org/pub/software/network/ethtool/
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
|
@ -1,468 +0,0 @@
|
||||||
.. SPDX-License-Identifier: GPL-2.0+
|
|
||||||
|
|
||||||
=====================================================================
|
|
||||||
Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection
|
|
||||||
=====================================================================
|
|
||||||
|
|
||||||
October 1, 2018
|
|
||||||
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
- In This Release
|
|
||||||
- Identifying Your Adapter
|
|
||||||
- Command Line Parameters
|
|
||||||
- Improving Performance
|
|
||||||
- Additional Configurations
|
|
||||||
- Known Issues/Troubleshooting
|
|
||||||
- Support
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
In This Release
|
|
||||||
===============
|
|
||||||
|
|
||||||
This file describes the ixgb Linux Base Driver for the 10 Gigabit Intel(R)
|
|
||||||
Network Connection. This driver includes support for Itanium(R)2-based
|
|
||||||
systems.
|
|
||||||
|
|
||||||
For questions related to hardware requirements, refer to the documentation
|
|
||||||
supplied with your 10 Gigabit adapter. All hardware requirements listed apply
|
|
||||||
to use with Linux.
|
|
||||||
|
|
||||||
The following features are available in this kernel:
|
|
||||||
- Native VLANs
|
|
||||||
- Channel Bonding (teaming)
|
|
||||||
- SNMP
|
|
||||||
|
|
||||||
Channel Bonding documentation can be found in the Linux kernel source:
|
|
||||||
/Documentation/networking/bonding.rst
|
|
||||||
|
|
||||||
The driver information previously displayed in the /proc filesystem is not
|
|
||||||
supported in this release. Alternatively, you can use ethtool (version 1.6
|
|
||||||
or later), lspci, and iproute2 to obtain the same information.
|
|
||||||
|
|
||||||
Instructions on updating ethtool can be found in the section "Additional
|
|
||||||
Configurations" later in this document.
|
|
||||||
|
|
||||||
|
|
||||||
Identifying Your Adapter
|
|
||||||
========================
|
|
||||||
|
|
||||||
The following Intel network adapters are compatible with the drivers in this
|
|
||||||
release:
|
|
||||||
|
|
||||||
+------------+------------------------------+----------------------------------+
|
|
||||||
| Controller | Adapter Name | Physical Layer |
|
|
||||||
+============+==============================+==================================+
|
|
||||||
| 82597EX | Intel(R) PRO/10GbE LR/SR/CX4 | - 10G Base-LR (fiber) |
|
|
||||||
| | Server Adapters | - 10G Base-SR (fiber) |
|
|
||||||
| | | - 10G Base-CX4 (copper) |
|
|
||||||
+------------+------------------------------+----------------------------------+
|
|
||||||
|
|
||||||
For more information on how to identify your adapter, go to the Adapter &
|
|
||||||
Driver ID Guide at:
|
|
||||||
|
|
||||||
https://support.intel.com
|
|
||||||
|
|
||||||
|
|
||||||
Command Line Parameters
|
|
||||||
=======================
|
|
||||||
|
|
||||||
If the driver is built as a module, the following optional parameters are
|
|
||||||
used by entering them on the command line with the modprobe command using
|
|
||||||
this syntax::
|
|
||||||
|
|
||||||
modprobe ixgb [<option>=<VAL1>,<VAL2>,...]
|
|
||||||
|
|
||||||
For example, with two 10GbE PCI adapters, entering::
|
|
||||||
|
|
||||||
modprobe ixgb TxDescriptors=80,128
|
|
||||||
|
|
||||||
loads the ixgb driver with 80 TX resources for the first adapter and 128 TX
|
|
||||||
resources for the second adapter.
|
|
||||||
|
|
||||||
The default value for each parameter is generally the recommended setting,
|
|
||||||
unless otherwise noted.
|
|
||||||
|
|
||||||
Copybreak
|
|
||||||
---------
|
|
||||||
:Valid Range: 0-XXXX
|
|
||||||
:Default Value: 256
|
|
||||||
|
|
||||||
This is the maximum size of packet that is copied to a new buffer on
|
|
||||||
receive.
|
|
||||||
|
|
||||||
Debug
|
|
||||||
-----
|
|
||||||
:Valid Range: 0-16 (0=none,...,16=all)
|
|
||||||
:Default Value: 0
|
|
||||||
|
|
||||||
This parameter adjusts the level of debug messages displayed in the
|
|
||||||
system logs.
|
|
||||||
|
|
||||||
FlowControl
|
|
||||||
-----------
|
|
||||||
:Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
|
|
||||||
:Default Value: 1 if no EEPROM, otherwise read from EEPROM
|
|
||||||
|
|
||||||
This parameter controls the automatic generation(Tx) and response(Rx) to
|
|
||||||
Ethernet PAUSE frames. There are hardware bugs associated with enabling
|
|
||||||
Tx flow control so beware.
|
|
||||||
|
|
||||||
RxDescriptors
|
|
||||||
-------------
|
|
||||||
:Valid Range: 64-4096
|
|
||||||
:Default Value: 1024
|
|
||||||
|
|
||||||
This value is the number of receive descriptors allocated by the driver.
|
|
||||||
Increasing this value allows the driver to buffer more incoming packets.
|
|
||||||
Each descriptor is 16 bytes. A receive buffer is also allocated for
|
|
||||||
each descriptor and can be either 2048, 4056, 8192, or 16384 bytes,
|
|
||||||
depending on the MTU setting. When the MTU size is 1500 or less, the
|
|
||||||
receive buffer size is 2048 bytes. When the MTU is greater than 1500 the
|
|
||||||
receive buffer size will be either 4056, 8192, or 16384 bytes. The
|
|
||||||
maximum MTU size is 16114.
|
|
||||||
|
|
||||||
TxDescriptors
|
|
||||||
-------------
|
|
||||||
:Valid Range: 64-4096
|
|
||||||
:Default Value: 256
|
|
||||||
|
|
||||||
This value is the number of transmit descriptors allocated by the driver.
|
|
||||||
Increasing this value allows the driver to queue more transmits. Each
|
|
||||||
descriptor is 16 bytes.
|
|
||||||
|
|
||||||
RxIntDelay
|
|
||||||
----------
|
|
||||||
:Valid Range: 0-65535 (0=off)
|
|
||||||
:Default Value: 72
|
|
||||||
|
|
||||||
This value delays the generation of receive interrupts in units of
|
|
||||||
0.8192 microseconds. Receive interrupt reduction can improve CPU
|
|
||||||
efficiency if properly tuned for specific network traffic. Increasing
|
|
||||||
this value adds extra latency to frame reception and can end up
|
|
||||||
decreasing the throughput of TCP traffic. If the system is reporting
|
|
||||||
dropped receives, this value may be set too high, causing the driver to
|
|
||||||
run out of available receive descriptors.
|
|
||||||
|
|
||||||
TxIntDelay
|
|
||||||
----------
|
|
||||||
:Valid Range: 0-65535 (0=off)
|
|
||||||
:Default Value: 32
|
|
||||||
|
|
||||||
This value delays the generation of transmit interrupts in units of
|
|
||||||
0.8192 microseconds. Transmit interrupt reduction can improve CPU
|
|
||||||
efficiency if properly tuned for specific network traffic. Increasing
|
|
||||||
this value adds extra latency to frame transmission and can end up
|
|
||||||
decreasing the throughput of TCP traffic. If this value is set too high,
|
|
||||||
it will cause the driver to run out of available transmit descriptors.
|
|
||||||
|
|
||||||
XsumRX
|
|
||||||
------
|
|
||||||
:Valid Range: 0-1
|
|
||||||
:Default Value: 1
|
|
||||||
|
|
||||||
A value of '1' indicates that the driver should enable IP checksum
|
|
||||||
offload for received packets (both UDP and TCP) to the adapter hardware.
|
|
||||||
|
|
||||||
RxFCHighThresh
|
|
||||||
--------------
|
|
||||||
:Valid Range: 1,536-262,136 (0x600 - 0x3FFF8, 8 byte granularity)
|
|
||||||
:Default Value: 196,608 (0x30000)
|
|
||||||
|
|
||||||
Receive Flow control high threshold (when we send a pause frame)
|
|
||||||
|
|
||||||
RxFCLowThresh
|
|
||||||
-------------
|
|
||||||
:Valid Range: 64-262,136 (0x40 - 0x3FFF8, 8 byte granularity)
|
|
||||||
:Default Value: 163,840 (0x28000)
|
|
||||||
|
|
||||||
Receive Flow control low threshold (when we send a resume frame)
|
|
||||||
|
|
||||||
FCReqTimeout
|
|
||||||
------------
|
|
||||||
:Valid Range: 1-65535
|
|
||||||
:Default Value: 65535
|
|
||||||
|
|
||||||
Flow control request timeout (how long to pause the link partner's tx)
|
|
||||||
|
|
||||||
IntDelayEnable
|
|
||||||
--------------
|
|
||||||
:Value Range: 0,1
|
|
||||||
:Default Value: 1
|
|
||||||
|
|
||||||
Interrupt Delay, 0 disables transmit interrupt delay and 1 enables it.
|
|
||||||
|
|
||||||
|
|
||||||
Improving Performance
|
|
||||||
=====================
|
|
||||||
|
|
||||||
With the 10 Gigabit server adapters, the default Linux configuration will
|
|
||||||
very likely limit the total available throughput artificially. There is a set
|
|
||||||
of configuration changes that, when applied together, will increase the ability
|
|
||||||
of Linux to transmit and receive data. The following enhancements were
|
|
||||||
originally acquired from settings published at https://www.spec.org/web99/ for
|
|
||||||
various submitted results using Linux.
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
These changes are only suggestions, and serve as a starting point for
|
|
||||||
tuning your network performance.
|
|
||||||
|
|
||||||
The changes are made in three major ways, listed in order of greatest effect:
|
|
||||||
|
|
||||||
- Use ip link to modify the mtu (maximum transmission unit) and the txqueuelen
|
|
||||||
parameter.
|
|
||||||
- Use sysctl to modify /proc parameters (essentially kernel tuning)
|
|
||||||
- Use setpci to modify the MMRBC field in PCI-X configuration space to increase
|
|
||||||
transmit burst lengths on the bus.
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
setpci modifies the adapter's configuration registers to allow it to read
|
|
||||||
up to 4k bytes at a time (for transmits). However, for some systems the
|
|
||||||
behavior after modifying this register may be undefined (possibly errors of
|
|
||||||
some kind). A power-cycle, hard reset or explicitly setting the e6 register
|
|
||||||
back to 22 (setpci -d 8086:1a48 e6.b=22) may be required to get back to a
|
|
||||||
stable configuration.
|
|
||||||
|
|
||||||
- COPY these lines and paste them into ixgb_perf.sh:
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
#!/bin/bash
|
|
||||||
echo "configuring network performance , edit this file to change the interface
|
|
||||||
or device ID of 10GbE card"
|
|
||||||
# set mmrbc to 4k reads, modify only Intel 10GbE device IDs
|
|
||||||
# replace 1a48 with appropriate 10GbE device's ID installed on the system,
|
|
||||||
# if needed.
|
|
||||||
setpci -d 8086:1a48 e6.b=2e
|
|
||||||
# set the MTU (max transmission unit) - it requires your switch and clients
|
|
||||||
# to change as well.
|
|
||||||
# set the txqueuelen
|
|
||||||
# your ixgb adapter should be loaded as eth1 for this to work, change if needed
|
|
||||||
ip li set dev eth1 mtu 9000 txqueuelen 1000 up
|
|
||||||
# call the sysctl utility to modify /proc/sys entries
|
|
||||||
sysctl -p ./sysctl_ixgb.conf
|
|
||||||
|
|
||||||
- COPY these lines and paste them into sysctl_ixgb.conf:
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
# some of the defaults may be different for your kernel
|
|
||||||
# call this file with sysctl -p <this file>
|
|
||||||
# these are just suggested values that worked well to increase throughput in
|
|
||||||
# several network benchmark tests, your mileage may vary
|
|
||||||
|
|
||||||
### IPV4 specific settings
|
|
||||||
# turn TCP timestamp support off, default 1, reduces CPU use
|
|
||||||
net.ipv4.tcp_timestamps = 0
|
|
||||||
# turn SACK support off, default on
|
|
||||||
# on systems with a VERY fast bus -> memory interface this is the big gainer
|
|
||||||
net.ipv4.tcp_sack = 0
|
|
||||||
# set min/default/max TCP read buffer, default 4096 87380 174760
|
|
||||||
net.ipv4.tcp_rmem = 10000000 10000000 10000000
|
|
||||||
# set min/pressure/max TCP write buffer, default 4096 16384 131072
|
|
||||||
net.ipv4.tcp_wmem = 10000000 10000000 10000000
|
|
||||||
# set min/pressure/max TCP buffer space, default 31744 32256 32768
|
|
||||||
net.ipv4.tcp_mem = 10000000 10000000 10000000
|
|
||||||
|
|
||||||
### CORE settings (mostly for socket and UDP effect)
|
|
||||||
# set maximum receive socket buffer size, default 131071
|
|
||||||
net.core.rmem_max = 524287
|
|
||||||
# set maximum send socket buffer size, default 131071
|
|
||||||
net.core.wmem_max = 524287
|
|
||||||
# set default receive socket buffer size, default 65535
|
|
||||||
net.core.rmem_default = 524287
|
|
||||||
# set default send socket buffer size, default 65535
|
|
||||||
net.core.wmem_default = 524287
|
|
||||||
# set maximum amount of option memory buffers, default 10240
|
|
||||||
net.core.optmem_max = 524287
|
|
||||||
# set number of unprocessed input packets before kernel starts dropping them; default 300
|
|
||||||
net.core.netdev_max_backlog = 300000
|
|
||||||
|
|
||||||
Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface
|
|
||||||
your ixgb driver is using and/or replace '1a48' with appropriate 10GbE device's
|
|
||||||
ID installed on the system.
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
Unless these scripts are added to the boot process, these changes will
|
|
||||||
only last only until the next system reboot.
|
|
||||||
|
|
||||||
|
|
||||||
Resolving Slow UDP Traffic
|
|
||||||
--------------------------
|
|
||||||
If your server does not seem to be able to receive UDP traffic as fast as it
|
|
||||||
can receive TCP traffic, it could be because Linux, by default, does not set
|
|
||||||
the network stack buffers as large as they need to be to support high UDP
|
|
||||||
transfer rates. One way to alleviate this problem is to allow more memory to
|
|
||||||
be used by the IP stack to store incoming data.
|
|
||||||
|
|
||||||
For instance, use the commands::
|
|
||||||
|
|
||||||
sysctl -w net.core.rmem_max=262143
|
|
||||||
|
|
||||||
and::
|
|
||||||
|
|
||||||
sysctl -w net.core.rmem_default=262143
|
|
||||||
|
|
||||||
to increase the read buffer memory max and default to 262143 (256k - 1) from
|
|
||||||
defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables
|
|
||||||
will increase the amount of memory used by the network stack for receives, and
|
|
||||||
can be increased significantly more if necessary for your application.
|
|
||||||
|
|
||||||
|
|
||||||
Additional Configurations
|
|
||||||
=========================
|
|
||||||
|
|
||||||
Configuring the Driver on Different Distributions
|
|
||||||
-------------------------------------------------
|
|
||||||
Configuring a network driver to load properly when the system is started is
|
|
||||||
distribution dependent. Typically, the configuration process involves adding
|
|
||||||
an alias line to /etc/modprobe.conf as well as editing other system startup
|
|
||||||
scripts and/or configuration files. Many popular Linux distributions ship
|
|
||||||
with tools to make these changes for you. To learn the proper way to
|
|
||||||
configure a network device for your system, refer to your distribution
|
|
||||||
documentation. If during this process you are asked for the driver or module
|
|
||||||
name, the name for the Linux Base Driver for the Intel 10GbE Family of
|
|
||||||
Adapters is ixgb.
|
|
||||||
|
|
||||||
Viewing Link Messages
|
|
||||||
---------------------
|
|
||||||
Link messages will not be displayed to the console if the distribution is
|
|
||||||
restricting system messages. In order to see network driver link messages on
|
|
||||||
your console, set dmesg to eight by entering the following::
|
|
||||||
|
|
||||||
dmesg -n 8
|
|
||||||
|
|
||||||
NOTE: This setting is not saved across reboots.
|
|
||||||
|
|
||||||
Jumbo Frames
|
|
||||||
------------
|
|
||||||
The driver supports Jumbo Frames for all adapters. Jumbo Frames support is
|
|
||||||
enabled by changing the MTU to a value larger than the default of 1500.
|
|
||||||
The maximum value for the MTU is 16114. Use the ip command to
|
|
||||||
increase the MTU size. For example::
|
|
||||||
|
|
||||||
ip li set dev ethx mtu 9000
|
|
||||||
|
|
||||||
The maximum MTU setting for Jumbo Frames is 16114. This value coincides
|
|
||||||
with the maximum Jumbo Frames size of 16128.
|
|
||||||
|
|
||||||
Ethtool
|
|
||||||
-------
|
|
||||||
The driver utilizes the ethtool interface for driver configuration and
|
|
||||||
diagnostics, as well as displaying statistical information. The ethtool
|
|
||||||
version 1.6 or later is required for this functionality.
|
|
||||||
|
|
||||||
The latest release of ethtool can be found from
|
|
||||||
https://www.kernel.org/pub/software/network/ethtool/
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
The ethtool version 1.6 only supports a limited set of ethtool options.
|
|
||||||
Support for a more complete ethtool feature set can be enabled by
|
|
||||||
upgrading to the latest version.
|
|
||||||
|
|
||||||
NAPI
|
|
||||||
----
|
|
||||||
NAPI (Rx polling mode) is supported in the ixgb driver.
|
|
||||||
|
|
||||||
See https://wiki.linuxfoundation.org/networking/napi for more information on
|
|
||||||
NAPI.
|
|
||||||
|
|
||||||
|
|
||||||
Known Issues/Troubleshooting
|
|
||||||
============================
|
|
||||||
|
|
||||||
NOTE:
|
|
||||||
After installing the driver, if your Intel Network Connection is not
|
|
||||||
working, verify in the "In This Release" section of the readme that you have
|
|
||||||
installed the correct driver.
|
|
||||||
|
|
||||||
Cable Interoperability Issue with Fujitsu XENPAK Module in SmartBits Chassis
|
|
||||||
----------------------------------------------------------------------------
|
|
||||||
Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4
|
|
||||||
Server adapter is connected to a Fujitsu XENPAK CX4 module in a SmartBits
|
|
||||||
chassis using 15 m/24AWG cable assemblies manufactured by Fujitsu or Leoni.
|
|
||||||
The CRC errors may be received either by the Intel(R) PRO/10GbE CX4
|
|
||||||
Server adapter or the SmartBits. If this situation occurs using a different
|
|
||||||
cable assembly may resolve the issue.
|
|
||||||
|
|
||||||
Cable Interoperability Issues with HP Procurve 3400cl Switch Port
|
|
||||||
-----------------------------------------------------------------
|
|
||||||
Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 Server
|
|
||||||
adapter is connected to an HP Procurve 3400cl switch port using short cables
|
|
||||||
(1 m or shorter). If this situation occurs, using a longer cable may resolve
|
|
||||||
the issue.
|
|
||||||
|
|
||||||
Excessive CRC errors may be observed using Fujitsu 24AWG cable assemblies that
|
|
||||||
Are 10 m or longer or where using a Leoni 15 m/24AWG cable assembly. The CRC
|
|
||||||
errors may be received either by the CX4 Server adapter or at the switch. If
|
|
||||||
this situation occurs, using a different cable assembly may resolve the issue.
|
|
||||||
|
|
||||||
Jumbo Frames System Requirement
|
|
||||||
-------------------------------
|
|
||||||
Memory allocation failures have been observed on Linux systems with 64 MB
|
|
||||||
of RAM or less that are running Jumbo Frames. If you are using Jumbo
|
|
||||||
Frames, your system may require more than the advertised minimum
|
|
||||||
requirement of 64 MB of system memory.
|
|
||||||
|
|
||||||
Performance Degradation with Jumbo Frames
|
|
||||||
-----------------------------------------
|
|
||||||
Degradation in throughput performance may be observed in some Jumbo frames
|
|
||||||
environments. If this is observed, increasing the application's socket buffer
|
|
||||||
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
|
|
||||||
See the specific application manual and /usr/src/linux*/Documentation/
|
|
||||||
networking/ip-sysctl.txt for more details.
|
|
||||||
|
|
||||||
Allocating Rx Buffers when Using Jumbo Frames
|
|
||||||
---------------------------------------------
|
|
||||||
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
|
|
||||||
the available memory is heavily fragmented. This issue may be seen with PCI-X
|
|
||||||
adapters or with packet split disabled. This can be reduced or eliminated
|
|
||||||
by changing the amount of available memory for receive buffer allocation, by
|
|
||||||
increasing /proc/sys/vm/min_free_kbytes.
|
|
||||||
|
|
||||||
Multiple Interfaces on Same Ethernet Broadcast Network
|
|
||||||
------------------------------------------------------
|
|
||||||
Due to the default ARP behavior on Linux, it is not possible to have
|
|
||||||
one system on two IP networks in the same Ethernet broadcast domain
|
|
||||||
(non-partitioned switch) behave as expected. All Ethernet interfaces
|
|
||||||
will respond to IP traffic for any IP address assigned to the system.
|
|
||||||
This results in unbalanced receive traffic.
|
|
||||||
|
|
||||||
If you have multiple interfaces in a server, do either of the following:
|
|
||||||
|
|
||||||
- Turn on ARP filtering by entering::
|
|
||||||
|
|
||||||
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
|
|
||||||
|
|
||||||
- Install the interfaces in separate broadcast domains - either in
|
|
||||||
different switches or in a switch partitioned to VLANs.
|
|
||||||
|
|
||||||
UDP Stress Test Dropped Packet Issue
|
|
||||||
--------------------------------------
|
|
||||||
Under small packets UDP stress test with 10GbE driver, the Linux system
|
|
||||||
may drop UDP packets due to the fullness of socket buffers. You may want
|
|
||||||
to change the driver's Flow Control variables to the minimum value for
|
|
||||||
controlling packet reception.
|
|
||||||
|
|
||||||
Tx Hangs Possible Under Stress
|
|
||||||
------------------------------
|
|
||||||
Under stress conditions, if TX hangs occur, turning off TSO
|
|
||||||
"ethtool -K eth0 tso off" may resolve the problem.
|
|
||||||
|
|
||||||
|
|
||||||
Support
|
|
||||||
=======
|
|
||||||
For general information, go to the Intel support website at:
|
|
||||||
|
|
||||||
https://www.intel.com/support/
|
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
|
||||||
with a supported adapter, email the specific information related to the issue
|
|
||||||
to e1000-devel@lists.sf.net
|
|
|
@ -545,13 +545,8 @@ on the Intel Ethernet Controller XL710.
|
||||||
Support
|
Support
|
||||||
=======
|
=======
|
||||||
For general information, go to the Intel support website at:
|
For general information, go to the Intel support website at:
|
||||||
|
|
||||||
https://www.intel.com/support/
|
https://www.intel.com/support/
|
||||||
|
|
||||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
|
||||||
|
|
||||||
https://sourceforge.net/projects/e1000
|
|
||||||
|
|
||||||
If an issue is identified with the released source code on a supported kernel
|
If an issue is identified with the released source code on a supported kernel
|
||||||
with a supported adapter, email the specific information related to the issue
|
with a supported adapter, email the specific information related to the issue
|
||||||
to e1000-devel@lists.sf.net.
|
to intel-wired-lan@lists.osuosl.org.
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue