diff options
Diffstat (limited to 'Documentation')
53 files changed, 4653 insertions, 677 deletions
diff --git a/Documentation/ABI/removed/ip_queue b/Documentation/ABI/removed/ip_queue new file mode 100644 index 00000000000..3243613bc2d --- /dev/null +++ b/Documentation/ABI/removed/ip_queue @@ -0,0 +1,9 @@ +What: ip_queue +Date: finally removed in kernel v3.5.0 +Contact: Pablo Neira Ayuso <pablo@netfilter.org> +Description: + ip_queue has been replaced by nfnetlink_queue which provides + more advanced queueing mechanism to user-space. The ip_queue + module was already announced to become obsolete years ago. + +Users: diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index b218e0f8bdb..c81fe89c4c4 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -14,6 +14,15 @@ Description: mesh will be sent using multiple interfaces at the same time (if available). +What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance +Date: November 2011 +Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> +Description: + Indicates whether the bridge loop avoidance feature + is enabled. This feature detects and avoids loops + between the mesh and devices bridged with the soft + interface <mesh_iface>. + What: /sys/class/net/<mesh_iface>/mesh/fragmentation Date: October 2010 Contact: Andreas Langer <an.langer@gmx.de> diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index c5ac6929c41..f3e214f9e25 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -516,7 +516,7 @@ !Finclude/net/mac80211.h ieee80211_start_tx_ba_cb_irqsafe !Finclude/net/mac80211.h ieee80211_stop_tx_ba_session !Finclude/net/mac80211.h ieee80211_stop_tx_ba_cb_irqsafe -!Finclude/net/mac80211.h rate_control_changed +!Finclude/net/mac80211.h ieee80211_rate_control_changed !Finclude/net/mac80211.h ieee80211_tx_rate_control !Finclude/net/mac80211.h rate_control_send_low </chapter> diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index 375d3fb7143..4ddf3913fd8 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -47,6 +47,16 @@ irqreader Says to invoke RCU readers from irq level. This is currently permit this. (Or, more accurately, variants of RCU that do -not- permit this know to ignore this variable.) +n_barrier_cbs If this is nonzero, RCU barrier testing will be conducted, + in which case n_barrier_cbs specifies the number of + RCU callbacks (and corresponding kthreads) to use for + this testing. The value cannot be negative. If you + specify this to be non-zero when torture_type indicates a + synchronous RCU implementation (one for which a member of + the synchronize_rcu() rather than the call_rcu() family is + used -- see the documentation for torture_type below), an + error will be reported and no testing will be carried out. + nfakewriters This is the number of RCU fake writer threads to run. Fake writer threads repeatedly use the synchronous "wait for current readers" function of the interface selected by @@ -188,7 +198,7 @@ OUTPUT The statistics output is as follows: rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 - rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767 + rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767 rcu-torture: Reader Pipe: 727860534 34213 0 0 0 0 0 0 0 0 0 rcu-torture: Reader Batch: 727877838 17003 0 0 0 0 0 0 0 0 0 rcu-torture: Free-Block Circulation: 155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0 @@ -230,6 +240,9 @@ o "rtmbe": A non-zero value indicates that rcutorture believes that rcu_assign_pointer() and rcu_dereference() are not working correctly. This value should be zero. +o "rtbe": A non-zero value indicates that one of the rcu_barrier() + family of functions is not working correctly. + o "rtbke": rcutorture was unable to create the real-time kthreads used to force RCU priority inversion. This value should be zero. diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index 91c24a1e8a9..36420e116c9 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -4,8 +4,6 @@ Booting - requirements for booting Interrupts - ARM Interrupt subsystem documentation -IXP2000 - - Release Notes for Linux on Intel's IXP2000 Network Processor msm - MSM specific documentation Netwinder diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000 deleted file mode 100644 index 68d21d92a30..00000000000 --- a/Documentation/arm/IXP2000 +++ /dev/null @@ -1,69 +0,0 @@ - -------------------------------------------------------------------------- -Release Notes for Linux on Intel's IXP2000 Network Processor - -Maintained by Deepak Saxena <dsaxena@plexity.net> -------------------------------------------------------------------------- - -1. Overview - -Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed -for high-performance network applications such high-availability -telecom systems. In addition to an XScale core, it contains up to 8 -"MicroEngines" that run special code, several high-end networking -interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port, -flash interface, and some other odds and ends. For more information, see: - -http://developer.intel.com - -2. Linux Support - -Linux currently supports the following features on the IXP2000 NPUs: - -- On-chip serial -- PCI -- Flash (MTD/JFFS2) -- I2C through GPIO -- Timers (watchdog, OS) - -That is about all we can support under Linux ATM b/c the core networking -components of the chip are accessed via Intel's closed source SDK. -Please contact Intel directly on issues with using those. There is -also a mailing list run by some folks at Princeton University that might -be of help: https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx - -WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL -MAILING LISTS REGARDING THE INTEL SDK. - -3. Supported Platforms - -- Intel IXDP2400 Reference Platform -- Intel IXDP2800 Reference Platform -- Intel IXDP2401 Reference Platform -- Intel IXDP2801 Reference Platform -- RadiSys ENP-2611 - -4. Usage Notes - -- The IXP2000 platforms usually have rather complex PCI bus topologies - with large memory space requirements. In addition, b/c of the way the - Intel SDK is designed, devices are enumerated in a very specific - way. B/c of this this, we use "pci=firmware" option in the kernel - command line so that we do not re-enumerate the bus. - -- IXDP2x01 systems have variable clock tick rates that we cannot determine - via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you - to pass the clock rate to the board port. - -5. Thanks - -The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc. - -The following people have contributed patches/comments/etc: - -Naeem F. Afzal -Lennert Buytenhek -Jeffrey Daly - -------------------------------------------------------------------------- -Last Update: 8/09/2004 diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt new file mode 100644 index 00000000000..52478c83d0c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -0,0 +1,27 @@ +* ARM architected timer + +ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which +provides per-cpu timers. + +The timer is attached to a GIC to deliver its per-processor interrupts. + +** Timer node properties: + +- compatible : Should at least contain "arm,armv7-timer". + +- interrupts : Interrupt list for secure, non-secure, virtual and + hypervisor timers, in that order. + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +Example: + + timer { + compatible = "arm,cortex-a15-timer", + "arm,armv7-timer"; + interrupts = <1 13 0xf08>, + <1 14 0xf08>, + <1 11 0xf08>, + <1 10 0xf08>; + clock-frequency = <100000000>; + }; diff --git a/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt new file mode 100644 index 00000000000..539adca19e8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt @@ -0,0 +1,38 @@ +* NXP LPC32xx Main Interrupt Controller + (MIC, including SIC1 and SIC2 secondary controllers) + +Required properties: +- compatible: Should be "nxp,lpc3220-mic" +- interrupt-controller: Identifies the node as an interrupt controller. +- interrupt-parent: Empty for the interrupt controller itself +- #interrupt-cells: The number of cells to define the interrupts. Should be 2. + The first cell is the IRQ number + The second cell is used to specify mode: + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + Default for internal sources should be set to 4 (active high). +- reg: Should contain MIC registers location and length + +Examples: + /* + * MIC + */ + mic: interrupt-controller@40008000 { + compatible = "nxp,lpc3220-mic"; + interrupt-controller; + interrupt-parent; + #interrupt-cells = <2>; + reg = <0x40008000 0xC000>; + }; + + /* + * ADC + */ + adc@40048000 { + compatible = "nxp,lpc3220-adc"; + reg = <0x40048000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <39 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/lpc32xx.txt b/Documentation/devicetree/bindings/arm/lpc32xx.txt new file mode 100644 index 00000000000..56ec8ddc4a3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/lpc32xx.txt @@ -0,0 +1,8 @@ +NXP LPC32xx Platforms Device Tree Bindings +------------------------------------------ + +Boards with the NXP LPC32xx SoC shall have the following properties: + +Required root node property: + +compatible: must be "nxp,lpc3220", "nxp,lpc3230", "nxp,lpc3240" or "nxp,lpc3250" diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt new file mode 100644 index 00000000000..80b9a94d9a2 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt @@ -0,0 +1,40 @@ +* Marvell MMP Interrupt controller + +Required properties: +- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or + "mrvl,mmp2-mux-intc" +- reg : Address and length of the register set of the interrupt controller. + If the interrupt controller is intc, address and length means the range + of the whold interrupt controller. If the interrupt controller is mux-intc, + address and length means one register. Since address of mux-intc is in the + range of intc. mux-intc is secondary interrupt controller. +- reg-names : Name of the register set of the interrupt controller. It's + only required in mux-intc interrupt controller. +- interrupts : Should be the port interrupt shared by mux interrupts. It's + only required in mux-intc interrupt controller. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. +- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt + controller. +- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge + detection first. + +Example: + intc: interrupt-controller@d4282000 { + compatible = "mrvl,mmp2-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xd4282000 0x1000>; + mrvl,intc-nr-irqs = <64>; + }; + + intcmux4@d4282150 { + compatible = "mrvl,mmp2-mux-intc"; + interrupts = <4>; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x150 0x4>, <0x168 0x4>; + reg-names = "mux status", "mux mask"; + mrvl,intc-nr-irqs = <2>; + }; diff --git a/Documentation/devicetree/bindings/arm/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt index d8de933e9d8..117d741a2e4 100644 --- a/Documentation/devicetree/bindings/arm/mrvl.txt +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt @@ -4,3 +4,11 @@ Marvell Platforms Device Tree Bindings PXA168 Aspenite Board Required root node properties: - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168"; + +PXA910 DKB Board +Required root node properties: + - compatible = "mrvl,pxa910-dkb"; + +MMP2 Brownstone Board +Required root node properties: + - compatible = "mrvl,mmp2-brownstone"; diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt new file mode 100644 index 00000000000..9a6e251462e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt @@ -0,0 +1,13 @@ +* Marvell MMP Timer controller + +Required properties: +- compatible : Should be "mrvl,mmp-timer". +- reg : Address and length of the register set of timer controller. +- interrupts : Should be the interrupt number. + +Example: + timer0: timer@d4014000 { + compatible = "mrvl,mmp-timer"; + reg = <0xd4014000 0x100>; + interrupts = <13>; + }; diff --git a/Documentation/devicetree/bindings/ata/calxeda-sata.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index 79caa5651f5..8bb8a76d42e 100644 --- a/Documentation/devicetree/bindings/ata/calxeda-sata.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -1,10 +1,10 @@ -* Calxeda SATA Controller +* AHCI SATA Controller SATA nodes are defined to describe on-chip Serial ATA controllers. Each SATA controller should have its own node. Required properties: -- compatible : compatible list, contains "calxeda,hb-ahci" +- compatible : compatible list, contains "calxeda,hb-ahci" or "snps,spear-ahci" - interrupts : <interrupt mapping for SATA IRQ> - reg : <registers mapping> @@ -14,4 +14,3 @@ Example: reg = <0xffe08000 0x1000>; interrupts = <115>; }; - diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt new file mode 100644 index 00000000000..ee87467ad8d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt @@ -0,0 +1,31 @@ +Nomadik GPIO controller + +Required properties: +- compatible : Should be "st,nomadik-gpio". +- reg : Physical base address and length of the controller's registers. +- interrupts : The interrupt outputs from the controller. +- #gpio-cells : Should be two: + The first cell is the pin number. + The second cell is used to specify optional parameters: + - bits[3:0] trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. +- gpio-controller : Marks the device node as a GPIO controller. +- interrupt-controller : Marks the device node as an interrupt controller. +- gpio-bank : Specifies which bank a controller owns. +- st,supports-sleepmode : Specifies whether controller can sleep or not + +Example: + + gpio1: gpio@8012e080 { + compatible = "st,nomadik-gpio"; + reg = <0x8012e080 0x80>; + interrupts = <0 120 0x4>; + #gpio-cells = <2>; + gpio-controller; + interrupt-controller; + supports-sleepmode; + gpio-bank = <1>; + }; diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt index 1e34cfe5ebe..05428f39d9a 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt @@ -3,19 +3,25 @@ Required properties: - compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio" - reg : Address and length of the register set for the device -- interrupts : Should be the port interrupt shared by all gpio pins, if -- interrupt-name : Should be the name of irq resource. - one number. +- interrupts : Should be the port interrupt shared by all gpio pins. + There're three gpio interrupts in arch-pxa, and they're gpio0, + gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp, + gpio_mux. +- interrupt-name : Should be the name of irq resource. Each interrupt + binds its interrupt-name. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. - gpio-controller : Marks the device node as a gpio controller. - #gpio-cells : Should be one. It is the pin number. Example: gpio: gpio@d4019000 { - compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio"; + compatible = "mrvl,mmp-gpio"; reg = <0xd4019000 0x1000>; - interrupts = <49>, <17>, <18>; - interrupt-name = "gpio_mux", "gpio0", "gpio1"; + interrupts = <49>; + interrupt-name = "gpio_mux"; gpio-controller; #gpio-cells = <1>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt index 071eb3caae9..b891ee21835 100644 --- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt @@ -3,34 +3,31 @@ Required properties : - reg : Offset and length of the register set for the device - - compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a + - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a compatible processor, e.g. pxa168, pxa910, mmp2, mmp3. For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required as shown in the example below. Recommended properties : - - interrupts : <a b> where a is the interrupt number and b is a - field that represents an encoding of the sense and level - information for the interrupt. This should be encoded based on - the information in section 2) depending on the type of interrupt - controller you have. + - interrupts : the interrupt number - interrupt-parent : the phandle for the interrupt controller that - services interrupts for this device. + services interrupts for this device. If the parent is the default + interrupt controller in device tree, it could be ignored. - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling status register of i2c controller instead. - mrvl,i2c-fast-mode : Enable fast mode of i2c controller. Examples: twsi1: i2c@d4011000 { - compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c"; + compatible = "mrvl,mmp-twsi"; reg = <0xd4011000 0x1000>; interrupts = <7>; mrvl,i2c-fast-mode; }; twsi2: i2c@d4025000 { - compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c"; + compatible = "mrvl,mmp-twsi"; reg = <0xd4025000 0x1000>; interrupts = <58>; }; diff --git a/Documentation/devicetree/bindings/i2c/pnx.txt b/Documentation/devicetree/bindings/i2c/pnx.txt new file mode 100644 index 00000000000..fe98ada33ee --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/pnx.txt @@ -0,0 +1,36 @@ +* NXP PNX I2C Controller + +Required properties: + + - reg: Offset and length of the register set for the device + - compatible: should be "nxp,pnx-i2c" + - interrupts: configure one interrupt line + - #address-cells: always 1 (for i2c addresses) + - #size-cells: always 0 + - interrupt-parent: the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: + + - clock-frequency: desired I2C bus clock frequency in Hz, Default: 100000 Hz + +Examples: + + i2c1: i2c@400a0000 { + compatible = "nxp,pnx-i2c"; + reg = <0x400a0000 0x100>; + interrupt-parent = <&mic>; + interrupts = <51 0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c2: i2c@400a8000 { + compatible = "nxp,pnx-i2c"; + reg = <0x400a8000 0x100>; + interrupt-parent = <&mic>; + interrupts = <50 0>; + #address-cells = <1>; + #size-cells = <0>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt new file mode 100644 index 00000000000..585021acd17 --- /dev/null +++ b/Documentation/devicetree/bindings/net/lpc-eth.txt @@ -0,0 +1,24 @@ +* NXP LPC32xx SoC Ethernet Controller + +Required properties: +- compatible: Should be "nxp,lpc-eth" +- reg: Address and length of the register set for the device +- interrupts: Should contain ethernet controller interrupt + +Optional properties: +- phy-mode: String, operation mode of the PHY interface. + Supported values are: "mii", "rmii" (default) +- use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering +- local-mac-address : 6 bytes, mac address + +Example: + + mac: ethernet@31060000 { + compatible = "nxp,lpc-eth"; + reg = <0x31060000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <29 0>; + + phy-mode = "rmii"; + use-iram; + }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt new file mode 100644 index 00000000000..79384113c2b --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt @@ -0,0 +1,127 @@ +Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. + +This is a special case of a MDIO bus multiplexer. One or more GPIO +lines are used to control which child bus is connected. + +Required properties in addition to the generic multiplexer properties: + +- compatible : mdio-mux-gpio. +- gpios : GPIO specifiers for each GPIO line. One or more must be specified. + + +Example : + + /* The parent MDIO bus. */ + smi1: mdio@1180000001900 { + compatible = "cavium,octeon-3860-mdio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11800 0x00001900 0x0 0x40>; + }; + + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + phy11: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy12: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy13: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy14: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + phy21: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy22: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy23: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy24: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt new file mode 100644 index 00000000000..f65606f8d63 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt @@ -0,0 +1,136 @@ +Common MDIO bus multiplexer/switch properties. + +An MDIO bus multiplexer/switch will have several child busses that are +numbered uniquely in a device dependent manner. The nodes for an MDIO +bus multiplexer/switch will have one child node for each child bus. + +Required properties: +- mdio-parent-bus : phandle to the parent MDIO bus. +- #address-cells = <1>; +- #size-cells = <0>; + +Optional properties: +- Other properties specific to the multiplexer/switch hardware. + +Required properties for child nodes: +- #address-cells = <1>; +- #size-cells = <0>; +- reg : The sub-bus number. + + +Example : + + /* The parent MDIO bus. */ + smi1: mdio@1180000001900 { + compatible = "cavium,octeon-3860-mdio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11800 0x00001900 0x0 0x40>; + }; + + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + phy11: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy12: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy13: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy14: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + phy21: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy22: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy23: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy24: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt new file mode 100644 index 00000000000..b96fa4c3174 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt @@ -0,0 +1,787 @@ +* Freescale IMX51 IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx51-iomuxc" +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a + pin working on a specific function, CONFIG is the pad setting value like + pull-up for this pin. Please refer to imx51 datasheet for the valid pad + config settings. + +CONFIG bits definition: +PAD_CTL_HVE (1 << 13) +PAD_CTL_HYS (1 << 8) +PAD_CTL_PKE (1 << 7) +PAD_CTL_PUE (1 << 6) +PAD_CTL_PUS_100K_DOWN (0 << 4) +PAD_CTL_PUS_47K_UP (1 << 4) +PAD_CTL_PUS_100K_UP (2 << 4) +PAD_CTL_PUS_22K_UP (3 << 4) +PAD_CTL_ODE (1 << 3) +PAD_CTL_DSE_LOW (0 << 1) +PAD_CTL_DSE_MED (1 << 1) +PAD_CTL_DSE_HIGH (2 << 1) +PAD_CTL_DSE_MAX (3 << 1) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) + +See below for available PIN_FUNC_ID for imx51: +MX51_PAD_EIM_D16__AUD4_RXFS 0 +MX51_PAD_EIM_D16__AUD5_TXD 1 +MX51_PAD_EIM_D16__EIM_D16 2 +MX51_PAD_EIM_D16__GPIO2_0 3 +MX51_PAD_EIM_D16__I2C1_SDA 4 +MX51_PAD_EIM_D16__UART2_CTS 5 +MX51_PAD_EIM_D16__USBH2_DATA0 6 +MX51_PAD_EIM_D17__AUD5_RXD 7 +MX51_PAD_EIM_D17__EIM_D17 8 +MX51_PAD_EIM_D17__GPIO2_1 9 +MX51_PAD_EIM_D17__UART2_RXD 10 +MX51_PAD_EIM_D17__UART3_CTS 11 +MX51_PAD_EIM_D17__USBH2_DATA1 12 +MX51_PAD_EIM_D18__AUD5_TXC 13 +MX51_PAD_EIM_D18__EIM_D18 14 +MX51_PAD_EIM_D18__GPIO2_2 15 +MX51_PAD_EIM_D18__UART2_TXD 16 +MX51_PAD_EIM_D18__UART3_RTS 17 +MX51_PAD_EIM_D18__USBH2_DATA2 18 +MX51_PAD_EIM_D19__AUD4_RXC 19 +MX51_PAD_EIM_D19__AUD5_TXFS 20 +MX51_PAD_EIM_D19__EIM_D19 21 +MX51_PAD_EIM_D19__GPIO2_3 22 +MX51_PAD_EIM_D19__I2C1_SCL 23 +MX51_PAD_EIM_D19__UART2_RTS 24 +MX51_PAD_EIM_D19__USBH2_DATA3 25 +MX51_PAD_EIM_D20__AUD4_TXD 26 +MX51_PAD_EIM_D20__EIM_D20 27 +MX51_PAD_EIM_D20__GPIO2_4 28 +MX51_PAD_EIM_D20__SRTC_ALARM_DEB 29 +MX51_PAD_EIM_D20__USBH2_DATA4 30 +MX51_PAD_EIM_D21__AUD4_RXD 31 +MX51_PAD_EIM_D21__EIM_D21 32 +MX51_PAD_EIM_D21__GPIO2_5 33 +MX51_PAD_EIM_D21__SRTC_ALARM_DEB 34 +MX51_PAD_EIM_D21__USBH2_DATA5 35 +MX51_PAD_EIM_D22__AUD4_TXC 36 +MX51_PAD_EIM_D22__EIM_D22 37 +MX51_PAD_EIM_D22__GPIO2_6 38 +MX51_PAD_EIM_D22__USBH2_DATA6 39 +MX51_PAD_EIM_D23__AUD4_TXFS 40 +MX51_PAD_EIM_D23__EIM_D23 41 +MX51_PAD_EIM_D23__GPIO2_7 42 +MX51_PAD_EIM_D23__SPDIF_OUT1 43 +MX51_PAD_EIM_D23__USBH2_DATA7 44 +MX51_PAD_EIM_D24__AUD6_RXFS 45 +MX51_PAD_EIM_D24__EIM_D24 46 +MX51_PAD_EIM_D24__GPIO2_8 47 +MX51_PAD_EIM_D24__I2C2_SDA 48 +MX51_PAD_EIM_D24__UART3_CTS 49 +MX51_PAD_EIM_D24__USBOTG_DATA0 50 +MX51_PAD_EIM_D25__EIM_D25 51 +MX51_PAD_EIM_D25__KEY_COL6 52 +MX51_PAD_EIM_D25__UART2_CTS 53 +MX51_PAD_EIM_D25__UART3_RXD 54 +MX51_PAD_EIM_D25__USBOTG_DATA1 55 +MX51_PAD_EIM_D26__EIM_D26 56 +MX51_PAD_EIM_D26__KEY_COL7 57 +MX51_PAD_EIM_D26__UART2_RTS 58 +MX51_PAD_EIM_D26__UART3_TXD 59 +MX51_PAD_EIM_D26__USBOTG_DATA2 60 +MX51_PAD_EIM_D27__AUD6_RXC 61 +MX51_PAD_EIM_D27__EIM_D27 62 +MX51_PAD_EIM_D27__GPIO2_9 63 +MX51_PAD_EIM_D27__I2C2_SCL 64 +MX51_PAD_EIM_D27__UART3_RTS 65 +MX51_PAD_EIM_D27__USBOTG_DATA3 66 +MX51_PAD_EIM_D28__AUD6_TXD 67 +MX51_PAD_EIM_D28__EIM_D28 68 +MX51_PAD_EIM_D28__KEY_ROW4 69 +MX51_PAD_EIM_D28__USBOTG_DATA4 70 +MX51_PAD_EIM_D29__AUD6_RXD 71 +MX51_PAD_EIM_D29__EIM_D29 72 +MX51_PAD_EIM_D29__KEY_ROW5 73 +MX51_PAD_EIM_D29__USBOTG_DATA5 74 +MX51_PAD_EIM_D30__AUD6_TXC 75 +MX51_PAD_EIM_D30__EIM_D30 76 +MX51_PAD_EIM_D30__KEY_ROW6 77 +MX51_PAD_EIM_D30__USBOTG_DATA6 78 +MX51_PAD_EIM_D31__AUD6_TXFS 79 +MX51_PAD_EIM_D31__EIM_D31 80 +MX51_PAD_EIM_D31__KEY_ROW7 81 +MX51_PAD_EIM_D31__USBOTG_DATA7 82 +MX51_PAD_EIM_A16__EIM_A16 83 +MX51_PAD_EIM_A16__GPIO2_10 84 +MX51_PAD_EIM_A16__OSC_FREQ_SEL0 85 +MX51_PAD_EIM_A17__EIM_A17 86 +MX51_PAD_EIM_A17__GPIO2_11 87 +MX51_PAD_EIM_A17__OSC_FREQ_SEL1 88 +MX51_PAD_EIM_A18__BOOT_LPB0 89 +MX51_PAD_EIM_A18__EIM_A18 90 +MX51_PAD_EIM_A18__GPIO2_12 91 +MX51_PAD_EIM_A19__BOOT_LPB1 92 +MX51_PAD_EIM_A19__EIM_A19 93 +MX51_PAD_EIM_A19__GPIO2_13 94 +MX51_PAD_EIM_A20__BOOT_UART_SRC0 95 +MX51_PAD_EIM_A20__EIM_A20 96 +MX51_PAD_EIM_A20__GPIO2_14 97 +MX51_PAD_EIM_A21__BOOT_UART_SRC1 98 +MX51_PAD_EIM_A21__EIM_A21 99 +MX51_PAD_EIM_A21__GPIO2_15 100 +MX51_PAD_EIM_A22__EIM_A22 101 +MX51_PAD_EIM_A22__GPIO2_16 102 +MX51_PAD_EIM_A23__BOOT_HPN_EN 103 +MX51_PAD_EIM_A23__EIM_A23 104 +MX51_PAD_EIM_A23__GPIO2_17 105 +MX51_PAD_EIM_A24__EIM_A24 106 +MX51_PAD_EIM_A24__GPIO2_18 107 +MX51_PAD_EIM_A24__USBH2_CLK 108 +MX51_PAD_EIM_A25__DISP1_PIN4 109 +MX51_PAD_EIM_A25__EIM_A25 110 +MX51_PAD_EIM_A25__GPIO2_19 111 +MX51_PAD_EIM_A25__USBH2_DIR 112 +MX51_PAD_EIM_A26__CSI1_DATA_EN 113 +MX51_PAD_EIM_A26__DISP2_EXT_CLK 114 +MX51_PAD_EIM_A26__EIM_A26 115 +MX51_PAD_EIM_A26__GPIO2_20 116 +MX51_PAD_EIM_A26__USBH2_STP 117 +MX51_PAD_EIM_A27__CSI2_DATA_EN 118 +MX51_PAD_EIM_A27__DISP1_PIN1 119 +MX51_PAD_EIM_A27__EIM_A27 120 +MX51_PAD_EIM_A27__GPIO2_21 121 +MX51_PAD_EIM_A27__USBH2_NXT 122 +MX51_PAD_EIM_EB0__EIM_EB0 123 +MX51_PAD_EIM_EB1__EIM_EB1 124 +MX51_PAD_EIM_EB2__AUD5_RXFS 125 +MX51_PAD_EIM_EB2__CSI1_D2 126 +MX51_PAD_EIM_EB2__EIM_EB2 127 +MX51_PAD_EIM_EB2__FEC_MDIO 128 +MX51_PAD_EIM_EB2__GPIO2_22 129 +MX51_PAD_EIM_EB2__GPT_CMPOUT1 130 +MX51_PAD_EIM_EB3__AUD5_RXC 131 +MX51_PAD_EIM_EB3__CSI1_D3 132 +MX51_PAD_EIM_EB3__EIM_EB3 133 +MX51_PAD_EIM_EB3__FEC_RDATA1 134 +MX51_PAD_EIM_EB3__GPIO2_23 135 +MX51_PAD_EIM_EB3__GPT_CMPOUT2 136 +MX51_PAD_EIM_OE__EIM_OE 137 +MX51_PAD_EIM_OE__GPIO2_24 138 +MX51_PAD_EIM_CS0__EIM_CS0 139 +MX51_PAD_EIM_CS0__GPIO2_25 140 +MX51_PAD_EIM_CS1__EIM_CS1 141 +MX51_PAD_EIM_CS1__GPIO2_26 142 +MX51_PAD_EIM_CS2__AUD5_TXD 143 +MX51_PAD_EIM_CS2__CSI1_D4 144 +MX51_PAD_EIM_CS2__EIM_CS2 145 +MX51_PAD_EIM_CS2__FEC_RDATA2 146 +MX51_PAD_EIM_CS2__GPIO2_27 147 +MX51_PAD_EIM_CS2__USBOTG_STP 148 +MX51_PAD_EIM_CS3__AUD5_RXD 149 +MX51_PAD_EIM_CS3__CSI1_D5 150 +MX51_PAD_EIM_CS3__EIM_CS3 151 +MX51_PAD_EIM_CS3__FEC_RDATA3 152 +MX51_PAD_EIM_CS3__GPIO2_28 153 +MX51_PAD_EIM_CS3__USBOTG_NXT 154 +MX51_PAD_EIM_CS4__AUD5_TXC 155 +MX51_PAD_EIM_CS4__CSI1_D6 156 +MX51_PAD_EIM_CS4__EIM_CS4 157 +MX51_PAD_EIM_CS4__FEC_RX_ER 158 +MX51_PAD_EIM_CS4__GPIO2_29 159 +MX51_PAD_EIM_CS4__USBOTG_CLK 160 +MX51_PAD_EIM_CS5__AUD5_TXFS 161 +MX51_PAD_EIM_CS5__CSI1_D7 162 +MX51_PAD_EIM_CS5__DISP1_EXT_CLK 163 +MX51_PAD_EIM_CS5__EIM_CS5 164 +MX51_PAD_EIM_CS5__FEC_CRS 165 +MX51_PAD_EIM_CS5__GPIO2_30 166 +MX51_PAD_EIM_CS5__USBOTG_DIR 167 +MX51_PAD_EIM_DTACK__EIM_DTACK 168 +MX51_PAD_EIM_DTACK__GPIO2_31 169 +MX51_PAD_EIM_LBA__EIM_LBA 170 +MX51_PAD_EIM_LBA__GPIO3_1 171 +MX51_PAD_EIM_CRE__EIM_CRE 172 +MX51_PAD_EIM_CRE__GPIO3_2 173 +MX51_PAD_DRAM_CS1__DRAM_CS1 174 +MX51_PAD_NANDF_WE_B__GPIO3_3 175 +MX51_PAD_NANDF_WE_B__NANDF_WE_B 176 +MX51_PAD_NANDF_WE_B__PATA_DIOW 177 +MX51_PAD_NANDF_WE_B__SD3_DATA0 178 +MX51_PAD_NANDF_RE_B__GPIO3_4 179 +MX51_PAD_NANDF_RE_B__NANDF_RE_B 180 +MX51_PAD_NANDF_RE_B__PATA_DIOR 181 +MX51_PAD_NANDF_RE_B__SD3_DATA1 182 +MX51_PAD_NANDF_ALE__GPIO3_5 183 +MX51_PAD_NANDF_ALE__NANDF_ALE 184 +MX51_PAD_NANDF_ALE__PATA_BUFFER_EN 185 +MX51_PAD_NANDF_CLE__GPIO3_6 186 +MX51_PAD_NANDF_CLE__NANDF_CLE 187 +MX51_PAD_NANDF_CLE__PATA_RESET_B 188 +MX51_PAD_NANDF_WP_B__GPIO3_7 189 +MX51_PAD_NANDF_WP_B__NANDF_WP_B 190 +MX51_PAD_NANDF_WP_B__PATA_DMACK 191 +MX51_PAD_NANDF_WP_B__SD3_DATA2 192 +MX51_PAD_NANDF_RB0__ECSPI2_SS1 193 +MX51_PAD_NANDF_RB0__GPIO3_8 194 +MX51_PAD_NANDF_RB0__NANDF_RB0 195 +MX51_PAD_NANDF_RB0__PATA_DMARQ 196 +MX51_PAD_NANDF_RB0__SD3_DATA3 197 +MX51_PAD_NANDF_RB1__CSPI_MOSI 198 +MX51_PAD_NANDF_RB1__ECSPI2_RDY 199 +MX51_PAD_NANDF_RB1__GPIO3_9 200 +MX51_PAD_NANDF_RB1__NANDF_RB1 201 +MX51_PAD_NANDF_RB1__PATA_IORDY 202 +MX51_PAD_NANDF_RB1__SD4_CMD 203 +MX51_PAD_NANDF_RB2__DISP2_WAIT 204 +MX51_PAD_NANDF_RB2__ECSPI2_SCLK 205 +MX51_PAD_NANDF_RB2__FEC_COL 206 +MX51_PAD_NANDF_RB2__GPIO3_10 207 +MX51_PAD_NANDF_RB2__NANDF_RB2 208 +MX51_PAD_NANDF_RB2__USBH3_H3_DP 209 +MX51_PAD_NANDF_RB2__USBH3_NXT 210 +MX51_PAD_NANDF_RB3__DISP1_WAIT 211 +MX51_PAD_NANDF_RB3__ECSPI2_MISO 212 +MX51_PAD_NANDF_RB3__FEC_RX_CLK 213 +MX51_PAD_NANDF_RB3__GPIO3_11 214 +MX51_PAD_NANDF_RB3__NANDF_RB3 215 +MX51_PAD_NANDF_RB3__USBH3_CLK 216 +MX51_PAD_NANDF_RB3__USBH3_H3_DM 217 +MX51_PAD_GPIO_NAND__GPIO_NAND 218 +MX51_PAD_GPIO_NAND__PATA_INTRQ 219 +MX51_PAD_NANDF_CS0__GPIO3_16 220 +MX51_PAD_NANDF_CS0__NANDF_CS0 221 +MX51_PAD_NANDF_CS1__GPIO3_17 222 +MX51_PAD_NANDF_CS1__NANDF_CS1 223 +MX51_PAD_NANDF_CS2__CSPI_SCLK 224 +MX51_PAD_NANDF_CS2__FEC_TX_ER 225 +MX51_PAD_NANDF_CS2__GPIO3_18 226 +MX51_PAD_NANDF_CS2__NANDF_CS2 227 +MX51_PAD_NANDF_CS2__PATA_CS_0 228 +MX51_PAD_NANDF_CS2__SD4_CLK 229 +MX51_PAD_NANDF_CS2__USBH3_H1_DP 230 +MX51_PAD_NANDF_CS3__FEC_MDC 231 +MX51_PAD_NANDF_CS3__GPIO3_19 232 +MX51_PAD_NANDF_CS3__NANDF_CS3 233 +MX51_PAD_NANDF_CS3__PATA_CS_1 234 +MX51_PAD_NANDF_CS3__SD4_DAT0 235 +MX51_PAD_NANDF_CS3__USBH3_H1_DM 236 +MX51_PAD_NANDF_CS4__FEC_TDATA1 237 +MX51_PAD_NANDF_CS4__GPIO3_20 238 +MX51_PAD_NANDF_CS4__NANDF_CS4 239 +MX51_PAD_NANDF_CS4__PATA_DA_0 240 +MX51_PAD_NANDF_CS4__SD4_DAT1 241 +MX51_PAD_NANDF_CS4__USBH3_STP 242 +MX51_PAD_NANDF_CS5__FEC_TDATA2 243 +MX51_PAD_NANDF_CS5__GPIO3_21 244 +MX51_PAD_NANDF_CS5__NANDF_CS5 245 +MX51_PAD_NANDF_CS5__PATA_DA_1 246 +MX51_PAD_NANDF_CS5__SD4_DAT2 247 +MX51_PAD_NANDF_CS5__USBH3_DIR 248 +MX51_PAD_NANDF_CS6__CSPI_SS3 249 +MX51_PAD_NANDF_CS6__FEC_TDATA3 250 +MX51_PAD_NANDF_CS6__GPIO3_22 251 +MX51_PAD_NANDF_CS6__NANDF_CS6 252 +MX51_PAD_NANDF_CS6__PATA_DA_2 253 +MX51_PAD_NANDF_CS6__SD4_DAT3 254 +MX51_PAD_NANDF_CS7__FEC_TX_EN 255 +MX51_PAD_NANDF_CS7__GPIO3_23 256 +MX51_PAD_NANDF_CS7__NANDF_CS7 257 +MX51_PAD_NANDF_CS7__SD3_CLK 258 +MX51_PAD_NANDF_RDY_INT__ECSPI2_SS0 259 +MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK 260 +MX51_PAD_NANDF_RDY_INT__GPIO3_24 261 +MX51_PAD_NANDF_RDY_INT__NANDF_RDY_INT 262 +MX51_PAD_NANDF_RDY_INT__SD3_CMD 263 +MX51_PAD_NANDF_D15__ECSPI2_MOSI 264 +MX51_PAD_NANDF_D15__GPIO3_25 265 +MX51_PAD_NANDF_D15__NANDF_D15 266 +MX51_PAD_NANDF_D15__PATA_DATA15 267 +MX51_PAD_NANDF_D15__SD3_DAT7 268 +MX51_PAD_NANDF_D14__ECSPI2_SS3 269 +MX51_PAD_NANDF_D14__GPIO3_26 270 +MX51_PAD_NANDF_D14__NANDF_D14 271 +MX51_PAD_NANDF_D14__PATA_DATA14 272 +MX51_PAD_NANDF_D14__SD3_DAT6 273 +MX51_PAD_NANDF_D13__ECSPI2_SS2 274 +MX51_PAD_NANDF_D13__GPIO3_27 275 +MX51_PAD_NANDF_D13__NANDF_D13 276 +MX51_PAD_NANDF_D13__PATA_DATA13 277 +MX51_PAD_NANDF_D13__SD3_DAT5 278 +MX51_PAD_NANDF_D12__ECSPI2_SS1 279 +MX51_PAD_NANDF_D12__GPIO3_28 280 +MX51_PAD_NANDF_D12__NANDF_D12 281 +MX51_PAD_NANDF_D12__PATA_DATA12 282 +MX51_PAD_NANDF_D12__SD3_DAT4 283 +MX51_PAD_NANDF_D11__FEC_RX_DV 284 +MX51_PAD_NANDF_D11__GPIO3_29 285 +MX51_PAD_NANDF_D11__NANDF_D11 286 +MX51_PAD_NANDF_D11__PATA_DATA11 287 +MX51_PAD_NANDF_D11__SD3_DATA3 288 +MX51_PAD_NANDF_D10__GPIO3_30 289 +MX51_PAD_NANDF_D10__NANDF_D10 290 +MX51_PAD_NANDF_D10__PATA_DATA10 291 +MX51_PAD_NANDF_D10__SD3_DATA2 292 +MX51_PAD_NANDF_D9__FEC_RDATA0 293 +MX51_PAD_NANDF_D9__GPIO3_31 294 +MX51_PAD_NANDF_D9__NANDF_D9 295 +MX51_PAD_NANDF_D9__PATA_DATA9 296 +MX51_PAD_NANDF_D9__SD3_DATA1 297 +MX51_PAD_NANDF_D8__FEC_TDATA0 298 +MX51_PAD_NANDF_D8__GPIO4_0 299 +MX51_PAD_NANDF_D8__NANDF_D8 300 +MX51_PAD_NANDF_D8__PATA_DATA8 301 +MX51_PAD_NANDF_D8__SD3_DATA0 302 +MX51_PAD_NANDF_D7__GPIO4_1 303 +MX51_PAD_NANDF_D7__NANDF_D7 304 +MX51_PAD_NANDF_D7__PATA_DATA7 305 +MX51_PAD_NANDF_D7__USBH3_DATA0 306 +MX51_PAD_NANDF_D6__GPIO4_2 307 +MX51_PAD_NANDF_D6__NANDF_D6 308 +MX51_PAD_NANDF_D6__PATA_DATA6 309 +MX51_PAD_NANDF_D6__SD4_LCTL 310 +MX51_PAD_NANDF_D6__USBH3_DATA1 311 +MX51_PAD_NANDF_D5__GPIO4_3 312 +MX51_PAD_NANDF_D5__NANDF_D5 313 +MX51_PAD_NANDF_D5__PATA_DATA5 314 +MX51_PAD_NANDF_D5__SD4_WP 315 +MX51_PAD_NANDF_D5__USBH3_DATA2 316 +MX51_PAD_NANDF_D4__GPIO4_4 317 +MX51_PAD_NANDF_D4__NANDF_D4 318 +MX51_PAD_NANDF_D4__PATA_DATA4 319 +MX51_PAD_NANDF_D4__SD4_CD 320 +MX51_PAD_NANDF_D4__USBH3_DATA3 321 +MX51_PAD_NANDF_D3__GPIO4_5 322 +MX51_PAD_NANDF_D3__NANDF_D3 323 +MX51_PAD_NANDF_D3__PATA_DATA3 324 +MX51_PAD_NANDF_D3__SD4_DAT4 325 +MX51_PAD_NANDF_D3__USBH3_DATA4 326 +MX51_PAD_NANDF_D2__GPIO4_6 327 +MX51_PAD_NANDF_D2__NANDF_D2 328 +MX51_PAD_NANDF_D2__PATA_DATA2 329 +MX51_PAD_NANDF_D2__SD4_DAT5 330 +MX51_PAD_NANDF_D2__USBH3_DATA5 331 +MX51_PAD_NANDF_D1__GPIO4_7 332 +MX51_PAD_NANDF_D1__NANDF_D1 333 +MX51_PAD_NANDF_D1__PATA_DATA1 334 +MX51_PAD_NANDF_D1__SD4_DAT6 335 +MX51_PAD_NANDF_D1__USBH3_DATA6 336 +MX51_PAD_NANDF_D0__GPIO4_8 337 +MX51_PAD_NANDF_D0__NANDF_D0 338 +MX51_PAD_NANDF_D0__PATA_DATA0 339 +MX51_PAD_NANDF_D0__SD4_DAT7 340 +MX51_PAD_NANDF_D0__USBH3_DATA7 341 +MX51_PAD_CSI1_D8__CSI1_D8 342 +MX51_PAD_CSI1_D8__GPIO3_12 343 +MX51_PAD_CSI1_D9__CSI1_D9 344 +MX51_PAD_CSI1_D9__GPIO3_13 345 +MX51_PAD_CSI1_D10__CSI1_D10 346 +MX51_PAD_CSI1_D11__CSI1_D11 347 +MX51_PAD_CSI1_D12__CSI1_D12 348 +MX51_PAD_CSI1_D13__CSI1_D13 349 +MX51_PAD_CSI1_D14__CSI1_D14 350 +MX51_PAD_CSI1_D15__CSI1_D15 351 +MX51_PAD_CSI1_D16__CSI1_D16 352 +MX51_PAD_CSI1_D17__CSI1_D17 353 +MX51_PAD_CSI1_D18__CSI1_D18 354 +MX51_PAD_CSI1_D19__CSI1_D19 355 +MX51_PAD_CSI1_VSYNC__CSI1_VSYNC 356 +MX51_PAD_CSI1_VSYNC__GPIO3_14 357 +MX51_PAD_CSI1_HSYNC__CSI1_HSYNC 358 +MX51_PAD_CSI1_HSYNC__GPIO3_15 359 +MX51_PAD_CSI1_PIXCLK__CSI1_PIXCLK 360 +MX51_PAD_CSI1_MCLK__CSI1_MCLK 361 +MX51_PAD_CSI2_D12__CSI2_D12 362 +MX51_PAD_CSI2_D12__GPIO4_9 363 +MX51_PAD_CSI2_D13__CSI2_D13 364 +MX51_PAD_CSI2_D13__GPIO4_10 365 +MX51_PAD_CSI2_D14__CSI2_D14 366 +MX51_PAD_CSI2_D15__CSI2_D15 367 +MX51_PAD_CSI2_D16__CSI2_D16 368 +MX51_PAD_CSI2_D17__CSI2_D17 369 +MX51_PAD_CSI2_D18__CSI2_D18 370 +MX51_PAD_CSI2_D18__GPIO4_11 371 +MX51_PAD_CSI2_D19__CSI2_D19 372 +MX51_PAD_CSI2_D19__GPIO4_12 373 +MX51_PAD_CSI2_VSYNC__CSI2_VSYNC 374 +MX51_PAD_CSI2_VSYNC__GPIO4_13 375 +MX51_PAD_CSI2_HSYNC__CSI2_HSYNC 376 +MX51_PAD_CSI2_HSYNC__GPIO4_14 377 +MX51_PAD_CSI2_PIXCLK__CSI2_PIXCLK 378 +MX51_PAD_CSI2_PIXCLK__GPIO4_15 379 +MX51_PAD_I2C1_CLK__GPIO4_16 380 +MX51_PAD_I2C1_CLK__I2C1_CLK 381 +MX51_PAD_I2C1_DAT__GPIO4_17 382 +MX51_PAD_I2C1_DAT__I2C1_DAT 383 +MX51_PAD_AUD3_BB_TXD__AUD3_TXD 384 +MX51_PAD_AUD3_BB_TXD__GPIO4_18 385 +MX51_PAD_AUD3_BB_RXD__AUD3_RXD 386 +MX51_PAD_AUD3_BB_RXD__GPIO4_19 387 +MX51_PAD_AUD3_BB_RXD__UART3_RXD 388 +MX51_PAD_AUD3_BB_CK__AUD3_TXC 389 +MX51_PAD_AUD3_BB_CK__GPIO4_20 390 +MX51_PAD_AUD3_BB_FS__AUD3_TXFS 391 +MX51_PAD_AUD3_BB_FS__GPIO4_21 392 +MX51_PAD_AUD3_BB_FS__UART3_TXD 393 +MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI 394 +MX51_PAD_CSPI1_MOSI__GPIO4_22 395 +MX51_PAD_CSPI1_MOSI__I2C1_SDA 396 +MX51_PAD_CSPI1_MISO__AUD4_RXD 397 +MX51_PAD_CSPI1_MISO__ECSPI1_MISO 398 +MX51_PAD_CSPI1_MISO__GPIO4_23 399 +MX51_PAD_CSPI1_SS0__AUD4_TXC 400 +MX51_PAD_CSPI1_SS0__ECSPI1_SS0 401 +MX51_PAD_CSPI1_SS0__GPIO4_24 402 +MX51_PAD_CSPI1_SS1__AUD4_TXD 403 +MX51_PAD_CSPI1_SS1__ECSPI1_SS1 404 +MX51_PAD_CSPI1_SS1__GPIO4_25 405 +MX51_PAD_CSPI1_RDY__AUD4_TXFS 406 +MX51_PAD_CSPI1_RDY__ECSPI1_RDY 407 +MX51_PAD_CSPI1_RDY__GPIO4_26 408 +MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK 409 +MX51_PAD_CSPI1_SCLK__GPIO4_27 410 +MX51_PAD_CSPI1_SCLK__I2C1_SCL 411 +MX51_PAD_UART1_RXD__GPIO4_28 412 +MX51_PAD_UART1_RXD__UART1_RXD 413 +MX51_PAD_UART1_TXD__GPIO4_29 414 +MX51_PAD_UART1_TXD__PWM2_PWMO 415 +MX51_PAD_UART1_TXD__UART1_TXD 416 +MX51_PAD_UART1_RTS__GPIO4_30 417 +MX51_PAD_UART1_RTS__UART1_RTS 418 +MX51_PAD_UART1_CTS__GPIO4_31 419 +MX51_PAD_UART1_CTS__UART1_CTS 420 +MX51_PAD_UART2_RXD__FIRI_TXD 421 +MX51_PAD_UART2_RXD__GPIO1_20 422 +MX51_PAD_UART2_RXD__UART2_RXD 423 +MX51_PAD_UART2_TXD__FIRI_RXD 424 +MX51_PAD_UART2_TXD__GPIO1_21 425 +MX51_PAD_UART2_TXD__UART2_TXD 426 +MX51_PAD_UART3_RXD__CSI1_D0 427 +MX51_PAD_UART3_RXD__GPIO1_22 428 +MX51_PAD_UART3_RXD__UART1_DTR 429 +MX51_PAD_UART3_RXD__UART3_RXD 430 +MX51_PAD_UART3_TXD__CSI1_D1 431 +MX51_PAD_UART3_TXD__GPIO1_23 432 +MX51_PAD_UART3_TXD__UART1_DSR 433 +MX51_PAD_UART3_TXD__UART3_TXD 434 +MX51_PAD_OWIRE_LINE__GPIO1_24 435 +MX51_PAD_OWIRE_LINE__OWIRE_LINE 436 +MX51_PAD_OWIRE_LINE__SPDIF_OUT 437 +MX51_PAD_KEY_ROW0__KEY_ROW0 438 +MX51_PAD_KEY_ROW1__KEY_ROW1 439 +MX51_PAD_KEY_ROW2__KEY_ROW2 440 +MX51_PAD_KEY_ROW3__KEY_ROW3 441 +MX51_PAD_KEY_COL0__KEY_COL0 442 +MX51_PAD_KEY_COL0__PLL1_BYP 443 +MX51_PAD_KEY_COL1__KEY_COL1 444 +MX51_PAD_KEY_COL1__PLL2_BYP 445 +MX51_PAD_KEY_COL2__KEY_COL2 446 +MX51_PAD_KEY_COL2__PLL3_BYP 447 +MX51_PAD_KEY_COL3__KEY_COL3 448 +MX51_PAD_KEY_COL4__I2C2_SCL 449 +MX51_PAD_KEY_COL4__KEY_COL4 450 +MX51_PAD_KEY_COL4__SPDIF_OUT1 451 +MX51_PAD_KEY_COL4__UART1_RI 452 +MX51_PAD_KEY_COL4__UART3_RTS 453 +MX51_PAD_KEY_COL5__I2C2_SDA 454 +MX51_PAD_KEY_COL5__KEY_COL5 455 +MX51_PAD_KEY_COL5__UART1_DCD 456 +MX51_PAD_KEY_COL5__UART3_CTS 457 +MX51_PAD_USBH1_CLK__CSPI_SCLK 458 +MX51_PAD_USBH1_CLK__GPIO1_25 459 +MX51_PAD_USBH1_CLK__I2C2_SCL 460 +MX51_PAD_USBH1_CLK__USBH1_CLK 461 +MX51_PAD_USBH1_DIR__CSPI_MOSI 462 +MX51_PAD_USBH1_DIR__GPIO1_26 463 +MX51_PAD_USBH1_DIR__I2C2_SDA 464 +MX51_PAD_USBH1_DIR__USBH1_DIR 465 +MX51_PAD_USBH1_STP__CSPI_RDY 466 +MX51_PAD_USBH1_STP__GPIO1_27 467 +MX51_PAD_USBH1_STP__UART3_RXD 468 +MX51_PAD_USBH1_STP__USBH1_STP 469 +MX51_PAD_USBH1_NXT__CSPI_MISO 470 +MX51_PAD_USBH1_NXT__GPIO1_28 471 +MX51_PAD_USBH1_NXT__UART3_TXD 472 +MX51_PAD_USBH1_NXT__USBH1_NXT 473 +MX51_PAD_USBH1_DATA0__GPIO1_11 474 +MX51_PAD_USBH1_DATA0__UART2_CTS 475 +MX51_PAD_USBH1_DATA0__USBH1_DATA0 476 +MX51_PAD_USBH1_DATA1__GPIO1_12 477 +MX51_PAD_USBH1_DATA1__UART2_RXD 478 +MX51_PAD_USBH1_DATA1__USBH1_DATA1 479 +MX51_PAD_USBH1_DATA2__GPIO1_13 480 +MX51_PAD_USBH1_DATA2__UART2_TXD 481 +MX51_PAD_USBH1_DATA2__USBH1_DATA2 482 +MX51_PAD_USBH1_DATA3__GPIO1_14 483 +MX51_PAD_USBH1_DATA3__UART2_RTS 484 +MX51_PAD_USBH1_DATA3__USBH1_DATA3 485 +MX51_PAD_USBH1_DATA4__CSPI_SS0 486 +MX51_PAD_USBH1_DATA4__GPIO1_15 487 +MX51_PAD_USBH1_DATA4__USBH1_DATA4 488 +MX51_PAD_USBH1_DATA5__CSPI_SS1 489 +MX51_PAD_USBH1_DATA5__GPIO1_16 490 +MX51_PAD_USBH1_DATA5__USBH1_DATA5 491 +MX51_PAD_USBH1_DATA6__CSPI_SS3 492 +MX51_PAD_USBH1_DATA6__GPIO1_17 493 +MX51_PAD_USBH1_DATA6__USBH1_DATA6 494 +MX51_PAD_USBH1_DATA7__ECSPI1_SS3 495 +MX51_PAD_USBH1_DATA7__ECSPI2_SS3 496 +MX51_PAD_USBH1_DATA7__GPIO1_18 497 +MX51_PAD_USBH1_DATA7__USBH1_DATA7 498 +MX51_PAD_DI1_PIN11__DI1_PIN11 499 +MX51_PAD_DI1_PIN11__ECSPI1_SS2 500 +MX51_PAD_DI1_PIN11__GPIO3_0 501 +MX51_PAD_DI1_PIN12__DI1_PIN12 502 +MX51_PAD_DI1_PIN12__GPIO3_1 503 +MX51_PAD_DI1_PIN13__DI1_PIN13 504 +MX51_PAD_DI1_PIN13__GPIO3_2 505 +MX51_PAD_DI1_D0_CS__DI1_D0_CS 506 +MX51_PAD_DI1_D0_CS__GPIO3_3 507 +MX51_PAD_DI1_D1_CS__DI1_D1_CS 508 +MX51_PAD_DI1_D1_CS__DISP1_PIN14 509 +MX51_PAD_DI1_D1_CS__DISP1_PIN5 510 +MX51_PAD_DI1_D1_CS__GPIO3_4 511 +MX51_PAD_DISPB2_SER_DIN__DISP1_PIN1 512 +MX51_PAD_DISPB2_SER_DIN__DISPB2_SER_DIN 513 +MX51_PAD_DISPB2_SER_DIN__GPIO3_5 514 +MX51_PAD_DISPB2_SER_DIO__DISP1_PIN6 515 +MX51_PAD_DISPB2_SER_DIO__DISPB2_SER_DIO 516 +MX51_PAD_DISPB2_SER_DIO__GPIO3_6 517 +MX51_PAD_DISPB2_SER_CLK__DISP1_PIN17 518 +MX51_PAD_DISPB2_SER_CLK__DISP1_PIN7 519 +MX51_PAD_DISPB2_SER_CLK__DISPB2_SER_CLK 520 +MX51_PAD_DISPB2_SER_CLK__GPIO3_7 521 +MX51_PAD_DISPB2_SER_RS__DISP1_EXT_CLK 522 +MX51_PAD_DISPB2_SER_RS__DISP1_PIN16 523 +MX51_PAD_DISPB2_SER_RS__DISP1_PIN8 524 +MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 525 +MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 526 +MX51_PAD_DISPB2_SER_RS__GPIO3_8 527 +MX51_PAD_DISP1_DAT0__DISP1_DAT0 528 +MX51_PAD_DISP1_DAT1__DISP1_DAT1 529 +MX51_PAD_DISP1_DAT2__DISP1_DAT2 530 +MX51_PAD_DISP1_DAT3__DISP1_DAT3 531 +MX51_PAD_DISP1_DAT4__DISP1_DAT4 532 +MX51_PAD_DISP1_DAT5__DISP1_DAT5 533 +MX51_PAD_DISP1_DAT6__BOOT_USB_SRC 534 +MX51_PAD_DISP1_DAT6__DISP1_DAT6 535 +MX51_PAD_DISP1_DAT7__BOOT_EEPROM_CFG 536 +MX51_PAD_DISP1_DAT7__DISP1_DAT7 537 +MX51_PAD_DISP1_DAT8__BOOT_SRC0 538 +MX51_PAD_DISP1_DAT8__DISP1_DAT8 539 +MX51_PAD_DISP1_DAT9__BOOT_SRC1 540 +MX51_PAD_DISP1_DAT9__DISP1_DAT9 541 +MX51_PAD_DISP1_DAT10__BOOT_SPARE_SIZE 542 +MX51_PAD_DISP1_DAT10__DISP1_DAT10 543 +MX51_PAD_DISP1_DAT11__BOOT_LPB_FREQ2 544 +MX51_PAD_DISP1_DAT11__DISP1_DAT11 545 +MX51_PAD_DISP1_DAT12__BOOT_MLC_SEL 546 +MX51_PAD_DISP1_DAT12__DISP1_DAT12 547 +MX51_PAD_DISP1_DAT13__BOOT_MEM_CTL0 548 +MX51_PAD_DISP1_DAT13__DISP1_DAT13 549 +MX51_PAD_DISP1_DAT14__BOOT_MEM_CTL1 550 +MX51_PAD_DISP1_DAT14__DISP1_DAT14 551 +MX51_PAD_DISP1_DAT15__BOOT_BUS_WIDTH 552 +MX51_PAD_DISP1_DAT15__DISP1_DAT15 553 +MX51_PAD_DISP1_DAT16__BOOT_PAGE_SIZE0 554 +MX51_PAD_DISP1_DAT16__DISP1_DAT16 555 +MX51_PAD_DISP1_DAT17__BOOT_PAGE_SIZE1 556 +MX51_PAD_DISP1_DAT17__DISP1_DAT17 557 +MX51_PAD_DISP1_DAT18__BOOT_WEIM_MUXED0 558 +MX51_PAD_DISP1_DAT18__DISP1_DAT18 559 +MX51_PAD_DISP1_DAT18__DISP2_PIN11 560 +MX51_PAD_DISP1_DAT18__DISP2_PIN5 561 +MX51_PAD_DISP1_DAT19__BOOT_WEIM_MUXED1 562 +MX51_PAD_DISP1_DAT19__DISP1_DAT19 563 +MX51_PAD_DISP1_DAT19__DISP2_PIN12 564 +MX51_PAD_DISP1_DAT19__DISP2_PIN6 565 +MX51_PAD_DISP1_DAT20__BOOT_MEM_TYPE0 566 +MX51_PAD_DISP1_DAT20__DISP1_DAT20 567 +MX51_PAD_DISP1_DAT20__DISP2_PIN13 568 +MX51_PAD_DISP1_DAT20__DISP2_PIN7 569 +MX51_PAD_DISP1_DAT21__BOOT_MEM_TYPE1 570 +MX51_PAD_DISP1_DAT21__DISP1_DAT21 571 +MX51_PAD_DISP1_DAT21__DISP2_PIN14 572 +MX51_PAD_DISP1_DAT21__DISP2_PIN8 573 +MX51_PAD_DISP1_DAT22__BOOT_LPB_FREQ0 574 +MX51_PAD_DISP1_DAT22__DISP1_DAT22 575 +MX51_PAD_DISP1_DAT22__DISP2_D0_CS 576 +MX51_PAD_DISP1_DAT22__DISP2_DAT16 577 +MX51_PAD_DISP1_DAT23__BOOT_LPB_FREQ1 578 +MX51_PAD_DISP1_DAT23__DISP1_DAT23 579 +MX51_PAD_DISP1_DAT23__DISP2_D1_CS 580 +MX51_PAD_DISP1_DAT23__DISP2_DAT17 581 +MX51_PAD_DISP1_DAT23__DISP2_SER_CS 582 +MX51_PAD_DI1_PIN3__DI1_PIN3 583 +MX51_PAD_DI1_PIN2__DI1_PIN2 584 +MX51_PAD_DI_GP2__DISP1_SER_CLK 585 +MX51_PAD_DI_GP2__DISP2_WAIT 586 +MX51_PAD_DI_GP3__CSI1_DATA_EN 587 +MX51_PAD_DI_GP3__DISP1_SER_DIO 588 +MX51_PAD_DI_GP3__FEC_TX_ER 589 +MX51_PAD_DI2_PIN4__CSI2_DATA_EN 590 +MX51_PAD_DI2_PIN4__DI2_PIN4 591 +MX51_PAD_DI2_PIN4__FEC_CRS 592 +MX51_PAD_DI2_PIN2__DI2_PIN2 593 +MX51_PAD_DI2_PIN2__FEC_MDC 594 +MX51_PAD_DI2_PIN3__DI2_PIN3 595 +MX51_PAD_DI2_PIN3__FEC_MDIO 596 +MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK 597 +MX51_PAD_DI2_DISP_CLK__FEC_RDATA1 598 +MX51_PAD_DI_GP4__DI2_PIN15 599 +MX51_PAD_DI_GP4__DISP1_SER_DIN 600 +MX51_PAD_DI_GP4__DISP2_PIN1 601 +MX51_PAD_DI_GP4__FEC_RDATA2 602 +MX51_PAD_DISP2_DAT0__DISP2_DAT0 603 +MX51_PAD_DISP2_DAT0__FEC_RDATA3 604 +MX51_PAD_DISP2_DAT0__KEY_COL6 605 +MX51_PAD_DISP2_DAT0__UART3_RXD 606 +MX51_PAD_DISP2_DAT0__USBH3_CLK 607 +MX51_PAD_DISP2_DAT1__DISP2_DAT1 608 +MX51_PAD_DISP2_DAT1__FEC_RX_ER 609 +MX51_PAD_DISP2_DAT1__KEY_COL7 610 +MX51_PAD_DISP2_DAT1__UART3_TXD 611 +MX51_PAD_DISP2_DAT1__USBH3_DIR 612 +MX51_PAD_DISP2_DAT2__DISP2_DAT2 613 +MX51_PAD_DISP2_DAT3__DISP2_DAT3 614 +MX51_PAD_DISP2_DAT4__DISP2_DAT4 615 +MX51_PAD_DISP2_DAT5__DISP2_DAT5 616 +MX51_PAD_DISP2_DAT6__DISP2_DAT6 617 +MX51_PAD_DISP2_DAT6__FEC_TDATA1 618 +MX51_PAD_DISP2_DAT6__GPIO1_19 619 +MX51_PAD_DISP2_DAT6__KEY_ROW4 620 +MX51_PAD_DISP2_DAT6__USBH3_STP 621 +MX51_PAD_DISP2_DAT7__DISP2_DAT7 622 +MX51_PAD_DISP2_DAT7__FEC_TDATA2 623 +MX51_PAD_DISP2_DAT7__GPIO1_29 624 +MX51_PAD_DISP2_DAT7__KEY_ROW5 625 +MX51_PAD_DISP2_DAT7__USBH3_NXT 626 +MX51_PAD_DISP2_DAT8__DISP2_DAT8 627 +MX51_PAD_DISP2_DAT8__FEC_TDATA3 628 +MX51_PAD_DISP2_DAT8__GPIO1_30 629 +MX51_PAD_DISP2_DAT8__KEY_ROW6 630 +MX51_PAD_DISP2_DAT8__USBH3_DATA0 631 +MX51_PAD_DISP2_DAT9__AUD6_RXC 632 +MX51_PAD_DISP2_DAT9__DISP2_DAT9 633 +MX51_PAD_DISP2_DAT9__FEC_TX_EN 634 +MX51_PAD_DISP2_DAT9__GPIO1_31 635 +MX51_PAD_DISP2_DAT9__USBH3_DATA1 636 +MX51_PAD_DISP2_DAT10__DISP2_DAT10 637 +MX51_PAD_DISP2_DAT10__DISP2_SER_CS 638 +MX51_PAD_DISP2_DAT10__FEC_COL 639 +MX51_PAD_DISP2_DAT10__KEY_ROW7 640 +MX51_PAD_DISP2_DAT10__USBH3_DATA2 641 +MX51_PAD_DISP2_DAT11__AUD6_TXD 642 +MX51_PAD_DISP2_DAT11__DISP2_DAT11 643 +MX51_PAD_DISP2_DAT11__FEC_RX_CLK 644 +MX51_PAD_DISP2_DAT11__GPIO1_10 645 +MX51_PAD_DISP2_DAT11__USBH3_DATA3 646 +MX51_PAD_DISP2_DAT12__AUD6_RXD 647 +MX51_PAD_DISP2_DAT12__DISP2_DAT12 648 +MX51_PAD_DISP2_DAT12__FEC_RX_DV 649 +MX51_PAD_DISP2_DAT12__USBH3_DATA4 650 +MX51_PAD_DISP2_DAT13__AUD6_TXC 651 +MX51_PAD_DISP2_DAT13__DISP2_DAT13 652 +MX51_PAD_DISP2_DAT13__FEC_TX_CLK 653 +MX51_PAD_DISP2_DAT13__USBH3_DATA5 654 +MX51_PAD_DISP2_DAT14__AUD6_TXFS 655 +MX51_PAD_DISP2_DAT14__DISP2_DAT14 656 +MX51_PAD_DISP2_DAT14__FEC_RDATA0 657 +MX51_PAD_DISP2_DAT14__USBH3_DATA6 658 +MX51_PAD_DISP2_DAT15__AUD6_RXFS 659 +MX51_PAD_DISP2_DAT15__DISP1_SER_CS 660 +MX51_PAD_DISP2_DAT15__DISP2_DAT15 661 +MX51_PAD_DISP2_DAT15__FEC_TDATA0 662 +MX51_PAD_DISP2_DAT15__USBH3_DATA7 663 +MX51_PAD_SD1_CMD__AUD5_RXFS 664 +MX51_PAD_SD1_CMD__CSPI_MOSI 665 +MX51_PAD_SD1_CMD__SD1_CMD 666 +MX51_PAD_SD1_CLK__AUD5_RXC 667 +MX51_PAD_SD1_CLK__CSPI_SCLK 668 +MX51_PAD_SD1_CLK__SD1_CLK 669 +MX51_PAD_SD1_DATA0__AUD5_TXD 670 +MX51_PAD_SD1_DATA0__CSPI_MISO 671 +MX51_PAD_SD1_DATA0__SD1_DATA0 672 +MX51_PAD_EIM_DA0__EIM_DA0 673 +MX51_PAD_EIM_DA1__EIM_DA1 674 +MX51_PAD_EIM_DA2__EIM_DA2 675 +MX51_PAD_EIM_DA3__EIM_DA3 676 +MX51_PAD_SD1_DATA1__AUD5_RXD 677 +MX51_PAD_SD1_DATA1__SD1_DATA1 678 +MX51_PAD_EIM_DA4__EIM_DA4 679 +MX51_PAD_EIM_DA5__EIM_DA5 680 +MX51_PAD_EIM_DA6__EIM_DA6 681 +MX51_PAD_EIM_DA7__EIM_DA7 682 +MX51_PAD_SD1_DATA2__AUD5_TXC 683 +MX51_PAD_SD1_DATA2__SD1_DATA2 684 +MX51_PAD_EIM_DA10__EIM_DA10 685 +MX51_PAD_EIM_DA11__EIM_DA11 686 +MX51_PAD_EIM_DA8__EIM_DA8 687 +MX51_PAD_EIM_DA9__EIM_DA9 688 +MX51_PAD_SD1_DATA3__AUD5_TXFS 689 +MX51_PAD_SD1_DATA3__CSPI_SS1 690 +MX51_PAD_SD1_DATA3__SD1_DATA3 691 +MX51_PAD_GPIO1_0__CSPI_SS2 692 +MX51_PAD_GPIO1_0__GPIO1_0 693 +MX51_PAD_GPIO1_0__SD1_CD 694 +MX51_PAD_GPIO1_1__CSPI_MISO 695 +MX51_PAD_GPIO1_1__GPIO1_1 696 +MX51_PAD_GPIO1_1__SD1_WP 697 +MX51_PAD_EIM_DA12__EIM_DA12 698 +MX51_PAD_EIM_DA13__EIM_DA13 699 +MX51_PAD_EIM_DA14__EIM_DA14 700 +MX51_PAD_EIM_DA15__EIM_DA15 701 +MX51_PAD_SD2_CMD__CSPI_MOSI 702 +MX51_PAD_SD2_CMD__I2C1_SCL 703 +MX51_PAD_SD2_CMD__SD2_CMD 704 +MX51_PAD_SD2_CLK__CSPI_SCLK 705 +MX51_PAD_SD2_CLK__I2C1_SDA 706 +MX51_PAD_SD2_CLK__SD2_CLK 707 +MX51_PAD_SD2_DATA0__CSPI_MISO 708 +MX51_PAD_SD2_DATA0__SD1_DAT4 709 +MX51_PAD_SD2_DATA0__SD2_DATA0 710 +MX51_PAD_SD2_DATA1__SD1_DAT5 711 +MX51_PAD_SD2_DATA1__SD2_DATA1 712 +MX51_PAD_SD2_DATA1__USBH3_H2_DP 713 +MX51_PAD_SD2_DATA2__SD1_DAT6 714 +MX51_PAD_SD2_DATA2__SD2_DATA2 715 +MX51_PAD_SD2_DATA2__USBH3_H2_DM 716 +MX51_PAD_SD2_DATA3__CSPI_SS2 717 +MX51_PAD_SD2_DATA3__SD1_DAT7 718 +MX51_PAD_SD2_DATA3__SD2_DATA3 719 +MX51_PAD_GPIO1_2__CCM_OUT_2 720 +MX51_PAD_GPIO1_2__GPIO1_2 721 +MX51_PAD_GPIO1_2__I2C2_SCL 722 +MX51_PAD_GPIO1_2__PLL1_BYP 723 +MX51_PAD_GPIO1_2__PWM1_PWMO 724 +MX51_PAD_GPIO1_3__GPIO1_3 725 +MX51_PAD_GPIO1_3__I2C2_SDA 726 +MX51_PAD_GPIO1_3__PLL2_BYP 727 +MX51_PAD_GPIO1_3__PWM2_PWMO 728 +MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ 729 +MX51_PAD_PMIC_INT_REQ__PMIC_PMU_IRQ_B 730 +MX51_PAD_GPIO1_4__DISP2_EXT_CLK 731 +MX51_PAD_GPIO1_4__EIM_RDY 732 +MX51_PAD_GPIO1_4__GPIO1_4 733 +MX51_PAD_GPIO1_4__WDOG1_WDOG_B 734 +MX51_PAD_GPIO1_5__CSI2_MCLK 735 +MX51_PAD_GPIO1_5__DISP2_PIN16 736 +MX51_PAD_GPIO1_5__GPIO1_5 737 +MX51_PAD_GPIO1_5__WDOG2_WDOG_B 738 +MX51_PAD_GPIO1_6__DISP2_PIN17 739 +MX51_PAD_GPIO1_6__GPIO1_6 740 +MX51_PAD_GPIO1_6__REF_EN_B 741 +MX51_PAD_GPIO1_7__CCM_OUT_0 742 +MX51_PAD_GPIO1_7__GPIO1_7 743 +MX51_PAD_GPIO1_7__SD2_WP 744 +MX51_PAD_GPIO1_7__SPDIF_OUT1 745 +MX51_PAD_GPIO1_8__CSI2_DATA_EN 746 +MX51_PAD_GPIO1_8__GPIO1_8 747 +MX51_PAD_GPIO1_8__SD2_CD 748 +MX51_PAD_GPIO1_8__USBH3_PWR 749 +MX51_PAD_GPIO1_9__CCM_OUT_1 750 +MX51_PAD_GPIO1_9__DISP2_D1_CS 751 +MX51_PAD_GPIO1_9__DISP2_SER_CS 752 +MX51_PAD_GPIO1_9__GPIO1_9 753 +MX51_PAD_GPIO1_9__SD2_LCTL 754 +MX51_PAD_GPIO1_9__USBH3_OC 755 diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt new file mode 100644 index 00000000000..ca85ca432ef --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt @@ -0,0 +1,1202 @@ +* Freescale IMX53 IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx53-iomuxc" +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a + pin working on a specific function, CONFIG is the pad setting value like + pull-up for this pin. Please refer to imx53 datasheet for the valid pad + config settings. + +CONFIG bits definition: +PAD_CTL_HVE (1 << 13) +PAD_CTL_HYS (1 << 8) +PAD_CTL_PKE (1 << 7) +PAD_CTL_PUE (1 << 6) +PAD_CTL_PUS_100K_DOWN (0 << 4) +PAD_CTL_PUS_47K_UP (1 << 4) +PAD_CTL_PUS_100K_UP (2 << 4) +PAD_CTL_PUS_22K_UP (3 << 4) +PAD_CTL_ODE (1 << 3) +PAD_CTL_DSE_LOW (0 << 1) +PAD_CTL_DSE_MED (1 << 1) +PAD_CTL_DSE_HIGH (2 << 1) +PAD_CTL_DSE_MAX (3 << 1) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) + +See below for available PIN_FUNC_ID for imx53: +MX53_PAD_GPIO_19__KPP_COL_5 0 +MX53_PAD_GPIO_19__GPIO4_5 1 +MX53_PAD_GPIO_19__CCM_CLKO 2 +MX53_PAD_GPIO_19__SPDIF_OUT1 3 +MX53_PAD_GPIO_19__RTC_CE_RTC_EXT_TRIG2 4 +MX53_PAD_GPIO_19__ECSPI1_RDY 5 +MX53_PAD_GPIO_19__FEC_TDATA_3 6 +MX53_PAD_GPIO_19__SRC_INT_BOOT 7 +MX53_PAD_KEY_COL0__KPP_COL_0 8 +MX53_PAD_KEY_COL0__GPIO4_6 9 +MX53_PAD_KEY_COL0__AUDMUX_AUD5_TXC 10 +MX53_PAD_KEY_COL0__UART4_TXD_MUX 11 +MX53_PAD_KEY_COL0__ECSPI1_SCLK 12 +MX53_PAD_KEY_COL0__FEC_RDATA_3 13 +MX53_PAD_KEY_COL0__SRC_ANY_PU_RST 14 +MX53_PAD_KEY_ROW0__KPP_ROW_0 15 +MX53_PAD_KEY_ROW0__GPIO4_7 16 +MX53_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 17 +MX53_PAD_KEY_ROW0__UART4_RXD_MUX 18 +MX53_PAD_KEY_ROW0__ECSPI1_MOSI 19 +MX53_PAD_KEY_ROW0__FEC_TX_ER 20 +MX53_PAD_KEY_COL1__KPP_COL_1 21 +MX53_PAD_KEY_COL1__GPIO4_8 22 +MX53_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 23 +MX53_PAD_KEY_COL1__UART5_TXD_MUX 24 +MX53_PAD_KEY_COL1__ECSPI1_MISO 25 +MX53_PAD_KEY_COL1__FEC_RX_CLK 26 +MX53_PAD_KEY_COL1__USBPHY1_TXREADY 27 +MX53_PAD_KEY_ROW1__KPP_ROW_1 28 +MX53_PAD_KEY_ROW1__GPIO4_9 29 +MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 30 +MX53_PAD_KEY_ROW1__UART5_RXD_MUX 31 +MX53_PAD_KEY_ROW1__ECSPI1_SS0 32 +MX53_PAD_KEY_ROW1__FEC_COL 33 +MX53_PAD_KEY_ROW1__USBPHY1_RXVALID 34 +MX53_PAD_KEY_COL2__KPP_COL_2 35 +MX53_PAD_KEY_COL2__GPIO4_10 36 +MX53_PAD_KEY_COL2__CAN1_TXCAN 37 +MX53_PAD_KEY_COL2__FEC_MDIO 38 +MX53_PAD_KEY_COL2__ECSPI1_SS1 39 +MX53_PAD_KEY_COL2__FEC_RDATA_2 40 +MX53_PAD_KEY_COL2__USBPHY1_RXACTIVE 41 +MX53_PAD_KEY_ROW2__KPP_ROW_2 42 +MX53_PAD_KEY_ROW2__GPIO4_11 43 +MX53_PAD_KEY_ROW2__CAN1_RXCAN 44 +MX53_PAD_KEY_ROW2__FEC_MDC 45 +MX53_PAD_KEY_ROW2__ECSPI1_SS2 46 +MX53_PAD_KEY_ROW2__FEC_TDATA_2 47 +MX53_PAD_KEY_ROW2__USBPHY1_RXERROR 48 +MX53_PAD_KEY_COL3__KPP_COL_3 49 +MX53_PAD_KEY_COL3__GPIO4_12 50 +MX53_PAD_KEY_COL3__USBOH3_H2_DP 51 +MX53_PAD_KEY_COL3__SPDIF_IN1 52 +MX53_PAD_KEY_COL3__I2C2_SCL 53 +MX53_PAD_KEY_COL3__ECSPI1_SS3 54 +MX53_PAD_KEY_COL3__FEC_CRS 55 +MX53_PAD_KEY_COL3__USBPHY1_SIECLOCK 56 +MX53_PAD_KEY_ROW3__KPP_ROW_3 57 +MX53_PAD_KEY_ROW3__GPIO4_13 58 +MX53_PAD_KEY_ROW3__USBOH3_H2_DM 59 +MX53_PAD_KEY_ROW3__CCM_ASRC_EXT_CLK 60 +MX53_PAD_KEY_ROW3__I2C2_SDA 61 +MX53_PAD_KEY_ROW3__OSC32K_32K_OUT 62 +MX53_PAD_KEY_ROW3__CCM_PLL4_BYP 63 +MX53_PAD_KEY_ROW3__USBPHY1_LINESTATE_0 64 +MX53_PAD_KEY_COL4__KPP_COL_4 65 +MX53_PAD_KEY_COL4__GPIO4_14 66 +MX53_PAD_KEY_COL4__CAN2_TXCAN 67 +MX53_PAD_KEY_COL4__IPU_SISG_4 68 +MX53_PAD_KEY_COL4__UART5_RTS 69 +MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC 70 +MX53_PAD_KEY_COL4__USBPHY1_LINESTATE_1 71 +MX53_PAD_KEY_ROW4__KPP_ROW_4 72 +MX53_PAD_KEY_ROW4__GPIO4_15 73 +MX53_PAD_KEY_ROW4__CAN2_RXCAN 74 +MX53_PAD_KEY_ROW4__IPU_SISG_5 75 +MX53_PAD_KEY_ROW4__UART5_CTS 76 +MX53_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 77 +MX53_PAD_KEY_ROW4__USBPHY1_VBUSVALID 78 +MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 79 +MX53_PAD_DI0_DISP_CLK__GPIO4_16 80 +MX53_PAD_DI0_DISP_CLK__USBOH3_USBH2_DIR 81 +MX53_PAD_DI0_DISP_CLK__SDMA_DEBUG_CORE_STATE_0 82 +MX53_PAD_DI0_DISP_CLK__EMI_EMI_DEBUG_0 83 +MX53_PAD_DI0_DISP_CLK__USBPHY1_AVALID 84 +MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 85 +MX53_PAD_DI0_PIN15__GPIO4_17 86 +MX53_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 87 +MX53_PAD_DI0_PIN15__SDMA_DEBUG_CORE_STATE_1 88 +MX53_PAD_DI0_PIN15__EMI_EMI_DEBUG_1 89 +MX53_PAD_DI0_PIN15__USBPHY1_BVALID 90 +MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 91 +MX53_PAD_DI0_PIN2__GPIO4_18 92 +MX53_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 93 +MX53_PAD_DI0_PIN2__SDMA_DEBUG_CORE_STATE_2 94 +MX53_PAD_DI0_PIN2__EMI_EMI_DEBUG_2 95 +MX53_PAD_DI0_PIN2__USBPHY1_ENDSESSION 96 +MX53_PAD_DI0_PIN3__IPU_DI0_PIN3 97 +MX53_PAD_DI0_PIN3__GPIO4_19 98 +MX53_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 99 +MX53_PAD_DI0_PIN3__SDMA_DEBUG_CORE_STATE_3 100 +MX53_PAD_DI0_PIN3__EMI_EMI_DEBUG_3 101 +MX53_PAD_DI0_PIN3__USBPHY1_IDDIG 102 +MX53_PAD_DI0_PIN4__IPU_DI0_PIN4 103 +MX53_PAD_DI0_PIN4__GPIO4_20 104 +MX53_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 105 +MX53_PAD_DI0_PIN4__ESDHC1_WP 106 +MX53_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 107 +MX53_PAD_DI0_PIN4__EMI_EMI_DEBUG_4 108 +MX53_PAD_DI0_PIN4__USBPHY1_HOSTDISCONNECT 109 +MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 110 +MX53_PAD_DISP0_DAT0__GPIO4_21 111 +MX53_PAD_DISP0_DAT0__CSPI_SCLK 112 +MX53_PAD_DISP0_DAT0__USBOH3_USBH2_DATA_0 113 +MX53_PAD_DISP0_DAT0__SDMA_DEBUG_CORE_RUN 114 +MX53_PAD_DISP0_DAT0__EMI_EMI_DEBUG_5 115 +MX53_PAD_DISP0_DAT0__USBPHY2_TXREADY 116 +MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 117 +MX53_PAD_DISP0_DAT1__GPIO4_22 118 +MX53_PAD_DISP0_DAT1__CSPI_MOSI 119 +MX53_PAD_DISP0_DAT1__USBOH3_USBH2_DATA_1 120 +MX53_PAD_DISP0_DAT1__SDMA_DEBUG_EVENT_CHANNEL_SEL 121 +MX53_PAD_DISP0_DAT1__EMI_EMI_DEBUG_6 122 +MX53_PAD_DISP0_DAT1__USBPHY2_RXVALID 123 +MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 124 +MX53_PAD_DISP0_DAT2__GPIO4_23 125 +MX53_PAD_DISP0_DAT2__CSPI_MISO 126 +MX53_PAD_DISP0_DAT2__USBOH3_USBH2_DATA_2 127 +MX53_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 128 +MX53_PAD_DISP0_DAT2__EMI_EMI_DEBUG_7 129 +MX53_PAD_DISP0_DAT2__USBPHY2_RXACTIVE 130 +MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 131 +MX53_PAD_DISP0_DAT3__GPIO4_24 132 +MX53_PAD_DISP0_DAT3__CSPI_SS0 133 +MX53_PAD_DISP0_DAT3__USBOH3_USBH2_DATA_3 134 +MX53_PAD_DISP0_DAT3__SDMA_DEBUG_BUS_ERROR 135 +MX53_PAD_DISP0_DAT3__EMI_EMI_DEBUG_8 136 +MX53_PAD_DISP0_DAT3__USBPHY2_RXERROR 137 +MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 138 +MX53_PAD_DISP0_DAT4__GPIO4_25 139 +MX53_PAD_DISP0_DAT4__CSPI_SS1 140 +MX53_PAD_DISP0_DAT4__USBOH3_USBH2_DATA_4 141 +MX53_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 142 +MX53_PAD_DISP0_DAT4__EMI_EMI_DEBUG_9 143 +MX53_PAD_DISP0_DAT4__USBPHY2_SIECLOCK 144 +MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 145 +MX53_PAD_DISP0_DAT5__GPIO4_26 146 +MX53_PAD_DISP0_DAT5__CSPI_SS2 147 +MX53_PAD_DISP0_DAT5__USBOH3_USBH2_DATA_5 148 +MX53_PAD_DISP0_DAT5__SDMA_DEBUG_MATCHED_DMBUS 149 +MX53_PAD_DISP0_DAT5__EMI_EMI_DEBUG_10 150 +MX53_PAD_DISP0_DAT5__USBPHY2_LINESTATE_0 151 +MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 152 +MX53_PAD_DISP0_DAT6__GPIO4_27 153 +MX53_PAD_DISP0_DAT6__CSPI_SS3 154 +MX53_PAD_DISP0_DAT6__USBOH3_USBH2_DATA_6 155 +MX53_PAD_DISP0_DAT6__SDMA_DEBUG_RTBUFFER_WRITE 156 +MX53_PAD_DISP0_DAT6__EMI_EMI_DEBUG_11 157 +MX53_PAD_DISP0_DAT6__USBPHY2_LINESTATE_1 158 +MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 159 +MX53_PAD_DISP0_DAT7__GPIO4_28 160 +MX53_PAD_DISP0_DAT7__CSPI_RDY 161 +MX53_PAD_DISP0_DAT7__USBOH3_USBH2_DATA_7 162 +MX53_PAD_DISP0_DAT7__SDMA_DEBUG_EVENT_CHANNEL_0 163 +MX53_PAD_DISP0_DAT7__EMI_EMI_DEBUG_12 164 +MX53_PAD_DISP0_DAT7__USBPHY2_VBUSVALID 165 +MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 166 +MX53_PAD_DISP0_DAT8__GPIO4_29 167 +MX53_PAD_DISP0_DAT8__PWM1_PWMO 168 +MX53_PAD_DISP0_DAT8__WDOG1_WDOG_B 169 +MX53_PAD_DISP0_DAT8__SDMA_DEBUG_EVENT_CHANNEL_1 170 +MX53_PAD_DISP0_DAT8__EMI_EMI_DEBUG_13 171 +MX53_PAD_DISP0_DAT8__USBPHY2_AVALID 172 +MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 173 +MX53_PAD_DISP0_DAT9__GPIO4_30 174 +MX53_PAD_DISP0_DAT9__PWM2_PWMO 175 +MX53_PAD_DISP0_DAT9__WDOG2_WDOG_B 176 +MX53_PAD_DISP0_DAT9__SDMA_DEBUG_EVENT_CHANNEL_2 177 +MX53_PAD_DISP0_DAT9__EMI_EMI_DEBUG_14 178 +MX53_PAD_DISP0_DAT9__USBPHY2_VSTATUS_0 179 +MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 180 +MX53_PAD_DISP0_DAT10__GPIO4_31 181 +MX53_PAD_DISP0_DAT10__USBOH3_USBH2_STP 182 +MX53_PAD_DISP0_DAT10__SDMA_DEBUG_EVENT_CHANNEL_3 183 +MX53_PAD_DISP0_DAT10__EMI_EMI_DEBUG_15 184 +MX53_PAD_DISP0_DAT10__USBPHY2_VSTATUS_1 185 +MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 186 +MX53_PAD_DISP0_DAT11__GPIO5_5 187 +MX53_PAD_DISP0_DAT11__USBOH3_USBH2_NXT 188 +MX53_PAD_DISP0_DAT11__SDMA_DEBUG_EVENT_CHANNEL_4 189 +MX53_PAD_DISP0_DAT11__EMI_EMI_DEBUG_16 190 +MX53_PAD_DISP0_DAT11__USBPHY2_VSTATUS_2 191 +MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 192 +MX53_PAD_DISP0_DAT12__GPIO5_6 193 +MX53_PAD_DISP0_DAT12__USBOH3_USBH2_CLK 194 +MX53_PAD_DISP0_DAT12__SDMA_DEBUG_EVENT_CHANNEL_5 195 +MX53_PAD_DISP0_DAT12__EMI_EMI_DEBUG_17 196 +MX53_PAD_DISP0_DAT12__USBPHY2_VSTATUS_3 197 +MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 198 +MX53_PAD_DISP0_DAT13__GPIO5_7 199 +MX53_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 200 +MX53_PAD_DISP0_DAT13__SDMA_DEBUG_EVT_CHN_LINES_0 201 +MX53_PAD_DISP0_DAT13__EMI_EMI_DEBUG_18 202 +MX53_PAD_DISP0_DAT13__USBPHY2_VSTATUS_4 203 +MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 204 +MX53_PAD_DISP0_DAT14__GPIO5_8 205 +MX53_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 206 +MX53_PAD_DISP0_DAT14__SDMA_DEBUG_EVT_CHN_LINES_1 207 +MX53_PAD_DISP0_DAT14__EMI_EMI_DEBUG_19 208 +MX53_PAD_DISP0_DAT14__USBPHY2_VSTATUS_5 209 +MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 210 +MX53_PAD_DISP0_DAT15__GPIO5_9 211 +MX53_PAD_DISP0_DAT15__ECSPI1_SS1 212 +MX53_PAD_DISP0_DAT15__ECSPI2_SS1 213 +MX53_PAD_DISP0_DAT15__SDMA_DEBUG_EVT_CHN_LINES_2 214 +MX53_PAD_DISP0_DAT15__EMI_EMI_DEBUG_20 215 +MX53_PAD_DISP0_DAT15__USBPHY2_VSTATUS_6 216 +MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 217 +MX53_PAD_DISP0_DAT16__GPIO5_10 218 +MX53_PAD_DISP0_DAT16__ECSPI2_MOSI 219 +MX53_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 220 +MX53_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 221 +MX53_PAD_DISP0_DAT16__SDMA_DEBUG_EVT_CHN_LINES_3 222 +MX53_PAD_DISP0_DAT16__EMI_EMI_DEBUG_21 223 +MX53_PAD_DISP0_DAT16__USBPHY2_VSTATUS_7 224 +MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 225 +MX53_PAD_DISP0_DAT17__GPIO5_11 226 +MX53_PAD_DISP0_DAT17__ECSPI2_MISO 227 +MX53_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 228 +MX53_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 229 +MX53_PAD_DISP0_DAT17__SDMA_DEBUG_EVT_CHN_LINES_4 230 +MX53_PAD_DISP0_DAT17__EMI_EMI_DEBUG_22 231 +MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 232 +MX53_PAD_DISP0_DAT18__GPIO5_12 233 +MX53_PAD_DISP0_DAT18__ECSPI2_SS0 234 +MX53_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 235 +MX53_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 236 +MX53_PAD_DISP0_DAT18__SDMA_DEBUG_EVT_CHN_LINES_5 237 +MX53_PAD_DISP0_DAT18__EMI_EMI_DEBUG_23 238 +MX53_PAD_DISP0_DAT18__EMI_WEIM_CS_2 239 +MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 240 +MX53_PAD_DISP0_DAT19__GPIO5_13 241 +MX53_PAD_DISP0_DAT19__ECSPI2_SCLK 242 +MX53_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 243 +MX53_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 244 +MX53_PAD_DISP0_DAT19__SDMA_DEBUG_EVT_CHN_LINES_6 245 +MX53_PAD_DISP0_DAT19__EMI_EMI_DEBUG_24 246 +MX53_PAD_DISP0_DAT19__EMI_WEIM_CS_3 247 +MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 248 +MX53_PAD_DISP0_DAT20__GPIO5_14 249 +MX53_PAD_DISP0_DAT20__ECSPI1_SCLK 250 +MX53_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 251 +MX53_PAD_DISP0_DAT20__SDMA_DEBUG_EVT_CHN_LINES_7 252 +MX53_PAD_DISP0_DAT20__EMI_EMI_DEBUG_25 253 +MX53_PAD_DISP0_DAT20__SATA_PHY_TDI 254 +MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 255 +MX53_PAD_DISP0_DAT21__GPIO5_15 256 +MX53_PAD_DISP0_DAT21__ECSPI1_MOSI 257 +MX53_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 258 +MX53_PAD_DISP0_DAT21__SDMA_DEBUG_BUS_DEVICE_0 259 +MX53_PAD_DISP0_DAT21__EMI_EMI_DEBUG_26 260 +MX53_PAD_DISP0_DAT21__SATA_PHY_TDO 261 +MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 262 +MX53_PAD_DISP0_DAT22__GPIO5_16 263 +MX53_PAD_DISP0_DAT22__ECSPI1_MISO 264 +MX53_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 265 +MX53_PAD_DISP0_DAT22__SDMA_DEBUG_BUS_DEVICE_1 266 +MX53_PAD_DISP0_DAT22__EMI_EMI_DEBUG_27 267 +MX53_PAD_DISP0_DAT22__SATA_PHY_TCK 268 +MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 269 +MX53_PAD_DISP0_DAT23__GPIO5_17 270 +MX53_PAD_DISP0_DAT23__ECSPI1_SS0 271 +MX53_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 272 +MX53_PAD_DISP0_DAT23__SDMA_DEBUG_BUS_DEVICE_2 273 +MX53_PAD_DISP0_DAT23__EMI_EMI_DEBUG_28 274 +MX53_PAD_DISP0_DAT23__SATA_PHY_TMS 275 +MX53_PAD_CSI0_PIXCLK__IPU_CSI0_PIXCLK 276 +MX53_PAD_CSI0_PIXCLK__GPIO5_18 277 +MX53_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 278 +MX53_PAD_CSI0_PIXCLK__EMI_EMI_DEBUG_29 279 +MX53_PAD_CSI0_MCLK__IPU_CSI0_HSYNC 280 +MX53_PAD_CSI0_MCLK__GPIO5_19 281 +MX53_PAD_CSI0_MCLK__CCM_CSI0_MCLK 282 +MX53_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 283 +MX53_PAD_CSI0_MCLK__EMI_EMI_DEBUG_30 284 +MX53_PAD_CSI0_MCLK__TPIU_TRCTL 285 +MX53_PAD_CSI0_DATA_EN__IPU_CSI0_DATA_EN 286 +MX53_PAD_CSI0_DATA_EN__GPIO5_20 287 +MX53_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 288 +MX53_PAD_CSI0_DATA_EN__EMI_EMI_DEBUG_31 289 +MX53_PAD_CSI0_DATA_EN__TPIU_TRCLK 290 +MX53_PAD_CSI0_VSYNC__IPU_CSI0_VSYNC 291 +MX53_PAD_CSI0_VSYNC__GPIO5_21 292 +MX53_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 293 +MX53_PAD_CSI0_VSYNC__EMI_EMI_DEBUG_32 294 +MX53_PAD_CSI0_VSYNC__TPIU_TRACE_0 295 +MX53_PAD_CSI0_DAT4__IPU_CSI0_D_4 296 +MX53_PAD_CSI0_DAT4__GPIO5_22 297 +MX53_PAD_CSI0_DAT4__KPP_COL_5 298 +MX53_PAD_CSI0_DAT4__ECSPI1_SCLK 299 +MX53_PAD_CSI0_DAT4__USBOH3_USBH3_STP 300 +MX53_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 301 +MX53_PAD_CSI0_DAT4__EMI_EMI_DEBUG_33 302 +MX53_PAD_CSI0_DAT4__TPIU_TRACE_1 303 +MX53_PAD_CSI0_DAT5__IPU_CSI0_D_5 304 +MX53_PAD_CSI0_DAT5__GPIO5_23 305 +MX53_PAD_CSI0_DAT5__KPP_ROW_5 306 +MX53_PAD_CSI0_DAT5__ECSPI1_MOSI 307 +MX53_PAD_CSI0_DAT5__USBOH3_USBH3_NXT 308 +MX53_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 309 +MX53_PAD_CSI0_DAT5__EMI_EMI_DEBUG_34 310 +MX53_PAD_CSI0_DAT5__TPIU_TRACE_2 311 +MX53_PAD_CSI0_DAT6__IPU_CSI0_D_6 312 +MX53_PAD_CSI0_DAT6__GPIO5_24 313 +MX53_PAD_CSI0_DAT6__KPP_COL_6 314 +MX53_PAD_CSI0_DAT6__ECSPI1_MISO 315 +MX53_PAD_CSI0_DAT6__USBOH3_USBH3_CLK 316 +MX53_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 317 +MX53_PAD_CSI0_DAT6__EMI_EMI_DEBUG_35 318 +MX53_PAD_CSI0_DAT6__TPIU_TRACE_3 319 +MX53_PAD_CSI0_DAT7__IPU_CSI0_D_7 320 +MX53_PAD_CSI0_DAT7__GPIO5_25 321 +MX53_PAD_CSI0_DAT7__KPP_ROW_6 322 +MX53_PAD_CSI0_DAT7__ECSPI1_SS0 323 +MX53_PAD_CSI0_DAT7__USBOH3_USBH3_DIR 324 +MX53_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 325 +MX53_PAD_CSI0_DAT7__EMI_EMI_DEBUG_36 326 +MX53_PAD_CSI0_DAT7__TPIU_TRACE_4 327 +MX53_PAD_CSI0_DAT8__IPU_CSI0_D_8 328 +MX53_PAD_CSI0_DAT8__GPIO5_26 329 +MX53_PAD_CSI0_DAT8__KPP_COL_7 330 +MX53_PAD_CSI0_DAT8__ECSPI2_SCLK 331 +MX53_PAD_CSI0_DAT8__USBOH3_USBH3_OC 332 +MX53_PAD_CSI0_DAT8__I2C1_SDA 333 +MX53_PAD_CSI0_DAT8__EMI_EMI_DEBUG_37 334 +MX53_PAD_CSI0_DAT8__TPIU_TRACE_5 335 +MX53_PAD_CSI0_DAT9__IPU_CSI0_D_9 336 +MX53_PAD_CSI0_DAT9__GPIO5_27 337 +MX53_PAD_CSI0_DAT9__KPP_ROW_7 338 +MX53_PAD_CSI0_DAT9__ECSPI2_MOSI 339 +MX53_PAD_CSI0_DAT9__USBOH3_USBH3_PWR 340 +MX53_PAD_CSI0_DAT9__I2C1_SCL 341 +MX53_PAD_CSI0_DAT9__EMI_EMI_DEBUG_38 342 +MX53_PAD_CSI0_DAT9__TPIU_TRACE_6 343 +MX53_PAD_CSI0_DAT10__IPU_CSI0_D_10 344 +MX53_PAD_CSI0_DAT10__GPIO5_28 345 +MX53_PAD_CSI0_DAT10__UART1_TXD_MUX 346 +MX53_PAD_CSI0_DAT10__ECSPI2_MISO 347 +MX53_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 348 +MX53_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 349 +MX53_PAD_CSI0_DAT10__EMI_EMI_DEBUG_39 350 +MX53_PAD_CSI0_DAT10__TPIU_TRACE_7 351 +MX53_PAD_CSI0_DAT11__IPU_CSI0_D_11 352 +MX53_PAD_CSI0_DAT11__GPIO5_29 353 +MX53_PAD_CSI0_DAT11__UART1_RXD_MUX 354 +MX53_PAD_CSI0_DAT11__ECSPI2_SS0 355 +MX53_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 356 +MX53_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 357 +MX53_PAD_CSI0_DAT11__EMI_EMI_DEBUG_40 358 +MX53_PAD_CSI0_DAT11__TPIU_TRACE_8 359 +MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12 360 +MX53_PAD_CSI0_DAT12__GPIO5_30 361 +MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 362 +MX53_PAD_CSI0_DAT12__USBOH3_USBH3_DATA_0 363 +MX53_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 364 +MX53_PAD_CSI0_DAT12__EMI_EMI_DEBUG_41 365 +MX53_PAD_CSI0_DAT12__TPIU_TRACE_9 366 +MX53_PAD_CSI0_DAT13__IPU_CSI0_D_13 367 +MX53_PAD_CSI0_DAT13__GPIO5_31 368 +MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 369 +MX53_PAD_CSI0_DAT13__USBOH3_USBH3_DATA_1 370 +MX53_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 371 +MX53_PAD_CSI0_DAT13__EMI_EMI_DEBUG_42 372 +MX53_PAD_CSI0_DAT13__TPIU_TRACE_10 373 +MX53_PAD_CSI0_DAT14__IPU_CSI0_D_14 374 +MX53_PAD_CSI0_DAT14__GPIO6_0 375 +MX53_PAD_CSI0_DAT14__UART5_TXD_MUX 376 +MX53_PAD_CSI0_DAT14__USBOH3_USBH3_DATA_2 377 +MX53_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 378 +MX53_PAD_CSI0_DAT14__EMI_EMI_DEBUG_43 379 +MX53_PAD_CSI0_DAT14__TPIU_TRACE_11 380 +MX53_PAD_CSI0_DAT15__IPU_CSI0_D_15 381 +MX53_PAD_CSI0_DAT15__GPIO6_1 382 +MX53_PAD_CSI0_DAT15__UART5_RXD_MUX 383 +MX53_PAD_CSI0_DAT15__USBOH3_USBH3_DATA_3 384 +MX53_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 385 +MX53_PAD_CSI0_DAT15__EMI_EMI_DEBUG_44 386 +MX53_PAD_CSI0_DAT15__TPIU_TRACE_12 387 +MX53_PAD_CSI0_DAT16__IPU_CSI0_D_16 388 +MX53_PAD_CSI0_DAT16__GPIO6_2 389 +MX53_PAD_CSI0_DAT16__UART4_RTS 390 +MX53_PAD_CSI0_DAT16__USBOH3_USBH3_DATA_4 391 +MX53_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 392 +MX53_PAD_CSI0_DAT16__EMI_EMI_DEBUG_45 393 +MX53_PAD_CSI0_DAT16__TPIU_TRACE_13 394 +MX53_PAD_CSI0_DAT17__IPU_CSI0_D_17 395 +MX53_PAD_CSI0_DAT17__GPIO6_3 396 +MX53_PAD_CSI0_DAT17__UART4_CTS 397 +MX53_PAD_CSI0_DAT17__USBOH3_USBH3_DATA_5 398 +MX53_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 399 +MX53_PAD_CSI0_DAT17__EMI_EMI_DEBUG_46 400 +MX53_PAD_CSI0_DAT17__TPIU_TRACE_14 401 +MX53_PAD_CSI0_DAT18__IPU_CSI0_D_18 402 +MX53_PAD_CSI0_DAT18__GPIO6_4 403 +MX53_PAD_CSI0_DAT18__UART5_RTS 404 +MX53_PAD_CSI0_DAT18__USBOH3_USBH3_DATA_6 405 +MX53_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 406 +MX53_PAD_CSI0_DAT18__EMI_EMI_DEBUG_47 407 +MX53_PAD_CSI0_DAT18__TPIU_TRACE_15 408 +MX53_PAD_CSI0_DAT19__IPU_CSI0_D_19 409 +MX53_PAD_CSI0_DAT19__GPIO6_5 410 +MX53_PAD_CSI0_DAT19__UART5_CTS 411 +MX53_PAD_CSI0_DAT19__USBOH3_USBH3_DATA_7 412 +MX53_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 413 +MX53_PAD_CSI0_DAT19__EMI_EMI_DEBUG_48 414 +MX53_PAD_CSI0_DAT19__USBPHY2_BISTOK 415 +MX53_PAD_EIM_A25__EMI_WEIM_A_25 416 +MX53_PAD_EIM_A25__GPIO5_2 417 +MX53_PAD_EIM_A25__ECSPI2_RDY 418 +MX53_PAD_EIM_A25__IPU_DI1_PIN12 419 +MX53_PAD_EIM_A25__CSPI_SS1 420 +MX53_PAD_EIM_A25__IPU_DI0_D1_CS 421 +MX53_PAD_EIM_A25__USBPHY1_BISTOK 422 +MX53_PAD_EIM_EB2__EMI_WEIM_EB_2 423 +MX53_PAD_EIM_EB2__GPIO2_30 424 +MX53_PAD_EIM_EB2__CCM_DI1_EXT_CLK 425 +MX53_PAD_EIM_EB2__IPU_SER_DISP1_CS 426 +MX53_PAD_EIM_EB2__ECSPI1_SS0 427 +MX53_PAD_EIM_EB2__I2C2_SCL 428 +MX53_PAD_EIM_D16__EMI_WEIM_D_16 429 +MX53_PAD_EIM_D16__GPIO3_16 430 +MX53_PAD_EIM_D16__IPU_DI0_PIN5 431 +MX53_PAD_EIM_D16__IPU_DISPB1_SER_CLK 432 +MX53_PAD_EIM_D16__ECSPI1_SCLK 433 +MX53_PAD_EIM_D16__I2C2_SDA 434 +MX53_PAD_EIM_D17__EMI_WEIM_D_17 435 +MX53_PAD_EIM_D17__GPIO3_17 436 +MX53_PAD_EIM_D17__IPU_DI0_PIN6 437 +MX53_PAD_EIM_D17__IPU_DISPB1_SER_DIN 438 +MX53_PAD_EIM_D17__ECSPI1_MISO 439 +MX53_PAD_EIM_D17__I2C3_SCL 440 +MX53_PAD_EIM_D18__EMI_WEIM_D_18 441 +MX53_PAD_EIM_D18__GPIO3_18 442 +MX53_PAD_EIM_D18__IPU_DI0_PIN7 443 +MX53_PAD_EIM_D18__IPU_DISPB1_SER_DIO 444 +MX53_PAD_EIM_D18__ECSPI1_MOSI 445 +MX53_PAD_EIM_D18__I2C3_SDA 446 +MX53_PAD_EIM_D18__IPU_DI1_D0_CS 447 +MX53_PAD_EIM_D19__EMI_WEIM_D_19 448 +MX53_PAD_EIM_D19__GPIO3_19 449 +MX53_PAD_EIM_D19__IPU_DI0_PIN8 450 +MX53_PAD_EIM_D19__IPU_DISPB1_SER_RS 451 +MX53_PAD_EIM_D19__ECSPI1_SS1 452 +MX53_PAD_EIM_D19__EPIT1_EPITO 453 +MX53_PAD_EIM_D19__UART1_CTS 454 +MX53_PAD_EIM_D19__USBOH3_USBH2_OC 455 +MX53_PAD_EIM_D20__EMI_WEIM_D_20 456 +MX53_PAD_EIM_D20__GPIO3_20 457 +MX53_PAD_EIM_D20__IPU_DI0_PIN16 458 +MX53_PAD_EIM_D20__IPU_SER_DISP0_CS 459 +MX53_PAD_EIM_D20__CSPI_SS0 460 +MX53_PAD_EIM_D20__EPIT2_EPITO 461 +MX53_PAD_EIM_D20__UART1_RTS 462 +MX53_PAD_EIM_D20__USBOH3_USBH2_PWR 463 +MX53_PAD_EIM_D21__EMI_WEIM_D_21 464 +MX53_PAD_EIM_D21__GPIO3_21 465 +MX53_PAD_EIM_D21__IPU_DI0_PIN17 466 +MX53_PAD_EIM_D21__IPU_DISPB0_SER_CLK 467 +MX53_PAD_EIM_D21__CSPI_SCLK 468 +MX53_PAD_EIM_D21__I2C1_SCL 469 +MX53_PAD_EIM_D21__USBOH3_USBOTG_OC 470 +MX53_PAD_EIM_D22__EMI_WEIM_D_22 471 +MX53_PAD_EIM_D22__GPIO3_22 472 +MX53_PAD_EIM_D22__IPU_DI0_PIN1 473 +MX53_PAD_EIM_D22__IPU_DISPB0_SER_DIN 474 +MX53_PAD_EIM_D22__CSPI_MISO 475 +MX53_PAD_EIM_D22__USBOH3_USBOTG_PWR 476 +MX53_PAD_EIM_D23__EMI_WEIM_D_23 477 +MX53_PAD_EIM_D23__GPIO3_23 478 +MX53_PAD_EIM_D23__UART3_CTS 479 +MX53_PAD_EIM_D23__UART1_DCD 480 +MX53_PAD_EIM_D23__IPU_DI0_D0_CS 481 +MX53_PAD_EIM_D23__IPU_DI1_PIN2 482 +MX53_PAD_EIM_D23__IPU_CSI1_DATA_EN 483 +MX53_PAD_EIM_D23__IPU_DI1_PIN14 484 +MX53_PAD_EIM_EB3__EMI_WEIM_EB_3 485 +MX53_PAD_EIM_EB3__GPIO2_31 486 +MX53_PAD_EIM_EB3__UART3_RTS 487 +MX53_PAD_EIM_EB3__UART1_RI 488 +MX53_PAD_EIM_EB3__IPU_DI1_PIN3 489 +MX53_PAD_EIM_EB3__IPU_CSI1_HSYNC 490 +MX53_PAD_EIM_EB3__IPU_DI1_PIN16 491 +MX53_PAD_EIM_D24__EMI_WEIM_D_24 492 +MX53_PAD_EIM_D24__GPIO3_24 493 +MX53_PAD_EIM_D24__UART3_TXD_MUX 494 +MX53_PAD_EIM_D24__ECSPI1_SS2 495 +MX53_PAD_EIM_D24__CSPI_SS2 496 +MX53_PAD_EIM_D24__AUDMUX_AUD5_RXFS 497 +MX53_PAD_EIM_D24__ECSPI2_SS2 498 +MX53_PAD_EIM_D24__UART1_DTR 499 +MX53_PAD_EIM_D25__EMI_WEIM_D_25 500 +MX53_PAD_EIM_D25__GPIO3_25 501 +MX53_PAD_EIM_D25__UART3_RXD_MUX 502 +MX53_PAD_EIM_D25__ECSPI1_SS3 503 +MX53_PAD_EIM_D25__CSPI_SS3 504 +MX53_PAD_EIM_D25__AUDMUX_AUD5_RXC 505 +MX53_PAD_EIM_D25__ECSPI2_SS3 506 +MX53_PAD_EIM_D25__UART1_DSR 507 +MX53_PAD_EIM_D26__EMI_WEIM_D_26 508 +MX53_PAD_EIM_D26__GPIO3_26 509 +MX53_PAD_EIM_D26__UART2_TXD_MUX 510 +MX53_PAD_EIM_D26__FIRI_RXD 511 +MX53_PAD_EIM_D26__IPU_CSI0_D_1 512 +MX53_PAD_EIM_D26__IPU_DI1_PIN11 513 +MX53_PAD_EIM_D26__IPU_SISG_2 514 +MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 515 +MX53_PAD_EIM_D27__EMI_WEIM_D_27 516 +MX53_PAD_EIM_D27__GPIO3_27 517 +MX53_PAD_EIM_D27__UART2_RXD_MUX 518 +MX53_PAD_EIM_D27__FIRI_TXD 519 +MX53_PAD_EIM_D27__IPU_CSI0_D_0 520 +MX53_PAD_EIM_D27__IPU_DI1_PIN13 521 +MX53_PAD_EIM_D27__IPU_SISG_3 522 +MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 523 +MX53_PAD_EIM_D28__EMI_WEIM_D_28 524 +MX53_PAD_EIM_D28__GPIO3_28 525 +MX53_PAD_EIM_D28__UART2_CTS 526 +MX53_PAD_EIM_D28__IPU_DISPB0_SER_DIO 527 +MX53_PAD_EIM_D28__CSPI_MOSI 528 +MX53_PAD_EIM_D28__I2C1_SDA 529 +MX53_PAD_EIM_D28__IPU_EXT_TRIG 530 +MX53_PAD_EIM_D28__IPU_DI0_PIN13 531 +MX53_PAD_EIM_D29__EMI_WEIM_D_29 532 +MX53_PAD_EIM_D29__GPIO3_29 533 +MX53_PAD_EIM_D29__UART2_RTS 534 +MX53_PAD_EIM_D29__IPU_DISPB0_SER_RS 535 +MX53_PAD_EIM_D29__CSPI_SS0 536 +MX53_PAD_EIM_D29__IPU_DI1_PIN15 537 +MX53_PAD_EIM_D29__IPU_CSI1_VSYNC 538 +MX53_PAD_EIM_D29__IPU_DI0_PIN14 539 +MX53_PAD_EIM_D30__EMI_WEIM_D_30 540 +MX53_PAD_EIM_D30__GPIO3_30 541 +MX53_PAD_EIM_D30__UART3_CTS 542 +MX53_PAD_EIM_D30__IPU_CSI0_D_3 543 +MX53_PAD_EIM_D30__IPU_DI0_PIN11 544 +MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 545 +MX53_PAD_EIM_D30__USBOH3_USBH1_OC 546 +MX53_PAD_EIM_D30__USBOH3_USBH2_OC 547 +MX53_PAD_EIM_D31__EMI_WEIM_D_31 548 +MX53_PAD_EIM_D31__GPIO3_31 549 +MX53_PAD_EIM_D31__UART3_RTS 550 +MX53_PAD_EIM_D31__IPU_CSI0_D_2 551 +MX53_PAD_EIM_D31__IPU_DI0_PIN12 552 +MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 553 +MX53_PAD_EIM_D31__USBOH3_USBH1_PWR 554 +MX53_PAD_EIM_D31__USBOH3_USBH2_PWR 555 +MX53_PAD_EIM_A24__EMI_WEIM_A_24 556 +MX53_PAD_EIM_A24__GPIO5_4 557 +MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 558 +MX53_PAD_EIM_A24__IPU_CSI1_D_19 559 +MX53_PAD_EIM_A24__IPU_SISG_2 560 +MX53_PAD_EIM_A24__USBPHY2_BVALID 561 +MX53_PAD_EIM_A23__EMI_WEIM_A_23 562 +MX53_PAD_EIM_A23__GPIO6_6 563 +MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 564 +MX53_PAD_EIM_A23__IPU_CSI1_D_18 565 +MX53_PAD_EIM_A23__IPU_SISG_3 566 +MX53_PAD_EIM_A23__USBPHY2_ENDSESSION 567 +MX53_PAD_EIM_A22__EMI_WEIM_A_22 568 +MX53_PAD_EIM_A22__GPIO2_16 569 +MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 570 +MX53_PAD_EIM_A22__IPU_CSI1_D_17 571 +MX53_PAD_EIM_A22__SRC_BT_CFG1_7 572 +MX53_PAD_EIM_A21__EMI_WEIM_A_21 573 +MX53_PAD_EIM_A21__GPIO2_17 574 +MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 575 +MX53_PAD_EIM_A21__IPU_CSI1_D_16 576 +MX53_PAD_EIM_A21__SRC_BT_CFG1_6 577 +MX53_PAD_EIM_A20__EMI_WEIM_A_20 578 +MX53_PAD_EIM_A20__GPIO2_18 579 +MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 580 +MX53_PAD_EIM_A20__IPU_CSI1_D_15 581 +MX53_PAD_EIM_A20__SRC_BT_CFG1_5 582 +MX53_PAD_EIM_A19__EMI_WEIM_A_19 583 +MX53_PAD_EIM_A19__GPIO2_19 584 +MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 585 +MX53_PAD_EIM_A19__IPU_CSI1_D_14 586 +MX53_PAD_EIM_A19__SRC_BT_CFG1_4 587 +MX53_PAD_EIM_A18__EMI_WEIM_A_18 588 +MX53_PAD_EIM_A18__GPIO2_20 589 +MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 590 +MX53_PAD_EIM_A18__IPU_CSI1_D_13 591 +MX53_PAD_EIM_A18__SRC_BT_CFG1_3 592 +MX53_PAD_EIM_A17__EMI_WEIM_A_17 593 +MX53_PAD_EIM_A17__GPIO2_21 594 +MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 595 +MX53_PAD_EIM_A17__IPU_CSI1_D_12 596 +MX53_PAD_EIM_A17__SRC_BT_CFG1_2 597 +MX53_PAD_EIM_A16__EMI_WEIM_A_16 598 +MX53_PAD_EIM_A16__GPIO2_22 599 +MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 600 +MX53_PAD_EIM_A16__IPU_CSI1_PIXCLK 601 +MX53_PAD_EIM_A16__SRC_BT_CFG1_1 602 +MX53_PAD_EIM_CS0__EMI_WEIM_CS_0 603 +MX53_PAD_EIM_CS0__GPIO2_23 604 +MX53_PAD_EIM_CS0__ECSPI2_SCLK 605 +MX53_PAD_EIM_CS0__IPU_DI1_PIN5 606 +MX53_PAD_EIM_CS1__EMI_WEIM_CS_1 607 +MX53_PAD_EIM_CS1__GPIO2_24 608 +MX53_PAD_EIM_CS1__ECSPI2_MOSI 609 +MX53_PAD_EIM_CS1__IPU_DI1_PIN6 610 +MX53_PAD_EIM_OE__EMI_WEIM_OE 611 +MX53_PAD_EIM_OE__GPIO2_25 612 +MX53_PAD_EIM_OE__ECSPI2_MISO 613 +MX53_PAD_EIM_OE__IPU_DI1_PIN7 614 +MX53_PAD_EIM_OE__USBPHY2_IDDIG 615 +MX53_PAD_EIM_RW__EMI_WEIM_RW 616 +MX53_PAD_EIM_RW__GPIO2_26 617 +MX53_PAD_EIM_RW__ECSPI2_SS0 618 +MX53_PAD_EIM_RW__IPU_DI1_PIN8 619 +MX53_PAD_EIM_RW__USBPHY2_HOSTDISCONNECT 620 +MX53_PAD_EIM_LBA__EMI_WEIM_LBA 621 +MX53_PAD_EIM_LBA__GPIO2_27 622 +MX53_PAD_EIM_LBA__ECSPI2_SS1 623 +MX53_PAD_EIM_LBA__IPU_DI1_PIN17 624 +MX53_PAD_EIM_LBA__SRC_BT_CFG1_0 625 +MX53_PAD_EIM_EB0__EMI_WEIM_EB_0 626 +MX53_PAD_EIM_EB0__GPIO2_28 627 +MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 628 +MX53_PAD_EIM_EB0__IPU_CSI1_D_11 629 +MX53_PAD_EIM_EB0__GPC_PMIC_RDY 630 +MX53_PAD_EIM_EB0__SRC_BT_CFG2_7 631 +MX53_PAD_EIM_EB1__EMI_WEIM_EB_1 632 +MX53_PAD_EIM_EB1__GPIO2_29 633 +MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 634 +MX53_PAD_EIM_EB1__IPU_CSI1_D_10 635 +MX53_PAD_EIM_EB1__SRC_BT_CFG2_6 636 +MX53_PAD_EIM_DA0__EMI_NAND_WEIM_DA_0 637 +MX53_PAD_EIM_DA0__GPIO3_0 638 +MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 639 +MX53_PAD_EIM_DA0__IPU_CSI1_D_9 640 +MX53_PAD_EIM_DA0__SRC_BT_CFG2_5 641 +MX53_PAD_EIM_DA1__EMI_NAND_WEIM_DA_1 642 +MX53_PAD_EIM_DA1__GPIO3_1 643 +MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 644 +MX53_PAD_EIM_DA1__IPU_CSI1_D_8 645 +MX53_PAD_EIM_DA1__SRC_BT_CFG2_4 646 +MX53_PAD_EIM_DA2__EMI_NAND_WEIM_DA_2 647 +MX53_PAD_EIM_DA2__GPIO3_2 648 +MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 649 +MX53_PAD_EIM_DA2__IPU_CSI1_D_7 650 +MX53_PAD_EIM_DA2__SRC_BT_CFG2_3 651 +MX53_PAD_EIM_DA3__EMI_NAND_WEIM_DA_3 652 +MX53_PAD_EIM_DA3__GPIO3_3 653 +MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 654 +MX53_PAD_EIM_DA3__IPU_CSI1_D_6 655 +MX53_PAD_EIM_DA3__SRC_BT_CFG2_2 656 +MX53_PAD_EIM_DA4__EMI_NAND_WEIM_DA_4 657 +MX53_PAD_EIM_DA4__GPIO3_4 658 +MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 659 +MX53_PAD_EIM_DA4__IPU_CSI1_D_5 660 +MX53_PAD_EIM_DA4__SRC_BT_CFG3_7 661 +MX53_PAD_EIM_DA5__EMI_NAND_WEIM_DA_5 662 +MX53_PAD_EIM_DA5__GPIO3_5 663 +MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 664 +MX53_PAD_EIM_DA5__IPU_CSI1_D_4 665 +MX53_PAD_EIM_DA5__SRC_BT_CFG3_6 666 +MX53_PAD_EIM_DA6__EMI_NAND_WEIM_DA_6 667 +MX53_PAD_EIM_DA6__GPIO3_6 668 +MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 669 +MX53_PAD_EIM_DA6__IPU_CSI1_D_3 670 +MX53_PAD_EIM_DA6__SRC_BT_CFG3_5 671 +MX53_PAD_EIM_DA7__EMI_NAND_WEIM_DA_7 672 +MX53_PAD_EIM_DA7__GPIO3_7 673 +MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 674 +MX53_PAD_EIM_DA7__IPU_CSI1_D_2 675 +MX53_PAD_EIM_DA7__SRC_BT_CFG3_4 676 +MX53_PAD_EIM_DA8__EMI_NAND_WEIM_DA_8 677 +MX53_PAD_EIM_DA8__GPIO3_8 678 +MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 679 +MX53_PAD_EIM_DA8__IPU_CSI1_D_1 680 +MX53_PAD_EIM_DA8__SRC_BT_CFG3_3 681 +MX53_PAD_EIM_DA9__EMI_NAND_WEIM_DA_9 682 +MX53_PAD_EIM_DA9__GPIO3_9 683 +MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 684 +MX53_PAD_EIM_DA9__IPU_CSI1_D_0 685 +MX53_PAD_EIM_DA9__SRC_BT_CFG3_2 686 +MX53_PAD_EIM_DA10__EMI_NAND_WEIM_DA_10 687 +MX53_PAD_EIM_DA10__GPIO3_10 688 +MX53_PAD_EIM_DA10__IPU_DI1_PIN15 689 +MX53_PAD_EIM_DA10__IPU_CSI1_DATA_EN 690 +MX53_PAD_EIM_DA10__SRC_BT_CFG3_1 691 +MX53_PAD_EIM_DA11__EMI_NAND_WEIM_DA_11 692 +MX53_PAD_EIM_DA11__GPIO3_11 693 +MX53_PAD_EIM_DA11__IPU_DI1_PIN2 694 +MX53_PAD_EIM_DA11__IPU_CSI1_HSYNC 695 +MX53_PAD_EIM_DA12__EMI_NAND_WEIM_DA_12 696 +MX53_PAD_EIM_DA12__GPIO3_12 697 +MX53_PAD_EIM_DA12__IPU_DI1_PIN3 698 +MX53_PAD_EIM_DA12__IPU_CSI1_VSYNC 699 +MX53_PAD_EIM_DA13__EMI_NAND_WEIM_DA_13 700 +MX53_PAD_EIM_DA13__GPIO3_13 701 +MX53_PAD_EIM_DA13__IPU_DI1_D0_CS 702 +MX53_PAD_EIM_DA13__CCM_DI1_EXT_CLK 703 +MX53_PAD_EIM_DA14__EMI_NAND_WEIM_DA_14 704 +MX53_PAD_EIM_DA14__GPIO3_14 705 +MX53_PAD_EIM_DA14__IPU_DI1_D1_CS 706 +MX53_PAD_EIM_DA14__CCM_DI0_EXT_CLK 707 +MX53_PAD_EIM_DA15__EMI_NAND_WEIM_DA_15 708 +MX53_PAD_EIM_DA15__GPIO3_15 709 +MX53_PAD_EIM_DA15__IPU_DI1_PIN1 710 +MX53_PAD_EIM_DA15__IPU_DI1_PIN4 711 +MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B 712 +MX53_PAD_NANDF_WE_B__GPIO6_12 713 +MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B 714 +MX53_PAD_NANDF_RE_B__GPIO6_13 715 +MX53_PAD_EIM_WAIT__EMI_WEIM_WAIT 716 +MX53_PAD_EIM_WAIT__GPIO5_0 717 +MX53_PAD_EIM_WAIT__EMI_WEIM_DTACK_B 718 +MX53_PAD_LVDS1_TX3_P__GPIO6_22 719 +MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 720 +MX53_PAD_LVDS1_TX2_P__GPIO6_24 721 +MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 722 +MX53_PAD_LVDS1_CLK_P__GPIO6_26 723 +MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 724 +MX53_PAD_LVDS1_TX1_P__GPIO6_28 725 +MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 726 +MX53_PAD_LVDS1_TX0_P__GPIO6_30 727 +MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 728 +MX53_PAD_LVDS0_TX3_P__GPIO7_22 729 +MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 730 +MX53_PAD_LVDS0_CLK_P__GPIO7_24 731 +MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 732 +MX53_PAD_LVDS0_TX2_P__GPIO7_26 733 +MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 734 +MX53_PAD_LVDS0_TX1_P__GPIO7_28 735 +MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 736 +MX53_PAD_LVDS0_TX0_P__GPIO7_30 737 +MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 738 +MX53_PAD_GPIO_10__GPIO4_0 739 +MX53_PAD_GPIO_10__OSC32k_32K_OUT 740 +MX53_PAD_GPIO_11__GPIO4_1 741 +MX53_PAD_GPIO_12__GPIO4_2 742 +MX53_PAD_GPIO_13__GPIO4_3 743 +MX53_PAD_GPIO_14__GPIO4_4 744 +MX53_PAD_NANDF_CLE__EMI_NANDF_CLE 745 +MX53_PAD_NANDF_CLE__GPIO6_7 746 +MX53_PAD_NANDF_CLE__USBPHY1_VSTATUS_0 747 +MX53_PAD_NANDF_ALE__EMI_NANDF_ALE 748 +MX53_PAD_NANDF_ALE__GPIO6_8 749 +MX53_PAD_NANDF_ALE__USBPHY1_VSTATUS_1 750 +MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B 751 +MX53_PAD_NANDF_WP_B__GPIO6_9 752 +MX53_PAD_NANDF_WP_B__USBPHY1_VSTATUS_2 753 +MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0 754 +MX53_PAD_NANDF_RB0__GPIO6_10 755 +MX53_PAD_NANDF_RB0__USBPHY1_VSTATUS_3 756 +MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0 757 +MX53_PAD_NANDF_CS0__GPIO6_11 758 +MX53_PAD_NANDF_CS0__USBPHY1_VSTATUS_4 759 +MX53_PAD_NANDF_CS1__EMI_NANDF_CS_1 760 +MX53_PAD_NANDF_CS1__GPIO6_14 761 +MX53_PAD_NANDF_CS1__MLB_MLBCLK 762 +MX53_PAD_NANDF_CS1__USBPHY1_VSTATUS_5 763 +MX53_PAD_NANDF_CS2__EMI_NANDF_CS_2 764 +MX53_PAD_NANDF_CS2__GPIO6_15 765 +MX53_PAD_NANDF_CS2__IPU_SISG_0 766 +MX53_PAD_NANDF_CS2__ESAI1_TX0 767 +MX53_PAD_NANDF_CS2__EMI_WEIM_CRE 768 +MX53_PAD_NANDF_CS2__CCM_CSI0_MCLK 769 +MX53_PAD_NANDF_CS2__MLB_MLBSIG 770 +MX53_PAD_NANDF_CS2__USBPHY1_VSTATUS_6 771 +MX53_PAD_NANDF_CS3__EMI_NANDF_CS_3 772 +MX53_PAD_NANDF_CS3__GPIO6_16 773 +MX53_PAD_NANDF_CS3__IPU_SISG_1 774 +MX53_PAD_NANDF_CS3__ESAI1_TX1 775 +MX53_PAD_NANDF_CS3__EMI_WEIM_A_26 776 +MX53_PAD_NANDF_CS3__MLB_MLBDAT 777 +MX53_PAD_NANDF_CS3__USBPHY1_VSTATUS_7 778 +MX53_PAD_FEC_MDIO__FEC_MDIO 779 +MX53_PAD_FEC_MDIO__GPIO1_22 780 +MX53_PAD_FEC_MDIO__ESAI1_SCKR 781 +MX53_PAD_FEC_MDIO__FEC_COL 782 +MX53_PAD_FEC_MDIO__RTC_CE_RTC_PS2 783 +MX53_PAD_FEC_MDIO__SDMA_DEBUG_BUS_DEVICE_3 784 +MX53_PAD_FEC_MDIO__EMI_EMI_DEBUG_49 785 +MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 786 +MX53_PAD_FEC_REF_CLK__GPIO1_23 787 +MX53_PAD_FEC_REF_CLK__ESAI1_FSR 788 +MX53_PAD_FEC_REF_CLK__SDMA_DEBUG_BUS_DEVICE_4 789 +MX53_PAD_FEC_REF_CLK__EMI_EMI_DEBUG_50 790 +MX53_PAD_FEC_RX_ER__FEC_RX_ER 791 +MX53_PAD_FEC_RX_ER__GPIO1_24 792 +MX53_PAD_FEC_RX_ER__ESAI1_HCKR 793 +MX53_PAD_FEC_RX_ER__FEC_RX_CLK 794 +MX53_PAD_FEC_RX_ER__RTC_CE_RTC_PS3 795 +MX53_PAD_FEC_CRS_DV__FEC_RX_DV 796 +MX53_PAD_FEC_CRS_DV__GPIO1_25 797 +MX53_PAD_FEC_CRS_DV__ESAI1_SCKT 798 +MX53_PAD_FEC_RXD1__FEC_RDATA_1 799 +MX53_PAD_FEC_RXD1__GPIO1_26 800 +MX53_PAD_FEC_RXD1__ESAI1_FST 801 +MX53_PAD_FEC_RXD1__MLB_MLBSIG 802 +MX53_PAD_FEC_RXD1__RTC_CE_RTC_PS1 803 +MX53_PAD_FEC_RXD0__FEC_RDATA_0 804 +MX53_PAD_FEC_RXD0__GPIO1_27 805 +MX53_PAD_FEC_RXD0__ESAI1_HCKT 806 +MX53_PAD_FEC_RXD0__OSC32k_32K_OUT 807 +MX53_PAD_FEC_TX_EN__FEC_TX_EN 808 +MX53_PAD_FEC_TX_EN__GPIO1_28 809 +MX53_PAD_FEC_TX_EN__ESAI1_TX3_RX2 810 +MX53_PAD_FEC_TXD1__FEC_TDATA_1 811 +MX53_PAD_FEC_TXD1__GPIO1_29 812 +MX53_PAD_FEC_TXD1__ESAI1_TX2_RX3 813 +MX53_PAD_FEC_TXD1__MLB_MLBCLK 814 +MX53_PAD_FEC_TXD1__RTC_CE_RTC_PRSC_CLK 815 +MX53_PAD_FEC_TXD0__FEC_TDATA_0 816 +MX53_PAD_FEC_TXD0__GPIO1_30 817 +MX53_PAD_FEC_TXD0__ESAI1_TX4_RX1 818 +MX53_PAD_FEC_TXD0__USBPHY2_DATAOUT_0 819 +MX53_PAD_FEC_MDC__FEC_MDC 820 +MX53_PAD_FEC_MDC__GPIO1_31 821 +MX53_PAD_FEC_MDC__ESAI1_TX5_RX0 822 +MX53_PAD_FEC_MDC__MLB_MLBDAT 823 +MX53_PAD_FEC_MDC__RTC_CE_RTC_ALARM1_TRIG 824 +MX53_PAD_FEC_MDC__USBPHY2_DATAOUT_1 825 +MX53_PAD_PATA_DIOW__PATA_DIOW 826 +MX53_PAD_PATA_DIOW__GPIO6_17 827 +MX53_PAD_PATA_DIOW__UART1_TXD_MUX 828 +MX53_PAD_PATA_DIOW__USBPHY2_DATAOUT_2 829 +MX53_PAD_PATA_DMACK__PATA_DMACK 830 +MX53_PAD_PATA_DMACK__GPIO6_18 831 +MX53_PAD_PATA_DMACK__UART1_RXD_MUX 832 +MX53_PAD_PATA_DMACK__USBPHY2_DATAOUT_3 833 +MX53_PAD_PATA_DMARQ__PATA_DMARQ 834 +MX53_PAD_PATA_DMARQ__GPIO7_0 835 +MX53_PAD_PATA_DMARQ__UART2_TXD_MUX 836 +MX53_PAD_PATA_DMARQ__CCM_CCM_OUT_0 837 +MX53_PAD_PATA_DMARQ__USBPHY2_DATAOUT_4 838 +MX53_PAD_PATA_BUFFER_EN__PATA_BUFFER_EN 839 +MX53_PAD_PATA_BUFFER_EN__GPIO7_1 840 +MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX 841 +MX53_PAD_PATA_BUFFER_EN__CCM_CCM_OUT_1 842 +MX53_PAD_PATA_BUFFER_EN__USBPHY2_DATAOUT_5 843 +MX53_PAD_PATA_INTRQ__PATA_INTRQ 844 +MX53_PAD_PATA_INTRQ__GPIO7_2 845 +MX53_PAD_PATA_INTRQ__UART2_CTS 846 +MX53_PAD_PATA_INTRQ__CAN1_TXCAN 847 +MX53_PAD_PATA_INTRQ__CCM_CCM_OUT_2 848 +MX53_PAD_PATA_INTRQ__USBPHY2_DATAOUT_6 849 +MX53_PAD_PATA_DIOR__PATA_DIOR 850 +MX53_PAD_PATA_DIOR__GPIO7_3 851 +MX53_PAD_PATA_DIOR__UART2_RTS 852 +MX53_PAD_PATA_DIOR__CAN1_RXCAN 853 +MX53_PAD_PATA_DIOR__USBPHY2_DATAOUT_7 854 +MX53_PAD_PATA_RESET_B__PATA_PATA_RESET_B 855 +MX53_PAD_PATA_RESET_B__GPIO7_4 856 +MX53_PAD_PATA_RESET_B__ESDHC3_CMD 857 +MX53_PAD_PATA_RESET_B__UART1_CTS 858 +MX53_PAD_PATA_RESET_B__CAN2_TXCAN 859 +MX53_PAD_PATA_RESET_B__USBPHY1_DATAOUT_0 860 +MX53_PAD_PATA_IORDY__PATA_IORDY 861 +MX53_PAD_PATA_IORDY__GPIO7_5 862 +MX53_PAD_PATA_IORDY__ESDHC3_CLK 863 +MX53_PAD_PATA_IORDY__UART1_RTS 864 +MX53_PAD_PATA_IORDY__CAN2_RXCAN 865 +MX53_PAD_PATA_IORDY__USBPHY1_DATAOUT_1 866 +MX53_PAD_PATA_DA_0__PATA_DA_0 867 +MX53_PAD_PATA_DA_0__GPIO7_6 868 +MX53_PAD_PATA_DA_0__ESDHC3_RST 869 +MX53_PAD_PATA_DA_0__OWIRE_LINE 870 +MX53_PAD_PATA_DA_0__USBPHY1_DATAOUT_2 871 +MX53_PAD_PATA_DA_1__PATA_DA_1 872 +MX53_PAD_PATA_DA_1__GPIO7_7 873 +MX53_PAD_PATA_DA_1__ESDHC4_CMD 874 +MX53_PAD_PATA_DA_1__UART3_CTS 875 +MX53_PAD_PATA_DA_1__USBPHY1_DATAOUT_3 876 +MX53_PAD_PATA_DA_2__PATA_DA_2 877 +MX53_PAD_PATA_DA_2__GPIO7_8 878 +MX53_PAD_PATA_DA_2__ESDHC4_CLK 879 +MX53_PAD_PATA_DA_2__UART3_RTS 880 +MX53_PAD_PATA_DA_2__USBPHY1_DATAOUT_4 881 +MX53_PAD_PATA_CS_0__PATA_CS_0 882 +MX53_PAD_PATA_CS_0__GPIO7_9 883 +MX53_PAD_PATA_CS_0__UART3_TXD_MUX 884 +MX53_PAD_PATA_CS_0__USBPHY1_DATAOUT_5 885 +MX53_PAD_PATA_CS_1__PATA_CS_1 886 +MX53_PAD_PATA_CS_1__GPIO7_10 887 +MX53_PAD_PATA_CS_1__UART3_RXD_MUX 888 +MX53_PAD_PATA_CS_1__USBPHY1_DATAOUT_6 889 +MX53_PAD_PATA_DATA0__PATA_DATA_0 890 +MX53_PAD_PATA_DATA0__GPIO2_0 891 +MX53_PAD_PATA_DATA0__EMI_NANDF_D_0 892 +MX53_PAD_PATA_DATA0__ESDHC3_DAT4 893 +MX53_PAD_PATA_DATA0__GPU3d_GPU_DEBUG_OUT_0 894 +MX53_PAD_PATA_DATA0__IPU_DIAG_BUS_0 895 +MX53_PAD_PATA_DATA0__USBPHY1_DATAOUT_7 896 +MX53_PAD_PATA_DATA1__PATA_DATA_1 897 +MX53_PAD_PATA_DATA1__GPIO2_1 898 +MX53_PAD_PATA_DATA1__EMI_NANDF_D_1 899 +MX53_PAD_PATA_DATA1__ESDHC3_DAT5 900 +MX53_PAD_PATA_DATA1__GPU3d_GPU_DEBUG_OUT_1 901 +MX53_PAD_PATA_DATA1__IPU_DIAG_BUS_1 902 +MX53_PAD_PATA_DATA2__PATA_DATA_2 903 +MX53_PAD_PATA_DATA2__GPIO2_2 904 +MX53_PAD_PATA_DATA2__EMI_NANDF_D_2 905 +MX53_PAD_PATA_DATA2__ESDHC3_DAT6 906 +MX53_PAD_PATA_DATA2__GPU3d_GPU_DEBUG_OUT_2 907 +MX53_PAD_PATA_DATA2__IPU_DIAG_BUS_2 908 +MX53_PAD_PATA_DATA3__PATA_DATA_3 909 +MX53_PAD_PATA_DATA3__GPIO2_3 910 +MX53_PAD_PATA_DATA3__EMI_NANDF_D_3 911 +MX53_PAD_PATA_DATA3__ESDHC3_DAT7 912 +MX53_PAD_PATA_DATA3__GPU3d_GPU_DEBUG_OUT_3 913 +MX53_PAD_PATA_DATA3__IPU_DIAG_BUS_3 914 +MX53_PAD_PATA_DATA4__PATA_DATA_4 915 +MX53_PAD_PATA_DATA4__GPIO2_4 916 +MX53_PAD_PATA_DATA4__EMI_NANDF_D_4 917 +MX53_PAD_PATA_DATA4__ESDHC4_DAT4 918 +MX53_PAD_PATA_DATA4__GPU3d_GPU_DEBUG_OUT_4 919 +MX53_PAD_PATA_DATA4__IPU_DIAG_BUS_4 920 +MX53_PAD_PATA_DATA5__PATA_DATA_5 921 +MX53_PAD_PATA_DATA5__GPIO2_5 922 +MX53_PAD_PATA_DATA5__EMI_NANDF_D_5 923 +MX53_PAD_PATA_DATA5__ESDHC4_DAT5 924 +MX53_PAD_PATA_DATA5__GPU3d_GPU_DEBUG_OUT_5 925 +MX53_PAD_PATA_DATA5__IPU_DIAG_BUS_5 926 +MX53_PAD_PATA_DATA6__PATA_DATA_6 927 +MX53_PAD_PATA_DATA6__GPIO2_6 928 +MX53_PAD_PATA_DATA6__EMI_NANDF_D_6 929 +MX53_PAD_PATA_DATA6__ESDHC4_DAT6 930 +MX53_PAD_PATA_DATA6__GPU3d_GPU_DEBUG_OUT_6 931 +MX53_PAD_PATA_DATA6__IPU_DIAG_BUS_6 932 +MX53_PAD_PATA_DATA7__PATA_DATA_7 933 +MX53_PAD_PATA_DATA7__GPIO2_7 934 +MX53_PAD_PATA_DATA7__EMI_NANDF_D_7 935 +MX53_PAD_PATA_DATA7__ESDHC4_DAT7 936 +MX53_PAD_PATA_DATA7__GPU3d_GPU_DEBUG_OUT_7 937 +MX53_PAD_PATA_DATA7__IPU_DIAG_BUS_7 938 +MX53_PAD_PATA_DATA8__PATA_DATA_8 939 +MX53_PAD_PATA_DATA8__GPIO2_8 940 +MX53_PAD_PATA_DATA8__ESDHC1_DAT4 941 +MX53_PAD_PATA_DATA8__EMI_NANDF_D_8 942 +MX53_PAD_PATA_DATA8__ESDHC3_DAT0 943 +MX53_PAD_PATA_DATA8__GPU3d_GPU_DEBUG_OUT_8 944 +MX53_PAD_PATA_DATA8__IPU_DIAG_BUS_8 945 +MX53_PAD_PATA_DATA9__PATA_DATA_9 946 +MX53_PAD_PATA_DATA9__GPIO2_9 947 +MX53_PAD_PATA_DATA9__ESDHC1_DAT5 948 +MX53_PAD_PATA_DATA9__EMI_NANDF_D_9 949 +MX53_PAD_PATA_DATA9__ESDHC3_DAT1 950 +MX53_PAD_PATA_DATA9__GPU3d_GPU_DEBUG_OUT_9 951 +MX53_PAD_PATA_DATA9__IPU_DIAG_BUS_9 952 +MX53_PAD_PATA_DATA10__PATA_DATA_10 953 +MX53_PAD_PATA_DATA10__GPIO2_10 954 +MX53_PAD_PATA_DATA10__ESDHC1_DAT6 955 +MX53_PAD_PATA_DATA10__EMI_NANDF_D_10 956 +MX53_PAD_PATA_DATA10__ESDHC3_DAT2 957 +MX53_PAD_PATA_DATA10__GPU3d_GPU_DEBUG_OUT_10 958 +MX53_PAD_PATA_DATA10__IPU_DIAG_BUS_10 959 +MX53_PAD_PATA_DATA11__PATA_DATA_11 960 +MX53_PAD_PATA_DATA11__GPIO2_11 961 +MX53_PAD_PATA_DATA11__ESDHC1_DAT7 962 +MX53_PAD_PATA_DATA11__EMI_NANDF_D_11 963 +MX53_PAD_PATA_DATA11__ESDHC3_DAT3 964 +MX53_PAD_PATA_DATA11__GPU3d_GPU_DEBUG_OUT_11 965 +MX53_PAD_PATA_DATA11__IPU_DIAG_BUS_11 966 +MX53_PAD_PATA_DATA12__PATA_DATA_12 967 +MX53_PAD_PATA_DATA12__GPIO2_12 968 +MX53_PAD_PATA_DATA12__ESDHC2_DAT4 969 +MX53_PAD_PATA_DATA12__EMI_NANDF_D_12 970 +MX53_PAD_PATA_DATA12__ESDHC4_DAT0 971 +MX53_PAD_PATA_DATA12__GPU3d_GPU_DEBUG_OUT_12 972 +MX53_PAD_PATA_DATA12__IPU_DIAG_BUS_12 973 +MX53_PAD_PATA_DATA13__PATA_DATA_13 974 +MX53_PAD_PATA_DATA13__GPIO2_13 975 +MX53_PAD_PATA_DATA13__ESDHC2_DAT5 976 +MX53_PAD_PATA_DATA13__EMI_NANDF_D_13 977 +MX53_PAD_PATA_DATA13__ESDHC4_DAT1 978 +MX53_PAD_PATA_DATA13__GPU3d_GPU_DEBUG_OUT_13 979 +MX53_PAD_PATA_DATA13__IPU_DIAG_BUS_13 980 +MX53_PAD_PATA_DATA14__PATA_DATA_14 981 +MX53_PAD_PATA_DATA14__GPIO2_14 982 +MX53_PAD_PATA_DATA14__ESDHC2_DAT6 983 +MX53_PAD_PATA_DATA14__EMI_NANDF_D_14 984 +MX53_PAD_PATA_DATA14__ESDHC4_DAT2 985 +MX53_PAD_PATA_DATA14__GPU3d_GPU_DEBUG_OUT_14 986 +MX53_PAD_PATA_DATA14__IPU_DIAG_BUS_14 987 +MX53_PAD_PATA_DATA15__PATA_DATA_15 988 +MX53_PAD_PATA_DATA15__GPIO2_15 989 +MX53_PAD_PATA_DATA15__ESDHC2_DAT7 990 +MX53_PAD_PATA_DATA15__EMI_NANDF_D_15 991 +MX53_PAD_PATA_DATA15__ESDHC4_DAT3 992 +MX53_PAD_PATA_DATA15__GPU3d_GPU_DEBUG_OUT_15 993 +MX53_PAD_PATA_DATA15__IPU_DIAG_BUS_15 994 +MX53_PAD_SD1_DATA0__ESDHC1_DAT0 995 +MX53_PAD_SD1_DATA0__GPIO1_16 996 +MX53_PAD_SD1_DATA0__GPT_CAPIN1 997 +MX53_PAD_SD1_DATA0__CSPI_MISO 998 +MX53_PAD_SD1_DATA0__CCM_PLL3_BYP 999 +MX53_PAD_SD1_DATA1__ESDHC1_DAT1 1000 +MX53_PAD_SD1_DATA1__GPIO1_17 1001 +MX53_PAD_SD1_DATA1__GPT_CAPIN2 1002 +MX53_PAD_SD1_DATA1__CSPI_SS0 1003 +MX53_PAD_SD1_DATA1__CCM_PLL4_BYP 1004 +MX53_PAD_SD1_CMD__ESDHC1_CMD 1005 +MX53_PAD_SD1_CMD__GPIO1_18 1006 +MX53_PAD_SD1_CMD__GPT_CMPOUT1 1007 +MX53_PAD_SD1_CMD__CSPI_MOSI 1008 +MX53_PAD_SD1_CMD__CCM_PLL1_BYP 1009 +MX53_PAD_SD1_DATA2__ESDHC1_DAT2 1010 +MX53_PAD_SD1_DATA2__GPIO1_19 1011 +MX53_PAD_SD1_DATA2__GPT_CMPOUT2 1012 +MX53_PAD_SD1_DATA2__PWM2_PWMO 1013 +MX53_PAD_SD1_DATA2__WDOG1_WDOG_B 1014 +MX53_PAD_SD1_DATA2__CSPI_SS1 1015 +MX53_PAD_SD1_DATA2__WDOG1_WDOG_RST_B_DEB 1016 +MX53_PAD_SD1_DATA2__CCM_PLL2_BYP 1017 +MX53_PAD_SD1_CLK__ESDHC1_CLK 1018 +MX53_PAD_SD1_CLK__GPIO1_20 1019 +MX53_PAD_SD1_CLK__OSC32k_32K_OUT 1020 +MX53_PAD_SD1_CLK__GPT_CLKIN 1021 +MX53_PAD_SD1_CLK__CSPI_SCLK 1022 +MX53_PAD_SD1_CLK__SATA_PHY_DTB_0 1023 +MX53_PAD_SD1_DATA3__ESDHC1_DAT3 1024 +MX53_PAD_SD1_DATA3__GPIO1_21 1025 +MX53_PAD_SD1_DATA3__GPT_CMPOUT3 1026 +MX53_PAD_SD1_DATA3__PWM1_PWMO 1027 +MX53_PAD_SD1_DATA3__WDOG2_WDOG_B 1028 +MX53_PAD_SD1_DATA3__CSPI_SS2 1029 +MX53_PAD_SD1_DATA3__WDOG2_WDOG_RST_B_DEB 1030 +MX53_PAD_SD1_DATA3__SATA_PHY_DTB_1 1031 +MX53_PAD_SD2_CLK__ESDHC2_CLK 1032 +MX53_PAD_SD2_CLK__GPIO1_10 1033 +MX53_PAD_SD2_CLK__KPP_COL_5 1034 +MX53_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1035 +MX53_PAD_SD2_CLK__CSPI_SCLK 1036 +MX53_PAD_SD2_CLK__SCC_RANDOM_V 1037 +MX53_PAD_SD2_CMD__ESDHC2_CMD 1038 +MX53_PAD_SD2_CMD__GPIO1_11 1039 +MX53_PAD_SD2_CMD__KPP_ROW_5 1040 +MX53_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1041 +MX53_PAD_SD2_CMD__CSPI_MOSI 1042 +MX53_PAD_SD2_CMD__SCC_RANDOM 1043 +MX53_PAD_SD2_DATA3__ESDHC2_DAT3 1044 +MX53_PAD_SD2_DATA3__GPIO1_12 1045 +MX53_PAD_SD2_DATA3__KPP_COL_6 1046 +MX53_PAD_SD2_DATA3__AUDMUX_AUD4_TXC 1047 +MX53_PAD_SD2_DATA3__CSPI_SS2 1048 +MX53_PAD_SD2_DATA3__SJC_DONE 1049 +MX53_PAD_SD2_DATA2__ESDHC2_DAT2 1050 +MX53_PAD_SD2_DATA2__GPIO1_13 1051 +MX53_PAD_SD2_DATA2__KPP_ROW_6 1052 +MX53_PAD_SD2_DATA2__AUDMUX_AUD4_TXD 1053 +MX53_PAD_SD2_DATA2__CSPI_SS1 1054 +MX53_PAD_SD2_DATA2__SJC_FAIL 1055 +MX53_PAD_SD2_DATA1__ESDHC2_DAT1 1056 +MX53_PAD_SD2_DATA1__GPIO1_14 1057 +MX53_PAD_SD2_DATA1__KPP_COL_7 1058 +MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS 1059 +MX53_PAD_SD2_DATA1__CSPI_SS0 1060 +MX53_PAD_SD2_DATA1__RTIC_SEC_VIO 1061 +MX53_PAD_SD2_DATA0__ESDHC2_DAT0 1062 +MX53_PAD_SD2_DATA0__GPIO1_15 1063 +MX53_PAD_SD2_DATA0__KPP_ROW_7 1064 +MX53_PAD_SD2_DATA0__AUDMUX_AUD4_RXD 1065 +MX53_PAD_SD2_DATA0__CSPI_MISO 1066 +MX53_PAD_SD2_DATA0__RTIC_DONE_INT 1067 +MX53_PAD_GPIO_0__CCM_CLKO 1068 +MX53_PAD_GPIO_0__GPIO1_0 1069 +MX53_PAD_GPIO_0__KPP_COL_5 1070 +MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 1071 +MX53_PAD_GPIO_0__EPIT1_EPITO 1072 +MX53_PAD_GPIO_0__SRTC_ALARM_DEB 1073 +MX53_PAD_GPIO_0__USBOH3_USBH1_PWR 1074 +MX53_PAD_GPIO_0__CSU_TD 1075 +MX53_PAD_GPIO_1__ESAI1_SCKR 1076 +MX53_PAD_GPIO_1__GPIO1_1 1077 +MX53_PAD_GPIO_1__KPP_ROW_5 1078 +MX53_PAD_GPIO_1__CCM_SSI_EXT2_CLK 1079 +MX53_PAD_GPIO_1__PWM2_PWMO 1080 +MX53_PAD_GPIO_1__WDOG2_WDOG_B 1081 +MX53_PAD_GPIO_1__ESDHC1_CD 1082 +MX53_PAD_GPIO_1__SRC_TESTER_ACK 1083 +MX53_PAD_GPIO_9__ESAI1_FSR 1084 +MX53_PAD_GPIO_9__GPIO1_9 1085 +MX53_PAD_GPIO_9__KPP_COL_6 1086 +MX53_PAD_GPIO_9__CCM_REF_EN_B 1087 +MX53_PAD_GPIO_9__PWM1_PWMO 1088 +MX53_PAD_GPIO_9__WDOG1_WDOG_B 1089 +MX53_PAD_GPIO_9__ESDHC1_WP 1090 +MX53_PAD_GPIO_9__SCC_FAIL_STATE 1091 +MX53_PAD_GPIO_3__ESAI1_HCKR 1092 +MX53_PAD_GPIO_3__GPIO1_3 1093 +MX53_PAD_GPIO_3__I2C3_SCL 1094 +MX53_PAD_GPIO_3__DPLLIP1_TOG_EN 1095 +MX53_PAD_GPIO_3__CCM_CLKO2 1096 +MX53_PAD_GPIO_3__OBSERVE_MUX_OBSRV_INT_OUT0 1097 +MX53_PAD_GPIO_3__USBOH3_USBH1_OC 1098 +MX53_PAD_GPIO_3__MLB_MLBCLK 1099 +MX53_PAD_GPIO_6__ESAI1_SCKT 1100 +MX53_PAD_GPIO_6__GPIO1_6 1101 +MX53_PAD_GPIO_6__I2C3_SDA 1102 +MX53_PAD_GPIO_6__CCM_CCM_OUT_0 1103 +MX53_PAD_GPIO_6__CSU_CSU_INT_DEB 1104 +MX53_PAD_GPIO_6__OBSERVE_MUX_OBSRV_INT_OUT1 1105 +MX53_PAD_GPIO_6__ESDHC2_LCTL 1106 +MX53_PAD_GPIO_6__MLB_MLBSIG 1107 +MX53_PAD_GPIO_2__ESAI1_FST 1108 +MX53_PAD_GPIO_2__GPIO1_2 1109 +MX53_PAD_GPIO_2__KPP_ROW_6 1110 +MX53_PAD_GPIO_2__CCM_CCM_OUT_1 1111 +MX53_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 1112 +MX53_PAD_GPIO_2__OBSERVE_MUX_OBSRV_INT_OUT2 1113 +MX53_PAD_GPIO_2__ESDHC2_WP 1114 +MX53_PAD_GPIO_2__MLB_MLBDAT 1115 +MX53_PAD_GPIO_4__ESAI1_HCKT 1116 +MX53_PAD_GPIO_4__GPIO1_4 1117 +MX53_PAD_GPIO_4__KPP_COL_7 1118 +MX53_PAD_GPIO_4__CCM_CCM_OUT_2 1119 +MX53_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1120 +MX53_PAD_GPIO_4__OBSERVE_MUX_OBSRV_INT_OUT3 1121 +MX53_PAD_GPIO_4__ESDHC2_CD 1122 +MX53_PAD_GPIO_4__SCC_SEC_STATE 1123 +MX53_PAD_GPIO_5__ESAI1_TX2_RX3 1124 +MX53_PAD_GPIO_5__GPIO1_5 1125 +MX53_PAD_GPIO_5__KPP_ROW_7 1126 +MX53_PAD_GPIO_5__CCM_CLKO 1127 +MX53_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1128 +MX53_PAD_GPIO_5__OBSERVE_MUX_OBSRV_INT_OUT4 1129 +MX53_PAD_GPIO_5__I2C3_SCL 1130 +MX53_PAD_GPIO_5__CCM_PLL1_BYP 1131 +MX53_PAD_GPIO_7__ESAI1_TX4_RX1 1132 +MX53_PAD_GPIO_7__GPIO1_7 1133 +MX53_PAD_GPIO_7__EPIT1_EPITO 1134 +MX53_PAD_GPIO_7__CAN1_TXCAN 1135 +MX53_PAD_GPIO_7__UART2_TXD_MUX 1136 +MX53_PAD_GPIO_7__FIRI_RXD 1137 +MX53_PAD_GPIO_7__SPDIF_PLOCK 1138 +MX53_PAD_GPIO_7__CCM_PLL2_BYP 1139 +MX53_PAD_GPIO_8__ESAI1_TX5_RX0 1140 +MX53_PAD_GPIO_8__GPIO1_8 1141 +MX53_PAD_GPIO_8__EPIT2_EPITO 1142 +MX53_PAD_GPIO_8__CAN1_RXCAN 1143 +MX53_PAD_GPIO_8__UART2_RXD_MUX 1144 +MX53_PAD_GPIO_8__FIRI_TXD 1145 +MX53_PAD_GPIO_8__SPDIF_SRCLK 1146 +MX53_PAD_GPIO_8__CCM_PLL3_BYP 1147 +MX53_PAD_GPIO_16__ESAI1_TX3_RX2 1148 +MX53_PAD_GPIO_16__GPIO7_11 1149 +MX53_PAD_GPIO_16__TZIC_PWRFAIL_INT 1150 +MX53_PAD_GPIO_16__RTC_CE_RTC_EXT_TRIG1 1151 +MX53_PAD_GPIO_16__SPDIF_IN1 1152 +MX53_PAD_GPIO_16__I2C3_SDA 1153 +MX53_PAD_GPIO_16__SJC_DE_B 1154 +MX53_PAD_GPIO_17__ESAI1_TX0 1155 +MX53_PAD_GPIO_17__GPIO7_12 1156 +MX53_PAD_GPIO_17__SDMA_EXT_EVENT_0 1157 +MX53_PAD_GPIO_17__GPC_PMIC_RDY 1158 +MX53_PAD_GPIO_17__RTC_CE_RTC_FSV_TRIG 1159 +MX53_PAD_GPIO_17__SPDIF_OUT1 1160 +MX53_PAD_GPIO_17__IPU_SNOOP2 1161 +MX53_PAD_GPIO_17__SJC_JTAG_ACT 1162 +MX53_PAD_GPIO_18__ESAI1_TX1 1163 +MX53_PAD_GPIO_18__GPIO7_13 1164 +MX53_PAD_GPIO_18__SDMA_EXT_EVENT_1 1165 +MX53_PAD_GPIO_18__OWIRE_LINE 1166 +MX53_PAD_GPIO_18__RTC_CE_RTC_ALARM2_TRIG 1167 +MX53_PAD_GPIO_18__CCM_ASRC_EXT_CLK 1168 +MX53_PAD_GPIO_18__ESDHC1_LCTL 1169 +MX53_PAD_GPIO_18__SRC_SYSTEM_RST 1170 diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt index 9cf57fd042d..2f5b6b1ba15 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt @@ -8,6 +8,8 @@ Optional properties: - startup-delay-us: startup time in microseconds - enable-active-high: Polarity of GPIO is Active high If this property is missing, the default assumed is Active low. +- gpio-open-drain: GPIO is open drain type. + If this property is missing then default assumption is false. Any property defined as part of the core regulator binding, defined in regulator.txt, can also be used. @@ -25,5 +27,6 @@ Example: gpio = <&gpio1 16 0>; startup-delay-us = <70000>; enable-active-high; - regulator-boot-on + regulator-boot-on; + gpio-open-drain; }; diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt new file mode 100644 index 00000000000..c8ca6b8f658 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt @@ -0,0 +1,44 @@ +TPS62360 Voltage regulators + +Required properties: +- compatible: Must be one of the following. + "ti,tps62360" + "ti,tps62361", + "ti,tps62362", + "ti,tps62363", +- reg: I2C slave address + +Optional properties: +- ti,enable-vout-discharge: Enable output discharge. This is boolean value. +- ti,enable-pull-down: Enable pull down. This is boolean value. +- ti,vsel0-gpio: GPIO for controlling VSEL0 line. + If this property is missing, then assume that there is no GPIO + for vsel0 control. +- ti,vsel1-gpio: Gpio for controlling VSEL1 line. + If this property is missing, then assume that there is no GPIO + for vsel1 control. +- ti,vsel0-state-high: Inital state of vsel0 input is high. + If this property is missing, then assume the state as low (0). +- ti,vsel1-state-high: Inital state of vsel1 input is high. + If this property is missing, then assume the state as low (0). + +Any property defined as part of the core regulator binding, defined in +regulator.txt, can also be used. + +Example: + + abc: tps62360 { + compatible = "ti,tps62361"; + reg = <0x60>; + regulator-name = "tps62361-vout"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on + ti,vsel0-gpio = <&gpio1 16 0>; + ti,vsel1-gpio = <&gpio1 17 0>; + ti,vsel0-state-high; + ti,vsel1-state-high; + ti,enable-pull-down; + ti,enable-force-pwm; + ti,enable-vout-discharge; + }; diff --git a/Documentation/devicetree/bindings/regulator/tps6586x.txt b/Documentation/devicetree/bindings/regulator/tps6586x.txt new file mode 100644 index 00000000000..0fcabaa3baa --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt @@ -0,0 +1,97 @@ +TPS6586x family of regulators + +Required properties: +- compatible: "ti,tps6586x" +- reg: I2C slave address +- interrupts: the interrupt outputs of the controller +- #gpio-cells: number of cells to describe a GPIO +- gpio-controller: mark the device as a GPIO controller +- regulators: list of regulators provided by this controller, must be named + after their hardware counterparts: sm[0-2], ldo[0-9] and ldo_rtc + +Each regulator is defined using the standard binding for regulators. + +Example: + + pmu: tps6586x@34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + interrupts = <0 88 0x4>; + + #gpio-cells = <2>; + gpio-controller; + + regulators { + sm0_reg: sm0 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + sm1_reg: sm1 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + sm2_reg: sm2 { + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <4550000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo0_reg: ldo0 { + regulator-name = "PCIE CLK"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + ldo1_reg: ldo1 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + }; + + ldo2_reg: ldo2 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + }; + + ldo3_reg: ldo3 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo4_reg: ldo4 { + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <2475000>; + }; + + ldo5_reg: ldo5 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo6_reg: ldo6 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo7_reg: ldo7 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo8_reg: ldo8 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo9_reg: ldo9 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt index 2c3cd413f04..9cc44449508 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.txt +++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt @@ -3,6 +3,8 @@ Required properties: - compatible : "fsl,sgtl5000". +- reg : the I2C address of the device + Example: codec: sgtl5000@0a { diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 03ca210406e..e4b57756b9f 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -539,3 +539,13 @@ When: 3.6 Why: setitimer is not returning -EFAULT if user pointer is NULL. This violates the spec. Who: Sasikantha Babu <sasikanth.v19@gmail.com> + +---------------------------- + +What: V4L2_CID_HCENTER, V4L2_CID_VCENTER V4L2 controls +When: 3.7 +Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated + for about 4 years and they are not used by any mainline driver. + There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide + similar functionality. +Who: Sylwester Nawrocki <sylvester.nawrocki@gmail.com> diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt index 0494f78d87e..fcc79957be6 100644 --- a/Documentation/filesystems/gfs2-glocks.txt +++ b/Documentation/filesystems/gfs2-glocks.txt @@ -61,7 +61,9 @@ go_unlock | Called on the final local unlock of a lock go_dump | Called to print content of object for debugfs file, or on | error to dump glock to the log. go_type | The type of the glock, LM_TYPE_..... -go_min_hold_time | The minimum hold time +go_callback | Called if the DLM sends a callback to drop this lock +go_flags | GLOF_ASPACE is set, if the glock has an address space + | associated with it The minimum hold time for each lock is the time after a remote lock grant for which we ignore remote demote requests. This is in order to @@ -89,6 +91,7 @@ go_demote_ok | Sometimes | Yes go_lock | Yes | No go_unlock | Yes | No go_dump | Sometimes | Yes +go_callback | Sometimes (N/A) | Yes N.B. Operations must not drop either the bit lock or the spinlock if its held on entry. go_dump and do_demote_ok must never block. @@ -111,4 +114,118 @@ itself (locking order as above), and the other, known as the iopen glock is used in conjunction with the i_nlink field in the inode to determine the lifetime of the inode in question. Locking of inodes is on a per-inode basis. Locking of rgrps is on a per rgrp basis. +In general we prefer to lock local locks prior to cluster locks. + + Glock Statistics + ------------------ + +The stats are divided into two sets: those relating to the +super block and those relating to an individual glock. The +super block stats are done on a per cpu basis in order to +try and reduce the overhead of gathering them. They are also +further divided by glock type. All timings are in nanoseconds. + +In the case of both the super block and glock statistics, +the same information is gathered in each case. The super +block timing statistics are used to provide default values for +the glock timing statistics, so that newly created glocks +should have, as far as possible, a sensible starting point. +The per-glock counters are initialised to zero when the +glock is created. The per-glock statistics are lost when +the glock is ejected from memory. + +The statistics are divided into three pairs of mean and +variance, plus two counters. The mean/variance pairs are +smoothed exponential estimates and the algorithm used is +one which will be very familiar to those used to calculation +of round trip times in network code. See "TCP/IP Illustrated, +Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement", +p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards. +Unlike the TCP/IP Illustrated case, the mean and variance are +not scaled, but are in units of integer nanoseconds. + +The three pairs of mean/variance measure the following +things: + + 1. DLM lock time (non-blocking requests) + 2. DLM lock time (blocking requests) + 3. Inter-request time (again to the DLM) + +A non-blocking request is one which will complete right +away, whatever the state of the DLM lock in question. That +currently means any requests when (a) the current state of +the lock is exclusive, i.e. a lock demotion (b) the requested +state is either null or unlocked (again, a demotion) or (c) the +"try lock" flag is set. A blocking request covers all the other +lock requests. + +There are two counters. The first is there primarily to show +how many lock requests have been made, and thus how much data +has gone into the mean/variance calculations. The other counter +is counting queuing of holders at the top layer of the glock +code. Hopefully that number will be a lot larger than the number +of dlm lock requests issued. + +So why gather these statistics? There are several reasons +we'd like to get a better idea of these timings: + +1. To be able to better set the glock "min hold time" +2. To spot performance issues more easily +3. To improve the algorithm for selecting resource groups for +allocation (to base it on lock wait time, rather than blindly +using a "try lock") + +Due to the smoothing action of the updates, a step change in +some input quantity being sampled will only fully be taken +into account after 8 samples (or 4 for the variance) and this +needs to be carefully considered when interpreting the +results. + +Knowing both the time it takes a lock request to complete and +the average time between lock requests for a glock means we +can compute the total percentage of the time for which the +node is able to use a glock vs. time that the rest of the +cluster has its share. That will be very useful when setting +the lock min hold time. + +Great care has been taken to ensure that we +measure exactly the quantities that we want, as accurately +as possible. There are always inaccuracies in any +measuring system, but I hope this is as accurate as we +can reasonably make it. + +Per sb stats can be found here: +/sys/kernel/debug/gfs2/<fsname>/sbstats +Per glock stats can be found here: +/sys/kernel/debug/gfs2/<fsname>/glstats + +Assuming that debugfs is mounted on /sys/kernel/debug and also +that <fsname> is replaced with the name of the gfs2 filesystem +in question. + +The abbreviations used in the output as are follows: + +srtt - Smoothed round trip time for non-blocking dlm requests +srttvar - Variance estimate for srtt +srttb - Smoothed round trip time for (potentially) blocking dlm requests +srttvarb - Variance estimate for srttb +sirt - Smoothed inter-request time (for dlm requests) +sirtvar - Variance estimate for sirt +dlm - Number of dlm requests made (dcnt in glstats file) +queue - Number of glock requests queued (qcnt in glstats file) + +The sbstats file contains a set of these stats for each glock type (so 8 lines +for each type) and for each cpu (one column per cpu). The glstats file contains +a set of these stats for each glock in a similar format to the glocks file, but +using the format mean/variance for each of the timing stats. + +The gfs2_glock_lock_time tracepoint prints out the current values of the stats +for the glock in question, along with some addition information on each dlm +reply that is received: + +status - The status of the dlm request +flags - The dlm request flags +tdiff - The time taken by this specific request +(remaining fields as per above list) + diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt index 4cda926628a..cc4f2306609 100644 --- a/Documentation/filesystems/gfs2.txt +++ b/Documentation/filesystems/gfs2.txt @@ -1,7 +1,7 @@ Global File System ------------------ -http://sources.redhat.com/cluster/wiki/ +https://fedorahosted.org/cluster/wiki/HomePage GFS is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, @@ -30,7 +30,8 @@ needed, simply: If you are using Fedora, you need to install the gfs2-utils package and, for lock_dlm, you will also need to install the cman package -and write a cluster.conf as per the documentation. +and write a cluster.conf as per the documentation. For F17 and above +cman has been replaced by the dlm package. GFS2 is not on-disk compatible with previous versions of GFS, but it is pretty close. @@ -39,8 +40,6 @@ The following man pages can be found at the URL above: fsck.gfs2 to repair a filesystem gfs2_grow to expand a filesystem online gfs2_jadd to add journals to a filesystem online - gfs2_tool to manipulate, examine and tune a filesystem - gfs2_quota to examine and change quota values in a filesystem + tunegfs2 to manipulate, examine and tune a filesystem gfs2_convert to convert a gfs filesystem to gfs2 in-place - mount.gfs2 to help mount(8) mount a filesystem mkfs.gfs2 to make a filesystem diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index b7413cb46dc..ef088e55ab2 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -996,7 +996,6 @@ Table 1-9: Network info in /proc/net snmp SNMP data sockstat Socket statistics tcp TCP sockets - tr_rif Token ring RIF routing table udp UDP sockets unix UNIX domain sockets wireless Wireless interface data (Wavelan etc) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c1601e5a8b7..e275432ef2c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -110,6 +110,7 @@ parameter is applicable: USB USB support is enabled. USBHID USB Human Interface Device support is enabled. V4L Video For Linux support is enabled. + VMMIO Driver for memory mapped virtio devices is enabled. VGA The VGA console has been enabled. VT Virtual terminal support is enabled. WDT Watchdog support is enabled. @@ -2161,6 +2162,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. on: Turn realloc on realloc same as realloc=on noari do not use PCIe ARI. + pcie_scan_all Scan all possible PCIe devices. Otherwise we + only look for one device below a PCIe downstream + port. pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power Management. @@ -2330,18 +2334,100 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ramdisk_size= [RAM] Sizes of RAM disks in kilobytes See Documentation/blockdev/ramdisk.txt. - rcupdate.blimit= [KNL,BOOT] + rcutree.blimit= [KNL,BOOT] Set maximum number of finished RCU callbacks to process in one batch. - rcupdate.qhimark= [KNL,BOOT] + rcutree.qhimark= [KNL,BOOT] Set threshold of queued RCU callbacks over which batch limiting is disabled. - rcupdate.qlowmark= [KNL,BOOT] + rcutree.qlowmark= [KNL,BOOT] Set threshold of queued RCU callbacks below which batch limiting is re-enabled. + rcutree.rcu_cpu_stall_suppress= [KNL,BOOT] + Suppress RCU CPU stall warning messages. + + rcutree.rcu_cpu_stall_timeout= [KNL,BOOT] + Set timeout for RCU CPU stall warning messages. + + rcutorture.fqs_duration= [KNL,BOOT] + Set duration of force_quiescent_state bursts. + + rcutorture.fqs_holdoff= [KNL,BOOT] + Set holdoff time within force_quiescent_state bursts. + + rcutorture.fqs_stutter= [KNL,BOOT] + Set wait time between force_quiescent_state bursts. + + rcutorture.irqreader= [KNL,BOOT] + Test RCU readers from irq handlers. + + rcutorture.n_barrier_cbs= [KNL,BOOT] + Set callbacks/threads for rcu_barrier() testing. + + rcutorture.nfakewriters= [KNL,BOOT] + Set number of concurrent RCU writers. These just + stress RCU, they don't participate in the actual + test, hence the "fake". + + rcutorture.nreaders= [KNL,BOOT] + Set number of RCU readers. + + rcutorture.onoff_holdoff= [KNL,BOOT] + Set time (s) after boot for CPU-hotplug testing. + + rcutorture.onoff_interval= [KNL,BOOT] + Set time (s) between CPU-hotplug operations, or + zero to disable CPU-hotplug testing. + + rcutorture.shuffle_interval= [KNL,BOOT] + Set task-shuffle interval (s). Shuffling tasks + allows some CPUs to go into dyntick-idle mode + during the rcutorture test. + + rcutorture.shutdown_secs= [KNL,BOOT] + Set time (s) after boot system shutdown. This + is useful for hands-off automated testing. + + rcutorture.stall_cpu= [KNL,BOOT] + Duration of CPU stall (s) to test RCU CPU stall + warnings, zero to disable. + + rcutorture.stall_cpu_holdoff= [KNL,BOOT] + Time to wait (s) after boot before inducing stall. + + rcutorture.stat_interval= [KNL,BOOT] + Time (s) between statistics printk()s. + + rcutorture.stutter= [KNL,BOOT] + Time (s) to stutter testing, for example, specifying + five seconds causes the test to run for five seconds, + wait for five seconds, and so on. This tests RCU's + ability to transition abruptly to and from idle. + + rcutorture.test_boost= [KNL,BOOT] + Test RCU priority boosting? 0=no, 1=maybe, 2=yes. + "Maybe" means test if the RCU implementation + under test support RCU priority boosting. + + rcutorture.test_boost_duration= [KNL,BOOT] + Duration (s) of each individual boost test. + + rcutorture.test_boost_interval= [KNL,BOOT] + Interval (s) between each boost test. + + rcutorture.test_no_idle_hz= [KNL,BOOT] + Test RCU's dyntick-idle handling. See also the + rcutorture.shuffle_interval parameter. + + rcutorture.torture_type= [KNL,BOOT] + Specify the RCU implementation to test. + + rcutorture.verbose= [KNL,BOOT] + Enable additional printk() statements. + rdinit= [KNL] Format: <full_path> Run specified binary instead of /init from the ramdisk, @@ -2847,6 +2933,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. video= [FB] Frame buffer configuration See Documentation/fb/modedb.txt. + virtio_mmio.device= + [VMMIO] Memory mapped virtio (platform) device. + + <size>@<baseaddr>:<irq>[:<id>] + where: + <size> := size (can use standard suffixes + like K, M and G) + <baseaddr> := physical base address + <irq> := interrupt number (as passed to + request_irq()) + <id> := (optional) platform device id + example: + virtio_mmio.device=1K@0x100b0000:48:7 + + Can be used multiple times for multiple devices. + vga= [BOOT,X86-32] Select a particular video mode See Documentation/x86/boot.txt and Documentation/svga.txt. diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 9ad9ddeb384..2cc3c7733a2 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -1,7 +1,5 @@ 00-INDEX - this file -3c359.txt - - information on the 3Com TokenLink Velocity XL (3c5359) driver. 3c505.txt - information on the 3Com EtherLink Plus (3c505) driver. 3c509.txt @@ -142,8 +140,6 @@ netif-msg.txt - Design of the network interface message level setting (NETIF_MSG_*). nfc.txt - The Linux Near Field Communication (NFS) subsystem. -olympic.txt - - IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info. openvswitch.txt - Open vSwitch developer documentation. operstates.txt @@ -184,8 +180,6 @@ skfp.txt - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info. smc9.txt - the driver for SMC's 9000 series of Ethernet cards -smctr.txt - - SMC TokenCard TokenRing Linux driver info. spider-net.txt - README for the Spidernet Driver (as found in PS3 / Cell BE). stmmac.txt @@ -200,8 +194,6 @@ tcp-thin.txt - kernel tuning options for low rate 'thin' TCP streams. tlan.txt - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info. -tms380tr.txt - - SysKonnect Token Ring ISA/PCI adapter driver info. tproxy.txt - Transparent proxy support user guide. tuntap.txt diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt deleted file mode 100644 index dadfe8147ab..00000000000 --- a/Documentation/networking/3c359.txt +++ /dev/null @@ -1,58 +0,0 @@ - -3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS README - -Release 0.9.0 - Release - Jul 17th 2000 Mike Phillips - - 1.2.0 - Final - Feb 17th 2002 Mike Phillips - Updated for submission to the 2.4.x kernel. - -Thanks: - Terry Murphy from 3Com for tech docs and support, - Adam D. Ligas for testing the driver. - -Note: - This driver will NOT work with the 3C339 Token Ring cards, you need -to use the tms380 driver instead. - -Options: - -The driver accepts three options: ringspeed, pkt_buf_sz and message_level. - -These options can be specified differently for each card found. - -ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will -make the card autosense the ringspeed and join at the appropriate speed, -this will be the default option for most people. 4 or 16 allow you to -explicitly force the card to operate at a certain speed. The card will fail -if you try to insert it at the wrong speed. (Although some hubs will allow -this so be *very* careful). The main purpose for explicitly setting the ring -speed is for when the card is first on the ring. In autosense mode, if the card -cannot detect any active monitors on the ring it will open at the same speed as -its last opening. This can be hazardous if this speed does not match the speed -you want the ring to operate at. - -pkt_buf_sz: This is this initial receive buffer allocation size. This will -default to 4096 if no value is entered. You may increase performance of the -driver by setting this to a value larger than the network packet size, although -the driver now re-sizes buffers based on MTU settings as well. - -message_level: Controls level of messages created by the driver. Defaults to 0: -which only displays start-up and critical messages. Presently any non-zero -value will display all soft messages as well. NB This does not turn -debugging messages on, that must be done by modified the source code. - -Variable MTU size: - -The driver can handle a MTU size up to either 4500 or 18000 depending upon -ring speed. The driver also changes the size of the receive buffers as part -of the mtu re-sizing, so if you set mtu = 18000, you will need to be able -to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring -position = 296,000 bytes of memory space, plus of course anything -necessary for the tx sk_buff's. Remember this is per card, so if you are -building routers, gateway's etc, you could start to use a lot of memory -real fast. - -2/17/02 Mike Phillips - diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt index dcc9eaf5939..fbf722e15ac 100644 --- a/Documentation/networking/3c509.txt +++ b/Documentation/networking/3c509.txt @@ -25,7 +25,6 @@ models: 3c509B (later revision of the ISA card; supports full-duplex) 3c589 (PCMCIA) 3c589B (later revision of the 3c589; supports full-duplex) - 3c529 (MCA) 3c579 (EISA) Large portions of this documentation were heavily borrowed from the guide diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index 221ad0cdf11..75a592365af 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt @@ -1,5 +1,3 @@ -[state: 21-08-2011] - BATMAN-ADV ---------- @@ -67,18 +65,19 @@ To deactivate an interface you have to write "none" into its All mesh wide settings can be found in batman's own interface folder: -# ls /sys/class/net/bat0/mesh/ -# aggregated_ogms fragmentation gw_sel_class vis_mode -# ap_isolation gw_bandwidth hop_penalty -# bonding gw_mode orig_interval +# ls /sys/class/net/bat0/mesh/ +# aggregated_ogms gw_bandwidth log_level +# ap_isolation gw_mode orig_interval +# bonding gw_sel_class routing_algo +# bridge_loop_avoidance hop_penalty vis_mode +# fragmentation There is a special folder for debugging information: # ls /sys/kernel/debug/batman_adv/bat0/ -# gateways socket transtable_global vis_data -# originators softif_neigh transtable_local - +# bla_claim_table log socket transtable_local +# gateways originators transtable_global vis_data Some of the files contain all sort of status information regard- ing the mesh network. For example, you can view the table of @@ -202,12 +201,13 @@ abled during run time. Following log_levels are defined: 1 - Enable messages related to routing / flooding / broadcasting 2 - Enable messages related to route added / changed / deleted 4 - Enable messages related to translation table operations -7 - Enable all messages +8 - Enable messages related to bridge loop avoidance +15 - enable all messages The debug output can be changed at runtime using the file /sys/class/net/bat0/mesh/log_level. e.g. -# echo 2 > /sys/class/net/bat0/mesh/log_level +# echo 6 > /sys/class/net/bat0/mesh/log_level will enable debug messages for when routes change. diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt index f648eb26518..d52af53efdc 100644 --- a/Documentation/networking/fore200e.txt +++ b/Documentation/networking/fore200e.txt @@ -11,12 +11,10 @@ i386, alpha (untested), powerpc, sparc and sparc64 archs. The intent is to enable the use of different models of FORE adapters at the same time, by hosts that have several bus interfaces (such as PCI+SBUS, -PCI+MCA or PCI+EISA). +or PCI+EISA). Only PCI and SBUS devices are currently supported by the driver, but support -for other bus interfaces such as EISA should not be too hard to add (this may -be more tricky for the MCA bus, though, as FORE made some MCA-specific -modifications to the adapter's AALI interface). +for other bus interfaces such as EISA should not be too hard to add. Firmware Copyright Notice diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index 1dc1c24a754..703cf4370c7 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -4,15 +4,22 @@ Introduction ============ +The IEEE 802.15.4 working group focuses on standartization of bottom +two layers: Medium Accsess Control (MAC) and Physical (PHY). And there +are mainly two options available for upper layers: + - ZigBee - proprietary protocol from ZigBee Alliance + - 6LowPAN - IPv6 networking over low rate personal area networks The Linux-ZigBee project goal is to provide complete implementation -of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack +of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack of protocols for organizing Low-Rate Wireless Personal Area Networks. -Currently only IEEE 802.15.4 layer is implemented. We have chosen -to use plain Berkeley socket API, the generic Linux networking stack -to transfer IEEE 802.15.4 messages and a special protocol over genetlink -for configuration/management +The stack is composed of three main parts: + - IEEE 802.15.4 layer; We have chosen to use plain Berkeley socket API, + the generic Linux networking stack to transfer IEEE 802.15.4 messages + and a special protocol over genetlink for configuration/management + - MAC - provides access to shared channel and reliable data delivery + - PHY - represents device drivers Socket API @@ -29,15 +36,6 @@ or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee). One can use SOCK_RAW for passing raw data towards device xmit function. YMMV. -MLME - MAC Level Management -============================ - -Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands. -See the include/net/nl802154.h header. Our userspace tools package -(see above) provides CLI configuration utility for radio interfaces and simple -coordinator for IEEE 802.15.4 networks as an example users of MLME protocol. - - Kernel side ============= @@ -51,6 +49,15 @@ Like with WiFi, there are several types of devices implementing IEEE 802.15.4. Those types of devices require different approach to be hooked into Linux kernel. +MLME - MAC Level Management +============================ + +Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands. +See the include/net/nl802154.h header. Our userspace tools package +(see above) provides CLI configuration utility for radio interfaces and simple +coordinator for IEEE 802.15.4 networks as an example users of MLME protocol. + + HardMAC ======= @@ -73,11 +80,47 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c SoftMAC ======= -We are going to provide intermediate layer implementing IEEE 802.15.4 MAC -in software. This is currently WIP. +The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it +provides interface for drivers registration and management of slave interfaces. + +NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4 +stack interface for network sniffers (e.g. WireShark). + +This layer is going to be extended soon. See header include/net/mac802154.h and several drivers in drivers/ieee802154/. + +Device drivers API +================== + +The include/net/mac802154.h defines following functions: + - struct ieee802154_dev *ieee802154_alloc_device + (size_t priv_size, struct ieee802154_ops *ops): + allocation of IEEE 802.15.4 compatible device + + - void ieee802154_free_device(struct ieee802154_dev *dev): + freeing allocated device + + - int ieee802154_register_device(struct ieee802154_dev *dev): + register PHY in the system + + - void ieee802154_unregister_device(struct ieee802154_dev *dev): + freeing registered PHY + +Moreover IEEE 802.15.4 device operations structure should be filled. + +Fake drivers +============ + +In addition there are two drivers available which simulate real devices with +HardMAC (fakehard) and SoftMAC (fakelb - IEEE 802.15.4 loopback driver) +interfaces. This option provides possibility to test and debug stack without +usage of real hardware. + +See sources in drivers/ieee802154 folder for more details. + + 6LoWPAN Linux implementation ============================ diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index bd80ba5847d..6f896b94abd 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -147,7 +147,7 @@ tcp_adv_win_scale - INTEGER (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale), if it is <= 0. Possible values are [-31, 31], inclusive. - Default: 2 + Default: 1 tcp_allowed_congestion_control - STRING Show/set the congestion control choices available to non-privileged @@ -190,6 +190,20 @@ tcp_cookie_size - INTEGER tcp_dsack - BOOLEAN Allows TCP to send "duplicate" SACKs. +tcp_early_retrans - INTEGER + Enable Early Retransmit (ER), per RFC 5827. ER lowers the threshold + for triggering fast retransmit when the amount of outstanding data is + small and when no previously unsent data can be transmitted (such + that limited transmit could be used). + Possible values: + 0 disables ER + 1 enables ER + 2 enables ER but delays fast recovery and fast retransmit + by a fourth of RTT. This mitigates connection falsely + recovers when network has a small degree of reordering + (less than 3 packets). + Default: 2 + tcp_ecn - INTEGER Enable Explicit Congestion Notification (ECN) in TCP. ECN is only used when both ends of the TCP flow support it. It is useful to @@ -410,7 +424,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max net.core.rmem_max. Calling setsockopt() with SO_RCVBUF disables automatic tuning of that socket's receive buffer size, in which case this value is ignored. - Default: between 87380B and 4MB, depending on RAM size. + Default: between 87380B and 6MB, depending on RAM size. tcp_sack - BOOLEAN Enable select acknowledgments (SACKS). @@ -1287,13 +1301,22 @@ bridge-nf-call-ip6tables - BOOLEAN bridge-nf-filter-vlan-tagged - BOOLEAN 1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables. 0 : disable this. - Default: 1 + Default: 0 bridge-nf-filter-pppoe-tagged - BOOLEAN 1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables. 0 : disable this. - Default: 1 + Default: 0 +bridge-nf-pass-vlan-input-dev - BOOLEAN + 1: if bridge-nf-filter-vlan-tagged is enabled, try to find a vlan + interface on the bridge and set the netfilter input device to the vlan. + This allows use of e.g. "iptables -i br0.1" and makes the REDIRECT + target work with vlan-on-top-of-bridge interfaces. When no matching + vlan interface is found, or this switch is off, the input device is + set to the bridge interface. + 0: disable bridge netfilter vlan interface lookup. + Default: 0 proc/sys/net/sctp/* Variables: @@ -1484,11 +1507,8 @@ addr_scope_policy - INTEGER /proc/sys/net/core/* -dev_weight - INTEGER - The maximum number of packets that kernel can handle on a NAPI - interrupt, it's a Per-CPU variable. + Please see: Documentation/sysctl/net.txt for descriptions of these entries. - Default: 64 /proc/sys/net/unix/* max_dgram_qlen - INTEGER diff --git a/Documentation/networking/mac80211-auth-assoc-deauth.txt b/Documentation/networking/mac80211-auth-assoc-deauth.txt index e0a2aa585ca..d7a15fe91bf 100644 --- a/Documentation/networking/mac80211-auth-assoc-deauth.txt +++ b/Documentation/networking/mac80211-auth-assoc-deauth.txt @@ -23,7 +23,7 @@ BA session stop & deauth/disassoc frames end note end -mac80211->driver: config(channel, non-HT) +mac80211->driver: config(channel, channel type) mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap) mac80211->driver: sta_state(AP, exists) @@ -51,7 +51,7 @@ note over mac80211,driver: cleanup like for authenticate end alt not previously authenticated (FT) -mac80211->driver: config(channel, non-HT) +mac80211->driver: config(channel, channel type) mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap) mac80211->driver: sta_state(AP, exists) mac80211->driver: sta_state(AP, authenticated) @@ -67,10 +67,6 @@ end mac80211->driver: set up QoS parameters -alt is HT channel -mac80211->driver: config(channel, HT params) -end - mac80211->driver: bss_info_changed(QoS, HT, associated with AID) mac80211->userspace: associated @@ -95,5 +91,5 @@ mac80211->driver: sta_state(AP,exists) mac80211->driver: sta_state(AP,not-exists) mac80211->driver: turn off powersave mac80211->driver: bss_info_changed(clear BSSID, not associated, no QoS, ...) -mac80211->driver: config(non-HT channel type) +mac80211->driver: config(channel type to non-HT) mac80211->userspace: disconnected diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt deleted file mode 100644 index b95b5bf9675..00000000000 --- a/Documentation/networking/olympic.txt +++ /dev/null @@ -1,79 +0,0 @@ - -IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README - -Release 0.2.0 - Release - June 8th 1999 Peter De Schrijver & Mike Phillips -Release 0.9.C - Release - April 18th 2001 Mike Phillips - -Thanks: -Erik De Cock, Adrian Bridgett and Frank Fiene for their -patience and testing. -Donald Champion for the cardbus support -Kyle Lucke for the dma api changes. -Jonathon Bitner for hardware support. -Everybody on linux-tr for their continued support. - -Options: - -The driver accepts four options: ringspeed, pkt_buf_sz, -message_level and network_monitor. - -These options can be specified differently for each card found. - -ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will -make the card autosense the ringspeed and join at the appropriate speed, -this will be the default option for most people. 4 or 16 allow you to -explicitly force the card to operate at a certain speed. The card will fail -if you try to insert it at the wrong speed. (Although some hubs will allow -this so be *very* careful). The main purpose for explicitly setting the ring -speed is for when the card is first on the ring. In autosense mode, if the card -cannot detect any active monitors on the ring it will not open, so you must -re-init the card at the appropriate speed. Unfortunately at present the only -way of doing this is rmmod and insmod which is a bit tough if it is compiled -in the kernel. - -pkt_buf_sz: This is this initial receive buffer allocation size. This will -default to 4096 if no value is entered. You may increase performance of the -driver by setting this to a value larger than the network packet size, although -the driver now re-sizes buffers based on MTU settings as well. - -message_level: Controls level of messages created by the driver. Defaults to 0: -which only displays start-up and critical messages. Presently any non-zero -value will display all soft messages as well. NB This does not turn -debugging messages on, that must be done by modified the source code. - -network_monitor: Any non-zero value will provide a quasi network monitoring -mode. All unexpected MAC frames (beaconing etc.) will be received -by the driver and the source and destination addresses printed. -Also an entry will be added in /proc/net called olympic_tr%d, where tr%d -is the registered device name, i.e tr0, tr1, etc. This displays low -level information about the configuration of the ring and the adapter. -This feature has been designed for network administrators to assist in -the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR, -but has now changed to allow each adapter to be configured differently and -to alleviate the necessity to re-compile olympic to turn the option on). - -Multi-card: - -The driver will detect multiple cards and will work with shared interrupts, -each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The -driver should also happily reside in the system with other drivers. It has -been tested with ibmtr.c running, and I personally have had one Olicom PCI -card and two IBM olympic cards (all on the same interrupt), all running -together. - -Variable MTU size: - -The driver can handle a MTU size up to either 4500 or 18000 depending upon -ring speed. The driver also changes the size of the receive buffers as part -of the mtu re-sizing, so if you set mtu = 18000, you will need to be able -to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring -position = 296,000 bytes of memory space, plus of course anything -necessary for the tx sk_buff's. Remember this is per card, so if you are -building routers, gateway's etc, you could start to use a lot of memory -real fast. - - -6/8/99 Peter De Schrijver and Mike Phillips - diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt deleted file mode 100644 index 9af25b810c1..00000000000 --- a/Documentation/networking/smctr.txt +++ /dev/null @@ -1,66 +0,0 @@ -Text File for the SMC TokenCard TokenRing Linux driver (smctr.c). - By Jay Schulist <jschlst@samba.org> - -The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) -ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters. - -Latest information on this driver can be obtained on the Linux-SNA WWW site. -Please point your browser to: http://www.linux-sna.org - -This driver is rather simple to use. Select Y to Token Ring adapter support -in the kernel configuration. A choice for SMC Token Ring adapters will -appear. This drives supports all SMC ISA/MCA adapters. Choose this -option. I personally recommend compiling the driver as a module (M), but if you -you would like to compile it statically answer Y instead. - -This driver supports multiple adapters without the need to load multiple copies -of the driver. You should be able to load up to 7 adapters without any kernel -modifications, if you are in need of more please contact the maintainer of this -driver. - -Load the driver either by lilo/loadlin or as a module. When a module using the -following command will suffice for most: - -# modprobe smctr -smctr.c: v1.00 12/6/99 by jschlst@samba.org -tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000. - -Now just setup the device via ifconfig and set and routes you may have. After -this you are ready to start sending some tokens. - -Errata: -1). For anyone wondering where to pick up the SMC adapters please browse - to http://www.smc.com - -2). If you are the first/only Token Ring Client on a Token Ring LAN, please - specify the ringspeed with the ringspeed=[4/16] module option. If no - ringspeed is specified the driver will attempt to autodetect the ring - speed and/or if the adapter is the first/only station on the ring take - the appropriate actions. - - NOTE: Default ring speed is 16MB UTP. - -3). PnP support for this adapter sucks. I recommend hard setting the - IO/MEM/IRQ by the jumpers on the adapter. If this is not possible - load the module with the following io=[ioaddr] mem=[mem_addr] - irq=[irq_num]. - - The following IRQ, IO, and MEM settings are supported. - - IO ports: - 0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300, - 0x320, 0x340, 0x360, 0x380. - - IRQs: - 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15 - - Memory addresses: - 0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000, - 0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000, - 0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000, - 0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000 - -This driver is under the GNU General Public License. Its Firmware image is -included as an initialized C-array and is licensed by SMC to the Linux -users of this driver. However no warranty about its fitness is expressed or -implied by SMC. diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt index d0aeeadd264..ab1e8d7004c 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -111,11 +111,12 @@ and detailed below as well: int phy_addr; int interface; struct stmmac_mdio_bus_data *mdio_bus_data; - int pbl; + struct stmmac_dma_cfg *dma_cfg; int clk_csr; int has_gmac; int enh_desc; int tx_coe; + int rx_coe; int bugged_jumbo; int pmt; int force_sf_dma_mode; @@ -136,10 +137,12 @@ Where: o pbl: the Programmable Burst Length is maximum number of beats to be transferred in one DMA transaction. GMAC also enables the 4xPBL by default. - o clk_csr: CSR Clock range selection. + o clk_csr: fixed CSR Clock range selection. o has_gmac: uses the GMAC core. o enh_desc: if sets the MAC will use the enhanced descriptor structure. o tx_coe: core is able to perform the tx csum in HW. + o rx_coe: the supports three check sum offloading engine types: + type_1, type_2 (full csum) and no RX coe. o bugged_jumbo: some HWs are not able to perform the csum in HW for over-sized frames due to limited buffer sizes. Setting this flag the csum will be done in SW on @@ -160,7 +163,7 @@ Where: o custom_cfg: this is a custom configuration that can be passed while initialising the resources. -The we have: +For MDIO bus The we have: struct stmmac_mdio_bus_data { int bus_id; @@ -177,10 +180,28 @@ Where: o irqs: list of IRQs, one per PHY. o probed_phy_irq: if irqs is NULL, use this for probed PHY. + +For DMA engine we have the following internal fields that should be +tuned according to the HW capabilities. + +struct stmmac_dma_cfg { + int pbl; + int fixed_burst; + int burst_len_supported; +}; + +Where: + o pbl: Programmable Burst Length + o fixed_burst: program the DMA to use the fixed burst mode + o burst_len: this is the value we put in the register + supported values are provided as macros in + linux/stmmac.h header file. + +--- + Below an example how the structures above are using on ST platforms. static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = { - .pbl = 32, .has_gmac = 0, .enh_desc = 0, .fix_mac_speed = stxYYY_ethernet_fix_mac_speed, diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt deleted file mode 100644 index 1f73e13058d..00000000000 --- a/Documentation/networking/tms380tr.txt +++ /dev/null @@ -1,147 +0,0 @@ -Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver. - Text file by: Jay Schulist <jschlst@samba.org> - -The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA, -SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the -SK NET TR4/16 ISA card. - -Latest information on this driver can be obtained on the Linux-SNA WWW site. -Please point your browser to: -http://www.linux-sna.org - -Many thanks to Christoph Goos for his excellent work on this driver and -SysKonnect for donating the adapters to Linux-SNA for the testing and -maintenance of this device driver. - -Important information to be noted: -1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be - patient. -2. This driver works very well when autoprobing for adapters. Why even - think about those nasty io/int/dma settings of modprobe when the driver - will do it all for you! - -This driver is rather simple to use. Select Y to Token Ring adapter support -in the kernel configuration. A choice for SysKonnect Token Ring adapters will -appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this -option. I personally recommend compiling the driver as a module (M), but if you -you would like to compile it statically answer Y instead. - -This driver supports multiple adapters without the need to load multiple copies -of the driver. You should be able to load up to 7 adapters without any kernel -modifications, if you are in need of more please contact the maintainer of this -driver. - -Load the driver either by lilo/loadlin or as a module. When a module using the -following command will suffice for most: - -# modprobe sktr - -This will produce output similar to the following: (Output is user specific) - -sktr.c: v1.01 08/29/97 by Christoph Goos -tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17. -tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16. -tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5. - -Now just setup the device via ifconfig and set and routes you may have. After -this you are ready to start sending some tokens. - -Errata: -For anyone wondering where to pick up the SysKonnect adapters please browse -to http://www.syskonnect.com - -This driver is under the GNU General Public License. Its Firmware image is -included as an initialized C-array and is licensed by SysKonnect to the Linux -users of this driver. However no warranty about its fitness is expressed or -implied by SysKonnect. - -Below find attached the setting for the SK NET TR 4/16 ISA adapters -------------------------------------------------------------------- - - *************************** - *** C O N T E N T S *** - *************************** - - 1) Location of DIP-Switch W1 - 2) Default settings - 3) DIP-Switch W1 description - - - ============================================================== - CHAPTER 1 LOCATION OF DIP-SWITCH - ============================================================== - -UÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ -þUÄÄÄÄÄÄ¿ UÄÄÄÄÄ¿ UÄÄÄ¿ þ -þAÄÄÄÄÄÄU W1 AÄÄÄÄÄU UÄÄÄÄ¿ þ þ þ -þUÄÄÄÄÄÄ¿ þ þ þ þ UÄÄÅ¿ -þAÄÄÄÄÄÄU UÄÄÄÄÄÄÄÄÄÄÄ¿ AÄÄÄÄU þ þ þ þþ -þUÄÄÄÄÄÄ¿ þ þ UÄÄÄ¿ AÄÄÄU AÄÄÅU -þAÄÄÄÄÄÄU þ TMS380C26 þ þ þ þ -þUÄÄÄÄÄÄ¿ þ þ AÄÄÄU AÄ¿ -þAÄÄÄÄÄÄU þ þ þ þ -þ AÄÄÄÄÄÄÄÄÄÄÄU þ þ -þ þ þ -þ AÄU -þ þ -þ þ -þ þ -þ þ -AÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄU - AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU - - ============================================================== - CHAPTER 2 DEFAULT SETTINGS - ============================================================== - - W1 1 2 3 4 5 6 7 8 - +------------------------------+ - | ON X | - | OFF X X X X X X X | - +------------------------------+ - - W1.1 = ON Adapter drives address lines SA17..19 - W1.2 - 1.5 = OFF BootROM disabled - W1.6 - 1.8 = OFF I/O address 0A20h - - ============================================================== - CHAPTER 3 DIP SWITCH W1 DESCRIPTION - ============================================================== - - UÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄ¿ ON - þ 1 þ 2 þ 3 þ 4 þ 5 þ 6 þ 7 þ 8 þ - AÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄU OFF - |AD | BootROM Addr. | I/O | - +-+-+-------+-------+-----+-----+ - | | | - | | +------ 6 7 8 - | | ON ON ON 1900h - | | ON ON OFF 0900h - | | ON OFF ON 1980h - | | ON OFF OFF 0980h - | | OFF ON ON 1b20h - | | OFF ON OFF 0b20h - | | OFF OFF ON 1a20h - | | OFF OFF OFF 0a20h (+) - | | - | | - | +-------- 2 3 4 5 - | OFF x x x disabled (+) - | ON ON ON ON C0000 - | ON ON ON OFF C4000 - | ON ON OFF ON C8000 - | ON ON OFF OFF CC000 - | ON OFF ON ON D0000 - | ON OFF ON OFF D4000 - | ON OFF OFF ON D8000 - | ON OFF OFF OFF DC000 - | - | - +----- 1 - OFF adapter does NOT drive SA<17..19> - ON adapter drives SA<17..19> (+) - - - (+) means default setting - - ******************************** diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt new file mode 100644 index 00000000000..216b7254fcc --- /dev/null +++ b/Documentation/nfc/nfc-hci.txt @@ -0,0 +1,155 @@ +HCI backend for NFC Core + +Author: Eric Lapuyade, Samuel Ortiz +Contact: eric.lapuyade@intel.com, samuel.ortiz@intel.com + +General +------- + +The HCI layer implements much of the ETSI TS 102 622 V10.2.0 specification. It +enables easy writing of HCI-based NFC drivers. The HCI layer runs as an NFC Core +backend, implementing an abstract nfc device and translating NFC Core API +to HCI commands and events. + +HCI +--- + +HCI registers as an nfc device with NFC Core. Requests coming from userspace are +routed through netlink sockets to NFC Core and then to HCI. From this point, +they are translated in a sequence of HCI commands sent to the HCI layer in the +host controller (the chip). The sending context blocks while waiting for the +response to arrive. +HCI events can also be received from the host controller. They will be handled +and a translation will be forwarded to NFC Core as needed. +HCI uses 2 execution contexts: +- one if for executing commands : nfc_hci_msg_tx_work(). Only one command +can be executing at any given moment. +- one if for dispatching received events and responses : nfc_hci_msg_rx_work() + +HCI Session initialization: +--------------------------- + +The Session initialization is an HCI standard which must unfortunately +support proprietary gates. This is the reason why the driver will pass a list +of proprietary gates that must be part of the session. HCI will ensure all +those gates have pipes connected when the hci device is set up. + +HCI Gates and Pipes +------------------- + +A gate defines the 'port' where some service can be found. In order to access +a service, one must create a pipe to that gate and open it. In this +implementation, pipes are totally hidden. The public API only knows gates. +This is consistent with the driver need to send commands to proprietary gates +without knowing the pipe connected to it. + +Driver interface +---------------- + +A driver would normally register itself with HCI and provide the following +entry points: + +struct nfc_hci_ops { + int (*open)(struct nfc_hci_dev *hdev); + void (*close)(struct nfc_hci_dev *hdev); + int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb); + int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols); + int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate, + struct nfc_target *target); +}; + +open() and close() shall turn the hardware on and off. xmit() shall simply +write a frame to the chip. start_poll() is an optional entrypoint that shall +set the hardware in polling mode. This must be implemented only if the hardware +uses proprietary gates or a mechanism slightly different from the HCI standard. +target_from_gate() is another optional entrypoint to return the protocols +corresponding to a proprietary gate. + +On the rx path, the driver is responsible to push incoming HCP frames to HCI +using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling +This must be done from a context that can sleep. + +SHDLC +----- + +Most chips use shdlc to ensure integrity and delivery ordering of the HCP +frames between the host controller (the chip) and hosts (entities connected +to the chip, like the cpu). In order to simplify writing the driver, an shdlc +layer is available for use by the driver. +When used, the driver actually registers with shdlc, and shdlc will register +with HCI. HCI sees shdlc as the driver and thus send its HCP frames +through shdlc->xmit. +SHDLC adds a new execution context (nfc_shdlc_sm_work()) to run its state +machine and handle both its rx and tx path. + +Included Drivers +---------------- + +An HCI based driver for an NXP PN544, connected through I2C bus, and using +shdlc is included. + +Execution Contexts +------------------ + +The execution contexts are the following: +- IRQ handler (IRQH): +fast, cannot sleep. stores incoming frames into an shdlc rx queue + +- SHDLC State Machine worker (SMW) +handles shdlc rx & tx queues. Dispatches HCI cmd responses. + +- HCI Tx Cmd worker (MSGTXWQ) +Serialize execution of HCI commands. Complete execution in case of resp timeout. + +- HCI Rx worker (MSGRXWQ) +Dispatches incoming HCI commands or events. + +- Syscall context from a userspace call (SYSCALL) +Any entrypoint in HCI called from NFC Core + +Workflow executing an HCI command (using shdlc) +----------------------------------------------- + +Executing an HCI command can easily be performed synchronously using the +following API: + +int nfc_hci_send_cmd (struct nfc_hci_dev *hdev, u8 gate, u8 cmd, + const u8 *param, size_t param_len, struct sk_buff **skb) + +The API must be invoked from a context that can sleep. Most of the time, this +will be the syscall context. skb will return the result that was received in +the response. + +Internally, execution is asynchronous. So all this API does is to enqueue the +HCI command, setup a local wait queue on stack, and wait_event() for completion. +The wait is not interruptible because it is guaranteed that the command will +complete after some short timeout anyway. + +MSGTXWQ context will then be scheduled and invoke nfc_hci_msg_tx_work(). +This function will dequeue the next pending command and send its HCP fragments +to the lower layer which happens to be shdlc. It will then start a timer to be +able to complete the command with a timeout error if no response arrive. + +SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function +handles shdlc framing in and out. It uses the driver xmit to send frames and +receives incoming frames in an skb queue filled from the driver IRQ handler. +SHDLC I(nformation) frames payload are HCP fragments. They are agregated to +form complete HCI frames, which can be a response, command, or event. + +HCI Responses are dispatched immediately from this context to unblock +waiting command execution. Reponse processing involves invoking the completion +callback that was provided by nfc_hci_msg_tx_work() when it sent the command. +The completion callback will then wake the syscall context. + +Workflow receiving an HCI event or command +------------------------------------------ + +HCI commands or events are not dispatched from SMW context. Instead, they are +queued to HCI rx_queue and will be dispatched from HCI rx worker +context (MSGRXWQ). This is done this way to allow a cmd or event handler +to also execute other commands (for example, handling the +NFC_HCI_EVT_TARGET_DISCOVERED event from PN544 requires to issue an +ANY_GET_PARAMETER to the reader A gate to get information on the target +that was discovered). + +Typically, such an event will be propagated to NFC Core from MSGRXWQ context. diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt index e272d9909e3..13902778ae4 100644 --- a/Documentation/power/regulator/regulator.txt +++ b/Documentation/power/regulator/regulator.txt @@ -11,8 +11,7 @@ Registration Drivers can register a regulator by calling :- struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, - struct device *dev, struct regulator_init_data *init_data, - void *driver_data, struct device_node *of_node); + const struct regulator_config *config); This will register the regulators capabilities and operations to the regulator core. diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt new file mode 100644 index 00000000000..597c3c58137 --- /dev/null +++ b/Documentation/prctl/seccomp_filter.txt @@ -0,0 +1,163 @@ + SECure COMPuting with filters + ============================= + +Introduction +------------ + +A large number of system calls are exposed to every userland process +with many of them going unused for the entire lifetime of the process. +As system calls change and mature, bugs are found and eradicated. A +certain subset of userland applications benefit by having a reduced set +of available system calls. The resulting set reduces the total kernel +surface exposed to the application. System call filtering is meant for +use with those applications. + +Seccomp filtering provides a means for a process to specify a filter for +incoming system calls. The filter is expressed as a Berkeley Packet +Filter (BPF) program, as with socket filters, except that the data +operated on is related to the system call being made: system call +number and the system call arguments. This allows for expressive +filtering of system calls using a filter program language with a long +history of being exposed to userland and a straightforward data set. + +Additionally, BPF makes it impossible for users of seccomp to fall prey +to time-of-check-time-of-use (TOCTOU) attacks that are common in system +call interposition frameworks. BPF programs may not dereference +pointers which constrains all filters to solely evaluating the system +call arguments directly. + +What it isn't +------------- + +System call filtering isn't a sandbox. It provides a clearly defined +mechanism for minimizing the exposed kernel surface. It is meant to be +a tool for sandbox developers to use. Beyond that, policy for logical +behavior and information flow should be managed with a combination of +other system hardening techniques and, potentially, an LSM of your +choosing. Expressive, dynamic filters provide further options down this +path (avoiding pathological sizes or selecting which of the multiplexed +system calls in socketcall() is allowed, for instance) which could be +construed, incorrectly, as a more complete sandboxing solution. + +Usage +----- + +An additional seccomp mode is added and is enabled using the same +prctl(2) call as the strict seccomp. If the architecture has +CONFIG_HAVE_ARCH_SECCOMP_FILTER, then filters may be added as below: + +PR_SET_SECCOMP: + Now takes an additional argument which specifies a new filter + using a BPF program. + The BPF program will be executed over struct seccomp_data + reflecting the system call number, arguments, and other + metadata. The BPF program must then return one of the + acceptable values to inform the kernel which action should be + taken. + + Usage: + prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog); + + The 'prog' argument is a pointer to a struct sock_fprog which + will contain the filter program. If the program is invalid, the + call will return -1 and set errno to EINVAL. + + If fork/clone and execve are allowed by @prog, any child + processes will be constrained to the same filters and system + call ABI as the parent. + + Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or + run with CAP_SYS_ADMIN privileges in its namespace. If these are not + true, -EACCES will be returned. This requirement ensures that filter + programs cannot be applied to child processes with greater privileges + than the task that installed them. + + Additionally, if prctl(2) is allowed by the attached filter, + additional filters may be layered on which will increase evaluation + time, but allow for further decreasing the attack surface during + execution of a process. + +The above call returns 0 on success and non-zero on error. + +Return values +------------- +A seccomp filter may return any of the following values. If multiple +filters exist, the return value for the evaluation of a given system +call will always use the highest precedent value. (For example, +SECCOMP_RET_KILL will always take precedence.) + +In precedence order, they are: + +SECCOMP_RET_KILL: + Results in the task exiting immediately without executing the + system call. The exit status of the task (status & 0x7f) will + be SIGSYS, not SIGKILL. + +SECCOMP_RET_TRAP: + Results in the kernel sending a SIGSYS signal to the triggering + task without executing the system call. The kernel will + rollback the register state to just before the system call + entry such that a signal handler in the task will be able to + inspect the ucontext_t->uc_mcontext registers and emulate + system call success or failure upon return from the signal + handler. + + The SECCOMP_RET_DATA portion of the return value will be passed + as si_errno. + + SIGSYS triggered by seccomp will have a si_code of SYS_SECCOMP. + +SECCOMP_RET_ERRNO: + Results in the lower 16-bits of the return value being passed + to userland as the errno without executing the system call. + +SECCOMP_RET_TRACE: + When returned, this value will cause the kernel to attempt to + notify a ptrace()-based tracer prior to executing the system + call. If there is no tracer present, -ENOSYS is returned to + userland and the system call is not executed. + + A tracer will be notified if it requests PTRACE_O_TRACESECCOMP + using ptrace(PTRACE_SETOPTIONS). The tracer will be notified + of a PTRACE_EVENT_SECCOMP and the SECCOMP_RET_DATA portion of + the BPF program return value will be available to the tracer + via PTRACE_GETEVENTMSG. + +SECCOMP_RET_ALLOW: + Results in the system call being executed. + +If multiple filters exist, the return value for the evaluation of a +given system call will always use the highest precedent value. + +Precedence is only determined using the SECCOMP_RET_ACTION mask. When +multiple filters return values of the same precedence, only the +SECCOMP_RET_DATA from the most recently installed filter will be +returned. + +Pitfalls +-------- + +The biggest pitfall to avoid during use is filtering on system call +number without checking the architecture value. Why? On any +architecture that supports multiple system call invocation conventions, +the system call numbers may vary based on the specific invocation. If +the numbers in the different calling conventions overlap, then checks in +the filters may be abused. Always check the arch value! + +Example +------- + +The samples/seccomp/ directory contains both an x86-specific example +and a more generic example of a higher level macro interface for BPF +program generation. + + + +Adding architecture support +----------------------- + +See arch/Kconfig for the authoritative requirements. In general, if an +architecture supports both ptrace_event and seccomp, it will be able to +support seccomp filter with minor fixup: SIGSYS support and seccomp return +value checking. Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER +to its arch-specific Kconfig. diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 83f8ea8b79e..80441ab608e 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,11 @@ +Release Date : Mon. Mar 19, 2012 17:00:00 PST 2012 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.06.15-rc1 +Old Version : 00.00.06.14-rc1 + 1. Optimize HostMSIxVectors setting. + 2. Add fpRead/WriteCapable, fpRead/WriteAcrossStripe checks. +------------------------------------------------------------------------------- Release Date : Fri. Jan 6, 2012 17:00:00 PST 2010 - (emaild-id:megaraidlinux@lsi.com) Adam Radford diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index d2f72ae6643..a416479b8a1 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -15,7 +15,7 @@ at hand. Smack consists of three major components: - The kernel - - A start-up script and a few modified applications + - Basic utilities, which are helpful but not required - Configuration data The kernel component of Smack is implemented as a Linux @@ -23,37 +23,28 @@ Security Modules (LSM) module. It requires netlabel and works best with file systems that support extended attributes, although xattr support is not strictly required. It is safe to run a Smack kernel under a "vanilla" distribution. + Smack kernels use the CIPSO IP option. Some network configurations are intolerant of IP options and can impede access to systems that use them as Smack does. -The startup script etc-init.d-smack should be installed -in /etc/init.d/smack and should be invoked early in the -start-up process. On Fedora rc5.d/S02smack is recommended. -This script ensures that certain devices have the correct -Smack attributes and loads the Smack configuration if -any is defined. This script invokes two programs that -ensure configuration data is properly formatted. These -programs are /usr/sbin/smackload and /usr/sin/smackcipso. -The system will run just fine without these programs, -but it will be difficult to set access rules properly. - -A version of "ls" that provides a "-M" option to display -Smack labels on long listing is available. +The current git repositories for Smack user space are: -A hacked version of sshd that allows network logins by users -with specific Smack labels is available. This version does -not work for scp. You must set the /etc/ssh/sshd_config -line: - UsePrivilegeSeparation no + git@gitorious.org:meego-platform-security/smackutil.git + git@gitorious.org:meego-platform-security/libsmack.git -The format of /etc/smack/usr is: +These should make and install on most modern distributions. +There are three commands included in smackutil: - username smack +smackload - properly formats data for writing to /smack/load +smackcipso - properly formats data for writing to /smack/cipso +chsmack - display or set Smack extended attribute values In keeping with the intent of Smack, configuration data is minimal and not strictly required. The most important configuration step is mounting the smackfs pseudo filesystem. +If smackutil is installed the startup script will take care +of this, but it can be manually as well. Add this line to /etc/fstab: @@ -61,19 +52,148 @@ Add this line to /etc/fstab: and create the /smack directory for mounting. -Smack uses extended attributes (xattrs) to store file labels. -The command to set a Smack label on a file is: +Smack uses extended attributes (xattrs) to store labels on filesystem +objects. The attributes are stored in the extended attribute security +name space. A process must have CAP_MAC_ADMIN to change any of these +attributes. + +The extended attributes that Smack uses are: + +SMACK64 + Used to make access control decisions. In almost all cases + the label given to a new filesystem object will be the label + of the process that created it. +SMACK64EXEC + The Smack label of a process that execs a program file with + this attribute set will run with this attribute's value. +SMACK64MMAP + Don't allow the file to be mmapped by a process whose Smack + label does not allow all of the access permitted to a process + with the label contained in this attribute. This is a very + specific use case for shared libraries. +SMACK64TRANSMUTE + Can only have the value "TRUE". If this attribute is present + on a directory when an object is created in the directory and + the Smack rule (more below) that permitted the write access + to the directory includes the transmute ("t") mode the object + gets the label of the directory instead of the label of the + creating process. If the object being created is a directory + the SMACK64TRANSMUTE attribute is set as well. +SMACK64IPIN + This attribute is only available on file descriptors for sockets. + Use the Smack label in this attribute for access control + decisions on packets being delivered to this socket. +SMACK64IPOUT + This attribute is only available on file descriptors for sockets. + Use the Smack label in this attribute for access control + decisions on packets coming from this socket. + +There are multiple ways to set a Smack label on a file: # attr -S -s SMACK64 -V "value" path + # chsmack -a value path -NOTE: Smack labels are limited to 23 characters. The attr command - does not enforce this restriction and can be used to set - invalid Smack labels on files. - -If you don't do anything special all users will get the floor ("_") -label when they log in. If you do want to log in via the hacked ssh -at other labels use the attr command to set the smack value on the -home directory and its contents. +A process can see the smack label it is running with by +reading /proc/self/attr/current. A process with CAP_MAC_ADMIN +can set the process smack by writing there. + +Most Smack configuration is accomplished by writing to files +in the smackfs filesystem. This pseudo-filesystem is usually +mounted on /smack. + +access + This interface reports whether a subject with the specified + Smack label has a particular access to an object with a + specified Smack label. Write a fixed format access rule to + this file. The next read will indicate whether the access + would be permitted. The text will be either "1" indicating + access, or "0" indicating denial. +access2 + This interface reports whether a subject with the specified + Smack label has a particular access to an object with a + specified Smack label. Write a long format access rule to + this file. The next read will indicate whether the access + would be permitted. The text will be either "1" indicating + access, or "0" indicating denial. +ambient + This contains the Smack label applied to unlabeled network + packets. +cipso + This interface allows a specific CIPSO header to be assigned + to a Smack label. The format accepted on write is: + "%24s%4d%4d"["%4d"]... + The first string is a fixed Smack label. The first number is + the level to use. The second number is the number of categories. + The following numbers are the categories. + "level-3-cats-5-19 3 2 5 19" +cipso2 + This interface allows a specific CIPSO header to be assigned + to a Smack label. The format accepted on write is: + "%s%4d%4d"["%4d"]... + The first string is a long Smack label. The first number is + the level to use. The second number is the number of categories. + The following numbers are the categories. + "level-3-cats-5-19 3 2 5 19" +direct + This contains the CIPSO level used for Smack direct label + representation in network packets. +doi + This contains the CIPSO domain of interpretation used in + network packets. +load + This interface allows access control rules in addition to + the system defined rules to be specified. The format accepted + on write is: + "%24s%24s%5s" + where the first string is the subject label, the second the + object label, and the third the requested access. The access + string may contain only the characters "rwxat-", and specifies + which sort of access is allowed. The "-" is a placeholder for + permissions that are not allowed. The string "r-x--" would + specify read and execute access. Labels are limited to 23 + characters in length. +load2 + This interface allows access control rules in addition to + the system defined rules to be specified. The format accepted + on write is: + "%s %s %s" + where the first string is the subject label, the second the + object label, and the third the requested access. The access + string may contain only the characters "rwxat-", and specifies + which sort of access is allowed. The "-" is a placeholder for + permissions that are not allowed. The string "r-x--" would + specify read and execute access. +load-self + This interface allows process specific access rules to be + defined. These rules are only consulted if access would + otherwise be permitted, and are intended to provide additional + restrictions on the process. The format is the same as for + the load interface. +load-self2 + This interface allows process specific access rules to be + defined. These rules are only consulted if access would + otherwise be permitted, and are intended to provide additional + restrictions on the process. The format is the same as for + the load2 interface. +logging + This contains the Smack logging state. +mapped + This contains the CIPSO level used for Smack mapped label + representation in network packets. +netlabel + This interface allows specific internet addresses to be + treated as single label hosts. Packets are sent to single + label hosts without CIPSO headers, but only from processes + that have Smack write access to the host label. All packets + received from single label hosts are given the specified + label. The format accepted on write is: + "%d.%d.%d.%d label" or "%d.%d.%d.%d/%d label". +onlycap + This contains the label processes must have for CAP_MAC_ADMIN + and CAP_MAC_OVERRIDE to be effective. If this file is empty + these capabilities are effective at for processes with any + label. The value is set by writing the desired label to the + file or cleared by writing "-" to the file. You can add access rules in /etc/smack/accesses. They take the form: @@ -83,10 +203,6 @@ access is a combination of the letters rwxa which specify the kind of access permitted a subject with subjectlabel on an object with objectlabel. If there is no rule no access is allowed. -A process can see the smack label it is running with by -reading /proc/self/attr/current. A privileged process can -set the process smack by writing there. - Look for additional programs on http://schaufler-ca.com From the Smack Whitepaper: @@ -186,7 +302,7 @@ team. Smack labels are unstructured, case sensitive, and the only operation ever performed on them is comparison for equality. Smack labels cannot contain unprintable characters, the "/" (slash), the "\" (backslash), the "'" (quote) and '"' (double-quote) characters. -Smack labels cannot begin with a '-', which is reserved for special options. +Smack labels cannot begin with a '-'. This is reserved for special options. There are some predefined labels: @@ -194,7 +310,7 @@ There are some predefined labels: ^ Pronounced "hat", a single circumflex character. * Pronounced "star", a single asterisk character. ? Pronounced "huh", a single question mark character. - @ Pronounced "Internet", a single at sign character. + @ Pronounced "web", a single at sign character. Every task on a Smack system is assigned a label. System tasks, such as init(8) and systems daemons, are run with the floor ("_") label. User tasks @@ -246,13 +362,14 @@ The format of an access rule is: Where subject-label is the Smack label of the task, object-label is the Smack label of the thing being accessed, and access is a string specifying the sort -of access allowed. The Smack labels are limited to 23 characters. The access -specification is searched for letters that describe access modes: +of access allowed. The access specification is searched for letters that +describe access modes: a: indicates that append access should be granted. r: indicates that read access should be granted. w: indicates that write access should be granted. x: indicates that execute access should be granted. + t: indicates that the rule requests transmutation. Uppercase values for the specification letters are allowed as well. Access mode specifications can be in any order. Examples of acceptable rules @@ -273,7 +390,7 @@ Examples of unacceptable rules are: Spaces are not allowed in labels. Since a subject always has access to files with the same label specifying a rule for that case is pointless. Only -valid letters (rwxaRWXA) and the dash ('-') character are allowed in +valid letters (rwxatRWXAT) and the dash ('-') character are allowed in access specifications. The dash is a placeholder, so "a-r" is the same as "ar". A lone dash is used to specify that no access should be allowed. @@ -297,6 +414,13 @@ but not any of its attributes by the circumstance of having read access to the containing directory but not to the differently labeled file. This is an artifact of the file name being data in the directory, not a part of the file. +If a directory is marked as transmuting (SMACK64TRANSMUTE=TRUE) and the +access rule that allows a process to create an object in that directory +includes 't' access the label assigned to the new object will be that +of the directory, not the creating process. This makes it much easier +for two processes with different labels to share data without granting +access to all of their files. + IPC objects, message queues, semaphore sets, and memory segments exist in flat namespaces and access requests are only required to match the object in question. diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt index a9511f17906..e369de2d48c 100644 --- a/Documentation/security/Yama.txt +++ b/Documentation/security/Yama.txt @@ -34,7 +34,7 @@ parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID" still work as root). -For software that has defined application-specific relationships +In mode 1, software that has defined application-specific relationships between a debugging process and its inferior (crash handlers, etc), prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which other process (and its descendents) are allowed to call PTRACE_ATTACH @@ -46,6 +46,8 @@ restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...) so that any otherwise allowed process (even those in external pid namespaces) may attach. +These restrictions do not change how ptrace via PTRACE_TRACEME operates. + The sysctl settings are: 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other @@ -60,6 +62,12 @@ The sysctl settings are: inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare an allowed debugger PID to call PTRACE_ATTACH on the inferior. +2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace + with PTRACE_ATTACH. + +3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set, + this sysctl cannot be changed to a lower value. + The original children-only logic was based on the restrictions in grsecurity. ============================================================== diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index d389acd31e1..aa0dbd74b71 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -805,6 +805,23 @@ The keyctl syscall functions are: kernel and resumes executing userspace. + (*) Invalidate a key. + + long keyctl(KEYCTL_INVALIDATE, key_serial_t key); + + This function marks a key as being invalidated and then wakes up the + garbage collector. The garbage collector immediately removes invalidated + keys from all keyrings and deletes the key when its reference count + reaches zero. + + Keys that are marked invalidated become invisible to normal key operations + immediately, though they are still visible in /proc/keys until deleted + (they're marked with an 'i' flag). + + A process must have search permission on the key for this function to be + successful. + + =============== KERNEL SERVICES =============== diff --git a/Documentation/sparc/README-2.5 b/Documentation/sparc/README-2.5 deleted file mode 100644 index 806fe490a56..00000000000 --- a/Documentation/sparc/README-2.5 +++ /dev/null @@ -1,46 +0,0 @@ -BTFIXUP -------- - -To build new kernels you have to issue "make image". The ready kernel -in ELF format is placed in arch/sparc/boot/image. Explanation is below. - -BTFIXUP is a unique feature of Linux/sparc among other architectures, -developed by Jakub Jelinek (I think... Obviously David S. Miller took -part, too). It allows to boot the same kernel at different -sub-architectures, such as sun4c, sun4m, sun4d, where SunOS uses -different kernels. This feature is convinient for people who you move -disks between boxes and for distrution builders. - -To function, BTFIXUP must link the kernel "in the draft" first, -analyze the result, write a special stub code based on that, and -build the final kernel with the stub (btfix.o). - -Kai Germaschewski improved the build system of the kernel in the 2.5 series -significantly. Unfortunately, the traditional way of running the draft -linking from architecture specific Makefile before the actual linking -by generic Makefile is nearly impossible to support properly in the -new build system. Therefore, the way we integrate BTFIXUP with the -build system was changed in 2.5.40. Now, generic Makefile performs -the draft linking and stores the result in file vmlinux. Architecture -specific post-processing invokes BTFIXUP machinery and final linking -in the same way as other architectures do bootstraps. - -Implications of that change are as follows. - -1. Hackers must type "make image" now, instead of just "make", in the same - way as s390 people do now. It is analogous to "make bzImage" on i386. - This does NOT affect sparc64, you continue to use "make" to build sparc64 - kernels. - -2. vmlinux is not the final kernel, so RPM builders have to adjust - their spec files (if they delivered vmlinux for debugging). - System.map generated for vmlinux is still valid. - -3. Scripts that produce a.out images have to be changed. First, if they - invoke make, they have to use "make image". Second, they have to pick up - the new kernel in arch/sparc/boot/image instead of vmlinux. - -4. Since we are compliant with Kai's build system now, make -j is permitted. - --- Pete Zaitcev -zaitcev@yahoo.com diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 3201a7097e4..98335b7a533 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -43,6 +43,13 @@ Values : 1 - enable the JIT 2 - enable the JIT and ask the compiler to emit traces on kernel log. +dev_weight +-------------- + +The maximum number of packets that kernel can handle on a NAPI interrupt, +it's a Per-CPU variable. +Default: 64 + rmem_default ------------ diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt index da094737e2f..0d6ec85481c 100644 --- a/Documentation/virtual/virtio-spec.txt +++ b/Documentation/virtual/virtio-spec.txt @@ -1,11 +1,11 @@ [Generated file: see http://ozlabs.org/~rusty/virtio-spec/] Virtio PCI Card Specification -v0.9.1 DRAFT +v0.9.5 DRAFT - -Rusty Russell <rusty@rustcorp.com.au>IBM Corporation (Editor) +Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor) -2011 August 1. +2012 May 7. Purpose and Description @@ -68,11 +68,11 @@ and consists of three parts: +-------------------+-----------------------------------+-----------+ -When the driver wants to send buffers to the device, it puts them -in one or more slots in the descriptor table, and writes the -descriptor indices into the available ring. It then notifies the -device. When the device has finished with the buffers, it writes -the descriptors into the used ring, and sends an interrupt. +When the driver wants to send a buffer to the device, it fills in +a slot in the descriptor table (or chains several together), and +writes the descriptor index into the available ring. It then +notifies the device. When the device has finished a buffer, it +writes the descriptor into the used ring, and sends an interrupt. Specification @@ -106,8 +106,14 @@ for informational purposes by the guest). +----------------------+--------------------+---------------+ | 6 | ioMemory | - | +----------------------+--------------------+---------------+ +| 7 | rpmsg | Appendix H | ++----------------------+--------------------+---------------+ +| 8 | SCSI host | Appendix I | ++----------------------+--------------------+---------------+ | 9 | 9P transport | - | +----------------------+--------------------+---------------+ +| 10 | mac80211 wlan | - | ++----------------------+--------------------+---------------+ Device Configuration @@ -127,7 +133,7 @@ Note that this is possible because while the virtio header is PCI the native endian of the guest (where such distinction is applicable). - Device Initialization Sequence + Device Initialization Sequence<sub:Device-Initialization-Sequence> We start with an overview of device initialization, then expand on the details of the device and how each step is preformed. @@ -177,7 +183,10 @@ The virtio header looks as follows: If MSI-X is enabled for the device, two additional fields -immediately follow this header: +immediately follow this header:[footnote: +ie. once you enable MSI-X on the device, the other fields move. +If you turn it off again, they move back! +] +------------++----------------+--------+ @@ -191,20 +200,6 @@ immediately follow this header: +------------++----------------+--------+ -Finally, if feature bits (VIRTIO_F_FEATURES_HI) this is -immediately followed by two additional fields: - - -+------------++----------------------+---------------------- -| Bits || 32 | 32 -+------------++----------------------+---------------------- -| Read/Write || R | R+W -+------------++----------------------+---------------------- -| Purpose || Device | Guest -| || Features bits 32:63 | Features bits 32:63 -+------------++----------------------+---------------------- - - Immediately following these general headers, there may be device-specific headers: @@ -238,31 +233,25 @@ at least one bit should be set: may be a significant (or infinite) delay before setting this bit. - DRIVER_OK (3) Indicates that the driver is set up and ready to + DRIVER_OK (4) Indicates that the driver is set up and ready to drive the device. - FAILED (8) Indicates that something went wrong in the guest, + FAILED (128) Indicates that something went wrong in the guest, and it has given up on the device. This could be an internal error, or the driver didn't like the device for some reason, or even a fatal error during device operation. The device must be reset before attempting to re-initialize. - Feature Bits + Feature Bits<sub:Feature-Bits> -The least significant 31 bits of the first configuration field -indicates the features that the device supports (the high bit is -reserved, and will be used to indicate the presence of future -feature bits elsewhere). If more than 31 feature bits are -supported, the device indicates so by setting feature bit 31 (see -[cha:Reserved-Feature-Bits]). The bits are allocated as follows: +Thefirst configuration field indicates the features that the +device supports. The bits are allocated as follows: 0 to 23 Feature bits for the specific device type - 24 to 40 Feature bits reserved for extensions to the queue and + 24 to 32 Feature bits reserved for extensions to the queue and feature negotiation mechanisms - 41 to 63 Feature bits reserved for future extensions - For example, feature bit 0 for a network device (i.e. Subsystem Device ID 1) indicates that the device supports checksumming of packets. @@ -286,10 +275,6 @@ will not see that feature bit in the Device Features field and can go into backwards compatibility mode (or, for poor implementations, set the FAILED Device Status bit). -Access to feature bits 32 to 63 is enabled by Guest by setting -feature bit 31. If this bit is unset, Device must assume that all -feature bits > 31 are unset. - Configuration/Queue Vectors When MSI-X capability is present and enabled in the device @@ -324,7 +309,7 @@ success, the previously written value is returned, and on failure, NO_VECTOR is returned. If a mapping failure is detected, the driver can retry mapping with fewervectors, or disable MSI-X. - Virtqueue Configuration + Virtqueue Configuration<sec:Virtqueue-Configuration> As a device can have zero or more virtqueues for bulk data transport (for example, the network driver has two), the driver @@ -587,7 +572,7 @@ and Red Hat under the (3-clause) BSD license so that it can be freely used by all other projects, and is reproduced (with slight variation to remove Linux assumptions) in Appendix A. - Device Operation + Device Operation<sec:Device-Operation> There are two parts to device operation: supplying new buffers to the device, and processing used buffers from the device. As an @@ -813,7 +798,7 @@ vring.used->ring[vq->last_seen_used%vsz]; } - Dealing With Configuration Changes + Dealing With Configuration Changes<sub:Dealing-With-Configuration> Some virtio PCI devices can change the device configuration state, as reflected in the virtio header in the PCI configuration @@ -1260,18 +1245,6 @@ Currently there are five device-independent feature bits defined: driver should ignore the used_event field; the device should ignore the avail_event field; the flags field is used - VIRTIO_F_BAD_FEATURE(30) This feature should never be - negotiated by the guest; doing so is an indication that the - guest is faulty[footnote: -An experimental virtio PCI driver contained in Linux version -2.6.25 had this problem, and this feature bit can be used to -detect it. -] - - VIRTIO_F_FEATURES_HIGH(31) This feature indicates that the - device supports feature bits 32:63. If unset, feature bits - 32:63 are unset. - Appendix C: Network Device The virtio network device is a virtual ethernet card, and is the @@ -1335,11 +1308,17 @@ were required. VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering. + VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous + packets. + Device configuration layout Two configuration fields are currently defined. The mac address field always exists (though is only valid if VIRTIO_NET_F_MAC is set), and the status field - only exists if VIRTIO_NET_F_STATUS is set. Only one bit is - currently defined for the status field: VIRTIO_NET_S_LINK_UP. #define VIRTIO_NET_S_LINK_UP 1 + only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits + are currently defined for the status field: + VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE. #define VIRTIO_NET_S_LINK_UP 1 + +#define VIRTIO_NET_S_ANNOUNCE 2 @@ -1377,12 +1356,19 @@ struct virtio_net_config { packets by negotating the VIRTIO_NET_F_CSUM feature. This “ checksum offload” is a common feature on modern network cards. - If that feature is negotiated, a driver can use TCP or UDP - segmentation offload by negotiating the VIRTIO_NET_F_HOST_TSO4 - (IPv4 TCP), VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and - VIRTIO_NET_F_HOST_UFO (UDP fragmentation) features. It should - not send TCP packets requiring segmentation offload which have - the Explicit Congestion Notification bit set, unless the + If that feature is negotiated[footnote: +ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are +dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload +features must offer the checksum feature, and a driver which +accepts the offload features must accept the checksum feature. +Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features +depending on VIRTIO_NET_F_GUEST_CSUM. +], a driver can use TCP or UDP segmentation offload by + negotiating the VIRTIO_NET_F_HOST_TSO4 (IPv4 TCP), + VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and VIRTIO_NET_F_HOST_UFO + (UDP fragmentation) features. It should not send TCP packets + requiring segmentation offload which have the Explicit + Congestion Notification bit set, unless the VIRTIO_NET_F_HOST_ECN feature is negotiated.[footnote: This is a common restriction in real, older network cards. ] @@ -1403,7 +1389,7 @@ segmentation, if both guests are amenable. Packets are transmitted by placing them in the transmitq, and buffers for incoming packets are placed in the receiveq. In each -case, the packet itself is preceded by a header: +case, the packet itself is preceeded by a header: struct virtio_net_hdr { @@ -1462,9 +1448,10 @@ It will have a 14 byte ethernet header and 20 byte IP header followed by the TCP header (with the TCP checksum field 16 bytes into that header). csum_start will be 14+20 = 34 (the TCP checksum includes the header), and csum_offset will be 16. The -value in the TCP checksum field will be the sum of the TCP pseudo -header, so that replacing it by the ones' complement checksum of -the TCP header and body will give the correct result. +value in the TCP checksum field should be initialized to the sum +of the TCP pseudo header, so that replacing it by the ones' +complement checksum of the TCP header and body will give the +correct result. ] <enu:If-the-driver>If the driver negotiated @@ -1483,8 +1470,8 @@ Due to various bugs in implementations, this field is not useful as a guarantee of the transport header size. ] - gso_size is the size of the packet beyond that header (ie. - MSS). + gso_size is the maximum size of each packet beyond that header + (ie. MSS). If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature, the VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as well, @@ -1567,7 +1554,9 @@ Processing packet involves: If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were negotiated, then the “gso_type” may be something other than VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the - desired MSS (see [enu:If-the-driver]).Control Virtqueue + desired MSS (see [enu:If-the-driver]). + + Control Virtqueue The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is negotiated) to send commands to manipulate various features of @@ -1642,7 +1631,7 @@ struct virtio_net_ctrl_mac { The device can filter incoming packets by any number of destination MAC addresses.[footnote: -Since there are no guarantees, it can use a hash filter +Since there are no guarentees, it can use a hash filter orsilently switch to allmulti or promiscuous mode if it is given too many addresses. ] This table is set using the class VIRTIO_NET_CTRL_MAC and the @@ -1665,6 +1654,38 @@ can control a VLAN filter table in the device. Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL command take a 16-bit VLAN id as the command-specific-data. + Gratuitous Packet Sending + +If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends +on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous +packets; this is usually done after the guest has been physically +migrated, and needs to announce its presence on the new network +links. (As hypervisor does not have the knowledge of guest +network configuration (eg. tagged vlan) it is simplest to prod +the guest in this way). + +#define VIRTIO_NET_CTRL_ANNOUNCE 3 + + #define VIRTIO_NET_CTRL_ANNOUNCE_ACK 0 + +The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status +field when it notices the changes of device configuration. The +command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that +driver has recevied the notification and device would clear the +VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received +this command. + +Processing this notification involves: + + Sending the gratuitous packets or marking there are pending + gratuitous packets to be sent and letting deferred routine to + send them. + + Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control + vq. + + . + Appendix D: Block Device The virtio block device is a simple virtual block device (ie. @@ -1699,8 +1720,6 @@ device except where noted. VIRTIO_BLK_F_FLUSH (9) Cache flush command support. - - Device configuration layout The capacity of the device (expressed in 512-byte sectors) is always present. The availability of the others all depend on various feature bits @@ -1743,8 +1762,6 @@ device except where noted. If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail. - - Device Operation The driver queues requests to the virtqueue, and they are used by @@ -1805,7 +1822,7 @@ the FLUSH and FLUSH_OUT types are equivalent, the device does not distinguish between them ]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit (VIRTIO_BLK_T_BARRIER) indicates that this request acts as a -barrier and that all preceding requests must be complete before +barrier and that all preceeding requests must be complete before this one, and all following requests must not be started until this is complete. Note that a barrier does not flush caches in the underlying backend device in host, and thus does not serve as @@ -2118,7 +2135,7 @@ This is historical, and independent of the guest page size Otherwise, the guest may begin to re-use pages previously given to the balloon before the device has acknowledged their - withdrawal. [footnote: + withdrawl. [footnote: In this case, deflation advice is merely a courtesy ] @@ -2198,3 +2215,996 @@ as follows: VIRTIO_BALLOON_S_MEMTOT The total amount of memory available (in bytes). +Appendix H: Rpmsg: Remote Processor Messaging + +Virtio rpmsg devices represent remote processors on the system +which run in asymmetric multi-processing (AMP) configuration, and +which are usually used to offload cpu-intensive tasks from the +main application processor (a typical SoC methodology). + +Virtio is being used to communicate with those remote processors; +empty buffers are placed in one virtqueue for receiving messages, +and non-empty buffers, containing outbound messages, are enqueued +in a second virtqueue for transmission. + +Numerous communication channels can be multiplexed over those two +virtqueues, so different entities, running on the application and +remote processor, can directly communicate in a point-to-point +fashion. + + Configuration + + Subsystem Device ID 7 + + Virtqueues 0:receiveq. 1:transmitq. + + Feature bits + + VIRTIO_RPMSG_F_NS (0) Device sends (and capable of receiving) + name service messages announcing the creation (or + destruction) of a channel:/** + + * struct rpmsg_ns_msg - dynamic name service announcement +message + + * @name: name of remote service that is published + + * @addr: address of remote service that is published + + * @flags: indicates whether service is created or destroyed + + * + + * This message is sent across to publish a new service (or +announce + + * about its removal). When we receives these messages, an +appropriate + + * rpmsg channel (i.e device) is created/destroyed. + + */ + +struct rpmsg_ns_msgoon_config { + + char name[RPMSG_NAME_SIZE]; + + u32 addr; + + u32 flags; + +} __packed; + + + +/** + + * enum rpmsg_ns_flags - dynamic name service announcement flags + + * + + * @RPMSG_NS_CREATE: a new remote service was just created + + * @RPMSG_NS_DESTROY: a remote service was just destroyed + + */ + +enum rpmsg_ns_flags { + + RPMSG_NS_CREATE = 0, + + RPMSG_NS_DESTROY = 1, + +}; + + Device configuration layout + +At his point none currently defined. + + Device Initialization + + The initialization routine should identify the receive and + transmission virtqueues. + + The receive virtqueue should be filled with receive buffers. + + Device Operation + +Messages are transmitted by placing them in the transmitq, and +buffers for inbound messages are placed in the receiveq. In any +case, messages are always preceded by the following header: /** + + * struct rpmsg_hdr - common header for all rpmsg messages + + * @src: source address + + * @dst: destination address + + * @reserved: reserved for future use + + * @len: length of payload (in bytes) + + * @flags: message flags + + * @data: @len bytes of message payload data + + * + + * Every message sent(/received) on the rpmsg bus begins with +this header. + + */ + +struct rpmsg_hdr { + + u32 src; + + u32 dst; + + u32 reserved; + + u16 len; + + u16 flags; + + u8 data[0]; + +} __packed; + +Appendix I: SCSI Host Device + +The virtio SCSI host device groups together one or more virtual +logical units (such as disks), and allows communicating to them +using the SCSI protocol. An instance of the device represents a +SCSI host to which many targets and LUNs are attached. + +The virtio SCSI device services two kinds of requests: + + command requests for a logical unit; + + task management functions related to a logical unit, target or + command. + +The device is also able to send out notifications about added and +removed logical units. Together, these capabilities provide a +SCSI transport protocol that uses virtqueues as the transfer +medium. In the transport protocol, the virtio driver acts as the +initiator, while the virtio SCSI host provides one or more +targets that receive and process the requests. + + Configuration + + Subsystem Device ID 8 + + Virtqueues 0:controlq; 1:eventq; 2..n:request queues. + + Feature bits + + VIRTIO_SCSI_F_INOUT (0) A single request can include both + read-only and write-only data buffers. + + VIRTIO_SCSI_F_HOTPLUG (1) The host should enable + hot-plug/hot-unplug of new LUNs and targets on the SCSI bus. + + Device configuration layout All fields of this configuration + are always available. sense_size and cdb_size are writable by + the guest.struct virtio_scsi_config { + + u32 num_queues; + + u32 seg_max; + + u32 max_sectors; + + u32 cmd_per_lun; + + u32 event_info_size; + + u32 sense_size; + + u32 cdb_size; + + u16 max_channel; + + u16 max_target; + + u32 max_lun; + +}; + + num_queues is the total number of request virtqueues exposed by + the device. The driver is free to use only one request queue, + or it can use more to achieve better performance. + + seg_max is the maximum number of segments that can be in a + command. A bidirectional command can include seg_max input + segments and seg_max output segments. + + max_sectors is a hint to the guest about the maximum transfer + size it should use. + + cmd_per_lun is a hint to the guest about the maximum number of + linked commands it should send to one LUN. The actual value + to be used is the minimum of cmd_per_lun and the virtqueue + size. + + event_info_size is the maximum size that the device will fill + for buffers that the driver places in the eventq. The driver + should always put buffers at least of this size. It is + written by the device depending on the set of negotated + features. + + sense_size is the maximum size of the sense data that the + device will write. The default value is written by the device + and will always be 96, but the driver can modify it. It is + restored to the default when the device is reset. + + cdb_size is the maximum size of the CDB that the driver will + write. The default value is written by the device and will + always be 32, but the driver can likewise modify it. It is + restored to the default when the device is reset. + + max_channel, max_target and max_lun can be used by the driver + as hints to constrain scanning the logical units on the + host.h + + Device Initialization + +The initialization routine should first of all discover the +device's virtqueues. + +If the driver uses the eventq, it should then place at least a +buffer in the eventq. + +The driver can immediately issue requests (for example, INQUIRY +or REPORT LUNS) or task management functions (for example, I_T +RESET). + + Device Operation: request queues + +The driver queues requests to an arbitrary request queue, and +they are used by the device on that same queue. It is the +responsibility of the driver to ensure strict request ordering +for commands placed on different queues, because they will be +consumed with no order constraints. + +Requests have the following format: + +struct virtio_scsi_req_cmd { + + // Read-only + + u8 lun[8]; + + u64 id; + + u8 task_attr; + + u8 prio; + + u8 crn; + + char cdb[cdb_size]; + + char dataout[]; + + // Write-only part + + u32 sense_len; + + u32 residual; + + u16 status_qualifier; + + u8 status; + + u8 response; + + u8 sense[sense_size]; + + char datain[]; + +}; + + + +/* command-specific response values */ + +#define VIRTIO_SCSI_S_OK 0 + +#define VIRTIO_SCSI_S_OVERRUN 1 + +#define VIRTIO_SCSI_S_ABORTED 2 + +#define VIRTIO_SCSI_S_BAD_TARGET 3 + +#define VIRTIO_SCSI_S_RESET 4 + +#define VIRTIO_SCSI_S_BUSY 5 + +#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6 + +#define VIRTIO_SCSI_S_TARGET_FAILURE 7 + +#define VIRTIO_SCSI_S_NEXUS_FAILURE 8 + +#define VIRTIO_SCSI_S_FAILURE 9 + + + +/* task_attr */ + +#define VIRTIO_SCSI_S_SIMPLE 0 + +#define VIRTIO_SCSI_S_ORDERED 1 + +#define VIRTIO_SCSI_S_HEAD 2 + +#define VIRTIO_SCSI_S_ACA 3 + +The lun field addresses a target and logical unit in the +virtio-scsi device's SCSI domain. The only supported format for +the LUN field is: first byte set to 1, second byte set to target, +third and fourth byte representing a single level LUN structure, +followed by four zero bytes. With this representation, a +virtio-scsi device can serve up to 256 targets and 16384 LUNs per +target. + +The id field is the command identifier (“tag”). + +task_attr, prio and crn should be left to zero. task_attr defines +the task attribute as in the table above, but all task attributes +may be mapped to SIMPLE by the device; crn may also be provided +by clients, but is generally expected to be 0. The maximum CRN +value defined by the protocol is 255, since CRN is stored in an +8-bit integer. + +All of these fields are defined in SAM. They are always +read-only, as are the cdb and dataout field. The cdb_size is +taken from the configuration space. + +sense and subsequent fields are always write-only. The sense_len +field indicates the number of bytes actually written to the sense +buffer. The residual field indicates the residual size, +calculated as “data_length - number_of_transferred_bytes”, for +read or write operations. For bidirectional commands, the +number_of_transferred_bytes includes both read and written bytes. +A residual field that is less than the size of datain means that +the dataout field was processed entirely. A residual field that +exceeds the size of datain means that the dataout field was +processed partially and the datain field was not processed at +all. + +The status byte is written by the device to be the status code as +defined in SAM. + +The response byte is written by the device to be one of the +following: + + VIRTIO_SCSI_S_OK when the request was completed and the status + byte is filled with a SCSI status code (not necessarily + "GOOD"). + + VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires + transferring more data than is available in the data buffers. + + VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an + ABORT TASK or ABORT TASK SET task management function. + + VIRTIO_SCSI_S_BAD_TARGET if the request was never processed + because the target indicated by the lun field does not exist. + + VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus + or device reset (including a task management function). + + VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a + problem in the connection between the host and the target + (severed link). + + VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a + failure and the guest should not retry on other paths. + + VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure + but retrying on other paths might yield a different result. + + VIRTIO_SCSI_S_BUSY if the request failed but retrying on the + same path should work. + + VIRTIO_SCSI_S_FAILURE for other host or guest error. In + particular, if neither dataout nor datain is empty, and the + VIRTIO_SCSI_F_INOUT feature has not been negotiated, the + request will be immediately returned with a response equal to + VIRTIO_SCSI_S_FAILURE. + + Device Operation: controlq + +The controlq is used for other SCSI transport operations. +Requests have the following format: + +struct virtio_scsi_ctrl { + + u32 type; + + ... + + u8 response; + +}; + + + +/* response values valid for all commands */ + +#define VIRTIO_SCSI_S_OK 0 + +#define VIRTIO_SCSI_S_BAD_TARGET 3 + +#define VIRTIO_SCSI_S_BUSY 5 + +#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6 + +#define VIRTIO_SCSI_S_TARGET_FAILURE 7 + +#define VIRTIO_SCSI_S_NEXUS_FAILURE 8 + +#define VIRTIO_SCSI_S_FAILURE 9 + +#define VIRTIO_SCSI_S_INCORRECT_LUN 12 + +The type identifies the remaining fields. + +The following commands are defined: + + Task management function +#define VIRTIO_SCSI_T_TMF 0 + + + +#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0 + +#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1 + +#define VIRTIO_SCSI_T_TMF_CLEAR_ACA 2 + +#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3 + +#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET 4 + +#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5 + +#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6 + +#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7 + + + +struct virtio_scsi_ctrl_tmf + +{ + + // Read-only part + + u32 type; + + u32 subtype; + + u8 lun[8]; + + u64 id; + + // Write-only part + + u8 response; + +} + + + +/* command-specific response values */ + +#define VIRTIO_SCSI_S_FUNCTION_COMPLETE 0 + +#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10 + +#define VIRTIO_SCSI_S_FUNCTION_REJECTED 11 + + The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All + fields except response are filled by the driver. The subtype + field must always be specified and identifies the requested + task management function. + + Other fields may be irrelevant for the requested TMF; if so, + they are ignored but they should still be present. The lun + field is in the same format specified for request queues; the + single level LUN is ignored when the task management function + addresses a whole I_T nexus. When relevant, the value of the id + field is matched against the id values passed on the requestq. + + The outcome of the task management function is written by the + device in the response field. The command-specific response + values map 1-to-1 with those defined in SAM. + + Asynchronous notification query +#define VIRTIO_SCSI_T_AN_QUERY 1 + + + +struct virtio_scsi_ctrl_an { + + // Read-only part + + u32 type; + + u8 lun[8]; + + u32 event_requested; + + // Write-only part + + u32 event_actual; + + u8 response; + +} + + + +#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2 + +#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT 4 + +#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST 8 + +#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE 16 + +#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST 32 + +#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY 64 + + By sending this command, the driver asks the device which + events the given LUN can report, as described in paragraphs 6.6 + and A.6 of the SCSI MMC specification. The driver writes the + events it is interested in into the event_requested; the device + responds by writing the events that it supports into + event_actual. + + The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested + fields are written by the driver. The event_actual and response + fields are written by the device. + + No command-specific values are defined for the response byte. + + Asynchronous notification subscription +#define VIRTIO_SCSI_T_AN_SUBSCRIBE 2 + + + +struct virtio_scsi_ctrl_an { + + // Read-only part + + u32 type; + + u8 lun[8]; + + u32 event_requested; + + // Write-only part + + u32 event_actual; + + u8 response; + +} + + By sending this command, the driver asks the specified LUN to + report events for its physical interface, again as described in + the SCSI MMC specification. The driver writes the events it is + interested in into the event_requested; the device responds by + writing the events that it supports into event_actual. + + Event types are the same as for the asynchronous notification + query message. + + The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and + event_requested fields are written by the driver. The + event_actual and response fields are written by the device. + + No command-specific values are defined for the response byte. + + Device Operation: eventq + +The eventq is used by the device to report information on logical +units that are attached to it. The driver should always leave a +few buffers ready in the eventq. In general, the device will not +queue events to cope with an empty eventq, and will end up +dropping events if it finds no buffer ready. However, when +reporting events for many LUNs (e.g. when a whole target +disappears), the device can throttle events to avoid dropping +them. For this reason, placing 10-15 buffers on the event queue +should be enough. + +Buffers are placed in the eventq and filled by the device when +interesting events occur. The buffers should be strictly +write-only (device-filled) and the size of the buffers should be +at least the value given in the device's configuration +information. + +Buffers returned by the device on the eventq will be referred to +as "events" in the rest of this section. Events have the +following format: + +#define VIRTIO_SCSI_T_EVENTS_MISSED 0x80000000 + + + +struct virtio_scsi_event { + + // Write-only part + + u32 event; + + ... + +} + +If bit 31 is set in the event field, the device failed to report +an event due to missing buffers. In this case, the driver should +poll the logical units for unit attention conditions, and/or do +whatever form of bus scan is appropriate for the guest operating +system. + +Other data that the device writes to the buffer depends on the +contents of the event field. The following events are defined: + + No event +#define VIRTIO_SCSI_T_NO_EVENT 0 + + This event is fired in the following cases: + + When the device detects in the eventq a buffer that is shorter + than what is indicated in the configuration field, it might + use it immediately and put this dummy value in the event + field. A well-written driver will never observe this + situation. + + When events are dropped, the device may signal this event as + soon as the drivers makes a buffer available, in order to + request action from the driver. In this case, of course, this + event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED + flag. + + Transport reset +#define VIRTIO_SCSI_T_TRANSPORT_RESET 1 + + + +struct virtio_scsi_event_reset { + + // Write-only part + + u32 event; + + u8 lun[8]; + + u32 reason; + +} + + + +#define VIRTIO_SCSI_EVT_RESET_HARD 0 + +#define VIRTIO_SCSI_EVT_RESET_RESCAN 1 + +#define VIRTIO_SCSI_EVT_RESET_REMOVED 2 + + By sending this event, the device signals that a logical unit + on a target has been reset, including the case of a new device + appearing or disappearing on the bus.The device fills in all + fields. The event field is set to + VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a + logical unit in the SCSI host. + + The reason value is one of the three #define values appearing + above: + + VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used if + the target or logical unit is no longer able to receive + commands. + + VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the + logical unit has been reset, but is still present. + + VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if a + target or logical unit has just appeared on the device. + + The “removed” and “rescan” events, when sent for LUN 0, may + apply to the entire target. After receiving them the driver + should ask the initiator to rescan the target, in order to + detect the case when an entire target has appeared or + disappeared. These two events will never be reported unless the + VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host + and the guest. + + Events will also be reported via sense codes (this obviously + does not apply to newly appeared buses or targets, since the + application has never discovered them): + + “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc + 0x25, ascq 0x00 (LOGICAL UNIT NOT SUPPORTED) + + “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29 + (POWER ON, RESET OR BUS DEVICE RESET OCCURRED) + + “rescan LUN/target” maps to sense key UNIT ATTENTION, asc 0x3f, + ascq 0x0e (REPORTED LUNS DATA HAS CHANGED) + + The preferred way to detect transport reset is always to use + events, because sense codes are only seen by the driver when it + sends a SCSI command to the logical unit or target. However, in + case events are dropped, the initiator will still be able to + synchronize with the actual state of the controller if the + driver asks the initiator to rescan of the SCSI bus. During the + rescan, the initiator will be able to observe the above sense + codes, and it will process them as if it the driver had + received the equivalent event. + + Asynchronous notification +#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2 + + + +struct virtio_scsi_event_an { + + // Write-only part + + u32 event; + + u8 lun[8]; + + u32 reason; + +} + + By sending this event, the device signals that an asynchronous + event was fired from a physical interface. + + All fields are written by the device. The event field is set to + VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical + unit in the SCSI host. The reason field is a subset of the + events that the driver has subscribed to via the "Asynchronous + notification subscription" command. + + When dropped events are reported, the driver should poll for + asynchronous events manually using SCSI commands. + +Appendix X: virtio-mmio + +Virtual environments without PCI support (a common situation in +embedded devices models) might use simple memory mapped device (“ +virtio-mmio”) instead of the PCI device. + +The memory mapped virtio device behaviour is based on the PCI +device specification. Therefore most of operations like device +initialization, queues configuration and buffer transfers are +nearly identical. Existing differences are described in the +following sections. + + Device Initialization + +Instead of using the PCI IO space for virtio header, the “ +virtio-mmio” device provides a set of memory mapped control +registers, all 32 bits wide, followed by device-specific +configuration space. The following list presents their layout: + + Offset from the device base address | Direction | Name + Description + + 0x000 | R | MagicValue + “virt” string. + + 0x004 | R | Version + Device version number. Currently must be 1. + + 0x008 | R | DeviceID + Virtio Subsystem Device ID (ie. 1 for network card). + + 0x00c | R | VendorID + Virtio Subsystem Vendor ID. + + 0x010 | R | HostFeatures + Flags representing features the device supports. + Reading from this register returns 32 consecutive flag bits, + first bit depending on the last value written to + HostFeaturesSel register. Access to this register returns bits HostFeaturesSel*32 + + to (HostFeaturesSel*32)+31 +, eg. feature bits 0 to 31 if + HostFeaturesSel is set to 0 and features bits 32 to 63 if + HostFeaturesSel is set to 1. Also see [sub:Feature-Bits] + + 0x014 | W | HostFeaturesSel + Device (Host) features word selection. + Writing to this register selects a set of 32 device feature bits + accessible by reading from HostFeatures register. Device driver + must write a value to the HostFeaturesSel register before + reading from the HostFeatures register. + + 0x020 | W | GuestFeatures + Flags representing device features understood and activated by + the driver. + Writing to this register sets 32 consecutive flag bits, first + bit depending on the last value written to GuestFeaturesSel + register. Access to this register sets bits GuestFeaturesSel*32 + + to (GuestFeaturesSel*32)+31 +, eg. feature bits 0 to 31 if + GuestFeaturesSel is set to 0 and features bits 32 to 63 if + GuestFeaturesSel is set to 1. Also see [sub:Feature-Bits] + + 0x024 | W | GuestFeaturesSel + Activated (Guest) features word selection. + Writing to this register selects a set of 32 activated feature + bits accessible by writing to the GuestFeatures register. + Device driver must write a value to the GuestFeaturesSel + register before writing to the GuestFeatures register. + + 0x028 | W | GuestPageSize + Guest page size. + Device driver must write the guest page size in bytes to the + register during initialization, before any queues are used. + This value must be a power of 2 and is used by the Host to + calculate Guest address of the first queue page (see QueuePFN). + + 0x030 | W | QueueSel + Virtual queue index (first queue is 0). + Writing to this register selects the virtual queue that the + following operations on QueueNum, QueueAlign and QueuePFN apply + to. + + 0x034 | R | QueueNumMax + Maximum virtual queue size. + Reading from the register returns the maximum size of the queue + the Host is ready to process or zero (0x0) if the queue is not + available. This applies to the queue selected by writing to + QueueSel and is allowed only when QueuePFN is set to zero + (0x0), so when the queue is not actively used. + + 0x038 | W | QueueNum + Virtual queue size. + Queue size is a number of elements in the queue, therefore size + of the descriptor table and both available and used rings. + Writing to this register notifies the Host what size of the + queue the Guest will use. This applies to the queue selected by + writing to QueueSel. + + 0x03c | W | QueueAlign + Used Ring alignment in the virtual queue. + Writing to this register notifies the Host about alignment + boundary of the Used Ring in bytes. This value must be a power + of 2 and applies to the queue selected by writing to QueueSel. + + 0x040 | RW | QueuePFN + Guest physical page number of the virtual queue. + Writing to this register notifies the host about location of the + virtual queue in the Guest's physical address space. This value + is the index number of a page starting with the queue + Descriptor Table. Value zero (0x0) means physical address zero + (0x00000000) and is illegal. When the Guest stops using the + queue it must write zero (0x0) to this register. + Reading from this register returns the currently used page + number of the queue, therefore a value other than zero (0x0) + means that the queue is in use. + Both read and write accesses apply to the queue selected by + writing to QueueSel. + + 0x050 | W | QueueNotify + Queue notifier. + Writing a queue index to this register notifies the Host that + there are new buffers to process in the queue. + + 0x60 | R | InterruptStatus +Interrupt status. +Reading from this register returns a bit mask of interrupts + asserted by the device. An interrupt is asserted if the + corresponding bit is set, ie. equals one (1). + + Bit 0 | Used Ring Update +This interrupt is asserted when the Host has updated the Used + Ring in at least one of the active virtual queues. + + Bit 1 | Configuration change +This interrupt is asserted when configuration of the device has + changed. + + 0x064 | W | InterruptACK + Interrupt acknowledge. + Writing to this register notifies the Host that the Guest + finished handling interrupts. Set bits in the value clear the + corresponding bits of the InterruptStatus register. + + 0x070 | RW | Status + Device status. + Reading from this register returns the current device status + flags. + Writing non-zero values to this register sets the status flags, + indicating the Guest progress. Writing zero (0x0) to this + register triggers a device reset. + Also see [sub:Device-Initialization-Sequence] + + 0x100+ | RW | Config + Device-specific configuration space starts at an offset 0x100 + and is accessed with byte alignment. Its meaning and size + depends on the device and the driver. + +Virtual queue size is a number of elements in the queue, +therefore size of the descriptor table and both available and +used rings. + +The endianness of the registers follows the native endianness of +the Guest. Writing to registers described as “R” and reading from +registers described as “W” is not permitted and can cause +undefined behavior. + +The device initialization is performed as described in [sub:Device-Initialization-Sequence] + with one exception: the Guest must notify the Host about its +page size, writing the size in bytes to GuestPageSize register +before the initialization is finished. + +The memory mapped virtio devices generate single interrupt only, +therefore no special configuration is required. + + Virtqueue Configuration + +The virtual queue configuration is performed in a similar way to +the one described in [sec:Virtqueue-Configuration] with a few +additional operations: + + Select the queue writing its index (first queue is 0) to the + QueueSel register. + + Check if the queue is not already in use: read QueuePFN + register, returned value should be zero (0x0). + + Read maximum queue size (number of elements) from the + QueueNumMax register. If the returned value is zero (0x0) the + queue is not available. + + Allocate and zero the queue pages in contiguous virtual memory, + aligning the Used Ring to an optimal boundary (usually page + size). Size of the allocated queue may be smaller than or equal + to the maximum size returned by the Host. + + Notify the Host about the queue size by writing the size to + QueueNum register. + + Notify the Host about the used alignment by writing its value + in bytes to QueueAlign register. + + Write the physical number of the first page of the queue to the + QueuePFN register. + +The queue and the device are ready to begin normal operations +now. + + Device Operation + +The memory mapped virtio device behaves in the same way as +described in [sec:Device-Operation], with the following +exceptions: + + The device is notified about new buffers available in a queue + by writing the queue index to register QueueNum instead of the + virtio header in PCI I/O space ([sub:Notifying-The-Device]). + + The memory mapped virtio device is using single, dedicated + interrupt signal, which is raised when at least one of the + interrupts described in the InterruptStatus register + description is asserted. After receiving an interrupt, the + driver must read the InterruptStatus register to check what + caused the interrupt (see the register description). After the + interrupt is handled, the driver must acknowledge it by writing + a bit mask corresponding to the serviced interrupt to the + InterruptACK register. + |