Merge branch 'spi/merge' of git://git.secretlab.ca/git/linux-2.6

+29 -4

Documentation/arm/Booting

··· 65 65 The boot loader must ultimately be able to provide a MACH_TYPE_xxx 66 66 value to the kernel. (see linux/arch/arm/tools/mach-types). 67 67 68 - 69 - 4. Setup the kernel tagged list 70 - ------------------------------- 68 + 4. Setup boot data 69 + ------------------ 71 70 72 71 Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED 73 72 New boot loaders: MANDATORY 73 + 74 + The boot loader must provide either a tagged list or a dtb image for 75 + passing configuration data to the kernel. The physical address of the 76 + boot data is passed to the kernel in register r2. 77 + 78 + 4a. Setup the kernel tagged list 79 + -------------------------------- 74 80 75 81 The boot loader must create and initialise the kernel tagged list. 76 82 A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. ··· 107 101 the kernel decompressor nor initrd 'bootp' program will overwrite 108 102 it. The recommended placement is in the first 16KiB of RAM. 109 103 104 + 4b. Setup the device tree 105 + ------------------------- 106 + 107 + The boot loader must load a device tree image (dtb) into system ram 108 + at a 64bit aligned address and initialize it with the boot data. The 109 + dtb format is documented in Documentation/devicetree/booting-without-of.txt. 110 + The kernel will look for the dtb magic value of 0xd00dfeed at the dtb 111 + physical address to determine if a dtb has been passed instead of a 112 + tagged list. 113 + 114 + The boot loader must pass at a minimum the size and location of the 115 + system memory, and the root filesystem location. The dtb must be 116 + placed in a region of memory where the kernel decompressor will not 117 + overwrite it. The recommended placement is in the first 16KiB of RAM 118 + with the caveat that it may not be located at physical address 0 since 119 + the kernel interprets a value of 0 in r2 to mean neither a tagged list 120 + nor a dtb were passed. 121 + 110 122 5. Calling the kernel image 111 123 --------------------------- 112 124 ··· 149 125 - CPU register settings 150 126 r0 = 0, 151 127 r1 = machine type number discovered in (3) above. 152 - r2 = physical address of tagged list in system RAM. 128 + r2 = physical address of tagged list in system RAM, or 129 + physical address of device tree block (dtb) in system RAM 153 130 154 131 - CPU mode 155 132 All forms of interrupts must be disabled (IRQs and FIQs)

+88 -105

Documentation/powerpc/booting-without-of.txt Documentation/devicetree/booting-without-of.txt

··· 13 13 14 14 I - Introduction 15 15 1) Entry point for arch/powerpc 16 - 2) Board support 16 + 2) Entry point for arch/arm 17 17 18 18 II - The DT block format 19 19 1) Header ··· 41 41 VI - System-on-a-chip devices and nodes 42 42 1) Defining child nodes of an SOC 43 43 2) Representing devices without a current OF specification 44 - a) PHY nodes 45 - b) Interrupt controllers 46 - c) 4xx/Axon EMAC ethernet nodes 47 - d) Xilinx IP cores 48 - e) USB EHCI controllers 49 - f) MDIO on GPIOs 50 - g) SPI busses 51 44 52 45 VII - Specifying interrupt information for devices 53 46 1) interrupts property ··· 116 123 I - Introduction 117 124 ================ 118 125 119 - During the recent development of the Linux/ppc64 kernel, and more 126 + During the development of the Linux/ppc64 kernel, and more 120 127 specifically, the addition of new platform types outside of the old 121 128 IBM pSeries/iSeries pair, it was decided to enforce some strict rules 122 129 regarding the kernel entry and bootloader <-> kernel interfaces, in ··· 139 146 create a node for every PCI device in the system. It is a requirement 140 147 to have a node for PCI host bridges in order to provide interrupt 141 148 routing informations and memory/IO ranges, among others. It is also 142 - recommended to define nodes for on chip devices and other busses that 149 + recommended to define nodes for on chip devices and other buses that 143 150 don't specifically fit in an existing OF specification. This creates a 144 151 great flexibility in the way the kernel can then probe those and match 145 152 drivers to device, without having to hard code all sorts of tables. It ··· 151 158 1) Entry point for arch/powerpc 152 159 ------------------------------- 153 160 154 - There is one and one single entry point to the kernel, at the start 161 + There is one single entry point to the kernel, at the start 155 162 of the kernel image. That entry point supports two calling 156 163 conventions: 157 164 ··· 203 210 with all CPUs. The way to do that with method b) will be 204 211 described in a later revision of this document. 205 212 206 - 207 - 2) Board support 208 - ---------------- 209 - 210 - 64-bit kernels: 211 - 212 213 Board supports (platforms) are not exclusive config options. An 213 214 arbitrary set of board supports can be built in a single kernel 214 215 image. The kernel will "know" what set of functions to use for a ··· 221 234 containing the various callbacks that the generic code will 222 235 use to get to your platform specific code 223 236 224 - c) Add a reference to your "ppc_md" structure in the 225 - "machines" table in arch/powerpc/kernel/setup_64.c if you are 226 - a 64-bit platform. 227 - 228 - d) request and get assigned a platform number (see PLATFORM_* 229 - constants in arch/powerpc/include/asm/processor.h 230 - 231 - 32-bit embedded kernels: 232 - 233 - Currently, board support is essentially an exclusive config option. 234 - The kernel is configured for a single platform. Part of the reason 235 - for this is to keep kernels on embedded systems small and efficient; 236 - part of this is due to the fact the code is already that way. In the 237 - future, a kernel may support multiple platforms, but only if the 237 + A kernel image may support multiple platforms, but only if the 238 238 platforms feature the same core architecture. A single kernel build 239 239 cannot support both configurations with Book E and configurations 240 240 with classic Powerpc architectures. 241 241 242 - 32-bit embedded platforms that are moved into arch/powerpc using a 243 - flattened device tree should adopt the merged tree practice of 244 - setting ppc_md up dynamically, even though the kernel is currently 245 - built with support for only a single platform at a time. This allows 246 - unification of the setup code, and will make it easier to go to a 247 - multiple-platform-support model in the future. 242 + 2) Entry point for arch/arm 243 + --------------------------- 248 244 249 - NOTE: I believe the above will be true once Ben's done with the merge 250 - of the boot sequences.... someone speak up if this is wrong! 245 + There is one single entry point to the kernel, at the start 246 + of the kernel image. That entry point supports two calling 247 + conventions. A summary of the interface is described here. A full 248 + description of the boot requirements is documented in 249 + Documentation/arm/Booting 251 250 252 - To add a 32-bit embedded platform support, follow the instructions 253 - for 64-bit platforms above, with the exception that the Kconfig 254 - option should be set up such that the kernel builds exclusively for 255 - the platform selected. The processor type for the platform should 256 - enable another config option to select the specific board 257 - supported. 251 + a) ATAGS interface. Minimal information is passed from firmware 252 + to the kernel with a tagged list of predefined parameters. 258 253 259 - NOTE: If Ben doesn't merge the setup files, may need to change this to 260 - point to setup_32.c 254 + r0 : 0 261 255 256 + r1 : Machine type number 262 257 263 - I will describe later the boot process and various callbacks that 264 - your platform should implement. 258 + r2 : Physical address of tagged list in system RAM 259 + 260 + b) Entry with a flattened device-tree block. Firmware loads the 261 + physical address of the flattened device tree block (dtb) into r2, 262 + r1 is not used, but it is considered good practise to use a valid 263 + machine number as described in Documentation/arm/Booting. 264 + 265 + r0 : 0 266 + 267 + r1 : Valid machine type number. When using a device tree, 268 + a single machine type number will often be assigned to 269 + represent a class or family of SoCs. 270 + 271 + r2 : physical pointer to the device-tree block 272 + (defined in chapter II) in RAM. Device tree can be located 273 + anywhere in system RAM, but it should be aligned on a 32 bit 274 + boundary. 275 + 276 + The kernel will differentiate between ATAGS and device tree booting by 277 + reading the memory pointed to by r1 and looking for either the flattened 278 + device tree block magic value (0xd00dfeed) or the ATAG_CORE value at 279 + offset 0x4 from r2 (0x54410001). 265 280 266 281 267 282 II - The DT block format ··· 289 300 1) Header 290 301 --------- 291 302 292 - The kernel is entered with r3 pointing to an area of memory that is 293 - roughly described in arch/powerpc/include/asm/prom.h by the structure 303 + The kernel is passed the physical address pointing to an area of memory 304 + that is roughly described in include/linux/of_fdt.h by the structure 294 305 boot_param_header: 295 306 296 307 struct boot_param_header { ··· 328 339 All values in this header are in big endian format, the various 329 340 fields in this header are defined more precisely below. All 330 341 "offset" values are in bytes from the start of the header; that is 331 - from the value of r3. 342 + from the physical base address of the device tree block. 332 343 333 344 - magic 334 345 ··· 426 437 427 438 428 439 ------------------------------ 429 - r3 -> | struct boot_param_header | 440 + base -> | struct boot_param_header | 430 441 ------------------------------ 431 442 | (alignment gap) (*) | 432 443 ------------------------------ ··· 446 457 -----> ------------------------------ 447 458 | 448 459 | 449 - --- (r3 + totalsize) 460 + --- (base + totalsize) 450 461 451 462 (*) The alignment gaps are not necessarily present; their presence 452 463 and size are dependent on the various alignment requirements of ··· 489 500 the device-tree. More details about the actual format of these will be 490 501 below. 491 502 492 - The kernel powerpc generic code does not make any formal use of the 503 + The kernel generic code does not make any formal use of the 493 504 unit address (though some board support code may do) so the only real 494 505 requirement here for the unit address is to ensure uniqueness of 495 506 the node unit name at a given level of the tree. Nodes with no notion ··· 507 518 508 519 Every node which actually represents an actual device (that is, a node 509 520 which isn't only a virtual "container" for more nodes, like "/cpus" 510 - is) is also required to have a "device_type" property indicating the 511 - type of node . 521 + is) is also required to have a "compatible" property indicating the 522 + specific hardware and an optional list of devices it is fully 523 + backwards compatible with. 512 524 513 525 Finally, every node that can be referenced from a property in another 514 - node is required to have a "linux,phandle" property. Real open 515 - firmware implementations provide a unique "phandle" value for every 516 - node that the "prom_init()" trampoline code turns into 517 - "linux,phandle" properties. However, this is made optional if the 518 - flattened device tree is used directly. An example of a node 526 + node is required to have either a "phandle" or a "linux,phandle" 527 + property. Real Open Firmware implementations provide a unique 528 + "phandle" value for every node that the "prom_init()" trampoline code 529 + turns into "linux,phandle" properties. However, this is made optional 530 + if the flattened device tree is used directly. An example of a node 519 531 referencing another node via "phandle" is when laying out the 520 532 interrupt tree which will be described in a further version of this 521 533 document. 522 534 523 - This "linux, phandle" property is a 32-bit value that uniquely 535 + The "phandle" property is a 32-bit value that uniquely 524 536 identifies a node. You are free to use whatever values or system of 525 537 values, internal pointers, or whatever to generate these, the only 526 538 requirement is that every node for which you provide that property has ··· 684 694 while the top cell contains address space indication, flags, and pci 685 695 bus & device numbers. 686 696 687 - For busses that support dynamic allocation, it's the accepted practice 697 + For buses that support dynamic allocation, it's the accepted practice 688 698 to then not provide the address in "reg" (keep it 0) though while 689 699 providing a flag indicating the address is dynamically allocated, and 690 700 then, to provide a separate "assigned-addresses" property that ··· 701 711 The "reg" property only defines addresses and sizes (if #size-cells is 702 712 non-0) within a given bus. In order to translate addresses upward 703 713 (that is into parent bus addresses, and possibly into CPU physical 704 - addresses), all busses must contain a "ranges" property. If the 714 + addresses), all buses must contain a "ranges" property. If the 705 715 "ranges" property is missing at a given level, it's assumed that 706 716 translation isn't possible, i.e., the registers are not visible on the 707 717 parent bus. The format of the "ranges" property for a bus is a list ··· 717 727 PCI<->ISA bridge, that would be a PCI address. It defines the base 718 728 address in the parent bus where the beginning of that range is mapped. 719 729 720 - For a new 64-bit powerpc board, I recommend either the 2/2 format or 730 + For new 64-bit board support, I recommend either the 2/2 format or 721 731 Apple's 2/1 format which is slightly more compact since sizes usually 722 - fit in a single 32-bit word. New 32-bit powerpc boards should use a 732 + fit in a single 32-bit word. New 32-bit board support should use a 723 733 1/1 format, unless the processor supports physical addresses greater 724 734 than 32-bits, in which case a 2/1 format is recommended. 725 735 ··· 744 754 While earlier users of Open Firmware like OldWorld macintoshes tended 745 755 to use the actual device name for the "name" property, it's nowadays 746 756 considered a good practice to use a name that is closer to the device 747 - class (often equal to device_type). For example, nowadays, ethernet 757 + class (often equal to device_type). For example, nowadays, Ethernet 748 758 controllers are named "ethernet", an additional "model" property 749 759 defining precisely the chip type/model, and "compatible" property 750 760 defining the family in case a single driver can driver more than one ··· 762 772 4) Note about node and property names and character set 763 773 ------------------------------------------------------- 764 774 765 - While open firmware provides more flexible usage of 8859-1, this 775 + While Open Firmware provides more flexible usage of 8859-1, this 766 776 specification enforces more strict rules. Nodes and properties should 767 777 be comprised only of ASCII characters 'a' to 'z', '0' to 768 778 '9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally ··· 782 792 -------------------------------- 783 793 These are all that are currently required. However, it is strongly 784 794 recommended that you expose PCI host bridges as documented in the 785 - PCI binding to open firmware, and your interrupt tree as documented 795 + PCI binding to Open Firmware, and your interrupt tree as documented 786 796 in OF interrupt tree specification. 787 797 788 798 a) The root node ··· 792 802 - model : this is your board name/model 793 803 - #address-cells : address representation for "root" devices 794 804 - #size-cells: the size representation for "root" devices 795 - - device_type : This property shouldn't be necessary. However, if 796 - you decide to create a device_type for your root node, make sure it 797 - is _not_ "chrp" unless your platform is a pSeries or PAPR compliant 798 - one for 64-bit, or a CHRP-type machine for 32-bit as this will 799 - matched by the kernel this way. 800 - 801 - Additionally, some recommended properties are: 802 - 803 805 - compatible : the board "family" generally finds its way here, 804 806 for example, if you have 2 board models with a similar layout, 805 807 that typically get driven by the same platform code in the 806 - kernel, you would use a different "model" property but put a 807 - value in "compatible". The kernel doesn't directly use that 808 - value but it is generally useful. 808 + kernel, you would specify the exact board model in the 809 + compatible property followed by an entry that represents the SoC 810 + model. 809 811 810 812 The root node is also generally where you add additional properties 811 813 specific to your board like the serial number if any, that sort of ··· 823 841 824 842 So under /cpus, you are supposed to create a node for every CPU on 825 843 the machine. There is no specific restriction on the name of the 826 - CPU, though It's common practice to call it PowerPC,<name>. For 844 + CPU, though it's common to call it <architecture>,<core>. For 827 845 example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX. 846 + However, the Generic Names convention suggests that it would be 847 + better to simply use 'cpu' for each cpu node and use the compatible 848 + property to identify the specific cpu core. 828 849 829 850 Required properties: 830 851 ··· 908 923 909 924 e) The /chosen node 910 925 911 - This node is a bit "special". Normally, that's where open firmware 926 + This node is a bit "special". Normally, that's where Open Firmware 912 927 puts some variable environment information, like the arguments, or 913 928 the default input/output devices. 914 929 ··· 925 940 console device if any. Typically, if you have serial devices on 926 941 your board, you may want to put the full path to the one set as 927 942 the default console in the firmware here, for the kernel to pick 928 - it up as its own default console. If you look at the function 929 - set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see 930 - that the kernel tries to find out the default console and has 931 - knowledge of various types like 8250 serial ports. You may want 932 - to extend this function to add your own. 943 + it up as its own default console. 933 944 934 945 Note that u-boot creates and fills in the chosen node for platforms 935 946 that use it. ··· 936 955 937 956 f) the /soc<SOCname> node 938 957 939 - This node is used to represent a system-on-a-chip (SOC) and must be 940 - present if the processor is a SOC. The top-level soc node contains 941 - information that is global to all devices on the SOC. The node name 942 - should contain a unit address for the SOC, which is the base address 943 - of the memory-mapped register set for the SOC. The name of an soc 958 + This node is used to represent a system-on-a-chip (SoC) and must be 959 + present if the processor is a SoC. The top-level soc node contains 960 + information that is global to all devices on the SoC. The node name 961 + should contain a unit address for the SoC, which is the base address 962 + of the memory-mapped register set for the SoC. The name of an SoC 944 963 node should start with "soc", and the remainder of the name should 945 964 represent the part number for the soc. For example, the MPC8540's 946 965 soc node would be called "soc8540". 947 966 948 967 Required properties: 949 968 950 - - device_type : Should be "soc" 951 969 - ranges : Should be defined as specified in 1) to describe the 952 - translation of SOC addresses for memory mapped SOC registers. 953 - - bus-frequency: Contains the bus frequency for the SOC node. 970 + translation of SoC addresses for memory mapped SoC registers. 971 + - bus-frequency: Contains the bus frequency for the SoC node. 954 972 Typically, the value of this field is filled in by the boot 955 973 loader. 974 + - compatible : Exact model of the SoC 956 975 957 976 958 977 Recommended properties: ··· 1136 1155 1137 1156 - An example of code for iterating nodes & retrieving properties 1138 1157 directly from the flattened tree format can be found in the kernel 1139 - file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function, 1158 + file drivers/of/fdt.c. Look at the of_scan_flat_dt() function, 1140 1159 its usage in early_init_devtree(), and the corresponding various 1141 1160 early_init_dt_scan_*() callbacks. That code can be re-used in a 1142 1161 GPL bootloader, and as the author of that code, I would be happy 1143 1162 to discuss possible free licensing to any vendor who wishes to 1144 1163 integrate all or part of this code into a non-GPL bootloader. 1164 + (reference needed; who is 'I' here? ---gcl Jan 31, 2011) 1145 1165 1146 1166 1147 1167 ··· 1185 1203 2) Representing devices without a current OF specification 1186 1204 ---------------------------------------------------------- 1187 1205 1188 - Currently, there are many devices on SOCs that do not have a standard 1189 - representation pre-defined as part of the open firmware 1190 - specifications, mainly because the boards that contain these SOCs are 1191 - not currently booted using open firmware. This section contains 1192 - descriptions for the SOC devices for which new nodes have been 1193 - defined; this list will expand as more and more SOC-containing 1194 - platforms are moved over to use the flattened-device-tree model. 1206 + Currently, there are many devices on SoCs that do not have a standard 1207 + representation defined as part of the Open Firmware specifications, 1208 + mainly because the boards that contain these SoCs are not currently 1209 + booted using Open Firmware. Binding documentation for new devices 1210 + should be added to the Documentation/devicetree/bindings directory. 1211 + That directory will expand as device tree support is added to more and 1212 + more SoCs. 1213 + 1195 1214 1196 1215 VII - Specifying interrupt information for devices 1197 1216 =================================================== 1198 1217 1199 - The device tree represents the busses and devices of a hardware 1218 + The device tree represents the buses and devices of a hardware 1200 1219 system in a form similar to the physical bus topology of the 1201 1220 hardware. 1202 1221

Documentation/powerpc/dts-bindings/4xx/cpm.txt Documentation/devicetree/bindings/powerpc/4xx/cpm.txt

Documentation/powerpc/dts-bindings/4xx/emac.txt Documentation/devicetree/bindings/powerpc/4xx/emac.txt

Documentation/powerpc/dts-bindings/4xx/ndfc.txt Documentation/devicetree/bindings/powerpc/4xx/ndfc.txt

Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt Documentation/devicetree/bindings/powerpc/4xx/ppc440spe-adma.txt

Documentation/powerpc/dts-bindings/4xx/reboot.txt Documentation/devicetree/bindings/powerpc/4xx/reboot.txt

Documentation/powerpc/dts-bindings/can/sja1000.txt Documentation/devicetree/bindings/net/can/sja1000.txt

Documentation/powerpc/dts-bindings/ecm.txt Documentation/devicetree/bindings/powerpc/fsl/ecm.txt

Documentation/powerpc/dts-bindings/eeprom.txt Documentation/devicetree/bindings/eeprom.txt

Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt Documentation/devicetree/bindings/pci/83xx-512x-pci.txt

Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt Documentation/devicetree/bindings/gpio/8xxx_gpio.txt

Documentation/powerpc/dts-bindings/fsl/board.txt Documentation/devicetree/bindings/powerpc/fsl/board.txt

Documentation/powerpc/dts-bindings/fsl/can.txt Documentation/devicetree/bindings/net/can/mpc5xxx-mscan.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/brg.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/i2c.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/pic.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/usb.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/gpio.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/firmware.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/par_io.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/ucc.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/usb.txt

Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/serial.txt

Documentation/powerpc/dts-bindings/fsl/diu.txt Documentation/devicetree/bindings/powerpc/fsl/diu.txt

Documentation/powerpc/dts-bindings/fsl/dma.txt Documentation/devicetree/bindings/powerpc/fsl/dma.txt

Documentation/powerpc/dts-bindings/fsl/esdhc.txt Documentation/devicetree/bindings/mmc/fsl-esdhc.txt

Documentation/powerpc/dts-bindings/fsl/gtm.txt Documentation/devicetree/bindings/powerpc/fsl/gtm.txt

Documentation/powerpc/dts-bindings/fsl/guts.txt Documentation/devicetree/bindings/powerpc/fsl/guts.txt

Documentation/powerpc/dts-bindings/fsl/i2c.txt Documentation/devicetree/bindings/i2c/fsl-i2c.txt

Documentation/powerpc/dts-bindings/fsl/lbc.txt Documentation/devicetree/bindings/powerpc/fsl/lbc.txt

Documentation/powerpc/dts-bindings/fsl/mcm.txt Documentation/devicetree/bindings/powerpc/fsl/mcm.txt

Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt

Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt Documentation/devicetree/bindings/powerpc/fsl/mpc5121-psc.txt

Documentation/powerpc/dts-bindings/fsl/mpc5200.txt Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt

Documentation/powerpc/dts-bindings/fsl/mpic.txt Documentation/devicetree/bindings/powerpc/fsl/mpic.txt

Documentation/powerpc/dts-bindings/fsl/msi-pic.txt Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt

Documentation/powerpc/dts-bindings/fsl/pmc.txt Documentation/devicetree/bindings/powerpc/fsl/pmc.txt

Documentation/powerpc/dts-bindings/fsl/sata.txt Documentation/devicetree/bindings/ata/fsl-sata.txt

Documentation/powerpc/dts-bindings/fsl/sec.txt Documentation/devicetree/bindings/powerpc/fsl/sec.txt

Documentation/powerpc/dts-bindings/fsl/spi.txt Documentation/devicetree/bindings/spi/fsl-spi.txt

Documentation/powerpc/dts-bindings/fsl/ssi.txt Documentation/devicetree/bindings/powerpc/fsl/ssi.txt

Documentation/powerpc/dts-bindings/fsl/tsec.txt Documentation/devicetree/bindings/net/fsl-tsec-phy.txt

Documentation/powerpc/dts-bindings/fsl/upm-nand.txt Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt

Documentation/powerpc/dts-bindings/fsl/usb.txt Documentation/devicetree/bindings/usb/fsl-usb.txt

Documentation/powerpc/dts-bindings/gpio/gpio.txt Documentation/devicetree/bindings/gpio/gpio.txt

Documentation/powerpc/dts-bindings/gpio/led.txt Documentation/devicetree/bindings/gpio/led.txt

Documentation/powerpc/dts-bindings/gpio/mdio.txt Documentation/devicetree/bindings/net/mdio-gpio.txt

Documentation/powerpc/dts-bindings/marvell.txt Documentation/devicetree/bindings/marvell.txt

Documentation/powerpc/dts-bindings/mmc-spi-slot.txt Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt

Documentation/powerpc/dts-bindings/mtd-physmap.txt Documentation/devicetree/bindings/mtd/mtd-physmap.txt

Documentation/powerpc/dts-bindings/nintendo/gamecube.txt Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt

Documentation/powerpc/dts-bindings/nintendo/wii.txt Documentation/devicetree/bindings/powerpc/nintendo/wii.txt

Documentation/powerpc/dts-bindings/phy.txt Documentation/devicetree/bindings/net/phy.txt

Documentation/powerpc/dts-bindings/spi-bus.txt Documentation/devicetree/bindings/spi/spi-bus.txt

Documentation/powerpc/dts-bindings/usb-ehci.txt Documentation/devicetree/bindings/usb/usb-ehci.txt

Documentation/powerpc/dts-bindings/xilinx.txt Documentation/devicetree/bindings/xilinx.txt

+1 -1

MAINTAINERS

··· 4600 4600 4601 4601 OPEN FIRMWARE AND FLATTENED DEVICE TREE 4602 4602 M: Grant Likely <grant.likely@secretlab.ca> 4603 - L: devicetree-discuss@lists.ozlabs.org 4603 + L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers) 4604 4604 W: http://fdt.secretlab.ca 4605 4605 T: git git://git.secretlab.ca/git/linux-2.6.git 4606 4606 S: Maintained

+4 -2

drivers/spi/spi_sh_msiof.c

··· 509 509 bytes_done = 0; 510 510 511 511 while (bytes_done < t->len) { 512 + void *rx_buf = t->rx_buf ? t->rx_buf + bytes_done : NULL; 513 + const void *tx_buf = t->tx_buf ? t->tx_buf + bytes_done : NULL; 512 514 n = sh_msiof_spi_txrx_once(p, tx_fifo, rx_fifo, 513 - t->tx_buf + bytes_done, 514 - t->rx_buf + bytes_done, 515 + tx_buf, 516 + rx_buf, 515 517 words, bits); 516 518 if (n < 0) 517 519 break;

Configure Feed

Configure Feed