hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'net-next/master'

This commit is contained in:
Stefan Schmidt 2018-08-06 09:04:48 +02:00
parent 811e299f46 981467033a
commit a304610803
1936 changed files with 80166 additions and 22327 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Documentation/admin-guide/kernel-parameters.txt
View File

@ -4846,3 +4846,8 @@
xirc2ps_cs= [NET,PCMCIA]
Format:
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
xhci-hcd.quirks [USB,KNL]
A hex value specifying bitmask with supplemental xhci
host controller quirks. Meaning of each bit can be
consulted in header drivers/usb/host/xhci.h.

21
Documentation/bpf/bpf_devel_QA.rst
View File

@ -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:

2
Documentation/device-mapper/writecache.txt
View File

@ -15,6 +15,8 @@ Constructor parameters:
size)
5. the number of optional parameters (the parameters with an argument
count as two)
start_sector n (default: 0)
offset from the start of cache device in 512-byte sectors
high_watermark n (default: 50)
start writeback when the number of used blocks reach this
watermark

2
Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
View File

@ -66,7 +66,7 @@ Required root node properties:
- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
Octa board.
- "insignal,origen" - for Exynos4210-based Insignal Origen board.
- "insignal,origen4412 - for Exynos4412-based Insignal Origen board.
- "insignal,origen4412" - for Exynos4412-based Insignal Origen board.
Optional nodes:

2
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
View File

@ -36,7 +36,7 @@ Optional nodes:
- port/ports: to describe a connection to an external encoder. The
binding follows Documentation/devicetree/bindings/graph.txt and
suppors a single port with a single endpoint.
supports a single port with a single endpoint.
- See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting

2
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
View File

@ -1,7 +1,7 @@
Nintendo Wii (Hollywood) GPIO controller
Required properties:
- compatible: "nintendo,hollywood-gpio
- compatible: "nintendo,hollywood-gpio"
- reg: Physical base address and length of the controller's registers.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells: Should be <2>. The first cell is the pin number and the

2
Documentation/devicetree/bindings/input/touchscreen/hideep.txt
View File

@ -32,7 +32,7 @@ i2c@00000000 {
reg = <0x6c>;
interrupt-parent = <&gpx1>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
vdd-supply = <&ldo15_reg>";
vdd-supply = <&ldo15_reg>;
vid-supply = <&ldo18_reg>;
reset-gpios = <&gpx1 5 0>;
touchscreen-size-x = <1080>;

2
Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.txt
View File

@ -15,7 +15,7 @@ Required properties:
include "nvidia,tegra30-ictlr".
- reg : Specifies base physical address and size of the registers.
Each controller must be described separately (Tegra20 has 4 of them,
whereas Tegra30 and later have 5"
whereas Tegra30 and later have 5).
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The value must be 3.

2
Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt
View File

@ -12,7 +12,7 @@ Required properties:
specifier, shall be 2
- interrupts: interrupts references to primary interrupt controller
(only needed for exti controller with multiple exti under
same parent interrupt: st,stm32-exti and st,stm32h7-exti")
same parent interrupt: st,stm32-exti and st,stm32h7-exti)
Example:

2
Documentation/devicetree/bindings/mips/brcm/soc.txt
View File

@ -152,7 +152,7 @@ Required properties:
- compatible : should contain one of:
"brcm,bcm7425-timers"
"brcm,bcm7429-timers"
"brcm,bcm7435-timers and
"brcm,bcm7435-timers" and
"brcm,brcmstb-timers"
- reg : the timers register range
- interrupts : the interrupt line for this timer block

7
Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
View File

@ -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>;

35
Documentation/devicetree/bindings/net/can/xilinx_can.txt
View File

@ -2,20 +2,26 @@ 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.
- interrupt-parent : Must be core interrupt controller
- 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:
@ -42,3 +48,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>;
};

153
Documentation/devicetree/bindings/net/dsa/realtek-smi.txt Normal file
View File

@ -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>;
};
};
};

2
Documentation/devicetree/bindings/net/fsl-fman.txt
View File

@ -238,7 +238,7 @@ PROPERTIES
Must include one of the following:
- "fsl,fman-dtsec" for dTSEC MAC
- "fsl,fman-xgec" for XGEC MAC
- "fsl,fman-memac for mEMAC MAC
- "fsl,fman-memac" for mEMAC MAC
- cell-index
Usage: required

29
Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
View File

@ -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>;
};
};

2
Documentation/devicetree/bindings/power/power_domain.txt
View File

@ -133,7 +133,7 @@ located inside a PM domain with index 0 of a power controller represented by a
node with the label "power".
In the second example the consumer device are partitioned across two PM domains,
the first with index 0 and the second with index 1, of a power controller that
is represented by a node with the label "power.
is represented by a node with the label "power".
Optional properties:
- required-opps: This contains phandle to an OPP node in another device's OPP

2
Documentation/devicetree/bindings/regulator/tps65090.txt
View File

@ -16,7 +16,7 @@ Required properties:
Optional properties:
- ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3.
If DCDCs are externally controlled then this property should be there.
- "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
- dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3.
If DCDCs are externally controlled and if it is from GPIO then GPIO
number should be provided. If it is externally controlled and no GPIO
entry then driver will just configure this rails as external control

2
Documentation/devicetree/bindings/reset/st,sti-softreset.txt
View File

@ -15,7 +15,7 @@ Please refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
- compatible: Should be st,stih407-softreset";
- compatible: Should be "st,stih407-softreset";
- #reset-cells: 1, see below
example:

2
Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
View File

@ -39,7 +39,7 @@ Required properties:
Optional property:
- clock-frequency: Desired I2C bus clock frequency in Hz.
When missing default to 400000Hz.
When missing default to 100000Hz.
Child nodes should conform to I2C bus binding as described in i2c.txt.

2
Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
View File

@ -30,7 +30,7 @@ Required properties:
Board connectors:
* Headset Mic
* Secondary Mic",
* Secondary Mic
* DMIC
* Ext Spk

2
Documentation/devicetree/bindings/sound/qcom,apq8096.txt
View File

@ -35,7 +35,7 @@ This binding describes the APQ8096 sound card, which uses qdsp for audio.
"Digital Mic3"
Audio pins and MicBias on WCD9335 Codec:
"MIC_BIAS1
"MIC_BIAS1"
"MIC_BIAS2"
"MIC_BIAS3"
"MIC_BIAS4"

3
Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
View File

@ -16,7 +16,8 @@ A child node must exist to represent the core DWC3 IP block. The name of
the node is not important. The content of the node is defined in dwc3.txt.
Phy documentation is provided in the following places:
Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt - USB2.0 PHY
Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt - Type-C PHY
Example device nodes:

2
Documentation/devicetree/bindings/w1/w1-gpio.txt
View File

@ -15,7 +15,7 @@ Optional properties:
Examples:
onewire@0 {
onewire {
compatible = "w1-gpio";
gpios = <&gpio 126 0>, <&gpio 105 0>;
};

17
Documentation/kbuild/kbuild.txt
View File

@ -50,6 +50,11 @@ LDFLAGS_MODULE
--------------------------------------------------
Additional options used for $(LD) when linking modules.
KBUILD_KCONFIG
--------------------------------------------------
Set the top-level Kconfig file to the value of this environment
variable. The default name is "Kconfig".
KBUILD_VERBOSE
--------------------------------------------------
Set the kbuild verbosity. Can be assigned same values as "V=...".
@ -88,7 +93,8 @@ In most cases the name of the architecture is the same as the
directory name found in the arch/ directory.
But some architectures such as x86 and sparc have aliases.
x86: i386 for 32 bit, x86_64 for 64 bit
sparc: sparc for 32 bit, sparc64 for 64 bit
sh: sh for 32 bit, sh64 for 64 bit
sparc: sparc32 for 32 bit, sparc64 for 64 bit
CROSS_COMPILE
--------------------------------------------------
@ -148,15 +154,6 @@ stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
the default option --strip-debug will be used. Otherwise,
INSTALL_MOD_STRIP value will be used as the options to the strip command.
INSTALL_FW_PATH
--------------------------------------------------
INSTALL_FW_PATH specifies where to install the firmware blobs.
The default value is:
$(INSTALL_MOD_PATH)/lib/firmware
The value can be overridden in which case the default value is ignored.
INSTALL_HDR_PATH
--------------------------------------------------
INSTALL_HDR_PATH specifies where to install user space headers when

51
Documentation/kbuild/kconfig.txt
View File

@ -2,9 +2,9 @@ This file contains some assistance for using "make *config".
Use "make help" to list all of the possible configuration targets.
The xconfig ('qconf') and menuconfig ('mconf') programs also
have embedded help text. Be sure to check it for navigation,
search, and other general help text.
The xconfig ('qconf'), menuconfig ('mconf'), and nconfig ('nconf')
programs also have embedded help text. Be sure to check that for
navigation, search, and other general help text.
======================================================================
General
@ -17,13 +17,16 @@ this happens, using a previously working .config file and running
for you, so you may find that you need to see what NEW kernel
symbols have been introduced.
To see a list of new config symbols when using "make oldconfig", use
To see a list of new config symbols, use
cp user/some/old.config .config
make listnewconfig
and the config program will list any new symbols, one per line.
Alternatively, you can use the brute force method:
make oldconfig
scripts/diffconfig .config.old .config | less
______________________________________________________________________
@ -160,7 +163,7 @@ Searching in menuconfig:
This lists all config symbols that contain "hotplug",
e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
For search help, enter / followed TAB-TAB-TAB (to highlight
For search help, enter / followed by TAB-TAB (to highlight
<Help>) and Enter. This will tell you that you can also use
regular expressions (regexes) in the search string, so if you
are not interested in MEMORY_HOTPLUG, you could try
@ -202,6 +205,39 @@ Example:
make MENUCONFIG_MODE=single_menu menuconfig
======================================================================
nconfig
--------------------------------------------------
nconfig is an alternate text-based configurator. It lists function
keys across the bottom of the terminal (window) that execute commands.
You can also just use the corresponding numeric key to execute the
commands unless you are in a data entry window. E.g., instead of F6
for Save, you can just press 6.
Use F1 for Global help or F3 for the Short help menu.
Searching in nconfig:
You can search either in the menu entry "prompt" strings
or in the configuration symbols.
Use / to begin a search through the menu entries. This does
not support regular expressions. Use <Down> or <Up> for
Next hit and Previous hit, respectively. Use <Esc> to
terminate the search mode.
F8 (SymSearch) searches the configuration symbols for the
given string or regular expression (regex).
NCONFIG_MODE
--------------------------------------------------
This mode shows all sub-menus in one large tree.
Example:
make NCONFIG_MODE=single_menu nconfig
======================================================================
xconfig
--------------------------------------------------
@ -230,8 +266,7 @@ gconfig
Searching in gconfig:
None (gconfig isn't maintained as well as xconfig or menuconfig);
however, gconfig does have a few more viewing choices than
xconfig does.
There is no search command in gconfig. However, gconfig does
have several different viewing choices, modes, and options.
###

4
Documentation/networking/00-INDEX
View File

@ -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

49
Documentation/networking/alias.rst Normal file
View File

@ -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.

40
Documentation/networking/alias.txt
View File

@ -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.

2
Documentation/networking/bonding.txt
View File

@ -1490,7 +1490,7 @@ To remove an ARP target:
To configure the interval between learning packet transmits:
# echo 12 > /sys/class/net/bond0/bonding/lp_interval
NOTE: the lp_inteval is the number of seconds between instances where
NOTE: the lp_interval is the number of seconds between instances where
the bonding driver sends learning packets to each slaves peer switch. The
default interval is 1 second.

6
Documentation/networking/bridge.txt → Documentation/networking/bridge.rst
View File

@ -1,3 +1,9 @@
.. SPDX-License-Identifier: GPL-2.0
=================
Ethernet Bridging
=================
In order to use the Ethernet bridging functionality, you'll need the
userspace tools.

332
Documentation/networking/can_ucan_protocol.rst Normal file
View File

@ -0,0 +1,332 @@
=================
The UCAN Protocol
=================
UCAN is the protocol used by the microcontroller-based USB-CAN
adapter that is integrated on System-on-Modules from Theobroma Systems
and that is also available as a standalone USB stick.
The UCAN protocol has been designed to be hardware-independent.
It is modeled closely after how Linux represents CAN devices
internally. All multi-byte integers are encoded as Little Endian.
All structures mentioned in this document are defined in
``drivers/net/can/usb/ucan.c``.
USB Endpoints
=============
UCAN devices use three USB endpoints:
CONTROL endpoint
The driver sends device management commands on this endpoint
IN endpoint
The device sends CAN data frames and CAN error frames
OUT endpoint
The driver sends CAN data frames on the out endpoint
CONTROL Messages
================
UCAN devices are configured using vendor requests on the control pipe.
To support multiple CAN interfaces in a single USB device all
configuration commands target the corresponding interface in the USB
descriptor.
The driver uses ``ucan_ctrl_command_in/out`` and
``ucan_device_request_in`` to deliver commands to the device.
Setup Packet
------------
================= =====================================================
``bmRequestType`` Direction | Vendor | (Interface or Device)
``bRequest`` Command Number
``wValue`` Subcommand Number (16 Bit) or 0 if not used
``wIndex`` USB Interface Index (0 for device commands)
``wLength`` * Host to Device - Number of bytes to transmit
* Device to Host - Maximum Number of bytes to
receive. If the device send less. Commom ZLP
semantics are used.
================= =====================================================
Error Handling
--------------
The device indicates failed control commands by stalling the
pipe.
Device Commands
---------------
UCAN_DEVICE_GET_FW_STRING
~~~~~~~~~~~~~~~~~~~~~~~~~
*Dev2Host; optional*
Request the device firmware string.
Interface Commands
------------------
UCAN_COMMAND_START
~~~~~~~~~~~~~~~~~~
*Host2Dev; mandatory*
Bring the CAN interface up.
Payload Format
``ucan_ctl_payload_t.cmd_start``
==== ============================
mode or mask of ``UCAN_MODE_*``
==== ============================
UCAN_COMMAND_STOP
~~~~~~~~~~~~~~~~~~
*Host2Dev; mandatory*
Stop the CAN interface
Payload Format
*empty*
UCAN_COMMAND_RESET
~~~~~~~~~~~~~~~~~~
*Host2Dev; mandatory*
Reset the CAN controller (including error counters)
Payload Format
*empty*
UCAN_COMMAND_GET
~~~~~~~~~~~~~~~~
*Host2Dev; mandatory*
Get Information from the Device
Subcommands
^^^^^^^^^^^
UCAN_COMMAND_GET_INFO
Request the device information structure ``ucan_ctl_payload_t.device_info``.
See the ``device_info`` field for details, and
``uapi/linux/can/netlink.h`` for an explanation of the
``can_bittiming fields``.
Payload Format
``ucan_ctl_payload_t.device_info``
UCAN_COMMAND_GET_PROTOCOL_VERSION
Request the device protocol version
``ucan_ctl_payload_t.protocol_version``. The current protocol version is 3.
Payload Format
``ucan_ctl_payload_t.protocol_version``
.. note:: Devices that do not implement this command use the old
protocol version 1
UCAN_COMMAND_SET_BITTIMING
~~~~~~~~~~~~~~~~~~~~~~~~~~
*Host2Dev; mandatory*
Setup bittiming by sending the the structure
``ucan_ctl_payload_t.cmd_set_bittiming`` (see ``struct bittiming`` for
details)
Payload Format
``ucan_ctl_payload_t.cmd_set_bittiming``.
UCAN_SLEEP/WAKE
~~~~~~~~~~~~~~~
*Host2Dev; optional*
Configure sleep and wake modes. Not yet supported by the driver.
UCAN_FILTER
~~~~~~~~~~~
*Host2Dev; optional*
Setup hardware CAN filters. Not yet supported by the driver.
Allowed interface commands
--------------------------
================== =================== ==================
Legal Device State Command New Device State
================== =================== ==================
stopped SET_BITTIMING stopped
stopped START started
started STOP or RESET stopped
stopped STOP or RESET stopped
started RESTART started
any GET *no change*
================== =================== ==================
IN Message Format
=================
A data packet on the USB IN endpoint contains one or more
``ucan_message_in`` values. If multiple messages are batched in a USB
data packet, the ``len`` field can be used to jump to the next
``ucan_message_in`` value (take care to sanity-check the ``len`` value
against the actual data size).
.. _can_ucan_in_message_len:
``len`` field
-------------
Each ``ucan_message_in`` must be aligned to a 4-byte boundary (relative
to the start of the start of the data buffer). That means that there
may be padding bytes between multiple ``ucan_message_in`` values:
.. code::
+----------------------------+ < 0
| |
| struct ucan_message_in |
| |
+----------------------------+ < len
[padding]
+----------------------------+ < round_up(len, 4)
| |
| struct ucan_message_in |
| |
+----------------------------+
[...]
``type`` field
--------------
The ``type`` field specifies the type of the message.
UCAN_IN_RX
~~~~~~~~~~
``subtype``
zero
Data received from the CAN bus (ID + payload).
UCAN_IN_TX_COMPLETE
~~~~~~~~~~~~~~~~~~~
``subtype``
zero
The CAN device has sent a message to the CAN bus. It answers with a
list of of tuples <echo-ids, flags>.
The echo-id identifies the frame from (echos the id from a previous
UCAN_OUT_TX message). The flag indicates the result of the
transmission. Whereas a set Bit 0 indicates success. All other bits
are reserved and set to zero.
Flow Control
------------
When receiving CAN messages there is no flow control on the USB
buffer. The driver has to handle inbound message quickly enough to
avoid drops. I case the device buffer overflow the condition is
reported by sending corresponding error frames (see
:ref:`can_ucan_error_handling`)
OUT Message Format
==================
A data packet on the USB OUT endpoint contains one or more ``struct
ucan_message_out`` values. If multiple messages are batched into one
data packet, the device uses the ``len`` field to jump to the next
ucan_message_out value. Each ucan_message_out must be aligned to 4
bytes (relative to the start of the data buffer). The mechanism is
same as described in :ref:`can_ucan_in_message_len`.
.. code::
+----------------------------+ < 0
| |
| struct ucan_message_out |
| |
+----------------------------+ < len
[padding]
+----------------------------+ < round_up(len, 4)
| |
| struct ucan_message_out |
| |
+----------------------------+
[...]
``type`` field
--------------
In protocol version 3 only ``UCAN_OUT_TX`` is defined, others are used
only by legacy devices (protocol version 1).
UCAN_OUT_TX
~~~~~~~~~~~
``subtype``
echo id to be replied within a CAN_IN_TX_COMPLETE message
Transmit a CAN frame. (parameters: ``id``, ``data``)
Flow Control
------------
When the device outbound buffers are full it starts sending *NAKs* on
the *OUT* pipe until more buffers are available. The driver stops the
queue when a certain threshold of out packets are incomplete.
.. _can_ucan_error_handling:
CAN Error Handling
==================
If error reporting is turned on the device encodes errors into CAN
error frames (see ``uapi/linux/can/error.h``) and sends it using the
IN endpoint. The driver updates its error statistics and forwards
it.
Although UCAN devices can suppress error frames completely, in Linux
the driver is always interested. Hence, the device is always started with
the ``UCAN_MODE_BERR_REPORT`` set. Filtering those messages for the
user space is done by the driver.
Bus OFF
-------
- The device does not recover from bus of automatically.
- Bus OFF is indicated by an error frame (see ``uapi/linux/can/error.h``)
- Bus OFF recovery is started by ``UCAN_COMMAND_RESTART``
- Once Bus OFF recover is completed the device sends an error frame
indicating that it is on ERROR-ACTIVE state.
- During Bus OFF no frames are sent by the device.
- During Bus OFF transmission requests from the host are completed
immediately with the success bit left unset.
Example Conversation
====================
#) Device is connected to USB
#) Host sends command ``UCAN_COMMAND_RESET``, subcmd 0
#) Host sends command ``UCAN_COMMAND_GET``, subcmd ``UCAN_COMMAND_GET_INFO``
#) Device sends ``UCAN_IN_DEVICE_INFO``
#) Host sends command ``UCAN_OUT_SET_BITTIMING``
#) Host sends command ``UCAN_COMMAND_START``, subcmd 0, mode ``UCAN_MODE_BERR_REPORT``

1
Documentation/networking/dpaa2/overview.rst
View File

@ -1,5 +1,6 @@
.. include:: <isonum.txt>
=========================================================
DPAA2 (Data Path Acceleration Architecture Gen2) Overview
=========================================================

27
Documentation/networking/e100.rst
View File

@ -47,41 +47,45 @@ Driver Configuration Parameters
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
Rx Descriptors: Number of receive descriptors. A receive descriptor is a data
Rx Descriptors:
Number of receive descriptors. A receive descriptor is a data
structure that describes a receive buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to write
data from the controller to host memory. In the 3.x.x driver the valid range
for this parameter is 64-256. The default value is 256. This parameter can be
changed using the command::
ethtool -G eth? rx n
ethtool -G eth? rx n
Where n is the number of desired Rx descriptors.
Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a data
Tx Descriptors:
Number of transmit descriptors. A transmit descriptor is a data
structure that describes a transmit buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to read
data from the host memory to the controller. In the 3.x.x driver the valid
range for this parameter is 64-256. The default value is 128. This parameter
can be changed using the command::
ethtool -G eth? tx n
ethtool -G eth? tx n
Where n is the number of desired Tx descriptors.
Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
Speed/Duplex:
The driver auto-negotiates the link speed and duplex settings by
default. The ethtool utility can be used as follows to force speed/duplex.::
ethtool -s eth? autoneg off speed {10|100} duplex {full|half}
ethtool -s eth? autoneg off speed {10|100} duplex {full|half}
NOTE: setting the speed/duplex to incorrect values will cause the link to
fail.
Event Log Message Level: The driver uses the message level flag to log events
Event Log Message Level:
The driver uses the message level flag to log events
to syslog. The message level can be set at driver load time. It can also be
set using the command::
ethtool -s eth? msglvl n
ethtool -s eth? msglvl n
Additional Configurations
@ -92,7 +96,7 @@ Configuring the Driver on Different Distributions
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
adding an alias line to /etc/modprobe.d/*.conf as well as editing other
adding an alias line to `/etc/modprobe.d/*.conf` as well as editing other
system startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn
the proper way to configure a network device for your system, refer to
@ -160,7 +164,10 @@ This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP
filtering by
(1) entering:: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(1) entering::
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5), or
(2) installing the interfaces in separate broadcast domains (either

187
Documentation/networking/e1000.rst
View File

@ -34,7 +34,8 @@ Command Line Parameters
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
NOTES: For more information about the AutoNeg, Duplex, and Speed
NOTES:
For more information about the AutoNeg, Duplex, and Speed
parameters, see the "Speed and Duplex Configuration" section in
this document.
@ -45,22 +46,27 @@ NOTES: For more information about the AutoNeg, Duplex, and Speed
AutoNeg
-------
(Supported only on adapters with copper connections)
Valid Range: 0x01-0x0F, 0x20-0x2F
Default Value: 0x2F
:Valid Range: 0x01-0x0F, 0x20-0x2F
:Default Value: 0x2F
This parameter is a bit-mask that specifies the speed and duplex settings
advertised by the adapter. When this parameter is used, the Speed and
Duplex parameters must not be specified.
NOTE: Refer to the Speed and Duplex section of this readme for more
NOTE:
Refer to the Speed and Duplex section of this readme for more
information on the AutoNeg parameter.
Duplex
------
(Supported only on adapters with copper connections)
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
Default Value: 0
:Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
:Default Value: 0
This defines the direction in which data is allowed to flow. Can be
either one or two-directional. If both Duplex and the link partner are
@ -70,18 +76,22 @@ duplex.
FlowControl
-----------
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
Default Value: Reads flow control settings from the EEPROM
:Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
:Default Value: Reads flow control settings from the EEPROM
This parameter controls the automatic generation(Tx) and response(Rx)
to Ethernet PAUSE frames.
InterruptThrottleRate
---------------------
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
Valid Range: 0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
4=simplified balancing)
Default Value: 3
:Valid Range:
0,1,3,4,100-100000 (0=off, 1=dynamic, 3=dynamic conservative,
4=simplified balancing)
:Default Value: 3
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to the
@ -135,13 +145,15 @@ Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic.
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
NOTE:
InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive
and/or transmit absolute delays does not force the controller to
generate more interrupts than what the Interrupt Throttle Rate
allows.
CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection
CAUTION:
If you are using the Intel(R) PRO/1000 CT Network Connection
(controller 82547), setting InterruptThrottleRate to a value
greater than 75,000, may hang (stop transmitting) adapters
under certain network conditions. If this occurs a NETDEV
@ -151,7 +163,8 @@ CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection
hang, ensure that InterruptThrottleRate is set no greater
than 75,000 and is not set to 0.
NOTE: When e1000 is loaded with default settings and multiple adapters
NOTE:
When e1000 is loaded with default settings and multiple adapters
are in use simultaneously, the CPU utilization may increase non-
linearly. In order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
@ -168,9 +181,11 @@ NOTE: When e1000 is loaded with default settings and multiple adapters
RxDescriptors
-------------
Valid Range: 48-256 for 82542 and 82543-based adapters
48-4096 for all other supported adapters
Default Value: 256
:Valid Range:
- 48-256 for 82542 and 82543-based adapters
- 48-4096 for all other supported adapters
:Default Value: 256
This value specifies the number of receive buffer descriptors allocated
by the driver. Increasing this value allows the driver to buffer more
@ -180,15 +195,17 @@ Each descriptor is 16 bytes. A receive buffer is also allocated for each
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
on the MTU setting. The maximum MTU size is 16110.
NOTE: MTU designates the frame size. It only needs to be set for Jumbo
NOTE:
MTU designates the frame size. It only needs to be set for Jumbo
Frames. Depending on the available system resources, the request
for a higher number of receive descriptors may be denied. In this
case, use a lower number.
RxIntDelay
----------
Valid Range: 0-65535 (0=off)
Default Value: 0
:Valid Range: 0-65535 (0=off)
:Default Value: 0
This value delays the generation of receive interrupts in units of 1.024
microseconds. Receive interrupt reduction can improve CPU efficiency if
@ -198,7 +215,8 @@ of TCP traffic. If the system is reporting dropped receives, this value
may be set too high, causing the driver to run out of available receive
descriptors.
CAUTION: When setting RxIntDelay to a value other than 0, adapters may
CAUTION:
When setting RxIntDelay to a value other than 0, adapters may
hang (stop transmitting) under certain network conditions. If
this occurs a NETDEV WATCHDOG message is logged in the system
event log. In addition, the controller is automatically reset,
@ -207,9 +225,11 @@ CAUTION: When setting RxIntDelay to a value other than 0, adapters may
RxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
Valid Range: 0-65535 (0=off)
Default Value: 128
:Valid Range: 0-65535 (0=off)
:Default Value: 128
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
@ -220,9 +240,11 @@ conditions.
Speed
-----
(This parameter is supported only on adapters with copper connections.)
Valid Settings: 0, 10, 100, 1000
Default Value: 0 (auto-negotiate at all supported speeds)
:Valid Settings: 0, 10, 100, 1000
:Default Value: 0 (auto-negotiate at all supported speeds)
Speed forces the line speed to the specified value in megabits per second
(Mbps). If this parameter is not specified or is set to 0 and the link
@ -231,22 +253,26 @@ speed. Duplex should also be set when Speed is set to either 10 or 100.
TxDescriptors
-------------
Valid Range: 48-256 for 82542 and 82543-based adapters
48-4096 for all other supported adapters
Default Value: 256
:Valid Range:
- 48-256 for 82542 and 82543-based adapters
- 48-4096 for all other supported adapters
:Default Value: 256
This value is the number of transmit descriptors allocated by the driver.
Increasing this value allows the driver to queue more transmits. Each
descriptor is 16 bytes.
NOTE: Depending on the available system resources, the request for a
NOTE:
Depending on the available system resources, the request for a
higher number of transmit descriptors may be denied. In this case,
use a lower number.
TxIntDelay
----------
Valid Range: 0-65535 (0=off)
Default Value: 8
:Valid Range: 0-65535 (0=off)
:Default Value: 8
This value delays the generation of transmit interrupts in units of
1.024 microseconds. Transmit interrupt reduction can improve CPU
@ -256,9 +282,11 @@ causing the driver to run out of available transmit descriptors.
TxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
Valid Range: 0-65535 (0=off)
Default Value: 32
:Valid Range: 0-65535 (0=off)
:Default Value: 32
This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
@ -269,18 +297,21 @@ network conditions.
XsumRX
------
(This parameter is NOT supported on the 82542-based adapter.)
Valid Range: 0-1
Default Value: 1
:Valid Range: 0-1
:Default Value: 1
A value of '1' indicates that the driver should enable IP checksum
offload for received packets (both UDP and TCP) to the adapter hardware.
Copybreak
---------
Valid Range: 0-xxxxxxx (0=off)
Default Value: 256
Usage: modprobe e1000.ko copybreak=128
:Valid Range: 0-xxxxxxx (0=off)
:Default Value: 256
:Usage: modprobe e1000.ko copybreak=128
Driver copies all packets below or equaling this size to a fresh RX
buffer before handing it up the stack.
@ -292,8 +323,9 @@ it is also available during runtime at
SmartPowerDownEnable
--------------------
Valid Range: 0-1
Default Value: 0 (disabled)
:Valid Range: 0-1
:Default Value: 0 (disabled)
Allows PHY to turn off in lower power states. The user can turn off
this parameter in supported chipsets.
@ -309,14 +341,14 @@ fiber interface board only links at 1000 Mbps full-duplex.
For copper-based boards, the keywords interact as follows:
The default operation is auto-negotiate. The board advertises all
- The default operation is auto-negotiate. The board advertises all
supported speed and duplex combinations, and it links at the highest
common speed and duplex mode IF the link partner is set to auto-negotiate.
If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
- If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
is advertised (The 1000BaseT spec requires auto-negotiation.)
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
- If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
SHOULD also be forced.
@ -328,13 +360,15 @@ process.
The parameter may be specified as either a decimal or hexadecimal value as
determined by the bitmap below.
============== ====== ====== ======= ======= ====== ====== ======= ======
Bit position 7 6 5 4 3 2 1 0
Decimal Value 128 64 32 16 8 4 2 1
Hex value 80 40 20 10 8 4 2 1
Speed (Mbps) N/A N/A 1000 N/A 100 100 10 10
Duplex Full Full Half Full Half
============== ====== ====== ======= ======= ====== ====== ======= ======
Some examples of using AutoNeg:
Some examples of using AutoNeg::
modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
modprobe e1000 AutoNeg=1 (Same as above)
@ -357,56 +391,59 @@ Additional Configurations
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the MTU to a value larger
than the default of 1500. Use the ifconfig command to increase the MTU
size. For example::
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
For example::
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. It can be made permanent if
you add::
This setting is not saved across reboots. It can be made permanent if
you add::
MTU=9000
to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
applies to the Red Hat distributions; other distributions may store this
setting in a different location.
to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
applies to the Red Hat distributions; other distributions may store this
setting in a different location.
Notes: Degradation in throughput performance may be observed in some
Jumbo frames environments. If this is observed, increasing the
application's socket buffer size and/or increasing the
/proc/sys/net/ipv4/tcp_*mem entry values may help. See the specific
application manual and /usr/src/linux*/Documentation/
networking/ip-sysctl.txt for more details.
Notes:
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket buffer
size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
See the specific application manual and /usr/src/linux*/Documentation/
networking/ip-sysctl.txt for more details.
- The maximum MTU setting for Jumbo Frames is 16110. This value
coincides with the maximum Jumbo Frames size of 16128.
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
with the maximum Jumbo Frames size of 16128.
- Using Jumbo frames at 10 or 100 Mbps is not supported and may result
in poor performance or loss of link.
- Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
poor performance or loss of link.
- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
support Jumbo Frames. These correspond to the following product names:
Intel(R) PRO/1000 Gigabit Server Adapter Intel(R) PRO/1000 PM Network
Connection
- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
support Jumbo Frames. These correspond to the following product names::
Intel(R) PRO/1000 Gigabit Server Adapter
Intel(R) PRO/1000 PM Network Connection
ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
version 1.6 or later is required for this functionality.
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The ethtool
version 1.6 or later is required for this functionality.
The latest release of ethtool can be found from
https://www.kernel.org/pub/software/network/ethtool/
Enabling Wake on LAN* (WoL)
---------------------------
WoL is configured through the ethtool* utility.
WoL will be enabled on the system during the next shut down or reboot.
For this driver version, in order to enable WoL, the e1000 driver must be
loaded when shutting down or rebooting the system.
WoL is configured through the ethtool* utility.
WoL will be enabled on the system during the next shut down or reboot.
For this driver version, in order to enable WoL, the e1000 driver must be
loaded when shutting down or rebooting the system.
Support
=======

6
Documentation/networking/index.rst
View File

@ -6,15 +6,21 @@ Contents:
.. toctree::
:maxdepth: 2
netdev-FAQ
af_xdp
batman-adv
can
can_ucan_protocol
dpaa2/index
e100
e1000
kapi
z8530book
msg_zerocopy
failover
net_failover
alias
bridge
.. only:: subproject

9
Documentation/networking/ip-sysctl.txt
View File

@ -81,6 +81,15 @@ fib_multipath_hash_policy - INTEGER
0 - Layer 3
1 - Layer 4
ip_forward_update_priority - INTEGER
Whether to update SKB priority from "TOS" field in IPv4 header after it
is forwarded. The new SKB priority is mapped from TOS field value
according to an rt_tos2priority table (see e.g. man tc-prio).
Default: 1 (Update priority.)
Possible values:
0 - Do not update priority.
1 - Update priority.
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.

107
Documentation/networking/net_failover.rst
View File

@ -36,37 +36,39 @@ feature on the virtio-net interface and assign the same MAC address to both
virtio-net and VF interfaces.
Here is an example XML snippet that shows such configuration.
::
<interface type='network'>
<mac address='52:54:00:00:12:53'/>
<source network='enp66s0f0_br'/>
<target dev='tap01'/>
<model type='virtio'/>
<driver name='vhost' queues='4'/>
<link state='down'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</interface>
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:00:12:53'/>
<source>
<address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:00:12:53'/>
<source network='enp66s0f0_br'/>
<target dev='tap01'/>
<model type='virtio'/>
<driver name='vhost' queues='4'/>
<link state='down'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</interface>
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:00:12:53'/>
<source>
<address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
</interface>
Booting a VM with the above configuration will result in the following 3
netdevs created in the VM.
::
4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.53/24 brd 192.168.12.255 scope global dynamic ens10
valid_lft 42482sec preferred_lft 42482sec
inet6 fe80::97d8:db2:8c10:b6d6/64 scope link
valid_lft forever preferred_lft forever
5: ens10nsby: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ens10 state UP group default qlen 1000
link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
7: ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ens10 state UP group default qlen 1000
link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.53/24 brd 192.168.12.255 scope global dynamic ens10
valid_lft 42482sec preferred_lft 42482sec
inet6 fe80::97d8:db2:8c10:b6d6/64 scope link
valid_lft forever preferred_lft forever
5: ens10nsby: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ens10 state UP group default qlen 1000
link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
7: ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ens10 state UP group default qlen 1000
link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff
ens10 is the 'failover' master netdev, ens10nsby and ens11 are the slave
'standby' and 'primary' netdevs respectively.
@ -80,37 +82,38 @@ the paravirtual datapath when the VF is unplugged.
Here is a sample script that shows the steps to initiate live migration on
the source hypervisor.
::
# cat vf_xml
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:00:12:53'/>
<source>
<address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
</interface>
# cat vf_xml
<interface type='hostdev' managed='yes'>
<mac address='52:54:00:00:12:53'/>
<source>
<address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
</interface>
# Source Hypervisor
#!/bin/bash
# Source Hypervisor
#!/bin/bash
DOMAIN=fedora27-tap01
PF=enp66s0f0
VF_NUM=5
TAP_IF=tap01
VF_XML=
DOMAIN=fedora27-tap01
PF=enp66s0f0
VF_NUM=5
TAP_IF=tap01
VF_XML=
MAC=52:54:00:00:12:53
ZERO_MAC=00:00:00:00:00:00
MAC=52:54:00:00:12:53
ZERO_MAC=00:00:00:00:00:00
virsh domif-setlink $DOMAIN $TAP_IF up
bridge fdb del $MAC dev $PF master
virsh detach-device $DOMAIN $VF_XML
ip link set $PF vf $VF_NUM mac $ZERO_MAC
virsh domif-setlink $DOMAIN $TAP_IF up
bridge fdb del $MAC dev $PF master
virsh detach-device $DOMAIN $VF_XML
ip link set $PF vf $VF_NUM mac $ZERO_MAC
virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system
virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system
# Destination Hypervisor
#!/bin/bash
# Destination Hypervisor
#!/bin/bash
virsh attach-device $DOMAIN $VF_XML
virsh domif-setlink $DOMAIN $TAP_IF down
virsh attach-device $DOMAIN $VF_XML
virsh domif-setlink $DOMAIN $TAP_IF down

259
Documentation/networking/netdev-FAQ.rst Normal file
View File

@ -0,0 +1,259 @@
.. SPDX-License-Identifier: GPL-2.0
.. _netdev-FAQ:
==========
netdev FAQ
==========
Q: What is netdev?
------------------
A: It is a mailing list for all network-related Linux stuff. This
includes anything found under net/ (i.e. core code like IPv6) and
drivers/net (i.e. hardware specific drivers) in the Linux source tree.
Note that some subsystems (e.g. wireless drivers) which have a high
volume of traffic have their own specific mailing lists.
The netdev list is managed (like many other Linux mailing lists) through
VGER (http://vger.kernel.org/) and archives can be found below:
- http://marc.info/?l=linux-netdev
- http://www.spinics.net/lists/netdev/
Aside from subsystems like that mentioned above, all network-related
Linux development (i.e. RFC, review, comments, etc.) takes place on
netdev.
Q: How do the changes posted to netdev make their way into Linux?
-----------------------------------------------------------------
A: There are always two trees (git repositories) in play. Both are
driven by David Miller, the main network maintainer. There is the
``net`` tree, and the ``net-next`` tree. As you can probably guess from
the names, the ``net`` tree is for fixes to existing code already in the
mainline tree from Linus, and ``net-next`` is where the new code goes
for the future release. You can find the trees here:
- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
Q: How often do changes from these trees make it to the mainline Linus tree?
----------------------------------------------------------------------------
A: To understand this, you need to know a bit of background information on
the cadence of Linux development. Each new release starts off with a
two week "merge window" where the main maintainers feed their new stuff
to Linus for merging into the mainline tree. After the two weeks, the
merge window is closed, and it is called/tagged ``-rc1``. No new
features get mainlined after this -- only fixes to the rc1 content are
expected. After roughly a week of collecting fixes to the rc1 content,
rc2 is released. This repeats on a roughly weekly basis until rc7
(typically; sometimes rc6 if things are quiet, or rc8 if things are in a
state of churn), and a week after the last vX.Y-rcN was done, the
official vX.Y is released.
Relating that to netdev: At the beginning of the 2-week merge window,
the ``net-next`` tree will be closed - no new changes/features. The
accumulated new content of the past ~10 weeks will be passed onto
mainline/Linus via a pull request for vX.Y -- at the same time, the
``net`` tree will start accumulating fixes for this pulled content
relating to vX.Y
An announcement indicating when ``net-next`` has been closed is usually
sent to netdev, but knowing the above, you can predict that in advance.
IMPORTANT: Do not send new ``net-next`` content to netdev during the
period during which ``net-next`` tree is closed.
Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
tree for ``net-next`` reopens to collect content for the next (vX.Y+1)
release.
If you aren't subscribed to netdev and/or are simply unsure if
``net-next`` has re-opened yet, simply check the ``net-next`` git
repository link above for any new networking-related commits. You may
also check the following website for the current status:
http://vger.kernel.org/~davem/net-next.html
The ``net`` tree continues to collect fixes for the vX.Y content, and is
fed back to Linus at regular (~weekly) intervals. Meaning that the
focus for ``net`` is on stabilization and bug fixes.
Finally, the vX.Y gets released, and the whole cycle starts over.
Q: So where are we now in this cycle?
Load the mainline (Linus) page here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
and note the top of the "tags" section. If it is rc1, it is early in
the dev cycle. If it was tagged rc7 a week ago, then a release is
probably imminent.
Q: How do I indicate which tree (net vs. net-next) my patch should be in?
-------------------------------------------------------------------------
A: Firstly, think whether you have a bug fix or new "next-like" content.
Then once decided, assuming that you use git, use the prefix flag, i.e.
::
git format-patch --subject-prefix='PATCH net-next' start..finish
Use ``net`` instead of ``net-next`` (always lower case) in the above for
bug-fix ``net`` content. If you don't use git, then note the only magic
in the above is just the subject text of the outgoing e-mail, and you
can manually change it yourself with whatever MUA you are comfortable
with.
Q: I sent a patch and I'm wondering what happened to it?
--------------------------------------------------------
Q: How can I tell whether it got merged?
A: Start by looking at the main patchworks queue for netdev:
http://patchwork.ozlabs.org/project/netdev/list/
The "State" field will tell you exactly where things are at with your
patch.
Q: The above only says "Under Review". How can I find out more?
----------------------------------------------------------------
A: Generally speaking, the patches get triaged quickly (in less than
48h). So be patient. Asking the maintainer for status updates on your
patch is a good way to ensure your patch is ignored or pushed to the
bottom of the priority list.
Q: I submitted multiple versions of the patch series
----------------------------------------------------
Q: should I directly update patchwork for the previous versions of these
patch series?
A: No, please don't interfere with the patch status on patchwork, leave
it to the maintainer to figure out what is the most recent and current
version that should be applied. If there is any doubt, the maintainer
will reply and ask what should be done.
Q: How can I tell what patches are queued up for backporting to the various stable releases?
--------------------------------------------------------------------------------------------
A: Normally Greg Kroah-Hartman collects stable commits himself, but for
networking, Dave collects up patches he deems critical for the
networking subsystem, and then hands them off to Greg.
There is a patchworks queue that you can see here:
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
It contains the patches which Dave has selected, but not yet handed off
to Greg. If Greg already has the patch, then it will be here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
A quick way to find whether the patch is in this stable-queue is to
simply clone the repo, and then git grep the mainline commit ID, e.g.
::
stable-queue$ git grep -l 284041ef21fdf2e
releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
stable/stable-queue$
Q: I see a network patch and I think it should be backported to stable.
-----------------------------------------------------------------------
Q: Should I request it via stable@vger.kernel.org like the references in
the kernel's Documentation/process/stable-kernel-rules.rst file say?
A: No, not for networking. Check the stable queues as per above first
to see if it is already queued. If not, then send a mail to netdev,
listing the upstream commit ID and why you think it should be a stable
candidate.
Before you jump to go do the above, do note that the normal stable rules
in :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
still apply. So you need to explicitly indicate why it is a critical
fix and exactly what users are impacted. In addition, you need to
convince yourself that you *really* think it has been overlooked,
vs. having been considered and rejected.
Generally speaking, the longer it has had a chance to "soak" in
mainline, the better the odds that it is an OK candidate for stable. So
scrambling to request a commit be added the day after it appears should
be avoided.
Q: I have created a network patch and I think it should be backported to stable.
--------------------------------------------------------------------------------
Q: Should I add a Cc: stable@vger.kernel.org like the references in the
kernel's Documentation/ directory say?
A: No. See above answer. In short, if you think it really belongs in
stable, then ensure you write a decent commit log that describes who
gets impacted by the bug fix and how it manifests itself, and when the
bug was introduced. If you do that properly, then the commit will get
handled appropriately and most likely get put in the patchworks stable
queue if it really warrants it.
If you think there is some valid information relating to it being in
stable that does *not* belong in the commit log, then use the three dash
marker line as described in
:ref:`Documentation/process/submitting-patches.rst <the_canonical_patch_format>`
to temporarily embed that information into the patch that you send.
Q: Are all networking bug fixes backported to all stable releases?
------------------------------------------------------------------
A: Due to capacity, Dave could only take care of the backports for the
last two stable releases. For earlier stable releases, each stable
branch maintainer is supposed to take care of them. If you find any
patch is missing from an earlier stable branch, please notify
stable@vger.kernel.org with either a commit ID or a formal patch
backported, and CC Dave and other relevant networking developers.
Q: Is the comment style convention different for the networking content?
------------------------------------------------------------------------
A: Yes, in a largely trivial way. Instead of this::
/*
* foobar blah blah blah
* another line of text
*/
it is requested that you make it look like this::
/* foobar blah blah blah
* another line of text
*/
Q: I am working in existing code that has the former comment style and not the latter.
--------------------------------------------------------------------------------------
Q: Should I submit new code in the former style or the latter?
A: Make it the latter style, so that eventually all code in the domain
of netdev is of this format.
Q: I found a bug that might have possible security implications or similar.
---------------------------------------------------------------------------
Q: Should I mail the main netdev maintainer off-list?**
A: No. The current netdev maintainer has consistently requested that
people use the mailing lists and not reach out directly. If you aren't
OK with that, then perhaps consider mailing security@kernel.org or
reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
as possible alternative mechanisms.
Q: What level of testing is expected before I submit my change?
---------------------------------------------------------------
A: If your changes are against ``net-next``, the expectation is that you
have tested by layering your changes on top of ``net-next``. Ideally
you will have done run-time testing specific to your change, but at a
minimum, your changes should survive an ``allyesconfig`` and an
``allmodconfig`` build without new warnings or failures.
Q: Any other tips to help ensure my net/net-next patch gets OK'd?
-----------------------------------------------------------------
A: Attention to detail. Re-read your own work as if you were the
reviewer. You can start with using ``checkpatch.pl``, perhaps even with
the ``--strict`` flag. But do not be mindlessly robotic in doing so.
If your change is a bug fix, make sure your commit log indicates the
end-user visible symptom, the underlying reason as to why it happens,
and then if necessary, explain why the fix proposed is the best way to
get things done. Don't mangle whitespace, and as is common, don't
mis-indent function arguments that span multiple lines. If it is your
first patch, mail it to yourself so you can test apply it to an
unpatched tree to confirm infrastructure didn't mangle it.
Finally, go back and read
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
to be sure you are not repeating some common mistake documented there.

244
Documentation/networking/netdev-FAQ.txt
View File

@ -1,244 +0,0 @@
Information you need to know about netdev
-----------------------------------------
Q: What is netdev?
A: It is a mailing list for all network-related Linux stuff. This includes
anything found under net/ (i.e. core code like IPv6) and drivers/net
(i.e. hardware specific drivers) in the Linux source tree.
Note that some subsystems (e.g. wireless drivers) which have a high volume
of traffic have their own specific mailing lists.
The netdev list is managed (like many other Linux mailing lists) through
VGER ( http://vger.kernel.org/ ) and archives can be found below:
http://marc.info/?l=linux-netdev
http://www.spinics.net/lists/netdev/
Aside from subsystems like that mentioned above, all network-related Linux
development (i.e. RFC, review, comments, etc.) takes place on netdev.
Q: How do the changes posted to netdev make their way into Linux?
A: There are always two trees (git repositories) in play. Both are driven
by David Miller, the main network maintainer. There is the "net" tree,
and the "net-next" tree. As you can probably guess from the names, the
net tree is for fixes to existing code already in the mainline tree from
Linus, and net-next is where the new code goes for the future release.
You can find the trees here:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
Q: How often do changes from these trees make it to the mainline Linus tree?
A: To understand this, you need to know a bit of background information
on the cadence of Linux development. Each new release starts off with
a two week "merge window" where the main maintainers feed their new
stuff to Linus for merging into the mainline tree. After the two weeks,
the merge window is closed, and it is called/tagged "-rc1". No new
features get mainlined after this -- only fixes to the rc1 content
are expected. After roughly a week of collecting fixes to the rc1
content, rc2 is released. This repeats on a roughly weekly basis
until rc7 (typically; sometimes rc6 if things are quiet, or rc8 if
things are in a state of churn), and a week after the last vX.Y-rcN
was done, the official "vX.Y" is released.
Relating that to netdev: At the beginning of the 2-week merge window,
the net-next tree will be closed - no new changes/features. The
accumulated new content of the past ~10 weeks will be passed onto
mainline/Linus via a pull request for vX.Y -- at the same time,
the "net" tree will start accumulating fixes for this pulled content
relating to vX.Y
An announcement indicating when net-next has been closed is usually
sent to netdev, but knowing the above, you can predict that in advance.
IMPORTANT: Do not send new net-next content to netdev during the
period during which net-next tree is closed.
Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
tree for net-next reopens to collect content for the next (vX.Y+1) release.
If you aren't subscribed to netdev and/or are simply unsure if net-next
has re-opened yet, simply check the net-next git repository link above for
any new networking-related commits. You may also check the following
website for the current status:
http://vger.kernel.org/~davem/net-next.html
The "net" tree continues to collect fixes for the vX.Y content, and
is fed back to Linus at regular (~weekly) intervals. Meaning that the
focus for "net" is on stabilization and bugfixes.
Finally, the vX.Y gets released, and the whole cycle starts over.
Q: So where are we now in this cycle?
A: Load the mainline (Linus) page here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
and note the top of the "tags" section. If it is rc1, it is early
in the dev cycle. If it was tagged rc7 a week ago, then a release
is probably imminent.
Q: How do I indicate which tree (net vs. net-next) my patch should be in?
A: Firstly, think whether you have a bug fix or new "next-like" content.
Then once decided, assuming that you use git, use the prefix flag, i.e.
git format-patch --subject-prefix='PATCH net-next' start..finish
Use "net" instead of "net-next" (always lower case) in the above for
bug-fix net content. If you don't use git, then note the only magic in
the above is just the subject text of the outgoing e-mail, and you can
manually change it yourself with whatever MUA you are comfortable with.
Q: I sent a patch and I'm wondering what happened to it. How can I tell
whether it got merged?
A: Start by looking at the main patchworks queue for netdev:
http://patchwork.ozlabs.org/project/netdev/list/
The "State" field will tell you exactly where things are at with
your patch.
Q: The above only says "Under Review". How can I find out more?
A: Generally speaking, the patches get triaged quickly (in less than 48h).
So be patient. Asking the maintainer for status updates on your
patch is a good way to ensure your patch is ignored or pushed to
the bottom of the priority list.
Q: I submitted multiple versions of the patch series, should I directly update
patchwork for the previous versions of these patch series?
A: No, please don't interfere with the patch status on patchwork, leave it to
the maintainer to figure out what is the most recent and current version that
should be applied. If there is any doubt, the maintainer will reply and ask
what should be done.
Q: How can I tell what patches are queued up for backporting to the
various stable releases?
A: Normally Greg Kroah-Hartman collects stable commits himself, but
for networking, Dave collects up patches he deems critical for the
networking subsystem, and then hands them off to Greg.
There is a patchworks queue that you can see here:
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
It contains the patches which Dave has selected, but not yet handed
off to Greg. If Greg already has the patch, then it will be here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
A quick way to find whether the patch is in this stable-queue is
to simply clone the repo, and then git grep the mainline commit ID, e.g.
stable-queue$ git grep -l 284041ef21fdf2e
releases/3.0.84/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
releases/3.4.51/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
stable/stable-queue$
Q: I see a network patch and I think it should be backported to stable.
Should I request it via "stable@vger.kernel.org" like the references in
the kernel's Documentation/process/stable-kernel-rules.rst file say?
A: No, not for networking. Check the stable queues as per above 1st to see
if it is already queued. If not, then send a mail to netdev, listing
the upstream commit ID and why you think it should be a stable candidate.
Before you jump to go do the above, do note that the normal stable rules
in Documentation/process/stable-kernel-rules.rst still apply. So you need to
explicitly indicate why it is a critical fix and exactly what users are
impacted. In addition, you need to convince yourself that you _really_
think it has been overlooked, vs. having been considered and rejected.
Generally speaking, the longer it has had a chance to "soak" in mainline,
the better the odds that it is an OK candidate for stable. So scrambling
to request a commit be added the day after it appears should be avoided.
Q: I have created a network patch and I think it should be backported to
stable. Should I add a "Cc: stable@vger.kernel.org" like the references
in the kernel's Documentation/ directory say?
A: No. See above answer. In short, if you think it really belongs in
stable, then ensure you write a decent commit log that describes who
gets impacted by the bugfix and how it manifests itself, and when the
bug was introduced. If you do that properly, then the commit will
get handled appropriately and most likely get put in the patchworks
stable queue if it really warrants it.
If you think there is some valid information relating to it being in
stable that does _not_ belong in the commit log, then use the three
dash marker line as described in Documentation/process/submitting-patches.rst to
temporarily embed that information into the patch that you send.
Q: Are all networking bug fixes backported to all stable releases?
A: Due to capacity, Dave could only take care of the backports for the last
2 stable releases. For earlier stable releases, each stable branch maintainer
is supposed to take care of them. If you find any patch is missing from an
earlier stable branch, please notify stable@vger.kernel.org with either a
commit ID or a formal patch backported, and CC Dave and other relevant
networking developers.
Q: Someone said that the comment style and coding convention is different
for the networking content. Is this true?
A: Yes, in a largely trivial way. Instead of this:
/*
* foobar blah blah blah
* another line of text
*/
it is requested that you make it look like this:
/* foobar blah blah blah
* another line of text
*/
Q: I am working in existing code that has the former comment style and not the
latter. Should I submit new code in the former style or the latter?
A: Make it the latter style, so that eventually all code in the domain of
netdev is of this format.
Q: I found a bug that might have possible security implications or similar.
Should I mail the main netdev maintainer off-list?
A: No. The current netdev maintainer has consistently requested that people
use the mailing lists and not reach out directly. If you aren't OK with
that, then perhaps consider mailing "security@kernel.org" or reading about
http://oss-security.openwall.org/wiki/mailing-lists/distros
as possible alternative mechanisms.
Q: What level of testing is expected before I submit my change?
A: If your changes are against net-next, the expectation is that you
have tested by layering your changes on top of net-next. Ideally you
will have done run-time testing specific to your change, but at a
minimum, your changes should survive an "allyesconfig" and an
"allmodconfig" build without new warnings or failures.
Q: Any other tips to help ensure my net/net-next patch gets OK'd?
A: Attention to detail. Re-read your own work as if you were the
reviewer. You can start with using checkpatch.pl, perhaps even
with the "--strict" flag. But do not be mindlessly robotic in
doing so. If your change is a bug-fix, make sure your commit log
indicates the end-user visible symptom, the underlying reason as
to why it happens, and then if necessary, explain why the fix proposed
is the best way to get things done. Don't mangle whitespace, and as
is common, don't mis-indent function arguments that span multiple lines.
If it is your first patch, mail it to yourself so you can test apply
it to an unpatched tree to confirm infrastructure didn't mangle it.
Finally, go back and read Documentation/process/submitting-patches.rst to be
sure you are not repeating some common mistake documented there.

540
Documentation/networking/ti-cpsw.txt Normal file
View File

@ -0,0 +1,540 @@
* Texas Instruments CPSW ethernet driver
Multiqueue & CBS & MQPRIO
=====================================================================
=====================================================================
The cpsw has 3 CBS shapers for each external ports. This document
describes MQPRIO and CBS Qdisc offload configuration for cpsw driver
based on examples. It potentially can be used in audio video bridging
(AVB) and time sensitive networking (TSN).
The following examples were tested on AM572x EVM and BBB boards.
Test setup
==========
Under consideration two examples with AM572x EVM running cpsw driver
in dual_emac mode.
Several prerequisites:
- TX queues must be rated starting from txq0 that has highest priority
- Traffic classes are used starting from 0, that has highest priority
- CBS shapers should be used with rated queues
- The bandwidth for CBS shapers has to be set a little bit more then
potential incoming rate, thus, rate of all incoming tx queues has
to be a little less
- Real rates can differ, due to discreetness
- Map skb-priority to txq is not enough, also skb-priority to l2 prio
map has to be created with ip or vconfig tool
- Any l2/socket prio (0 - 7) for classes can be used, but for
simplicity default values are used: 3 and 2
- only 2 classes tested: A and B, but checked and can work with more,
maximum allowed 4, but only for 3 rate can be set.
Test setup for examples
=======================
+-------------------------------+
|--+ |
| | Workstation0 |
|E | MAC 18:03:73:66:87:42 |
+-----------------------------+ +--|t | |
| | 1 | E | | |h |./tsn_listener -d \ |
| Target board: | 0 | t |--+ |0 | 18:03:73:66:87:42 -i eth0 \|
| AM572x EVM | 0 | h | | | -s 1500 |
| | 0 | 0 | |--+ |
| Only 2 classes: |Mb +---| +-------------------------------+
| class A, class B | |
| | +---| +-------------------------------+
| | 1 | E | |--+ |
| | 0 | t | | | Workstation1 |
| | 0 | h |--+ |E | MAC 20:cf:30:85:7d:fd |
| |Mb | 1 | +--|t | |
+-----------------------------+ |h |./tsn_listener -d \ |
|0 | 20:cf:30:85:7d:fd -i eth0 \|
| | -s 1500 |
|--+ |
+-------------------------------+
*********************************************************************
*********************************************************************
*********************************************************************
Example 1: One port tx AVB configuration scheme for target board
----------------------------------------------------------------------
(prints and scheme for AM572x evm, applicable for single port boards)
tc - traffic class
txq - transmit queue
p - priority
f - fifo (cpsw fifo)
S - shaper configured
+------------------------------------------------------------------+ u
| +---------------+ +---------------+ +------+ +------+ | s
| | | | | | | | | | e
| | App 1 | | App 2 | | Apps | | Apps | | r
| | Class A | | Class B | | Rest | | Rest | |
| | Eth0 | | Eth0 | | Eth0 | | Eth1 | | s
| | VLAN100 | | VLAN100 | | | | | | | | p
| | 40 Mb/s | | 20 Mb/s | | | | | | | | a
| | SO_PRIORITY=3 | | SO_PRIORITY=2 | | | | | | | | c
| | | | | | | | | | | | | | e
| +---|-----------+ +---|-----------+ +---|--+ +---|--+ |
+-----|------------------|------------------|--------|-------------+
+-+ +------------+ | |
| | +-----------------+ +--+
| | | |
+---|-------|-------------|-----------------------|----------------+
| +----+ +----+ +----+ +----+ +----+ |
| | p3 | | p2 | | p1 | | p0 | | p0 | | k
| \ / \ / \ / \ / \ / | e
| \ / \ / \ / \ / \ / | r
| \/ \/ \/ \/ \/ | n
| | | | | | e
| | | +-----+ | | l
| | | | | |
| +----+ +----+ +----+ +----+ | s
| |tc0 | |tc1 | |tc2 | |tc0 | | p
| \ / \ / \ / \ / | a
| \ / \ / \ / \ / | c
| \/ \/ \/ \/ | e
| | | +-----+ | |
| | | | | | |
| | | | | | |
| | | | | | |
| +----+ +----+ +----+ +----+ +----+ |
| |txq0| |txq1| |txq2| |txq3| |txq4| |
| \ / \ / \ / \ / \ / |
| \ / \ / \ / \ / \ / |
| \/ \/ \/ \/ \/ |
| +-|------|------|------|--+ +--|--------------+ |
| | | | | | | Eth0.100 | | Eth1 | |
+---|------|------|------|------------------------|----------------+
| | | | |
p p p p |
3 2 0-1, 4-7 <- L2 priority |
| | | | |
| | | | |
+---|------|------|------|------------------------|----------------+
| | | | | |----------+ |
| +----+ +----+ +----+ +----+ +----+ |
| |dma7| |dma6| |dma5| |dma4| |dma3| |
| \ / \ / \ / \ / \ / | c
| \S / \S / \ / \ / \ / | p
| \/ \/ \/ \/ \/ | s
| | | | +----- | | w
| | | | | | |
| | | | | | | d
| +----+ +----+ +----+p p+----+ | r
| | | | | | |o o| | | i
| | f3 | | f2 | | f0 |r r| f0 | | v
| |tc0 | |tc1 | |tc2 |t t|tc0 | | e
| \CBS / \CBS / \CBS /1 2\CBS / | r
| \S / \S / \ / \ / |
| \/ \/ \/ \/ |
+------------------------------------------------------------------+
========================================Eth==========================>
1)
// Add 4 tx queues, for interface Eth0, and 1 tx queue for Eth1
$ ethtool -L eth0 rx 1 tx 5
rx unmodified, ignoring
2)
// Check if num of queues is set correctly:
$ ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 8
TX: 8
Other: 0
Combined: 0
Current hardware settings:
RX: 1
TX: 5
Other: 0
Combined: 0
3)
// TX queues must be rated starting from 0, so set bws for tx0 and tx1
// Set rates 40 and 20 Mb/s appropriately.
// Pay attention, real speed can differ a bit due to discreetness.
// Leave last 2 tx queues not rated.
$ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate
$ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate
4)
// Check maximum rate of tx (cpdma) queues:
$ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate
40
20
0
0
0
5)
// Map skb->priority to traffic class:
// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2
// Map traffic class to transmit queue:
// tc0 -> txq0, tc1 -> txq1, tc2 -> (txq2, txq3)
$ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \
map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 1
5a)
// As two interface sharing same set of tx queues, assign all traffic
// coming to interface Eth1 to separate queue in order to not mix it
// with traffic from interface Eth0, so use separate txq to send
// packets to Eth1, so all prio -> tc0 and tc0 -> txq4
// Here hw 0, so here still default configuration for eth1 in hw
$ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 1 \
map 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@4 hw 0
6)
// Check classes settings
$ tc -g class show dev eth0
+---(100:ffe2) mqprio
| +---(100:3) mqprio
| +---(100:4) mqprio
|
+---(100:ffe1) mqprio
| +---(100:2) mqprio
|
+---(100:ffe0) mqprio
+---(100:1) mqprio
$ tc -g class show dev eth1
+---(100:ffe0) mqprio
+---(100:5) mqprio
7)
// Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc
// Set it +1 Mb for reserve (important!)
// here only idle slope is important, others arg are ignored
// Pay attention, real speed can differ a bit due to discreetness
$ tc qdisc add dev eth0 parent 100:1 cbs locredit -1438 \
hicredit 62 sendslope -959000 idleslope 41000 offload 1
net eth0: set FIFO3 bw = 50
8)
// Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc:
// Set it +1 Mb for reserve (important!)
$ tc qdisc add dev eth0 parent 100:2 cbs locredit -1468 \
hicredit 65 sendslope -979000 idleslope 21000 offload 1
net eth0: set FIFO2 bw = 30
9)
// Create vlan 100 to map sk->priority to vlan qos
$ ip link add link eth0 name eth0.100 type vlan id 100
8021q: 802.1Q VLAN Support v1.8
8021q: adding VLAN 0 to HW filter on device eth0
8021q: adding VLAN 0 to HW filter on device eth1
net eth0: Adding vlanid 100 to vlan filter
10)
// Map skb->priority to L2 prio, 1 to 1
$ ip link set eth0.100 type vlan \
egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
11)
// Check egress map for vlan 100
$ cat /proc/net/vlan/eth0.100
[...]
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
12)
// Run your appropriate tools with socket option "SO_PRIORITY"
// to 3 for class A and/or to 2 for class B
// (I took at https://www.spinics.net/lists/netdev/msg460869.html)
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500&
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500&
13)
// run your listener on workstation (should be in same vlan)
// (I took at https://www.spinics.net/lists/netdev/msg460869.html)
./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39000 kbps
14)
// Restore default configuration if needed
$ ip link del eth0.100
$ tc qdisc del dev eth1 root
$ tc qdisc del dev eth0 root
net eth0: Prev FIFO2 is shaped
net eth0: set FIFO3 bw = 0
net eth0: set FIFO2 bw = 0
$ ethtool -L eth0 rx 1 tx 1
*********************************************************************
*********************************************************************
*********************************************************************
Example 2: Two port tx AVB configuration scheme for target board
----------------------------------------------------------------------
(prints and scheme for AM572x evm, for dual emac boards only)
+------------------------------------------------------------------+ u
| +----------+ +----------+ +------+ +----------+ +----------+ | s
| | | | | | | | | | | | e
| | App 1 | | App 2 | | Apps | | App 3 | | App 4 | | r
| | Class A | | Class B | | Rest | | Class B | | Class A | |
| | Eth0 | | Eth0 | | | | | Eth1 | | Eth1 | | s
| | VLAN100 | | VLAN100 | | | | | VLAN100 | | VLAN100 | | p
| | 40 Mb/s | | 20 Mb/s | | | | | 10 Mb/s | | 30 Mb/s | | a
| | SO_PRI=3 | | SO_PRI=2 | | | | | SO_PRI=3 | | SO_PRI=2 | | c
| | | | | | | | | | | | | | | | | e
| +---|------+ +---|------+ +---|--+ +---|------+ +---|------+ |
+-----|-------------|-------------|---------|-------------|--------+
+-+ +-------+ | +----------+ +----+
| | +-------+------+ | |
| | | | | |
+---|-------|-------------|--------------|-------------|-------|---+
| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
| | p3 | | p2 | | p1 | | p0 | | p0 | | p1 | | p2 | | p3 | | k
| \ / \ / \ / \ / \ / \ / \ / \ / | e
| \ / \ / \ / \ / \ / \ / \ / \ / | r
| \/ \/ \/ \/ \/ \/ \/ \/ | n
| | | | | | | | e
| | | +----+ +----+ | | | l
| | | | | | | |
| +----+ +----+ +----+ +----+ +----+ +----+ | s
| |tc0 | |tc1 | |tc2 | |tc2 | |tc1 | |tc0 | | p
| \ / \ / \ / \ / \ / \ / | a
| \ / \ / \ / \ / \ / \ / | c
| \/ \/ \/ \/ \/ \/ | e
| | | +-----+ +-----+ | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | E E | | | | |
| +----+ +----+ +----+ +----+ t t +----+ +----+ +----+ +----+ |
| |txq0| |txq1| |txq4| |txq5| h h |txq6| |txq7| |txq3| |txq2| |
| \ / \ / \ / \ / 0 1 \ / \ / \ / \ / |
| \ / \ / \ / \ / . . \ / \ / \ / \ / |
| \/ \/ \/ \/ 1 1 \/ \/ \/ \/ |
| +-|------|------|------|--+ 0 0 +-|------|------|------|--+ |
| | | | | | | 0 0 | | | | | | |
+---|------|------|------|---------------|------|------|------|----+
| | | | | | | |
p p p p p p p p
3 2 0-1, 4-7 <-L2 pri-> 0-1, 4-7 2 3
| | | | | | | |
| | | | | | | |
+---|------|------|------|---------------|------|------|------|----+
| | | | | | | | | |
| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
| |dma7| |dma6| |dma3| |dma2| |dma1| |dma0| |dma4| |dma5| |
| \ / \ / \ / \ / \ / \ / \ / \ / | c
| \S / \S / \ / \ / \ / \ / \S / \S / | p
| \/ \/ \/ \/ \/ \/ \/ \/ | s
| | | | +----- | | | | | w
| | | | | +----+ | | | |
| | | | | | | | | | d
| +----+ +----+ +----+p p+----+ +----+ +----+ | r
| | | | | | |o o| | | | | | | i
| | f3 | | f2 | | f0 |r CPSW r| f3 | | f2 | | f0 | | v
| |tc0 | |tc1 | |tc2 |t t|tc0 | |tc1 | |tc2 | | e
| \CBS / \CBS / \CBS /1 2\CBS / \CBS / \CBS / | r
| \S / \S / \ / \S / \S / \ / |
| \/ \/ \/ \/ \/ \/ |
+------------------------------------------------------------------+
========================================Eth==========================>
1)
// Add 8 tx queues, for interface Eth0, but they are common, so are accessed
// by two interfaces Eth0 and Eth1.
$ ethtool -L eth1 rx 1 tx 8
rx unmodified, ignoring
2)
// Check if num of queues is set correctly:
$ ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 8
TX: 8
Other: 0
Combined: 0
Current hardware settings:
RX: 1
TX: 8
Other: 0
Combined: 0
3)
// TX queues must be rated starting from 0, so set bws for tx0 and tx1 for Eth0
// and for tx2 and tx3 for Eth1. That is, rates 40 and 20 Mb/s appropriately
// for Eth0 and 30 and 10 Mb/s for Eth1.
// Real speed can differ a bit due to discreetness
// Leave last 4 tx queues as not rated
$ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate
$ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate
$ echo 30 > /sys/class/net/eth1/queues/tx-2/tx_maxrate
$ echo 10 > /sys/class/net/eth1/queues/tx-3/tx_maxrate
4)
// Check maximum rate of tx (cpdma) queues:
$ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate
40
20
30
10
0
0
0
0
5)
// Map skb->priority to traffic class for Eth0:
// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2
// Map traffic class to transmit queue:
// tc0 -> txq0, tc1 -> txq1, tc2 -> (txq4, txq5)
$ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \
map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@4 hw 1
6)
// Check classes settings
$ tc -g class show dev eth0
+---(100:ffe2) mqprio
| +---(100:5) mqprio
| +---(100:6) mqprio
|
+---(100:ffe1) mqprio
| +---(100:2) mqprio
|
+---(100:ffe0) mqprio
+---(100:1) mqprio
7)
// Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc for Eth0
// here only idle slope is important, others ignored
// Real speed can differ a bit due to discreetness
$ tc qdisc add dev eth0 parent 100:1 cbs locredit -1470 \
hicredit 62 sendslope -959000 idleslope 41000 offload 1
net eth0: set FIFO3 bw = 50
8)
// Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc for Eth0
$ tc qdisc add dev eth0 parent 100:2 cbs locredit -1470 \
hicredit 65 sendslope -979000 idleslope 21000 offload 1
net eth0: set FIFO2 bw = 30
9)
// Create vlan 100 to map sk->priority to vlan qos for Eth0
$ ip link add link eth0 name eth0.100 type vlan id 100
net eth0: Adding vlanid 100 to vlan filter
10)
// Map skb->priority to L2 prio for Eth0.100, one to one
$ ip link set eth0.100 type vlan \
egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
11)
// Check egress map for vlan 100
$ cat /proc/net/vlan/eth0.100
[...]
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
12)
// Map skb->priority to traffic class for Eth1:
// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2
// Map traffic class to transmit queue:
// tc0 -> txq2, tc1 -> txq3, tc2 -> (txq6, txq7)
$ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 3 \
map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@2 1@3 2@6 hw 1
13)
// Check classes settings
$ tc -g class show dev eth1
+---(100:ffe2) mqprio
| +---(100:7) mqprio
| +---(100:8) mqprio
|
+---(100:ffe1) mqprio
| +---(100:4) mqprio
|
+---(100:ffe0) mqprio
+---(100:3) mqprio
14)
// Set rate for class A - 31 Mbit (tc0, txq2) using CBS Qdisc for Eth1
// here only idle slope is important, others ignored
// Set it +1 Mb for reserve (important!)
$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1453 \
hicredit 47 sendslope -969000 idleslope 31000 offload 1
net eth1: set FIFO3 bw = 31
15)
// Set rate for class B - 11 Mbit (tc1, txq3) using CBS Qdisc for Eth1
// Set it +1 Mb for reserve (important!)
$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1483 \
hicredit 34 sendslope -989000 idleslope 11000 offload 1
net eth1: set FIFO2 bw = 11
16)
// Create vlan 100 to map sk->priority to vlan qos for Eth1
$ ip link add link eth1 name eth1.100 type vlan id 100
net eth1: Adding vlanid 100 to vlan filter
17)
// Map skb->priority to L2 prio for Eth1.100, one to one
$ ip link set eth1.100 type vlan \
egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
18)
// Check egress map for vlan 100
$ cat /proc/net/vlan/eth1.100
[...]
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
19)
// Run appropriate tools with socket option "SO_PRIORITY" to 3
// for class A and to 2 for class B. For both interfaces
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500&
./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500&
./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p2 -s 1500&
./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p3 -s 1500&
20)
// run your listener on workstation (should be in same vlan)
// (I took at https://www.spinics.net/lists/netdev/msg460869.html)
./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39012 kbps
Receiving data rate: 39000 kbps
21)
// Restore default configuration if needed
$ ip link del eth1.100
$ ip link del eth0.100
$ tc qdisc del dev eth1 root
net eth1: Prev FIFO2 is shaped
net eth1: set FIFO3 bw = 0
net eth1: set FIFO2 bw = 0
$ tc qdisc del dev eth0 root
net eth0: Prev FIFO2 is shaped
net eth0: set FIFO3 bw = 0
net eth0: set FIFO2 bw = 0
$ ethtool -L eth0 rx 1 tx 1

2
Documentation/process/stable-kernel-rules.rst
View File

@ -37,7 +37,7 @@ Procedure for submitting patches to the -stable tree
- If the patch covers files in net/ or drivers/net please follow netdev stable
submission guidelines as described in
Documentation/networking/netdev-FAQ.txt
:ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>`
- Security patches should not be handled (solely) by the -stable review
process but should follow the procedures in
:ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.

1
Documentation/process/submitting-patches.rst
View File

@ -611,6 +611,7 @@ which stable kernel versions should receive your fix. This is the preferred
method for indicating a bug fixed by the patch. See :ref:`describe_changes`
for more details.
.. _the_canonical_patch_format:
14) The canonical patch format
------------------------------

31
MAINTAINERS
View File

@ -581,7 +581,7 @@ W: https://www.infradead.org/~dhowells/kafs/
AGPGART DRIVER
M: David Airlie <airlied@linux.ie>
T: git git://people.freedesktop.org/~airlied/linux (part of drm maint)
T: git git://anongit.freedesktop.org/drm/drm
S: Maintained
F: drivers/char/agp/
F: include/linux/agp*
@ -2523,7 +2523,7 @@ S: Supported
F: drivers/scsi/esas2r
ATUSB IEEE 802.15.4 RADIO DRIVER
M: Stefan Schmidt <stefan@osg.samsung.com>
M: Stefan Schmidt <stefan@datenfreihafen.org>
L: linux-wpan@vger.kernel.org
S: Maintained
F: drivers/net/ieee802154/atusb.c
@ -4460,6 +4460,7 @@ F: Documentation/blockdev/drbd/
DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
R: "Rafael J. Wysocki" <rafael@kernel.org>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
S: Supported
F: Documentation/kobject.txt
@ -4630,7 +4631,7 @@ F: include/uapi/drm/vmwgfx_drm.h
DRM DRIVERS
M: David Airlie <airlied@linux.ie>
L: dri-devel@lists.freedesktop.org
T: git git://people.freedesktop.org/~airlied/linux
T: git git://anongit.freedesktop.org/drm/drm
B: https://bugs.freedesktop.org/
C: irc://chat.freenode.net/dri-devel
S: Maintained
@ -5443,6 +5444,7 @@ F: drivers/iommu/exynos-iommu.c
EZchip NPS platform support
M: Vineet Gupta <vgupta@synopsys.com>
M: Ofer Levi <oferle@mellanox.com>
S: Supported
F: arch/arc/plat-eznps
F: arch/arc/boot/dts/eznps.dts
@ -5789,7 +5791,6 @@ F: include/linux/fsl/
FREESCALE SOC FS_ENET DRIVER
M: Pantelis Antoniou <pantelis.antoniou@gmail.com>
M: Vitaly Bordug <vbordug@ru.mvista.com>
L: linuxppc-dev@lists.ozlabs.org
L: netdev@vger.kernel.org
S: Maintained
@ -6908,7 +6909,7 @@ F: drivers/clk/clk-versaclock5.c
IEEE 802.15.4 SUBSYSTEM
M: Alexander Aring <alex.aring@gmail.com>
M: Stefan Schmidt <stefan@osg.samsung.com>
M: Stefan Schmidt <stefan@datenfreihafen.org>
L: linux-wpan@vger.kernel.org
W: http://wpan.cakelab.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git
@ -7095,6 +7096,7 @@ F: include/uapi/linux/input.h
F: include/uapi/linux/input-event-codes.h
F: include/linux/input/
F: Documentation/devicetree/bindings/input/
F: Documentation/devicetree/bindings/serio/
F: Documentation/input/
INPUT MULTITOUCH (MT) PROTOCOL
@ -7984,7 +7986,7 @@ F: lib/test_kmod.c
F: tools/testing/selftests/kmod/
KPROBES
M: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
M: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
M: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
M: "David S. Miller" <davem@davemloft.net>
M: Masami Hiramatsu <mhiramat@kernel.org>
@ -8628,7 +8630,7 @@ MARVELL MWIFIEX WIRELESS DRIVER
M: Amitkumar Karwar <amitkarwar@gmail.com>
M: Nishant Sarmukadam <nishants@marvell.com>
M: Ganapathi Bhat <gbhat@marvell.com>
M: Xinming Hu <huxm@marvell.com>
M: Xinming Hu <huxinming820@gmail.com>
L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/net/wireless/marvell/mwifiex/
@ -9074,7 +9076,7 @@ S: Maintained
F: drivers/usb/mtu3/
MEGACHIPS STDPXXXX-GE-B850V3-FW LVDS/DP++ BRIDGES
M: Peter Senna Tschudin <peter.senna@collabora.com>
M: Peter Senna Tschudin <peter.senna@gmail.com>
M: Martin Donnelly <martin.donnelly@ge.com>
M: Martyn Welch <martyn.welch@collabora.co.uk>
S: Maintained
@ -10214,11 +10216,13 @@ F: sound/soc/codecs/sgtl5000*
NXP TDA998X DRM DRIVER
M: Russell King <linux@armlinux.org.uk>
S: Supported
S: Maintained
T: git git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel
T: git git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-fixes
F: drivers/gpu/drm/i2c/tda998x_drv.c
F: include/drm/i2c/tda998x.h
F: include/dt-bindings/display/tda998x.h
K: "nxp,tda998x"
NXP TFA9879 DRIVER
M: Peter Rosin <peda@axentia.se>
@ -11836,7 +11840,7 @@ S: Supported
F: arch/hexagon/
QUALCOMM HIDMA DRIVER
M: Sinan Kaya <okaya@codeaurora.org>
M: Sinan Kaya <okaya@kernel.org>
L: linux-arm-kernel@lists.infradead.org
L: linux-arm-msm@vger.kernel.org
L: dmaengine@vger.kernel.org
@ -12063,6 +12067,13 @@ S: Maintained
F: sound/soc/codecs/rt*
F: include/sound/rt*.h
REALTEK RTL83xx SMI DSA ROUTER CHIPS
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
F: Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
F: drivers/net/dsa/realtek-smi*
F: drivers/net/dsa/rtl83*
REGISTER MAP ABSTRACTION
M: Mark Brown <broonie@kernel.org>
L: linux-kernel@vger.kernel.org

10
Makefile
View File

@ -2,7 +2,7 @@
VERSION = 4
PATCHLEVEL = 18
SUBLEVEL = 0
EXTRAVERSION = -rc3
EXTRAVERSION = -rc8
NAME = Merciless Moray
# *DOCUMENTATION*
@ -353,9 +353,9 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
else if [ -x /bin/bash ]; then echo /bin/bash; \
else echo sh; fi ; fi)
HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS)
HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS)
HOST_LFS_LIBS := $(shell getconf LFS_LIBS)
HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS 2>/dev/null)
HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
HOSTCC = gcc
HOSTCXX = g++
@ -1712,6 +1712,6 @@ endif # skip-makefile
PHONY += FORCE
FORCE:
# Declare the contents of the .PHONY variable as phony. We keep that
# Declare the contents of the PHONY variable as phony. We keep that
# information in a variable so we can use it in if_changed and friends.
.PHONY: $(PHONY)

5
arch/alpha/kernel/osf_sys.c
View File

@ -1180,13 +1180,10 @@ SYSCALL_DEFINE2(osf_getrusage, int, who, struct rusage32 __user *, ru)
SYSCALL_DEFINE4(osf_wait4, pid_t, pid, int __user *, ustatus, int, options,
struct rusage32 __user *, ur)
{
unsigned int status = 0;
struct rusage r;
long err = kernel_wait4(pid, &status, options, &r);
long err = kernel_wait4(pid, ustatus, options, &r);
if (err <= 0)
return err;
if (put_user(status, ustatus))
return -EFAULT;
if (!ur)
return err;
if (put_tv_to_tv32(&ur->ru_utime, &r.ru_utime))

5
arch/arc/Kconfig
View File

@ -50,6 +50,9 @@ config ARC
select HAVE_KERNEL_LZMA
select ARCH_HAS_PTE_SPECIAL
config ARCH_HAS_CACHE_LINE_SIZE
def_bool y
config MIGHT_HAVE_PCI
bool
@ -413,7 +416,7 @@ config ARC_HAS_DIV_REM
config ARC_HAS_ACCL_REGS
bool "Reg Pair ACCL:ACCH (FPU and/or MPY > 6)"
default n
default y
help
Depending on the configuration, CPU can contain accumulator reg-pair
(also referred to as r58:r59). These can also be used by gcc as GPR so

15
arch/arc/Makefile
View File

@ -16,7 +16,7 @@ endif
KBUILD_DEFCONFIG := nsim_700_defconfig
cflags-y += -fno-common -pipe -fno-builtin -D__linux__
cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7
cflags-$(CONFIG_ISA_ARCV2) += -mcpu=archs
@ -140,16 +140,3 @@ dtbs: scripts
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
# Hacks to enable final link due to absence of link-time branch relexation
# and gcc choosing optimal(shorter) branches at -O3
#
# vineetg Feb 2010: -mlong-calls switched off for overall kernel build
# However lib/decompress_inflate.o (.init.text) calls
# zlib_inflate_workspacesize (.text) causing relocation errors.
# Thus forcing all exten calls in this file to be long calls
export CFLAGS_decompress_inflate.o = -mmedium-calls
export CFLAGS_initramfs.o = -mmedium-calls
ifdef CONFIG_SMP
export CFLAGS_core.o = -mmedium-calls
endif

1
arch/arc/configs/axs101_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set

1
arch/arc/configs/axs103_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set

1
arch/arc/configs/axs103_smp_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set

1
arch/arc/configs/haps_hs_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EXPERT=y
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set

1
arch/arc/configs/haps_hs_smp_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set

1
arch/arc/configs/hsdk_defconfig
View File

@ -9,7 +9,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y
# CONFIG_VM_EVENT_COUNTERS is not set

1
arch/arc/configs/nsim_700_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y

1
arch/arc/configs/nsim_hs_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y

1
arch/arc/configs/nsim_hs_smp_defconfig
View File

@ -9,7 +9,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y

1
arch/arc/configs/nsimosci_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y

1
arch/arc/configs/nsimosci_hs_defconfig
View File

@ -11,7 +11,6 @@ CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_PERF_EVENTS=y

1
arch/arc/configs/nsimosci_hs_smp_defconfig
View File

@ -9,7 +9,6 @@ CONFIG_IKCONFIG_PROC=y
# CONFIG_UTS_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
CONFIG_PERF_EVENTS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_KPROBES=y

1
arch/arc/configs/tb10x_defconfig
View File

@ -56,7 +56,6 @@ CONFIG_STMMAC_ETH=y
# CONFIG_INPUT is not set
# CONFIG_SERIO is not set
# CONFIG_VT is not set
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_8250=y

4
arch/arc/include/asm/cache.h
View File

@ -48,7 +48,9 @@
})
/* Largest line length for either L1 or L2 is 128 bytes */
#define ARCH_DMA_MINALIGN 128
#define SMP_CACHE_BYTES 128
#define cache_line_size() SMP_CACHE_BYTES
#define ARCH_DMA_MINALIGN SMP_CACHE_BYTES
extern void arc_cache_init(void);
extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len);

3
arch/arc/include/asm/delay.h
View File

@ -17,8 +17,11 @@
#ifndef __ASM_ARC_UDELAY_H
#define __ASM_ARC_UDELAY_H
#include <asm-generic/types.h>
#include <asm/param.h> /* HZ */
extern unsigned long loops_per_jiffy;
static inline void __delay(unsigned long loops)
{
__asm__ __volatile__(

6
arch/arc/include/asm/entry-compact.h
View File

@ -234,6 +234,9 @@
POP gp
RESTORE_R12_TO_R0
#ifdef CONFIG_ARC_CURR_IN_REG
ld r25, [sp, 12]
#endif
ld sp, [sp] /* restore original sp */
/* orig_r0, ECR, user_r25 skipped automatically */
.endm
@ -315,6 +318,9 @@
POP gp
RESTORE_R12_TO_R0
#ifdef CONFIG_ARC_CURR_IN_REG
ld r25, [sp, 12]
#endif
ld sp, [sp] /* restore original sp */
/* orig_r0, ECR, user_r25 skipped automatically */
.endm

3
arch/arc/include/asm/entry.h
View File

@ -86,9 +86,6 @@
POP r1
POP r0
#ifdef CONFIG_ARC_CURR_IN_REG
ld r25, [sp, 12]
#endif
.endm
/*--------------------------------------------------------------

2
arch/arc/include/asm/mach_desc.h
View File

@ -34,9 +34,7 @@ struct machine_desc {
const char *name;
const char **dt_compat;
void (*init_early)(void);
#ifdef CONFIG_SMP
void (*init_per_cpu)(unsigned int);
#endif
void (*init_machine)(void);
void (*init_late)(void);

2
arch/arc/include/asm/page.h
View File

@ -105,7 +105,7 @@ typedef pte_t * pgtable_t;
#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
/* Default Permissions for stack/heaps pages (Non Executable) */
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE)
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
#define WANT_PAGE_VIRTUAL 1

2
arch/arc/include/asm/pgtable.h
View File

@ -377,7 +377,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
/* Decode a PTE containing swap "identifier "into constituents */
#define __swp_type(pte_lookalike) (((pte_lookalike).val) & 0x1f)
#define __swp_offset(pte_lookalike) ((pte_lookalike).val << 13)
#define __swp_offset(pte_lookalike) ((pte_lookalike).val >> 13)
/* NOPs, to keep generic kernel happy */
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })

2
arch/arc/kernel/irq.c
View File

@ -31,10 +31,10 @@ void __init init_IRQ(void)
/* a SMP H/w block could do IPI IRQ request here */
if (plat_smp_ops.init_per_cpu)
plat_smp_ops.init_per_cpu(smp_processor_id());
#endif
if (machine_desc->init_per_cpu)
machine_desc->init_per_cpu(smp_processor_id());
#endif
}
/*

47
arch/arc/kernel/process.c
View File

@ -47,7 +47,8 @@ SYSCALL_DEFINE0(arc_gettls)
SYSCALL_DEFINE3(arc_usr_cmpxchg, int *, uaddr, int, expected, int, new)
{
struct pt_regs *regs = current_pt_regs();
int uval = -EFAULT;
u32 uval;
int ret;
/*
* This is only for old cores lacking LLOCK/SCOND, which by defintion
@ -60,23 +61,47 @@ SYSCALL_DEFINE3(arc_usr_cmpxchg, int *, uaddr, int, expected, int, new)
/* Z indicates to userspace if operation succeded */
regs->status32 &= ~STATUS_Z_MASK;
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
return -EFAULT;
ret = access_ok(VERIFY_WRITE, uaddr, sizeof(*uaddr));
if (!ret)
goto fail;
again:
preempt_disable();
if (__get_user(uval, uaddr))
goto done;
ret = __get_user(uval, uaddr);
if (ret)
goto fault;
if (uval == expected) {
if (!__put_user(new, uaddr))
regs->status32 |= STATUS_Z_MASK;
}
if (uval != expected)
goto out;
done:
ret = __put_user(new, uaddr);
if (ret)
goto fault;
regs->status32 |= STATUS_Z_MASK;
out:
preempt_enable();
return uval;
fault:
preempt_enable();
return uval;
if (unlikely(ret != -EFAULT))
goto fail;
down_read(&current->mm->mmap_sem);
ret = fixup_user_fault(current, current->mm, (unsigned long) uaddr,
FAULT_FLAG_WRITE, NULL);
up_read(&current->mm->mmap_sem);
if (likely(!ret))
goto again;
fail:
force_sig(SIGSEGV, current);
return ret;
}
#ifdef CONFIG_ISA_ARCV2

17
arch/arc/mm/cache.c
View File

@ -1038,7 +1038,7 @@ void flush_cache_mm(struct mm_struct *mm)
void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
unsigned long pfn)
{
unsigned int paddr = pfn << PAGE_SHIFT;
phys_addr_t paddr = pfn << PAGE_SHIFT;
u_vaddr &= PAGE_MASK;
@ -1058,8 +1058,9 @@ void flush_anon_page(struct vm_area_struct *vma, struct page *page,
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
__flush_dcache_page(page_address(page), u_vaddr);
__flush_dcache_page(page_address(page), page_address(page));
__flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
__flush_dcache_page((phys_addr_t)page_address(page),
(phys_addr_t)page_address(page));
}
@ -1246,6 +1247,16 @@ void __init arc_cache_init_master(void)
}
}
/*
* Check that SMP_CACHE_BYTES (and hence ARCH_DMA_MINALIGN) is larger
* or equal to any cache line length.
*/
BUILD_BUG_ON_MSG(L1_CACHE_BYTES > SMP_CACHE_BYTES,
"SMP_CACHE_BYTES must be >= any cache line length");
if (is_isa_arcv2() && (l2_line_sz > SMP_CACHE_BYTES))
panic("L2 Cache line [%d] > kernel Config [%d]\n",
l2_line_sz, SMP_CACHE_BYTES);
/* Note that SLC disable not formally supported till HS 3.0 */
if (is_isa_arcv2() && l2_line_sz && !slc_enable)
arc_slc_disable();

49
arch/arc/mm/dma.c
View File

@ -129,14 +129,59 @@ int arch_dma_mmap(struct device *dev, struct vm_area_struct *vma,
return ret;
}
/*
* Cache operations depending on function and direction argument, inspired by
* https://lkml.org/lkml/2018/5/18/979
* "dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20]
* dma-mapping: provide a generic dma-noncoherent implementation)"
*
* | map == for_device | unmap == for_cpu
* |----------------------------------------------------------------
* TO_DEV | writeback writeback | none none
* FROM_DEV | invalidate invalidate | invalidate* invalidate*
* BIDIR | writeback+inv writeback+inv | invalidate invalidate
*
* [*] needed for CPU speculative prefetches
*
* NOTE: we don't check the validity of direction argument as it is done in
* upper layer functions (in include/linux/dma-mapping.h)
*/
void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
size_t size, enum dma_data_direction dir)
{
dma_cache_wback(paddr, size);
switch (dir) {
case DMA_TO_DEVICE:
dma_cache_wback(paddr, size);
break;
case DMA_FROM_DEVICE:
dma_cache_inv(paddr, size);
break;
case DMA_BIDIRECTIONAL:
dma_cache_wback_inv(paddr, size);
break;
default:
break;
}
}
void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr,
size_t size, enum dma_data_direction dir)
{
dma_cache_inv(paddr, size);
switch (dir) {
case DMA_TO_DEVICE:
break;
/* FROM_DEVICE invalidate needed if speculative CPU prefetch only */
case DMA_FROM_DEVICE:
case DMA_BIDIRECTIONAL:
dma_cache_inv(paddr, size);
break;
default:
break;
}
}

10
arch/arc/plat-eznps/include/plat/ctop.h
View File

@ -21,6 +21,7 @@
#error "Incorrect ctop.h include"
#endif
#include <linux/types.h>
#include <soc/nps/common.h>
/* core auxiliary registers */
@ -143,6 +144,15 @@ struct nps_host_reg_gim_p_int_dst {
};
/* AUX registers definition */
struct nps_host_reg_aux_dpc {
union {
struct {
u32 ien:1, men:1, hen:1, reserved:29;
};
u32 value;
};
};
struct nps_host_reg_aux_udmc {
union {
struct {

6
arch/arc/plat-eznps/mtm.c
View File

@ -15,6 +15,8 @@
*/
#include <linux/smp.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/io.h>
#include <linux/log2.h>
#include <asm/arcregs.h>
@ -157,10 +159,10 @@ void mtm_enable_core(unsigned int cpu)
/* Verify and set the value of the mtm hs counter */
static int __init set_mtm_hs_ctr(char *ctr_str)
{
long hs_ctr;
int hs_ctr;
int ret;
ret = kstrtol(ctr_str, 0, &hs_ctr);
ret = kstrtoint(ctr_str, 0, &hs_ctr);
if (ret || hs_ctr > MT_HS_CNT_MAX || hs_ctr < MT_HS_CNT_MIN) {
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d] (incl)\n",

3
arch/arc/plat-hsdk/Kconfig
View File

@ -7,5 +7,8 @@
menuconfig ARC_SOC_HSDK
bool "ARC HS Development Kit SOC"
depends on ISA_ARCV2
select ARC_HAS_ACCL_REGS
select CLK_HSDK
select RESET_HSDK
select MIGHT_HAVE_PCI

62
arch/arc/plat-hsdk/platform.c
View File

@ -42,6 +42,66 @@ static void __init hsdk_init_per_cpu(unsigned int cpu)
#define SDIO_UHS_REG_EXT (SDIO_BASE + 0x108)
#define SDIO_UHS_REG_EXT_DIV_2 (2 << 30)
#define HSDK_GPIO_INTC (ARC_PERIPHERAL_BASE + 0x3000)
static void __init hsdk_enable_gpio_intc_wire(void)
{
/*
* Peripherals on CPU Card are wired to cpu intc via intermediate
* DW APB GPIO blocks (mainly for debouncing)
*
* ---------------------
* | snps,archs-intc |
* ---------------------
* |
* ----------------------
* | snps,archs-idu-intc |
* ----------------------
* | | | | |
* | [eth] [USB] [... other peripherals]
* |
* -------------------
* | snps,dw-apb-intc |
* -------------------
* | | | |
* [Bt] [HAPS] [... other peripherals]
*
* Current implementation of "irq-dw-apb-ictl" driver doesn't work well
* with stacked INTCs. In particular problem happens if its master INTC
* not yet instantiated. See discussion here -
* https://lkml.org/lkml/2015/3/4/755
*
* So setup the first gpio block as a passive pass thru and hide it from
* DT hardware topology - connect intc directly to cpu intc
* The GPIO "wire" needs to be init nevertheless (here)
*
* One side adv is that peripheral interrupt handling avoids one nested
* intc ISR hop
*
* According to HSDK User's Manual [1], "Table 2 Interrupt Mapping"
* we have the following GPIO input lines used as sources of interrupt:
* - GPIO[0] - Bluetooth interrupt of RS9113 module
* - GPIO[2] - HAPS interrupt (on HapsTrak 3 connector)
* - GPIO[3] - Audio codec (MAX9880A) interrupt
* - GPIO[8-23] - Available on Arduino and PMOD_x headers
* For now there's no use of Arduino and PMOD_x headers in Linux
* use-case so we only enable lines 0, 2 and 3.
*
* [1] https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/wiki/docs/ARC_HSDK_User_Guide.pdf
*/
#define GPIO_INTEN (HSDK_GPIO_INTC + 0x30)
#define GPIO_INTMASK (HSDK_GPIO_INTC + 0x34)
#define GPIO_INTTYPE_LEVEL (HSDK_GPIO_INTC + 0x38)
#define GPIO_INT_POLARITY (HSDK_GPIO_INTC + 0x3c)
#define GPIO_INT_CONNECTED_MASK 0x0d
iowrite32(0xffffffff, (void __iomem *) GPIO_INTMASK);
iowrite32(~GPIO_INT_CONNECTED_MASK, (void __iomem *) GPIO_INTMASK);
iowrite32(0x00000000, (void __iomem *) GPIO_INTTYPE_LEVEL);
iowrite32(0xffffffff, (void __iomem *) GPIO_INT_POLARITY);
iowrite32(GPIO_INT_CONNECTED_MASK, (void __iomem *) GPIO_INTEN);
}
static void __init hsdk_init_early(void)
{
/*
@ -62,6 +122,8 @@ static void __init hsdk_init_early(void)
* minimum possible div-by-2.
*/
iowrite32(SDIO_UHS_REG_EXT_DIV_2, (void __iomem *) SDIO_UHS_REG_EXT);
hsdk_enable_gpio_intc_wire();
}
static const char *hsdk_compat[] __initconst = {

1
arch/arm/boot/dts/am335x-bone-common.dtsi
View File

@ -168,7 +168,6 @@
AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_dat3.mmc0_dat3 */
AM33XX_IOPAD(0x904, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_cmd.mmc0_cmd */
AM33XX_IOPAD(0x900, PIN_INPUT_PULLUP | MUX_MODE0) /* mmc0_clk.mmc0_clk */
AM33XX_IOPAD(0x9a0, PIN_INPUT | MUX_MODE4) /* mcasp0_aclkr.mmc0_sdwp */
>;
};

9
arch/arm/boot/dts/am3517.dtsi
View File

@ -39,6 +39,8 @@
ti,davinci-ctrl-ram-size = <0x2000>;
ti,davinci-rmii-en = /bits/ 8 <1>;
local-mac-address = [ 00 00 00 00 00 00 ];
clocks = <&emac_ick>;
clock-names = "ick";
};
davinci_mdio: ethernet@5c030000 {
@ -49,6 +51,8 @@
bus_freq = <1000000>;
#address-cells = <1>;
#size-cells = <0>;
clocks = <&emac_fck>;
clock-names = "fck";
};
uart4: serial@4809e000 {
@ -87,6 +91,11 @@
};
};
/* Table Table 5-79 of the TRM shows 480ab000 is reserved */
&usb_otg_hs {
status = "disabled";
};
&iva {
status = "disabled";
};

2
arch/arm/boot/dts/am437x-sk-evm.dts
View File

@ -610,6 +610,8 @@
touchscreen-size-x = <480>;
touchscreen-size-y = <272>;
wakeup-source;
};
tlv320aic3106: tlv320aic3106@1b {

2
arch/arm/boot/dts/armada-38x.dtsi
View File

@ -547,7 +547,7 @@
thermal: thermal@e8078 {
compatible = "marvell,armada380-thermal";
reg = <0xe4078 0x4>, <0xe4074 0x4>;
reg = <0xe4078 0x4>, <0xe4070 0x8>;
status = "okay";
};

2
arch/arm/boot/dts/dra7.dtsi
View File

@ -1580,7 +1580,6 @@
dr_mode = "otg";
snps,dis_u3_susphy_quirk;
snps,dis_u2_susphy_quirk;
snps,dis_metastability_quirk;
};
};
@ -1608,6 +1607,7 @@
dr_mode = "otg";
snps,dis_u3_susphy_quirk;
snps,dis_u2_susphy_quirk;
snps,dis_metastability_quirk;
};
};

140
arch/arm/boot/dts/gemini-dlink-dir-685.dts
View File

@ -156,6 +156,100 @@
};
};
/* This is a RealTek RTL8366RB switch and PHY using SMI over GPIO */
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>;
realtek,disable-leds;
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>;
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>;
};
rtl8366rb_cpu_port: port@5 {
reg = <5>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
mdio {
compatible = "realtek,smi-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>;
};
};
};
soc {
flash@30000000 {
/*
@ -223,10 +317,12 @@
* gpio0bgrp cover line 7 used by WPS LED
* gpio0cgrp cover line 8, 13 used by keys
* and 11, 12 used by the HD LEDs
* and line 14, 15 used by RTL8366
* RESET and phy ready
* gpio0egrp cover line 16 used by VDISP
* gpio0fgrp cover line 17 used by TK IRQ
* gpio0ggrp cover line 20 used by panel CS
* gpio0hgrp cover line 21,22 used by RTL8366RB
* gpio0hgrp cover line 21,22 used by RTL8366RB MDIO
*/
gpio0_default_pins: pinctrl-gpio0 {
mux {
@ -250,6 +346,32 @@
groups = "gpio1bgrp";
};
};
pinctrl-gmii {
mux {
function = "gmii";
groups = "gmii_gmac0_grp";
};
conf0 {
pins = "V8 GMAC0 RXDV", "T10 GMAC1 RXDV",
"Y7 GMAC0 RXC", "Y11 GMAC1 RXC",
"T8 GMAC0 TXEN", "W11 GMAC1 TXEN",
"U8 GMAC0 TXC", "V11 GMAC1 TXC",
"W8 GMAC0 RXD0", "V9 GMAC0 RXD1",
"Y8 GMAC0 RXD2", "U9 GMAC0 RXD3",
"T7 GMAC0 TXD0", "U6 GMAC0 TXD1",
"V7 GMAC0 TXD2", "U7 GMAC0 TXD3",
"Y12 GMAC1 RXD0", "V12 GMAC1 RXD1",
"T11 GMAC1 RXD2", "W12 GMAC1 RXD3",
"U10 GMAC1 TXD0", "Y10 GMAC1 TXD1",
"W10 GMAC1 TXD2", "T9 GMAC1 TXD3";
skew-delay = <7>;
};
/* Set up drive strength on GMAC0 to 16 mA */
conf1 {
groups = "gmii_gmac0_grp";
drive-strength = <16>;
};
};
};
};
@ -291,6 +413,22 @@
<0x6000 0 0 4 &pci_intc 2>;
};
ethernet@60000000 {
status = "okay";
ethernet-port@0 {
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
ethernet-port@1 {
/* Not used in this platform */
};
};
ata@63000000 {
status = "okay";
};

2
arch/arm/boot/dts/imx51-zii-rdu1.dts
View File

@ -770,7 +770,7 @@
pinctrl_ts: tsgrp {
fsl,pins = <
MX51_PAD_CSI1_D8__GPIO3_12 0x85
MX51_PAD_CSI1_D8__GPIO3_12 0x04
MX51_PAD_CSI1_D9__GPIO3_13 0x85
>;
};

2
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
View File

@ -692,7 +692,7 @@
dsa,member = <0 0>;
eeprom-length = <512>;
interrupt-parent = <&gpio6>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;

9
arch/arm/boot/dts/omap4-droid4-xt894.dts
View File

@ -159,13 +159,7 @@
dais = <&mcbsp2_port>, <&mcbsp3_port>;
};
};
&dss {
status = "okay";
};
&gpio6 {
pwm8: dmtimer-pwm-8 {
pinctrl-names = "default";
pinctrl-0 = <&vibrator_direction_pin>;
@ -192,7 +186,10 @@
pwm-names = "enable", "direction";
direction-duty-cycle-ns = <10000000>;
};
};
&dss {
status = "okay";
};
&dsi1 {

2
arch/arm/configs/imx_v4_v5_defconfig
View File

@ -141,9 +141,11 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_USB_CHIPIDEA_ULPI=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_GADGET=y
CONFIG_USB_ETH=m
CONFIG_USB_ULPI_BUS=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y

2
arch/arm/configs/imx_v6_v7_defconfig
View File

@ -302,6 +302,7 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_USB_CHIPIDEA_ULPI=y
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=m
@ -338,6 +339,7 @@ CONFIG_USB_GADGETFS=m
CONFIG_USB_FUNCTIONFS=m
CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_ULPI_BUS=y
CONFIG_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y

6
arch/arm/crypto/speck-neon-core.S
View File

@ -272,9 +272,11 @@
* Allocate stack space to store 128 bytes worth of tweaks. For
* performance, this space is aligned to a 16-byte boundary so that we
* can use the load/store instructions that declare 16-byte alignment.
* For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
*/
sub sp, #128
bic sp, #0xf
sub r12, sp, #128
bic r12, #0xf
mov sp, r12
.if \n == 64
// Load first tweak

3
arch/arm/firmware/Makefile
View File

@ -1 +1,4 @@
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
# tf_generic_smc() fails to build with -fsanitize-coverage=trace-pc
KCOV_INSTRUMENT := n

4
arch/arm/kernel/entry-common.S
View File

@ -48,6 +48,7 @@ saved_pc .req lr
* from those features make this path too inefficient.
*/
ret_fast_syscall:
__ret_fast_syscall:
UNWIND(.fnstart )
UNWIND(.cantunwind )
disable_irq_notrace @ disable interrupts
@ -78,6 +79,7 @@ fast_work_pending:
* call.
*/
ret_fast_syscall:
__ret_fast_syscall:
UNWIND(.fnstart )
UNWIND(.cantunwind )
str r0, [sp, #S_R0 + S_OFF]! @ save returned r0
@ -255,7 +257,7 @@ local_restart:
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
bne __sys_trace
invoke_syscall tbl, scno, r10, ret_fast_syscall
invoke_syscall tbl, scno, r10, __ret_fast_syscall
add r1, sp, #S_OFF
2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)

2
arch/arm/kernel/head-nommu.S
View File

@ -177,7 +177,7 @@ M_CLASS(streq r3, [r12, #PMSAv8_MAIR1])
bic r0, r0, #CR_I
#endif
mcr p15, 0, r0, c1, c0, 0 @ write control reg
isb
instr_sync
#elif defined (CONFIG_CPU_V7M)
#ifdef CONFIG_ARM_MPU
ldreq r3, [r12, MPU_CTRL]

1
arch/arm/kernel/process.c
View File

@ -338,6 +338,7 @@ static struct vm_area_struct gate_vma = {
static int __init gate_vma_init(void)
{
vma_init(&gate_vma, NULL);
gate_vma.vm_page_prot = PAGE_READONLY_EXEC;
return 0;
}

41
arch/arm/mach-omap2/omap-smp.c
View File

@ -109,6 +109,45 @@ void omap5_erratum_workaround_801819(void)
static inline void omap5_erratum_workaround_801819(void) { }
#endif
#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
/*
* Configure ACR and enable ACTLR[0] (Enable invalidates of BTB with
* ICIALLU) to activate the workaround for secondary Core.
* NOTE: it is assumed that the primary core's configuration is done
* by the boot loader (kernel will detect a misconfiguration and complain
* if this is not done).
*
* In General Purpose(GP) devices, ACR bit settings can only be done
* by ROM code in "secure world" using the smc call and there is no
* option to update the "firmware" on such devices. This also works for
* High security(HS) devices, as a backup option in case the
* "update" is not done in the "security firmware".
*/
static void omap5_secondary_harden_predictor(void)
{
u32 acr, acr_mask;
asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr));
/*
* ACTLR[0] (Enable invalidates of BTB with ICIALLU)
*/
acr_mask = BIT(0);
/* Do we already have it done.. if yes, skip expensive smc */
if ((acr & acr_mask) == acr_mask)
return;
acr |= acr_mask;
omap_smc1(OMAP5_DRA7_MON_SET_ACR_INDEX, acr);
pr_debug("%s: ARM ACR setup for CVE_2017_5715 applied on CPU%d\n",
__func__, smp_processor_id());
}
#else
static inline void omap5_secondary_harden_predictor(void) { }
#endif
static void omap4_secondary_init(unsigned int cpu)
{
/*
@ -131,6 +170,8 @@ static void omap4_secondary_init(unsigned int cpu)
set_cntfreq();
/* Configure ACR to disable streaming WA for 801819 */
omap5_erratum_workaround_801819();
/* Enable ACR to allow for ICUALLU workaround */
omap5_secondary_harden_predictor();
}
/*

4
arch/arm/mach-pxa/irq.c
View File

@ -185,7 +185,7 @@ static int pxa_irq_suspend(void)
{
int i;
for (i = 0; i < pxa_internal_irq_nr / 32; i++) {
for (i = 0; i < DIV_ROUND_UP(pxa_internal_irq_nr, 32); i++) {
void __iomem *base = irq_base(i);
saved_icmr[i] = __raw_readl(base + ICMR);
@ -204,7 +204,7 @@ static void pxa_irq_resume(void)
{
int i;
for (i = 0; i < pxa_internal_irq_nr / 32; i++) {
for (i = 0; i < DIV_ROUND_UP(pxa_internal_irq_nr, 32); i++) {
void __iomem *base = irq_base(i);
__raw_writel(saved_icmr[i], base + ICMR);

5
arch/arm/mach-rpc/ecard.c
View File

@ -212,7 +212,7 @@ static DEFINE_MUTEX(ecard_mutex);
*/
static void ecard_init_pgtables(struct mm_struct *mm)
{
struct vm_area_struct vma;
struct vm_area_struct vma = TLB_FLUSH_VMA(mm, VM_EXEC);
/* We want to set up the page tables for the following mapping:
* Virtual Physical
@ -237,9 +237,6 @@ static void ecard_init_pgtables(struct mm_struct *mm)
memcpy(dst_pgd, src_pgd, sizeof(pgd_t) * (EASI_SIZE / PGDIR_SIZE));
vma.vm_flags = VM_EXEC;
vma.vm_mm = mm;
flush_tlb_range(&vma, IO_START, IO_START + IO_SIZE);
flush_tlb_range(&vma, EASI_START, EASI_START + EASI_SIZE);
}

9
arch/arm/mm/init.c
View File

@ -736,20 +736,29 @@ static int __mark_rodata_ro(void *unused)
return 0;
}
static int kernel_set_to_readonly __read_mostly;
void mark_rodata_ro(void)
{
kernel_set_to_readonly = 1;
stop_machine(__mark_rodata_ro, NULL, NULL);
debug_checkwx();
}
void set_kernel_text_rw(void)
{
if (!kernel_set_to_readonly)
return;
set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), false,
current->active_mm);
}
void set_kernel_text_ro(void)
{
if (!kernel_set_to_readonly)
return;
set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
current->active_mm);
}

1060
arch/arm/net/bpf_jit_32.c
View File

File diff suppressed because it is too large Load Diff

42
arch/arm/net/bpf_jit_32.h
View File

@ -77,11 +77,14 @@
#define ARM_INST_EOR_R 0x00200000
#define ARM_INST_EOR_I 0x02200000
#define ARM_INST_LDRB_I 0x05d00000
#define ARM_INST_LDST__U 0x00800000
#define ARM_INST_LDST__IMM12 0x00000fff
#define ARM_INST_LDRB_I 0x05500000
#define ARM_INST_LDRB_R 0x07d00000
#define ARM_INST_LDRH_I 0x01d000b0
#define ARM_INST_LDRD_I 0x014000d0
#define ARM_INST_LDRH_I 0x015000b0
#define ARM_INST_LDRH_R 0x019000b0
#define ARM_INST_LDR_I 0x05900000
#define ARM_INST_LDR_I 0x05100000
#define ARM_INST_LDR_R 0x07900000
#define ARM_INST_LDM 0x08900000
@ -124,9 +127,10 @@
#define ARM_INST_SBC_R 0x00c00000
#define ARM_INST_SBCS_R 0x00d00000
#define ARM_INST_STR_I 0x05800000
#define ARM_INST_STRB_I 0x05c00000
#define ARM_INST_STRH_I 0x01c000b0
#define ARM_INST_STR_I 0x05000000
#define ARM_INST_STRB_I 0x05400000
#define ARM_INST_STRD_I 0x014000f0
#define ARM_INST_STRH_I 0x014000b0
#define ARM_INST_TST_R 0x01100000
#define ARM_INST_TST_I 0x03100000
@ -183,17 +187,18 @@
#define ARM_EOR_R(rd, rn, rm) _AL3_R(ARM_INST_EOR, rd, rn, rm)
#define ARM_EOR_I(rd, rn, imm) _AL3_I(ARM_INST_EOR, rd, rn, imm)
#define ARM_LDR_I(rt, rn, off) (ARM_INST_LDR_I | (rt) << 12 | (rn) << 16 \
| ((off) & 0xfff))
#define ARM_LDR_R(rt, rn, rm) (ARM_INST_LDR_R | (rt) << 12 | (rn) << 16 \
#define ARM_LDR_R(rt, rn, rm) (ARM_INST_LDR_R | ARM_INST_LDST__U \
| (rt) << 12 | (rn) << 16 \
| (rm))
#define ARM_LDRB_I(rt, rn, off) (ARM_INST_LDRB_I | (rt) << 12 | (rn) << 16 \
| (off))
#define ARM_LDRB_R(rt, rn, rm) (ARM_INST_LDRB_R | (rt) << 12 | (rn) << 16 \
#define ARM_LDR_R_SI(rt, rn, rm, type, imm) \
(ARM_INST_LDR_R | ARM_INST_LDST__U \
| (rt) << 12 | (rn) << 16 \
| (imm) << 7 | (type) << 5 | (rm))
#define ARM_LDRB_R(rt, rn, rm) (ARM_INST_LDRB_R | ARM_INST_LDST__U \
| (rt) << 12 | (rn) << 16 \
| (rm))
#define ARM_LDRH_I(rt, rn, off) (ARM_INST_LDRH_I | (rt) << 12 | (rn) << 16 \
| (((off) & 0xf0) << 4) | ((off) & 0xf))
#define ARM_LDRH_R(rt, rn, rm) (ARM_INST_LDRH_R | (rt) << 12 | (rn) << 16 \
#define ARM_LDRH_R(rt, rn, rm) (ARM_INST_LDRH_R | ARM_INST_LDST__U \
| (rt) << 12 | (rn) << 16 \
| (rm))
#define ARM_LDM(rn, regs) (ARM_INST_LDM | (rn) << 16 | (regs))
@ -254,13 +259,6 @@
#define ARM_SUBS_I(rd, rn, imm) _AL3_I(ARM_INST_SUBS, rd, rn, imm)
#define ARM_SBC_I(rd, rn, imm) _AL3_I(ARM_INST_SBC, rd, rn, imm)
#define ARM_STR_I(rt, rn, off) (ARM_INST_STR_I | (rt) << 12 | (rn) << 16 \
| ((off) & 0xfff))
#define ARM_STRH_I(rt, rn, off) (ARM_INST_STRH_I | (rt) << 12 | (rn) << 16 \
| (((off) & 0xf0) << 4) | ((off) & 0xf))
#define ARM_STRB_I(rt, rn, off) (ARM_INST_STRB_I | (rt) << 12 | (rn) << 16 \
| (((off) & 0xf0) << 4) | ((off) & 0xf))
#define ARM_TST_R(rn, rm) _AL3_R(ARM_INST_TST, 0, rn, rm)
#define ARM_TST_I(rn, imm) _AL3_I(ARM_INST_TST, 0, rn, imm)

10
arch/arm64/Makefile
View File

@ -10,7 +10,7 @@
#
# Copyright (C) 1995-2001 by Russell King
LDFLAGS_vmlinux :=-p --no-undefined -X
LDFLAGS_vmlinux :=--no-undefined -X
CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
GZFLAGS :=-9
@ -60,15 +60,15 @@ ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
KBUILD_CPPFLAGS += -mbig-endian
CHECKFLAGS += -D__AARCH64EB__
AS += -EB
LD += -EB
LDFLAGS += -maarch64linuxb
# We must use the linux target here, since distributions don't tend to package
# the ELF linker scripts with binutils, and this results in a build failure.
LDFLAGS += -EB -maarch64linuxb
UTS_MACHINE := aarch64_be
else
KBUILD_CPPFLAGS += -mlittle-endian
CHECKFLAGS += -D__AARCH64EL__
AS += -EL
LD += -EL
LDFLAGS += -maarch64linux
LDFLAGS += -EL -maarch64linux # See comment above
UTS_MACHINE := aarch64
endif

4
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
View File

@ -482,9 +482,9 @@
status = "disabled";
};
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>;

4
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
View File

@ -278,9 +278,9 @@
#include "stingray-pinctrl.dtsi"
mdio_mux_iproc: mdio-mux@2023c {
mdio_mux_iproc: mdio-mux@20000 {
compatible = "brcm,mdio-mux-iproc";
reg = <0x0002023c 0x14>;
reg = <0x00020000 0x250>;
#address-cells = <1>;
#size-cells = <0>;

Some files were not shown because too many files have changed in this diff Show More