diff options
Diffstat (limited to 'Documentation')
251 files changed, 7099 insertions, 1158 deletions
diff --git a/Documentation/ABI/testing/sysfs-ata b/Documentation/ABI/testing/sysfs-ata index 0a932155cbba..aa4296498859 100644 --- a/Documentation/ABI/testing/sysfs-ata +++ b/Documentation/ABI/testing/sysfs-ata @@ -90,6 +90,17 @@ gscr 130: SATA_PMP_GSCR_SII_GPIO Only valid if the device is a PM. +trim + + Shows the DSM TRIM mode currently used by the device. Valid + values are: + unsupported: Drive does not support DSM TRIM + unqueued: Drive supports unqueued DSM TRIM only + queued: Drive supports queued DSM TRIM + forced_unqueued: Drive's queued DSM support is known to be + buggy and only unqueued TRIM commands + are sent + spdn_cnt Number of time libata decided to lower the speed of link due to errors. diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe index 21640eaad371..657df13b100d 100644 --- a/Documentation/ABI/testing/sysfs-bus-fcoe +++ b/Documentation/ABI/testing/sysfs-bus-fcoe @@ -32,7 +32,7 @@ Description: 'FCoE Controller' instances on the fcoe bus. Attributes: - fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing + fcf_dev_loss_tmo: Device loss timeout period (see below). Changing this value will change the dev_loss_tmo for all FCFs discovered by this controller. @@ -61,7 +61,7 @@ Attributes: lesb/err_block: Link Error Status Block (LESB) block error count. lesb/fcs_error: Link Error Status Block (LESB) Fibre Channel - Serivces error count. + Services error count. Notes: ctlr_X (global increment starting at 0) @@ -85,7 +85,7 @@ Attributes: fabric. selected: 1 indicates that the switch has been selected for use; - 0 indicates that the swich will not be used. + 0 indicates that the switch will not be used. fc_map: The Fibre Channel MAP @@ -93,7 +93,7 @@ Attributes: mac: The FCF's MAC address - fka_peroid: The FIP Keep-Alive peroid + fka_period: The FIP Keep-Alive period fabric_state: The internal kernel state "Unknown" - Initialization value @@ -101,9 +101,9 @@ Attributes: "Connected" - Host is connected to the FCF "Deleted" - FCF is being removed from the system - dev_loss_tmo: The device loss timeout peroid for this FCF. + dev_loss_tmo: The device loss timeout period for this FCF. -Notes: A device loss infrastructre similar to the FC Transport's +Notes: A device loss infrastructure similar to the FC Transport's is present in fcoe_sysfs. It is nice to have so that a link flapping adapter doesn't continually advance the count used to identify the discovered FCF. FCFs will exist in a diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio b/Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio new file mode 100644 index 000000000000..4d08f28dc871 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio @@ -0,0 +1,8 @@ +What: /sys/bus/pci/drivers/janz-cmodio/.../modulbus_number +Date: May 2010 +KernelVersion: 2.6.35 +Contact: Ira W. Snyder <ira.snyder@gmail.com> +Description: + Value representing the HEX switch S2 of the janz carrier board CMOD-IO or CAN-PCI2 + + Read-only: value of the configuration switch (0..15) diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl index d46bba801aac..acfe9df83139 100644 --- a/Documentation/ABI/testing/sysfs-class-cxl +++ b/Documentation/ABI/testing/sysfs-class-cxl @@ -6,6 +6,17 @@ Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is Slave contexts (eg. /sys/class/cxl/afu0.0s): +What: /sys/class/cxl/<afu>/afu_err_buf +Date: September 2014 +Contact: linuxppc-dev@lists.ozlabs.org +Description: read only + AFU Error Buffer contents. The contents of this file are + application specific and depends on the AFU being used. + Applications interacting with the AFU can use this attribute + to know about the current error condition and take appropriate + action like logging the event etc. + + What: /sys/class/cxl/<afu>/irqs_max Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org @@ -15,6 +26,7 @@ Description: read/write that hardware can support (eg. 2037). Write values will limit userspace applications to that many userspace interrupts. Must be >= irqs_min. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/irqs_min Date: September 2014 @@ -24,6 +36,7 @@ Description: read only userspace must request on a CXL_START_WORK ioctl. Userspace may omit the num_interrupts field in the START_WORK IOCTL to get this minimum automatically. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/mmio_size Date: September 2014 @@ -31,6 +44,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the size of the MMIO space that may be mmaped by userspace. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/modes_supported Date: September 2014 @@ -38,6 +52,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only List of the modes this AFU supports. One per line. Valid entries are: "dedicated_process" and "afu_directed" +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/mode Date: September 2014 @@ -46,6 +61,7 @@ Description: read/write The current mode the AFU is using. Will be one of the modes given in modes_supported. Writing will change the mode provided that no user contexts are attached. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/prefault_mode @@ -59,6 +75,7 @@ Description: read/write descriptor as an effective address and prefault what it points to. all: all segments process calling START_WORK maps. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/reset Date: September 2014 @@ -66,12 +83,14 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: write only Writing 1 here will reset the AFU provided there are not contexts active on the AFU. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/api_version Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the current version of the kernel/user API. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/api_version_compatible Date: September 2014 @@ -79,6 +98,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the the lowest version of the userspace API this this kernel supports. +Users: https://github.com/ibm-capi/libcxl AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0): @@ -92,6 +112,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Hexadecimal value of the vendor ID found in this AFU configuration record. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/cr<config num>/device Date: February 2015 @@ -99,6 +120,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Hexadecimal value of the device ID found in this AFU configuration record. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/cr<config num>/class Date: February 2015 @@ -106,6 +128,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Hexadecimal value of the class code found in this AFU configuration record. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/cr<config num>/config Date: February 2015 @@ -115,6 +138,7 @@ Description: read only record. The format is expected to match the either the standard or extended configuration space defined by the PCIe specification. +Users: https://github.com/ibm-capi/libcxl @@ -126,18 +150,21 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the size of the MMIO space that may be mmaped by userspace. This includes all slave contexts space also. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>m/pp_mmio_len Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the Per Process MMIO space length. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>m/pp_mmio_off Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the Per Process MMIO space offset. +Users: https://github.com/ibm-capi/libcxl Card info (eg. /sys/class/cxl/card0) @@ -147,12 +174,14 @@ Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Identifies the CAIA Version the card implements. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/psl_revision Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Identifies the revision level of the PSL. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/base_image Date: September 2014 @@ -162,6 +191,7 @@ Description: read only that support loadable PSLs. For FPGAs this field identifies the image contained in the on-adapter flash which is loaded during the initial program load. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/image_loaded Date: September 2014 @@ -169,6 +199,7 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: read only Will return "user" or "factory" depending on the image loaded onto the card. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/load_image_on_perst Date: December 2014 @@ -183,6 +214,7 @@ Description: read/write user or factory image to be loaded. Default is to reload on PERST whichever image the card has loaded. +Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/reset Date: October 2014 @@ -190,3 +222,4 @@ Contact: linuxppc-dev@lists.ozlabs.org Description: write only Writing 1 will issue a PERST to card which may cause the card to reload the FPGA depending on load_image_on_perst. +Users: https://github.com/ibm-capi/libcxl diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 5ecfd72ba684..668604fc8e06 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net @@ -39,6 +39,25 @@ Description: Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC address. +What: /sys/class/net/<bridge iface>/bridge/group_fwd_mask +Date: January 2012 +KernelVersion: 3.2 +Contact: netdev@vger.kernel.org +Description: + Bitmask to allow forwarding of link local frames with address + 01-80-C2-00-00-0X on a bridge device. Only values that set bits + not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h + allowed. + Default value 0 does not forward any link local frames. + + Restricted bits: + 0: 01-80-C2-00-00-00 Bridge Group Address used for STP + 1: 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE + 2: 01-80-C2-00-00-02 (Link Aggregation) 802.3ad + + Any values not setting these bits can be used. Take special + care when forwarding control frames e.g. 802.1X-PAE or LLDP. + What: /sys/class/net/<iface>/broadcast Date: April 2005 KernelVersion: 2.6.12 diff --git a/Documentation/ABI/testing/sysfs-class-net-janz-ican3 b/Documentation/ABI/testing/sysfs-class-net-janz-ican3 new file mode 100644 index 000000000000..fdbc03a2b8f8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-janz-ican3 @@ -0,0 +1,19 @@ +What: /sys/class/net/<iface>/termination +Date: May 2010 +KernelVersion: 2.6.35 +Contact: Ira W. Snyder <ira.snyder@gmail.com> +Description: + Value representing the can bus termination + + Default: 1 (termination active) + Reading: get actual termination state + Writing: set actual termination state (0=no termination, 1=termination active) + +What: /sys/class/net/<iface>/fwinfo +Date: May 2015 +KernelVersion: 3.19 +Contact: Andreas Gröger <andreas24groeger@gmail.com> +Description: + Firmware stamp of ican3 module + Read-only: 32 byte string identification of the ICAN3 module + (known values: "JANZ-ICAN3 ICANOS 1.xx", "JANZ-ICAN3 CAL/CANopen 1.xx") diff --git a/Documentation/ABI/testing/sysfs-class-scsi_tape b/Documentation/ABI/testing/sysfs-class-scsi_tape new file mode 100644 index 000000000000..9be398b87ee9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-scsi_tape @@ -0,0 +1,109 @@ +What: /sys/class/scsi_tape/*/stats/in_flight +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Show the number of I/Os currently in-flight between the st + module and the SCSI mid-layer. +Users: + + +What: /sys/class/scsi_tape/*/stats/io_ns +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total amount of time spent waiting for all I/O + to and from the tape drive to complete. This includes all + reads, writes, and other SCSI commands issued to the tape + drive. An example of other SCSI commands would be tape + movement such as a rewind when a rewind tape device is + closed. This item is measured in nanoseconds. + + To determine the amount of time spent waiting for other I/O + to complete subtract read_ns and write_ns from this value. +Users: + + +What: /sys/class/scsi_tape/*/stats/other_cnt +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + The number of I/O requests issued to the tape drive other + than SCSI read/write requests. +Users: + + +What: /sys/class/scsi_tape/*/stats/read_byte_cnt +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total number of bytes requested from the tape drive. + This value is presented in bytes because tape drives support + variable length block sizes. +Users: + + +What: /sys/class/scsi_tape/*/stats/read_cnt +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total number of read requests issued to the tape + drive. +Users: + + +What: /sys/class/scsi_tape/*/stats/read_ns +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total amount of time in nanoseconds waiting for + read I/O requests to complete. +Users: + + +What: /sys/class/scsi_tape/*/stats/write_byte_cnt +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total number of bytes written to the tape drive. + This value is presented in bytes because tape drives support + variable length block sizes. +Users: + + +What: /sys/class/scsi_tape/*/stats/write_cnt +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total number of write requests issued to the tape + drive. +Users: + + +What: /sys/class/scsi_tape/*/stats/write_ms +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the total amount of time in nanoseconds waiting for + write I/O requests to complete. +Users: + + +What: /sys/class/scsi_tape/*/stats/resid_cnt +Date: Apr 2015 +KernelVersion: 4.2 +Contact: Shane Seymour <shane.seymour@hp.com> +Description: + Shows the number of times we found that a residual >0 + was found when the SCSI midlayer indicated that there was + an error. For reads this may be a case of someone issuing + reads greater than the block size. +Users: diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff b/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff index b3f6a2ac5007..db197a879580 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff +++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff @@ -1,7 +1,7 @@ -What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range. +What: /sys/bus/hid/drivers/logitech/<dev>/range Date: July 2011 KernelVersion: 3.2 -Contact: Michal Malý <madcatxster@gmail.com> +Contact: Michal Malý <madcatxster@devoid-pointer.net> Description: Display minimum, maximum and current range of the steering wheel. Writing a value within min and max boundaries sets the range of the wheel. @@ -9,7 +9,7 @@ Description: Display minimum, maximum and current range of the steering What: /sys/bus/hid/drivers/logitech/<dev>/alternate_modes Date: Feb 2015 KernelVersion: 4.1 -Contact: Michal Malý <madcatxster@gmail.com> +Contact: Michal Malý <madcatxster@devoid-pointer.net> Description: Displays a set of alternate modes supported by a wheel. Each mode is listed as follows: Tag: Mode Name @@ -45,7 +45,7 @@ Description: Displays a set of alternate modes supported by a wheel. Each What: /sys/bus/hid/drivers/logitech/<dev>/real_id Date: Feb 2015 KernelVersion: 4.1 -Contact: Michal Malý <madcatxster@gmail.com> +Contact: Michal Malý <madcatxster@devoid-pointer.net> Description: Displays the real model of the wheel regardless of any alternate mode the wheel might be switched to. It is a read-only value. diff --git a/Documentation/ABI/testing/sysfs-firmware-efi b/Documentation/ABI/testing/sysfs-firmware-efi index 05874da7ce80..e794eac32a90 100644 --- a/Documentation/ABI/testing/sysfs-firmware-efi +++ b/Documentation/ABI/testing/sysfs-firmware-efi @@ -18,3 +18,13 @@ Contact: Dave Young <dyoung@redhat.com> Description: It shows the physical address of config table entry in the EFI system table. Users: Kexec + +What: /sys/firmware/efi/systab +Date: April 2005 +Contact: linux-efi@vger.kernel.org +Description: Displays the physical addresses of all EFI Configuration + Tables found via the EFI System Table. The order in + which the tables are printed forms an ABI and newer + versions are always printed first, i.e. ACPI20 comes + before ACPI. +Users: dmidecode diff --git a/Documentation/ABI/testing/sysfs-firmware-efi-esrt b/Documentation/ABI/testing/sysfs-firmware-efi-esrt new file mode 100644 index 000000000000..6e431d1a4e79 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-efi-esrt @@ -0,0 +1,81 @@ +What: /sys/firmware/efi/esrt/ +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: Provides userland access to read the EFI System Resource Table + (ESRT), a catalog of firmware for which can be updated with + the UEFI UpdateCapsule mechanism described in section 7.5 of + the UEFI Standard. +Users: fwupdate - https://github.com/rhinstaller/fwupdate + +What: /sys/firmware/efi/esrt/fw_resource_count +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The number of entries in the ESRT + +What: /sys/firmware/efi/esrt/fw_resource_count_max +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The maximum number of entries that /could/ be registered + in the allocation the table is currently in. This is + really only useful to the system firmware itself. + +What: /sys/firmware/efi/esrt/fw_resource_version +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The version of the ESRT structure provided by the firmware. + +What: /sys/firmware/efi/esrt/entries/entry$N/ +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: Each ESRT entry is identified by a GUID, and each gets a + subdirectory under entries/ . + example: /sys/firmware/efi/esrt/entries/entry0/ + +What: /sys/firmware/efi/esrt/entries/entry$N/fw_type +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: What kind of firmware entry this is: + 0 - Unknown + 1 - System Firmware + 2 - Device Firmware + 3 - UEFI Driver + +What: /sys/firmware/efi/esrt/entries/entry$N/fw_class +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: This is the entry's guid, and will match the directory name. + +What: /sys/firmware/efi/esrt/entries/entry$N/fw_version +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The version of the firmware currently installed. This is a + 32-bit unsigned integer. + +What: /sys/firmware/efi/esrt/entries/entry$N/lowest_supported_fw_version +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The lowest version of the firmware that can be installed. + +What: /sys/firmware/efi/esrt/entries/entry$N/capsule_flags +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: Flags that must be passed to UpdateCapsule() + +What: /sys/firmware/efi/esrt/entries/entry$N/last_attempt_version +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The last firmware version for which an update was attempted. + +What: /sys/firmware/efi/esrt/entries/entry$N/last_attempt_status +Date: February 2015 +Contact: Peter Jones <pjones@redhat.com> +Description: The result of the last firmware update attempt for the + firmware resource entry. + 0 - Success + 1 - Insufficient resources + 2 - Incorrect version + 3 - Invalid format + 4 - Authentication error + 5 - AC power event + 6 - Battery power event + diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index f4b78eafd92a..b713c35f8543 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -670,7 +670,7 @@ functions: typeof(x) ret; \ ret = calc_ret(x); \ (ret); \ -)} +}) ret is a common name for a local variable - __foo_ret is less likely to collide with an existing variable. diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 0f7afb2bb442..55b70b903ead 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -25,13 +25,18 @@ physical addresses. These are the addresses in /proc/iomem. The physical address is not directly useful to a driver; it must use ioremap() to map the space and produce a virtual address. -I/O devices use a third kind of address: a "bus address" or "DMA address". -If a device has registers at an MMIO address, or if it performs DMA to read -or write system memory, the addresses used by the device are bus addresses. -In some systems, bus addresses are identical to CPU physical addresses, but -in general they are not. IOMMUs and host bridges can produce arbitrary +I/O devices use a third kind of address: a "bus address". If a device has +registers at an MMIO address, or if it performs DMA to read or write system +memory, the addresses used by the device are bus addresses. In some +systems, bus addresses are identical to CPU physical addresses, but in +general they are not. IOMMUs and host bridges can produce arbitrary mappings between physical and bus addresses. +From a device's point of view, DMA uses the bus address space, but it may +be restricted to a subset of that space. For example, even if a system +supports 64-bit addresses for main memory and PCI BARs, it may use an IOMMU +so devices only need to use 32-bit DMA addresses. + Here's a picture and some examples: CPU CPU Bus @@ -72,11 +77,11 @@ can use virtual address X to access the buffer, but the device itself cannot because DMA doesn't go through the CPU virtual memory system. In some simple systems, the device can do DMA directly to physical address -Y. But in many others, there is IOMMU hardware that translates bus +Y. But in many others, there is IOMMU hardware that translates DMA addresses to physical addresses, e.g., it translates Z to Y. This is part of the reason for the DMA API: the driver can give a virtual address X to an interface like dma_map_single(), which sets up any required IOMMU -mapping and returns the bus address Z. The driver then tells the device to +mapping and returns the DMA address Z. The driver then tells the device to do DMA to Z, and the IOMMU maps it to the buffer at address Y in system RAM. @@ -98,7 +103,7 @@ First of all, you should make sure #include <linux/dma-mapping.h> is in your driver, which provides the definition of dma_addr_t. This type -can hold any valid DMA or bus address for the platform and should be used +can hold any valid DMA address for the platform and should be used everywhere you hold a DMA address returned from the DMA mapping functions. What memory is DMA'able? @@ -240,7 +245,7 @@ the case would look like this: if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { using_dac = 1; - consistent_using_dac = 1; + consistent_using_dac = 1; } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { using_dac = 0; consistent_using_dac = 0; @@ -316,7 +321,7 @@ There are two types of DMA mappings: Think of "consistent" as "synchronous" or "coherent". The current default is to return consistent memory in the low 32 - bits of the bus space. However, for future compatibility you should + bits of the DMA space. However, for future compatibility you should set the consistent mask even if this default is fine for your driver. @@ -353,7 +358,7 @@ There are two types of DMA mappings: transfer, unmapped right after it (unless you use dma_sync_* below) and for which hardware can optimize for sequential accesses. - This of "streaming" as "asynchronous" or "outside the coherency + Think of "streaming" as "asynchronous" or "outside the coherency domain". Good examples of what to use streaming mappings for are: @@ -403,7 +408,7 @@ dma_alloc_coherent() returns two values: the virtual address which you can use to access it from the CPU and dma_handle which you pass to the card. -The CPU virtual address and the DMA bus address are both +The CPU virtual address and the DMA address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk @@ -645,8 +650,8 @@ PLEASE NOTE: The 'nents' argument to the dma_unmap_sg call must be dma_map_sg call. Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}() -counterpart, because the bus address space is a shared resource and -you could render the machine unusable by consuming all bus addresses. +counterpart, because the DMA address space is a shared resource and +you could render the machine unusable by consuming all DMA addresses. If you need to use the same streaming DMA region multiple times and touch the data in between the DMA transfers, the buffer needs to be synced diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 52088408668a..7eba542eff7c 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -18,10 +18,10 @@ Part I - dma_ API To get the dma_ API, you must #include <linux/dma-mapping.h>. This provides dma_addr_t and the interfaces described below. -A dma_addr_t can hold any valid DMA or bus address for the platform. It -can be given to a device to use as a DMA source or target. A CPU cannot -reference a dma_addr_t directly because there may be translation between -its physical address space and the bus address space. +A dma_addr_t can hold any valid DMA address for the platform. It can be +given to a device to use as a DMA source or target. A CPU cannot reference +a dma_addr_t directly because there may be translation between its physical +address space and the DMA address space. Part Ia - Using large DMA-coherent buffers ------------------------------------------ @@ -42,7 +42,7 @@ It returns a pointer to the allocated region (in the processor's virtual address space) or NULL if the allocation failed. It also returns a <dma_handle> which may be cast to an unsigned integer the -same width as the bus and given to the device as the bus address base of +same width as the bus and given to the device as the DMA address base of the region. Note: consistent memory can be expensive on some platforms, and the @@ -193,7 +193,7 @@ dma_map_single(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction direction) Maps a piece of processor virtual memory so it can be accessed by the -device and returns the bus address of the memory. +device and returns the DMA address of the memory. The direction for both APIs may be converted freely by casting. However the dma_ API uses a strongly typed enumerator for its @@ -212,20 +212,20 @@ contiguous piece of memory. For this reason, memory to be mapped by this API should be obtained from sources which guarantee it to be physically contiguous (like kmalloc). -Further, the bus address of the memory must be within the +Further, the DMA address of the memory must be within the dma_mask of the device (the dma_mask is a bit mask of the -addressable region for the device, i.e., if the bus address of -the memory ANDed with the dma_mask is still equal to the bus +addressable region for the device, i.e., if the DMA address of +the memory ANDed with the dma_mask is still equal to the DMA address, then the device can perform DMA to the memory). To ensure that the memory allocated by kmalloc is within the dma_mask, the driver may specify various platform-dependent flags to restrict -the bus address range of the allocation (e.g., on x86, GFP_DMA -guarantees to be within the first 16MB of available bus addresses, +the DMA address range of the allocation (e.g., on x86, GFP_DMA +guarantees to be within the first 16MB of available DMA addresses, as required by ISA devices). Note also that the above constraints on physical contiguity and dma_mask may not apply if the platform has an IOMMU (a device which -maps an I/O bus address to a physical memory address). However, to be +maps an I/O DMA address to a physical memory address). However, to be portable, device driver writers may *not* assume that such an IOMMU exists. @@ -296,7 +296,7 @@ reduce current DMA mapping usage or delay and try again later). dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) -Returns: the number of bus address segments mapped (this may be shorter +Returns: the number of DMA address segments mapped (this may be shorter than <nents> passed in if some elements of the scatter/gather list are physically or virtually adjacent and an IOMMU maps them with a single entry). @@ -340,7 +340,7 @@ must be the same as those and passed in to the scatter/gather mapping API. Note: <nents> must be the number you passed in, *not* the number of -bus address entries returned. +DMA address entries returned. void dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, @@ -507,7 +507,7 @@ it's asked for coherent memory for this device. phys_addr is the CPU physical address to which the memory is currently assigned (this will be ioremapped so the CPU can access the region). -device_addr is the bus address the device needs to be programmed +device_addr is the DMA address the device needs to be programmed with to actually address this memory (this will be handed out as the dma_addr_t in dma_alloc_coherent()). diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl index efc8d90a9a3f..0992531ffefb 100644 --- a/Documentation/DocBook/crypto-API.tmpl +++ b/Documentation/DocBook/crypto-API.tmpl @@ -119,7 +119,7 @@ <para> Note: The terms "transformation" and cipher algorithm are used - interchangably. + interchangeably. </para> </sect1> @@ -536,8 +536,8 @@ <para> For other use cases of AEAD ciphers, the ASCII art applies as - well, but the caller may not use the GIVCIPHER interface. In - this case, the caller must generate the IV. + well, but the caller may not use the AEAD cipher with a separate + IV generator. In this case, the caller must generate the IV. </para> <para> @@ -584,8 +584,8 @@ kernel crypto API | IPSEC Layer | +-----------+ | | | (1) -| givcipher | <----------------------------------- esp_output -| (seqiv) | ---+ +| aead | <----------------------------------- esp_output +| (seqniv) | ---+ +-----------+ | | (2) +-----------+ | @@ -620,8 +620,8 @@ kernel crypto API | IPSEC Layer <orderedlist> <listitem> <para> - esp_output() invokes crypto_aead_givencrypt() to trigger an encryption - operation of the GIVCIPHER implementation. + esp_output() invokes crypto_aead_encrypt() to trigger an encryption + operation of the AEAD cipher with IV generator. </para> <para> @@ -1563,7 +1563,7 @@ struct sockaddr_alg sa = { <sect1><title>Zero-Copy Interface</title> <para> - In addition to the send/write/read/recv system call familty, the AF_ALG + In addition to the send/write/read/recv system call family, the AF_ALG interface can be accessed with the zero-copy interface of splice/vmsplice. As the name indicates, the kernel tries to avoid a copy operation into kernel space. @@ -1669,9 +1669,19 @@ read(opfd, out, outlen); </chapter> <chapter id="API"><title>Programming Interface</title> + <para> + Please note that the kernel crypto API contains the AEAD givcrypt + API (crypto_aead_giv* and aead_givcrypt_* function calls in + include/crypto/aead.h). This API is obsolete and will be removed + in the future. To obtain the functionality of an AEAD cipher with + internal IV generation, use the IV generator as a regular cipher. + For example, rfc4106(gcm(aes)) is the AEAD cipher with external + IV generation and seqniv(rfc4106(gcm(aes))) implies that the kernel + crypto API generates the IV. Different IV generators are available. + </para> <sect1><title>Block Cipher Context Data Structures</title> !Pinclude/linux/crypto.h Block Cipher Context Data Structures -!Finclude/linux/crypto.h aead_request +!Finclude/crypto/aead.h aead_request </sect1> <sect1><title>Block Cipher Algorithm Definitions</title> !Pinclude/linux/crypto.h Block Cipher Algorithm Definitions @@ -1680,7 +1690,7 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h aead_alg !Finclude/linux/crypto.h blkcipher_alg !Finclude/linux/crypto.h cipher_alg -!Finclude/linux/crypto.h rng_alg +!Finclude/crypto/rng.h rng_alg </sect1> <sect1><title>Asynchronous Block Cipher API</title> !Pinclude/linux/crypto.h Asynchronous Block Cipher API @@ -1704,26 +1714,27 @@ read(opfd, out, outlen); !Finclude/linux/crypto.h ablkcipher_request_set_crypt </sect1> <sect1><title>Authenticated Encryption With Associated Data (AEAD) Cipher API</title> -!Pinclude/linux/crypto.h Authenticated Encryption With Associated Data (AEAD) Cipher API -!Finclude/linux/crypto.h crypto_alloc_aead -!Finclude/linux/crypto.h crypto_free_aead -!Finclude/linux/crypto.h crypto_aead_ivsize -!Finclude/linux/crypto.h crypto_aead_authsize -!Finclude/linux/crypto.h crypto_aead_blocksize -!Finclude/linux/crypto.h crypto_aead_setkey -!Finclude/linux/crypto.h crypto_aead_setauthsize -!Finclude/linux/crypto.h crypto_aead_encrypt -!Finclude/linux/crypto.h crypto_aead_decrypt +!Pinclude/crypto/aead.h Authenticated Encryption With Associated Data (AEAD) Cipher API +!Finclude/crypto/aead.h crypto_alloc_aead +!Finclude/crypto/aead.h crypto_free_aead +!Finclude/crypto/aead.h crypto_aead_ivsize +!Finclude/crypto/aead.h crypto_aead_authsize +!Finclude/crypto/aead.h crypto_aead_blocksize +!Finclude/crypto/aead.h crypto_aead_setkey +!Finclude/crypto/aead.h crypto_aead_setauthsize +!Finclude/crypto/aead.h crypto_aead_encrypt +!Finclude/crypto/aead.h crypto_aead_decrypt </sect1> <sect1><title>Asynchronous AEAD Request Handle</title> -!Pinclude/linux/crypto.h Asynchronous AEAD Request Handle -!Finclude/linux/crypto.h crypto_aead_reqsize -!Finclude/linux/crypto.h aead_request_set_tfm -!Finclude/linux/crypto.h aead_request_alloc -!Finclude/linux/crypto.h aead_request_free -!Finclude/linux/crypto.h aead_request_set_callback -!Finclude/linux/crypto.h aead_request_set_crypt -!Finclude/linux/crypto.h aead_request_set_assoc +!Pinclude/crypto/aead.h Asynchronous AEAD Request Handle +!Finclude/crypto/aead.h crypto_aead_reqsize +!Finclude/crypto/aead.h aead_request_set_tfm +!Finclude/crypto/aead.h aead_request_alloc +!Finclude/crypto/aead.h aead_request_free +!Finclude/crypto/aead.h aead_request_set_callback +!Finclude/crypto/aead.h aead_request_set_crypt +!Finclude/crypto/aead.h aead_request_set_assoc +!Finclude/crypto/aead.h aead_request_set_ad </sect1> <sect1><title>Synchronous Block Cipher API</title> !Pinclude/linux/crypto.h Synchronous Block Cipher API diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index e84f09467cd7..589b40cc5eb5 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -954,6 +954,8 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <function>MODULE_LICENSE()</function> that specifies a GPL compatible license. It implies that the function is considered an internal implementation issue, and not really an interface. + Some maintainers and developers may however + require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality. </para> </sect1> </chapter> diff --git a/Documentation/DocBook/scsi.tmpl b/Documentation/DocBook/scsi.tmpl index 324b53494f08..4b9b9b286cea 100644 --- a/Documentation/DocBook/scsi.tmpl +++ b/Documentation/DocBook/scsi.tmpl @@ -81,7 +81,7 @@ SAS, Fibre Channel, FireWire, and ATAPI devices. SCSI packets are also commonly exchanged over Infiniband, <ulink url='http://i2o.shadowconnect.com/faq.php'>I20</ulink>, TCP/IP - (<ulink url='http://en.wikipedia.org/wiki/ISCSI'>iSCSI</ulink>), even + (<ulink url='https://en.wikipedia.org/wiki/ISCSI'>iSCSI</ulink>), even <ulink url='http://cyberelk.net/tim/parport/parscsi.html'>Parallel ports</ulink>. </para> diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index f29bcbc463e7..370ca006db7a 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -1496,7 +1496,7 @@ Canis Rufus and Zoicon5 and Anome and Hal Eisen" ,month="July" ,day="8" ,year="2006" -,note="\url{http://en.wikipedia.org/wiki/Read-copy-update}" +,note="\url{https://en.wikipedia.org/wiki/Read-copy-update}" ,annotation={ Wikipedia RCU page as of July 8 2006. [Viewed August 21, 2006] diff --git a/Documentation/RCU/arrayRCU.txt b/Documentation/RCU/arrayRCU.txt index 453ebe6953ee..f05a9afb2c39 100644 --- a/Documentation/RCU/arrayRCU.txt +++ b/Documentation/RCU/arrayRCU.txt @@ -10,7 +10,19 @@ also be used to protect arrays. Three situations are as follows: 3. Resizeable Arrays -Each of these situations are discussed below. +Each of these three situations involves an RCU-protected pointer to an +array that is separately indexed. It might be tempting to consider use +of RCU to instead protect the index into an array, however, this use +case is -not- supported. The problem with RCU-protected indexes into +arrays is that compilers can play way too many optimization games with +integers, which means that the rules governing handling of these indexes +are far more trouble than they are worth. If RCU-protected indexes into +arrays prove to be particularly valuable (which they have not thus far), +explicit cooperation from the compiler will be required to permit them +to be safely used. + +That aside, each of the three RCU-protected pointer situations are +described in the following sections. Situation 1: Hash Tables @@ -36,9 +48,9 @@ Quick Quiz: Why is it so important that updates be rare when Situation 3: Resizeable Arrays Use of RCU for resizeable arrays is demonstrated by the grow_ary() -function used by the System V IPC code. The array is used to map from -semaphore, message-queue, and shared-memory IDs to the data structure -that represents the corresponding IPC construct. The grow_ary() +function formerly used by the System V IPC code. The array is used +to map from semaphore, message-queue, and shared-memory IDs to the data +structure that represents the corresponding IPC construct. The grow_ary() function does not acquire any locks; instead its caller must hold the ids->sem semaphore. diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt index cd83d2348fef..da51d3068850 100644 --- a/Documentation/RCU/lockdep.txt +++ b/Documentation/RCU/lockdep.txt @@ -47,11 +47,6 @@ checking of rcu_dereference() primitives: Use explicit check expression "c" along with srcu_read_lock_held()(). This is useful in code that is invoked by both SRCU readers and updaters. - rcu_dereference_index_check(p, c): - Use explicit check expression "c", but the caller - must supply one of the rcu_read_lock_held() functions. - This is useful in code that uses RCU-protected arrays - that is invoked by both RCU readers and updaters. rcu_dereference_raw(p): Don't check. (Use sparingly, if at all.) rcu_dereference_protected(p, c): @@ -64,11 +59,6 @@ checking of rcu_dereference() primitives: but retain the compiler constraints that prevent duplicating or coalescsing. This is useful when when testing the value of the pointer itself, for example, against NULL. - rcu_access_index(idx): - Return the value of the index and omit all barriers, but - retain the compiler constraints that prevent duplicating - or coalescsing. This is useful when when testing the - value of the index itself, for example, against -1. The rcu_dereference_check() check expression can be any boolean expression, but would normally include a lockdep expression. However, diff --git a/Documentation/RCU/rcu_dereference.txt b/Documentation/RCU/rcu_dereference.txt index ceb05da5a5ac..1e6c0da994f5 100644 --- a/Documentation/RCU/rcu_dereference.txt +++ b/Documentation/RCU/rcu_dereference.txt @@ -25,17 +25,6 @@ o You must use one of the rcu_dereference() family of primitives for an example where the compiler can in fact deduce the exact value of the pointer, and thus cause misordering. -o Do not use single-element RCU-protected arrays. The compiler - is within its right to assume that the value of an index into - such an array must necessarily evaluate to zero. The compiler - could then substitute the constant zero for the computation, so - that the array index no longer depended on the value returned - by rcu_dereference(). If the array index no longer depends - on rcu_dereference(), then both the compiler and the CPU - are within their rights to order the array access before the - rcu_dereference(), which can cause the array access to return - garbage. - o Avoid cancellation when using the "+" and "-" infix arithmetic operators. For example, for a given variable "x", avoid "(x-x)". There are similar arithmetic pitfalls from other @@ -76,14 +65,15 @@ o Do not use the results from the boolean "&&" and "||" when dereferencing. For example, the following (rather improbable) code is buggy: - int a[2]; - int index; - int force_zero_index = 1; + int *p; + int *q; ... - r1 = rcu_dereference(i1) - r2 = a[r1 && force_zero_index]; /* BUGGY!!! */ + p = rcu_dereference(gp) + q = &global_q; + q += p != &oom_p1 && p != &oom_p2; + r1 = *q; /* BUGGY!!! */ The reason this is buggy is that "&&" and "||" are often compiled using branches. While weak-memory machines such as ARM or PowerPC @@ -94,14 +84,15 @@ o Do not use the results from relational operators ("==", "!=", ">", ">=", "<", or "<=") when dereferencing. For example, the following (quite strange) code is buggy: - int a[2]; - int index; - int flip_index = 0; + int *p; + int *q; ... - r1 = rcu_dereference(i1) - r2 = a[r1 != flip_index]; /* BUGGY!!! */ + p = rcu_dereference(gp) + q = &global_q; + q += p > &oom_p; + r1 = *q; /* BUGGY!!! */ As before, the reason this is buggy is that relational operators are often compiled using branches. And as before, although @@ -193,6 +184,11 @@ o Be very careful about comparing pointers obtained from pointer. Note that the volatile cast in rcu_dereference() will normally prevent the compiler from knowing too much. + However, please note that if the compiler knows that the + pointer takes on only one of two values, a not-equal + comparison will provide exactly the information that the + compiler needs to deduce the value of the pointer. + o Disable any value-speculation optimizations that your compiler might provide, especially if you are making use of feedback-based optimizations that take data collected from prior runs. Such diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 88dfce182f66..5746b0c77f3e 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -256,7 +256,9 @@ rcu_dereference() If you are going to be fetching multiple fields from the RCU-protected structure, using the local variable is of course preferred. Repeated rcu_dereference() calls look - ugly and incur unnecessary overhead on Alpha CPUs. + ugly, do not guarantee that the same pointer will be returned + if an update happened while in the critical section, and incur + unnecessary overhead on Alpha CPUs. Note that the value returned by rcu_dereference() is valid only within the enclosing RCU read-side critical section. @@ -879,9 +881,7 @@ SRCU: Initialization/cleanup All: lockdep-checked RCU-protected pointer access - rcu_access_index rcu_access_pointer - rcu_dereference_index_check rcu_dereference_raw rcu_lockdep_assert rcu_sleep_check diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index b03a832a08e2..27e7e5edeca8 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -299,7 +299,9 @@ toward the stable maintainers by putting a line like this: Cc: stable@vger.kernel.org -into your patch. +into the sign-off area of your patch (note, NOT an email recipient). You +should also read Documentation/stable_kernel_rules.txt in addition to this +file. Note, however, that some subsystem maintainers want to come to their own conclusions on which patches should go to the stable trees. The networking diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index 15dfce708ebf..b731b292e812 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -42,7 +42,7 @@ Adding ACPI support for an existing driver should be pretty straightforward. Here is the simplest example: #ifdef CONFIG_ACPI - static struct acpi_device_id mydrv_acpi_match[] = { + static const struct acpi_device_id mydrv_acpi_match[] = { /* ACPI IDs here */ { } }; @@ -166,7 +166,7 @@ the platform device drivers. Below is an example where we add ACPI support to at25 SPI eeprom driver (this is meant for the above ACPI snippet): #ifdef CONFIG_ACPI - static struct acpi_device_id at25_acpi_match[] = { + static const struct acpi_device_id at25_acpi_match[] = { { "AT25", 0 }, { }, }; @@ -230,7 +230,7 @@ Below is an example of how to add ACPI support to the existing mpu3050 input driver: #ifdef CONFIG_ACPI - static struct acpi_device_id mpu3050_acpi_match[] = { + static const struct acpi_device_id mpu3050_acpi_match[] = { { "MPU3050", 0 }, { }, }; @@ -359,3 +359,54 @@ the id should be set like: The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under the MFD device and if found, that ACPI companion device is bound to the resulting child platform device. + +Device Tree namespace link device ID +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The Device Tree protocol uses device indentification based on the "compatible" +property whose value is a string or an array of strings recognized as device +identifiers by drivers and the driver core. The set of all those strings may be +regarded as a device indentification namespace analogous to the ACPI/PNP device +ID namespace. Consequently, in principle it should not be necessary to allocate +a new (and arguably redundant) ACPI/PNP device ID for a devices with an existing +identification string in the Device Tree (DT) namespace, especially if that ID +is only needed to indicate that a given device is compatible with another one, +presumably having a matching driver in the kernel already. + +In ACPI, the device identification object called _CID (Compatible ID) is used to +list the IDs of devices the given one is compatible with, but those IDs must +belong to one of the namespaces prescribed by the ACPI specification (see +Section 6.1.2 of ACPI 6.0 for details) and the DT namespace is not one of them. +Moreover, the specification mandates that either a _HID or an _ADR identificaion +object be present for all ACPI objects representing devices (Section 6.1 of ACPI +6.0). For non-enumerable bus types that object must be _HID and its value must +be a device ID from one of the namespaces prescribed by the specification too. + +The special DT namespace link device ID, PRP0001, provides a means to use the +existing DT-compatible device identification in ACPI and to satisfy the above +requirements following from the ACPI specification at the same time. Namely, +if PRP0001 is returned by _HID, the ACPI subsystem will look for the +"compatible" property in the device object's _DSD and will use the value of that +property to identify the corresponding device in analogy with the original DT +device identification algorithm. If the "compatible" property is not present +or its value is not valid, the device will not be enumerated by the ACPI +subsystem. Otherwise, it will be enumerated automatically as a platform device +(except when an I2C or SPI link from the device to its parent is present, in +which case the ACPI core will leave the device enumeration to the parent's +driver) and the identification strings from the "compatible" property value will +be used to find a driver for the device along with the device IDs listed by _CID +(if present). + +Analogously, if PRP0001 is present in the list of device IDs returned by _CID, +the identification strings listed by the "compatible" property value (if present +and valid) will be used to look for a driver matching the device, but in that +case their relative priority with respect to the other device IDs listed by +_HID and _CID depends on the position of PRP0001 in the _CID return package. +Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID +return package will be checked first. Also in that case the bus type the device +will be enumerated to depends on the device ID returned by _HID. + +It is valid to define device objects with a _HID returning PRP0001 and without +the "compatible" property in the _DSD or a _CID as long as one of their +ancestors provides a _DSD with a valid "compatible" property. Such device +objects are then simply regarded as additional "blocks" providing hierarchical +configuration information to the driver of the composite ancestor device. diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt new file mode 100644 index 000000000000..b96ead9a6919 --- /dev/null +++ b/Documentation/arm/Samsung/Bootloader-interface.txt @@ -0,0 +1,53 @@ + Interface between kernel and boot loaders on Exynos boards + ========================================================== + +Author: Krzysztof Kozlowski +Date : 6 June 2015 + +The document tries to describe currently used interface between Linux kernel +and boot loaders on Samsung Exynos based boards. This is not a definition +of interface but rather a description of existing state, a reference +for information purpose only. + +In the document "boot loader" means any of following: U-boot, proprietary +SBOOT or any other firmware for ARMv7 and ARMv8 initializing the board before +executing kernel. + + +1. Non-Secure mode +Address: sysram_ns_base_addr +Offset Value Purpose +============================================================================= +0x08 exynos_cpu_resume_ns System suspend +0x0c 0x00000bad (Magic cookie) System suspend +0x1c exynos4_secondary_startup Secondary CPU boot +0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot +0x20 0xfcba0d10 (Magic cookie) AFTR +0x24 exynos_cpu_resume_ns AFTR +0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR + + +2. Secure mode +Address: sysram_base_addr +Offset Value Purpose +============================================================================= +0x00 exynos4_secondary_startup Secondary CPU boot +0x04 exynos4_secondary_startup (Exynos542x) Secondary CPU boot +4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot +0x20 exynos_cpu_resume (Exynos4210 r1.0) AFTR +0x24 0xfcba0d10 (Magic cookie, Exynos4210 r1.0) AFTR + +Address: pmu_base_addr +Offset Value Purpose +============================================================================= +0x0800 exynos_cpu_resume AFTR +0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot +0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR +0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR + + +3. Other (regardless of secure/non-secure mode) +Address: pmu_base_addr +Offset Value Purpose +============================================================================= +0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator diff --git a/Documentation/arm/vlocks.txt b/Documentation/arm/vlocks.txt index 415960a9bab0..45731672c564 100644 --- a/Documentation/arm/vlocks.txt +++ b/Documentation/arm/vlocks.txt @@ -206,6 +206,6 @@ References [1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming Problem", Communications of the ACM 17, 8 (August 1974), 453-455. - http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm + https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm [2] linux/arch/arm/common/vlock.S, www.kernel.org. diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index f3c05b5f9f08..1690350f16e7 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -45,11 +45,13 @@ sees fit.) Requirement: MANDATORY -The device tree blob (dtb) must be placed on an 8-byte boundary within -the first 512 megabytes from the start of the kernel image and must not -cross a 2-megabyte boundary. This is to allow the kernel to map the -blob using a single section mapping in the initial page tables. +The device tree blob (dtb) must be placed on an 8-byte boundary and must +not exceed 2 megabytes in size. Since the dtb will be mapped cacheable +using blocks of up to 2 megabytes in size, it must not be placed within +any 2M region which must be mapped with any specific attributes. +NOTE: versions prior to v4.2 also require that the DTB be placed within +the 512 MB region starting at text_offset bytes below the kernel Image. 3. Decompress the kernel image ------------------------------ diff --git a/Documentation/blackfin/gptimers-example.c b/Documentation/blackfin/gptimers-example.c index b1bd6340e748..283eba993d9d 100644 --- a/Documentation/blackfin/gptimers-example.c +++ b/Documentation/blackfin/gptimers-example.c @@ -17,6 +17,12 @@ #define DRIVER_NAME "gptimer_example" +#ifdef IRQ_TIMER5 +#define SAMPLE_IRQ_TIMER IRQ_TIMER5 +#else +#define SAMPLE_IRQ_TIMER IRQ_TIMER2 +#endif + struct gptimer_data { uint32_t period, width; }; @@ -57,7 +63,8 @@ static int __init gptimer_example_init(void) } /* grab the IRQ for the timer */ - ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED, DRIVER_NAME, &data); + ret = request_irq(SAMPLE_IRQ_TIMER, gptimer_example_irq, + IRQF_SHARED, DRIVER_NAME, &data); if (ret) { printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n"); peripheral_free(P_TMR5); @@ -65,7 +72,8 @@ static int __init gptimer_example_init(void) } /* setup the timer and enable it */ - set_gptimer_config(TIMER5_id, WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA); + set_gptimer_config(TIMER5_id, + WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA); enable_gptimers(TIMER5bit); return 0; @@ -75,7 +83,7 @@ module_init(gptimer_example_init); static void __exit gptimer_example_exit(void) { disable_gptimers(TIMER5bit); - free_irq(IRQ_TIMER5, &data); + free_irq(SAMPLE_IRQ_TIMER, &data); peripheral_free(P_TMR5); } module_exit(gptimer_example_exit); diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index cd556b914786..68b6a6a470b0 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -387,8 +387,81 @@ groups and put applications in that group which are not driving enough IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle on individual groups and throughput should improve. -What works -========== -- Currently only sync IO queues are support. All the buffered writes are - still system wide and not per group. Hence we will not see service - differentiation between buffered writes between groups. +Writeback +========= + +Page cache is dirtied through buffered writes and shared mmaps and +written asynchronously to the backing filesystem by the writeback +mechanism. Writeback sits between the memory and IO domains and +regulates the proportion of dirty memory by balancing dirtying and +write IOs. + +On traditional cgroup hierarchies, relationships between different +controllers cannot be established making it impossible for writeback +to operate accounting for cgroup resource restrictions and all +writeback IOs are attributed to the root cgroup. + +If both the blkio and memory controllers are used on the v2 hierarchy +and the filesystem supports cgroup writeback, writeback operations +correctly follow the resource restrictions imposed by both memory and +blkio controllers. + +Writeback examines both system-wide and per-cgroup dirty memory status +and enforces the more restrictive of the two. Also, writeback control +parameters which are absolute values - vm.dirty_bytes and +vm.dirty_background_bytes - are distributed across cgroups according +to their current writeback bandwidth. + +There's a peculiarity stemming from the discrepancy in ownership +granularity between memory controller and writeback. While memory +controller tracks ownership per page, writeback operates on inode +basis. cgroup writeback bridges the gap by tracking ownership by +inode but migrating ownership if too many foreign pages, pages which +don't match the current inode ownership, have been encountered while +writing back the inode. + +This is a conscious design choice as writeback operations are +inherently tied to inodes making strictly following page ownership +complicated and inefficient. The only use case which suffers from +this compromise is multiple cgroups concurrently dirtying disjoint +regions of the same inode, which is an unlikely use case and decided +to be unsupported. Note that as memory controller assigns page +ownership on the first use and doesn't update it until the page is +released, even if cgroup writeback strictly follows page ownership, +multiple cgroups dirtying overlapping areas wouldn't work as expected. +In general, write-sharing an inode across multiple cgroups is not well +supported. + +Filesystem support for cgroup writeback +--------------------------------------- + +A filesystem can make writeback IOs cgroup-aware by updating +address_space_operations->writepage[s]() to annotate bio's using the +following two functions. + +* wbc_init_bio(@wbc, @bio) + + Should be called for each bio carrying writeback data and associates + the bio with the inode's owner cgroup. Can be called anytime + between bio allocation and submission. + +* wbc_account_io(@wbc, @page, @bytes) + + Should be called for each data segment being written out. While + this function doesn't care exactly when it's called during the + writeback session, it's the easiest and most natural to call it as + data segments are added to a bio. + +With writeback bio's annotated, cgroup support can be enabled per +super_block by setting MS_CGROUPWB in ->s_flags. This allows for +selective disabling of cgroup writeback support which is helpful when +certain filesystem features, e.g. journaled data mode, are +incompatible. + +wbc_init_bio() binds the specified bio to its cgroup. Depending on +the configuration, the bio may be executed at a lower priority and if +the writeback session is holding shared resources, e.g. a journal +entry, may lead to priority inversion. There is no one easy solution +for the problem. Filesystems can try to work around specific problem +cases by skipping wbc_init_bio() or using bio_associate_blkcg() +directly. diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index f456b4315e86..ff71e16cc752 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -493,6 +493,7 @@ pgpgin - # of charging events to the memory cgroup. The charging pgpgout - # of uncharging events to the memory cgroup. The uncharging event happens each time a page is unaccounted from the cgroup. swap - # of bytes of swap usage +dirty - # of bytes that are waiting to get written back to the disk. writeback - # of bytes of file/anon cache that are queued for syncing to disk. inactive_anon - # of bytes of anonymous and swap cache memory on inactive diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index 77ec21574fb1..c15aa75f5227 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -36,7 +36,7 @@ Contents: 1. What Is A CPUFreq Governor? ============================== -Most cpufreq drivers (in fact, all except one, longrun) or even most +Most cpufreq drivers (except the intel_pstate and longrun) or even most cpu frequency scaling algorithms only offer the CPU to be set to one frequency. In order to offer dynamic frequency scaling, the cpufreq core must be able to tell these drivers of a "target frequency". So diff --git a/Documentation/cpu-freq/intel-pstate.txt b/Documentation/cpu-freq/intel-pstate.txt index 655750743fb0..be8d4006bf76 100644 --- a/Documentation/cpu-freq/intel-pstate.txt +++ b/Documentation/cpu-freq/intel-pstate.txt @@ -3,24 +3,25 @@ Intel P-state driver This driver provides an interface to control the P state selection for SandyBridge+ Intel processors. The driver can operate two different -modes based on the processor model legacy and Hardware P state (HWP) +modes based on the processor model, legacy mode and Hardware P state (HWP) mode. -In legacy mode the driver implements a scaling driver with an internal -governor for Intel Core processors. The driver follows the same model -as the Transmeta scaling driver (longrun.c) and implements the -setpolicy() instead of target(). Scaling drivers that implement -setpolicy() are assumed to implement internal governors by the cpufreq -core. All the logic for selecting the current P state is contained -within the driver; no external governor is used by the cpufreq core. +In legacy mode, the Intel P-state implements two internal governors, +performance and powersave, that differ from the general cpufreq governors of +the same name (the general cpufreq governors implement target(), whereas the +internal Intel P-state governors implement setpolicy()). The internal +performance governor sets the max_perf_pct and min_perf_pct to 100; that is, +the governor selects the highest available P state to maximize the performance +of the core. The internal powersave governor selects the appropriate P state +based on the current load on the CPU. In HWP mode P state selection is implemented in the processor itself. The driver provides the interfaces between the cpufreq core and the processor to control P state selection based on user preferences and reporting frequency to the cpufreq core. In this mode the -internal governor code is disabled. +internal Intel P-state governor code is disabled. -In addtion to the interfaces provided by the cpufreq core for +In addition to the interfaces provided by the cpufreq core for controlling frequency the driver provides sysfs files for controlling P state selection. These files have been added to /sys/devices/system/cpu/intel_pstate/ diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt index ff2f28332cc4..109e97bbab77 100644 --- a/Documentation/cpu-freq/user-guide.txt +++ b/Documentation/cpu-freq/user-guide.txt @@ -196,8 +196,6 @@ affected_cpus : List of Online CPUs that require software related_cpus : List of Online + Offline CPUs that need software coordination of frequency. -scaling_driver : Hardware driver for cpufreq. - scaling_cur_freq : Current frequency of the CPU as determined by the governor and cpufreq core, in KHz. This is the frequency the kernel thinks the CPU runs diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 0aad6deb2d96..12b1b25b4da9 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -1,6 +1,6 @@ Export CPU topology info via sysfs. Items (attributes) are similar -to /proc/cpuinfo. +to /proc/cpuinfo output of some architectures: 1) /sys/devices/system/cpu/cpuX/topology/physical_package_id: @@ -23,20 +23,35 @@ to /proc/cpuinfo. 4) /sys/devices/system/cpu/cpuX/topology/thread_siblings: internal kernel map of cpuX's hardware threads within the same - core as cpuX + core as cpuX. -5) /sys/devices/system/cpu/cpuX/topology/core_siblings: +5) /sys/devices/system/cpu/cpuX/topology/thread_siblings_list: + + human-readable list of cpuX's hardware threads within the same + core as cpuX. + +6) /sys/devices/system/cpu/cpuX/topology/core_siblings: internal kernel map of cpuX's hardware threads within the same physical_package_id. -6) /sys/devices/system/cpu/cpuX/topology/book_siblings: +7) /sys/devices/system/cpu/cpuX/topology/core_siblings_list: + + human-readable list of cpuX's hardware threads within the same + physical_package_id. + +8) /sys/devices/system/cpu/cpuX/topology/book_siblings: internal kernel map of cpuX's hardware threads within the same book_id. +9) /sys/devices/system/cpu/cpuX/topology/book_siblings_list: + + human-readable list of cpuX's hardware threads within the same + book_id. + To implement it in an architecture-neutral way, a new source file, -drivers/base/topology.c, is to export the 4 or 6 attributes. The two book +drivers/base/topology.c, is to export the 6 or 9 attributes. The three book related sysfs files will only be created if CONFIG_SCHED_BOOK is selected. For an architecture to support this feature, it must define some of @@ -44,20 +59,22 @@ these macros in include/asm-XXX/topology.h: #define topology_physical_package_id(cpu) #define topology_core_id(cpu) #define topology_book_id(cpu) -#define topology_thread_cpumask(cpu) +#define topology_sibling_cpumask(cpu) #define topology_core_cpumask(cpu) #define topology_book_cpumask(cpu) -The type of **_id is int. -The type of siblings is (const) struct cpumask *. +The type of **_id macros is int. +The type of **_cpumask macros is (const) struct cpumask *. The latter +correspond with appropriate **_siblings sysfs attributes (except for +topology_sibling_cpumask() which corresponds with thread_siblings). To be consistent on all architectures, include/linux/topology.h provides default definitions for any of the above macros that are not defined by include/asm-XXX/topology.h: 1) physical_package_id: -1 2) core_id: 0 -3) thread_siblings: just the given CPU -4) core_siblings: just the given CPU +3) sibling_cpumask: just the given CPU +4) core_cpumask: just the given CPU For architectures that don't support books (CONFIG_SCHED_BOOK) there are no default definitions for topology_book_id() and topology_book_cpumask(). diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index 5c9a567b3fac..03703afc4d30 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -181,4 +181,4 @@ Notes Documentation and specifications: http://halobates.de/firewire/ FireWire is a trademark of Apple Inc. - for more information please refer to: -http://en.wikipedia.org/wiki/FireWire +https://en.wikipedia.org/wiki/FireWire diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt index 0d124a971801..d9246a32e673 100644 --- a/Documentation/device-mapper/cache-policies.txt +++ b/Documentation/device-mapper/cache-policies.txt @@ -25,10 +25,10 @@ trying to see when the io scheduler has let the ios run. Overview of supplied cache replacement policies =============================================== -multiqueue ----------- +multiqueue (mq) +--------------- -This policy is the default. +This policy has been deprecated in favor of the smq policy (see below). The multiqueue policy has three sets of 16 queues: one set for entries waiting for the cache and another two for those in the cache (a set for @@ -73,6 +73,67 @@ If you're trying to quickly warm a new cache device you may wish to reduce these to encourage promotion. Remember to switch them back to their defaults after the cache fills though. +Stochastic multiqueue (smq) +--------------------------- + +This policy is the default. + +The stochastic multi-queue (smq) policy addresses some of the problems +with the multiqueue (mq) policy. + +The smq policy (vs mq) offers the promise of less memory utilization, +improved performance and increased adaptability in the face of changing +workloads. SMQ also does not have any cumbersome tuning knobs. + +Users may switch from "mq" to "smq" simply by appropriately reloading a +DM table that is using the cache target. Doing so will cause all of the +mq policy's hints to be dropped. Also, performance of the cache may +degrade slightly until smq recalculates the origin device's hotspots +that should be cached. + +Memory usage: +The mq policy uses a lot of memory; 88 bytes per cache block on a 64 +bit machine. + +SMQ uses 28bit indexes to implement it's data structures rather than +pointers. It avoids storing an explicit hit count for each block. It +has a 'hotspot' queue rather than a pre cache which uses a quarter of +the entries (each hotspot block covers a larger area than a single +cache block). + +All these mean smq uses ~25bytes per cache block. Still a lot of +memory, but a substantial improvement nontheless. + +Level balancing: +MQ places entries in different levels of the multiqueue structures +based on their hit count (~ln(hit count)). This means the bottom +levels generally have the most entries, and the top ones have very +few. Having unbalanced levels like this reduces the efficacy of the +multiqueue. + +SMQ does not maintain a hit count, instead it swaps hit entries with +the least recently used entry from the level above. The over all +ordering being a side effect of this stochastic process. With this +scheme we can decide how many entries occupy each multiqueue level, +resulting in better promotion/demotion decisions. + +Adaptability: +The MQ policy maintains a hit count for each cache block. For a +different block to get promoted to the cache it's hit count has to +exceed the lowest currently in the cache. This means it can take a +long time for the cache to adapt between varying IO patterns. +Periodically degrading the hit counts could help with this, but I +haven't found a nice general solution. + +SMQ doesn't maintain hit counts, so a lot of this problem just goes +away. In addition it tracks performance of the hotspot queue, which +is used to decide which blocks to promote. If the hotspot queue is +performing badly then it starts moving entries more quickly between +levels. This lets it adapt to new IO patterns very quickly. + +Performance: +Testing SMQ shows substantially better performance than MQ. + cleaner ------- diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt index 68c0f517c60e..82960cffbad3 100644 --- a/Documentation/device-mapper/cache.txt +++ b/Documentation/device-mapper/cache.txt @@ -221,6 +221,7 @@ Status <#read hits> <#read misses> <#write hits> <#write misses> <#demotions> <#promotions> <#dirty> <#features> <features>* <#core args> <core args>* <policy name> <#policy args> <policy args>* +<cache metadata mode> metadata block size : Fixed block size for each metadata block in sectors @@ -251,8 +252,12 @@ core args : Key/value pairs for tuning the core e.g. migration_threshold policy name : Name of the policy #policy args : Number of policy arguments to follow (must be even) -policy args : Key/value pairs - e.g. sequential_threshold +policy args : Key/value pairs e.g. sequential_threshold +cache metadata mode : ro if read-only, rw if read-write + In serious cases where even a read-only mode is deemed unsafe + no further I/O will be permitted and the status will just + contain the string 'Fail'. The userspace recovery tools + should then be used. Messages -------- diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index ef8ba9fa58c4..cb12af3b51c2 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -224,3 +224,5 @@ Version History New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt. 1.5.1 Add ability to restore transiently failed devices on resume. 1.5.2 'mismatch_cnt' is zero unless [last_]sync_action is "check". +1.6.0 Add discard support (and devices_handle_discard_safely module param). +1.7.0 Add support for MD RAID0 mappings. diff --git a/Documentation/device-mapper/statistics.txt b/Documentation/device-mapper/statistics.txt index 2a1673adc200..4919b2dfd1b3 100644 --- a/Documentation/device-mapper/statistics.txt +++ b/Documentation/device-mapper/statistics.txt @@ -13,9 +13,14 @@ the range specified. The I/O statistics counters for each step-sized area of a region are in the same format as /sys/block/*/stat or /proc/diskstats (see: Documentation/iostats.txt). But two extra counters (12 and 13) are -provided: total time spent reading and writing in milliseconds. All -these counters may be accessed by sending the @stats_print message to -the appropriate DM device via dmsetup. +provided: total time spent reading and writing. When the histogram +argument is used, the 14th parameter is reported that represents the +histogram of latencies. All these counters may be accessed by sending +the @stats_print message to the appropriate DM device via dmsetup. + +The reported times are in milliseconds and the granularity depends on +the kernel ticks. When the option precise_timestamps is used, the +reported times are in nanoseconds. Each region has a corresponding unique identifier, which we call a region_id, that is assigned when the region is created. The region_id @@ -33,7 +38,9 @@ memory is used by reading Messages ======== - @stats_create <range> <step> [<program_id> [<aux_data>]] + @stats_create <range> <step> + [<number_of_optional_arguments> <optional_arguments>...] + [<program_id> [<aux_data>]] Create a new region and return the region_id. @@ -48,6 +55,29 @@ Messages "/<number_of_areas>" - the range is subdivided into the specified number of areas. + <number_of_optional_arguments> + The number of optional arguments + + <optional_arguments> + The following optional arguments are supported + precise_timestamps - use precise timer with nanosecond resolution + instead of the "jiffies" variable. When this argument is + used, the resulting times are in nanoseconds instead of + milliseconds. Precise timestamps are a little bit slower + to obtain than jiffies-based timestamps. + histogram:n1,n2,n3,n4,... - collect histogram of latencies. The + numbers n1, n2, etc are times that represent the boundaries + of the histogram. If precise_timestamps is not used, the + times are in milliseconds, otherwise they are in + nanoseconds. For each range, the kernel will report the + number of requests that completed within this range. For + example, if we use "histogram:10,20,30", the kernel will + report four numbers a:b:c:d. a is the number of requests + that took 0-10 ms to complete, b is the number of requests + that took 10-20 ms to complete, c is the number of requests + that took 20-30 ms to complete and d is the number of + requests that took more than 30 ms to complete. + <program_id> An optional parameter. A name that uniquely identifies the userspace owner of the range. This groups ranges together @@ -55,6 +85,9 @@ Messages created and ignore those created by others. The kernel returns this string back in the output of @stats_list message, but it doesn't use it for anything else. + If we omit the number of optional arguments, program id must not + be a number, otherwise it would be interpreted as the number of + optional arguments. <aux_data> An optional parameter. A word that provides auxiliary data diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt index d0ce01da5c59..f5ad0ff69fae 100644 --- a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt @@ -2,7 +2,7 @@ Altera SOCFPGA SDRAM Error Detection & Correction [EDAC] The EDAC accesses a range of registers in the SDRAM controller. Required properties: -- compatible : should contain "altr,sdram-edac"; +- compatible : should contain "altr,sdram-edac" or "altr,sdram-edac-a10" - altr,sdr-syscon : phandle of the sdr module - interrupts : Should contain the SDRAM ECC IRQ in the appropriate format for the IRQ controller. diff --git a/Documentation/devicetree/bindings/arm/armv7m_systick.txt b/Documentation/devicetree/bindings/arm/armv7m_systick.txt new file mode 100644 index 000000000000..7cf4a24601eb --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armv7m_systick.txt @@ -0,0 +1,26 @@ +* ARMv7M System Timer + +ARMv7-M includes a system timer, known as SysTick. Current driver only +implements the clocksource feature. + +Required properties: +- compatible : Should be "arm,armv7m-systick" +- reg : The address range of the timer + +Required clocking property, have to be one of: +- clocks : The input clock of the timer +- clock-frequency : The rate in HZ in input of the ARM SysTick + +Examples: + +systick: timer@e000e010 { + compatible = "arm,armv7m-systick"; + reg = <0xe000e010 0x10>; + clocks = <&clk_systick>; +}; + +systick: timer@e000e010 { + compatible = "arm,armv7m-systick"; + reg = <0xe000e010 0x10>; + clock-frequency = <90000000>; +}; diff --git a/Documentation/devicetree/bindings/ata/ahci-ceva.txt b/Documentation/devicetree/bindings/ata/ahci-ceva.txt new file mode 100644 index 000000000000..7ca8b976c13a --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt @@ -0,0 +1,20 @@ +Binding for CEVA AHCI SATA Controller + +Required properties: + - reg: Physical base address and size of the controller's register area. + - compatible: Compatibility string. Must be 'ceva,ahci-1v84'. + - clocks: Input clock specifier. Refer to common clock bindings. + - interrupts: Interrupt specifier. Refer to interrupt binding. + +Optional properties: + - ceva,broken-gen2: limit to gen1 speed instead of gen2. + +Examples: + ahci@fd0c0000 { + compatible = "ceva,ahci-1v84"; + reg = <0xfd0c0000 0x200>; + interrupt-parent = <&gic>; + interrupts = <0 133 4>; + clocks = <&clkc SATA_CLK_ID>; + ceva,broken-gen2; + }; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index c2340eeeb97f..a2321819e7f5 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -16,6 +16,8 @@ Required properties: - "snps,dwc-ahci" - "snps,exynos5440-ahci" - "snps,spear-ahci" + - "fsl,qoriq-ahci" : for qoriq series socs which include ls1021, ls2085, etc. + - "fsl,<chip>-ahci" : chip could be ls1021, ls2085 etc. - "generic-ahci" - interrupts : <interrupt mapping for SATA IRQ> - reg : <registers mapping> diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt new file mode 100644 index 000000000000..20ac9bbfa1fd --- /dev/null +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt @@ -0,0 +1,34 @@ +* Broadcom SATA3 AHCI Controller for STB + +SATA nodes are defined to describe on-chip Serial ATA controllers. +Each SATA controller should have its own node. + +Required properties: +- compatible : compatible list, may contain "brcm,bcm7445-ahci" and/or + "brcm,sata3-ahci" +- reg : register mappings for AHCI and SATA_TOP_CTRL +- reg-names : "ahci" and "top-ctrl" +- interrupts : interrupt mapping for SATA IRQ + +Also see ahci-platform.txt. + +Example: + + sata@f045a000 { + compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci"; + reg = <0xf045a000 0xa9c>, <0xf0458040 0x24>; + reg-names = "ahci", "top-ctrl"; + interrupts = <0 30 0>; + #address-cells = <1>; + #size-cells = <0>; + + sata0: sata-port@0 { + reg = <0>; + phys = <&sata_phy 0>; + }; + + sata1: sata-port@1 { + reg = <1>; + phys = <&sata_phy 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt b/Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt new file mode 100644 index 000000000000..36c2b528245c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,h8300-div-clock.txt @@ -0,0 +1,24 @@ +* Renesas H8/300 divider clock + +Required Properties: + + - compatible: Must be "renesas,sh73a0-h8300-div-clock" + + - clocks: Reference to the parent clocks ("extal1" and "extal2") + + - #clock-cells: Must be 1 + + - reg: Base address and length of the divide rate selector + + - renesas,width: bit width of selector + +Example +------- + + cclk: cclk { + compatible = "renesas,h8300-div-clock"; + clocks = <&xclk>; + #clock-cells = <0>; + reg = <0xfee01b 2>; + renesas,width = <2>; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,h8s2678-pll-clock.txt b/Documentation/devicetree/bindings/clock/renesas,h8s2678-pll-clock.txt new file mode 100644 index 000000000000..500cdadbceb7 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,h8s2678-pll-clock.txt @@ -0,0 +1,23 @@ +Renesas H8S2678 PLL clock + +This device is Clock multiplyer + +Required Properties: + + - compatible: Must be "renesas,h8s2678-pll-clock" + + - clocks: Reference to the parent clocks + + - #clock-cells: Must be 0 + + - reg: Two rate selector (Multiply / Divide) register address + +Example +------- + + pllclk: pllclk { + compatible = "renesas,h8s2678-pll-clock"; + clocks = <&xclk>; + #clock-cells = <0>; + reg = <0xfee03b 2>, <0xfee045 2>; + }; diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt index 38988ef1336b..f0d926bf9f36 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt @@ -1,9 +1,11 @@ -Freescale SoC SEC Security Engines versions 2.x-3.x +Freescale SoC SEC Security Engines versions 1.x-2.x-3.x Required properties: - compatible : Should contain entries for this and backward compatible - SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" + SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" (SEC2/3) + e.g., "fsl,sec1.2", "fsl,sec1.0" (SEC1) + warning: SEC1 and SEC2 are mutually exclusive - reg : Offset and length of the register set for the device - interrupts : the SEC's interrupt number - fsl,num-channels : An integer representing the number of channels diff --git a/Documentation/devicetree/bindings/crypto/marvell-cesa.txt b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt new file mode 100644 index 000000000000..c6c6a4a045bd --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/marvell-cesa.txt @@ -0,0 +1,45 @@ +Marvell Cryptographic Engines And Security Accelerator + +Required properties: +- compatible: should be one of the following string + "marvell,orion-crypto" + "marvell,kirkwood-crypto" + "marvell,dove-crypto" + "marvell,armada-370-crypto" + "marvell,armada-xp-crypto" + "marvell,armada-375-crypto" + "marvell,armada-38x-crypto" +- reg: base physical address of the engine and length of memory mapped + region. Can also contain an entry for the SRAM attached to the CESA, + but this representation is deprecated and marvell,crypto-srams should + be used instead +- reg-names: "regs". Can contain an "sram" entry, but this representation + is deprecated and marvell,crypto-srams should be used instead +- interrupts: interrupt number +- clocks: reference to the crypto engines clocks. This property is not + required for orion and kirkwood platforms +- clock-names: "cesaX" and "cesazX", X should be replaced by the crypto engine + id. + This property is not required for the orion and kirkwoord + platforms. + "cesazX" clocks are not required on armada-370 platforms +- marvell,crypto-srams: phandle to crypto SRAM definitions + +Optional properties: +- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not + specified the whole SRAM is used (2KB) + + +Examples: + + crypto@90000 { + compatible = "marvell,armada-xp-crypto"; + reg = <0x90000 0x10000>; + reg-names = "regs"; + interrupts = <48>, <49>; + clocks = <&gateclk 23>, <&gateclk 23>; + clock-names = "cesa0", "cesa1"; + marvell,crypto-srams = <&crypto_sram0>, <&crypto_sram1>; + marvell,crypto-sram-size = <0x600>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt index 47229b1a594b..c0c35f00335b 100644 --- a/Documentation/devicetree/bindings/crypto/mv_cesa.txt +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -1,20 +1,33 @@ Marvell Cryptographic Engines And Security Accelerator Required properties: -- compatible : should be "marvell,orion-crypto" -- reg : base physical address of the engine and length of memory mapped - region, followed by base physical address of sram and its memory - length -- reg-names : "regs" , "sram"; -- interrupts : interrupt number +- compatible: should be one of the following string + "marvell,orion-crypto" + "marvell,kirkwood-crypto" + "marvell,dove-crypto" +- reg: base physical address of the engine and length of memory mapped + region. Can also contain an entry for the SRAM attached to the CESA, + but this representation is deprecated and marvell,crypto-srams should + be used instead +- reg-names: "regs". Can contain an "sram" entry, but this representation + is deprecated and marvell,crypto-srams should be used instead +- interrupts: interrupt number +- clocks: reference to the crypto engines clocks. This property is only + required for Dove platforms +- marvell,crypto-srams: phandle to crypto SRAM definitions + +Optional properties: +- marvell,crypto-sram-size: SRAM size reserved for crypto operations, if not + specified the whole SRAM is used (2KB) Examples: crypto@30000 { compatible = "marvell,orion-crypto"; - reg = <0x30000 0x10000>, - <0x4000000 0x800>; - reg-names = "regs" , "sram"; + reg = <0x30000 0x10000>; + reg-names = "regs"; interrupts = <22>; + marvell,crypto-srams = <&crypto_sram>; + marvell,crypto-sram-size = <0x600>; status = "okay"; }; diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt new file mode 100644 index 000000000000..78edb80002c8 --- /dev/null +++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt @@ -0,0 +1,79 @@ +* APM X-Gene SoC EDAC node + +EDAC node is defined to describe on-chip error detection and correction. +The follow error types are supported: + + memory controller - Memory controller + PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache + +The following section describes the EDAC DT node binding. + +Required properties: +- compatible : Shall be "apm,xgene-edac". +- regmap-csw : Regmap of the CPU switch fabric (CSW) resource. +- regmap-mcba : Regmap of the MCB-A (memory bridge) resource. +- regmap-mcbb : Regmap of the MCB-B (memory bridge) resource. +- regmap-efuse : Regmap of the PMD efuse resource. +- reg : First resource shall be the CPU bus (PCP) resource. +- interrupts : Interrupt-specifier for MCU, PMD, L3, or SoC error + IRQ(s). + +Required properties for memory controller subnode: +- compatible : Shall be "apm,xgene-edac-mc". +- reg : First resource shall be the memory controller unit + (MCU) resource. +- memory-controller : Instance number of the memory controller. + +Required properties for PMD subnode: +- compatible : Shall be "apm,xgene-edac-pmd" or + "apm,xgene-edac-pmd-v2". +- reg : First resource shall be the PMD resource. +- pmd-controller : Instance number of the PMD controller. + +Example: + csw: csw@7e200000 { + compatible = "apm,xgene-csw", "syscon"; + reg = <0x0 0x7e200000 0x0 0x1000>; + }; + + mcba: mcba@7e700000 { + compatible = "apm,xgene-mcb", "syscon"; + reg = <0x0 0x7e700000 0x0 0x1000>; + }; + + mcbb: mcbb@7e720000 { + compatible = "apm,xgene-mcb", "syscon"; + reg = <0x0 0x7e720000 0x0 0x1000>; + }; + + efuse: efuse@1054a000 { + compatible = "apm,xgene-efuse", "syscon"; + reg = <0x0 0x1054a000 0x0 0x20>; + }; + + edac@78800000 { + compatible = "apm,xgene-edac"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + regmap-csw = <&csw>; + regmap-mcba = <&mcba>; + regmap-mcbb = <&mcbb>; + regmap-efuse = <&efuse>; + reg = <0x0 0x78800000 0x0 0x100>; + interrupts = <0x0 0x20 0x4>, + <0x0 0x21 0x4>, + <0x0 0x27 0x4>; + + edacmc@7e800000 { + compatible = "apm,xgene-edac-mc"; + reg = <0x0 0x7e800000 0x0 0x1000>; + memory-controller = <0>; + }; + + edacpmd@7c000000 { + compatible = "apm,xgene-edac-pmd"; + reg = <0x0 0x7c000000 0x0 0x200000>; + pmd-controller = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt new file mode 100644 index 000000000000..435f1bcca341 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt @@ -0,0 +1,65 @@ +Broadcom STB "UPG GIO" GPIO controller + +The controller's registers are organized as sets of eight 32-bit +registers with each set controlling a bank of up to 32 pins. A single +interrupt is shared for all of the banks handled by the controller. + +Required properties: + +- compatible: + Must be "brcm,brcmstb-gpio" + +- reg: + Define the base and range of the I/O address space containing + the brcmstb GPIO controller registers + +- #gpio-cells: + Should be <2>. The first cell is the pin number (within the controller's + pin space), and the second is used for the following: + bit[0]: polarity (0 for active-high, 1 for active-low) + +- gpio-controller: + Specifies that the node is a GPIO controller. + +- brcm,gpio-bank-widths: + Number of GPIO lines for each bank. Number of elements must + correspond to number of banks suggested by the 'reg' property. + +Optional properties: + +- interrupts: + The interrupt shared by all GPIO lines for this controller. + +- interrupt-parent: + phandle of the parent interrupt controller + +- #interrupt-cells: + Should be <2>. The first cell is the GPIO number, the second should specify + flags. The following subset of flags is supported: + - 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 + Valid combinations are 1, 2, 3, 4, 8. + See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + +- interrupt-controller: + Marks the device node as an interrupt controller + +- interrupt-names: + The name of the IRQ resource used by this controller + +Example: + upg_gio: gpio@f040a700 { + #gpio-cells = <0x2>; + #interrupt-cells = <0x2>; + compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio"; + gpio-controller; + interrupt-controller; + reg = <0xf040a700 0x80>; + interrupt-parent = <0xf>; + interrupts = <0x6>; + interrupt-names = "upg_gio"; + brcm,gpio-bank-widths = <0x20 0x20 0x20 0x18>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-atlas7.txt b/Documentation/devicetree/bindings/gpio/gpio-atlas7.txt new file mode 100644 index 000000000000..d7e123fc90b5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-atlas7.txt @@ -0,0 +1,50 @@ +CSR SiRFatlas7 GPIO controller bindings + +Required properties: +- compatible : "sirf,atlas7-gpio" +- reg : Address range of the pinctrl registers +- interrupts : Interrupts used by every GPIO group +- gpio-banks : How many gpio banks on this controller +- gpio-controller : Indicates this device is a GPIO controller +- interrupt-controller : Marks the device node as an interrupt controller + +The GPIO controller also acts as an interrupt controller. It uses the default +two cells specifier as described in Documentation/devicetree/bindings/ +interrupt-controller/interrupts.txt. + +Example: + + gpio_0: gpio_mediam@17040000 { + compatible = "sirf,atlas7-gpio"; + reg = <0x17040000 0x1000>; + interrupts = <0 13 0>, <0 14 0>; + + #gpio-cells = <2>; + #interrupt-cells = <2>; + + gpio-controller; + interrupt-controller; + + gpio-banks = <2>; + gpio-ranges = <&pinctrl 0 0 0>, + <&pinctrl 32 0 0>; + gpio-ranges-group-names = "lvds_gpio_grp", + "uart_nand_gpio_grp"; + }; + + leds { + compatible = "gpio-leds"; + + led1 { + gpios = <&gpio_1 15 0>; + ... + }; + + led2 { + gpios = <&gpio_2 34 0>; + ... + }; + }; + +Please refer to gpio.txt in this directory for details of the common +gpio properties used by devices. diff --git a/Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt b/Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt new file mode 100644 index 000000000000..abf4db736c6e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt @@ -0,0 +1,21 @@ +Axis ETRAX FS General I/O controller bindings + +Required properties: + +- compatible: + - "axis,etraxfs-gio" +- reg: Physical base address and length of the controller's registers. +- #gpio-cells: Should be 3 + - The first cell is the gpio offset number. + - The second cell is reserved and is currently unused. + - The third cell is the port number (hex). +- gpio-controller: Marks the device node as a GPIO controller. + +Example: + + gio: gpio@b001a000 { + compatible = "axis,etraxfs-gio"; + reg = <0xb001a000 0x1000>; + gpio-controller; + #gpio-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-xlp.txt b/Documentation/devicetree/bindings/gpio/gpio-xlp.txt new file mode 100644 index 000000000000..262ee4ddf2cb --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-xlp.txt @@ -0,0 +1,47 @@ +Netlogic XLP Family GPIO +======================== + +This GPIO driver is used for following Netlogic XLP SoCs: + XLP832, XLP316, XLP208, XLP980, XLP532 + +Required properties: +------------------- + +- compatible: Should be one of the following: + - "netlogic,xlp832-gpio": For Netlogic XLP832 + - "netlogic,xlp316-gpio": For Netlogic XLP316 + - "netlogic,xlp208-gpio": For Netlogic XLP208 + - "netlogic,xlp980-gpio": For Netlogic XLP980 + - "netlogic,xlp532-gpio": For Netlogic XLP532 +- reg: Physical base address and length of the controller's registers. +- #gpio-cells: Should be two. The first cell is the pin number and the second + cell is used to specify optional parameters (currently unused). +- gpio-controller: Marks the device node as a GPIO controller. +- nr-gpios: Number of GPIO pins supported by the controller. +- interrupt-cells: Should be two. The first cell is the GPIO Number. The + second cell is used to specify flags. The following subset of flags is + supported: + - trigger type: + 1 = low to high edge triggered. + 2 = high to low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. +- interrupts: Interrupt number for this device. +- interrupt-parent: phandle of the parent interrupt controller. +- interrupt-controller: Identifies the node as an interrupt controller. + +Example: + + gpio: xlp_gpio@34000 { + compatible = "netlogic,xlp316-gpio"; + reg = <0 0x34100 0x1000 + 0 0x35100 0x1000>; + #gpio-cells = <2>; + gpio-controller; + nr-gpios = <57>; + + #interrupt-cells = <2>; + interrupt-parent = <&pic>; + interrupts = <39>; + interrupt-controller; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt index 986371a4be2c..db4c6a663c03 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt @@ -6,7 +6,7 @@ Required properties: - First cell is the GPIO line number - Second cell is used to specify optional parameters (unused) -- compatible : Should be "xlnx,zynq-gpio-1.0" +- compatible : Should be "xlnx,zynq-gpio-1.0" or "xlnx,zynqmp-gpio-1.0" - clocks : Clock specifier (see clock bindings for details) - gpio-controller : Marks the device node as a GPIO controller. - interrupts : Interrupt specifier (see interrupt bindings for diff --git a/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt b/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt new file mode 100644 index 000000000000..eb7cdd69e10b --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nxp,lpc1850-gpio.txt @@ -0,0 +1,39 @@ +NXP LPC18xx/43xx GPIO controller Device Tree Bindings +----------------------------------------------------- + +Required properties: +- compatible : Should be "nxp,lpc1850-gpio" +- reg : Address and length of the register set for the device +- clocks : Clock specifier (see clock bindings for details) +- gpio-controller : Marks the device node as a GPIO controller. +- #gpio-cells : Should be two + - First cell is the GPIO line number + - Second cell is used to specify polarity + +Optional properties: +- gpio-ranges : Mapping between GPIO and pinctrl + +Example: +#define LPC_GPIO(port, pin) (port * 32 + pin) +#define LPC_PIN(port, pin) (0x##port * 32 + pin) + +gpio: gpio@400f4000 { + compatible = "nxp,lpc1850-gpio"; + reg = <0x400f4000 0x4000>; + clocks = <&ccu1 CLK_CPU_GPIO>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl LPC_GPIO(0,0) LPC_PIN(0,0) 2>, + ... + <&pinctrl LPC_GPIO(7,19) LPC_PIN(f,5) 7>; +}; + +gpio_joystick { + compatible = "gpio-keys-polled"; + ... + + button@0 { + ... + gpios = <&gpio LPC_GPIO(4,8) GPIO_ACTIVE_LOW>; + }; +}; diff --git a/Documentation/devicetree/bindings/h8300/cpu.txt b/Documentation/devicetree/bindings/h8300/cpu.txt new file mode 100644 index 000000000000..70cd58608f4b --- /dev/null +++ b/Documentation/devicetree/bindings/h8300/cpu.txt @@ -0,0 +1,13 @@ +* H8/300 CPU bindings + +Required properties: + +- compatible: Compatible property value should be "renesas,h8300". +- clock-frequency: Contains the clock frequency for CPU, in Hz. + +Example: + + cpu@0 { + compatible = "renesas,h8300"; + clock-frequency = <20000000>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt index fcca8e744f41..a04a80f9cc70 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt @@ -9,6 +9,7 @@ Requires node properties: "murata,ncp21wb473" "murata,ncp03wb473" "murata,ncp15wl333" + "murata,ncp03wf104" /* Usage of vendor name "ntc" is deprecated */ <DEPRECATED> "ntc,ncp15wb473" diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index ad0c4ac916dd..00f8652e193a 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -19,8 +19,7 @@ adi,adt7475 +/-1C TDM Extended Temp Range I.C adi,adt7476 +/-1C TDM Extended Temp Range I.C adi,adt7490 +/-1C TDM Extended Temp Range I.C adi,adxl345 Three-Axis Digital Accelerometer -adi,adxl346 Three-Axis Digital Accelerometer -adi,adxl34x Three-Axis Digital Accelerometer +adi,adxl346 Three-Axis Digital Accelerometer (backward-compatibility value "adi,adxl345" must be listed too) at,24c08 i2c serial eeprom (24cxx) atmel,24c00 i2c serial eeprom (24cxx) atmel,24c01 i2c serial eeprom (24cxx) diff --git a/Documentation/devicetree/bindings/input/ti,drv2665.txt b/Documentation/devicetree/bindings/input/ti,drv2665.txt new file mode 100644 index 000000000000..1ba97ac04305 --- /dev/null +++ b/Documentation/devicetree/bindings/input/ti,drv2665.txt @@ -0,0 +1,17 @@ +* Texas Instruments - drv2665 Haptics driver + +Required properties: + - compatible - "ti,drv2665" - DRV2665 + - reg - I2C slave address + - vbat-supply - Required supply regulator + +Example: + +haptics: haptics@59 { + compatible = "ti,drv2665"; + reg = <0x59>; + vbat-supply = <&vbat>; +}; + +For more product information please see the link below: +http://www.ti.com/product/drv2665 diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt index f292917fa00d..0e9f09a6a2fe 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt @@ -2,7 +2,7 @@ Required properties: - compatible: Should be "atmel,<chip>-aic" - <chip> can be "at91rm9200", "sama5d3" or "sama5d4" + <chip> can be "at91rm9200", "sama5d2", "sama5d3" or "sama5d4" - interrupt-controller: Identifies the node as an interrupt controller. - interrupt-parent: For single AIC system, it is an empty property. - #interrupt-cells: The number of cells to define the interrupts. It should be 3. diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt new file mode 100644 index 000000000000..56e8d82aff34 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,h8300h-intc.txt @@ -0,0 +1,22 @@ +* H8/300H Interrupt controller + +Required properties: + +- compatible: has to be "renesas,h8300h-intc", "renesas,h8300-intc" as fallback. +- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in + interrupts.txt in this directory +- regs: Base address of interrupt controller registers. + +Optional properties: + +- any properties, listed in interrupts.txt, and any standard resource allocation + properties + +Example: + + h8intc: interrupt-controller@fee012 { + compatible = "renesas,h8300h-intc", "renesas,h8300-intc"; + #interrupt-cells = <2>; + interrupt-controller; + reg = <0xfee012 7>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt new file mode 100644 index 000000000000..faded2b1559b --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,h8s-intc.txt @@ -0,0 +1,22 @@ +* H8S Interrupt controller + +Required properties: + +- compatible: has to be "renesas,h8s-intc", "renesas,h8300-intc" as fallback. +- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in + interrupts.txt in this directory +- regs: Base address of interrupt controller registers. + +Optional properties: + +- any properties, listed in interrupts.txt, and any standard resource allocation + properties + +Example: + + h8intc: interrupt-controller@fffe00 { + compatible = "renesas,h8s-intc", "renesas,h8300-intc"; + #interrupt-cells = <2>; + interrupt-controller; + reg = <0xfffe00 24>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt index 4f7946ae8adc..772c550d3b4b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt @@ -13,9 +13,12 @@ Required properties: - reg: Base address and length of each register bank used by the external IRQ pins driven by the interrupt controller hardware module. The base addresses, length and number of required register banks varies with soctype. - +- interrupt-controller: Identifies the node as an interrupt controller. - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in - interrupts.txt in this directory + interrupts.txt in this directory. +- interrupts: Must contain a list of interrupt specifiers. For each interrupt + provided by this irqpin controller instance, there must be one entry, + referring to the corresponding parent interrupt. Optional properties: @@ -25,3 +28,35 @@ Optional properties: if different from the default 4 bits - control-parent: disable and enable interrupts on the parent interrupt controller, needed for some broken implementations +- clocks: Must contain a reference to the functional clock. This property is + mandatory if the hardware implements a controllable functional clock for + the irqpin controller instance. +- power-domains: Must contain a reference to the power domain. This property is + mandatory if the irqpin controller instance is part of a controllable power + domain. + + +Example +------- + + irqpin1: interrupt-controller@e6900004 { + compatible = "renesas,intc-irqpin-r8a7740", + "renesas,intc-irqpin"; + #interrupt-cells = <2>; + interrupt-controller; + reg = <0xe6900004 4>, + <0xe6900014 4>, + <0xe6900024 1>, + <0xe6900044 1>, + <0xe6900064 1>; + interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH + 0 149 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp2_clks R8A7740_CLK_INTCA>; + power-domains = <&pd_a4s>; + }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt new file mode 100644 index 000000000000..c03eec116872 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt @@ -0,0 +1,37 @@ +* ARM SMMUv3 Architecture Implementation + +The SMMUv3 architecture is a significant deparature from previous +revisions, replacing the MMIO register interface with in-memory command +and event queues and adding support for the ATS and PRI components of +the PCIe specification. + +** SMMUv3 required properties: + +- compatible : Should include: + + * "arm,smmu-v3" for any SMMUv3 compliant + implementation. This entry should be last in the + compatible list. + +- reg : Base address and size of the SMMU. + +- interrupts : Non-secure interrupt list describing the wired + interrupt sources corresponding to entries in + interrupt-names. If no wired interrupts are + present then this property may be omitted. + +- interrupt-names : When the interrupts property is present, should + include the following: + * "eventq" - Event Queue not empty + * "priq" - PRI Queue not empty + * "cmdq-sync" - CMD_SYNC complete + * "gerror" - Global Error activated + +** SMMUv3 optional properties: + +- dma-coherent : Present if DMA operations made by the SMMU (page + table walks, stream table accesses etc) are cache + coherent with the CPU. + + NOTE: this only applies to the SMMU itself, not + masters connected upstream of the SMMU. diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.txt b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.txt new file mode 100644 index 000000000000..cdf406c902e2 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.txt @@ -0,0 +1,12 @@ +* H8/300 bus controller + +Required properties: + - compatible: Must be "renesas,h8300-bsc". + - reg: Base address and length of BSC registers. + +Example. + bsc: memory-controller@fee01e { + compatible = "renesas,h8300h-bsc", "renesas,h8300-bsc"; + reg = <0xfee01e 8>; + }; + diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 7665aa95979f..64fa3b2de6cd 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -10,6 +10,9 @@ Required properties: "wlf,wm5110" "wlf,wm8280" "wlf,wm8997" + "wlf,wm8998" + "wlf,wm1814" + - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -31,10 +34,10 @@ Required properties: as covered in Documentation/devicetree/bindings/regulator/regulator.txt - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, - wm5110, wm8280) + wm5110, wm8280, wm8998, wm1814) - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, - wm5110, wm8280) + wm5110, wm8280, wm8998, wm1814) - SPKVDD-supply : Speaker driver power supply (wm8997) @@ -53,8 +56,10 @@ Optional properties: of input signals. Valid values are 0 (Differential), 1 (Single-ended) and 2 (Digital Microphone). If absent, INn_MODE registers set to 0 by default. If present, values must be specified less than or equal to the number of - input singals. If values less than the number of input signals, elements - that has not been specifed are set to 0 by default. + input signals. If values less than the number of input signals, elements + that have not been specified are set to 0 by default. Entries are: + <IN1, IN2, IN3, IN4> (wm5102, wm5110, wm8280, wm8997) + <IN1A, IN2A, IN1B, IN2B> (wm8998, wm1814) - wlf,dmic-ref : DMIC reference voltage source for each input, can be selected from either MICVDD or one of the MICBIAS's, defines diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 98685f291a72..753f14f46e85 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -1,15 +1,16 @@ -AXP202/AXP209 device tree bindings +AXP family PMIC device tree bindings The axp20x family current members : axp202 (X-Powers) axp209 (X-Powers) +axp221 (X-Powers) Required properties: -- compatible: "x-powers,axp202" or "x-powers,axp209" +- compatible: "x-powers,axp202", "x-powers,axp209", "x-powers,axp221" - reg: The I2C slave address for the AXP chip - interrupt-parent: The parent interrupt controller - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin -- interrupt-controller: axp20x has its own internal IRQs +- interrupt-controller: The PMIC has its own internal IRQs - #interrupt-cells: Should be set to 1 Optional properties: @@ -48,6 +49,31 @@ LDO3 : LDO : ldo3in-supply LDO4 : LDO : ldo24in-supply : shared supply LDO5 : LDO : ldo5in-supply +AXP221 regulators, type, and corresponding input supply names: + +Regulator Type Supply Name Notes +--------- ---- ----------- ----- +DCDC1 : DC-DC buck : vin1-supply +DCDC2 : DC-DC buck : vin2-supply +DCDC3 : DC-DC buck : vin3-supply +DCDC4 : DC-DC buck : vin4-supply +DCDC5 : DC-DC buck : vin5-supply +DC1SW : On/Off Switch : dcdc1-supply : DCDC1 secondary output +DC5LDO : LDO : dcdc5-supply : input from DCDC5 +ALDO1 : LDO : aldoin-supply : shared supply +ALDO2 : LDO : aldoin-supply : shared supply +ALDO3 : LDO : aldoin-supply : shared supply +DLDO1 : LDO : dldoin-supply : shared supply +DLDO2 : LDO : dldoin-supply : shared supply +DLDO3 : LDO : dldoin-supply : shared supply +DLDO4 : LDO : dldoin-supply : shared supply +ELDO1 : LDO : eldoin-supply : shared supply +ELDO2 : LDO : eldoin-supply : shared supply +ELDO3 : LDO : eldoin-supply : shared supply +LDO_IO0 : LDO : ips-supply : GPIO 0 +LDO_IO1 : LDO : ips-supply : GPIO 1 +RTC_LDO : LDO : ips-supply : always on + Example: axp209: pmic@34 { diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt index 8009c3d87f33..1777916e9e28 100644 --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt @@ -18,6 +18,10 @@ Required properties (SPI): - reg: SPI chip select Optional properties (SPI): +- google,cros-ec-spi-pre-delay: Some implementations of the EC need a little + time to wake up from sleep before they can receive SPI transfers at a high + clock rate. This property specifies the delay, in usecs, between the + assertion of the CS to the start of the first clock pulse. - google,cros-ec-spi-msg-delay: Some implementations of the EC require some additional processing time in order to accept new transactions. If the delay between transactions is not long enough the EC may not be able to respond diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt b/Documentation/devicetree/bindings/mfd/da9063.txt index 42c6fa6f1c9a..05b21bcb8543 100644 --- a/Documentation/devicetree/bindings/mfd/da9063.txt +++ b/Documentation/devicetree/bindings/mfd/da9063.txt @@ -5,6 +5,7 @@ DA9093 consists of a large and varied group of sub-devices (I2C Only): Device Supply Names Description ------ ------------ ----------- da9063-regulator : : LDOs & BUCKs +da9063-onkey : : On Key da9063-rtc : : Real-Time Clock da9063-watchdog : : Watchdog @@ -51,6 +52,18 @@ Sub-nodes: the DA9063. There are currently no entries in this binding, however compatible = "dlg,da9063-rtc" should be added if a node is created. +- onkey : This node defines the OnKey settings for controlling the key + functionality of the device. The node should contain the compatible property + with the value "dlg,da9063-onkey". + + Optional onkey properties: + + - dlg,disable-key-power : Disable power-down using a long key-press. If this + entry exists the OnKey driver will remove support for the KEY_POWER key + press. If this entry does not exist then by default the key-press + triggered power down is enabled and the OnKey will support both KEY_POWER + and KEY_SLEEP. + - watchdog : This node defines settings for the Watchdog timer associated with the DA9063. There are currently no entries in this binding, however compatible = "dlg,da9063-watchdog" should be added if a node is created. @@ -73,6 +86,11 @@ Example: compatible = "dlg,da9063-watchdog"; }; + onkey { + compatible = "dlg,da9063-onkey"; + dlg,disable-key-power; + }; + regulators { DA9063_BCORE1: bcore1 { regulator-name = "BCORE1"; diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt index e39f0bc1f55e..163bd81a4607 100644 --- a/Documentation/devicetree/bindings/mfd/max77686.txt +++ b/Documentation/devicetree/bindings/mfd/max77686.txt @@ -1,6 +1,6 @@ Maxim MAX77686 multi-function device -MAX77686 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is +MAX77686 is a Multifunction device with PMIC, RTC and Charger on chip. It is interfaced to host controller using i2c interface. PMIC and Charger submodules are addressed using same i2c slave address whereas RTC submodule uses different i2c slave address,presently for which we are statically creating i2c diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt index 38e64405e98d..d3425846aa5b 100644 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -76,7 +76,60 @@ Optional properties: Valid values: 4300000, 4700000, 4800000, 4900000 Default: 4300000 +- led : the LED submodule device node + +There are two LED outputs available - FLED1 and FLED2. Each of them can +control a separate LED or they can be connected together to double +the maximum current for a single connected LED. One LED is represented +by one child node. + +Required properties: +- compatible : Must be "maxim,max77693-led". + +Optional properties: +- maxim,boost-mode : + In boost mode the device can produce up to 1.2A of total current + on both outputs. The maximum current on each output is reduced + to 625mA then. If not enabled explicitly, boost setting defaults to + LEDS_BOOST_FIXED in case both current sources are used. + Possible values: + LEDS_BOOST_OFF (0) - no boost, + LEDS_BOOST_ADAPTIVE (1) - adaptive mode, + LEDS_BOOST_FIXED (2) - fixed mode. +- maxim,boost-mvout : Output voltage of the boost module in millivolts. + Valid values: 3300 - 5500, step by 25 (rounded down) + Default: 3300 +- maxim,mvsys-min : Low input voltage level in millivolts. Flash is not fired + if chip estimates that system voltage could drop below this level due + to flash power consumption. + Valid values: 2400 - 3400, step by 33 (rounded down) + Default: 2400 + +Required properties for the LED child node: +- led-sources : see Documentation/devicetree/bindings/leds/common.txt; + device current output identifiers: 0 - FLED1, 1 - FLED2 +- led-max-microamp : see Documentation/devicetree/bindings/leds/common.txt + Valid values for a LED connected to one FLED output: + 15625 - 250000, step by 15625 (rounded down) + Valid values for a LED connected to both FLED outputs: + 15625 - 500000, step by 15625 (rounded down) +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt + Valid values for a single LED connected to one FLED output + (boost mode must be turned off): + 15625 - 1000000, step by 15625 (rounded down) + Valid values for a single LED connected to both FLED outputs: + 15625 - 1250000, step by 15625 (rounded down) + Valid values for two LEDs case: + 15625 - 625000, step by 15625 (rounded down) +- flash-max-timeout-us : see Documentation/devicetree/bindings/leds/common.txt + Valid values: 62500 - 1000000, step by 62500 (rounded down) + +Optional properties for the LED child node: +- label : see Documentation/devicetree/bindings/leds/common.txt + Example: +#include <dt-bindings/leds/common.h> + max77693@66 { compatible = "maxim,max77693"; reg = <0x66>; @@ -117,5 +170,19 @@ Example: maxim,thermal-regulation-celsius = <75>; maxim,battery-overcurrent-microamp = <3000000>; maxim,charge-input-threshold-microvolt = <4300000>; + + led { + compatible = "maxim,max77693-led"; + maxim,boost-mode = <LEDS_BOOST_FIXED>; + maxim,boost-mvout = <5000>; + maxim,mvsys-min = <2400>; + + camera_flash: flash-led { + label = "max77693-flash"; + led-sources = <0>, <1>; + led-max-microamp = <500000>; + flash-max-microamp = <1250000>; + flash-max-timeout-us = <1000000>; + }; }; }; diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt index 98ee2abbe138..7e9490313d5a 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt @@ -8,7 +8,8 @@ Device Tree Bindings for the Arasan SDHCI Controller [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt Required Properties: - - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' + - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or + 'arasan,sdhci-4.9a' - reg: From mmc bindings: Register location and length. - clocks: From clock bindings: Handles to clock inputs. - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb" diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt index 415c5575cbf7..5d0376b8f202 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt @@ -7,7 +7,14 @@ This file documents differences between the core properties described by mmc.txt and the properties used by the sdhci-esdhc-imx driver. Required properties: -- compatible : Should be "fsl,<chip>-esdhc" +- compatible : Should be "fsl,<chip>-esdhc", the supported chips include + "fsl,imx25-esdhc" + "fsl,imx35-esdhc" + "fsl,imx51-esdhc" + "fsl,imx53-esdhc" + "fsl,imx6q-usdhc" + "fsl,imx6sl-usdhc" + "fsl,imx6sx-usdhc" Optional properties: - fsl,cd-controller : Indicate to use controller internal card detection diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt index 3b3544931437..df370585cbcc 100644 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt @@ -13,6 +13,10 @@ Required Properties: * compatible: should be one of the following. - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions. + - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions. + +Optional Properties: +- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral. Example: @@ -42,3 +46,27 @@ Example: cap-mmc-highspeed; cap-sd-highspeed; }; + + /* for Hi6220 */ + + dwmmc_1: dwmmc1@f723e000 { + compatible = "hisilicon,hi6220-dw-mshc"; + num-slots = <0x1>; + bus-width = <0x4>; + disable-wp; + cap-sd-highspeed; + sd-uhs-sdr12; + sd-uhs-sdr25; + card-detect-delay = <200>; + hisilicon,peripheral-syscon = <&ao_ctrl>; + reg = <0x0 0xf723e000 0x0 0x1000>; + interrupts = <0x0 0x49 0x4>; + clocks = <&clock_sys HI6220_MMC1_CIUCLK>, <&clock_sys HI6220_MMC1_CLK>; + clock-names = "ciu", "biu"; + cd-gpios = <&gpio1 0 1>; + pinctrl-names = "default", "idle"; + pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>; + pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>; + vqmmc-supply = <&ldo7>; + vmmc-supply = <&ldo10>; + }; diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt index a462c50f19a8..ce0e76749671 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt @@ -21,5 +21,7 @@ Example: sdhci0_pwrseq { compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio1 12 0>; + reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + clocks = <&clk_32768_ck>; + clock-names = "ext_clock"; } diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 438899e8829b..0384fc3f64e8 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -21,6 +21,11 @@ Optional properties: below for the case, when a GPIO is used for the CD line - wp-inverted: when present, polarity on the WP line is inverted. See the note below for the case, when a GPIO is used for the WP line +- disable-wp: When set no physical WP line is present. This property should + only be specified when the controller has a dedicated write-protect + detection logic. If a GPIO is always used for the write-protect detection + logic it is sufficient to not specify wp-gpios property in the absence of a WP + line. - max-frequency: maximum operating clock frequency - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is. diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt new file mode 100644 index 000000000000..a1adfa495ad3 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -0,0 +1,32 @@ +* MTK MMC controller + +The MTK MSDC can act as a MMC controller +to support MMC, SD, and SDIO types of memory cards. + +This file documents differences between the core properties in mmc.txt +and the properties used by the msdc driver. + +Required properties: +- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc" +- interrupts: Should contain MSDC interrupt number +- clocks: MSDC source clock, HCLK +- clock-names: "source", "hclk" +- pinctrl-names: should be "default", "state_uhs" +- pinctrl-0: should contain default/high speed pin ctrl +- pinctrl-1: should contain uhs mode pin ctrl +- vmmc-supply: power to the Core +- vqmmc-supply: power to the IO + +Examples: +mmc0: mmc@11230000 { + compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc"; + reg = <0 0x11230000 0 0x108>; + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_LOW>; + vmmc-supply = <&mt6397_vemc_3v3_reg>; + vqmmc-supply = <&mt6397_vio18_reg>; + clocks = <&pericfg CLK_PERI_MSDC30_0>, <&topckgen CLK_TOP_MSDC50_0_H_SEL>; + clock-names = "source", "hclk"; + pinctrl-names = "default", "state_uhs"; + pinctrl-0 = <&mmc0_pins_default>; + pinctrl-1 = <&mmc0_pins_uhs>; +}; diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt index 299081f94abd..d38942f6c5ae 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt @@ -18,6 +18,8 @@ Required properties: dma-names property. - dma-names: must contain "tx" for the transmit DMA channel and "rx" for the receive DMA channel. +- max-frequency: Maximum operating clock frequency, driver uses default clock + frequency if it is not set. Example: R8A7790 (R-Car H2) MMCIF0 @@ -29,4 +31,5 @@ Example: R8A7790 (R-Car H2) MMCIF0 clocks = <&mstp3_clks R8A7790_CLK_MMCIF0>; dmas = <&dmac0 0xd1>, <&dmac0 0xd2>; dma-names = "tx", "rx"; + max-frequency = <97500000>; }; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt new file mode 100644 index 000000000000..4ff7128ee3b2 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt @@ -0,0 +1,150 @@ +* Broadcom STB NAND Controller + +The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND +flash chips. It has a memory-mapped register interface for both control +registers and for its data input/output buffer. On some SoCs, this controller is +paired with a custom DMA engine (inventively named "Flash DMA") which supports +basic PROGRAM and READ functions, among other features. + +This controller was originally designed for STB SoCs (BCM7xxx) but is now +available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and +iProc/Cygnus. Its history includes several similar (but not fully register +compatible) versions. + +Required properties: +- compatible : May contain an SoC-specific compatibility string (see below) + to account for any SoC-specific hardware bits that may be + added on top of the base core controller. + In addition, must contain compatibility information about + the core NAND controller, of the following form: + "brcm,brcmnand" and an appropriate version compatibility + string, like "brcm,brcmnand-v7.0" + Possible values: + brcm,brcmnand-v4.0 + brcm,brcmnand-v5.0 + brcm,brcmnand-v6.0 + brcm,brcmnand-v6.1 + brcm,brcmnand-v7.0 + brcm,brcmnand-v7.1 + brcm,brcmnand +- reg : the register start and length for NAND register region. + (optional) Flash DMA register range (if present) + (optional) NAND flash cache range (if at non-standard offset) +- reg-names : a list of the names corresponding to the previous register + ranges. Should contain "nand" and (optionally) + "flash-dma" and/or "nand-cache". +- interrupts : The NAND CTLRDY interrupt and (if Flash DMA is available) + FLASH_DMA_DONE +- interrupt-names : May be "nand_ctlrdy" or "flash_dma_done", if broken out as + individual interrupts. + May be "nand", if the SoC has the individual NAND + interrupts multiplexed behind another custom piece of + hardware +- interrupt-parent : See standard interrupt bindings +- #address-cells : <1> - subnodes give the chip-select number +- #size-cells : <0> + +Optional properties: +- brcm,nand-has-wp : Some versions of this IP include a write-protect + (WP) control bit. It is always available on >= + v7.0. Use this property to describe the rare + earlier versions of this core that include WP + + -- Additonal SoC-specific NAND controller properties -- + +The NAND controller is integrated differently on the variety of SoCs on which it +is found. Part of this integration involves providing status and enable bits +with which to control the 8 exposed NAND interrupts, as well as hardware for +configuring the endianness of the data bus. On some SoCs, these features are +handled via standard, modular components (e.g., their interrupts look like a +normal IRQ chip), but on others, they are controlled in unique and interesting +ways, sometimes with registers that lump multiple NAND-related functions +together. The former case can be described simply by the standard interrupts +properties in the main controller node. But for the latter exceptional cases, +we define additional 'compatible' properties and associated register resources within the NAND controller node above. + + - compatible: Can be one of several SoC-specific strings. Each SoC may have + different requirements for its additional properties, as described below each + bullet point below. + + * "brcm,nand-bcm63138" + - reg: (required) the 'NAND_INT_BASE' register range, with separate status + and enable registers + - reg-names: (required) "nand-int-base" + + * "brcm,nand-iproc" + - reg: (required) the "IDM" register range, for interrupt enable and APB + bus access endianness configuration, and the "EXT" register range, + for interrupt status/ack. + - reg-names: (required) a list of the names corresponding to the previous + register ranges. Should contain "iproc-idm" and "iproc-ext". + + +* NAND chip-select + +Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes +to represent enabled chip-selects which (may) contain NAND flash chips. Their +properties are as follows. + +Required properties: +- compatible : should contain "brcm,nandcs" +- reg : a single integer representing the chip-select + number (e.g., 0, 1, 2, etc.) +- #address-cells : see partition.txt +- #size-cells : see partition.txt +- nand-ecc-strength : see nand.txt +- nand-ecc-step-size : must be 512 or 1024. See nand.txt + +Optional properties: +- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this + chip-select. See nand.txt +- brcm,nand-oob-sector-size : integer, to denote the spare area sector size + expected for the ECC layout in use. This size, in + addition to the strength and step-size, + determines how the hardware BCH engine will lay + out the parity bytes it stores on the flash. + This property can be automatically determined by + the flash geometry (particularly the NAND page + and OOB size) in many cases, but when booting + from NAND, the boot controller has only a limited + number of available options for its default ECC + layout. + +Each nandcs device node may optionally contain sub-nodes describing the flash +partition mapping. See partition.txt for more detail. + + +Example: + +nand@f0442800 { + compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; + reg = <0xF0442800 0x600>, + <0xF0443000 0x100>; + reg-names = "nand", "flash-dma"; + interrupt-parent = <&hif_intr2_intc>; + interrupts = <24>, <4>; + + #address-cells = <1>; + #size-cells = <0>; + + nandcs@1 { + compatible = "brcm,nandcs"; + reg = <1>; // Chip select 1 + nand-on-flash-bbt; + nand-ecc-strength = <12>; + nand-ecc-step-size = <512>; + + // Partitions + #address-cells = <1>; // <2>, for 64-bit offset + #size-cells = <1>; // <2>, for 64-bit length + flash0.rootfs@0 { + reg = <0 0x10000000>; + }; + flash0@0 { + reg = <0 0>; // MTDPART_SIZ_FULL + }; + flash0.kernel@10000000 { + reg = <0x10000000 0x400000>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt deleted file mode 100644 index 8db32384a486..000000000000 --- a/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt +++ /dev/null @@ -1,48 +0,0 @@ -* AMD 10GbE PHY driver (amd-xgbe-phy) - -Required properties: -- compatible: Should be "amd,xgbe-phy-seattle-v1a" and - "ethernet-phy-ieee802.3-c45" -- reg: Address and length of the register sets for the device - - SerDes Rx/Tx registers - - SerDes integration registers (1/2) - - SerDes integration registers (2/2) -- interrupt-parent: Should be the phandle for the interrupt controller - that services interrupts for this device -- interrupts: Should contain the amd-xgbe-phy interrupt. - -Optional properties: -- amd,speed-set: Speed capabilities of the device - 0 - 1GbE and 10GbE (default) - 1 - 2.5GbE and 10GbE - -The following optional properties are represented by an array with each -value corresponding to a particular speed. The first array value represents -the setting for the 1GbE speed, the second value for the 2.5GbE speed and -the third value for the 10GbE speed. All three values are required if the -property is used. -- amd,serdes-blwc: Baseline wandering correction enablement - 0 - Off - 1 - On -- amd,serdes-cdr-rate: CDR rate speed selection -- amd,serdes-pq-skew: PQ (data sampling) skew -- amd,serdes-tx-amp: TX amplitude boost -- amd,serdes-dfe-tap-config: DFE taps available to run -- amd,serdes-dfe-tap-enable: DFE taps to enable - -Example: - xgbe_phy@e1240800 { - compatible = "amd,xgbe-phy-seattle-v1a", "ethernet-phy-ieee802.3-c45"; - reg = <0 0xe1240800 0 0x00400>, - <0 0xe1250000 0 0x00060>, - <0 0xe1250080 0 0x00004>; - interrupt-parent = <&gic>; - interrupts = <0 323 4>; - amd,speed-set = <0>; - amd,serdes-blwc = <1>, <1>, <0>; - amd,serdes-cdr-rate = <2>, <2>, <7>; - amd,serdes-pq-skew = <10>, <10>, <30>; - amd,serdes-tx-amp = <15>, <15>, <10>; - amd,serdes-dfe-tap-config = <3>, <3>, <1>; - amd,serdes-dfe-tap-enable = <0>, <0>, <127>; - }; diff --git a/Documentation/devicetree/bindings/net/amd-xgbe.txt b/Documentation/devicetree/bindings/net/amd-xgbe.txt index 26efd526d16c..4bb624a73b54 100644 --- a/Documentation/devicetree/bindings/net/amd-xgbe.txt +++ b/Documentation/devicetree/bindings/net/amd-xgbe.txt @@ -5,12 +5,16 @@ Required properties: - reg: Address and length of the register sets for the device - MAC registers - PCS registers + - SerDes Rx/Tx registers + - SerDes integration registers (1/2) + - SerDes integration registers (2/2) - interrupt-parent: Should be the phandle for the interrupt controller that services interrupts for this device - interrupts: Should contain the amd-xgbe interrupt(s). The first interrupt listed is required and is the general device interrupt. If the optional amd,per-channel-interrupt property is specified, then one additional - interrupt for each DMA channel supported by the device should be specified + interrupt for each DMA channel supported by the device should be specified. + The last interrupt listed should be the PCS auto-negotiation interrupt. - clocks: - DMA clock for the amd-xgbe device (used for calculating the correct Rx interrupt watchdog timer value on a DMA channel @@ -19,7 +23,6 @@ Required properties: - clock-names: Should be the names of the clocks - "dma_clk" for the DMA clock - "ptp_clk" for the PTP clock -- phy-handle: See ethernet.txt file in the same directory - phy-mode: See ethernet.txt file in the same directory Optional properties: @@ -29,19 +32,46 @@ Optional properties: - amd,per-channel-interrupt: Indicates that Rx and Tx complete will generate a unique interrupt for each DMA channel - this requires an additional interrupt be configured for each DMA channel +- amd,speed-set: Speed capabilities of the device + 0 - 1GbE and 10GbE (default) + 1 - 2.5GbE and 10GbE + +The following optional properties are represented by an array with each +value corresponding to a particular speed. The first array value represents +the setting for the 1GbE speed, the second value for the 2.5GbE speed and +the third value for the 10GbE speed. All three values are required if the +property is used. +- amd,serdes-blwc: Baseline wandering correction enablement + 0 - Off + 1 - On +- amd,serdes-cdr-rate: CDR rate speed selection +- amd,serdes-pq-skew: PQ (data sampling) skew +- amd,serdes-tx-amp: TX amplitude boost +- amd,serdes-dfe-tap-config: DFE taps available to run +- amd,serdes-dfe-tap-enable: DFE taps to enable Example: xgbe@e0700000 { compatible = "amd,xgbe-seattle-v1a"; reg = <0 0xe0700000 0 0x80000>, - <0 0xe0780000 0 0x80000>; + <0 0xe0780000 0 0x80000>, + <0 0xe1240800 0 0x00400>, + <0 0xe1250000 0 0x00060>, + <0 0xe1250080 0 0x00004>; interrupt-parent = <&gic>; interrupts = <0 325 4>, - <0 326 1>, <0 327 1>, <0 328 1>, <0 329 1>; + <0 326 1>, <0 327 1>, <0 328 1>, <0 329 1>, + <0 323 4>; amd,per-channel-interrupt; clocks = <&xgbe_dma_clk>, <&xgbe_ptp_clk>; clock-names = "dma_clk", "ptp_clk"; - phy-handle = <&phy>; phy-mode = "xgmii"; mac-address = [ 02 a1 a2 a3 a4 a5 ]; + amd,speed-set = <0>; + amd,serdes-blwc = <1>, <1>, <0>; + amd,serdes-cdr-rate = <2>, <2>, <7>; + amd,serdes-pq-skew = <10>, <10>, <30>; + amd,serdes-tx-amp = <15>, <15>, <10>; + amd,serdes-dfe-tap-config = <3>, <3>, <1>; + amd,serdes-dfe-tap-enable = <0>, <0>, <127>; }; diff --git a/Documentation/devicetree/bindings/net/ezchip_enet.txt b/Documentation/devicetree/bindings/net/ezchip_enet.txt new file mode 100644 index 000000000000..4e29b2b82873 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ezchip_enet.txt @@ -0,0 +1,15 @@ +* EZchip NPS Management Ethernet port driver + +Required properties: +- compatible: Should be "ezchip,nps-mgt-enet" +- reg: Address and length of the register set for the device +- interrupts: Should contain the ENET interrupt + +Examples: + + ethernet@f0003000 { + compatible = "ezchip,nps-mgt-enet"; + reg = <0xf0003000 0x44>; + interrupts = <7>; + mac-address = [ 00 11 22 33 44 55 ]; + }; diff --git a/Documentation/devicetree/bindings/net/ipq806x-dwmac.txt b/Documentation/devicetree/bindings/net/ipq806x-dwmac.txt new file mode 100644 index 000000000000..6d7ab4e524d4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ipq806x-dwmac.txt @@ -0,0 +1,35 @@ +* IPQ806x DWMAC Ethernet controller + +The device inherits all the properties of the dwmac/stmmac devices +described in the file net/stmmac.txt with the following changes. + +Required properties: + +- compatible: should be "qcom,ipq806x-gmac" along with "snps,dwmac" + and any applicable more detailed version number + described in net/stmmac.txt + +- qcom,nss-common: should contain a phandle to a syscon device mapping the + nss-common registers. + +- qcom,qsgmii-csr: should contain a phandle to a syscon device mapping the + qsgmii-csr registers. + +Example: + + gmac: ethernet@37000000 { + device_type = "network"; + compatible = "qcom,ipq806x-gmac"; + reg = <0x37000000 0x200000>; + interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + + qcom,nss-common = <&nss_common>; + qcom,qsgmii-csr = <&qsgmii_csr>; + + clocks = <&gcc GMAC_CORE1_CLK>; + clock-names = "stmmaceth"; + + resets = <&gcc GMAC_CORE1_RESET>; + reset-names = "stmmaceth"; + }; diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index ba19d671e808..b5d79761ac97 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -7,8 +7,10 @@ Required properties: Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb". Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on the Cadence GEM, or the generic form: "cdns,gem". - Use "cdns,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs. - Use "cdns,sama5d4-gem" for the Gigabit IP available on Atmel sama5d4 SoCs. + Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 SoCs. + Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs. + Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs. + Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC. - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt - phy-mode: See ethernet.txt file in the same directory. diff --git a/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt b/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt new file mode 100644 index 000000000000..7c4a0cc370cf --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt @@ -0,0 +1,29 @@ +* Marvell International Ltd. NCI NFC Controller + +Required properties: +- compatible: Should be "mrvl,nfc-uart". + +Optional SoC specific properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. +- reset-n-io: Output GPIO pin used to reset the chip (active low). +- hci-muxed: Specifies that the chip is muxing NCI over HCI frames. + +Optional UART-based chip specific properties: +- flow-control: Specifies that the chip is using RTS/CTS. +- break-control: Specifies that the chip needs specific break management. + +Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): + +&uart5 { + status = "okay"; + + nfcmrvluart: nfcmrvluart@5 { + compatible = "mrvl,nfc-uart"; + + reset-n-io = <&gpio3 16 0>; + + hci-muxed; + flow-control; + } +}; diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfcb.txt b/Documentation/devicetree/bindings/net/nfc/st-nci.txt index bb237072dbe9..d707588ed734 100644 --- a/Documentation/devicetree/bindings/net/nfc/st21nfcb.txt +++ b/Documentation/devicetree/bindings/net/nfc/st-nci.txt @@ -1,7 +1,7 @@ -* STMicroelectronics SAS. ST21NFCB NFC Controller +* STMicroelectronics SAS. ST NCI NFC Controller Required properties: -- compatible: Should be "st,st21nfcb-i2c". +- compatible: Should be "st,st21nfcb-i2c" or "st,st21nfcc-i2c". - clock-frequency: I²C work frequency. - reg: address on the bus - interrupt-parent: phandle for the interrupt gpio controller diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt index 7c89ca290ced..32b35a07abe4 100644 --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt @@ -18,6 +18,9 @@ Optional SoC Specific Properties: "IRQ Status Read" erratum. - en2-rf-quirk: Specify that the trf7970a being used has the "EN2 RF" erratum. +- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum + where an extra byte is returned by Read Multiple Block commands issued + to Type 5 tags. Example (for ARM-based BeagleBone with TRF7970A on SPI1): @@ -39,6 +42,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1): autosuspend-delay = <30000>; irq-status-read-quirk; en2-rf-quirk; + t5t-rmb-extra-byte-quirk; status = "okay"; }; }; diff --git a/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt b/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt new file mode 100644 index 000000000000..7edba1264f6f --- /dev/null +++ b/Documentation/devicetree/bindings/net/nxp,lpc1850-dwmac.txt @@ -0,0 +1,20 @@ +* NXP LPC1850 GMAC ethernet controller + +This device is a platform glue layer for stmmac. +Please see stmmac.txt for the other unchanged properties. + +Required properties: + - compatible: Should contain "nxp,lpc1850-dwmac" + +Examples: + +mac: ethernet@40010000 { + compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", "snps,dwmac"; + reg = <0x40010000 0x2000>; + interrupts = <5>; + interrupt-names = "macirq"; + clocks = <&ccu1 CLK_CPU_ETHERNET>; + clock-names = "stmmaceth"; + resets = <&rgu 22>; + reset-names = "stmmaceth"; +} diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt index 40831fbaff72..525e1658f2da 100644 --- a/Documentation/devicetree/bindings/net/phy.txt +++ b/Documentation/devicetree/bindings/net/phy.txt @@ -30,6 +30,9 @@ Optional Properties: - max-speed: Maximum PHY supported speed (10, 100, 1000...) +- broken-turn-around: If set, indicates the PHY device does not correctly + release the turn around line low at the end of a MDIO transaction. + Example: ethernet-phy@0 { diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt new file mode 100644 index 000000000000..1fd8831437bf --- /dev/null +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -0,0 +1,48 @@ +* Renesas Electronics Ethernet AVB + +This file provides information on what the device node for the Ethernet AVB +interface contains. + +Required properties: +- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC. + "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. +- reg: offset and length of (1) the register block and (2) the stream buffer. +- interrupts: interrupt specifier for the sole interrupt. +- phy-mode: see ethernet.txt file in the same directory. +- phy-handle: see ethernet.txt file in the same directory. +- #address-cells: number of address cells for the MDIO bus, must be equal to 1. +- #size-cells: number of size cells on the MDIO bus, must be equal to 0. +- clocks: clock phandle and specifier pair. +- pinctrl-0: phandle, referring to a default pin configuration node. + +Optional properties: +- interrupt-parent: the phandle for the interrupt controller that services + interrupts for this device. +- pinctrl-names: pin configuration state name ("default"). +- renesas,no-ether-link: boolean, specify when a board does not provide a proper + AVB_LINK signal. +- renesas,ether-link-active-low: boolean, specify when the AVB_LINK signal is + active-low instead of normal active-high. + +Example: + + ethernet@e6800000 { + compatible = "renesas,etheravb-r8a7790"; + reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>; + interrupt-parent = <&gic>; + interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>; + phy-mode = "rmii"; + phy-handle = <&phy0>; + pinctrl-0 = <ðer_pins>; + pinctrl-names = "default"; + renesas,no-ether-link; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + interrupt-parent = <&gpio2>; + interrupts = <15 IRQ_TYPE_LEVEL_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt index 21fd199e89b5..93eac7ce1446 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt @@ -3,7 +3,7 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC) The device node has following properties. Required properties: - - compatible: Can be "rockchip,rk3288-gmac". + - compatible: Can be one of "rockchip,rk3288-gmac", "rockchip,rk3368-gmac" - reg: addresses and length of the register sets for the device. - interrupts: Should contain the GMAC interrupts. - interrupt-names: Should contain the interrupt names "macirq". diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt new file mode 100644 index 000000000000..58d935b58598 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt @@ -0,0 +1,25 @@ +* Texas Instruments - dp83867 Giga bit ethernet phy + +Required properties: + - reg - The ID number for the phy, usually a small integer + - ti,rx-internal-delay - RGMII Recieve Clock Delay - see dt-bindings/net/ti-dp83867.h + for applicable values + - ti,tx-internal-delay - RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h + for applicable values + - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h + for applicable values + +Default child nodes are standard Ethernet PHY device +nodes as described in Documentation/devicetree/bindings/net/phy.txt + +Example: + + ethernet-phy@0 { + reg = <0>; + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>; + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>; + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; + }; + +Datasheet can be found: +http://www.ti.com/product/DP83867IR/datasheet diff --git a/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt b/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt new file mode 100644 index 000000000000..36d881c8e6d4 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/xgene-pci-msi.txt @@ -0,0 +1,68 @@ +* AppliedMicro X-Gene v1 PCIe MSI controller + +Required properties: + +- compatible: should be "apm,xgene1-msi" to identify + X-Gene v1 PCIe MSI controller block. +- msi-controller: indicates that this is X-Gene v1 PCIe MSI controller node +- reg: physical base address (0x79000000) and length (0x900000) for controller + registers. These registers include the MSI termination address and data + registers as well as the MSI interrupt status registers. +- reg-names: not required +- interrupts: A list of 16 interrupt outputs of the controller, starting from + interrupt number 0x10 to 0x1f. +- interrupt-names: not required + +Each PCIe node needs to have property msi-parent that points to msi controller node + +Examples: + +SoC DTSI: + + + MSI node: + msi@79000000 { + compatible = "apm,xgene1-msi"; + msi-controller; + reg = <0x00 0x79000000 0x0 0x900000>; + interrupts = <0x0 0x10 0x4> + <0x0 0x11 0x4> + <0x0 0x12 0x4> + <0x0 0x13 0x4> + <0x0 0x14 0x4> + <0x0 0x15 0x4> + <0x0 0x16 0x4> + <0x0 0x17 0x4> + <0x0 0x18 0x4> + <0x0 0x19 0x4> + <0x0 0x1a 0x4> + <0x0 0x1b 0x4> + <0x0 0x1c 0x4> + <0x0 0x1d 0x4> + <0x0 0x1e 0x4> + <0x0 0x1f 0x4>; + }; + + + PCIe controller node with msi-parent property pointing to MSI node: + pcie0: pcie@1f2b0000 { + status = "disabled"; + device_type = "pci"; + compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie"; + #interrupt-cells = <1>; + #size-cells = <2>; + #address-cells = <3>; + reg = < 0x00 0x1f2b0000 0x0 0x00010000 /* Controller registers */ + 0xe0 0xd0000000 0x0 0x00040000>; /* PCI config space */ + reg-names = "csr", "cfg"; + ranges = <0x01000000 0x00 0x00000000 0xe0 0x10000000 0x00 0x00010000 /* io */ + 0x02000000 0x00 0x80000000 0xe1 0x80000000 0x00 0x80000000>; /* mem */ + dma-ranges = <0x42000000 0x80 0x00000000 0x80 0x00000000 0x00 0x80000000 + 0x42000000 0x00 0x00000000 0x00 0x00000000 0x80 0x00000000>; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0xc2 0x1 + 0x0 0x0 0x0 0x2 &gic 0x0 0xc3 0x1 + 0x0 0x0 0x0 0x3 &gic 0x0 0xc4 0x1 + 0x0 0x0 0x0 0x4 &gic 0x0 0xc5 0x1>; + dma-coherent; + clocks = <&pcie0clk 0>; + msi-parent= <&msi>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index fdd8046e650a..9462ab7ddd1f 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -16,6 +16,8 @@ Required properties: "allwinner,sun7i-a20-pinctrl" "allwinner,sun8i-a23-pinctrl" "allwinner,sun8i-a23-r-pinctrl" + "allwinner,sun8i-a33-pinctrl" + - reg: Should contain the register physical address and length for the pin controller. diff --git a/Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt new file mode 100644 index 000000000000..08a4a32c8eb0 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt @@ -0,0 +1,217 @@ +Imagination Technologies Pistachio SoC pin controllers +====================================================== + +The pin controllers on Pistachio are a combined GPIO controller, (GPIO) +interrupt controller, and pinmux + pinconf device. The system ("east") pin +controller on Pistachio has 99 pins, 90 of which are MFIOs which can be +configured as GPIOs. The 90 GPIOs are divided into 6 banks of up to 16 GPIOs +each. The GPIO banks are represented as sub-nodes of the pad controller node. + +Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and +../interrupt-controller/interrupts.txt for generic information regarding +pin controller, GPIO, and interrupt bindings. + +Required properties for pin controller node: +-------------------------------------------- + - compatible: "img,pistachio-system-pinctrl". + - reg: Address range of the pinctrl registers. + +Required properties for GPIO bank sub-nodes: +-------------------------------------------- + - interrupts: Interrupt line for the GPIO bank. + - gpio-controller: Indicates the device is a GPIO controller. + - #gpio-cells: Must be two. The first cell is the GPIO pin number and the + second cell indicates the polarity. See <dt-bindings/gpio/gpio.h> for + a list of possible values. + - interrupt-controller: Indicates the device is an interrupt controller. + - #interrupt-cells: Must be two. The first cell is the GPIO pin number and + the second cell encodes the interrupt flags. See + <dt-bindings/interrupt-controller/irq.h> for a list of valid flags. + +Note that the N GPIO bank sub-nodes *must* be named gpio0, gpio1, ... gpioN-1. + +Required properties for pin configuration sub-nodes: +---------------------------------------------------- + - pins: List of pins to which the configuration applies. See below for a + list of possible pins. + +Optional properties for pin configuration sub-nodes: +---------------------------------------------------- + - function: Mux function for the specified pins. This is not applicable for + non-MFIO pins. See below for a list of valid functions for each pin. + - bias-high-impedance: Enable high-impedance mode. + - bias-pull-up: Enable weak pull-up. + - bias-pull-down: Enable weak pull-down. + - bias-bus-hold: Enable bus-keeper mode. + - drive-strength: Drive strength in mA. Supported values: 2, 4, 8, 12. + - input-schmitt-enable: Enable Schmitt trigger. + - input-schmitt-disable: Disable Schmitt trigger. + - slew-rate: Slew rate control. 0 for slow, 1 for fast. + +Pin Functions +--- --------- +mfio0 spim1 +mfio1 spim1, spim0, uart1 +mfio2 spim1, spim0, uart1 +mfio3 spim1 +mfio4 spim1 +mfio5 spim1 +mfio6 spim1 +mfio7 spim1 +mfio8 spim0 +mfio9 spim0 +mfio10 spim0 +mfio11 spis +mfio12 spis +mfio13 spis +mfio14 spis +mfio15 sdhost, mips_trace_clk, mips_trace_data +mfio16 sdhost, mips_trace_dint, mips_trace_data +mfio17 sdhost, mips_trace_trigout, mips_trace_data +mfio18 sdhost, mips_trace_trigin, mips_trace_data +mfio19 sdhost, mips_trace_dm, mips_trace_data +mfio20 sdhost, mips_trace_probe_n, mips_trace_data +mfio21 sdhost, mips_trace_data +mfio22 sdhost, mips_trace_data +mfio23 sdhost +mfio24 sdhost +mfio25 sdhost +mfio26 sdhost +mfio27 sdhost +mfio28 i2c0, spim0 +mfio29 i2c0, spim0 +mfio30 i2c1, spim0 +mfio31 i2c1, spim1 +mfio32 i2c2 +mfio33 i2c2 +mfio34 i2c3 +mfio35 i2c3 +mfio36 i2s_out, audio_clk_in +mfio37 i2s_out, debug_raw_cca_ind +mfio38 i2s_out, debug_ed_sec20_cca_ind +mfio39 i2s_out, debug_ed_sec40_cca_ind +mfio40 i2s_out, debug_agc_done_0 +mfio41 i2s_out, debug_agc_done_1 +mfio42 i2s_out, debug_ed_cca_ind +mfio43 i2s_out, debug_s2l_done +mfio44 i2s_out +mfio45 i2s_dac_clk, audio_sync +mfio46 audio_trigger +mfio47 i2s_in +mfio48 i2s_in +mfio49 i2s_in +mfio50 i2s_in +mfio51 i2s_in +mfio52 i2s_in +mfio53 i2s_in +mfio54 i2s_in, spdif_in +mfio55 uart0, spim0, spim1 +mfio56 uart0, spim0, spim1 +mfio57 uart0, spim0, spim1 +mfio58 uart0, spim1 +mfio59 uart1 +mfio60 uart1 +mfio61 spdif_out +mfio62 spdif_in +mfio63 eth, mips_trace_clk, mips_trace_data +mfio64 eth, mips_trace_dint, mips_trace_data +mfio65 eth, mips_trace_trigout, mips_trace_data +mfio66 eth, mips_trace_trigin, mips_trace_data +mfio67 eth, mips_trace_dm, mips_trace_data +mfio68 eth, mips_trace_probe_n, mips_trace_data +mfio69 eth, mips_trace_data +mfio70 eth, mips_trace_data +mfio71 eth +mfio72 ir +mfio73 pwmpdm, mips_trace_clk, sram_debug +mfio74 pwmpdm, mips_trace_dint, sram_debug +mfio75 pwmpdm, mips_trace_trigout, rom_debug +mfio76 pwmpdm, mips_trace_trigin, rom_debug +mfio77 mdc_debug, mips_trace_dm, rpu_debug +mfio78 mdc_debug, mips_trace_probe_n, rpu_debug +mfio79 ddr_debug, mips_trace_data, mips_debug +mfio80 ddr_debug, mips_trace_data, mips_debug +mfio81 dreq0, mips_trace_data, eth_debug +mfio82 dreq1, mips_trace_data, eth_debug +mfio83 mips_pll_lock, mips_trace_data, usb_debug +mfio84 sys_pll_lock, mips_trace_data, usb_debug +mfio85 wifi_pll_lock, mips_trace_data, sdhost_debug +mfio86 bt_pll_lock, mips_trace_data, sdhost_debug +mfio87 rpu_v_pll_lock, dreq2, socif_debug +mfio88 rpu_l_pll_lock, dreq3, socif_debug +mfio89 audio_pll_lock, dreq4, dreq5 +tck +trstn +tdi +tms +tdo +jtag_comply +safe_mode +por_disable +resetn + +Example: +-------- +pinctrl@18101C00 { + compatible = "img,pistachio-system-pinctrl"; + reg = <0x18101C00 0x400>; + + gpio0: gpio0 { + interrupts = <GIC_SHARED 71 IRQ_TYPE_LEVEL_HIGH>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + ... + + gpio5: gpio5 { + interrupts = <GIC_SHARED 76 IRQ_TYPE_LEVEL_HIGH>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + ... + + uart0_xfer: uart0-xfer { + uart0-rxd { + pins = "mfio55"; + function = "uart0"; + }; + uart0-txd { + pins = "mfio56"; + function = "uart0"; + }; + }; + + uart0_rts_cts: uart0-rts-cts { + uart0-rts { + pins = "mfio57"; + function = "uart0"; + }; + uart0-cts { + pins = "mfio58"; + function = "uart0"; + }; + }; +}; + +uart@... { + ... + pinctrl-names = "default"; + pinctrl-0 = <&uart0_xfer>, <&uart0_rts_cts>; + ... +}; + +usb_vbus: fixed-regulator { + ... + gpio = <&gpio5 6 GPIO_ACTIVE_HIGH>; + ... +}; diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt index adda2a8d1d52..add7c38ec7d8 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt @@ -17,10 +17,10 @@ mpp0 0 gpio, uart0(rxd) mpp1 1 gpo, uart0(txd) mpp2 2 gpio, i2c0(sck), uart0(txd) mpp3 3 gpio, i2c0(sda), uart0(rxd) -mpp4 4 gpio, cpu_pd(vdd) -mpp5 5 gpo, ge0(txclko), uart1(txd), spi1(clk), audio(mclk) +mpp4 4 gpio, vdd(cpu-pd) +mpp5 5 gpo, ge0(txclkout), uart1(txd), spi1(sck), audio(mclk) mpp6 6 gpio, ge0(txd0), sata0(prsnt), tdm(rst), audio(sdo) -mpp7 7 gpo, ge0(txd1), tdm(tdx), audio(lrclk) +mpp7 7 gpo, ge0(txd1), tdm(dtx), audio(lrclk) mpp8 8 gpio, ge0(txd2), uart0(rts), tdm(drx), audio(bclk) mpp9 9 gpo, ge0(txd3), uart1(txd), sd0(clk), audio(spdifo) mpp10 10 gpio, ge0(txctl), uart0(cts), tdm(fsync), audio(sdi) @@ -52,8 +52,8 @@ mpp30 30 gpio, ge0(rxd7), ge1(rxclk), i2c1(sck) mpp31 31 gpio, tclk, ge0(txerr) mpp32 32 gpio, spi0(cs0) mpp33 33 gpio, dev(bootcs), spi0(cs0) -mpp34 34 gpo, dev(wen0), spi0(mosi) -mpp35 35 gpo, dev(oen), spi0(sck) +mpp34 34 gpo, dev(we0), spi0(mosi) +mpp35 35 gpo, dev(oe), spi0(sck) mpp36 36 gpo, dev(a1), spi0(miso) mpp37 37 gpo, dev(a0), sata0(prsnt) mpp38 38 gpio, dev(ready), uart1(cts), uart0(cts) @@ -86,11 +86,11 @@ mpp57 57 gpio, dev(cs3), uart1(rxd), tdm(fsync), sata0(prsnt), mpp58 58 gpio, dev(cs0), uart1(rts), tdm(int), audio(extclk), uart0(rts) mpp59 59 gpo, dev(ale0), uart1(rts), uart0(rts), audio(bclk) -mpp60 60 gpio, dev(ale1), uart1(rxd), sata0(prsnt), pcie(rst-out), +mpp60 60 gpio, dev(ale1), uart1(rxd), sata0(prsnt), pcie(rstout), audio(sdi) -mpp61 61 gpo, dev(wen1), uart1(txd), audio(rclk) +mpp61 61 gpo, dev(we1), uart1(txd), audio(lrclk) mpp62 62 gpio, dev(a2), uart1(cts), tdm(drx), pcie(clkreq0), audio(mclk), uart0(cts) mpp63 63 gpo, spi0(sck), tclk -mpp64 64 gpio, spi0(miso), spi0-1(cs1) -mpp65 65 gpio, spi0(mosi), spi0-1(cs2) +mpp64 64 gpio, spi0(miso), spi0(cs1) +mpp65 65 gpio, spi0(mosi), spi0(cs2) diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt index 7de0cda4a379..06e5bb0367f5 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt @@ -15,24 +15,24 @@ name pins functions ================================================================================ mpp0 0 gpio, dev(ad2), spi0(cs1), spi1(cs1) mpp1 1 gpio, dev(ad3), spi0(mosi), spi1(mosi) -mpp2 2 gpio, dev(ad4), ptp(eventreq), led(c0), audio(sdi) -mpp3 3 gpio, dev(ad5), ptp(triggen), led(p3), audio(mclk) +mpp2 2 gpio, dev(ad4), ptp(evreq), led(c0), audio(sdi) +mpp3 3 gpio, dev(ad5), ptp(trig), led(p3), audio(mclk) mpp4 4 gpio, dev(ad6), spi0(miso), spi1(miso) mpp5 5 gpio, dev(ad7), spi0(cs2), spi1(cs2) -mpp6 6 gpio, dev(ad0), led(p1), audio(rclk) +mpp6 6 gpio, dev(ad0), led(p1), audio(lrclk) mpp7 7 gpio, dev(ad1), ptp(clk), led(p2), audio(extclk) mpp8 8 gpio, dev (bootcs), spi0(cs0), spi1(cs0) -mpp9 9 gpio, nf(wen), spi0(sck), spi1(sck) -mpp10 10 gpio, nf(ren), dram(vttctrl), led(c1) +mpp9 9 gpio, spi0(sck), spi1(sck), nand(we) +mpp10 10 gpio, dram(vttctrl), led(c1), nand(re) mpp11 11 gpio, dev(a0), led(c2), audio(sdo) mpp12 12 gpio, dev(a1), audio(bclk) -mpp13 13 gpio, dev(readyn), pcie0(rstoutn), pcie1(rstoutn) +mpp13 13 gpio, dev(ready), pcie0(rstout), pcie1(rstout) mpp14 14 gpio, i2c0(sda), uart1(txd) mpp15 15 gpio, i2c0(sck), uart1(rxd) mpp16 16 gpio, uart0(txd) mpp17 17 gpio, uart0(rxd) -mpp18 18 gpio, tdm(intn) -mpp19 19 gpio, tdm(rstn) +mpp18 18 gpio, tdm(int) +mpp19 19 gpio, tdm(rst) mpp20 20 gpio, tdm(pclk) mpp21 21 gpio, tdm(fsync) mpp22 22 gpio, tdm(drx) @@ -45,12 +45,12 @@ mpp28 28 gpio, led(p3), ge1(txctl), sd(clk) mpp29 29 gpio, pcie1(clkreq), ge1(rxclk), sd(d3) mpp30 30 gpio, ge1(txd0), spi1(cs0) mpp31 31 gpio, ge1(txd1), spi1(mosi) -mpp32 32 gpio, ge1(txd2), spi1(sck), ptp(triggen) +mpp32 32 gpio, ge1(txd2), spi1(sck), ptp(trig) mpp33 33 gpio, ge1(txd3), spi1(miso) mpp34 34 gpio, ge1(txclkout), spi1(sck) mpp35 35 gpio, ge1(rxctl), spi1(cs1), spi0(cs2) mpp36 36 gpio, pcie0(clkreq) -mpp37 37 gpio, pcie0(clkreq), tdm(intn), ge(mdc) +mpp37 37 gpio, pcie0(clkreq), tdm(int), ge(mdc) mpp38 38 gpio, pcie1(clkreq), ge(mdio) mpp39 39 gpio, ref(clkout) mpp40 40 gpio, uart1(txd) @@ -58,25 +58,25 @@ mpp41 41 gpio, uart1(rxd) mpp42 42 gpio, spi1(cs2), led(c0) mpp43 43 gpio, sata0(prsnt), dram(vttctrl) mpp44 44 gpio, sata0(prsnt) -mpp45 45 gpio, spi0(cs2), pcie0(rstoutn) -mpp46 46 gpio, led(p0), ge0(txd0), ge1(txd0) +mpp45 45 gpio, spi0(cs2), pcie0(rstout) +mpp46 46 gpio, led(p0), ge0(txd0), ge1(txd0), dev(we1) mpp47 47 gpio, led(p1), ge0(txd1), ge1(txd1) mpp48 48 gpio, led(p2), ge0(txd2), ge1(txd2) mpp49 49 gpio, led(p3), ge0(txd3), ge1(txd3) mpp50 50 gpio, led(c0), ge0(rxd0), ge1(rxd0) mpp51 51 gpio, led(c1), ge0(rxd1), ge1(rxd1) mpp52 52 gpio, led(c2), ge0(rxd2), ge1(rxd2) -mpp53 53 gpio, pcie1(rstoutn), ge0(rxd3), ge1(rxd3) -mpp54 54 gpio, pcie0(rstoutn), ge0(rxctl), ge1(rxctl) +mpp53 53 gpio, pcie1(rstout), ge0(rxd3), ge1(rxd3) +mpp54 54 gpio, pcie0(rstout), ge0(rxctl), ge1(rxctl) mpp55 55 gpio, ge0(rxclk), ge1(rxclk) mpp56 56 gpio, ge0(txclkout), ge1(txclkout) -mpp57 57 gpio, ge0(txctl), ge1(txctl) +mpp57 57 gpio, ge0(txctl), ge1(txctl), dev(we0) mpp58 58 gpio, led(c0) mpp59 59 gpio, led(c1) mpp60 60 gpio, uart1(txd), led(c2) mpp61 61 gpio, i2c1(sda), uart1(rxd), spi1(cs2), led(p0) mpp62 62 gpio, i2c1(sck), led(p1) -mpp63 63 gpio, ptp(triggen), led(p2) +mpp63 63 gpio, ptp(trig), led(p2), dev(burst/last) mpp64 64 gpio, dram(vttctrl), led(p3) mpp65 65 gpio, sata1(prsnt) -mpp66 66 gpio, ptp(eventreq), spi1(cs3) +mpp66 66 gpio, ptp(evreq), spi1(cs3) diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt index b17c96849fc9..54ec4c0a0d0e 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt @@ -27,16 +27,16 @@ mpp8 8 gpio, ge0(txd1), dev(ad10) mpp9 9 gpio, ge0(txd2), dev(ad11) mpp10 10 gpio, ge0(txd3), dev(ad12) mpp11 11 gpio, ge0(txctl), dev(ad13) -mpp12 12 gpio, ge0(rxd0), pcie0(rstout), pcie1(rstout) [1], spi0(cs1), dev(ad14) -mpp13 13 gpio, ge0(rxd1), pcie0(clkreq), pcie1(clkreq) [1], spi0(cs2), dev(ad15) -mpp14 14 gpio, ge0(rxd2), ptp(clk), m(vtt_ctrl), spi0(cs3), dev(wen1) -mpp15 15 gpio, ge0(rxd3), ge(mdc slave), pcie0(rstout), spi0(mosi), pcie1(rstout) [1] -mpp16 16 gpio, ge0(rxctl), ge(mdio slave), m(decc_err), spi0(miso), pcie0(clkreq) -mpp17 17 gpio, ge0(rxclk), ptp(clk), ua1(rxd), spi0(sck), sata1(prsnt) -mpp18 18 gpio, ge0(rxerr), ptp(trig_gen), ua1(txd), spi0(cs0), pcie1(rstout) [1] -mpp19 19 gpio, ge0(col), ptp(event_req), pcie0(clkreq), sata1(prsnt), ua0(cts) -mpp20 20 gpio, ge0(txclk), ptp(clk), pcie1(rstout) [1], sata0(prsnt), ua0(rts) -mpp21 21 gpio, spi0(cs1), ge1(rxd0), sata0(prsnt), sd0(cmd), dev(bootcs) +mpp12 12 gpio, ge0(rxd0), pcie0(rstout), spi0(cs1), dev(ad14), pcie3(clkreq) +mpp13 13 gpio, ge0(rxd1), pcie0(clkreq), pcie1(clkreq) [1], spi0(cs2), dev(ad15), pcie2(clkreq) +mpp14 14 gpio, ge0(rxd2), ptp(clk), dram(vttctrl), spi0(cs3), dev(we1), pcie3(clkreq) +mpp15 15 gpio, ge0(rxd3), ge(mdc slave), pcie0(rstout), spi0(mosi) +mpp16 16 gpio, ge0(rxctl), ge(mdio slave), dram(deccerr), spi0(miso), pcie0(clkreq), pcie1(clkreq) [1] +mpp17 17 gpio, ge0(rxclk), ptp(clk), ua1(rxd), spi0(sck), sata1(prsnt), sata0(prsnt) +mpp18 18 gpio, ge0(rxerr), ptp(trig), ua1(txd), spi0(cs0) +mpp19 19 gpio, ge0(col), ptp(evreq), ge0(txerr), sata1(prsnt), ua0(cts) +mpp20 20 gpio, ge0(txclk), ptp(clk), sata0(prsnt), ua0(rts) +mpp21 21 gpio, spi0(cs1), ge1(rxd0), sata0(prsnt), sd0(cmd), dev(bootcs), sata1(prsnt) mpp22 22 gpio, spi0(mosi), dev(ad0) mpp23 23 gpio, spi0(sck), dev(ad2) mpp24 24 gpio, spi0(miso), ua0(cts), ua1(rxd), sd0(d4), dev(ready) @@ -45,36 +45,36 @@ mpp26 26 gpio, spi0(cs2), i2c1(sck), sd0(d6), dev(cs1) mpp27 27 gpio, spi0(cs3), ge1(txclkout), i2c1(sda), sd0(d7), dev(cs2) mpp28 28 gpio, ge1(txd0), sd0(clk), dev(ad5) mpp29 29 gpio, ge1(txd1), dev(ale0) -mpp30 30 gpio, ge1(txd2), dev(oen) +mpp30 30 gpio, ge1(txd2), dev(oe) mpp31 31 gpio, ge1(txd3), dev(ale1) -mpp32 32 gpio, ge1(txctl), dev(wen0) -mpp33 33 gpio, m(decc_err), dev(ad3) +mpp32 32 gpio, ge1(txctl), dev(we0) +mpp33 33 gpio, dram(deccerr), dev(ad3) mpp34 34 gpio, dev(ad1) mpp35 35 gpio, ref(clk_out1), dev(a1) -mpp36 36 gpio, ptp(trig_gen), dev(a0) +mpp36 36 gpio, ptp(trig), dev(a0) mpp37 37 gpio, ptp(clk), ge1(rxclk), sd0(d3), dev(ad8) -mpp38 38 gpio, ptp(event_req), ge1(rxd1), ref(clk_out0), sd0(d0), dev(ad4) +mpp38 38 gpio, ptp(evreq), ge1(rxd1), ref(clk_out0), sd0(d0), dev(ad4) mpp39 39 gpio, i2c1(sck), ge1(rxd2), ua0(cts), sd0(d1), dev(a2) mpp40 40 gpio, i2c1(sda), ge1(rxd3), ua0(rts), sd0(d2), dev(ad6) -mpp41 41 gpio, ua1(rxd), ge1(rxctl), ua0(cts), spi1(cs3), dev(burst/last) +mpp41 41 gpio, ua1(rxd), ge1(rxctl), ua0(cts), spi1(cs3), dev(burst/last), nand(rb0) mpp42 42 gpio, ua1(txd), ua0(rts), dev(ad7) -mpp43 43 gpio, pcie0(clkreq), m(vtt_ctrl), m(decc_err), pcie0(rstout), dev(clkout) -mpp44 44 gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], sata3(prsnt) [3], pcie0(rstout) -mpp45 45 gpio, ref(clk_out0), pcie0(rstout), pcie1(rstout) [1], pcie2(rstout), pcie3(rstout) -mpp46 46 gpio, ref(clk_out1), pcie0(rstout), pcie1(rstout) [1], pcie2(rstout), pcie3(rstout) -mpp47 47 gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], spi1(cs2), sata3(prsnt) [2] -mpp48 48 gpio, sata0(prsnt), m(vtt_ctrl), tdm2c(pclk), audio(mclk), sd0(d4) -mpp49 49 gpio, sata2(prsnt) [2], sata3(prsnt) [2], tdm2c(fsync), audio(lrclk), sd0(d5) -mpp50 50 gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(drx), audio(extclk), sd0(cmd) -mpp51 51 gpio, tdm2c(dtx), audio(sdo), m(decc_err) -mpp52 52 gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(intn), audio(sdi), sd0(d6) -mpp53 53 gpio, sata1(prsnt), sata0(prsnt), tdm2c(rstn), audio(bclk), sd0(d7) -mpp54 54 gpio, sata0(prsnt), sata1(prsnt), pcie0(rstout), pcie1(rstout) [1], sd0(d3) -mpp55 55 gpio, ua1(cts), ge(mdio), pcie1(clkreq) [1], spi1(cs1), sd0(d0) -mpp56 56 gpio, ua1(rts), ge(mdc), m(decc_err), spi1(mosi) -mpp57 57 gpio, spi1(sck), sd0(clk) -mpp58 58 gpio, pcie1(clkreq) [1], i2c1(sck), pcie2(clkreq), spi1(miso), sd0(d1) -mpp59 59 gpio, pcie0(rstout), i2c1(sda), pcie1(rstout) [1], spi1(cs0), sd0(d2) +mpp43 43 gpio, pcie0(clkreq), dram(vttctrl), dram(deccerr), spi1(cs2), dev(clkout), nand(rb1) +mpp44 44 gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], sata3(prsnt) [3] +mpp45 45 gpio, ref(clk_out0), pcie0(rstout), ua1(rxd) +mpp46 46 gpio, ref(clk_out1), pcie0(rstout), ua1(txd) +mpp47 47 gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], sata3(prsnt) [2] +mpp48 48 gpio, sata0(prsnt), dram(vttctrl), tdm(pclk), audio(mclk), sd0(d4), pcie0(clkreq) +mpp49 49 gpio, sata2(prsnt) [2], sata3(prsnt) [2], tdm(fsync), audio(lrclk), sd0(d5), pcie1(clkreq) +mpp50 50 gpio, pcie0(rstout), tdm(drx), audio(extclk), sd0(cmd) +mpp51 51 gpio, tdm(dtx), audio(sdo), dram(deccerr), ptp(trig) +mpp52 52 gpio, pcie0(rstout), tdm(int), audio(sdi), sd0(d6), ptp(clk) +mpp53 53 gpio, sata1(prsnt), sata0(prsnt), tdm(rst), audio(bclk), sd0(d7), ptp(evreq) +mpp54 54 gpio, sata0(prsnt), sata1(prsnt), pcie0(rstout), ge0(txerr), sd0(d3) +mpp55 55 gpio, ua1(cts), ge(mdio), pcie1(clkreq) [1], spi1(cs1), sd0(d0), ua1(rxd) +mpp56 56 gpio, ua1(rts), ge(mdc), dram(deccerr), spi1(mosi), ua1(txd) +mpp57 57 gpio, spi1(sck), sd0(clk), ua1(txd) +mpp58 58 gpio, pcie1(clkreq) [1], i2c1(sck), pcie2(clkreq), spi1(miso), sd0(d1), ua1(rxd) +mpp59 59 gpio, pcie0(rstout), i2c1(sda), spi1(cs0), sd0(d2) [1]: only available on 88F6820 and 88F6828 [2]: only available on 88F6828 diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-39x-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-39x-pinctrl.txt index 5b1a9dc004f4..a40b60f1ca4c 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-39x-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-39x-pinctrl.txt @@ -4,8 +4,9 @@ Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding part and usage. Required properties: -- compatible: "marvell,88f6920-pinctrl", "marvell,88f6928-pinctrl" - depending on the specific variant of the SoC being used. +- compatible: "marvell,88f6920-pinctrl", "marvell,88f6925-pinctrl" or + "marvell,88f6928-pinctrl" depending on the specific variant of the + SoC being used. - reg: register specifier of MPP registers Available mpp pins/groups and functions: @@ -24,55 +25,60 @@ mpp6 6 gpio, dev(cs3), xsmi(mdio) mpp7 7 gpio, dev(ad9), xsmi(mdc) mpp8 8 gpio, dev(ad10), ptp(trig) mpp9 9 gpio, dev(ad11), ptp(clk) -mpp10 10 gpio, dev(ad12), ptp(event) +mpp10 10 gpio, dev(ad12), ptp(evreq) mpp11 11 gpio, dev(ad13), led(clk) mpp12 12 gpio, pcie0(rstout), dev(ad14), led(stb) -mpp13 13 gpio, dev(ad15), led(data) -mpp14 14 gpio, m(vtt), dev(wen1), ua1(txd) +mpp13 13 gpio, dev(ad15), pcie2(clkreq), led(data) +mpp14 14 gpio, dram(vttctrl), dev(we1), ua1(txd) mpp15 15 gpio, pcie0(rstout), spi0(mosi), i2c1(sck) -mpp16 16 gpio, m(decc), spi0(miso), i2c1(sda) -mpp17 17 gpio, ua1(rxd), spi0(sck), smi(mdio) +mpp16 16 gpio, dram(deccerr), spi0(miso), pcie0(clkreq), i2c1(sda) +mpp17 17 gpio, ua1(rxd), spi0(sck), sata1(prsnt) [1], sata0(prsnt) [1], smi(mdio) mpp18 18 gpio, ua1(txd), spi0(cs0), i2c2(sck) -mpp19 19 gpio, sata1(present) [1], ua0(cts), ua1(rxd), i2c2(sda) -mpp20 20 gpio, sata0(present) [1], ua0(rts), ua1(txd), smi(mdc) -mpp21 21 gpio, spi0(cs1), sata0(present) [1], sd(cmd), dev(bootcs), ge(rxd0) +mpp19 19 gpio, sata1(prsnt) [1], ua0(cts), ua1(rxd), i2c2(sda) +mpp20 20 gpio, sata0(prsnt) [1], ua0(rts), ua1(txd), smi(mdc) +mpp21 21 gpio, spi0(cs1), sata0(prsnt) [1], sd0(cmd), dev(bootcs), + sata1(prsnt) [1], ge(rxd0) mpp22 22 gpio, spi0(mosi), dev(ad0) mpp23 23 gpio, spi0(sck), dev(ad2) -mpp24 24 gpio, spi0(miso), ua0(cts), ua1(rxd), sd(d4), dev(readyn) -mpp25 25 gpio, spi0(cs0), ua0(rts), ua1(txd), sd(d5), dev(cs0) -mpp26 26 gpio, spi0(cs2), i2c1(sck), sd(d6), dev(cs1) -mpp27 27 gpio, spi0(cs3), i2c1(sda), sd(d7), dev(cs2), ge(txclkout) -mpp28 28 gpio, sd(clk), dev(ad5), ge(txd0) +mpp24 24 gpio, spi0(miso), ua0(cts), ua1(rxd), sd0(d4), dev(ready) +mpp25 25 gpio, spi0(cs0), ua0(rts), ua1(txd), sd0(d5), dev(cs0) +mpp26 26 gpio, spi0(cs2), i2c1(sck), sd0(d6), dev(cs1) +mpp27 27 gpio, spi0(cs3), i2c1(sda), sd0(d7), dev(cs2), ge(txclkout) +mpp28 28 gpio, sd0(clk), dev(ad5), ge(txd0) mpp29 29 gpio, dev(ale0), ge(txd1) -mpp30 30 gpio, dev(oen), ge(txd2) +mpp30 30 gpio, dev(oe), ge(txd2) mpp31 31 gpio, dev(ale1), ge(txd3) -mpp32 32 gpio, dev(wen0), ge(txctl) -mpp33 33 gpio, m(decc), dev(ad3) +mpp32 32 gpio, dev(we0), ge(txctl) +mpp33 33 gpio, dram(deccerr), dev(ad3) mpp34 34 gpio, dev(ad1) mpp35 35 gpio, ref(clk), dev(a1) mpp36 36 gpio, dev(a0) -mpp37 37 gpio, sd(d3), dev(ad8), ge(rxclk) -mpp38 38 gpio, ref(clk), sd(d0), dev(ad4), ge(rxd1) -mpp39 39 gpio, i2c1(sck), ua0(cts), sd(d1), dev(a2), ge(rxd2) -mpp40 40 gpio, i2c1(sda), ua0(rts), sd(d2), dev(ad6), ge(rxd3) -mpp41 41 gpio, ua1(rxd), ua0(cts), spi1(cs3), dev(burstn), nd(rbn0), ge(rxctl) +mpp37 37 gpio, sd0(d3), dev(ad8), ge(rxclk) +mpp38 38 gpio, ref(clk), sd0(d0), dev(ad4), ge(rxd1) +mpp39 39 gpio, i2c1(sck), ua0(cts), sd0(d1), dev(a2), ge(rxd2) +mpp40 40 gpio, i2c1(sda), ua0(rts), sd0(d2), dev(ad6), ge(rxd3) +mpp41 41 gpio, ua1(rxd), ua0(cts), spi1(cs3), dev(burst/last), nand(rb0), ge(rxctl) mpp42 42 gpio, ua1(txd), ua0(rts), dev(ad7) -mpp43 43 gpio, pcie0(clkreq), m(vtt), m(decc), spi1(cs2), dev(clkout), nd(rbn1) -mpp44 44 gpio, sata0(present) [1], sata1(present) [1], led(clk) +mpp43 43 gpio, pcie0(clkreq), dram(vttctrl), dram(deccerr), spi1(cs2), dev(clkout), nand(rb1) +mpp44 44 gpio, sata0(prsnt) [1], sata1(prsnt) [1], sata2(prsnt) [2], + sata3(prsnt) [2], led(clk) mpp45 45 gpio, ref(clk), pcie0(rstout), ua1(rxd) mpp46 46 gpio, ref(clk), pcie0(rstout), ua1(txd), led(stb) -mpp47 47 gpio, sata0(present) [1], sata1(present) [1], led(data) -mpp48 48 gpio, sata0(present) [1], m(vtt), tdm(pclk) [1], audio(mclk) [1], sd(d4), pcie0(clkreq), ua1(txd) -mpp49 49 gpio, tdm(fsync) [1], audio(lrclk) [1], sd(d5), ua2(rxd) -mpp50 50 gpio, pcie0(rstout), tdm(drx) [1], audio(extclk) [1], sd(cmd), ua2(rxd) -mpp51 51 gpio, tdm(dtx) [1], audio(sdo) [1], m(decc), ua2(txd) -mpp52 52 gpio, pcie0(rstout), tdm(intn) [1], audio(sdi) [1], sd(d6), i2c3(sck) -mpp53 53 gpio, sata1(present) [1], sata0(present) [1], tdm(rstn) [1], audio(bclk) [1], sd(d7), i2c3(sda) -mpp54 54 gpio, sata0(present) [1], sata1(present) [1], pcie0(rstout), sd(d3), ua3(txd) -mpp55 55 gpio, ua1(cts), spi1(cs1), sd(d0), ua1(rxd), ua3(rxd) -mpp56 56 gpio, ua1(rts), m(decc), spi1(mosi), ua1(txd) -mpp57 57 gpio, spi1(sck), sd(clk), ua1(txd) -mpp58 58 gpio, i2c1(sck), pcie2(clkreq), spi1(miso), sd(d1), ua1(rxd) -mpp59 59 gpio, pcie0(rstout), i2c1(sda), spi1(cs0), sd(d2) +mpp47 47 gpio, sata0(prsnt) [1], sata1(prsnt) [1], sata2(prsnt) [2], + sata3(prsnt) [2], led(data) +mpp48 48 gpio, sata0(prsnt) [1], dram(vttctrl), tdm(pclk) [2], audio(mclk) [2], sd0(d4), pcie0(clkreq), ua1(txd) +mpp49 49 gpio, sata2(prsnt) [2], sata3(prsnt) [2], tdm(fsync) [2], + audio(lrclk) [2], sd0(d5), ua2(rxd) +mpp50 50 gpio, pcie0(rstout), tdm(drx) [2], audio(extclk) [2], sd0(cmd), ua2(rxd) +mpp51 51 gpio, tdm(dtx) [2], audio(sdo) [2], dram(deccerr), ua2(txd) +mpp52 52 gpio, pcie0(rstout), tdm(int) [2], audio(sdi) [2], sd0(d6), i2c3(sck) +mpp53 53 gpio, sata1(prsnt) [1], sata0(prsnt) [1], tdm(rst) [2], audio(bclk) [2], sd0(d7), i2c3(sda) +mpp54 54 gpio, sata0(prsnt) [1], sata1(prsnt) [1], pcie0(rstout), sd0(d3), ua3(txd) +mpp55 55 gpio, ua1(cts), spi1(cs1), sd0(d0), ua1(rxd), ua3(rxd) +mpp56 56 gpio, ua1(rts), dram(deccerr), spi1(mosi), ua1(txd) +mpp57 57 gpio, spi1(sck), sd0(clk), ua1(txd) +mpp58 58 gpio, i2c1(sck), pcie2(clkreq), spi1(miso), sd0(d1), ua1(rxd) +mpp59 59 gpio, pcie0(rstout), i2c1(sda), spi1(cs0), sd0(d2) -[1]: only available on 88F6928 +[1]: only available on 88F6925/88F6928 +[2]: only available on 88F6928 diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt index 373dbccd7ab0..76da7222ff92 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt @@ -18,7 +18,7 @@ only for more detailed description in this document. name pins functions ================================================================================ -mpp0 0 gpio, ge0(txclko), lcd(d0) +mpp0 0 gpio, ge0(txclkout), lcd(d0) mpp1 1 gpio, ge0(txd0), lcd(d1) mpp2 2 gpio, ge0(txd1), lcd(d2) mpp3 3 gpio, ge0(txd2), lcd(d3) @@ -30,49 +30,50 @@ mpp8 8 gpio, ge0(rxd2), lcd(d8) mpp9 9 gpio, ge0(rxd3), lcd(d9) mpp10 10 gpio, ge0(rxctl), lcd(d10) mpp11 11 gpio, ge0(rxclk), lcd(d11) -mpp12 12 gpio, ge0(txd4), ge1(txd0), lcd(d12) -mpp13 13 gpio, ge0(txd5), ge1(txd1), lcd(d13) -mpp14 14 gpio, ge0(txd6), ge1(txd2), lcd(d15) -mpp15 15 gpio, ge0(txd7), ge1(txd3), lcd(d16) -mpp16 16 gpio, ge0(txd7), ge1(txd3), lcd(d16) -mpp17 17 gpio, ge0(col), ge1(txctl), lcd(d17) +mpp12 12 gpio, ge0(txd4), ge1(txclkout), lcd(d12) +mpp13 13 gpio, ge0(txd5), ge1(txd0), spi1(mosi), lcd(d13) +mpp14 14 gpio, ge0(txd6), ge1(txd1), spi1(sck), lcd(d15) +mpp15 15 gpio, ge0(txd7), ge1(txd2), lcd(d16) +mpp16 16 gpio, ge0(txd7), ge1(txd3), spi1(cs0), lcd(d16) +mpp17 17 gpio, ge0(col), ge1(txctl), spi1(miso), lcd(d17) mpp18 18 gpio, ge0(rxerr), ge1(rxd0), lcd(d18), ptp(trig) mpp19 19 gpio, ge0(crs), ge1(rxd1), lcd(d19), ptp(evreq) mpp20 20 gpio, ge0(rxd4), ge1(rxd2), lcd(d20), ptp(clk) -mpp21 21 gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat) +mpp21 21 gpio, ge0(rxd5), ge1(rxd3), lcd(d21), dram(bat) mpp22 22 gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt) mpp23 23 gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt) -mpp24 24 gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst) -mpp25 25 gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk) -mpp26 26 gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd) +mpp24 24 gpio, lcd(hsync), sata1(prsnt), tdm(rst) +mpp25 25 gpio, lcd(vsync), sata0(prsnt), tdm(pclk) +mpp26 26 gpio, lcd(clk), tdm(fsync) mpp27 27 gpio, lcd(e), tdm(dtx), ptp(trig) mpp28 28 gpio, lcd(pwm), tdm(drx), ptp(evreq) -mpp29 29 gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd) +mpp29 29 gpio, lcd(ref-clk), tdm(int0), ptp(clk) mpp30 30 gpio, tdm(int1), sd0(clk) -mpp31 31 gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd) -mpp32 32 gpio, tdm(int3), sd0(d0), vdd(cpu1-pd) -mpp33 33 gpio, tdm(int4), sd0(d1), mem(bat) -mpp34 34 gpio, tdm(int5), sd0(d2), sata0(prsnt) +mpp31 31 gpio, tdm(int2), sd0(cmd) +mpp32 32 gpio, tdm(int3), sd0(d0) +mpp33 33 gpio, tdm(int4), sd0(d1), dram(bat), dram(vttctrl) +mpp34 34 gpio, tdm(int5), sd0(d2), sata0(prsnt), dram(deccerr) mpp35 35 gpio, tdm(int6), sd0(d3), sata1(prsnt) -mpp36 36 gpio, spi(mosi) -mpp37 37 gpio, spi(miso) -mpp38 38 gpio, spi(sck) -mpp39 39 gpio, spi(cs0) -mpp40 40 gpio, spi(cs1), uart2(cts), lcd(vga-hsync), vdd(cpu1-pd), - pcie(clkreq0) -mpp41 41 gpio, spi(cs2), uart2(rts), lcd(vga-vsync), sata1(prsnt), - pcie(clkreq1) -mpp42 42 gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer), - vdd(cpu0-pd) -mpp43 43 gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout), - vdd(cpu2-3-pd){1} -mpp44 44 gpio, uart2(cts), uart3(rxd), spi(cs4), pcie(clkreq2), - mem(bat) -mpp45 45 gpio, uart2(rts), uart3(txd), spi(cs5), sata1(prsnt) -mpp46 46 gpio, uart3(rts), uart1(rts), spi(cs6), sata0(prsnt) -mpp47 47 gpio, uart3(cts), uart1(cts), spi(cs7), pcie(clkreq3), - ref(clkout) -mpp48 48 gpio, tclk, dev(burst/last) +mpp36 36 gpio, spi0(mosi) +mpp37 37 gpio, spi0(miso) +mpp38 38 gpio, spi0(sck) +mpp39 39 gpio, spi0(cs0) +mpp40 40 gpio, spi0(cs1), uart2(cts), lcd(vga-hsync), pcie(clkreq0), + spi1(cs1) +mpp41 41 gpio, spi0(cs2), uart2(rts), lcd(vga-vsync), sata1(prsnt), + pcie(clkreq1), spi1(cs2) +mpp42 42 gpio, uart2(rxd), uart0(cts), tdm(int7), tdm(timer) +mpp43 43 gpio, uart2(txd), uart0(rts), spi0(cs3), pcie(rstout), + spi1(cs3) +mpp44 44 gpio, uart2(cts), uart3(rxd), spi0(cs4), pcie(clkreq2), + dram(bat), spi1(cs4) +mpp45 45 gpio, uart2(rts), uart3(txd), spi0(cs5), sata1(prsnt), + spi1(cs5), dram(vttctrl) +mpp46 46 gpio, uart3(rts), uart1(rts), spi0(cs6), sata0(prsnt), + spi1(cs6) +mpp47 47 gpio, uart3(cts), uart1(cts), spi0(cs7), pcie(clkreq3), + ref(clkout), spi1(cs7) +mpp48 48 gpio, dev(clkout), dev(burst/last), nand(rb) * Marvell Armada XP (mv78260 and mv78460 only) @@ -84,9 +85,9 @@ mpp51 51 gpio, dev(ad16) mpp52 52 gpio, dev(ad17) mpp53 53 gpio, dev(ad18) mpp54 54 gpio, dev(ad19) -mpp55 55 gpio, dev(ad20), vdd(cpu0-pd) -mpp56 56 gpio, dev(ad21), vdd(cpu1-pd) -mpp57 57 gpio, dev(ad22), vdd(cpu2-3-pd){1} +mpp55 55 gpio, dev(ad20) +mpp56 56 gpio, dev(ad21) +mpp57 57 gpio, dev(ad22) mpp58 58 gpio, dev(ad23) mpp59 59 gpio, dev(ad24) mpp60 60 gpio, dev(ad25) @@ -96,6 +97,3 @@ mpp63 63 gpio, dev(ad28) mpp64 64 gpio, dev(ad29) mpp65 65 gpio, dev(ad30) mpp66 66 gpio, dev(ad31) - -Notes: -* {1} vdd(cpu2-3-pd) only available on mv78460. diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt b/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt new file mode 100644 index 000000000000..df0309c57505 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nxp,lpc1850-scu.txt @@ -0,0 +1,57 @@ +NXP LPC18xx/43xx SCU pin controller Device Tree Bindings +-------------------------------------------------------- + +Required properties: +- compatible : Should be "nxp,lpc1850-scu" +- reg : Address and length of the register set for the device +- clocks : Clock specifier (see clock bindings for details) + +The lpc1850-scu driver uses the generic pin multiplexing and generic pin +configuration documented in pinctrl-bindings.txt. + +The following generic nodes are supported: + - function + - pins + - bias-disable + - bias-pull-up + - bias-pull-down + - drive-strength + - input-enable + - input-disable + - input-schmitt-enable + - input-schmitt-disable + - slew-rate + +Not all pins support all properties so either refer to the NXP 1850/4350 +user manual or the pin table in the pinctrl-lpc18xx driver for supported +pin properties. + +Example: +pinctrl: pinctrl@40086000 { + compatible = "nxp,lpc1850-scu"; + reg = <0x40086000 0x1000>; + clocks = <&ccu1 CLK_CPU_SCU>; + + i2c0_pins: i2c0-pins { + i2c0_pins_cfg { + pins = "i2c0_scl", "i2c0_sda"; + function = "i2c0"; + input-enable; + }; + }; + + uart0_pins: uart0-pins { + uart0_rx_cfg { + pins = "pf_11"; + function = "uart0"; + bias-disable; + input-enable; + }; + + uart0_tx_cfg { + pins = "pf_10"; + function = "uart0"; + bias-disable; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt new file mode 100644 index 000000000000..eecf028ff485 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt @@ -0,0 +1,109 @@ +CSR SiRFatlas7 pinmux controller + +Required properties: +- compatible : "sirf,atlas7-ioc" +- reg : Address range of the pinctrl registers + +For example, pinctrl might have properties like the following: + pinctrl: ioc@18880000 { + compatible = "sirf,atlas7-ioc"; + reg = <0x18880000 0x1000>; + + a_ac97_pmx: ac97@0 { + ac97 { + groups = "audio_ac97_grp"; + function = "audio_ac97"; + }; + }; + + ... + + sd2_pmx: sd2@0 { + sd2 { + groups = "sd2_grp0"; + function = "sd2"; + }; + }; + + ... + + + sample0_cfg: sample0@0 { + sample0 { + pins = "ldd_0", "ldd_1"; + bias-pull-up; + }; + }; + + sample1_cfg: sample1@0 { + sample1 { + pins = "ldd_2", "ldd_3"; + input-schmitt-enable; + }; + }; + + sample2_cfg: sample2@0 { + sample2 { + groups = "uart4_nopause_grp"; + bias-pull-down; + }; + }; + + sample3_cfg: sample3@0 { + sample3 { + pins = "ldd_4", "ldd_5"; + drive-strength = <2>; + }; + }; + }; + +Please refer to pinctrl-bindings.txt in this directory for details of the common +pinctrl bindings used by client devices. + +SiRFatlas7's pinmux nodes act as a container for an abitrary number of subnodes. +Each of these subnodes represents some desired configuration for a group of pins. + +Required subnode-properties: +- groups : An array of strings. Each string contains the name of a group. +- function: A string containing the name of the function to mux to the + group. + + Valid values for group and function names can be found from looking at the + group and function arrays in driver files: + drivers/pinctrl/pinctrl-sirf.c + +For example, pinctrl might have subnodes like the following: + sd0_pmx: sd0@0 { + sd0 { + groups = "sd0_grp"; + function = "sd0"; + }; + }; + + sd1_pmx0: sd1@0 { + sd1 { + groups = "sd1_grp0"; + function = "sd1_m0"; + }; + }; + + sd1_pmx1: sd1@1 { + sd1 { + groups = "sd1_grp1"; + function = "sd1_m1"; + }; + }; + +For a specific board, if it wants to use sd1, +it can add the following to its board-specific .dts file. +sd1: sd@0x12340000 { + pinctrl-names = "default"; + pinctrl-0 = <&sd1_pmx0>; +} + +or + +sd1: sd@0x12340000 { + pinctrl-names = "default"; + pinctrl-0 = <&sd1_pmx1>; +} diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index 5868a0f7255d..0480bc31bfd7 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -3,9 +3,11 @@ The Mediatek's Pin controller is used to control SoC pins. Required properties: -- compatible: value should be either of the following. +- compatible: value should be one of the following. (a) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. -- mediatek,pctl-regmap: Should be a phandle of the syscfg node. + (b) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. + (c) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. + (d) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. - gpio-controller : Marks the device node as a gpio controller. @@ -24,6 +26,9 @@ Required properties: Only the following flags are supported: 0 - GPIO_ACTIVE_HIGH 1 - GPIO_ACTIVE_LOW + +Optional properties: +- mediatek,pctl-regmap: Should be a phandle of the syscfg node. - reg: physicall address base for EINT registers - interrupt-controller: Marks the device node as an interrupt controller - #interrupt-cells: Should be two. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt new file mode 100644 index 000000000000..77aa11790163 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt @@ -0,0 +1,90 @@ +Qualcomm MSM8660 TLMM block + +Required properties: +- compatible: "qcom,msm8660-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. + The first cell is the gpio pin number and the + second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Qualcomm's pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength, + output-low, output-high. + +Non-empty subnodes must specify the 'pins' property. + +Valid values for pins are: + gpio0-gpio172, sdc3_clk, sdc3_cmd, sdc3_data sdc4_clk, sdc4_cmd, sdc4_data + +Valid values for function are: + gpio, cam_mclk, dsub, ext_gps, gp_clk_0a, gp_clk_0b, gp_clk_1a, gp_clk_1b, + gp_clk_2a, gp_clk_2b, gp_mn, gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n, + gsbi1_spi_cs2b_n, gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n, + gsbi2_spi_cs3_n, gsbi3, gsbi3_spi_cs1_n, gsbi3_spi_cs2_n, gsbi3_spi_cs3_n, + gsbi4, gsbi5, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, gsbi11, gsbi12, hdmi, i2s, + lcdc, mdp_vsync, mi2s, pcm, ps_hold, sdc1, sdc2, sdc5, tsif1, tsif2, usb_fs1, + usb_fs1_oe_n, usb_fs2, usb_fs2_oe_n, vfe, vsens_alarm, + +Example: + + msmgpio: pinctrl@800000 { + compatible = "qcom,msm8660-pinctrl"; + reg = <0x800000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 16 0x4>; + + pinctrl-names = "default"; + pinctrl-0 = <&gsbi12_uart>; + + gsbi12_uart: gsbi12-uart { + mux { + pins = "gpio117", "gpio118"; + function = "gsbi12"; + }; + + tx { + pins = "gpio118"; + drive-strength = <8>; + bias-disable; + }; + + rx { + pins = "gpio117"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index bfe72ec055e3..51cee44fc140 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -16,7 +16,9 @@ Required Properties: - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller. - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. - - "renesas,pfc-r8a7791": for R8A7791 (R-Car M2) compatible pin-controller. + - "renesas,pfc-r8a7791": for R8A7791 (R-Car M2-W) compatible pin-controller. + - "renesas,pfc-r8a7793": for R8A7793 (R-Car M2-N) compatible pin-controller. + - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. - reg: Base address and length of each memory resource used by the pin diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index 388b213249fd..391ef4be8d50 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -21,14 +21,15 @@ defined as gpio sub-nodes of the pinmux controller. Required properties for iomux controller: - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl" - "rockchip,rk3288-pinctrl" + "rockchip,rk3288-pinctrl", "rockchip,rk3368-pinctrl" - rockchip,grf: phandle referencing a syscon providing the "general register files" Optional properties for iomux controller: - rockchip,pmu: phandle referencing a syscon providing the pmu registers as some SoCs carry parts of the iomux controller registers there. - Required for at least rk3188 and rk3288. + Required for at least rk3188 and rk3288. On the rk3368 this should + point to the PMUGRF syscon. Deprecated properties for iomux controller: - reg: first element is the general register space of the iomux controller diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt index b7b55a964f65..f488b0f77406 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt @@ -45,8 +45,9 @@ to specify in a pinconf subnode: Valid values for groups are: ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp, mdio1_0_grp, - qspi0_0_grp, qspi1_0_grp, qspi_fbclk, qspi_cs1_grp, spi0_0_grp, - spi0_1_grp - spi0_2_grp, spi1_0_grp - spi1_3_grp, sdio0_0_grp - sdio0_2_grp, + qspi0_0_grp, qspi1_0_grp, qspi_fbclk, qspi_cs1_grp, spi0_0_grp - spi0_2_grp, + spi0_X_ssY (X=0..2, Y=0..2), spi1_0_grp - spi1_3_grp, + spi1_X_ssY (X=0..3, Y=0..2), sdio0_0_grp - sdio0_2_grp, sdio1_0_grp - sdio1_3_grp, sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp, sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp, smc0_nor_addr25_grp, smc0_nand, can0_0_grp - can0_10_grp, can1_0_grp - can1_11_grp, uart0_0_grp - uart0_10_grp, @@ -59,7 +60,7 @@ to specify in a pinconf subnode: Valid values for function are: ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk, qspi_cs1, - spi0, spi1, sdio0, sdio0_pc, sdio0_cd, sdio0_wp, + spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc, sdio0_cd, sdio0_wp, sdio1, sdio1_pc, sdio1_cd, sdio1_wp, smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0, can1, uart0, uart1, i2c0, i2c1, ttc0, ttc1, swdt0, gpio0, usb0, usb1 diff --git a/Documentation/devicetree/bindings/power/bq24257.txt b/Documentation/devicetree/bindings/power/bq24257.txt new file mode 100644 index 000000000000..5c9d3940d07c --- /dev/null +++ b/Documentation/devicetree/bindings/power/bq24257.txt @@ -0,0 +1,21 @@ +Binding for TI bq24257 Li-Ion Charger + +Required properties: +- compatible: Should contain one of the following: + * "ti,bq24257" +- reg: integer, i2c address of the device. +- ti,battery-regulation-voltage: integer, maximum charging voltage in uV. +- ti,charge-current: integer, maximum charging current in uA. +- ti,termination-current: integer, charge will be terminated when current in + constant-voltage phase drops below this value (in uA). + +Example: + +bq24257 { + compatible = "ti,bq24257"; + reg = <0x6a>; + + ti,battery-regulation-voltage = <4200000>; + ti,charge-current = <1000000>; + ti,termination-current = <50000>; +}; diff --git a/Documentation/devicetree/bindings/power/bq25890.txt b/Documentation/devicetree/bindings/power/bq25890.txt new file mode 100644 index 000000000000..c9dd17d142ad --- /dev/null +++ b/Documentation/devicetree/bindings/power/bq25890.txt @@ -0,0 +1,46 @@ +Binding for TI bq25890 Li-Ion Charger + +Required properties: +- compatible: Should contain one of the following: + * "ti,bq25890" +- reg: integer, i2c address of the device. +- ti,battery-regulation-voltage: integer, maximum charging voltage (in uV); +- ti,charge-current: integer, maximum charging current (in uA); +- ti,termination-current: integer, charge will be terminated when current in + constant-voltage phase drops below this value (in uA); +- ti,precharge-current: integer, maximum charge current during precharge + phase (in uA); +- ti,minimum-sys-voltage: integer, when battery is charging and it is below + minimum system voltage, the system will be regulated above + minimum-sys-voltage setting (in uV); +- ti,boost-voltage: integer, VBUS voltage level in boost mode (in uV); +- ti,boost-max-current: integer, maximum allowed current draw in boost mode + (in uA). + +Optional properties: +- ti,boost-low-freq: boolean, if present boost mode frequency will be 500kHz, + otherwise 1.5MHz; +- ti,use-ilim-pin: boolean, if present the ILIM resistor will be used and the + input current will be the lower between the resistor setting and the IINLIM + register setting; +- ti,thermal-regulation-threshold: integer, temperature above which the charge + current is lowered, to avoid overheating (in degrees Celsius). If omitted, + the default setting will be used (120 degrees); + +Example: + +bq25890 { + compatible = "ti,bq25890"; + reg = <0x6a>; + + ti,battery-regulation-voltage = <4200000>; + ti,charge-current = <1000000>; + ti,termination-current = <50000>; + ti,precharge-current = <128000>; + ti,minimum-sys-voltage = <3600000>; + ti,boost-voltage = <5000000>; + ti,boost-max-current = <1000000>; + + ti,use-ilim-pin; + ti,thermal-regulation-threshold = <120>; +}; diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index 74499e5033fc..0d5e7c978121 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -1,8 +1,19 @@ -* Generic OPP Interface +Generic OPP (Operating Performance Points) Bindings +---------------------------------------------------- -SoCs have a standard set of tuples consisting of frequency and -voltage pairs that the device will support per voltage domain. These -are called Operating Performance Points or OPPs. +Devices work at voltage-current-frequency combinations and some implementations +have the liberty of choosing these. These combinations are called Operating +Performance Points aka OPPs. This document defines bindings for these OPPs +applicable across wide range of devices. For illustration purpose, this document +uses CPU as a device. + +This document contain multiple versions of OPP binding and only one of them +should be used per device. + +Binding 1: operating-points +============================ + +This binding only supports voltage-frequency pairs. Properties: - operating-points: An array of 2-tuples items, and each item consists @@ -23,3 +34,432 @@ cpu@0 { 198000 850000 >; }; + + +Binding 2: operating-points-v2 +============================ + +* Property: operating-points-v2 + +Devices supporting OPPs must set their "operating-points-v2" property with +phandle to a OPP table in their DT node. The OPP core will use this phandle to +find the operating points for the device. + +Devices may want to choose OPP tables at runtime and so can provide a list of +phandles here. But only *one* of them should be chosen at runtime. This must be +accompanied by a corresponding "operating-points-names" property, to uniquely +identify the OPP tables. + +If required, this can be extended for SoC vendor specfic bindings. Such bindings +should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt +and should have a compatible description like: "operating-points-v2-<vendor>". + +Optional properties: +- operating-points-names: Names of OPP tables (required if multiple OPP + tables are present), to uniquely identify them. The same list must be present + for all the CPUs which are sharing clock/voltage rails and hence the OPP + tables. + +* OPP Table Node + +This describes the OPPs belonging to a device. This node can have following +properties: + +Required properties: +- compatible: Allow OPPs to express their compatibility. It should be: + "operating-points-v2". + +- OPP nodes: One or more OPP nodes describing voltage-current-frequency + combinations. Their name isn't significant but their phandle can be used to + reference an OPP. + +Optional properties: +- opp-shared: Indicates that device nodes using this OPP Table Node's phandle + switch their DVFS state together, i.e. they share clock/voltage/current lines. + Missing property means devices have independent clock/voltage/current lines, + but they share OPP tables. + +- status: Marks the OPP table enabled/disabled. + + +* OPP Node + +This defines voltage-current-frequency combinations along with other related +properties. + +Required properties: +- opp-hz: Frequency in Hz + +Optional properties: +- opp-microvolt: voltage in micro Volts. + + A single regulator's voltage is specified with an array of size one or three. + Single entry is for target voltage and three entries are for <target min max> + voltages. + + Entries for multiple regulators must be present in the same order as + regulators are specified in device's DT node. + +- opp-microamp: The maximum current drawn by the device in microamperes + considering system specific parameters (such as transients, process, aging, + maximum operating temperature range etc.) as necessary. This may be used to + set the most efficient regulator operating mode. + + Should only be set if opp-microvolt is set for the OPP. + + Entries for multiple regulators must be present in the same order as + regulators are specified in device's DT node. If this property isn't required + for few regulators, then this should be marked as zero for them. If it isn't + required for any regulator, then this property need not be present. + +- clock-latency-ns: Specifies the maximum possible transition latency (in + nanoseconds) for switching to this OPP from any other OPP. + +- turbo-mode: Marks the OPP to be used only for turbo modes. Turbo mode is + available on some platforms, where the device can run over its operating + frequency for a short duration of time limited by the device's power, current + and thermal limits. + +- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in + the table should have this. + +- status: Marks the node enabled/disabled. + +Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. + +/ { + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "arm,cortex-a9"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cpu0_opp_table>; + }; + + cpu@1 { + compatible = "arm,cortex-a9"; + reg = <1>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cpu0_opp_table>; + }; + }; + + cpu0_opp_table: opp_table0 { + compatible = "operating-points-v2"; + opp-shared; + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>; + opp-microamp = <70000>; + clock-latency-ns = <300000>; + opp-suspend; + }; + opp01 { + opp-hz = <1100000000>; + opp-microvolt = <980000 1000000 1010000>; + opp-microamp = <80000>; + clock-latency-ns = <310000>; + }; + opp02 { + opp-hz = <1200000000>; + opp-microvolt = <1025000>; + clock-latency-ns = <290000>; + turbo-mode; + }; + }; +}; + +Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states +independently. + +/ { + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "qcom,krait"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cpu_opp_table>; + }; + + cpu@1 { + compatible = "qcom,krait"; + reg = <1>; + next-level-cache = <&L2>; + clocks = <&clk_controller 1>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply1>; + operating-points-v2 = <&cpu_opp_table>; + }; + + cpu@2 { + compatible = "qcom,krait"; + reg = <2>; + next-level-cache = <&L2>; + clocks = <&clk_controller 2>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply2>; + operating-points-v2 = <&cpu_opp_table>; + }; + + cpu@3 { + compatible = "qcom,krait"; + reg = <3>; + next-level-cache = <&L2>; + clocks = <&clk_controller 3>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply3>; + operating-points-v2 = <&cpu_opp_table>; + }; + }; + + cpu_opp_table: opp_table { + compatible = "operating-points-v2"; + + /* + * Missing opp-shared property means CPUs switch DVFS states + * independently. + */ + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>; + opp-microamp = <70000>; + clock-latency-ns = <300000>; + opp-suspend; + }; + opp01 { + opp-hz = <1100000000>; + opp-microvolt = <980000 1000000 1010000>; + opp-microamp = <80000>; + clock-latency-ns = <310000>; + }; + opp02 { + opp-hz = <1200000000>; + opp-microvolt = <1025000>; + opp-microamp = <90000; + lock-latency-ns = <290000>; + turbo-mode; + }; + }; +}; + +Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch +DVFS state together. + +/ { + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "arm,cortex-a7"; + reg = <0>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cluster0_opp>; + }; + + cpu@1 { + compatible = "arm,cortex-a7"; + reg = <1>; + next-level-cache = <&L2>; + clocks = <&clk_controller 0>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply0>; + operating-points-v2 = <&cluster0_opp>; + }; + + cpu@100 { + compatible = "arm,cortex-a15"; + reg = <100>; + next-level-cache = <&L2>; + clocks = <&clk_controller 1>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply1>; + operating-points-v2 = <&cluster1_opp>; + }; + + cpu@101 { + compatible = "arm,cortex-a15"; + reg = <101>; + next-level-cache = <&L2>; + clocks = <&clk_controller 1>; + clock-names = "cpu"; + cpu-supply = <&cpu_supply1>; + operating-points-v2 = <&cluster1_opp>; + }; + }; + + cluster0_opp: opp_table0 { + compatible = "operating-points-v2"; + opp-shared; + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>; + opp-microamp = <70000>; + clock-latency-ns = <300000>; + opp-suspend; + }; + opp01 { + opp-hz = <1100000000>; + opp-microvolt = <980000 1000000 1010000>; + opp-microamp = <80000>; + clock-latency-ns = <310000>; + }; + opp02 { + opp-hz = <1200000000>; + opp-microvolt = <1025000>; + opp-microamp = <90000>; + clock-latency-ns = <290000>; + turbo-mode; + }; + }; + + cluster1_opp: opp_table1 { + compatible = "operating-points-v2"; + opp-shared; + + opp10 { + opp-hz = <1300000000>; + opp-microvolt = <1045000 1050000 1055000>; + opp-microamp = <95000>; + clock-latency-ns = <400000>; + opp-suspend; + }; + opp11 { + opp-hz = <1400000000>; + opp-microvolt = <1075000>; + opp-microamp = <100000>; + clock-latency-ns = <400000>; + }; + opp12 { + opp-hz = <1500000000>; + opp-microvolt = <1010000 1100000 1110000>; + opp-microamp = <95000>; + clock-latency-ns = <400000>; + turbo-mode; + }; + }; +}; + +Example 4: Handling multiple regulators + +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>; + operating-points-v2 = <&cpu0_opp_table>; + }; + }; + + cpu0_opp_table: opp_table0 { + compatible = "operating-points-v2"; + opp-shared; + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000>, /* Supply 0 */ + <960000>, /* Supply 1 */ + <960000>; /* Supply 2 */ + opp-microamp = <70000>, /* Supply 0 */ + <70000>, /* Supply 1 */ + <70000>; /* Supply 2 */ + clock-latency-ns = <300000>; + }; + + /* OR */ + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>, /* Supply 0 */ + <960000 965000 975000>, /* Supply 1 */ + <960000 965000 975000>; /* Supply 2 */ + opp-microamp = <70000>, /* Supply 0 */ + <70000>, /* Supply 1 */ + <70000>; /* Supply 2 */ + clock-latency-ns = <300000>; + }; + + /* OR */ + + opp00 { + opp-hz = <1000000000>; + opp-microvolt = <970000 975000 985000>, /* Supply 0 */ + <960000 965000 975000>, /* Supply 1 */ + <960000 965000 975000>; /* Supply 2 */ + opp-microamp = <70000>, /* Supply 0 */ + <0>, /* Supply 1 doesn't need this */ + <70000>; /* Supply 2 */ + clock-latency-ns = <300000>; + }; + }; +}; + +Example 5: Multiple OPP tables + +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + cpu-supply = <&cpu_supply> + operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>; + operating-points-names = "slow", "fast"; + }; + }; + + cpu0_opp_table_slow: opp_table_slow { + compatible = "operating-points-v2"; + status = "okay"; + opp-shared; + + opp00 { + opp-hz = <600000000>; + ... + }; + + opp01 { + opp-hz = <800000000>; + ... + }; + }; + + cpu0_opp_table_fast: opp_table_fast { + compatible = "operating-points-v2"; + status = "okay"; + opp-shared; + + opp10 { + opp-hz = <1000000000>; + ... + }; + + opp11 { + opp-hz = <1100000000>; + ... + }; + }; +}; diff --git a/Documentation/devicetree/bindings/power/rt9455_charger.txt b/Documentation/devicetree/bindings/power/rt9455_charger.txt new file mode 100644 index 000000000000..5d9ad5cf2c5a --- /dev/null +++ b/Documentation/devicetree/bindings/power/rt9455_charger.txt @@ -0,0 +1,48 @@ +Binding for Richtek rt9455 battery charger + +Required properties: +- compatible: it should contain one of the following: + "richtek,rt9455". +- reg: integer, i2c address of the device. +- interrupt-parent: the phandle for the interrupt controller that + services interrupts for this device. +- interrupts: interrupt mapping for GPIO IRQ, it should be + configured with IRQ_TYPE_LEVEL_LOW flag. +- richtek,output-charge-current: integer, output current from the charger to the + battery, in uA. +- richtek,end-of-charge-percentage: integer, percent of the output charge current. + When the current in constant-voltage phase drops + below output_charge_current x end-of-charge-percentage, + charge is terminated. +- richtek,battery-regulation-voltage: integer, maximum battery voltage in uV. +- richtek,boost-output-voltage: integer, maximum voltage provided to consumer + devices, when the charger is in boost mode, in uV. + +Optional properties: +- richtek,min-input-voltage-regulation: integer, input voltage level in uV, used to + decrease voltage level when the over current + of the input power source occurs. + This prevents input voltage drop due to insufficient + current provided by the power source. + Default: 4500000 uV (4.5V) +- richtek,avg-input-current-regulation: integer, input current value in uA drained by the + charger from the power source. + Default: 500000 uA (500mA) + +Example: + +rt9455@22 { + compatible = "richtek,rt9455"; + reg = <0x22>; + + interrupt-parent = <&gpio1>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + + richtek,output-charge-current = <500000>; + richtek,end-of-charge-percentage = <10>; + richtek,battery-regulation-voltage = <4200000>; + richtek,boost-output-voltage = <5050000>; + + richtek,min-input-voltage-regulation = <4500000>; + richtek,avg-input-current-regulation = <500000>; +}; diff --git a/Documentation/devicetree/bindings/power_supply/max17042_battery.txt b/Documentation/devicetree/bindings/power_supply/max17042_battery.txt index 5bc9b685cf8a..3f3894aaeebc 100644 --- a/Documentation/devicetree/bindings/power_supply/max17042_battery.txt +++ b/Documentation/devicetree/bindings/power_supply/max17042_battery.txt @@ -9,10 +9,23 @@ Optional properties : (datasheet-recommended value is 10000). Defining this property enables current-sense functionality. +Optional threshold properties : + If skipped the condition won't be reported. + - maxim,cold-temp : Temperature threshold to report battery + as cold (in tenths of degree Celsius). + - maxim,over-heat-temp : Temperature threshold to report battery + as over heated (in tenths of degree Celsius). + - maxim,dead-volt : Voltage threshold to report battery + as dead (in mV). + - maxim,over-volt : Voltage threshold to report battery + as over voltage (in mV). + Example: battery-charger@36 { compatible = "maxim,max17042"; reg = <0x36>; maxim,rsns-microohm = <10000>; + maxim,over-heat-temp = <600>; + maxim,over-volt = <4300>; }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt index edda55f74004..1fc5328c0651 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt @@ -189,6 +189,19 @@ PROPERTIES Definition: There is one reg region describing the port configuration registers. +- fsl,fman-10g-port + Usage: optional + Value type: boolean + Definition: The default port rate is 1G. + If this property exists, the port is s 10G port. + +- fsl,fman-best-effort-port + Usage: optional + Value type: boolean + Definition: Can be defined only if 10G-support is set. + This property marks a best-effort 10G port (10G port that + may not be capable of line rate). + EXAMPLE port@a8000 { diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt index 7f150b5012cc..b71b2039e112 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt @@ -9,6 +9,11 @@ Required properties: - compatible : Should define the compatible device type for global-utilities. + Possible compatibles: + "fsl,qoriq-device-config-1.0" + "fsl,qoriq-device-config-2.0" + "fsl,<chip>-device-config" + "fsl,<chip>-guts" - reg : Offset and length of the register set for the device. Recommended properties: diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt index 4f15d8a1bfd0..55efb24e5683 100644 --- a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt @@ -2,12 +2,30 @@ Required properties: -- compatible: must be "maxim,max8973" +- compatible: must be one of following: + "maxim,max8973" + "maxim,max77621". - reg: the i2c slave address of the regulator. It should be 0x1b. Any standard regulator properties can be used to configure the single max8973 DCDC. +Optional properties: + +-maxim,externally-enable: boolean, externally control the regulator output + enable/disable. +-maxim,enable-gpio: GPIO for enable control. If the valid GPIO is provided + then externally enable control will be considered. +-maxim,dvs-gpio: GPIO which is connected to DVS pin of device. +-maxim,dvs-default-state: Default state of GPIO during initialisation. + 1 for HIGH and 0 for LOW. +-maxim,enable-remote-sense: boolean, enable reote sense. +-maxim,enable-falling-slew-rate: boolean, enable falling slew rate. +-maxim,enable-active-discharge: boolean: enable active discharge. +-maxim,enable-frequency-shift: boolean, enable 9% frequency shift. +-maxim,enable-bias-control: boolean, enable bias control. By enabling this + startup delay can be reduce to 20us from 220us. + Example: max8973@1b { diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt new file mode 100644 index 000000000000..75b4604bad07 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt @@ -0,0 +1,121 @@ +Qualcomm SPMI Regulators + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8841-regulators" + "qcom,pm8916-regulators" + "qcom,pm8941-regulators" + +- interrupts: + Usage: optional + Value type: <prop-encoded-array> + Definition: List of OCP interrupts. + +- interrupt-names: + Usage: required if 'interrupts' property present + Value type: <string-array> + Definition: List of strings defining the names of the + interrupts in the 'interrupts' property 1-to-1. + Supported values are "ocp-<regulator_name>", where + <regulator_name> corresponds to a voltage switch + type regulator. + +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_s4-supply: +- vdd_s5-supply: +- vdd_s6-supply: +- vdd_s7-supply: +- vdd_s8-supply: + Usage: optional (pm8841 only) + Value type: <phandle> + Definition: Reference to regulator supplying the input pin, as + described in the data sheet. + +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_s4-supply: +- vdd_l1_l3-supply: +- vdd_l2-supply: +- vdd_l4_l5_l6-supply: +- vdd_l7-supply: +- vdd_l8_l11_l14_l15_l16-supply: +- vdd_l9_l10_l12_l13_l17_l18-supply: + Usage: optional (pm8916 only) + Value type: <phandle> + Definition: Reference to regulator supplying the input pin, as + described in the data sheet. + +- vdd_s1-supply: +- vdd_s2-supply: +- vdd_s3-supply: +- vdd_l1_l3-supply: +- vdd_l2_lvs_1_2_3-supply: +- vdd_l4_l11-supply: +- vdd_l5_l7-supply: +- vdd_l6_l12_l14_l15-supply: +- vdd_l8_l16_l18_19-supply: +- vdd_l9_l10_l17_l22-supply: +- vdd_l13_l20_l23_l24-supply: +- vdd_l21-supply: +- vin_5vs-supply: + Usage: optional (pm8941 only) + Value type: <phandle> + Definition: Reference to regulator supplying the input pin, as + described in the data sheet. + + +The regulator node houses sub-nodes for each regulator within the device. Each +sub-node is identified using the node's name, with valid values listed for each +of the PMICs below. + +pm8841: + s1, s2, s3, s4, s5, s6, s7, s8 + +pm8916: + s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, + l14, l15, l16, l17, l18 + +pm8941: + s1, s2, s3, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, + l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2, lvs3, + mvs1, mvs2 + +The content of each sub-node is defined by the standard binding for regulators - +see regulator.txt - with additional custom properties described below: + +- regulator-initial-mode: + Usage: optional + Value type: <u32> + Descrption: 1 = Set initial mode to high power mode (HPM), also referred + to as NPM. HPM consumes more ground current than LPM, but + it can source significantly higher load current. HPM is not + available on boost type regulators. For voltage switch type + regulators, HPM implies that over current protection and + soft start are active all the time. 0 = Set initial mode to + low power mode (LPM). + +Example: + + regulators { + compatible = "qcom,pm8941-regulators"; + vdd_l1_l3-supply = <&s1>; + + s1: s1 { + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1400000>; + }; + + ... + + l1: l1 { + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1300000>; + }; + + .... + }; diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index abb26b58c83e..db88feb28c03 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -7,18 +7,20 @@ Optional properties: - regulator-microvolt-offset: Offset applied to voltages to compensate for voltage drops - regulator-min-microamp: smallest current consumers may set - regulator-max-microamp: largest current consumers may set +- regulator-input-current-limit-microamp: maximum input current regulator allows - regulator-always-on: boolean, regulator should never be disabled - regulator-boot-on: bootloader/firmware enabled regulator - regulator-allow-bypass: allow the regulator to go into bypass mode - <name>-supply: phandle to the parent supply/regulator node - regulator-ramp-delay: ramp delay for regulator(in uV/uS) For hardware which supports disabling ramp rate, it should be explicitly - intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. + initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply rail to reach the target voltage, plus/minus whatever tolerance the board design requires. This property describes the total system ramp time required due to the combination of internal ramping of the regulator itself, and board design issues such as trace capacitance and load on the supply. +- regulator-soft-start: Enable soft start so that voltage ramps slowly - regulator-state-mem sub-root node for Suspend-to-RAM mode : suspend to memory, the device goes to sleep, but all data stored in memory, only some external interrupt can wake the device. @@ -37,6 +39,9 @@ Optional properties: - regulator-initial-mode: initial operating mode. The set of possible operating modes depends on the capabilities of every hardware so each device binding documentation explains which values the regulator supports. +- regulator-system-load: Load in uA present on regulator that is not captured by + any consumer request. +- regulator-pull-down: Enable pull down resistor when the regulator is disabled. Deprecated properties: - regulator-compatible: If a regulator chip contains multiple diff --git a/Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt b/Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt new file mode 100644 index 000000000000..73407f502e4e --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-st-lpc.txt @@ -0,0 +1,25 @@ +STMicroelectronics Low Power Controller (LPC) - RTC +=================================================== + +LPC currently supports Watchdog OR Real Time Clock functionality. + +[See: ../watchdog/st_lpc_wdt.txt for Watchdog options] + +Required properties + +- compatible : Must be one of: "st,stih407-lpc" "st,stih416-lpc" + "st,stih415-lpc" "st,stid127-lpc" +- reg : LPC registers base address + size +- interrupts : LPC interrupt line number and associated flags +- clocks : Clock used by LPC device (See: ../clock/clock-bindings.txt) +- st,lpc-mode : The LPC can run either one of two modes ST_LPC_MODE_RTC [0] or + ST_LPC_MODE_WDT [1]. One (and only one) mode must be + selected. + +Example: + lpc@fde05000 { + compatible = "st,stih407-lpc"; + reg = <0xfde05000 0x1000>; + clocks = <&clk_s_d3_flexgen CLK_LPC_0>; + st,lpc-mode = <ST_LPC_MODE_RTC>; + }; diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index ae73bb0e9ad9..7534d46e9ad8 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -29,6 +29,7 @@ Required properties: - "renesas,scifa" for generic SCIFA compatible UART. - "renesas,scifb" for generic SCIFB compatible UART. - "renesas,hscif" for generic HSCIF compatible UART. + - "renesas,sci" for generic SCI compatible UART. When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first followed by the diff --git a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt index 48c4dae5d6f9..47e46ccbc170 100644 --- a/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt +++ b/Documentation/devicetree/bindings/soc/fsl/qman-portals.txt @@ -47,7 +47,7 @@ PROPERTIES For additional details about the PAMU/LIODN binding(s) see pamu.txt -- fsl,qman-channel-id +- cell-index Usage: Required Value type: <u32> Definition: The hardware index of the channel. This can also be @@ -136,7 +136,7 @@ The example below shows a (P4080) QMan portals container/bus node with two porta reg = <0x4000 0x4000>, <0x101000 0x1000>; interrupts = <106 2 0 0>; fsl,liodn = <3 4>; - fsl,qman-channel-id = <1>; + cell-index = <1>; fman0 { fsl,liodn = <0x22>; diff --git a/Documentation/devicetree/bindings/spi/spi-ath79.txt b/Documentation/devicetree/bindings/spi/spi-ath79.txt new file mode 100644 index 000000000000..f1ad9c367532 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-ath79.txt @@ -0,0 +1,24 @@ +Binding for Qualcomm Atheros AR7xxx/AR9xxx SPI controller + +Required properties: +- compatible: has to be "qca,<soc-type>-spi", "qca,ar7100-spi" as fallback. +- reg: Base address and size of the controllers memory area +- clocks: phandle to the AHB clock. +- clock-names: has to be "ahb". +- #address-cells: <1>, as required by generic SPI binding. +- #size-cells: <0>, also as required by generic SPI binding. + +Child nodes as per the generic SPI binding. + +Example: + + spi@1F000000 { + compatible = "qca,ar9132-spi", "qca,ar7100-spi"; + reg = <0x1F000000 0x10>; + + clocks = <&pll 2>; + clock-names = "ahb"; + + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt index 70af78a9185e..fa77f874e321 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt @@ -1,7 +1,7 @@ ARM Freescale DSPI controller Required properties: -- compatible : "fsl,vf610-dspi" +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi" - reg : Offset and length of the register set for the device - interrupts : Should contain SPI controller interrupt - clocks: from common clock binding: handle to dspi clock. diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt index 50c3a3de61c1..98bc69815eb3 100644 --- a/Documentation/devicetree/bindings/spi/spi-orion.txt +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt @@ -1,7 +1,13 @@ Marvell Orion SPI device Required properties: -- compatible : should be "marvell,orion-spi" or "marvell,armada-370-spi". +- compatible : should be on of the following: + - "marvell,orion-spi" for the Orion, mv78x00, Kirkwood and Dove SoCs + - "marvell,armada-370-spi", for the Armada 370 SoCs + - "marvell,armada-375-spi", for the Armada 375 SoCs + - "marvell,armada-380-spi", for the Armada 38x SoCs + - "marvell,armada-390-spi", for the Armada 39x SoCs + - "marvell,armada-xp-spi", for the Armada XP SoCs - reg : offset and length of the register set for the device - cell-index : Which of multiple SPI controllers is this. Optional properties: diff --git a/Documentation/devicetree/bindings/spi/spi-sirf.txt b/Documentation/devicetree/bindings/spi/spi-sirf.txt index 4c7adb8f777c..ddd78ff68fae 100644 --- a/Documentation/devicetree/bindings/spi/spi-sirf.txt +++ b/Documentation/devicetree/bindings/spi/spi-sirf.txt @@ -1,7 +1,8 @@ * CSR SiRFprimaII Serial Peripheral Interface Required properties: -- compatible : Should be "sirf,prima2-spi" +- compatible : Should be "sirf,prima2-spi", "sirf,prima2-usp" + or "sirf,atlas7-usp" - reg : Offset and length of the register set for the device - interrupts : Should contain SPI interrupt - resets: phandle to the reset controller asserting this device in diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt new file mode 100644 index 000000000000..c8f50e5cf70b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt @@ -0,0 +1,26 @@ +Xilinx Zynq UltraScale+ MPSoC GQSPI controller Device Tree Bindings +------------------------------------------------------------------- + +Required properties: +- compatible : Should be "xlnx,zynqmp-qspi-1.0". +- reg : Physical base address and size of GQSPI registers map. +- interrupts : Property with a value describing the interrupt + number. +- interrupt-parent : Must be core interrupt controller. +- clock-names : List of input clock names - "ref_clk", "pclk" + (See clock bindings for details). +- clocks : Clock phandles (see clock bindings for details). + +Optional properties: +- num-cs : Number of chip selects used. + +Example: + qspi: spi@ff0f0000 { + compatible = "xlnx,zynqmp-qspi-1.0"; + clock-names = "ref_clk", "pclk"; + clocks = <&misc_clk &misc_clk>; + interrupts = <0 15 4>; + interrupt-parent = <&gic>; + num-cs = <1>; + reg = <0x0 0xff0f0000 0x1000>,<0x0 0xc0000000 0x8000000>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi_atmel.txt b/Documentation/devicetree/bindings/spi/spi_atmel.txt index 4f8184d069cb..fb588b3e6a9a 100644 --- a/Documentation/devicetree/bindings/spi/spi_atmel.txt +++ b/Documentation/devicetree/bindings/spi/spi_atmel.txt @@ -4,11 +4,16 @@ Required properties: - compatible : should be "atmel,at91rm9200-spi". - reg: Address and length of the register set for the device - interrupts: Should contain spi interrupt -- cs-gpios: chipselects +- cs-gpios: chipselects (optional for SPI controller version >= 2 with the + Chip Select Active After Transfer feature). - clock-names: tuple listing input clock names. Required elements: "spi_clk" - clocks: phandles to input clocks. +Optional properties: +- atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO + capable SPI controllers. + Example: spi1: spi@fffcc000 { @@ -20,6 +25,7 @@ spi1: spi@fffcc000 { clocks = <&spi1_clk>; clock-names = "spi_clk"; cs-gpios = <&pioB 3 0>; + atmel,fifo-size = <32>; status = "okay"; mmc-slot@0 { diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt b/Documentation/devicetree/bindings/spi/spi_pl022.txt index 22ed6797216d..4d1673ca8cf8 100644 --- a/Documentation/devicetree/bindings/spi/spi_pl022.txt +++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt @@ -4,9 +4,9 @@ Required properties: - compatible : "arm,pl022", "arm,primecell" - reg : Offset and length of the register set for the device - interrupts : Should contain SPI controller interrupt +- num-cs : total number of chipselects Optional properties: -- num-cs : total number of chipselects - cs-gpios : should specify GPIOs used for chipselects. The gpios will be referred to as reg = <index> in the SPI child nodes. If unspecified, a single SPI device without a chip select can be used. diff --git a/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt b/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt new file mode 100644 index 000000000000..51b05a0e70d1 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nxp,lpc3220-timer.txt @@ -0,0 +1,26 @@ +* NXP LPC3220 timer + +The NXP LPC3220 timer is used on a wide range of NXP SoCs. This +includes LPC32xx, LPC178x, LPC18xx and LPC43xx parts. + +Required properties: +- compatible: + Should be "nxp,lpc3220-timer". +- reg: + Address and length of the register set. +- interrupts: + Reference to the timer interrupt +- clocks: + Should contain a reference to timer clock. +- clock-names: + Should contain "timerclk". + +Example: + +timer1: timer@40085000 { + compatible = "nxp,lpc3220-timer"; + reg = <0x40085000 0x1000>; + interrupts = <13>; + clocks = <&ccu1 CLK_CPU_TIMER1>; + clock-names = "timerclk"; +}; diff --git a/Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt b/Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt new file mode 100644 index 000000000000..e8792447a199 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,16bit-timer.txt @@ -0,0 +1,25 @@ +* Renesas H8/300 16bit timer + +The 16bit timer is a 16bit timer/counter with configurable clock inputs and +programmable compare match. + +Required Properties: + + - compatible: must contain "renesas,16bit-timer" + - reg: base address and length of the registers block for the timer module. + - interrupts: interrupt-specifier for the timer, IMIA + - clocks: a list of phandle, one for each entry in clock-names. + - clock-names: must contain "peripheral_clk" for the functional clock. + - renesas,channel: timer channel number. + +Example: + + timer16: timer@ffff68 { + compatible = "reneas,16bit-timer"; + reg = <0xffff68 8>, <0xffff60 8>; + interrupts = <24>; + renesas,channel = <0>; + clocks = <&pclk>; + clock-names = "peripheral_clk"; + }; + diff --git a/Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt b/Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt new file mode 100644 index 000000000000..9dca3759a0f0 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,8bit-timer.txt @@ -0,0 +1,25 @@ +* Renesas H8/300 8bit timer + +The 8bit timer is a 8bit timer/counter with configurable clock inputs and +programmable compare match. + +This implement only supported cascade mode. + +Required Properties: + + - compatible: must contain "renesas,8bit-timer" + - reg: base address and length of the registers block for the timer module. + - interrupts: interrupt-specifier for the timer, CMIA and TOVI + - clocks: a list of phandle, one for each entry in clock-names. + - clock-names: must contain "fck" for the functional clock. + +Example: + + timer8_0: timer@ffff80 { + compatible = "renesas,8bit-timer"; + reg = <0xffff80 10>; + interrupts = <36>; + clocks = <&fclk>; + clock-names = "fck"; + }; + diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.txt b/Documentation/devicetree/bindings/timer/renesas,tpu.txt new file mode 100644 index 000000000000..f8b25897fb31 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,tpu.txt @@ -0,0 +1,21 @@ +* Renesas H8/300 Timer Pluse Unit + +The TPU is a 16bit timer/counter with configurable clock inputs and +programmable compare match. +This implementation support only cascade mode. + +Required Properties: + + - compatible: must contain "renesas,tpu" + - reg: base address and length of the registers block in 2 channel. + - clocks: a list of phandle, one for each entry in clock-names. + - clock-names: must contain "peripheral_clk" for the functional clock. + + +Example: + tpu: tpu@ffffe0 { + compatible = "renesas,tpu"; + reg = <0xffffe0 16>, <0xfffff0 12>; + clocks = <&pclk>; + clock-names = "peripheral_clk"; + }; diff --git a/Documentation/devicetree/bindings/timer/st,stm32-timer.txt b/Documentation/devicetree/bindings/timer/st,stm32-timer.txt new file mode 100644 index 000000000000..8ef28e70d6e8 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/st,stm32-timer.txt @@ -0,0 +1,22 @@ +. STMicroelectronics STM32 timer + +The STM32 MCUs family has several general-purpose 16 and 32 bits timers. + +Required properties: +- compatible : Should be "st,stm32-timer" +- reg : Address and length of the register set +- clocks : Reference on the timer input clock +- interrupts : Reference to the timer interrupt + +Optional properties: +- resets: Reference to a reset controller asserting the timer + +Example: + +timer5: timer@40000c00 { + compatible = "st,stm32-timer"; + reg = <0x40000c00 0x400>; + interrupts = <50>; + resets = <&rrc 259>; + clocks = <&clk_pmtr1>; +}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 80339192c93e..53d87bad0adc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -161,6 +161,7 @@ ralink Mediatek/Ralink Technology Corp. ramtron Ramtron International realtek Realtek Semiconductor Corp. renesas Renesas Electronics Corporation +richtek Richtek Technology Corporation ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsung Samsung Semiconductor @@ -181,6 +182,7 @@ skyworks Skyworks Solutions, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. solidrun SolidRun +solomon Solomon Systech Limited sony Sony Corporation spansion Spansion Inc. sprd Spreadtrum Communications Inc. diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt index 7a125427ff4b..d1be78db63f5 100644 --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt @@ -2,7 +2,7 @@ Required properties: - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for - now is i2c, and the supported chips are ssd1306 and ssd1307. + now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307. - reg: Should contain address of the controller on the I2C bus. Most likely 0x3c or 0x3d - pwm: Should contain the pwm to use according to the OF device tree PWM @@ -15,6 +15,16 @@ Required properties: Optional properties: - reset-active-low: Is the reset gpio is active on physical low? + - solomon,segment-no-remap: Display needs normal (non-inverted) data column + to segment mapping + - solomon,com-seq: Display uses sequential COM pin configuration + - solomon,com-lrremap: Display uses left-right COM pin remap + - solomon,com-invdir: Display uses inverted COM pin scan direction + - solomon,com-offset: Number of the COM pin wired to the first display line + - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles. + - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles. + This needs to be the higher, the higher the capacitance + of the OLED's pixels is [0]: Documentation/devicetree/bindings/pwm/pwm.txt @@ -26,3 +36,14 @@ ssd1307: oled@3c { reset-gpios = <&gpio2 7>; reset-active-low; }; + +ssd1306: oled@3c { + compatible = "solomon,ssd1306fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + reset-active-low; + solomon,com-lrremap; + solomon,com-invdir; + solomon,com-offset = <32>; +}; diff --git a/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt b/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt new file mode 100644 index 000000000000..388c88a01222 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/st_lpc_wdt.txt @@ -0,0 +1,38 @@ +STMicroelectronics Low Power Controller (LPC) - Watchdog +======================================================== + +LPC currently supports Watchdog OR Real Time Clock functionality. + +[See: ../rtc/rtc-st-lpc.txt for RTC options] + +Required properties + +- compatible : Must be one of: "st,stih407-lpc" "st,stih416-lpc" + "st,stih415-lpc" "st,stid127-lpc" +- reg : LPC registers base address + size +- interrupts : LPC interrupt line number and associated flags +- clocks : Clock used by LPC device (See: ../clock/clock-bindings.txt) +- st,lpc-mode : The LPC can run either one of two modes ST_LPC_MODE_RTC [0] or + ST_LPC_MODE_WDT [1]. One (and only one) mode must be + selected. + +Required properties [watchdog mode] + +- st,syscfg : Phandle to syscfg node used to enable watchdog and configure + CPU reset type. +- timeout-sec : Watchdog timeout in seconds + +Optional properties [watchdog mode] + +- st,warm-reset : If present reset type will be 'warm' - if not it will be cold + +Example: + lpc@fde05000 { + compatible = "st,stih407-lpc"; + reg = <0xfde05000 0x1000>; + clocks = <&clk_s_d3_flexgen CLK_LPC_0>; + st,syscfg = <&syscfg_core>; + timeout-sec = <120>; + st,lpc-mode = <ST_LPC_MODE_WDT>; + st,warm-reset; + }; diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 73fff13e848f..0cf27a3544a5 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -1,53 +1,34 @@ - - EDAC - Error Detection And Correction - -Written by Doug Thompson <dougthompson@xmission.com> -7 Dec 2005 -17 Jul 2007 Updated - -(c) Mauro Carvalho Chehab -05 Aug 2009 Nehalem interface - -EDAC is maintained and written by: - - Doug Thompson, Dave Jiang, Dave Peterson et al, - original author: Thayne Harbaugh, - -Contact: - website: bluesmoke.sourceforge.net - mailing list: bluesmoke-devel@lists.sourceforge.net +===================================== "bluesmoke" was the name for this device driver when it was "out-of-tree" and maintained at sourceforge.net. When it was pushed into 2.6.16 for the first time, it was renamed to 'EDAC'. -The bluesmoke project at sourceforge.net is now utilized as a 'staging area' -for EDAC development, before it is sent upstream to kernel.org - -At the bluesmoke/EDAC project site is a series of quilt patches against -recent kernels, stored in a SVN repository. For easier downloading, there -is also a tarball snapshot available. +PURPOSE +------- -============================================================================ -EDAC PURPOSE - -The 'edac' kernel module goal is to detect and report errors that occur -within the computer system running under linux. +The 'edac' kernel module's goal is to detect and report hardware errors +that occur within the computer system running under linux. MEMORY +------ -In the initial release, memory Correctable Errors (CE) and Uncorrectable -Errors (UE) are the primary errors being harvested. These types of errors -are harvested by the 'edac_mc' class of device. +Memory Correctable Errors (CE) and Uncorrectable Errors (UE) are the +primary errors being harvested. These types of errors are harvested by +the 'edac_mc' device. Detecting CE events, then harvesting those events and reporting them, -CAN be a predictor of future UE events. With CE events, the system can -continue to operate, but with less safety. Preventive maintenance and -proactive part replacement of memory DIMMs exhibiting CEs can reduce -the likelihood of the dreaded UE events and system 'panics'. +*can* but must not necessarily be a predictor of future UE events. With +CE events only, the system can and will continue to operate as no data +has been damaged yet. + +However, preventive maintenance and proactive part replacement of memory +DIMMs exhibiting CEs can reduce the likelihood of the dreaded UE events +and system panics. -NON-MEMORY +OTHER HARDWARE ELEMENTS +----------------------- A new feature for EDAC, the edac_device class of device, was added in the 2.6.23 version of the kernel. @@ -56,70 +37,57 @@ This new device type allows for non-memory type of ECC hardware detectors to have their states harvested and presented to userspace via the sysfs interface. -Some architectures have ECC detectors for L1, L2 and L3 caches, along with DMA -engines, fabric switches, main data path switches, interconnections, -and various other hardware data paths. If the hardware reports it, then -a edac_device device probably can be constructed to harvest and present -that to userspace. +Some architectures have ECC detectors for L1, L2 and L3 caches, +along with DMA engines, fabric switches, main data path switches, +interconnections, and various other hardware data paths. If the hardware +reports it, then a edac_device device probably can be constructed to +harvest and present that to userspace. PCI BUS SCANNING +---------------- -In addition, PCI Bus Parity and SERR Errors are scanned for on PCI devices -in order to determine if errors are occurring on data transfers. +In addition, PCI devices are scanned for PCI Bus Parity and SERR Errors +in order to determine if errors are occurring during data transfers. The presence of PCI Parity errors must be examined with a grain of salt. -There are several add-in adapters that do NOT follow the PCI specification +There are several add-in adapters that do *not* follow the PCI specification with regards to Parity generation and reporting. The specification says the vendor should tie the parity status bits to 0 if they do not intend to generate parity. Some vendors do not do this, and thus the parity bit can "float" giving false positives. -In the kernel there is a PCI device attribute located in sysfs that is -checked by the EDAC PCI scanning code. If that attribute is set, -PCI parity/error scanning is skipped for that device. The attribute -is: +There is a PCI device attribute located in sysfs that is checked by +the EDAC PCI scanning code. If that attribute is set, PCI parity/error +scanning is skipped for that device. The attribute is: broken_parity_status -as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for +and is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for PCI devices. -FUTURE HARDWARE SCANNING -EDAC will have future error detectors that will be integrated with -EDAC or added to it, in the following list: - - MCE Machine Check Exception - MCA Machine Check Architecture - NMI NMI notification of ECC errors - MSRs Machine Specific Register error cases - and other mechanisms. - -These errors are usually bus errors, ECC errors, thermal throttling -and the like. - - -============================================================================ -EDAC VERSIONING +VERSIONING +---------- EDAC is composed of a "core" module (edac_core.ko) and several Memory -Controller (MC) driver modules. On a given system, the CORE -is loaded and one MC driver will be loaded. Both the CORE and -the MC driver (or edac_device driver) have individual versions that reflect -current release level of their respective modules. +Controller (MC) driver modules. On a given system, the CORE is loaded +and one MC driver will be loaded. Both the CORE and the MC driver (or +edac_device driver) have individual versions that reflect current +release level of their respective modules. -Thus, to "report" on what version a system is running, one must report both -the CORE's and the MC driver's versions. +Thus, to "report" on what version a system is running, one must report +both the CORE's and the MC driver's versions. LOADING +------- -If 'edac' was statically linked with the kernel then no loading is -necessary. If 'edac' was built as modules then simply modprobe the -'edac' pieces that you need. You should be able to modprobe -hardware-specific modules and have the dependencies load the necessary core -modules. +If 'edac' was statically linked with the kernel then no loading +is necessary. If 'edac' was built as modules then simply modprobe +the 'edac' pieces that you need. You should be able to modprobe +hardware-specific modules and have the dependencies load the necessary +core modules. Example: @@ -129,35 +97,33 @@ loads both the amd76x_edac.ko memory controller module and the edac_mc.ko core module. -============================================================================ -EDAC sysfs INTERFACE - -EDAC presents a 'sysfs' interface for control, reporting and attribute -reporting purposes. +SYSFS INTERFACE +--------------- -EDAC lives in the /sys/devices/system/edac directory. +EDAC presents a 'sysfs' interface for control and reporting purposes. It +lives in the /sys/devices/system/edac directory. -Within this directory there currently reside 2 'edac' components: +Within this directory there currently reside 2 components: mc memory controller(s) system pci PCI control and status system -============================================================================ + Memory Controller (mc) Model +---------------------------- -First a background on the memory controller's model abstracted in EDAC. -Each 'mc' device controls a set of DIMM memory modules. These modules are -laid out in a Chip-Select Row (csrowX) and Channel table (chX). There can -be multiple csrows and multiple channels. +Each 'mc' device controls a set of DIMM memory modules. These modules +are laid out in a Chip-Select Row (csrowX) and Channel table (chX). +There can be multiple csrows and multiple channels. -Memory controllers allow for several csrows, with 8 csrows being a typical value. -Yet, the actual number of csrows depends on the electrical "loading" -of a given motherboard, memory controller and DIMM characteristics. +Memory controllers allow for several csrows, with 8 csrows being a +typical value. Yet, the actual number of csrows depends on the layout of +a given motherboard, memory controller and DIMM characteristics. -Dual channels allows for 128 bit data transfers to the CPU from memory. -Some newer chipsets allow for more than 2 channels, like Fully Buffered DIMMs -(FB-DIMMs). The following example will assume 2 channels: +Dual channels allows for 128 bit data transfers to/from the CPU from/to +memory. Some newer chipsets allow for more than 2 channels, like Fully +Buffered DIMMs (FB-DIMMs). The following example will assume 2 channels: Channel 0 Channel 1 @@ -179,12 +145,12 @@ for memory DIMMs: DIMM_A1 DIMM_B1 -Labels for these slots are usually silk screened on the motherboard. Slots -labeled 'A' are channel 0 in this example. Slots labeled 'B' -are channel 1. Notice that there are two csrows possible on a -physical DIMM. These csrows are allocated their csrow assignment -based on the slot into which the memory DIMM is placed. Thus, when 1 DIMM -is placed in each Channel, the csrows cross both DIMMs. +Labels for these slots are usually silk-screened on the motherboard. +Slots labeled 'A' are channel 0 in this example. Slots labeled 'B' are +channel 1. Notice that there are two csrows possible on a physical DIMM. +These csrows are allocated their csrow assignment based on the slot into +which the memory DIMM is placed. Thus, when 1 DIMM is placed in each +Channel, the csrows cross both DIMMs. Memory DIMMs come single or dual "ranked". A rank is a populated csrow. Thus, 2 single ranked DIMMs, placed in slots DIMM_A0 and DIMM_B0 above @@ -193,8 +159,8 @@ when 2 dual ranked DIMMs are similarly placed, then both csrow0 and csrow1 will be populated. The pattern repeats itself for csrow2 and csrow3. -The representation of the above is reflected in the directory tree -in EDAC's sysfs interface. Starting in directory +The representation of the above is reflected in the directory +tree in EDAC's sysfs interface. Starting in directory /sys/devices/system/edac/mc each memory controller will be represented by its own 'mcX' directory, where 'X' is the index of the MC. @@ -217,34 +183,35 @@ Under each 'mcX' directory each 'csrowX' is again represented by a |->csrow3 .... -Notice that there is no csrow1, which indicates that csrow0 is -composed of a single ranked DIMMs. This should also apply in both -Channels, in order to have dual-channel mode be operational. Since -both csrow2 and csrow3 are populated, this indicates a dual ranked -set of DIMMs for channels 0 and 1. +Notice that there is no csrow1, which indicates that csrow0 is composed +of a single ranked DIMMs. This should also apply in both Channels, in +order to have dual-channel mode be operational. Since both csrow2 and +csrow3 are populated, this indicates a dual ranked set of DIMMs for +channels 0 and 1. -Within each of the 'mcX' and 'csrowX' directories are several -EDAC control and attribute files. +Within each of the 'mcX' and 'csrowX' directories are several EDAC +control and attribute files. -============================================================================ -'mcX' DIRECTORIES +'mcX' directories +----------------- In 'mcX' directories are EDAC control and attribute files for this 'X' instance of the memory controllers. For a description of the sysfs API, please see: - Documentation/ABI/testing/sysfs/devices-edac + Documentation/ABI/testing/sysfs-devices-edac + -============================================================================ -'csrowX' DIRECTORIES +'csrowX' directories +-------------------- -When CONFIG_EDAC_LEGACY_SYSFS is enabled, the sysfs will contain the -csrowX directories. As this API doesn't work properly for Rambus, FB-DIMMs -and modern Intel Memory Controllers, this is being deprecated in favor -of dimmX directories. +When CONFIG_EDAC_LEGACY_SYSFS is enabled, sysfs will contain the csrowX +directories. As this API doesn't work properly for Rambus, FB-DIMMs and +modern Intel Memory Controllers, this is being deprecated in favor of +dimmX directories. In the 'csrowX' directories are EDAC control and attribute files for this 'X' instance of csrow: @@ -265,18 +232,18 @@ Total Correctable Errors count attribute file: 'ce_count' This attribute file displays the total count of correctable - errors that have occurred on this csrow. This - count is very important to examine. CEs provide early - indications that a DIMM is beginning to fail. This count - field should be monitored for non-zero values and report - such information to the system administrator. + errors that have occurred on this csrow. This count is very + important to examine. CEs provide early indications that a + DIMM is beginning to fail. This count field should be + monitored for non-zero values and report such information + to the system administrator. Total memory managed by this csrow attribute file: 'size_mb' - This attribute file displays, in count of megabytes, of memory + This attribute file displays, in count of megabytes, the memory that this csrow contains. @@ -377,11 +344,13 @@ Channel 1 DIMM Label control file: motherboard specific and determination of this information must occur in userland at this time. -============================================================================ + + SYSTEM LOGGING +-------------- -If logging for UEs and CEs are enabled then system logs will have -error notices indicating errors that have been detected: +If logging for UEs and CEs is enabled, then system logs will contain +information indicating that errors have been detected: EDAC MC0: CE page 0x283, offset 0xce0, grain 8, syndrome 0x6ec3, row 0, channel 1 "DIMM_B1": amd76x_edac @@ -404,24 +373,23 @@ The structure of the message is: and then an optional, driver-specific message that may have additional information. -Both UEs and CEs with no info will lack all but memory controller, -error type, a notice of "no info" and then an optional, -driver-specific error message. +Both UEs and CEs with no info will lack all but memory controller, error +type, a notice of "no info" and then an optional, driver-specific error +message. -============================================================================ PCI Bus Parity Detection +------------------------ - -On Header Type 00 devices the primary status is looked at -for any parity error regardless of whether Parity is enabled on the -device. (The spec indicates parity is generated in some cases). -On Header Type 01 bridges, the secondary status register is also -looked at to see if parity occurred on the bus on the other side of -the bridge. +On Header Type 00 devices, the primary status is looked at for any +parity error regardless of whether parity is enabled on the device or +not. (The spec indicates parity is generated in some cases). On Header +Type 01 bridges, the secondary status register is also looked at to see +if parity occurred on the bus on the other side of the bridge. SYSFS CONFIGURATION +------------------- Under /sys/devices/system/edac/pci are control and attribute files as follows: @@ -450,8 +418,9 @@ Parity Count: have been detected. -============================================================================ + MODULE PARAMETERS +----------------- Panic on UE control file: @@ -516,7 +485,7 @@ Panic on PCI PARITY Error: 'panic_on_pci_parity' - This control files enables or disables panicking when a parity + This control file enables or disables panicking when a parity error has been detected. @@ -530,10 +499,8 @@ Panic on PCI PARITY Error: -======================================================================= - - -EDAC_DEVICE type of device +EDAC device type +---------------- In the header file, edac_core.h, there is a series of edac_device structures and APIs for the EDAC_DEVICE. @@ -573,6 +540,7 @@ The test_device_edac device adds at least one of its own custom control: The symlink points to the 'struct dev' that is registered for this edac_device. INSTANCES +--------- One or more instance directories are present. For the 'test_device_edac' case: @@ -586,6 +554,7 @@ counter in deeper subdirectories. ue_count total of UE events of subdirectories BLOCKS +------ At the lowest directory level is the 'block' directory. There can be 0, 1 or more blocks specified in each instance. @@ -617,14 +586,15 @@ The 'test_device_edac' device adds 4 attributes and 1 control: reset all the above counters. -Use of the 'test_device_edac' driver should any others to create their own +Use of the 'test_device_edac' driver should enable any others to create their own unique drivers for their hardware systems. The 'test_device_edac' sample driver is located at the bluesmoke.sourceforge.net project site for EDAC. -======================================================================= + NEHALEM USAGE OF EDAC APIs +-------------------------- This chapter documents some EXPERIMENTAL mappings for EDAC API to handle Nehalem EDAC driver. They will likely be changed on future versions @@ -633,7 +603,7 @@ of the driver. Due to the way Nehalem exports Memory Controller data, some adjustments were done at i7core_edac driver. This chapter will cover those differences -1) On Nehalem, there are one Memory Controller per Quick Patch Interconnect +1) On Nehalem, there is one Memory Controller per Quick Patch Interconnect (QPI). At the driver, the term "socket" means one QPI. This is associated with a physical CPU socket. @@ -642,7 +612,7 @@ were done at i7core_edac driver. This chapter will cover those differences Each channel can have up to 3 DIMMs. The minimum known unity is DIMMs. There are no information about csrows. - As EDAC API maps the minimum unity is csrows, the driver sequencially + As EDAC API maps the minimum unity is csrows, the driver sequentially maps channel/dimm into different csrows. For example, supposing the following layout: @@ -664,7 +634,7 @@ exports one Each QPI is exported as a different memory controller. -2) Nehalem MC has the hability to generate errors. The driver implements this +2) Nehalem MC has the ability to generate errors. The driver implements this functionality via some error injection nodes: For injecting a memory error, there are some sysfs nodes, under @@ -771,5 +741,22 @@ exports one The standard error counters are generated when an mcelog error is received by the driver. Since, with udimm, this is counted by software, it is - possible that some errors could be lost. With rdimm's, they displays the + possible that some errors could be lost. With rdimm's, they display the contents of the registers + +CREDITS: +======== + +Written by Doug Thompson <dougthompson@xmission.com> +7 Dec 2005 +17 Jul 2007 Updated + +(c) Mauro Carvalho Chehab +05 Aug 2009 Nehalem interface + +EDAC authors/maintainers: + + Doug Thompson, Dave Jiang, Dave Peterson et al, + Mauro Carvalho Chehab + Borislav Petkov + original author: Thayne Harbaugh diff --git a/Documentation/features/arch-support.txt b/Documentation/features/arch-support.txt new file mode 100644 index 000000000000..d22a1095e661 --- /dev/null +++ b/Documentation/features/arch-support.txt @@ -0,0 +1,11 @@ + +For generic kernel features that need architecture support, the +arch-support.txt file in each feature directory shows the arch +support matrix, for all upstream Linux architectures. + +The meaning of entries in the tables is: + + | ok | # feature supported by the architecture + |TODO| # feature not yet supported by the architecture + | .. | # feature cannot be supported by the hardware + diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt b/Documentation/features/core/BPF-JIT/arch-support.txt new file mode 100644 index 000000000000..c1b4f917238f --- /dev/null +++ b/Documentation/features/core/BPF-JIT/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: BPF-JIT +# Kconfig: HAVE_BPF_JIT +# description: arch supports BPF JIT optimizations +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | ok | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt new file mode 100644 index 000000000000..6d930fcbe519 --- /dev/null +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: generic-idle-thread +# Kconfig: GENERIC_SMP_IDLE_THREAD +# description: arch makes use of the generic SMP idle thread facility +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | ok | + | arc: | ok | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | ok | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | ok | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | ok | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | ok | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt new file mode 100644 index 000000000000..136868b636e6 --- /dev/null +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: jump-labels +# Kconfig: HAVE_ARCH_JUMP_LABEL +# description: arch supports live patched, high efficiency branches +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | ok | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt new file mode 100644 index 000000000000..728061d763b1 --- /dev/null +++ b/Documentation/features/core/tracehook/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: tracehook +# Kconfig: HAVE_ARCH_TRACEHOOK +# description: arch supports tracehook (ptrace) register handling APIs +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | ok | + | c6x: | ok | + | cris: | TODO | + | frv: | ok | + | h8300: | TODO | + | hexagon: | ok | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | ok | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | ok | + | nios2: | ok | + | openrisc: | ok | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt new file mode 100644 index 000000000000..14531da2fb54 --- /dev/null +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: KASAN +# Kconfig: HAVE_ARCH_KASAN +# description: arch supports the KASAN runtime memory checker +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt new file mode 100644 index 000000000000..38dea8eeba0a --- /dev/null +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: gcov-profile-all +# Kconfig: ARCH_HAS_GCOV_PROFILE_ALL +# description: arch supports whole-kernel GCOV code coverage profiling +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | ok | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt new file mode 100644 index 000000000000..862e15d6f79e --- /dev/null +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: kgdb +# Kconfig: HAVE_ARCH_KGDB +# description: arch supports the kGDB kernel debugger +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | ok | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | ok | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | ok | + | mips: | ok | + | mn10300: | ok | + | nios2: | ok | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | TODO | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt new file mode 100644 index 000000000000..40f44d041fb4 --- /dev/null +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: kprobes-on-ftrace +# Kconfig: HAVE_KPROBES_ON_FTRACE +# description: arch supports combined kprobes and ftrace live patching +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt new file mode 100644 index 000000000000..a44bfff6940b --- /dev/null +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: kprobes +# Kconfig: HAVE_KPROBES +# description: arch supports live patched kernel probe +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | ok | + | arm64: | TODO | + | avr32: | ok | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt new file mode 100644 index 000000000000..d87c1ce24204 --- /dev/null +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: kretprobes +# Kconfig: HAVE_KRETPROBES +# description: arch supports kernel function-return probes +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | ok | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt new file mode 100644 index 000000000000..b8999d8544ca --- /dev/null +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: optprobes +# Kconfig: HAVE_OPTPROBES +# description: arch supports live patched optprobes +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt new file mode 100644 index 000000000000..0fa423313409 --- /dev/null +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: stackprotector +# Kconfig: HAVE_CC_STACKPROTECTOR +# description: arch supports compiler driven stack overflow protection +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | ok | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt new file mode 100644 index 000000000000..4efe36c3ace9 --- /dev/null +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: uprobes +# Kconfig: ARCH_SUPPORTS_UPROBES +# description: arch supports live patched user probes +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/user-ret-profiler/arch-support.txt b/Documentation/features/debug/user-ret-profiler/arch-support.txt new file mode 100644 index 000000000000..44cc1ff3f603 --- /dev/null +++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: user-ret-profiler +# Kconfig: HAVE_USER_RETURN_NOTIFIER +# description: arch supports user-space return from system call profiler +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/io/dma-api-debug/arch-support.txt b/Documentation/features/io/dma-api-debug/arch-support.txt new file mode 100644 index 000000000000..4f4a3443b114 --- /dev/null +++ b/Documentation/features/io/dma-api-debug/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: dma-api-debug +# Kconfig: HAVE_DMA_API_DEBUG +# description: arch supports DMA debug facilities +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | ok | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | ok | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt new file mode 100644 index 000000000000..a97e8e3f4ebb --- /dev/null +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: dma-contiguous +# Kconfig: HAVE_DMA_CONTIGUOUS +# description: arch supports the DMA CMA (continuous memory allocator) +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/io/dma_map_attrs/arch-support.txt b/Documentation/features/io/dma_map_attrs/arch-support.txt new file mode 100644 index 000000000000..51d0f1c02a3e --- /dev/null +++ b/Documentation/features/io/dma_map_attrs/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: dma_map_attrs +# Kconfig: HAVE_DMA_ATTRS +# description: arch provides dma_*map*_attrs() APIs +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | ok | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | ok | + | hexagon: | ok | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | ok | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | ok | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | ok | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/io/sg-chain/arch-support.txt b/Documentation/features/io/sg-chain/arch-support.txt new file mode 100644 index 000000000000..b9b675539b9d --- /dev/null +++ b/Documentation/features/io/sg-chain/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: sg-chain +# Kconfig: ARCH_HAS_SG_CHAIN +# description: arch supports chained scatter-gather lists +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | ok | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/lib/strncasecmp/arch-support.txt b/Documentation/features/lib/strncasecmp/arch-support.txt new file mode 100644 index 000000000000..12b1c9358e57 --- /dev/null +++ b/Documentation/features/lib/strncasecmp/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: strncasecmp +# Kconfig: __HAVE_ARCH_STRNCASECMP +# description: arch provides an optimized strncasecmp() function +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | TODO | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh new file mode 100755 index 000000000000..6065124a072f --- /dev/null +++ b/Documentation/features/list-arch.sh @@ -0,0 +1,24 @@ +# +# Small script that visualizes the kernel feature support status +# of an architecture. +# +# (If no arguments are given then it will print the host architecture's status.) +# + +ARCH=${1:-$(arch | sed 's/x86_64/x86/' | sed 's/i386/x86/')} + +cd $(dirname $0) +echo "#" +echo "# Kernel feature support matrix of the '$ARCH' architecture:" +echo "#" + +for F in */*/arch-support.txt; do + SUBSYS=$(echo $F | cut -d/ -f1) + N=$(grep -h "^# Feature name:" $F | cut -c25-) + C=$(grep -h "^# Kconfig:" $F | cut -c25-) + D=$(grep -h "^# description:" $F | cut -c25-) + S=$(grep -hw $ARCH $F | cut -d\| -f3) + + printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D" +done + diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt new file mode 100644 index 000000000000..d9c310889bc1 --- /dev/null +++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: cmpxchg-local +# Kconfig: HAVE_CMPXCHG_LOCAL +# description: arch supports the this_cpu_cmpxchg() API +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt new file mode 100644 index 000000000000..cf90635bdcbb --- /dev/null +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: lockdep +# Kconfig: LOCKDEP_SUPPORT +# description: arch supports the runtime locking correctness debug facility +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | ok | + | arm64: | ok | + | avr32: | ok | + | blackfin: | ok | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | ok | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | ok | + | microblaze: | ok | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | ok | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | ok | + | unicore32: | ok | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt new file mode 100644 index 000000000000..68c3a5ddd9b9 --- /dev/null +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: queued-rwlocks +# Kconfig: ARCH_USE_QUEUED_RWLOCKS +# description: arch supports queued rwlocks +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt new file mode 100644 index 000000000000..e973b1a9572f --- /dev/null +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: queued-spinlocks +# Kconfig: ARCH_USE_QUEUED_SPINLOCKS +# description: arch supports queued spinlocks +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/locking/rwsem-optimized/arch-support.txt b/Documentation/features/locking/rwsem-optimized/arch-support.txt new file mode 100644 index 000000000000..ac93d7ab66c4 --- /dev/null +++ b/Documentation/features/locking/rwsem-optimized/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: rwsem-optimized +# Kconfig: Optimized asm/rwsem.h +# description: arch provides optimized rwsem APIs +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | ok | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt new file mode 100644 index 000000000000..9855ad044386 --- /dev/null +++ b/Documentation/features/perf/kprobes-event/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: kprobes-event +# Kconfig: HAVE_REGS_AND_STACK_ACCESS_API +# description: arch supports kprobes with perf events +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | ok | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | TODO | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt new file mode 100644 index 000000000000..e2b4a78ec543 --- /dev/null +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: perf-regs +# Kconfig: HAVE_PERF_REGS +# description: arch supports perf events register access +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt new file mode 100644 index 000000000000..3dc24b0673c0 --- /dev/null +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: perf-stackdump +# Kconfig: HAVE_PERF_USER_STACK_DUMP +# description: arch supports perf events stack dumps +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/sched/numa-balancing/arch-support.txt b/Documentation/features/sched/numa-balancing/arch-support.txt new file mode 100644 index 000000000000..ac7cd6b1502b --- /dev/null +++ b/Documentation/features/sched/numa-balancing/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: numa-balancing +# Kconfig: ARCH_SUPPORTS_NUMA_BALANCING +# description: arch supports NUMA balancing +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | .. | + | arm: | .. | + | arm64: | .. | + | avr32: | .. | + | blackfin: | .. | + | c6x: | .. | + | cris: | .. | + | frv: | .. | + | h8300: | .. | + | hexagon: | .. | + | ia64: | TODO | + | m32r: | .. | + | m68k: | .. | + | metag: | .. | + | microblaze: | .. | + | mips: | TODO | + | mn10300: | .. | + | nios2: | .. | + | openrisc: | .. | + | parisc: | .. | + | powerpc: | ok | + | s390: | .. | + | score: | .. | + | sh: | .. | + | sparc: | TODO | + | tile: | TODO | + | um: | .. | + | unicore32: | .. | + | x86: | ok | + | xtensa: | .. | + ----------------------- diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt new file mode 100644 index 000000000000..bea800910342 --- /dev/null +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: seccomp-filter +# Kconfig: HAVE_ARCH_SECCOMP_FILTER +# description: arch supports seccomp filters +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt new file mode 100644 index 000000000000..8acb439a4a17 --- /dev/null +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: arch-tick-broadcast +# Kconfig: ARCH_HAS_TICK_BROADCAST +# description: arch provides tick_broadcast() +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | TODO | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt new file mode 100644 index 000000000000..ff670b2207f1 --- /dev/null +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: clockevents +# Kconfig: GENERIC_CLOCKEVENTS +# description: arch support generic clock events +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | ok | + | arc: | ok | + | arm: | ok | + | arm64: | ok | + | avr32: | ok | + | blackfin: | ok | + | c6x: | ok | + | cris: | ok | + | frv: | TODO | + | h8300: | ok | + | hexagon: | ok | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | ok | + | metag: | ok | + | microblaze: | ok | + | mips: | ok | + | mn10300: | ok | + | nios2: | ok | + | openrisc: | ok | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | ok | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | ok | + | unicore32: | ok | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt new file mode 100644 index 000000000000..a1e3eea7003f --- /dev/null +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: context-tracking +# Kconfig: HAVE_CONTEXT_TRACKING +# description: arch supports context tracking for NO_HZ_FULL +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt new file mode 100644 index 000000000000..e63316239938 --- /dev/null +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: irq-time-acct +# Kconfig: HAVE_IRQ_TIME_ACCOUNTING +# description: arch supports precise IRQ time accounting +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | .. | + | arc: | TODO | + | arm: | ok | + | arm64: | .. | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | .. | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | .. | + | powerpc: | .. | + | s390: | .. | + | score: | TODO | + | sh: | TODO | + | sparc: | .. | + | tile: | .. | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/time/modern-timekeeping/arch-support.txt b/Documentation/features/time/modern-timekeeping/arch-support.txt new file mode 100644 index 000000000000..17f68a02e84d --- /dev/null +++ b/Documentation/features/time/modern-timekeeping/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: modern-timekeeping +# Kconfig: !ARCH_USES_GETTIMEOFFSET +# description: arch does not use arch_gettimeoffset() anymore +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | ok | + | arc: | ok | + | arm: | TODO | + | arm64: | ok | + | avr32: | ok | + | blackfin: | TODO | + | c6x: | ok | + | cris: | TODO | + | frv: | ok | + | h8300: | ok | + | hexagon: | ok | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | ok | + | microblaze: | ok | + | mips: | ok | + | mn10300: | ok | + | nios2: | ok | + | openrisc: | ok | + | parisc: | ok | + | powerpc: | ok | + | s390: | ok | + | score: | ok | + | sh: | ok | + | sparc: | ok | + | tile: | ok | + | um: | ok | + | unicore32: | ok | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt new file mode 100644 index 000000000000..cf3c3e383d15 --- /dev/null +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: virt-cpuacct +# Kconfig: HAVE_VIRT_CPU_ACCOUNTING +# description: arch supports precise virtual CPU time accounting +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | ok | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | ok | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | ok | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt new file mode 100644 index 000000000000..ec4dd28e1297 --- /dev/null +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: ELF-ASLR +# Kconfig: ARCH_HAS_ELF_RANDOMIZE +# description: arch randomizes the stack, heap and binary images of ELF binaries +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/vm/PG_uncached/arch-support.txt b/Documentation/features/vm/PG_uncached/arch-support.txt new file mode 100644 index 000000000000..991974275a3e --- /dev/null +++ b/Documentation/features/vm/PG_uncached/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: PG_uncached +# Kconfig: ARCH_USES_PG_UNCACHED +# description: arch supports the PG_uncached page flag +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | ok | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt new file mode 100644 index 000000000000..972d02c2a74c --- /dev/null +++ b/Documentation/features/vm/THP/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: THP +# Kconfig: HAVE_ARCH_TRANSPARENT_HUGEPAGE +# description: arch supports transparent hugepages +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | .. | + | arm: | ok | + | arm64: | ok | + | avr32: | .. | + | blackfin: | .. | + | c6x: | .. | + | cris: | .. | + | frv: | .. | + | h8300: | .. | + | hexagon: | .. | + | ia64: | TODO | + | m32r: | .. | + | m68k: | .. | + | metag: | .. | + | microblaze: | .. | + | mips: | ok | + | mn10300: | .. | + | nios2: | .. | + | openrisc: | .. | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | .. | + | sh: | .. | + | sparc: | ok | + | tile: | TODO | + | um: | .. | + | unicore32: | .. | + | x86: | ok | + | xtensa: | .. | + ----------------------- diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt new file mode 100644 index 000000000000..af6816bccb43 --- /dev/null +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: huge-vmap +# Kconfig: HAVE_ARCH_HUGE_VMAP +# description: arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | TODO | + | s390: | TODO | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt new file mode 100644 index 000000000000..90c53749fde7 --- /dev/null +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: ioremap_prot +# Kconfig: HAVE_IOREMAP_PROT +# description: arch has ioremap_prot() +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | TODO | + | arm64: | TODO | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | TODO | + | score: | TODO | + | sh: | ok | + | sparc: | TODO | + | tile: | ok | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/vm/numa-memblock/arch-support.txt b/Documentation/features/vm/numa-memblock/arch-support.txt new file mode 100644 index 000000000000..e7c252a0c531 --- /dev/null +++ b/Documentation/features/vm/numa-memblock/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: numa-memblock +# Kconfig: HAVE_MEMBLOCK_NODE_MAP +# description: arch supports NUMA aware memblocks +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | .. | + | arm: | .. | + | arm64: | .. | + | avr32: | .. | + | blackfin: | .. | + | c6x: | .. | + | cris: | .. | + | frv: | .. | + | h8300: | .. | + | hexagon: | .. | + | ia64: | ok | + | m32r: | TODO | + | m68k: | .. | + | metag: | ok | + | microblaze: | ok | + | mips: | ok | + | mn10300: | TODO | + | nios2: | .. | + | openrisc: | .. | + | parisc: | .. | + | powerpc: | ok | + | s390: | ok | + | score: | ok | + | sh: | ok | + | sparc: | ok | + | tile: | TODO | + | um: | .. | + | unicore32: | .. | + | x86: | ok | + | xtensa: | .. | + ----------------------- diff --git a/Documentation/features/vm/pmdp_splitting_flush/arch-support.txt b/Documentation/features/vm/pmdp_splitting_flush/arch-support.txt new file mode 100644 index 000000000000..26f74b457e0b --- /dev/null +++ b/Documentation/features/vm/pmdp_splitting_flush/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: pmdp_splitting_flush +# Kconfig: __HAVE_ARCH_PMDP_SPLITTING_FLUSH +# description: arch supports the pmdp_splitting_flush() VM API +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | ok | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | TODO | + | sparc: | TODO | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt new file mode 100644 index 000000000000..aaaa21db6226 --- /dev/null +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -0,0 +1,40 @@ +# +# Feature name: pte_special +# Kconfig: __HAVE_ARCH_PTE_SPECIAL +# description: arch supports the pte_special()/pte_mkspecial() VM APIs +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | avr32: | TODO | + | blackfin: | TODO | + | c6x: | TODO | + | cris: | TODO | + | frv: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m32r: | TODO | + | m68k: | TODO | + | metag: | TODO | + | microblaze: | TODO | + | mips: | TODO | + | mn10300: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | s390: | ok | + | score: | TODO | + | sh: | ok | + | sparc: | ok | + | tile: | TODO | + | um: | TODO | + | unicore32: | TODO | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 0a926e2ba3ab..6a34a0f4d37c 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -50,8 +50,8 @@ prototypes: int (*rename2) (struct inode *, struct dentry *, struct inode *, struct dentry *, unsigned int); int (*readlink) (struct dentry *, char __user *,int); - void * (*follow_link) (struct dentry *, struct nameidata *); - void (*put_link) (struct dentry *, struct nameidata *, void *); + const char *(*follow_link) (struct dentry *, void **); + void (*put_link) (struct inode *, void *); void (*truncate) (struct inode *); int (*permission) (struct inode *, int, unsigned int); int (*get_acl)(struct inode *, int); diff --git a/Documentation/filesystems/automount-support.txt b/Documentation/filesystems/automount-support.txt index 7cac200e2a85..7eb762eb3136 100644 --- a/Documentation/filesystems/automount-support.txt +++ b/Documentation/filesystems/automount-support.txt @@ -1,41 +1,15 @@ -Support is available for filesystems that wish to do automounting support (such -as kAFS which can be found in fs/afs/). This facility includes allowing -in-kernel mounts to be performed and mountpoint degradation to be -requested. The latter can also be requested by userspace. +Support is available for filesystems that wish to do automounting +support (such as kAFS which can be found in fs/afs/ and NFS in +fs/nfs/). This facility includes allowing in-kernel mounts to be +performed and mountpoint degradation to be requested. The latter can +also be requested by userspace. ====================== IN-KERNEL AUTOMOUNTING ====================== -A filesystem can now mount another filesystem on one of its directories by the -following procedure: - - (1) Give the directory a follow_link() operation. - - When the directory is accessed, the follow_link op will be called, and - it will be provided with the location of the mountpoint in the nameidata - structure (vfsmount and dentry). - - (2) Have the follow_link() op do the following steps: - - (a) Call vfs_kern_mount() to call the appropriate filesystem to set up a - superblock and gain a vfsmount structure representing it. - - (b) Copy the nameidata provided as an argument and substitute the dentry - argument into it the copy. - - (c) Call do_add_mount() to install the new vfsmount into the namespace's - mountpoint tree, thus making it accessible to userspace. Use the - nameidata set up in (b) as the destination. - - If the mountpoint will be automatically expired, then do_add_mount() - should also be given the location of an expiration list (see further - down). - - (d) Release the path in the nameidata argument and substitute in the new - vfsmount and its root dentry. The ref counts on these will need - incrementing. +See section "Mount Traps" of Documentation/filesystems/autofs4.txt Then from userspace, you can just do something like: @@ -61,17 +35,18 @@ AUTOMATIC MOUNTPOINT EXPIRY =========================== Automatic expiration of mountpoints is easy, provided you've mounted the -mountpoint to be expired in the automounting procedure outlined above. +mountpoint to be expired in the automounting procedure outlined separately. To do expiration, you need to follow these steps: - (3) Create at least one list off which the vfsmounts to be expired can be - hung. Access to this list will be governed by the vfsmount_lock. + (1) Create at least one list off which the vfsmounts to be expired can be + hung. - (4) In step (2c) above, the call to do_add_mount() should be provided with a - pointer to this list. It will hang the vfsmount off of it if it succeeds. + (2) When a new mountpoint is created in the ->d_automount method, add + the mnt to the list using mnt_set_expiry() + mnt_set_expiry(newmnt, &afs_vfsmounts); - (5) When you want mountpoints to be expired, call mark_mounts_for_expiry() + (3) When you want mountpoints to be expired, call mark_mounts_for_expiry() with a pointer to this list. This will process the list, marking every vfsmount thereon for potential expiry on the next call. diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index e69274de8d0c..68f1c9106573 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -379,10 +379,10 @@ may now be called in rcu-walk mode (nd->flags & LOOKUP_RCU). -ECHILD should be returned if the filesystem cannot handle rcu-walk. See Documentation/filesystems/vfs.txt for more details. - permission and check_acl are inode permission checks that are called -on many or all directory inodes on the way down a path walk (to check for -exec permission). These must now be rcu-walk aware (flags & IPERM_FLAG_RCU). -See Documentation/filesystems/vfs.txt for more details. + permission is an inode permission check that is called on many or all +directory inodes on the way down a path walk (to check for exec permission). It +must now be rcu-walk aware (mask & MAY_NOT_BLOCK). See +Documentation/filesystems/vfs.txt for more details. -- [mandatory] @@ -483,3 +483,20 @@ in your dentry operations instead. -- [mandatory] ->aio_read/->aio_write are gone. Use ->read_iter/->write_iter. +--- +[recommended] + for embedded ("fast") symlinks just set inode->i_link to wherever the + symlink body is and use simple_follow_link() as ->follow_link(). +-- +[mandatory] + calling conventions for ->follow_link() have changed. Instead of returning + cookie and using nd_set_link() to store the body to traverse, we return + the body to traverse and store the cookie using explicit void ** argument. + nameidata isn't passed at all - nd_jump_link() doesn't need it and + nd_[gs]et_link() is gone. +-- +[mandatory] + calling conventions for ->put_link() have changed. It gets inode instead of + dentry, it does not get nameidata at all and it gets called only when cookie + is non-NULL. Note that link body isn't available anymore, so if you need it, + store it as cookie. diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index c3b6b301d8b0..6f7fafde0884 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -205,7 +205,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 3.20.0) +Table 1-2: Contents of the status files (as of 4.1) .............................................................................. Field Content Name filename of the executable @@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0) VmExe size of text segment VmLib size of shared library code VmPTE size of page table entries + VmPMD size of second level page tables VmSwap size of swap usage (the number of referred swapents) Threads number of threads SigQ number of signals queued/max. number for queue diff --git a/Documentation/filesystems/quota.txt b/Documentation/filesystems/quota.txt index 5e8de25bf0f1..29fc01552646 100644 --- a/Documentation/filesystems/quota.txt +++ b/Documentation/filesystems/quota.txt @@ -32,7 +32,10 @@ The interface uses generic netlink framework (see http://lwn.net/Articles/208755/ and http://people.suug.ch/~tgr/libnl/ for more details about this layer). The name of the quota generic netlink interface is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>. - Currently, the interface supports only one message type QUOTA_NL_C_WARNING. +Since the quota netlink protocol is not namespace aware, quota netlink messages +are sent only in initial network namespace. + +Currently, the interface supports only one message type QUOTA_NL_C_WARNING. This command is used to send a notification about any of the above mentioned events. Each message has six attributes. These are (type of the argument is in parentheses): diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 5d833b32bbcd..5eb8456fc41e 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -350,8 +350,8 @@ struct inode_operations { int (*rename2) (struct inode *, struct dentry *, struct inode *, struct dentry *, unsigned int); int (*readlink) (struct dentry *, char __user *,int); - void * (*follow_link) (struct dentry *, struct nameidata *); - void (*put_link) (struct dentry *, struct nameidata *, void *); + const char *(*follow_link) (struct dentry *, void **); + void (*put_link) (struct inode *, void *); int (*permission) (struct inode *, int); int (*get_acl)(struct inode *, int); int (*setattr) (struct dentry *, struct iattr *); @@ -436,16 +436,18 @@ otherwise noted. follow_link: called by the VFS to follow a symbolic link to the inode it points to. Only required if you want to support - symbolic links. This method returns a void pointer cookie - that is passed to put_link(). + symbolic links. This method returns the symlink body + to traverse (and possibly resets the current position with + nd_jump_link()). If the body won't go away until the inode + is gone, nothing else is needed; if it needs to be otherwise + pinned, the data needed to release whatever we'd grabbed + is to be stored in void * variable passed by address to + follow_link() instance. put_link: called by the VFS to release resources allocated by - follow_link(). The cookie returned by follow_link() is passed - to this method as the last parameter. It is used by - filesystems such as NFS where page cache is not stable - (i.e. page that was installed when the symbolic link walk - started might not be in the page cache at the end of the - walk). + follow_link(). The cookie stored by follow_link() is passed + to this method as the last parameter; only called when + cookie isn't NULL. permission: called by the VFS to check for access rights on a POSIX-like filesystem. @@ -797,7 +799,7 @@ struct file_operations ---------------------- This describes how the VFS can manipulate an open file. As of kernel -3.12, the following members are defined: +4.1, the following members are defined: struct file_operations { struct module *owner; @@ -811,8 +813,9 @@ struct file_operations { long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); + int (*mremap)(struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); - int (*flush) (struct file *); + int (*flush) (struct file *, fl_owner_t id); int (*release) (struct inode *, struct file *); int (*fsync) (struct file *, loff_t, loff_t, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); @@ -822,11 +825,15 @@ struct file_operations { unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); int (*check_flags)(int); int (*flock) (struct file *, int, struct file_lock *); - ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int); - ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int); - int (*setlease)(struct file *, long arg, struct file_lock **, void **); - long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len); + ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int); + ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int); + int (*setlease)(struct file *, long, struct file_lock **, void **); + long (*fallocate)(struct file *file, int mode, loff_t offset, + loff_t len); void (*show_fdinfo)(struct seq_file *m, struct file *f); +#ifndef CONFIG_MMU + unsigned (*mmap_capabilities)(struct file *); +#endif }; Again, all methods are called without any locks being held, unless diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index c21c1313f09e..75542b91b766 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -241,18 +241,18 @@ Set multiple GPIO outputs with a single function call ----------------------------------------------------- The following functions set the output values of an array of GPIOs: - void gpiod_set_array(unsigned int array_size, - struct gpio_desc **desc_array, - int *value_array) - void gpiod_set_raw_array(unsigned int array_size, - struct gpio_desc **desc_array, - int *value_array) - void gpiod_set_array_cansleep(unsigned int array_size, - struct gpio_desc **desc_array, - int *value_array) - void gpiod_set_raw_array_cansleep(unsigned int array_size, - struct gpio_desc **desc_array, - int *value_array) + void gpiod_set_array_value(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array) + void gpiod_set_raw_array_value(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array) + void gpiod_set_array_value_cansleep(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array) + void gpiod_set_raw_array_value_cansleep(unsigned int array_size, + struct gpio_desc **desc_array, + int *value_array) The array can be an arbitrary set of GPIOs. The functions will try to set GPIOs belonging to the same bank or chip simultaneously if supported by the @@ -271,8 +271,8 @@ matches the desired group of GPIOs, those GPIOs can be set by simply using the struct gpio_descs returned by gpiod_get_array(): struct gpio_descs *my_gpio_descs = gpiod_get_array(...); - gpiod_set_array(my_gpio_descs->ndescs, my_gpio_descs->desc, - my_gpio_values); + gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc, + my_gpio_values); It is also possible to set a completely arbitrary array of descriptors. The descriptors may be obtained using any combination of gpiod_get() and @@ -290,7 +290,7 @@ corresponding to a given GPIO using the following call: int gpiod_to_irq(const struct gpio_desc *desc) -It will return an IRQ number, or an negative errno code if the mapping can't be +It will return an IRQ number, or a negative errno code if the mapping can't be done (most likely because that particular GPIO cannot be used as IRQ). It is an unchecked error to use a GPIO that wasn't set up as an input using gpiod_direction_input(), or to use an IRQ number that didn't originally come diff --git a/Documentation/gpio/gpio-legacy.txt b/Documentation/gpio/gpio-legacy.txt index 6f83fa965b4b..79ab5648d69b 100644 --- a/Documentation/gpio/gpio-legacy.txt +++ b/Documentation/gpio/gpio-legacy.txt @@ -751,9 +751,6 @@ requested using gpio_request(): int gpio_export_link(struct device *dev, const char *name, unsigned gpio) - /* change the polarity of a GPIO node in sysfs */ - int gpio_sysfs_set_active_low(unsigned gpio, int value); - After a kernel driver requests a GPIO, it may only be made available in the sysfs interface by gpio_export(). The driver can control whether the signal direction may change. This helps drivers prevent userspace code @@ -767,9 +764,3 @@ After the GPIO has been exported, gpio_export_link() allows creating symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can use this to provide the interface under their own device in sysfs with a descriptive name. - -Drivers can use gpio_sysfs_set_active_low() to hide GPIO line polarity -differences between boards from user space. This only affects the -sysfs interface. Polarity change can be done both before and after -gpio_export(), and previously enabled poll(2) support for either -rising or falling edge will be reconfigured to follow this setting. diff --git a/Documentation/gpio/sysfs.txt b/Documentation/gpio/sysfs.txt index c2c3a97f8ff7..535b6a8a7a7c 100644 --- a/Documentation/gpio/sysfs.txt +++ b/Documentation/gpio/sysfs.txt @@ -132,9 +132,6 @@ requested using gpio_request(): int gpiod_export_link(struct device *dev, const char *name, struct gpio_desc *desc); - /* change the polarity of a GPIO node in sysfs */ - int gpiod_sysfs_set_active_low(struct gpio_desc *desc, int value); - After a kernel driver requests a GPIO, it may only be made available in the sysfs interface by gpiod_export(). The driver can control whether the signal direction may change. This helps drivers prevent userspace code @@ -148,8 +145,3 @@ After the GPIO has been exported, gpiod_export_link() allows creating symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can use this to provide the interface under their own device in sysfs with a descriptive name. - -Drivers can use gpiod_sysfs_set_active_low() to hide GPIO line polarity -differences between boards from user space. Polarity change can be done both -before and after gpiod_export(), and previously enabled poll(2) support for -either rising or falling edge will be reconfigured to follow this setting. diff --git a/Documentation/hwmon/ntc_thermistor b/Documentation/hwmon/ntc_thermistor index c5e05e2900a3..1d4cc847c6fe 100644 --- a/Documentation/hwmon/ntc_thermistor +++ b/Documentation/hwmon/ntc_thermistor @@ -2,8 +2,10 @@ Kernel driver ntc_thermistor ================= Supported thermistors from Murata: -* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, NCP15WL333 - Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 'ncp15wl333' +* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, + NCP15WL333, NCP03WF104 + Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', + 'ncp15wl333', 'ncp03wf104' Datasheet: Publicly available at Murata Supported thermistors from EPCOS: diff --git a/Documentation/hwmon/tc74 b/Documentation/hwmon/tc74 new file mode 100644 index 000000000000..43027aad5f8e --- /dev/null +++ b/Documentation/hwmon/tc74 @@ -0,0 +1,20 @@ +Kernel driver tc74 +==================== + +Supported chips: + * Microchip TC74 + Prefix: 'tc74' + Datasheet: Publicly available at Microchip website. + +Description +----------- + +Driver supports the above part. + +The tc74 has an 8-bit sensor, with 1 degree centigrade resolution +and +- 2 degrees centigrade accuracy. + +Notes +----- + +Currently entering low power standby mode is not supported. diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 92e68bce13a4..5737e3590adb 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt @@ -33,7 +33,7 @@ The phase diagram of these two outputs look like this: one step (half-period mode) For more information, please see - http://en.wikipedia.org/wiki/Rotary_encoder + https://en.wikipedia.org/wiki/Rotary_encoder 1. Events / state machine diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO index b61885c35ce1..5a0f2bdc2cf9 100644 --- a/Documentation/ja_JP/HOWTO +++ b/Documentation/ja_JP/HOWTO @@ -445,7 +445,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで す。 -もしパッチをメールに付ける場合は、Documentaion/SubmittingPatches に提 +もしパッチをメールに付ける場合は、Documentation/SubmittingPatches に提 示されているように、それは プレーンな可読テキストにすることを忘れない ようにしましょう。カーネル開発者は 添付や圧縮したパッチを扱いたがりま せん- diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt index 4692241789b1..0d32355a4c34 100644 --- a/Documentation/kasan.txt +++ b/Documentation/kasan.txt @@ -150,7 +150,7 @@ AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory (e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and offset to translate a memory address to its corresponding shadow address. -Here is the function witch translate an address to its corresponding shadow +Here is the function which translates an address to its corresponding shadow address: static inline void *kasan_mem_to_shadow(const void *addr) diff --git a/Documentation/kbuild/headers_install.txt b/Documentation/kbuild/headers_install.txt index 951eb9f1e040..f0153adb95e2 100644 --- a/Documentation/kbuild/headers_install.txt +++ b/Documentation/kbuild/headers_install.txt @@ -24,7 +24,7 @@ The "make headers_install" command can be run in the top level directory of the kernel source code (or using a standard out-of-tree build). It takes two optional arguments: - make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include + make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr ARCH indicates which architecture to produce headers for, and defaults to the current architecture. The linux/asm directory of the exported kernel headers @@ -33,8 +33,11 @@ the command: ls -d include/asm-* | sed 's/.*-//' -INSTALL_HDR_PATH indicates where to install the headers. It defaults to -"./usr/include". +INSTALL_HDR_PATH indicates where to install the headers. It defaults to +"./usr". + +An 'include' directory is automatically created inside INSTALL_HDR_PATH and +headers are installed in 'INSTALL_HDR_PATH/include'. The command "make headers_install_all" exports headers for all architectures simultaneously. (This is mostly of interest to distribution maintainers, diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 74b6c6d97210..e63b446d973c 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -755,8 +755,8 @@ Additional files can be specified in kbuild makefiles by use of $(clean-files). #lib/Makefile clean-files := crc32table.h -When executing "make clean", the two files "devlist.h classlist.h" will be -deleted. Kbuild will assume files to be in the same relative directory as the +When executing "make clean", the file "crc32table.h" will be deleted. +Kbuild will assume files to be in the same relative directory as the Makefile, except if prefixed with $(objtree). To delete a directory hierarchy use: diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6726139bd289..c84d078a6376 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -179,11 +179,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See also Documentation/power/runtime_pm.txt, pci=noacpi - acpi_rsdp= [ACPI,EFI,KEXEC] - Pass the RSDP address to the kernel, mostly used - on machines running EFI runtime service to boot the - second kernel for kdump. - acpi_apic_instance= [ACPI, IOAPIC] Format: <int> 2: use 2nd APIC table, if available @@ -197,6 +192,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. (e.g. thinkpad_acpi, sony_acpi, etc.) instead of the ACPI video.ko driver. + acpica_no_return_repair [HW, ACPI] + Disable AML predefined validation mechanism + This mechanism can repair the evaluation result to make + the return objects more ACPI specification compliant. + This option is useful for developers to identify the + root cause of an AML interpreter issue when the issue + has something to do with the repair mechanism. + acpi.debug_layer= [HW,ACPI,ACPI_DEBUG] acpi.debug_level= [HW,ACPI,ACPI_DEBUG] Format: <int> @@ -225,6 +228,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. unusable. The "log_buf_len" parameter may be useful if you need to capture more output. + acpi_enforce_resources= [ACPI] + { strict | lax | no } + Check for resource conflicts between native drivers + and ACPI OperationRegions (SystemIO and SystemMemory + only). IO ports and memory declared in ACPI might be + used by the ACPI subsystem in arbitrary AML code and + can interfere with legacy drivers. + strict (default): access to resources claimed by ACPI + is denied; legacy drivers trying to access reserved + resources will fail to bind to device using them. + lax: access to resources claimed by ACPI is allowed; + legacy drivers trying to access reserved resources + will bind successfully but a warning message is logged. + no: ACPI OperationRegions are not marked as reserved, + no further checks are performed. + acpi_force_table_verification [HW,ACPI] Enable table checksum verification during early stage. By default, this is disabled due to x86 early mapping @@ -253,6 +272,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. This feature is enabled by default. This option allows to turn off the feature. + acpi_no_memhotplug [ACPI] Disable memory hotplug. Useful for kdump + kernels. + acpi_no_static_ssdt [HW,ACPI] Disable installation of static SSDTs at early boot time By default, SSDTs contained in the RSDT/XSDT will be @@ -263,13 +285,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. dynamic table installation which will install SSDT tables to /sys/firmware/acpi/tables/dynamic. - acpica_no_return_repair [HW, ACPI] - Disable AML predefined validation mechanism - This mechanism can repair the evaluation result to make - the return objects more ACPI specification compliant. - This option is useful for developers to identify the - root cause of an AML interpreter issue when the issue - has something to do with the repair mechanism. + acpi_rsdp= [ACPI,EFI,KEXEC] + Pass the RSDP address to the kernel, mostly used + on machines running EFI runtime service to boot the + second kernel for kdump. acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows" @@ -365,25 +384,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Use timer override. For some broken Nvidia NF5 boards that require a timer override, but don't have HPET - acpi_enforce_resources= [ACPI] - { strict | lax | no } - Check for resource conflicts between native drivers - and ACPI OperationRegions (SystemIO and SystemMemory - only). IO ports and memory declared in ACPI might be - used by the ACPI subsystem in arbitrary AML code and - can interfere with legacy drivers. - strict (default): access to resources claimed by ACPI - is denied; legacy drivers trying to access reserved - resources will fail to bind to device using them. - lax: access to resources claimed by ACPI is allowed; - legacy drivers trying to access reserved resources - will bind successfully but a warning message is logged. - no: ACPI OperationRegions are not marked as reserved, - no further checks are performed. - - acpi_no_memhotplug [ACPI] Disable memory hotplug. Useful for kdump - kernels. - add_efi_memmap [EFI; X86] Include EFI memory map in kernel's map of available physical RAM. @@ -746,6 +746,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. cpuidle.off=1 [CPU_IDLE] disable the cpuidle sub-system + cpu_init_udelay=N + [X86] Delay for N microsec between assert and de-assert + of APIC INIT to start processors. This delay occurs + on every CPU online, such as boot, and resume from suspend. + Default: 10000 + cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver Format: <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] @@ -937,6 +943,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Enable debug messages at boot time. See Documentation/dynamic-debug-howto.txt for details. + nompx [X86] Disables Intel Memory Protection Extensions. + See Documentation/x86/intel_mpx.txt for more + information about the feature. + eagerfpu= [X86] on enable eager fpu restore off disable eager fpu restore @@ -1009,6 +1019,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. earlyprintk=serial[,0x...[,baudrate]] earlyprintk=ttySn[,baudrate] earlyprintk=dbgp[debugController#] + earlyprintk=pciserial,bus:device.function[,baudrate] earlyprintk is useful when the kernel crashes before the normal console is initialized. It is not enabled by @@ -1780,6 +1791,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. * [no]ncq: Turn on or off NCQ. + * [no]ncqtrim: Turn off queued DSM TRIM. + * nohrst, nosrst, norst: suppress hard, soft and both resets. @@ -2443,7 +2456,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nomca [IA-64] Disable machine check abort handling - nomce [X86-32] Machine Check Exception + nomce [X86-32] Disable Machine Check Exception nomfgpt [X86-32] Disable Multi-Function General Purpose Timer usage (for AMD Geode machines). @@ -2998,11 +3011,34 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Set maximum number of finished RCU callbacks to process in one batch. + rcutree.dump_tree= [KNL] + Dump the structure of the rcu_node combining tree + out at early boot. This is used for diagnostic + purposes, to verify correct tree setup. + + rcutree.gp_cleanup_delay= [KNL] + Set the number of jiffies to delay each step of + RCU grace-period cleanup. This only has effect + when CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP is set. + rcutree.gp_init_delay= [KNL] Set the number of jiffies to delay each step of RCU grace-period initialization. This only has - effect when CONFIG_RCU_TORTURE_TEST_SLOW_INIT is - set. + effect when CONFIG_RCU_TORTURE_TEST_SLOW_INIT + is set. + + rcutree.gp_preinit_delay= [KNL] + Set the number of jiffies to delay each step of + RCU grace-period pre-initialization, that is, + the propagation of recent CPU-hotplug changes up + the rcu_node combining tree. This only has effect + when CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT is set. + + rcutree.rcu_fanout_exact= [KNL] + Disable autobalancing of the rcu_node combining + tree. This is used by rcutorture, and might + possibly be useful for architectures having high + cache-to-cache transfer latencies. rcutree.rcu_fanout_leaf= [KNL] Increase the number of CPUs assigned to each @@ -3107,7 +3143,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. test, hence the "fake". rcutorture.nreaders= [KNL] - Set number of RCU readers. + Set number of RCU readers. The value -1 selects + N-1, where N is the number of CPUs. A value + "n" less than -1 selects N-n-2, where N is again + the number of CPUs. For example, -2 selects N + (the number of CPUs), -3 selects N+1, and so on. rcutorture.object_debug= [KNL] Enable debug-object double-call_rcu() testing. diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 45e777f4e41d..18e24abb3ecf 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -6,7 +6,7 @@ Introduction Kmemleak provides a way of detecting possible kernel memory leaks in a way similar to a tracing garbage collector -(http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors), +(https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors), with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in diff --git a/Documentation/laptops/.gitignore b/Documentation/laptops/.gitignore index da2bd065f4bc..9fc984e64386 100644 --- a/Documentation/laptops/.gitignore +++ b/Documentation/laptops/.gitignore @@ -1,2 +1 @@ dslm -freefall diff --git a/Documentation/laptops/00-INDEX b/Documentation/laptops/00-INDEX index a3b4f209e562..7c0ac2a26b9e 100644 --- a/Documentation/laptops/00-INDEX +++ b/Documentation/laptops/00-INDEX @@ -8,8 +8,6 @@ disk-shock-protection.txt - information on hard disk shock protection. dslm.c - Simple Disk Sleep Monitor program -freefall.c - - (HP/DELL) laptop accelerometer program for disk protection. laptop-mode.txt - how to conserve battery power using laptop-mode. sony-laptop.txt diff --git a/Documentation/laptops/Makefile b/Documentation/laptops/Makefile index 2b0fa5edf1d3..0abe44f68965 100644 --- a/Documentation/laptops/Makefile +++ b/Documentation/laptops/Makefile @@ -1,5 +1,5 @@ # List of programs to build -hostprogs-y := dslm freefall +hostprogs-y := dslm # Tell kbuild to always build the programs always := $(hostprogs-y) diff --git a/Documentation/laptops/freefall.c b/Documentation/laptops/freefall.c deleted file mode 100644 index 5e44b20b1848..000000000000 --- a/Documentation/laptops/freefall.c +++ /dev/null @@ -1,174 +0,0 @@ -/* Disk protection for HP/DELL machines. - * - * Copyright 2008 Eric Piel - * Copyright 2009 Pavel Machek <pavel@ucw.cz> - * Copyright 2012 Sonal Santan - * Copyright 2014 Pali Rohár <pali.rohar@gmail.com> - * - * GPLv2. - */ - -#include <stdio.h> -#include <stdlib.h> -#include <unistd.h> -#include <fcntl.h> -#include <sys/stat.h> -#include <sys/types.h> -#include <string.h> -#include <stdint.h> -#include <errno.h> -#include <signal.h> -#include <sys/mman.h> -#include <sched.h> -#include <syslog.h> - -static int noled; -static char unload_heads_path[64]; -static char device_path[32]; -static const char app_name[] = "FREE FALL"; - -static int set_unload_heads_path(char *device) -{ - if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) - return -EINVAL; - strncpy(device_path, device, sizeof(device_path) - 1); - - snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, - "/sys/block/%s/device/unload_heads", device+5); - return 0; -} - -static int valid_disk(void) -{ - int fd = open(unload_heads_path, O_RDONLY); - - if (fd < 0) { - perror(unload_heads_path); - return 0; - } - - close(fd); - return 1; -} - -static void write_int(char *path, int i) -{ - char buf[1024]; - int fd = open(path, O_RDWR); - - if (fd < 0) { - perror("open"); - exit(1); - } - - sprintf(buf, "%d", i); - - if (write(fd, buf, strlen(buf)) != strlen(buf)) { - perror("write"); - exit(1); - } - - close(fd); -} - -static void set_led(int on) -{ - if (noled) - return; - write_int("/sys/class/leds/hp::hddprotect/brightness", on); -} - -static void protect(int seconds) -{ - const char *str = (seconds == 0) ? "Unparked" : "Parked"; - - write_int(unload_heads_path, seconds*1000); - syslog(LOG_INFO, "%s %s disk head\n", str, device_path); -} - -static int on_ac(void) -{ - /* /sys/class/power_supply/AC0/online */ - return 1; -} - -static int lid_open(void) -{ - /* /proc/acpi/button/lid/LID/state */ - return 1; -} - -static void ignore_me(int signum) -{ - protect(0); - set_led(0); -} - -int main(int argc, char **argv) -{ - int fd, ret; - struct stat st; - struct sched_param param; - - if (argc == 1) - ret = set_unload_heads_path("/dev/sda"); - else if (argc == 2) - ret = set_unload_heads_path(argv[1]); - else - ret = -EINVAL; - - if (ret || !valid_disk()) { - fprintf(stderr, "usage: %s <device> (default: /dev/sda)\n", - argv[0]); - exit(1); - } - - fd = open("/dev/freefall", O_RDONLY); - if (fd < 0) { - perror("/dev/freefall"); - return EXIT_FAILURE; - } - - if (stat("/sys/class/leds/hp::hddprotect/brightness", &st)) - noled = 1; - - if (daemon(0, 0) != 0) { - perror("daemon"); - return EXIT_FAILURE; - } - - openlog(app_name, LOG_CONS | LOG_PID | LOG_NDELAY, LOG_LOCAL1); - - param.sched_priority = sched_get_priority_max(SCHED_FIFO); - sched_setscheduler(0, SCHED_FIFO, ¶m); - mlockall(MCL_CURRENT|MCL_FUTURE); - - signal(SIGALRM, ignore_me); - - for (;;) { - unsigned char count; - - ret = read(fd, &count, sizeof(count)); - alarm(0); - if ((ret == -1) && (errno == EINTR)) { - /* Alarm expired, time to unpark the heads */ - continue; - } - - if (ret != sizeof(count)) { - perror("read"); - break; - } - - protect(21); - set_led(1); - if (1 || on_ac() || lid_open()) - alarm(2); - else - alarm(20); - } - - closelog(); - close(fd); - return EXIT_SUCCESS; -} diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index 79699c200766..62261c04060a 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -2,9 +2,6 @@ LED handling under Linux ======================== -If you're reading this and thinking about keyboard leds, these are -handled by the input subsystem and the led class is *not* needed. - In its simplest form, the LED class just allows control of LEDs from userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the LED is defined in max_brightness file. The brightness file will set the brightness diff --git a/Documentation/lockup-watchdogs.txt b/Documentation/lockup-watchdogs.txt index ab0baa692c13..22dd6af2e4bd 100644 --- a/Documentation/lockup-watchdogs.txt +++ b/Documentation/lockup-watchdogs.txt @@ -61,3 +61,21 @@ As explained above, a kernel knob is provided that allows administrators to configure the period of the hrtimer and the perf event. The right value for a particular environment is a trade-off between fast response to lockups and detection overhead. + +By default, the watchdog runs on all online cores. However, on a +kernel configured with NO_HZ_FULL, by default the watchdog runs only +on the housekeeping cores, not the cores specified in the "nohz_full" +boot argument. If we allowed the watchdog to run by default on +the "nohz_full" cores, we would have to run timer ticks to activate +the scheduler, which would prevent the "nohz_full" functionality +from protecting the user code on those cores from the kernel. +Of course, disabling it by default on the nohz_full cores means that +when those cores do enter the kernel, by default we will not be +able to detect if they lock up. However, allowing the watchdog +to continue to run on the housekeeping (non-tickless) cores means +that we will continue to detect lockups properly on those cores. + +In either case, the set of cores excluded from running the watchdog +may be adjusted via the kernel.watchdog_cpumask sysctl. For +nohz_full cores, this may be useful for debugging a case where the +kernel seems to be hanging on the nohz_full cores. diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index 4c8e142db2ef..28befed9f610 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -116,7 +116,6 @@ COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9] -SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h RED_MAGIC1 0x5a2cf071 (any) mm/slab.c @@ -138,7 +137,6 @@ KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h -SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h CODA_MAGIC 0xC0DAC0DA coda_file_info fs/coda/coda_fs_i.h DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c diff --git a/Documentation/md.txt b/Documentation/md.txt index f925666e4342..1a2ada46aaed 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -549,7 +549,7 @@ also have sync_speed_max This are similar to /proc/sys/dev/raid/speed_limit_{min,max} however they only apply to the particular array. - If no value has been written to these, of if the word 'system' + If no value has been written to these, or if the word 'system' is written, then the system-wide value is used. If a value, in kibibytes-per-second is written, then it is used. When the files are read, they show the currently active value diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index f95746189b5d..13feb697271f 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -617,16 +617,16 @@ case what's actually required is: However, stores are not speculated. This means that ordering -is- provided for load-store control dependencies, as in the following example: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); if (q) { ACCESS_ONCE(b) = p; } -Control dependencies pair normally with other types of barriers. -That said, please note that ACCESS_ONCE() is not optional! Without the -ACCESS_ONCE(), might combine the load from 'a' with other loads from -'a', and the store to 'b' with other stores to 'b', with possible highly -counterintuitive effects on ordering. +Control dependencies pair normally with other types of barriers. That +said, please note that READ_ONCE_CTRL() is not optional! Without the +READ_ONCE_CTRL(), the compiler might combine the load from 'a' with +other loads from 'a', and the store to 'b' with other stores to 'b', +with possible highly counterintuitive effects on ordering. Worse yet, if the compiler is able to prove (say) that the value of variable 'a' is always non-zero, it would be well within its rights @@ -636,12 +636,15 @@ as follows: q = a; b = p; /* BUG: Compiler and CPU can both reorder!!! */ -So don't leave out the ACCESS_ONCE(). +Finally, the READ_ONCE_CTRL() includes an smp_read_barrier_depends() +that DEC Alpha needs in order to respect control depedencies. + +So don't leave out the READ_ONCE_CTRL(). It is tempting to try to enforce ordering on identical stores on both branches of the "if" statement as follows: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); if (q) { barrier(); ACCESS_ONCE(b) = p; @@ -655,7 +658,7 @@ branches of the "if" statement as follows: Unfortunately, current compilers will transform this as follows at high optimization levels: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); barrier(); ACCESS_ONCE(b) = p; /* BUG: No ordering vs. load from a!!! */ if (q) { @@ -685,7 +688,7 @@ memory barriers, for example, smp_store_release(): In contrast, without explicit memory barriers, two-legged-if control ordering is guaranteed only when the stores differ, for example: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); if (q) { ACCESS_ONCE(b) = p; do_something(); @@ -694,14 +697,14 @@ ordering is guaranteed only when the stores differ, for example: do_something_else(); } -The initial ACCESS_ONCE() is still required to prevent the compiler from -proving the value of 'a'. +The initial READ_ONCE_CTRL() is still required to prevent the compiler +from proving the value of 'a'. In addition, you need to be careful what you do with the local variable 'q', otherwise the compiler might be able to guess the value and again remove the needed conditional. For example: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); if (q % MAX) { ACCESS_ONCE(b) = p; do_something(); @@ -714,7 +717,7 @@ If MAX is defined to be 1, then the compiler knows that (q % MAX) is equal to zero, in which case the compiler is within its rights to transform the above code into the following: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); ACCESS_ONCE(b) = p; do_something_else(); @@ -725,7 +728,7 @@ is gone, and the barrier won't bring it back. Therefore, if you are relying on this ordering, you should make sure that MAX is greater than one, perhaps as follows: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */ if (q % MAX) { ACCESS_ONCE(b) = p; @@ -742,14 +745,15 @@ of the 'if' statement. You must also be careful not to rely too much on boolean short-circuit evaluation. Consider this example: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); if (a || 1 > 0) ACCESS_ONCE(b) = 1; -Because the second condition is always true, the compiler can transform -this example as following, defeating control dependency: +Because the first condition cannot fault and the second condition is +always true, the compiler can transform this example as following, +defeating control dependency: - q = ACCESS_ONCE(a); + q = READ_ONCE_CTRL(a); ACCESS_ONCE(b) = 1; This example underscores the need to ensure that the compiler cannot @@ -762,8 +766,8 @@ demonstrated by two related examples, with the initial values of x and y both being zero: CPU 0 CPU 1 - ===================== ===================== - r1 = ACCESS_ONCE(x); r2 = ACCESS_ONCE(y); + ======================= ======================= + r1 = READ_ONCE_CTRL(x); r2 = READ_ONCE_CTRL(y); if (r1 > 0) if (r2 > 0) ACCESS_ONCE(y) = 1; ACCESS_ONCE(x) = 1; @@ -783,7 +787,8 @@ But because control dependencies do -not- provide transitivity, the above assertion can fail after the combined three-CPU example completes. If you need the three-CPU example to provide ordering, you will need smp_mb() between the loads and stores in the CPU 0 and CPU 1 code fragments, -that is, just before or just after the "if" statements. +that is, just before or just after the "if" statements. Furthermore, +the original two-CPU example is very fragile and should be avoided. These two examples are the LB and WWC litmus tests from this paper: http://www.cl.cam.ac.uk/users/pes20/ppc-supplemental/test6.pdf and this @@ -791,6 +796,12 @@ site: https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html. In summary: + (*) Control dependencies must be headed by READ_ONCE_CTRL(). + Or, as a much less preferable alternative, interpose + be headed by READ_ONCE() or an ACCESS_ONCE() read and must + have smp_read_barrier_depends() between this read and the + control-dependent write. + (*) Control dependencies can order prior loads against later stores. However, they do -not- guarantee any other sort of ordering: Not prior loads against later loads, nor prior stores against @@ -1662,7 +1673,7 @@ CPU from reordering them. There are some more advanced barrier functions: - (*) set_mb(var, value) + (*) smp_store_mb(var, value) This assigns the value to the variable and then inserts a full memory barrier after it, depending on the function. It isn't guaranteed to @@ -1784,10 +1795,9 @@ for each construct. These operations all imply certain barriers: Memory operations issued before the ACQUIRE may be completed after the ACQUIRE operation has completed. An smp_mb__before_spinlock(), - combined with a following ACQUIRE, orders prior loads against - subsequent loads and stores and also orders prior stores against - subsequent stores. Note that this is weaker than smp_mb()! The - smp_mb__before_spinlock() primitive is free on many architectures. + combined with a following ACQUIRE, orders prior stores against + subsequent loads and stores. Note that this is weaker than smp_mb()! + The smp_mb__before_spinlock() primitive is free on many architectures. (2) RELEASE operation implication: @@ -1975,7 +1985,7 @@ after it has altered the task state: CPU 1 =============================== set_current_state(); - set_mb(); + smp_store_mb(); STORE current->state <general barrier> LOAD event_indicated @@ -2016,7 +2026,7 @@ between the STORE to indicate the event and the STORE to set TASK_RUNNING: CPU 1 CPU 2 =============================== =============================== set_current_state(); STORE event_indicated - set_mb(); wake_up(); + smp_store_mb(); wake_up(); STORE current->state <write barrier> <general barrier> STORE current->state LOAD event_indicated diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile index f47fe6ba7300..06871b0c08a6 100644 --- a/Documentation/mic/mpssd/Makefile +++ b/Documentation/mic/mpssd/Makefile @@ -1,3 +1,4 @@ +ifndef CROSS_COMPILE # List of programs to build hostprogs-$(CONFIG_X86_64) := mpssd @@ -17,3 +18,4 @@ HOSTLOADLIBES_mpssd := -lpthread install: install mpssd /usr/sbin/mpssd install micctrl /usr/sbin/micctrl +endif diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 83bf4986baea..334b49ef02d1 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -51,6 +51,7 @@ Table of Contents 3.4 Configuring Bonding Manually via Sysfs 3.5 Configuration with Interfaces Support 3.6 Overriding Configuration for Special Cases +3.7 Configuring LACP for 802.3ad mode in a more secure way 4. Querying Bonding Configuration 4.1 Bonding Configuration @@ -178,6 +179,27 @@ active_slave active slave, or the empty string if there is no active slave or the current mode does not use an active slave. +ad_actor_sys_prio + + In an AD system, this specifies the system priority. The allowed range + is 1 - 65535. If the value is not specified, it takes 65535 as the + default value. + + This parameter has effect only in 802.3ad mode and is available through + SysFs interface. + +ad_actor_system + + In an AD system, this specifies the mac-address for the actor in + protocol packet exchanges (LACPDUs). The value cannot be NULL or + multicast. It is preferred to have the local-admin bit set for this + mac but driver does not enforce it. If the value is not given then + system defaults to using the masters' mac address as actors' system + address. + + This parameter has effect only in 802.3ad mode and is available through + SysFs interface. + ad_select Specifies the 802.3ad aggregation selection logic to use. The @@ -220,6 +242,21 @@ ad_select This option was added in bonding version 3.4.0. +ad_user_port_key + + In an AD system, the port-key has three parts as shown below - + + Bits Use + 00 Duplex + 01-05 Speed + 06-15 User-defined + + This defines the upper 10 bits of the port key. The values can be + from 0 - 1023. If not given, the system defaults to 0. + + This parameter has effect only in 802.3ad mode and is available through + SysFs interface. + all_slaves_active Specifies that duplicate frames (received on inactive ports) should be @@ -1622,6 +1659,53 @@ output port selection. This feature first appeared in bonding driver version 3.7.0 and support for output slave selection was limited to round-robin and active-backup modes. +3.7 Configuring LACP for 802.3ad mode in a more secure way +---------------------------------------------------------- + +When using 802.3ad bonding mode, the Actor (host) and Partner (switch) +exchange LACPDUs. These LACPDUs cannot be sniffed, because they are +destined to link local mac addresses (which switches/bridges are not +supposed to forward). However, most of the values are easily predictable +or are simply the machine's MAC address (which is trivially known to all +other hosts in the same L2). This implies that other machines in the L2 +domain can spoof LACPDU packets from other hosts to the switch and potentially +cause mayhem by joining (from the point of view of the switch) another +machine's aggregate, thus receiving a portion of that hosts incoming +traffic and / or spoofing traffic from that machine themselves (potentially +even successfully terminating some portion of flows). Though this is not +a likely scenario, one could avoid this possibility by simply configuring +few bonding parameters: + + (a) ad_actor_system : You can set a random mac-address that can be used for + these LACPDU exchanges. The value can not be either NULL or Multicast. + Also it's preferable to set the local-admin bit. Following shell code + generates a random mac-address as described above. + + # sys_mac_addr=$(printf '%02x:%02x:%02x:%02x:%02x:%02x' \ + $(( (RANDOM & 0xFE) | 0x02 )) \ + $(( RANDOM & 0xFF )) \ + $(( RANDOM & 0xFF )) \ + $(( RANDOM & 0xFF )) \ + $(( RANDOM & 0xFF )) \ + $(( RANDOM & 0xFF ))) + # echo $sys_mac_addr > /sys/class/net/bond0/bonding/ad_actor_system + + (b) ad_actor_sys_prio : Randomize the system priority. The default value + is 65535, but system can take the value from 1 - 65535. Following shell + code generates random priority and sets it. + + # sys_prio=$(( 1 + RANDOM + RANDOM )) + # echo $sys_prio > /sys/class/net/bond0/bonding/ad_actor_sys_prio + + (c) ad_user_port_key : Use the user portion of the port-key. The default + keeps this empty. These are the upper 10 bits of the port-key and value + ranges from 0 - 1023. Following shell code generates these 10 bits and + sets it. + + # usr_port_key=$(( RANDOM & 0x3FF )) + # echo $usr_port_key > /sys/class/net/bond0/bonding/ad_user_port_key + + 4 Querying Bonding Configuration ================================= diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 5abad1e921ca..b48d4a149411 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -268,6 +268,9 @@ solution for a couple of reasons: struct can_frame { canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ __u8 can_dlc; /* frame payload length in byte (0 .. 8) */ + __u8 __pad; /* padding */ + __u8 __res0; /* reserved / padding */ + __u8 __res1; /* reserved / padding */ __u8 data[8] __attribute__((aligned(8))); }; diff --git a/Documentation/networking/dctcp.txt b/Documentation/networking/dctcp.txt index 0d5dfbc89ec9..13a857753208 100644 --- a/Documentation/networking/dctcp.txt +++ b/Documentation/networking/dctcp.txt @@ -8,6 +8,7 @@ the data center network to provide multi-bit feedback to the end hosts. To enable it on end hosts: sysctl -w net.ipv4.tcp_congestion_control=dctcp + sysctl -w net.ipv4.tcp_ecn_fallback=0 (optional) All switches in the data center network running DCTCP must support ECN marking and be configured for marking when reaching defined switch buffer diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt index d52af53efdc5..1f98f62b4370 100644 --- a/Documentation/networking/fore200e.txt +++ b/Documentation/networking/fore200e.txt @@ -37,7 +37,7 @@ version. Alternative binary firmware images can be found somewhere on the ForeThought CD-ROM supplied with your adapter by FORE Systems. You can also get the latest firmware images from FORE Systems at -http://en.wikipedia.org/wiki/FORE_Systems. Register TACTics Online and go to +https://en.wikipedia.org/wiki/FORE_Systems. Register TACTics Online and go to the 'software updates' pages. The firmware binaries are part of the various ForeThought software distributions. diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index 22bbc7225f8e..1700756af057 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -30,8 +30,8 @@ int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0); The address family, socket addresses etc. are defined in the include/net/af_ieee802154.h header or in the special header -in our userspace package (see either linux-zigbee sourceforge download page -or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee). +in the userspace package (see either http://wpan.cakelab.org/ or the +git tree at https://github.com/linux-wpan/wpan-tools). One can use SOCK_RAW for passing raw data towards device xmit function. YMMV. @@ -49,15 +49,6 @@ 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 ======= @@ -75,8 +66,6 @@ net_device with a pointer to struct ieee802154_mlme_ops instance. The fields assoc_req, assoc_resp, disassoc_req, start_req, and scan_req are optional. All other fields are required. -We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c - SoftMAC ======= @@ -89,7 +78,8 @@ 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/. +See header include/net/mac802154.h and several drivers in +drivers/net/ieee802154/. Device drivers API @@ -114,18 +104,17 @@ 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. +In addition there is a driver available which simulates a real device with +SoftMAC (fakelb - IEEE 802.15.4 loopback driver) interface. This option +provides possibility to test and debug stack without usage of real hardware. -See sources in drivers/ieee802154 folder for more details. +See sources in drivers/net/ieee802154 folder for more details. 6LoWPAN Linux implementation ============================ -The IEEE 802.15.4 standard specifies an MTU of 128 bytes, yielding about 80 +The IEEE 802.15.4 standard specifies an MTU of 127 bytes, yielding about 80 octets of actual MAC payload once security is turned on, on a wireless link with a link throughput of 250 kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 datagrams over such constrained links, @@ -140,7 +129,8 @@ In Semptember 2011 the standard update was published - [RFC6282]. It deprecates HC1 and HC2 compression and defines IPHC encoding format which is used in this Linux implementation. -All the code related to 6lowpan you may find in files: net/ieee802154/6lowpan.* +All the code related to 6lowpan you may find in files: net/6lowpan/* +and net/ieee802154/6lowpan/* To setup 6lowpan interface you need (busybox release > 1.17.0): 1. Add IEEE802.15.4 interface and initialize PANid; diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 071fb18dc57c..5fae7704daab 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -267,6 +267,15 @@ tcp_ecn - INTEGER but do not request ECN on outgoing connections. Default: 2 +tcp_ecn_fallback - BOOLEAN + If the kernel detects that ECN connection misbehaves, enable fall + back to non-ECN. Currently, this knob implements the fallback + from RFC3168, section 6.1.1.1., but we reserve that in future, + additional detection mechanisms could be implemented under this + knob. The value is not used, if tcp_ecn or per route (or congestion + control) ECN settings are disabled. + Default: 1 (fallback enabled) + tcp_fack - BOOLEAN Enable FACK congestion avoidance and fast retransmission. The value is not used, if tcp_sack is not enabled. @@ -742,8 +751,10 @@ IP Variables: ip_local_port_range - 2 INTEGERS Defines the local port range that is used by TCP and UDP to choose the local port. The first number is the first, the - second the last local port number. The default values are - 32768 and 61000 respectively. + second the last local port number. + If possible, it is better these numbers have different parity. + (one even and one odd values) + The default values are 32768 and 60999 respectively. ip_local_reserved_ports - list of comma separated ranges Specify the ports which are reserved for known third-party @@ -766,7 +777,7 @@ ip_local_reserved_ports - list of comma separated ranges ip_local_port_range, e.g.: $ cat /proc/sys/net/ipv4/ip_local_port_range - 32000 61000 + 32000 60999 $ cat /proc/sys/net/ipv4/ip_local_reserved_ports 8080,9148 @@ -1213,6 +1224,14 @@ auto_flowlabels - BOOLEAN FALSE: disabled Default: false +flowlabel_state_ranges - BOOLEAN + Split the flow label number space into two ranges. 0-0x7FFFF is + reserved for the IPv6 flow manager facility, 0x80000-0xFFFFF + is reserved for stateless flow labels as described in RFC6437. + TRUE: enabled + FALSE: disabled + Default: true + anycast_src_echo_reply - BOOLEAN Controls the use of anycast addresses as source addresses for ICMPv6 echo reply diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 0344f1d45b37..f4be85e96005 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -1,6 +1,6 @@ - HOWTO for the linux packet generator + HOWTO for the linux packet generator ------------------------------------ Enable CONFIG_NET_PKTGEN to compile and build pktgen either in-kernel @@ -50,17 +50,33 @@ For ixgbe use e.g. "30" resulting in approx 33K interrupts/sec (1/30*10^6): # ethtool -C ethX rx-usecs 30 -Viewing threads -=============== -/proc/net/pktgen/kpktgend_0 -Name: kpktgend_0 max_before_softirq: 10000 -Running: -Stopped: eth1 -Result: OK: max_before_softirq=10000 +Kernel threads +============== +Pktgen creates a thread for each CPU with affinity to that CPU. +Which is controlled through procfile /proc/net/pktgen/kpktgend_X. + +Example: /proc/net/pktgen/kpktgend_0 + + Running: + Stopped: eth4@0 + Result: OK: add_device=eth4@0 + +Most important are the devices assigned to the thread. + +The two basic thread commands are: + * add_device DEVICE@NAME -- adds a single device + * rem_device_all -- remove all associated devices + +When adding a device to a thread, a corrosponding procfile is created +which is used for configuring this device. Thus, device names need to +be unique. -Most important are the devices assigned to the thread. Note that a -device can only belong to one thread. +To support adding the same device to multiple threads, which is useful +with multi queue NICs, a the device naming scheme is extended with "@": + device@something +The part after "@" can be anything, but it is custom to use the thread +number. Viewing devices =============== @@ -69,29 +85,32 @@ The Params section holds configured information. The Current section holds running statistics. The Result is printed after a run or after interruption. Example: -/proc/net/pktgen/eth1 +/proc/net/pktgen/eth4@0 -Params: count 10000000 min_pkt_size: 60 max_pkt_size: 60 - frags: 0 delay: 0 clone_skb: 1000000 ifname: eth1 + Params: count 100000 min_pkt_size: 60 max_pkt_size: 60 + frags: 0 delay: 0 clone_skb: 64 ifname: eth4@0 flows: 0 flowlen: 0 - dst_min: 10.10.11.2 dst_max: - src_min: src_max: - src_mac: 00:00:00:00:00:00 dst_mac: 00:04:23:AC:FD:82 - udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 - src_mac_count: 0 dst_mac_count: 0 - Flags: -Current: - pkts-sofar: 10000000 errors: 39664 - started: 1103053986245187us stopped: 1103053999346329us idle: 880401us - seq_num: 10000011 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 - cur_saddr: 0x10a0a0a cur_daddr: 0x20b0a0a - cur_udp_dst: 9 cur_udp_src: 9 + queue_map_min: 0 queue_map_max: 0 + dst_min: 192.168.81.2 dst_max: + src_min: src_max: + src_mac: 90:e2:ba:0a:56:b4 dst_mac: 00:1b:21:3c:9d:f8 + udp_src_min: 9 udp_src_max: 109 udp_dst_min: 9 udp_dst_max: 9 + src_mac_count: 0 dst_mac_count: 0 + Flags: UDPSRC_RND NO_TIMESTAMP QUEUE_MAP_CPU + Current: + pkts-sofar: 100000 errors: 0 + started: 623913381008us stopped: 623913396439us idle: 25us + seq_num: 100001 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 + cur_saddr: 192.168.8.3 cur_daddr: 192.168.81.2 + cur_udp_dst: 9 cur_udp_src: 42 + cur_queue_map: 0 flows: 0 -Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags) - 763292pps 390Mb/sec (390805504bps) errors: 39664 + Result: OK: 15430(c15405+d25) usec, 100000 (60byte,0frags) + 6480562pps 3110Mb/sec (3110669760bps) errors: 0 -Configuring threads and devices -================================ + +Configuring devices +=================== This is done via the /proc interface, and most easily done via pgset as defined in the sample scripts. @@ -126,7 +145,7 @@ Examples: To select queue 1 of a given device, use queue_map_min=1 and queue_map_max=1 - pgset "src_mac_count 1" Sets the number of MACs we'll range through. + pgset "src_mac_count 1" Sets the number of MACs we'll range through. The 'minimum' MAC is what you set with srcmac. pgset "dst_mac_count 1" Sets the number of MACs we'll range through. @@ -145,6 +164,7 @@ Examples: UDPCSUM, IPSEC # IPsec encapsulation (needs CONFIG_XFRM) NODE_ALLOC # node specific memory allocation + NO_TIMESTAMP # disable timestamping pgset spi SPI_VALUE Set specific SA used to transform packet. @@ -192,24 +212,43 @@ Examples: pgset "rate 300M" set rate to 300 Mb/s pgset "ratep 1000000" set rate to 1Mpps + pgset "xmit_mode netif_receive" RX inject into stack netif_receive_skb() + Works with "burst" but not with "clone_skb". + Default xmit_mode is "start_xmit". + Sample scripts ============== -A collection of small tutorial scripts for pktgen is in the -samples/pktgen directory: +A collection of tutorial scripts and helpers for pktgen is in the +samples/pktgen directory. The helper parameters.sh file support easy +and consistant parameter parsing across the sample scripts. + +Usage example and help: + ./pktgen_sample01_simple.sh -i eth4 -m 00:1B:21:3C:9D:F8 -d 192.168.8.2 + +Usage: ./pktgen_sample01_simple.sh [-vx] -i ethX + -i : ($DEV) output interface/device (required) + -s : ($PKT_SIZE) packet size + -d : ($DEST_IP) destination IP + -m : ($DST_MAC) destination MAC-addr + -t : ($THREADS) threads to start + -c : ($SKB_CLONE) SKB clones send before alloc new SKB + -b : ($BURST) HW level bursting of SKBs + -v : ($VERBOSE) verbose + -x : ($DEBUG) debug + +The global variables being set are also listed. E.g. the required +interface/device parameter "-i" sets variable $DEV. Copy the +pktgen_sampleXX scripts and modify them to fit your own needs. + +The old scripts: -pktgen.conf-1-1 # 1 CPU 1 dev pktgen.conf-1-2 # 1 CPU 2 dev -pktgen.conf-2-1 # 2 CPU's 1 dev -pktgen.conf-2-2 # 2 CPU's 2 dev pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6 pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows. -Run in shell: ./pktgen.conf-X-Y -This does all the setup including sending. - Interrupt affinity =================== @@ -217,6 +256,9 @@ Note that when adding devices to a specific CPU it is a good idea to also assign /proc/irq/XX/smp_affinity so that the TX interrupts are bound to the same CPU. This reduces cache bouncing when freeing skbs. +Plus using the device flag QUEUE_MAP_CPU, which maps the SKBs TX queue +to the running threads CPU (directly from smp_processor_id()). + Enable IPsec ============ Default IPsec transformation with ESP encapsulation plus transport mode @@ -237,18 +279,19 @@ Current commands and configuration options start stop +reset ** Thread commands: add_device rem_device_all -max_before_softirq ** Device commands: count clone_skb +burst debug frags @@ -257,10 +300,17 @@ delay src_mac_count dst_mac_count -pkt_size +pkt_size min_pkt_size max_pkt_size +queue_map_min +queue_map_max +skb_priority + +tos (ipv4) +traffic_class (ipv6) + mpls udp_src_min @@ -269,6 +319,8 @@ udp_src_max udp_dst_min udp_dst_max +node + flag IPSRC_RND IPDST_RND @@ -287,6 +339,9 @@ flag UDPCSUM IPSEC NODE_ALLOC + NO_TIMESTAMP + +spi (ipsec) dst_min dst_max @@ -299,8 +354,10 @@ src_mac clear_counters -dst6 src6 +dst6 +dst6_max +dst6_min flows flowlen @@ -308,6 +365,17 @@ flowlen rate ratep +xmit_mode <start_xmit|netif_receive> + +vlan_cfi +vlan_id +vlan_p + +svlan_cfi +svlan_id +svlan_p + + References: ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/ ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt index f981a9295a39..c5d7ade10ff2 100644 --- a/Documentation/networking/switchdev.txt +++ b/Documentation/networking/switchdev.txt @@ -1,59 +1,360 @@ -Switch (and switch-ish) device drivers HOWTO -=========================== - -Please note that the word "switch" is here used in very generic meaning. -This include devices supporting L2/L3 but also various flow offloading chips, -including switches embedded into SR-IOV NICs. - -Lets describe a topology a bit. Imagine the following example: - - +----------------------------+ +---------------+ - | SOME switch chip | | CPU | - +----------------------------+ +---------------+ - port1 port2 port3 port4 MNGMNT | PCI-E | - | | | | | +---------------+ - PHY PHY | | | | NIC0 NIC1 - | | | | | | - | | +- PCI-E -+ | | - | +------- MII -------+ | - +------------- MII ------------+ - -In this example, there are two independent lines between the switch silicon -and CPU. NIC0 and NIC1 drivers are not aware of a switch presence. They are -separate from the switch driver. SOME switch chip is by managed by a driver -via PCI-E device MNGMNT. Note that MNGMNT device, NIC0 and NIC1 may be -connected to some other type of bus. - -Now, for the previous example show the representation in kernel: - - +----------------------------+ +---------------+ - | SOME switch chip | | CPU | - +----------------------------+ +---------------+ - sw0p0 sw0p1 sw0p2 sw0p3 MNGMNT | PCI-E | - | | | | | +---------------+ - PHY PHY | | | | eth0 eth1 - | | | | | | - | | +- PCI-E -+ | | - | +------- MII -------+ | - +------------- MII ------------+ - -Lets call the example switch driver for SOME switch chip "SOMEswitch". This -driver takes care of PCI-E device MNGMNT. There is a netdevice instance sw0pX -created for each port of a switch. These netdevices are instances -of "SOMEswitch" driver. sw0pX netdevices serve as a "representation" -of the switch chip. eth0 and eth1 are instances of some other existing driver. - -The only difference of the switch-port netdevice from the ordinary netdevice -is that is implements couple more NDOs: - - ndo_switch_parent_id_get - This returns the same ID for two port netdevices - of the same physical switch chip. This is - mandatory to be implemented by all switch drivers - and serves the caller for recognition of a port - netdevice. - ndo_switch_parent_* - Functions that serve for a manipulation of the switch - chip itself (it can be though of as a "parent" of the - port, therefore the name). They are not port-specific. - Caller might use arbitrary port netdevice of the same - switch and it will make no difference. - ndo_switch_port_* - Functions that serve for a port-specific manipulation. +Ethernet switch device driver model (switchdev) +=============================================== +Copyright (c) 2014 Jiri Pirko <jiri@resnulli.us> +Copyright (c) 2014-2015 Scott Feldman <sfeldma@gmail.com> + + +The Ethernet switch device driver model (switchdev) is an in-kernel driver +model for switch devices which offload the forwarding (data) plane from the +kernel. + +Figure 1 is a block diagram showing the components of the switchdev model for +an example setup using a data-center-class switch ASIC chip. Other setups +with SR-IOV or soft switches, such as OVS, are possible. + + + User-space tools + + user space | + +-------------------------------------------------------------------+ + kernel | Netlink + | + +--------------+-------------------------------+ + | Network stack | + | (Linux) | + | | + +----------------------------------------------+ + + sw1p2 sw1p4 sw1p6 + sw1p1 + sw1p3 + sw1p5 + eth1 + + | + | + | + + | | | | | | | + +--+----+----+----+-+--+----+---+ +-----+-----+ + | Switch driver | | mgmt | + | (this document) | | driver | + | | | | + +--------------+----------------+ +-----------+ + | + kernel | HW bus (eg PCI) + +-------------------------------------------------------------------+ + hardware | + +--------------+---+------------+ + | Switch device (sw1) | + | +----+ +--------+ + | | v offloaded data path | mgmt port + | | | | + +--|----|----+----+----+----+---+ + | | | | | | + + + + + + + + p1 p2 p3 p4 p5 p6 + + front-panel ports + + + Fig 1. + + +Include Files +------------- + +#include <linux/netdevice.h> +#include <net/switchdev.h> + + +Configuration +------------- + +Use "depends NET_SWITCHDEV" in driver's Kconfig to ensure switchdev model +support is built for driver. + + +Switch Ports +------------ + +On switchdev driver initialization, the driver will allocate and register a +struct net_device (using register_netdev()) for each enumerated physical switch +port, called the port netdev. A port netdev is the software representation of +the physical port and provides a conduit for control traffic to/from the +controller (the kernel) and the network, as well as an anchor point for higher +level constructs such as bridges, bonds, VLANs, tunnels, and L3 routers. Using +standard netdev tools (iproute2, ethtool, etc), the port netdev can also +provide to the user access to the physical properties of the switch port such +as PHY link state and I/O statistics. + +There is (currently) no higher-level kernel object for the switch beyond the +port netdevs. All of the switchdev driver ops are netdev ops or switchdev ops. + +A switch management port is outside the scope of the switchdev driver model. +Typically, the management port is not participating in offloaded data plane and +is loaded with a different driver, such as a NIC driver, on the management port +device. + +Port Netdev Naming +^^^^^^^^^^^^^^^^^^ + +Udev rules should be used for port netdev naming, using some unique attribute +of the port as a key, for example the port MAC address or the port PHYS name. +Hard-coding of kernel netdev names within the driver is discouraged; let the +kernel pick the default netdev name, and let udev set the final name based on a +port attribute. + +Using port PHYS name (ndo_get_phys_port_name) for the key is particularly +useful for dynamically-named ports where the device names its ports based on +external configuration. For example, if a physical 40G port is split logically +into 4 10G ports, resulting in 4 port netdevs, the device can give a unique +name for each port using port PHYS name. The udev rule would be: + +SUBSYSTEM=="net", ACTION=="add", DRIVER="<driver>", ATTR{phys_port_name}!="", \ + NAME="$attr{phys_port_name}" + +Suggested naming convention is "swXpYsZ", where X is the switch name or ID, Y +is the port name or ID, and Z is the sub-port name or ID. For example, sw1p1s0 +would be sub-port 0 on port 1 on switch 1. + +Switch ID +^^^^^^^^^ + +The switchdev driver must implement the switchdev op switchdev_port_attr_get +for SWITCHDEV_ATTR_PORT_PARENT_ID for each port netdev, returning the same +physical ID for each port of a switch. The ID must be unique between switches +on the same system. The ID does not need to be unique between switches on +different systems. + +The switch ID is used to locate ports on a switch and to know if aggregated +ports belong to the same switch. + +Port Features +^^^^^^^^^^^^^ + +NETIF_F_NETNS_LOCAL + +If the switchdev driver (and device) only supports offloading of the default +network namespace (netns), the driver should set this feature flag to prevent +the port netdev from being moved out of the default netns. A netns-aware +driver/device would not set this flag and be responsible for partitioning +hardware to preserve netns containment. This means hardware cannot forward +traffic from a port in one namespace to another port in another namespace. + +Port Topology +^^^^^^^^^^^^^ + +The port netdevs representing the physical switch ports can be organized into +higher-level switching constructs. The default construct is a standalone +router port, used to offload L3 forwarding. Two or more ports can be bonded +together to form a LAG. Two or more ports (or LAGs) can be bridged to bridge +L2 networks. VLANs can be applied to sub-divide L2 networks. L2-over-L3 +tunnels can be built on ports. These constructs are built using standard Linux +tools such as the bridge driver, the bonding/team drivers, and netlink-based +tools such as iproute2. + +The switchdev driver can know a particular port's position in the topology by +monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a +bond will see it's upper master change. If that bond is moved into a bridge, +the bond's upper master will change. And so on. The driver will track such +movements to know what position a port is in in the overall topology by +registering for netdevice events and acting on NETDEV_CHANGEUPPER. + +L2 Forwarding Offload +--------------------- + +The idea is to offload the L2 data forwarding (switching) path from the kernel +to the switchdev device by mirroring bridge FDB entries down to the device. An +FDB entry is the {port, MAC, VLAN} tuple forwarding destination. + +To offloading L2 bridging, the switchdev driver/device should support: + + - Static FDB entries installed on a bridge port + - Notification of learned/forgotten src mac/vlans from device + - STP state changes on the port + - VLAN flooding of multicast/broadcast and unknown unicast packets + +Static FDB Entries +^^^^^^^^^^^^^^^^^^ + +The switchdev driver should implement ndo_fdb_add, ndo_fdb_del and ndo_fdb_dump +to support static FDB entries installed to the device. Static bridge FDB +entries are installed, for example, using iproute2 bridge cmd: + + bridge fdb add ADDR dev DEV [vlan VID] [self] + +The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx +ops, and handle add/delete/dump of SWITCHDEV_OBJ_PORT_FDB object using +switchdev_port_obj_xxx ops. + +XXX: what should be done if offloading this rule to hardware fails (for +example, due to full capacity in hardware tables) ? + +Note: by default, the bridge does not filter on VLAN and only bridges untagged +traffic. To enable VLAN support, turn on VLAN filtering: + + echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering + +Notification of Learned/Forgotten Source MAC/VLANs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The switch device will learn/forget source MAC address/VLAN on ingress packets +and notify the switch driver of the mac/vlan/port tuples. The switch driver, +in turn, will notify the bridge driver using the switchdev notifier call: + + err = call_switchdev_notifiers(val, dev, info); + +Where val is SWITCHDEV_FDB_ADD when learning and SWITCHDEV_FDB_DEL when +forgetting, and info points to a struct switchdev_notifier_fdb_info. On +SWITCHDEV_FDB_ADD, the bridge driver will install the FDB entry into the +bridge's FDB and mark the entry as NTF_EXT_LEARNED. The iproute2 bridge +command will label these entries "offload": + + $ bridge fdb + 52:54:00:12:35:01 dev sw1p1 master br0 permanent + 00:02:00:00:02:00 dev sw1p1 master br0 offload + 00:02:00:00:02:00 dev sw1p1 self + 52:54:00:12:35:02 dev sw1p2 master br0 permanent + 00:02:00:00:03:00 dev sw1p2 master br0 offload + 00:02:00:00:03:00 dev sw1p2 self + 33:33:00:00:00:01 dev eth0 self permanent + 01:00:5e:00:00:01 dev eth0 self permanent + 33:33:ff:00:00:00 dev eth0 self permanent + 01:80:c2:00:00:0e dev eth0 self permanent + 33:33:00:00:00:01 dev br0 self permanent + 01:00:5e:00:00:01 dev br0 self permanent + 33:33:ff:12:35:01 dev br0 self permanent + +Learning on the port should be disabled on the bridge using the bridge command: + + bridge link set dev DEV learning off + +Learning on the device port should be enabled, as well as learning_sync: + + bridge link set dev DEV learning on self + bridge link set dev DEV learning_sync on self + +Learning_sync attribute enables syncing of the learned/forgotton FDB entry to +the bridge's FDB. It's possible, but not optimal, to enable learning on the +device port and on the bridge port, and disable learning_sync. + +To support learning and learning_sync port attributes, the driver implements +switchdev op switchdev_port_attr_get/set for SWITCHDEV_ATTR_PORT_BRIDGE_FLAGS. +The driver should initialize the attributes to the hardware defaults. + +FDB Ageing +^^^^^^^^^^ + +There are two FDB ageing models supported: 1) ageing by the device, and 2) +ageing by the kernel. Ageing by the device is preferred if many FDB entries +are supported. The driver calls call_switchdev_notifiers(SWITCHDEV_FDB_DEL, +...) to age out the FDB entry. In this model, ageing by the kernel should be +turned off. XXX: how to turn off ageing in kernel on a per-port basis or +otherwise prevent the kernel from ageing out the FDB entry? + +In the kernel ageing model, the standard bridge ageing mechanism is used to age +out stale FDB entries. To keep an FDB entry "alive", the driver should refresh +the FDB entry by calling call_switchdev_notifiers(SWITCHDEV_FDB_ADD, ...). The +notification will reset the FDB entry's last-used time to now. The driver +should rate limit refresh notifications, for example, no more than once a +second. If the FDB entry expires, fdb_delete is called to remove entry from +the device. + +STP State Change on Port +^^^^^^^^^^^^^^^^^^^^^^^^ + +Internally or with a third-party STP protocol implementation (e.g. mstpd), the +bridge driver maintains the STP state for ports, and will notify the switch +driver of STP state change on a port using the switchdev op +switchdev_attr_port_set for SWITCHDEV_ATTR_PORT_STP_UPDATE. + +State is one of BR_STATE_*. The switch driver can use STP state updates to +update ingress packet filter list for the port. For example, if port is +DISABLED, no packets should pass, but if port moves to BLOCKED, then STP BPDUs +and other IEEE 01:80:c2:xx:xx:xx link-local multicast packets can pass. + +Note that STP BDPUs are untagged and STP state applies to all VLANs on the port +so packet filters should be applied consistently across untagged and tagged +VLANs on the port. + +Flooding L2 domain +^^^^^^^^^^^^^^^^^^ + +For a given L2 VLAN domain, the switch device should flood multicast/broadcast +and unknown unicast packets to all ports in domain, if allowed by port's +current STP state. The switch driver, knowing which ports are within which +vlan L2 domain, can program the switch device for flooding. The packet should +also be sent to the port netdev for processing by the bridge driver. The +bridge should not reflood the packet to the same ports the device flooded. +XXX: the mechanism to avoid duplicate flood packets is being discuseed. + +It is possible for the switch device to not handle flooding and push the +packets up to the bridge driver for flooding. This is not ideal as the number +of ports scale in the L2 domain as the device is much more efficient at +flooding packets that software. + +IGMP Snooping +^^^^^^^^^^^^^ + +XXX: complete this section + + +L3 Routing Offload +------------------ + +Offloading L3 routing requires that device be programmed with FIB entries from +the kernel, with the device doing the FIB lookup and forwarding. The device +does a longest prefix match (LPM) on FIB entries matching route prefix and +forwards the packet to the matching FIB entry's nexthop(s) egress ports. + +To program the device, the driver implements support for +SWITCHDEV_OBJ_IPV[4|6]_FIB object using switchdev_port_obj_xxx ops. +switchdev_port_obj_add is used for both adding a new FIB entry to the device, +or modifying an existing entry on the device. + +XXX: Currently, only SWITCHDEV_OBJ_IPV4_FIB objects are supported. + +SWITCHDEV_OBJ_IPV4_FIB object passes: + + struct switchdev_obj_ipv4_fib { /* IPV4_FIB */ + u32 dst; + int dst_len; + struct fib_info *fi; + u8 tos; + u8 type; + u32 nlflags; + u32 tb_id; + } ipv4_fib; + +to add/modify/delete IPv4 dst/dest_len prefix on table tb_id. The *fi +structure holds details on the route and route's nexthops. *dev is one of the +port netdevs mentioned in the routes next hop list. If the output port netdevs +referenced in the route's nexthop list don't all have the same switch ID, the +driver is not called to add/modify/delete the FIB entry. + +Routes offloaded to the device are labeled with "offload" in the ip route +listing: + + $ ip route show + default via 192.168.0.2 dev eth0 + 11.0.0.0/30 dev sw1p1 proto kernel scope link src 11.0.0.2 offload + 11.0.0.4/30 via 11.0.0.1 dev sw1p1 proto zebra metric 20 offload + 11.0.0.8/30 dev sw1p2 proto kernel scope link src 11.0.0.10 offload + 11.0.0.12/30 via 11.0.0.9 dev sw1p2 proto zebra metric 20 offload + 12.0.0.2 proto zebra metric 30 offload + nexthop via 11.0.0.1 dev sw1p1 weight 1 + nexthop via 11.0.0.9 dev sw1p2 weight 1 + 12.0.0.3 via 11.0.0.1 dev sw1p1 proto zebra metric 20 offload + 12.0.0.4 via 11.0.0.9 dev sw1p2 proto zebra metric 20 offload + 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.15 + +XXX: add/mod/del IPv6 FIB API + +Nexthop Resolution +^^^^^^^^^^^^^^^^^^ + +The FIB entry's nexthop list contains the nexthop tuple (gateway, dev), but for +the switch device to forward the packet with the correct dst mac address, the +nexthop gateways must be resolved to the neighbor's mac address. Neighbor mac +address discovery comes via the ARP (or ND) process and is available via the +arp_tbl neighbor table. To resolve the routes nexthop gateways, the driver +should trigger the kernel's neighbor resolution process. See the rocker +driver's rocker_port_ipv4_resolve() for an example. + +The driver can monitor for updates to arp_tbl using the netevent notifier +NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops +for the routes as arp_tbl updates. diff --git a/Documentation/networking/tc-actions-env-rules.txt b/Documentation/networking/tc-actions-env-rules.txt index 70d6cf608251..f37814693ad3 100644 --- a/Documentation/networking/tc-actions-env-rules.txt +++ b/Documentation/networking/tc-actions-env-rules.txt @@ -8,14 +8,8 @@ For example if your action queues a packet to be processed later, or intentionally branches by redirecting a packet, then you need to clone the packet. -There are certain fields in the skb tc_verd that need to be reset so we -avoid loops, etc. A few are generic enough that skb_act_clone() -resets them for you, so invoke skb_act_clone() rather than skb_clone(). - 2) If you munge any packet thou shalt call pskb_expand_head in the case someone else is referencing the skb. After that you "own" the skb. -You must also tell us if it is ok to munge the packet (TC_OK2MUNGE), -this way any action downstream can stomp on the packet. 3) Dropping packets you don't own is a no-no. You simply return TC_ACT_SHOT to the caller and they will drop it. diff --git a/Documentation/networking/timestamping/txtimestamp.c b/Documentation/networking/timestamping/txtimestamp.c index 8217510d3842..5df07047ca86 100644 --- a/Documentation/networking/timestamping/txtimestamp.c +++ b/Documentation/networking/timestamping/txtimestamp.c @@ -36,6 +36,7 @@ #include <asm/types.h> #include <error.h> #include <errno.h> +#include <inttypes.h> #include <linux/errqueue.h> #include <linux/if_ether.h> #include <linux/net_tstamp.h> @@ -49,7 +50,6 @@ #include <poll.h> #include <stdarg.h> #include <stdbool.h> -#include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> @@ -96,7 +96,7 @@ static void __print_timestamp(const char *name, struct timespec *cur, prev_ms = (long) ts_prev.tv_sec * 1000 * 1000; prev_ms += ts_prev.tv_nsec / 1000; - fprintf(stderr, " (%+ld us)", cur_ms - prev_ms); + fprintf(stderr, " (%+" PRId64 " us)", cur_ms - prev_ms); } ts_prev = *cur; diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt index 0686c9e211c2..0dc078cab972 100644 --- a/Documentation/nfc/nfc-hci.txt +++ b/Documentation/nfc/nfc-hci.txt @@ -122,7 +122,7 @@ This must be done from a context that can sleep. PHY Management -------------- -The physical link (i2c, ...) management is defined by the following struture: +The physical link (i2c, ...) management is defined by the following structure: struct nfc_phy_ops { int (*write)(void *dev_id, struct sk_buff *skb); diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index a9b47163bb5d..4976389e432d 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -714,6 +714,7 @@ static struct pinmux_ops foo_pmxops = { .get_function_name = foo_get_fname, .get_function_groups = foo_get_groups, .set_mux = foo_set_mux, + .strict = true, }; /* Pinmux operations are handled by some pin controller */ @@ -830,6 +831,11 @@ separate memory range only intended for GPIO driving, and the register range dealing with pin config and pin multiplexing get placed into a different memory range and a separate section of the data sheet. +A flag "strict" in struct pinctrl_desc is available to check and deny +simultaneous access to the same pin from GPIO and pin multiplexing +consumers on hardware of this type. The pinctrl driver should set this flag +accordingly. + (B) pin config @@ -850,6 +856,11 @@ possible that the GPIO, pin config and pin multiplex registers are placed into the same memory range and the same section of the data sheet, although that need not be the case. +In some pin controllers, although the physical pins are designed in the same +way as (B), the GPIO function still can't be enabled at the same time as the +peripheral functions. So again the "strict" flag should be set, denying +simultaneous activation by GPIO and other muxed in devices. + From a kernel point of view, however, these are different aspects of the hardware and shall be put into different subsystems: diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 44fe1d28a163..e76dc0ad4d2b 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -556,6 +556,12 @@ helper functions described in Section 4. In that case, pm_runtime_resume() should be used. Of course, for this purpose the device's runtime PM has to be enabled earlier by calling pm_runtime_enable(). +Note, if the device may execute pm_runtime calls during the probe (such as +if it is registers with a subsystem that may call back in) then the +pm_runtime_get_sync() call paired with a pm_runtime_put() call will be +appropriate to ensure that the device is not put back to sleep during the +probe. This can happen with systems such as the network device layer. + It may be desirable to suspend the device once ->probe() has finished. Therefore the driver core uses the asyncronous pm_request_idle() to submit a request to execute the subsystem-level idle callback for the device at that diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 6fd0e8bb8140..9dc845cf7d88 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -30,3 +30,5 @@ ptrace.txt - Information on the ptrace interfaces for hardware debug registers. transactional_memory.txt - Overview of the Power8 transactional memory support. +dscr.txt + - Overview DSCR (Data Stream Control Register) support. diff --git a/Documentation/powerpc/cxl.txt b/Documentation/powerpc/cxl.txt index 2c71ecc519d9..2a230d01cd8c 100644 --- a/Documentation/powerpc/cxl.txt +++ b/Documentation/powerpc/cxl.txt @@ -133,6 +133,9 @@ User API The following file operations are supported on both slave and master devices. + A userspace library libcxl is avaliable here: + https://github.com/ibm-capi/libcxl + This provides a C interface to this kernel API. open ---- @@ -366,6 +369,7 @@ Sysfs Class enumeration and tuning of the accelerators. Its layout is described in Documentation/ABI/testing/sysfs-class-cxl + Udev rules ========== diff --git a/Documentation/powerpc/dscr.txt b/Documentation/powerpc/dscr.txt new file mode 100644 index 000000000000..1ff4400c57b3 --- /dev/null +++ b/Documentation/powerpc/dscr.txt @@ -0,0 +1,83 @@ + DSCR (Data Stream Control Register) + ================================================ + +DSCR register in powerpc allows user to have some control of prefetch of data +stream in the processor. Please refer to the ISA documents or related manual +for more detailed information regarding how to use this DSCR to attain this +control of the pefetches . This document here provides an overview of kernel +support for DSCR, related kernel objects, it's functionalities and exported +user interface. + +(A) Data Structures: + + (1) thread_struct: + dscr /* Thread DSCR value */ + dscr_inherit /* Thread has changed default DSCR */ + + (2) PACA: + dscr_default /* per-CPU DSCR default value */ + + (3) sysfs.c: + dscr_default /* System DSCR default value */ + +(B) Scheduler Changes: + + Scheduler will write the per-CPU DSCR default which is stored in the + CPU's PACA value into the register if the thread has dscr_inherit value + cleared which means that it has not changed the default DSCR till now. + If the dscr_inherit value is set which means that it has changed the + default DSCR value, scheduler will write the changed value which will + now be contained in thread struct's dscr into the register instead of + the per-CPU default PACA based DSCR value. + + NOTE: Please note here that the system wide global DSCR value never + gets used directly in the scheduler process context switch at all. + +(C) SYSFS Interface: + + Global DSCR default: /sys/devices/system/cpu/dscr_default + CPU specific DSCR default: /sys/devices/system/cpu/cpuN/dscr + + Changing the global DSCR default in the sysfs will change all the CPU + specific DSCR defaults immediately in their PACA structures. Again if + the current process has the dscr_inherit clear, it also writes the new + value into every CPU's DSCR register right away and updates the current + thread's DSCR value as well. + + Changing the CPU specif DSCR default value in the sysfs does exactly + the same thing as above but unlike the global one above, it just changes + stuff for that particular CPU instead for all the CPUs on the system. + +(D) User Space Instructions: + + The DSCR register can be accessed in the user space using any of these + two SPR numbers available for that purpose. + + (1) Problem state SPR: 0x03 (Un-privileged, POWER8 only) + (2) Privileged state SPR: 0x11 (Privileged) + + Accessing DSCR through privileged SPR number (0x11) from user space + works, as it is emulated following an illegal instruction exception + inside the kernel. Both mfspr and mtspr instructions are emulated. + + Accessing DSCR through user level SPR (0x03) from user space will first + create a facility unavailable exception. Inside this exception handler + all mfspr isntruction based read attempts will get emulated and returned + where as the first mtspr instruction based write attempts will enable + the DSCR facility for the next time around (both for read and write) by + setting DSCR facility in the FSCR register. + +(E) Specifics about 'dscr_inherit': + + The thread struct element 'dscr_inherit' represents whether the thread + in question has attempted and changed the DSCR itself using any of the + following methods. This element signifies whether the thread wants to + use the CPU default DSCR value or its own changed DSCR value in the + kernel. + + (1) mtspr instruction (SPR number 0x03) + (2) mtspr instruction (SPR number 0x11) + (3) ptrace interface (Explicitly set user DSCR value) + + Any child of the process created after this event in the process inherits + this same behaviour as well. diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt index ded69794a5c0..ba0a2a4a54ba 100644 --- a/Documentation/powerpc/transactional_memory.txt +++ b/Documentation/powerpc/transactional_memory.txt @@ -74,22 +74,23 @@ Causes of transaction aborts Syscalls ======== -Performing syscalls from within transaction is not recommended, and can lead -to unpredictable results. +Syscalls made from within an active transaction will not be performed and the +transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL +| TM_CAUSE_PERSISTENT. -Syscalls do not by design abort transactions, but beware: The kernel code will -not be running in transactional state. The effect of syscalls will always -remain visible, but depending on the call they may abort your transaction as a -side-effect, read soon-to-be-aborted transactional data that should not remain -invisible, etc. If you constantly retry a transaction that constantly aborts -itself by calling a syscall, you'll have a livelock & make no progress. +Syscalls made from within a suspended transaction are performed as normal and +the transaction is not explicitly doomed by the kernel. However, what the +kernel does to perform the syscall may result in the transaction being doomed +by the hardware. The syscall is performed in suspended mode so any side +effects will be persistent, independent of transaction success or failure. No +guarantees are provided by the kernel about which syscalls will affect +transaction success. -Simple syscalls (e.g. sigprocmask()) "could" be OK. Even things like write() -from, say, printf() should be OK as long as the kernel does not access any -memory that was accessed transactionally. - -Consider any syscalls that happen to work as debug-only -- not recommended for -production use. Best to queue them up till after the transaction is over. +Care must be taken when relying on syscalls to abort during active transactions +if the calls are made via a library. Libraries may cache values (which may +give the appearance of success) or perform operations that cause transaction +failure before entering the kernel (which may produce different failure codes). +Examples are glibc's getpid() and lazy symbol resolution. Signals @@ -176,8 +177,7 @@ kernel aborted a transaction: TM_CAUSE_RESCHED Thread was rescheduled. TM_CAUSE_TLBI Software TLB invalid. TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap. - TM_CAUSE_SYSCALL Currently unused; future syscalls that must abort - transactions for consistency will use this. + TM_CAUSE_SYSCALL Syscall from active transaction. TM_CAUSE_SIGNAL Signal delivered. TM_CAUSE_MISC Currently unused. TM_CAUSE_ALIGNMENT Alignment fault. diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt index c03b1be5eb15..c508cceeee7d 100644 --- a/Documentation/pps/pps.txt +++ b/Documentation/pps/pps.txt @@ -166,7 +166,7 @@ Testing the PPS support In order to test the PPS support even without specific hardware you can use the ktimer driver (see the client subsection in the PPS configuration menu) -and the userland tools provided into Documentaion/pps/ directory. +and the userland tools provided in the Documentation/pps/ directory. Once you have enabled the compilation of ktimer just modprobe it (if not statically compiled): diff --git a/Documentation/prctl/Makefile b/Documentation/prctl/Makefile index 2948b7b124b9..44de3080c7f2 100644 --- a/Documentation/prctl/Makefile +++ b/Documentation/prctl/Makefile @@ -1,3 +1,4 @@ +ifndef CROSS_COMPILE # List of programs to build hostprogs-$(CONFIG_X86) := disable-tsc-ctxt-sw-stress-test disable-tsc-on-off-stress-test disable-tsc-test # Tell kbuild to always build the programs @@ -6,3 +7,4 @@ always := $(hostprogs-y) HOSTCFLAGS_disable-tsc-ctxt-sw-stress-test.o += -I$(objtree)/usr/include HOSTCFLAGS_disable-tsc-on-off-stress-test.o += -I$(objtree)/usr/include HOSTCFLAGS_disable-tsc-test.o += -I$(objtree)/usr/include +endif diff --git a/Documentation/preempt-locking.txt b/Documentation/preempt-locking.txt index 57883ca2498b..e89ce6624af2 100644 --- a/Documentation/preempt-locking.txt +++ b/Documentation/preempt-locking.txt @@ -48,7 +48,7 @@ preemption must be disabled around such regions. Note, some FPU functions are already explicitly preempt safe. For example, kernel_fpu_begin and kernel_fpu_end will disable and enable preemption. -However, math_state_restore must be called with preemption disabled. +However, fpu__restore() must be called with preemption disabled. RULE #3: Lock acquire and release must be performed by same task diff --git a/Documentation/s390/qeth.txt b/Documentation/s390/qeth.txt index 74122ada9949..aa06fcf5f8c2 100644 --- a/Documentation/s390/qeth.txt +++ b/Documentation/s390/qeth.txt @@ -1,6 +1,6 @@ IBM s390 QDIO Ethernet Driver -HiperSockets Bridge Port Support +OSA and HiperSockets Bridge Port Support Uevents @@ -8,7 +8,7 @@ To generate the events the device must be assigned a role of either a primary or a secondary Bridge Port. For more information, see "z/VM Connectivity, SC24-6174". -When run on HiperSockets Bridge Capable Port hardware, and the state +When run on an OSA or HiperSockets Bridge Capable Port hardware, and the state of some configured Bridge Port device on the channel changes, a udev event with ACTION=CHANGE is emitted on behalf of the corresponding ccwgroup device. The event has the following attributes: diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index 21461a0441c1..e114513a2731 100644 --- a/Documentation/scheduler/sched-deadline.txt +++ b/Documentation/scheduler/sched-deadline.txt @@ -8,6 +8,10 @@ CONTENTS 1. Overview 2. Scheduling algorithm 3. Scheduling Real-Time Tasks + 3.1 Definitions + 3.2 Schedulability Analysis for Uniprocessor Systems + 3.3 Schedulability Analysis for Multiprocessor Systems + 3.4 Relationship with SCHED_DEADLINE Parameters 4. Bandwidth management 4.1 System-wide settings 4.2 Task interface @@ -43,7 +47,7 @@ CONTENTS "deadline", to schedule tasks. A SCHED_DEADLINE task should receive "runtime" microseconds of execution time every "period" microseconds, and these "runtime" microseconds are available within "deadline" microseconds - from the beginning of the period. In order to implement this behaviour, + from the beginning of the period. In order to implement this behavior, every time the task wakes up, the scheduler computes a "scheduling deadline" consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then scheduled using EDF[1] on these scheduling deadlines (the task with the @@ -52,7 +56,7 @@ CONTENTS "admission control" strategy (see Section "4. Bandwidth management") is used (clearly, if the system is overloaded this guarantee cannot be respected). - Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks so + Summing up, the CBS[2,3] algorithm assigns scheduling deadlines to tasks so that each task runs for at most its runtime every period, avoiding any interference between different tasks (bandwidth isolation), while the EDF[1] algorithm selects the task with the earliest scheduling deadline as the one @@ -63,7 +67,7 @@ CONTENTS In more details, the CBS algorithm assigns scheduling deadlines to tasks in the following way: - - Each SCHED_DEADLINE task is characterised by the "runtime", + - Each SCHED_DEADLINE task is characterized by the "runtime", "deadline", and "period" parameters; - The state of the task is described by a "scheduling deadline", and @@ -78,7 +82,7 @@ CONTENTS then, if the scheduling deadline is smaller than the current time, or this condition is verified, the scheduling deadline and the - remaining runtime are re-initialised as + remaining runtime are re-initialized as scheduling deadline = current time + deadline remaining runtime = runtime @@ -126,31 +130,37 @@ CONTENTS suited for periodic or sporadic real-time tasks that need guarantees on their timing behavior, e.g., multimedia, streaming, control applications, etc. +3.1 Definitions +------------------------ + A typical real-time task is composed of a repetition of computation phases (task instances, or jobs) which are activated on a periodic or sporadic fashion. - Each job J_j (where J_j is the j^th job of the task) is characterised by an + Each job J_j (where J_j is the j^th job of the task) is characterized by an arrival time r_j (the time when the job starts), an amount of computation time c_j needed to finish the job, and a job absolute deadline d_j, which is the time within which the job should be finished. The maximum execution - time max_j{c_j} is called "Worst Case Execution Time" (WCET) for the task. + time max{c_j} is called "Worst Case Execution Time" (WCET) for the task. A real-time task can be periodic with period P if r_{j+1} = r_j + P, or sporadic with minimum inter-arrival time P is r_{j+1} >= r_j + P. Finally, d_j = r_j + D, where D is the task's relative deadline. - The utilisation of a real-time task is defined as the ratio between its + Summing up, a real-time task can be described as + Task = (WCET, D, P) + + The utilization of a real-time task is defined as the ratio between its WCET and its period (or minimum inter-arrival time), and represents the fraction of CPU time needed to execute the task. - If the total utilisation sum_i(WCET_i/P_i) is larger than M (with M equal + If the total utilization U=sum(WCET_i/P_i) is larger than M (with M equal to the number of CPUs), then the scheduler is unable to respect all the deadlines. - Note that total utilisation is defined as the sum of the utilisations + Note that total utilization is defined as the sum of the utilizations WCET_i/P_i over all the real-time tasks in the system. When considering multiple real-time tasks, the parameters of the i-th task are indicated with the "_i" suffix. - Moreover, if the total utilisation is larger than M, then we risk starving + Moreover, if the total utilization is larger than M, then we risk starving non- real-time tasks by real-time tasks. - If, instead, the total utilisation is smaller than M, then non real-time + If, instead, the total utilization is smaller than M, then non real-time tasks will not be starved and the system might be able to respect all the deadlines. As a matter of fact, in this case it is possible to provide an upper bound @@ -159,38 +169,119 @@ CONTENTS More precisely, it can be proven that using a global EDF scheduler the maximum tardiness of each task is smaller or equal than ((M − 1) · WCET_max − WCET_min)/(M − (M − 2) · U_max) + WCET_max - where WCET_max = max_i{WCET_i} is the maximum WCET, WCET_min=min_i{WCET_i} - is the minimum WCET, and U_max = max_i{WCET_i/P_i} is the maximum utilisation. + where WCET_max = max{WCET_i} is the maximum WCET, WCET_min=min{WCET_i} + is the minimum WCET, and U_max = max{WCET_i/P_i} is the maximum + utilization[12]. + +3.2 Schedulability Analysis for Uniprocessor Systems +------------------------ If M=1 (uniprocessor system), or in case of partitioned scheduling (each real-time task is statically assigned to one and only one CPU), it is possible to formally check if all the deadlines are respected. If D_i = P_i for all tasks, then EDF is able to respect all the deadlines - of all the tasks executing on a CPU if and only if the total utilisation + of all the tasks executing on a CPU if and only if the total utilization of the tasks running on such a CPU is smaller or equal than 1. If D_i != P_i for some task, then it is possible to define the density of - a task as C_i/min{D_i,T_i}, and EDF is able to respect all the deadlines - of all the tasks running on a CPU if the sum sum_i C_i/min{D_i,T_i} of the - densities of the tasks running on such a CPU is smaller or equal than 1 - (notice that this condition is only sufficient, and not necessary). + a task as WCET_i/min{D_i,P_i}, and EDF is able to respect all the deadlines + of all the tasks running on a CPU if the sum of the densities of the tasks + running on such a CPU is smaller or equal than 1: + sum(WCET_i / min{D_i, P_i}) <= 1 + It is important to notice that this condition is only sufficient, and not + necessary: there are task sets that are schedulable, but do not respect the + condition. For example, consider the task set {Task_1,Task_2} composed by + Task_1=(50ms,50ms,100ms) and Task_2=(10ms,100ms,100ms). + EDF is clearly able to schedule the two tasks without missing any deadline + (Task_1 is scheduled as soon as it is released, and finishes just in time + to respect its deadline; Task_2 is scheduled immediately after Task_1, hence + its response time cannot be larger than 50ms + 10ms = 60ms) even if + 50 / min{50,100} + 10 / min{100, 100} = 50 / 50 + 10 / 100 = 1.1 + Of course it is possible to test the exact schedulability of tasks with + D_i != P_i (checking a condition that is both sufficient and necessary), + but this cannot be done by comparing the total utilization or density with + a constant. Instead, the so called "processor demand" approach can be used, + computing the total amount of CPU time h(t) needed by all the tasks to + respect all of their deadlines in a time interval of size t, and comparing + such a time with the interval size t. If h(t) is smaller than t (that is, + the amount of time needed by the tasks in a time interval of size t is + smaller than the size of the interval) for all the possible values of t, then + EDF is able to schedule the tasks respecting all of their deadlines. Since + performing this check for all possible values of t is impossible, it has been + proven[4,5,6] that it is sufficient to perform the test for values of t + between 0 and a maximum value L. The cited papers contain all of the + mathematical details and explain how to compute h(t) and L. + In any case, this kind of analysis is too complex as well as too + time-consuming to be performed on-line. Hence, as explained in Section + 4 Linux uses an admission test based on the tasks' utilizations. + +3.3 Schedulability Analysis for Multiprocessor Systems +------------------------ On multiprocessor systems with global EDF scheduling (non partitioned systems), a sufficient test for schedulability can not be based on the - utilisations (it can be shown that task sets with utilisations slightly - larger than 1 can miss deadlines regardless of the number of CPUs M). - However, as previously stated, enforcing that the total utilisation is smaller - than M is enough to guarantee that non real-time tasks are not starved and - that the tardiness of real-time tasks has an upper bound. + utilizations or densities: it can be shown that even if D_i = P_i task + sets with utilizations slightly larger than 1 can miss deadlines regardless + of the number of CPUs. + + Consider a set {Task_1,...Task_{M+1}} of M+1 tasks on a system with M + CPUs, with the first task Task_1=(P,P,P) having period, relative deadline + and WCET equal to P. The remaining M tasks Task_i=(e,P-1,P-1) have an + arbitrarily small worst case execution time (indicated as "e" here) and a + period smaller than the one of the first task. Hence, if all the tasks + activate at the same time t, global EDF schedules these M tasks first + (because their absolute deadlines are equal to t + P - 1, hence they are + smaller than the absolute deadline of Task_1, which is t + P). As a + result, Task_1 can be scheduled only at time t + e, and will finish at + time t + e + P, after its absolute deadline. The total utilization of the + task set is U = M · e / (P - 1) + P / P = M · e / (P - 1) + 1, and for small + values of e this can become very close to 1. This is known as "Dhall's + effect"[7]. Note: the example in the original paper by Dhall has been + slightly simplified here (for example, Dhall more correctly computed + lim_{e->0}U). + + More complex schedulability tests for global EDF have been developed in + real-time literature[8,9], but they are not based on a simple comparison + between total utilization (or density) and a fixed constant. If all tasks + have D_i = P_i, a sufficient schedulability condition can be expressed in + a simple way: + sum(WCET_i / P_i) <= M - (M - 1) · U_max + where U_max = max{WCET_i / P_i}[10]. Notice that for U_max = 1, + M - (M - 1) · U_max becomes M - M + 1 = 1 and this schedulability condition + just confirms the Dhall's effect. A more complete survey of the literature + about schedulability tests for multi-processor real-time scheduling can be + found in [11]. + + As seen, enforcing that the total utilization is smaller than M does not + guarantee that global EDF schedules the tasks without missing any deadline + (in other words, global EDF is not an optimal scheduling algorithm). However, + a total utilization smaller than M is enough to guarantee that non real-time + tasks are not starved and that the tardiness of real-time tasks has an upper + bound[12] (as previously noted). Different bounds on the maximum tardiness + experienced by real-time tasks have been developed in various papers[13,14], + but the theoretical result that is important for SCHED_DEADLINE is that if + the total utilization is smaller or equal than M then the response times of + the tasks are limited. + +3.4 Relationship with SCHED_DEADLINE Parameters +------------------------ - SCHED_DEADLINE can be used to schedule real-time tasks guaranteeing that - the jobs' deadlines of a task are respected. In order to do this, a task - must be scheduled by setting: + Finally, it is important to understand the relationship between the + SCHED_DEADLINE scheduling parameters described in Section 2 (runtime, + deadline and period) and the real-time task parameters (WCET, D, P) + described in this section. Note that the tasks' temporal constraints are + represented by its absolute deadlines d_j = r_j + D described above, while + SCHED_DEADLINE schedules the tasks according to scheduling deadlines (see + Section 2). + If an admission test is used to guarantee that the scheduling deadlines + are respected, then SCHED_DEADLINE can be used to schedule real-time tasks + guaranteeing that all the jobs' deadlines of a task are respected. + In order to do this, a task must be scheduled by setting: - runtime >= WCET - deadline = D - period <= P - IOW, if runtime >= WCET and if period is >= P, then the scheduling deadlines + IOW, if runtime >= WCET and if period is <= P, then the scheduling deadlines and the absolute deadlines (d_j) coincide, so a proper admission control allows to respect the jobs' absolute deadlines for this task (this is what is called "hard schedulability property" and is an extension of Lemma 1 of [2]). @@ -206,6 +297,39 @@ CONTENTS Symposium, 1998. http://retis.sssup.it/~giorgio/paps/1998/rtss98-cbs.pdf 3 - L. Abeni. Server Mechanisms for Multimedia Applications. ReTiS Lab Technical Report. http://disi.unitn.it/~abeni/tr-98-01.pdf + 4 - J. Y. Leung and M.L. Merril. A Note on Preemptive Scheduling of + Periodic, Real-Time Tasks. Information Processing Letters, vol. 11, + no. 3, pp. 115-118, 1980. + 5 - S. K. Baruah, A. K. Mok and L. E. Rosier. Preemptively Scheduling + Hard-Real-Time Sporadic Tasks on One Processor. Proceedings of the + 11th IEEE Real-time Systems Symposium, 1990. + 6 - S. K. Baruah, L. E. Rosier and R. R. Howell. Algorithms and Complexity + Concerning the Preemptive Scheduling of Periodic Real-Time tasks on + One Processor. Real-Time Systems Journal, vol. 4, no. 2, pp 301-324, + 1990. + 7 - S. J. Dhall and C. L. Liu. On a real-time scheduling problem. Operations + research, vol. 26, no. 1, pp 127-140, 1978. + 8 - T. Baker. Multiprocessor EDF and Deadline Monotonic Schedulability + Analysis. Proceedings of the 24th IEEE Real-Time Systems Symposium, 2003. + 9 - T. Baker. An Analysis of EDF Schedulability on a Multiprocessor. + IEEE Transactions on Parallel and Distributed Systems, vol. 16, no. 8, + pp 760-768, 2005. + 10 - J. Goossens, S. Funk and S. Baruah, Priority-Driven Scheduling of + Periodic Task Systems on Multiprocessors. Real-Time Systems Journal, + vol. 25, no. 2–3, pp. 187–205, 2003. + 11 - R. Davis and A. Burns. A Survey of Hard Real-Time Scheduling for + Multiprocessor Systems. ACM Computing Surveys, vol. 43, no. 4, 2011. + http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf + 12 - U. C. Devi and J. H. Anderson. Tardiness Bounds under Global EDF + Scheduling on a Multiprocessor. Real-Time Systems Journal, vol. 32, + no. 2, pp 133-189, 2008. + 13 - P. Valente and G. Lipari. An Upper Bound to the Lateness of Soft + Real-Time Tasks Scheduled by EDF on Multiprocessors. Proceedings of + the 26th IEEE Real-Time Systems Symposium, 2005. + 14 - J. Erickson, U. Devi and S. Baruah. Improved tardiness bounds for + Global EDF. Proceedings of the 22nd Euromicro Conference on + Real-Time Systems, 2010. + 4. Bandwidth management ======================= @@ -218,10 +342,10 @@ CONTENTS no guarantee can be given on the actual scheduling of the -deadline tasks. As already stated in Section 3, a necessary condition to be respected to - correctly schedule a set of real-time tasks is that the total utilisation + correctly schedule a set of real-time tasks is that the total utilization is smaller than M. When talking about -deadline tasks, this requires that the sum of the ratio between runtime and period for all tasks is smaller - than M. Notice that the ratio runtime/period is equivalent to the utilisation + than M. Notice that the ratio runtime/period is equivalent to the utilization of a "traditional" real-time task, and is also often referred to as "bandwidth". The interface used to control the CPU bandwidth that can be allocated @@ -251,7 +375,7 @@ CONTENTS The system wide settings are configured under the /proc virtual file system. For now the -rt knobs are used for -deadline admission control and the - -deadline runtime is accounted against the -rt runtime. We realise that this + -deadline runtime is accounted against the -rt runtime. We realize that this isn't entirely desirable; however, it is better to have a small interface for now, and be able to change it easily later. The ideal situation (see 5.) is to run -rt tasks from a -deadline server; in which case the -rt bandwidth is a diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index 731bc4f4c5e6..255075157511 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -1269,7 +1269,7 @@ Members of interest: request_buffer - either contains data buffer or scatter gather list depending on the setting of use_sg. Scatter gather elements are defined by 'struct scatterlist' found - in include/asm/scatterlist.h . + in include/linux/scatterlist.h . done - function pointer that should be invoked by LLD when the SCSI command is completed (successfully or otherwise). Should only be called by an LLD if the LLD has accepted diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt index 0d5bdb153d3b..f29fa550665a 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -151,6 +151,65 @@ A link named 'tape' is made from the SCSI device directory to the class directory corresponding to the mode 0 auto-rewind device (e.g., st0). +SYSFS AND STATISTICS FOR TAPE DEVICES + +The st driver maintains statistics for tape drives inside the sysfs filesystem. +The following method can be used to locate the statistics that are +available (assuming that sysfs is mounted at /sys): + +1. Use opendir(3) on the directory /sys/class/scsi_tape +2. Use readdir(3) to read the directory contents +3. Use regcomp(3)/regexec(3) to match directory entries to the extended + regular expression "^st[0-9]+$" +4. Access the statistics from the /sys/class/scsi_tape/<match>/stats + directory (where <match> is a directory entry from /sys/class/scsi_tape + that matched the extended regular expression) + +The reason for using this approach is that all the character devices +pointing to the same tape drive use the same statistics. That means +that st0 would have the same statistics as nst0. + +The directory contains the following statistics files: + +1. in_flight - The number of I/Os currently outstanding to this device. +2. io_ns - The amount of time spent waiting (in nanoseconds) for all I/O + to complete (including read and write). This includes tape movement + commands such as seeking between file or set marks and implicit tape + movement such as when rewind on close tape devices are used. +3. other_cnt - The number of I/Os issued to the tape drive other than read or + write commands. The time taken to complete these commands uses the + following calculation io_ms-read_ms-write_ms. +4. read_byte_cnt - The number of bytes read from the tape drive. +5. read_cnt - The number of read requests issued to the tape drive. +6. read_ns - The amount of time (in nanoseconds) spent waiting for read + requests to complete. +7. write_byte_cnt - The number of bytes written to the tape drive. +8. write_cnt - The number of write requests issued to the tape drive. +9. write_ns - The amount of time (in nanoseconds) spent waiting for write + requests to complete. +10. resid_cnt - The number of times during a read or write we found + the residual amount to be non-zero. This should mean that a program + is issuing a read larger thean the block size on tape. For write + not all data made it to tape. + +Note: The in_flight value is incremented when an I/O starts the I/O +itself is not added to the statistics until it completes. + +The total of read_cnt, write_cnt, and other_cnt may not total to the same +value as iodone_cnt at the device level. The tape statistics only count +I/O issued via the st module. + +When read the statistics may not be temporally consistent while I/O is in +progress. The individual values are read and written to atomically however +when reading them back via sysfs they may be in the process of being +updated when starting an I/O or when it is completed. + +The value shown in in_flight is incremented before any statstics are +updated and decremented when an I/O completes after updating statistics. +The value of in_flight is 0 when there are no I/Os outstanding that are +issued by the st driver. Tape statistics do not take into account any +I/O performed via the sg device. + BSD AND SYS V SEMANTICS The user can choose between these two behaviours of the tape driver by diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index 58d0ac4df946..3049a612291b 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -59,11 +59,20 @@ For all other submissions, choose one of the following procedures: changelog of your submission, as well as the kernel version you wish it to be applied to. -Option 1 is probably the easiest and most common. Options 2 and 3 are more -useful if the patch isn't deemed worthy at the time it is applied to a public -git tree (for instance, because it deserves more regression testing first). -Option 3 is especially useful if the patch needs some special handling to apply -to an older kernel (e.g., if API's have changed in the meantime). +Option 1 is *strongly* preferred, is the easiest and most common. Options 2 and +3 are more useful if the patch isn't deemed worthy at the time it is applied to +a public git tree (for instance, because it deserves more regression testing +first). Option 3 is especially useful if the patch needs some special handling +to apply to an older kernel (e.g., if API's have changed in the meantime). + +Note that for Option 3, if the patch deviates from the original upstream patch +(for example because it had to be backported) this must be very clearly +documented and justified in the patch description. + +The upstream commit ID must be specified with a separate line above the commit +text, like this: + + commit <sha1> upstream. Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index c831001c45f1..e5d528e0c46e 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -923,6 +923,27 @@ and nmi_watchdog. ============================================================== +watchdog_cpumask: + +This value can be used to control on which cpus the watchdog may run. +The default cpumask is all possible cores, but if NO_HZ_FULL is +enabled in the kernel config, and cores are specified with the +nohz_full= boot argument, those cores are excluded by default. +Offline cores can be included in this mask, and if the core is later +brought online, the watchdog will be started based on the mask value. + +Typically this value would only be touched in the nohz_full case +to re-enable cores that by default were not running the watchdog, +if a kernel lockup was suspected on those cores. + +The argument value is the standard cpulist format for cpumasks, +so for example to enable the watchdog on cores 0, 2, 3, and 4 you +might say: + + echo 0,2-4 > /proc/sys/kernel/watchdog_cpumask + +============================================================== + watchdog_thresh: This value can be used to control the frequency of hrtimer and NMI diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index 2ba71cea0172..6085e1f19c9d 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -503,11 +503,8 @@ def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += "#include <linux/string.h>\n" buf += "#include <linux/ctype.h>\n" buf += "#include <asm/unaligned.h>\n" - buf += "#include <scsi/scsi.h>\n" - buf += "#include <scsi/scsi_host.h>\n" - buf += "#include <scsi/scsi_device.h>\n" - buf += "#include <scsi/scsi_cmnd.h>\n" - buf += "#include <scsi/libfc.h>\n\n" + buf += "#include <scsi/scsi_common.h>\n" + buf += "#include <scsi/scsi_proto.h>\n" buf += "#include <target/target_core_base.h>\n" buf += "#include <target/target_core_fabric.h>\n" buf += "#include <target/target_core_configfs.h>\n\n" diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 572ca923631a..7ddb1e319f84 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -108,8 +108,8 @@ of ftrace. Here is a list of some of the key files: data is read from this file, it is consumed, and will not be read again with a sequential read. The "trace" file is static, and if the tracer is not - adding more data,they will display the same - information every time they are read. + adding more data, it will display the same + information every time it is read. trace_options: diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 947fa62bccf2..349f3104fa4f 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -465,12 +465,14 @@ Generic Serial driver device, and does not support any kind of device flow control. All that is required of your device is that it has at least one bulk in endpoint, or one bulk out endpoint. - - To enable the generic driver to recognize your device, build the driver - as a module and load it by the following invocation: + + To enable the generic driver to recognize your device, provide + echo <vid> <pid> >/sys/bus/usb-serial/drivers/generic/new_id + where the <vid> and <pid> is replaced with the hex representation of your + device's vendor id and product id. + If the driver is compiled as a module you can also provide one id when + loading the module insmod usbserial vendor=0x#### product=0x#### - where the #### is replaced with the hex representation of your device's - vendor id and product id. This driver has been successfully used to connect to the NetChip USB development board, providing a way to develop USB firmware without diff --git a/Documentation/vDSO/Makefile b/Documentation/vDSO/Makefile index ee075c3d2124..b12e98770e1f 100644 --- a/Documentation/vDSO/Makefile +++ b/Documentation/vDSO/Makefile @@ -1,3 +1,4 @@ +ifndef CROSS_COMPILE # vdso_test won't build for glibc < 2.16, so disable it # hostprogs-y := vdso_test hostprogs-$(CONFIG_X86) := vdso_standalone_test_x86 @@ -13,3 +14,4 @@ HOSTLOADLIBES_vdso_standalone_test_x86 := -nostdlib ifeq ($(CONFIG_X86_32),y) HOSTLOADLIBES_vdso_standalone_test_x86 += -lgcc_s endif +endif diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt index 96978eced341..1dd3fddfd3a1 100644 --- a/Documentation/vfio.txt +++ b/Documentation/vfio.txt @@ -289,10 +289,12 @@ PPC64 sPAPR implementation note This implementation has some specifics: -1) Only one IOMMU group per container is supported as an IOMMU group -represents the minimal entity which isolation can be guaranteed for and -groups are allocated statically, one per a Partitionable Endpoint (PE) +1) On older systems (POWER7 with P5IOC2/IODA1) only one IOMMU group per +container is supported as an IOMMU table is allocated at the boot time, +one table per a IOMMU group which is a Partitionable Endpoint (PE) (PE is often a PCI domain but not always). +Newer systems (POWER8 with IODA2) have improved hardware design which allows +to remove this limitation and have multiple IOMMU groups per a VFIO container. 2) The hardware supports so called DMA windows - the PCI address range within which DMA transfer is allowed, any attempt to access address space @@ -385,6 +387,18 @@ The code flow from the example above should be slightly changed: .... + /* Inject EEH error, which is expected to be caused by 32-bits + * config load. + */ + pe_op.op = VFIO_EEH_PE_INJECT_ERR; + pe_op.err.type = EEH_ERR_TYPE_32; + pe_op.err.func = EEH_ERR_FUNC_LD_CFG_ADDR; + pe_op.err.addr = 0ul; + pe_op.err.mask = 0ul; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + .... + /* When 0xFF's returned from reading PCI config space or IO BARs * of the PCI device. Check the PE's state to see if that has been * frozen. @@ -427,6 +441,48 @@ The code flow from the example above should be slightly changed: .... +5) There is v2 of SPAPR TCE IOMMU. It deprecates VFIO_IOMMU_ENABLE/ +VFIO_IOMMU_DISABLE and implements 2 new ioctls: +VFIO_IOMMU_SPAPR_REGISTER_MEMORY and VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY +(which are unsupported in v1 IOMMU). + +PPC64 paravirtualized guests generate a lot of map/unmap requests, +and the handling of those includes pinning/unpinning pages and updating +mm::locked_vm counter to make sure we do not exceed the rlimit. +The v2 IOMMU splits accounting and pinning into separate operations: + +- VFIO_IOMMU_SPAPR_REGISTER_MEMORY/VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY ioctls +receive a user space address and size of the block to be pinned. +Bisecting is not supported and VFIO_IOMMU_UNREGISTER_MEMORY is expected to +be called with the exact address and size used for registering +the memory block. The userspace is not expected to call these often. +The ranges are stored in a linked list in a VFIO container. + +- VFIO_IOMMU_MAP_DMA/VFIO_IOMMU_UNMAP_DMA ioctls only update the actual +IOMMU table and do not do pinning; instead these check that the userspace +address is from pre-registered range. + +This separation helps in optimizing DMA for guests. + +6) sPAPR specification allows guests to have an additional DMA window(s) on +a PCI bus with a variable page size. Two ioctls have been added to support +this: VFIO_IOMMU_SPAPR_TCE_CREATE and VFIO_IOMMU_SPAPR_TCE_REMOVE. +The platform has to support the functionality or error will be returned to +the userspace. The existing hardware supports up to 2 DMA windows, one is +2GB long, uses 4K pages and called "default 32bit window"; the other can +be as big as entire RAM, use different page size, it is optional - guests +create those in run-time if the guest driver supports 64bit DMA. + +VFIO_IOMMU_SPAPR_TCE_CREATE receives a page shift, a DMA window size and +a number of TCE table levels (if a TCE table is going to be big enough and +the kernel may not be able to allocate enough of physically contiguous memory). +It creates a new window in the available slot and returns the bus address where +the new window starts. Due to hardware limitation, the user space cannot choose +the location of DMA windows. + +VFIO_IOMMU_SPAPR_TCE_REMOVE receives the bus start address of the window +and removes it. + ------------------------------------------------------------------------------- [1] VFIO was originally an acronym for "Virtual Function I/O" in its diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 9fa2bf8c3f6f..a7926a90156f 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -254,6 +254,11 @@ since the last call to this ioctl. Bit 0 is the first page in the memory slot. Ensure the entire structure is cleared to avoid padding issues. +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies +the address space for which you want to return the dirty bitmap. +They must be less than the value that KVM_CHECK_EXTENSION returns for +the KVM_CAP_MULTI_ADDRESS_SPACE capability. + 4.9 KVM_SET_MEMORY_ALIAS @@ -820,11 +825,21 @@ struct kvm_vcpu_events { } nmi; __u32 sipi_vector; __u32 flags; + struct { + __u8 smm; + __u8 pending; + __u8 smm_inside_nmi; + __u8 latched_init; + } smi; }; -KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that -interrupt.shadow contains a valid state. Otherwise, this field is undefined. +Only two fields are defined in the flags field: + +- KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that + interrupt.shadow contains a valid state. +- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that + smi contains a valid state. 4.32 KVM_SET_VCPU_EVENTS @@ -841,17 +856,20 @@ vcpu. See KVM_GET_VCPU_EVENTS for the data structure. Fields that may be modified asynchronously by running VCPUs can be excluded -from the update. These fields are nmi.pending and sipi_vector. Keep the -corresponding bits in the flags field cleared to suppress overwriting the -current in-kernel state. The bits are: +from the update. These fields are nmi.pending, sipi_vector, smi.smm, +smi.pending. Keep the corresponding bits in the flags field cleared to +suppress overwriting the current in-kernel state. The bits are: KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector +KVM_VCPUEVENT_VALID_SMM - transfer the smi sub-struct. If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in the flags field to signal that interrupt.shadow contains a valid state and shall be written into the VCPU. +KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. + 4.33 KVM_GET_DEBUGREGS @@ -911,6 +929,13 @@ slot. When changing an existing slot, it may be moved in the guest physical memory space, or its flags may be modified. It may not be resized. Slots may not overlap in guest physical address space. +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot" +specifies the address space which is being modified. They must be +less than the value that KVM_CHECK_EXTENSION returns for the +KVM_CAP_MULTI_ADDRESS_SPACE capability. Slots in separate address spaces +are unrelated; the restriction on overlapping slots only applies within +each address space. + Memory for the region is taken starting at the address denoted by the field userspace_addr, which must point at user addressable memory for the entire memory slot size. Any object may back this memory, including @@ -959,7 +984,8 @@ documentation when it pops into existence). 4.37 KVM_ENABLE_CAP Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM -Architectures: ppc, s390 +Architectures: x86 (only KVM_CAP_ENABLE_CAP_VM), + mips (only KVM_CAP_ENABLE_CAP), ppc, s390 Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM) Parameters: struct kvm_enable_cap (in) Returns: 0 on success; -1 on error @@ -1268,7 +1294,7 @@ The flags bitmap is defined as: /* the host supports the ePAPR idle hcall #define KVM_PPC_PVINFO_FLAGS_EV_IDLE (1<<0) -4.48 KVM_ASSIGN_PCI_DEVICE +4.48 KVM_ASSIGN_PCI_DEVICE (deprecated) Capability: none Architectures: x86 @@ -1318,7 +1344,7 @@ Errors: have their standard meanings. -4.49 KVM_DEASSIGN_PCI_DEVICE +4.49 KVM_DEASSIGN_PCI_DEVICE (deprecated) Capability: none Architectures: x86 @@ -1337,7 +1363,7 @@ Errors: Other error conditions may be defined by individual device types or have their standard meanings. -4.50 KVM_ASSIGN_DEV_IRQ +4.50 KVM_ASSIGN_DEV_IRQ (deprecated) Capability: KVM_CAP_ASSIGN_DEV_IRQ Architectures: x86 @@ -1377,7 +1403,7 @@ Errors: have their standard meanings. -4.51 KVM_DEASSIGN_DEV_IRQ +4.51 KVM_DEASSIGN_DEV_IRQ (deprecated) Capability: KVM_CAP_ASSIGN_DEV_IRQ Architectures: x86 @@ -1451,7 +1477,7 @@ struct kvm_irq_routing_s390_adapter { }; -4.53 KVM_ASSIGN_SET_MSIX_NR +4.53 KVM_ASSIGN_SET_MSIX_NR (deprecated) Capability: none Architectures: x86 @@ -1473,7 +1499,7 @@ struct kvm_assigned_msix_nr { #define KVM_MAX_MSIX_PER_DEV 256 -4.54 KVM_ASSIGN_SET_MSIX_ENTRY +4.54 KVM_ASSIGN_SET_MSIX_ENTRY (deprecated) Capability: none Architectures: x86 @@ -1629,7 +1655,7 @@ should skip processing the bitmap and just invalidate everything. It must be set to the number of set bits in the bitmap. -4.61 KVM_ASSIGN_SET_INTX_MASK +4.61 KVM_ASSIGN_SET_INTX_MASK (deprecated) Capability: KVM_CAP_PCI_2_3 Architectures: x86 @@ -2978,6 +3004,16 @@ len must be a multiple of sizeof(struct kvm_s390_irq). It must be > 0 and it must not exceed (max_vcpus + 32) * sizeof(struct kvm_s390_irq), which is the maximum number of possibly pending cpu-local interrupts. +4.90 KVM_SMI + +Capability: KVM_CAP_X86_SMM +Architectures: x86 +Type: vcpu ioctl +Parameters: none +Returns: 0 on success, -1 on error + +Queues an SMI on the thread's vcpu. + 5. The kvm_run structure ------------------------ @@ -3013,7 +3049,12 @@ an interrupt can be injected now with KVM_INTERRUPT. The value of the current interrupt flag. Only valid if in-kernel local APIC is not used. - __u8 padding2[2]; + __u16 flags; + +More architecture-specific flags detailing state of the VCPU that may +affect the device's behavior. The only currently defined flag is +KVM_RUN_X86_SMM, which is valid on x86 machines and is set if the +VCPU is in system management mode. /* in (pre_kvm_run), out (post_kvm_run) */ __u64 cr8; diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index c59bd9bc41ef..3a4d681c3e98 100644 --- a/Documentation/virtual/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt @@ -173,6 +173,12 @@ Shadow pages contain the following information: Contains the value of cr4.smap && !cr0.wp for which the page is valid (pages for which this is true are different from other pages; see the treatment of cr0.wp=0 below). + role.smm: + Is 1 if the page is valid in system management mode. This field + determines which of the kvm_memslots array was used to build this + shadow page; it is also used to go back from a struct kvm_mmu_page + to a memslot, through the kvm_memslots_for_spte_role macro and + __gfn_to_memslot. gfn: Either the guest page table containing the translations shadowed by this page, or the base page frame for linear translations. See role.direct. diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index 3be0bfc4738d..32ee3a67dba2 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt @@ -467,7 +467,13 @@ mmap(MAP_LOCKED) SYSTEM CALL HANDLING In addition the mlock()/mlockall() system calls, an application can request that a region of memory be mlocked supplying the MAP_LOCKED flag to the mmap() -call. Furthermore, any mmap() call or brk() call that expands the heap by a +call. There is one important and subtle difference here, though. mmap() + mlock() +will fail if the range cannot be faulted in (e.g. because mm_populate fails) +and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. The mmaped +area will still have properties of the locked area - aka. pages will not get +swapped out - but major page faults to fault memory in might still happen. + +Furthermore, any mmap() call or brk() call that expands the heap by a task that has previously called mlockall() with the MCL_FUTURE flag will result in the newly mapped memory being mlocked. Before the unevictable/mlock changes, the kernel simply called make_pages_present() to allocate pages and diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 88b85899d309..7c1f9fad6674 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -1124,7 +1124,6 @@ The boot loader *must* fill out the following fields in bp, o hdr.code32_start o hdr.cmd_line_ptr - o hdr.cmdline_size o hdr.ramdisk_image (if applicable) o hdr.ramdisk_size (if applicable) diff --git a/Documentation/x86/entry_64.txt b/Documentation/x86/entry_64.txt index 9132b86176a3..33884d156125 100644 --- a/Documentation/x86/entry_64.txt +++ b/Documentation/x86/entry_64.txt @@ -18,10 +18,10 @@ Some of these entries are: - system_call: syscall instruction from 64-bit code. - - ia32_syscall: int 0x80 from 32-bit or 64-bit code; compat syscall + - entry_INT80_compat: int 0x80 from 32-bit or 64-bit code; compat syscall either way. - - ia32_syscall, ia32_sysenter: syscall and sysenter from 32-bit + - entry_INT80_compat, ia32_sysenter: syscall and sysenter from 32-bit code - interrupt: An array of entries. Every IDT vector that doesn't diff --git a/Documentation/x86/x86_64/kernel-stacks b/Documentation/x86/kernel-stacks index e3c8a49d1a2f..0f3a6c201943 100644 --- a/Documentation/x86/x86_64/kernel-stacks +++ b/Documentation/x86/kernel-stacks @@ -1,3 +1,6 @@ +Kernel stacks on x86-64 bit +--------------------------- + Most of the text from Keith Owens, hacked by AK x86_64 page size (PAGE_SIZE) is 4K. @@ -56,13 +59,6 @@ If that assumption is ever broken then the stacks will become corrupt. The currently assigned IST stacks are :- -* STACKFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). - - Used for interrupt 12 - Stack Fault Exception (#SS). - - This allows the CPU to recover from invalid stack segments. Rarely - happens. - * DOUBLEFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). Used for interrupt 8 - Double Fault Exception (#DF). @@ -99,3 +95,47 @@ The currently assigned IST stacks are :- assumptions about the previous state of the kernel stack. For more details see the Intel IA32 or AMD AMD64 architecture manuals. + + +Printing backtraces on x86 +-------------------------- + +The question about the '?' preceding function names in an x86 stacktrace +keeps popping up, here's an indepth explanation. It helps if the reader +stares at print_context_stack() and the whole machinery in and around +arch/x86/kernel/dumpstack.c. + +Adapted from Ingo's mail, Message-ID: <20150521101614.GA10889@gmail.com>: + +We always scan the full kernel stack for return addresses stored on +the kernel stack(s) [*], from stack top to stack bottom, and print out +anything that 'looks like' a kernel text address. + +If it fits into the frame pointer chain, we print it without a question +mark, knowing that it's part of the real backtrace. + +If the address does not fit into our expected frame pointer chain we +still print it, but we print a '?'. It can mean two things: + + - either the address is not part of the call chain: it's just stale + values on the kernel stack, from earlier function calls. This is + the common case. + + - or it is part of the call chain, but the frame pointer was not set + up properly within the function, so we don't recognize it. + +This way we will always print out the real call chain (plus a few more +entries), regardless of whether the frame pointer was set up correctly +or not - but in most cases we'll get the call chain right as well. The +entries printed are strictly in stack order, so you can deduce more +information from that as well. + +The most important property of this method is that we _never_ lose +information: we always strive to print _all_ addresses on the stack(s) +that look like kernel text addresses, so if debug information is wrong, +we still print out the real call chain as well - just with more question +marks than ideal. + +[*] For things like IRQ and IST stacks, we also scan those stacks, in + the right order, and try to cross from one stack into another + reconstructing the call chain. This works most of the time. diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt index cc071dc333c2..860bc3adc223 100644 --- a/Documentation/x86/mtrr.txt +++ b/Documentation/x86/mtrr.txt @@ -1,7 +1,19 @@ MTRR (Memory Type Range Register) control -3 Jun 1999 -Richard Gooch -<rgooch@atnf.csiro.au> + +Richard Gooch <rgooch@atnf.csiro.au> - 3 Jun 1999 +Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015 + +=============================================================================== +Phasing out MTRR use + +MTRR use is replaced on modern x86 hardware with PAT. Over time the only type +of effective MTRR that is expected to be supported will be for write-combining. +As MTRR use is phased out device drivers should use arch_phys_wc_add() to make +MTRR effective on non-PAT systems while a no-op on PAT enabled systems. + +For details refer to Documentation/x86/pat.txt. + +=============================================================================== On Intel P6 family processors (Pentium Pro, Pentium II and later) the Memory Type Range Registers (MTRRs) may be used to control diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt index cf08c9fff3cd..54944c71b819 100644 --- a/Documentation/x86/pat.txt +++ b/Documentation/x86/pat.txt @@ -12,7 +12,7 @@ virtual addresses. PAT allows for different types of memory attributes. The most commonly used ones that will be supported at this time are Write-back, Uncached, -Write-combined and Uncached Minus. +Write-combined, Write-through and Uncached Minus. PAT APIs @@ -34,16 +34,23 @@ ioremap | -- | UC- | UC- | | | | | ioremap_cache | -- | WB | WB | | | | | +ioremap_uc | -- | UC | UC | + | | | | ioremap_nocache | -- | UC- | UC- | | | | | ioremap_wc | -- | -- | WC | | | | | +ioremap_wt | -- | -- | WT | + | | | | set_memory_uc | UC- | -- | -- | set_memory_wb | | | | | | | | set_memory_wc | WC | -- | -- | set_memory_wb | | | | | | | | +set_memory_wt | WT | -- | -- | + set_memory_wb | | | | + | | | | pci sysfs resource | -- | -- | UC- | | | | | pci sysfs resource_wc | -- | -- | WC | @@ -102,7 +109,38 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc() as step 0 above and also track the usage of those pages and use set_memory_wb() before the page is freed to free pool. - +MTRR effects on PAT / non-PAT systems +------------------------------------- + +The following table provides the effects of using write-combining MTRRs when +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally +mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add() +is made, should already have been ioremapped with WC attributes or PAT entries, +this can be done by using ioremap_wc() / set_memory_wc(). Devices which +combine areas of IO memory desired to remain uncacheable with areas where +write-combining is desirable should consider use of ioremap_uc() followed by +set_memory_wc() to white-list effective write-combined areas. Such use is +nevertheless discouraged as the effective memory type is considered +implementation defined, yet this strategy can be used as last resort on devices +with size-constrained regions where otherwise MTRR write-combining would +otherwise not be effective. + +---------------------------------------------------------------------- +MTRR Non-PAT PAT Linux ioremap value Effective memory type +---------------------------------------------------------------------- + Non-PAT | PAT + PAT + |PCD + ||PWT + ||| +WC 000 WB _PAGE_CACHE_MODE_WB WC | WC +WC 001 WC _PAGE_CACHE_MODE_WC WC* | WC +WC 010 UC- _PAGE_CACHE_MODE_UC_MINUS WC* | UC +WC 011 UC _PAGE_CACHE_MODE_UC UC | UC +---------------------------------------------------------------------- + +(*) denotes implementation defined and is discouraged Notes: @@ -115,8 +153,8 @@ can be more restrictive, in case of any existing aliasing for that address. For example: If there is an existing uncached mapping, a new ioremap_wc can return uncached mapping in place of write-combine requested. -set_memory_[uc|wc] and set_memory_wb should be used in pairs, where driver will -first make a region uc or wc and switch it back to wb after use. +set_memory_[uc|wc|wt] and set_memory_wb should be used in pairs, where driver +will first make a region uc, wc or wt and switch it back to wb after use. Over time writes to /proc/mtrr will be deprecated in favor of using PAT based interfaces. Users writing to /proc/mtrr are suggested to use above interfaces. @@ -124,7 +162,7 @@ interfaces. Users writing to /proc/mtrr are suggested to use above interfaces. Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access types. -Drivers should use set_memory_[uc|wc] to set access type for RAM ranges. +Drivers should use set_memory_[uc|wc|wt] to set access type for RAM ranges. PAT debugging diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt index 5223479291a2..68ed3114c363 100644 --- a/Documentation/x86/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt @@ -31,6 +31,9 @@ Machine check (e.g. BIOS or hardware monitoring applications), conflicting with OS's error handling, and you cannot deactivate the agent, then this option will be a help. + mce=no_lmce + Do not opt-in to Local MCE delivery. Use legacy method + to broadcast MCEs. mce=bootlog Enable logging of machine checks left over from booting. Disabled by default on AMD because some BIOS leave bogus ones. diff --git a/Documentation/zh_CN/gpio.txt b/Documentation/zh_CN/gpio.txt index d5b8f01833f4..bce972521065 100644 --- a/Documentation/zh_CN/gpio.txt +++ b/Documentation/zh_CN/gpio.txt @@ -638,9 +638,6 @@ GPIO 控制器的路径类似 /sys/class/gpio/gpiochip42/ (对于从#42 GPIO int gpio_export_link(struct device *dev, const char *name, unsigned gpio) - /* 改变 sysfs 中的一个 GPIO 节点的极性 */ - int gpio_sysfs_set_active_low(unsigned gpio, int value); - 在一个内核驱动申请一个 GPIO 之后，它可以通过 gpio_export()使其在 sysfs 接口中可见。该驱动可以控制信号方向是否可修改。这有助于防止用户空间代码无意间 破坏重要的系统状态。 @@ -651,8 +648,3 @@ GPIO 控制器的路径类似 /sys/class/gpio/gpiochip42/ (对于从#42 GPIO 在 GPIO 被导出之后，gpio_export_link()允许在 sysfs 文件系统的任何地方 创建一个到这个 GPIO sysfs 节点的符号链接。这样驱动就可以通过一个描述性的 名字，在 sysfs 中他们所拥有的设备下提供一个(到这个 GPIO sysfs 节点的)接口。 - -驱动可以使用 gpio_sysfs_set_active_low() 来在用户空间隐藏电路板之间 -GPIO 线的极性差异。这个仅对 sysfs 接口起作用。极性的改变可以在 gpio_export() -前后进行,且之前使能的轮询操作(poll(2))支持(上升或下降沿)将会被重新配置来遵循 -这个设置。 diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index dfb72a5c63e9..e9db693c0a23 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -116,7 +116,6 @@ COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9] -SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h RED_MAGIC1 0x5a2cf071 (any) mm/slab.c @@ -138,7 +137,6 @@ KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h -SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c |