The Devicetree Specification has superseded the ePAPR as the base specification for bindings. Update files in Documentation to reference the new document. First reference to ePAPR in Documentation/devicetree/bindings/arm/cci.txt is generic, remove it. Some files are not updated because there is no hypervisor chapter in the Devicetree Specification: Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt Documenation/virtual/kvm/api.txt Documenation/virtual/kvm/ppc-pv.txt Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org>
		
			
				
	
	
		
			61 lines
		
	
	
		
			2.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			61 lines
		
	
	
		
			2.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| Common properties
 | |
| 
 | |
| The Devicetree Specification does not define any properties related to hardware
 | |
| byteswapping, but endianness issues show up frequently in porting Linux to
 | |
| different machine types.  This document attempts to provide a consistent
 | |
| way of handling byteswapping across drivers.
 | |
| 
 | |
| Optional properties:
 | |
|  - big-endian: Boolean; force big endian register accesses
 | |
|    unconditionally (e.g. ioread32be/iowrite32be).  Use this if you
 | |
|    know the peripheral always needs to be accessed in BE mode.
 | |
|  - little-endian: Boolean; force little endian register accesses
 | |
|    unconditionally (e.g. readl/writel).  Use this if you know the
 | |
|    peripheral always needs to be accessed in LE mode.
 | |
|  - native-endian: Boolean; always use register accesses matched to the
 | |
|    endianness of the kernel binary (e.g. LE vmlinux -> readl/writel,
 | |
|    BE vmlinux -> ioread32be/iowrite32be).  In this case no byteswaps
 | |
|    will ever be performed.  Use this if the hardware "self-adjusts"
 | |
|    register endianness based on the CPU's configured endianness.
 | |
| 
 | |
| If a binding supports these properties, then the binding should also
 | |
| specify the default behavior if none of these properties are present.
 | |
| In such cases, little-endian is the preferred default, but it is not
 | |
| a requirement.  The of_device_is_big_endian() and of_fdt_is_big_endian()
 | |
| helper functions do assume that little-endian is the default, because
 | |
| most existing (PCI-based) drivers implicitly default to LE by using
 | |
| readl/writel for MMIO accesses.
 | |
| 
 | |
| Examples:
 | |
| Scenario 1 : CPU in LE mode & device in LE mode.
 | |
| dev: dev@40031000 {
 | |
| 	      compatible = "name";
 | |
| 	      reg = <0x40031000 0x1000>;
 | |
| 	      ...
 | |
| 	      native-endian;
 | |
| };
 | |
| 
 | |
| Scenario 2 : CPU in LE mode & device in BE mode.
 | |
| dev: dev@40031000 {
 | |
| 	      compatible = "name";
 | |
| 	      reg = <0x40031000 0x1000>;
 | |
| 	      ...
 | |
| 	      big-endian;
 | |
| };
 | |
| 
 | |
| Scenario 3 : CPU in BE mode & device in BE mode.
 | |
| dev: dev@40031000 {
 | |
| 	      compatible = "name";
 | |
| 	      reg = <0x40031000 0x1000>;
 | |
| 	      ...
 | |
| 	      native-endian;
 | |
| };
 | |
| 
 | |
| Scenario 4 : CPU in BE mode & device in LE mode.
 | |
| dev: dev@40031000 {
 | |
| 	      compatible = "name";
 | |
| 	      reg = <0x40031000 0x1000>;
 | |
| 	      ...
 | |
| 	      little-endian;
 | |
| };
 |