mirror of
https://github.com/torvalds/linux.git
synced 2026-07-27 09:36:22 +02:00
Networking changes for 7.2.
Core & protocols
----------------
- Work on removing rtnl_lock protection throughout the stack continues.
In this chapter:
- don't use rtnl_lock for IPv6 multicast routing configuration
- don't take rtnl_lock in ethtool for modern drivers
- prepare Qdisc dump callbacks for rtnl_lock removal
- Support dumping just ifindex + name of all interfaces, under RCU.
It's a common operation for Netlink CLI tools (when translating
names to ifindexes) and previously required full rtnl_lock.
- Support dumping qdiscs and page pools for a specific netdev. Even tho
user space wants a dump of all netdevs, most of the time, the OOO
programming model results in repeating the dump for each netdev.
Which, in absence of a cache, leads to a O(n^2) behavior.
- Flush nexthops once on multi-nexthop removal (e.g. when device goes
down), another O(n^2) -> O(n) improvement.
- Rehash locally generated traffic to a different nexthop on retransmit
timeout.
- Honor oif when choosing nexthop for locally generated IPv6 traffic.
- Convert TCP Auth Option to crypto library, and drop non-RFC algos.
- Increase subflow limits in MPTCP to 64 and endpoint limit to 256.
- Support MPTCP signaling of IPv6 address + port (ADD_ADDR). We need
to selectively skip reporting of the standard TCP Timestamp option,
because they won't fit into the header space together (12 + 30 > 40).
- Support using bridge neighbor suppression, Duplicate Address
Detection, Gratuitous ARP and unsolicited NA forwarding - in EVPN
deployments, e.g. VXLAN fabrics (IPv4 and IPv6).
- Improve link state reporting for upper netdevs (e.g. macvlan) over
tunnel devices (again, mostly for EVPN deployments).
- Support binding GENEVE tunnels to a local address.
- Speed up UDP tunnel destruction (remove one synchronize_rcu()).
- Support exponential field encoding in multicast (IGMPv3 and MLDv2).
- Support attaching PSP crypto offload to containers (veth, netkit).
- Add a new IPSec Netlink message XFRM_MSG_MIGRATE_STATE that allows
migrating individual IPsec SAs independently of their policies.
The existing XFRM_MSG_MIGRATE is tightly coupled to policy+SA
migration, lacks SPI for unique SA identification, and cannot express
reqid changes or migrate Transport mode selectors. The new interface
identifies the SA via SPI and mark, supports reqid changes, address
family changes, encap removal, and uses an atomic create+install
flow under x->lock to prevent SN/IV reuse during AEAD SA migration.
- Implement GRO/GSO support for PPPoE.
- Convert sockopt callbacks in a number of protocols to iov_iter.
Cross-tree stuff
----------------
- Remove support for Crypto TFM cloning (unblocked after the TCP Auth
Option rework). This feature regressed performance for all crypto API
users, since it changed crypto transformation objects into reference-
-counted objects.
- Add FCrypt-PCBC implementation to rxrpc and remove it from the global
crypto API as obsolete and insecure.
Wireless
--------
- Major rework of station bandwidth handling, fixing issues with lower
capability than AP.
- Cleanups for EMLSR spec issues (drafts differed).
- More Neighbor Awareness Networking (Wi-Fi Aware) work (multicast,
schedule improvements, multi-station etc.)
- Some Ultra High Reliability (UHR) / IEEE 802.11bn (D1.4) work
(e.g. non-primary channel access, UHR DBE support).
- Fine Timing Measurement ranging (i.e. distance measurement) APIs.
Netfilter
---------
- Use per-rule hash initval in nf_conncount. This avoids unnecessary
lock contention with short keys (e.g. conntrack zones) in different
namespaces.
- Various safety improvements, both in packet parsing and object
lifetimes. Notably add refcounts to conntrack timeout policy.
Deletions
---------
- Remove TLS + sockmap integration. TLS wants to pin user pages
to avoid a copy, and sockmap wants to write to the input stream.
More work on this integration is clearly needed, and we can't find
any users (original author admitted that they never deployed it).
- Remove support for TLS offload with TCP Offload Engine (the far
more common opportunistic offload is retained). The locking looks
unfixable (driver sleeps under TCP spin locks) and people from
the vendor that added this are AWOL.
- Remove more ATM code, trying to leave behind only what PPPoATM needs,
AAL5 and br2684 with permanent circuits.
- Remove AppleTalk. Let it join hamradio in our out of tree protocol
graveyard, I mean, repository.
- Disable 32-bit x_tables compatibility (32bit binaries on 64bit kernel)
interface in user namespaces. To be deleted completely, soon.
- Remove 5/10 MHz support from cfg80211/mac80211.
Drivers
-------
- Software:
- Support DEVMEM/DMABUF Tx over NETMEM_TX_NO_DMA devices (netkit).
- bonding: add knob to strictly follow 802.3ad for link state.
- New drivers:
- Alibaba Elastic Ethernet Adaptor (cloud vNIC).
- NXP NETC switch within i.MX94.
- DPLL:
- Add operational state to pins (implement in zl3073x).
- Add generic DPLL type, for daisy-chaining DPLLs (implement in ice).
- Ethernet high-speed NICs:
- Huawei (hinic3):
- enhance tc flow offload support with queue selection, tunnels
- nVidia/Mellanox:
- avoid over-copying payload to the skb's linear part (up to 60%
win for LRO on slow CPUs like ARM64 V2)
- expose more per-queue stats over the standard API
- support additional, unprivileged PFs in the DPU configuration
- support Socket Direct (multi-PF) with switchdev offloads
- add a pool / frag allocator for DMA mapped buffers for control
objects, save memory on systems with 64kB page size
- take advantage of the ability to dynamically change RSS table
size, even when table is configured by the user
- increase the max RSS table size for even traffic distribution
- Ethernet NICs:
- Marvell/Aquantia:
- AQC113 PTP support
- Realtek USB (r8152):
- support 10Gbit Link Speeds and Energy-Efficient Ethernet (EEE)
- support firmware loaded (for RTL8157/RTL8159)
- support for the RTL8159
- Intel (ixgbe):
- support Energy-Efficient Ethernet (EEE) on E610 devices
- Ethernet switches:
- Airoha:
- support multiple netdevs on a single GDM block / port
- Marvell (mv88e6xxx):
- support SERDES of mv88e6321
- Microchip (ksz8/9):
- rework the driver callbacks to remove one indirection layer
- Motorcomm (yt921x):
- support port rate policing
- support TBF qdisc offload
- support ACL/flower offload
- nVidia/Mellanox:
- expose per-PG rx_discards
- Realtek:
- rtl8365mb: bridge offloading and VLAN support
- Ethernet PHYs:
- Airoha:
- support Airoha AN8801R Gigabit PHYs.
- Micrel:
- implement 3 low-loss cable tunables
- Realtek:
- support MDI swapping for RTL8226-CG
- support MDIO for RTL931x
- Qualcomm:
- at803x: Rx and Tx clock management for IPQ5018 PHY
- Motorcomm:
- support YT8522 100M RMII PHY
- set drive strength in YT8531s RGMII
- TI:
- dp83822: add optional external PHY clock
- Bluetooth:
- hci_sync: add support for HCI_LE_Set_Host_Feature [v2]
- SMP: use AES-CMAC library API
- Intel:
- support Product level reset
- support smart trigger dump
- Mediatek:
- add event filter to filter specific event
- Realtek:
- fix RTL8761B/BU broken LE extended scan
- WiFi:
- Broadcom (b43):
- new support for a 11n device
- MediaTek (mt76):
- support mt7927
- mt792x: broken usb transport detection
- mt7921: regulatory improvements
- Qualcomm (ath9k):
- GPIO interface improvements
- Qualcomm (ath12k):
- WDS support
- replace dynamic memory allocation in WMI Rx path
- thermal throttling/cooling device support
- 6 GHz incumbent interference detection
- channel 177 in 5 GHz
- Realtek (rt89):
- RTL8922AU support
- USB 3 mode switch for performance
- better monitor radiotap support
- RTL8922DE preparations
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmox1O4ACgkQMUZtbf5S
Irve7hAAgvCYRFvQ/1dvL+PORg2KqVW4rWXMvNrEWaMVAEXJIIPJoxen6zn6a/72
aRs2Ord/wVM/Uh291TOrARwtv1U0oOvOvnbrVM2u06o/EqjtxRAZSF9quTlPdm6Q
RvlkR5X9XXM2MwbDc1zYNTITfhVv80YDCFmYGI7O8dyhLuyspX2eU0SiW33Twl4f
y6RLcn12gyUbDpa6vt+tari6cFCO/X2zot/uwaDY38b+kwsMHunrj3/PSfJzeYIU
5mD7jG+xsPxQlEskMYGOjVT5VeMdRquhb9UGwoostZpuEPYZfzTdFtphC1qZqIPk
8O8ngAW1yYNIY9TTMPF3Y3LMpOiyZq6/P4KY+tksbeDw8vvTYJzEgw3VpwurZQLM
vfHKDj1kM6VLNekeCI+2cip06flVH3jtIkN0KOERwzTSS8NUbs6PuoEP0HLdjafj
cr/pgSSTQPUsQkpS5R5Ld3bwpnKea56CQ36p2E8JvU2akwK5RnvqiZiTAfz2z2Tg
M0NVlTsJ07ucNBxsO4l7osDtRTnzUqo+ZeTo+zR5l0cGRXPd9nJByk257z4IAlcQ
2MHrJmCZ+ZFKhmkUNUPBdFBATbRgOZHzA/iiiThBrT2hDvWQ2kygO9+IkJBS/WYx
eQz7G9hb6Xn1ifWVvPVD0oDL3DKKTotQIN90PZCzvObQFWMc1Vk=
=oNfE
-----END PGP SIGNATURE-----
Merge tag 'net-next-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
Pull networking updates from Jakub Kicinski:
"Core & protocols:
- Work on removing rtnl_lock protection throughout the stack
continues. In this chapter:
- don't use rtnl_lock for IPv6 multicast routing configuration
- don't take rtnl_lock in ethtool for modern drivers
- prepare Qdisc dump callbacks for rtnl_lock removal
- Support dumping just ifindex + name of all interfaces, under RCU.
It's a common operation for Netlink CLI tools (when translating
names to ifindexes) and previously required full rtnl_lock.
- Support dumping qdiscs and page pools for a specific netdev. Even
tho user space wants a dump of all netdevs, most of the time, the
OOO programming model results in repeating the dump for each
netdev. Which, in absence of a cache, leads to a O(n^2) behavior.
- Flush nexthops once on multi-nexthop removal (e.g. when device goes
down), another O(n^2) -> O(n) improvement.
- Rehash locally generated traffic to a different nexthop on
retransmit timeout.
- Honor oif when choosing nexthop for locally generated IPv6 traffic.
- Convert TCP Auth Option to crypto library, and drop non-RFC algos.
- Increase subflow limits in MPTCP to 64 and endpoint limit to 256.
- Support MPTCP signaling of IPv6 address + port (ADD_ADDR). We need
to selectively skip reporting of the standard TCP Timestamp option,
because they won't fit into the header space together (12 + 30 >
40).
- Support using bridge neighbor suppression, Duplicate Address
Detection, Gratuitous ARP and unsolicited NA forwarding - in EVPN
deployments, e.g. VXLAN fabrics (IPv4 and IPv6).
- Improve link state reporting for upper netdevs (e.g. macvlan) over
tunnel devices (again, mostly for EVPN deployments).
- Support binding GENEVE tunnels to a local address.
- Speed up UDP tunnel destruction (remove one synchronize_rcu()).
- Support exponential field encoding in multicast (IGMPv3 and MLDv2).
- Support attaching PSP crypto offload to containers (veth, netkit).
- Add a new IPSec Netlink message XFRM_MSG_MIGRATE_STATE that allows
migrating individual IPsec SAs independently of their policies.
The existing XFRM_MSG_MIGRATE is tightly coupled to policy+SA
migration, lacks SPI for unique SA identification, and cannot
express reqid changes or migrate Transport mode selectors.
The new interface identifies the SA via SPI and mark, supports
reqid changes, address family changes, encap removal, and uses an
atomic create+install flow under x->lock to prevent SN/IV reuse
during AEAD SA migration.
- Implement GRO/GSO support for PPPoE.
- Convert sockopt callbacks in a number of protocols to iov_iter.
Cross-tree stuff:
- Remove support for Crypto TFM cloning (unblocked after the TCP Auth
Option rework). This feature regressed performance for all crypto
API users, since it changed crypto transformation objects into
reference-counted objects.
- Add FCrypt-PCBC implementation to rxrpc and remove it from the
global crypto API as obsolete and insecure.
Wireless:
- Major rework of station bandwidth handling, fixing issues with
lower capability than AP.
- Cleanups for EMLSR spec issues (drafts differed).
- More Neighbor Awareness Networking (Wi-Fi Aware) work (multicast,
schedule improvements, multi-station etc.)
- Some Ultra High Reliability (UHR) / IEEE 802.11bn (D1.4) work
(e.g. non-primary channel access, UHR DBE support).
- Fine Timing Measurement ranging (i.e. distance measurement) APIs.
Netfilter:
- Use per-rule hash initval in nf_conncount. This avoids unnecessary
lock contention with short keys (e.g. conntrack zones) in different
namespaces.
- Various safety improvements, both in packet parsing and object
lifetimes. Notably add refcounts to conntrack timeout policy.
Deletions:
- Remove TLS + sockmap integration. TLS wants to pin user pages to
avoid a copy, and sockmap wants to write to the input stream. More
work on this integration is clearly needed, and we can't find any
users (original author admitted that they never deployed it).
- Remove support for TLS offload with TCP Offload Engine (the far
more common opportunistic offload is retained). The locking looks
unfixable (driver sleeps under TCP spin locks) and people from the
vendor that added this are AWOL.
- Remove more ATM code, trying to leave behind only what PPPoATM
needs, AAL5 and br2684 with permanent circuits.
- Remove AppleTalk. Let it join hamradio in our out of tree protocol
graveyard, I mean, repository.
- Disable 32-bit x_tables compatibility (32bit binaries on 64bit
kernel) interface in user namespaces. To be deleted completely,
soon.
- Remove 5/10 MHz support from cfg80211/mac80211.
Drivers:
- Software:
- Support DEVMEM/DMABUF Tx over NETMEM_TX_NO_DMA devices (netkit)
- bonding: add knob to strictly follow 802.3ad for link state
- New drivers:
- Alibaba Elastic Ethernet Adaptor (cloud vNIC).
- NXP NETC switch within i.MX94.
- DPLL:
- Add operational state to pins (implement in zl3073x).
- Add generic DPLL type, for daisy-chaining DPLLs (implement in ice).
- Ethernet high-speed NICs:
- Huawei (hinic3):
- enhance tc flow offload support with queue selection,
tunnels
- nVidia/Mellanox:
- avoid over-copying payload to the skb's linear part (up to
60% win for LRO on slow CPUs like ARM64 V2)
- expose more per-queue stats over the standard API
- support additional, unprivileged PFs in the DPU
configuration
- support Socket Direct (multi-PF) with switchdev offloads
- add a pool / frag allocator for DMA mapped buffers for
control objects, save memory on systems with 64kB page size
- take advantage of the ability to dynamically change RSS
table size, even when table is configured by the user
- increase the max RSS table size for even traffic
distribution
- Ethernet NICs:
- Marvell/Aquantia:
- AQC113 PTP support
- Realtek USB (r8152):
- support 10Gbit Link Speeds and Energy-Efficient Ethernet
(EEE)
- support firmware loaded (for RTL8157/RTL8159)
- support for the RTL8159
- Intel (ixgbe):
- support Energy-Efficient Ethernet (EEE) on E610 devices
- Ethernet switches:
- Airoha:
- support multiple netdevs on a single GDM block / port
- Marvell (mv88e6xxx):
- support SERDES of mv88e6321
- Microchip (ksz8/9):
- rework the driver callbacks to remove one indirection layer
- Motorcomm (yt921x):
- support port rate policing
- support TBF qdisc offload
- support ACL/flower offload
- nVidia/Mellanox:
- expose per-PG rx_discards
- Realtek:
- rtl8365mb: bridge offloading and VLAN support
- Ethernet PHYs:
- Airoha:
- support Airoha AN8801R Gigabit PHYs.
- Micrel:
- implement 3 low-loss cable tunables
- Realtek:
- support MDI swapping for RTL8226-CG
- support MDIO for RTL931x
- Qualcomm:
- at803x: Rx and Tx clock management for IPQ5018 PHY
- Motorcomm:
- support YT8522 100M RMII PHY
- set drive strength in YT8531s RGMII
- TI:
- dp83822: add optional external PHY clock
- Bluetooth:
- hci_sync: add support for HCI_LE_Set_Host_Feature [v2]
- SMP: use AES-CMAC library API
- Intel:
- support Product level reset
- support smart trigger dump
- Mediatek:
- add event filter to filter specific event
- Realtek:
- fix RTL8761B/BU broken LE extended scan
- WiFi:
- Broadcom (b43):
- new support for a 11n device
- MediaTek (mt76):
- support mt7927
- mt792x: broken usb transport detection
- mt7921: regulatory improvements
- Qualcomm (ath9k):
- GPIO interface improvements
- Qualcomm (ath12k):
- WDS support
- replace dynamic memory allocation in WMI Rx path
- thermal throttling/cooling device support
- 6 GHz incumbent interference detection
- channel 177 in 5 GHz
- Realtek (rt89):
- RTL8922AU support
- USB 3 mode switch for performance
- better monitor radiotap support
- RTL8922DE preparations"
* tag 'net-next-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1778 commits)
ipv4: fib_rule: Move fib4_rules_exit() to ->exit().
net: serialize netif_running() check in enqueue_to_backlog()
net: skmsg: preserve sg.copy across SG transforms
appletalk: move the protocol out of tree
appletalk: stop storing per-interface state in struct net_device
selftests/bpf: test that TLS crypto is rejected on a sockmap socket
selftests/bpf: drop the unused kTLS program from test_sockmap
selftests/bpf: remove sockmap + ktls tests
tls: remove dead sockmap (psock) handling from the SW path
tls: reject the combination of TLS and sockmap
atm: remove orphaned uAPI for deleted drivers, protocols and SVCs
atm: remove unused ATM PHY operations
atm: remove the unused pre_send and send_bh device operations
atm: remove the unused change_qos device operation
atm: remove SVC socket support and the signaling daemon interface
atm: remove the local ATM (NSAP) address registry
atm: remove dead SONET PHY ioctls
atm: remove the unused send_oam / push_oam callbacks
atm: remove AAL3/4 transport support
net: dsa: sja1105: fix lastused timestamp in flower stats
...
This commit is contained in:
Linus Torvalds
commit
b85966adbf
1
.mailmap
1
.mailmap
|
|
@ -402,6 +402,7 @@ Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
|
|||
Jesper Dangaard Brouer <hawk@kernel.org> <jbrouer@redhat.com>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <jdb@comx.dk>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <netoptimizer@brouer.com>
|
||||
Jesse Brandeburg <jbrandeb@kernel.org> <jesse.brandeburg@intel.com>
|
||||
Jessica Zhang <jesszhan0024@gmail.com> <jesszhan@codeaurora.org>
|
||||
Jessica Zhang <jesszhan0024@gmail.com> <quic_jesszhan@quicinc.com>
|
||||
Jessica Zhang <jesszhan0024@gmail.com> <jessica.zhang@oss.qualcomm.com>
|
||||
|
|
|
|||
24
Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
Normal file
24
Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
What: /sys/class/ieee80211/phyX/rtw89_usb/serial_number
|
||||
Date: May 2026
|
||||
Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-wireless@vger.kernel.org
|
||||
Description: (Read) Serial number burned into EFUSE of the RTL8852CU-based
|
||||
USB Wi-Fi adapter. Only present on devices that set the
|
||||
RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
|
||||
PID 0x2432).
|
||||
|
||||
Format: %10phN (5 raw bytes printed as 10 lowercase hex
|
||||
digits, no separators).
|
||||
|
||||
Example: 3642000123
|
||||
|
||||
What: /sys/class/ieee80211/phyX/rtw89_usb/uuid
|
||||
Date: May 2026
|
||||
Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-wireless@vger.kernel.org
|
||||
Description: (Read) UUID burned into EFUSE of the RTL8852CU-based USB Wi-Fi
|
||||
adapter. Only present on devices that set the
|
||||
RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
|
||||
PID 0x2432).
|
||||
|
||||
Format: %pUb (RFC 4122 UUID in lowercase with hyphens).
|
||||
|
||||
Example: aaec2b7c-0a55-4727-8de0-b30febccbbaa
|
||||
|
|
@ -556,9 +556,6 @@ Kernel parameters
|
|||
1 -- enable.
|
||||
Default value is set via kernel config option.
|
||||
|
||||
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
|
||||
Format: <io>,<irq>,<nodeID>
|
||||
|
||||
arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
|
||||
32 bit applications.
|
||||
|
||||
|
|
@ -891,17 +888,6 @@ Kernel parameters
|
|||
Sets the size of memory pool for coherent, atomic dma
|
||||
allocations, by default set to 256K.
|
||||
|
||||
com20020= [HW,NET] ARCnet - COM20020 chipset
|
||||
Format:
|
||||
<io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]]
|
||||
|
||||
com90io= [HW,NET] ARCnet - COM90xx chipset (IO-mapped buffers)
|
||||
Format: <io>[,<irq>]
|
||||
|
||||
com90xx= [HW,NET]
|
||||
ARCnet - COM90xx chipset (memory-mapped buffers)
|
||||
Format: <io>[,<irq>[,<memstart>]]
|
||||
|
||||
condev= [HW,S390] console device
|
||||
conmode=
|
||||
|
||||
|
|
@ -4250,12 +4236,8 @@ Kernel parameters
|
|||
|
||||
n2= [NET] SDL Inc. RISCom/N2 synchronous serial card
|
||||
|
||||
netdev= [NET] Network devices parameters
|
||||
netdev= [NET] NE2000 ISA network devices parameters
|
||||
Format: <irq>,<io>,<mem_start>,<mem_end>,<name>
|
||||
Note that mem_start is often overloaded to mean
|
||||
something different and driver-specific.
|
||||
This usage is only documented in each driver source
|
||||
file if at all.
|
||||
|
||||
netpoll.carrier_timeout=
|
||||
[NET] Specifies amount of time (in seconds) that
|
||||
|
|
|
|||
|
|
@ -474,51 +474,7 @@ Please see: Documentation/networking/ip-sysctl.rst and
|
|||
Documentation/admin-guide/sysctl/net.rst for descriptions of these entries.
|
||||
|
||||
|
||||
4. Appletalk
|
||||
------------
|
||||
|
||||
The /proc/sys/net/appletalk directory holds the Appletalk configuration data
|
||||
when Appletalk is loaded. The configurable parameters are:
|
||||
|
||||
aarp-expiry-time
|
||||
----------------
|
||||
|
||||
The amount of time we keep an ARP entry before expiring it. Used to age out
|
||||
old hosts.
|
||||
|
||||
aarp-resolve-time
|
||||
-----------------
|
||||
|
||||
The amount of time we will spend trying to resolve an Appletalk address.
|
||||
|
||||
aarp-retransmit-limit
|
||||
---------------------
|
||||
|
||||
The number of times we will retransmit a query before giving up.
|
||||
|
||||
aarp-tick-time
|
||||
--------------
|
||||
|
||||
Controls the rate at which expires are checked.
|
||||
|
||||
The directory /proc/net/appletalk holds the list of active Appletalk sockets
|
||||
on a machine.
|
||||
|
||||
The fields indicate the DDP type, the local address (in network:node format)
|
||||
the remote address, the size of the transmit pending queue, the size of the
|
||||
received queue (bytes waiting for applications to read) the state and the uid
|
||||
owning the socket.
|
||||
|
||||
/proc/net/atalk_iface lists all the interfaces configured for appletalk.It
|
||||
shows the name of the interface, its Appletalk address, the network range on
|
||||
that address (or network number for phase 1 networks), and the status of the
|
||||
interface.
|
||||
|
||||
/proc/net/atalk_route lists each known network route. It lists the target
|
||||
(network) that the route leads to, the router (may be directly connected), the
|
||||
route flags, and the device the route is using.
|
||||
|
||||
5. TIPC
|
||||
4. TIPC
|
||||
-------
|
||||
|
||||
tipc_rmem
|
||||
|
|
|
|||
|
|
@ -244,23 +244,7 @@ drive (with "root=").
|
|||
3) General Device Options (Amiga and Atari)
|
||||
===========================================
|
||||
|
||||
3.1) ether=
|
||||
-----------
|
||||
|
||||
:Syntax: ether=[<irq>[,<base_addr>[,<mem_start>[,<mem_end>]]]],<dev-name>
|
||||
|
||||
<dev-name> is the name of a net driver, as specified in
|
||||
drivers/net/Space.c in the Linux source. Most prominent are eth0, ...
|
||||
eth3, sl0, ... sl3, ppp0, ..., ppp3, dummy, and lo.
|
||||
|
||||
The non-ethernet drivers (sl, ppp, dummy, lo) obviously ignore the
|
||||
settings by this options. Also, the existing ethernet drivers for
|
||||
Linux/m68k (ariadne, a2065, hydra) don't use them because Zorro boards
|
||||
are really Plug-'n-Play, so the "ether=" option is useless altogether
|
||||
for Linux/m68k.
|
||||
|
||||
|
||||
3.2) hd=
|
||||
3.1) hd=
|
||||
--------
|
||||
|
||||
:Syntax: hd=<cylinders>,<heads>,<sectors>
|
||||
|
|
@ -273,7 +257,7 @@ itself. It exists just for the case that this fails for one of your
|
|||
disks.
|
||||
|
||||
|
||||
3.3) max_scsi_luns=
|
||||
3.2) max_scsi_luns=
|
||||
-------------------
|
||||
|
||||
:Syntax: max_scsi_luns=<n>
|
||||
|
|
@ -284,7 +268,7 @@ be scanned. Valid values for <n> are between 1 and 8. Default is 8 if
|
|||
configuration, else 1.
|
||||
|
||||
|
||||
3.4) st=
|
||||
3.3) st=
|
||||
--------
|
||||
|
||||
:Syntax: st=<buffer_size>,[<write_thres>,[<max_buffers>]]
|
||||
|
|
@ -297,7 +281,7 @@ total number of buffers. <max_buffer> limits the total number of
|
|||
buffers allocated for all tape devices.
|
||||
|
||||
|
||||
3.5) dmasound=
|
||||
3.4) dmasound=
|
||||
--------------
|
||||
|
||||
:Syntax: dmasound=[<buffers>,<buffer-size>[,<catch-radius>]]
|
||||
|
|
|
|||
120
Documentation/devicetree/bindings/net/airoha,an8801.yaml
Normal file
120
Documentation/devicetree/bindings/net/airoha,an8801.yaml
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/airoha,an8801.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Airoha AN8801R Series PHY
|
||||
|
||||
maintainers:
|
||||
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
||||
|
||||
description:
|
||||
The Airoha AN8801R is a low power single-port Ethernet PHY Transceiver
|
||||
with Single-port serdes interface for 1000Base-X/RGMII; this chip is
|
||||
compliant with 10Base-T, 100Base-TX and 1000Base-T IEEE 802.3(u,ab)
|
||||
and supports Energy Efficient Ethernet (802.3az), Full Duplex Control
|
||||
Flow (802.3x), auto-negotiation, crossover detect and autocorrection,
|
||||
Wake-on-LAN with Magic Packet, and Jumbo Frame up to 9 Kilobytes.
|
||||
This PHY also supports up to three user-configurable LEDs, which are
|
||||
usually used for LAN Activity, 100M, 1000M indication.
|
||||
|
||||
allOf:
|
||||
- $ref: ethernet-phy.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ethernet-phy-idc0ff.0421
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
leds:
|
||||
type: object
|
||||
description:
|
||||
Describes the LEDs associated to the PHY
|
||||
|
||||
properties:
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^led@[0-2]$":
|
||||
type: object
|
||||
description: PHY LEDs
|
||||
$ref: /schemas/leds/common.yaml#
|
||||
|
||||
properties:
|
||||
reg:
|
||||
enum: [0, 1, 2]
|
||||
|
||||
function-enumerator:
|
||||
enum: [0, 1, 2]
|
||||
description: |
|
||||
Specifies a function for offloading LED functionality to the PHY:
|
||||
0 - No offloading
|
||||
1 - Link Availability
|
||||
2 - Network Activity
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
wakeup-source:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Enable Wake-on-LAN support
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/leds/common.h>
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ethernet-phy@0 {
|
||||
compatible = "ethernet-phy-idc0ff.0421";
|
||||
reg = <0>;
|
||||
|
||||
leds {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
led@0 {
|
||||
reg = <0>;
|
||||
color = <LED_COLOR_ID_GREEN>;
|
||||
function = LED_FUNCTION_LAN;
|
||||
default-state = "keep";
|
||||
};
|
||||
|
||||
led@1 {
|
||||
reg = <1>;
|
||||
color = <LED_COLOR_ID_GREEN>;
|
||||
function = LED_FUNCTION_LAN;
|
||||
function-enumerator = <1>;
|
||||
default-state = "keep";
|
||||
};
|
||||
|
||||
led@2 {
|
||||
reg = <2>;
|
||||
color = <LED_COLOR_ID_YELLOW>;
|
||||
function = LED_FUNCTION_LAN;
|
||||
function-enumerator = <2>;
|
||||
default-state = "keep";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -130,6 +130,42 @@ patternProperties:
|
|||
maximum: 4
|
||||
description: GMAC port identifier
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
reg:
|
||||
contains:
|
||||
items:
|
||||
- enum:
|
||||
- 3
|
||||
- 4
|
||||
then:
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^ethernet@[0-5]$":
|
||||
type: object
|
||||
unevaluatedProperties: false
|
||||
$ref: ethernet-controller.yaml#
|
||||
description: External ethernet port ID available on the GDM port
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: airoha,eth-port
|
||||
|
||||
reg:
|
||||
maximum: 5
|
||||
description: External ethernet port identifier
|
||||
|
||||
required:
|
||||
- reg
|
||||
- compatible
|
||||
|
||||
required:
|
||||
- reg
|
||||
- compatible
|
||||
|
|
@ -191,9 +227,27 @@ examples:
|
|||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
mac: ethernet@1 {
|
||||
ethernet@1 {
|
||||
compatible = "airoha,eth-mac";
|
||||
reg = <1>;
|
||||
};
|
||||
|
||||
ethernet@4 {
|
||||
compatible = "airoha,eth-mac";
|
||||
reg = <4>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ethernet@0 {
|
||||
compatible = "airoha,eth-port";
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
ethernet@1 {
|
||||
compatible = "airoha,eth-port";
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
Distributed Switch Architecture Device Tree Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documentation.
|
||||
|
|
@ -28,7 +28,11 @@ properties:
|
|||
A two element list indicates which DSA cluster, and position within the
|
||||
cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0,
|
||||
switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster
|
||||
(single device hanging off a CPU port) must not specify this property
|
||||
(single device hanging off a CPU port) does not usually need to specify
|
||||
this property, and then it becomes cluster 0, switch 0. For a topology
|
||||
aware switch, its switch index can be specified through this property,
|
||||
even if it is not part of any cluster. Also, topology-unaware switches
|
||||
must always be defined as index 0 of their cluster.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
||||
additionalProperties: true
|
||||
|
|
|
|||
|
|
@ -1,100 +0,0 @@
|
|||
SMSC/MicroChip LAN9303 three port ethernet switch
|
||||
-------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be
|
||||
- "smsc,lan9303-i2c" for I2C managed mode
|
||||
or
|
||||
- "smsc,lan9303-mdio" for mdio managed mode
|
||||
|
||||
Optional properties:
|
||||
|
||||
- reset-gpios: GPIO to be used to reset the whole device
|
||||
- reset-duration: reset duration in milliseconds, defaults to 200 ms
|
||||
|
||||
Subnodes:
|
||||
|
||||
The integrated switch subnode should be specified according to the binding
|
||||
described in dsa/dsa.txt. The CPU port of this switch is always port 0.
|
||||
|
||||
Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
|
||||
configured to use 1/2/3 instead. This hardware configuration will be
|
||||
auto-detected and mapped accordingly.
|
||||
|
||||
Example:
|
||||
|
||||
I2C managed mode:
|
||||
|
||||
master: masterdevice@X {
|
||||
|
||||
fixed-link { /* RMII fixed link to LAN9303 */
|
||||
speed = <100>;
|
||||
full-duplex;
|
||||
};
|
||||
};
|
||||
|
||||
switch: switch@a {
|
||||
compatible = "smsc,lan9303-i2c";
|
||||
reg = <0xa>;
|
||||
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
|
||||
reset-duration = <200>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 { /* RMII fixed link to master */
|
||||
reg = <0>;
|
||||
ethernet = <&master>;
|
||||
};
|
||||
|
||||
port@1 { /* external port 1 */
|
||||
reg = <1>;
|
||||
label = "lan1";
|
||||
};
|
||||
|
||||
port@2 { /* external port 2 */
|
||||
reg = <2>;
|
||||
label = "lan2";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
MDIO managed mode:
|
||||
|
||||
master: masterdevice@X {
|
||||
phy-handle = <&switch>;
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
switch: switch-phy@0 {
|
||||
compatible = "smsc,lan9303-mdio";
|
||||
reg = <0>;
|
||||
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
|
||||
reset-duration = <100>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
ethernet = <&master>;
|
||||
};
|
||||
|
||||
port@1 { /* external port 1 */
|
||||
reg = <1>;
|
||||
label = "lan1";
|
||||
};
|
||||
|
||||
port@2 { /* external port 2 */
|
||||
reg = <2>;
|
||||
label = "lan2";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
131
Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
Normal file
131
Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
Normal file
|
|
@ -0,0 +1,131 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NETC Switch family
|
||||
|
||||
description: >
|
||||
The NETC presents itself as a multi-function PCIe Root Complex Integrated
|
||||
Endpoint (RCiEP) and provides full 802.1Q Ethernet switch functionality,
|
||||
advanced QoS with 8 traffic classes and 4 drop resilience levels, and a
|
||||
full range of TSN standards capabilities.
|
||||
|
||||
The CPU port of the switch connects to an internal ENETC. The switch and
|
||||
the internal ENETC are fully integrated into the NETC IP, a back-to-back
|
||||
MAC is not required. Instead, a light-weight "pseudo MAC" provides the
|
||||
delineation between the switch and ENETC. This translates to lower power
|
||||
(less logic and memory) and lower delay (as there is no serialization
|
||||
delay across this link).
|
||||
|
||||
maintainers:
|
||||
- Wei Fang <wei.fang@nxp.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- pci1131,eef2
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
dsa,member:
|
||||
description: >
|
||||
The property indicates DSA cluster and switch index. For NETC switch,
|
||||
the valid range of the switch index is 1 ~ 7, the index is reflected
|
||||
in the switch tag as an indication of the switch ID where the frame
|
||||
originated. The value 0 is reserved for ENETC VEPA switch, whose ID
|
||||
is hardwired to zero.
|
||||
items:
|
||||
- true
|
||||
- minimum: 1
|
||||
maximum: 7
|
||||
|
||||
ethernet-ports:
|
||||
type: object
|
||||
patternProperties:
|
||||
"^ethernet-port@[0-9a-f]$":
|
||||
type: object
|
||||
$ref: dsa-port.yaml#
|
||||
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: MAC transmit/receive reference clock.
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ref
|
||||
|
||||
mdio:
|
||||
$ref: /schemas/net/mdio.yaml#
|
||||
unevaluatedProperties: false
|
||||
description:
|
||||
Optional child node for switch port, otherwise use NETC EMDIO.
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- dsa,member
|
||||
- ethernet-ports
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/pci/pci-device.yaml
|
||||
- $ref: dsa.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
pcie {
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
|
||||
ethernet-switch@0,2 {
|
||||
compatible = "pci1131,eef2";
|
||||
reg = <0x200 0 0 0 0>;
|
||||
dsa,member = <0 1>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_switch>;
|
||||
|
||||
ethernet-ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ethernet-port@0 {
|
||||
reg = <0>;
|
||||
phy-handle = <ðphy0>;
|
||||
phy-mode = "mii";
|
||||
};
|
||||
|
||||
ethernet-port@1 {
|
||||
reg = <1>;
|
||||
phy-handle = <ðphy1>;
|
||||
phy-mode = "mii";
|
||||
};
|
||||
|
||||
ethernet-port@2 {
|
||||
reg = <2>;
|
||||
clocks = <&scmi_clk 103>;
|
||||
clock-names = "ref";
|
||||
phy-handle = <ðphy2>;
|
||||
phy-mode = "rgmii-id";
|
||||
};
|
||||
|
||||
ethernet-port@3 {
|
||||
reg = <3>;
|
||||
ethernet = <&enetc3>;
|
||||
phy-mode = "internal";
|
||||
|
||||
fixed-link {
|
||||
speed = <2500>;
|
||||
full-duplex;
|
||||
pause;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
123
Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
Normal file
123
Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
Normal file
|
|
@ -0,0 +1,123 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/dsa/smsc,lan9303.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: SMSC/MicroChip LAN9303 three port ethernet switch
|
||||
|
||||
maintainers:
|
||||
- Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
description:
|
||||
The LAN9303 is a three port ethernet switch with integrated PHYs for the
|
||||
two external ports. The third port is an RMII/MII interface to a host
|
||||
processor. The device can be managed via I2C or MDIO.
|
||||
|
||||
Note - always use 'reg = <0/1/2>;' for the three DSA ports, even if the
|
||||
device is configured to use 1/2/3 instead. This hardware configuration
|
||||
will be auto-detected and mapped accordingly.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- smsc,lan9303-i2c
|
||||
- smsc,lan9303-mdio
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
description:
|
||||
GPIO to be used to reset the whole device
|
||||
maxItems: 1
|
||||
|
||||
reset-duration:
|
||||
description:
|
||||
Reset duration in milliseconds
|
||||
default: 200
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
allOf:
|
||||
- $ref: dsa.yaml#
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
/* I2C managed mode */
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
switch@a {
|
||||
compatible = "smsc,lan9303-i2c";
|
||||
reg = <0xa>;
|
||||
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
|
||||
reset-duration = <200>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
label = "cpu";
|
||||
ethernet = <&master>;
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
label = "lan1";
|
||||
};
|
||||
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
label = "lan2";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
/* MDIO managed mode */
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
switch@0 {
|
||||
compatible = "smsc,lan9303-mdio";
|
||||
reg = <0>;
|
||||
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
|
||||
reset-duration = <100>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
label = "cpu";
|
||||
ethernet = <&master>;
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
label = "lan1";
|
||||
};
|
||||
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
label = "lan2";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -106,10 +106,13 @@ properties:
|
|||
by software.
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
description:
|
||||
External clock connected to the PHY. If not specified it is assumed
|
||||
that the PHY uses a fixed crystal or an internal oscillator.
|
||||
External clock connected to the PHY or RX and TX clocks that the PHY
|
||||
requires to enable explicitly. If not specified it is assumed
|
||||
that the PHY uses a fixed crystal or an internal oscillator or that the
|
||||
RX/TX clocks are hardware enabled by default.
|
||||
|
||||
enet-phy-lane-swap:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
This file has moved to mdio.yaml.
|
||||
|
|
@ -67,7 +67,7 @@ examples:
|
|||
pinctrl-names = "default";
|
||||
pinctrl-0 = <ð0_pins>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
|
||||
interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
|
||||
local-mac-address = [04 05 06 01 02 03];
|
||||
spi-max-frequency = <15000000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- usb424,7500 # SMSC LAN7500 USB Ethernet Device
|
||||
- usb424,7505 # SMSC LAN7505 USB Ethernet Device
|
||||
- usb424,9500 # SMSC9500 USB Ethernet Device
|
||||
- usb424,9505 # SMSC9505 USB Ethernet Device
|
||||
- usb424,9530 # SMSC LAN9530 USB Ethernet Device
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ description: |
|
|||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^switch@[0-9a-f]+$"
|
||||
pattern: "^(ethernet-)?switch@[0-9a-f]+$"
|
||||
|
||||
compatible:
|
||||
const: microchip,lan966x-switch
|
||||
|
|
@ -70,7 +70,7 @@ properties:
|
|||
additionalProperties: false
|
||||
|
||||
patternProperties:
|
||||
"^port@[0-9a-f]+$":
|
||||
"^(ethernet-)?port@[0-9a-f]+$":
|
||||
type: object
|
||||
|
||||
$ref: /schemas/net/ethernet-controller.yaml#
|
||||
|
|
@ -138,7 +138,7 @@ additionalProperties: false
|
|||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
switch: switch@e0000000 {
|
||||
switch: ethernet-switch@e0000000 {
|
||||
compatible = "microchip,lan966x-switch";
|
||||
reg = <0xe0000000 0x0100000>,
|
||||
<0xe2000000 0x0800000>;
|
||||
|
|
@ -151,14 +151,14 @@ examples:
|
|||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port0: port@0 {
|
||||
port0: ethernet-port@0 {
|
||||
reg = <0>;
|
||||
phy-handle = <&phy0>;
|
||||
phys = <&serdes 0 0>;
|
||||
phy-mode = "gmii";
|
||||
};
|
||||
|
||||
port1: port@1 {
|
||||
port1: ethernet-port@1 {
|
||||
reg = <1>;
|
||||
sfp = <&sfp_eth1>;
|
||||
managed = "in-band-status";
|
||||
|
|
|
|||
|
|
@ -22,6 +22,10 @@ properties:
|
|||
reg:
|
||||
maxItems: 1
|
||||
|
||||
disable-ports-gpios:
|
||||
description: GPIO pin to disable PoE on all ports
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply:
|
||||
description: Regulator that provides 3.3V VDD power supply.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,16 @@ allOf:
|
|||
reg:
|
||||
const: 7 # This PHY is always at MDIO address 7 in the IPQ5018 SoC
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: RX clock
|
||||
- description: TX clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
resets:
|
||||
items:
|
||||
- description:
|
||||
|
|
@ -42,6 +52,11 @@ allOf:
|
|||
of this PHY are directly connected to an RJ45 connector.
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- clocks
|
||||
- clock-names
|
||||
- resets
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
|
|
@ -162,6 +177,7 @@ examples:
|
|||
};
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-ipq5018.h>
|
||||
#include <dt-bindings/reset/qcom,gcc-ipq5018.h>
|
||||
|
||||
mdio {
|
||||
|
|
@ -172,6 +188,9 @@ examples:
|
|||
compatible = "ethernet-phy-id004d.d0c0";
|
||||
reg = <7>;
|
||||
|
||||
clocks = <&gcc GCC_GEPHY_RX_CLK>,
|
||||
<&gcc GCC_GEPHY_TX_CLK>;
|
||||
clock-names = "rx", "tx";
|
||||
resets = <&gcc GCC_GEPHY_MISC_ARES>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -18,7 +18,14 @@ properties:
|
|||
- realtek,rtl9302c-mdio
|
||||
- realtek,rtl9303-mdio
|
||||
- const: realtek,rtl9301-mdio
|
||||
- const: realtek,rtl9301-mdio
|
||||
- items:
|
||||
- enum:
|
||||
- realtek,rtl9312-mdio
|
||||
- realtek,rtl9313-mdio
|
||||
- const: realtek,rtl9311-mdio
|
||||
- enum:
|
||||
- realtek,rtl9301-mdio
|
||||
- realtek,rtl9311-mdio
|
||||
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ properties:
|
|||
- const: starfive,jh7110-dwmac
|
||||
- const: snps,dwmac-5.20
|
||||
- items:
|
||||
- const: starfive,jh8100-dwmac
|
||||
- const: starfive,jhb100-dwmac
|
||||
- const: starfive,jh7110-dwmac
|
||||
- const: snps,dwmac-5.20
|
||||
|
||||
|
|
@ -39,20 +39,24 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 5
|
||||
items:
|
||||
- description: GMAC main clock
|
||||
- description: GMAC AHB clock
|
||||
- description: PTP clock
|
||||
- description: TX clock
|
||||
- description: GTX clock
|
||||
- description: SGMII RX clock
|
||||
|
||||
clock-names:
|
||||
minItems: 5
|
||||
items:
|
||||
- const: stmmaceth
|
||||
- const: pclk
|
||||
- const: ptp_ref
|
||||
- const: tx
|
||||
- const: gtx
|
||||
- const: sgmii_rx
|
||||
|
||||
starfive,tx-use-rgmii-clk:
|
||||
description:
|
||||
|
|
@ -111,22 +115,19 @@ allOf:
|
|||
contains:
|
||||
const: starfive,jh7110-dwmac
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
|
||||
interrupt-names:
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: starfive,jh8100-dwmac
|
||||
const: starfive,jhb100-dwmac
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
interrupt-names:
|
||||
const: macirq
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
|
|
@ -134,6 +135,14 @@ allOf:
|
|||
const: stmmaceth
|
||||
else:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
|
||||
interrupt-names:
|
||||
minItems: 3
|
||||
maxItems: 3
|
||||
|
||||
resets:
|
||||
minItems: 2
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/wireless/st,stlc4560.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ST/Intersil/Conexant stlc45xx/p54spi/cx3110x SPI wireless device
|
||||
|
||||
maintainers:
|
||||
- Christian Lamparter <chunkeey@gmail.com>
|
||||
|
||||
description:
|
||||
The SPI variant of the Intersil Prism54 wireless device was sold
|
||||
under a variety of names, including Conexant CX3110x and
|
||||
ST Microelectronics STLC5460.
|
||||
|
||||
allOf:
|
||||
- $ref: ieee80211.yaml#
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: st,stlc4560
|
||||
- items:
|
||||
- enum:
|
||||
- cnxt,3110x
|
||||
- isil,p54spi
|
||||
- st,stlc4550
|
||||
- const: st,stlc4560
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
powerdown-gpios:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
wifi@0 {
|
||||
compatible = "st,stlc4560";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <48000000>;
|
||||
interrupts-extended = <&gpio 23>;
|
||||
powerdown-gpios = <&gpio 1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -65,35 +65,43 @@ request, where user provides attributes that result in single pin match.
|
|||
Pin selection
|
||||
=============
|
||||
|
||||
In general, selected pin (the one which signal is driving the dpll
|
||||
device) can be obtained from ``DPLL_A_PIN_STATE`` attribute, and only
|
||||
one pin shall be in ``DPLL_PIN_STATE_CONNECTED`` state for any dpll
|
||||
device.
|
||||
Pin state (``DPLL_A_PIN_STATE``) reflects the administrative intent set
|
||||
by the user. Pin operational state (``DPLL_A_PIN_OPERSTATE``) reflects
|
||||
what the hardware is actually doing with the pin.
|
||||
|
||||
Pin selection can be done either manually or automatically, depending
|
||||
on hardware capabilities and active dpll device work mode
|
||||
(``DPLL_A_MODE`` attribute). The consequence is that there are
|
||||
differences for each mode in terms of available pin states, as well as
|
||||
for the states the user can request for a dpll device.
|
||||
differences for each mode in terms of available pin states the user can
|
||||
request for a dpll device.
|
||||
|
||||
In manual mode (``DPLL_MODE_MANUAL``) the user can request or receive
|
||||
one of following pin states:
|
||||
In manual mode (``DPLL_MODE_MANUAL``) the user can request one of
|
||||
following pin states:
|
||||
|
||||
- ``DPLL_PIN_STATE_CONNECTED`` - the pin is used to drive dpll device
|
||||
- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin is not used to drive dpll
|
||||
- ``DPLL_PIN_STATE_CONNECTED`` - the pin is selected to drive dpll
|
||||
device
|
||||
- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin is not selected to drive
|
||||
dpll device
|
||||
|
||||
In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can request or
|
||||
receive one of following pin states:
|
||||
In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can request one of
|
||||
following pin states:
|
||||
|
||||
- ``DPLL_PIN_STATE_SELECTABLE`` - the pin shall be considered as valid
|
||||
input for automatic selection algorithm
|
||||
- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin shall be not considered as
|
||||
a valid input for automatic selection algorithm
|
||||
|
||||
In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can only receive
|
||||
pin state ``DPLL_PIN_STATE_CONNECTED`` once automatic selection
|
||||
algorithm locks a dpll device with one of the inputs.
|
||||
The actual hardware status of a pin is reported via the operational
|
||||
state (``DPLL_A_PIN_OPERSTATE``) attribute nested under the parent
|
||||
device:
|
||||
|
||||
- ``DPLL_PIN_OPERSTATE_ACTIVE`` - pin is qualified and actively used
|
||||
by the DPLL
|
||||
- ``DPLL_PIN_OPERSTATE_STANDBY`` - pin is qualified but not actively
|
||||
used by the DPLL
|
||||
- ``DPLL_PIN_OPERSTATE_NO_SIGNAL`` - pin does not have a valid signal
|
||||
- ``DPLL_PIN_OPERSTATE_QUAL_FAILED`` - pin signal failed qualification
|
||||
checks
|
||||
|
||||
Shared pins
|
||||
===========
|
||||
|
|
@ -250,6 +258,26 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
|
|||
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
|
||||
=============================== ========================
|
||||
|
||||
Fractional frequency offset
|
||||
===========================
|
||||
|
||||
The fractional frequency offset (FFO) is reported through two attributes
|
||||
that carry the same measurement at different precisions:
|
||||
|
||||
- ``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET`` in PPM (parts per million)
|
||||
- ``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT`` in PPT (parts per trillion)
|
||||
|
||||
Both attributes appear at the top level of a pin and inside each
|
||||
``pin-parent-device`` nest. Two FFO types are defined:
|
||||
|
||||
- ``DPLL_FFO_PORT_RXTX_RATE`` - RX vs TX symbol rate offset (top-level)
|
||||
- ``DPLL_FFO_PIN_DEVICE`` - pin vs parent DPLL offset (per-parent)
|
||||
|
||||
The driver declares which types it supports via the ``supported_ffo``
|
||||
bitmask in ``struct dpll_pin_ops``. The core only calls the ``ffo_get``
|
||||
callback for types the driver has opted into. The requested type is
|
||||
passed to the driver in the ``struct dpll_ffo_param``.
|
||||
|
||||
Frequency monitor
|
||||
=================
|
||||
|
||||
|
|
|
|||
107
Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst
Normal file
107
Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================================
|
||||
Motorcomm yt8xxx PHY properties (_DSD)
|
||||
======================================
|
||||
|
||||
This document describes ACPI _DSD device properties for Motorcomm yt8xxx
|
||||
Ethernet PHYs supported by the in-kernel driver in
|
||||
``drivers/net/phy/motorcomm.c``.
|
||||
|
||||
The properties are exposed on the PHY device object under the MDIO bus ACPI
|
||||
device (the same objects that are registered via
|
||||
``fwnode_mdiobus_register_phy()``). MAC-side connection properties such as
|
||||
``phy-handle`` and ``phy-mode`` are documented in [acpi-mdio-phy]_.
|
||||
|
||||
Property names and semantics are intentionally aligned with the Devicetree
|
||||
binding [motorcomm-yt8xxx]_ so that the same driver code path
|
||||
(``device_property_*`` on ``&phydev->mdio.dev``) can consume firmware
|
||||
described either as Devicetree or ACPI _DSD.
|
||||
|
||||
UUID and placement
|
||||
==================
|
||||
|
||||
Per [acpi-dsd-properties-rules]_ and [acpi-mdio-phy]_, properties must be
|
||||
placed in an _DSD package using the standard Device Properties UUID::
|
||||
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
|
||||
|
||||
Properties
|
||||
==========
|
||||
|
||||
Unless noted otherwise, integer properties use the same allowed values and
|
||||
defaults as [motorcomm-yt8xxx]_.
|
||||
|
||||
``rx-internal-delay-ps`` (u32, optional)
|
||||
RGMII RX internal delay in picoseconds. Only meaningful when the link is
|
||||
using RGMII modes with RX internal delay; see [motorcomm-yt8xxx]_.
|
||||
|
||||
``tx-internal-delay-ps`` (u32, optional)
|
||||
RGMII TX internal delay in picoseconds. Only meaningful when the link is
|
||||
using RGMII modes with TX internal delay; see [motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,clk-out-frequency-hz`` (u32, optional)
|
||||
Clock output frequency on the PHY clock output pin. Allowed values and
|
||||
default are defined in [motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,keep-pll-enabled`` (boolean, optional)
|
||||
If true, keep the PLL enabled even when there is no link (useful for using
|
||||
the clock output without an Ethernet link). See [motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,auto-sleep-disabled`` (boolean, optional)
|
||||
If true, disable the PHY auto-sleep behavior described in
|
||||
[motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,rx-clk-drv-microamp`` (u32, optional)
|
||||
Drive strength for the ``rx_clk`` RGMII pad in microamps. Allowed values
|
||||
depend on the configured RGMII LDO voltage; see [motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,rx-data-drv-microamp`` (u32, optional)
|
||||
Drive strength for the ``rx_data`` and ``rx_ctl`` RGMII pads in microamps.
|
||||
See [motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,tx-clk-adj-enabled`` (boolean, optional)
|
||||
Enables adjustments related to ``motorcomm,tx-clk-*-inverted`` usage; see
|
||||
[motorcomm-yt8xxx]_.
|
||||
|
||||
``motorcomm,tx-clk-10-inverted`` (boolean, optional)
|
||||
``motorcomm,tx-clk-100-inverted`` (boolean, optional)
|
||||
``motorcomm,tx-clk-1000-inverted`` (boolean, optional)
|
||||
Per-speed TX clock inversion options; see [motorcomm-yt8xxx]_.
|
||||
|
||||
ASL example (illustrative)
|
||||
==========================
|
||||
|
||||
The example below only shows PHY-local _DSD properties. A real platform
|
||||
still needs a MAC ``phy-handle`` and ``phy-mode`` package as in
|
||||
[acpi-mdio-phy]_.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Scope (\_SB.MDI0)
|
||||
{
|
||||
Device (PHY4)
|
||||
{
|
||||
Name (_ADR, 0x4)
|
||||
|
||||
Name (_DSD, Package () {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package (2) { "rx-internal-delay-ps", 2100 },
|
||||
Package (2) { "tx-internal-delay-ps", 150 },
|
||||
Package (2) { "motorcomm,clk-out-frequency-hz", 0 },
|
||||
Package (2) { "motorcomm,keep-pll-enabled", 1 },
|
||||
Package (2) { "motorcomm,auto-sleep-disabled", 1 },
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [acpi-mdio-phy] Documentation/firmware-guide/acpi/dsd/phy.rst
|
||||
.. [acpi-dsd-properties-rules]
|
||||
Documentation/firmware-guide/acpi/DSD-properties-rules.rst
|
||||
.. [motorcomm-yt8xxx]
|
||||
Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
|
||||
|
|
@ -11,6 +11,7 @@ ACPI Support
|
|||
dsd/graph
|
||||
dsd/data-node-references
|
||||
dsd/leds
|
||||
dsd/motorcomm-yt8xxx-phy
|
||||
dsd/phy
|
||||
enumeration
|
||||
osi
|
||||
|
|
|
|||
|
|
@ -234,6 +234,10 @@ definitions:
|
|||
value: 10
|
||||
-
|
||||
name: binary
|
||||
-
|
||||
name: u64-array
|
||||
value: 129
|
||||
|
||||
-
|
||||
name: rate-tc-index-max
|
||||
type: const
|
||||
|
|
|
|||
|
|
@ -138,6 +138,9 @@ definitions:
|
|||
-
|
||||
name: eec
|
||||
doc: dpll drives the Ethernet Equipment Clock
|
||||
-
|
||||
name: generic
|
||||
doc: generic dpll type for devices outside PPS/EEC classes
|
||||
render-max: true
|
||||
-
|
||||
type: enum
|
||||
|
|
@ -212,6 +215,27 @@ definitions:
|
|||
name: selectable
|
||||
doc: pin enabled for automatic input selection
|
||||
render-max: true
|
||||
-
|
||||
type: enum
|
||||
name: pin-operstate
|
||||
doc: |
|
||||
defines possible operational states of a pin with respect to its
|
||||
parent DPLL device, valid values for DPLL_A_PIN_OPERSTATE attribute
|
||||
entries:
|
||||
-
|
||||
name: active
|
||||
doc: pin is qualified and actively used by the DPLL
|
||||
value: 1
|
||||
-
|
||||
name: standby
|
||||
doc: pin is qualified but not actively used by the DPLL
|
||||
-
|
||||
name: no-signal
|
||||
doc: pin does not have a valid signal
|
||||
-
|
||||
name: qual-failed
|
||||
doc: pin signal failed qualification (e.g. frequency or phase monitor)
|
||||
render-max: true
|
||||
-
|
||||
type: flags
|
||||
name: pin-capabilities
|
||||
|
|
@ -427,12 +451,14 @@ attribute-sets:
|
|||
name: fractional-frequency-offset
|
||||
type: sint
|
||||
doc: |
|
||||
The FFO (Fractional Frequency Offset) between the RX and TX
|
||||
symbol rate on the media associated with the pin:
|
||||
(rx_frequency-tx_frequency)/rx_frequency
|
||||
The FFO (Fractional Frequency Offset) of the pin.
|
||||
At top level this represents the RX vs TX symbol rate
|
||||
offset on the media associated with the pin. Inside
|
||||
the pin-parent-device nest it represents the frequency
|
||||
offset between the pin and its parent DPLL device.
|
||||
Value is in PPM (parts per million).
|
||||
This may be implemented for example for pin of type
|
||||
PIN_TYPE_SYNCE_ETH_PORT.
|
||||
This is a lower-precision version of
|
||||
fractional-frequency-offset-ppt.
|
||||
-
|
||||
name: esync-frequency
|
||||
type: u64
|
||||
|
|
@ -471,12 +497,14 @@ attribute-sets:
|
|||
name: fractional-frequency-offset-ppt
|
||||
type: sint
|
||||
doc: |
|
||||
The FFO (Fractional Frequency Offset) of the pin with respect to
|
||||
the nominal frequency.
|
||||
Value = (frequency_measured - frequency_nominal) / frequency_nominal
|
||||
The FFO (Fractional Frequency Offset) of the pin.
|
||||
At top level this represents the RX vs TX symbol rate
|
||||
offset on the media associated with the pin. Inside
|
||||
the pin-parent-device nest it represents the frequency
|
||||
offset between the pin and its parent DPLL device.
|
||||
Value is in PPT (parts per trillion, 10^-12).
|
||||
Note: This attribute provides higher resolution than the standard
|
||||
fractional-frequency-offset (which is in PPM).
|
||||
This is a higher-precision version of
|
||||
fractional-frequency-offset.
|
||||
-
|
||||
name: measured-frequency
|
||||
type: u64
|
||||
|
|
@ -488,6 +516,14 @@ attribute-sets:
|
|||
Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
|
||||
DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part
|
||||
of a measured frequency value.
|
||||
-
|
||||
name: operstate
|
||||
type: u32
|
||||
enum: pin-operstate
|
||||
doc: |
|
||||
Operational state of the pin with respect to its parent DPLL
|
||||
device. Unlike state (which reflects the administrative intent),
|
||||
operstate reflects the actual hardware status.
|
||||
|
||||
-
|
||||
name: pin-parent-device
|
||||
|
|
@ -501,8 +537,14 @@ attribute-sets:
|
|||
name: prio
|
||||
-
|
||||
name: state
|
||||
-
|
||||
name: operstate
|
||||
-
|
||||
name: phase-offset
|
||||
-
|
||||
name: fractional-frequency-offset
|
||||
-
|
||||
name: fractional-frequency-offset-ppt
|
||||
-
|
||||
name: pin-parent-pin
|
||||
subset-of: pin
|
||||
|
|
|
|||
|
|
@ -125,6 +125,7 @@ operations:
|
|||
name: done
|
||||
doc: Handler reports handshake completion
|
||||
attribute-set: done
|
||||
flags: [admin-perm]
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
|
|
|
|||
|
|
@ -127,7 +127,14 @@ attribute-sets:
|
|||
enum: xsk-flags
|
||||
-
|
||||
name: io-uring-provider-info
|
||||
attributes: []
|
||||
attributes:
|
||||
-
|
||||
name: rx-buf-len
|
||||
type: uint
|
||||
doc: |
|
||||
RX buffer length in bytes for this io_uring memory provider.
|
||||
Reflects the rx_buf_len passed at io_uring zerocopy rx
|
||||
registration time.
|
||||
-
|
||||
name: page-pool
|
||||
attributes:
|
||||
|
|
@ -649,6 +656,9 @@ operations:
|
|||
- dmabuf
|
||||
- io-uring
|
||||
dump:
|
||||
request:
|
||||
attributes:
|
||||
- ifindex
|
||||
reply: *pp-reply
|
||||
config-cond: page-pool
|
||||
-
|
||||
|
|
@ -692,6 +702,9 @@ operations:
|
|||
- recycle-ring-full
|
||||
- recycle-released-refcnt
|
||||
dump:
|
||||
request:
|
||||
attributes:
|
||||
- info
|
||||
reply: *pp-stats-reply
|
||||
config-cond: page-pool-stats
|
||||
-
|
||||
|
|
@ -792,7 +805,7 @@ operations:
|
|||
name: bind-rx
|
||||
doc: Bind dmabuf to netdev
|
||||
attribute-set: dmabuf
|
||||
flags: [admin-perm]
|
||||
flags: [uns-admin-perm]
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
|
|
|
|||
130
Documentation/netlink/specs/ovs_packet.yaml
Normal file
130
Documentation/netlink/specs/ovs_packet.yaml
Normal file
|
|
@ -0,0 +1,130 @@
|
|||
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
|
||||
---
|
||||
name: ovs_packet
|
||||
version: 1
|
||||
protocol: genetlink-legacy
|
||||
uapi-header: linux/openvswitch.h
|
||||
|
||||
doc: |
|
||||
OVS packet execution over generic netlink.
|
||||
|
||||
Only OVS_PACKET_CMD_EXECUTE is exposed as a genl operation.
|
||||
OVS_PACKET_CMD_MISS and OVS_PACKET_CMD_ACTION are kernel-to-userspace
|
||||
upcalls sent via genlmsg_unicast() to the vport's upcall_pid and have
|
||||
no associated genl_ops or multicast group.
|
||||
|
||||
Several attributes in the attribute set (userdata, egress-tun-key, len)
|
||||
exist for the upcall path and are not used by the EXECUTE operation.
|
||||
For EXECUTE, packet, key, and actions are mandatory (kernel returns
|
||||
-EINVAL without them).
|
||||
|
||||
definitions:
|
||||
-
|
||||
name: ovs-header
|
||||
type: struct
|
||||
members:
|
||||
-
|
||||
name: dp-ifindex
|
||||
type: u32
|
||||
|
||||
attribute-sets:
|
||||
-
|
||||
name: packet
|
||||
name-prefix: ovs-packet-attr-
|
||||
enum-name: ovs-packet-attr
|
||||
attributes:
|
||||
-
|
||||
name: packet
|
||||
type: binary
|
||||
doc: Packet data, from the start of the Ethernet header.
|
||||
checks:
|
||||
min-len: 14
|
||||
-
|
||||
name: key
|
||||
type: binary
|
||||
doc: |
|
||||
Nested OVS_KEY_ATTR_* attributes, extracted flow key.
|
||||
Defined as binary because the key attribute-set belongs to the
|
||||
ovs_flow family spec; cross-spec references are not supported.
|
||||
-
|
||||
name: actions
|
||||
type: binary
|
||||
doc: |
|
||||
Nested OVS_ACTION_ATTR_* attributes.
|
||||
Defined as binary for the same reason as key.
|
||||
-
|
||||
name: userdata
|
||||
type: binary
|
||||
doc: Opaque userspace cookie from OVS_USERSPACE_ATTR_USERDATA.
|
||||
-
|
||||
name: egress-tun-key
|
||||
type: binary
|
||||
doc: Nested OVS_TUNNEL_KEY_ATTR_* for output tunnel metadata.
|
||||
-
|
||||
name: unused1
|
||||
type: unused
|
||||
-
|
||||
name: unused2
|
||||
type: unused
|
||||
-
|
||||
name: probe
|
||||
type: flag
|
||||
doc: Packet operation is a feature probe, error logging suppressed.
|
||||
-
|
||||
name: mru
|
||||
type: u16
|
||||
doc: Maximum received IP fragment size.
|
||||
-
|
||||
name: len
|
||||
type: u32
|
||||
doc: Packet size before truncation.
|
||||
-
|
||||
name: hash
|
||||
type: u64
|
||||
doc: Packet hash, low 32 bits are skb hash, upper bits are flags.
|
||||
-
|
||||
name: upcall-pid
|
||||
type: u32
|
||||
doc: Netlink PID to use for upcalls during EXECUTE processing.
|
||||
|
||||
operations:
|
||||
fixed-header: ovs-header
|
||||
name-prefix: ovs-packet-cmd-
|
||||
list:
|
||||
-
|
||||
name: miss
|
||||
doc: Notify userspace of a flow table miss for a received packet.
|
||||
value: 1
|
||||
attribute-set: packet
|
||||
event:
|
||||
attributes: &event-attrs
|
||||
- packet
|
||||
- key
|
||||
- userdata
|
||||
- actions
|
||||
- egress-tun-key
|
||||
- mru
|
||||
- len
|
||||
- hash
|
||||
-
|
||||
name: action
|
||||
doc: Notify userspace as requested by an OVS_ACTION_ATTR_USERSPACE action.
|
||||
value: 2
|
||||
attribute-set: packet
|
||||
event:
|
||||
attributes: *event-attrs
|
||||
-
|
||||
name: execute
|
||||
doc: Apply actions to a packet.
|
||||
value: 3
|
||||
attribute-set: packet
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
- packet
|
||||
- key
|
||||
- actions
|
||||
- probe
|
||||
- mru
|
||||
- hash
|
||||
- upcall-pid
|
||||
|
|
@ -13,6 +13,17 @@ definitions:
|
|||
hdr0-aes-gmac-128, hdr0-aes-gmac-256]
|
||||
|
||||
attribute-sets:
|
||||
-
|
||||
name: assoc-dev-info
|
||||
attributes:
|
||||
-
|
||||
name: ifindex
|
||||
doc: ifindex of an associated network device.
|
||||
type: u32
|
||||
-
|
||||
name: nsid
|
||||
doc: Network namespace ID of the associated device.
|
||||
type: s32
|
||||
-
|
||||
name: dev
|
||||
attributes:
|
||||
|
|
@ -24,7 +35,9 @@ attribute-sets:
|
|||
min: 1
|
||||
-
|
||||
name: ifindex
|
||||
doc: ifindex of the main netdevice linked to the PSP device.
|
||||
doc: |
|
||||
ifindex of the main netdevice linked to the PSP device,
|
||||
or the ifindex to associate with the PSP device.
|
||||
type: u32
|
||||
-
|
||||
name: psp-versions-cap
|
||||
|
|
@ -38,6 +51,28 @@ attribute-sets:
|
|||
type: u32
|
||||
enum: version
|
||||
enum-as-flags: true
|
||||
-
|
||||
name: assoc-list
|
||||
doc: List of associated virtual devices.
|
||||
type: nest
|
||||
nested-attributes: assoc-dev-info
|
||||
multi-attr: true
|
||||
-
|
||||
name: nsid
|
||||
doc: |
|
||||
Network namespace ID for the device to associate/disassociate.
|
||||
Optional for dev-assoc and dev-disassoc; if not present, the
|
||||
device is looked up in the caller's network namespace.
|
||||
type: s32
|
||||
-
|
||||
name: by-association
|
||||
doc: |
|
||||
Flag indicating the PSP device is an associated device from a
|
||||
different network namespace.
|
||||
Present when in associated namespace, absent when in primary/host
|
||||
namespace.
|
||||
type: flag
|
||||
|
||||
-
|
||||
name: assoc
|
||||
attributes:
|
||||
|
|
@ -170,6 +205,8 @@ operations:
|
|||
- ifindex
|
||||
- psp-versions-cap
|
||||
- psp-versions-ena
|
||||
- assoc-list
|
||||
- by-association
|
||||
pre: psp-device-get-locked
|
||||
post: psp-device-unlock
|
||||
dump:
|
||||
|
|
@ -196,7 +233,7 @@ operations:
|
|||
- psp-versions-ena
|
||||
reply:
|
||||
attributes: []
|
||||
pre: psp-device-get-locked
|
||||
pre: psp-device-get-locked-admin
|
||||
post: psp-device-unlock
|
||||
-
|
||||
name: dev-change-ntf
|
||||
|
|
@ -216,7 +253,7 @@ operations:
|
|||
reply:
|
||||
attributes:
|
||||
- id
|
||||
pre: psp-device-get-locked
|
||||
pre: psp-device-get-locked-admin
|
||||
post: psp-device-unlock
|
||||
-
|
||||
name: key-rotate-ntf
|
||||
|
|
@ -281,6 +318,36 @@ operations:
|
|||
post: psp-device-unlock
|
||||
dump:
|
||||
reply: *stats-all
|
||||
-
|
||||
name: dev-assoc
|
||||
doc: Associate a network device with a PSP device.
|
||||
attribute-set: dev
|
||||
flags: [admin-perm]
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
- id
|
||||
- ifindex
|
||||
- nsid
|
||||
reply:
|
||||
attributes: []
|
||||
pre: psp-device-get-locked-dev-assoc
|
||||
post: psp-device-unlock
|
||||
-
|
||||
name: dev-disassoc
|
||||
doc: Disassociate a network device from a PSP device.
|
||||
attribute-set: dev
|
||||
flags: [admin-perm]
|
||||
do:
|
||||
request:
|
||||
attributes:
|
||||
- id
|
||||
- ifindex
|
||||
- nsid
|
||||
reply:
|
||||
attributes: []
|
||||
pre: psp-device-get-locked
|
||||
post: psp-device-unlock
|
||||
|
||||
mcast-groups:
|
||||
list:
|
||||
|
|
|
|||
|
|
@ -880,19 +880,21 @@ attribute-sets:
|
|||
struct: rtnl-link-stats
|
||||
-
|
||||
name: cost
|
||||
type: string
|
||||
type: unused
|
||||
-
|
||||
name: priority
|
||||
type: string
|
||||
type: unused
|
||||
-
|
||||
name: master
|
||||
type: u32
|
||||
-
|
||||
name: wireless
|
||||
type: string
|
||||
type: binary
|
||||
doc: struct iw_event
|
||||
-
|
||||
name: protinfo
|
||||
type: string
|
||||
type: binary
|
||||
doc: A nest of ifla6-attrs or linkinfo-brport-attrs
|
||||
-
|
||||
name: txqlen
|
||||
type: u32
|
||||
|
|
@ -1351,6 +1353,12 @@ attribute-sets:
|
|||
-
|
||||
name: coupled-control
|
||||
type: u8
|
||||
-
|
||||
name: broadcast-neigh
|
||||
type: u8
|
||||
-
|
||||
name: lacp-strict
|
||||
type: u8
|
||||
-
|
||||
name: bond-ad-info-attrs
|
||||
name-prefix: ifla-bond-ad-info-
|
||||
|
|
@ -1700,6 +1708,9 @@ attribute-sets:
|
|||
-
|
||||
name: backup-nhid
|
||||
type: u32
|
||||
-
|
||||
name: neigh-forward-grat
|
||||
type: u8
|
||||
-
|
||||
name: linkinfo-gre-attrs
|
||||
name-prefix: ifla-gre-
|
||||
|
|
@ -1936,6 +1947,15 @@ attribute-sets:
|
|||
-
|
||||
name: gro-hint
|
||||
type: flag
|
||||
-
|
||||
name: local
|
||||
type: u32
|
||||
byte-order: big-endian
|
||||
display-hint: ipv4
|
||||
-
|
||||
name: local6
|
||||
type: binary
|
||||
display-hint: ipv6
|
||||
-
|
||||
name: linkinfo-hsr-attrs
|
||||
name-prefix: ifla-hsr-
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -8,30 +8,10 @@ ARCnet
|
|||
|
||||
.. note::
|
||||
|
||||
See also arcnet-hardware.txt in this directory for jumper-setting
|
||||
See also arcnet-hardware.rst in this directory for jumper-setting
|
||||
and cabling information if you're like many of us and didn't happen to get a
|
||||
manual with your ARCnet card.
|
||||
|
||||
Since no one seems to listen to me otherwise, perhaps a poem will get your
|
||||
attention::
|
||||
|
||||
This driver's getting fat and beefy,
|
||||
But my cat is still named Fifi.
|
||||
|
||||
Hmm, I think I'm allowed to call that a poem, even though it's only two
|
||||
lines. Hey, I'm in Computer Science, not English. Give me a break.
|
||||
|
||||
The point is: I REALLY REALLY REALLY REALLY REALLY want to hear from you if
|
||||
you test this and get it working. Or if you don't. Or anything.
|
||||
|
||||
ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
|
||||
nice, but after that even FEWER people started writing to me because they
|
||||
didn't even have to install the patch. <sigh>
|
||||
|
||||
Come on, be a sport! Send me a success report!
|
||||
|
||||
(hey, that was even better than my original poem... this is getting bad!)
|
||||
|
||||
----
|
||||
|
||||
These are the ARCnet drivers for Linux.
|
||||
|
|
@ -62,183 +42,47 @@ netdev@vger.kernel.org and make sure to Cc: maintainer listed in
|
|||
Other Drivers and Info
|
||||
----------------------
|
||||
|
||||
You can try my ARCNET page on the World Wide Web at:
|
||||
You can try JoAnne Schmitz's ARCNET page on the World Wide Web at:
|
||||
|
||||
http://www.qis.net/~jschmitz/arcnet/
|
||||
|
||||
Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
|
||||
might be interested in, which includes several drivers for various cards
|
||||
including ARCnet. Try:
|
||||
|
||||
http://www.smc.com/
|
||||
|
||||
Performance Technologies makes various network software that supports
|
||||
ARCnet:
|
||||
|
||||
http://www.perftech.com/ or ftp to ftp.perftech.com.
|
||||
|
||||
Novell makes a networking stack for DOS which includes ARCnet drivers. Try
|
||||
FTPing to ftp.novell.com.
|
||||
|
||||
You can get the Crynwr packet driver collection (including arcether.com, the
|
||||
one you'll want to use with ARCnet cards) from
|
||||
oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
|
||||
without patches, though, and also doesn't like several cards. Fixed
|
||||
versions are available on my WWW page, or via e-mail if you don't have WWW
|
||||
access.
|
||||
https://www.qis.net/~jschmitz/arcnet/
|
||||
|
||||
|
||||
Installing the Driver
|
||||
---------------------
|
||||
Supported Hardware
|
||||
------------------
|
||||
|
||||
All you will need to do in order to install the driver is::
|
||||
Only PCI and PCI Express devices based on the COM20020 chipset are supported.
|
||||
This is the newest chipset from SMC with support for promiscuous mode (packet
|
||||
sniffing), extra diagnostic information, etc. These devices use the com20020_pci
|
||||
driver.
|
||||
|
||||
make config
|
||||
(be sure to choose ARCnet in the network devices
|
||||
and at least one chipset driver.)
|
||||
make clean
|
||||
make zImage
|
||||
Support for older chipsets and ISA and PCMCIA devices was previously available
|
||||
but has been removed.
|
||||
|
||||
If you obtained this ARCnet package as an upgrade to the ARCnet driver in
|
||||
your current kernel, you will need to first copy arcnet.c over the one in
|
||||
the linux/drivers/net directory.
|
||||
|
||||
You will know the driver is installed properly if you get some ARCnet
|
||||
messages when you reboot into the new Linux kernel.
|
||||
Configuring the Driver
|
||||
----------------------
|
||||
|
||||
There are four chipset options:
|
||||
The COM20020 driver will be loaded automatically at boot if a supported card is
|
||||
detected.
|
||||
|
||||
1. Standard ARCnet COM90xx chipset.
|
||||
If the com20020_pci driver was compiled as a loadable module, the options are::
|
||||
|
||||
This is the normal ARCnet card, which you've probably got. This is the only
|
||||
chipset driver which will autoprobe if not told where the card is.
|
||||
It following options on the command line::
|
||||
node=<node_ID> backplane=<backplane> clockp=<CKP> clockm=<CKM>
|
||||
timeout=<timeout> device=<interface_name>
|
||||
|
||||
com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
|
||||
If the driver was compiled into the kernel, the same options can be specified on
|
||||
the kernel command line by prefixing them with `com20020_pci.`, as in the
|
||||
following example::
|
||||
|
||||
If you load the chipset support as a module, the options are::
|
||||
|
||||
io=<io> irq=<irq> shmem=<shmem> device=<name>
|
||||
|
||||
To disable the autoprobe, just specify "com90xx=" on the kernel command line.
|
||||
To specify the name alone, but allow autoprobe, just put "com90xx=<name>"
|
||||
|
||||
2. ARCnet COM20020 chipset.
|
||||
|
||||
This is the new chipset from SMC with support for promiscuous mode (packet
|
||||
sniffing), extra diagnostic information, etc. Unfortunately, there is no
|
||||
sensible method of autoprobing for these cards. You must specify the I/O
|
||||
address on the kernel command line.
|
||||
|
||||
The command line options are::
|
||||
|
||||
com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
|
||||
|
||||
If you load the chipset support as a module, the options are::
|
||||
|
||||
io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>
|
||||
timeout=<timeout> device=<name>
|
||||
com20020_pci.device=eth1
|
||||
|
||||
The COM20020 chipset allows you to set the node ID in software, overriding the
|
||||
default which is still set in DIP switches on the card. If you don't have the
|
||||
COM20020 data sheets, and you don't know what the other three options refer
|
||||
COM20020 data sheets, and you don't know what the other options refer
|
||||
to, then they won't interest you - forget them.
|
||||
|
||||
3. ARCnet COM90xx chipset in IO-mapped mode.
|
||||
|
||||
This will also work with the normal ARCnet cards, but doesn't use the shared
|
||||
memory. It performs less well than the above driver, but is provided in case
|
||||
you have a card which doesn't support shared memory, or (strangely) in case
|
||||
you have so many ARCnet cards in your machine that you run out of shmem slots.
|
||||
If you don't give the IO address on the kernel command line, then the driver
|
||||
will not find the card.
|
||||
|
||||
The command line options are::
|
||||
|
||||
com90io=<io>[,<irq>][,<name>]
|
||||
|
||||
If you load the chipset support as a module, the options are:
|
||||
io=<io> irq=<irq> device=<name>
|
||||
|
||||
4. ARCnet RIM I cards.
|
||||
|
||||
These are COM90xx chips which are _completely_ memory mapped. The support for
|
||||
these is not tested. If you have one, please mail the author with a success
|
||||
report. All options must be specified, except the device name.
|
||||
Command line options::
|
||||
|
||||
arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
|
||||
|
||||
If you load the chipset support as a module, the options are::
|
||||
|
||||
shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
|
||||
|
||||
|
||||
Loadable Module Support
|
||||
-----------------------
|
||||
|
||||
Configure and rebuild Linux. When asked, answer 'm' to "Generic ARCnet
|
||||
support" and to support for your ARCnet chipset if you want to use the
|
||||
loadable module. You can also say 'y' to "Generic ARCnet support" and 'm'
|
||||
to the chipset support if you wish.
|
||||
|
||||
::
|
||||
|
||||
make config
|
||||
make clean
|
||||
make zImage
|
||||
make modules
|
||||
|
||||
If you're using a loadable module, you need to use insmod to load it, and
|
||||
you can specify various characteristics of your card on the command
|
||||
line. (In recent versions of the driver, autoprobing is much more reliable
|
||||
and works as a module, so most of this is now unnecessary.)
|
||||
|
||||
For example::
|
||||
|
||||
cd /usr/src/linux/modules
|
||||
insmod arcnet.o
|
||||
insmod com90xx.o
|
||||
insmod com20020.o io=0x2e0 device=eth1
|
||||
|
||||
|
||||
Using the Driver
|
||||
----------------
|
||||
|
||||
If you build your kernel with ARCnet COM90xx support included, it should
|
||||
probe for your card automatically when you boot. If you use a different
|
||||
chipset driver complied into the kernel, you must give the necessary options
|
||||
on the kernel command line, as detailed above.
|
||||
|
||||
Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
|
||||
available where you picked up this driver. Think of your ARCnet as a
|
||||
souped-up (or down, as the case may be) Ethernet card.
|
||||
|
||||
By the way, be sure to change all references from "eth0" to "arc0" in the
|
||||
HOWTOs. Remember that ARCnet isn't a "true" Ethernet, and the device name
|
||||
is DIFFERENT.
|
||||
|
||||
|
||||
Multiple Cards in One Computer
|
||||
------------------------------
|
||||
|
||||
Linux has pretty good support for this now, but since I've been busy, the
|
||||
ARCnet driver has somewhat suffered in this respect. COM90xx support, if
|
||||
compiled into the kernel, will (try to) autodetect all the installed cards.
|
||||
|
||||
If you have other cards, with support compiled into the kernel, then you can
|
||||
just repeat the options on the kernel command line, e.g.::
|
||||
|
||||
LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
|
||||
|
||||
If you have the chipset support built as a loadable module, then you need to
|
||||
do something like this::
|
||||
|
||||
insmod -o arc0 com90xx
|
||||
insmod -o arc1 com20020 io=0x2e0
|
||||
insmod -o arc2 com90xx
|
||||
|
||||
The ARCnet drivers will now sort out their names automatically.
|
||||
Otherwise, ARCnet can be configured in a similar way to Ethernet, with the
|
||||
exception that ARCnet interface names begin with `arc`.
|
||||
|
||||
|
||||
How do I get it to work with...?
|
||||
|
|
@ -276,9 +120,8 @@ LAN Manager and Windows for Workgroups:
|
|||
are incompatible with the Internet standard. They try to pretend
|
||||
the cards are Ethernet, and confuse everyone else on the network.
|
||||
|
||||
However, v2.00 and higher of the Linux ARCnet driver supports this
|
||||
protocol via the 'arc0e' device. See the section on "Multiprotocol
|
||||
Support" for more information.
|
||||
The Linux ARCnet driver supports this protocol via the 'arc0e' device.
|
||||
See the section on "Multiprotocol Support" for more information.
|
||||
|
||||
Using the freeware Samba server and clients for Linux, you can now
|
||||
interface quite nicely with TCP/IP-based WfWg or Lan Manager
|
||||
|
|
@ -313,7 +156,7 @@ NetBSD/AmiTCP:
|
|||
Using Multiprotocol ARCnet
|
||||
--------------------------
|
||||
|
||||
The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
|
||||
The ARCnet driver supports three protocols, each on its own
|
||||
"virtual network device":
|
||||
|
||||
====== ===============================================================
|
||||
|
|
@ -505,7 +348,7 @@ can set up your network then:
|
|||
It works: what now?
|
||||
-------------------
|
||||
|
||||
Send mail following :ref:`arcnet-netdev`. Describe your setup, preferably
|
||||
:ref:`Send an email to netdev <arcnet-netdev>`. Describe your setup, preferably
|
||||
including driver version, kernel version, ARCnet card model, CPU type, number
|
||||
of systems on your network, and list of software in use.
|
||||
|
||||
|
|
@ -524,10 +367,6 @@ first! D_DURING displays 4-5 lines for each packet sent or received. D_TX,
|
|||
D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
|
||||
which is obviously quite big.
|
||||
|
||||
Starting with v2.40 ALPHA, the autoprobe routines have changed
|
||||
significantly. In particular, they won't tell you why the card was not
|
||||
found unless you turn on the D_INIT_REASONS debugging flag.
|
||||
|
||||
Once the driver is running, you can run the arcdump shell script (available
|
||||
from me or in the full ARCnet package, if you have it) as root to list the
|
||||
contents of the arcnet buffers at any time. To make any sense at all out of
|
||||
|
|
@ -548,21 +387,13 @@ out which bytes are being used by a packet.
|
|||
You can change the debug level without recompiling the kernel by typing::
|
||||
|
||||
ifconfig arc0 down metric 1xxx
|
||||
/etc/rc.d/rc.inet1
|
||||
ifconfig arc0 up
|
||||
|
||||
where "xxx" is the debug level you want. For example, "metric 1015" would put
|
||||
you at debug level 15. Debug level 7 is currently the default.
|
||||
|
||||
Note that the debug level is (starting with v1.90 ALPHA) a binary
|
||||
combination of different debug flags; so debug level 7 is really 1+2+4 or
|
||||
D_NORMAL+D_EXTRA+D_INIT. To include D_DURING, you would add 16 to this,
|
||||
resulting in debug level 23.
|
||||
Note that the debug level is a binary combination of different debug flags;
|
||||
debug level 7 is really 1+2+4 or D_NORMAL+D_EXTRA+D_INIT. To include D_DURING,
|
||||
you would add 16 to this, resulting in debug level 23.
|
||||
|
||||
If you don't understand that, you probably don't want to know anyway.
|
||||
E-mail me about your problem.
|
||||
|
||||
|
||||
I want to send money: what now?
|
||||
-------------------------------
|
||||
|
||||
Go take a nap or something. You'll feel better in the morning.
|
||||
|
|
|
|||
|
|
@ -619,6 +619,29 @@ min_links
|
|||
aggregator cannot be active without at least one available link,
|
||||
setting this option to 0 or to 1 has the exact same effect.
|
||||
|
||||
lacp_strict
|
||||
|
||||
Specifies the fallback behavior of a bonding when LACP negotiation
|
||||
fails on all slave links, i.e. when no slave is in the
|
||||
Collecting_Distributing state, while at least `min_links` link still
|
||||
reports carrier up.
|
||||
|
||||
This option is only applicable to 802.3ad mode (mode 4).
|
||||
|
||||
Valid values are:
|
||||
|
||||
off or 0
|
||||
One interface of the bond is selected to be active, in order to
|
||||
facilitate communication with peer devices that do not implement
|
||||
LACP.
|
||||
|
||||
on or 1
|
||||
Interfaces are only permitted to be made active if they have an
|
||||
active LACP partner and have successfully reached
|
||||
Collecting_Distributing state.
|
||||
|
||||
The default value is 0 (off).
|
||||
|
||||
mode
|
||||
|
||||
Specifies one of the bonding policies. The default is
|
||||
|
|
|
|||
|
|
@ -19,17 +19,14 @@ The following technologies are described:
|
|||
|
||||
Things that should be documented here but aren't yet:
|
||||
|
||||
* RX Checksum Offload
|
||||
* CHECKSUM_UNNECESSARY conversion
|
||||
|
||||
|
||||
TX Checksum Offload
|
||||
===================
|
||||
|
||||
The interface for offloading a transmit checksum to a device is explained in
|
||||
detail in comments near the top of include/linux/skbuff.h.
|
||||
|
||||
In brief, it allows to request the device fill in a single ones-complement
|
||||
In brief, Tx checksum offload allows to request the device fill in a single
|
||||
ones-complement
|
||||
checksum defined by the sk_buff fields skb->csum_start and skb->csum_offset.
|
||||
The device should compute the 16-bit ones-complement checksum (i.e. the
|
||||
'IP-style' checksum) from csum_start to the end of the packet, and fill in the
|
||||
|
|
@ -45,9 +42,10 @@ encapsulation is used, the packet may have multiple checksum fields in
|
|||
different header layers, and the rest will have to be handled by another
|
||||
mechanism such as LCO or RCO.
|
||||
|
||||
CRC32c can also be offloaded using this interface, by means of filling
|
||||
skb->csum_start and skb->csum_offset as described above, and setting
|
||||
skb->csum_not_inet: see skbuff.h comment (section 'D') for more details.
|
||||
SCTP CRC32c can also be offloaded using this interface, by means of filling
|
||||
skb->csum_start and skb->csum_offset as described above, setting
|
||||
skb->csum_not_inet, and advertising NETIF_F_SCTP_CRC. Drivers must not treat
|
||||
ordinary IP checksum offload as SCTP CRC32c support.
|
||||
|
||||
No offloading of the IP header checksum is performed; it is always done in
|
||||
software. This is OK because when we build the IP header, we obviously have it
|
||||
|
|
@ -55,18 +53,15 @@ in cache, so summing it isn't expensive. It's also rather short.
|
|||
|
||||
The requirements for GSO are more complicated, because when segmenting an
|
||||
encapsulated packet both the inner and outer checksums may need to be edited or
|
||||
recomputed for each resulting segment. See the skbuff.h comment (section 'E')
|
||||
for more details.
|
||||
recomputed for each resulting segment.
|
||||
|
||||
A driver declares its offload capabilities in netdev->hw_features; see
|
||||
Documentation/networking/netdev-features.rst for more. Note that a device
|
||||
which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start and
|
||||
csum_offset given in the SKB; if it tries to deduce these itself in hardware
|
||||
(as some NICs do) the driver should check that the values in the SKB match
|
||||
those which the hardware will deduce, and if not, fall back to checksumming in
|
||||
software instead (with skb_csum_hwoffload_help() or one of the
|
||||
skb_checksum_help() / skb_crc32c_csum_help functions, as mentioned in
|
||||
include/linux/skbuff.h).
|
||||
Documentation/networking/netdev-features.rst for more. NETIF_F_IP_CSUM and
|
||||
NETIF_F_IPV6_CSUM are restricted legacy features and are being deprecated in
|
||||
favor of NETIF_F_HW_CSUM. New devices should use NETIF_F_HW_CSUM to advertise
|
||||
generic checksum offload. The skb_csum_hwoffload_help() helper can resolve
|
||||
CHECKSUM_PARTIAL according to the device's advertised checksum capabilities,
|
||||
falling back to software when needed.
|
||||
|
||||
The stack should, for the most part, assume that checksum offload is supported
|
||||
by the underlying device. The only place that should check is
|
||||
|
|
@ -108,11 +103,9 @@ LCO is performed by the stack when constructing an outer UDP header for an
|
|||
encapsulation such as VXLAN or GENEVE, in udp_set_csum(). Similarly for the
|
||||
IPv6 equivalents, in udp6_set_csum().
|
||||
|
||||
It is also performed when constructing an IPv4 GRE header, in
|
||||
net/ipv4/ip_gre.c:build_header(). It is *not* currently performed when
|
||||
constructing an IPv6 GRE header; the GRE checksum is computed over the whole
|
||||
packet in net/ipv6/ip6_gre.c:ip6gre_xmit2(), but it should be possible to use
|
||||
LCO here as IPv6 GRE still uses an IP-style checksum.
|
||||
It is also performed when constructing GRE headers with the shared
|
||||
gre_build_header() helper in include/net/gre.h, which is used by both IPv4 and
|
||||
IPv6 GRE.
|
||||
|
||||
All of the LCO implementations use a helper function lco_csum(), in
|
||||
include/linux/skbuff.h.
|
||||
|
|
@ -138,6 +131,28 @@ RCO is detailed in the following Internet-Drafts:
|
|||
* https://tools.ietf.org/html/draft-herbert-vxlan-rco-00
|
||||
|
||||
In Linux, RCO is implemented individually in each encapsulation protocol, and
|
||||
most tunnel types have flags controlling its use. For instance, VXLAN has the
|
||||
flag VXLAN_F_REMCSUM_TX (per struct vxlan_rdst) to indicate that RCO should be
|
||||
used when transmitting to a given remote destination.
|
||||
most tunnel types have flags controlling its use. For instance, VXLAN has the
|
||||
configuration flag VXLAN_F_REMCSUM_TX to indicate that RCO should be used when
|
||||
transmitting.
|
||||
|
||||
|
||||
RX Checksum Offload
|
||||
===================
|
||||
|
||||
RX checksum offload is controlled via NETIF_F_RXCSUM. When disabled the driver
|
||||
must not set skb->ip_summed on ingress packets. As mentioned, IPv4 checksum
|
||||
is not offloaded, the RXCSUM feature controls the offload of verification of
|
||||
transport layer checksums.
|
||||
|
||||
Note that packets with bad TCP/UDP checksums must still be passed
|
||||
to the stack. skb->ip_summed of such packets can be set to ``CHECKSUM_COMPLETE``
|
||||
or left at ``CHECKSUM_NONE``. Drivers **must not discard** packets with
|
||||
bad TCP/UDP checksum and must not configure the device to drop them.
|
||||
Checksum validation is relatively inexpensive and having bad packets reflected
|
||||
in SNMP counters is crucial for network monitoring.
|
||||
|
||||
skb checksum documentation
|
||||
==========================
|
||||
|
||||
.. kernel-doc:: include/linux/skbuff.h
|
||||
:doc: skb checksums
|
||||
|
|
|
|||
|
|
@ -1,647 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
================================================
|
||||
Cirrus Logic LAN CS8900/CS8920 Ethernet Adapters
|
||||
================================================
|
||||
|
||||
.. note::
|
||||
|
||||
This document was contributed by Cirrus Logic for kernel 2.2.5. This version
|
||||
has been updated for 2.3.48 by Andrew Morton.
|
||||
|
||||
Still, this is too outdated! A major cleanup is needed here.
|
||||
|
||||
Cirrus make a copy of this driver available at their website, as
|
||||
described below. In general, you should use the driver version which
|
||||
comes with your Linux distribution.
|
||||
|
||||
|
||||
Linux Network Interface Driver ver. 2.00 <kernel 2.3.48>
|
||||
|
||||
|
||||
.. TABLE OF CONTENTS
|
||||
|
||||
1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
|
||||
1.1 Product Overview
|
||||
1.2 Driver Description
|
||||
1.2.1 Driver Name
|
||||
1.2.2 File in the Driver Package
|
||||
1.3 System Requirements
|
||||
1.4 Licensing Information
|
||||
|
||||
2.0 ADAPTER INSTALLATION and CONFIGURATION
|
||||
2.1 CS8900-based Adapter Configuration
|
||||
2.2 CS8920-based Adapter Configuration
|
||||
|
||||
3.0 LOADING THE DRIVER AS A MODULE
|
||||
|
||||
4.0 COMPILING THE DRIVER
|
||||
4.1 Compiling the Driver as a Loadable Module
|
||||
4.2 Compiling the driver to support memory mode
|
||||
4.3 Compiling the driver to support Rx DMA
|
||||
|
||||
5.0 TESTING AND TROUBLESHOOTING
|
||||
5.1 Known Defects and Limitations
|
||||
5.2 Testing the Adapter
|
||||
5.2.1 Diagnostic Self-Test
|
||||
5.2.2 Diagnostic Network Test
|
||||
5.3 Using the Adapter's LEDs
|
||||
5.4 Resolving I/O Conflicts
|
||||
|
||||
6.0 TECHNICAL SUPPORT
|
||||
6.1 Contacting Cirrus Logic's Technical Support
|
||||
6.2 Information Required Before Contacting Technical Support
|
||||
6.3 Obtaining the Latest Driver Version
|
||||
6.4 Current maintainer
|
||||
6.5 Kernel boot parameters
|
||||
|
||||
|
||||
1. Cirrus Logic LAN CS8900/CS8920 Ethernet Adapters
|
||||
===================================================
|
||||
|
||||
|
||||
1.1. Product Overview
|
||||
=====================
|
||||
|
||||
The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow
|
||||
IEEE 802.3 standards and support half or full-duplex operation in ISA bus
|
||||
computers on 10 Mbps Ethernet networks. The adapters are designed for operation
|
||||
in 16-bit ISA or EISA bus expansion slots and are available in
|
||||
10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5
|
||||
or fiber networks).
|
||||
|
||||
CS8920-based adapters are similar to the CS8900-based adapter with additional
|
||||
features for Plug and Play (PnP) support and Wakeup Frame recognition. As
|
||||
such, the configuration procedures differ somewhat between the two types of
|
||||
adapters. Refer to the "Adapter Configuration" section for details on
|
||||
configuring both types of adapters.
|
||||
|
||||
|
||||
1.2. Driver Description
|
||||
=======================
|
||||
|
||||
The CS8900/CS8920 Ethernet Adapter driver for Linux supports the Linux
|
||||
v2.3.48 or greater kernel. It can be compiled directly into the kernel
|
||||
or loaded at run-time as a device driver module.
|
||||
|
||||
1.2.1 Driver Name: cs89x0
|
||||
|
||||
1.2.2 Files in the Driver Archive:
|
||||
|
||||
The files in the driver at Cirrus' website include:
|
||||
|
||||
=================== ====================================================
|
||||
readme.txt this file
|
||||
build batch file to compile cs89x0.c.
|
||||
cs89x0.c driver C code
|
||||
cs89x0.h driver header file
|
||||
cs89x0.o pre-compiled module (for v2.2.5 kernel)
|
||||
config/Config.in sample file to include cs89x0 driver in the kernel.
|
||||
config/Makefile sample file to include cs89x0 driver in the kernel.
|
||||
config/Space.c sample file to include cs89x0 driver in the kernel.
|
||||
=================== ====================================================
|
||||
|
||||
|
||||
|
||||
1.3. System Requirements
|
||||
------------------------
|
||||
|
||||
The following hardware is required:
|
||||
|
||||
* Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter
|
||||
|
||||
* IBM or IBM-compatible PC with:
|
||||
* An 80386 or higher processor
|
||||
* 16 bytes of contiguous IO space available between 210h - 370h
|
||||
* One available IRQ (5,10,11,or 12 for the CS8900, 3-7,9-15 for CS8920).
|
||||
|
||||
* Appropriate cable (and connector for AUI, 10BASE-2) for your network
|
||||
topology.
|
||||
|
||||
The following software is required:
|
||||
|
||||
* LINUX kernel version 2.3.48 or higher
|
||||
|
||||
* CS8900/20 Setup Utility (DOS-based)
|
||||
|
||||
* LINUX kernel sources for your kernel (if compiling into kernel)
|
||||
|
||||
* GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel
|
||||
or a module)
|
||||
|
||||
|
||||
|
||||
1.4. Licensing Information
|
||||
--------------------------
|
||||
|
||||
This program is free software; you can redistribute it and/or modify it under
|
||||
the terms of the GNU General Public License as published by the Free Software
|
||||
Foundation, version 1.
|
||||
|
||||
This program is distributed in the hope that it will be useful, but WITHOUT
|
||||
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
||||
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
||||
more details.
|
||||
|
||||
For a full copy of the GNU General Public License, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
|
||||
|
||||
|
||||
2. Adapter Installation and Configuration
|
||||
=========================================
|
||||
|
||||
Both the CS8900 and CS8920-based adapters can be configured using parameters
|
||||
stored in an on-board EEPROM. You must use the DOS-based CS8900/20 Setup
|
||||
Utility if you want to change the adapter's configuration in EEPROM.
|
||||
|
||||
When loading the driver as a module, you can specify many of the adapter's
|
||||
configuration parameters on the command-line to override the EEPROM's settings
|
||||
or for interface configuration when an EEPROM is not used. (CS8920-based
|
||||
adapters must use an EEPROM.) See Section 3.0 LOADING THE DRIVER AS A MODULE.
|
||||
|
||||
Since the CS8900/20 Setup Utility is a DOS-based application, you must install
|
||||
and configure the adapter in a DOS-based system using the CS8900/20 Setup
|
||||
Utility before installation in the target LINUX system. (Not required if
|
||||
installing a CS8900-based adapter and the default configuration is acceptable.)
|
||||
|
||||
|
||||
2.1. CS8900-based Adapter Configuration
|
||||
---------------------------------------
|
||||
|
||||
CS8900-based adapters shipped from Cirrus Logic have been configured
|
||||
with the following "default" settings::
|
||||
|
||||
Operation Mode: Memory Mode
|
||||
IRQ: 10
|
||||
Base I/O Address: 300
|
||||
Memory Base Address: D0000
|
||||
Optimization: DOS Client
|
||||
Transmission Mode: Half-duplex
|
||||
BootProm: None
|
||||
Media Type: Autodetect (3-media cards) or
|
||||
10BASE-T (10BASE-T only adapter)
|
||||
|
||||
You should only change the default configuration settings if conflicts with
|
||||
another adapter exists. To change the adapter's configuration, run the
|
||||
CS8900/20 Setup Utility.
|
||||
|
||||
|
||||
2.2. CS8920-based Adapter Configuration
|
||||
---------------------------------------
|
||||
|
||||
CS8920-based adapters are shipped from Cirrus Logic configured as Plug
|
||||
and Play (PnP) enabled. However, since the cs89x0 driver does NOT
|
||||
support PnP, you must install the CS8920 adapter in a DOS-based PC and
|
||||
run the CS8900/20 Setup Utility to disable PnP and configure the
|
||||
adapter before installation in the target Linux system. Failure to do
|
||||
this will leave the adapter inactive and the driver will be unable to
|
||||
communicate with the adapter.
|
||||
|
||||
::
|
||||
|
||||
****************************************************************
|
||||
* CS8920-BASED ADAPTERS: *
|
||||
* *
|
||||
* CS8920-BASED ADAPTERS ARE PLUG and PLAY ENABLED BY DEFAULT. *
|
||||
* THE CS89X0 DRIVER DOES NOT SUPPORT PnP. THEREFORE, YOU MUST *
|
||||
* RUN THE CS8900/20 SETUP UTILITY TO DISABLE PnP SUPPORT AND *
|
||||
* TO ACTIVATE THE ADAPTER. *
|
||||
****************************************************************
|
||||
|
||||
|
||||
|
||||
|
||||
3. Loading the Driver as a Module
|
||||
=================================
|
||||
|
||||
If the driver is compiled as a loadable module, you can load the driver module
|
||||
with the 'modprobe' command. Many of the adapter's configuration parameters can
|
||||
be specified as command-line arguments to the load command. This facility
|
||||
provides a means to override the EEPROM's settings or for interface
|
||||
configuration when an EEPROM is not used.
|
||||
|
||||
Example::
|
||||
|
||||
insmod cs89x0.o io=0x200 irq=0xA media=aui
|
||||
|
||||
This example loads the module and configures the adapter to use an IO port base
|
||||
address of 200h, interrupt 10, and use the AUI media connection. The following
|
||||
configuration options are available on the command line::
|
||||
|
||||
io=### - specify IO address (200h-360h)
|
||||
irq=## - specify interrupt level
|
||||
use_dma=1 - Enable DMA
|
||||
dma=# - specify dma channel (Driver is compiled to support
|
||||
Rx DMA only)
|
||||
dmasize=# (16 or 64) - DMA size 16K or 64K. Default value is set to 16.
|
||||
media=rj45 - specify media type
|
||||
or media=bnc
|
||||
or media=aui
|
||||
or media=auto
|
||||
duplex=full - specify forced half/full/autonegotiate duplex
|
||||
or duplex=half
|
||||
or duplex=auto
|
||||
debug=# - debug level (only available if the driver was compiled
|
||||
for debugging)
|
||||
|
||||
**Notes:**
|
||||
|
||||
a) If an EEPROM is present, any specified command-line parameter
|
||||
will override the corresponding configuration value stored in
|
||||
EEPROM.
|
||||
|
||||
b) The "io" parameter must be specified on the command-line.
|
||||
|
||||
c) The driver's hardware probe routine is designed to avoid
|
||||
writing to I/O space until it knows that there is a cs89x0
|
||||
card at the written addresses. This could cause problems
|
||||
with device probing. To avoid this behaviour, add one
|
||||
to the ``io=`` module parameter. This doesn't actually change
|
||||
the I/O address, but it is a flag to tell the driver
|
||||
to partially initialise the hardware before trying to
|
||||
identify the card. This could be dangerous if you are
|
||||
not sure that there is a cs89x0 card at the provided address.
|
||||
|
||||
For example, to scan for an adapter located at IO base 0x300,
|
||||
specify an IO address of 0x301.
|
||||
|
||||
d) The "duplex=auto" parameter is only supported for the CS8920.
|
||||
|
||||
e) The minimum command-line configuration required if an EEPROM is
|
||||
not present is:
|
||||
|
||||
io
|
||||
irq
|
||||
media type (no autodetect)
|
||||
|
||||
f) The following additional parameters are CS89XX defaults (values
|
||||
used with no EEPROM or command-line argument).
|
||||
|
||||
* DMA Burst = enabled
|
||||
* IOCHRDY Enabled = enabled
|
||||
* UseSA = enabled
|
||||
* CS8900 defaults to half-duplex if not specified on command-line
|
||||
* CS8920 defaults to autoneg if not specified on command-line
|
||||
* Use reset defaults for other config parameters
|
||||
* dma_mode = 0
|
||||
|
||||
g) You can use ifconfig to set the adapter's Ethernet address.
|
||||
|
||||
h) Many Linux distributions use the 'modprobe' command to load
|
||||
modules. This program uses the '/etc/conf.modules' file to
|
||||
determine configuration information which is passed to a driver
|
||||
module when it is loaded. All the configuration options which are
|
||||
described above may be placed within /etc/conf.modules.
|
||||
|
||||
For example::
|
||||
|
||||
> cat /etc/conf.modules
|
||||
...
|
||||
alias eth0 cs89x0
|
||||
options cs89x0 io=0x0200 dma=5 use_dma=1
|
||||
...
|
||||
|
||||
In this example we are telling the module system that the
|
||||
ethernet driver for this machine should use the cs89x0 driver. We
|
||||
are asking 'modprobe' to pass the 'io', 'dma' and 'use_dma'
|
||||
arguments to the driver when it is loaded.
|
||||
|
||||
i) Cirrus recommend that the cs89x0 use the ISA DMA channels 5, 6 or
|
||||
7. You will probably find that other DMA channels will not work.
|
||||
|
||||
j) The cs89x0 supports DMA for receiving only. DMA mode is
|
||||
significantly more efficient. Flooding a 400 MHz Celeron machine
|
||||
with large ping packets consumes 82% of its CPU capacity in non-DMA
|
||||
mode. With DMA this is reduced to 45%.
|
||||
|
||||
k) If your Linux kernel was compiled with inbuilt plug-and-play
|
||||
support you will be able to find information about the cs89x0 card
|
||||
with the command::
|
||||
|
||||
cat /proc/isapnp
|
||||
|
||||
l) If during DMA operation you find erratic behavior or network data
|
||||
corruption you should use your PC's BIOS to slow the EISA bus clock.
|
||||
|
||||
m) If the cs89x0 driver is compiled directly into the kernel
|
||||
(non-modular) then its I/O address is automatically determined by
|
||||
ISA bus probing. The IRQ number, media options, etc are determined
|
||||
from the card's EEPROM.
|
||||
|
||||
n) If the cs89x0 driver is compiled directly into the kernel, DMA
|
||||
mode may be selected by providing the kernel with a boot option
|
||||
'cs89x0_dma=N' where 'N' is the desired DMA channel number (5, 6 or 7).
|
||||
|
||||
Kernel boot options may be provided on the LILO command line::
|
||||
|
||||
LILO boot: linux cs89x0_dma=5
|
||||
|
||||
or they may be placed in /etc/lilo.conf::
|
||||
|
||||
image=/boot/bzImage-2.3.48
|
||||
append="cs89x0_dma=5"
|
||||
label=linux
|
||||
root=/dev/hda5
|
||||
read-only
|
||||
|
||||
The DMA Rx buffer size is hardwired to 16 kbytes in this mode.
|
||||
(64k mode is not available).
|
||||
|
||||
|
||||
4. Compiling the Driver
|
||||
=======================
|
||||
|
||||
The cs89x0 driver can be compiled directly into the kernel or compiled into
|
||||
a loadable device driver module.
|
||||
|
||||
Just use the standard way to configure the driver and compile the Kernel.
|
||||
|
||||
|
||||
4.1. Compiling the Driver to Support Rx DMA
|
||||
-------------------------------------------
|
||||
|
||||
The compile-time optionality for DMA was removed in the 2.3 kernel
|
||||
series. DMA support is now unconditionally part of the driver. It is
|
||||
enabled by the 'use_dma=1' module option.
|
||||
|
||||
|
||||
5. Testing and Troubleshooting
|
||||
==============================
|
||||
|
||||
5.1. Known Defects and Limitations
|
||||
----------------------------------
|
||||
|
||||
Refer to the RELEASE.TXT file distributed as part of this archive for a list of
|
||||
known defects, driver limitations, and work arounds.
|
||||
|
||||
|
||||
5.2. Testing the Adapter
|
||||
------------------------
|
||||
|
||||
Once the adapter has been installed and configured, the diagnostic option of
|
||||
the CS8900/20 Setup Utility can be used to test the functionality of the
|
||||
adapter and its network connection. Use the diagnostics 'Self Test' option to
|
||||
test the functionality of the adapter with the hardware configuration you have
|
||||
assigned. You can use the diagnostics 'Network Test' to test the ability of the
|
||||
adapter to communicate across the Ethernet with another PC equipped with a
|
||||
CS8900/20-based adapter card (it must also be running the CS8900/20 Setup
|
||||
Utility).
|
||||
|
||||
.. note::
|
||||
|
||||
The Setup Utility's diagnostics are designed to run in a
|
||||
DOS-only operating system environment. DO NOT run the diagnostics
|
||||
from a DOS or command prompt session under Windows 95, Windows NT,
|
||||
OS/2, or other operating system.
|
||||
|
||||
To run the diagnostics tests on the CS8900/20 adapter:
|
||||
|
||||
1. Boot DOS on the PC and start the CS8900/20 Setup Utility.
|
||||
|
||||
2. The adapter's current configuration is displayed. Hit the ENTER key to
|
||||
get to the main menu.
|
||||
|
||||
4. Select 'Diagnostics' (ALT-G) from the main menu.
|
||||
* Select 'Self-Test' to test the adapter's basic functionality.
|
||||
* Select 'Network Test' to test the network connection and cabling.
|
||||
|
||||
|
||||
5.2.1. Diagnostic Self-test
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The diagnostic self-test checks the adapter's basic functionality as well as
|
||||
its ability to communicate across the ISA bus based on the system resources
|
||||
assigned during hardware configuration. The following tests are performed:
|
||||
|
||||
* IO Register Read/Write Test
|
||||
|
||||
The IO Register Read/Write test insures that the CS8900/20 can be
|
||||
accessed in IO mode, and that the IO base address is correct.
|
||||
|
||||
* Shared Memory Test
|
||||
|
||||
The Shared Memory test insures the CS8900/20 can be accessed in memory
|
||||
mode and that the range of memory addresses assigned does not conflict
|
||||
with other devices in the system.
|
||||
|
||||
* Interrupt Test
|
||||
|
||||
The Interrupt test insures there are no conflicts with the assigned IRQ
|
||||
signal.
|
||||
|
||||
* EEPROM Test
|
||||
|
||||
The EEPROM test insures the EEPROM can be read.
|
||||
|
||||
* Chip RAM Test
|
||||
|
||||
The Chip RAM test insures the 4K of memory internal to the CS8900/20 is
|
||||
working properly.
|
||||
|
||||
* Internal Loop-back Test
|
||||
|
||||
The Internal Loop Back test insures the adapter's transmitter and
|
||||
receiver are operating properly. If this test fails, make sure the
|
||||
adapter's cable is connected to the network (check for LED activity for
|
||||
example).
|
||||
|
||||
* Boot PROM Test
|
||||
|
||||
The Boot PROM test insures the Boot PROM is present, and can be read.
|
||||
Failure indicates the Boot PROM was not successfully read due to a
|
||||
hardware problem or due to a conflicts on the Boot PROM address
|
||||
assignment. (Test only applies if the adapter is configured to use the
|
||||
Boot PROM option.)
|
||||
|
||||
Failure of a test item indicates a possible system resource conflict with
|
||||
another device on the ISA bus. In this case, you should use the Manual Setup
|
||||
option to reconfigure the adapter by selecting a different value for the system
|
||||
resource that failed.
|
||||
|
||||
|
||||
5.2.2. Diagnostic Network Test
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The Diagnostic Network Test verifies a working network connection by
|
||||
transferring data between two CS8900/20 adapters installed in different PCs
|
||||
on the same network. (Note: the diagnostic network test should not be run
|
||||
between two nodes across a router.)
|
||||
|
||||
This test requires that each of the two PCs have a CS8900/20-based adapter
|
||||
installed and have the CS8900/20 Setup Utility running. The first PC is
|
||||
configured as a Responder and the other PC is configured as an Initiator.
|
||||
Once the Initiator is started, it sends data frames to the Responder which
|
||||
returns the frames to the Initiator.
|
||||
|
||||
The total number of frames received and transmitted are displayed on the
|
||||
Initiator's display, along with a count of the number of frames received and
|
||||
transmitted OK or in error. The test can be terminated anytime by the user at
|
||||
either PC.
|
||||
|
||||
To setup the Diagnostic Network Test:
|
||||
|
||||
1. Select a PC with a CS8900/20-based adapter and a known working network
|
||||
connection to act as the Responder. Run the CS8900/20 Setup Utility
|
||||
and select 'Diagnostics -> Network Test -> Responder' from the main
|
||||
menu. Hit ENTER to start the Responder.
|
||||
|
||||
2. Return to the PC with the CS8900/20-based adapter you want to test and
|
||||
start the CS8900/20 Setup Utility.
|
||||
|
||||
3. From the main menu, Select 'Diagnostic -> Network Test -> Initiator'.
|
||||
Hit ENTER to start the test.
|
||||
|
||||
You may stop the test on the Initiator at any time while allowing the Responder
|
||||
to continue running. In this manner, you can move to additional PCs and test
|
||||
them by starting the Initiator on another PC without having to stop/start the
|
||||
Responder.
|
||||
|
||||
|
||||
|
||||
5.3. Using the Adapter's LEDs
|
||||
-----------------------------
|
||||
|
||||
The 2 and 3-media adapters have two LEDs visible on the back end of the board
|
||||
located near the 10Base-T connector.
|
||||
|
||||
Link Integrity LED: A "steady" ON of the green LED indicates a valid 10Base-T
|
||||
connection. (Only applies to 10Base-T. The green LED has no significance for
|
||||
a 10Base-2 or AUI connection.)
|
||||
|
||||
TX/RX LED: The yellow LED lights briefly each time the adapter transmits or
|
||||
receives data. (The yellow LED will appear to "flicker" on a typical network.)
|
||||
|
||||
|
||||
5.4. Resolving I/O Conflicts
|
||||
----------------------------
|
||||
|
||||
An IO conflict occurs when two or more adapter use the same ISA resource (IO
|
||||
address, memory address or IRQ). You can usually detect an IO conflict in one
|
||||
of four ways after installing and or configuring the CS8900/20-based adapter:
|
||||
|
||||
1. The system does not boot properly (or at all).
|
||||
|
||||
2. The driver cannot communicate with the adapter, reporting an "Adapter
|
||||
not found" error message.
|
||||
|
||||
3. You cannot connect to the network or the driver will not load.
|
||||
|
||||
4. If you have configured the adapter to run in memory mode but the driver
|
||||
reports it is using IO mode when loading, this is an indication of a
|
||||
memory address conflict.
|
||||
|
||||
If an IO conflict occurs, run the CS8900/20 Setup Utility and perform a
|
||||
diagnostic self-test. Normally, the ISA resource in conflict will fail the
|
||||
self-test. If so, reconfigure the adapter selecting another choice for the
|
||||
resource in conflict. Run the diagnostics again to check for further IO
|
||||
conflicts.
|
||||
|
||||
In some cases, such as when the PC will not boot, it may be necessary to remove
|
||||
the adapter and reconfigure it by installing it in another PC to run the
|
||||
CS8900/20 Setup Utility. Once reinstalled in the target system, run the
|
||||
diagnostics self-test to ensure the new configuration is free of conflicts
|
||||
before loading the driver again.
|
||||
|
||||
When manually configuring the adapter, keep in mind the typical ISA system
|
||||
resource usage as indicated in the tables below.
|
||||
|
||||
::
|
||||
|
||||
I/O Address Device IRQ Device
|
||||
----------- -------- --- --------
|
||||
200-20F Game I/O adapter 3 COM2, Bus Mouse
|
||||
230-23F Bus Mouse 4 COM1
|
||||
270-27F LPT3: third parallel port 5 LPT2
|
||||
2F0-2FF COM2: second serial port 6 Floppy Disk controller
|
||||
320-32F Fixed disk controller 7 LPT1
|
||||
8 Real-time Clock
|
||||
9 EGA/VGA display adapter
|
||||
12 Mouse (PS/2)
|
||||
Memory Address Device 13 Math Coprocessor
|
||||
-------------- --------------------- 14 Hard Disk controller
|
||||
A000-BFFF EGA Graphics Adapter
|
||||
A000-C7FF VGA Graphics Adapter
|
||||
B000-BFFF Mono Graphics Adapter
|
||||
B800-BFFF Color Graphics Adapter
|
||||
E000-FFFF AT BIOS
|
||||
|
||||
|
||||
|
||||
|
||||
6. Technical Support
|
||||
====================
|
||||
|
||||
6.1. Contacting Cirrus Logic's Technical Support
|
||||
------------------------------------------------
|
||||
|
||||
Cirrus Logic's CS89XX Technical Application Support can be reached at::
|
||||
|
||||
Telephone :(800) 888-5016 (from inside U.S. and Canada)
|
||||
:(512) 442-7555 (from outside the U.S. and Canada)
|
||||
Fax :(512) 912-3871
|
||||
Email :ethernet@crystal.cirrus.com
|
||||
WWW :http://www.cirrus.com
|
||||
|
||||
|
||||
6.2. Information Required before Contacting Technical Support
|
||||
-------------------------------------------------------------
|
||||
|
||||
Before contacting Cirrus Logic for technical support, be prepared to provide as
|
||||
Much of the following information as possible.
|
||||
|
||||
1.) Adapter type (CRD8900, CDB8900, CDB8920, etc.)
|
||||
|
||||
2.) Adapter configuration
|
||||
|
||||
* IO Base, Memory Base, IO or memory mode enabled, IRQ, DMA channel
|
||||
* Plug and Play enabled/disabled (CS8920-based adapters only)
|
||||
* Configured for media auto-detect or specific media type (which type).
|
||||
|
||||
3.) PC System's Configuration
|
||||
|
||||
* Plug and Play system (yes/no)
|
||||
* BIOS (make and version)
|
||||
* System make and model
|
||||
* CPU (type and speed)
|
||||
* System RAM
|
||||
* SCSI Adapter
|
||||
|
||||
4.) Software
|
||||
|
||||
* CS89XX driver and version
|
||||
* Your network operating system and version
|
||||
* Your system's OS version
|
||||
* Version of all protocol support files
|
||||
|
||||
5.) Any Error Message displayed.
|
||||
|
||||
|
||||
|
||||
6.3 Obtaining the Latest Driver Version
|
||||
---------------------------------------
|
||||
|
||||
You can obtain the latest CS89XX drivers and support software from Cirrus Logic's
|
||||
Web site. You can also contact Cirrus Logic's Technical Support (email:
|
||||
ethernet@crystal.cirrus.com) and request that you be registered for automatic
|
||||
software-update notification.
|
||||
|
||||
Cirrus Logic maintains a web page at http://www.cirrus.com with the
|
||||
latest drivers and technical publications.
|
||||
|
||||
|
||||
6.4. Current maintainer
|
||||
-----------------------
|
||||
|
||||
In February 2000 the maintenance of this driver was assumed by Andrew
|
||||
Morton.
|
||||
|
||||
6.5 Kernel module parameters
|
||||
----------------------------
|
||||
|
||||
For use in embedded environments with no cs89x0 EEPROM, the kernel boot
|
||||
parameter ``cs89x0_media=`` has been implemented. Usage is::
|
||||
|
||||
cs89x0_media=rj45 or
|
||||
cs89x0_media=aui or
|
||||
cs89x0_media=bnc
|
||||
|
|
@ -19,7 +19,6 @@ Contents:
|
|||
amd/pds_vfio_pci
|
||||
aquantia/atlantic
|
||||
chelsio/cxgb
|
||||
cirrus/cs89x0
|
||||
dlink/dl2k
|
||||
davicom/dm9000
|
||||
dec/dmfe
|
||||
|
|
|
|||
|
|
@ -33,7 +33,9 @@ Device driver can provide specific callbacks for each "health reporter", e.g.:
|
|||
* Recovery procedures
|
||||
* Diagnostics procedures
|
||||
* Object dump procedures
|
||||
* Out Of Box initial parameters
|
||||
|
||||
Drivers also provide default values for generic reporter parameters when
|
||||
creating a health reporter.
|
||||
|
||||
Different parts of the driver can register different types of health reporters
|
||||
with different handlers.
|
||||
|
|
@ -45,8 +47,9 @@ Once an error is reported, devlink health will perform the following actions:
|
|||
|
||||
* A log is being send to the kernel trace events buffer
|
||||
* Health status and statistics are being updated for the reporter instance
|
||||
* Object dump is being taken and saved at the reporter instance (as long as
|
||||
auto-dump is set and there is no other dump which is already stored)
|
||||
* Object dump is being taken and saved at the reporter instance. This is
|
||||
best effort and skipped when recovery is aborted, auto-dump is disabled,
|
||||
no dump callback is registered, or a dump is already stored.
|
||||
* Auto recovery attempt is being done. Depends on:
|
||||
|
||||
- Auto-recovery configuration
|
||||
|
|
@ -75,7 +78,8 @@ User Interface
|
|||
==============
|
||||
|
||||
User can access/change each reporter's parameters and driver specific callbacks
|
||||
via ``devlink``, e.g per error type (per health reporter):
|
||||
via ``devlink``, e.g. per error type (per health reporter). Reporters may be
|
||||
registered for the whole devlink instance or for a specific devlink port.
|
||||
|
||||
* Configure reporter's generic parameters (like: disable/enable auto recovery)
|
||||
* Invoke recovery procedure
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ own name.
|
|||
* - ``enable_iwarp``
|
||||
- Boolean
|
||||
- Enable handling of iWARP traffic in the device.
|
||||
* - ``internal_err_reset``
|
||||
* - ``internal_error_reset``
|
||||
- Boolean
|
||||
- When enabled, the device driver will reset the device on internal
|
||||
errors.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Devlink port flavours are described below.
|
|||
- This indicates an eswitch port representing a port of PCI
|
||||
subfunction (SF).
|
||||
* - ``DEVLINK_PORT_FLAVOUR_VIRTUAL``
|
||||
- This indicates a virtual port for the PCI virtual function.
|
||||
- Any virtual port facing the user.
|
||||
|
||||
Devlink port can have a different type based on the link layer described below.
|
||||
|
||||
|
|
@ -134,6 +134,9 @@ Users may also set the IPsec crypto capability of the function using
|
|||
Users may also set the IPsec packet capability of the function using
|
||||
`devlink port function set ipsec_packet` command.
|
||||
|
||||
The ``migratable`` attribute may be set only on ports with
|
||||
``DEVLINK_PORT_FLAVOUR_PCI_VF``.
|
||||
|
||||
Users may also set the maximum IO event queues of the function
|
||||
using `devlink port function set max_io_eqs` command.
|
||||
|
||||
|
|
|
|||
|
|
@ -516,9 +516,11 @@ Generic Packet Trap Groups
|
|||
|
||||
Generic packet trap groups are used to aggregate logically related packet
|
||||
traps. These groups allow the user to batch operations such as setting the trap
|
||||
action of all member traps. In addition, ``devlink-trap`` can report aggregated
|
||||
per-group packets and bytes statistics, in case per-trap statistics are too
|
||||
narrow. The description of these groups must be added to the following table:
|
||||
action of all member drop traps whose action may legally change. Exception and
|
||||
control traps remain unchanged. In addition, ``devlink-trap`` can report
|
||||
aggregated per-group packets and bytes statistics, in case per-trap statistics
|
||||
are too narrow. The description of these groups must be added to the following
|
||||
table:
|
||||
|
||||
.. list-table:: List of Generic Packet Trap Groups
|
||||
:widths: 10 90
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ new APIs prefixed by ``devl_*``. The older APIs handle all the locking
|
|||
in devlink core, but don't allow registration of most sub-objects once
|
||||
the main devlink object is itself registered. The newer ``devl_*`` APIs assume
|
||||
the devlink instance lock is already held. Drivers can take the instance
|
||||
lock by calling ``devl_lock()``. It is also held all callbacks of devlink
|
||||
netlink commands.
|
||||
lock by calling ``devl_lock()``. It is also held across all callbacks of
|
||||
devlink netlink commands.
|
||||
|
||||
Drivers are encouraged to use the devlink instance lock for their own needs.
|
||||
|
||||
|
|
@ -33,11 +33,11 @@ sure to respect following rules:
|
|||
lock of both nested and parent instances at the same time, devlink
|
||||
instance lock of the parent instance should be taken first, only then
|
||||
instance lock of the nested instance could be taken.
|
||||
- Driver should use object-specific helpers to setup the
|
||||
nested relationship:
|
||||
- Driver should use object-specific helpers to setup the nested relationship
|
||||
before registering the nested devlink instance:
|
||||
|
||||
- ``devl_nested_devlink_set()`` - called to setup devlink -> nested
|
||||
devlink relationship (could be user for multiple nested instances.
|
||||
devlink relationship (could be used for multiple nested instances).
|
||||
- ``devl_port_fn_devlink_set()`` - called to setup port function ->
|
||||
nested devlink relationship.
|
||||
- ``devlink_linecard_nested_dl_set()`` - called to setup linecard ->
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ The ``stmmac`` driver implements the following driver-specific parameters.
|
|||
- runtime
|
||||
- Enable the Coarse timestamping mode, as defined in the DWMAC TRM.
|
||||
A detailed explanation of this timestamping mode can be found in the
|
||||
Socfpga Functionnal Description [1].
|
||||
Socfpga Functional Description [1].
|
||||
|
||||
In Coarse mode, the ptp clock is expected to be fed by a high-precision
|
||||
clock that is externally adjusted, and the subsecond increment used for
|
||||
|
|
|
|||
|
|
@ -103,24 +103,22 @@ The user must bind a dmabuf to any number of RX queues on a given NIC using
|
|||
the netlink API::
|
||||
|
||||
/* Bind dmabuf to NIC RX queue 15 */
|
||||
struct netdev_queue *queues;
|
||||
queues = malloc(sizeof(*queues) * 1);
|
||||
struct netdev_queue_id *queues;
|
||||
|
||||
queues[0]._present.type = 1;
|
||||
queues[0]._present.idx = 1;
|
||||
queues[0].type = NETDEV_RX_QUEUE_TYPE_RX;
|
||||
queues[0].idx = 15;
|
||||
queues = netdev_queue_id_alloc(1);
|
||||
netdev_queue_id_set_type(&queues[0], NETDEV_QUEUE_TYPE_RX);
|
||||
netdev_queue_id_set_id(&queues[0], 15);
|
||||
|
||||
*ys = ynl_sock_create(&ynl_netdev_family, &yerr);
|
||||
|
||||
req = netdev_bind_rx_req_alloc();
|
||||
netdev_bind_rx_req_set_ifindex(req, 1 /* ifindex */);
|
||||
netdev_bind_rx_req_set_dmabuf_fd(req, dmabuf_fd);
|
||||
__netdev_bind_rx_req_set_queues(req, queues, n_queue_index);
|
||||
netdev_bind_rx_req_set_fd(req, dmabuf_fd);
|
||||
__netdev_bind_rx_req_set_queues(req, queues, 1);
|
||||
|
||||
rsp = netdev_bind_rx(*ys, req);
|
||||
|
||||
dmabuf_id = rsp->dmabuf_id;
|
||||
dmabuf_id = rsp->id;
|
||||
|
||||
|
||||
The netlink API returns a dmabuf_id: a unique ID that refers to this dmabuf
|
||||
|
|
@ -302,13 +300,12 @@ The user should create a msghdr where,
|
|||
* iov_base is set to the offset into the dmabuf to start sending from
|
||||
* iov_len is set to the number of bytes to be sent from the dmabuf
|
||||
|
||||
The user passes the dma-buf id to send from via the dmabuf_tx_cmsg.dmabuf_id.
|
||||
The user passes the dma-buf id to send from as a u32 cmsg payload.
|
||||
|
||||
The example below sends 1024 bytes from offset 100 into the dmabuf, and 2048
|
||||
from offset 2000 into the dmabuf. The dmabuf to send from is tx_dmabuf_id::
|
||||
|
||||
char ctrl_data[CMSG_SPACE(sizeof(struct dmabuf_tx_cmsg))];
|
||||
struct dmabuf_tx_cmsg ddmabuf;
|
||||
char ctrl_data[CMSG_SPACE(sizeof(__u32))];
|
||||
struct msghdr msg = {};
|
||||
struct cmsghdr *cmsg;
|
||||
struct iovec iov[2];
|
||||
|
|
@ -327,11 +324,9 @@ from offset 2000 into the dmabuf. The dmabuf to send from is tx_dmabuf_id::
|
|||
cmsg = CMSG_FIRSTHDR(&msg);
|
||||
cmsg->cmsg_level = SOL_SOCKET;
|
||||
cmsg->cmsg_type = SCM_DEVMEM_DMABUF;
|
||||
cmsg->cmsg_len = CMSG_LEN(sizeof(struct dmabuf_tx_cmsg));
|
||||
cmsg->cmsg_len = CMSG_LEN(sizeof(__u32));
|
||||
|
||||
ddmabuf.dmabuf_id = tx_dmabuf_id;
|
||||
|
||||
*((struct dmabuf_tx_cmsg *)CMSG_DATA(cmsg)) = ddmabuf;
|
||||
*((__u32 *)CMSG_DATA(cmsg)) = tx_dmabuf_id;
|
||||
|
||||
sendmsg(socket_fd, &msg, MSG_ZEROCOPY);
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ for a driver implementing scatter-gather this means:
|
|||
{
|
||||
u32 used = READ_ONCE(dr->prod) - READ_ONCE(dr->cons);
|
||||
|
||||
return dr->tx_ring_size - (used & bp->tx_ring_mask);
|
||||
return dr->tx_ring_size - (used & dr->tx_ring_mask);
|
||||
}
|
||||
|
||||
static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
|
||||
|
|
@ -69,7 +69,7 @@ for a driver implementing scatter-gather this means:
|
|||
//...
|
||||
/* This should be a very rare race - log it. */
|
||||
if (drv_tx_avail(dr) <= skb_shinfo(skb)->nr_frags + 1) {
|
||||
netif_stop_queue(dev);
|
||||
netif_tx_stop_queue(txq);
|
||||
netdev_warn(dev, "Tx Ring full when queue awake!\n");
|
||||
return NETDEV_TX_BUSY;
|
||||
}
|
||||
|
|
@ -103,6 +103,9 @@ Lockless queue stop / wake helper macros
|
|||
.. kernel-doc:: include/net/netdev_queues.h
|
||||
:doc: Lockless queue stopping / waking helpers.
|
||||
|
||||
The standard macros like netif_txq_maybe_stop(), netif_txq_try_stop() etc.
|
||||
are well tested, prefer them over local synchronization schemes.
|
||||
|
||||
No exclusive ownership
|
||||
----------------------
|
||||
|
||||
|
|
@ -125,3 +128,16 @@ to be freed up.
|
|||
If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
|
||||
must not keep any reference to that SKB and you must not attempt
|
||||
to free it up.
|
||||
|
||||
Error message reporting
|
||||
=======================
|
||||
|
||||
A number of driver configuration interfaces pass a Netlink extended ACK
|
||||
(``extack``) object to the driver (either directly as an argument or
|
||||
as a member of a parameter struct). The drivers should try to report
|
||||
most errors via the ``extack`` object. System level exceptions,
|
||||
indicating that system or device is misbehaving or is in bad state,
|
||||
should continue to be reported to system logs.
|
||||
|
||||
Messages should be passed **either** via ``extack`` **or** to system logs.
|
||||
Drivers should not try to report the same information to both.
|
||||
|
|
|
|||
|
|
@ -509,7 +509,7 @@ Device Tree
|
|||
-----------
|
||||
|
||||
DSA features a standardized binding which is documented in
|
||||
``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
|
||||
``Documentation/devicetree/bindings/net/dsa/dsa.yaml``. PHY/MDIO library helper
|
||||
functions such as ``of_get_phy_mode()``, ``of_phy_connect()`` are also used to query
|
||||
per-port PHY specific details: interface connection, MDIO bus location, etc.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Driver details
|
|||
|
||||
The driver is implemented as a DSA driver, see ``Documentation/networking/dsa/dsa.rst``.
|
||||
|
||||
See ``Documentation/devicetree/bindings/net/dsa/lan9303.txt`` for device tree
|
||||
See ``Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml`` for device tree
|
||||
binding.
|
||||
|
||||
The LAN9303 can be managed both via MDIO and I2C, both supported by this driver.
|
||||
|
|
|
|||
|
|
@ -489,7 +489,7 @@ tcp_ecn - INTEGER
|
|||
tcp_ecn_option - INTEGER
|
||||
Control Accurate ECN (AccECN) option sending when AccECN has been
|
||||
successfully negotiated during handshake. Send logic inhibits
|
||||
sending AccECN options regarless of this setting when no AccECN
|
||||
sending AccECN options regardless of this setting when no AccECN
|
||||
option has been seen for the reverse direction.
|
||||
|
||||
Possible values are:
|
||||
|
|
@ -2444,7 +2444,11 @@ fib_multipath_hash_policy - INTEGER
|
|||
|
||||
Possible values:
|
||||
|
||||
- 0 - Layer 3 (source and destination addresses plus flow label)
|
||||
- 0 - Layer 3 (source and destination addresses plus flow label).
|
||||
For IPv6 TCP, the local ECMP path is selected from the socket
|
||||
txhash rather than the flow label, and may change after a TCP
|
||||
rehash event (such as a retransmission timeout) to recover from
|
||||
path failure. The on-wire flow label is unaffected.
|
||||
- 1 - Layer 4 (standard 5-tuple)
|
||||
- 2 - Layer 3 or inner Layer 3 if present
|
||||
- 3 - Custom multipath hash. Fields used for multipath hash calculation
|
||||
|
|
|
|||
|
|
@ -56,6 +56,50 @@ conn_lfactor - INTEGER
|
|||
-4: grow if load goes above 6% (buckets = nodes * 16)
|
||||
2: grow if load goes above 400% (buckets = nodes / 4)
|
||||
|
||||
conn_max - INTEGER
|
||||
Limit for number of connections, per netns.
|
||||
|
||||
Controls the soft and hard limit for number of connections.
|
||||
Initially, the platform specific limit is assigned for init_net.
|
||||
The value can be changed and later the soft limit propagated
|
||||
to other networking namespaces.
|
||||
|
||||
Privileged admin can change both limits up to the value of the
|
||||
platform limit while the unprivileged admin can change only the
|
||||
soft limit up to the value of the hard limit.
|
||||
|
||||
For setups using conntrack=1 (CONFIG_IP_VS_NFCT for
|
||||
Netfilter connection tracking) the connections can be
|
||||
limited also by nf_conntrack_max.
|
||||
|
||||
Limits for init_net:
|
||||
|
||||
======================= =============== =============
|
||||
\ soft limit hard limit
|
||||
======================= =============== =============
|
||||
create netns platform platform
|
||||
priv admin 0 .. platform 0 .. platform
|
||||
======================= =============== =============
|
||||
|
||||
Limits for new netns:
|
||||
|
||||
======================= =============== =============
|
||||
\ soft limit hard limit
|
||||
======================= =============== =============
|
||||
create netns init_net:soft init_net:soft
|
||||
priv admin 0 .. platform 0 .. platform
|
||||
unpriv admin 0 .. hard N/A
|
||||
======================= =============== =============
|
||||
|
||||
Limits per platform:
|
||||
|
||||
- 1,073,741,824 (2^30 for 64-bit)
|
||||
- 16,777,216 (2^24 for 32-bit)
|
||||
|
||||
Possible values: 0 .. platform limit
|
||||
|
||||
Default: platform limit
|
||||
|
||||
conn_reuse_mode - INTEGER
|
||||
1 - default
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,19 @@ add_addr_timeout - INTEGER (seconds)
|
|||
|
||||
Default: 120
|
||||
|
||||
add_addr_v6_port_drop_ts - BOOLEAN
|
||||
Control whether preparing an ADD_ADDR with an IPv6 address and a port
|
||||
should drop the TCP timestamps option to have enough option space to
|
||||
send the signal.
|
||||
|
||||
If there is not enough option space, and the TCP timestamps option
|
||||
cannot be dropped, the signal cannot be sent. Note that dropping the TCP
|
||||
timestamps option for one packet of the connection could disrupt some
|
||||
middleboxes: even if it should be unlikely, they could drop the packet
|
||||
or block the connection. This is a per-namespace sysctl.
|
||||
|
||||
Default: 1 (enabled)
|
||||
|
||||
allow_join_initial_addr_port - BOOLEAN
|
||||
Allow peers to send join requests to the IP address and port number used
|
||||
by the initial subflow if the value is 1. This controls a flag that is
|
||||
|
|
|
|||
|
|
@ -49,7 +49,11 @@ instance to be released.
|
|||
The control APIs are not idempotent. Control API calls are safe against
|
||||
concurrent use of datapath APIs but an incorrect sequence of control API
|
||||
calls may result in crashes, deadlocks, or race conditions. For example,
|
||||
calling napi_disable() multiple times in a row will deadlock.
|
||||
calling napi_disable() multiple times in a row will hang waiting for
|
||||
ownership of the NAPI instance to be released.
|
||||
|
||||
Drivers using the netdev instance lock may need to use the ``_locked()``
|
||||
variants of the control APIs when that lock is already held.
|
||||
|
||||
Datapath API
|
||||
------------
|
||||
|
|
@ -190,7 +194,8 @@ User API
|
|||
========
|
||||
|
||||
User interactions with NAPI depend on NAPI instance ID. The instance IDs
|
||||
are only visible to the user thru the ``SO_INCOMING_NAPI_ID`` socket option.
|
||||
are visible to the user through the ``SO_INCOMING_NAPI_ID`` socket option
|
||||
and the netdev Netlink API.
|
||||
|
||||
Users can query NAPI IDs for a device or device queue using netlink. This can
|
||||
be done programmatically in a user application or by using a script included in
|
||||
|
|
@ -371,7 +376,7 @@ To use this mechanism:
|
|||
the application has stalled. This value should be chosen so that it covers
|
||||
the amount of time the user application needs to process data from its
|
||||
call to epoll_wait, noting that applications can control how much data
|
||||
they retrieve by setting ``max_events`` when calling epoll_wait.
|
||||
they retrieve by setting ``maxevents`` when calling epoll_wait.
|
||||
|
||||
2. The sysfs parameter or per-NAPI config parameters ``gro_flush_timeout``
|
||||
and ``napi_defer_hard_irqs`` can be set to low values. They will be used
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Type Name fastpath_tx_acce
|
|||
=================================== =========================== =================== =================== ===================================================================================
|
||||
unsigned_long:32 priv_flags read_mostly __dev_queue_xmit(tx)
|
||||
unsigned_long:1 lltx read_mostly HARD_TX_LOCK,HARD_TX_TRYLOCK,HARD_TX_UNLOCK(tx)
|
||||
unsigned long:1 netmem_tx:1; read_mostly
|
||||
unsigned_long:2 netmem_tx:2; read_mostly
|
||||
char name[16]
|
||||
struct netdev_name_node* name_node
|
||||
struct dev_ifalias* ifalias
|
||||
|
|
@ -90,8 +90,6 @@ struct inet6_dev* ip6_ptr read_mostly
|
|||
struct vlan_info* vlan_info
|
||||
struct dsa_port* dsa_ptr
|
||||
struct tipc_bearer* tipc_ptr
|
||||
void* atalk_ptr
|
||||
void* ax25_ptr
|
||||
struct wireless_dev* ieee80211_ptr
|
||||
struct wpan_dev* ieee802154_ptr
|
||||
struct mpls_dev* mpls_ptr
|
||||
|
|
|
|||
|
|
@ -13,16 +13,16 @@ u16 tcp_header_len read_mostly read_m
|
|||
u16 gso_segs read_mostly tcp_xmit_size_goal
|
||||
__be32 pred_flags read_write read_mostly tcp_select_window(tx);tcp_rcv_established(rx)
|
||||
u64 bytes_received read_write tcp_rcv_nxt_update(rx)
|
||||
u32 segs_in read_write tcp_v6_rcv(rx)
|
||||
u32 segs_in read_write read_write tcp_segs_in(),tcp_v6_rcv(rx),tcp_v4_rcv()
|
||||
u32 data_segs_in read_write tcp_v6_rcv(rx)
|
||||
u32 rcv_nxt read_mostly read_write tcp_cleanup_rbuf,tcp_send_ack,tcp_inq_hint,tcp_transmit_skb,tcp_receive_window(tx);tcp_v6_do_rcv,tcp_rcv_established,tcp_data_queue,tcp_receive_window,tcp_rcv_nxt_update(write)(rx)
|
||||
u32 copied_seq read_mostly tcp_cleanup_rbuf,tcp_rcv_space_adjust,tcp_inq_hint
|
||||
u32 rcv_wup read_write __tcp_cleanup_rbuf,tcp_receive_window,tcp_receive_established
|
||||
u32 snd_nxt read_write read_mostly tcp_rate_check_app_limited,__tcp_transmit_skb,tcp_event_new_data_sent(write)(tx);tcp_rcv_established,tcp_ack,tcp_clean_rtx_queue(rx)
|
||||
u32 segs_out read_write __tcp_transmit_skb
|
||||
u32 segs_out read_write read_write __tcp_transmit_skb
|
||||
u32 data_segs_out read_write __tcp_transmit_skb,tcp_update_skb_after_send
|
||||
u64 bytes_sent read_write __tcp_transmit_skb
|
||||
u64 bytes_acked read_write tcp_snd_una_update/tcp_ack
|
||||
u64 bytes_acked read_write tcp_snd_una_update/tcp_ack
|
||||
u32 dsack_dups
|
||||
u32 snd_una read_mostly read_write tcp_wnd_end,tcp_urg_mode,tcp_minshall_check,tcp_cwnd_validate(tx);tcp_ack,tcp_may_update_window,tcp_clean_rtx_queue(write),tcp_ack_tstamp(rx)
|
||||
u32 snd_sml read_write tcp_minshall_check,tcp_minshall_update
|
||||
|
|
@ -99,8 +99,8 @@ u32 snd_cwnd_stamp
|
|||
u32 prior_cwnd
|
||||
u32 prr_delivered
|
||||
u32 prr_out read_mostly read_mostly tcp_rate_skb_sent,tcp_newly_delivered(tx);tcp_ack,tcp_rate_gen,tcp_clean_rtx_queue(rx)
|
||||
u32 delivered read_mostly read_write tcp_rate_skb_sent, tcp_newly_delivered(tx);tcp_ack, tcp_rate_gen, tcp_clean_rtx_queue (rx)
|
||||
u32 delivered_ce read_mostly read_write tcp_rate_skb_sent(tx);tcp_rate_gen(rx)
|
||||
u32 delivered read_write tcp_rate_skb_sent, tcp_newly_delivered(tx);tcp_ack, tcp_rate_gen, tcp_clean_rtx_queue (rx)
|
||||
u32 delivered_ce read_write tcp_rate_skb_sent(tx);tcp_rate_gen(rx)
|
||||
u32 received_ce read_mostly read_write
|
||||
u32[3] received_ecn_bytes read_mostly read_write
|
||||
u8:4 received_ce_pending read_mostly read_write
|
||||
|
|
|
|||
|
|
@ -18,29 +18,38 @@ that relieve an OS of various tasks like generating and checking checksums,
|
|||
splitting packets, classifying them. Those capabilities and their state
|
||||
are commonly referred to as netdev features in Linux kernel world.
|
||||
|
||||
There are currently three sets of features relevant to the driver, and
|
||||
one used internally by network core:
|
||||
There are currently three main sets of features on each netdevice,
|
||||
first and second are initialized by the driver:
|
||||
|
||||
1. netdev->hw_features set contains features whose state may possibly
|
||||
be changed (enabled or disabled) for a particular device by user's
|
||||
request. This set should be initialized in ndo_init callback and not
|
||||
changed later.
|
||||
request. Drivers normally initialize this set before registration or
|
||||
in the ndo_init callback. Changes after registration should be made
|
||||
very carefully as other parts of the code may assume hw_features are
|
||||
static. At the very least changes must be made under rtnl_lock and
|
||||
the netdev instance lock, and followed by netdev_update_features().
|
||||
|
||||
2. netdev->features set contains features which are currently enabled
|
||||
for a device. This should be changed only by network core or in
|
||||
error paths of ndo_set_features callback.
|
||||
|
||||
3. netdev->vlan_features set contains features whose state is inherited
|
||||
by child VLAN devices (limits netdev->features set). This is currently
|
||||
used for all VLAN devices whether tags are stripped or inserted in
|
||||
hardware or software.
|
||||
|
||||
4. netdev->wanted_features set contains feature set requested by user.
|
||||
3. netdev->wanted_features set contains feature set requested by user.
|
||||
This set is filtered by ndo_fix_features callback whenever it or
|
||||
some device-specific conditions change. This set is internal to
|
||||
networking core and should not be referenced in drivers.
|
||||
|
||||
On top of those three main sets, each netdev has:
|
||||
|
||||
1. Sets which control features inherited by child devices (VLAN, MPLS,
|
||||
hw_enc for L3/L4 tunnels). These sets allow the driver to limit which
|
||||
netdev->features are propagated, in case HW cannot perform the offloads
|
||||
with the extra headers present.
|
||||
|
||||
2. netdev->mangleid_features, TSO features which are supported only when
|
||||
IP ID field can be mangled (constant instead of incrementing) during TSO.
|
||||
|
||||
3. netdev->gso_partial_features, additional TSO features which HW can
|
||||
support via NETIF_F_GSO_PARTIAL.
|
||||
|
||||
Part II: Controlling enabled features
|
||||
=====================================
|
||||
|
|
@ -62,11 +71,22 @@ ndo_*_features callbacks are called with rtnl_lock held. Missing callbacks
|
|||
are treated as always returning success.
|
||||
|
||||
A driver that wants to trigger recalculation must do so by calling
|
||||
netdev_update_features() while holding rtnl_lock. This should not be done
|
||||
from ndo_*_features callbacks. netdev->features should not be modified by
|
||||
driver except by means of ndo_fix_features callback.
|
||||
netdev_update_features() while holding rtnl_lock. If the device uses the
|
||||
netdev instance lock, that lock must be held as well. This should not be
|
||||
done from ndo_*_features callbacks. netdev->features should not be modified
|
||||
by driver except by means of ndo_fix_features callback.
|
||||
|
||||
For "ops locked" drivers (see Documentation/networking/netdevices.rst),
|
||||
ethtool callbacks that may end up invoking netdev_update_features() must
|
||||
opt back into rtnl_lock by setting the matching ETHTOOL_OP_NEEDS_RTNL_*
|
||||
bit in ``ethtool_ops::op_needs_rtnl``. The ethtool core then keeps
|
||||
rtnl_lock held across those SET callbacks so the contract above still
|
||||
holds.
|
||||
|
||||
ndo_features_check is called for each skb before that skb is passed to
|
||||
ndo_start_xmit. Driver may perform any non-trivial checks (e.g. exact
|
||||
header geometry / length) and withdraw features like HW_CSUM or TSO,
|
||||
requesting the networking stack to fall back to the software implementation.
|
||||
|
||||
Part III: Implementation hints
|
||||
==============================
|
||||
|
|
@ -83,8 +103,9 @@ stateless). It can be called multiple times between successive
|
|||
ndo_set_features calls.
|
||||
|
||||
Callback must not alter features contained in NETIF_F_SOFT_FEATURES or
|
||||
NETIF_F_NEVER_CHANGE sets. The exception is NETIF_F_VLAN_CHALLENGED but
|
||||
care must be taken as the change won't affect already configured VLANs.
|
||||
NETIF_F_NEVER_CHANGE, except that NETIF_F_VLAN_CHALLENGED may be changed.
|
||||
Care must be taken as changes to NETIF_F_VLAN_CHALLENGED won't affect already
|
||||
configured VLANs.
|
||||
|
||||
* ndo_set_features:
|
||||
|
||||
|
|
@ -186,10 +207,14 @@ Redundancy) frames from one port to another in hardware.
|
|||
* hsr-dup-offload
|
||||
|
||||
This should be set for devices which duplicate outgoing HSR (High-availability
|
||||
Seamless Redundancy) or PRP (Parallel Redundancy Protocol) tags automatically
|
||||
frames in hardware.
|
||||
Seamless Redundancy) or PRP (Parallel Redundancy Protocol) frames
|
||||
automatically in hardware.
|
||||
|
||||
* netmem-tx
|
||||
Part V: Related device flags
|
||||
============================
|
||||
|
||||
This should be set for devices which support netmem TX. See
|
||||
Documentation/networking/netmem.rst
|
||||
* netdev->netmem_tx
|
||||
|
||||
This is not a netdev feature bit. Drivers support netmem TX by setting
|
||||
netdev->netmem_tx to one of the values in enum netmem_tx_mode.
|
||||
See Documentation/networking/netmem.rst.
|
||||
|
|
|
|||
|
|
@ -21,13 +21,14 @@ by free_netdev(). This is required to handle the pathological case cleanly
|
|||
alloc_netdev_mqs() / alloc_netdev() reserve extra space for driver
|
||||
private data which gets freed when the network device is freed. If
|
||||
separately allocated data is attached to the network device
|
||||
(netdev_priv()) then it is up to the module exit handler to free that.
|
||||
(extra pointers stored in the device private struct) then it is up
|
||||
to the module exit handler to free that.
|
||||
|
||||
There are two groups of APIs for registering struct net_device.
|
||||
First group can be used in normal contexts where ``rtnl_lock`` is not already
|
||||
held: register_netdev(), unregister_netdev().
|
||||
Second group can be used when ``rtnl_lock`` is already held:
|
||||
register_netdevice(), unregister_netdevice(), free_netdevice().
|
||||
register_netdevice(), unregister_netdevice(), free_netdev().
|
||||
|
||||
Simple drivers
|
||||
--------------
|
||||
|
|
@ -58,6 +59,7 @@ the register_netdev(), and unregister_netdev() functions:
|
|||
goto err_undo;
|
||||
|
||||
/* net_device is visible to the user! */
|
||||
return 0;
|
||||
|
||||
err_undo:
|
||||
/* ... undo the device setup ... */
|
||||
|
|
@ -73,7 +75,7 @@ the register_netdev(), and unregister_netdev() functions:
|
|||
|
||||
Note that after calling register_netdev() the device is visible in the system.
|
||||
Users can open it and start sending / receiving traffic immediately,
|
||||
or run any other callback, so all initialization must be done prior to
|
||||
or run any other callback, so all initialization must be **complete** prior to
|
||||
registration.
|
||||
|
||||
unregister_netdev() closes the device and waits for all users to be done
|
||||
|
|
@ -157,7 +159,7 @@ register_netdevice() fails. The callback may be invoked with or without
|
|||
There is no explicit constructor callback, driver "constructs" the private
|
||||
netdev state after allocating it and before registration.
|
||||
|
||||
Setting struct net_device.needs_free_netdev makes core call free_netdevice()
|
||||
Setting struct net_device.needs_free_netdev makes core call free_netdev()
|
||||
automatically after unregister_netdevice() when all references to the device
|
||||
are gone. It only takes effect after a successful call to register_netdevice()
|
||||
so if register_netdevice() fails driver is responsible for calling
|
||||
|
|
@ -256,7 +258,7 @@ ndo_eth_ioctl:
|
|||
lock if the driver implements queue management or shaper API.
|
||||
Context: process
|
||||
|
||||
ndo_get_stats:
|
||||
ndo_get_stats / ndo_get_stats64:
|
||||
Synchronization: RCU (can be called concurrently with the stats
|
||||
update path).
|
||||
Context: atomic (can't sleep under RCU)
|
||||
|
|
@ -264,12 +266,9 @@ ndo_get_stats:
|
|||
ndo_start_xmit:
|
||||
Synchronization: __netif_tx_lock spinlock.
|
||||
|
||||
When the driver sets dev->lltx this will be
|
||||
called without holding netif_tx_lock. In this case the driver
|
||||
has to lock by itself when needed.
|
||||
The locking there should also properly protect against
|
||||
set_rx_mode. WARNING: use of dev->lltx is deprecated.
|
||||
Don't use it for new drivers.
|
||||
When the driver sets dev->lltx this will be called without holding
|
||||
netif_tx_lock. dev->lltx is meant for software drivers only, since
|
||||
they often have no per-queue state.
|
||||
|
||||
Context: Process with BHs disabled or BH (timer),
|
||||
will be called with interrupts disabled by netconsole.
|
||||
|
|
@ -304,11 +303,15 @@ ndo_change_rx_flags:
|
|||
lock if the driver implements queue management or shaper API.
|
||||
|
||||
ndo_setup_tc:
|
||||
``TC_SETUP_BLOCK`` and ``TC_SETUP_FT`` are running under NFT locks
|
||||
(i.e. no ``rtnl_lock`` and no device instance lock). The rest of
|
||||
``tc_setup_type`` types run under netdev instance lock if the driver
|
||||
Locking depends on ``tc_setup_type``. For most types the callback
|
||||
is invoked under ``rtnl_lock`` and netdev instance lock if the driver
|
||||
implements queue management or shaper API.
|
||||
|
||||
For ``TC_SETUP_BLOCK`` and ``TC_SETUP_FT`` ``rtnl_lock`` may or
|
||||
may not be held, and the netdev instance lock is not held.
|
||||
``TC_SETUP_BLOCK`` runs under ``block->cb_lock`` and ``TC_SETUP_FT``
|
||||
runs under ``flowtable->flow_block_lock``.
|
||||
|
||||
Most ndo callbacks not specified in the list above are running
|
||||
under ``rtnl_lock``. In addition, netdev instance lock is taken as well if
|
||||
the driver implements queue management or shaper API.
|
||||
|
|
@ -348,10 +351,6 @@ virtual and the physical device. To prevent deadlocks, the virtual device's
|
|||
lock must always be acquired before the physical device's (see
|
||||
``netdev_nl_queue_create_doit``).
|
||||
|
||||
In the future, there will be an option for individual
|
||||
drivers to opt out of using ``rtnl_lock`` and instead perform their control
|
||||
operations directly under the netdev instance lock.
|
||||
|
||||
Device drivers are encouraged to rely on the instance lock where possible.
|
||||
|
||||
For the (mostly software) drivers that need to interact with the core stack,
|
||||
|
|
@ -372,9 +371,16 @@ the instance lock.
|
|||
struct ethtool_ops
|
||||
------------------
|
||||
|
||||
Similarly to ``ndos`` the instance lock is only held for select drivers.
|
||||
For "ops locked" drivers all ethtool ops without exceptions should
|
||||
be called under the instance lock.
|
||||
For non-"ops locked" drivers ethtool_ops are executed under ``rtnl_lock``.
|
||||
|
||||
For "ops locked" drivers, ``ethtool_ops``, unlike ``ndos``, run under
|
||||
the instance lock **only**. Drivers may request that ``rtnl_lock``
|
||||
is held around specific operations (both SET and GET) by setting
|
||||
appropriate bits in ``ethtool_ops::op_needs_rtnl`` (if the necessary
|
||||
``ETHTOOL_OP_NEEDS_RTNL_*`` bit doesn't exist, just add it).
|
||||
Commonly used core helpers which force drivers to selectively opt-in to
|
||||
``rtnl_lock`` protection include ``netdev_update_features()``,
|
||||
``netif_set_real_num_tx_queues()``, and phylink helpers.
|
||||
|
||||
struct netdev_stat_ops
|
||||
----------------------
|
||||
|
|
@ -412,6 +418,7 @@ The following netdev notifiers are always run under the instance lock:
|
|||
For devices with locked ops, currently only the following notifiers are
|
||||
running under the lock:
|
||||
* ``NETDEV_CHANGE``
|
||||
* ``NETDEV_CHANGENAME``
|
||||
* ``NETDEV_REGISTER``
|
||||
* ``NETDEV_UP``
|
||||
|
||||
|
|
|
|||
|
|
@ -95,4 +95,10 @@ Driver TX Requirements
|
|||
netdev@, or reach out to the maintainers and/or almasrymina@google.com for
|
||||
help adding the netmem API.
|
||||
|
||||
2. Driver should declare support by setting `netdev->netmem_tx = true`
|
||||
2. Driver should declare support by setting `netdev->netmem_tx` to the
|
||||
appropriate mode:
|
||||
|
||||
- `NETMEM_TX_DMA`: for physical devices that perform DMA.
|
||||
|
||||
- `NETMEM_TX_NO_DMA`: for virtual or passthrough devices that do
|
||||
not DMA, but still support handling of netmem-backed skbs.
|
||||
|
|
|
|||
|
|
@ -43,18 +43,32 @@ Architecture overview
|
|||
|
||||
Monitoring
|
||||
==========
|
||||
Information about page pools on the system can be accessed via the netdev
|
||||
genetlink family (see Documentation/netlink/specs/netdev.yaml).
|
||||
Information about allocated page pools, their memory use, recycling statistics
|
||||
etc. can be accessed via the netdev genetlink family
|
||||
(see Documentation/netlink/specs/netdev.yaml).
|
||||
|
||||
Statistics
|
||||
----------
|
||||
|
||||
.. kernel-doc:: include/net/page_pool/types.h
|
||||
:identifiers: struct page_pool_recycle_stats
|
||||
struct page_pool_alloc_stats
|
||||
struct page_pool_stats
|
||||
|
||||
API interface
|
||||
=============
|
||||
The number of pools created **must** match the number of hardware queues
|
||||
The number of pools created **must** match the number of NAPI contexts / queues
|
||||
unless hardware restrictions make that impossible. This would otherwise beat the
|
||||
purpose of page pool, which is allocate pages fast from cache without locking.
|
||||
This lockless guarantee naturally comes from running under a NAPI softirq.
|
||||
The protection doesn't strictly have to be NAPI, any guarantee that allocating
|
||||
a page will cause no race conditions is enough.
|
||||
|
||||
If ``params.napi`` is set, the NAPI instance must be the sole consumer
|
||||
context for pages allocated from the pool. In other words, when running in
|
||||
that NAPI context, the page pool may safely access consumer-side resources
|
||||
**without any additional locking**.
|
||||
|
||||
.. kernel-doc:: net/core/page_pool.c
|
||||
:identifiers: page_pool_create
|
||||
|
||||
|
|
@ -69,7 +83,7 @@ a page will cause no race conditions is enough.
|
|||
page_pool_get_dma_addr page_pool_get_dma_dir
|
||||
|
||||
.. kernel-doc:: net/core/page_pool.c
|
||||
:identifiers: page_pool_put_page_bulk page_pool_get_stats
|
||||
:identifiers: page_pool_put_page_bulk
|
||||
|
||||
DMA sync
|
||||
--------
|
||||
|
|
@ -98,29 +112,12 @@ If in doubt set ``offset`` to 0, ``max_len`` to ``PAGE_SIZE`` and
|
|||
pass -1 as ``dma_sync_size``. That combination of arguments is always
|
||||
correct.
|
||||
|
||||
Note that the syncing parameters are for the entire page.
|
||||
This is important to remember when using fragments (``PP_FLAG_PAGE_FRAG``),
|
||||
where allocated buffers may be smaller than a full page.
|
||||
Note that the syncing parameters are for the **entire page**, even if
|
||||
the driver allocates fragments (e.g. via ``page_pool_dev_alloc_frag()``).
|
||||
Unless the driver author really understands page pool internals
|
||||
it's recommended to always use ``offset = 0``, ``max_len = PAGE_SIZE``
|
||||
with fragmented page pools.
|
||||
|
||||
Stats API and structures
|
||||
------------------------
|
||||
If the kernel is configured with ``CONFIG_PAGE_POOL_STATS=y``, the API
|
||||
page_pool_get_stats() and structures described below are available.
|
||||
It takes a pointer to a ``struct page_pool`` and a pointer to a struct
|
||||
page_pool_stats allocated by the caller.
|
||||
|
||||
Older drivers expose page pool statistics via ethtool or debugfs.
|
||||
The same statistics are accessible via the netlink netdev family
|
||||
in a driver-independent fashion.
|
||||
|
||||
.. kernel-doc:: include/net/page_pool/types.h
|
||||
:identifiers: struct page_pool_recycle_stats
|
||||
struct page_pool_alloc_stats
|
||||
struct page_pool_stats
|
||||
|
||||
Coding examples
|
||||
===============
|
||||
|
||||
|
|
@ -140,7 +137,7 @@ Registration
|
|||
pp_params.pool_size = DESC_NUM;
|
||||
pp_params.nid = NUMA_NO_NODE;
|
||||
pp_params.dev = priv->dev;
|
||||
pp_params.napi = napi; /* only if locking is tied to NAPI */
|
||||
pp_params.napi = napi; /* only if this NAPI is the sole consumer, see above */
|
||||
pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
|
||||
page_pool = page_pool_create(&pp_params);
|
||||
|
||||
|
|
@ -174,21 +171,6 @@ NAPI poller
|
|||
}
|
||||
}
|
||||
|
||||
Stats
|
||||
-----
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#ifdef CONFIG_PAGE_POOL_STATS
|
||||
/* retrieve stats */
|
||||
struct page_pool_stats stats = { 0 };
|
||||
if (page_pool_get_stats(page_pool, &stats)) {
|
||||
/* perhaps the driver reports statistics with ethool */
|
||||
ethtool_print_allocation_stats(&stats.alloc_stats);
|
||||
ethtool_print_recycle_stats(&stats.recycle_stats);
|
||||
}
|
||||
#endif
|
||||
|
||||
Driver unload
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -14,10 +14,13 @@ to take advantage of segmentation offload capabilities of various NICs.
|
|||
The following technologies are described:
|
||||
* TCP Segmentation Offload - TSO
|
||||
* UDP Fragmentation Offload - UFO
|
||||
* UDP Segmentation Offload - USO
|
||||
* IPIP, SIT, GRE, and UDP Tunnel Offloads
|
||||
* Generic Segmentation Offload - GSO
|
||||
* Generic Receive Offload - GRO
|
||||
* Partial Generic Segmentation Offload - GSO_PARTIAL
|
||||
* ESP Segmentation Offload
|
||||
* Fraglist Generic Segmentation Offload - GSO_FRAGLIST
|
||||
* SCTP acceleration with GSO - GSO_BY_FRAGS
|
||||
|
||||
|
||||
|
|
@ -38,7 +41,8 @@ In order to support TCP segmentation offload it is necessary to populate
|
|||
the network and transport header offsets of the skbuff so that the device
|
||||
drivers will be able determine the offsets of the IP or IPv6 header and the
|
||||
TCP header. In addition as CHECKSUM_PARTIAL is required csum_start should
|
||||
also point to the TCP header of the packet.
|
||||
also point to the TCP header of the packet, or to the inner transport header
|
||||
for encapsulated TSO.
|
||||
|
||||
For IPv4 segmentation we support one of two types in terms of the IP ID.
|
||||
The default behavior is to increment the IP ID with every segment. If the
|
||||
|
|
@ -57,6 +61,10 @@ DF bit is not set on the outer header, in which case the device driver must
|
|||
guarantee that the IP ID field is incremented in the outer header with every
|
||||
segment.
|
||||
|
||||
SKB_GSO_TCP_ACCECN is a modifier used with TCP segmentation offload for
|
||||
AccECN packets where the CWR bit must not be cleared during segmentation.
|
||||
Devices advertise support for this using NETIF_F_GSO_ACCECN.
|
||||
|
||||
|
||||
UDP Fragmentation Offload
|
||||
=========================
|
||||
|
|
@ -71,6 +79,16 @@ still receive them from tuntap and similar devices. Offload of UDP-based
|
|||
tunnel protocols is still supported.
|
||||
|
||||
|
||||
UDP Segmentation Offload
|
||||
========================
|
||||
|
||||
UDP segmentation offload allows a device to segment a large UDP packet into
|
||||
multiple UDP datagrams. Unlike UFO, these are not IP fragments. The payload
|
||||
size of each datagram is specified in skb_shinfo()->gso_size and the GSO type
|
||||
is SKB_GSO_UDP_L4. Devices advertise support for this using
|
||||
NETIF_F_GSO_UDP_L4.
|
||||
|
||||
|
||||
IPIP, SIT, GRE, UDP Tunnel, and Remote Checksum Offloads
|
||||
========================================================
|
||||
|
||||
|
|
@ -154,6 +172,23 @@ that the IPv4 ID field is incremented in the case that a given header does
|
|||
not have the DF bit set.
|
||||
|
||||
|
||||
ESP Segmentation Offload
|
||||
========================
|
||||
|
||||
ESP segmentation offload uses SKB_GSO_ESP to mark packets that require
|
||||
IPsec ESP segmentation. This type is set by the XFRM output path for GSO
|
||||
packets handled by ESP hardware offload.
|
||||
|
||||
|
||||
Fraglist Generic Segmentation Offload
|
||||
=====================================
|
||||
|
||||
Fraglist GSO uses SKB_GSO_FRAGLIST to mark packets whose segments are
|
||||
already arranged as a list of skbs. The segmentation path splits the skb
|
||||
based on that list rather than by creating segments of skb_shinfo()->gso_size
|
||||
bytes from the linear and page-fragment data.
|
||||
|
||||
|
||||
SCTP acceleration with GSO
|
||||
===========================
|
||||
|
||||
|
|
|
|||
|
|
@ -29,9 +29,3 @@ dataref and headerless skbs
|
|||
|
||||
.. kernel-doc:: include/linux/skbuff.h
|
||||
:doc: dataref and headerless skbs
|
||||
|
||||
Checksum information
|
||||
--------------------
|
||||
|
||||
.. kernel-doc:: include/linux/skbuff.h
|
||||
:doc: skb checksums
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ smcr_max_send_wr - INTEGER
|
|||
Please be aware that all the buffers need to be allocated as a physically
|
||||
continuous array in which each element is a single buffer and has the size
|
||||
of SMC_WR_BUF_SIZE (48) bytes. If the allocation fails, we keep retrying
|
||||
with half of the buffer count until it is ether successful or (unlikely)
|
||||
with half of the buffer count until it is either successful or (unlikely)
|
||||
we dip below the old hard coded value which is 16 where we give up much
|
||||
like before having this control.
|
||||
|
||||
|
|
@ -100,14 +100,14 @@ smcr_max_recv_wr - INTEGER
|
|||
depending on the workload it can be a bottleneck in a sense that threads
|
||||
have to wait for work request buffers to become available. Before the
|
||||
introduction of this control the maximal number of work request buffers
|
||||
available on the receive path used to be hard coded to 16. With this control
|
||||
available on the receive path used to be hard coded to 48. With this control
|
||||
it becomes configurable. The acceptable range is between 2 and 2048.
|
||||
|
||||
Please be aware that all the buffers need to be allocated as a physically
|
||||
continuous array in which each element is a single buffer and has the size
|
||||
of SMC_WR_BUF_SIZE (48) bytes. If the allocation fails, we keep retrying
|
||||
with half of the buffer count until it is ether successful or (unlikely)
|
||||
we dip below the old hard coded value which is 16 where we give up much
|
||||
with half of the buffer count until it is either successful or (unlikely)
|
||||
we dip below the old hard coded value which is 48 where we give up much
|
||||
like before having this control.
|
||||
|
||||
Default: 48
|
||||
|
|
|
|||
|
|
@ -231,8 +231,19 @@ Kernel-internal data structures
|
|||
-------------------------------
|
||||
|
||||
The following structures are internal to the kernel, their members are
|
||||
translated to netlink attributes when dumped. Drivers must not overwrite
|
||||
the statistics they don't report with 0.
|
||||
translated to netlink attributes when dumped. Fields are pre-initialized
|
||||
to ``ETHTOOL_STAT_NOT_SET`` (by ``ethtool_stats_init()``); drivers must
|
||||
leave fields they do not report at that value rather than overwriting
|
||||
them with 0.
|
||||
|
||||
- ethtool_pause_stats()
|
||||
- ethtool_fec_stats()
|
||||
- ``struct ethtool_eth_ctrl_stats``
|
||||
- ``struct ethtool_eth_mac_stats``
|
||||
- ``struct ethtool_eth_phy_stats``
|
||||
- ``struct ethtool_fec_hist``
|
||||
- ``struct ethtool_fec_stats``
|
||||
- ``struct ethtool_link_ext_stats``
|
||||
- ``struct ethtool_mm_stats``
|
||||
- ``struct ethtool_pause_stats``
|
||||
- ``struct ethtool_phy_stats``
|
||||
- ``struct ethtool_rmon_stats``
|
||||
- ``struct ethtool_ts_stats``
|
||||
|
|
|
|||
|
|
@ -40,8 +40,8 @@ Functions
|
|||
|
||||
::
|
||||
|
||||
strp_init(struct strparser *strp, struct sock *sk,
|
||||
const struct strp_callbacks *cb)
|
||||
int strp_init(struct strparser *strp, struct sock *sk,
|
||||
const struct strp_callbacks *cb)
|
||||
|
||||
Called to initialize a stream parser. strp is a struct of type
|
||||
strparser that is allocated by the upper layer. sk is the TCP
|
||||
|
|
@ -95,7 +95,7 @@ Functions
|
|||
|
||||
void strp_data_ready(struct strparser *strp);
|
||||
|
||||
The upper layer calls strp_tcp_data_ready when data is ready on
|
||||
The upper layer calls strp_data_ready when data is ready on
|
||||
the lower socket for strparser to process. This should be called
|
||||
from a data_ready callback that is set on the socket. Note that
|
||||
maximum messages size is the limit of the receive socket
|
||||
|
|
@ -123,9 +123,9 @@ There are seven callbacks:
|
|||
should parse the sk_buff as containing the headers for the
|
||||
next application layer message in the stream.
|
||||
|
||||
The skb->cb in the input skb is a struct strp_msg. Only
|
||||
the offset field is relevant in parse_msg and gives the offset
|
||||
where the message starts in the skb.
|
||||
The strparser metadata in the input skb can be accessed with
|
||||
strp_msg(skb). Only the offset field is relevant in parse_msg and
|
||||
gives the offset where the message starts in the skb.
|
||||
|
||||
The return values of this function are:
|
||||
|
||||
|
|
@ -176,11 +176,11 @@ There are seven callbacks:
|
|||
received in rcv_msg (see strp_pause above). This callback
|
||||
must be set.
|
||||
|
||||
The skb->cb in the input skb is a struct strp_msg. This
|
||||
struct contains two fields: offset and full_len. Offset is
|
||||
where the message starts in the skb, and full_len is the
|
||||
the length of the message. skb->len - offset may be greater
|
||||
than full_len since strparser does not trim the skb.
|
||||
The strparser metadata in the input skb can be accessed with
|
||||
strp_msg(skb). This struct contains two fields: offset and full_len.
|
||||
Offset is where the message starts in the skb, and full_len is
|
||||
the length of the message. skb->len - offset may be greater than
|
||||
full_len since strparser does not trim the skb.
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -7,9 +7,9 @@ TCP Authentication Option Linux implementation (RFC5925)
|
|||
TCP Authentication Option (TCP-AO) provides a TCP extension aimed at verifying
|
||||
segments between trusted peers. It adds a new TCP header option with
|
||||
a Message Authentication Code (MAC). MACs are produced from the content
|
||||
of a TCP segment using a hashing function with a password known to both peers.
|
||||
of a TCP segment using a key known to both peers.
|
||||
The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
|
||||
key rotation and support for a variety of hashing algorithms.
|
||||
key rotation and support for a variety of MAC algorithms.
|
||||
|
||||
1. Introduction
|
||||
===============
|
||||
|
|
@ -19,16 +19,18 @@ key rotation and support for a variety of hashing algorithms.
|
|||
+----------------------+------------------------+-----------------------+
|
||||
| | TCP-MD5 | TCP-AO |
|
||||
+======================+========================+=======================+
|
||||
|Supported hashing |MD5 |Must support HMAC-SHA1 |
|
||||
|algorithms |(cryptographically weak)|(chosen-prefix attacks)|
|
||||
| | |and CMAC-AES-128 (only |
|
||||
| | |side-channel attacks). |
|
||||
| | |May support any hashing|
|
||||
| | |algorithm. |
|
||||
|Supported MAC |MD5 of data and key |HMAC-SHA-1-96 and |
|
||||
|algorithms |(cryptographically weak)|AES-128-CMAC-96. |
|
||||
| | |Implementations are |
|
||||
| | |permitted to support |
|
||||
| | |additional algorithms. |
|
||||
+----------------------+------------------------+-----------------------+
|
||||
|Length of MACs (bytes)|16 |Typically 12-16. |
|
||||
| | |Other variants that fit|
|
||||
| | |TCP header permitted. |
|
||||
|Length of MACs (bytes)|16 |12 for HMAC-SHA-1-96 |
|
||||
| | |and AES-128-CMAC-96. |
|
||||
| | |Implementations are |
|
||||
| | |permitted to support |
|
||||
| | |any MAC length that |
|
||||
| | |fits in the TCP header.|
|
||||
+----------------------+------------------------+-----------------------+
|
||||
|Number of keys per |1 |Many |
|
||||
|TCP connection | | |
|
||||
|
|
@ -296,6 +298,20 @@ userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs
|
|||
It is not allowed to add a key on an established non-TCP-AO connection
|
||||
as well as to remove the last key from TCP-AO connection.
|
||||
|
||||
``TCP_AO_ADD_KEY`` allows the MAC algorithm and MAC length to be selected.
|
||||
Linux supports the mandatory-to-implement algorithms HMAC-SHA-1-96 and
|
||||
AES-128-CMAC-96. In addition, as Linux extensions, it supports:
|
||||
|
||||
- HMAC-SHA256. Linux uses HMAC-SHA256 in the same way as HMAC-SHA1; this
|
||||
includes omitting an explicit entropy extraction step. To work around the
|
||||
missing entropy extraction, users should provide keys with full entropy. The
|
||||
implementation is interoperable with other implementations of HMAC-SHA256 for
|
||||
TCP-AO only when they have implemented the key derivation the same way (and
|
||||
also the same MAC length is selected on each side).
|
||||
|
||||
- Any MAC length for any of the supported MAC algorithms, provided it fits in
|
||||
the TCP header and is at least 4 bytes.
|
||||
|
||||
``setsockopt(TCP_AO_DEL_KEY)`` command may specify ``tcp_ao_del::current_key``
|
||||
+ ``tcp_ao_del::set_current`` and/or ``tcp_ao_del::rnext``
|
||||
+ ``tcp_ao_del::set_rnext`` which makes such delete "forced": it
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Layer Protocol (ULP) and install the cryptographic connection state.
|
|||
For details regarding the user-facing interface refer to the TLS
|
||||
documentation in :ref:`Documentation/networking/tls.rst <kernel_tls>`.
|
||||
|
||||
``ktls`` can operate in three modes:
|
||||
``ktls`` can operate in two modes:
|
||||
|
||||
* Software crypto mode (``TLS_SW``) - CPU handles the cryptography.
|
||||
In most basic cases only crypto operations synchronous with the CPU
|
||||
|
|
@ -26,11 +26,6 @@ documentation in :ref:`Documentation/networking/tls.rst <kernel_tls>`.
|
|||
This mode integrates best with the kernel stack and is described in detail
|
||||
in the remaining part of this document
|
||||
(``ethtool`` flags ``tls-hw-tx-offload`` and ``tls-hw-rx-offload``).
|
||||
* Full TCP NIC offload mode (``TLS_HW_RECORD``) - mode of operation where
|
||||
NIC driver and firmware replace the kernel networking stack
|
||||
with its own TCP handling, it is not usable in production environments
|
||||
making use of the Linux networking stack for example any firewalling
|
||||
abilities or QoS and packet scheduling (``ethtool`` flag ``tls-hw-record``).
|
||||
|
||||
The operation mode is selected automatically based on device configuration,
|
||||
offload opt-in or opt-out on per-connection basis is not currently supported.
|
||||
|
|
@ -104,6 +99,29 @@ at the end of kernel structures (see :c:member:`driver_state` members
|
|||
in ``include/net/tls.h``) to avoid additional allocations and pointer
|
||||
dereferences.
|
||||
|
||||
When the offloaded connection is destroyed the core calls
|
||||
the :c:member:`tls_dev_del` callback so the driver can release per-direction
|
||||
state:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
void (*tls_dev_del)(struct net_device *netdev,
|
||||
struct tls_context *ctx,
|
||||
enum tls_offload_ctx_dir direction);
|
||||
|
||||
``tls_dev_del`` is mandatory whenever ``tls_dev_add`` is provided.
|
||||
|
||||
The third TLS device callback is :c:member:`tls_dev_resync`, called by the core
|
||||
to synchronize the TCP stream with the record boundaries:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int (*tls_dev_resync)(struct net_device *netdev,
|
||||
struct sock *sk, u32 seq, u8 *rcd_sn,
|
||||
enum tls_offload_ctx_dir direction);
|
||||
|
||||
See the `Resync handling`_ section for details.
|
||||
|
||||
TX
|
||||
--
|
||||
|
||||
|
|
@ -255,9 +273,9 @@ Following helper should be used to test if resync is complete:
|
|||
bool tls_offload_tx_resync_pending(struct sock *sk)
|
||||
|
||||
Next time ``ktls`` pushes a record it will first send its TCP sequence number
|
||||
and TLS record number to the driver. Stack will also make sure that
|
||||
the new record will start on a segment boundary (like it does when
|
||||
the connection is initially added).
|
||||
and TLS record number to the driver via the ``tls_dev_resync`` callback.
|
||||
The stack will also make sure that the new record will start on a segment
|
||||
boundary (like it does when the connection is initially added).
|
||||
|
||||
RX
|
||||
--
|
||||
|
|
@ -349,9 +367,10 @@ all TLS record headers that have been logged since the resync request
|
|||
started.
|
||||
|
||||
The kernel confirms the guessed location was correct and tells the device
|
||||
the record sequence number. Meanwhile, the device had been parsing
|
||||
and counting all records since the just-confirmed one, it adds the number
|
||||
of records it had seen to the record number provided by the kernel.
|
||||
the record sequence number via the ``tls_dev_resync`` callback. Meanwhile,
|
||||
the device had been parsing and counting all records since the just-confirmed
|
||||
one, it adds the number of records it had seen to the record number provided
|
||||
by the kernel.
|
||||
At this point the device is in sync and can resume decryption at next
|
||||
segment boundary.
|
||||
|
||||
|
|
@ -375,12 +394,19 @@ schedules resynchronization after it has received two completely encrypted
|
|||
records.
|
||||
|
||||
The stack waits for the socket to drain and informs the device about
|
||||
the next expected record number and its TCP sequence number. If the
|
||||
the next expected record number and its TCP sequence number via the
|
||||
``tls_dev_resync`` callback. If the
|
||||
records continue to be received fully encrypted stack retries the
|
||||
synchronization with an exponential back off (first after 2 encrypted
|
||||
records, then after 4 records, after 8, after 16... up until every
|
||||
128 records).
|
||||
|
||||
Rekey
|
||||
=====
|
||||
|
||||
Offload does not currently support TLS 1.3, therefore key rotation
|
||||
is not a concern for offloaded connections at this point.
|
||||
|
||||
Error handling
|
||||
==============
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ metadata available in which case the driver returns ``-ENODATA``.
|
|||
|
||||
Not all kfuncs have to be implemented by the device driver; when not
|
||||
implemented, the default ones that return ``-EOPNOTSUPP`` will be used
|
||||
to indicate the device driver have not implemented this kfunc.
|
||||
to indicate the device driver has not implemented this kfunc.
|
||||
|
||||
|
||||
Within an XDP frame, the metadata layout (accessed via ``xdp_buff``) is
|
||||
|
|
|
|||
|
|
@ -9,5 +9,6 @@ XFRM Framework
|
|||
|
||||
xfrm_device
|
||||
xfrm_proc
|
||||
xfrm_migrate_state
|
||||
xfrm_sync
|
||||
xfrm_sysctl
|
||||
|
|
|
|||
274
Documentation/networking/xfrm/xfrm_migrate_state.rst
Normal file
274
Documentation/networking/xfrm/xfrm_migrate_state.rst
Normal file
|
|
@ -0,0 +1,274 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====================
|
||||
XFRM SA Migrate State
|
||||
=====================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
``XFRM_MSG_MIGRATE_STATE`` migrates a single SA, looked up using SPI and
|
||||
mark, without involving policies. Unlike ``XFRM_MSG_MIGRATE``, which couples
|
||||
SA and policy migration and allows migrating multiple SAs in one call, this
|
||||
interface identifies the SA unambiguously via SPI and supports changing
|
||||
the reqid, addresses, encapsulation, selector, and offload.
|
||||
|
||||
Because IKE daemons can manage policies independently of
|
||||
the kernel, this interface allows precise per-SA migration without
|
||||
requiring policy involvement. Optional netlink attributes follow an
|
||||
omit-to-inherit model: omitting an attribute preserves the value from
|
||||
the old SA. The ``flags`` field controls two exceptions: hardware offload
|
||||
is inherited by default and can be suppressed with
|
||||
``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD`` or overridden with ``XFRMA_OFFLOAD_DEV``;
|
||||
the new selector is taken from ``new_sel`` by default and can instead be
|
||||
derived from the new addresses with ``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL``.
|
||||
|
||||
SA Identification
|
||||
=================
|
||||
|
||||
The struct is defined in ``include/uapi/linux/xfrm.h``. The SA is looked
|
||||
up using ``xfrm_state_lookup()`` with ``id.spi``,
|
||||
``id.daddr``, ``id.proto``, ``id.family``, and
|
||||
``old_mark.v & old_mark.m`` as the mark key::
|
||||
|
||||
struct xfrm_user_migrate_state {
|
||||
struct xfrm_usersa_id id; /* spi, daddr, proto, family */
|
||||
xfrm_address_t new_daddr;
|
||||
xfrm_address_t new_saddr;
|
||||
struct xfrm_mark old_mark; /* SA lookup: key = v & m */
|
||||
struct xfrm_selector new_sel; /* new selector (see Flags) */
|
||||
__u32 new_reqid;
|
||||
__u32 flags; /* XFRM_MIGRATE_STATE_* */
|
||||
__u16 new_family;
|
||||
__u16 reserved; /* must be zero */
|
||||
};
|
||||
|
||||
The ``reserved`` field must be set to zero; the kernel rejects any
|
||||
other value with ``-EINVAL``.
|
||||
|
||||
Supported Attributes
|
||||
====================
|
||||
|
||||
The following fields in ``xfrm_user_migrate_state`` are always explicit
|
||||
and are not inherited from the existing SA. Passing zero is not equivalent
|
||||
to "keep unchanged" — zero is used as-is:
|
||||
|
||||
- ``new_daddr`` - new destination address
|
||||
- ``new_saddr`` - new source address
|
||||
- ``new_family`` - new address family
|
||||
- ``new_reqid`` - new reqid (0 = no reqid)
|
||||
- ``new_sel`` - new selector; used when ``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL`` is
|
||||
not set (see `Flags`_ below)
|
||||
- ``flags`` - bitmask of ``XFRM_MIGRATE_STATE_*`` flags (see `Flags`_ below)
|
||||
|
||||
The following netlink attributes are also accepted. Omitting an attribute
|
||||
inherits the value from the existing SA (omit-to-inherit).
|
||||
|
||||
.. list-table::
|
||||
:widths: 30 70
|
||||
:header-rows: 1
|
||||
|
||||
* - Attribute
|
||||
- Description
|
||||
* - ``XFRMA_MARK``
|
||||
- Mark on the migrated SA (``struct xfrm_mark``). Absent inherits
|
||||
``old_mark``. To use no mark on the new SA, send ``XFRMA_MARK``
|
||||
with ``{0, 0}``.
|
||||
* - ``XFRMA_ENCAP``
|
||||
- UDP encapsulation template; only ``UDP_ENCAP_ESPINUDP`` is supported.
|
||||
Set ``encap_type=0`` to remove encap.
|
||||
* - ``XFRMA_OFFLOAD_DEV``
|
||||
- Hardware offload configuration (``struct xfrm_user_offload``). Absent
|
||||
copies offload from the existing SA. When
|
||||
``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD`` is set in ``flags``, the new SA has
|
||||
no offload; this flag is mutually exclusive with ``XFRMA_OFFLOAD_DEV``
|
||||
and sending both returns ``-EINVAL``.
|
||||
* - ``XFRMA_SET_MARK``
|
||||
- Output mark on the migrated SA; pair with ``XFRMA_SET_MARK_MASK``.
|
||||
Send 0 to clear.
|
||||
* - ``XFRMA_NAT_KEEPALIVE_INTERVAL``
|
||||
- NAT keepalive interval in seconds. Requires encap. Send 0 to clear.
|
||||
Automatically cleared when encap is removed; setting a non-zero
|
||||
value without encap returns ``-EINVAL``.
|
||||
* - ``XFRMA_MTIMER_THRESH``
|
||||
- Mapping maxage threshold. Only valid on input SAs; setting on an
|
||||
output SA returns ``-EINVAL``. Requires encap. Send 0 to clear.
|
||||
Automatically cleared when encap is removed; setting a non-zero
|
||||
value without encap returns ``-EINVAL``.
|
||||
|
||||
The following SA properties are immutable and cannot be changed via
|
||||
``XFRM_MSG_MIGRATE_STATE``: algorithms (``XFRMA_ALG_*``), replay state,
|
||||
direction (``XFRMA_SA_DIR``), and security context (``XFRMA_SEC_CTX``).
|
||||
|
||||
Flags
|
||||
=====
|
||||
|
||||
The ``flags`` field in ``xfrm_user_migrate_state`` controls optional
|
||||
migration behaviour. Unknown flag bits are rejected with ``-EINVAL``; the
|
||||
extended ACK message identifies the unrecognised bits (e.g. ``"Unknown flags:
|
||||
0x4"``). Userspace can use ``XFRM_MIGRATE_STATE_KNOWN_FLAGS`` (defined in
|
||||
``<linux/xfrm.h>``) to validate flags before sending; note that this constant
|
||||
reflects the flags known to the header version userspace was compiled against,
|
||||
which may differ from what the running kernel accepts.
|
||||
|
||||
.. list-table::
|
||||
:widths: 40 60
|
||||
:header-rows: 1
|
||||
|
||||
* - Flag
|
||||
- Description
|
||||
* - ``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD``
|
||||
- When set, the new SA has no hardware offload even when
|
||||
``XFRMA_OFFLOAD_DEV`` is absent. Without this flag, omitting
|
||||
``XFRMA_OFFLOAD_DEV`` copies the existing offload to the new SA.
|
||||
Mutually exclusive with ``XFRMA_OFFLOAD_DEV``; sending both
|
||||
returns ``-EINVAL``.
|
||||
* - ``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL``
|
||||
- When set, the kernel validates that the existing SA selector is a
|
||||
single-host entry matching the SA addresses (``prefixlen_s ==
|
||||
prefixlen_d`` equal to 32 for IPv4 or 128 for IPv6, and addresses
|
||||
matching ``id.daddr`` and ``props.saddr``). If the check passes,
|
||||
the new selector is derived from ``new_daddr`` and ``new_saddr``
|
||||
with the single-host mask for ``new_family``. A mismatch returns
|
||||
``-EINVAL``. When this flag is not set, ``new_sel`` is used as-is
|
||||
for the migrated SA.
|
||||
|
||||
Migration Steps
|
||||
===============
|
||||
|
||||
Outgoing SA
|
||||
-----------
|
||||
|
||||
To prevent cleartext traffic leaks, install a block policy before
|
||||
migrating:
|
||||
|
||||
#. Install a block policy to drop traffic on the affected selector.
|
||||
#. Remove the old policy.
|
||||
#. Call ``XFRM_MSG_MIGRATE_STATE`` for each SA.
|
||||
#. Reinstall the policies.
|
||||
#. Remove the block policy.
|
||||
|
||||
If AES-GCM is in use, the block policy also prevents IV reuse during
|
||||
the migration window. For other AEADs this step is not required for
|
||||
IV safety, but skipping it allows a brief cleartext window.
|
||||
|
||||
Incoming SA
|
||||
-----------
|
||||
|
||||
No block policy is needed. ``XFRM_MSG_MIGRATE_STATE`` atomically
|
||||
transfers the sequence number and replay window from the old SA to
|
||||
the new SA, so the new SA continues replay protection without a gap.
|
||||
Call ``XFRM_MSG_MIGRATE_STATE`` for each SA directly.
|
||||
|
||||
When accepting incoming traffic, be liberal during the migration
|
||||
window: packets sent by the remote peer before it completed its own
|
||||
migration may arrive out of order or slightly late. Dropping them
|
||||
unnecessarily causes packet loss. A generous replay window reduces
|
||||
the impact of reordering during migration.
|
||||
|
||||
Block Policy and IV Safety
|
||||
--------------------------
|
||||
|
||||
AES-GCM IV uniqueness is critical: reusing a (key, IV) pair allows
|
||||
an attacker to recover the authentication subkey and forge
|
||||
authentication tags, breaking both confidentiality and integrity.
|
||||
This concern applies to outgoing SAs only — the remote peer controls
|
||||
IV generation on incoming traffic.
|
||||
|
||||
``XFRM_MSG_MIGRATE_STATE`` atomically copies the sequence number and
|
||||
replay window from the old SA to the new SA and deletes the old SA.
|
||||
The block policy serves two purposes: it prevents cleartext traffic
|
||||
leaks during the migration window, and for AES-GCM it prevents IV
|
||||
reuse by ensuring no outgoing packets are sent under the same key.
|
||||
The atomic copy of the sequence number and replay window complements
|
||||
this — together they eliminate both risks during migration.
|
||||
The atomic copy also serves incoming SAs, ensuring replay protection
|
||||
continues without a gap across the migration.
|
||||
|
||||
Feature Detection
|
||||
=================
|
||||
|
||||
Userspace can probe for kernel support by sending a minimal
|
||||
``XFRM_MSG_MIGRATE_STATE`` message with a non-zero non-existent SPI:
|
||||
|
||||
- ``-EINVAL``: kernel predates ``XFRM_MSG_MIGRATE_STATE``; message type
|
||||
is out of range
|
||||
- ``-ENOPROTOOPT``: message type is known but ``CONFIG_XFRM_MIGRATE``
|
||||
is not enabled
|
||||
- ``-ESRCH``: supported (SPI not found)
|
||||
|
||||
Userspace Notification on Success
|
||||
=================================
|
||||
|
||||
On successful migration the kernel multicasts an
|
||||
``XFRM_MSG_MIGRATE_STATE`` message to the ``XFRMNLGRP_MIGRATE`` group.
|
||||
The fixed header is ``struct xfrm_user_migrate_state`` copied from the
|
||||
request, followed by the same set of netlink attributes that are
|
||||
accepted as input, with the differences noted below.
|
||||
|
||||
Differences from the request
|
||||
-----------------------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 25 75
|
||||
:header-rows: 1
|
||||
|
||||
* - Field / Attribute
|
||||
- Difference
|
||||
* - ``new_sel``
|
||||
- Contains the actual selector of the newly installed SA, not the
|
||||
``new_sel`` from the request. When
|
||||
``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL`` is set the kernel derives the
|
||||
selector from ``new_daddr`` / ``new_saddr``; the caller's
|
||||
``new_sel`` field is ignored in that case. The notification
|
||||
always carries the real selector of the new SA.
|
||||
* - ``XFRMA_SA_DIR``
|
||||
- Present in the notification (set from the direction of the new
|
||||
SA) but **not accepted as input** — direction is immutable.
|
||||
* - ``flags``
|
||||
- Echoed back as-is. ``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD`` and
|
||||
``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL`` describe the request that was
|
||||
made, not a property of the resulting SA.
|
||||
|
||||
Attributes in the notification
|
||||
-------------------------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 30 70
|
||||
:header-rows: 1
|
||||
|
||||
* - Attribute
|
||||
- Description
|
||||
* - ``XFRMA_ENCAP``
|
||||
- UDP encapsulation template, if configured on the new SA.
|
||||
* - ``XFRMA_OFFLOAD_DEV``
|
||||
- Hardware offload configuration, if active on the new SA.
|
||||
* - ``XFRMA_MARK``
|
||||
- Mark on the new SA, if set.
|
||||
* - ``XFRMA_SET_MARK``
|
||||
- Output mark on the new SA, if set.
|
||||
* - ``XFRMA_SET_MARK_MASK``
|
||||
- Output mark mask, present together with ``XFRMA_SET_MARK``.
|
||||
* - ``XFRMA_MTIMER_THRESH``
|
||||
- Mapping maxage threshold, if non-zero.
|
||||
* - ``XFRMA_NAT_KEEPALIVE_INTERVAL``
|
||||
- NAT keepalive interval, if non-zero.
|
||||
* - ``XFRMA_SA_DIR``
|
||||
- Direction of the new SA.
|
||||
|
||||
Error Handling
|
||||
==============
|
||||
|
||||
If the target SA tuple (new daddr, SPI, proto, new family) is already
|
||||
occupied, the operation returns ``-EEXIST`` before the migration begins.
|
||||
The old SA remains intact and the operation is safe to retry after
|
||||
resolving the conflict.
|
||||
|
||||
If the target SA is deleted before the migration completes, the operation
|
||||
returns ``-ESRCH``. No new SA is installed. Userspace should verify the
|
||||
current SA state before retrying.
|
||||
|
||||
If the multicast notification (``XFRMNLGRP_MIGRATE``) fails to send,
|
||||
the migration itself has already completed successfully and the new SA
|
||||
is installed. The operation returns success, 0, with an extack warning,
|
||||
but listeners will not receive the migration event.
|
||||
|
|
@ -14,9 +14,9 @@ General Design
|
|||
The headroom for the metadata is reserved via ``tx_metadata_len`` and
|
||||
``XDP_UMEM_TX_METADATA_LEN`` flag in ``struct xdp_umem_reg``. The metadata
|
||||
length is therefore the same for every socket that shares the same umem.
|
||||
The metadata layout is a fixed UAPI, refer to ``union xsk_tx_metadata`` in
|
||||
The metadata layout is a fixed UAPI, refer to ``struct xsk_tx_metadata`` in
|
||||
``include/uapi/linux/if_xdp.h``. Thus, generally, the ``tx_metadata_len``
|
||||
field above should contain ``sizeof(union xsk_tx_metadata)``.
|
||||
field above should contain ``sizeof(struct xsk_tx_metadata)``.
|
||||
|
||||
Note that in the original implementation the ``XDP_UMEM_TX_METADATA_LEN``
|
||||
flag was not required. Applications might attempt to create a umem
|
||||
|
|
@ -45,15 +45,16 @@ the metadata area is ignored by the kernel as well.
|
|||
The flags field enables the particular offload:
|
||||
|
||||
- ``XDP_TXMD_FLAGS_TIMESTAMP``: requests the device to put transmission
|
||||
timestamp into ``tx_timestamp`` field of ``union xsk_tx_metadata``.
|
||||
timestamp into ``completion.tx_timestamp`` field of
|
||||
``struct xsk_tx_metadata``.
|
||||
- ``XDP_TXMD_FLAGS_CHECKSUM``: requests the device to calculate L4
|
||||
checksum. ``csum_start`` specifies byte offset of where the checksumming
|
||||
should start and ``csum_offset`` specifies byte offset where the
|
||||
device should store the computed checksum.
|
||||
checksum. ``request.csum_start`` specifies byte offset of where the
|
||||
checksumming should start and ``request.csum_offset`` specifies byte offset
|
||||
where the device should store the computed checksum.
|
||||
- ``XDP_TXMD_FLAGS_LAUNCH_TIME``: requests the device to schedule the
|
||||
packet for transmission at a pre-determined time called launch time. The
|
||||
value of launch time is indicated by ``launch_time`` field of
|
||||
``union xsk_tx_metadata``.
|
||||
value of launch time is indicated by ``request.launch_time`` field of
|
||||
``struct xsk_tx_metadata``.
|
||||
|
||||
Besides the flags above, in order to trigger the offloads, the first
|
||||
packet's ``struct xdp_desc`` descriptor should set ``XDP_TX_METADATA``
|
||||
|
|
@ -63,9 +64,9 @@ only the first chunk should carry the metadata.
|
|||
Software TX Checksum
|
||||
====================
|
||||
|
||||
For development and testing purposes its possible to pass
|
||||
For development and testing purposes it's possible to pass
|
||||
``XDP_UMEM_TX_SW_CSUM`` flag to ``XDP_UMEM_REG`` UMEM registration call.
|
||||
In this case, when running in ``XDK_COPY`` mode, the TX checksum
|
||||
In this case, when running in ``XDP_COPY`` mode, the TX checksum
|
||||
is calculated on the CPU. Do not enable this option in production because
|
||||
it will negatively affect performance.
|
||||
|
||||
|
|
@ -118,7 +119,7 @@ schedule with a 1-second cycle time, with all Tx Queues open at all times.
|
|||
|
||||
The value of the launch time that is programmed in the Advanced Transmit
|
||||
Context Descriptor is a relative offset to the starting time of the Qbv
|
||||
transmission window of the queue. The Frst flag of the descriptor can be
|
||||
transmission window of the queue. The First flag of the descriptor can be
|
||||
set to schedule the packet for the next Qbv cycle. Therefore, the horizon
|
||||
of the launch time for i225 and i226 is the ending time of the next cycle
|
||||
of the Qbv transmission window of the queue. For example, when the Qbv
|
||||
|
|
@ -129,9 +130,10 @@ running.
|
|||
Querying Device Capabilities
|
||||
============================
|
||||
|
||||
Every devices exports its offloads capabilities via netlink netdev family.
|
||||
Refer to ``xsk-flags`` features bitmask in
|
||||
``Documentation/netlink/specs/netdev.yaml``.
|
||||
Every device exports its offload capabilities via the Netlink netdev family.
|
||||
Query the ``xsk-features`` attribute in
|
||||
``Documentation/netlink/specs/netdev.yaml``. Its bits are defined by the
|
||||
``xsk-flags`` enum.
|
||||
|
||||
- ``tx-timestamp``: device supports ``XDP_TXMD_FLAGS_TIMESTAMP``
|
||||
- ``tx-checksum``: device supports ``XDP_TXMD_FLAGS_CHECKSUM``
|
||||
|
|
|
|||
|
|
@ -89,4 +89,9 @@ dma-mapping API 去处理。
|
|||
使用某个还不存在的 netmem API，你可以自行添加并提交到 netdev@，也可以联系维护
|
||||
人员或者发送邮件至 almasrymina@google.com 寻求帮助。
|
||||
|
||||
2. 驱动程序应通过设置 netdev->netmem_tx = true 来表明自身支持 netmem 功能。
|
||||
2. 驱动程序应将 `netdev->netmem_tx` 设置为适当的模式：
|
||||
|
||||
- `NETMEM_TX_DMA`：适用于执行 DMA 的物理设备。
|
||||
|
||||
- `NETMEM_TX_NO_DMA`：适用于不执行 DMA 的虚拟或透传设备，但仍支持
|
||||
处理 netmem 支持的 skb。
|
||||
|
|
|
|||
|
|
@ -526,8 +526,8 @@ of the recvmsg() system call, *not* a Netlink header).
|
|||
|
||||
Upon truncation the remaining part of the message is discarded.
|
||||
|
||||
Netlink expects that the user buffer will be at least 8kB or a page
|
||||
size of the CPU architecture, whichever is bigger. Particular Netlink
|
||||
Netlink expects that the user buffer will be at most 8kB or a page
|
||||
size of the CPU architecture, whichever is smaller. Particular Netlink
|
||||
families may, however, require a larger buffer. 32kB buffer is recommended
|
||||
for most efficient handling of dumps (larger buffer fits more dumped
|
||||
objects and therefore fewer recvmsg() calls are needed).
|
||||
|
|
|
|||
34
MAINTAINERS
34
MAINTAINERS
|
|
@ -809,6 +809,14 @@ S: Maintained
|
|||
F: Documentation/i2c/busses/i2c-ali1563.rst
|
||||
F: drivers/i2c/busses/i2c-ali1563.c
|
||||
|
||||
ALIBABA ELASTIC ETHERNET ADAPTER DRIVER
|
||||
M: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
|
||||
M: Wen Gu <guwen@linux.alibaba.com>
|
||||
R: Philo Lu <lulie@linux.alibaba.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/ethernet/alibaba/eea
|
||||
|
||||
ALIBABA ELASTIC RDMA DRIVER
|
||||
M: Cheng Xu <chengyou@linux.alibaba.com>
|
||||
M: Kai Shen <kaishen@linux.alibaba.com>
|
||||
|
|
@ -1966,10 +1974,9 @@ F: drivers/hwmon/applesmc.c
|
|||
|
||||
APPLETALK NETWORK LAYER
|
||||
L: netdev@vger.kernel.org
|
||||
S: Odd fixes
|
||||
F: include/linux/atalk.h
|
||||
S: Obsolete
|
||||
F: include/uapi/linux/atalk.h
|
||||
F: net/appletalk/
|
||||
F: include/uapi/linux/if_ltalk.h
|
||||
|
||||
APPLIED MICRO (APM) X-GENE DEVICE TREE SUPPORT
|
||||
M: Khuong Dinh <khuong@os.amperecomputing.com>
|
||||
|
|
@ -4455,7 +4462,7 @@ W: https://www.open-mesh.org/
|
|||
Q: https://patchwork.open-mesh.org/project/batman/list/
|
||||
B: https://www.open-mesh.org/projects/batman-adv/issues
|
||||
C: ircs://irc.hackint.org/batadv
|
||||
T: git https://git.open-mesh.org/linux-merge.git
|
||||
T: git https://git.open-mesh.org/batadv.git
|
||||
F: Documentation/networking/batman-adv.rst
|
||||
F: include/uapi/linux/batadv_packet.h
|
||||
F: include/uapi/linux/batman_adv.h
|
||||
|
|
@ -15379,7 +15386,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
|
||||
F: Documentation/networking/mac80211-injection.rst
|
||||
F: Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
|
||||
F: drivers/net/wireless/virtual/mac80211_hwsim.[ch]
|
||||
F: drivers/net/wireless/virtual/mac80211_hwsim*.[ch]
|
||||
F: include/net/mac80211.h
|
||||
F: net/mac80211/
|
||||
|
||||
|
|
@ -18546,7 +18553,6 @@ F: include/linux/fddidevice.h
|
|||
F: include/linux/if_*
|
||||
F: include/linux/inetdevice.h
|
||||
F: include/linux/netdev*
|
||||
F: include/linux/platform_data/wiznet.h
|
||||
F: include/uapi/linux/cn_proc.h
|
||||
F: include/uapi/linux/ethtool_netlink*
|
||||
F: include/uapi/linux/if_*
|
||||
|
|
@ -18694,6 +18700,7 @@ F: net/
|
|||
F: samples/pktgen/
|
||||
F: tools/net/
|
||||
F: tools/testing/selftests/net/
|
||||
X: Documentation/networking/batman-adv.rst
|
||||
X: Documentation/networking/mac80211-injection.rst
|
||||
X: Documentation/networking/mac80211_hwsim/
|
||||
X: Documentation/networking/regulatory.rst
|
||||
|
|
@ -18704,6 +18711,7 @@ X: include/net/iw_handler.h
|
|||
X: include/net/mac80211.h
|
||||
X: include/net/wext.h
|
||||
X: net/9p/
|
||||
X: net/batman-adv/
|
||||
X: net/bluetooth/
|
||||
X: net/can/
|
||||
X: net/ceph/
|
||||
|
|
@ -18936,7 +18944,7 @@ F: drivers/net/net_failover.c
|
|||
F: include/net/net_failover.h
|
||||
|
||||
NFC SUBSYSTEM
|
||||
M: David Heidelberg <david+nfc@ixit.cz>
|
||||
M: David Heidelberg <david@ixit.cz>
|
||||
L: oe-linux-nfc@lists.linux.dev
|
||||
S: Maintained
|
||||
T: git https://codeberg.org/linux-nfc/linux.git
|
||||
|
|
@ -19361,6 +19369,17 @@ F: Documentation/devicetree/bindings/clock/*imx*
|
|||
F: drivers/clk/imx/
|
||||
F: include/dt-bindings/clock/*imx*
|
||||
|
||||
NXP NETC ETHERNET SWITCH DRIVER
|
||||
M: Wei Fang <wei.fang@nxp.com>
|
||||
R: Clark Wang <xiaoning.wang@nxp.com>
|
||||
L: imx@lists.linux.dev
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
|
||||
F: drivers/net/dsa/netc/
|
||||
F: include/linux/dsa/tag_netc.h
|
||||
F: net/dsa/tag_netc.c
|
||||
|
||||
NXP NETC TIMER PTP CLOCK DRIVER
|
||||
M: Wei Fang <wei.fang@nxp.com>
|
||||
M: Clark Wang <xiaoning.wang@nxp.com>
|
||||
|
|
@ -20197,6 +20216,7 @@ M: Christian Lamparter <chunkeey@googlemail.com>
|
|||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/p54
|
||||
F: Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
|
||||
F: drivers/net/wireless/intersil/
|
||||
|
||||
PACKET SOCKETS
|
||||
|
|
|
|||
|
|
@ -129,6 +129,8 @@ i2c2: i2c@48072000 {
|
|||
};
|
||||
|
||||
mcspi1: spi@48098000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "ti,omap2-mcspi";
|
||||
ti,hwmods = "mcspi1";
|
||||
reg = <0x48098000 0x100>;
|
||||
|
|
@ -140,6 +142,8 @@ mcspi1: spi@48098000 {
|
|||
};
|
||||
|
||||
mcspi2: spi@4809a000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "ti,omap2-mcspi";
|
||||
ti,hwmods = "mcspi2";
|
||||
reg = <0x4809a000 0x100>;
|
||||
|
|
|
|||
|
|
@ -109,3 +109,15 @@ partition@5 {
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
&mcspi2 {
|
||||
status = "okay";
|
||||
|
||||
wifi@0 {
|
||||
reg = <0>;
|
||||
compatible = "st,stlc4560";
|
||||
spi-max-frequency = <48000000>;
|
||||
interrupts-extended = <&gpio3 23 IRQ_TYPE_EDGE_RISING>;
|
||||
powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>; /* gpio 97 */
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -86,7 +86,6 @@ CONFIG_DEBUG_KERNEL=y
|
|||
CONFIG_CRYPTO=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_ECB=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_ARC4=m
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
# CONFIG_DEBUG_PREEMPT is not set
|
||||
|
|
|
|||
|
|
@ -118,7 +118,6 @@ CONFIG_CRYPTO_BLOWFISH=y
|
|||
CONFIG_CRYPTO_TEA=y
|
||||
CONFIG_CRYPTO_TWOFISH=y
|
||||
CONFIG_CRYPTO_ECB=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_HMAC=y
|
||||
CONFIG_CRYPTO_MD4=y
|
||||
CONFIG_CRYPTO_SHA1=y
|
||||
|
|
|
|||
|
|
@ -55,7 +55,6 @@ CONFIG_ATM=y
|
|||
CONFIG_ATM_BR2684=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_VLAN_8021Q=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DEV_APPLETALK=m
|
||||
CONFIG_IPDDP=m
|
||||
CONFIG_IPDDP_ENCAP=y
|
||||
|
|
|
|||
|
|
@ -286,7 +286,6 @@ CONFIG_NLS_ISO8859_1=y
|
|||
CONFIG_NLS_ISO8859_2=y
|
||||
CONFIG_NLS_UTF8=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
|
|
|||
|
|
@ -111,7 +111,6 @@ CONFIG_NLS_ISO8859_1=y
|
|||
CONFIG_NLS_ISO8859_2=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_ECB=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
|
|
|
|||
|
|
@ -185,7 +185,6 @@ CONFIG_NLS_ISO8859_1=y
|
|||
CONFIG_NLS_ISO8859_2=y
|
||||
CONFIG_NLS_UTF8=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
|
|
|||
|
|
@ -215,7 +215,6 @@ CONFIG_NLS_UTF8=y
|
|||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_SECURITY=y
|
||||
CONFIG_CRYPTO_ECB=y
|
||||
CONFIG_CRYPTO_PCBC=y
|
||||
CONFIG_CRYPTO_DEFLATE=y
|
||||
CONFIG_CRYPTO_LZO=y
|
||||
CONFIG_FONTS=y
|
||||
|
|
|
|||
|
|
@ -134,7 +134,6 @@ CONFIG_NLS_ISO8859_1=y
|
|||
CONFIG_NLS_ISO8859_2=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_ECB=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
|
||||
|
|
|
|||
|
|
@ -77,9 +77,6 @@ CONFIG_BT_HCIUART_BCSP=y
|
|||
CONFIG_BT_HCIBCM203X=m
|
||||
CONFIG_BT_HCIBPA10X=m
|
||||
CONFIG_BT_HCIBFUSB=m
|
||||
CONFIG_BT_HCIDTL1=m
|
||||
CONFIG_BT_HCIBT3C=m
|
||||
CONFIG_BT_HCIBLUECARD=m
|
||||
CONFIG_BT_HCIBTUART=m
|
||||
CONFIG_BT_HCIVHCI=m
|
||||
CONFIG_BT_MRVL=m
|
||||
|
|
@ -640,14 +637,12 @@ CONFIG_CRYPTO_BENCHMARK=m
|
|||
CONFIG_CRYPTO_BLOWFISH=m
|
||||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
CONFIG_CRYPTO_TEA=m
|
||||
CONFIG_CRYPTO_TWOFISH=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_SHA512=m
|
||||
CONFIG_CRYPTO_TGR192=m
|
||||
|
|
|
|||
|
|
@ -62,9 +62,6 @@ CONFIG_BT_HCIUART_BCSP=y
|
|||
CONFIG_BT_HCIBCM203X=m
|
||||
CONFIG_BT_HCIBPA10X=m
|
||||
CONFIG_BT_HCIBFUSB=m
|
||||
CONFIG_BT_HCIDTL1=m
|
||||
CONFIG_BT_HCIBT3C=m
|
||||
CONFIG_BT_HCIBLUECARD=m
|
||||
CONFIG_BT_HCIBTUART=m
|
||||
CONFIG_BT_HCIVHCI=m
|
||||
CONFIG_PCCARD=y
|
||||
|
|
|
|||
|
|
@ -181,7 +181,6 @@ CONFIG_FORTIFY_SOURCE=y
|
|||
CONFIG_CRYPTO_RSA=y
|
||||
CONFIG_CRYPTO_AES=y
|
||||
CONFIG_CRYPTO_CBC=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_CCM=y
|
||||
CONFIG_CRYPTO_GCM=y
|
||||
CONFIG_CRYPTO_CMAC=y
|
||||
|
|
|
|||
|
|
@ -20,7 +20,6 @@
|
|||
#include <linux/spi/spi.h>
|
||||
#include <linux/usb/musb.h>
|
||||
#include <linux/mmc/host.h>
|
||||
#include <linux/platform_data/spi-omap2-mcspi.h>
|
||||
#include <linux/platform_data/mmc-omap.h>
|
||||
#include <linux/mfd/menelaus.h>
|
||||
|
||||
|
|
@ -106,21 +105,6 @@ static void __init n8x0_usb_init(void) {}
|
|||
|
||||
#endif /*CONFIG_USB_MUSB_TUSB6010 */
|
||||
|
||||
|
||||
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
|
||||
.turbo_mode = 0,
|
||||
};
|
||||
|
||||
static struct spi_board_info n800_spi_board_info[] __initdata = {
|
||||
{
|
||||
.modalias = "p54spi",
|
||||
.bus_num = 2,
|
||||
.chip_select = 0,
|
||||
.max_speed_hz = 48000000,
|
||||
.controller_data = &p54spi_mcspi_config,
|
||||
},
|
||||
};
|
||||
|
||||
#if defined(CONFIG_MENELAUS) && IS_ENABLED(CONFIG_MMC_OMAP)
|
||||
|
||||
/*
|
||||
|
|
@ -524,7 +508,5 @@ omap_late_initcall(n8x0_late_initcall);
|
|||
void * __init n8x0_legacy_init(void)
|
||||
{
|
||||
board_check_revision();
|
||||
spi_register_board_info(n800_spi_board_info,
|
||||
ARRAY_SIZE(n800_spi_board_info));
|
||||
return &mmc1_data;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -383,9 +383,6 @@ CONFIG_BT_HCIUART_AG6XX=y
|
|||
CONFIG_BT_HCIBCM203X=m
|
||||
CONFIG_BT_HCIBPA10X=m
|
||||
CONFIG_BT_HCIBFUSB=m
|
||||
CONFIG_BT_HCIDTL1=m
|
||||
CONFIG_BT_HCIBT3C=m
|
||||
CONFIG_BT_HCIBLUECARD=m
|
||||
CONFIG_BT_HCIVHCI=m
|
||||
CONFIG_BT_MRVL=m
|
||||
CONFIG_BT_ATH3K=m
|
||||
|
|
|
|||
|
|
@ -399,9 +399,6 @@ CONFIG_BT_HCIUART_AG6XX=y
|
|||
CONFIG_BT_HCIBCM203X=m
|
||||
CONFIG_BT_HCIBPA10X=m
|
||||
CONFIG_BT_HCIBFUSB=m
|
||||
CONFIG_BT_HCIDTL1=m
|
||||
CONFIG_BT_HCIBT3C=m
|
||||
CONFIG_BT_HCIBLUECARD=m
|
||||
CONFIG_BT_HCIVHCI=m
|
||||
CONFIG_BT_MRVL=m
|
||||
CONFIG_BT_ATH3K=m
|
||||
|
|
|
|||
|
|
@ -236,7 +236,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -521,7 +520,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -533,7 +531,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -232,7 +232,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -476,7 +475,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -488,7 +486,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -239,7 +239,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -499,7 +498,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -511,7 +509,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -229,7 +229,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -468,7 +467,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -480,7 +478,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -231,7 +231,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -478,7 +477,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -490,7 +488,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -230,7 +230,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -497,7 +496,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -509,7 +507,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -250,7 +250,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -584,7 +583,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -596,7 +594,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -228,7 +228,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -468,7 +467,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -480,7 +478,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -229,7 +229,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -469,7 +468,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -481,7 +479,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -230,7 +230,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -487,7 +486,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -499,7 +497,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -225,7 +225,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -466,7 +465,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -478,7 +476,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
|
|
@ -226,7 +226,6 @@ CONFIG_RDS=m
|
|||
CONFIG_RDS_TCP=m
|
||||
CONFIG_L2TP=m
|
||||
CONFIG_BRIDGE=m
|
||||
CONFIG_ATALK=m
|
||||
CONFIG_DNS_RESOLVER=y
|
||||
CONFIG_BATMAN_ADV=m
|
||||
# CONFIG_BATMAN_ADV_BATMAN_V is not set
|
||||
|
|
@ -466,7 +465,6 @@ CONFIG_CRYPTO_CAMELLIA=m
|
|||
CONFIG_CRYPTO_CAST5=m
|
||||
CONFIG_CRYPTO_CAST6=m
|
||||
CONFIG_CRYPTO_DES=m
|
||||
CONFIG_CRYPTO_FCRYPT=m
|
||||
CONFIG_CRYPTO_KHAZAD=m
|
||||
CONFIG_CRYPTO_SEED=m
|
||||
CONFIG_CRYPTO_SERPENT=m
|
||||
|
|
@ -478,7 +476,6 @@ CONFIG_CRYPTO_ARC4=m
|
|||
CONFIG_CRYPTO_CTS=m
|
||||
CONFIG_CRYPTO_HCTR2=m
|
||||
CONFIG_CRYPTO_LRW=m
|
||||
CONFIG_CRYPTO_PCBC=m
|
||||
CONFIG_CRYPTO_XTS=m
|
||||
CONFIG_CRYPTO_AEGIS128=m
|
||||
CONFIG_CRYPTO_CMAC=m
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user