You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
Pull networking updates from David Miller:
"Highlights:
- Gustavo A. R. Silva keeps working on the implicit switch fallthru
changes.
- Support 802.11ax High-Efficiency wireless in cfg80211 et al, From
Luca Coelho.
- Re-enable ASPM in r8169, from Kai-Heng Feng.
- Add virtual XFRM interfaces, which avoids all of the limitations of
existing IPSEC tunnels. From Steffen Klassert.
- Convert GRO over to use a hash table, so that when we have many
flows active we don't traverse a long list during accumluation.
- Many new self tests for routing, TC, tunnels, etc. Too many
contributors to mention them all, but I'm really happy to keep
seeing this stuff.
- Hardware timestamping support for dpaa_eth/fsl-fman from Yangbo Lu.
- Lots of cleanups and fixes in L2TP code from Guillaume Nault.
- Add IPSEC offload support to netdevsim, from Shannon Nelson.
- Add support for slotting with non-uniform distribution to netem
packet scheduler, from Yousuk Seung.
- Add UDP GSO support to mlx5e, from Boris Pismenny.
- Support offloading of Team LAG in NFP, from John Hurley.
- Allow to configure TX queue selection based upon RX queue, from
Amritha Nambiar.
- Support ethtool ring size configuration in aquantia, from Anton
Mikaev.
- Support DSCP and flowlabel per-transport in SCTP, from Xin Long.
- Support list based batching and stack traversal of SKBs, this is
very exciting work. From Edward Cree.
- Busyloop optimizations in vhost_net, from Toshiaki Makita.
- Introduce the ETF qdisc, which allows time based transmissions. IGB
can offload this in hardware. From Vinicius Costa Gomes.
- Add parameter support to devlink, from Moshe Shemesh.
- Several multiplication and division optimizations for BPF JIT in
nfp driver, from Jiong Wang.
- Lots of prepatory work to make more of the packet scheduler layer
lockless, when possible, from Vlad Buslov.
- Add ACK filter and NAT awareness to sch_cake packet scheduler, from
Toke Høiland-Jørgensen.
- Support regions and region snapshots in devlink, from Alex Vesker.
- Allow to attach XDP programs to both HW and SW at the same time on
a given device, with initial support in nfp. From Jakub Kicinski.
- Add TLS RX offload and support in mlx5, from Ilya Lesokhin.
- Use PHYLIB in r8169 driver, from Heiner Kallweit.
- All sorts of changes to support Spectrum 2 in mlxsw driver, from
Ido Schimmel.
- PTP support in mv88e6xxx DSA driver, from Andrew Lunn.
- Make TCP_USER_TIMEOUT socket option more accurate, from Jon
Maxwell.
- Support for templates in packet scheduler classifier, from Jiri
Pirko.
- IPV6 support in RDS, from Ka-Cheong Poon.
- Native tproxy support in nf_tables, from Máté Eckl.
- Maintain IP fragment queue in an rbtree, but optimize properly for
in-order frags. From Peter Oskolkov.
- Improvde handling of ACKs on hole repairs, from Yuchung Cheng"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1996 commits)
bpf: test: fix spelling mistake "REUSEEPORT" -> "REUSEPORT"
hv/netvsc: Fix NULL dereference at single queue mode fallback
net: filter: mark expected switch fall-through
xen-netfront: fix warn message as irq device name has '/'
cxgb4: Add new T5 PCI device ids 0x50af and 0x50b0
net: dsa: mv88e6xxx: missing unlock on error path
rds: fix building with IPV6=m
inet/connection_sock: prefer _THIS_IP_ to current_text_addr
net: dsa: mv88e6xxx: bitwise vs logical bug
net: sock_diag: Fix spectre v1 gadget in __sock_diag_cmd()
ieee802154: hwsim: using right kind of iteration
net: hns3: Add vlan filter setting by ethtool command -K
net: hns3: Set tx ring' tc info when netdev is up
net: hns3: Remove tx ring BD len register in hns3_enet
net: hns3: Fix desc num set to default when setting channel
net: hns3: Fix for phy link issue when using marvell phy driver
net: hns3: Fix for information of phydev lost problem when down/up
net: hns3: Fix for command format parsing error in hclge_is_all_function_id_zero
net: hns3: Add support for serdes loopback selftest
bnxt_en: take coredump_record structure off stack
...
This commit is contained in:
Linus Torvalds
@@ -11,7 +11,7 @@ KernelVersion: v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org,
|
||||
Description: The rfkill class subsystem folder.
|
||||
Each registered rfkill driver is represented by an rfkillX
|
||||
subfolder (X being an integer > 0).
|
||||
subfolder (X being an integer >= 0).
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/name
|
||||
@@ -48,8 +48,8 @@ Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file was scheduled to be removed in 2014, but due to its
|
||||
large number of users it will be sticking around for a bit
|
||||
longer. Despite it being marked as stabe, the newer "hard" and
|
||||
"soft" interfaces should be preffered, since it is not possible
|
||||
longer. Despite it being marked as stable, the newer "hard" and
|
||||
"soft" interfaces should be preferred, since it is not possible
|
||||
to express the 'soft and hard block' state of the rfkill driver
|
||||
through this interface. There will likely be another attempt to
|
||||
remove it in the future.
|
||||
|
||||
@@ -42,6 +42,17 @@ Description:
|
||||
network device transmit queue. Possible vaules depend on the
|
||||
number of available CPU(s) in the system.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
|
||||
Date: June 2018
|
||||
KernelVersion: 4.18.0
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
Mask of the receive queue(s) currently enabled to participate
|
||||
into the Transmit Packet Steering packet processing flow for this
|
||||
network device transmit queue. Possible values depend on the
|
||||
number of available receive queue(s) in the network device.
|
||||
Default is disabled.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
|
||||
Date: November 2011
|
||||
KernelVersion: 3.3
|
||||
|
||||
@@ -106,9 +106,9 @@ into the bpf-next tree will make their way into net-next tree. net and
|
||||
net-next are both run by David S. Miller. From there, they will go
|
||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||
process of net and net-next being merged into the mainline tree, see
|
||||
the `netdev FAQ`_ under:
|
||||
the :ref:`netdev-FAQ`
|
||||
|
||||
|
||||
`Documentation/networking/netdev-FAQ.txt`_
|
||||
|
||||
Occasionally, to prevent merge conflicts, we might send pull requests
|
||||
to other trees (e.g. tracing) with a small subset of the patches, but
|
||||
@@ -125,8 +125,8 @@ request)::
|
||||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
A: The process is the very same as described in the `netdev FAQ`_, so
|
||||
please read up on it. The subject line must indicate whether the
|
||||
A: The process is the very same as described in the :ref:`netdev-FAQ`,
|
||||
so please read up on it. The subject line must indicate whether the
|
||||
patch is a fix or rather "next-like" content in order to let the
|
||||
maintainers know whether it is targeted at bpf or bpf-next.
|
||||
|
||||
@@ -184,7 +184,7 @@ ii) run extensive BPF test suite and
|
||||
Once the BPF pull request was accepted by David S. Miller, then
|
||||
the patches end up in net or net-next tree, respectively, and
|
||||
make their way from there further into mainline. Again, see the
|
||||
`netdev FAQ`_ for additional information e.g. on how often they are
|
||||
:ref:`netdev-FAQ` for additional information e.g. on how often they are
|
||||
merged to mainline.
|
||||
|
||||
Q: How long do I need to wait for feedback on my BPF patches?
|
||||
@@ -208,7 +208,7 @@ Q: Are patches applied to bpf-next when the merge window is open?
|
||||
-----------------------------------------------------------------
|
||||
A: For the time when the merge window is open, bpf-next will not be
|
||||
processed. This is roughly analogous to net-next patch processing,
|
||||
so feel free to read up on the `netdev FAQ`_ about further details.
|
||||
so feel free to read up on the :ref:`netdev-FAQ` about further details.
|
||||
|
||||
During those two weeks of merge window, we might ask you to resend
|
||||
your patch series once bpf-next is open again. Once Linus released
|
||||
@@ -372,7 +372,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
||||
netdev@vger.kernel.org
|
||||
|
||||
The process in general is the same as on netdev itself, see also the
|
||||
`netdev FAQ`_ document.
|
||||
:ref:`netdev-FAQ`.
|
||||
|
||||
Q: Do you also backport to kernels not currently maintained as stable?
|
||||
----------------------------------------------------------------------
|
||||
@@ -388,9 +388,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
|
||||
What should I do?
|
||||
|
||||
A: The same rules apply as with netdev patch submissions in general, see
|
||||
`netdev FAQ`_ under:
|
||||
|
||||
`Documentation/networking/netdev-FAQ.txt`_
|
||||
the :ref:`netdev-FAQ`.
|
||||
|
||||
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
||||
ask the BPF maintainers to queue the patches instead. This can be done
|
||||
@@ -630,8 +628,7 @@ when:
|
||||
.. Links
|
||||
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
|
||||
.. _MAINTAINERS: ../../MAINTAINERS
|
||||
.. _Documentation/networking/netdev-FAQ.txt: ../networking/netdev-FAQ.txt
|
||||
.. _netdev FAQ: ../networking/netdev-FAQ.txt
|
||||
.. _netdev-FAQ: ../networking/netdev-FAQ.rst
|
||||
.. _samples/bpf/: ../../samples/bpf/
|
||||
.. _selftests: ../../tools/testing/selftests/bpf/
|
||||
.. _Documentation/dev-tools/kselftest.rst:
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
=================
|
||||
BPF documentation
|
||||
BPF Documentation
|
||||
=================
|
||||
|
||||
This directory contains documentation for the BPF (Berkeley Packet
|
||||
@@ -22,14 +22,14 @@ Frequently asked questions (FAQ)
|
||||
|
||||
Two sets of Questions and Answers (Q&A) are maintained.
|
||||
|
||||
* QA for common questions about BPF see: bpf_design_QA_
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
* QA for developers interacting with BPF subsystem: bpf_devel_QA_
|
||||
bpf_design_QA
|
||||
bpf_devel_QA
|
||||
|
||||
|
||||
.. Links:
|
||||
.. _bpf_design_QA: bpf_design_QA.rst
|
||||
.. _bpf_devel_QA: bpf_devel_QA.rst
|
||||
.. _Documentation/networking/filter.txt: ../networking/filter.txt
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
@@ -13,14 +13,17 @@ MDIO multiplexer node:
|
||||
Every non-ethernet PHY requires a compatible so that it could be probed based
|
||||
on this compatible string.
|
||||
|
||||
Optional properties:
|
||||
- clocks: phandle of the core clock which drives the mdio block.
|
||||
|
||||
Additional information regarding generic multiplexer properties can be found
|
||||
at- Documentation/devicetree/bindings/net/mdio-mux.txt
|
||||
|
||||
|
||||
for example:
|
||||
mdio_mux_iproc: mdio-mux@6602023c {
|
||||
mdio_mux_iproc: mdio-mux@66020000 {
|
||||
compatible = "brcm,mdio-mux-iproc";
|
||||
reg = <0x6602023c 0x14>;
|
||||
reg = <0x66020000 0x250>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -2,19 +2,25 @@ Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
|
||||
---------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "xlnx,zynq-can-1.0" for Zynq CAN
|
||||
controllers and "xlnx,axi-can-1.00.a" for Axi CAN
|
||||
controllers.
|
||||
- reg : Physical base address and size of the Axi CAN/Zynq
|
||||
CANPS registers map.
|
||||
- compatible : Should be:
|
||||
- "xlnx,zynq-can-1.0" for Zynq CAN controllers
|
||||
- "xlnx,axi-can-1.00.a" for Axi CAN controllers
|
||||
- "xlnx,canfd-1.0" for CAN FD controllers
|
||||
- reg : Physical base address and size of the controller
|
||||
registers map.
|
||||
- interrupts : Property with a value describing the interrupt
|
||||
number.
|
||||
- clock-names : List of input clock names - "can_clk", "pclk"
|
||||
(For CANPS), "can_clk" , "s_axi_aclk"(For AXI CAN)
|
||||
- clock-names : List of input clock names
|
||||
- "can_clk", "pclk" (For CANPS),
|
||||
- "can_clk", "s_axi_aclk" (For AXI CAN and CAN FD).
|
||||
(See clock bindings for details).
|
||||
- clocks : Clock phandles (see clock bindings for details).
|
||||
- tx-fifo-depth : Can Tx fifo depth.
|
||||
- rx-fifo-depth : Can Rx fifo depth.
|
||||
- tx-fifo-depth : Can Tx fifo depth (Zynq, Axi CAN).
|
||||
- rx-fifo-depth : Can Rx fifo depth (Zynq, Axi CAN, CAN FD in
|
||||
sequential Rx mode).
|
||||
- tx-mailbox-count : Can Tx mailbox buffer count (CAN FD).
|
||||
- rx-mailbox-count : Can Rx mailbox buffer count (CAN FD in mailbox Rx
|
||||
mode).
|
||||
|
||||
|
||||
Example:
|
||||
@@ -41,3 +47,14 @@ For Axi CAN Dts file:
|
||||
tx-fifo-depth = <0x40>;
|
||||
rx-fifo-depth = <0x40>;
|
||||
};
|
||||
For CAN FD Dts file:
|
||||
canfd_0: canfd@40000000 {
|
||||
compatible = "xlnx,canfd-1.0";
|
||||
clocks = <&clkc 0>, <&clkc 1>;
|
||||
clock-names = "can_clk", "s_axi_aclk";
|
||||
reg = <0x40000000 0x2000>;
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <0 59 1>;
|
||||
tx-mailbox-count = <0x20>;
|
||||
rx-fifo-depth = <0x20>;
|
||||
};
|
||||
|
||||
@@ -24,6 +24,14 @@ Required properties:
|
||||
"brcm,bcm53018-srab"
|
||||
"brcm,bcm53019-srab" and the mandatory "brcm,bcm5301x-srab" string
|
||||
|
||||
For the BCM5831X/BCM1140x SoCs with an integrated switch, must be one of:
|
||||
"brcm,bcm11404-srab"
|
||||
"brcm,bcm11407-srab"
|
||||
"brcm,bcm11409-srab"
|
||||
"brcm,bcm58310-srab"
|
||||
"brcm,bcm58311-srab"
|
||||
"brcm,bcm58313-srab" and the mandatory "brcm,omega-srab" string
|
||||
|
||||
For the BCM585xx/586XX/88312 SoCs with an integrated switch, must be one of:
|
||||
"brcm,bcm58522-srab"
|
||||
"brcm,bcm58523-srab"
|
||||
|
||||
@@ -0,0 +1,153 @@
|
||||
Realtek SMI-based Switches
|
||||
==========================
|
||||
|
||||
The SMI "Simple Management Interface" is a two-wire protocol using
|
||||
bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
|
||||
not use the MDIO protocol. This binding defines how to specify the
|
||||
SMI-based Realtek devices.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be exactly one of:
|
||||
"realtek,rtl8366"
|
||||
"realtek,rtl8366rb" (4+1 ports)
|
||||
"realtek,rtl8366s" (4+1 ports)
|
||||
"realtek,rtl8367"
|
||||
"realtek,rtl8367b"
|
||||
"realtek,rtl8368s" (8 port)
|
||||
"realtek,rtl8369"
|
||||
"realtek,rtl8370" (8 port)
|
||||
|
||||
Required properties:
|
||||
- mdc-gpios: GPIO line for the MDC clock line.
|
||||
- mdio-gpios: GPIO line for the MDIO data line.
|
||||
- reset-gpios: GPIO line for the reset signal.
|
||||
|
||||
Optional properties:
|
||||
- realtek,disable-leds: if the LED drivers are not used in the
|
||||
hardware design this will disable them so they are not turned on
|
||||
and wasting power.
|
||||
|
||||
Required subnodes:
|
||||
|
||||
- interrupt-controller
|
||||
|
||||
This defines an interrupt controller with an IRQ line (typically
|
||||
a GPIO) that will demultiplex and handle the interrupt from the single
|
||||
interrupt line coming out of one of the SMI-based chips. It most
|
||||
importantly provides link up/down interrupts to the PHY blocks inside
|
||||
the ASIC.
|
||||
|
||||
Required properties of interrupt-controller:
|
||||
|
||||
- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
|
||||
- interrupt-controller: see interrupt-controller/interrupts.txt
|
||||
- #address-cells: should be <0>
|
||||
- #interrupt-cells: should be <1>
|
||||
|
||||
- mdio
|
||||
|
||||
This defines the internal MDIO bus of the SMI device, mostly for the
|
||||
purpose of being able to hook the interrupts to the right PHY and
|
||||
the right PHY to the corresponding port.
|
||||
|
||||
Required properties of mdio:
|
||||
|
||||
- compatible: should be set to "realtek,smi-mdio" for all SMI devices
|
||||
|
||||
See net/mdio.txt for additional MDIO bus properties.
|
||||
|
||||
See net/dsa/dsa.txt for a list of additional required and optional properties
|
||||
and subnodes of DSA switches.
|
||||
|
||||
Examples:
|
||||
|
||||
switch {
|
||||
compatible = "realtek,rtl8366rb";
|
||||
/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
|
||||
mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
|
||||
mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
|
||||
|
||||
switch_intc: interrupt-controller {
|
||||
/* GPIO 15 provides the interrupt */
|
||||
interrupt-parent = <&gpio0>;
|
||||
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#address-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
label = "lan0";
|
||||
phy-handle = <&phy0>;
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
label = "lan1";
|
||||
phy-handle = <&phy1>;
|
||||
};
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
label = "lan2";
|
||||
phy-handle = <&phy2>;
|
||||
};
|
||||
port@3 {
|
||||
reg = <3>;
|
||||
label = "lan3";
|
||||
phy-handle = <&phy3>;
|
||||
};
|
||||
port@4 {
|
||||
reg = <4>;
|
||||
label = "wan";
|
||||
phy-handle = <&phy4>;
|
||||
};
|
||||
port@5 {
|
||||
reg = <5>;
|
||||
label = "cpu";
|
||||
ethernet = <&gmac0>;
|
||||
phy-mode = "rgmii";
|
||||
fixed-link {
|
||||
speed = <1000>;
|
||||
full-duplex;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mdio {
|
||||
compatible = "realtek,smi-mdio", "dsa-mdio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
phy0: phy@0 {
|
||||
reg = <0>;
|
||||
interrupt-parent = <&switch_intc>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
phy1: phy@1 {
|
||||
reg = <1>;
|
||||
interrupt-parent = <&switch_intc>;
|
||||
interrupts = <1>;
|
||||
};
|
||||
phy2: phy@2 {
|
||||
reg = <2>;
|
||||
interrupt-parent = <&switch_intc>;
|
||||
interrupts = <2>;
|
||||
};
|
||||
phy3: phy@3 {
|
||||
reg = <3>;
|
||||
interrupt-parent = <&switch_intc>;
|
||||
interrupts = <3>;
|
||||
};
|
||||
phy4: phy@4 {
|
||||
reg = <4>;
|
||||
interrupt-parent = <&switch_intc>;
|
||||
interrupts = <12>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,81 @@
|
||||
Vitesse VSC73xx Switches
|
||||
========================
|
||||
|
||||
This defines device tree bindings for the Vitesse VSC73xx switch chips.
|
||||
The Vitesse company has been acquired by Microsemi and Microsemi in turn
|
||||
acquired by Microchip but retains this vendor branding.
|
||||
|
||||
The currently supported switch chips are:
|
||||
Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch
|
||||
Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch
|
||||
Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch
|
||||
Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch
|
||||
|
||||
The device tree node is an SPI device so it must reside inside a SPI bus
|
||||
device tree node, see spi/spi-bus.txt
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be exactly one of:
|
||||
"vitesse,vsc7385"
|
||||
"vitesse,vsc7388"
|
||||
"vitesse,vsc7395"
|
||||
"vitesse,vsc7398"
|
||||
- gpio-controller: indicates that this switch is also a GPIO controller,
|
||||
see gpio/gpio.txt
|
||||
- #gpio-cells: this must be set to <2> and indicates that we are a twocell
|
||||
GPIO controller, see gpio/gpio.txt
|
||||
|
||||
Optional properties:
|
||||
|
||||
- reset-gpios: a handle to a GPIO line that can issue reset of the chip.
|
||||
It should be tagged as active low.
|
||||
|
||||
Required subnodes:
|
||||
|
||||
See net/dsa/dsa.txt for a list of additional required and optional properties
|
||||
and subnodes of DSA switches.
|
||||
|
||||
Examples:
|
||||
|
||||
switch@0 {
|
||||
compatible = "vitesse,vsc7395";
|
||||
reg = <0>;
|
||||
/* Specified for 2.5 MHz or below */
|
||||
spi-max-frequency = <2500000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
label = "lan1";
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
label = "lan2";
|
||||
};
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
label = "lan3";
|
||||
};
|
||||
port@3 {
|
||||
reg = <3>;
|
||||
label = "lan4";
|
||||
};
|
||||
vsc: port@6 {
|
||||
reg = <6>;
|
||||
label = "cpu";
|
||||
ethernet = <&gmac1>;
|
||||
phy-mode = "rgmii";
|
||||
fixed-link {
|
||||
speed = <1000>;
|
||||
full-duplex;
|
||||
pause;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -356,30 +356,7 @@ ethernet@e0000 {
|
||||
============================================================================
|
||||
FMan IEEE 1588 Node
|
||||
|
||||
DESCRIPTION
|
||||
|
||||
The FMan interface to support IEEE 1588
|
||||
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: A standard property.
|
||||
Must include "fsl,fman-ptp-timer".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property.
|
||||
|
||||
EXAMPLE
|
||||
|
||||
ptp-timer@fe000 {
|
||||
compatible = "fsl,fman-ptp-timer";
|
||||
reg = <0xfe000 0x1000>;
|
||||
};
|
||||
Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
|
||||
|
||||
=============================================================================
|
||||
FMan MDIO Node
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
MediaTek SoC built-in Bluetooth Devices
|
||||
==================================
|
||||
|
||||
This device is a serial attached device to BTIF device and thus it must be a
|
||||
child node of the serial node with BTIF. The dt-bindings details for BTIF
|
||||
device can be known via Documentation/devicetree/bindings/serial/8250.txt.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be
|
||||
"mediatek,mt7622-bluetooth": for MT7622 SoC
|
||||
- clocks: Should be the clock specifiers corresponding to the entry in
|
||||
clock-names property.
|
||||
- clock-names: Should contain "ref" entries.
|
||||
- power-domains: Phandle to the power domain that the device is part of
|
||||
|
||||
Example:
|
||||
|
||||
btif: serial@1100c000 {
|
||||
compatible = "mediatek,mt7622-btif",
|
||||
"mediatek,mtk-btif";
|
||||
reg = <0 0x1100c000 0 0x1000>;
|
||||
interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_LOW>;
|
||||
clocks = <&pericfg CLK_PERI_BTIF_PD>;
|
||||
clock-names = "main";
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <4>;
|
||||
|
||||
bluetooth {
|
||||
compatible = "mediatek,mt7622-bluetooth";
|
||||
power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
|
||||
clocks = <&clk25m>;
|
||||
clock-names = "ref";
|
||||
};
|
||||
};
|
||||
@@ -10,12 +10,25 @@ device the slave device is attached to.
|
||||
Required properties:
|
||||
- compatible: should contain one of the following:
|
||||
* "qcom,qca6174-bt"
|
||||
* "qcom,wcn3990-bt"
|
||||
|
||||
Optional properties for compatible string qcom,qca6174-bt:
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: gpio specifier used to enable chip
|
||||
- clocks: clock provided to the controller (SUSCLK_32KHZ)
|
||||
|
||||
Example:
|
||||
Required properties for compatible string qcom,wcn3990-bt:
|
||||
|
||||
- vddio-supply: VDD_IO supply regulator handle.
|
||||
- vddxo-supply: VDD_XO supply regulator handle.
|
||||
- vddrf-supply: VDD_RF supply regulator handle.
|
||||
- vddch0-supply: VDD_CH0 supply regulator handle.
|
||||
|
||||
Optional properties for compatible string qcom,wcn3990-bt:
|
||||
|
||||
- max-speed: see Documentation/devicetree/bindings/serial/slave-device.txt
|
||||
|
||||
Examples:
|
||||
|
||||
serial@7570000 {
|
||||
label = "BT-UART";
|
||||
@@ -28,3 +41,15 @@ serial@7570000 {
|
||||
clocks = <&divclk4>;
|
||||
};
|
||||
};
|
||||
|
||||
serial@898000 {
|
||||
bluetooth {
|
||||
compatible = "qcom,wcn3990-bt";
|
||||
|
||||
vddio-supply = <&vreg_s4a_1p8>;
|
||||
vddxo-supply = <&vreg_l7a_1p8>;
|
||||
vddrf-supply = <&vreg_l17a_1p3>;
|
||||
vddch0-supply = <&vreg_l25a_3p3>;
|
||||
max-speed = <3200000>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -4,6 +4,7 @@ The device node has following properties.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "rockchip,<name>-gamc"
|
||||
"rockchip,px30-gmac": found on PX30 SoCs
|
||||
"rockchip,rk3128-gmac": found on RK312x SoCs
|
||||
"rockchip,rk3228-gmac": found on RK322x SoCs
|
||||
"rockchip,rk3288-gmac": found on RK3288 SoCs
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
|
||||
* STMicroelectronics 10/100/1000/2500/10000 Ethernet (GMAC/XGMAC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
|
||||
- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac" or
|
||||
"snps,dwxgmac-<ip_version>", "snps,dwxgmac".
|
||||
For backwards compatibility: "st,spear600-gmac" is also supported.
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupts: Should contain the STMMAC interrupts
|
||||
|
||||
@@ -2,7 +2,8 @@
|
||||
|
||||
General Properties:
|
||||
|
||||
- compatible Should be "fsl,etsec-ptp"
|
||||
- compatible Should be "fsl,etsec-ptp" for eTSEC
|
||||
Should be "fsl,fman-ptp-timer" for DPAA FMan
|
||||
- reg Offset and length of the register set for the device
|
||||
- interrupts There should be at least two interrupts. Some devices
|
||||
have as many as four PTP related interrupts.
|
||||
@@ -43,14 +44,22 @@ Clock Properties:
|
||||
value, which will be directly written in those bits, that is why,
|
||||
according to reference manual, the next clock sources can be used:
|
||||
|
||||
For eTSEC,
|
||||
<0> - external high precision timer reference clock (TSEC_TMR_CLK
|
||||
input is used for this purpose);
|
||||
<1> - eTSEC system clock;
|
||||
<2> - eTSEC1 transmit clock;
|
||||
<3> - RTC clock input.
|
||||
|
||||
When this attribute is not used, eTSEC system clock will serve as
|
||||
IEEE 1588 timer reference clock.
|
||||
For DPAA FMan,
|
||||
<0> - external high precision timer reference clock (TMR_1588_CLK)
|
||||
<1> - MAC system clock (1/2 FMan clock)
|
||||
<2> - reserved
|
||||
<3> - RTC clock oscillator
|
||||
|
||||
When this attribute is not used, the IEEE 1588 timer reference clock
|
||||
will use the eTSEC system clock (for Gianfar) or the MAC system
|
||||
clock (for DPAA).
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -397,6 +397,7 @@ v3 V3 Semiconductor
|
||||
variscite Variscite Ltd.
|
||||
via VIA Technologies, Inc.
|
||||
virtio Virtual I/O Device Specification, developed by the OASIS consortium
|
||||
vitesse Vitesse Semiconductor Corporation
|
||||
vivante Vivante Corporation
|
||||
vocore VoCore Studio
|
||||
voipac Voipac Technologies s.r.o.
|
||||
|
||||
@@ -92,6 +92,7 @@ needed).
|
||||
crypto/index
|
||||
filesystems/index
|
||||
vm/index
|
||||
bpf/index
|
||||
|
||||
Architecture-specific documentation
|
||||
-----------------------------------
|
||||
|
||||
@@ -18,8 +18,6 @@ README.ipw2200
|
||||
- README for the Intel PRO/Wireless 2915ABG and 2200BG driver.
|
||||
README.sb1000
|
||||
- info on General Instrument/NextLevel SURFboard1000 cable modem.
|
||||
alias.txt
|
||||
- info on using alias network devices.
|
||||
altera_tse.txt
|
||||
- Altera Triple-Speed Ethernet controller.
|
||||
arcnet-hardware.txt
|
||||
@@ -140,8 +138,6 @@ multiqueue.txt
|
||||
- HOWTO for multiqueue network device support.
|
||||
netconsole.txt
|
||||
- The network console module netconsole.ko: configuration and notes.
|
||||
netdev-FAQ.txt
|
||||
- FAQ describing how to submit net changes to netdev mailing list.
|
||||
netdev-features.txt
|
||||
- Network interface features API description.
|
||||
netdevices.txt
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===========
|
||||
IP-Aliasing
|
||||
===========
|
||||
|
||||
IP-aliases are an obsolete way to manage multiple IP-addresses/masks
|
||||
per interface. Newer tools such as iproute2 support multiple
|
||||
address/prefixes per interface, but aliases are still supported
|
||||
for backwards compatibility.
|
||||
|
||||
An alias is formed by adding a colon and a string when running ifconfig.
|
||||
This string is usually numeric, but this is not a must.
|
||||
|
||||
|
||||
Alias creation
|
||||
==============
|
||||
|
||||
Alias creation is done by 'magic' interface naming: eg. to create a
|
||||
200.1.1.1 alias for eth0 ...
|
||||
::
|
||||
|
||||
# ifconfig eth0:0 200.1.1.1 etc,etc....
|
||||
~~ -> request alias #0 creation (if not yet exists) for eth0
|
||||
|
||||
The corresponding route is also set up by this command. Please note:
|
||||
The route always points to the base interface.
|
||||
|
||||
|
||||
Alias deletion
|
||||
==============
|
||||
|
||||
The alias is removed by shutting the alias down::
|
||||
|
||||
# ifconfig eth0:0 down
|
||||
~~~~~~~~~~ -> will delete alias
|
||||
|
||||
|
||||
Alias (re-)configuring
|
||||
======================
|
||||
|
||||
Aliases are not real devices, but programs should be able to configure
|
||||
and refer to them as usual (ifconfig, route, etc).
|
||||
|
||||
|
||||
Relationship with main device
|
||||
=============================
|
||||
|
||||
If the base device is shut down the added aliases will be deleted too.
|
||||
@@ -1,40 +0,0 @@
|
||||
|
||||
IP-Aliasing:
|
||||
============
|
||||
|
||||
IP-aliases are an obsolete way to manage multiple IP-addresses/masks
|
||||
per interface. Newer tools such as iproute2 support multiple
|
||||
address/prefixes per interface, but aliases are still supported
|
||||
for backwards compatibility.
|
||||
|
||||
An alias is formed by adding a colon and a string when running ifconfig.
|
||||
This string is usually numeric, but this is not a must.
|
||||
|
||||
o Alias creation.
|
||||
Alias creation is done by 'magic' interface naming: eg. to create a
|
||||
200.1.1.1 alias for eth0 ...
|
||||
|
||||
# ifconfig eth0:0 200.1.1.1 etc,etc....
|
||||
~~ -> request alias #0 creation (if not yet exists) for eth0
|
||||
|
||||
The corresponding route is also set up by this command.
|
||||
Please note: The route always points to the base interface.
|
||||
|
||||
|
||||
o Alias deletion.
|
||||
The alias is removed by shutting the alias down:
|
||||
|
||||
# ifconfig eth0:0 down
|
||||
~~~~~~~~~~ -> will delete alias
|
||||
|
||||
|
||||
o Alias (re-)configuring
|
||||
|
||||
Aliases are not real devices, but programs should be able to configure and
|
||||
refer to them as usual (ifconfig, route, etc).
|
||||
|
||||
|
||||
o Relationship with main device
|
||||
|
||||
If the base device is shut down the added aliases will be deleted
|
||||
too.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user