diff --git a/.gitignore b/.gitignore index d5f4804ed07c..162bd2b67bdf 100644 --- a/.gitignore +++ b/.gitignore @@ -44,6 +44,7 @@ *.tab.[ch] *.tar *.xz +*.zst Module.symvers modules.builtin modules.order diff --git a/.mailmap b/.mailmap index db4f2295bd9d..a96f1b38fa58 100644 --- a/.mailmap +++ b/.mailmap @@ -18,6 +18,9 @@ Aleksey Gorelov Aleksandar Markovic Alex Shi Alex Shi +Alexander Lobakin +Alexander Lobakin +Alexander Lobakin Alexandre Belloni Alexei Starovoitov Alexei Starovoitov @@ -134,6 +137,11 @@ Jeff Layton Jeff Layton Jens Axboe Jens Osterkamp +Jiri Slaby +Jiri Slaby +Jiri Slaby +Jiri Slaby +Jiri Slaby Johan Hovold Johan Hovold John Paul Adrian Glaubitz @@ -151,6 +159,7 @@ Kamil Konieczny Kay Sievers Kenneth W Chen Konstantin Khlebnikov +Konstantin Khlebnikov Koushik Krzysztof Kozlowski Krzysztof Kozlowski diff --git a/CREDITS b/CREDITS index 0787b5872906..32ee70a7562e 100644 --- a/CREDITS +++ b/CREDITS @@ -34,7 +34,7 @@ S: Romania N: Mark Adler E: madler@alumni.caltech.edu -W: http://alumnus.caltech.edu/~madler/ +W: https://alumnus.caltech.edu/~madler/ D: zlib decompression N: Monalisa Agrawal @@ -62,7 +62,7 @@ S: United Kingdom N: Werner Almesberger E: werner@almesberger.net -W: http://www.almesberger.net/ +W: https://www.almesberger.net/ D: dosfs, LILO, some fd features, ATM, various other hacks here and there S: Buenos Aires S: Argentina @@ -96,7 +96,7 @@ S: USA N: Erik Andersen E: andersen@codepoet.org -W: http://www.codepoet.org/ +W: https://www.codepoet.org/ P: 1024D/30D39057 1BC4 2742 E885 E4DE 9301 0C82 5F9B 643E 30D3 9057 D: Maintainer of ide-cd and Uniform CD-ROM driver, D: ATAPI CD-Changer support, Major 2.1.x CD-ROM update. @@ -114,7 +114,7 @@ S: Canada K2P 0X3 N: H. Peter Anvin E: hpa@zytor.com -W: http://www.zytor.com/~hpa/ +W: https://www.zytor.com/~hpa/ P: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74 D: Author of the SYSLINUX boot loader, maintainer of the linux.* news D: hierarchy and the Linux Device List; various kernel hacks @@ -124,7 +124,7 @@ S: USA N: Andrea Arcangeli E: andrea@suse.de -W: http://www.kernel.org/pub/linux/kernel/people/andrea/ +W: https://www.kernel.org/pub/linux/kernel/people/andrea/ P: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 P: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 D: Parport hacker @@ -339,7 +339,7 @@ S: Haifa, Israel N: Johannes Berg E: johannes@sipsolutions.net -W: http://johannes.sipsolutions.net/ +W: https://johannes.sipsolutions.net/ P: 4096R/7BF9099A C0EB C440 F6DA 091C 884D 8532 E0F3 73F3 7BF9 099A D: powerpc & 802.11 hacker @@ -376,7 +376,7 @@ D: Original author of the Linux networking code N: Anton Blanchard E: anton@samba.org -W: http://samba.org/~anton/ +W: https://samba.org/~anton/ P: 1024/8462A731 4C 55 86 34 44 59 A7 99 2B 97 88 4A 88 9A 0D 97 D: sun4 port, Sparc hacker @@ -509,7 +509,7 @@ S: Sweden N: Paul Bristow E: paul@paulbristow.net -W: http://paulbristow.net/linux/idefloppy.html +W: https://paulbristow.net/linux/idefloppy.html D: Maintainer of IDE/ATAPI floppy driver N: Stefano Brivio @@ -518,7 +518,7 @@ D: Broadcom B43 driver N: Dominik Brodowski E: linux@brodo.de -W: http://www.brodo.de/ +W: https://www.brodo.de/ P: 1024D/725B37C6 190F 3E77 9C89 3B6D BECD 46EE 67C3 0308 725B 37C6 D: parts of CPUFreq code, ACPI bugfixes, PCMCIA rewrite, cpufrequtils S: Tuebingen, Germany @@ -865,7 +865,7 @@ D: Promise DC4030VL caching HD controller drivers N: Todd J. Derr E: tjd@fore.com -W: http://www.wordsmith.org/~tjd +W: https://www.wordsmith.org/~tjd D: Random console hacks and other miscellaneous stuff S: 3000 FORE Drive S: Warrendale, Pennsylvania 15086 @@ -894,8 +894,8 @@ S: USA N: Matt Domsch E: Matt_Domsch@dell.com -W: http://www.dell.com/linux -W: http://domsch.com/linux +W: https://www.dell.com/linux +W: https://domsch.com/linux D: Linux/IA-64 D: Dell PowerEdge server, SCSI layer, misc drivers, and other patches S: Dell Inc. @@ -992,7 +992,7 @@ S: USA N: Randy Dunlap E: rdunlap@infradead.org -W: http://www.infradead.org/~rdunlap/ +W: https://www.infradead.org/~rdunlap/ D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers D: x86 SMP, ACPI, bootflag hacking D: documentation, builds @@ -1157,7 +1157,7 @@ S: Germany N: Jeremy Fitzhardinge E: jeremy@goop.org -W: http://www.goop.org/~jeremy +W: https://www.goop.org/~jeremy D: author of userfs filesystem D: Improved mmap and munmap handling D: General mm minor tidyups @@ -1460,7 +1460,7 @@ S: The Netherlands N: Oliver Hartkopp E: oliver.hartkopp@volkswagen.de -W: http://www.volkswagen.de +W: https://www.volkswagen.de D: Controller Area Network (network layer core) S: Brieffach 1776 S: 38436 Wolfsburg @@ -1599,13 +1599,13 @@ S: Germany N: Kenji Hollis E: kenji@bitgate.com -W: http://www.bitgate.com/ +W: https://www.bitgate.com/ D: Berkshire PC Watchdog Driver D: Small/Industrial Driver Project N: Nick Holloway E: Nick.Holloway@pyrites.org.uk -W: http://www.pyrites.org.uk/ +W: https://www.pyrites.org.uk/ P: 1024/36115A04 F4E1 3384 FCFD C055 15D6 BA4C AB03 FBF8 3611 5A04 D: Occasional Linux hacker... S: (ask for current address) @@ -1655,7 +1655,7 @@ S: USA N: Harald Hoyer E: harald@redhat.com -W: http://www.harald-hoyer.de +W: https://www.harald-hoyer.de D: ip_masq_quake D: md boot support S: Am Strand 5 @@ -1856,7 +1856,7 @@ E: kas@fi.muni.cz D: Author of the COSA/SRP sync serial board driver. D: Port of the syncppp.c from the 2.0 to the 2.1 kernel. P: 1024/D3498839 0D 99 A7 FB 20 66 05 D7 8B 35 FC DE 05 B1 8A 5E -W: http://www.fi.muni.cz/~kas/ +W: https://www.fi.muni.cz/~kas/ S: c/o Faculty of Informatics, Masaryk University S: Botanicka' 68a S: 602 00 Brno @@ -2017,7 +2017,7 @@ S: Prague, Czech Republic N: Gene Kozin E: 74604.152@compuserve.com -W: http://www.sangoma.com +W: https://www.sangoma.com D: WAN Router & Sangoma WAN drivers S: Sangoma Technologies Inc. S: 7170 Warden Avenue, Unit 2 @@ -2112,7 +2112,7 @@ D: Original author of software suspend N: Jaroslav Kysela E: perex@perex.cz -W: http://www.perex.cz +W: https://www.perex.cz D: Original Author and Maintainer for HP 10/100 Mbit Network Adapters D: ISA PnP S: Sindlovy Dvory 117 @@ -2316,7 +2316,7 @@ S: Finland N: Daniel J. Maas E: dmaas@dcine.com -W: http://www.maasdigital.com +W: https://www.maasdigital.com D: dv1394 N: Hamish Macdonald @@ -2647,7 +2647,7 @@ D: bug fixes, documentation, minor hackery N: Paul Moore E: paul@paul-moore.com -W: http://www.paul-moore.com +W: https://www.paul-moore.com D: NetLabel, SELinux, audit N: James Morris @@ -2786,7 +2786,7 @@ N: David C. Niemi E: niemi@tux.org W: http://www.tux.org/~niemi/ D: Assistant maintainer of Mtools, fdutils, and floppy driver -D: Administrator of Tux.Org Linux Server, http://www.tux.org +D: Administrator of Tux.Org Linux Server, https://www.tux.org S: 2364 Old Trail Drive S: Reston, Virginia 20191 S: USA @@ -2850,7 +2850,7 @@ S: USA N: Mikulas Patocka E: mikulas@artax.karlin.mff.cuni.cz -W: http://artax.karlin.mff.cuni.cz/~mikulas/ +W: https://artax.karlin.mff.cuni.cz/~mikulas/ P: 1024/BB11D2D5 A0 F1 28 4A C4 14 1E CF 92 58 7A 8F 69 BC A4 D3 D: Read/write HPFS filesystem S: Weissova 8 @@ -2872,7 +2872,7 @@ D: RFC2385 Support for TCP N: Barak A. Pearlmutter E: bap@cs.unm.edu -W: http://www.cs.unm.edu/~bap/ +W: https://www.cs.unm.edu/~bap/ P: 512/602D785D 9B A1 83 CD EE CB AD 93 20 C6 4C B7 F5 E9 60 D4 D: Author of mark-and-sweep GC integrated by Alan Cox S: Computer Science Department @@ -3035,7 +3035,7 @@ S: United Kingdom N: Daniel Quinlan E: quinlan@pathname.com -W: http://www.pathname.com/~quinlan/ +W: https://www.pathname.com/~quinlan/ D: FSSTND coordinator; FHS editor D: random Linux documentation, patches, and hacks S: 4390 Albany Drive #41A @@ -3130,7 +3130,7 @@ S: France N: Rik van Riel E: riel@redhat.com -W: http://www.surriel.com/ +W: https://www.surriel.com/ D: Linux-MM site, Documentation/admin-guide/sysctl/*, swap/mm readaround D: kswapd fixes, random kernel hacker, rmap VM, D: nl.linux.org administrator, minor scheduler additions @@ -3246,7 +3246,7 @@ S: Germany N: Paul `Rusty' Russell E: rusty@rustcorp.com.au -W: http://ozlabs.org/~rusty +W: https://ozlabs.org/~rusty D: Ruggedly handsome. D: netfilter, ipchains with Michael Neuling. S: 52 Moore St @@ -3369,7 +3369,7 @@ S: Germany N: Robert Schwebel E: robert@schwebel.de -W: http://www.schwebel.de +W: https://www.schwebel.de D: Embedded hacker and book author, D: AMD Elan support for Linux S: Pengutronix @@ -3545,7 +3545,7 @@ S: Australia N: Henrik Storner E: storner@image.dk W: http://www.image.dk/~storner/ -W: http://www.sslug.dk/ +W: https://www.sslug.dk/ D: Configure script: Invented tristate for module-configuration D: vfat/msdos integration, kerneld docs, Linux promotion D: Miscellaneous bug-fixes @@ -3579,7 +3579,7 @@ S: USA N: Eugene Surovegin E: ebs@ebshome.net -W: http://kernel.ebshome.net/ +W: https://kernel.ebshome.net/ P: 1024D/AE5467F1 FF22 39F1 6728 89F6 6E6C 2365 7602 F33D AE54 67F1 D: Embedded PowerPC 4xx: EMAC, I2C, PIC and random hacks/fixes S: Sunnyvale, California 94085 @@ -3609,7 +3609,7 @@ S: France N: Urs Thuermann E: urs.thuermann@volkswagen.de -W: http://www.volkswagen.de +W: https://www.volkswagen.de D: Controller Area Network (network layer core) S: Brieffach 1776 S: 38436 Wolfsburg @@ -3656,7 +3656,7 @@ S: Canada K2L 1S2 N: Andrew Tridgell E: tridge@samba.org -W: http://samba.org/tridge/ +W: https://samba.org/tridge/ D: dosemu, networking, samba S: 3 Ballow Crescent S: MacGregor A.C.T 2615 @@ -3894,7 +3894,7 @@ D: The Linux Support Team Erlangen N: David Weinehall E: tao@acc.umu.se P: 1024D/DC47CA16 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16 -W: http://www.acc.umu.se/~tao/ +W: https://www.acc.umu.se/~tao/ D: v2.0 kernel maintainer D: Fixes for the NE/2-driver D: Miscellaneous MCA-support @@ -3919,7 +3919,7 @@ S: USA N: Harald Welte E: laforge@netfilter.org P: 1024D/30F48BFF DBDE 6912 8831 9A53 879B 9190 5DA5 C655 30F4 8BFF -W: http://gnumonks.org/users/laforge +W: https://gnumonks.org/users/laforge D: netfilter: new nat helper infrastructure D: netfilter: ULOG, ECN, DSCP target D: netfilter: TTL match diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io b/Documentation/ABI/stable/sysfs-driver-mlxreg-io index b0d90cc696a8..fd9a8045bb0c 100644 --- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io +++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io @@ -206,3 +206,20 @@ Description: This file exposes the firmware version of burnable voltage regulator devices. The file is read only. + +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_pn +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min +What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min +Date: July 2020 +KernelVersion: 5.9 +Contact: Vadim Pasternak +Description: These files show with which CPLD part numbers and minor + versions have been burned CPLD devices equipped on a + system. + + The files are read only. diff --git a/Documentation/ABI/testing/debugfs-turris-mox-rwtm b/Documentation/ABI/testing/debugfs-turris-mox-rwtm new file mode 100644 index 000000000000..2b3255ee68fd --- /dev/null +++ b/Documentation/ABI/testing/debugfs-turris-mox-rwtm @@ -0,0 +1,9 @@ +What: /sys/kernel/debug/turris-mox-rwtm/do_sign +Date: Jun 2020 +KernelVersion: 5.8 +Contact: Marek Behún +Description: (W) Message to sign with the ECDSA private key stored in + device's OTP. The message must be exactly 64 bytes (since + this is intended for SHA-512 hashes). + (R) The resulting signature, 136 bytes. This contains the R and + S values of the ECDSA signature, both in big-endian format. diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index f307506eb54c..3c0bb76e3417 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg @@ -56,6 +56,17 @@ Description: The /dev/kmsg character device node provides userspace access seek after the last record available at the time the last SYSLOG_ACTION_CLEAR was issued. + Other seek operations or offsets are not supported because of + the special behavior this device has. The device allows to read + or write only whole variable length messages (records) that are + stored in a ring buffer. + + Because of the non-standard behavior also the error values are + non-standard. -ESPIPE is returned for non-zero offset. -EINVAL + is returned for other operations, e.g. SEEK_CUR. This behavior + and values are historical and could not be modified without the + risk of breaking userspace. + The output format consists of a prefix carrying the syslog prefix including priority and facility, the 64 bit message sequence number and the monotonic timestamp in microseconds, diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index ed8c14f161ee..2322eb748b38 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -273,6 +273,24 @@ Description: device ("host-aware" or "host-managed" zone model). For regular block devices, the value is always 0. +What: /sys/block//queue/max_active_zones +Date: July 2020 +Contact: Niklas Cassel +Description: + For zoned block devices (zoned attribute indicating + "host-managed" or "host-aware"), the sum of zones belonging to + any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED, + is limited by this value. If this value is 0, there is no limit. + +What: /sys/block//queue/max_open_zones +Date: July 2020 +Contact: Niklas Cassel +Description: + For zoned block devices (zoned attribute indicating + "host-managed" or "host-aware"), the sum of zones belonging to + any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN, + is limited by this value. If this value is 0, there is no limit. + What: /sys/block//queue/chunk_sectors Date: September 2016 Contact: Hannes Reinecke diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices b/Documentation/ABI/testing/sysfs-bus-optee-devices new file mode 100644 index 000000000000..0f58701367b6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-optee-devices @@ -0,0 +1,8 @@ +What: /sys/bus/tee/devices/optee-ta-/ +Date: May 2020 +KernelVersion 5.8 +Contact: op-tee@lists.trustedfirmware.org +Description: + OP-TEE bus provides reference to registered drivers under this directory. The + matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers + are free to create needed API under optee-ta- directory. diff --git a/Documentation/ABI/testing/sysfs-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform index 5172a6124b27..194ca700e962 100644 --- a/Documentation/ABI/testing/sysfs-bus-platform +++ b/Documentation/ABI/testing/sysfs-bus-platform @@ -18,3 +18,13 @@ Description: devices to opt-out of driver binding using a driver_override name such as "none". Only a single driver may be specified in the override, there is no support for parsing delimiters. + +What: /sys/bus/platform/devices/.../numa_node +Date: June 2020 +Contact: Barry Song +Description: + This file contains the NUMA node to which the platform device + is attached. It won't be visible if the node is unknown. The + value comes from an ACPI _PXM method or a similar firmware + source. Initial users for this file would be devices like + arm smmu which are populated by arm64 acpi_iort. diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 82e80de78dd0..dd565c378b40 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -178,11 +178,18 @@ KernelVersion: 4.13 Contact: thunderbolt-software@lists.01.org Description: When new NVM image is written to the non-active NVM area (through non_activeX NVMem device), the - authentication procedure is started by writing 1 to - this file. If everything goes well, the device is + authentication procedure is started by writing to + this file. + If everything goes well, the device is restarted with the new NVM firmware. If the image verification fails an error code is returned instead. + This file will accept writing values "1" or "2" + - Writing "1" will flush the image to the storage + area and authenticate the image in one action. + - Writing "2" will run some basic validation on the image + and flush it to the storage area. + When read holds status of the last authentication operation if an error occurred during the process. This is directly the status value from the DMA configuration @@ -236,3 +243,49 @@ KernelVersion: 4.15 Contact: thunderbolt-software@lists.01.org Description: This contains XDomain service specific settings as bitmask. Format: %x + +What: /sys/bus/thunderbolt/devices/:./device +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg +Description: Retimer device identifier read from the hardware. + +What: /sys/bus/thunderbolt/devices/:./nvm_authenticate +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg +Description: When new NVM image is written to the non-active NVM + area (through non_activeX NVMem device), the + authentication procedure is started by writing 1 to + this file. If everything goes well, the device is + restarted with the new NVM firmware. If the image + verification fails an error code is returned instead. + + When read holds status of the last authentication + operation if an error occurred during the process. + Format: %x. + +What: /sys/bus/thunderbolt/devices/:./nvm_version +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg +Description: Holds retimer NVM version number. Format: %x.%x, major.minor. + +What: /sys/bus/thunderbolt/devices/:./vendor +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg +Description: Retimer vendor identifier read from the hardware. + +What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mario Limonciello +Description: For supported devices, automatically authenticate the new Thunderbolt + image when the device is disconnected from the host system. + + This file will accept writing values "1" or "2" + - Writing "1" will flush the image to the storage + area and prepare the device for authentication on disconnect. + - Writing "2" will run some basic validation on the image + and flush it to the storage area. diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq index 9758eb85ade3..deefffb3bbe4 100644 --- a/Documentation/ABI/testing/sysfs-class-devfreq +++ b/Documentation/ABI/testing/sysfs-class-devfreq @@ -108,3 +108,15 @@ Description: frequency requested by governors and min_freq. The max_freq overrides min_freq because max_freq may be used to throttle devices to avoid overheating. + +What: /sys/class/devfreq/.../timer +Date: July 2020 +Contact: Chanwoo Choi +Description: + This ABI shows and stores the kind of work timer by users. + This work timer is used by devfreq workqueue in order to + monitor the device status such as utilization. The user + can change the work timer on runtime according to their demand + as following: + echo deferrable > /sys/class/devfreq/.../timer + echo delayed > /sys/class/devfreq/.../timer diff --git a/Documentation/ABI/testing/sysfs-class-devlink b/Documentation/ABI/testing/sysfs-class-devlink new file mode 100644 index 000000000000..64791b65c9a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-devlink @@ -0,0 +1,126 @@ +What: /sys/class/devlink/.../ +Date: May 2020 +Contact: Saravana Kannan +Description: + Provide a place in sysfs for the device link objects in the + kernel at any given time. The name of a device link directory, + denoted as ... above, is of the form -- + where is the supplier device name and is + the consumer device name. + +What: /sys/class/devlink/.../auto_remove_on +Date: May 2020 +Contact: Saravana Kannan +Description: + This file indicates if the device link will ever be + automatically removed by the driver core when the consumer and + supplier devices themselves are still present. + + This will be one of the following strings: + + 'consumer unbind' + 'supplier unbind' + 'never' + + 'consumer unbind' means the device link will be removed when + the consumer's driver is unbound from the consumer device. + + 'supplier unbind' means the device link will be removed when + the supplier's driver is unbound from the supplier device. + + 'never' means the device link will not be automatically removed + when as long as the supplier and consumer devices themselves + are still present. + +What: /sys/class/devlink/.../consumer +Date: May 2020 +Contact: Saravana Kannan +Description: + This file is a symlink to the consumer device's sysfs directory. + +What: /sys/class/devlink/.../runtime_pm +Date: May 2020 +Contact: Saravana Kannan +Description: + This file indicates if the device link has any impact on the + runtime power management behavior of the consumer and supplier + devices. For example: Making sure the supplier doesn't enter + runtime suspend while the consumer is active. + + This will be one of the following strings: + + '0' - Does not affect runtime power management + '1' - Affects runtime power management + +What: /sys/class/devlink/.../status +Date: May 2020 +Contact: Saravana Kannan +Description: + This file indicates the status of the device link. The status + of a device link is affected by whether the supplier and + consumer devices have been bound to their corresponding + drivers. The status of a device link also affects the binding + and unbinding of the supplier and consumer devices with their + drivers and also affects whether the software state of the + supplier device is synced with the hardware state of the + supplier device after boot up. + See also: sysfs-devices-state_synced. + + This will be one of the following strings: + + 'not tracked' + 'dormant' + 'available' + 'consumer probing' + 'active' + 'supplier unbinding' + 'unknown' + + 'not tracked' means this device link does not track the status + and has no impact on the binding, unbinding and syncing the + hardware and software device state. + + 'dormant' means the supplier and the consumer devices have not + bound to their driver. + + 'available' means the supplier has bound to its driver and is + available to supply resources to the consumer device. + + 'consumer probing' means the consumer device is currently + trying to bind to its driver. + + 'active' means the supplier and consumer devices have both + bound successfully to their drivers. + + 'supplier unbinding' means the supplier devices is currently in + the process of unbinding from its driver. + + 'unknown' means the state of the device link is not any of the + above. If this is ever the value, there's a bug in the kernel. + +What: /sys/class/devlink/.../supplier +Date: May 2020 +Contact: Saravana Kannan +Description: + This file is a symlink to the supplier device's sysfs directory. + +What: /sys/class/devlink/.../sync_state_only +Date: May 2020 +Contact: Saravana Kannan +Description: + This file indicates if the device link is limited to only + affecting the syncing of the hardware and software state of the + supplier device. + + This will be one of the following strings: + + '0' + '1' - Affects runtime power management + + '0' means the device link can affect other device behaviors + like binding/unbinding, suspend/resume, runtime power + management, etc. + + '1' means the device link will only affect the syncing of + hardware and software state of the supplier device after boot + up and doesn't not affect other behaviors of the devices. diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia new file mode 100644 index 000000000000..795a5de12fc1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia @@ -0,0 +1,14 @@ +What: /sys/class/leds//device/brightness +Date: July 2020 +KernelVersion: 5.9 +Contact: Marek Behún +Description: (RW) On the front panel of the Turris Omnia router there is also + a button which can be used to control the intensity of all the + LEDs at once, so that if they are too bright, user can dim them. + + The microcontroller cycles between 8 levels of this global + brightness (from 100% to 0%), but this setting can have any + integer value between 0 and 100. It is therefore convenient to be + able to change this setting from software. + + Format: %i diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor new file mode 100644 index 000000000000..eeeddcbdbbe3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-multicolor @@ -0,0 +1,35 @@ +What: /sys/class/leds//brightness +Date: March 2020 +KernelVersion: 5.9 +Contact: Dan Murphy +Description: read/write + Writing to this file will update all LEDs within the group to a + calculated percentage of what each color LED intensity is set + to. The percentage is calculated for each grouped LED via the + equation below: + + led_brightness = brightness * multi_intensity/max_brightness + + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. + + The value of the LED is from 0 to + /sys/class/leds//max_brightness. + +What: /sys/class/leds//multi_index +Date: March 2020 +KernelVersion: 5.9 +Contact: Dan Murphy +Description: read + The multi_index array, when read, will output the LED colors + as an array of strings as they are indexed in the + multi_intensity file. + +What: /sys/class/leds//multi_intensity +Date: March 2020 +KernelVersion: 5.9 +Contact: Dan Murphy +Description: read/write + This file contains array of integers. Order of components is + described by the multi_index array. The maximum intensity should + not exceed /sys/class/leds//max_brightness. diff --git a/Documentation/ABI/testing/sysfs-class-mei b/Documentation/ABI/testing/sysfs-class-mei index e9dc110650ae..5c52372b43cb 100644 --- a/Documentation/ABI/testing/sysfs-class-mei +++ b/Documentation/ABI/testing/sysfs-class-mei @@ -90,3 +90,16 @@ Description: Display trc status register content The ME FW writes Glitch Detection HW (TRC) status information into trc status register for BIOS and OS to monitor fw health. + +What: /sys/class/mei/meiN/kind +Date: Jul 2020 +KernelVersion: 5.8 +Contact: Tomas Winkler +Description: Display kind of the device + + Generic devices are marked as "mei" + while special purpose have their own + names. + Available options: + - mei: generic mei device. + - itouch: itouch (ipts) mei device. diff --git a/Documentation/ABI/testing/sysfs-devices-consumer b/Documentation/ABI/testing/sysfs-devices-consumer new file mode 100644 index 000000000000..1f06d74d1c3c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-consumer @@ -0,0 +1,8 @@ +What: /sys/devices/.../consumer: +Date: May 2020 +Contact: Saravana Kannan +Description: + The /sys/devices/.../consumer: are symlinks to device + links where this device is the supplier. denotes the + name of the consumer in that device link. There can be zero or + more of these symlinks for a given device. diff --git a/Documentation/ABI/testing/sysfs-devices-mapping b/Documentation/ABI/testing/sysfs-devices-mapping new file mode 100644 index 000000000000..490ccfd67f12 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-mapping @@ -0,0 +1,33 @@ +What: /sys/devices/uncore_iio_x/dieX +Date: February 2020 +Contact: Roman Sudarikov +Description: + Each IIO stack (PCIe root port) has its own IIO PMON block, so + each dieX file (where X is die number) holds "Segment:Root Bus" + for PCIe root port, which can be monitored by that IIO PMON + block. + For example, on 4-die Xeon platform with up to 6 IIO stacks per + die and, therefore, 6 IIO PMON blocks per die, the mapping of + IIO PMON block 0 exposes as the following: + + $ ls /sys/devices/uncore_iio_0/die* + -r--r--r-- /sys/devices/uncore_iio_0/die0 + -r--r--r-- /sys/devices/uncore_iio_0/die1 + -r--r--r-- /sys/devices/uncore_iio_0/die2 + -r--r--r-- /sys/devices/uncore_iio_0/die3 + + $ tail /sys/devices/uncore_iio_0/die* + ==> /sys/devices/uncore_iio_0/die0 <== + 0000:00 + ==> /sys/devices/uncore_iio_0/die1 <== + 0000:40 + ==> /sys/devices/uncore_iio_0/die2 <== + 0000:80 + ==> /sys/devices/uncore_iio_0/die3 <== + 0000:c0 + + Which means: + IIO PMU 0 on die 0 belongs to PCI RP on bus 0x00, domain 0x0000 + IIO PMU 0 on die 1 belongs to PCI RP on bus 0x40, domain 0x0000 + IIO PMU 0 on die 2 belongs to PCI RP on bus 0x80, domain 0x0000 + IIO PMU 0 on die 3 belongs to PCI RP on bus 0xc0, domain 0x0000 diff --git a/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu b/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu index ae9af984471a..a8daceb4a956 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu +++ b/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu @@ -126,3 +126,39 @@ Description: 1 no action 0 firmware record the notify code defined in b[15:0]. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf0 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong +Description: + (RO) Decision firmware copy 0 version information. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf1 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong +Description: + (RO) Decision firmware copy 1 version information. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf2 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong +Description: + (RO) Decision firmware copy 2 version information. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf3 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong +Description: + (RO) Decision firmware copy 3 version information. + +What: /sys/devices/platform/stratix10-rsu.0/max_retry +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong +Description: + (RO) max retry parameter is stored in the firmware + decision IO section, as a byte located at offset 0x18c. diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc index ba3a3fac0ee1..ea999e292f11 100644 --- a/Documentation/ABI/testing/sysfs-devices-soc +++ b/Documentation/ABI/testing/sysfs-devices-soc @@ -26,6 +26,30 @@ Description: Read-only attribute common to all SoCs. Contains SoC family name (e.g. DB8500). + On many of ARM based silicon with SMCCC v1.2+ compliant firmware + this will contain the JEDEC JEP106 manufacturer’s identification + code. The format is "jep106:XXYY" where XX is identity code and + YY is continuation code. + + This manufacturer’s identification code is defined by one + or more eight (8) bit fields, each consisting of seven (7) + data bits plus one (1) odd parity bit. It is a single field, + limiting the possible number of vendors to 126. To expand + the maximum number of identification codes, a continuation + scheme has been defined. + + The specified mechanism is that an identity code of 0x7F + represents the "continuation code" and implies the presence + of an additional identity code field, and this mechanism + may be extended to multiple continuation codes followed + by the manufacturer's identity code. + + For example, ARM has identity code 0x7F 0x7F 0x7F 0x7F 0x3B, + which is code 0x3B on the fifth 'page'. This is shortened + as JEP106 identity code of 0x3B and a continuation code of + 0x4 to represent the four continuation codes preceding the + identity code. + What: /sys/devices/socX/serial_number Date: January 2019 contact: Bjorn Andersson @@ -40,6 +64,12 @@ Description: Read-only attribute supported by most SoCs. In the case of ST-Ericsson's chips this contains the SoC serial number. + On many of ARM based silicon with SMCCC v1.2+ compliant firmware + this will contain the SOC ID appended to the family attribute + to ensure there is no conflict in this namespace across various + vendors. The format is "jep106:XXYY:ZZZZ" where XX is identity + code, YY is continuation code and ZZZZ is the SOC ID. + What: /sys/devices/socX/revision Date: January 2012 contact: Lee Jones diff --git a/Documentation/ABI/testing/sysfs-devices-state_synced b/Documentation/ABI/testing/sysfs-devices-state_synced new file mode 100644 index 000000000000..0c922d7d02fc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-state_synced @@ -0,0 +1,24 @@ +What: /sys/devices/.../state_synced +Date: May 2020 +Contact: Saravana Kannan +Description: + The /sys/devices/.../state_synced attribute is only present for + devices whose bus types or driver provides the .sync_state() + callback. The number read from it (0 or 1) reflects the value + of the device's 'state_synced' field. A value of 0 means the + .sync_state() callback hasn't been called yet. A value of 1 + means the .sync_state() callback has been called. + + Generally, if a device has sync_state() support and has some of + the resources it provides enabled at the time the kernel starts + (Eg: enabled by hardware reset or bootloader or anything that + run before the kernel starts), then it'll keep those resources + enabled and in a state that's compatible with the state they + were in at the start of the kernel. The device will stop doing + this only when the sync_state() callback has been called -- + which happens only when all its consumer devices are registered + and have probed successfully. Resources that were left disabled + at the time the kernel starts are not affected or limited in + any way by sync_state() callbacks. + + diff --git a/Documentation/ABI/testing/sysfs-devices-supplier b/Documentation/ABI/testing/sysfs-devices-supplier new file mode 100644 index 000000000000..a919e0db5e90 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-supplier @@ -0,0 +1,8 @@ +What: /sys/devices/.../supplier: +Date: May 2020 +Contact: Saravana Kannan +Description: + The /sys/devices/.../supplier: are symlinks to device + links where this device is the consumer. denotes the + name of the supplier in that device link. There can be zero or + more of these symlinks for a given device. diff --git a/Documentation/ABI/testing/sysfs-devices-waiting_for_supplier b/Documentation/ABI/testing/sysfs-devices-waiting_for_supplier new file mode 100644 index 000000000000..59d073d20db6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-waiting_for_supplier @@ -0,0 +1,17 @@ +What: /sys/devices/.../waiting_for_supplier +Date: May 2020 +Contact: Saravana Kannan +Description: + The /sys/devices/.../waiting_for_supplier attribute is only + present when fw_devlink kernel command line option is enabled + and is set to something stricter than "permissive". It is + removed once a device probes successfully (because the + information is no longer relevant). The number read from it (0 + or 1) reflects whether the device is waiting for one or more + suppliers to be added and then linked to using device links + before the device can probe. + + A value of 0 means the device is not waiting for any suppliers + to be added before it can probe. A value of 1 means the device + is waiting for one or more suppliers to be added before it can + probe. diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 076659d506f2..9b488c0afdfa 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -8,7 +8,7 @@ Description: to device min/max capabilities. Values are integer as they are stored in a 8bit register in the device. Lowest value is automatically put to TL. Once set, alarms could be search at - master level, refer to Documentation/w1/w1_generic.rst for + master level, refer to Documentation/w1/w1-generic.rst for detailed information Users: any user space application which wants to communicate with w1_term device diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.rst b/Documentation/PCI/endpoint/function/binding/pci-test.rst new file mode 100644 index 000000000000..57ee866fb165 --- /dev/null +++ b/Documentation/PCI/endpoint/function/binding/pci-test.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +PCI Test Endpoint Function +========================== + +name: Should be "pci_epf_test" to bind to the pci_epf_test driver. + +Configurable Fields: + +================ =========================================================== +vendorid should be 0x104c +deviceid should be 0xb500 for DRA74x and 0xb501 for DRA72x +revid don't care +progif_code don't care +subclass_code don't care +baseclass_code should be 0xff +cache_line_size don't care +subsys_vendor_id don't care +subsys_id don't care +interrupt_pin Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD +msi_interrupts Should be 1 to 32 depending on the number of MSI interrupts + to test +msix_interrupts Should be 1 to 2048 depending on the number of MSI-X + interrupts to test +================ =========================================================== diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt b/Documentation/PCI/endpoint/function/binding/pci-test.txt deleted file mode 100644 index cd76ba47394b..000000000000 --- a/Documentation/PCI/endpoint/function/binding/pci-test.txt +++ /dev/null @@ -1,19 +0,0 @@ -PCI TEST ENDPOINT FUNCTION - -name: Should be "pci_epf_test" to bind to the pci_epf_test driver. - -Configurable Fields: -vendorid : should be 0x104c -deviceid : should be 0xb500 for DRA74x and 0xb501 for DRA72x -revid : don't care -progif_code : don't care -subclass_code : don't care -baseclass_code : should be 0xff -cache_line_size : don't care -subsys_vendor_id : don't care -subsys_id : don't care -interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD -msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts - to test -msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X - interrupts to test diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst index d114ea74b444..4ca7439fbfc9 100644 --- a/Documentation/PCI/endpoint/index.rst +++ b/Documentation/PCI/endpoint/index.rst @@ -11,3 +11,5 @@ PCI Endpoint Framework pci-endpoint-cfs pci-test-function pci-test-howto + + function/binding/pci-test diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst index b6d39cdec56e..1bbd81ed06c8 100644 --- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst +++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst @@ -24,7 +24,7 @@ Directory Structure The pci_ep configfs has two directories at its root: controllers and functions. Every EPC device present in the system will have an entry in -the *controllers* directory and and every EPF driver present in the system +the *controllers* directory and every EPF driver present in the system will have an entry in the *functions* directory. :: diff --git a/Documentation/PCI/endpoint/pci-endpoint.rst b/Documentation/PCI/endpoint/pci-endpoint.rst index 7536be445db8..4f5622a65555 100644 --- a/Documentation/PCI/endpoint/pci-endpoint.rst +++ b/Documentation/PCI/endpoint/pci-endpoint.rst @@ -214,7 +214,7 @@ pci-ep-cfs.c can be used as reference for using these APIs. * pci_epf_create() Create a new PCI EPF device by passing the name of the PCI EPF device. - This name will be used to bind the the EPF device to a EPF driver. + This name will be used to bind the EPF device to a EPF driver. * pci_epf_destroy() diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index 13beee23cb04..9fa49a6ece85 100644 --- a/Documentation/PCI/pci-error-recovery.rst +++ b/Documentation/PCI/pci-error-recovery.rst @@ -248,7 +248,7 @@ STEP 4: Slot Reset ------------------ In response to a return value of PCI_ERS_RESULT_NEED_RESET, the -the platform will perform a slot reset on the requesting PCI device(s). +platform will perform a slot reset on the requesting PCI device(s). The actual steps taken by a platform to perform a slot reset will be platform-dependent. Upon completion of slot reset, the platform will call the device slot_reset() callback. diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 8c016d8c9862..c35b187d5479 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -209,7 +209,7 @@ the PCI device by calling pci_enable_device(). This will: OS BUG: we don't check resource allocations before enabling those resources. The sequence would make more sense if we called pci_request_resources() before calling pci_enable_device(). - Currently, the device drivers can't detect the bug when when two + Currently, the device drivers can't detect the bug when two devices have been allocated the same range. This is not a common problem and unlikely to get fixed soon. @@ -265,7 +265,7 @@ Set the DMA mask size --------------------- .. note:: If anything below doesn't make sense, please refer to - Documentation/DMA-API.txt. This section is just a reminder that + :doc:`/core-api/dma-api`. This section is just a reminder that drivers need to indicate DMA capabilities of the device and is not an authoritative source for DMA interfaces. @@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are Setup shared control data ------------------------- Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared) -memory. See Documentation/DMA-API.txt for a full description of +memory. See :doc:`/core-api/dma-api` for a full description of the DMA APIs. This section is just a reminder that it needs to be done before enabling DMA on the device. @@ -421,7 +421,7 @@ owners if there is one. Then clean up "consistent" buffers which contain the control data. -See Documentation/DMA-API.txt for details on unmapping interfaces. +See :doc:`/core-api/dma-api` for details on unmapping interfaces. Unregister from other subsystems diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 75b8ca007a11..8f41ad0aa753 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -463,7 +463,7 @@ again without disrupting RCU readers. This guarantee was only partially premeditated. DYNIX/ptx used an explicit memory barrier for publication, but had nothing resembling ``rcu_dereference()`` for subscription, nor did it have anything -resembling the ``smp_read_barrier_depends()`` that was later subsumed +resembling the dependency-ordering barrier that was later subsumed into ``rcu_dereference()`` and later still into ``READ_ONCE()``. The need for these operations made itself known quite suddenly at a late-1990s meeting with the DEC Alpha architects, back in the days when @@ -2583,7 +2583,12 @@ not work to have these markers in the trampoline itself, because there would need to be instructions following ``rcu_read_unlock()``. Although ``synchronize_rcu()`` would guarantee that execution reached the ``rcu_read_unlock()``, it would not be able to guarantee that execution -had completely left the trampoline. +had completely left the trampoline. Worse yet, in some situations +the trampoline's protection must extend a few instructions *prior* to +execution reaching the trampoline. For example, these few instructions +might calculate the address of the trampoline, so that entering the +trampoline would be pre-ordained a surprisingly long time before execution +actually reached the trampoline itself. The solution, in the form of `Tasks RCU `__, is to have implicit read-side diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.rst similarity index 98% rename from Documentation/RCU/checklist.txt rename to Documentation/RCU/checklist.rst index e98ff261a438..2efed9926c3f 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.rst @@ -1,4 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ Review Checklist for RCU Patches +================================ This document contains a checklist for producing and reviewing patches @@ -411,18 +415,21 @@ over a rather long period of time, but improvements are always welcome! __rcu sparse checks to validate your RCU code. These can help find problems as follows: - CONFIG_PROVE_LOCKING: check that accesses to RCU-protected data + CONFIG_PROVE_LOCKING: + check that accesses to RCU-protected data structures are carried out under the proper RCU read-side critical section, while holding the right combination of locks, or whatever other conditions are appropriate. - CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the + CONFIG_DEBUG_OBJECTS_RCU_HEAD: + check that you don't pass the same object to call_rcu() (or friends) before an RCU grace period has elapsed since the last time that you passed that same object to call_rcu() (or friends). - __rcu sparse checks: tag the pointer to the RCU-protected data + __rcu sparse checks: + tag the pointer to the RCU-protected data structure with __rcu, and sparse will warn you if you access that pointer without the services of one of the variants of rcu_dereference(). @@ -442,8 +449,8 @@ over a rather long period of time, but improvements are always welcome! You instead need to use one of the barrier functions: - o call_rcu() -> rcu_barrier() - o call_srcu() -> srcu_barrier() + - call_rcu() -> rcu_barrier() + - call_srcu() -> srcu_barrier() However, these barrier functions are absolutely -not- guaranteed to wait for a grace period. In fact, if there are no call_rcu() diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst index 81a0a1e5f767..e703d3dbe60c 100644 --- a/Documentation/RCU/index.rst +++ b/Documentation/RCU/index.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + .. _rcu_concepts: ============ @@ -8,10 +10,17 @@ RCU concepts :maxdepth: 3 arrayRCU + checklist + lockdep + lockdep-splat rcubarrier rcu_dereference whatisRCU rcu + rculist_nulls + rcuref + torture + stallwarn listRCU NMI-RCU UP diff --git a/Documentation/RCU/lockdep-splat.txt b/Documentation/RCU/lockdep-splat.rst similarity index 54% rename from Documentation/RCU/lockdep-splat.txt rename to Documentation/RCU/lockdep-splat.rst index b8096316fd11..2a5c79db57dc 100644 --- a/Documentation/RCU/lockdep-splat.txt +++ b/Documentation/RCU/lockdep-splat.rst @@ -1,3 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Lockdep-RCU Splat +================= + Lockdep-RCU was added to the Linux kernel in early 2010 (http://lwn.net/Articles/371986/). This facility checks for some common misuses of the RCU API, most notably using one of the rcu_dereference() @@ -12,55 +18,54 @@ overwriting or worse. There can of course be false positives, this being the real world and all that. So let's look at an example RCU lockdep splat from 3.0-rc5, one that -has long since been fixed: +has long since been fixed:: -============================= -WARNING: suspicious RCU usage ------------------------------ -block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage! + ============================= + WARNING: suspicious RCU usage + ----------------------------- + block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage! -other info that might help us debug this: +other info that might help us debug this:: + rcu_scheduler_active = 1, debug_locks = 0 + 3 locks held by scsi_scan_6/1552: + #0: (&shost->scan_mutex){+.+.}, at: [] + scsi_scan_host_selected+0x5a/0x150 + #1: (&eq->sysfs_lock){+.+.}, at: [] + elevator_exit+0x22/0x60 + #2: (&(&q->__queue_lock)->rlock){-.-.}, at: [] + cfq_exit_queue+0x43/0x190 -rcu_scheduler_active = 1, debug_locks = 0 -3 locks held by scsi_scan_6/1552: - #0: (&shost->scan_mutex){+.+.}, at: [] -scsi_scan_host_selected+0x5a/0x150 - #1: (&eq->sysfs_lock){+.+.}, at: [] -elevator_exit+0x22/0x60 - #2: (&(&q->__queue_lock)->rlock){-.-.}, at: [] -cfq_exit_queue+0x43/0x190 + stack backtrace: + Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17 + Call Trace: + [] lockdep_rcu_dereference+0xbb/0xc0 + [] __cfq_exit_single_io_context+0xe9/0x120 + [] cfq_exit_queue+0x7c/0x190 + [] elevator_exit+0x36/0x60 + [] blk_cleanup_queue+0x4a/0x60 + [] scsi_free_queue+0x9/0x10 + [] __scsi_remove_device+0x84/0xd0 + [] scsi_probe_and_add_lun+0x353/0xb10 + [] ? error_exit+0x29/0xb0 + [] ? _raw_spin_unlock_irqrestore+0x3d/0x80 + [] __scsi_scan_target+0x112/0x680 + [] ? trace_hardirqs_off_thunk+0x3a/0x3c + [] ? error_exit+0x29/0xb0 + [] ? kobject_del+0x40/0x40 + [] scsi_scan_channel+0x86/0xb0 + [] scsi_scan_host_selected+0x140/0x150 + [] do_scsi_scan_host+0x89/0x90 + [] do_scan_async+0x20/0x160 + [] ? do_scsi_scan_host+0x90/0x90 + [] kthread+0xa6/0xb0 + [] kernel_thread_helper+0x4/0x10 + [] ? finish_task_switch+0x80/0x110 + [] ? retint_restore_args+0xe/0xe + [] ? __kthread_init_worker+0x70/0x70 + [] ? gs_change+0xb/0xb -stack backtrace: -Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17 -Call Trace: - [] lockdep_rcu_dereference+0xbb/0xc0 - [] __cfq_exit_single_io_context+0xe9/0x120 - [] cfq_exit_queue+0x7c/0x190 - [] elevator_exit+0x36/0x60 - [] blk_cleanup_queue+0x4a/0x60 - [] scsi_free_queue+0x9/0x10 - [] __scsi_remove_device+0x84/0xd0 - [] scsi_probe_and_add_lun+0x353/0xb10 - [] ? error_exit+0x29/0xb0 - [] ? _raw_spin_unlock_irqrestore+0x3d/0x80 - [] __scsi_scan_target+0x112/0x680 - [] ? trace_hardirqs_off_thunk+0x3a/0x3c - [] ? error_exit+0x29/0xb0 - [] ? kobject_del+0x40/0x40 - [] scsi_scan_channel+0x86/0xb0 - [] scsi_scan_host_selected+0x140/0x150 - [] do_scsi_scan_host+0x89/0x90 - [] do_scan_async+0x20/0x160 - [] ? do_scsi_scan_host+0x90/0x90 - [] kthread+0xa6/0xb0 - [] kernel_thread_helper+0x4/0x10 - [] ? finish_task_switch+0x80/0x110 - [] ? retint_restore_args+0xe/0xe - [] ? __kthread_init_worker+0x70/0x70 - [] ? gs_change+0xb/0xb - -Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows: +Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:: if (rcu_dereference(ioc->ioc_data) == cic) { @@ -70,7 +75,7 @@ case. Instead, we hold three locks, one of which might be RCU related. And maybe that lock really does protect this reference. If so, the fix is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to take the struct request_queue "q" from cfq_exit_queue() as an argument, -which would permit us to invoke rcu_dereference_protected as follows: +which would permit us to invoke rcu_dereference_protected as follows:: if (rcu_dereference_protected(ioc->ioc_data, lockdep_is_held(&q->queue_lock)) == cic) { @@ -85,7 +90,7 @@ On the other hand, perhaps we really do need an RCU read-side critical section. In this case, the critical section must span the use of the return value from rcu_dereference(), or at least until there is some reference count incremented or some such. One way to handle this is to -add rcu_read_lock() and rcu_read_unlock() as follows: +add rcu_read_lock() and rcu_read_unlock() as follows:: rcu_read_lock(); if (rcu_dereference(ioc->ioc_data) == cic) { @@ -102,7 +107,7 @@ above lockdep-RCU splat. But in this particular case, we don't actually dereference the pointer returned from rcu_dereference(). Instead, that pointer is just compared to the cic pointer, which means that the rcu_dereference() can be replaced -by rcu_access_pointer() as follows: +by rcu_access_pointer() as follows:: if (rcu_access_pointer(ioc->ioc_data) == cic) { diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.rst similarity index 96% rename from Documentation/RCU/lockdep.txt rename to Documentation/RCU/lockdep.rst index 89db949eeca0..f1fc8ae3846a 100644 --- a/Documentation/RCU/lockdep.txt +++ b/Documentation/RCU/lockdep.rst @@ -1,4 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== RCU and lockdep checking +======================== All flavors of RCU have lockdep checking available, so that lockdep is aware of when each task enters and leaves any flavor of RCU read-side @@ -8,7 +12,7 @@ tracking to include RCU state, which can sometimes help when debugging deadlocks and the like. In addition, RCU provides the following primitives that check lockdep's -state: +state:: rcu_read_lock_held() for normal RCU. rcu_read_lock_bh_held() for RCU-bh. @@ -63,7 +67,7 @@ checking of rcu_dereference() primitives: The rcu_dereference_check() check expression can be any boolean expression, but would normally include a lockdep expression. However, any boolean expression can be used. For a moderately ornate example, -consider the following: +consider the following:: file = rcu_dereference_check(fdt->fd[fd], lockdep_is_held(&files->file_lock) || @@ -82,7 +86,7 @@ RCU read-side critical sections, in case (2) the ->file_lock prevents any change from taking place, and finally, in case (3) the current task is the only task accessing the file_struct, again preventing any change from taking place. If the above statement was invoked only from updater -code, it could instead be written as follows: +code, it could instead be written as follows:: file = rcu_dereference_protected(fdt->fd[fd], lockdep_is_held(&files->file_lock) || @@ -105,7 +109,7 @@ false and they are called from outside any RCU read-side critical section. For example, the workqueue for_each_pwq() macro is intended to be used either within an RCU read-side critical section or with wq->mutex held. -It is thus implemented as follows: +It is thus implemented as follows:: #define for_each_pwq(pwq, wq) list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node, diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst new file mode 100644 index 000000000000..a9fc774bc400 --- /dev/null +++ b/Documentation/RCU/rculist_nulls.rst @@ -0,0 +1,200 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================= +Using RCU hlist_nulls to protect list and objects +================================================= + +This section describes how to use hlist_nulls to +protect read-mostly linked lists and +objects using SLAB_TYPESAFE_BY_RCU allocations. + +Please read the basics in Documentation/RCU/listRCU.rst + +Using 'nulls' +============= + +Using special makers (called 'nulls') is a convenient way +to solve following problem : + +A typical RCU linked list managing objects which are +allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can +use following algos : + +1) Lookup algo +-------------- + +:: + + rcu_read_lock() + begin: + obj = lockless_lookup(key); + if (obj) { + if (!try_get_ref(obj)) // might fail for free objects + goto begin; + /* + * Because a writer could delete object, and a writer could + * reuse these object before the RCU grace period, we + * must check key after getting the reference on object + */ + if (obj->key != key) { // not the object we expected + put_ref(obj); + goto begin; + } + } + rcu_read_unlock(); + +Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu() +but a version with an additional memory barrier (smp_rmb()) + +:: + + lockless_lookup(key) + { + struct hlist_node *node, *next; + for (pos = rcu_dereference((head)->first); + pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) && + ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; }); + pos = rcu_dereference(next)) + if (obj->key == key) + return obj; + return NULL; + } + +And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb():: + + struct hlist_node *node; + for (pos = rcu_dereference((head)->first); + pos && ({ prefetch(pos->next); 1; }) && + ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; }); + pos = rcu_dereference(pos->next)) + if (obj->key == key) + return obj; + return NULL; + +Quoting Corey Minyard:: + + "If the object is moved from one list to another list in-between the + time the hash is calculated and the next field is accessed, and the + object has moved to the end of a new list, the traversal will not + complete properly on the list it should have, since the object will + be on the end of the new list and there's not a way to tell it's on a + new list and restart the list traversal. I think that this can be + solved by pre-fetching the "next" field (with proper barriers) before + checking the key." + +2) Insert algo +-------------- + +We need to make sure a reader cannot read the new 'obj->obj_next' value +and previous value of 'obj->key'. Or else, an item could be deleted +from a chain, and inserted into another chain. If new chain was empty +before the move, 'next' pointer is NULL, and lockless reader can +not detect it missed following items in original chain. + +:: + + /* + * Please note that new inserts are done at the head of list, + * not in the middle or end. + */ + obj = kmem_cache_alloc(...); + lock_chain(); // typically a spin_lock() + obj->key = key; + /* + * we need to make sure obj->key is updated before obj->next + * or obj->refcnt + */ + smp_wmb(); + atomic_set(&obj->refcnt, 1); + hlist_add_head_rcu(&obj->obj_node, list); + unlock_chain(); // typically a spin_unlock() + + +3) Remove algo +-------------- +Nothing special here, we can use a standard RCU hlist deletion. +But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused +very very fast (before the end of RCU grace period) + +:: + + if (put_last_reference_on(obj) { + lock_chain(); // typically a spin_lock() + hlist_del_init_rcu(&obj->obj_node); + unlock_chain(); // typically a spin_unlock() + kmem_cache_free(cachep, obj); + } + + + +-------------------------------------------------------------------------- + +Avoiding extra smp_rmb() +======================== + +With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup() +and extra smp_wmb() in insert function. + +For example, if we choose to store the slot number as the 'nulls' +end-of-list marker for each slot of the hash table, we can detect +a race (some writer did a delete and/or a move of an object +to another chain) checking the final 'nulls' value if +the lookup met the end of chain. If final 'nulls' value +is not the slot number, then we must restart the lookup at +the beginning. If the object was moved to the same chain, +then the reader doesn't care : It might eventually +scan the list again without harm. + + +1) lookup algo +-------------- + +:: + + head = &table[slot]; + rcu_read_lock(); + begin: + hlist_nulls_for_each_entry_rcu(obj, node, head, member) { + if (obj->key == key) { + if (!try_get_ref(obj)) // might fail for free objects + goto begin; + if (obj->key != key) { // not the object we expected + put_ref(obj); + goto begin; + } + goto out; + } + /* + * if the nulls value we got at the end of this lookup is + * not the expected one, we must restart lookup. + * We probably met an item that was moved to another chain. + */ + if (get_nulls_value(node) != slot) + goto begin; + obj = NULL; + + out: + rcu_read_unlock(); + +2) Insert function +------------------ + +:: + + /* + * Please note that new inserts are done at the head of list, + * not in the middle or end. + */ + obj = kmem_cache_alloc(cachep); + lock_chain(); // typically a spin_lock() + obj->key = key; + /* + * changes to obj->key must be visible before refcnt one + */ + smp_wmb(); + atomic_set(&obj->refcnt, 1); + /* + * insert obj in RCU way (readers might be traversing chain) + */ + hlist_nulls_add_head_rcu(&obj->obj_node, list); + unlock_chain(); // typically a spin_unlock() diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt deleted file mode 100644 index 23f115dc87cf..000000000000 --- a/Documentation/RCU/rculist_nulls.txt +++ /dev/null @@ -1,172 +0,0 @@ -Using hlist_nulls to protect read-mostly linked lists and -objects using SLAB_TYPESAFE_BY_RCU allocations. - -Please read the basics in Documentation/RCU/listRCU.rst - -Using special makers (called 'nulls') is a convenient way -to solve following problem : - -A typical RCU linked list managing objects which are -allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can -use following algos : - -1) Lookup algo --------------- -rcu_read_lock() -begin: -obj = lockless_lookup(key); -if (obj) { - if (!try_get_ref(obj)) // might fail for free objects - goto begin; - /* - * Because a writer could delete object, and a writer could - * reuse these object before the RCU grace period, we - * must check key after getting the reference on object - */ - if (obj->key != key) { // not the object we expected - put_ref(obj); - goto begin; - } -} -rcu_read_unlock(); - -Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu() -but a version with an additional memory barrier (smp_rmb()) - -lockless_lookup(key) -{ - struct hlist_node *node, *next; - for (pos = rcu_dereference((head)->first); - pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) && - ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; }); - pos = rcu_dereference(next)) - if (obj->key == key) - return obj; - return NULL; - -And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb() : - - struct hlist_node *node; - for (pos = rcu_dereference((head)->first); - pos && ({ prefetch(pos->next); 1; }) && - ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; }); - pos = rcu_dereference(pos->next)) - if (obj->key == key) - return obj; - return NULL; -} - -Quoting Corey Minyard : - -"If the object is moved from one list to another list in-between the - time the hash is calculated and the next field is accessed, and the - object has moved to the end of a new list, the traversal will not - complete properly on the list it should have, since the object will - be on the end of the new list and there's not a way to tell it's on a - new list and restart the list traversal. I think that this can be - solved by pre-fetching the "next" field (with proper barriers) before - checking the key." - -2) Insert algo : ----------------- - -We need to make sure a reader cannot read the new 'obj->obj_next' value -and previous value of 'obj->key'. Or else, an item could be deleted -from a chain, and inserted into another chain. If new chain was empty -before the move, 'next' pointer is NULL, and lockless reader can -not detect it missed following items in original chain. - -/* - * Please note that new inserts are done at the head of list, - * not in the middle or end. - */ -obj = kmem_cache_alloc(...); -lock_chain(); // typically a spin_lock() -obj->key = key; -/* - * we need to make sure obj->key is updated before obj->next - * or obj->refcnt - */ -smp_wmb(); -atomic_set(&obj->refcnt, 1); -hlist_add_head_rcu(&obj->obj_node, list); -unlock_chain(); // typically a spin_unlock() - - -3) Remove algo --------------- -Nothing special here, we can use a standard RCU hlist deletion. -But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused -very very fast (before the end of RCU grace period) - -if (put_last_reference_on(obj) { - lock_chain(); // typically a spin_lock() - hlist_del_init_rcu(&obj->obj_node); - unlock_chain(); // typically a spin_unlock() - kmem_cache_free(cachep, obj); -} - - - --------------------------------------------------------------------------- -With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup() -and extra smp_wmb() in insert function. - -For example, if we choose to store the slot number as the 'nulls' -end-of-list marker for each slot of the hash table, we can detect -a race (some writer did a delete and/or a move of an object -to another chain) checking the final 'nulls' value if -the lookup met the end of chain. If final 'nulls' value -is not the slot number, then we must restart the lookup at -the beginning. If the object was moved to the same chain, -then the reader doesn't care : It might eventually -scan the list again without harm. - - -1) lookup algo - - head = &table[slot]; - rcu_read_lock(); -begin: - hlist_nulls_for_each_entry_rcu(obj, node, head, member) { - if (obj->key == key) { - if (!try_get_ref(obj)) // might fail for free objects - goto begin; - if (obj->key != key) { // not the object we expected - put_ref(obj); - goto begin; - } - goto out; - } -/* - * if the nulls value we got at the end of this lookup is - * not the expected one, we must restart lookup. - * We probably met an item that was moved to another chain. - */ - if (get_nulls_value(node) != slot) - goto begin; - obj = NULL; - -out: - rcu_read_unlock(); - -2) Insert function : --------------------- - -/* - * Please note that new inserts are done at the head of list, - * not in the middle or end. - */ -obj = kmem_cache_alloc(cachep); -lock_chain(); // typically a spin_lock() -obj->key = key; -/* - * changes to obj->key must be visible before refcnt one - */ -smp_wmb(); -atomic_set(&obj->refcnt, 1); -/* - * insert obj in RCU way (readers might be traversing chain) - */ -hlist_nulls_add_head_rcu(&obj->obj_node, list); -unlock_chain(); // typically a spin_unlock() diff --git a/Documentation/RCU/rcuref.txt b/Documentation/RCU/rcuref.rst similarity index 50% rename from Documentation/RCU/rcuref.txt rename to Documentation/RCU/rcuref.rst index 5e6429d66c24..b33aeb14fde3 100644 --- a/Documentation/RCU/rcuref.txt +++ b/Documentation/RCU/rcuref.rst @@ -1,4 +1,8 @@ -Reference-count design for elements of lists/arrays protected by RCU. +.. SPDX-License-Identifier: GPL-2.0 + +==================================================================== +Reference-count design for elements of lists/arrays protected by RCU +==================================================================== Please note that the percpu-ref feature is likely your first @@ -12,32 +16,33 @@ please read on. Reference counting on elements of lists which are protected by traditional reader/writer spinlocks or semaphores are straightforward: -CODE LISTING A: -1. 2. -add() search_and_reference() -{ { - alloc_object read_lock(&list_lock); - ... search_for_element - atomic_set(&el->rc, 1); atomic_inc(&el->rc); - write_lock(&list_lock); ... - add_element read_unlock(&list_lock); - ... ... - write_unlock(&list_lock); } -} +CODE LISTING A:: -3. 4. -release_referenced() delete() -{ { - ... write_lock(&list_lock); - if(atomic_dec_and_test(&el->rc)) ... - kfree(el); - ... remove_element -} write_unlock(&list_lock); - ... - if (atomic_dec_and_test(&el->rc)) - kfree(el); - ... - } + 1. 2. + add() search_and_reference() + { { + alloc_object read_lock(&list_lock); + ... search_for_element + atomic_set(&el->rc, 1); atomic_inc(&el->rc); + write_lock(&list_lock); ... + add_element read_unlock(&list_lock); + ... ... + write_unlock(&list_lock); } + } + + 3. 4. + release_referenced() delete() + { { + ... write_lock(&list_lock); + if(atomic_dec_and_test(&el->rc)) ... + kfree(el); + ... remove_element + } write_unlock(&list_lock); + ... + if (atomic_dec_and_test(&el->rc)) + kfree(el); + ... + } If this list/array is made lock free using RCU as in changing the write_lock() in add() and delete() to spin_lock() and changing read_lock() @@ -46,34 +51,35 @@ search_and_reference() could potentially hold reference to an element which has already been deleted from the list/array. Use atomic_inc_not_zero() in this scenario as follows: -CODE LISTING B: -1. 2. -add() search_and_reference() -{ { - alloc_object rcu_read_lock(); - ... search_for_element - atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) { - spin_lock(&list_lock); rcu_read_unlock(); - return FAIL; - add_element } - ... ... - spin_unlock(&list_lock); rcu_read_unlock(); -} } -3. 4. -release_referenced() delete() -{ { - ... spin_lock(&list_lock); - if (atomic_dec_and_test(&el->rc)) ... - call_rcu(&el->head, el_free); remove_element - ... spin_unlock(&list_lock); -} ... - if (atomic_dec_and_test(&el->rc)) - call_rcu(&el->head, el_free); - ... - } +CODE LISTING B:: + + 1. 2. + add() search_and_reference() + { { + alloc_object rcu_read_lock(); + ... search_for_element + atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) { + spin_lock(&list_lock); rcu_read_unlock(); + return FAIL; + add_element } + ... ... + spin_unlock(&list_lock); rcu_read_unlock(); + } } + 3. 4. + release_referenced() delete() + { { + ... spin_lock(&list_lock); + if (atomic_dec_and_test(&el->rc)) ... + call_rcu(&el->head, el_free); remove_element + ... spin_unlock(&list_lock); + } ... + if (atomic_dec_and_test(&el->rc)) + call_rcu(&el->head, el_free); + ... + } Sometimes, a reference to the element needs to be obtained in the -update (write) stream. In such cases, atomic_inc_not_zero() might be +update (write) stream. In such cases, atomic_inc_not_zero() might be overkill, since we hold the update-side spinlock. One might instead use atomic_inc() in such cases. @@ -82,39 +88,40 @@ search_and_reference() code path. In such cases, the atomic_dec_and_test() may be moved from delete() to el_free() as follows: -CODE LISTING C: -1. 2. -add() search_and_reference() -{ { - alloc_object rcu_read_lock(); - ... search_for_element - atomic_set(&el->rc, 1); atomic_inc(&el->rc); - spin_lock(&list_lock); ... +CODE LISTING C:: - add_element rcu_read_unlock(); - ... } - spin_unlock(&list_lock); 4. -} delete() -3. { -release_referenced() spin_lock(&list_lock); -{ ... - ... remove_element - if (atomic_dec_and_test(&el->rc)) spin_unlock(&list_lock); - kfree(el); ... - ... call_rcu(&el->head, el_free); -} ... -5. } -void el_free(struct rcu_head *rhp) -{ - release_referenced(); -} + 1. 2. + add() search_and_reference() + { { + alloc_object rcu_read_lock(); + ... search_for_element + atomic_set(&el->rc, 1); atomic_inc(&el->rc); + spin_lock(&list_lock); ... + + add_element rcu_read_unlock(); + ... } + spin_unlock(&list_lock); 4. + } delete() + 3. { + release_referenced() spin_lock(&list_lock); + { ... + ... remove_element + if (atomic_dec_and_test(&el->rc)) spin_unlock(&list_lock); + kfree(el); ... + ... call_rcu(&el->head, el_free); + } ... + 5. } + void el_free(struct rcu_head *rhp) + { + release_referenced(); + } The key point is that the initial reference added by add() is not removed until after a grace period has elapsed following removal. This means that search_and_reference() cannot find this element, which means that the value of el->rc cannot increase. Thus, once it reaches zero, there are no -readers that can or ever will be able to reference the element. The -element can therefore safely be freed. This in turn guarantees that if +readers that can or ever will be able to reference the element. The +element can therefore safely be freed. This in turn guarantees that if any reader finds the element, that reader may safely acquire a reference without checking the value of the reference counter. @@ -130,21 +137,21 @@ the eventual invocation of kfree(), which is usually not a problem on modern computer systems, even the small ones. In cases where delete() can sleep, synchronize_rcu() can be called from -delete(), so that el_free() can be subsumed into delete as follows: +delete(), so that el_free() can be subsumed into delete as follows:: -4. -delete() -{ - spin_lock(&list_lock); - ... - remove_element - spin_unlock(&list_lock); - ... - synchronize_rcu(); - if (atomic_dec_and_test(&el->rc)) - kfree(el); - ... -} + 4. + delete() + { + spin_lock(&list_lock); + ... + remove_element + spin_unlock(&list_lock); + ... + synchronize_rcu(); + if (atomic_dec_and_test(&el->rc)) + kfree(el); + ... + } As additional examples in the kernel, the pattern in listing C is used by reference counting of struct pid, while the pattern in listing B is used by diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.rst similarity index 88% rename from Documentation/RCU/stallwarn.txt rename to Documentation/RCU/stallwarn.rst index a360a8796710..c9ab6af4d3be 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.rst @@ -1,4 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== Using RCU's CPU Stall Detector +============================== This document first discusses what sorts of issues RCU's CPU stall detector can locate, and then discusses kernel parameters and Kconfig @@ -7,39 +11,40 @@ this document explains the stall detector's "splat" format. What Causes RCU CPU Stall Warnings? +=================================== So your kernel printed an RCU CPU stall warning. The next question is "What caused it?" The following problems can result in RCU CPU stall warnings: -o A CPU looping in an RCU read-side critical section. +- A CPU looping in an RCU read-side critical section. -o A CPU looping with interrupts disabled. +- A CPU looping with interrupts disabled. -o A CPU looping with preemption disabled. +- A CPU looping with preemption disabled. -o A CPU looping with bottom halves disabled. +- A CPU looping with bottom halves disabled. -o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel +- For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel without invoking schedule(). If the looping in the kernel is really expected and desirable behavior, you might need to add some calls to cond_resched(). -o Booting Linux using a console connection that is too slow to +- Booting Linux using a console connection that is too slow to keep up with the boot-time console-message rate. For example, a 115Kbaud serial console can be -way- too slow to keep up with boot-time message rates, and will frequently result in RCU CPU stall warning messages. Especially if you have added debug printk()s. -o Anything that prevents RCU's grace-period kthreads from running. +- Anything that prevents RCU's grace-period kthreads from running. This can result in the "All QSes seen" console-log message. This message will include information on when the kthread last ran and how often it should be expected to run. It can also - result in the "rcu_.*kthread starved for" console-log message, + result in the ``rcu_.*kthread starved for`` console-log message, which will include additional debugging information. -o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might +- A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might happen to preempt a low-priority task in the middle of an RCU read-side critical section. This is especially damaging if that low-priority task is not permitted to run on any other CPU, @@ -48,7 +53,7 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might While the system is in the process of running itself out of memory, you might see stall-warning messages. -o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that +- A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that is running at a higher priority than the RCU softirq threads. This will prevent RCU callbacks from ever being invoked, and in a CONFIG_PREEMPT_RCU kernel will further prevent @@ -63,7 +68,7 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that can increase your system's context-switch rate and thus degrade performance. -o A periodic interrupt whose handler takes longer than the time +- A periodic interrupt whose handler takes longer than the time interval between successive pairs of interrupts. This can prevent RCU's kthreads and softirq handlers from running. Note that certain high-overhead debugging options, for example @@ -71,20 +76,27 @@ o A periodic interrupt whose handler takes longer than the time considerably longer than normal, which can in turn result in RCU CPU stall warnings. -o Testing a workload on a fast system, tuning the stall-warning +- Testing a workload on a fast system, tuning the stall-warning timeout down to just barely avoid RCU CPU stall warnings, and then running the same workload with the same stall-warning timeout on a slow system. Note that thermal throttling and on-demand governors can cause a single system to be sometimes fast and sometimes slow! -o A hardware or software issue shuts off the scheduler-clock +- A hardware or software issue shuts off the scheduler-clock interrupt on a CPU that is not in dyntick-idle mode. This problem really has happened, and seems to be most likely to result in RCU CPU stall warnings for CONFIG_NO_HZ_COMMON=n kernels. -o A bug in the RCU implementation. +- A hardware or software issue that prevents time-based wakeups + from occurring. These issues can range from misconfigured or + buggy timer hardware through bugs in the interrupt or exception + path (whether hardware, firmware, or software) through bugs + in Linux's timer subsystem through bugs in the scheduler, and, + yes, even including bugs in RCU itself. -o A hardware failure. This is quite unlikely, but has occurred +- A bug in the RCU implementation. + +- A hardware failure. This is quite unlikely, but has occurred at least once in real life. A CPU failed in a running system, becoming unresponsive, but not causing an immediate crash. This resulted in a series of RCU CPU stall warnings, eventually @@ -109,6 +121,7 @@ see include/trace/events/rcu.h. Fine-Tuning the RCU CPU Stall Detector +====================================== The rcuupdate.rcu_cpu_stall_suppress module parameter disables RCU's CPU stall detector, which detects conditions that unduly delay RCU grace @@ -118,6 +131,7 @@ The stall detector's idea of what constitutes "unduly delayed" is controlled by a set of kernel configuration variables and cpp macros: CONFIG_RCU_CPU_STALL_TIMEOUT +---------------------------- This kernel configuration parameter defines the period of time that RCU will wait from the beginning of a grace period until it @@ -137,6 +151,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT /sys/module/rcupdate/parameters/rcu_cpu_stall_suppress. RCU_STALL_DELAY_DELTA +--------------------- Although the lockdep facility is extremely useful, it does add some overhead. Therefore, under CONFIG_PROVE_RCU, the @@ -145,6 +160,7 @@ RCU_STALL_DELAY_DELTA macro, not a kernel configuration parameter.) RCU_STALL_RAT_DELAY +------------------- The CPU stall detector tries to make the offending CPU print its own warnings, as this often gives better-quality stack traces. @@ -155,6 +171,7 @@ RCU_STALL_RAT_DELAY parameter.) rcupdate.rcu_task_stall_timeout +------------------------------- This boot/sysfs parameter controls the RCU-tasks stall warning interval. A value of zero or less suppresses RCU-tasks stall @@ -168,9 +185,10 @@ rcupdate.rcu_task_stall_timeout Interpreting RCU's CPU Stall-Detector "Splats" +============================================== For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling, -it will print a message similar to the following: +it will print a message similar to the following:: INFO: rcu_sched detected stalls on CPUs/tasks: 2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0 @@ -223,7 +241,7 @@ an estimate of the total number of RCU callbacks queued across all CPUs (625 in this case). In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed -for each CPU: +for each CPU:: 0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 dyntick_enabled: 1 @@ -235,7 +253,7 @@ processing is enabled. If the grace period ends just as the stall warning starts printing, there will be a spurious stall-warning message, which will include -the following: +the following:: INFO: Stall ended before state dump start @@ -248,7 +266,7 @@ which is overkill for this sort of problem. If all CPUs and tasks have passed through quiescent states, but the grace period has nevertheless failed to end, the stall-warning splat -will include something like the following: +will include something like the following:: All QSes seen, last rcu_preempt kthread activity 23807 (4297905177-4297881370), jiffies_till_next_fqs=3, root ->qsmask 0x0 @@ -261,7 +279,7 @@ which is way less than 23807. Finally, the root rcu_node structure's If the relevant grace-period kthread has been unable to run prior to the stall warning, as was the case in the "All QSes seen" line above, -the following additional line is printed: +the following additional line is printed:: kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5 @@ -276,6 +294,7 @@ kthread last ran on CPU 5. Multiple Warnings From One Stall +================================ If a stall lasts long enough, multiple stall-warning messages will be printed for it. The second and subsequent messages are printed at @@ -285,9 +304,10 @@ of the stall and the first message. Stall Warnings for Expedited Grace Periods +========================================== If an expedited grace period detects a stall, it will place a message -like the following in dmesg: +like the following in dmesg:: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 7-... } 21119 jiffies s: 73 root: 0x2/. diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.rst similarity index 76% rename from Documentation/RCU/torture.txt rename to Documentation/RCU/torture.rst index af712a3c5b6a..a90147713062 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.rst @@ -1,7 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== RCU Torture Test Operation +========================== CONFIG_RCU_TORTURE_TEST +======================= The CONFIG_RCU_TORTURE_TEST config option is available for all RCU implementations. It creates an rcutorture kernel module that can @@ -13,9 +18,10 @@ when the module is loaded, and stops when the module is unloaded. Module parameters are prefixed by "rcutorture." in Documentation/admin-guide/kernel-parameters.txt. -OUTPUT +Output +====== -The statistics output is as follows: +The statistics output is as follows:: rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767 @@ -36,53 +42,53 @@ automatic determination as to whether RCU operated correctly. The entries are as follows: -o "rtc": The hexadecimal address of the structure currently visible +* "rtc": The hexadecimal address of the structure currently visible to readers. -o "ver": The number of times since boot that the RCU writer task +* "ver": The number of times since boot that the RCU writer task has changed the structure visible to readers. -o "tfle": If non-zero, indicates that the "torture freelist" +* "tfle": If non-zero, indicates that the "torture freelist" containing structures to be placed into the "rtc" area is empty. This condition is important, since it can fool you into thinking that RCU is working when it is not. :-/ -o "rta": Number of structures allocated from the torture freelist. +* "rta": Number of structures allocated from the torture freelist. -o "rtaf": Number of allocations from the torture freelist that have +* "rtaf": Number of allocations from the torture freelist that have failed due to the list being empty. It is not unusual for this to be non-zero, but it is bad for it to be a large fraction of the value indicated by "rta". -o "rtf": Number of frees into the torture freelist. +* "rtf": Number of frees into the torture freelist. -o "rtmbe": A non-zero value indicates that rcutorture believes that +* "rtmbe": A non-zero value indicates that rcutorture believes that rcu_assign_pointer() and rcu_dereference() are not working correctly. This value should be zero. -o "rtbe": A non-zero value indicates that one of the rcu_barrier() +* "rtbe": A non-zero value indicates that one of the rcu_barrier() family of functions is not working correctly. -o "rtbke": rcutorture was unable to create the real-time kthreads +* "rtbke": rcutorture was unable to create the real-time kthreads used to force RCU priority inversion. This value should be zero. -o "rtbre": Although rcutorture successfully created the kthreads +* "rtbre": Although rcutorture successfully created the kthreads used to force RCU priority inversion, it was unable to set them to the real-time priority level of 1. This value should be zero. -o "rtbf": The number of times that RCU priority boosting failed +* "rtbf": The number of times that RCU priority boosting failed to resolve RCU priority inversion. -o "rtb": The number of times that rcutorture attempted to force +* "rtb": The number of times that rcutorture attempted to force an RCU priority inversion condition. If you are testing RCU priority boosting via the "test_boost" module parameter, this value should be non-zero. -o "nt": The number of times rcutorture ran RCU read-side code from +* "nt": The number of times rcutorture ran RCU read-side code from within a timer handler. This value should be non-zero only if you specified the "irqreader" module parameter. -o "Reader Pipe": Histogram of "ages" of structures seen by readers. +* "Reader Pipe": Histogram of "ages" of structures seen by readers. If any entries past the first two are non-zero, RCU is broken. And rcutorture prints the error flag string "!!!" to make sure you notice. The age of a newly allocated structure is zero, @@ -94,14 +100,14 @@ o "Reader Pipe": Histogram of "ages" of structures seen by readers. RCU. If you want to see what it looks like when broken, break it yourself. ;-) -o "Reader Batch": Another histogram of "ages" of structures seen +* "Reader Batch": Another histogram of "ages" of structures seen by readers, but in terms of counter flips (or batches) rather than in terms of grace periods. The legal number of non-zero entries is again two. The reason for this separate view is that it is sometimes easier to get the third entry to show up in the "Reader Batch" list than in the "Reader Pipe" list. -o "Free-Block Circulation": Shows the number of torture structures +* "Free-Block Circulation": Shows the number of torture structures that have reached a given point in the pipeline. The first element should closely correspond to the number of structures allocated, the second to the number that have been removed from reader view, @@ -112,7 +118,7 @@ o "Free-Block Circulation": Shows the number of torture structures Different implementations of RCU can provide implementation-specific additional information. For example, Tree SRCU provides the following -additional line: +additional line:: srcud-torture: Tree SRCU per-CPU(idx=0): 0(35,-21) 1(-4,24) 2(1,1) 3(-26,20) 4(28,-47) 5(-9,4) 6(-10,14) 7(-14,11) T(1,6) @@ -123,15 +129,15 @@ using a dynamically allocated srcu_struct (hence "srcud-" rather than "old" and "current" values to the underlying array, and is useful for debugging. The final "T" entry contains the totals of the counters. - -USAGE ON SPECIFIC KERNEL BUILDS +Usage on Specific Kernel Builds +=============================== It is sometimes desirable to torture RCU on a specific kernel build, for example, when preparing to put that kernel build into production. In that case, the kernel should be built with CONFIG_RCU_TORTURE_TEST=m so that the test can be started using modprobe and terminated using rmmod. -For example, the following script may be used to torture RCU: +For example, the following script may be used to torture RCU:: #!/bin/sh @@ -148,7 +154,8 @@ two are self-explanatory, while the last indicates that while there were no RCU failures, CPU-hotplug problems were detected. -USAGE ON MAINLINE KERNELS +Usage on Mainline Kernels +========================= When using rcutorture to test changes to RCU itself, it is often necessary to build a number of kernels in order to test that change @@ -180,16 +187,16 @@ to Tree SRCU might run only the SRCU-N and SRCU-P scenarios using the --configs argument to kvm.sh as follows: "--configs 'SRCU-N SRCU-P'". Large systems can run multiple copies of of the full set of scenarios, for example, a system with 448 hardware threads can run five instances -of the full set concurrently. To make this happen: +of the full set concurrently. To make this happen:: kvm.sh --cpus 448 --configs '5*CFLIST' Alternatively, such a system can run 56 concurrent instances of a single -eight-CPU scenario: +eight-CPU scenario:: kvm.sh --cpus 448 --configs '56*TREE04' -Or 28 concurrent instances of each of two eight-CPU scenarios: +Or 28 concurrent instances of each of two eight-CPU scenarios:: kvm.sh --cpus 448 --configs '28*TREE03 28*TREE04' @@ -199,14 +206,14 @@ values for memory may require disabling the callback-flooding tests using the --bootargs parameter discussed below. Sometimes additional debugging is useful, and in such cases the --kconfig -parameter to kvm.sh may be used, for example, "--kconfig 'CONFIG_KASAN=y'". +parameter to kvm.sh may be used, for example, ``--kconfig 'CONFIG_KASAN=y'``. Kernel boot arguments can also be supplied, for example, to control rcutorture's module parameters. For example, to test a change to RCU's CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'". This will of course result in the scripting reporting a failure, namely the resuling RCU CPU stall warning. As noted above, reducing memory may -require disabling rcutorture's callback-flooding tests: +require disabling rcutorture's callback-flooding tests:: kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \ --bootargs 'rcutorture.fwd_progress=0' @@ -225,7 +232,7 @@ is listed at the end of the kvm.sh output, which you really should redirect to a file. The build products and console output of each run is kept in tools/testing/selftests/rcutorture/res in timestamped directories. A given directory can be supplied to kvm-find-errors.sh in order to have -it cycle you through summaries of errors and full error logs. For example: +it cycle you through summaries of errors and full error logs. For example:: tools/testing/selftests/rcutorture/bin/kvm-find-errors.sh \ tools/testing/selftests/rcutorture/res/2020.01.20-15.54.23 @@ -245,38 +252,42 @@ that was tested and any uncommitted changes in diff format. The most frequently used files in each per-scenario-run directory are: -.config: This file contains the Kconfig options. +.config: + This file contains the Kconfig options. -Make.out: This contains build output for a specific scenario. +Make.out: + This contains build output for a specific scenario. -console.log: This contains the console output for a specific scenario. +console.log: + This contains the console output for a specific scenario. This file may be examined once the kernel has booted, but it might not exist if the build failed. -vmlinux: This contains the kernel, which can be useful with tools like +vmlinux: + This contains the kernel, which can be useful with tools like objdump and gdb. A number of additional files are available, but are less frequently used. Many are intended for debugging of rcutorture itself or of its scripting. As of v5.4, a successful run with the default set of scenarios produces -the following summary at the end of the run on a 12-CPU system: +the following summary at the end of the run on a 12-CPU system:: -SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ] -SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ] -SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ] -SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ] -TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ] -TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ] -TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ] -TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198 -TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631 -TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ] -TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844 -TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497 -CPU count limited from 16 to 12 -TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961 -TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997 -TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732 -CPU count limited from 16 to 12 -TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011 + SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ] + SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ] + SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ] + SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ] + TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ] + TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ] + TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ] + TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198 + TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631 + TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ] + TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844 + TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497 + CPU count limited from 16 to 12 + TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961 + TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997 + TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732 + CPU count limited from 16 to 12 + TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011 diff --git a/Documentation/admin-guide/LSM/Yama.rst b/Documentation/admin-guide/LSM/Yama.rst index d0a060de3973..d9cd937ebd2d 100644 --- a/Documentation/admin-guide/LSM/Yama.rst +++ b/Documentation/admin-guide/LSM/Yama.rst @@ -19,9 +19,10 @@ attach to other running processes (e.g. Firefox, SSH sessions, GPG agent, etc) to extract additional credentials and continue to expand the scope of their attack without resorting to user-assisted phishing. -This is not a theoretical problem. SSH session hijacking -(http://www.storm.net.nz/projects/7) and arbitrary code injection -(http://c-skills.blogspot.com/2007/05/injectso.html) attacks already +This is not a theoretical problem. `SSH session hijacking +`_ +and `arbitrary code injection +`_ attacks already exist and remain possible if ptrace is allowed to operate as before. Since ptrace is not commonly used by non-developers and non-admins, system builders should be allowed the option to disable this debugging system. diff --git a/Documentation/admin-guide/blockdev/drbd/index.rst b/Documentation/admin-guide/blockdev/drbd/index.rst index 68ecd5c113e9..561fd1e35917 100644 --- a/Documentation/admin-guide/blockdev/drbd/index.rst +++ b/Documentation/admin-guide/blockdev/drbd/index.rst @@ -10,7 +10,7 @@ Description clusters and in this context, is a "drop-in" replacement for shared storage. Simplistically, you could see it as a network RAID 1. - Please visit http://www.drbd.org to find out more. + Please visit https://www.drbd.org to find out more. .. toctree:: :maxdepth: 1 diff --git a/Documentation/admin-guide/blockdev/floppy.rst b/Documentation/admin-guide/blockdev/floppy.rst index 4a8f31cf4139..0328438ebe2c 100644 --- a/Documentation/admin-guide/blockdev/floppy.rst +++ b/Documentation/admin-guide/blockdev/floppy.rst @@ -6,7 +6,7 @@ FAQ list: ========= A FAQ list may be found in the fdutils package (see below), and also -at . +at . LILO configuration options (Thinkpad users, read this) @@ -220,11 +220,11 @@ It also contains additional documentation about the floppy driver. The latest version can be found at fdutils homepage: - http://fdutils.linux.lu + https://fdutils.linux.lu The fdutils releases can be found at: - http://fdutils.linux.lu/download.html + https://fdutils.linux.lu/download.html http://www.tux.org/pub/knaff/fdutils/ diff --git a/Documentation/admin-guide/cgroup-v1/rdma.rst b/Documentation/admin-guide/cgroup-v1/rdma.rst index 2fcb0a9bf790..e69369b7252e 100644 --- a/Documentation/admin-guide/cgroup-v1/rdma.rst +++ b/Documentation/admin-guide/cgroup-v1/rdma.rst @@ -114,4 +114,4 @@ Following resources can be accounted by rdma controller. (d) Delete resource limit:: - echo echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max + echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index d09471aa7443..fa4018afa5a4 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1483,8 +1483,7 @@ IO Interface Files ~~~~~~~~~~~~~~~~~~ io.stat - A read-only nested-keyed file which exists on non-root - cgroups. + A read-only nested-keyed file. Lines are keyed by $MAJ:$MIN device numbers and not ordered. The following nested keys are defined. @@ -1684,9 +1683,9 @@ per-cgroup dirty memory states are examined and the more restrictive of the two is enforced. cgroup writeback requires explicit support from the underlying -filesystem. Currently, cgroup writeback is implemented on ext2, ext4 -and btrfs. On other filesystems, all writeback IOs are attributed to -the root cgroup. +filesystem. Currently, cgroup writeback is implemented on ext2, ext4, +btrfs, f2fs, and xfs. On other filesystems, all writeback IOs are +attributed to the root cgroup. There are inherent differences in memory and writeback management which affects how cgroup ownership is tracked. Memory is tracked per @@ -2043,7 +2042,7 @@ RDMA ---- The "rdma" controller regulates the distribution and accounting of -of RDMA resources. +RDMA resources. RDMA Interface Files ~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/admin-guide/cifs/todo.rst b/Documentation/admin-guide/cifs/todo.rst index 084c25f92dcb..25f11576e7b9 100644 --- a/Documentation/admin-guide/cifs/todo.rst +++ b/Documentation/admin-guide/cifs/todo.rst @@ -98,7 +98,7 @@ x) Finish support for SMB3.1.1 compression Known Bugs ========== -See http://bugzilla.samba.org - search on product "CifsVFS" for +See https://bugzilla.samba.org - search on product "CifsVFS" for current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS) 1) existing symbolic links (Windows reparse points) are recognized but diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst index d3fb67b8a976..7b32d5063803 100644 --- a/Documentation/admin-guide/cifs/usage.rst +++ b/Documentation/admin-guide/cifs/usage.rst @@ -16,8 +16,7 @@ standard for interoperating between Macs and Windows and major NAS appliances. Please see MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification) -http://protocolfreedom.org/ and -http://samba.org/samba/PFIF/ +or https://samba.org/samba/PFIF/ for more details. @@ -32,7 +31,7 @@ Build instructions For Linux: -1) Download the kernel (e.g. from http://www.kernel.org) +1) Download the kernel (e.g. from https://www.kernel.org) and change directory into the top of the kernel directory tree (e.g. /usr/src/linux-2.5.73) 2) make menuconfig (or make xconfig) @@ -831,7 +830,7 @@ the active sessions and the shares that are mounted. Enabling Kerberos (extended security) works but requires version 1.2 or later of the helper program cifs.upcall to be present and to be configured in the /etc/request-key.conf file. The cifs.upcall helper program is from the Samba -project(http://www.samba.org). NTLM and NTLMv2 and LANMAN support do not +project(https://www.samba.org). NTLM and NTLMv2 and LANMAN support do not require this helper. Note that NTLMv2 security (which does not require the cifs.upcall helper program), instead of using Kerberos, is sufficient for some use cases. diff --git a/Documentation/admin-guide/cifs/winucase_convert.pl b/Documentation/admin-guide/cifs/winucase_convert.pl index 322a9c833f23..993186beea20 100755 --- a/Documentation/admin-guide/cifs/winucase_convert.pl +++ b/Documentation/admin-guide/cifs/winucase_convert.pl @@ -16,7 +16,7 @@ # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License -# along with this program. If not, see . +# along with this program. If not, see . # while(<>) { diff --git a/Documentation/admin-guide/dell_rbu.rst b/Documentation/admin-guide/dell_rbu.rst index 8d70e1fc9f9d..2196caf1b939 100644 --- a/Documentation/admin-guide/dell_rbu.rst +++ b/Documentation/admin-guide/dell_rbu.rst @@ -26,7 +26,7 @@ Please go to http://support.dell.com register and you can find info on OpenManage and Dell Update packages (DUP). Libsmbios can also be used to update BIOS on Dell systems go to -http://linux.dell.com/libsmbios/ for details. +https://linux.dell.com/libsmbios/ for details. Dell_RBU driver supports BIOS update using the monolithic image and packetized image methods. In case of monolithic the driver allocates a contiguous chunk diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst index 9edd45593abd..3ab4f7756a6e 100644 --- a/Documentation/admin-guide/device-mapper/dm-integrity.rst +++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst @@ -45,7 +45,7 @@ To use the target for the first time: will format the device 3. unload the dm-integrity target 4. read the "provided_data_sectors" value from the superblock -5. load the dm-integrity target with the the target size +5. load the dm-integrity target with the target size "provided_data_sectors" 6. if you want to use dm-integrity with dm-crypt, load the dm-crypt target with the size "provided_data_sectors" @@ -99,7 +99,7 @@ interleave_sectors:number the superblock is used. meta_device:device - Don't interleave the data and metadata on on device. Use a + Don't interleave the data and metadata on the device. Use a separate device for metadata. buffer_sectors:number diff --git a/Documentation/admin-guide/device-mapper/dm-raid.rst b/Documentation/admin-guide/device-mapper/dm-raid.rst index 695a2ea1d1ae..7ef9fe63b3d4 100644 --- a/Documentation/admin-guide/device-mapper/dm-raid.rst +++ b/Documentation/admin-guide/device-mapper/dm-raid.rst @@ -71,7 +71,7 @@ The target is named "raid" and it accepts the following parameters:: ============= =============================================================== Reference: Chapter 4 of - http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf + https://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf <#raid_params>: The number of parameters that follow. diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst b/Documentation/admin-guide/device-mapper/dm-zoned.rst index 553752ea2521..e635041351bc 100644 --- a/Documentation/admin-guide/device-mapper/dm-zoned.rst +++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst @@ -14,7 +14,7 @@ host-aware zoned block devices. For a more detailed description of the zoned block device models and their constraints see (for SCSI devices): -http://www.t10.org/drafts.htm#ZBC_Family +https://www.t10.org/drafts.htm#ZBC_Family and (for ATA devices): diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 2a97aaec8b12..d336f3f73a4c 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -375,8 +375,9 @@ 239 = /dev/uhid User-space I/O driver support for HID subsystem 240 = /dev/userio Serio driver testing device 241 = /dev/vhost-vsock Host kernel driver for virtio vsock + 242 = /dev/rfkill Turning off radio transmissions (rfkill) - 242-254 Reserved for local use + 243-254 Reserved for local use 255 Reserved for MISC_DYNAMIC_MINOR 11 char Raw keyboard device (Linux/SPARC only) @@ -1442,7 +1443,7 @@ ... The driver and documentation may be obtained from - http://www.winradio.com/ + https://www.winradio.com/ 82 block I2O hard disk 0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk @@ -1656,7 +1657,7 @@ dynamically, so there is no fixed mapping from subdevice pathnames to minor numbers. - See http://www.comedi.org/ for information about the Comedi + See https://www.comedi.org/ for information about the Comedi project. 98 block User-mode virtual block device @@ -1723,7 +1724,7 @@ implementations a kernel presence for caching and easy mounting. For more information about the project, write to or see - http://www.stacken.kth.se/project/arla/ + https://www.stacken.kth.se/project/arla/ 103 block Audit device 0 = /dev/audit Audit device diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 1012bd9305e9..e5a8def45f3f 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -70,10 +70,10 @@ statements via:: nullarbor:~ # cat /dynamic_debug/control # filename:lineno [module]function flags format - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012" - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012" + net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" + net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" + net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012" + net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012" ... @@ -93,7 +93,7 @@ the debug statement callsites with any non-default flags:: nullarbor:~ # awk '$3 != "=_"' /dynamic_debug/control # filename:lineno [module]function flags format - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" + net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" Command Language Reference ========================== @@ -156,6 +156,7 @@ against. Possible keywords are::: ``line-range`` cannot contain space, e.g. "1-30" is valid range but "1 - 30" is not. + ``module=foo`` combined keyword=value form is interchangably accepted The meanings of each keyword are: @@ -164,15 +165,18 @@ func of each callsite. Example:: func svc_tcp_accept + func *recv* # in rfcomm, bluetooth, ping, tcp file - The given string is compared against either the full pathname, the - src-root relative pathname, or the basename of the source file of - each callsite. Examples:: + The given string is compared against either the src-root relative + pathname, or the basename of the source file of each callsite. + Examples:: file svcsock.c - file kernel/freezer.c - file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c + file kernel/freezer.c # ie column 1 of control file + file drivers/usb/* # all callsites under it + file inode.c:start_* # parse :tail as a func (above) + file inode.c:1-100 # parse :tail as a line-range (above) module The given string is compared against the module name @@ -182,6 +186,7 @@ module module sunrpc module nfsd + module drm* # both drm, drm_kms_helper format The given string is searched for in the dynamic debug format @@ -251,8 +256,8 @@ the syntax described above, but must not exceed 1023 characters. Your bootloader may impose lower limits. These ``dyndbg`` params are processed just after the ddebug tables are -processed, as part of the arch_initcall. Thus you can enable debug -messages in all code run after this arch_initcall via this boot +processed, as part of the early_initcall. Thus you can enable debug +messages in all code run after this early_initcall via this boot parameter. On an x86 system for example ACPI enablement is a subsys_initcall and:: diff --git a/Documentation/admin-guide/ext4.rst b/Documentation/admin-guide/ext4.rst index 9443fcef1876..a683976fad6d 100644 --- a/Documentation/admin-guide/ext4.rst +++ b/Documentation/admin-guide/ext4.rst @@ -395,6 +395,13 @@ When mounting an ext4 filesystem, the following option are accepted: Documentation/filesystems/dax.txt. Note that this option is incompatible with data=journal. + inlinecrypt + When possible, encrypt/decrypt the contents of encrypted files using the + blk-crypto framework rather than filesystem-layer encryption. This + allows the use of inline encryption hardware. The on-disk format is + unaffected. For more details, see + Documentation/block/inline-encryption.rst. + Data Mode ========= There are 3 different data modes: @@ -611,7 +618,7 @@ kernel source: programs: http://e2fsprogs.sourceforge.net/ -useful links: http://fedoraproject.org/wiki/ext3-devel +useful links: https://fedoraproject.org/wiki/ext3-devel http://www.bullopensource.org/ext4/ http://ext4.wiki.kernel.org/index.php/Main_Page - http://fedoraproject.org/wiki/Features/Ext4 + https://fedoraproject.org/wiki/Features/Ext4 diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst index 47b1b3afac99..3b1ce68d2456 100644 --- a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst @@ -14,7 +14,7 @@ to the core through the special register mechanism that is susceptible to MDS attacks. Affected processors --------------------- +------------------- Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may be affected. @@ -59,7 +59,7 @@ executed on another core or sibling thread using MDS techniques. Mitigation mechanism -------------------- +-------------------- Intel will release microcode updates that modify the RDRAND, RDSEED, and EGETKEY instructions to overwrite secret special register data in the shared staging buffer before the secret data can be accessed by another logical @@ -118,7 +118,7 @@ with the option "srbds=". The option for this is: ============= ============================================================= SRBDS System Information ------------------------ +------------------------ The Linux kernel provides vulnerability status information through sysfs. For SRBDS this can be accessed by the following sysfs file: /sys/devices/system/cpu/vulnerabilities/srbds diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 58c7f9fc2396..ed1cf94ea50c 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -41,6 +41,7 @@ problems and bugs in particular. init kdump/index perf/index + pstore-blk This is the beginning of a section with information of interest to application developers. Documents covering various aspects of the kernel diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index e4ee8b2db604..2baad0bfb09d 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -93,6 +93,11 @@ It exists in the sparse memory mapping model, and it is also somewhat similar to the mem_map variable, both of them are used to translate an address. +MAX_PHYSMEM_BITS +---------------- + +Defines the maximum supported physical address space memory. + page ---- @@ -399,6 +404,17 @@ KERNELPACMASK The mask to extract the Pointer Authentication Code from a kernel virtual address. +TCR_EL1.T1SZ +------------ + +Indicates the size offset of the memory region addressed by TTBR1_EL1. +The region size is 2^(64-T1SZ) bytes. + +TTBR1_EL1 is the table base address register specified by ARMv8-A +architecture which is used to lookup the page-tables for the Virtual +addresses in the higher VA range (refer to ARMv8 ARM document for +more details). + arm === diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index fb95fad81c79..254bfafdcbcd 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -703,6 +703,11 @@ cpufreq.off=1 [CPU_FREQ] disable the cpufreq sub-system + cpufreq.default_governor= + [CPU_FREQ] Name of the default cpufreq governor or + policy to use. This governor must be registered in the + kernel before the cpufreq driver probes. + cpu_init_udelay=N [X86] Delay for N microsec between assert and de-assert of APIC INIT to start processors. This delay occurs @@ -827,6 +832,21 @@ useful to also enable the page_owner functionality. on: enable the feature + debugfs= [KNL] This parameter enables what is exposed to userspace + and debugfs internal clients. + Format: { on, no-mount, off } + on: All functions are enabled. + no-mount: + Filesystem is not registered but kernel clients can + access APIs and a crashkernel can be used to read + its content. There is nothing to mount. + off: Filesystem is not registered and clients + get a -EPERM as result when trying to register files + or directories within debugfs. + This is equivalent of the runtime functionality if + debugfs was not enabled in the kernel at all. + Default value is set in build-time with a kernel configuration. + debugpat [X86] Enable PAT debugging decnet.addr= [HW,NET] @@ -1207,26 +1227,28 @@ Format: {"off" | "on" | "skip[mbr]"} efi= [EFI] - Format: { "old_map", "nochunk", "noruntime", "debug", - "nosoftreserve", "disable_early_pci_dma", - "no_disable_early_pci_dma" } - old_map [X86-64]: switch to the old ioremap-based EFI - runtime services mapping. [Needs CONFIG_X86_UV=y] + Format: { "debug", "disable_early_pci_dma", + "nochunk", "noruntime", "nosoftreserve", + "novamap", "no_disable_early_pci_dma", + "old_map" } + debug: enable misc debug output. + disable_early_pci_dma: disable the busmaster bit on all + PCI bridges while in the EFI boot stub. nochunk: disable reading files in "chunks" in the EFI boot stub, as chunking can cause problems with some firmware implementations. noruntime : disable EFI runtime services support - debug: enable misc debug output nosoftreserve: The EFI_MEMORY_SP (Specific Purpose) attribute may cause the kernel to reserve the memory range for a memory mapping driver to claim. Specify efi=nosoftreserve to disable this reservation and treat the memory by its base type (i.e. EFI_CONVENTIONAL_MEMORY / "System RAM"). - disable_early_pci_dma: Disable the busmaster bit on all - PCI bridges while in the EFI boot stub + novamap: do not call SetVirtualAddressMap(). no_disable_early_pci_dma: Leave the busmaster bit set on all PCI bridges while in the EFI boot stub + old_map [X86-64]: switch to the old ioremap-based EFI + runtime services mapping. [Needs CONFIG_X86_UV=y] efi_no_storage_paranoia [EFI; X86] Using this parameter you can use more than 50% of @@ -2786,7 +2808,7 @@ touchscreen support is not enabled in the mainstream kernel as of 2.6.30, a preliminary port can be found in the "bleeding edge" mini2440 support kernel at - http://repo.or.cz/w/linux-2.6/mini2440.git + https://repo.or.cz/w/linux-2.6/mini2440.git mitigations= [X86,PPC,S390,ARM64] Control optional mitigations for @@ -3079,6 +3101,8 @@ no5lvl [X86-64] Disable 5-level paging mode. Forces kernel to use 4-level paging instead. + nofsgsbase [X86] Disables FSGSBASE instructions. + no_console_suspend [HW] Never suspend the console Disable suspending of consoles during suspend and @@ -4038,6 +4062,14 @@ latencies, which will choose a value aligned with the appropriate hardware boundaries. + rcutree.rcu_min_cached_objs= [KNL] + Minimum number of objects which are cached and + maintained per one CPU. Object size is equal + to PAGE_SIZE. The cache allows to reduce the + pressure to page allocator, also it makes the + whole algorithm to behave better in low memory + condition. + rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. @@ -4258,6 +4290,20 @@ Set time (jiffies) between CPU-hotplug operations, or zero to disable CPU-hotplug testing. + rcutorture.read_exit= [KNL] + Set the number of read-then-exit kthreads used + to test the interaction of RCU updaters and + task-exit processing. + + rcutorture.read_exit_burst= [KNL] + The number of times in a given read-then-exit + episode that a set of read-then-exit kthreads + is spawned. + + rcutorture.read_exit_delay= [KNL] + The delay, in seconds, between successive + read-then-exit testing episodes. + rcutorture.shuffle_interval= [KNL] Set task-shuffle interval (s). Shuffling tasks allows some CPUs to go into dyntick-idle mode @@ -4407,6 +4453,45 @@ reboot_cpu is s[mp]#### with #### being the processor to be used for rebooting. + refscale.holdoff= [KNL] + Set test-start holdoff period. The purpose of + this parameter is to delay the start of the + test until boot completes in order to avoid + interference. + + refscale.loops= [KNL] + Set the number of loops over the synchronization + primitive under test. Increasing this number + reduces noise due to loop start/end overhead, + but the default has already reduced the per-pass + noise to a handful of picoseconds on ca. 2020 + x86 laptops. + + refscale.nreaders= [KNL] + Set number of readers. The default value of -1 + selects N, where N is roughly 75% of the number + of CPUs. A value of zero is an interesting choice. + + refscale.nruns= [KNL] + Set number of runs, each of which is dumped onto + the console log. + + refscale.readdelay= [KNL] + Set the read-side critical-section duration, + measured in microseconds. + + refscale.scale_type= [KNL] + Specify the read-protection implementation to test. + + refscale.shutdown= [KNL] + Shut down the system at the end of the performance + test. This defaults to 1 (shut it down) when + rcuperf is built into the kernel and to 0 (leave + it running) when rcuperf is built as a module. + + refscale.verbose= [KNL] + Enable additional printk() statements. + relax_domain_level= [KNL, SMP] Set scheduler's default relax_domain_level. See Documentation/admin-guide/cgroup-v1/cpusets.rst. @@ -5082,6 +5167,13 @@ Prevent the CPU-hotplug component of torturing until after init has spawned. + torture.ftrace_dump_at_shutdown= [KNL] + Dump the ftrace buffer at torture-test shutdown, + even if there were no errors. This can be a + very costly operation when many torture tests + are running concurrently, especially on systems + with rotating-rust storage. + tp720= [HW,PS2] tpm_suspend_pcr=[HW,TPM] diff --git a/Documentation/admin-guide/laptops/disk-shock-protection.rst b/Documentation/admin-guide/laptops/disk-shock-protection.rst index e97c5f78d8c3..22c7ec3e84cf 100644 --- a/Documentation/admin-guide/laptops/disk-shock-protection.rst +++ b/Documentation/admin-guide/laptops/disk-shock-protection.rst @@ -135,7 +135,7 @@ single project which, although still considered experimental, is fit for use. Please feel free to add projects that have been the victims of my ignorance. -- http://www.thinkwiki.org/wiki/HDAPS +- https://www.thinkwiki.org/wiki/HDAPS See this page for information about Linux support of the hard disk active protection system as implemented in IBM/Lenovo Thinkpads. diff --git a/Documentation/admin-guide/laptops/sonypi.rst b/Documentation/admin-guide/laptops/sonypi.rst index c6eaaf48f7c1..190da1234314 100644 --- a/Documentation/admin-guide/laptops/sonypi.rst +++ b/Documentation/admin-guide/laptops/sonypi.rst @@ -151,7 +151,7 @@ Bugs: different way to adjust the backlighting of the screen. There is a userspace utility to adjust the brightness on those models, which can be downloaded from - http://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2 + https://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2 - since all development was done by reverse engineering, there is *absolutely no guarantee* that this driver will not crash your diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst index 822907dcc845..5e477869df18 100644 --- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst +++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst @@ -50,6 +50,7 @@ detailed description): - WAN enable and disable - UWB enable and disable - LCD Shadow (PrivacyGuard) enable and disable + - Lap mode sensor A compatibility table by model and feature is maintained on the web site, http://ibm-acpi.sf.net/. I appreciate any success or failure @@ -904,7 +905,7 @@ temperatures: The mapping of thermal sensors to physical locations varies depending on system-board model (and thus, on ThinkPad model). -http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that +https://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that tries to track down these locations for various models. Most (newer?) models seem to follow this pattern: @@ -925,7 +926,7 @@ For the R51 (source: Thomas Gruber): - 3: Internal HDD For the T43, T43/p (source: Shmidoax/Thinkwiki.org) -http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p +https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p - 2: System board, left side (near PCMCIA slot), reported as HDAPS temp - 3: PCMCIA slot @@ -935,7 +936,7 @@ http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p - 11: Power regulator, underside of system board, below F2 key The A31 has a very atypical layout for the thermal sensors -(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) +(source: Milos Popovic, https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31) - 1: CPU - 2: Main Battery: main sensor @@ -1432,6 +1433,20 @@ The first command ensures the best viewing angle and the latter one turns on the feature, restricting the viewing angles. +DYTC Lapmode sensor +------------------ + +sysfs: dytc_lapmode + +Newer thinkpads and mobile workstations have the ability to determine if +the device is in deskmode or lapmode. This feature is used by user space +to decide if WWAN transmission can be increased to maximum power and is +also useful for understanding the different thermal modes available as +they differ between desk and lap mode. + +The property is read-only. If the platform doesn't have support the sysfs +class is not created. + EXPERIMENTAL: UWB ----------------- @@ -1470,6 +1485,23 @@ For more details about which buttons will appear depending on the mode, please review the laptop's user guide: http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf +Battery charge control +---------------------- + +sysfs attributes: +/sys/class/power_supply/BAT*/charge_control_{start,end}_threshold + +These two attributes are created for those batteries that are supported by the +driver. They enable the user to control the battery charge thresholds of the +given battery. Both values may be read and set. `charge_control_start_threshold` +accepts an integer between 0 and 99 (inclusive); this value represents a battery +percentage level, below which charging will begin. `charge_control_end_threshold` +accepts an integer between 1 and 100 (inclusive); this value represents a battery +percentage level, above which charging will stop. + +The exact semantics of the attributes may be found in +Documentation/ABI/testing/sysfs-class-power. + Multiple Commands, Module Parameters ------------------------------------ diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst index d973d469ffc4..cc8781b96b4d 100644 --- a/Documentation/admin-guide/md.rst +++ b/Documentation/admin-guide/md.rst @@ -426,6 +426,10 @@ All md devices contain: The accepted values when writing to this file are ``ppl`` and ``resync``, used to enable and disable PPL. + uuid + This indicates the UUID of the array in the following format: + xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + As component devices are added to an md array, they appear in the ``md`` directory as new directories named:: diff --git a/Documentation/admin-guide/media/building.rst b/Documentation/admin-guide/media/building.rst index c898e3a981c1..2d660b76caea 100644 --- a/Documentation/admin-guide/media/building.rst +++ b/Documentation/admin-guide/media/building.rst @@ -90,7 +90,7 @@ built as modules. Those GPU-specific drivers are selected via the ``Graphics support`` menu, under ``Device Drivers``. - When a GPU driver supports supports HDMI CEC, it will automatically + When a GPU driver supports HDMI CEC, it will automatically enable the CEC core support at the media subsystem. Media dependencies @@ -244,7 +244,7 @@ functionality. If you have an hybrid card, you may need to enable both ``Analog TV`` and ``Digital TV`` at the menu. -When using this option, the defaults for the the media support core +When using this option, the defaults for the media support core functionality are usually good enough to provide the basic functionality for the driver. Yet, you could manually enable some desired extra (optional) functionality using the settings under each of the following diff --git a/Documentation/admin-guide/mm/concepts.rst b/Documentation/admin-guide/mm/concepts.rst index c2531b14bf46..fa0974fbeae7 100644 --- a/Documentation/admin-guide/mm/concepts.rst +++ b/Documentation/admin-guide/mm/concepts.rst @@ -35,7 +35,7 @@ physical memory (demand paging) and provides a mechanism for the protection and controlled sharing of data between processes. With virtual memory, each and every memory access uses a virtual -address. When the CPU decodes the an instruction that reads (or +address. When the CPU decodes an instruction that reads (or writes) from (or to) the system memory, it translates the `virtual` address encoded in that instruction to a `physical` address that the memory controller can understand. diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index 5026e58826e2..015a5f7d7854 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -101,37 +101,48 @@ be specified in bytes with optional scale suffix [kKmMgG]. The default huge page size may be selected with the "default_hugepagesz=" boot parameter. Hugetlb boot command line parameter semantics -hugepagesz - Specify a huge page size. Used in conjunction with hugepages + +hugepagesz + Specify a huge page size. Used in conjunction with hugepages parameter to preallocate a number of huge pages of the specified size. Hence, hugepagesz and hugepages are typically specified in - pairs such as: + pairs such as:: + hugepagesz=2M hugepages=512 + hugepagesz can only be specified once on the command line for a specific huge page size. Valid huge page sizes are architecture dependent. -hugepages - Specify the number of huge pages to preallocate. This typically +hugepages + Specify the number of huge pages to preallocate. This typically follows a valid hugepagesz or default_hugepagesz parameter. However, if hugepages is the first or only hugetlb command line parameter it implicitly specifies the number of huge pages of default size to allocate. If the number of huge pages of default size is implicitly specified, it can not be overwritten by a hugepagesz,hugepages parameter pair for the default size. - For example, on an architecture with 2M default huge page size: + + For example, on an architecture with 2M default huge page size:: + hugepages=256 hugepagesz=2M hugepages=512 + will result in 256 2M huge pages being allocated and a warning message indicating that the hugepages=512 parameter is ignored. If a hugepages parameter is preceded by an invalid hugepagesz parameter, it will be ignored. -default_hugepagesz - Specify the default huge page size. This parameter can +default_hugepagesz + pecify the default huge page size. This parameter can only be specified once on the command line. default_hugepagesz can optionally be followed by the hugepages parameter to preallocate a specific number of huge pages of default size. The number of default sized huge pages to preallocate can also be implicitly specified as mentioned in the hugepages section above. Therefore, on an - architecture with 2M default huge page size: + architecture with 2M default huge page size:: + hugepages=256 default_hugepagesz=2M hugepages=256 hugepages=256 default_hugepagesz=2M + will all result in 256 2M huge pages being allocated. Valid default huge page size is architecture dependent. diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index 11db46448354..cd727cfc1b04 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -31,6 +31,7 @@ the Linux memory management. idle_page_tracking ksm memory-hotplug + nommu-mmap numa_memory_policy numaperf pagemap diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index 874eb0c77d34..97d816791aca 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -9,7 +9,7 @@ Overview KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y, added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation, -and http://lwn.net/Articles/306704/ and http://lwn.net/Articles/330589/ +and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/ KSM was originally developed for use with KVM (where it was known as Kernel Shared Memory), to fit more virtual machines into physical memory, @@ -52,7 +52,7 @@ with EAGAIN, but more probably arousing the Out-Of-Memory killer. If KSM is not configured into the running kernel, madvise MADV_MERGEABLE and MADV_UNMERGEABLE simply fail with EINVAL. If the running kernel was built with CONFIG_KSM=y, those calls will normally succeed: even if the -the KSM daemon is not currently running, MADV_MERGEABLE still registers +KSM daemon is not currently running, MADV_MERGEABLE still registers the range for whenever the KSM daemon is started; even if the range cannot contain any pages which KSM could actually merge; even if MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE. diff --git a/Documentation/nommu-mmap.txt b/Documentation/admin-guide/mm/nommu-mmap.rst similarity index 100% rename from Documentation/nommu-mmap.txt rename to Documentation/admin-guide/mm/nommu-mmap.rst diff --git a/Documentation/admin-guide/mm/numaperf.rst b/Documentation/admin-guide/mm/numaperf.rst index a80c3c37226e..4d69ef1de830 100644 --- a/Documentation/admin-guide/mm/numaperf.rst +++ b/Documentation/admin-guide/mm/numaperf.rst @@ -129,7 +129,7 @@ will create the following directory:: /sys/devices/system/node/nodeX/memory_side_cache/ -If that directory is not present, the system either does not not provide +If that directory is not present, the system either does not provide a memory-side cache, or that information is not accessible to the kernel. The attributes for each level of cache is provided under its cache diff --git a/Documentation/admin-guide/nfs/nfs-client.rst b/Documentation/admin-guide/nfs/nfs-client.rst index c4b777c7584b..6adb6457bc69 100644 --- a/Documentation/admin-guide/nfs/nfs-client.rst +++ b/Documentation/admin-guide/nfs/nfs-client.rst @@ -65,8 +65,8 @@ migrated onto another server by means of the special "fs_locations" attribute. See `RFC3530 Section 6: Filesystem Migration and Replication`_ and `Implementation Guide for Referrals in NFSv4`_. -.. _RFC3530 Section 6\: Filesystem Migration and Replication: http://tools.ietf.org/html/rfc3530#section-6 -.. _Implementation Guide for Referrals in NFSv4: http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 +.. _RFC3530 Section 6\: Filesystem Migration and Replication: https://tools.ietf.org/html/rfc3530#section-6 +.. _Implementation Guide for Referrals in NFSv4: https://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 The fs_locations information can take the form of either an ip address and a path, or a DNS hostname and a path. The latter requires the NFS client to diff --git a/Documentation/admin-guide/nfs/nfs-rdma.rst b/Documentation/admin-guide/nfs/nfs-rdma.rst index ef0f3678b1fb..f137485f8bde 100644 --- a/Documentation/admin-guide/nfs/nfs-rdma.rst +++ b/Documentation/admin-guide/nfs/nfs-rdma.rst @@ -65,7 +65,7 @@ use with NFS/RDMA. If the version is less than 1.1.2 or the command does not exist, you should install the latest version of nfs-utils. - Download the latest package from: http://www.kernel.org/pub/linux/utils/nfs + Download the latest package from: https://www.kernel.org/pub/linux/utils/nfs Uncompress the package and follow the installation instructions. diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst index c6772075c80c..135218f33394 100644 --- a/Documentation/admin-guide/nfs/nfsroot.rst +++ b/Documentation/admin-guide/nfs/nfsroot.rst @@ -264,7 +264,7 @@ They depend on various facilities being available: access to the floppy drive device, /dev/fd0 For more information on syslinux, including how to create bootdisks - for prebuilt kernels, see http://syslinux.zytor.com/ + for prebuilt kernels, see https://syslinux.zytor.com/ .. note:: Previously it was possible to write a kernel directly to @@ -292,7 +292,7 @@ They depend on various facilities being available: cdrecord dev=ATAPI:1,0,0 arch/x86/boot/image.iso For more information on isolinux, including how to create bootdisks - for prebuilt kernels, see http://syslinux.zytor.com/ + for prebuilt kernels, see https://syslinux.zytor.com/ - Using LILO @@ -346,7 +346,7 @@ They depend on various facilities being available: see Documentation/admin-guide/serial-console.rst for more information. For more information on isolinux, including how to create bootdisks - for prebuilt kernels, see http://syslinux.zytor.com/ + for prebuilt kernels, see https://syslinux.zytor.com/ diff --git a/Documentation/admin-guide/nfs/pnfs-block-server.rst b/Documentation/admin-guide/nfs/pnfs-block-server.rst index b00a2e705cc4..20fe9f5117fe 100644 --- a/Documentation/admin-guide/nfs/pnfs-block-server.rst +++ b/Documentation/admin-guide/nfs/pnfs-block-server.rst @@ -8,7 +8,7 @@ to handling all the metadata access to the NFS export also hands out layouts to the clients to directly access the underlying block devices that are shared with the client. -To use pNFS block layouts with with the Linux NFS server the exported file +To use pNFS block layouts with the Linux NFS server the exported file system needs to support the pNFS block layouts (currently just XFS), and the file system must sit on shared storage (typically iSCSI) that is accessible to the clients in addition to the MDS. As of now the file system needs to diff --git a/Documentation/admin-guide/nfs/pnfs-scsi-server.rst b/Documentation/admin-guide/nfs/pnfs-scsi-server.rst index d2f6ee558071..b2eec2288329 100644 --- a/Documentation/admin-guide/nfs/pnfs-scsi-server.rst +++ b/Documentation/admin-guide/nfs/pnfs-scsi-server.rst @@ -9,7 +9,7 @@ which in addition to handling all the metadata access to the NFS export, also hands out layouts to the clients so that they can directly access the underlying SCSI LUNs that are shared with the client. -To use pNFS SCSI layouts with with the Linux NFS server, the exported file +To use pNFS SCSI layouts with the Linux NFS server, the exported file system needs to support the pNFS SCSI layouts (currently just XFS), and the file system must sit on a SCSI LUN that is accessible to the clients in addition to the MDS. As of now the file system needs to sit directly on the diff --git a/Documentation/admin-guide/perf/arm-ccn.rst b/Documentation/admin-guide/perf/arm-ccn.rst index 832b0c64023a..f62f7fe50eba 100644 --- a/Documentation/admin-guide/perf/arm-ccn.rst +++ b/Documentation/admin-guide/perf/arm-ccn.rst @@ -27,7 +27,7 @@ Crosspoint PMU events require "xp" (index), "bus" (bus number) and "vc" (virtual channel ID). Crosspoint watchpoint-based events (special "event" value 0xfe) -require "xp" and "vc" as as above plus "port" (device port index), +require "xp" and "vc" as above plus "port" (device port index), "dir" (transmit/receive direction), comparator values ("cmp_l" and "cmp_h") and "mask", being index of the comparator mask. diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst index 0c74a7784964..368e612145d2 100644 --- a/Documentation/admin-guide/pm/cpufreq.rst +++ b/Documentation/admin-guide/pm/cpufreq.rst @@ -147,9 +147,9 @@ CPUs in it. The next major initialization step for a new policy object is to attach a scaling governor to it (to begin with, that is the default scaling governor -determined by the kernel configuration, but it may be changed later -via ``sysfs``). First, a pointer to the new policy object is passed to the -governor's ``->init()`` callback which is expected to initialize all of the +determined by the kernel command line or configuration, but it may be changed +later via ``sysfs``). First, a pointer to the new policy object is passed to +the governor's ``->init()`` callback which is expected to initialize all of the data structures necessary to handle the given policy and, possibly, to add a governor ``sysfs`` interface to it. Next, the governor is started by invoking its ``->start()`` callback. diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst index b2ca601c21c6..219f1359aac7 100644 --- a/Documentation/admin-guide/pm/intel-speed-select.rst +++ b/Documentation/admin-guide/pm/intel-speed-select.rst @@ -114,7 +114,7 @@ base performance profile (which is performance level 0). Lock/Unlock status ~~~~~~~~~~~~~~~~~~ -Even if there are multiple performance profiles, it is possible that that they +Even if there are multiple performance profiles, it is possible that they are locked. If they are locked, users cannot issue a command to change the performance state. It is possible that there is a BIOS setup to unlock or check with your system vendor. @@ -883,7 +883,7 @@ To enable Intel(R) SST-TF, execute:: enable:success In this case, the option "-a" is optional. If set, it enables Intel(R) SST-TF -feature and also sets the CPUs to high and and low priority using Intel Speed +feature and also sets the CPUs to high and low priority using Intel Speed Select Technology Core Power (Intel(R) SST-CP) features. The CPU numbers passed with "-c" arguments are marked as high priority, including its siblings. diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index 39d80bc29ccd..9db924904d2c 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -431,6 +431,17 @@ argument is passed to the kernel in the command line. supported in the current configuration, writes to this attribute will fail with an appropriate error. +``energy_efficiency`` + This attribute is only present on platforms, which have CPUs matching + Kaby Lake or Coffee Lake desktop CPU model. By default + energy efficiency optimizations are disabled on these CPU models in HWP + mode by this driver. Enabling energy efficiency may limit maximum + operating frequency in both HWP and non HWP mode. In non HWP mode, + optimizations are done only in the turbo frequency range. In HWP mode, + optimizations are done in the entire frequency range. Setting this + attribute to "1" enables energy efficiency optimizations and setting + to "0" disables energy efficiency optimizations. + Interpretation of Policy Attributes ----------------------------------- @@ -554,7 +565,11 @@ somewhere between the two extremes: Strings written to the ``energy_performance_preference`` attribute are internally translated to integer values written to the processor's Energy-Performance Preference (EPP) knob (if supported) or its -Energy-Performance Bias (EPB) knob. +Energy-Performance Bias (EPB) knob. It is also possible to write a positive +integer value between 0 to 255, if the EPP feature is present. If the EPP +feature is not present, writing integer value to this attribute is not +supported. In this case, user can use + "/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface. [Note that tasks may by migrated from one CPU to another by the scheduler's load-balancing algorithm and if different energy vs performance hints are @@ -708,7 +723,7 @@ core (for the policies with other scaling governors). The ``ftrace`` interface can be used for low-level diagnostics of ``intel_pstate``. For example, to check how often the function to set a -P-state is called, the ``ftrace`` filter can be set to to +P-state is called, the ``ftrace`` filter can be set to :c:func:`intel_pstate_set_pstate`:: # cd /sys/kernel/debug/tracing/ diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst index dcd6c93c7aac..c32eb786201c 100644 --- a/Documentation/admin-guide/security-bugs.rst +++ b/Documentation/admin-guide/security-bugs.rst @@ -21,11 +21,18 @@ understand and fix the security vulnerability. As it is with any bug, the more information provided the easier it will be to diagnose and fix. Please review the procedure outlined in -admin-guide/reporting-bugs.rst if you are unclear about what +:doc:`reporting-bugs` if you are unclear about what information is helpful. Any exploit code is very helpful and will not be released without consent from the reporter unless it has already been made public. +Please send plain text emails without attachments where possible. +It is much harder to have a context-quoted discussion about a complex +issue if all the details are hidden away in attachments. Think of it like a +:doc:`regular patch submission <../process/submitting-patches>` +(even if you don't have a patch yet): describe the problem and impact, list +reproduction steps, and follow it with a proposed fix, all in plain text. + Disclosure and embargoed information ------------------------------------ diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst index 2a45119e3331..f48277a0a850 100644 --- a/Documentation/admin-guide/sysctl/fs.rst +++ b/Documentation/admin-guide/sysctl/fs.rst @@ -261,7 +261,7 @@ directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see: -http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp +https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp When set to "0", symlink following behavior is unrestricted. diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 83acf5025488..2ae9669eb22c 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -235,7 +235,7 @@ This toggle indicates whether unprivileged users are prevented from using ``dmesg(8)`` to view messages from the kernel's log buffer. When ``dmesg_restrict`` is set to 0 there are no restrictions. -When ``dmesg_restrict`` is set set to 1, users must have +When ``dmesg_restrict`` is set to 1, users must have ``CAP_SYSLOG`` to use ``dmesg(8)``. The kernel config option ``CONFIG_SECURITY_DMESG_RESTRICT`` sets the @@ -335,8 +335,8 @@ Path for the hotplug policy agent. Default value is "``/sbin/hotplug``". -hung_task_all_cpu_backtrace: -================ +hung_task_all_cpu_backtrace +=========================== If this option is set, the kernel will send an NMI to all CPUs to dump their backtraces when a hung task is detected. This file shows up if @@ -646,8 +646,8 @@ rate for each task. scanned for a given scan. -oops_all_cpu_backtrace: -================ +oops_all_cpu_backtrace +====================== If this option is set, the kernel will send an NMI to all CPUs to dump their backtraces when an oops event occurs. It should be used as a last @@ -996,6 +996,38 @@ pty See Documentation/filesystems/devpts.rst. +random +====== + +This is a directory, with the following entries: + +* ``boot_id``: a UUID generated the first time this is retrieved, and + unvarying after that; + +* ``entropy_avail``: the pool's entropy count, in bits; + +* ``poolsize``: the entropy pool size, in bits; + +* ``urandom_min_reseed_secs``: obsolete (used to determine the minimum + number of seconds between urandom pool reseeding). + +* ``uuid``: a UUID generated every time this is retrieved (this can + thus be used to generate UUIDs at will); + +* ``write_wakeup_threshold``: when the entropy count drops below this + (as a number of bits), processes waiting to write to ``/dev/random`` + are woken up. + +If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH`` +defined, these additional entries are present: + +* ``add_interrupt_avg_cycles``: the average number of cycles between + interrupts used to feed the pool; + +* ``add_interrupt_avg_deviation``: the standard deviation seen on the + number of cycles between interrupts used to feed the pool. + + randomize_va_space ================== @@ -1062,6 +1094,60 @@ Enables/disables scheduler statistics. Enabling this feature incurs a small amount of overhead in the scheduler but is useful for debugging and performance tuning. +sched_util_clamp_min: +===================== + +Max allowed *minimum* utilization. + +Default value is 1024, which is the maximum possible value. + +It means that any requested uclamp.min value cannot be greater than +sched_util_clamp_min, i.e., it is restricted to the range +[0:sched_util_clamp_min]. + +sched_util_clamp_max: +===================== + +Max allowed *maximum* utilization. + +Default value is 1024, which is the maximum possible value. + +It means that any requested uclamp.max value cannot be greater than +sched_util_clamp_max, i.e., it is restricted to the range +[0:sched_util_clamp_max]. + +sched_util_clamp_min_rt_default: +================================ + +By default Linux is tuned for performance. Which means that RT tasks always run +at the highest frequency and most capable (highest capacity) CPU (in +heterogeneous systems). + +Uclamp achieves this by setting the requested uclamp.min of all RT tasks to +1024 by default, which effectively boosts the tasks to run at the highest +frequency and biases them to run on the biggest CPU. + +This knob allows admins to change the default behavior when uclamp is being +used. In battery powered devices particularly, running at the maximum +capacity and frequency will increase energy consumption and shorten the battery +life. + +This knob is only effective for RT tasks which the user hasn't modified their +requested uclamp.min value via sched_setattr() syscall. + +This knob will not escape the range constraint imposed by sched_util_clamp_min +defined above. + +For example if + + sched_util_clamp_min_rt_default = 800 + sched_util_clamp_min = 600 + +Then the boost will be clamped to 600 because 800 is outside of the permissible +range of [0:600]. This could happen for instance if a powersave mode will +restrict all boosts temporarily by modifying sched_util_clamp_min. As soon as +this restriction is lifted, the requested sched_util_clamp_min_rt_default +will take effect. seccomp ======= diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index d46d5b7013c6..d997cc3c26d0 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -583,7 +583,7 @@ trimming of allocations is initiated. The default value is 1. -See Documentation/nommu-mmap.txt for more information. +See Documentation/admin-guide/mm/nommu-mmap.rst for more information. numa_zonelist_order diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index 71e9184a9079..abf804719890 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -38,7 +38,7 @@ either letters or blanks. In above example it looks like this:: Tainted: P W O -The meaning of those characters is explained in the table below. In tis case +The meaning of those characters is explained in the table below. In this case the kernel got tainted earlier because a proprietary Module (``P``) was loaded, a warning occurred (``W``), and an externally-built module was loaded (``O``). To decode other letters use the table below. @@ -61,7 +61,7 @@ this on the machine that had the statements in the logs that were quoted earlier * Proprietary module was loaded (#0) * Kernel issued warning (#9) * Externally-built ('out-of-tree') module was loaded (#12) - See Documentation/admin-guide/tainted-kernels.rst in the the Linux kernel or + See Documentation/admin-guide/tainted-kernels.rst in the Linux kernel or https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for a more details explanation of the various taint flags. Raw taint value as int/string: 4609/'P W O ' diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 10c4f0ce2ad0..613cb24c76c7 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -173,8 +173,8 @@ following ``udev`` rule:: ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1" -Upgrading NVM on Thunderbolt device or host -------------------------------------------- +Upgrading NVM on Thunderbolt device, host or retimer +---------------------------------------------------- Since most of the functionality is handled in firmware running on a host controller or a device, it is important that the firmware can be upgraded to the latest where possible bugs in it have been fixed. @@ -185,9 +185,10 @@ for some machines: `Thunderbolt Updates `_ -Before you upgrade firmware on a device or host, please make sure it is a -suitable upgrade. Failing to do that may render the device (or host) in a -state where it cannot be used properly anymore without special tools! +Before you upgrade firmware on a device, host or retimer, please make +sure it is a suitable upgrade. Failing to do that may render the device +in a state where it cannot be used properly anymore without special +tools! Host NVM upgrade on Apple Macs is not supported. diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst index ad911be5b5e9..f461d6c33534 100644 --- a/Documentation/admin-guide/xfs.rst +++ b/Documentation/admin-guide/xfs.rst @@ -133,7 +133,7 @@ When mounting an XFS filesystem, the following options are accepted. logbsize must be an integer multiple of the log stripe unit configured at **mkfs(8)** time. - The default value for for version 1 logs is 32768, while the + The default value for version 1 logs is 32768, while the default value for version 2 logs is MAX(32768, log_sunit). logdev=device and rtdev=device diff --git a/Documentation/arm/booting.rst b/Documentation/arm/booting.rst index 4babb6c6ae1e..a2263451dc2c 100644 --- a/Documentation/arm/booting.rst +++ b/Documentation/arm/booting.rst @@ -128,7 +128,7 @@ it. The recommended placement is in the first 16KiB of RAM. The boot loader must load a device tree image (dtb) into system ram at a 64bit aligned address and initialize it with the boot data. The -dtb format is documented in Documentation/devicetree/booting-without-of.txt. +dtb format is documented in Documentation/devicetree/booting-without-of.rst. The kernel will look for the dtb magic value of 0xd00dfeed at the dtb physical address to determine if a dtb has been passed instead of a tagged list. diff --git a/Documentation/arm64/acpi_object_usage.rst b/Documentation/arm64/acpi_object_usage.rst index d51b69dc624d..377e9d224db0 100644 --- a/Documentation/arm64/acpi_object_usage.rst +++ b/Documentation/arm64/acpi_object_usage.rst @@ -220,7 +220,7 @@ LPIT Signature Reserved (signature == "LPIT") x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor descriptions and power states on ARM platforms should use the DSDT and define processor container devices (_HID ACPI0010, Section 8.4, - and more specifically 8.4.3 and and 8.4.4). + and more specifically 8.4.3 and 8.4.4). MADT Section 5.2.12 (signature == "APIC") diff --git a/Documentation/arm64/arm-acpi.rst b/Documentation/arm64/arm-acpi.rst index 872dbbc73d4a..47ecb9930dde 100644 --- a/Documentation/arm64/arm-acpi.rst +++ b/Documentation/arm64/arm-acpi.rst @@ -273,7 +273,7 @@ only use the _DSD Device Properties UUID [5]: - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 - - http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf + - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf The UEFI Forum provides a mechanism for registering device properties [4] so that they may be used across all operating systems supporting ACPI. @@ -470,7 +470,7 @@ likely be willing to assist in submitting ECRs. Linux Code ---------- -Individual items specific to Linux on ARM, contained in the the Linux +Individual items specific to Linux on ARM, contained in the Linux source code, are in the list that follows: ACPI_OS_NAME diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst index 09cbb4ed2237..d9665d83c53a 100644 --- a/Documentation/arm64/index.rst +++ b/Documentation/arm64/index.rst @@ -14,6 +14,7 @@ ARM64 Architecture hugetlbpage legacy_instructions memory + perf pointer-authentication silicon-errata sve diff --git a/Documentation/arm64/perf.txt b/Documentation/arm64/perf.rst similarity index 95% rename from Documentation/arm64/perf.txt rename to Documentation/arm64/perf.rst index 0d6a7d87d49e..9c76a97baf28 100644 --- a/Documentation/arm64/perf.txt +++ b/Documentation/arm64/perf.rst @@ -1,8 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== Perf Event Attributes ===================== -Author: Andrew Murray -Date: 2019-03-06 +:Author: Andrew Murray +:Date: 2019-03-06 exclude_user ------------ diff --git a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst index bfd55f468258..03137154299e 100644 --- a/Documentation/arm64/sve.rst +++ b/Documentation/arm64/sve.rst @@ -494,7 +494,7 @@ Appendix B. ARMv8-A FP/SIMD programmer's model Note: This section is for information only and not intended to be complete or to replace any architectural specification. -Refer to [4] for for more information. +Refer to [4] for more information. ARMv8-A defines the following floating-point / SIMD register state: diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index 0ab747e0d5ac..0f1fdedf36bb 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -85,21 +85,21 @@ smp_store_release() respectively. Therefore, if you find yourself only using the Non-RMW operations of atomic_t, you do not in fact need atomic_t at all and are doing it wrong. -A subtle detail of atomic_set{}() is that it should be observable to the RMW -ops. That is: +A note for the implementation of atomic_set{}() is that it must not break the +atomicity of the RMW ops. That is: - C atomic-set + C Atomic-RMW-ops-are-atomic-WRT-atomic_set { - atomic_set(v, 1); + atomic_t v = ATOMIC_INIT(1); + } + + P0(atomic_t *v) + { + (void)atomic_add_unless(v, 1, 0); } P1(atomic_t *v) - { - atomic_add_unless(v, 1, 0); - } - - P2(atomic_t *v) { atomic_set(v, 0); } @@ -233,19 +233,19 @@ as well. Similarly, something like: is an ACQUIRE pattern (though very much not typical), but again the barrier is strictly stronger than ACQUIRE. As illustrated: - C strong-acquire + C Atomic-RMW+mb__after_atomic-is-stronger-than-acquire { } - P1(int *x, atomic_t *y) + P0(int *x, atomic_t *y) { r0 = READ_ONCE(*x); smp_rmb(); r1 = atomic_read(y); } - P2(int *x, atomic_t *y) + P1(int *x, atomic_t *y) { atomic_inc(y); smp_mb__after_atomic(); @@ -253,14 +253,14 @@ strictly stronger than ACQUIRE. As illustrated: } exists - (r0=1 /\ r1=0) + (0:r0=1 /\ 0:r1=0) This should not happen; but a hypothetical atomic_inc_acquire() -- (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome, because it would not order the W part of the RMW against the following WRITE_ONCE. Thus: - P1 P2 + P0 P1 t = LL.acq *y (0) t++; diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst index b964796ec9c7..1d4d71e391af 100644 --- a/Documentation/block/biodoc.rst +++ b/Documentation/block/biodoc.rst @@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to Documentation/DMA-API-HOWTO.txt for a discussion +Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. @@ -1036,7 +1036,7 @@ Now the generic block layer performs partition-remapping early and thus provides drivers with a sector number relative to whole device, rather than having to take partition number into account in order to arrive at the true sector number. The routine blk_partition_remap() is invoked by -generic_make_request even before invoking the queue specific make_request_fn, +submit_bio_noacct even before invoking the queue specific ->submit_bio, so the i/o scheduler also gets to operate on whole disk sector numbers. This should typically not require changes to block drivers, it just never gets to invoke its own partition sector offset calculations since all bios diff --git a/Documentation/block/blk-mq.rst b/Documentation/block/blk-mq.rst new file mode 100644 index 000000000000..88c56afcb070 --- /dev/null +++ b/Documentation/block/blk-mq.rst @@ -0,0 +1,153 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================ +Multi-Queue Block IO Queueing Mechanism (blk-mq) +================================================ + +The Multi-Queue Block IO Queueing Mechanism is an API to enable fast storage +devices to achieve a huge number of input/output operations per second (IOPS) +through queueing and submitting IO requests to block devices simultaneously, +benefiting from the parallelism offered by modern storage devices. + +Introduction +============ + +Background +---------- + +Magnetic hard disks have been the de facto standard from the beginning of the +development of the kernel. The Block IO subsystem aimed to achieve the best +performance possible for those devices with a high penalty when doing random +access, and the bottleneck was the mechanical moving parts, a lot slower than +any layer on the storage stack. One example of such optimization technique +involves ordering read/write requests according to the current position of the +hard disk head. + +However, with the development of Solid State Drives and Non-Volatile Memories +without mechanical parts nor random access penalty and capable of performing +high parallel access, the bottleneck of the stack had moved from the storage +device to the operating system. In order to take advantage of the parallelism +in those devices' design, the multi-queue mechanism was introduced. + +The former design had a single queue to store block IO requests with a single +lock. That did not scale well in SMP systems due to dirty data in cache and the +bottleneck of having a single lock for multiple processors. This setup also +suffered with congestion when different processes (or the same process, moving +to different CPUs) wanted to perform block IO. Instead of this, the blk-mq API +spawns multiple queues with individual entry points local to the CPU, removing +the need for a lock. A deeper explanation on how this works is covered in the +following section (`Operation`_). + +Operation +--------- + +When the userspace performs IO to a block device (reading or writing a file, +for instance), blk-mq takes action: it will store and manage IO requests to +the block device, acting as middleware between the userspace (and a file +system, if present) and the block device driver. + +blk-mq has two group of queues: software staging queues and hardware dispatch +queues. When the request arrives at the block layer, it will try the shortest +path possible: send it directly to the hardware queue. However, there are two +cases that it might not do that: if there's an IO scheduler attached at the +layer or if we want to try to merge requests. In both cases, requests will be +sent to the software queue. + +Then, after the requests are processed by software queues, they will be placed +at the hardware queue, a second stage queue were the hardware has direct access +to process those requests. However, if the hardware does not have enough +resources to accept more requests, blk-mq will places requests on a temporary +queue, to be sent in the future, when the hardware is able. + +Software staging queues +~~~~~~~~~~~~~~~~~~~~~~~ + +The block IO subsystem adds requests in the software staging queues +(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent +directly to the driver. A request is one or more BIOs. They arrived at the +block layer through the data structure struct :c:type:`bio`. The block layer +will then build a new structure from it, the struct :c:type:`request` that will +be used to communicate with the device driver. Each queue has its own lock and +the number of queues is defined by a per-CPU or per-node basis. + +The staging queue can be used to merge requests for adjacent sectors. For +instance, requests for sector 3-6, 6-7, 7-9 can become one request for 3-9. +Even if random access to SSDs and NVMs have the same time of response compared +to sequential access, grouped requests for sequential access decreases the +number of individual requests. This technique of merging requests is called +plugging. + +Along with that, the requests can be reordered to ensure fairness of system +resources (e.g. to ensure that no application suffers from starvation) and/or to +improve IO performance, by an IO scheduler. + +IO Schedulers +^^^^^^^^^^^^^ + +There are several schedulers implemented by the block layer, each one following +a heuristic to improve the IO performance. They are "pluggable" (as in plug +and play), in the sense of they can be selected at run time using sysfs. You +can read more about Linux's IO schedulers `here +`_. The scheduling +happens only between requests in the same queue, so it is not possible to merge +requests from different queues, otherwise there would be cache trashing and a +need to have a lock for each queue. After the scheduling, the requests are +eligible to be sent to the hardware. One of the possible schedulers to be +selected is the NONE scheduler, the most straightforward one. It will just +place requests on whatever software queue the process is running on, without +any reordering. When the device starts processing requests in the hardware +queue (a.k.a. run the hardware queue), the software queues mapped to that +hardware queue will be drained in sequence according to their mapping. + +Hardware dispatch queues +~~~~~~~~~~~~~~~~~~~~~~~~ + +The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct +used by device drivers to map the device submission queues (or device DMA ring +buffer), and are the last step of the block layer submission code before the +low level device driver taking ownership of the request. To run this queue, the +block layer removes requests from the associated software queues and tries to +dispatch to the hardware. + +If it's not possible to send the requests directly to hardware, they will be +added to a linked list (:c:type:`hctx->dispatch`) of requests. Then, +next time the block layer runs a queue, it will send the requests laying at the +:c:type:`dispatch` list first, to ensure a fairness dispatch with those +requests that were ready to be sent first. The number of hardware queues +depends on the number of hardware contexts supported by the hardware and its +device driver, but it will not be more than the number of cores of the system. +There is no reordering at this stage, and each software queue has a set of +hardware queues to send requests for. + +.. note:: + + Neither the block layer nor the device protocols guarantee + the order of completion of requests. This must be handled by + higher layers, like the filesystem. + +Tag-based completion +~~~~~~~~~~~~~~~~~~~~ + +In order to indicate which request has been completed, every request is +identified by an integer, ranging from 0 to the dispatch queue size. This tag +is generated by the block layer and later reused by the device driver, removing +the need to create a redundant identifier. When a request is completed in the +drive, the tag is sent back to the block layer to notify it of the finalization. +This removes the need to do a linear search to find out which IO has been +completed. + +Further reading +--------------- + +- `Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems `_ + +- `NOOP scheduler `_ + +- `Null block device driver `_ + +Source code documentation +========================= + +.. kernel-doc:: include/linux/blk-mq.h + +.. kernel-doc:: block/blk-mq.c diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst index 026addfc69bc..86dcf7159f99 100644 --- a/Documentation/block/index.rst +++ b/Documentation/block/index.rst @@ -10,6 +10,7 @@ Block bfq-iosched biodoc biovecs + blk-mq capability cmdline-partition data-integrity diff --git a/Documentation/block/pr.rst b/Documentation/block/pr.rst index 30ea1c2e39eb..c893d6da8e04 100644 --- a/Documentation/block/pr.rst +++ b/Documentation/block/pr.rst @@ -9,7 +9,7 @@ access to block devices to specific initiators in a shared storage setup. This document gives a general overview of the support ioctl commands. -For a more detailed reference please refer the the SCSI Primary +For a more detailed reference please refer to the SCSI Primary Commands standard, specifically the section on Reservations and the "PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands. diff --git a/Documentation/block/queue-sysfs.rst b/Documentation/block/queue-sysfs.rst index 6a8513af9201..f261a5c84170 100644 --- a/Documentation/block/queue-sysfs.rst +++ b/Documentation/block/queue-sysfs.rst @@ -117,6 +117,20 @@ Maximum number of elements in a DMA scatter/gather list with integrity data that will be submitted by the block layer core to the associated block driver. +max_active_zones (RO) +--------------------- +For zoned block devices (zoned attribute indicating "host-managed" or +"host-aware"), the sum of zones belonging to any of the zone states: +EXPLICIT OPEN, IMPLICIT OPEN or CLOSED, is limited by this value. +If this value is 0, there is no limit. + +max_open_zones (RO) +------------------- +For zoned block devices (zoned attribute indicating "host-managed" or +"host-aware"), the sum of zones belonging to any of the zone states: +EXPLICIT OPEN or IMPLICIT OPEN, is limited by this value. +If this value is 0, there is no limit. + max_sectors_kb (RW) ------------------- This is the maximum number of kilobytes that the block layer will allow diff --git a/Documentation/block/writeback_cache_control.rst b/Documentation/block/writeback_cache_control.rst index 2c752c57c14c..b208488d0aae 100644 --- a/Documentation/block/writeback_cache_control.rst +++ b/Documentation/block/writeback_cache_control.rst @@ -47,7 +47,7 @@ the Forced Unit Access is implemented. The REQ_PREFLUSH and REQ_FUA flags may both be set on a single bio. -Implementation details for make_request_fn based block drivers +Implementation details for bio based block drivers -------------------------------------------------------------- These drivers will always see the REQ_PREFLUSH and REQ_FUA bits as they sit diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 0b3db91dc100..a26aa1b9b259 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -643,5 +643,6 @@ when: .. _selftests: ../../tools/testing/selftests/bpf/ .. _Documentation/dev-tools/kselftest.rst: https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html +.. _Documentation/bpf/btf.rst: btf.rst Happy BPF hacking! diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 4d565d202ce3..b5361b8621c9 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -691,6 +691,42 @@ kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the beginning of section (``btf_ext_info_sec->sec_name_off``). +4.2 .BTF_ids section +==================== + +The .BTF_ids section encodes BTF ID values that are used within the kernel. + +This section is created during the kernel compilation with the help of +macros defined in ``include/linux/btf_ids.h`` header file. Kernel code can +use them to create lists and sets (sorted lists) of BTF ID values. + +The ``BTF_ID_LIST`` and ``BTF_ID`` macros define unsorted list of BTF ID values, +with following syntax:: + + BTF_ID_LIST(list) + BTF_ID(type1, name1) + BTF_ID(type2, name2) + +resulting in following layout in .BTF_ids section:: + + __BTF_ID__type1__name1__1: + .zero 4 + __BTF_ID__type2__name2__2: + .zero 4 + +The ``u32 list[];`` variable is defined to access the list. + +The ``BTF_ID_UNUSED`` macro defines 4 zero bytes. It's used when we +want to define unused entry in BTF_ID_LIST, like:: + + BTF_ID_LIST(bpf_skb_output_btf_ids) + BTF_ID(struct, sk_buff) + BTF_ID_UNUSED + BTF_ID(struct, task_struct) + +All the BTF ID lists and sets are compiled in the .BTF_ids section and +resolved during the linking phase of kernel build by ``resolve_btfids`` tool. + 5. Using BTF ************ diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 38b4db8be7a2..d46429be334e 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -5,10 +5,10 @@ BPF Documentation This directory contains documentation for the BPF (Berkeley Packet Filter) facility, with a focus on the extended BPF version (eBPF). -This kernel side documentation is still work in progress. The main +This kernel side documentation is still work in progress. The main textual documentation is (for historical reasons) described in -`Documentation/networking/filter.rst`_, which describe both classical -and extended BPF instruction-set. +:ref:`networking-filter`, which describe both classical and extended +BPF instruction-set. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. @@ -48,6 +48,15 @@ Program types bpf_lsm +Map types +========= + +.. toctree:: + :maxdepth: 1 + + map_cgroup_storage + + Testing and debugging BPF ========================= @@ -58,8 +67,16 @@ Testing and debugging BPF s390 +Other +===== + +.. toctree:: + :maxdepth: 1 + + ringbuf + .. Links: -.. _Documentation/networking/filter.rst: ../networking/filter.txt +.. _networking-filter: ../networking/filter.rst .. _man-pages: https://www.kernel.org/doc/man-pages/ -.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html -.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/ +.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html +.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/ diff --git a/Documentation/bpf/map_cgroup_storage.rst b/Documentation/bpf/map_cgroup_storage.rst new file mode 100644 index 000000000000..cab9543017bf --- /dev/null +++ b/Documentation/bpf/map_cgroup_storage.rst @@ -0,0 +1,169 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. Copyright (C) 2020 Google LLC. + +=========================== +BPF_MAP_TYPE_CGROUP_STORAGE +=========================== + +The ``BPF_MAP_TYPE_CGROUP_STORAGE`` map type represents a local fix-sized +storage. It is only available with ``CONFIG_CGROUP_BPF``, and to programs that +attach to cgroups; the programs are made available by the same Kconfig. The +storage is identified by the cgroup the program is attached to. + +The map provide a local storage at the cgroup that the BPF program is attached +to. It provides a faster and simpler access than the general purpose hash +table, which performs a hash table lookups, and requires user to track live +cgroups on their own. + +This document describes the usage and semantics of the +``BPF_MAP_TYPE_CGROUP_STORAGE`` map type. Some of its behaviors was changed in +Linux 5.9 and this document will describe the differences. + +Usage +===== + +The map uses key of type of either ``__u64 cgroup_inode_id`` or +``struct bpf_cgroup_storage_key``, declared in ``linux/bpf.h``:: + + struct bpf_cgroup_storage_key { + __u64 cgroup_inode_id; + __u32 attach_type; + }; + +``cgroup_inode_id`` is the inode id of the cgroup directory. +``attach_type`` is the the program's attach type. + +Linux 5.9 added support for type ``__u64 cgroup_inode_id`` as the key type. +When this key type is used, then all attach types of the particular cgroup and +map will share the same storage. Otherwise, if the type is +``struct bpf_cgroup_storage_key``, then programs of different attach types +be isolated and see different storages. + +To access the storage in a program, use ``bpf_get_local_storage``:: + + void *bpf_get_local_storage(void *map, u64 flags) + +``flags`` is reserved for future use and must be 0. + +There is no implicit synchronization. Storages of ``BPF_MAP_TYPE_CGROUP_STORAGE`` +can be accessed by multiple programs across different CPUs, and user should +take care of synchronization by themselves. The bpf infrastructure provides +``struct bpf_spin_lock`` to synchronize the storage. See +``tools/testing/selftests/bpf/progs/test_spin_lock.c``. + +Examples +======== + +Usage with key type as ``struct bpf_cgroup_storage_key``:: + + #include + + struct { + __uint(type, BPF_MAP_TYPE_CGROUP_STORAGE); + __type(key, struct bpf_cgroup_storage_key); + __type(value, __u32); + } cgroup_storage SEC(".maps"); + + int program(struct __sk_buff *skb) + { + __u32 *ptr = bpf_get_local_storage(&cgroup_storage, 0); + __sync_fetch_and_add(ptr, 1); + + return 0; + } + +Userspace accessing map declared above:: + + #include + #include + + __u32 map_lookup(struct bpf_map *map, __u64 cgrp, enum bpf_attach_type type) + { + struct bpf_cgroup_storage_key = { + .cgroup_inode_id = cgrp, + .attach_type = type, + }; + __u32 value; + bpf_map_lookup_elem(bpf_map__fd(map), &key, &value); + // error checking omitted + return value; + } + +Alternatively, using just ``__u64 cgroup_inode_id`` as key type:: + + #include + + struct { + __uint(type, BPF_MAP_TYPE_CGROUP_STORAGE); + __type(key, __u64); + __type(value, __u32); + } cgroup_storage SEC(".maps"); + + int program(struct __sk_buff *skb) + { + __u32 *ptr = bpf_get_local_storage(&cgroup_storage, 0); + __sync_fetch_and_add(ptr, 1); + + return 0; + } + +And userspace:: + + #include + #include + + __u32 map_lookup(struct bpf_map *map, __u64 cgrp, enum bpf_attach_type type) + { + __u32 value; + bpf_map_lookup_elem(bpf_map__fd(map), &cgrp, &value); + // error checking omitted + return value; + } + +Semantics +========= + +``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE`` is a variant of this map type. This +per-CPU variant will have different memory regions for each CPU for each +storage. The non-per-CPU will have the same memory region for each storage. + +Prior to Linux 5.9, the lifetime of a storage is precisely per-attachment, and +for a single ``CGROUP_STORAGE`` map, there can be at most one program loaded +that uses the map. A program may be attached to multiple cgroups or have +multiple attach types, and each attach creates a fresh zeroed storage. The +storage is freed upon detach. + +There is a one-to-one association between the map of each type (per-CPU and +non-per-CPU) and the BPF program during load verification time. As a result, +each map can only be used by one BPF program and each BPF program can only use +one storage map of each type. Because of map can only be used by one BPF +program, sharing of this cgroup's storage with other BPF programs were +impossible. + +Since Linux 5.9, storage can be shared by multiple programs. When a program is +attached to a cgroup, the kernel would create a new storage only if the map +does not already contain an entry for the cgroup and attach type pair, or else +the old storage is reused for the new attachment. If the map is attach type +shared, then attach type is simply ignored during comparison. Storage is freed +only when either the map or the cgroup attached to is being freed. Detaching +will not directly free the storage, but it may cause the reference to the map +to reach zero and indirectly freeing all storage in the map. + +The map is not associated with any BPF program, thus making sharing possible. +However, the BPF program can still only associate with one map of each type +(per-CPU and non-per-CPU). A BPF program cannot use more than one +``BPF_MAP_TYPE_CGROUP_STORAGE`` or more than one +``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE``. + +In all versions, userspace may use the the attach parameters of cgroup and +attach type pair in ``struct bpf_cgroup_storage_key`` as the key to the BPF map +APIs to read or update the storage for a given attachment. For Linux 5.9 +attach type shared storages, only the first value in the struct, cgroup inode +id, is used during comparison, so userspace may just specify a ``__u64`` +directly. + +The storage is bound at attach time. Even if the program is attached to parent +and triggers in child, the storage still belongs to the parent. + +Userspace cannot create a new entry in the map or delete an existing entry. +Program test runs always use a temporary storage. diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst index dde4f7f7fdbf..2de905810590 100644 --- a/Documentation/cdrom/cdrom-standard.rst +++ b/Documentation/cdrom/cdrom-standard.rst @@ -157,7 +157,6 @@ with the kernel as a block device by registering the following general cdrom_release, /∗ release ∗/ NULL, /∗ fsync ∗/ NULL, /∗ fasync ∗/ - cdrom_media_changed, /∗ media change ∗/ NULL /∗ revalidate ∗/ }; @@ -366,19 +365,6 @@ which may or may not be in the drive). If the drive is not a changer, CDS_DRIVE_NOT_READY /* something is wrong, tray is moving? */ CDS_DISC_OK /* a disc is loaded and everything is fine */ -:: - - int media_changed(struct cdrom_device_info *cdi, int disc_nr) - -This function is very similar to the original function in $struct -file_operations*. It returns 1 if the medium of the device *cdi->dev* -has changed since the last call, and 0 otherwise. The parameter -*disc_nr* identifies a specific slot in a juke-box, it should be -ignored for single-disc drives. Note that by `re-routing` this -function through *cdrom_media_changed()*, we can implement separate -queues for the VFS and a new *ioctl()* function that can report device -changes to software (e. g., an auto-mounting daemon). - :: int tray_move(struct cdrom_device_info *cdi, int position) @@ -917,9 +903,7 @@ commands can be identified by the underscores in their names. maximum number of discs in the juke-box found in the *cdrom_dops*. `CDROM_MEDIA_CHANGED` Returns 1 if a disc has been changed since the last call. - Note that calls to *cdrom_media_changed* by the VFS are treated - by an independent queue, so both mechanisms will detect a - media change once. For juke-boxes, an extra argument *arg* + For juke-boxes, an extra argument *arg* specifies the slot for which the information is given. The special value *CDSL_CURRENT* requests that information about the currently selected slot be returned. diff --git a/Documentation/bus-virt-phys-mapping.txt b/Documentation/core-api/bus-virt-phys-mapping.rst similarity index 99% rename from Documentation/bus-virt-phys-mapping.txt rename to Documentation/core-api/bus-virt-phys-mapping.rst index 4bb07c2f3e7d..c7bc99cd2e21 100644 --- a/Documentation/bus-virt-phys-mapping.txt +++ b/Documentation/core-api/bus-virt-phys-mapping.rst @@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers The virt_to_bus() and bus_to_virt() functions have been superseded by the functionality provided by the PCI DMA interface - (see Documentation/DMA-API-HOWTO.txt). They continue + (see :doc:`/core-api/dma-api-howto`). They continue to be documented below for historical purposes, but new code must not use them. --davidm 00/12/12 diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst index 4a50ab7817f7..f64668759b6a 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -35,8 +35,8 @@ Command Line Switches other CPUs later online. ``nr_cpus=n`` - Restrict the total amount CPUs the kernel will support. If the number - supplied here is lower than the number of physically available CPUs than + Restrict the total amount of CPUs the kernel will support. If the number + supplied here is lower than the number of physically available CPUs, then those CPUs can not be brought online later. ``additional_cpus=n`` diff --git a/Documentation/core-api/dma-api.rst b/Documentation/core-api/dma-api.rst index f41620439ef3..3b3abbbb4b9a 100644 --- a/Documentation/core-api/dma-api.rst +++ b/Documentation/core-api/dma-api.rst @@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device :Author: James E.J. Bottomley This document describes the DMA API. For a more gentle introduction -of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt. +of the API (and actual examples), see :doc:`/core-api/dma-api-howto`. This API is split into two pieces. Part I describes the basic API. Part II describes extensions for supporting non-consistent memory @@ -479,7 +479,7 @@ without the _attrs suffixes, except that they pass an optional dma_attrs. The interpretation of DMA attributes is architecture-specific, and -each attribute should be documented in Documentation/DMA-attributes.txt. +each attribute should be documented in :doc:`/core-api/dma-attributes`. If dma_attrs are 0, the semantics of each of these functions is identical to those of the corresponding function @@ -492,7 +492,7 @@ for DMA:: #include /* DMA_ATTR_FOO should be defined in linux/dma-mapping.h and - * documented in Documentation/DMA-attributes.txt */ + * documented in Documentation/core-api/dma-attributes.rst */ ... unsigned long attr; diff --git a/Documentation/core-api/dma-isa-lpc.rst b/Documentation/core-api/dma-isa-lpc.rst index b1ec7b16c21f..e59a3d35a93d 100644 --- a/Documentation/core-api/dma-isa-lpc.rst +++ b/Documentation/core-api/dma-isa-lpc.rst @@ -17,7 +17,7 @@ To do ISA style DMA you need to include two headers:: #include The first is the generic DMA API used to convert virtual addresses to -bus addresses (see Documentation/DMA-API.txt for details). +bus addresses (see :doc:`/core-api/dma-api` for details). The second contains the routines specific to ISA DMA transfers. Since this is not present on all platforms make sure you construct your diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 15ab86112627..69171b1799f2 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -39,6 +39,8 @@ Library functionality that is used throughout the kernel. rbtree generic-radix-tree packing + bus-virt-phys-mapping + this_cpu_ops timekeeping errseq @@ -82,6 +84,7 @@ more memory-management documentation in :doc:`/vm/index`. :maxdepth: 1 memory-allocation + unaligned-memory-access dma-api dma-api-howto dma-attributes diff --git a/Documentation/core-api/kobject.rst b/Documentation/core-api/kobject.rst index e93dc8cf52dd..2739f8b72575 100644 --- a/Documentation/core-api/kobject.rst +++ b/Documentation/core-api/kobject.rst @@ -6,7 +6,7 @@ Everything you never wanted to know about kobjects, ksets, and ktypes :Last updated: December 19, 2007 Based on an original article by Jon Corbet for lwn.net written October 1, -2003 and located at http://lwn.net/Articles/51437/ +2003 and located at https://lwn.net/Articles/51437/ Part of the difficulty in understanding the driver model - and the kobject abstraction upon which it is built - is that there is no obvious starting diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst index 4aa82ddd01b8..4446a1ac36cc 100644 --- a/Documentation/core-api/memory-allocation.rst +++ b/Documentation/core-api/memory-allocation.rst @@ -84,6 +84,50 @@ driver for a device with such restrictions, avoid using these flags. And even with hardware with restrictions it is preferable to use `dma_alloc*` APIs. +GFP flags and reclaim behavior +------------------------------ +Memory allocations may trigger direct or background reclaim and it is +useful to understand how hard the page allocator will try to satisfy that +or another request. + + * ``GFP_KERNEL & ~__GFP_RECLAIM`` - optimistic allocation without _any_ + attempt to free memory at all. The most light weight mode which even + doesn't kick the background reclaim. Should be used carefully because it + might deplete the memory and the next user might hit the more aggressive + reclaim. + + * ``GFP_KERNEL & ~__GFP_DIRECT_RECLAIM`` (or ``GFP_NOWAIT``)- optimistic + allocation without any attempt to free memory from the current + context but can wake kswapd to reclaim memory if the zone is below + the low watermark. Can be used from either atomic contexts or when + the request is a performance optimization and there is another + fallback for a slow path. + + * ``(GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM`` (aka ``GFP_ATOMIC``) - + non sleeping allocation with an expensive fallback so it can access + some portion of memory reserves. Usually used from interrupt/bottom-half + context with an expensive slow path fallback. + + * ``GFP_KERNEL`` - both background and direct reclaim are allowed and the + **default** page allocator behavior is used. That means that not costly + allocation requests are basically no-fail but there is no guarantee of + that behavior so failures have to be checked properly by callers + (e.g. OOM killer victim is allowed to fail currently). + + * ``GFP_KERNEL | __GFP_NORETRY`` - overrides the default allocator behavior + and all allocation requests fail early rather than cause disruptive + reclaim (one round of reclaim in this implementation). The OOM killer + is not invoked. + + * ``GFP_KERNEL | __GFP_RETRY_MAYFAIL`` - overrides the default allocator + behavior and all allocation requests try really hard. The request + will fail if the reclaim cannot make any progress. The OOM killer + won't be triggered. + + * ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior + and all allocation requests will loop endlessly until they succeed. + This might be really dangerous especially for larger orders. + Selecting memory allocator ========================== diff --git a/Documentation/core-api/padata.rst b/Documentation/core-api/padata.rst index 0830e5b0e821..35175710b43c 100644 --- a/Documentation/core-api/padata.rst +++ b/Documentation/core-api/padata.rst @@ -27,22 +27,11 @@ padata_instance structure for overall control of how jobs are to be run:: #include - struct padata_instance *padata_alloc_possible(const char *name); + struct padata_instance *padata_alloc(const char *name); 'name' simply identifies the instance. -There are functions for enabling and disabling the instance:: - - int padata_start(struct padata_instance *pinst); - void padata_stop(struct padata_instance *pinst); - -These functions are setting or clearing the "PADATA_INIT" flag; if that flag is -not set, other functions will refuse to work. padata_start() returns zero on -success (flag set) or -EINVAL if the padata cpumask contains no active CPU -(flag not set). padata_stop() clears the flag and blocks until the padata -instance is unused. - -Finally, complete padata initialization by allocating a padata_shell:: +Then, complete padata initialization by allocating a padata_shell:: struct padata_shell *padata_alloc_shell(struct padata_instance *pinst); @@ -155,11 +144,10 @@ submitted. Destroying ---------- -Cleaning up a padata instance predictably involves calling the three free +Cleaning up a padata instance predictably involves calling the two free functions that correspond to the allocation in reverse:: void padata_free_shell(struct padata_shell *ps); - void padata_stop(struct padata_instance *pinst); void padata_free(struct padata_instance *pinst); It is the user's responsibility to ensure all outstanding jobs are complete diff --git a/Documentation/core-api/printk-basics.rst b/Documentation/core-api/printk-basics.rst index 563a9ce5fe1d..965e4281eddd 100644 --- a/Documentation/core-api/printk-basics.rst +++ b/Documentation/core-api/printk-basics.rst @@ -69,7 +69,7 @@ You can check the current *console_loglevel* with:: The result shows the *current*, *default*, *minimum* and *boot-time-default* log levels. -To change the current console_loglevel simply write the the desired level to +To change the current console_loglevel simply write the desired level to ``/proc/sys/kernel/printk``. For example, to print all messages to the console:: # echo 8 > /proc/sys/kernel/printk diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 8c9aba262b1e..6d26c5c6ac48 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -317,7 +317,7 @@ colon-separators. Leading zeros are always used. The additional ``c`` specifier can be used with the ``I`` specifier to print a compressed IPv6 address as described by -http://tools.ietf.org/html/rfc5952 +https://tools.ietf.org/html/rfc5952 Passed by reference. @@ -341,7 +341,7 @@ The additional ``p``, ``f``, and ``s`` specifiers are used to specify port flowinfo a ``/`` and scope a ``%``, each followed by the actual value. In case of an IPv6 address the compressed IPv6 address as described by -http://tools.ietf.org/html/rfc5952 is being used if the additional +https://tools.ietf.org/html/rfc5952 is being used if the additional specifier ``c`` is given. The IPv6 address is surrounded by ``[``, ``]`` in case of additional specifiers ``p``, ``f`` or ``s`` as suggested by https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07 @@ -494,9 +494,11 @@ Time and date %pt[RT]t HH:MM:SS %pt[RT][dt][r] -For printing date and time as represented by +For printing date and time as represented by:: + R struct rtc_time structure T time64_t type + in human readable format. By default year will be incremented by 1900 and month by 1. diff --git a/Documentation/this_cpu_ops.txt b/Documentation/core-api/this_cpu_ops.rst similarity index 100% rename from Documentation/this_cpu_ops.txt rename to Documentation/core-api/this_cpu_ops.rst diff --git a/Documentation/process/unaligned-memory-access.rst b/Documentation/core-api/unaligned-memory-access.rst similarity index 100% rename from Documentation/process/unaligned-memory-access.rst rename to Documentation/core-api/unaligned-memory-access.rst diff --git a/Documentation/crypto/api-intro.txt b/Documentation/crypto/api-intro.rst similarity index 69% rename from Documentation/crypto/api-intro.txt rename to Documentation/crypto/api-intro.rst index 45d943fcae5b..15201be0b811 100644 --- a/Documentation/crypto/api-intro.txt +++ b/Documentation/crypto/api-intro.rst @@ -1,7 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 - Scatterlist Cryptographic API - -INTRODUCTION +============================= +Scatterlist Cryptographic API +============================= + +Introduction +============ The Scatterlist Crypto API takes page vectors (scatterlists) as arguments, and works directly on pages. In some cases (e.g. ECB @@ -13,22 +17,23 @@ so that processing can be applied to paged skb's without the need for linearization. -DETAILS +Details +======= At the lowest level are algorithms, which register dynamically with the API. 'Transforms' are user-instantiated objects, which maintain state, handle all -of the implementation logic (e.g. manipulating page vectors) and provide an -abstraction to the underlying algorithms. However, at the user +of the implementation logic (e.g. manipulating page vectors) and provide an +abstraction to the underlying algorithms. However, at the user level they are very simple. -Conceptually, the API layering looks like this: +Conceptually, the API layering looks like this:: [transform api] (user interface) [transform ops] (per-type logic glue e.g. cipher.c, compress.c) [algorithm api] (for registering algorithms) - + The idea is to make the user interface and algorithm registration API very simple, while hiding the core logic from both. Many good ideas from existing APIs such as Cryptoapi and Nettle have been adapted for this. @@ -44,21 +49,21 @@ one block while the former can operate on an arbitrary amount of data, subject to block size requirements (i.e., non-stream ciphers can only process multiples of blocks). -Here's an example of how to use the API: +Here's an example of how to use the API:: #include #include #include - + struct scatterlist sg[2]; char result[128]; struct crypto_ahash *tfm; struct ahash_request *req; - + tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC); if (IS_ERR(tfm)) fail(); - + /* ... set up the scatterlists ... */ req = ahash_request_alloc(tfm, GFP_ATOMIC); @@ -67,18 +72,19 @@ Here's an example of how to use the API: ahash_request_set_callback(req, 0, NULL, NULL); ahash_request_set_crypt(req, sg, result, 2); - + if (crypto_ahash_digest(req)) fail(); ahash_request_free(req); crypto_free_ahash(tfm); - + Many real examples are available in the regression test module (tcrypt.c). -DEVELOPER NOTES +Developer Notes +=============== Transforms may only be allocated in user context, and cryptographic methods may only be called from softirq and user contexts. For @@ -91,7 +97,8 @@ size (typically 8 bytes). This prevents having to do any copying across non-aligned page fragment boundaries. -ADDING NEW ALGORITHMS +Adding New Algorithms +===================== When submitting a new algorithm for inclusion, a mandatory requirement is that at least a few test vectors from known sources (preferably @@ -119,132 +126,137 @@ Also check the TODO list at the web site listed below to see what people might already be working on. -BUGS +Bugs +==== Send bug reports to: -linux-crypto@vger.kernel.org -Cc: Herbert Xu , + linux-crypto@vger.kernel.org + +Cc: + Herbert Xu , David S. Miller -FURTHER INFORMATION +Further Information +=================== For further patches and various updates, including the current TODO list, see: http://gondor.apana.org.au/~herbert/crypto/ -AUTHORS +Authors +======= -James Morris -David S. Miller -Herbert Xu +- James Morris +- David S. Miller +- Herbert Xu -CREDITS +Credits +======= The following people provided invaluable feedback during the development of the API: - Alexey Kuznetzov - Rusty Russell - Herbert Valerio Riedel - Jeff Garzik - Michael Richardson - Andrew Morton - Ingo Oeser - Christoph Hellwig + - Alexey Kuznetzov + - Rusty Russell + - Herbert Valerio Riedel + - Jeff Garzik + - Michael Richardson + - Andrew Morton + - Ingo Oeser + - Christoph Hellwig Portions of this API were derived from the following projects: - + Kerneli Cryptoapi (http://www.kerneli.org/) - Alexander Kjeldaas - Herbert Valerio Riedel - Kyle McMartin - Jean-Luc Cooke - David Bryson - Clemens Fruhwirth - Tobias Ringstrom - Harald Welte + - Alexander Kjeldaas + - Herbert Valerio Riedel + - Kyle McMartin + - Jean-Luc Cooke + - David Bryson + - Clemens Fruhwirth + - Tobias Ringstrom + - Harald Welte and; - - Nettle (http://www.lysator.liu.se/~nisse/nettle/) - Niels Möller + + Nettle (https://www.lysator.liu.se/~nisse/nettle/) + - Niels Möller Original developers of the crypto algorithms: - Dana L. How (DES) - Andrew Tridgell and Steve French (MD4) - Colin Plumb (MD5) - Steve Reid (SHA1) - Jean-Luc Cooke (SHA256, SHA384, SHA512) - Kazunori Miyazawa / USAGI (HMAC) - Matthew Skala (Twofish) - Dag Arne Osvik (Serpent) - Brian Gladman (AES) - Kartikey Mahendra Bhatt (CAST6) - Jon Oberheide (ARC4) - Jouni Malinen (Michael MIC) - NTT(Nippon Telegraph and Telephone Corporation) (Camellia) + - Dana L. How (DES) + - Andrew Tridgell and Steve French (MD4) + - Colin Plumb (MD5) + - Steve Reid (SHA1) + - Jean-Luc Cooke (SHA256, SHA384, SHA512) + - Kazunori Miyazawa / USAGI (HMAC) + - Matthew Skala (Twofish) + - Dag Arne Osvik (Serpent) + - Brian Gladman (AES) + - Kartikey Mahendra Bhatt (CAST6) + - Jon Oberheide (ARC4) + - Jouni Malinen (Michael MIC) + - NTT(Nippon Telegraph and Telephone Corporation) (Camellia) SHA1 algorithm contributors: - Jean-Francois Dive - + - Jean-Francois Dive + DES algorithm contributors: - Raimar Falke - Gisle Sælensminde - Niels Möller + - Raimar Falke + - Gisle Sælensminde + - Niels Möller Blowfish algorithm contributors: - Herbert Valerio Riedel - Kyle McMartin + - Herbert Valerio Riedel + - Kyle McMartin Twofish algorithm contributors: - Werner Koch - Marc Mutz + - Werner Koch + - Marc Mutz SHA256/384/512 algorithm contributors: - Andrew McDonald - Kyle McMartin - Herbert Valerio Riedel - + - Andrew McDonald + - Kyle McMartin + - Herbert Valerio Riedel + AES algorithm contributors: - Alexander Kjeldaas - Herbert Valerio Riedel - Kyle McMartin - Adam J. Richter - Fruhwirth Clemens (i586) - Linus Torvalds (i586) + - Alexander Kjeldaas + - Herbert Valerio Riedel + - Kyle McMartin + - Adam J. Richter + - Fruhwirth Clemens (i586) + - Linus Torvalds (i586) CAST5 algorithm contributors: - Kartikey Mahendra Bhatt (original developers unknown, FSF copyright). + - Kartikey Mahendra Bhatt (original developers unknown, FSF copyright). TEA/XTEA algorithm contributors: - Aaron Grothe - Michael Ringe + - Aaron Grothe + - Michael Ringe Khazad algorithm contributors: - Aaron Grothe + - Aaron Grothe Whirlpool algorithm contributors: - Aaron Grothe - Jean-Luc Cooke + - Aaron Grothe + - Jean-Luc Cooke Anubis algorithm contributors: - Aaron Grothe + - Aaron Grothe Tiger algorithm contributors: - Aaron Grothe + - Aaron Grothe VIA PadLock contributors: - Michal Ludvig + - Michal Ludvig Camellia algorithm contributors: - NTT(Nippon Telegraph and Telephone Corporation) (Camellia) + - NTT(Nippon Telegraph and Telephone Corporation) (Camellia) Generic scatterwalk code by Adam J. Richter Please send any credits updates or corrections to: Herbert Xu - diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.rst similarity index 91% rename from Documentation/crypto/asymmetric-keys.txt rename to Documentation/crypto/asymmetric-keys.rst index 8763866b11cf..349f44a29392 100644 --- a/Documentation/crypto/asymmetric-keys.txt +++ b/Documentation/crypto/asymmetric-keys.rst @@ -1,8 +1,10 @@ - ============================================= - ASYMMETRIC / PUBLIC-KEY CRYPTOGRAPHY KEY TYPE - ============================================= +.. SPDX-License-Identifier: GPL-2.0 -Contents: +============================================= +Asymmetric / Public-key Cryptography Key Type +============================================= + +.. Contents: - Overview. - Key identification. @@ -13,8 +15,7 @@ Contents: - Keyring link restrictions. -======== -OVERVIEW +Overview ======== The "asymmetric" key type is designed to be a container for the keys used in @@ -42,8 +43,7 @@ key, or it may interpret it as a reference to a key held somewhere else in the system (for example, a TPM). -================== -KEY IDENTIFICATION +Key Identification ================== If a key is added with an empty name, the instantiation data parsers are given @@ -57,49 +57,48 @@ The asymmetric key type's match function can then perform a wider range of comparisons than just the straightforward comparison of the description with the criterion string: - (1) If the criterion string is of the form "id:" then the match + 1) If the criterion string is of the form "id:" then the match function will examine a key's fingerprint to see if the hex digits given - after the "id:" match the tail. For instance: + after the "id:" match the tail. For instance:: keyctl search @s asymmetric id:5acc2142 - will match a key with fingerprint: + will match a key with fingerprint:: 1A00 2040 7601 7889 DE11 882C 3823 04AD 5ACC 2142 - (2) If the criterion string is of the form ":" then the + 2) If the criterion string is of the form ":" then the match will match the ID as in (1), but with the added restriction that only keys of the specified subtype (e.g. tpm) will be matched. For - instance: + instance:: keyctl search @s asymmetric tpm:5acc2142 Looking in /proc/keys, the last 8 hex digits of the key fingerprint are -displayed, along with the subtype: +displayed, along with the subtype:: 1a39e171 I----- 1 perm 3f010000 0 0 asymmetric modsign.0: DSA 5acc2142 [] -========================= -ACCESSING ASYMMETRIC KEYS +Accessing Asymmetric Keys ========================= For general access to asymmetric keys from within the kernel, the following -inclusion is required: +inclusion is required:: #include This gives access to functions for dealing with asymmetric / public keys. Three enums are defined there for representing public-key cryptography -algorithms: +algorithms:: enum pkey_algo -digest algorithms used by those: +digest algorithms used by those:: enum pkey_hash_algo -and key identifier representations: +and key identifier representations:: enum pkey_id_type @@ -110,25 +109,25 @@ PGP-specific metadata, whereas X.509 has arbitrary certificate identifiers. The operations defined upon a key are: - (1) Signature verification. + 1) Signature verification. Other operations are possible (such as encryption) with the same key data required for verification, but not currently supported, and others (eg. decryption and signature generation) require extra key data. -SIGNATURE VERIFICATION +Signature Verification ---------------------- An operation is provided to perform cryptographic signature verification, using -an asymmetric key to provide or to provide access to the public key. +an asymmetric key to provide or to provide access to the public key:: int verify_signature(const struct key *key, const struct public_key_signature *sig); The caller must have already obtained the key from some source and can then use it to check the signature. The caller must have parsed the signature and -transferred the relevant bits to the structure pointed to by sig. +transferred the relevant bits to the structure pointed to by sig:: struct public_key_signature { u8 *digest; @@ -159,8 +158,7 @@ data; or -ENOMEM if an allocation can't be performed. -EINVAL can be returned if the key argument is the wrong type or is incompletely set up. -======================= -ASYMMETRIC KEY SUBTYPES +Asymmetric Key Subtypes ======================= Asymmetric keys have a subtype that defines the set of operations that can be @@ -171,11 +169,11 @@ The subtype is selected by the key data parser and the parser must initialise the data required for it. The asymmetric key retains a reference on the subtype module. -The subtype definition structure can be found in: +The subtype definition structure can be found in:: #include -and looks like the following: +and looks like the following:: struct asymmetric_key_subtype { struct module *owner; @@ -198,39 +196,37 @@ the subtype. Currently, the name is only used for print statements. There are a number of operations defined by the subtype: - (1) describe(). + 1) describe(). Mandatory. This allows the subtype to display something in /proc/keys against the key. For instance the name of the public key algorithm type could be displayed. The key type will display the tail of the key identity string after this. - (2) destroy(). + 2) destroy(). Mandatory. This should free the memory associated with the key. The asymmetric key will look after freeing the fingerprint and releasing the reference on the subtype module. - (3) query(). + 3) query(). Mandatory. This is a function for querying the capabilities of a key. - (4) eds_op(). + 4) eds_op(). Optional. This is the entry point for the encryption, decryption and signature creation operations (which are distinguished by the operation ID in the parameter struct). The subtype may do anything it likes to implement an operation, including offloading to hardware. - (5) verify_signature(). + 5) verify_signature(). Optional. This is the entry point for signature verification. The subtype may do anything it likes to implement an operation, including offloading to hardware. - -========================== -INSTANTIATION DATA PARSERS +Instantiation Data Parsers ========================== The asymmetric key type doesn't generally want to store or to deal with a raw @@ -254,11 +250,11 @@ Examples of blob formats for which parsers could be implemented include: During key instantiation each parser in the list is tried until one doesn't return -EBADMSG. -The parser definition structure can be found in: +The parser definition structure can be found in:: #include -and looks like the following: +and looks like the following:: struct asymmetric_key_parser { struct module *owner; @@ -273,7 +269,7 @@ the parser. There is currently only a single operation defined by the parser, and it is mandatory: - (1) parse(). + 1) parse(). This is called to preparse the key from the key creation and update paths. In particular, it is called during the key creation _before_ a key is @@ -282,7 +278,7 @@ mandatory: The caller passes a pointer to the following struct with all of the fields cleared, except for data, datalen and quotalen [see - Documentation/security/keys/core.rst]. + Documentation/security/keys/core.rst]:: struct key_preparsed_payload { char *description; @@ -321,7 +317,7 @@ mandatory: public-key algorithm such as RSA and DSA this will likely be a printable hex version of the key's fingerprint. -Functions are provided to register and unregister parsers: +Functions are provided to register and unregister parsers:: int register_asymmetric_key_parser(struct asymmetric_key_parser *parser); void unregister_asymmetric_key_parser(struct asymmetric_key_parser *subtype); @@ -330,8 +326,7 @@ Parsers may not have the same name. The names are otherwise only used for displaying in debugging messages. -========================= -KEYRING LINK RESTRICTIONS +Keyring Link Restrictions ========================= Keyrings created from userspace using add_key can be configured to check the @@ -340,7 +335,7 @@ allowed to link. Several restriction methods are available: - (1) Restrict using the kernel builtin trusted keyring + 1) Restrict using the kernel builtin trusted keyring - Option string used with KEYCTL_RESTRICT_KEYRING: - "builtin_trusted" @@ -350,7 +345,7 @@ Several restriction methods are available: rejected. The ca_keys kernel parameter also affects which keys are used for signature verification. - (2) Restrict using the kernel builtin and secondary trusted keyrings + 2) Restrict using the kernel builtin and secondary trusted keyrings - Option string used with KEYCTL_RESTRICT_KEYRING: - "builtin_and_secondary_trusted" @@ -361,7 +356,7 @@ Several restriction methods are available: kernel parameter also affects which keys are used for signature verification. - (3) Restrict using a separate key or keyring + 3) Restrict using a separate key or keyring - Option string used with KEYCTL_RESTRICT_KEYRING: - "key_or_keyring:[:chain]" @@ -378,7 +373,7 @@ Several restriction methods are available: certificate in order (starting closest to the root) to a keyring. For instance, one keyring can be populated with links to a set of root certificates, with a separate, restricted keyring set up for each - certificate chain to be validated: + certificate chain to be validated:: # Create and populate a keyring for root certificates root_id=`keyctl add keyring root-certs "" @s` @@ -400,7 +395,7 @@ Several restriction methods are available: one of the root certificates. A single keyring can be used to verify a chain of signatures by - restricting the keyring after linking the root certificate: + restricting the keyring after linking the root certificate:: # Create a keyring for the certificate chain and add the root chain2_id=`keyctl add keyring chain2 "" @s` diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.rst similarity index 55% rename from Documentation/crypto/async-tx-api.txt rename to Documentation/crypto/async-tx-api.rst index 7bf1be20d93a..bfc773991bdc 100644 --- a/Documentation/crypto/async-tx-api.txt +++ b/Documentation/crypto/async-tx-api.rst @@ -1,27 +1,32 @@ - Asynchronous Transfers/Transforms API +.. SPDX-License-Identifier: GPL-2.0 -1 INTRODUCTION +===================================== +Asynchronous Transfers/Transforms API +===================================== -2 GENEALOGY +.. Contents -3 USAGE -3.1 General format of the API -3.2 Supported operations -3.3 Descriptor management -3.4 When does the operation execute? -3.5 When does the operation complete? -3.6 Constraints -3.7 Example + 1. INTRODUCTION -4 DMAENGINE DRIVER DEVELOPER NOTES -4.1 Conformance points -4.2 "My application needs exclusive control of hardware channels" + 2 GENEALOGY -5 SOURCE + 3 USAGE + 3.1 General format of the API + 3.2 Supported operations + 3.3 Descriptor management + 3.4 When does the operation execute? + 3.5 When does the operation complete? + 3.6 Constraints + 3.7 Example ---- + 4 DMAENGINE DRIVER DEVELOPER NOTES + 4.1 Conformance points + 4.2 "My application needs exclusive control of hardware channels" -1 INTRODUCTION + 5 SOURCE + +1. Introduction +=============== The async_tx API provides methods for describing a chain of asynchronous bulk memory transfers/transforms with support for inter-transactional @@ -31,7 +36,8 @@ that is written to the API can optimize for asynchronous operation and the API will fit the chain of operations to the available offload resources. -2 GENEALOGY +2.Genealogy +=========== The API was initially designed to offload the memory copy and xor-parity-calculations of the md-raid5 driver using the offload engines @@ -39,40 +45,52 @@ present in the Intel(R) Xscale series of I/O processors. It also built on the 'dmaengine' layer developed for offloading memory copies in the network stack using Intel(R) I/OAT engines. The following design features surfaced as a result: -1/ implicit synchronous path: users of the API do not need to know if + +1. implicit synchronous path: users of the API do not need to know if the platform they are running on has offload capabilities. The operation will be offloaded when an engine is available and carried out in software otherwise. -2/ cross channel dependency chains: the API allows a chain of dependent +2. cross channel dependency chains: the API allows a chain of dependent operations to be submitted, like xor->copy->xor in the raid5 case. The API automatically handles cases where the transition from one operation to another implies a hardware channel switch. -3/ dmaengine extensions to support multiple clients and operation types +3. dmaengine extensions to support multiple clients and operation types beyond 'memcpy' -3 USAGE +3. Usage +======== -3.1 General format of the API: -struct dma_async_tx_descriptor * -async_(, struct async_submit ctl *submit) +3.1 General format of the API +----------------------------- -3.2 Supported operations: -memcpy - memory copy between a source and a destination buffer -memset - fill a destination buffer with a byte value -xor - xor a series of source buffers and write the result to a +:: + + struct dma_async_tx_descriptor * + async_(, struct async_submit ctl *submit) + +3.2 Supported operations +------------------------ + +======== ==================================================================== +memcpy memory copy between a source and a destination buffer +memset fill a destination buffer with a byte value +xor xor a series of source buffers and write the result to a destination buffer -xor_val - xor a series of source buffers and set a flag if the +xor_val xor a series of source buffers and set a flag if the result is zero. The implementation attempts to prevent writes to memory -pq - generate the p+q (raid6 syndrome) from a series of source buffers -pq_val - validate that a p and or q buffer are in sync with a given series of +pq generate the p+q (raid6 syndrome) from a series of source buffers +pq_val validate that a p and or q buffer are in sync with a given series of sources -datap - (raid6_datap_recov) recover a raid6 data block and the p block +datap (raid6_datap_recov) recover a raid6 data block and the p block from the given sources -2data - (raid6_2data_recov) recover 2 raid6 data blocks from the given +2data (raid6_2data_recov) recover 2 raid6 data blocks from the given sources +======== ==================================================================== + +3.3 Descriptor management +------------------------- -3.3 Descriptor management: The return value is non-NULL and points to a 'descriptor' when the operation has been queued to execute asynchronously. Descriptors are recycled resources, under control of the offload engine driver, to be reused as @@ -82,12 +100,15 @@ before the dependency is submitted. This requires that all descriptors be acknowledged by the application before the offload engine driver is allowed to recycle (or free) the descriptor. A descriptor can be acked by one of the following methods: -1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted -2/ submitting an unacknowledged descriptor as a dependency to another + +1. setting the ASYNC_TX_ACK flag if no child operations are to be submitted +2. submitting an unacknowledged descriptor as a dependency to another async_tx call will implicitly set the acknowledged state. -3/ calling async_tx_ack() on the descriptor. +3. calling async_tx_ack() on the descriptor. 3.4 When does the operation execute? +------------------------------------ + Operations do not immediately issue after return from the async_ call. Offload engine drivers batch operations to improve performance by reducing the number of mmio cycles needed to @@ -98,12 +119,15 @@ channels since the application has no knowledge of channel to operation mapping. 3.5 When does the operation complete? +------------------------------------- + There are two methods for an application to learn about the completion of an operation. -1/ Call dma_wait_for_async_tx(). This call causes the CPU to spin while + +1. Call dma_wait_for_async_tx(). This call causes the CPU to spin while it polls for the completion of the operation. It handles dependency chains and issuing pending operations. -2/ Specify a completion callback. The callback routine runs in tasklet +2. Specify a completion callback. The callback routine runs in tasklet context if the offload engine driver supports interrupts, or it is called in application context if the operation is carried out synchronously in software. The callback can be set in the call to @@ -111,83 +135,95 @@ of an operation. unknown length it can use the async_trigger_callback() routine to set a completion interrupt/callback at the end of the chain. -3.6 Constraints: -1/ Calls to async_ are not permitted in IRQ context. Other +3.6 Constraints +--------------- + +1. Calls to async_ are not permitted in IRQ context. Other contexts are permitted provided constraint #2 is not violated. -2/ Completion callback routines cannot submit new operations. This +2. Completion callback routines cannot submit new operations. This results in recursion in the synchronous case and spin_locks being acquired twice in the asynchronous case. -3.7 Example: +3.7 Example +----------- + Perform a xor->copy->xor operation where each operation depends on the -result from the previous operation: +result from the previous operation:: -void callback(void *param) -{ - struct completion *cmp = param; + void callback(void *param) + { + struct completion *cmp = param; - complete(cmp); -} + complete(cmp); + } -void run_xor_copy_xor(struct page **xor_srcs, - int xor_src_cnt, - struct page *xor_dest, - size_t xor_len, - struct page *copy_src, - struct page *copy_dest, - size_t copy_len) -{ - struct dma_async_tx_descriptor *tx; - addr_conv_t addr_conv[xor_src_cnt]; - struct async_submit_ctl submit; - addr_conv_t addr_conv[NDISKS]; - struct completion cmp; + void run_xor_copy_xor(struct page **xor_srcs, + int xor_src_cnt, + struct page *xor_dest, + size_t xor_len, + struct page *copy_src, + struct page *copy_dest, + size_t copy_len) + { + struct dma_async_tx_descriptor *tx; + addr_conv_t addr_conv[xor_src_cnt]; + struct async_submit_ctl submit; + addr_conv_t addr_conv[NDISKS]; + struct completion cmp; - init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL, - addr_conv); - tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit) + init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL, + addr_conv); + tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit) - submit->depend_tx = tx; - tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit); + submit->depend_tx = tx; + tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit); - init_completion(&cmp); - init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx, - callback, &cmp, addr_conv); - tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit); + init_completion(&cmp); + init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx, + callback, &cmp, addr_conv); + tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit); - async_tx_issue_pending_all(); + async_tx_issue_pending_all(); - wait_for_completion(&cmp); -} + wait_for_completion(&cmp); + } See include/linux/async_tx.h for more information on the flags. See the ops_run_* and ops_complete_* routines in drivers/md/raid5.c for more implementation examples. -4 DRIVER DEVELOPMENT NOTES +4. Driver Development Notes +=========================== + +4.1 Conformance points +---------------------- -4.1 Conformance points: There are a few conformance points required in dmaengine drivers to accommodate assumptions made by applications using the async_tx API: -1/ Completion callbacks are expected to happen in tasklet context -2/ dma_async_tx_descriptor fields are never manipulated in IRQ context -3/ Use async_tx_run_dependencies() in the descriptor clean up path to + +1. Completion callbacks are expected to happen in tasklet context +2. dma_async_tx_descriptor fields are never manipulated in IRQ context +3. Use async_tx_run_dependencies() in the descriptor clean up path to handle submission of dependent operations 4.2 "My application needs exclusive control of hardware channels" +----------------------------------------------------------------- + Primarily this requirement arises from cases where a DMA engine driver is being used to support device-to-memory operations. A channel that is performing these operations cannot, for many platform specific reasons, be shared. For these cases the dma_request_channel() interface is provided. -The interface is: -struct dma_chan *dma_request_channel(dma_cap_mask_t mask, - dma_filter_fn filter_fn, - void *filter_param); +The interface is:: -Where dma_filter_fn is defined as: -typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param); + struct dma_chan *dma_request_channel(dma_cap_mask_t mask, + dma_filter_fn filter_fn, + void *filter_param); + +Where dma_filter_fn is defined as:: + + typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param); When the optional 'filter_fn' parameter is set to NULL dma_request_channel simply returns the first channel that satisfies the @@ -207,19 +243,28 @@ private. Alternatively, it is set when dma_request_channel() finds an unused "public" channel. A couple caveats to note when implementing a driver and consumer: -1/ Once a channel has been privately allocated it will no longer be + +1. Once a channel has been privately allocated it will no longer be considered by the general-purpose allocator even after a call to dma_release_channel(). -2/ Since capabilities are specified at the device level a dma_device +2. Since capabilities are specified at the device level a dma_device with multiple channels will either have all channels public, or all channels private. -5 SOURCE +5. Source +--------- -include/linux/dmaengine.h: core header file for DMA drivers and api users -drivers/dma/dmaengine.c: offload engine channel management routines -drivers/dma/: location for offload engine drivers -include/linux/async_tx.h: core header file for the async_tx api -crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code -crypto/async_tx/async_memcpy.c: copy offload -crypto/async_tx/async_xor.c: xor and xor zero sum offload +include/linux/dmaengine.h: + core header file for DMA drivers and api users +drivers/dma/dmaengine.c: + offload engine channel management routines +drivers/dma/: + location for offload engine drivers +include/linux/async_tx.h: + core header file for the async_tx api +crypto/async_tx/async_tx.c: + async_tx interface to dmaengine and common code +crypto/async_tx/async_memcpy.c: + copy offload +crypto/async_tx/async_xor.c: + xor and xor zero sum offload diff --git a/Documentation/crypto/descore-readme.txt b/Documentation/crypto/descore-readme.rst similarity index 81% rename from Documentation/crypto/descore-readme.txt rename to Documentation/crypto/descore-readme.rst index 16e9e6350755..45bd9c8babf4 100644 --- a/Documentation/crypto/descore-readme.txt +++ b/Documentation/crypto/descore-readme.rst @@ -1,8 +1,20 @@ -Below is the original README file from the descore.shar package. +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=========================================== +Fast & Portable DES encryption & decryption +=========================================== + +.. note:: + + Below is the original README file from the descore.shar package, + converted to ReST format. + ------------------------------------------------------------------------------ des - fast & portable DES encryption & decryption. -Copyright (C) 1992 Dana L. How + +Copyright |copy| 1992 Dana L. How This program is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by @@ -20,13 +32,12 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Author's address: how@isl.stanford.edu -$Id: README,v 1.15 1992/05/20 00:25:32 how E $ - - -==>> To compile after untarring/unsharring, just `make' <<== +.. README,v 1.15 1992/05/20 00:25:32 how E +==>> To compile after untarring/unsharring, just ``make`` <<== This package was designed with the following goals: + 1. Highest possible encryption/decryption PERFORMANCE. 2. PORTABILITY to any byte-addressable host with a 32bit unsigned C type 3. Plug-compatible replacement for KERBEROS's low-level routines. @@ -36,7 +47,7 @@ register-starved machines. My discussions with Richard Outerbridge, 71755.204@compuserve.com, sparked a number of these enhancements. To more rapidly understand the code in this package, inspect desSmallFips.i -(created by typing `make') BEFORE you tackle desCode.h. The latter is set +(created by typing ``make``) BEFORE you tackle desCode.h. The latter is set up in a parameterized fashion so it can easily be modified by speed-daemon hackers in pursuit of that last microsecond. You will find it more illuminating to inspect one specific implementation, @@ -47,11 +58,13 @@ performance comparison to other available des code which i could compile on a SPARCStation 1 (cc -O4, gcc -O2): this code (byte-order independent): - 30us per encryption (options: 64k tables, no IP/FP) - 33us per encryption (options: 64k tables, FIPS standard bit ordering) - 45us per encryption (options: 2k tables, no IP/FP) - 48us per encryption (options: 2k tables, FIPS standard bit ordering) - 275us to set a new key (uses 1k of key tables) + + - 30us per encryption (options: 64k tables, no IP/FP) + - 33us per encryption (options: 64k tables, FIPS standard bit ordering) + - 45us per encryption (options: 2k tables, no IP/FP) + - 48us per encryption (options: 2k tables, FIPS standard bit ordering) + - 275us to set a new key (uses 1k of key tables) + this has the quickest encryption/decryption routines i've seen. since i was interested in fast des filters rather than crypt(3) and password cracking, i haven't really bothered yet to speed up @@ -63,15 +76,20 @@ this code (byte-order independent): are highly variable because of cache effects). kerberos des replacement from australia (version 1.95): - 53us per encryption (uses 2k of tables) - 96us to set a new key (uses 2.25k of key tables) + + - 53us per encryption (uses 2k of tables) + - 96us to set a new key (uses 2.25k of key tables) + so despite the author's inclusion of some of the performance improvements i had suggested to him, this package's encryption/decryption is still slower on the sparc and 68000. more specifically, 19-40% slower on the 68020 and 11-35% slower on the sparc, depending on the compiler; in full gory detail (ALT_ECB is a libdes variant): + + =============== ============== =============== ================= compiler machine desCore libdes ALT_ECB slower by + =============== ============== =============== ================= gcc 2.1 -O2 Sun 3/110 304 uS 369.5uS 461.8uS 22% cc -O1 Sun 3/110 336 uS 436.6uS 399.3uS 19% cc -O2 Sun 3/110 360 uS 532.4uS 505.1uS 40% @@ -79,10 +97,15 @@ kerberos des replacement from australia (version 1.95): gcc 2.1 -O2 Sun 4/50 48 uS 53.4uS 57.5uS 11% cc -O2 Sun 4/50 48 uS 64.6uS 64.7uS 35% cc -O4 Sun 4/50 48 uS 64.7uS 64.9uS 35% + =============== ============== =============== ================= + (my time measurements are not as accurate as his). + the comments in my first release of desCore on version 1.92: - 68us per encryption (uses 2k of tables) - 96us to set a new key (uses 2.25k of key tables) + + - 68us per encryption (uses 2k of tables) + - 96us to set a new key (uses 2.25k of key tables) + this is a very nice package which implements the most important of the optimizations which i did in my encryption routines. it's a bit weak on common low-level optimizations which is why @@ -91,48 +114,60 @@ kerberos des replacement from australia (version 1.95): speed up the key-setting routines with impressive results. (at some point i may do the same in my package). he also implements the rest of the mit des library. + (code from eay@psych.psy.uq.oz.au via comp.sources.misc) fast crypt(3) package from denmark: + the des routine here is buried inside a loop to do the crypt function and i didn't feel like ripping it out and measuring performance. his code takes 26 sparc instructions to compute one des iteration; above, Quick (64k) takes 21 and Small (2k) takes 37. he claims to use 280k of tables but the iteration calculation seems to use only 128k. his tables and code are machine independent. + (code from glad@daimi.aau.dk via alt.sources or comp.sources.misc) swedish reimplementation of Kerberos des library - 108us per encryption (uses 34k worth of tables) - 134us to set a new key (uses 32k of key tables to get this speed!) + + - 108us per encryption (uses 34k worth of tables) + - 134us to set a new key (uses 32k of key tables to get this speed!) + the tables used seem to be machine-independent; he seems to have included a lot of special case code - so that, e.g., `long' loads can be used instead of 4 `char' loads + so that, e.g., ``long`` loads can be used instead of 4 ``char`` loads when the machine's architecture allows it. + (code obtained from chalmers.se:pub/des) crack 3.3c package from england: + as in crypt above, the des routine is buried in a loop. it's also very modified for crypt. his iteration code uses 16k of tables and appears to be slow. + (code obtained from aem@aber.ac.uk via alt.sources or comp.sources.misc) -``highly optimized'' and tweaked Kerberos/Athena code (byte-order dependent): - 165us per encryption (uses 6k worth of tables) - 478us to set a new key (uses <1k of key tables) +``highly optimized`` and tweaked Kerberos/Athena code (byte-order dependent): + + - 165us per encryption (uses 6k worth of tables) + - 478us to set a new key (uses <1k of key tables) + so despite the comments in this code, it was possible to get faster code AND smaller tables, as well as making the tables machine-independent. (code obtained from prep.ai.mit.edu) UC Berkeley code (depends on machine-endedness): - 226us per encryption -10848us to set a new key + - 226us per encryption + - 10848us to set a new key + table sizes are unclear, but they don't look very small (code obtained from wuarchive.wustl.edu) motivation and history +====================== a while ago i wanted some des routines and the routines documented on sun's man pages either didn't exist or dumped core. i had heard of kerberos, @@ -142,10 +177,10 @@ it was too convoluted, the code had been written without taking advantage of the regular structure of operations such as IP, E, and FP (i.e. the author didn't sit down and think before coding), it was excessively slow, the author had attempted to clarify the code -by adding MORE statements to make the data movement more `consistent' +by adding MORE statements to make the data movement more ``consistent`` instead of simplifying his implementation and cutting down on all data movement (in particular, his use of L1, R1, L2, R2), and it was full of -idiotic `tweaks' for particular machines which failed to deliver significant +idiotic ``tweaks`` for particular machines which failed to deliver significant speedups but which did obfuscate everything. so i took the test data from his verification program and rewrote everything else. @@ -167,12 +202,13 @@ than versions hand-written in assembly for the sparc! porting notes +============= one thing i did not want to do was write an enormous mess which depended on endedness and other machine quirks, and which necessarily produced different code and different lookup tables for different machines. see the kerberos code for an example -of what i didn't want to do; all their endedness-specific `optimizations' +of what i didn't want to do; all their endedness-specific ``optimizations`` obfuscate the code and in the end were slower than a simpler machine independent approach. however, there are always some portability considerations of some kind, and i have included some options @@ -184,8 +220,8 @@ perhaps some will still regard the result as a mess! i assume word pointers can be freely cast to and from char pointers. note that 99% of C programs make these assumptions. i always use unsigned char's if the high bit could be set. -2) the typedef `word' means a 32 bit unsigned integral type. - if `unsigned long' is not 32 bits, change the typedef in desCore.h. +2) the typedef ``word`` means a 32 bit unsigned integral type. + if ``unsigned long`` is not 32 bits, change the typedef in desCore.h. i assume sizeof(word) == 4 EVERYWHERE. the (worst-case) cost of my NOT doing endedness-specific optimizations @@ -195,40 +231,46 @@ the input and output work areas do not need to be word-aligned. OPTIONAL performance optimizations +================================== -1) you should define one of `i386,' `vax,' `mc68000,' or `sparc,' +1) you should define one of ``i386,`` ``vax,`` ``mc68000,`` or ``sparc,`` whichever one is closest to the capabilities of your machine. see the start of desCode.h to see exactly what this selection implies. note that if you select the wrong one, the des code will still work; these are just performance tweaks. -2) for those with functional `asm' keywords: you should change the +2) for those with functional ``asm`` keywords: you should change the ROR and ROL macros to use machine rotate instructions if you have them. this will save 2 instructions and a temporary per use, or about 32 to 40 instructions per en/decryption. + note that gcc is smart enough to translate the ROL/R macros into machine rotates! these optimizations are all rather persnickety, yet with them you should be able to get performance equal to assembly-coding, except that: + 1) with the lack of a bit rotate operator in C, rotates have to be synthesized - from shifts. so access to `asm' will speed things up if your machine + from shifts. so access to ``asm`` will speed things up if your machine has rotates, as explained above in (3) (not necessary if you use gcc). 2) if your machine has less than 12 32-bit registers i doubt your compiler will generate good code. - `i386' tries to configure the code for a 386 by only declaring 3 registers + + ``i386`` tries to configure the code for a 386 by only declaring 3 registers (it appears that gcc can use ebx, esi and edi to hold register variables). however, if you like assembly coding, the 386 does have 7 32-bit registers, - and if you use ALL of them, use `scaled by 8' address modes with displacement + and if you use ALL of them, use ``scaled by 8`` address modes with displacement and other tricks, you can get reasonable routines for DesQuickCore... with about 250 instructions apiece. For DesSmall... it will help to rearrange des_keymap, i.e., now the sbox # is the high part of the index and the 6 bits of data is the low part; it helps to exchange these. + since i have no way to conveniently test it i have not provided my shoehorned 386 version. note that with this release of desCore, gcc is able to put everything in registers(!), and generate about 370 instructions apiece for the DesQuickCore... routines! coding notes +============ the en/decryption routines each use 6 necessary register variables, with 4 being actively used at once during the inner iterations. @@ -236,15 +278,18 @@ if you don't have 4 register variables get a new machine. up to 8 more registers are used to hold constants in some configurations. i assume that the use of a constant is more expensive than using a register: + a) additionally, i have tried to put the larger constants in registers. registering priority was by the following: - anything more than 12 bits (bad for RISC and CISC) - greater than 127 in value (can't use movq or byte immediate on CISC) - 9-127 (may not be able to use CISC shift immediate or add/sub quick), - 1-8 were never registered, being the cheapest constants. + + - anything more than 12 bits (bad for RISC and CISC) + - greater than 127 in value (can't use movq or byte immediate on CISC) + - 9-127 (may not be able to use CISC shift immediate or add/sub quick), + - 1-8 were never registered, being the cheapest constants. + b) the compiler may be too stupid to realize table and table+256 should be assigned to different constant registers and instead repetitively - do the arithmetic, so i assign these to explicit `m' register variables + do the arithmetic, so i assign these to explicit ``m`` register variables when possible and helpful. i assume that indexing is cheaper or equivalent to auto increment/decrement, @@ -253,25 +298,31 @@ this assumption is reversed for 68k and vax. i assume that addresses can be cheaply formed from two registers, or from a register and a small constant. -for the 68000, the `two registers and small offset' form is used sparingly. +for the 68000, the ``two registers and small offset`` form is used sparingly. all index scaling is done explicitly - no hidden shifts by log2(sizeof). the code is written so that even a dumb compiler should never need more than one hidden temporary, increasing the chance that everything will fit in the registers. KEEP THIS MORE SUBTLE POINT IN MIND IF YOU REWRITE ANYTHING. + (actually, there are some code fragments now which do require two temps, but fixing it would either break the structure of the macros or require declaring another temporary). special efficient data format +============================== + +bits are manipulated in this arrangement most of the time (S7 S5 S3 S1):: -bits are manipulated in this arrangement most of the time (S7 S5 S3 S1): 003130292827xxxx242322212019xxxx161514131211xxxx080706050403xxxx + (the x bits are still there, i'm just emphasizing where the S boxes are). -bits are rotated left 4 when computing S6 S4 S2 S0: +bits are rotated left 4 when computing S6 S4 S2 S0:: + 282726252423xxxx201918171615xxxx121110090807xxxx040302010031xxxx + the rightmost two bits are usually cleared so the lower byte can be used as an index into an sbox mapping table. the next two x'd bits are set to various values to access different parts of the tables. @@ -288,7 +339,7 @@ datatypes: must be long-aligned. DesQuickInit() - call this before using any other routine with `Quick' in its name. + call this before using any other routine with ``Quick`` in its name. it generates the special 64k table these routines need. DesQuickDone() frees this table @@ -298,6 +349,7 @@ DesMethod(m, k) which must have odd parity (or -1 is returned) and which must not be a (semi-)weak key (or -2 is returned). normally DesMethod() returns 0. + m is filled in from k so that when one of the routines below is called with m, the routine will act like standard des en/decryption with the key k. if you use DesMethod, @@ -308,19 +360,26 @@ DesMethod(m, k) will be set to magic constants which speed up the encryption/decryption on some machines. and yes, each byte controls a specific sbox during a specific iteration. + you really shouldn't use the 768bit format directly; i should provide a routine that converts 128 6-bit bytes (specified in S-box mapping order or something) into the right format for you. this would entail some byte concatenation and rotation. Des{Small|Quick}{Fips|Core}{Encrypt|Decrypt}(d, m, s) - performs des on the 8 bytes at s into the 8 bytes at d. (d,s: char *). + performs des on the 8 bytes at s into the 8 bytes at + ``d. (d,s: char *)``. + uses m as a 768bit key as explained above. + the Encrypt|Decrypt choice is obvious. + Fips|Core determines whether a completely standard FIPS initial and final permutation is done; if not, then the data is loaded and stored in a nonstandard bit order (FIPS w/o IP/FP). + Fips slows down Quick by 10%, Small by 9%. + Small|Quick determines whether you use the normal routine or the crazy quick one which gobbles up 64k more of memory. Small is 50% slower then Quick, but Quick needs 32 times as much @@ -329,15 +388,17 @@ Des{Small|Quick}{Fips|Core}{Encrypt|Decrypt}(d, m, s) Getting it to compile on your machine +===================================== there are no machine-dependencies in the code (see porting), -except perhaps the `now()' macro in desTest.c. +except perhaps the ``now()`` macro in desTest.c. ALL generated tables are machine independent. you should edit the Makefile with the appropriate optimization flags for your compiler (MAX optimization). Speeding up kerberos (and/or its des library) +============================================= note that i have included a kerberos-compatible interface in desUtil.c through the functions des_key_sched() and des_ecb_encrypt(). @@ -347,6 +408,7 @@ you should not need to #include desCore.h; just include the header file provided with the kerberos library. Other uses +========== the macros in desCode.h would be very useful for putting inline des functions in more complicated encryption routines. diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst index c4ff5d791233..21338fa92642 100644 --- a/Documentation/crypto/index.rst +++ b/Documentation/crypto/index.rst @@ -17,9 +17,14 @@ for cryptographic use cases, as well as programming examples. :maxdepth: 2 intro + api-intro architecture + + async-tx-api + asymmetric-keys devel-algos userspace-if crypto_engine api api-samples + descore-readme diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst index ff86befa61e0..52019e905900 100644 --- a/Documentation/crypto/userspace-if.rst +++ b/Documentation/crypto/userspace-if.rst @@ -23,7 +23,7 @@ user space, however. This includes the difference between synchronous and asynchronous invocations. The user space API call is fully synchronous. -[1] http://www.chronox.de/libkcapi.html +[1] https://www.chronox.de/libkcapi.html User Space API General Remarks ------------------------------ @@ -384,4 +384,4 @@ Please see [1] for libkcapi which provides an easy-to-use wrapper around the aforementioned Netlink kernel interface. [1] also contains a test application that invokes all libkcapi API calls. -[1] http://www.chronox.de/libkcapi.html +[1] https://www.chronox.de/libkcapi.html diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 70274c3f5f5a..6c791af1c859 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -85,7 +85,7 @@ Four basic modes are defined: ``patch``, ``report``, ``context``, and file:line:column-column: message - ``context`` highlights lines of interest and their context in a - diff-like style.Lines of interest are indicated with ``-``. + diff-like style. Lines of interest are indicated with ``-``. - ``org`` generates a report in the Org mode format of Emacs. @@ -119,7 +119,7 @@ For each semantic patch, a commit message is proposed. It gives a description of the problem being checked by the semantic patch, and includes a reference to Coccinelle. -As any static code analyzer, Coccinelle produces false +As with any static code analyzer, Coccinelle produces false positives. Thus, reports must be carefully checked, and patches reviewed. @@ -135,18 +135,18 @@ the parallelism, set the J= variable. For example, to run across 4 CPUs:: make coccicheck MODE=report J=4 -As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization, +As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization; if support for this is detected you will benefit from parmap parallelization. When parmap is enabled coccicheck will enable dynamic load balancing by using -``--chunksize 1`` argument, this ensures we keep feeding threads with work +``--chunksize 1`` argument. This ensures we keep feeding threads with work one by one, so that we avoid the situation where most work gets done by only a few threads. With dynamic load balancing, if a thread finishes early we keep feeding it more work. When parmap is enabled, if an error occurs in Coccinelle, this error -value is propagated back, the return value of the ``make coccicheck`` -captures this return value. +value is propagated back, and the return value of the ``make coccicheck`` +command captures this return value. Using Coccinelle with a single semantic patch --------------------------------------------- @@ -183,7 +183,7 @@ To check only newly edited code, use the value 2 for the C flag, i.e.:: make C=2 CHECK="scripts/coccicheck" -In these modes, which works on a file basis, there is no information +In these modes, which work on a file basis, there is no information about semantic patches displayed, and no commit message proposed. This runs every semantic patch in scripts/coccinelle by default. The @@ -198,12 +198,12 @@ Debugging Coccinelle SmPL patches Using coccicheck is best as it provides in the spatch command line include options matching the options used when we compile the kernel. -You can learn what these options are by using V=1, you could then +You can learn what these options are by using V=1; you could then manually run Coccinelle with debug options added. Alternatively you can debug running Coccinelle against SmPL patches -by asking for stderr to be redirected to stderr, by default stderr -is redirected to /dev/null, if you'd like to capture stderr you +by asking for stderr to be redirected to stderr. By default stderr +is redirected to /dev/null; if you'd like to capture stderr you can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For instance:: @@ -211,8 +211,8 @@ instance:: make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err cat cocci.err -You can use SPFLAGS to add debugging flags, for instance you may want to -add both --profile --show-trying to SPFLAGS when debugging. For instance +You can use SPFLAGS to add debugging flags; for instance you may want to +add both --profile --show-trying to SPFLAGS when debugging. For example you may want to use:: rm -f err.log @@ -229,7 +229,7 @@ DEBUG_FILE support is only supported when using coccinelle >= 1.0.2. -------------------- Coccinelle supports reading .cocciconfig for default Coccinelle options that -should be used every time spatch is spawned, the order of precedence for +should be used every time spatch is spawned. The order of precedence for variables for .cocciconfig is as follows: - Your current user's home directory is processed first @@ -237,7 +237,7 @@ variables for .cocciconfig is as follows: - The directory provided with the --dir option is processed last, if used Since coccicheck runs through make, it naturally runs from the kernel -proper dir, as such the second rule above would be implied for picking up a +proper dir; as such the second rule above would be implied for picking up a .cocciconfig when using ``make coccicheck``. ``make coccicheck`` also supports using M= targets. If you do not supply @@ -260,13 +260,13 @@ If not using the kernel's coccicheck target, keep the above precedence order logic of .cocciconfig reading. If using the kernel's coccicheck target, override any of the kernel's .coccicheck's settings using SPFLAGS. -We help Coccinelle when used against Linux with a set of sensible defaults +We help Coccinelle when used against Linux with a set of sensible default options for Linux with our own Linux .cocciconfig. This hints to coccinelle -git can be used for ``git grep`` queries over coccigrep. A timeout of 200 +that git can be used for ``git grep`` queries over coccigrep. A timeout of 200 seconds should suffice for now. The options picked up by coccinelle when reading a .cocciconfig do not appear -as arguments to spatch processes running on your system, to confirm what +as arguments to spatch processes running on your system. To confirm what options will be used by Coccinelle run:: spatch --print-options-only @@ -290,7 +290,7 @@ given to it when options are in conflict. :: Coccinelle supports idutils as well but requires coccinelle >= 1.0.6. When no ID file is specified coccinelle assumes your ID database file -is in the file .id-utils.index on the top level of the kernel, coccinelle +is in the file .id-utils.index on the top level of the kernel. Coccinelle carries a script scripts/idutils_index.sh which creates the database with:: mkid -i C --output .id-utils.index @@ -317,7 +317,7 @@ SmPL patch specific options --------------------------- SmPL patches can have their own requirements for options passed -to Coccinelle. SmPL patch specific options can be provided by +to Coccinelle. SmPL patch-specific options can be provided by providing them at the top of the SmPL patch, for instance:: // Options: --no-includes --include-headers @@ -327,7 +327,7 @@ SmPL patch Coccinelle requirements As Coccinelle features get added some more advanced SmPL patches may require newer versions of Coccinelle. If an SmPL patch requires -at least a version of Coccinelle, this can be specified as follows, +a minimum version of Coccinelle, this can be specified as follows, as an example if requiring at least Coccinelle >= 1.0.5:: // Requires: 1.0.5 diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst index 7bd013596217..9e989baae154 100644 --- a/Documentation/dev-tools/gcov.rst +++ b/Documentation/dev-tools/gcov.rst @@ -22,7 +22,7 @@ Possible uses: * minimizing kernel configurations (do I need this option if the associated code is never run?) -.. _gcov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html +.. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html .. _lcov: http://ltp.sourceforge.net/coverage/lcov.php @@ -171,7 +171,7 @@ Note on compilers GCC and LLVM gcov tools are not necessarily compatible. Use gcov_ to work with GCC-generated .gcno and .gcda files, and use llvm-cov_ for Clang. -.. _gcov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html +.. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html .. _llvm-cov: https://llvm.org/docs/CommandGuide/llvm-cov.html Build differences between GCC and Clang gcov are handled by Kconfig. It diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index b38379f06194..be7a0b0e1f28 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -8,7 +8,8 @@ approach to detect races. KCSAN's primary purpose is to detect `data races`_. Usage ----- -KCSAN requires Clang version 11 or later. +KCSAN is supported by both GCC and Clang. With GCC we require version 11 or +later, and with Clang also require version 11 or later. To enable KCSAN configure the kernel with:: diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/dev-tools/kgdb.rst index 61293f40bc6e..0e52e966a153 100644 --- a/Documentation/dev-tools/kgdb.rst +++ b/Documentation/dev-tools/kgdb.rst @@ -872,7 +872,7 @@ The kgdboc driver contains logic to configure communications with an attached keyboard. The keyboard infrastructure is only compiled into the kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration. -The core polled keyboard driver driver for PS/2 type keyboards is in +The core polled keyboard driver for PS/2 type keyboards is in ``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core when kgdboc populates the callback in the array called :c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst index fce262883984..a41a2d238af2 100644 --- a/Documentation/dev-tools/kmemleak.rst +++ b/Documentation/dev-tools/kmemleak.rst @@ -8,8 +8,6 @@ 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 user-space applications. -Kmemleak is supported on x86, arm, arm64, powerpc, sparc, sh, microblaze, mips, -s390, nds32, arc and xtensa. Usage ----- diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 949af2da81e5..29ae2fee8123 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -19,13 +19,13 @@ compiles the kernel as a standalone Linux executable that can be run like any other program directly inside of a host operating system. To be clear, it does not require any virtualization support: it is just a regular program. -What is a kunitconfig? -====================== +What is a .kunitconfig? +======================= It's just a defconfig that kunit_tool looks for in the base directory. kunit_tool uses it to generate a .config as you might expect. In addition, it verifies that the generated .config contains the CONFIG options in the -kunitconfig; the reason it does this is so that it is easy to be sure that a +.kunitconfig; the reason it does this is so that it is easy to be sure that a CONFIG that enables a test actually ends up in the .config. How do I use kunit_tool? @@ -46,16 +46,9 @@ However, you most likely want to use it with the following options: - ``--timeout`` sets a maximum amount of time to allow tests to run. - ``--jobs`` sets the number of threads to use to build the kernel. -If you just want to use the defconfig that ships with the kernel, you can -append the ``--defconfig`` flag as well: - -.. code-block:: bash - - ./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all` --defconfig - .. note:: - This command is particularly helpful for getting started because it - just works. No kunitconfig needs to be present. + This command will work even without a .kunitconfig file: if no + .kunitconfig is present, a default one will be used instead. For a list of all the flags supported by kunit_tool, you can run: diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index bb112cf70624..d23385e3e159 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -18,7 +18,7 @@ The wrapper can be run with: .. code-block:: bash - ./tools/testing/kunit/kunit.py run --defconfig + ./tools/testing/kunit/kunit.py run For more information on this wrapper (also called kunit_tool) check out the :doc:`kunit-tool` page. diff --git a/Documentation/dev-tools/sparse.rst b/Documentation/dev-tools/sparse.rst index 6f4870528226..02102be7ff49 100644 --- a/Documentation/dev-tools/sparse.rst +++ b/Documentation/dev-tools/sparse.rst @@ -9,6 +9,8 @@ Sparse is a semantic checker for C programs; it can be used to find a number of potential problems with kernel code. See https://lwn.net/Articles/689907/ for an overview of sparse; this document contains some kernel-specific sparse information. +More information on sparse, mainly about its internals, can be found in +its official pages at https://sparse.docs.kernel.org. Using sparse for typechecking @@ -73,8 +75,8 @@ sparse would otherwise report a context imbalance. Getting sparse -------------- -You can get latest released versions from the Sparse homepage at -https://sparse.wiki.kernel.org/index.php/Main_Page +You can get tarballs of the latest released versions from: +https://www.kernel.org/pub/software/devel/sparse/dist/ Alternatively, you can get snapshots of the latest development version of sparse using git to clone:: diff --git a/Documentation/devicetree/bindings/arm/al,alpine.yaml b/Documentation/devicetree/bindings/arm/al,alpine.yaml deleted file mode 100644 index a70dff277e05..000000000000 --- a/Documentation/devicetree/bindings/arm/al,alpine.yaml +++ /dev/null @@ -1,21 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/arm/al,alpine.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Annapurna Labs Alpine Platform Device Tree Bindings - -maintainers: - - Tsahee Zidenberg - - Antoine Tenart - -properties: - compatible: - items: - - const: al,alpine - model: - items: - - const: "Annapurna Labs Alpine Dev Board" - -... diff --git a/Documentation/devicetree/bindings/arm/amazon,al.yaml b/Documentation/devicetree/bindings/arm/amazon,al.yaml new file mode 100644 index 000000000000..a3a4d710bd02 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amazon,al.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/amazon,al.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amazon's Annapurna Labs Alpine Platform Device Tree Bindings + +maintainers: + - Hanna Hawa + - Talel Shenhar , + - Ronen Krupnik + +properties: + compatible: + oneOf: + - description: Boards with Alpine V1 SoC + items: + - const: al,alpine + + - description: Boards with Alpine V2 SoC + items: + - enum: + - al,alpine-v2-evp + - const: al,alpine-v2 + + - description: Boards with Alpine V3 SoC + items: + - enum: + - amazon,al-alpine-v3-evp + - const: amazon,al-alpine-v3 + +... diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 378229fa8310..5eba9f48823e 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -121,6 +121,7 @@ properties: - libretech,aml-s912-pc - nexbox,a1 - tronsmart,vega-s96 + - wetek,core2 - const: amlogic,s912 - const: amlogic,meson-gxm diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index 846f6daae71b..d711676b4a51 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -108,6 +108,13 @@ its hardware characteristcs. * arm,cp14: must be present if the system accesses ETM/PTM management registers via co-processor 14. + * qcom,skip-power-up: boolean. Indicates that an implementation can + skip powering up the trace unit. TRCPDCR.PU does not have to be set + on Qualcomm Technologies Inc. systems since ETMs are in the same power + domain as their CPU cores. This property is required to identify such + systems with hardware errata where the CPU watchdog counter is stopped + when TRCPDCR.PU is set. + * Optional property for TMC: * arm,buffer-size: size of contiguous buffer space for TMC ETR @@ -121,6 +128,12 @@ its hardware characteristcs. * interrupts : Exactly one SPI may be listed for reporting the address error +* Optional property for configurable replicators: + + * qcom,replicator-loses-context: boolean. Indicates that the replicator + will lose register context when AMBA clock is removed which is observed + in some replicator designs. + Graph bindings for Coresight ------------------------------- diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05906e291e38..f63895c8ce2d 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -120,6 +120,8 @@ properties: - fsl,imx6q-sabrelite - fsl,imx6q-sabresd - kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module + - prt,prti6q # Protonic PRTI6Q board + - prt,prtwd2 # Protonic WD2 board - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph @@ -172,6 +174,8 @@ properties: - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board - fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - prt,prtrvt # Protonic RVT board + - prt,prtvt7 # Protonic VT7 board - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph @@ -268,6 +272,7 @@ properties: - armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board - fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board - kontron,imx6ull-n6411-som # Kontron N6411 SOM + - myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board - toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / Bluetooth Module on Colibri Evaluation Board - const: fsl,imx6ull diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml new file mode 100644 index 000000000000..4d925785f504 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/intel,keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Keem Bay platform device tree bindings + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +properties: + compatible: + items: + - enum: + - intel,keembay-evm + - const: intel,keembay +... diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index abc544dde692..30908963ae26 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -114,4 +114,9 @@ properties: - enum: - mediatek,mt8183-evb - const: mediatek,mt8183 + - description: Google Krane (Lenovo IdeaPad Duet, 10e,...) + items: + - const: google,krane-sku176 + - const: google,krane + - const: mediatek,mt8183 ... diff --git a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml new file mode 100644 index 000000000000..ecf6fa12e6ad --- /dev/null +++ b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 Boards Device Tree Bindings + +maintainers: + - Lars Povlsen + +description: |+ + The Microchip Sparx5 SoC is a ARMv8-based used in a family of + gigabit TSN-capable gigabit switches. + + The SparX-5 Ethernet switch family provides a rich set of switching + features such as advanced TCAM-based VLAN and QoS processing + enabling delivery of differentiated services, and security through + TCAM-based frame processing using versatile content aware processor + (VCAP) + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: The Sparx5 pcb125 board is a modular board, + which has both spi-nor and eMMC storage. The modular design + allows for connection of different network ports. + items: + - const: microchip,sparx5-pcb125 + - const: microchip,sparx5 + + - description: The Sparx5 pcb134 is a pizzabox form factor + gigabit switch with 20 SFP ports. It features spi-nor and + either spi-nand or eMMC storage (mount option). + items: + - const: microchip,sparx5-pcb134 + - const: microchip,sparx5 + + - description: The Sparx5 pcb135 is a pizzabox form factor + gigabit switch with 48+4 Cu ports. It features spi-nor and + either spi-nand or eMMC storage (mount option). + items: + - const: microchip,sparx5-pcb135 + - const: microchip,sparx5 + + axi@600000000: + type: object + description: the root node in the Sparx5 platforms must contain + an axi bus child node. They are always at physical address + 0x600000000 in all the Sparx5 variants. + properties: + compatible: + items: + - const: simple-bus + + required: + - compatible + +required: + - compatible + - axi@600000000 + +... diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml new file mode 100644 index 000000000000..6816bd68f9cf --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mstar/mstar,l3bridge.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 thingy.jp. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mstar/mstar,l3bridge.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MStar/SigmaStar Armv7 SoC l3bridge + +maintainers: + - Daniel Palmer + +description: | + MStar/SigmaStar's Armv7 SoCs have a pipeline in the interface + between the CPU and memory. This means that before DMA capable + devices are allowed to run the pipeline must be flushed to ensure + everything is in memory. + + The l3bridge region contains registers that allow such a flush + to be triggered. + + This node is used by the platform code to find where the registers + are and install a barrier that triggers the required pipeline flush. + +properties: + compatible: + items: + - const: mstar,l3bridge + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + l3bridge: l3bridge@1f204400 { + compatible = "mstar,l3bridge"; + reg = <0x1f204400 0x200>; + }; diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml new file mode 100644 index 000000000000..c2f980b00b06 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/mstar/mstar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar platforms device tree bindings + +maintainers: + - Daniel Palmer + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: infinity boards + items: + - enum: + - thingyjp,breadbee-crust # thingy.jp BreadBee Crust + - const: mstar,infinity + + - description: infinity3 boards + items: + - enum: + - thingyjp,breadbee # thingy.jp BreadBee + - const: mstar,infinity3 + + - description: mercury5 boards + items: + - enum: + - 70mai,midrived08 # 70mai midrive d08 + - const: mstar,mercury5 diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index b7d2e921150a..0d4dabb4a164 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -118,6 +118,7 @@ properties: items: - enum: - hoperun,hihope-rzg2m # HopeRun HiHope RZ/G2M platform + - beacon,beacon-rzg2m # Beacon EmbeddedWorks RZ/G2M Kit - const: renesas,r8a774a1 - items: @@ -150,6 +151,18 @@ properties: - const: si-linux,cat874 - const: renesas,r8a774c0 + - description: RZ/G2H (R8A774E1) + items: + - enum: + - hoperun,hihope-rzg2h # HopeRun HiHope RZ/G2H platform + - const: renesas,r8a774e1 + + - items: + - enum: + - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms + - const: hoperun,hihope-rzg2h + - const: renesas,r8a774e1 + - description: R-Car M1A (R8A77781) items: - enum: diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index d4a4045092df..db2e35796795 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -435,6 +435,12 @@ properties: - const: radxa,rockpi4 - const: rockchip,rk3399 + - description: Radxa ROCK Pi N8 + items: + - const: radxa,rockpi-n8 + - const: vamrs,rk3288-vmarc-som + - const: rockchip,rk3288 + - description: Radxa ROCK Pi N10 items: - const: radxa,rockpi-n10 diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index cf5db5e273f3..6f1cd0103c74 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -16,6 +16,9 @@ properties: - items: - enum: - st,stm32mp157-syscfg + - st,stm32mp151-pwr-mcu + - st,stm32-syscfg + - st,stm32-power-config - const: syscon reg: @@ -27,7 +30,16 @@ properties: required: - compatible - reg - - clocks + +if: + properties: + compatible: + contains: + enum: + - st,stm32mp157-syscfg +then: + required: + - clocks additionalProperties: false diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 87817ff0cd35..efc9118233b4 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -657,6 +657,11 @@ properties: - const: pine64,pinephone-1.1 - const: allwinner,sun50i-a64 + - description: Pine64 PinePhone (1.2) + items: + - const: pine64,pinephone-1.2 + - const: allwinner,sun50i-a64 + - description: Pine64 PineTab items: - const: pine64,pinetab diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 60b38eb5c61a..e0b3debaee9e 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -34,6 +34,9 @@ properties: - toradex,colibri_t20-iris - const: toradex,colibri_t20 - const: nvidia,tegra20 + - items: + - const: acer,picasso + - const: nvidia,tegra20 - items: - enum: - nvidia,beaver @@ -59,6 +62,13 @@ properties: - toradex,colibri_t30-eval-v3 - const: toradex,colibri_t30 - const: nvidia,tegra30 + - items: + - const: asus,grouper + - const: nvidia,tegra30 + - items: + - const: asus,tilapia + - const: asus,grouper + - const: nvidia,tegra30 - items: - enum: - nvidia,dalmore @@ -101,3 +111,11 @@ properties: - enum: - nvidia,p2972-0000 - const: nvidia,tegra194 + - description: Jetson Xavier NX + items: + - const: nvidia,p3668-0000 + - const: nvidia,tegra194 + - description: Jetson Xavier NX Developer Kit + items: + - const: nvidia,p3509-0000+p3668-0000 + - const: nvidia,tegra194 diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml b/Documentation/devicetree/bindings/clock/imx35-clock.yaml index bd871da6fc7c..3e20ccaf8131 100644 --- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml @@ -130,7 +130,7 @@ examples: #clock-cells = <1>; }; - esdhc@53fb4000 { + mmc@53fb4000 { compatible = "fsl,imx35-esdhc"; reg = <0x53fb4000 0x4000>; interrupts = <7>; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt deleted file mode 100644 index 93d89adb7afe..000000000000 --- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt +++ /dev/null @@ -1,103 +0,0 @@ -* Clock bindings for Freescale i.MX7ULP - -i.MX7ULP Clock functions are under joint control of the System -Clock Generation (SCG) modules, Peripheral Clock Control (PCC) -modules, and Core Mode Controller (CMC)1 blocks - -The clocking scheme provides clear separation between M4 domain -and A7 domain. Except for a few clock sources shared between two -domains, such as the System Oscillator clock, the Slow IRC (SIRC), -and and the Fast IRC clock (FIRCLK), clock sources and clock -management are separated and contained within each domain. - -M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules. -A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules. - -Note: this binding doc is only for A7 clock domain. - -System Clock Generation (SCG) modules: ---------------------------------------------------------------------- -The System Clock Generation (SCG) is responsible for clock generation -and distribution across this device. Functions performed by the SCG -include: clock reference selection, generation of clock used to derive -processor, system, peripheral bus and external memory interface clocks, -source selection for peripheral clocks and control of power saving -clock gating mode. - -Required properties: - -- compatible: Should be "fsl,imx7ulp-scg1". -- reg : Should contain registers location and length. -- #clock-cells: Should be <1>. -- clocks: Should contain the fixed input clocks. -- clock-names: Should contain the following clock names: - "rosc", "sosc", "sirc", "firc", "upll", "mpll". - -Peripheral Clock Control (PCC) modules: ---------------------------------------------------------------------- -The Peripheral Clock Control (PCC) is responsible for clock selection, -optional division and clock gating mode for peripherals in their -respected power domain - -Required properties: -- compatible: Should be one of: - "fsl,imx7ulp-pcc2", - "fsl,imx7ulp-pcc3". -- reg : Should contain registers location and length. -- #clock-cells: Should be <1>. -- clocks: Should contain the fixed input clocks. -- clock-names: Should contain the following clock names: - "nic1_bus_clk", "nic1_clk", "ddr_clk", "apll_pfd2", - "apll_pfd1", "apll_pfd0", "upll", "sosc_bus_clk", - "mpll", "firc_bus_clk", "rosc", "spll_bus_clk"; - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. -See include/dt-bindings/clock/imx7ulp-clock.h -for the full list of i.MX7ULP clock IDs of each module. - -Examples: - -#include - -scg1: scg1@403e0000 { - compatible = "fsl,imx7ulp-scg1; - reg = <0x403e0000 0x10000>; - clocks = <&rosc>, <&sosc>, <&sirc>, - <&firc>, <&upll>, <&mpll>; - clock-names = "rosc", "sosc", "sirc", - "firc", "upll", "mpll"; - #clock-cells = <1>; -}; - -pcc2: pcc2@403f0000 { - compatible = "fsl,imx7ulp-pcc2"; - reg = <0x403f0000 0x10000>; - #clock-cells = <1>; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&scg1 IMX7ULP_CLK_DDR_DIV>, - <&scg1 IMX7ULP_CLK_APLL_PFD2>, - <&scg1 IMX7ULP_CLK_APLL_PFD1>, - <&scg1 IMX7ULP_CLK_APLL_PFD0>, - <&scg1 IMX7ULP_CLK_UPLL>, - <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>, - <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>, - <&scg1 IMX7ULP_CLK_ROSC>, - <&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>; - clock-names = "nic1_bus_clk", "nic1_clk", "ddr_clk", - "apll_pfd2", "apll_pfd1", "apll_pfd0", - "upll", "sosc_bus_clk", "mpll", - "firc_bus_clk", "rosc", "spll_bus_clk"; -}; - -usdhc1: usdhc@40380000 { - compatible = "fsl,imx7ulp-usdhc"; - reg = <0x40380000 0x10000>; - interrupts = ; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&pcc2 IMX7ULP_CLK_USDHC1>; - clock-names ="ipg", "ahb", "per"; - bus-width = <4>; -}; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml new file mode 100644 index 000000000000..7caf5cee9199 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx7ulp-pcc-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX7ULP Peripheral Clock Control (PCC) modules + +maintainers: + - A.s. Dong + +description: | + i.MX7ULP Clock functions are under joint control of the System + Clock Generation (SCG) modules, Peripheral Clock Control (PCC) + modules, and Core Mode Controller (CMC)1 blocks + + The clocking scheme provides clear separation between M4 domain + and A7 domain. Except for a few clock sources shared between two + domains, such as the System Oscillator clock, the Slow IRC (SIRC), + and and the Fast IRC clock (FIRCLK), clock sources and clock + management are separated and contained within each domain. + + M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules. + A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules. + + Note: this binding doc is only for A7 clock domain. + + The Peripheral Clock Control (PCC) is responsible for clock selection, + optional division and clock gating mode for peripherals in their + respected power domain. + + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/imx7ulp-clock.h for the full list of + i.MX7ULP clock IDs of each module. + +properties: + compatible: + enum: + - fsl,imx7ulp-pcc2 + - fsl,imx7ulp-pcc3 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: nic1 bus clock + - description: nic1 clock + - description: ddr clock + - description: apll pfd2 + - description: apll pfd1 + - description: apll pfd0 + - description: usb pll + - description: system osc bus clock + - description: fast internal reference clock bus + - description: rtc osc + - description: system pll bus clock + + clock-names: + items: + - const: nic1_bus_clk + - const: nic1_clk + - const: ddr_clk + - const: apll_pfd2 + - const: apll_pfd1 + - const: apll_pfd0 + - const: upll + - const: sosc_bus_clk + - const: firc_bus_clk + - const: rosc + - const: spll_bus_clk + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + + clock-controller@403f0000 { + compatible = "fsl,imx7ulp-pcc2"; + reg = <0x403f0000 0x10000>; + #clock-cells = <1>; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&scg1 IMX7ULP_CLK_NIC1_DIV>, + <&scg1 IMX7ULP_CLK_DDR_DIV>, + <&scg1 IMX7ULP_CLK_APLL_PFD2>, + <&scg1 IMX7ULP_CLK_APLL_PFD1>, + <&scg1 IMX7ULP_CLK_APLL_PFD0>, + <&scg1 IMX7ULP_CLK_UPLL>, + <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>, + <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>, + <&scg1 IMX7ULP_CLK_ROSC>, + <&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>; + clock-names = "nic1_bus_clk", "nic1_clk", "ddr_clk", + "apll_pfd2", "apll_pfd1", "apll_pfd0", + "upll", "sosc_bus_clk", "firc_bus_clk", + "rosc", "spll_bus_clk"; + }; + + mmc@40380000 { + compatible = "fsl,imx7ulp-usdhc"; + reg = <0x40380000 0x10000>; + interrupts = ; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&scg1 IMX7ULP_CLK_NIC1_DIV>, + <&pcc2 IMX7ULP_CLK_USDHC1>; + clock-names ="ipg", "ahb", "per"; + bus-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml new file mode 100644 index 000000000000..ee8efb4ed599 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx7ulp-scg-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX7ULP System Clock Generation (SCG) modules + +maintainers: + - A.s. Dong + +description: | + i.MX7ULP Clock functions are under joint control of the System + Clock Generation (SCG) modules, Peripheral Clock Control (PCC) + modules, and Core Mode Controller (CMC)1 blocks + + The clocking scheme provides clear separation between M4 domain + and A7 domain. Except for a few clock sources shared between two + domains, such as the System Oscillator clock, the Slow IRC (SIRC), + and and the Fast IRC clock (FIRCLK), clock sources and clock + management are separated and contained within each domain. + + M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules. + A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules. + + Note: this binding doc is only for A7 clock domain. + + The System Clock Generation (SCG) is responsible for clock generation + and distribution across this device. Functions performed by the SCG + include: clock reference selection, generation of clock used to derive + processor, system, peripheral bus and external memory interface clocks, + source selection for peripheral clocks and control of power saving + clock gating mode. + + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/imx7ulp-clock.h for the full list of + i.MX7ULP clock IDs of each module. + +properties: + compatible: + const: fsl,imx7ulp-scg1 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: rtc osc + - description: system osc + - description: slow internal reference clock + - description: fast internal reference clock + - description: usb PLL + + clock-names: + items: + - const: rosc + - const: sosc + - const: sirc + - const: firc + - const: upll + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + + clock-controller@403e0000 { + compatible = "fsl,imx7ulp-scg1"; + reg = <0x403e0000 0x10000>; + clocks = <&rosc>, <&sosc>, <&sirc>, + <&firc>, <&upll>; + clock-names = "rosc", "sosc", "sirc", + "firc", "upll"; + #clock-cells = <1>; + }; + + mmc@40380000 { + compatible = "fsl,imx7ulp-usdhc"; + reg = <0x40380000 0x10000>; + interrupts = ; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&scg1 IMX7ULP_CLK_NIC1_DIV>, + <&pcc2 IMX7ULP_CLK_USDHC1>; + clock-names ="ipg", "ahb", "per"; + bus-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index 33f3010f48c3..1d5e9bcce4c8 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -62,7 +62,7 @@ examples: }; mmc@5b010000 { - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; + compatible = "fsl,imx8qxp-usdhc"; interrupts = ; reg = <0x5b010000 0x10000>; clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>, diff --git a/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml new file mode 100644 index 000000000000..39559a0a598a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/microchip,sparx5-dpll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 DPLL Clock + +maintainers: + - Lars Povlsen + +description: | + The Sparx5 DPLL clock controller generates and supplies clock to + various peripherals within the SoC. + +properties: + compatible: + const: microchip,sparx5-dpll + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock provider for eMMC: + - | + lcpll_clk: lcpll-clk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <2500000000>; + }; + clks: clock-controller@61110000c { + compatible = "microchip,sparx5-dpll"; + #clock-cells = <1>; + clocks = <&lcpll_clk>; + reg = <0x1110000c 0x24>; + }; + +... diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml new file mode 100644 index 000000000000..85ef69ffebed --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/ti,sa2ul.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: K3 SoC SA2UL crypto module + +maintainers: + - Tero Kristo + +properties: + compatible: + enum: + - ti,j721e-sa2ul + - ti,am654-sa2ul + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel #1 + - description: RX DMA Channel #2 + + dma-names: + items: + - const: tx + - const: rx1 + - const: rx2 + + dma-coherent: true + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + ranges: + description: + Address translation for the possible RNG child node for SA2UL + +patternProperties: + "^rng@[a-f0-9]+$": + type: object + description: + Child RNG node for SA2UL + +required: + - compatible + - reg + - power-domains + - dmas + - dma-names + - dma-coherent + +additionalProperties: false + +examples: + - | + #include + + main_crypto: crypto@4e00000 { + compatible = "ti,j721-sa2ul"; + reg = <0x0 0x4e00000 0x0 0x1200>; + power-domains = <&k3_pds 264 TI_SCI_PD_EXCLUSIVE>; + dmas = <&main_udmap 0xc000>, <&main_udmap 0x4000>, + <&main_udmap 0x4001>; + dma-names = "tx", "rx1", "rx2"; + dma-coherent; + }; diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt index 0ec68141f85a..a10d1f6d85c6 100644 --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt @@ -18,6 +18,8 @@ Optional properties: format depends on the interrupt controller. It should be a DCF interrupt. When DDR DVFS finishes a DCF interrupt is triggered. +- rockchip,pmu: Phandle to the syscon managing the "PMU general register + files". Following properties relate to DDR timing: diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml index 1dee641e3ea1..c040eef56518 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml @@ -36,6 +36,9 @@ properties: - const: bus - const: mod + iommus: + maxItems: 1 + resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt deleted file mode 100644 index 26649b4c4dd8..000000000000 --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt +++ /dev/null @@ -1,174 +0,0 @@ -Broadcom VC4 (VideoCore4) GPU - -The VC4 device present on the Raspberry Pi includes a display system -with HDMI output and the HVS (Hardware Video Scaler) for compositing -display planes. - -Required properties for VC4: -- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4" - -Required properties for Pixel Valve: -- compatible: Should be one of "brcm,bcm2835-pixelvalve0", - "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2" -- reg: Physical base address and length of the PV's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Required properties for HVS: -- compatible: Should be "brcm,bcm2835-hvs" -- reg: Physical base address and length of the HVS's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Required properties for HDMI -- compatible: Should be "brcm,bcm2835-hdmi" -- reg: Physical base address and length of the two register ranges - ("HDMI" and "HD", in that order) -- interrupts: The interrupt numbers - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt -- ddc: phandle of the I2C controller used for DDC EDID probing -- clocks: a) hdmi: The HDMI state machine clock - b) pixel: The pixel clock. - -Optional properties for HDMI: -- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear - as an interrupt/status bit in the HDMI controller - itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt -- dmas: Should contain one entry pointing to the DMA channel used to - transfer audio data -- dma-names: Should contain "audio-rx" - -Required properties for DPI: -- compatible: Should be "brcm,bcm2835-dpi" -- reg: Physical base address and length of the registers -- clocks: a) core: The core clock the unit runs on - b) pixel: The pixel clock that feeds the pixelvalve -- port: Port node with a single endpoint connecting to the panel - device, as defined in [1] - -Required properties for VEC: -- compatible: Should be "brcm,bcm2835-vec" -- reg: Physical base address and length of the registers -- clocks: The core clock the unit runs on -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Required properties for V3D: -- compatible: Should be "brcm,bcm2835-v3d" or "brcm,cygnus-v3d" -- reg: Physical base address and length of the V3D's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Optional properties for V3D: -- clocks: The clock the unit runs on - -Required properties for DSI: -- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1" -- reg: Physical base address and length of the DSI block's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt -- clocks: a) phy: The DSI PLL clock feeding the DSI analog PHY - b) escape: The DSI ESC clock from CPRMAN - c) pixel: The DSI pixel clock from CPRMAN -- clock-output-names: - The 3 clocks output from the DSI analog PHY: dsi[01]_byte, - dsi[01]_ddr2, and dsi[01]_ddr - -Required properties for the TXP (writeback) block: -- compatible: Should be "brcm,bcm2835-txp" -- reg: Physical base address and length of the TXP block's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -[1] Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: -pixelvalve@7e807000 { - compatible = "brcm,bcm2835-pixelvalve2"; - reg = <0x7e807000 0x100>; - interrupts = <2 10>; /* pixelvalve */ -}; - -hvs@7e400000 { - compatible = "brcm,bcm2835-hvs"; - reg = <0x7e400000 0x6000>; - interrupts = <2 1>; -}; - -hdmi: hdmi@7e902000 { - compatible = "brcm,bcm2835-hdmi"; - reg = <0x7e902000 0x600>, - <0x7e808000 0x100>; - interrupts = <2 8>, <2 9>; - ddc = <&i2c2>; - hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; - clocks = <&clocks BCM2835_PLLH_PIX>, - <&clocks BCM2835_CLOCK_HSM>; - clock-names = "pixel", "hdmi"; -}; - -dpi: dpi@7e208000 { - compatible = "brcm,bcm2835-dpi"; - reg = <0x7e208000 0x8c>; - clocks = <&clocks BCM2835_CLOCK_VPU>, - <&clocks BCM2835_CLOCK_DPI>; - clock-names = "core", "pixel"; - #address-cells = <1>; - #size-cells = <0>; - - port { - dpi_out: endpoint@0 { - remote-endpoint = <&panel_in>; - }; - }; -}; - -dsi1: dsi@7e700000 { - compatible = "brcm,bcm2835-dsi1"; - reg = <0x7e700000 0x8c>; - interrupts = <2 12>; - #address-cells = <1>; - #size-cells = <0>; - #clock-cells = <1>; - - clocks = <&clocks BCM2835_PLLD_DSI1>, - <&clocks BCM2835_CLOCK_DSI1E>, - <&clocks BCM2835_CLOCK_DSI1P>; - clock-names = "phy", "escape", "pixel"; - - clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr"; - - pitouchscreen: panel@0 { - compatible = "raspberrypi,touchscreen"; - reg = <0>; - - <...> - }; -}; - -vec: vec@7e806000 { - compatible = "brcm,bcm2835-vec"; - reg = <0x7e806000 0x1000>; - clocks = <&clocks BCM2835_CLOCK_VEC>; - interrupts = <2 27>; -}; - -v3d: v3d@7ec00000 { - compatible = "brcm,bcm2835-v3d"; - reg = <0x7ec00000 0x1000>; - interrupts = <1 10>; -}; - -vc4: gpu { - compatible = "brcm,bcm2835-vc4"; -}; - -panel: panel { - compatible = "ontat,yx700wv03", "simple-panel"; - - port { - panel_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml new file mode 100644 index 000000000000..5c1024bbc1b3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-dpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) DPI Controller + +maintainers: + - Eric Anholt + +properties: + compatible: + const: brcm,bcm2835-dpi + + reg: + maxItems: 1 + + clocks: + items: + - description: The core clock the unit runs on + - description: The pixel clock that feeds the pixelvalve + + clock-names: + items: + - const: core + - const: pixel + + port: + type: object + description: > + Port node with a single endpoint connecting to the panel, as + defined in Documentation/devicetree/bindings/media/video-interfaces.txt. + +required: + - compatible + - reg + - clocks + - clock-names + - port + +additionalProperties: false + +examples: + - | + #include + + dpi: dpi@7e208000 { + compatible = "brcm,bcm2835-dpi"; + reg = <0x7e208000 0x8c>; + clocks = <&clocks BCM2835_CLOCK_VPU>, + <&clocks BCM2835_CLOCK_DPI>; + clock-names = "core", "pixel"; + + port { + dpi_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml new file mode 100644 index 000000000000..3c643b227a70 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-dsi0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) DSI Controller + +maintainers: + - Eric Anholt + +properties: + "#clock-cells": + const: 1 + + compatible: + enum: + - brcm,bcm2835-dsi0 + - brcm,bcm2835-dsi1 + + reg: + maxItems: 1 + + clocks: + items: + - description: The DSI PLL clock feeding the DSI analog PHY + - description: The DSI ESC clock + - description: The DSI pixel clock + + clock-names: + items: + - const: phy + - const: escape + - const: pixel + + clock-output-names: true + # FIXME: The meta-schemas don't seem to allow it for now + # items: + # - description: The DSI byte clock for the PHY + # - description: The DSI DDR2 clock + # - description: The DSI DDR clock + + interrupts: + maxItems: 1 + +required: + - "#clock-cells" + - compatible + - reg + - clocks + - clock-names + - clock-output-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include + + dsi1: dsi@7e700000 { + compatible = "brcm,bcm2835-dsi1"; + reg = <0x7e700000 0x8c>; + interrupts = <2 12>; + #address-cells = <1>; + #size-cells = <0>; + #clock-cells = <1>; + + clocks = <&clocks BCM2835_PLLD_DSI1>, + <&clocks BCM2835_CLOCK_DSI1E>, + <&clocks BCM2835_CLOCK_DSI1P>; + clock-names = "phy", "escape", "pixel"; + + clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr"; + + pitouchscreen: panel@0 { + compatible = "raspberrypi,touchscreen"; + reg = <0>; + + /* ... */ + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml new file mode 100644 index 000000000000..52b3cdac0bdf --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) HDMI Controller + +maintainers: + - Eric Anholt + +properties: + compatible: + const: brcm,bcm2835-hdmi + + reg: + items: + - description: HDMI register range + - description: HD register range + + interrupts: + minItems: 2 + + clocks: + items: + - description: The pixel clock + - description: The HDMI state machine clock + + clock-names: + items: + - const: pixel + - const: hdmi + + ddc: + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + description: > + Phandle of the I2C controller used for DDC EDID probing + + hpd-gpios: + description: > + The GPIO pin for the HDMI hotplug detect (if it doesn't appear + as an interrupt/status bit in the HDMI controller itself) + + dmas: + maxItems: 1 + description: > + Should contain one entry pointing to the DMA channel used to + transfer audio data. + + dma-names: + const: audio-rx + +required: + - compatible + - reg + - interrupts + - clocks + - ddc + +additionalProperties: false + +examples: + - | + #include + #include + + hdmi: hdmi@7e902000 { + compatible = "brcm,bcm2835-hdmi"; + reg = <0x7e902000 0x600>, + <0x7e808000 0x100>; + interrupts = <2 8>, <2 9>; + ddc = <&i2c2>; + hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + clocks = <&clocks BCM2835_PLLH_PIX>, + <&clocks BCM2835_CLOCK_HSM>; + clock-names = "pixel", "hdmi"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml new file mode 100644 index 000000000000..02410f8d6d49 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-hvs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) Hardware Video Scaler + +maintainers: + - Eric Anholt + +properties: + compatible: + const: brcm,bcm2835-hvs + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + hvs@7e400000 { + compatible = "brcm,bcm2835-hvs"; + reg = <0x7e400000 0x6000>; + interrupts = <2 1>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml new file mode 100644 index 000000000000..e60791db1fa1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-pixelvalve0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) PixelValve + +maintainers: + - Eric Anholt + +properties: + compatible: + enum: + - brcm,bcm2835-pixelvalve0 + - brcm,bcm2835-pixelvalve1 + - brcm,bcm2835-pixelvalve2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + pixelvalve@7e807000 { + compatible = "brcm,bcm2835-pixelvalve2"; + reg = <0x7e807000 0x100>; + interrupts = <2 10>; /* pixelvalve */ + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml new file mode 100644 index 000000000000..bb186197e471 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-txp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) TXP (writeback) Controller + +maintainers: + - Eric Anholt + +properties: + compatible: + const: brcm,bcm2835-txp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + txp: txp@7e004000 { + compatible = "brcm,bcm2835-txp"; + reg = <0x7e004000 0x20>; + interrupts = <1 11>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml new file mode 100644 index 000000000000..8a73780f573d --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-v3d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) V3D GPU + +maintainers: + - Eric Anholt + +properties: + compatible: + enum: + - brcm,bcm2835-v3d + - brcm,cygnus-v3d + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + v3d: v3d@7ec00000 { + compatible = "brcm,bcm2835-v3d"; + reg = <0x7ec00000 0x1000>; + interrupts = <1 10>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml new file mode 100644 index 000000000000..0dcf0c397375 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-vc4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) GPU + +maintainers: + - Eric Anholt + +description: > + The VC4 device present on the Raspberry Pi includes a display system + with HDMI output and the HVS (Hardware Video Scaler) for compositing + display planes. + +properties: + compatible: + enum: + - brcm,bcm2835-vc4 + - brcm,cygnus-vc4 + +required: + - compatible + +additionalProperties: false + +examples: + - | + vc4: gpu { + compatible = "brcm,bcm2835-vc4"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml new file mode 100644 index 000000000000..d900cc57b4ec --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-vec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) VEC + +maintainers: + - Eric Anholt + +properties: + compatible: + const: brcm,bcm2835-vec + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + #include + + vec: vec@7e806000 { + compatible = "brcm,bcm2835-vec"; + reg = <0x7e806000 0x1000>; + clocks = <&clocks BCM2835_CLOCK_VEC>; + interrupts = <2 27>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml index 8aff2d68fc33..2c4c34e3bc29 100644 --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml @@ -165,6 +165,7 @@ examples: - | #include + #include #include #include @@ -191,12 +192,12 @@ examples: phy-names = "dphy"; panel@0 { - #address-cells = <1>; - #size-cells = <0>; compatible = "rocktech,jh057n00900"; reg = <0>; - port@0 { - reg = <0>; + vcc-supply = <®_2v8_p>; + iovcc-supply = <®_1v8_p>; + reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; + port { panel_in: endpoint { remote-endpoint = <&mipi_dsi_out>; }; diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt deleted file mode 100644 index c62ce2494ed9..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ /dev/null @@ -1,85 +0,0 @@ -Renesas R-Car LVDS Encoder -========================== - -These DT bindings describe the LVDS encoder embedded in the Renesas R-Car -Gen2, R-Car Gen3 and RZ/G SoCs. - -Required properties: - -- compatible : Shall contain one of - - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders - - "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders - - "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders - - "renesas,r8a774b1-lvds" for R8A774B1 (RZ/G2N) compatible LVDS encoders - - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders - - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders - - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders - - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders - - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders - - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders - - "renesas,r8a77965-lvds" for R8A77965 (R-Car M3-N) compatible LVDS encoders - - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders - - "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders - - "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders - - "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders - -- reg: Base address and length for the memory-mapped registers -- clocks: A list of phandles + clock-specifier pairs, one for each entry in - the clock-names property. -- clock-names: Name of the clocks. This property is model-dependent. - - The functional clock, which mandatory for all models, shall be listed - first, and shall be named "fck". - - On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL or - DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be - named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN - numerical index. - - When the clocks property only contains the functional clock, the - clock-names property may be omitted. -- resets: A phandle + reset specifier for the module reset - -Required nodes: - -The LVDS encoder has two video ports. Their connections are modelled using the -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 corresponds to the parallel RGB input -- Video port 1 corresponds to the LVDS output - -Each port shall have a single endpoint. - -Optional properties: - -- renesas,companion : phandle to the companion LVDS encoder. This property is - mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to - the second encoder to be used as a companion in dual-link mode. It shall not - be set for any other LVDS encoder. - - -Example: - - lvds0: lvds@feb90000 { - compatible = "renesas,r8a77990-lvds"; - reg = <0 0xfeb90000 0 0x20>; - clocks = <&cpg CPG_MOD 727>; - power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; - resets = <&cpg 727>; - - renesas,companion = <&lvds1>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - lvds0_in: endpoint { - remote-endpoint = <&du_out_lvds0>; - }; - }; - port@1 { - reg = <1>; - lvds0_out: endpoint { - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml new file mode 100644 index 000000000000..98c7330a9485 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/renesas,lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car LVDS Encoder + +maintainers: + - Laurent Pinchart + +description: | + These DT bindings describe the LVDS encoder embedded in the Renesas R-Car + Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs. + +properties: + compatible: + enum: + - renesas,r8a7743-lvds # for RZ/G1M compatible LVDS encoders + - renesas,r8a7744-lvds # for RZ/G1N compatible LVDS encoders + - renesas,r8a774a1-lvds # for RZ/G2M compatible LVDS encoders + - renesas,r8a774b1-lvds # for RZ/G2N compatible LVDS encoders + - renesas,r8a774c0-lvds # for RZ/G2E compatible LVDS encoders + - renesas,r8a7790-lvds # for R-Car H2 compatible LVDS encoders + - renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders + - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders + - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders + - renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders + - renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders + - renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders + - renesas,r8a77980-lvds # for R-Car V3H compatible LVDS encoders + - renesas,r8a77990-lvds # for R-Car E3 compatible LVDS encoders + - renesas,r8a77995-lvds # for R-Car D3 compatible LVDS encoders + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + + resets: + maxItems: 1 + + ports: + type: object + description: | + This device has two video ports. Their connections are modelled using the + OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. + Each port shall have a single endpoint. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@0: + type: object + description: Parallel RGB input port + + port@1: + type: object + description: LVDS output port + + required: + - port@0 + - port@1 + + additionalProperties: false + + power-domains: + maxItems: 1 + + renesas,companion: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the companion LVDS encoder. This property is mandatory + for the first LVDS encoder on D3 and E3 SoCs, and shall point to + the second encoder to be used as a companion in dual-link mode. It + shall not be set for any other LVDS encoder. + +required: + - compatible + - reg + - clocks + - power-domains + - resets + - ports + +if: + properties: + compatible: + enum: + - renesas,r8a774c0-lvds + - renesas,r8a77990-lvds + - renesas,r8a77995-lvds +then: + properties: + clocks: + minItems: 1 + maxItems: 4 + items: + - description: Functional clock + - description: EXTAL input clock + - description: DU_DOTCLKIN0 input clock + - description: DU_DOTCLKIN1 input clock + + clock-names: + minItems: 1 + maxItems: 4 + items: + - const: fck + # The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks. + # These clocks are optional. + - enum: + - extal + - dclkin.0 + - dclkin.1 + - enum: + - extal + - dclkin.0 + - dclkin.1 + - enum: + - extal + - dclkin.0 + - dclkin.1 + + required: + - clock-names + +else: + properties: + clocks: + maxItems: 1 + items: + - description: Functional clock + + clock-names: + maxItems: 1 + items: + - const: fck + + renesas,companion: false + +additionalProperties: false + +examples: + - | + #include + #include + + lvds@feb90000 { + compatible = "renesas,r8a7795-lvds"; + reg = <0xfeb90000 0x14>; + clocks = <&cpg CPG_MOD 727>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 727>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds_in: endpoint { + remote-endpoint = <&du_out_lvds0>; + }; + }; + port@1 { + reg = <1>; + lvds_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + + - | + #include + #include + + lvds0: lvds@feb90000 { + compatible = "renesas,r8a77990-lvds"; + reg = <0xfeb90000 0x20>; + clocks = <&cpg CPG_MOD 727>, + <&x13_clk>, + <&extal_clk>; + clock-names = "fck", "dclkin.0", "extal"; + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; + resets = <&cpg 727>; + + renesas,companion = <&lvds1>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds0_in: endpoint { + remote-endpoint = <&du_out_lvds0>; + }; + }; + port@1 { + reg = <1>; + lvds0_out: endpoint { + remote-endpoint = <&panel_in1>; + }; + }; + }; + }; + + lvds1: lvds@feb90100 { + compatible = "renesas,r8a77990-lvds"; + reg = <0xfeb90100 0x20>; + clocks = <&cpg CPG_MOD 727>, + <&x13_clk>, + <&extal_clk>; + clock-names = "fck", "dclkin.0", "extal"; + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; + resets = <&cpg 726>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds1_in: endpoint { + remote-endpoint = <&du_out_lvds1>; + }; + }; + port@1 { + reg = <1>; + lvds1_out: endpoint { + remote-endpoint = <&panel_in2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt deleted file mode 100644 index 8ec4a7f2623a..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt +++ /dev/null @@ -1,87 +0,0 @@ -SN65DSI86 DSI to eDP bridge chip --------------------------------- - -This is the binding for Texas Instruments SN65DSI86 bridge. -http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf - -Required properties: -- compatible: Must be "ti,sn65dsi86" -- reg: i2c address of the chip, 0x2d as per datasheet -- enable-gpios: gpio specification for bridge_en pin (active high) - -- vccio-supply: A 1.8V supply that powers up the digital IOs. -- vpll-supply: A 1.8V supply that powers up the displayport PLL. -- vcca-supply: A 1.2V supply that powers up the analog circuits. -- vcc-supply: A 1.2V supply that powers up the digital core. - -Optional properties: -- interrupts-extended: Specifier for the SN65DSI86 interrupt line. - -- gpio-controller: Marks the device has a GPIO controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. - See ../../gpio/gpio.txt for more information. -- #pwm-cells : Should be one. See ../../pwm/pwm.yaml for description of - the cell formats. - -- clock-names: should be "refclk" -- clocks: Specification for input reference clock. The reference - clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. - -- data-lanes: See ../../media/video-interface.txt -- lane-polarities: See ../../media/video-interface.txt - -- suspend-gpios: specification for GPIO1 pin on bridge (active low) - -Required nodes: -This device has two video ports. Their connections are modelled using the -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for DSI input -- Video port 1 for eDP output - -Example -------- - -edp-bridge@2d { - compatible = "ti,sn65dsi86"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x2d>; - - enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>; - suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>; - - interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>; - - vccio-supply = <&pm8916_l17>; - vcca-supply = <&pm8916_l6>; - vpll-supply = <&pm8916_l17>; - vcc-supply = <&pm8916_l6>; - - clock-names = "refclk"; - clocks = <&input_refclk>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - edp_bridge_in: endpoint { - remote-endpoint = <&dsi_out>; - }; - }; - - port@1 { - reg = <1>; - - edp_bridge_out: endpoint { - data-lanes = <2 1 3 0>; - lane-polarities = <0 1 0 1>; - remote-endpoint = <&edp_panel_in>; - }; - }; - }; -} diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml new file mode 100644 index 000000000000..f8622bd0f61e --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -0,0 +1,293 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi86.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI86 DSI to eDP bridge chip + +maintainers: + - Sandeep Panda + +description: | + The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP. + https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf + +properties: + compatible: + const: ti,sn65dsi86 + + reg: + const: 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + suspend-gpios: + maxItems: 1 + description: GPIO specifier for GPIO1 pin on bridge (active low). + + no-hpd: + type: boolean + description: + Set if the HPD line on the bridge isn't hooked up to anything or is + otherwise unusable. + + vccio-supply: + description: A 1.8V supply that powers the digital IOs. + + vpll-supply: + description: A 1.8V supply that powers the DisplayPort PLL. + + vcca-supply: + description: A 1.2V supply that powers the analog circuits. + + vcc-supply: + description: A 1.2V supply that powers the digital core. + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + Clock specifier for input reference clock. The reference clock rate must + be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. + + clock-names: + const: refclk + + gpio-controller: true + '#gpio-cells': + const: 2 + description: + First cell is pin number, second cell is flags. GPIO pin numbers are + 1-based to match the datasheet. See ../../gpio/gpio.txt for more + information. + + '#pwm-cells': + const: 1 + description: See ../../pwm/pwm.yaml for description of the cell formats. + + ports: + type: object + additionalProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + additionalProperties: false + + description: + Video port for MIPI DSI input + + properties: + reg: + const: 0 + + endpoint: + type: object + additionalProperties: false + properties: + remote-endpoint: true + + required: + - reg + + port@1: + type: object + additionalProperties: false + + description: + Video port for eDP output (panel or connector). + + properties: + reg: + const: 1 + + endpoint: + type: object + additionalProperties: false + + properties: + remote-endpoint: true + + data-lanes: + oneOf: + - minItems: 1 + maxItems: 1 + uniqueItems: true + items: + enum: + - 0 + - 1 + description: + If you have 1 logical lane the bridge supports routing + to either port 0 or port 1. Port 0 is suggested. + See ../../media/video-interface.txt for details. + + - minItems: 2 + maxItems: 2 + uniqueItems: true + items: + enum: + - 0 + - 1 + description: + If you have 2 logical lanes the bridge supports + reordering but only on physical ports 0 and 1. + See ../../media/video-interface.txt for details. + + - minItems: 4 + maxItems: 4 + uniqueItems: true + items: + enum: + - 0 + - 1 + - 2 + - 3 + description: + If you have 4 logical lanes the bridge supports + reordering in any way. + See ../../media/video-interface.txt for details. + + lane-polarities: + minItems: 1 + maxItems: 4 + items: + enum: + - 0 + - 1 + description: See ../../media/video-interface.txt + + dependencies: + lane-polarities: [data-lanes] + + required: + - reg + + required: + - "#address-cells" + - "#size-cells" + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - vccio-supply + - vpll-supply + - vcca-supply + - vcc-supply + - ports + +additionalProperties: false + +examples: + - | + #include + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + interrupt-parent = <&tlmm>; + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>; + + vpll-supply = <&src_pp1800_s4a>; + vccio-supply = <&src_pp1800_s4a>; + vcca-supply = <&src_pp1200_l2a>; + vcc-supply = <&src_pp1200_l2a>; + + clocks = <&rpmhcc RPMH_LN_BB_CLK2>; + clock-names = "refclk"; + + no-hpd; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + }; + }; + - | + #include + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>; + suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>; + + interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>; + + vccio-supply = <&pm8916_l17>; + vcca-supply = <&pm8916_l6>; + vpll-supply = <&pm8916_l17>; + vcc-supply = <&pm8916_l6>; + + clock-names = "refclk"; + clocks = <&input_refclk>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + edp_bridge_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + + port@1 { + reg = <1>; + + edp_bridge_out: endpoint { + data-lanes = <2 1 3 0>; + lane-polarities = <0 1 0 1>; + remote-endpoint = <&edp_panel_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt deleted file mode 100644 index 5ff4f64ef8e8..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt +++ /dev/null @@ -1,66 +0,0 @@ -TFP410 DPI to DVI encoder -========================= - -Required properties: -- compatible: "ti,tfp410" - -Optional properties: -- powerdown-gpios: power-down gpio -- reg: I2C address. If and only if present the device node should be placed - into the I2C controller node where the TFP410 I2C is connected to. -- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured - through th DK[3:1] pins. This property shall be present only if the TFP410 - is not connected through I2C. - -Required nodes: - -This device has two video ports. Their connections are modeled using the OF -graph bindings specified in [1]. Each port node shall have a single endpoint. - -- Port 0 is the DPI input port. Its endpoint subnode shall contain a - pclk-sample and bus-width property and a remote-endpoint property as specified - in [1]. - - If pclk-sample is not defined, pclk-sample = 0 should be assumed for - backward compatibility. - - If bus-width is not defined then bus-width = 24 should be assumed for - backward compatibility. - bus-width = 24: 24 data lines are connected and single-edge mode - bus-width = 12: 12 data lines are connected and dual-edge mode - -- Port 1 is the DVI output port. Its endpoint subnode shall contain a - remote-endpoint property is specified in [1]. - -[1] Documentation/devicetree/bindings/media/video-interfaces.txt - - -Example -------- - -tfp410: encoder@0 { - compatible = "ti,tfp410"; - powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; - ti,deskew = <4>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - tfp410_in: endpoint@0 { - pclk-sample = <1>; - bus-width = <24>; - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - - tfp410_out: endpoint@0 { - remote-endpoint = <&dvi_connector_in>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml new file mode 100644 index 000000000000..605831c1e836 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TFP410 DPI to DVI encoder + +maintainers: + - Tomi Valkeinen + - Jyri Sarha + +properties: + compatible: + const: ti,tfp410 + + reg: + description: I2C address of the device. + maxItems: 1 + + powerdown-gpios: + maxItems: 1 + + ti,deskew: + description: + Data de-skew value in 350ps increments, from 0 to 7, as configured + through the DK[3:1] pins. The de-skew multiplier is computed as + (DK[3:1] - 4), so it ranges from -4 to 3. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + + ports: + description: + A node containing input and output port nodes with endpoint + definitions as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + type: object + + properties: + port@0: + description: DPI input port. + type: object + + properties: + reg: + const: 0 + + endpoint: + type: object + + properties: + pclk-sample: + description: + Endpoint sampling edge. + enum: + - 0 # Falling edge + - 1 # Rising edge + default: 0 + + bus-width: + description: + Endpoint bus width. + enum: + - 12 # 12 data lines connected and dual-edge mode + - 24 # 24 data lines connected and single-edge mode + default: 24 + + port@1: + description: DVI output port. + type: object + + properties: + reg: + const: 1 + + endpoint: + type: object + + required: + - port@0 + - port@1 + +required: + - compatible + - ports + +if: + required: + - reg +then: + properties: + ti,deskew: false +else: + required: + - ti,deskew + +additionalProperties: false + +examples: + - | + #include + + tfp410: encoder { + compatible = "ti,tfp410"; + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; + ti,deskew = <3>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + tfp410_in: endpoint { + pclk-sample = <1>; + bus-width = <24>; + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + tfp410_out: endpoint { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt deleted file mode 100644 index 883bcb2604c7..000000000000 --- a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt +++ /dev/null @@ -1,31 +0,0 @@ -Analog TV Connector -=================== - -Required properties: -- compatible: "composite-video-connector" or "svideo-connector" - -Optional properties: -- label: a symbolic name for the connector -- sdtv-standards: limit the supported TV standards on a connector to the given - ones. If not specified all TV standards are allowed. - Possible TV standards are defined in - include/dt-bindings/display/sdtv-standards.h. - -Required nodes: -- Video port for TV input - -Example -------- -#include - -tv: connector { - compatible = "composite-video-connector"; - label = "tv"; - sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>; - - port { - tv_connector_in: endpoint { - remote-endpoint = <&venc_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml new file mode 100644 index 000000000000..eebe88fed999 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/analog-tv-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog TV Connector + +maintainers: + - Laurent Pinchart + +properties: + compatible: + enum: + - composite-video-connector + - svideo-connector + + label: true + + sdtv-standards: + description: + Limit the supported TV standards on a connector to the given ones. If + not specified all TV standards are allowed. Possible TV standards are + defined in include/dt-bindings/display/sdtv-standards.h. + $ref: /schemas/types.yaml#/definitions/uint32 + + port: + description: Connection to controller providing analog TV signals + +required: + - compatible + - port + +additionalProperties: false + +examples: + - | + #include + + connector { + compatible = "composite-video-connector"; + label = "tv"; + sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>; + + port { + tv_connector_in: endpoint { + remote-endpoint = <&venc_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt deleted file mode 100644 index 207e42e9eba0..000000000000 --- a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt +++ /dev/null @@ -1,36 +0,0 @@ -DVI Connector -============== - -Required properties: -- compatible: "dvi-connector" - -Optional properties: -- label: a symbolic name for the connector -- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC -- analog: the connector has DVI analog pins -- digital: the connector has DVI digital pins -- dual-link: the connector has pins for DVI dual-link -- hpd-gpios: HPD GPIO number - -Required nodes: -- Video port for DVI input - -Note: One (or both) of 'analog' or 'digital' must be set. - -Example -------- - -dvi0: connector@0 { - compatible = "dvi-connector"; - label = "dvi"; - - digital; - - ddc-i2c-bus = <&i2c3>; - - port { - dvi_connector_in: endpoint { - remote-endpoint = <&tfp410_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/dvi-connector.yaml b/Documentation/devicetree/bindings/display/connector/dvi-connector.yaml new file mode 100644 index 000000000000..71cb9220fa59 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/dvi-connector.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/dvi-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DVI Connector + +maintainers: + - Laurent Pinchart + +properties: + compatible: + const: dvi-connector + + label: true + + hpd-gpios: + description: A GPIO line connected to HPD + maxItems: 1 + + ddc-i2c-bus: + description: phandle link to the I2C controller used for DDC EDID probing + $ref: /schemas/types.yaml#/definitions/phandle + + analog: + type: boolean + description: the connector has DVI analog pins + + digital: + type: boolean + description: the connector has DVI digital pins + + dual-link: + type: boolean + description: the connector has pins for DVI dual-link + + port: + description: Connection to controller providing DVI signals + +required: + - compatible + - port + +anyOf: + - required: + - analog + - required: + - digital + +additionalProperties: false + +examples: + - | + connector { + compatible = "dvi-connector"; + label = "dvi"; + + digital; + + ddc-i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt deleted file mode 100644 index aeb07c4bd703..000000000000 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt +++ /dev/null @@ -1,31 +0,0 @@ -HDMI Connector -============== - -Required properties: -- compatible: "hdmi-connector" -- type: the HDMI connector type: "a", "b", "c", "d" or "e" - -Optional properties: -- label: a symbolic name for the connector -- hpd-gpios: HPD GPIO number -- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing -- ddc-en-gpios: signal to enable DDC bus - -Required nodes: -- Video port for HDMI input - -Example -------- - -hdmi0: connector@1 { - compatible = "hdmi-connector"; - label = "hdmi"; - - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&tpd12s015_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml new file mode 100644 index 000000000000..14d7128af592 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/hdmi-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HDMI Connector + +maintainers: + - Laurent Pinchart + +properties: + compatible: + const: hdmi-connector + + type: + description: The HDMI connector type + enum: + - a # Standard full size + - b # Never deployed? + - c # Mini + - d # Micro + - e # automotive + + label: true + + hpd-gpios: + description: A GPIO line connected to HPD + maxItems: 1 + + ddc-i2c-bus: + description: phandle link to the I2C controller used for DDC EDID probing + $ref: /schemas/types.yaml#/definitions/phandle + + ddc-en-gpios: + description: GPIO signal to enable DDC bus + maxItems: 1 + + port: + description: Connection to controller providing HDMI signals + +required: + - compatible + - port + - type + +additionalProperties: false + +examples: + - | + connector { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "a"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/vga-connector.txt b/Documentation/devicetree/bindings/display/connector/vga-connector.txt deleted file mode 100644 index c727f298e7ad..000000000000 --- a/Documentation/devicetree/bindings/display/connector/vga-connector.txt +++ /dev/null @@ -1,36 +0,0 @@ -VGA Connector -============= - -Required properties: - -- compatible: "vga-connector" - -Optional properties: - -- label: a symbolic name for the connector corresponding to a hardware label -- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC - -Required nodes: - -The VGA connector internal connections are modeled using the OF graph bindings -specified in Documentation/devicetree/bindings/graph.txt. - -The VGA connector has a single port that must be connected to a video source -port. - - -Example -------- - -vga0: connector@0 { - compatible = "vga-connector"; - label = "vga"; - - ddc-i2c-bus = <&i2c3>; - - port { - vga_connector_in: endpoint { - remote-endpoint = <&adv7123_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/vga-connector.yaml b/Documentation/devicetree/bindings/display/connector/vga-connector.yaml new file mode 100644 index 000000000000..5782c4bb3252 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/vga-connector.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/vga-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: VGA Connector + +maintainers: + - Laurent Pinchart + +properties: + compatible: + const: vga-connector + + label: true + + ddc-i2c-bus: + description: phandle link to the I2C controller used for DDC EDID probing + $ref: /schemas/types.yaml#/definitions/phandle + + port: + description: Connection to controller providing VGA signals + +required: + - compatible + - port + +additionalProperties: false + +examples: + - | + connector { + compatible = "vga-connector"; + label = "vga"; + + ddc-i2c-bus = <&i2c3>; + + port { + vga_connector_in: endpoint { + remote-endpoint = <&adv7123_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml new file mode 100644 index 000000000000..5bfc33eb32c9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/ingenic,ipu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs Image Processing Unit (IPU) devicetree bindings + +maintainers: + - Paul Cercueil + +properties: + compatible: + oneOf: + - enum: + - ingenic,jz4725b-ipu + - ingenic,jz4760-ipu + - items: + - const: ingenic,jz4770-ipu + - const: ingenic,jz4760-ipu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ipu + +patternProperties: + "^ports?$": + description: OF graph bindings (specified in bindings/graph.txt). + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + ipu@13080000 { + compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu"; + reg = <0x13080000 0x800>; + + interrupt-parent = <&intc>; + interrupts = <29>; + + clocks = <&cgu JZ4770_CLK_IPU>; + clock-names = "ipu"; + + port { + ipu_ep: endpoint { + remote-endpoint = <&lcdc_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt b/Documentation/devicetree/bindings/display/ingenic,lcd.txt deleted file mode 100644 index 01e3261defb6..000000000000 --- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt +++ /dev/null @@ -1,45 +0,0 @@ -Ingenic JZ47xx LCD driver - -Required properties: -- compatible: one of: - * ingenic,jz4740-lcd - * ingenic,jz4725b-lcd - * ingenic,jz4770-lcd -- reg: LCD registers location and length -- clocks: LCD pixclock and device clock specifiers. - The device clock is only required on the JZ4740. -- clock-names: "lcd_pclk" and "lcd" -- interrupts: Specifies the interrupt line the LCD controller is connected to. - -Example: - -panel { - compatible = "sharp,ls020b1dd01d"; - - backlight = <&backlight>; - power-supply = <&vcc>; - - port { - panel_input: endpoint { - remote-endpoint = <&panel_output>; - }; - }; -}; - - -lcd: lcd-controller@13050000 { - compatible = "ingenic,jz4725b-lcd"; - reg = <0x13050000 0x1000>; - - interrupt-parent = <&intc>; - interrupts = <31>; - - clocks = <&cgu JZ4725B_CLK_LCD>; - clock-names = "lcd"; - - port { - panel_output: endpoint { - remote-endpoint = <&panel_input>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml new file mode 100644 index 000000000000..d56db1802fad --- /dev/null +++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs LCD controller devicetree bindings + +maintainers: + - Paul Cercueil + +properties: + $nodename: + pattern: "^lcd-controller@[0-9a-f]+$" + + compatible: + enum: + - ingenic,jz4740-lcd + - ingenic,jz4725b-lcd + - ingenic,jz4770-lcd + - ingenic,jz4780-lcd + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Pixel clock + - description: Module clock + minItems: 1 + + clock-names: + items: + - const: lcd_pclk + - const: lcd + minItems: 1 + + port: + description: OF graph bindings (specified in bindings/graph.txt). + + ports: + description: OF graph bindings (specified in bindings/graph.txt). + type: object + properties: + port@0: + type: object + description: DPI output, to interface with TFT panels. + + port@8: + type: object + description: Link to the Image Processing Unit (IPU). + (See ingenic,ipu.yaml). + + required: + - port@0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +if: + properties: + compatible: + contains: + enum: + - ingenic,jz4740-lcd + - ingenic,jz4780-lcd +then: + properties: + clocks: + minItems: 2 + clock-names: + minItems: 2 +else: + properties: + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include + lcd-controller@13050000 { + compatible = "ingenic,jz4740-lcd"; + reg = <0x13050000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <30>; + + clocks = <&cgu JZ4740_CLK_LCD_PCLK>, <&cgu JZ4740_CLK_LCD>; + clock-names = "lcd_pclk", "lcd"; + + port { + endpoint { + remote-endpoint = <&panel_input>; + }; + }; + }; + + - | + #include + lcd-controller@13050000 { + compatible = "ingenic,jz4725b-lcd"; + reg = <0x13050000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <31>; + + clocks = <&cgu JZ4725B_CLK_LCD>; + clock-names = "lcd_pclk"; + + port { + endpoint { + remote-endpoint = <&panel_input>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index af95586c898f..7884fd7a85c1 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -87,6 +87,7 @@ Required properties: * "qcom,dsi-phy-20nm" * "qcom,dsi-phy-28nm-8960" * "qcom,dsi-phy-14nm" + * "qcom,dsi-phy-14nm-660" * "qcom,dsi-phy-10nm" * "qcom,dsi-phy-10nm-8998" - reg: Physical base address and length of the registers of PLL, PHY. Some diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index fd779cd6994d..1af0ff102b50 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -112,6 +112,34 @@ Example a6xx (with GMU): interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>; interconnect-names = "gfx-mem"; + gpu_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-430000000 { + opp-hz = /bits/ 64 <430000000>; + opp-level = ; + opp-peak-kBps = <5412000>; + }; + + opp-355000000 { + opp-hz = /bits/ 64 <355000000>; + opp-level = ; + opp-peak-kBps = <3072000>; + }; + + opp-267000000 { + opp-hz = /bits/ 64 <267000000>; + opp-level = ; + opp-peak-kBps = <3072000>; + }; + + opp-180000000 { + opp-hz = /bits/ 64 <180000000>; + opp-level = ; + opp-peak-kBps = <1804000>; + }; + }; + qcom,gmu = <&gmu>; zap-shader { diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt deleted file mode 100644 index 3ab8c7412cf6..000000000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt +++ /dev/null @@ -1,22 +0,0 @@ -Innolux P079ZCA 7.85" 768x1024 TFT LCD panel - -Required properties: -- compatible: should be "innolux,p079zca" -- reg: DSI virtual channel of the peripheral -- power-supply: phandle of the regulator that provides the supply voltage -- enable-gpios: panel enable gpio - -Optional properties: -- backlight: phandle of the backlight device attached to the panel - -Example: - - &mipi_dsi { - panel@0 { - compatible = "innolux,p079zca"; - reg = <0>; - power-supply = <...>; - backlight = <&backlight>; - enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt deleted file mode 100644 index dce48eb9db57..000000000000 --- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt +++ /dev/null @@ -1,29 +0,0 @@ -Generic MIPI DSI Command Mode Panel -=================================== - -Required properties: -- compatible: "panel-dsi-cm" - -Optional properties: -- label: a symbolic name for the panel -- reset-gpios: panel reset gpio -- te-gpios: panel TE gpio - -Required nodes: -- Video port for DSI input - -Example -------- - -lcd0: display { - compatible = "tpo,taal", "panel-dsi-cm"; - label = "lcd0"; - - reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; - - port { - lcd0_in: endpoint { - remote-endpoint = <&dsi1_out_ep>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml new file mode 100644 index 000000000000..d766c949c622 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DSI command mode panels + +maintainers: + - Tomi Valkeinen + - Sebastian Reichel + +description: | + This binding file is a collection of the DSI panels that + are usually driven in command mode. If no backlight is + referenced via the optional backlight property, the DSI + panel is assumed to have native backlight support. + The panel may use an OF graph binding for the association + to the display, or it may be a direct child node of the + display. + +allOf: + - $ref: panel-common.yaml# + +properties: + + compatible: + items: + - enum: + - motorola,droid4-panel # Panel from Motorola Droid4 phone + - nokia,himalaya # Panel from Nokia N950 phone + - tpo,taal # Panel from OMAP4 SDP board + - const: panel-dsi-cm # Generic DSI command mode panel compatible fallback + + reg: + maxItems: 1 + description: DSI virtual channel + + vddi-supply: + description: + Display panels require power to be supplied. While several panels need + more than one power supply with panel-specific constraints governing the + order and timings of the power supplies, in many cases a single power + supply is sufficient, either because the panel has a single power rail, or + because all its power rails can be driven by the same supply. In that case + the vddi-supply property specifies the supply powering the panel as a + phandle to a regulator. + + vpnl-supply: + description: + When the display panel needs a second power supply, this property can be + used in addition to vddi-supply. Both supplies will be enabled at the + same time before the panel is being accessed. + + width-mm: true + height-mm: true + label: true + rotation: true + panel-timing: true + port: true + reset-gpios: true + te-gpios: true + backlight: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include + + dsi-controller { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "tpo,taal", "panel-dsi-cm"; + reg = <0>; + reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 16778ce782fc..c0dd9fa29f1d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -33,6 +33,8 @@ properties: - auo,b080uan01 # Boe Corporation 8.0" WUXGA TFT LCD panel - boe,tv080wum-nl0 + # Innolux P079ZCA 7.85" 768x1024 TFT LCD panel + - innolux,p079zca # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel - kingdisplay,kd097d04 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index d6cca1479633..6deeeed59e59 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -81,6 +81,10 @@ properties: - boe,nv140fhmn49 # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel - cdtech,s043wq26h-ct7 + # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel + - cdtech,s070pws19hp-fc21 + # CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel + - cdtech,s070swv29hg-dc44 # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel - cdtech,s070wv95-ct16 # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel @@ -157,6 +161,8 @@ properties: - innolux,zj070na-01p # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel - koe,tx14d24vm1bpa + # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel + - koe,tx26d202vm0bwa # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel - koe,tx31d200vm0baa # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel @@ -245,6 +251,8 @@ properties: - starry,kr122ea0sra # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel - tianma,tm070jdhg30 + # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel + - tianma,tm070jvhg33 # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel - tianma,tm070rvhg71 # Toshiba 8.9" WXGA (1280x768) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt deleted file mode 100644 index a372c5d84695..000000000000 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt +++ /dev/null @@ -1,23 +0,0 @@ -Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel - -Required properties: -- compatible: should be "rocktech,jh057n00900" -- reg: DSI virtual channel of the peripheral -- reset-gpios: panel reset gpio -- backlight: phandle of the backlight device attached to the panel -- vcc-supply: phandle of the regulator that provides the vcc supply voltage. -- iovcc-supply: phandle of the regulator that provides the iovcc supply - voltage. - -Example: - - &mipi_dsi { - panel@0 { - compatible = "rocktech,jh057n00900"; - reg = <0>; - backlight = <&backlight>; - reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; - vcc-supply = <®_2v8_p>; - iovcc-supply = <®_1v8_p>; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml new file mode 100644 index 000000000000..d5733ef30954 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel + +maintainers: + - Ondrej Jirman + +description: | + Rocktech JH057N00900 is a 720x1440 TFT LCD panel + connected using a MIPI-DSI video interface. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + # Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel + - rocktech,jh057n00900 + # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel + - xingbangda,xbd599 + + port: true + reg: + maxItems: 1 + description: DSI virtual channel + + vcc-supply: + description: Panel power supply + + iovcc-supply: + description: I/O voltage supply + + reset-gpios: + description: GPIO used for the reset pin + maxItems: 1 + + backlight: + description: Backlight used by the panel + $ref: "/schemas/types.yaml#/definitions/phandle" + +required: + - compatible + - reg + - vcc-supply + - iovcc-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include + + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "rocktech,jh057n00900"; + reg = <0>; + vcc-supply = <®_2v8_p>; + iovcc-supply = <®_1v8_p>; + reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; + backlight = <&backlight>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt deleted file mode 100644 index 9e766c5f86da..000000000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt +++ /dev/null @@ -1,56 +0,0 @@ -Samsung S6E8AA0 AMOLED LCD 5.3 inch panel - -Required properties: - - compatible: "samsung,s6e8aa0" - - reg: the virtual channel number of a DSI peripheral - - vdd3-supply: core voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin - - display-timings: timings for the connected panel as described by [1] - -Optional properties: - - power-on-delay: delay after turning regulators on [ms] - - reset-delay: delay after reset sequence [ms] - - init-delay: delay after initialization sequence [ms] - - panel-width-mm: physical panel width [mm] - - panel-height-mm: physical panel height [mm] - - flip-horizontal: boolean to flip image horizontally - - flip-vertical: boolean to flip image vertically - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [2]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - panel { - compatible = "samsung,s6e8aa0"; - reg = <0>; - vdd3-supply = <&vcclcd_reg>; - vci-supply = <&vlcd_reg>; - reset-gpios = <&gpy4 5 0>; - power-on-delay= <50>; - reset-delay = <100>; - init-delay = <100>; - panel-width-mm = <58>; - panel-height-mm = <103>; - flip-horizontal; - flip-vertical; - - display-timings { - timing0: timing-0 { - clock-frequency = <57153600>; - hactive = <720>; - vactive = <1280>; - hfront-porch = <5>; - hback-porch = <5>; - hsync-len = <5>; - vfront-porch = <13>; - vback-porch = <1>; - vsync-len = <2>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml new file mode 100644 index 000000000000..ca959451557e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6e8aa0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S6E8AA0 AMOLED LCD 5.3 inch panel + +maintainers: + - Andrzej Hajda + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,s6e8aa0 + + reg: true + reset-gpios: true + display-timings: true + + vdd3-supply: + description: core voltage supply + + vci-supply: + description: voltage supply for analog circuits + + power-on-delay: + description: delay after turning regulators on [ms] + $ref: /schemas/types.yaml#/definitions/uint32 + + reset-delay: + description: delay after reset sequence [ms] + $ref: /schemas/types.yaml#/definitions/uint32 + + init-delay: + description: delay after initialization sequence [ms] + + panel-width-mm: + description: physical panel width [mm] + + panel-height-mm: + description: physical panel height [mm] + + flip-horizontal: + description: boolean to flip image horizontally + type: boolean + + flip-vertical: + description: boolean to flip image vertically + type: boolean + +required: + - compatible + - reg + - vdd3-supply + - vci-supply + - reset-gpios + - display-timings + +additionalProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6e8aa0"; + reg = <0>; + vdd3-supply = <&vcclcd_reg>; + vci-supply = <&vlcd_reg>; + reset-gpios = <&gpy4 5 0>; + power-on-delay= <50>; + reset-delay = <100>; + init-delay = <100>; + panel-width-mm = <58>; + panel-height-mm = <103>; + flip-horizontal; + flip-vertical; + + display-timings { + timing0: timing-0 { + clock-frequency = <57153600>; + hactive = <720>; + vactive = <1280>; + hfront-porch = <5>; + hback-porch = <5>; + hsync-len = <5>; + vfront-porch = <13>; + vback-porch = <1>; + vsync-len = <2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt deleted file mode 100644 index f522bb8e47e1..000000000000 --- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt +++ /dev/null @@ -1,49 +0,0 @@ -Sharp Microelectronics 10.1" WQXGA TFT LCD panel - -This panel requires a dual-channel DSI host to operate. It supports two modes: -- left-right: each channel drives the left or right half of the screen -- even-odd: each channel drives the even or odd lines of the screen - -Each of the DSI channels controls a separate DSI peripheral. The peripheral -driven by the first link (DSI-LINK1), left or even, is considered the primary -peripheral and controls the device. The 'link2' property contains a phandle -to the peripheral driven by the second link (DSI-LINK2, right or odd). - -Note that in video mode the DSI-LINK1 interface always provides the left/even -pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it -is possible to program either link to drive the left/even or right/odd pixels -but for the sake of consistency this binding assumes that the same assignment -is chosen as for video mode. - -Required properties: -- compatible: should be "sharp,lq101r1sx01" -- reg: DSI virtual channel of the peripheral - -Required properties (for DSI-LINK1 only): -- link2: phandle to the DSI peripheral on the secondary link. Note that the - presence of this property marks the containing node as DSI-LINK1. -- power-supply: phandle of the regulator that provides the supply voltage - -Optional properties (for DSI-LINK1 only): -- backlight: phandle of the backlight device attached to the panel - -Example: - - dsi@54300000 { - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - }; - }; - - dsi@54400000 { - secondary: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml new file mode 100644 index 000000000000..a679d3647dbd --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,lq101r1sx01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sharp Microelectronics 10.1" WQXGA TFT LCD panel + +maintainers: + - Thierry Reding + +description: | + This panel requires a dual-channel DSI host to operate. It supports two modes: + - left-right: each channel drives the left or right half of the screen + - even-odd: each channel drives the even or odd lines of the screen + + Each of the DSI channels controls a separate DSI peripheral. The peripheral + driven by the first link (DSI-LINK1), left or even, is considered the primary + peripheral and controls the device. The 'link2' property contains a phandle + to the peripheral driven by the second link (DSI-LINK2, right or odd). + + Note that in video mode the DSI-LINK1 interface always provides the left/even + pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it + is possible to program either link to drive the left/even or right/odd pixels + but for the sake of consistency this binding assumes that the same assignment + is chosen as for video mode. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sharp,lq101r1sx01 + + reg: true + power-supply: true + backlight: true + + link2: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + phandle to the DSI peripheral on the secondary link. Note that the + presence of this property marks the containing node as DSI-LINK1 + +required: + - compatible + - reg + +if: + required: + - link2 +then: + required: + - power-supply + +additionalProperties: false + +examples: + - | + dsi0: dsi@fd922800 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfd922800 0x200>; + + panel: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + + link2 = <&secondary>; + + power-supply = <&power>; + backlight = <&backlight>; + }; + }; + + dsi1: dsi@fd922a00 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfd922a00 0x200>; + + secondary: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 1db608c9eef5..eaf8c54fcf50 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -152,28 +152,28 @@ additionalProperties: false examples: - | - aliases { - display0 = &lcdc0; - }; + / { + compatible = "foo"; + model = "foo"; + #address-cells = <1>; + #size-cells = <1>; - chosen { - #address-cells = <1>; - #size-cells = <1>; - stdout-path = "display0"; - framebuffer0: framebuffer@1d385000 { - compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; - allwinner,pipeline = "de_be0-lcd0"; - reg = <0x1d385000 3840000>; - width = <1600>; - height = <1200>; - stride = <3200>; - format = "r5g6b5"; - clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; - lcd-supply = <®_dc1sw>; - display = <&lcdc0>; - }; + chosen { + #address-cells = <1>; + #size-cells = <1>; + framebuffer0: framebuffer@1d385000 { + compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; + allwinner,pipeline = "de_be0-lcd0"; + reg = <0x1d385000 3840000>; + width = <1600>; + height = <1200>; + stride = <3200>; + format = "r5g6b5"; + clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; + lcd-supply = <®_dc1sw>; + display = <&lcdc0>; + }; + }; }; - lcdc0: lcdc { }; - ... diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt index aac617acb64f..8b2a71395647 100644 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt @@ -46,7 +46,7 @@ Optional nodes: crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is for Blue[3-7]. For more details see section 3.1.1 in AM335x Silicon Errata: - http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 + https://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 Example: diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml new file mode 100644 index 000000000000..52a939cade3b --- /dev/null +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/xlnx/xlnx,zynqmp-dpsub.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DisplayPort Subsystem + +description: | + The DisplayPort subsystem of Xilinx ZynqMP (Zynq UltraScale+ MPSoC) + implements the display and audio pipelines based on the DisplayPort v1.2 + standard. The subsystem includes multiple functional blocks as below: + + +------------------------------------------------------------+ + +--------+ | +----------------+ +-----------+ | + | DPDMA | --->| | --> | Video | Video +-------------+ | + | 4x vid | | | | | Rendering | -+--> | | | +------+ + | 2x aud | | | Audio/Video | --> | Pipeline | | | DisplayPort |---> | PHY0 | + +--------+ | | Buffer Manager | +-----------+ | | Source | | +------+ + | | and STC | +-----------+ | | Controller | | +------+ + Live Video --->| | --> | Audio | Audio | |---> | PHY1 | + | | | | Mixer | --+-> | | | +------+ + Live Audio --->| | --> | | || +-------------+ | + | +----------------+ +-----------+ || | + +---------------------------------------||-------------------+ + vv + Blended Video and + Mixed Audio to PL + + The Buffer Manager interacts with external interface such as DMA engines or + live audio/video streams from the programmable logic. The Video Rendering + Pipeline blends the video and graphics layers and performs colorspace + conversion. The Audio Mixer mixes the incoming audio streams. The DisplayPort + Source Controller handles the DisplayPort protocol and connects to external + PHYs. + + The subsystem supports 2 video and 2 audio streams, and various pixel formats + and depths up to 4K@30 resolution. + + Please refer to "Zynq UltraScale+ Device Technical Reference Manual" + (https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf) + for more details. + +maintainers: + - Laurent Pinchart + +properties: + compatible: + const: xlnx,zynqmp-dpsub-1.7 + + reg: + maxItems: 4 + reg-names: + items: + - const: dp + - const: blend + - const: av_buf + - const: aud + + interrupts: + maxItems: 1 + + clocks: + description: + The APB clock and at least one video clock are mandatory, the audio clock + is optional. + minItems: 2 + maxItems: 4 + items: + - description: dp_apb_clk is the APB clock + - description: dp_aud_clk is the Audio clock + - description: + dp_vtc_pixel_clk_in is the non-live video clock (from Processing + System) + - description: + dp_live_video_in_clk is the live video clock (from Programmable + Logic) + clock-names: + oneOf: + - minItems: 2 + maxItems: 3 + items: + - const: dp_apb_clk + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - minItems: 3 + maxItems: 4 + items: + - const: dp_apb_clk + - const: dp_aud_clk + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + maxItems: 4 + items: + - description: Video layer, plane 0 (RGB or luma) + - description: Video layer, plane 1 (U/V or U) + - description: Video layer, plane 2 (V) + - description: Graphics layer + dma-names: + items: + - const: vid0 + - const: vid1 + - const: vid2 + - const: gfx0 + + phys: + description: PHYs for the DP data lanes + minItems: 1 + maxItems: 2 + phy-names: + minItems: 1 + maxItems: 2 + items: + - const: dp-phy0 + - const: dp-phy1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - power-domains + - resets + - dmas + - dma-names + - phys + - phy-names + +additionalProperties: false + +examples: + - | + #include + #include + + display@fd4a0000 { + compatible = "xlnx,zynqmp-dpsub-1.7"; + reg = <0x0 0xfd4a0000 0x0 0x1000>, + <0x0 0xfd4aa000 0x0 0x1000>, + <0x0 0xfd4ab000 0x0 0x1000>, + <0x0 0xfd4ac000 0x0 0x1000>; + reg-names = "dp", "blend", "av_buf", "aud"; + interrupts = <0 119 4>; + interrupt-parent = <&gic>; + + clock-names = "dp_apb_clk", "dp_aud_clk", "dp_live_video_in_clk"; + clocks = <&dp_aclk>, <&clkc 17>, <&si570_1>; + + power-domains = <&pd_dp>; + resets = <&reset ZYNQMP_RESET_DP>; + + dma-names = "vid0", "vid1", "vid2", "gfx0"; + dmas = <&xlnx_dpdma 0>, + <&xlnx_dpdma 1>, + <&xlnx_dpdma 2>, + <&xlnx_dpdma 3>; + + phys = <&psgtr 1 PHY_TYPE_DP 0 3 27000000>, + <&psgtr 0 PHY_TYPE_DP 1 3 27000000>; + + phy-names = "dp-phy0", "dp-phy1"; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml new file mode 100644 index 000000000000..5de510f8c88c --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dpdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DisplayPort DMA Controller Device Tree Bindings + +description: | + These bindings describe the DMA engine included in the Xilinx ZynqMP + DisplayPort Subsystem. The DMA engine supports up to 6 DMA channels (3 + channels for a video stream, 1 channel for a graphics stream, and 2 channels + for an audio stream). + +maintainers: + - Laurent Pinchart + +allOf: + - $ref: "../dma-controller.yaml#" + +properties: + "#dma-cells": + const: 1 + description: | + The cell is the DMA channel ID (see dt-bindings/dma/xlnx-zynqmp-dpdma.h + for a list of channel IDs). + + compatible: + const: xlnx,zynqmp-dpdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: The AXI clock + maxItems: 1 + + clock-names: + const: axi_clk + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + + dma: dma-controller@fd4c0000 { + compatible = "xlnx,zynqmp-dpdma"; + reg = <0x0 0xfd4c0000 0x0 0x1000>; + interrupts = ; + interrupt-parent = <&gic>; + clocks = <&dpdma_clk>; + clock-names = "axi_clk"; + #dma-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index 354b448fc0c3..78456437df5f 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -11,10 +11,12 @@ Required properties: * "qcom,scm-apq8084" * "qcom,scm-ipq4019" * "qcom,scm-ipq806x" + * "qcom,scm-ipq8074" * "qcom,scm-msm8660" * "qcom,scm-msm8916" * "qcom,scm-msm8960" * "qcom,scm-msm8974" + * "qcom,scm-msm8994" * "qcom,scm-msm8996" * "qcom,scm-msm8998" * "qcom,scm-sc7180" diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index 8ab19d1d3f9a..e811cf825019 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -493,4 +493,4 @@ FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration. -- [1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf [2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf -[3] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf +[3] https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf diff --git a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt index cfa4ed42b62f..5ef659c1394d 100644 --- a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt +++ b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt @@ -1,11 +1,14 @@ Xilinx Slave Serial SPI FPGA Manager -Xilinx Spartan-6 FPGAs support a method of loading the bitstream over -what is referred to as "slave serial" interface. +Xilinx Spartan-6 and 7 Series FPGAs support a method of loading the +bitstream over what is referred to as "slave serial" interface. The slave serial link is not technically SPI, and might require extra circuits in order to play nicely with other SPI slaves on the same bus. -See https://www.xilinx.com/support/documentation/user_guides/ug380.pdf +See: +- https://www.xilinx.com/support/documentation/user_guides/ug380.pdf +- https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf +- https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf Required properties: - compatible: should contain "xlnx,fpga-slave-serial" @@ -13,6 +16,10 @@ Required properties: - prog_b-gpios: config pin (referred to as PROGRAM_B in the manual) - done-gpios: config status pin (referred to as DONE in the manual) +Optional properties: +- init-b-gpios: initialization status and configuration error pin + (referred to as INIT_B in the manual) + Example for full FPGA configuration: fpga-region0 { @@ -37,7 +44,8 @@ Example for full FPGA configuration: spi-max-frequency = <60000000>; spi-cpha; reg = <0>; - done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; prog_b-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>; + init-b-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>; + done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; }; }; diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt index 41372d441131..2aaf661c04ee 100644 --- a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt +++ b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt @@ -4,8 +4,9 @@ Required properties: - compatible : For Tegra20, must contain "nvidia,tegra20-efuse". For Tegra30, must contain "nvidia,tegra30-efuse". For Tegra114, must contain "nvidia,tegra114-efuse". For Tegra124, must contain "nvidia,tegra124-efuse". - Otherwise, must contain "nvidia,-efuse", plus one of the above, where - is tegra132. + For Tegra132 must contain "nvidia,tegra132-efuse", "nvidia,tegra124-efuse". + For Tegra210 must contain "nvidia,tegra210-efuse". For Tegra186 must contain + "nvidia,tegra186-efuse". For Tegra194 must contain "nvidia,tegra194-efuse". Details: nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data due to a hardware bug. Tegra20 also lacks certain information which is diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index dab537c20def..3126c3817e2a 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -19,6 +19,7 @@ Required properties: nxp,pca9698 nxp,pcal6416 nxp,pcal6524 + nxp,pcal9535 nxp,pcal9555a maxim,max7310 maxim,max7312 diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml new file mode 100644 index 000000000000..338c5312a106 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-pca9570.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PCA9570 I2C GPO expander + +maintainers: + - Sungbo Eo + +properties: + compatible: + enum: + - nxp,pca9570 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + gpio@24 { + compatible = "nxp,pca9570"; + reg = <0x24>; + gpio-controller; + #gpio-cells = <2>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt index 4fa4eb5507cd..f693e82b4c0f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt @@ -6,7 +6,9 @@ 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" or "xlnx,zynqmp-gpio-1.0" +- compatible : Should be "xlnx,zynq-gpio-1.0" or + "xlnx,zynqmp-gpio-1.0" or "xlnx,versal-gpio-1.0 + or "xlnx,pmc-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/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt deleted file mode 100644 index 30fd2201b3d4..000000000000 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ /dev/null @@ -1,48 +0,0 @@ -* Marvell PXA GPIO controller - -Required properties: -- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio", - "intel,pxa27x-gpio", "intel,pxa3xx-gpio", - "marvell,pxa93x-gpio", "marvell,mmp-gpio", - "marvell,mmp2-gpio" or marvell,pxa1928-gpio. -- reg : Address and length of the register set for the device -- interrupts : Should be the port interrupt shared by all gpio pins. - There're three gpio interrupts in arch-pxa, and they're gpio0, - gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp, - gpio_mux. -- interrupt-names : Should be the names of irq resources. Each interrupt - uses its own interrupt name, so there should be as many interrupt names - as referenced interrupts. -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. See gpio.txt for possible - values. - -Example for a MMP platform: - - gpio: gpio@d4019000 { - compatible = "marvell,mmp-gpio"; - reg = <0xd4019000 0x1000>; - interrupts = <49>; - interrupt-names = "gpio_mux"; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <1>; - }; - -Example for a PXA3xx platform: - - gpio: gpio@40e00000 { - compatible = "intel,pxa3xx-gpio"; - reg = <0x40e00000 0x10000>; - interrupt-names = "gpio0", "gpio1", "gpio_mux"; - interrupts = <8 9 10>; - gpio-controller; - #gpio-cells = <0x2>; - interrupt-controller; - #interrupt-cells = <0x2>; - }; diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml new file mode 100644 index 000000000000..4db3b8a3332c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/mrvl-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell PXA GPIO controller + +maintainers: + - Linus Walleij + - Bartosz Golaszewski + - Rob Herring + +allOf: + - if: + properties: + compatible: + contains: + enum: + - intel,pxa25x-gpio + - intel,pxa26x-gpio + - intel,pxa27x-gpio + - intel,pxa3xx-gpio + then: + properties: + interrupts: + minItems: 3 + maxItems: 3 + interrupt-names: + items: + - const: gpio0 + - const: gpio1 + - const: gpio_mux + - if: + properties: + compatible: + contains: + enum: + - marvell,mmp-gpio + - marvell,mmp2-gpio + then: + properties: + interrupts: + maxItems: 1 + interrupt-names: + items: + - const: gpio_mux + +properties: + $nodename: + pattern: '^gpio@[0-9a-f]+$' + + compatible: + enum: + - intel,pxa25x-gpio + - intel,pxa26x-gpio + - intel,pxa27x-gpio + - intel,pxa3xx-gpio + - marvell,mmp-gpio + - marvell,mmp2-gpio + - marvell,pxa93x-gpio + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupts: true + + interrupt-names: true + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +patternProperties: + '^gpio@[0-9a-f]*$': + type: object + properties: + reg: + maxItems: 1 + + required: + - reg + + additionalProperties: false + +required: + - compatible + - '#address-cells' + - '#size-cells' + - reg + - gpio-controller + - '#gpio-cells' + - interrupts + - interrupt-names + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + #include + gpio@40e00000 { + compatible = "intel,pxa3xx-gpio"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x40e00000 0x10000>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <8>, <9>, <10>; + interrupt-names = "gpio0", "gpio1", "gpio_mux"; + clocks = <&clks CLK_GPIO>; + interrupt-controller; + #interrupt-cells = <2>; + }; + - | + #include + gpio@d4019000 { + compatible = "marvell,mmp-gpio"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xd4019000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <49>; + interrupt-names = "gpio_mux"; + clocks = <&soc_clocks PXA910_CLK_GPIO>; + resets = <&soc_clocks PXA910_CLK_GPIO>; + interrupt-controller; + #interrupt-cells = <2>; + ranges; + + gpio@d4019000 { + reg = <0xd4019000 0x4>; + }; + + gpio@d4019004 { + reg = <0xd4019004 0x4>; + }; + + gpio@d4019008 { + reg = <0xd4019008 0x4>; + }; + + gpio@d4019100 { + reg = <0xd4019100 0x4>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt index f32bbba4d3bc..662a3c8a7d29 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt @@ -6,6 +6,7 @@ Required properties: - nvidia,gk20a - nvidia,gm20b - nvidia,gp10b + - nvidia,gv11b - reg: Physical base address and length of the controller's registers. Must contain two entries: - first entry for bar0 @@ -25,6 +26,9 @@ Required properties: If the compatible string is "nvidia,gm20b", then the following clock is also required: - ref +If the compatible string is "nvidia,gv11b", then the following clock is also +required: + - fuse - resets: Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names: Must include the following entries: @@ -88,3 +92,24 @@ Example for GP10B: power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>; iommus = <&smmu TEGRA186_SID_GPU>; }; + +Example for GV11B: + + gpu@17000000 { + compatible = "nvidia,gv11b"; + reg = <0x17000000 0x10000000>, + <0x18000000 0x10000000>; + interrupts = , + ; + interrupt-names = "stall", "nonstall"; + clocks = <&bpmp TEGRA194_CLK_GPCCLK>, + <&bpmp TEGRA194_CLK_GPU_PWR>, + <&bpmp TEGRA194_CLK_FUSE>; + clock-names = "gpu", "pwr", "fuse"; + resets = <&bpmp TEGRA194_RESET_GPU>; + reset-names = "gpu"; + dma-coherent; + + power-domains = <&bpmp TEGRA194_POWER_DOMAIN_GPU>; + iommus = <&smmu TEGRA194_SID_GPU>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/microchip,sparx5-temp.yaml b/Documentation/devicetree/bindings/hwmon/microchip,sparx5-temp.yaml new file mode 100644 index 000000000000..76be625d5646 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,sparx5-temp.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,sparx5-temp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 Temperature Monitor + +maintainers: + - Lars Povlsen + +description: | + Microchip Sparx5 embedded temperature monitor + +properties: + compatible: + enum: + - microchip,sparx5-temp + + reg: + maxItems: 1 + + clocks: + items: + - description: AHB reference clock + + '#thermal-sensor-cells': + const: 0 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + tmon0: tmon@610508110 { + compatible = "microchip,sparx5-temp"; + reg = <0x10508110 0xc>; + #thermal-sensor-cells = <0>; + clocks = <&ahb_clk>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index 90b2fa3f7752..c17e5d3ee3f1 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml @@ -18,8 +18,8 @@ description: | consumption. Datasheets: - http://www.ti.com/lit/gpn/tmp513 - http://www.ti.com/lit/gpn/tmp512 + https://www.ti.com/lit/gpn/tmp513 + https://www.ti.com/lit/gpn/tmp512 properties: diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml index da6129090a8e..78ffcab2428c 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml @@ -52,15 +52,15 @@ properties: description: sda and scl gpio, alternative for {sda,scl}-gpios i2c-gpio,sda-open-drain: - # Generate a warning if present - not: true + type: boolean + deprecated: true description: this means that something outside of our control has put the GPIO line used for SDA into open drain mode, and that something is not the GPIO chip. It is essentially an inconsistency flag. i2c-gpio,scl-open-drain: - # Generate a warning if present - not: true + type: boolean + deprecated: true description: this means that something outside of our control has put the GPIO line used for SCL into open drain mode, and that something is not the GPIO chip. It is essentially an inconsistency flag. diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt deleted file mode 100644 index f0c072ff9eca..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Freescale Low Power Inter IC (LPI2C) for i.MX - -Required properties: -- compatible : - - "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc - - "fsl,imx8qxp-lpi2c" for LPI2C compatible with the one integrated on i.MX8QXP soc - - "fsl,imx8qm-lpi2c" for LPI2C compatible with the one integrated on i.MX8QM soc -- reg : address and length of the lpi2c master registers -- interrupts : lpi2c interrupt -- clocks : lpi2c clock specifier - -Examples: - -lpi2c7: lpi2c7@40a50000 { - compatible = "fsl,imx7ulp-lpi2c"; - reg = <0x40A50000 0x10000>; - interrupt-parent = <&intc>; - interrupts = ; - clocks = <&clks IMX7ULP_CLK_LPI2C7>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml new file mode 100644 index 000000000000..ac0bc5dd64d6 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-imx-lpi2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Low Power Inter IC (LPI2C) for i.MX + +maintainers: + - Anson Huang + +properties: + compatible: + enum: + - fsl,imx7ulp-lpi2c + - fsl,imx8qxp-lpi2c + - fsl,imx8qm-lpi2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + + lpi2c7@40a50000 { + compatible = "fsl,imx7ulp-lpi2c"; + reg = <0x40A50000 0x10000>; + interrupt-parent = <&intc>; + interrupts = ; + clocks = <&clks IMX7ULP_CLK_LPI2C7>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt deleted file mode 100644 index b967544590e8..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX - -Required properties: -- compatible : - - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC - - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC - - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC -- reg : Should contain I2C/HS-I2C registers location and length -- interrupts : Should contain I2C/HS-I2C interrupt -- clocks : Should contain the I2C/HS-I2C clock specifier - -Optional properties: -- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. - The absence of the property indicates the default frequency 100 kHz. -- dmas: A list of two dma specifiers, one for each entry in dma-names. -- dma-names: should contain "tx" and "rx". -- scl-gpios: specify the gpio related to SCL pin -- sda-gpios: specify the gpio related to SDA pin -- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c - bus recovery, call it "gpio" state - -Examples: - -i2c@83fc4000 { /* I2C2 on i.MX51 */ - compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; - reg = <0x83fc4000 0x4000>; - interrupts = <63>; -}; - -i2c@70038000 { /* HS-I2C on i.MX51 */ - compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; - reg = <0x70038000 0x4000>; - interrupts = <64>; - clock-frequency = <400000>; -}; - -i2c0: i2c@40066000 { /* i2c0 on vf610 */ - compatible = "fsl,vf610-i2c"; - reg = <0x40066000 0x1000>; - interrupts =<0 71 0x04>; - dmas = <&edma0 0 50>, - <&edma0 0 51>; - dma-names = "rx","tx"; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&pinctrl_i2c1>; - pinctrl-1 = <&pinctrl_i2c1_gpio>; - scl-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>; - sda-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml new file mode 100644 index 000000000000..869f2ae3d5b3 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-imx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX + +maintainers: + - Wolfram Sang + +properties: + compatible: + oneOf: + - const: fsl,imx1-i2c + - const: fsl,imx21-i2c + - const: fsl,vf610-i2c + - items: + - const: fsl,imx35-i2c + - const: fsl,imx1-i2c + - items: + - enum: + - fsl,imx25-i2c + - fsl,imx27-i2c + - fsl,imx31-i2c + - fsl,imx50-i2c + - fsl,imx51-i2c + - fsl,imx53-i2c + - fsl,imx6q-i2c + - fsl,imx6sl-i2c + - fsl,imx6sx-i2c + - fsl,imx6sll-i2c + - fsl,imx6ul-i2c + - fsl,imx7s-i2c + - fsl,imx8mq-i2c + - fsl,imx8mm-i2c + - fsl,imx8mn-i2c + - fsl,imx8mp-i2c + - const: fsl,imx21-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ipg + + clock-frequency: + enum: [ 100000, 400000 ] + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + + sda-gpios: + maxItems: 1 + + scl-gpios: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + + i2c@83fc4000 { + compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; + reg = <0x83fc4000 0x4000>; + interrupts = <63>; + clocks = <&clks IMX5_CLK_I2C2_GATE>; + }; + + i2c@40066000 { + compatible = "fsl,vf610-i2c"; + reg = <0x40066000 0x1000>; + interrupts = <71 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks VF610_CLK_I2C0>; + clock-names = "ipg"; + dmas = <&edma0 0 50>, + <&edma0 0 51>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt deleted file mode 100644 index 4e1c8ac01eba..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Freescale MXS Inter IC (I2C) Controller - -Required properties: -- compatible: Should be "fsl,-i2c" -- reg: Should contain registers location and length -- interrupts: Should contain ERROR interrupt number -- clock-frequency: Desired I2C bus clock frequency in Hz. - Only 100000Hz and 400000Hz modes are supported. -- dmas: DMA specifier, consisting of a phandle to DMA controller node - and I2C DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. -- dma-names: Must be "rx-tx". - -Examples: - -i2c0: i2c@80058000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,imx28-i2c"; - reg = <0x80058000 2000>; - interrupts = <111>; - clock-frequency = <100000>; - dmas = <&dma_apbx 6>; - dma-names = "rx-tx"; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml new file mode 100644 index 000000000000..d3134ed775fa --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mxs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS Inter IC (I2C) Controller + +maintainers: + - Shawn Guo + +properties: + compatible: + enum: + - fsl,imx23-i2c + - fsl,imx28-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + enum: [ 100000, 400000 ] + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + i2c@80058000 { + compatible = "fsl,imx28-i2c"; + reg = <0x80058000 2000>; + interrupts = <111>; + clock-frequency = <100000>; + dmas = <&dma_apbx 6>; + dma-names = "rx-tx"; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt deleted file mode 100644 index c30783c0eca0..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt +++ /dev/null @@ -1,31 +0,0 @@ -* Marvell MMP I2C controller - -Required properties : - - - reg : Offset and length of the register set for the device - - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a - compatible processor, e.g. pxa168, pxa910, mmp2, mmp3. - For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required - as shown in the example below. - For the Armada 3700, the compatible should be "marvell,armada-3700-i2c". - -Recommended properties : - - - interrupts : the interrupt number - - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling - status register of i2c controller instead. - - mrvl,i2c-fast-mode : Enable fast mode of i2c controller. - -Examples: - twsi1: i2c@d4011000 { - compatible = "mrvl,mmp-twsi"; - reg = <0xd4011000 0x1000>; - interrupts = <7>; - mrvl,i2c-fast-mode; - }; - - twsi2: i2c@d4025000 { - compatible = "mrvl,mmp-twsi"; - reg = <0xd4025000 0x1000>; - interrupts = <58>; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml new file mode 100644 index 000000000000..da6e8bdc4037 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-pxa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP I2C controller bindings + +maintainers: + - Rob Herring + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + not: + required: + - mrvl,i2c-polling + then: + required: + - interrupts + +properties: + compatible: + enum: + - mrvl,mmp-twsi + - mrvl,pxa-i2c + - marvell,armada-3700-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + + resets: + minItems: 1 + + mrvl,i2c-polling: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Disable interrupt of i2c controller. Polling status register of i2c + controller instead. + + mrvl,i2c-fast-mode: + $ref: /schemas/types.yaml#/definitions/flag + description: Enable fast mode of i2c controller. + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - '#address-cells' + - '#size-cells' + +examples: + - | + #include + i2c@d4011000 { + compatible = "mrvl,mmp-twsi"; + reg = <0xd4011000 0x1000>; + interrupts = <7>; + clocks = <&soc_clocks MMP2_CLK_TWSI1>; + mrvl,i2c-fast-mode; + #address-cells = <1>; + #size-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt index 18c0de362451..3f2f990c2e62 100644 --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt @@ -35,12 +35,12 @@ Required properties: Due to above changes, Tegra114 I2C driver makes incompatible with previous hardware driver. Hence, tegra114 I2C controller is compatible with "nvidia,tegra114-i2c". - nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is part of the - host1x domain and typically used for camera use-cases. This VI I2C - controller is mostly compatible with the programming model of the - regular I2C controllers with a few exceptions. The I2C registers start - at an offset of 0xc00 (instead of 0), registers are 16 bytes apart - (rather than 4) and the controller does not support slave mode. + nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is on host1x bus + and is part of VE power domain and typically used for camera use-cases. + This VI I2C controller is mostly compatible with the programming model + of the regular I2C controllers with a few exceptions. The I2C registers + start at an offset of 0xc00 (instead of 0), registers are 16 bytes + apart (rather than 4) and the controller does not support slave mode. - reg: Should contain I2C controller registers physical address and length. - interrupts: Should contain I2C controller interrupts. - address-cells: Address cells for I2C device address. @@ -53,10 +53,17 @@ Required properties: - fast-clk Tegra114: - div-clk + Tegra210: + - div-clk + - slow (only for nvidia,tegra210-i2c-vi compatible node) - resets: Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names: Must include the following entries: - i2c +- power-domains: Only for nvidia,tegra210-i2c-vi compatible node and must + include venc powergate node as vi i2c is part of VE power domain. + tegra210-i2c-vi: + - pd_venc - dmas: Must contain an entry for each entry in clock-names. See ../dma/dma.txt for details. - dma-names: Must include the following entries: diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt index c82794002595..89647d714387 100644 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt @@ -21,7 +21,7 @@ controller state. The mux controller state is described in Example: mux: mux-controller { - compatible = "mux-gpio"; + compatible = "gpio-mux"; #mux-control-cells = <0>; mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, diff --git a/Documentation/devicetree/bindings/input/imx-keypad.txt b/Documentation/devicetree/bindings/input/imx-keypad.txt deleted file mode 100644 index 2ebaf7d26843..000000000000 --- a/Documentation/devicetree/bindings/input/imx-keypad.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Freescale i.MX Keypad Port(KPP) device tree bindings - -The KPP is designed to interface with a keypad matrix with 2-point contact -or 3-point contact keys. The KPP is designed to simplify the software task -of scanning a keypad matrix. The KPP is capable of detecting, debouncing, -and decoding one or multiple keys pressed simultaneously on a keypad. - -Required SoC Specific Properties: -- compatible: Should be "fsl,-kpp". - -- reg: Physical base address of the KPP and length of memory mapped - region. - -- interrupts: The KPP interrupt number to the CPU(s). - -- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy -clock(The clock for the KPP is provided by the SoCs automatically). - -Required Board Specific Properties: -- pinctrl-names: The definition can be found at -pinctrl/pinctrl-bindings.txt. - -- pinctrl-0: The definition can be found at -pinctrl/pinctrl-bindings.txt. - -- linux,keymap: The definition can be found at -bindings/input/matrix-keymap.txt. - -Example: -kpp: kpp@73f94000 { - compatible = "fsl,imx51-kpp", "fsl,imx21-kpp"; - reg = <0x73f94000 0x4000>; - interrupts = <60>; - clocks = <&clks 0>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_kpp_1>; - linux,keymap = <0x00000067 /* KEY_UP */ - 0x0001006c /* KEY_DOWN */ - 0x00020072 /* KEY_VOLUMEDOWN */ - 0x00030066 /* KEY_HOME */ - 0x0100006a /* KEY_RIGHT */ - 0x01010069 /* KEY_LEFT */ - 0x0102001c /* KEY_ENTER */ - 0x01030073 /* KEY_VOLUMEUP */ - 0x02000040 /* KEY_F6 */ - 0x02010042 /* KEY_F8 */ - 0x02020043 /* KEY_F9 */ - 0x02030044 /* KEY_F10 */ - 0x0300003b /* KEY_F1 */ - 0x0301003c /* KEY_F2 */ - 0x0302003d /* KEY_F3 */ - 0x03030074>; /* KEY_POWER */ -}; diff --git a/Documentation/devicetree/bindings/input/imx-keypad.yaml b/Documentation/devicetree/bindings/input/imx-keypad.yaml new file mode 100644 index 000000000000..7432c6e8cf3a --- /dev/null +++ b/Documentation/devicetree/bindings/input/imx-keypad.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/imx-keypad.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX Keypad Port(KPP) device tree bindings + +maintainers: + - Liu Ying + +allOf: + - $ref: "/schemas/input/matrix-keymap.yaml#" + +description: | + The KPP is designed to interface with a keypad matrix with 2-point contact + or 3-point contact keys. The KPP is designed to simplify the software task + of scanning a keypad matrix. The KPP is capable of detecting, debouncing, + and decoding one or multiple keys pressed simultaneously on a keypad. + +properties: + compatible: + oneOf: + - const: fsl,imx21-kpp + - items: + - enum: + - fsl,imx25-kpp + - fsl,imx27-kpp + - fsl,imx31-kpp + - fsl,imx35-kpp + - fsl,imx51-kpp + - fsl,imx53-kpp + - fsl,imx50-kpp + - fsl,imx6q-kpp + - fsl,imx6sx-kpp + - fsl,imx6sl-kpp + - fsl,imx6sll-kpp + - fsl,imx6ul-kpp + - fsl,imx7d-kpp + - const: fsl,imx21-kpp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - linux,keymap + +unevaluatedProperties: false + +examples: + - | + keypad@73f94000 { + compatible = "fsl,imx51-kpp", "fsl,imx21-kpp"; + reg = <0x73f94000 0x4000>; + interrupts = <60>; + clocks = <&clks 0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_kpp_1>; + linux,keymap = <0x00000067 /* KEY_UP */ + 0x0001006c /* KEY_DOWN */ + 0x00020072 /* KEY_VOLUMEDOWN */ + 0x00030066 /* KEY_HOME */ + 0x0100006a /* KEY_RIGHT */ + 0x01010069 /* KEY_LEFT */ + 0x0102001c /* KEY_ENTER */ + 0x01030073 /* KEY_VOLUMEUP */ + 0x02000040 /* KEY_F6 */ + 0x02010042 /* KEY_F8 */ + 0x02020043 /* KEY_F9 */ + 0x02030044 /* KEY_F10 */ + 0x0300003b /* KEY_F1 */ + 0x0301003c /* KEY_F2 */ + 0x0302003d /* KEY_F3 */ + 0x03030074>; /* KEY_POWER */ + }; diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt index c54919fad17e..79f6d01aecaa 100644 --- a/Documentation/devicetree/bindings/input/matrix-keymap.txt +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt @@ -1,27 +1 @@ -A simple common binding for matrix-connected key boards. Currently targeted at -defining the keys in the scope of linux key codes since that is a stable and -standardized interface at this time. - -Required properties: -- linux,keymap: an array of packed 1-cell entries containing the equivalent - of row, column and linux key-code. The 32-bit big endian cell is packed - as: - row << 24 | column << 16 | key-code - -Optional properties: -Properties for the number of rows and columns are optional because some -drivers will use fixed values for these. -- keypad,num-rows: Number of row lines connected to the keypad controller. -- keypad,num-columns: Number of column lines connected to the keypad - controller. - -Some users of this binding might choose to specify secondary keymaps for -cases where there is a modifier key such as a Fn key. Proposed names -for said properties are "linux,fn-keymap" or with another descriptive -word for the modifier other from "Fn". - -Example: - linux,keymap = < 0x00030012 - 0x0102003a >; - keypad,num-rows = <2>; - keypad,num-columns = <8>; +This file has been moved to matrix-keymap.yaml diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.yaml b/Documentation/devicetree/bindings/input/matrix-keymap.yaml new file mode 100644 index 000000000000..c3bf09156783 --- /dev/null +++ b/Documentation/devicetree/bindings/input/matrix-keymap.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/matrix-keymap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common key matrices binding for matrix-connected key boards + +maintainers: + - Olof Johansson + +description: | + A simple common binding for matrix-connected key boards. Currently targeted at + defining the keys in the scope of linux key codes since that is a stable and + standardized interface at this time. + + Some users of this binding might choose to specify secondary keymaps for + cases where there is a modifier key such as a Fn key. Proposed names + for said properties are "linux,fn-keymap" or with another descriptive + word for the modifier other from "Fn". + +properties: + linux,keymap: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + description: | + An array of packed 1-cell entries containing the equivalent of row, + column and linux key-code. The 32-bit big endian cell is packed as: + row << 24 | column << 16 | key-code + + keypad,num-rows: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of row lines connected to the keypad controller. + + keypad,num-columns: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of column lines connected to the keypad controller. + +examples: + - | + keypad { + /* ... */ + linux,keymap = < 0x00030012 + 0x0102003a >; + keypad,num-rows = <2>; + keypad,num-columns = <8>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt index d514ec060a4a..021cf822395c 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt @@ -2,7 +2,10 @@ Broadcom Generic Level 2 Interrupt Controller Required properties: -- compatible: should be "brcm,l2-intc" for latched interrupt controllers +- compatible: should be one of: + "brcm,hif-spi-l2-intc" or + "brcm,upg-aux-aon-l2-intc" or + "brcm,l2-intc" for latched interrupt controllers should be "brcm,bcm7271-l2-intc" for level interrupt controllers - reg: specifies the base physical address and size of the registers - interrupt-controller: identifies the node as an interrupt controller diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml index e865cd8f96a9..87a74558204f 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml @@ -22,8 +22,8 @@ properties: interrupts: minItems: 1 - maxItems: 4 - description: Four parent interrupts that receive chained interrupts. + maxItems: 8 + description: Eight parent interrupts that receive chained interrupts. interrupt-controller: true diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index b1db21ed44e9..03fc4f5b4b39 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -51,8 +51,8 @@ properties: description: | This property points how the children interrupts will be mapped into CPU interrupt lines. Each cell refers to a parent interrupt line from 0 to 3 - and each bit in the cell refers to a children interrupt fron 0 to 31. - If a CPU interrupt line didn't connected with liointc, then keep it's + and each bit in the cell refers to a child interrupt from 0 to 31. + If a CPU interrupt line didn't connect with liointc, then keep its cell with zero. $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 4 diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt deleted file mode 100644 index a0ed02725a9d..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt +++ /dev/null @@ -1,64 +0,0 @@ -* Marvell MMP Interrupt controller - -Required properties: -- compatible : Should be - "mrvl,mmp-intc" on Marvel MMP, - "mrvl,mmp2-intc" along with "mrvl,mmp2-mux-intc" on MMP2 or - "marvell,mmp3-intc" with "mrvl,mmp2-mux-intc" on MMP3 -- reg : Address and length of the register set of the interrupt controller. - If the interrupt controller is intc, address and length means the range - of the whole interrupt controller. The "marvell,mmp3-intc" controller - also has a secondary range for the second CPU core. If the interrupt - controller is mux-intc, address and length means one register. Since - address of mux-intc is in the range of intc. mux-intc is secondary - interrupt controller. -- reg-names : Name of the register set of the interrupt controller. It's - only required in mux-intc interrupt controller. -- interrupts : Should be the port interrupt shared by mux interrupts. It's - only required in mux-intc interrupt controller. -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. -- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt - controller. -- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge - detection first. - -Example: - intc: interrupt-controller@d4282000 { - compatible = "mrvl,mmp2-intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xd4282000 0x1000>; - mrvl,intc-nr-irqs = <64>; - }; - - intcmux4@d4282150 { - compatible = "mrvl,mmp2-mux-intc"; - interrupts = <4>; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x150 0x4>, <0x168 0x4>; - reg-names = "mux status", "mux mask"; - mrvl,intc-nr-irqs = <2>; - }; - -* Marvell Orion Interrupt controller - -Required properties -- compatible : Should be "marvell,orion-intc". -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. Supported value is <1>. -- interrupt-controller : Declare this node to be an interrupt controller. -- reg : Interrupt mask address. A list of 4 byte ranges, one per controller. - One entry in the list represents 32 interrupts. - -Example: - - intc: interrupt-controller { - compatible = "marvell,orion-intc", "marvell,intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xfed20204 0x04>, - <0xfed20214 0x04>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml new file mode 100644 index 000000000000..372ccbfae771 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/mrvl,intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP/Orion Interrupt controller bindings + +maintainers: + - Thomas Gleixner + - Jason Cooper + - Marc Zyngier + - Rob Herring + +allOf: + - if: + properties: + compatible: + not: + contains: + const: marvell,orion-intc + then: + required: + - mrvl,intc-nr-irqs + - if: + properties: + compatible: + contains: + enum: + - mrvl,mmp-intc + - mrvl,mmp2-intc + then: + properties: + reg: + maxItems: 1 + - if: + properties: + compatible: + contains: + enum: + - marvell,mmp3-intc + - mrvl,mmp2-mux-intc + then: + properties: + reg: + minItems: 2 + - if: + properties: + compatible: + contains: + const: mrvl,mmp2-mux-intc + then: + properties: + interrupts: + maxItems: 1 + reg-names: + items: + - const: 'mux status' + - const: 'mux mask' + required: + - interrupts + else: + properties: + interrupts: false + +properties: + '#interrupt-cells': + const: 1 + + compatible: + enum: + - mrvl,mmp-intc + - mrvl,mmp2-intc + - marvell,mmp3-intc + - marvell,orion-intc + - mrvl,mmp2-mux-intc + + reg: + minItems: 1 + maxItems: 2 + + reg-names: true + + interrupts: true + + interrupt-controller: true + + mrvl,intc-nr-irqs: + description: | + Specifies the number of interrupts in the interrupt controller. + $ref: /schemas/types.yaml#/definitions/uint32 + + mrvl,clr-mfp-irq: + description: | + Specifies the interrupt that needs to clear MFP edge detection first. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - '#interrupt-cells' + - compatible + - reg + - interrupt-controller + +additionalProperties: false + +examples: + - | + interrupt-controller@d4282000 { + compatible = "mrvl,mmp2-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xd4282000 0x1000>; + mrvl,intc-nr-irqs = <64>; + }; + + interrupt-controller@d4282150 { + compatible = "mrvl,mmp2-mux-intc"; + interrupts = <4>; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x150 0x4>, <0x168 0x4>; + reg-names = "mux status", "mux mask"; + mrvl,intc-nr-irqs = <2>; + }; + - | + interrupt-controller@fed20204 { + compatible = "marvell,orion-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xfed20204 0x04>, + <0xfed20214 0x04>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.txt deleted file mode 100644 index 727b7e4cd6e0..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.txt +++ /dev/null @@ -1,43 +0,0 @@ -DT bindings for the Renesas RZ/A1 Interrupt Controller - -The RZ/A1 Interrupt Controller is a front-end for the GIC found on Renesas -RZ/A1 and RZ/A2 SoCs: - - IRQ sense select for 8 external interrupts, 1:1-mapped to 8 GIC SPI - interrupts, - - NMI edge select. - -Required properties: - - compatible: Must be "renesas,-irqc", and "renesas,rza1-irqc" as - fallback. - Examples with soctypes are: - - "renesas,r7s72100-irqc" (RZ/A1H) - - "renesas,r7s9210-irqc" (RZ/A2M) - - #interrupt-cells: Must be 2 (an interrupt index and flags, as defined - in interrupts.txt in this directory) - - #address-cells: Must be zero - - interrupt-controller: Marks the device as an interrupt controller - - reg: Base address and length of the memory resource used by the interrupt - controller - - interrupt-map: Specifies the mapping from external interrupts to GIC - interrupts - - interrupt-map-mask: Must be <7 0> - -Example: - - irqc: interrupt-controller@fcfef800 { - compatible = "renesas,r7s72100-irqc", "renesas,rza1-irqc"; - #interrupt-cells = <2>; - #address-cells = <0>; - interrupt-controller; - reg = <0xfcfef800 0x6>; - interrupt-map = - <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, - <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, - <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, - <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, - <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; - interrupt-map-mask = <7 0>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.yaml new file mode 100644 index 000000000000..755cdfabfcd0 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/renesas,rza1-irqc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/A1 Interrupt Controller + +maintainers: + - Chris Brandt + - Geert Uytterhoeven + +description: | + The RZ/A1 Interrupt Controller is a front-end for the GIC found on Renesas RZ/A1 and + RZ/A2 SoCs: + - IRQ sense select for 8 external interrupts, 1:1-mapped to 8 GIC SPI interrupts, + - NMI edge select. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,r7s72100-irqc # RZ/A1H + - renesas,r7s9210-irqc # RZ/A2M + - const: renesas,rza1-irqc + + '#interrupt-cells': + const: 2 + + '#address-cells': + const: 0 + + interrupt-controller: true + + reg: + maxItems: 1 + + interrupt-map: + maxItems: 8 + description: Specifies the mapping from external interrupts to GIC interrupts. + + interrupt-map-mask: + items: + - const: 7 + - const: 0 + +required: + - compatible + - '#interrupt-cells' + - '#address-cells' + - interrupt-controller + - reg + - interrupt-map + - interrupt-map-mask + +additionalProperties: false + +examples: + - | + #include + irqc: interrupt-controller@fcfef800 { + compatible = "renesas,r7s72100-irqc", "renesas,rza1-irqc"; + #interrupt-cells = <2>; + #address-cells = <0>; + interrupt-controller; + reg = <0xfcfef800 0x6>; + interrupt-map = + <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + interrupt-map-mask = <7 0>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt index 1a8718f8855d..178fca08278f 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt @@ -55,7 +55,7 @@ Required Properties: corresponds to a range of host irqs. For more details on TISCI IRQ resource management refer: -http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html +https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html Example: -------- diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index 39675cf4ed71..5e4fe54f51cd 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -32,6 +32,7 @@ properties: - enum: - renesas,ipmmu-r8a774a1 # RZ/G2M - renesas,ipmmu-r8a774b1 # RZ/G2N + - renesas,ipmmu-r8a774e1 # RZ/G2H - renesas,ipmmu-r8a774c0 # RZ/G2E - renesas,ipmmu-r8a7795 # R-Car H3 - renesas,ipmmu-r8a7796 # R-Car M3-W diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt deleted file mode 100644 index 321be6640533..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt +++ /dev/null @@ -1,16 +0,0 @@ -gpio-backlight bindings - -Required properties: - - compatible: "gpio-backlight" - - gpios: describes the gpio that is used for enabling/disabling the backlight. - refer to bindings/gpio/gpio.txt for more details. - -Optional properties: - - default-on: enable the backlight at boot. - -Example: - backlight { - compatible = "gpio-backlight"; - gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; - default-on; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml new file mode 100644 index 000000000000..75cc569b9c55 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/gpio-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: gpio-backlight bindings + +maintainers: + - Lee Jones + - Daniel Thompson + - Jingoo Han + +properties: + compatible: + const: gpio-backlight + + gpios: + description: The gpio that is used for enabling/disabling the backlight. + maxItems: 1 + + default-on: + description: enable the backlight at boot. + type: boolean + +required: + - compatible + - gpios + +additionalProperties: false + +examples: + - | + #include + backlight { + compatible = "gpio-backlight"; + gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; + default-on; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt deleted file mode 100644 index 4c7dfbe7f67a..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt +++ /dev/null @@ -1,28 +0,0 @@ -led-backlight bindings - -This binding is used to describe a basic backlight device made of LEDs. -It can also be used to describe a backlight device controlled by the output of -a LED driver. - -Required properties: - - compatible: "led-backlight" - - leds: a list of LEDs - -Optional properties: - - brightness-levels: Array of distinct brightness levels. The levels must be - in the range accepted by the underlying LED devices. - This is used to translate a backlight brightness level - into a LED brightness level. If it is not provided, the - identity mapping is used. - - - default-brightness-level: The default brightness level. - -Example: - - backlight { - compatible = "led-backlight"; - - leds = <&led1>, <&led2>; - brightness-levels = <0 4 8 16 32 64 128 255>; - default-brightness-level = <6>; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml new file mode 100644 index 000000000000..625082bf3892 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/led-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: led-backlight bindings + +maintainers: + - Lee Jones + - Daniel Thompson + - Jingoo Han + +description: + This binding is used to describe a basic backlight device made of LEDs. It + can also be used to describe a backlight device controlled by the output of + a LED driver. + +properties: + compatible: + const: led-backlight + + leds: + description: A list of LED nodes + $ref: /schemas/types.yaml#/definitions/phandle-array + + brightness-levels: + description: + Array of distinct brightness levels. The levels must be in the range + accepted by the underlying LED devices. This is used to translate a + backlight brightness level into a LED brightness level. If it is not + provided, the identity mapping is used. + $ref: /schemas/types.yaml#/definitions/uint32-array + + default-brightness-level: + description: + The default brightness level (index into the array defined by the + "brightness-levels" property). + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - leds + +additionalProperties: false + +examples: + - | + backlight { + compatible = "led-backlight"; + + leds = <&led1>, <&led2>; + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt deleted file mode 100644 index 64fa2fbd98c9..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt +++ /dev/null @@ -1,61 +0,0 @@ -pwm-backlight bindings - -Required properties: - - compatible: "pwm-backlight" - - pwms: OF device-tree PWM specification (see PWM binding[0]) - - power-supply: regulator for supply voltage - -Optional properties: - - pwm-names: a list of names for the PWM devices specified in the - "pwms" property (see PWM binding[0]) - - enable-gpios: contains a single GPIO specifier for the GPIO which enables - and disables the backlight (see GPIO binding[1]) - - post-pwm-on-delay-ms: Delay in ms between setting an initial (non-zero) PWM - and enabling the backlight using GPIO. - - pwm-off-delay-ms: Delay in ms between disabling the backlight using GPIO - and setting PWM value to 0. - - brightness-levels: Array of distinct brightness levels. Typically these - are in the range from 0 to 255, but any range starting at - 0 will do. The actual brightness level (PWM duty cycle) - will be interpolated from these values. 0 means a 0% duty - cycle (darkest/off), while the last value in the array - represents a 100% duty cycle (brightest). - - default-brightness-level: The default brightness level (index into the - array defined by the "brightness-levels" property). - - num-interpolated-steps: Number of interpolated steps between each value - of brightness-levels table. This way a high - resolution pwm duty cycle can be used without - having to list out every possible value in the - brightness-level array. - -[0]: Documentation/devicetree/bindings/pwm/pwm.txt -[1]: Documentation/devicetree/bindings/gpio/gpio.txt - -Example: - - backlight { - compatible = "pwm-backlight"; - pwms = <&pwm 0 5000000>; - - brightness-levels = <0 4 8 16 32 64 128 255>; - default-brightness-level = <6>; - - power-supply = <&vdd_bl_reg>; - enable-gpios = <&gpio 58 0>; - post-pwm-on-delay-ms = <10>; - pwm-off-delay-ms = <10>; - }; - -Example using num-interpolation-steps: - - backlight { - compatible = "pwm-backlight"; - pwms = <&pwm 0 5000000>; - - brightness-levels = <0 2048 4096 8192 16384 65535>; - num-interpolated-steps = <2048>; - default-brightness-level = <4096>; - - power-supply = <&vdd_bl_reg>; - enable-gpios = <&gpio 58 0>; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml new file mode 100644 index 000000000000..fcb8429f3088 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: pwm-backlight bindings + +maintainers: + - Lee Jones + - Daniel Thompson + - Jingoo Han + +properties: + compatible: + const: pwm-backlight + + pwms: + maxItems: 1 + + pwm-names: true + + power-supply: + description: regulator for supply voltage + + enable-gpios: + description: + Contains a single GPIO specifier for the GPIO which enables and disables + the backlight. + maxItems: 1 + + post-pwm-on-delay-ms: + description: + Delay in ms between setting an initial (non-zero) PWM and enabling the + backlight using GPIO. + + pwm-off-delay-ms: + description: + Delay in ms between disabling the backlight using GPIO and setting PWM + value to 0. + + brightness-levels: + description: + Array of distinct brightness levels. Typically these are in the range + from 0 to 255, but any range starting at 0 will do. The actual brightness + level (PWM duty cycle) will be interpolated from these values. 0 means a + 0% duty cycle (darkest/off), while the last value in the array represents + a 100% duty cycle (brightest). + $ref: /schemas/types.yaml#/definitions/uint32-array + + default-brightness-level: + description: + The default brightness level (index into the array defined by the + "brightness-levels" property). + $ref: /schemas/types.yaml#/definitions/uint32 + + num-interpolated-steps: + description: + Number of interpolated steps between each value of brightness-levels + table. This way a high resolution pwm duty cycle can be used without + having to list out every possible value in the brightness-level array. + $ref: /schemas/types.yaml#/definitions/uint32 + +dependencies: + default-brightness-level: [brightness-levels] + num-interpolated-steps: [brightness-levels] + +required: + - compatible + - pwms + - power-supply + +additionalProperties: false + +examples: + - | + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + + power-supply = <&vdd_bl_reg>; + enable-gpios = <&gpio 58 0>; + post-pwm-on-delay-ms = <10>; + pwm-off-delay-ms = <10>; + }; + + - | + // Example using num-interpolation-steps: + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 2048 4096 8192 16384 65535>; + num-interpolated-steps = <2048>; + default-brightness-level = <4096>; + + power-supply = <&vdd_bl_reg>; + enable-gpios = <&gpio 58 0>; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml new file mode 100644 index 000000000000..24ad1446445e --- /dev/null +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/cznic,turris-omnia-leds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CZ.NIC's Turris Omnia LEDs driver + +maintainers: + - Marek Behún + +description: + This module adds support for the RGB LEDs found on the front panel of the + Turris Omnia router. There are 12 RGB LEDs that are controlled by a + microcontroller that communicates via the I2C bus. Each LED is described + as a subnode of this I2C device. + +properties: + compatible: + const: cznic,turris-omnia-leds + + reg: + description: I2C slave address of the microcontroller. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^multi-led[0-9a-f]$": + type: object + allOf: + - $ref: leds-class-multicolor.yaml# + description: + This node represents one of the RGB LED devices on Turris Omnia. + No subnodes need to be added for subchannels since this controller only + supports RGB LEDs. + + properties: + reg: + minimum: 0 + maximum: 11 + description: + This property identifies one of the LEDs on the front panel of the + Turris Omnia router. + + required: + - reg + +additionalProperties: false + +examples: + - | + + #include + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@2b { + compatible = "cznic,turris-omnia-leds"; + reg = <0x2b>; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + /* + * No subnodes are needed, this controller only supports RGB + * LEDs. + */ + reg = <0>; + color = ; + function = LED_FUNCTION_POWER; + linux,default-trigger = "heartbeat"; + }; + + multi-led@a { + reg = <0xa>; + color = ; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <1>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file mode 100644 index 000000000000..b55e1f1308a4 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for the multicolor LED class. + +maintainers: + - Dan Murphy + +description: | + Bindings for multi color LEDs show how to describe current outputs of + either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV + etc.) or standalone LEDs, to achieve logically grouped multi-color LED + modules. This is achieved by adding multi-led nodes layer to the + monochrome LED bindings. + The nodes and properties defined in this document are unique to the multicolor + LED class. Common LED nodes and properties are inherited from the common.txt + within this documentation directory. + +patternProperties: + "^multi-led@([0-9a-f])$": + type: object + description: Represents the LEDs that are to be grouped. + properties: + color: + const: 8 # LED_COLOR_ID_MULTI + description: | + For multicolor LED support this property should be defined as + LED_COLOR_ID_MULTI which can be found in include/linux/leds/common.h. + + $ref: "common.yaml#" + + required: + - color +... diff --git a/Documentation/devicetree/bindings/leds/leds-lm3532.txt b/Documentation/devicetree/bindings/leds/leds-lm3532.txt index 53793213dd52..097490a5ff91 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3532.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3532.txt @@ -102,4 +102,4 @@ led-controller@38 { }; For more product information please see the links below: -http://www.ti.com/product/LM3532 +https://www.ti.com/product/LM3532 diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt index 095dafb6ec7f..17e940025dc2 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt @@ -47,5 +47,5 @@ led-controller@64 { } For more product information please see the links below: -http://www.ti.com/product/LM36010 -http://www.ti.com/product/LM36011 +https://www.ti.com/product/LM36010 +https://www.ti.com/product/LM36011 diff --git a/Documentation/devicetree/bindings/leds/leds-lm36274.txt b/Documentation/devicetree/bindings/leds/leds-lm36274.txt index 39c230d59a4d..de6f4931fb31 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm36274.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm36274.txt @@ -82,4 +82,4 @@ lm36274@11 { }; For more product information please see the link below: -http://www.ti.com/lit/ds/symlink/lm36274.pdf +https://www.ti.com/lit/ds/symlink/lm36274.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt index 501468aa4d38..b1103d961d6c 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt @@ -62,4 +62,4 @@ led-controller@36 { } For more product information please see the link below: -http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf +https://www.ti.com/lit/ds/snvsa29/snvsa29.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-lm3697.txt b/Documentation/devicetree/bindings/leds/leds-lm3697.txt index 63992d732959..221b37b6049b 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3697.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt @@ -70,4 +70,4 @@ led-controller@36 { } For more product information please see the link below: -http://www.ti.com/lit/ds/symlink/lm3697.pdf +https://www.ti.com/lit/ds/symlink/lm3697.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt deleted file mode 100644 index 1b66a413fb9d..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ /dev/null @@ -1,228 +0,0 @@ -Binding for TI/National Semiconductor LP55xx Led Drivers - -Required properties: -- compatible: one of - national,lp5521 - national,lp5523 - ti,lp55231 - ti,lp5562 - ti,lp8501 - -- reg: I2C slave address -- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) - -Each child has own specific current settings -- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected) -- max-cur: Maximun current at each led channel. - -Optional properties: -- enable-gpio: GPIO attached to the chip's enable pin -- label: Used for naming LEDs -- pwr-sel: LP8501 specific property. Power selection for output channels. - 0: D1~9 are connected to VDD - 1: D1~6 with VDD, D7~9 with VOUT - 2: D1~6 with VOUT, D7~9 with VDD - 3: D1~9 are connected to VOUT - -Alternatively, each child can have a specific channel name and trigger: -- chan-name (optional): name of channel -- linux,default-trigger (optional): see - Documentation/devicetree/bindings/leds/common.txt - -example 1) LP5521 -3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0', -'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger -on channel 0. - -lp5521@32 { - compatible = "national,lp5521"; - reg = <0x32>; - label = "lp5521_pri"; - clock-mode = /bits/ 8 <2>; - - chan0 { - led-cur = /bits/ 8 <0x2f>; - max-cur = /bits/ 8 <0x5f>; - linux,default-trigger = "heartbeat"; - }; - - chan1 { - led-cur = /bits/ 8 <0x2f>; - max-cur = /bits/ 8 <0x5f>; - }; - - chan2 { - led-cur = /bits/ 8 <0x2f>; - max-cur = /bits/ 8 <0x5f>; - }; -}; - -example 2) LP5523 -9 LED channels with specific name. Internal clock used. -The I2C slave address is configurable with ASEL1 and ASEL0 pins. -Available addresses are 32/33/34/35h. - -ASEL1 ASEL0 Address -------------------------- - GND GND 32h - GND VEN 33h - VEN GND 34h - VEN VEN 35h - -lp5523@32 { - compatible = "national,lp5523"; - reg = <0x32>; - clock-mode = /bits/ 8 <1>; - - chan0 { - chan-name = "d1"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan1 { - chan-name = "d2"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan2 { - chan-name = "d3"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan3 { - chan-name = "d4"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan4 { - chan-name = "d5"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan5 { - chan-name = "d6"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan6 { - chan-name = "d7"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan7 { - chan-name = "d8"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan8 { - chan-name = "d9"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; -}; - -example 3) LP5562 -4 channels are defined. - -lp5562@30 { - compatible = "ti,lp5562"; - reg = <0x30>; - clock-mode = /bits/8 <2>; - - chan0 { - chan-name = "R"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; - - chan1 { - chan-name = "G"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; - - chan2 { - chan-name = "B"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; - - chan3 { - chan-name = "W"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; -}; - -example 4) LP8501 -9 channels are defined. The 'pwr-sel' is LP8501 specific property. -Others are same as LP5523. - -lp8501@32 { - compatible = "ti,lp8501"; - reg = <0x32>; - clock-mode = /bits/ 8 <2>; - pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ - - chan0 { - chan-name = "d1"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan1 { - chan-name = "d2"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan2 { - chan-name = "d3"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan3 { - chan-name = "d4"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan4 { - chan-name = "d5"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan5 { - chan-name = "d6"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan6 { - chan-name = "d7"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan7 { - chan-name = "d8"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan8 { - chan-name = "d9"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml new file mode 100644 index 000000000000..b1bb3feb0f4d --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -0,0 +1,220 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI/National Semiconductor LP55xx and LP8501 LED Drivers + +maintainers: + - Jacek Anaszewski + - Pavel Machek + +description: | + Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel + LED Drivers. + + For more product information please see the link below: + https://www.ti.com/lit/gpn/lp5521 + https://www.ti.com/lit/gpn/lp5523 + https://www.ti.com/lit/gpn/lp55231 + https://www.ti.com/lit/gpn/lp5562 + https://www.ti.com/lit/gpn/lp8501 + +properties: + compatible: + enum: + - national,lp5521 + - national,lp5523 + - ti,lp55231 + - ti,lp5562 + - ti,lp8501 + + reg: + maxItems: 1 + description: I2C slave address + + clock-mode: + $ref: /schemas/types.yaml#definitions/uint8 + description: | + Input clock mode + enum: + - 0 # automode + - 1 # internal + - 2 # external + + enable-gpio: + maxItems: 1 + description: | + GPIO attached to the chip's enable pin + + pwr-sel: + $ref: /schemas/types.yaml#definitions/uint8 + description: | + LP8501 specific property. Power selection for output channels. + enum: + - 0 # D1~9 are connected to VDD + - 1 # D1~6 with VDD, D7~9 with VOUT + - 2 # D1~6 with VOUT, D7~9 with VDD + - 3 # D1~9 are connected to VOUT + +patternProperties: + "(^led@[0-9a-f]$|led)": + type: object + $ref: common.yaml# + properties: + led-cur: + $ref: /schemas/types.yaml#definitions/uint8 + description: | + Current setting at each LED channel (mA x10, 0 if LED is not connected) + minimum: 0 + maximum: 255 + + max-cur: + $ref: /schemas/types.yaml#definitions/uint8 + description: Maximun current at each LED channel. + + reg: + description: | + Output channel for the LED. This is zero based channel identifier and + the data sheet is a one based channel identifier. + reg value to output to LED output number + enum: + - 0 # LED output D1 + - 1 # LED output D2 + - 2 # LED output D3 + - 3 # LED output D4 + - 4 # LED output D5 + - 5 # LED output D6 + - 6 # LED output D7 + - 7 # LED output D8 + - 8 # LED output D9 + + chan-name: + $ref: /schemas/types.yaml#definitions/string + description: name of channel + +required: + - compatible + - reg + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@32 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp8501"; + reg = <0x32>; + clock-mode = /bits/ 8 <2>; + pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ + + led@0 { + reg = <0>; + chan-name = "d1"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@1 { + reg = <1>; + chan-name = "d2"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@2 { + reg = <2>; + chan-name = "d3"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@3 { + reg = <3>; + chan-name = "d4"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@4 { + reg = <4>; + chan-name = "d5"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@5 { + reg = <5>; + chan-name = "d6"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@6 { + reg = <6>; + chan-name = "d7"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@7 { + reg = <7>; + chan-name = "d8"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@8 { + reg = <8>; + chan-name = "d9"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + }; + + led-controller@33 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "national,lp5523"; + reg = <0x33>; + clock-mode = /bits/ 8 <0>; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0x2>; + color = ; + function = LED_FUNCTION_STANDBY; + linux,default-trigger = "heartbeat"; + + led@0 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x0>; + color = ; + }; + + led@1 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x1>; + color = ; + }; + + led@6 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x6>; + color = ; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt index 9863220db4ba..8bb25749a3da 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt @@ -47,4 +47,4 @@ led-controller@2d { } For more product information please see the link below: -http://www.ti.com/product/lp8860-q1 +https://www.ti.com/product/lp8860-q1 diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt index 7984efb767b4..7a5830f8d5ab 100644 --- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt +++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt @@ -26,9 +26,9 @@ LED sub-node properties: from 0 to 15 for the pca9552 from 0 to 3 for the pca9553 - type: (optional) either - PCA9532_TYPE_NONE - PCA9532_TYPE_LED - PCA9532_TYPE_GPIO + PCA955X_TYPE_NONE + PCA955X_TYPE_LED + PCA955X_TYPE_GPIO see dt-bindings/leds/leds-pca955x.h (default to LED) - label : (optional) see Documentation/devicetree/bindings/leds/common.txt diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt b/Documentation/devicetree/bindings/media/i2c/adv7180.txt deleted file mode 100644 index 552b6a82cb1f..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Analog Devices ADV7180 analog video decoder family - -The adv7180 family devices are used to capture analog video to different -digital interfaces like MIPI CSI-2 or parallel video. - -Required Properties : -- compatible : value must be one of - "adi,adv7180" - "adi,adv7180cp" - "adi,adv7180st" - "adi,adv7182" - "adi,adv7280" - "adi,adv7280-m" - "adi,adv7281" - "adi,adv7281-m" - "adi,adv7281-ma" - "adi,adv7282" - "adi,adv7282-m" - -Device nodes of "adi,adv7180cp" and "adi,adv7180st" must contain one -'port' child node per device input and output port, in accordance with the -video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. The port -nodes are numbered as follows. - - Port adv7180cp adv7180st -------------------------------------------------------------------- - Input 0-2 0-5 - Output 3 6 - -The digital output port node must contain at least one endpoint. - -Optional Properties : -- powerdown-gpios: reference to the GPIO connected to the powerdown pin, - if any. - - -Example: - - i2c0@1c22000 { - ... - ... - adv7180@21 { - compatible = "adi,adv7180"; - reg = <0x21>; - }; - ... - }; - diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml new file mode 100644 index 000000000000..e0084b272b25 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/adv7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV7180 analog video decoder family + +maintainers: + - Lars-Peter Clausen + +description: + The adv7180 family devices are used to capture analog video to different + digital interfaces like MIPI CSI-2 or parallel video. + +properties: + compatible: + items: + - enum: + - adi,adv7180 + - adi,adv7180cp + - adi,adv7180st + - adi,adv7182 + - adi,adv7280 + - adi,adv7280-m + - adi,adv7281 + - adi,adv7281-m + - adi,adv7281-ma + - adi,adv7282 + - adi,adv7282-m + + reg: + maxItems: 1 + + powerdown-gpios: + maxItems: 1 + + port: + type: object + description: + A node containing a single endpoint as doucmented in + Documentation/devicetree/bindings/media/video-interfaces.txt + + ports: + type: object + description: + A node containing input and output port nodes with endpoint definitions + as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + items: + - enum: + - adi,adv7180 + - adi,adv7182 + - adi,adv7280 + - adi,adv7280-m + - adi,adv7281 + - adi,adv7281-m + - adi,adv7281-ma + - adi,adv7282 + - adi,adv7282-m + then: + required: + - port + + - if: + properties: + compatible: + contains: + const: adi,adv7180cp + then: + properties: + ports: + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + port@3: + type: object + description: Output port + + patternProperties: + "^port@[0-2]$": + type: object + description: Input port + + required: + - port@3 + + additionalProperties: false + + required: + - ports + + - if: + properties: + compatible: + contains: + const: adi,adv7180st + then: + properties: + ports: + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + port@6: + type: object + description: Output port + + patternProperties: + "^port@[0-5]$": + type: object + description: Input port + + required: + - port@6 + + additionalProperties: false + + required: + - ports + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + composite-in@20 { + compatible = "adi,adv7180"; + reg = <0x20>; + + port { + adv7180: endpoint { + bus-width = <8>; + remote-endpoint = <&vin1ep>; + }; + }; + }; + + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + composite-in@20 { + compatible = "adi,adv7180cp"; + reg = <0x20>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7180_in: endpoint { + remote-endpoint = <&composite_con_in>; + }; + }; + + port@3 { + reg = <3>; + adv7180_out: endpoint { + remote-endpoint = <&vin4_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/imx274.txt b/Documentation/devicetree/bindings/media/i2c/imx274.txt index 80f2e89568e1..0727079d2410 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx274.txt +++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt @@ -13,6 +13,11 @@ Required Properties: Optional Properties: - reset-gpios: Sensor reset GPIO +- clocks: Reference to the input clock. +- clock-names: Should be "inck". +- VANA-supply: Sensor 2.8v analog supply. +- VDIG-supply: Sensor 1.8v digital core supply. +- VDDL-supply: Sensor digital IO 1.2v supply. The imx274 device node should contain one 'port' child node with an 'endpoint' subnode. For further reading on port node refer to diff --git a/Documentation/devicetree/bindings/media/xilinx/video.txt b/Documentation/devicetree/bindings/media/xilinx/video.txt index 68ac210e688e..d0335ca0cd57 100644 --- a/Documentation/devicetree/bindings/media/xilinx/video.txt +++ b/Documentation/devicetree/bindings/media/xilinx/video.txt @@ -32,4 +32,4 @@ The following properties are common to all Xilinx video IP cores. defaults to "mono". -[UG934] http://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf +[UG934] https://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt deleted file mode 100644 index bcc36c5b543c..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt +++ /dev/null @@ -1,35 +0,0 @@ -Freescale Multi Mode DDR controller (MMDC) - -Required properties : -- compatible : should be one of following: - for i.MX6Q/i.MX6DL: - - "fsl,imx6q-mmdc"; - for i.MX6QP: - - "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc"; - for i.MX6SL: - - "fsl,imx6sl-mmdc", "fsl,imx6q-mmdc"; - for i.MX6SLL: - - "fsl,imx6sll-mmdc", "fsl,imx6q-mmdc"; - for i.MX6SX: - - "fsl,imx6sx-mmdc", "fsl,imx6q-mmdc"; - for i.MX6UL/i.MX6ULL/i.MX6ULZ: - - "fsl,imx6ul-mmdc", "fsl,imx6q-mmdc"; - for i.MX7ULP: - - "fsl,imx7ulp-mmdc", "fsl,imx6q-mmdc"; -- reg : address and size of MMDC DDR controller registers - -Optional properties : -- clocks : the clock provided by the SoC to access the MMDC registers - -Example : - mmdc0: memory-controller@21b0000 { /* MMDC0 */ - compatible = "fsl,imx6q-mmdc"; - reg = <0x021b0000 0x4000>; - clocks = <&clks IMX6QDL_CLK_MMDC_P0_IPG>; - }; - - mmdc1: memory-controller@21b4000 { /* MMDC1 */ - compatible = "fsl,imx6q-mmdc"; - reg = <0x021b4000 0x4000>; - status = "disabled"; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml new file mode 100644 index 000000000000..dee5131c0361 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/fsl/mmdc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Multi Mode DDR controller (MMDC) + +maintainers: + - Anson Huang + +properties: + compatible: + oneOf: + - const: fsl,imx6q-mmdc + - items: + - enum: + - fsl,imx6qp-mmdc + - fsl,imx6sl-mmdc + - fsl,imx6sll-mmdc + - fsl,imx6sx-mmdc + - fsl,imx6ul-mmdc + - fsl,imx7ulp-mmdc + - const: fsl,imx6q-mmdc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + #include + + memory-controller@21b0000 { + compatible = "fsl,imx6q-mmdc"; + reg = <0x021b0000 0x4000>; + clocks = <&clks IMX6QDL_CLK_MMDC_P0_IPG>; + }; + + memory-controller@21b4000 { + compatible = "fsl,imx6q-mmdc"; + reg = <0x021b4000 0x4000>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml new file mode 100644 index 000000000000..660005601a7f --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/renesas,rpc-if.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Reduced Pin Count Interface (RPC-IF) + +maintainers: + - Sergei Shtylyov + +description: | + Renesas RPC-IF allows a SPI flash or HyperFlash connected to the SoC to + be accessed via the external address space read mode or the manual mode. + + The flash chip itself should be represented by a subnode of the RPC-IF node. + The flash interface is selected based on the "compatible" property of this + subnode: + - if it contains "jedec,spi-nor", then SPI is used; + - if it contains "cfi-flash", then HyperFlash is used. + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + items: + - enum: + - renesas,r8a77970-rpc-if # R-Car V3M + - renesas,r8a77980-rpc-if # R-Car V3H + - renesas,r8a77995-rpc-if # R-Car D3 + - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 device + + reg: + items: + - description: RPC-IF registers + - description: direct mapping read mode area + - description: write buffer area + + reg-names: + items: + - const: regs + - const: dirmap + - const: wbuf + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +patternProperties: + "flash@[0-9a-f]+$": + type: object + properties: + compatible: + enum: + - cfi-flash + - jedec,spi-nor + +examples: + - | + #include + #include + + spi@ee200000 { + compatible = "renesas,r8a77995-rpc-if", "renesas,rcar-gen3-rpc-if"; + reg = <0xee200000 0x200>, + <0x08000000 0x4000000>, + <0xee208000 0x100>; + reg-names = "regs", "dirmap", "wbuf"; + clocks = <&cpg CPG_MOD 917>; + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>; + resets = <&cpg 917>; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <40000000>; + spi-tx-bus-width = <1>; + spi-rx-bus-width = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt index 86446074e206..a92acf1dd491 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -37,7 +37,7 @@ syscon as a means to arbitrate access. [0] http://www.intel.com/design/chipsets/industry/25128901.pdf [1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4 -[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf +[2] https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf [3] https://en.wikipedia.org/wiki/Super_I/O Required properties diff --git a/Documentation/devicetree/bindings/mfd/atmel-tcb.txt b/Documentation/devicetree/bindings/mfd/atmel-tcb.txt deleted file mode 100644 index c4a83e364cb6..000000000000 --- a/Documentation/devicetree/bindings/mfd/atmel-tcb.txt +++ /dev/null @@ -1,56 +0,0 @@ -* Device tree bindings for Atmel Timer Counter Blocks -- compatible: Should be "atmel,-tcb", "simple-mfd", "syscon". - can be "at91rm9200" or "at91sam9x5" -- reg: Should contain registers location and length -- #address-cells: has to be 1 -- #size-cells: has to be 0 -- interrupts: Should contain all interrupts for the TC block - Note that you can specify several interrupt cells if the TC - block has one interrupt per channel. -- clock-names: tuple listing input clock names. - Required elements: "t0_clk", "slow_clk" - Optional elements: "t1_clk", "t2_clk" -- clocks: phandles to input clocks. - -The TCB can expose multiple subdevices: - * a timer - - compatible: Should be "atmel,tcb-timer" - - reg: Should contain the TCB channels to be used. If the - counter width is 16 bits (at91rm9200-tcb), two consecutive - channels are needed. Else, only one channel will be used. - -Examples: - -One interrupt per TC block: - tcb0: timer@fff7c000 { - compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xfff7c000 0x100>; - interrupts = <18 4>; - clocks = <&tcb0_clk>, <&clk32k>; - clock-names = "t0_clk", "slow_clk"; - - timer@0 { - compatible = "atmel,tcb-timer"; - reg = <0>, <1>; - }; - - timer@2 { - compatible = "atmel,tcb-timer"; - reg = <2>; - }; - }; - -One interrupt per TC channel in a TC block: - tcb1: timer@fffdc000 { - compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xfffdc000 0x100>; - interrupts = <26 4>, <27 4>, <28 4>; - clocks = <&tcb1_clk>, <&clk32k>; - clock-names = "t0_clk", "slow_clk"; - }; - - diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt index 857af982c88f..bab0d0e66cb3 100644 --- a/Documentation/devicetree/bindings/mfd/da9062.txt +++ b/Documentation/devicetree/bindings/mfd/da9062.txt @@ -1,8 +1,8 @@ * Dialog DA9062 Power Management Integrated Circuit (PMIC) Product information for the DA9062 and DA9061 devices can be found here: -- http://www.dialog-semiconductor.com/products/da9062 -- http://www.dialog-semiconductor.com/products/da9061 +- https://www.dialog-semiconductor.com/products/da9062 +- https://www.dialog-semiconductor.com/products/da9061 The DA9062 PMIC consists of: diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 19bdaf781853..049ec2ffc7f9 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -38,12 +38,15 @@ properties: - allwinner,sun8i-h3-system-controller - allwinner,sun8i-v3s-system-controller - allwinner,sun50i-a64-system-controller + - microchip,sparx5-cpu-syscon + - mstar,msc313-pmsleep - const: syscon - contains: const: syscon - additionalItems: true + minItems: 2 + maxItems: 4 # Should be enough reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml new file mode 100644 index 000000000000..03d0a232c75e --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/ti,j721e-system-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI J721e System Controller Registers R/W Device Tree Bindings + +description: | + This represents the Control Module registers (CTRL_MMR0) on the SoC. + System controller node represents a register region containing a set + of miscellaneous registers. The registers are not cohesive enough to + represent as any specific type of device. The typical use-case is + for some other node's driver, or platform-specific code, to acquire + a reference to the syscon node (e.g. by phandle, node path, or + search using a specific compatible value), interrogate the node (or + associated OS driver) to determine the location of the registers, + and access the registers directly. + +maintainers: + - Kishon Vijay Abraham I + - Roger Quadros ; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + serdes_ln_ctrl: serdes-ln-ctrl@4080 { + compatible = "mmio-mux"; + reg = <0x00004080 0x50>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index 9134e9bcca56..7b486d4985dc 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -10,7 +10,7 @@ such as network interfaces, crypto accelerator instances, L2 switches, etc. For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/freescale/dpaa2/overview.rst +Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst As described in the above overview, all DPAA2 objects in a DPRC share the same hardware "isolation context" and a 10-bit value called an ICID @@ -28,6 +28,16 @@ Documentation/devicetree/bindings/iommu/iommu.txt. For arm-smmu binding, see: Documentation/devicetree/bindings/iommu/arm,smmu.yaml. +The MSI writes are accompanied by sideband data which is derived from the ICID. +The msi-map property is used to associate the devices with both the ITS +controller and the sideband data which accompanies the writes. + +For generic MSI bindings, see +Documentation/devicetree/bindings/interrupt-controller/msi.txt. + +For GICv3 and GIC ITS bindings, see: +Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. + Required properties: - compatible @@ -49,11 +59,6 @@ Required properties: region may not be present in some scenarios, such as in the device tree presented to a virtual machine. - - msi-parent - Value type: - Definition: Must be present and point to the MSI controller node - handling message interrupts for the MC. - - ranges Value type: Definition: A standard property. Defines the mapping between the child @@ -119,6 +124,28 @@ Optional properties: associated with the listed IOMMU, with the iommu-specifier (i - icid-base + iommu-base). +- msi-map: Maps an ICID to a GIC ITS and associated msi-specifier + data. + + The property is an arbitrary number of tuples of + (icid-base,gic-its,msi-base,length). + + Any ICID in the interval [icid-base, icid-base + length) is + associated with the listed GIC ITS, with the msi-specifier + (i - icid-base + msi-base). + +Deprecated properties: + + - msi-parent + Value type: + Definition: Describes the MSI controller node handling message + interrupts for the MC. When there is no translation + between the ICID and deviceID this property can be used + to describe the MSI controller used by the devices on the + mc-bus. + The use of this property for mc-bus is deprecated. Please + use msi-map. + Example: smmu: iommu@5000000 { @@ -128,13 +155,24 @@ Example: ... }; + gic: interrupt-controller@6000000 { + compatible = "arm,gic-v3"; + ... + } + its: gic-its@6020000 { + compatible = "arm,gic-v3-its"; + msi-controller; + ... + }; + fsl_mc: fsl-mc@80c000000 { compatible = "fsl,qoriq-mc"; reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ - msi-parent = <&its>; /* define map for ICIDs 23-64 */ iommu-map = <23 &smmu 23 41>; + /* define msi map for ICIDs 23-64 */ + msi-map = <23 &its 23 41>; #address-cells = <3>; #size-cells = <1>; diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt deleted file mode 100644 index 2d7cdf19a0d0..000000000000 --- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt +++ /dev/null @@ -1,23 +0,0 @@ -OLPC XO-1.75 Embedded Controller - -Required properties: -- compatible: Should be "olpc,xo1.75-ec". -- cmd-gpios: gpio specifier of the CMD pin - -The embedded controller requires the SPI controller driver to signal readiness -to receive a transfer (that is, when TX FIFO contains the response data) by -strobing the ACK pin with the ready signal. See the "ready-gpios" property of the -SSP binding as documented in: -. - -Example: - &ssp3 { - spi-slave; - ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>; - - slave { - compatible = "olpc,xo1.75-ec"; - spi-cpha; - cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml new file mode 100644 index 000000000000..e75d77beec6a --- /dev/null +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +# Copyright (C) 2019,2020 Lubomir Rintel +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/olpc,xo1.75-ec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OLPC XO-1.75 Embedded Controller bindings + +description: | + This binding describes the Embedded Controller acting as a SPI bus master + on a OLPC XO-1.75 laptop computer. + + The embedded controller requires the SPI controller driver to signal + readiness to receive a transfer (that is, when TX FIFO contains the + response data) by strobing the ACK pin with the ready signal. See the + "ready-gpios" property of the SSP binding as documented in: + . + +maintainers: + - Lubomir Rintel + +properties: + compatible: + const: olpc,xo1.75-ec + + cmd-gpios: + description: GPIO uspecifier of the CMD pin + maxItems: 1 + +required: + - compatible + - cmd-gpios + +unevaluatedProperties: false + +examples: + - | + #include + + spi { + spi-slave; + ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>; + + slave { + compatible = "olpc,xo1.75-ec"; + spi-cpha; + cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt deleted file mode 100644 index f29bf7dd2ece..000000000000 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ /dev/null @@ -1,192 +0,0 @@ -Device Tree Bindings for the Arasan SDHCI Controller - - The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings. - Only deviations are documented here. - - [1] Documentation/devicetree/bindings/mmc/mmc.txt - [2] Documentation/devicetree/bindings/clock/clock-bindings.txt - [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - [4] Documentation/devicetree/bindings/phy/phy-bindings.txt - -Required Properties: - - compatible: Compatibility string. One of: - - "arasan,sdhci-8.9a": generic Arasan SDHCI 8.9a PHY - - "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY - - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY - - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "xlnx,zynqmp-8.9a": ZynqMP SDHCI 8.9a PHY - For this device it is strongly suggested to include clock-output-names and - #clock-cells. - - "xlnx,versal-8.9a": Versal SDHCI 8.9a PHY - For this device it is strongly suggested to include clock-output-names and - #clock-cells. - - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY - Note: This binding has been deprecated and moved to [5]. - - "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1": Intel LGM SDXC PHY - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel Keem Bay eMMC - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,keembay-sdhci-5.1-sd": Intel Keem Bay SD controller - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,keembay-sdhci-5.1-sdio": Intel Keem Bay SDIO controller - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt - - - 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" - - interrupts: Interrupt specifier - -Required Properties for "arasan,sdhci-5.1": - - phys: From PHY bindings: Phandle for the Generic PHY for arasan. - - phy-names: MUST be "phy_arasan". - -Optional Properties: - - arasan,soc-ctl-syscon: A phandle to a syscon device (see ../mfd/syscon.txt) - used to access core corecfg registers. Offsets of registers in this - syscon are determined based on the main compatible string for the device. - - clock-output-names: If specified, this will be the name of the card clock - which will be exposed by this device. Required if #clock-cells is - specified. - - #clock-cells: If specified this should be the value <0> or <1>. With this - property in place we will export one or two clocks representing the Card - Clock. These clocks are expected to be consumed by our PHY. - - xlnx,fails-without-test-cd: when present, the controller doesn't work when - the CD line is not connected properly, and the line is not connected - properly. Test mode can be used to force the controller to function. - - xlnx,int-clock-stable-broken: when present, the controller always reports - that the internal clock is stable even when it is not. - - - xlnx,mio-bank: When specified, this will indicate the MIO bank number in - which the command and data lines are configured. If not specified, driver - will assume this as 0. - -Example: - sdhci@e0100000 { - compatible = "arasan,sdhci-8.9a"; - reg = <0xe0100000 0x1000>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&clkc 21>, <&clkc 32>; - interrupt-parent = <&gic>; - interrupts = <0 24 4>; - } ; - - sdhci@e2800000 { - compatible = "arasan,sdhci-5.1"; - reg = <0xe2800000 0x1000>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&cru 8>, <&cru 18>; - interrupt-parent = <&gic>; - interrupts = <0 24 4>; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - } ; - - sdhci: sdhci@fe330000 { - compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1"; - reg = <0x0 0xfe330000 0x0 0x10000>; - interrupts = ; - clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>; - clock-names = "clk_xin", "clk_ahb"; - arasan,soc-ctl-syscon = <&grf>; - assigned-clocks = <&cru SCLK_EMMC>; - assigned-clock-rates = <200000000>; - clock-output-names = "emmc_cardclock"; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - #clock-cells = <0>; - }; - - sdhci: mmc@ff160000 { - compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a"; - interrupt-parent = <&gic>; - interrupts = <0 48 4>; - reg = <0x0 0xff160000 0x0 0x1000>; - clocks = <&clk200>, <&clk200>; - clock-names = "clk_xin", "clk_ahb"; - clock-output-names = "clk_out_sd0", "clk_in_sd0"; - #clock-cells = <1>; - clk-phase-sd-hs = <63>, <72>; - }; - - sdhci: mmc@f1040000 { - compatible = "xlnx,versal-8.9a", "arasan,sdhci-8.9a"; - interrupt-parent = <&gic>; - interrupts = <0 126 4>; - reg = <0x0 0xf1040000 0x0 0x10000>; - clocks = <&clk200>, <&clk200>; - clock-names = "clk_xin", "clk_ahb"; - clock-output-names = "clk_out_sd0", "clk_in_sd0"; - #clock-cells = <1>; - clk-phase-sd-hs = <132>, <60>; - }; - - emmc: sdhci@ec700000 { - compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1"; - reg = <0xec700000 0x300>; - interrupt-parent = <&ioapic1>; - interrupts = <44 1>; - clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>, - <&cgu0 LGM_GCLK_EMMC>; - clock-names = "clk_xin", "clk_ahb", "gate"; - clock-output-names = "emmc_cardclock"; - #clock-cells = <0>; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - arasan,soc-ctl-syscon = <&sysconf>; - }; - - sdxc: sdhci@ec600000 { - compatible = "arasan,sdhci-5.1", "intel,lgm-sdhci-5.1-sdxc"; - reg = <0xec600000 0x300>; - interrupt-parent = <&ioapic1>; - interrupts = <43 1>; - clocks = <&cgu0 LGM_CLK_SDIO>, <&cgu0 LGM_CLK_NGI>, - <&cgu0 LGM_GCLK_SDXC>; - clock-names = "clk_xin", "clk_ahb", "gate"; - clock-output-names = "sdxc_cardclock"; - #clock-cells = <0>; - phys = <&sdxc_phy>; - phy-names = "phy_arasan"; - arasan,soc-ctl-syscon = <&sysconf>; - }; - - mmc: mmc@33000000 { - compatible = "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1"; - interrupts = ; - reg = <0x0 0x33000000 0x0 0x300>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>, - <&scmi_clk KEEM_BAY_PSS_EMMC>; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - assigned-clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>; - assigned-clock-rates = <200000000>; - clock-output-names = "emmc_cardclock"; - #clock-cells = <0>; - arasan,soc-ctl-syscon = <&mmc_phy_syscon>; - }; - - sd0: mmc@31000000 { - compatible = "intel,keembay-sdhci-5.1-sd"; - interrupts = ; - reg = <0x0 0x31000000 0x0 0x300>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD0>, - <&scmi_clk KEEM_BAY_PSS_SD0>; - arasan,soc-ctl-syscon = <&sd0_phy_syscon>; - }; - - sd1: mmc@32000000 { - compatible = "intel,keembay-sdhci-5.1-sdio"; - interrupts = ; - reg = <0x0 0x32000000 0x0 0x300>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD1>, - <&scmi_clk KEEM_BAY_PSS_SD1>; - arasan,soc-ctl-syscon = <&sd1_phy_syscon>; - }; diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml new file mode 100644 index 000000000000..5887c917d480 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -0,0 +1,299 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device Tree Bindings for the Arasan SDHCI Controller + +maintainers: + - Adrian Hunter + +allOf: + - $ref: "mmc-controller.yaml#" + - if: + properties: + compatible: + contains: + const: arasan,sdhci-5.1 + then: + required: + - phys + - phy-names + - if: + properties: + compatible: + contains: + enum: + - xlnx,zynqmp-8.9a + - xlnx,versal-8.9a + then: + properties: + clock-output-names: + items: + - const: clk_out_sd0 + - const: clk_in_sd0 + +properties: + compatible: + oneOf: + - const: arasan,sdhci-8.9a # generic Arasan SDHCI 8.9a PHY + - const: arasan,sdhci-4.9a # generic Arasan SDHCI 4.9a PHY + - const: arasan,sdhci-5.1 # generic Arasan SDHCI 5.1 PHY + - items: + - const: rockchip,rk3399-sdhci-5.1 # rk3399 eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - items: + - const: xlnx,zynqmp-8.9a # ZynqMP SDHCI 8.9a PHY + - const: arasan,sdhci-8.9a + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. + - items: + - const: xlnx,versal-8.9a # Versal SDHCI 8.9a PHY + - const: arasan,sdhci-8.9a + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. + - items: + - const: intel,lgm-sdhci-5.1-emmc # Intel LGM eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - items: + - const: intel,lgm-sdhci-5.1-sdxc # Intel LGM SDXC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - items: + - const: intel,keembay-sdhci-5.1-emmc # Intel Keem Bay eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - const: intel,keembay-sdhci-5.1-sd # Intel Keem Bay SD controller + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - const: intel,keembay-sdhci-5.1-sdio # Intel Keem Bay SDIO controller + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + items: + - const: clk_xin + - const: clk_ahb + - const: gate + + interrupts: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + const: phy_arasan + + arasan,soc-ctl-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle to a syscon device (see ../mfd/syscon.txt) used to access + core corecfg registers. Offsets of registers in this syscon are + determined based on the main compatible string for the device. + + clock-output-names: + minItems: 1 + maxItems: 2 + description: + Name of the card clock which will be exposed by this device. + + '#clock-cells': + enum: [0, 1] + description: + With this property in place we will export one or two clocks + representing the Card Clock. These clocks are expected to be + consumed by our PHY. + + xlnx,fails-without-test-cd: + $ref: /schemas/types.yaml#/definitions/flag + description: + When present, the controller doesn't work when the CD line is not + connected properly, and the line is not connected properly. + Test mode can be used to force the controller to function. + + xlnx,int-clock-stable-broken: + $ref: /schemas/types.yaml#/definitions/flag + description: + When present, the controller always reports that the internal clock + is stable even when it is not. + + xlnx,mio-bank: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 2] + default: 0 + description: + The MIO bank number in which the command and data lines are configured. + +dependencies: + clock-output-names: [ '#clock-cells' ] + '#clock-cells': [ clock-output-names ] + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + mmc@e0100000 { + compatible = "arasan,sdhci-8.9a"; + reg = <0xe0100000 0x1000>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&clkc 21>, <&clkc 32>; + interrupt-parent = <&gic>; + interrupts = <0 24 4>; + }; + + - | + mmc@e2800000 { + compatible = "arasan,sdhci-5.1"; + reg = <0xe2800000 0x1000>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&cru 8>, <&cru 18>; + interrupt-parent = <&gic>; + interrupts = <0 24 4>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + }; + + - | + #include + #include + #include + mmc@fe330000 { + compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1"; + reg = <0xfe330000 0x10000>; + interrupts = ; + clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>; + clock-names = "clk_xin", "clk_ahb"; + arasan,soc-ctl-syscon = <&grf>; + assigned-clocks = <&cru SCLK_EMMC>; + assigned-clock-rates = <200000000>; + clock-output-names = "emmc_cardclock"; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + #clock-cells = <0>; + }; + + - | + mmc@ff160000 { + compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a"; + interrupt-parent = <&gic>; + interrupts = <0 48 4>; + reg = <0xff160000 0x1000>; + clocks = <&clk200>, <&clk200>; + clock-names = "clk_xin", "clk_ahb"; + clock-output-names = "clk_out_sd0", "clk_in_sd0"; + #clock-cells = <1>; + clk-phase-sd-hs = <63>, <72>; + }; + + - | + mmc@f1040000 { + compatible = "xlnx,versal-8.9a", "arasan,sdhci-8.9a"; + interrupt-parent = <&gic>; + interrupts = <0 126 4>; + reg = <0xf1040000 0x10000>; + clocks = <&clk200>, <&clk200>; + clock-names = "clk_xin", "clk_ahb"; + clock-output-names = "clk_out_sd0", "clk_in_sd0"; + #clock-cells = <1>; + clk-phase-sd-hs = <132>, <60>; + }; + + - | + #define LGM_CLK_EMMC5 + #define LGM_CLK_NGI + #define LGM_GCLK_EMMC + mmc@ec700000 { + compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1"; + reg = <0xec700000 0x300>; + interrupt-parent = <&ioapic1>; + interrupts = <44 1>; + clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>, + <&cgu0 LGM_GCLK_EMMC>; + clock-names = "clk_xin", "clk_ahb", "gate"; + clock-output-names = "emmc_cardclock"; + #clock-cells = <0>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + arasan,soc-ctl-syscon = <&sysconf>; + }; + + - | + #define LGM_CLK_SDIO + #define LGM_GCLK_SDXC + mmc@ec600000 { + compatible = "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1"; + reg = <0xec600000 0x300>; + interrupt-parent = <&ioapic1>; + interrupts = <43 1>; + clocks = <&cgu0 LGM_CLK_SDIO>, <&cgu0 LGM_CLK_NGI>, + <&cgu0 LGM_GCLK_SDXC>; + clock-names = "clk_xin", "clk_ahb", "gate"; + clock-output-names = "sdxc_cardclock"; + #clock-cells = <0>; + phys = <&sdxc_phy>; + phy-names = "phy_arasan"; + arasan,soc-ctl-syscon = <&sysconf>; + }; + + - | + #define KEEM_BAY_PSS_AUX_EMMC + #define KEEM_BAY_PSS_EMMC + mmc@33000000 { + compatible = "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1"; + interrupts = ; + reg = <0x33000000 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>, + <&scmi_clk KEEM_BAY_PSS_EMMC>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + assigned-clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>; + assigned-clock-rates = <200000000>; + clock-output-names = "emmc_cardclock"; + #clock-cells = <0>; + arasan,soc-ctl-syscon = <&mmc_phy_syscon>; + }; + + - | + #define KEEM_BAY_PSS_AUX_SD0 + #define KEEM_BAY_PSS_SD0 + mmc@31000000 { + compatible = "intel,keembay-sdhci-5.1-sd"; + interrupts = ; + reg = <0x31000000 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD0>, + <&scmi_clk KEEM_BAY_PSS_SD0>; + arasan,soc-ctl-syscon = <&sd0_phy_syscon>; + }; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt deleted file mode 100644 index de1b8bd550d3..000000000000 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt +++ /dev/null @@ -1,67 +0,0 @@ -* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX - -The Enhanced Secure Digital Host Controller on Freescale i.MX family -provides an interface for MMC, SD, and SDIO types of memory cards. - -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,-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" - "fsl,imx6ull-usdhc" - "fsl,imx7d-usdhc" - "fsl,imx7ulp-usdhc" - "fsl,imx8mq-usdhc" - "fsl,imx8mm-usdhc" - "fsl,imx8mn-usdhc" - "fsl,imx8mp-usdhc" - "fsl,imx8qm-usdhc" - "fsl,imx8qxp-usdhc" - -Optional properties: -- fsl,wp-controller : Indicate to use controller internal write protection -- fsl,delay-line : Specify the number of delay cells for override mode. - This is used to set the clock delay for DLL(Delay Line) on override mode - to select a proper data sampling window in case the clock quality is not good - due to signal path is too long on the board. Please refer to eSDHC/uSDHC - chapter, DLL (Delay Line) section in RM for details. -- voltage-ranges : Specify the voltage range in case there are software - transparent level shifters on the outputs of the controller. Two cells are - required, first cell specifies minimum slot voltage (mV), second cell - specifies maximum slot voltage (mV). Several ranges could be specified. -- fsl,tuning-start-tap: Specify the start dealy cell point when send first CMD19 - in tuning procedure. -- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure. - The uSDHC use one delay cell as default increasing step to do tuning process. - This property allows user to change the tuning step to more than one delay - cells which is useful for some special boards or cards when the default - tuning step can't find the proper delay window within limited tuning retries. -- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay target. - This delay target programming host controller loopback read clock, and this - property allows user to change the delay target for the strobe input read clock. - If not use this property, driver default set the delay target to value 7. - Only eMMC HS400 mode need to take care of this property. - -Examples: - -esdhc@70004000 { - compatible = "fsl,imx51-esdhc"; - reg = <0x70004000 0x4000>; - interrupts = <1>; - fsl,wp-controller; -}; - -esdhc@70008000 { - compatible = "fsl,imx51-esdhc"; - reg = <0x70008000 0x4000>; - interrupts = <2>; - cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */ - wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */ -}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml new file mode 100644 index 000000000000..75dc1168d717 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX + +maintainers: + - Shawn Guo + +allOf: + - $ref: "mmc-controller.yaml" + +description: | + The Enhanced Secure Digital Host Controller on Freescale i.MX family + provides an interface for MMC, SD, and SDIO types of memory cards. + + This file documents differences between the core properties described + by mmc.txt and the properties used by the sdhci-esdhc-imx driver. + +properties: + compatible: + enum: + - fsl,imx25-esdhc + - fsl,imx35-esdhc + - fsl,imx51-esdhc + - fsl,imx53-esdhc + - fsl,imx6q-usdhc + - fsl,imx6sl-usdhc + - fsl,imx6sx-usdhc + - fsl,imx6ull-usdhc + - fsl,imx7d-usdhc + - fsl,imx7ulp-usdhc + - fsl,imx8mq-usdhc + - fsl,imx8mm-usdhc + - fsl,imx8mn-usdhc + - fsl,imx8mp-usdhc + - fsl,imx8qm-usdhc + - fsl,imx8qxp-usdhc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,wp-controller: + description: | + boolean, if present, indicate to use controller internal write protection. + type: boolean + + fsl,delay-line: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the number of delay cells for override mode. + This is used to set the clock delay for DLL(Delay Line) on override mode + to select a proper data sampling window in case the clock quality is not good + due to signal path is too long on the board. Please refer to eSDHC/uSDHC + chapter, DLL (Delay Line) section in RM for details. + default: 0 + + voltage-ranges: + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' + description: | + Specify the voltage range in case there are software transparent level + shifters on the outputs of the controller. Two cells are required, first + cell specifies minimum slot voltage (mV), second cell specifies maximum + slot voltage (mV). + items: + items: + - description: value for minimum slot voltage + - description: value for maximum slot voltage + maxItems: 1 + + fsl,tuning-start-tap: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the start delay cell point when send first CMD19 in tuning procedure. + default: 0 + + fsl,tuning-step: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the increasing delay cell steps in tuning procedure. + The uSDHC use one delay cell as default increasing step to do tuning process. + This property allows user to change the tuning step to more than one delay + cells which is useful for some special boards or cards when the default + tuning step can't find the proper delay window within limited tuning retries. + default: 0 + + fsl,strobe-dll-delay-target: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the strobe dll control slave delay target. + This delay target programming host controller loopback read clock, and this + property allows user to change the delay target for the strobe input read clock. + If not use this property, driver default set the delay target to value 7. + Only eMMC HS400 mode need to take care of this property. + default: 0 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + mmc@70004000 { + compatible = "fsl,imx51-esdhc"; + reg = <0x70004000 0x4000>; + interrupts = <1>; + fsl,wp-controller; + }; + + mmc@70008000 { + compatible = "fsl,imx51-esdhc"; + reg = <0x70008000 0x4000>; + interrupts = <2>; + cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */ + wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */ + }; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt deleted file mode 100644 index 184ccffe2739..000000000000 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Freescale Secure Digital Host Controller for i.MX2/3 series - -This file documents differences to the properties defined in mmc.txt. - -Required properties: -- compatible : Should be "fsl,-mmc", chip can be imx21 or imx31 - -Optional properties: -- dmas: One DMA phandle with arguments as defined by the devicetree bindings - of the used DMA controller. -- dma-names: Has to be "rx-tx". - -Example: - -sdhci1: sdhci@10014000 { - compatible = "fsl,imx27-mmc", "fsl,imx21-mmc"; - reg = <0x10014000 0x1000>; - interrupts = <11>; - dmas = <&dma 7>; - dma-names = "rx-tx"; - bus-width = <4>; - cd-gpios = <&gpio3 29>; -}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml new file mode 100644 index 000000000000..ffa162722b8e --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/fsl-imx-mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Secure Digital Host Controller for i.MX2/3 series + +maintainers: + - Markus Pargmann + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + oneOf: + - const: fsl,imx21-mmc + - const: fsl,imx31-mmc + - items: + - const: fsl,imx27-mmc + - const: fsl,imx21-mmc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + mmc@10014000 { + compatible = "fsl,imx27-mmc", "fsl,imx21-mmc"; + reg = <0x10014000 0x1000>; + interrupts = <11>; + dmas = <&dma 7>; + dma-names = "rx-tx"; + bus-width = <4>; + cd-gpios = <&gpio3 29>; + }; diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 4931fab34d81..b96da0c7f819 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -169,6 +169,11 @@ properties: description: Full power cycle of the card is supported. + full-pwr-cycle-in-suspend: + $ref: /schemas/types.yaml#/definitions/flag + description: + Full power cycle of the card in suspend is supported. + mmc-ddr-1_2v: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt deleted file mode 100644 index 3d965d57e00b..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt +++ /dev/null @@ -1,25 +0,0 @@ -* The simple eMMC hardware reset provider - -The purpose of this driver is to perform standard eMMC hw reset -procedure, as described by Jedec 4.4 specification. This procedure is -performed just after MMC core enabled power to the given mmc host (to -fix possible issues if bootloader has left eMMC card in initialized or -unknown state), and before performing complete system reboot (also in -case of emergency reboot call). The latter is needed on boards, which -doesn't have hardware reset logic connected to emmc card and (limited or -broken) ROM bootloaders are unable to read second stage from the emmc -card if the card is left in unknown or already initialized state. - -Required properties: -- compatible : contains "mmc-pwrseq-emmc". -- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted - and then deasserted to perform eMMC card reset. To perform - reset procedure as described in Jedec 4.4 specification, the - gpio line should be defined as GPIO_ACTIVE_LOW. - -Example: - - sdhci0_pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; - } diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml new file mode 100644 index 000000000000..77f746f57284 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-emmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple eMMC hardware reset provider binding + +maintainers: + - Ulf Hansson + +description: + The purpose of this driver is to perform standard eMMC hw reset + procedure, as described by Jedec 4.4 specification. This procedure is + performed just after MMC core enabled power to the given mmc host (to + fix possible issues if bootloader has left eMMC card in initialized or + unknown state), and before performing complete system reboot (also in + case of emergency reboot call). The latter is needed on boards, which + doesn't have hardware reset logic connected to emmc card and (limited or + broken) ROM bootloaders are unable to read second stage from the emmc + card if the card is left in unknown or already initialized state. + +properties: + compatible: + const: mmc-pwrseq-emmc + + reset-gpios: + minItems: 1 + description: + contains a GPIO specifier. The reset GPIO is asserted + and then deasserted to perform eMMC card reset. To perform + reset procedure as described in Jedec 4.4 specification, the + gpio line should be defined as GPIO_ACTIVE_LOW. + +required: + - compatible + - reset-gpios + +examples: + - | + #include + sdhci0_pwrseq { + compatible = "mmc-pwrseq-emmc"; + reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt deleted file mode 100644 index 22e9340e4ba2..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt +++ /dev/null @@ -1,16 +0,0 @@ -* Marvell SD8787 power sequence provider - -Required properties: -- compatible: must be "mmc-pwrseq-sd8787". -- powerdown-gpios: contains a power down GPIO specifier with the - default active state -- reset-gpios: contains a reset GPIO specifier with the default - active state - -Example: - - wifi_pwrseq: wifi_pwrseq { - compatible = "mmc-pwrseq-sd8787"; - powerdown-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>; - reset-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>; - } diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml new file mode 100644 index 000000000000..a68820d31d50 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-sd8787.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell SD8787 power sequence provider binding + +maintainers: + - Ulf Hansson + +properties: + compatible: + const: mmc-pwrseq-sd8787 + + powerdown-gpios: + minItems: 1 + description: + contains a power down GPIO specifier with the default active state + + reset-gpios: + minItems: 1 + description: + contains a reset GPIO specifier with the default active state + +required: + - compatible + - powerdown-gpios + - reset-gpios + +examples: + - | + #include + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-sd8787"; + powerdown-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>; + reset-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt deleted file mode 100644 index 9029b45b8a22..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ /dev/null @@ -1,31 +0,0 @@ -* The simple MMC power sequence provider - -The purpose of the simple MMC power sequence provider is to supports a set of -common properties between various SOC designs. It thus enables us to use the -same provider for several SOC designs. - -Required properties: -- compatible : contains "mmc-pwrseq-simple". - -Optional properties: -- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted - at initialization and prior we start the power up procedure of the card. - They will be de-asserted right after the power has been provided to the - card. -- clocks : Must contain an entry for the entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entry: - "ext_clock" (External clock provided to the card). -- post-power-on-delay-ms : Delay in ms after powering the card and - de-asserting the reset-gpios (if any) -- power-off-delay-us : Delay in us after asserting the reset-gpios (if any) - during power off of the card. - -Example: - - sdhci0_pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; - clocks = <&clk_32768_ck>; - clock-names = "ext_clock"; - } diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml new file mode 100644 index 000000000000..449215444723 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-simple.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple MMC power sequence provider binding + +maintainers: + - Ulf Hansson + +description: + The purpose of the simple MMC power sequence provider is to supports a set + of common properties between various SOC designs. It thus enables us to use + the same provider for several SOC designs. + +properties: + compatible: + const: mmc-pwrseq-simple + + reset-gpios: + minItems: 1 + description: + contains a list of GPIO specifiers. The reset GPIOs are asserted + at initialization and prior we start the power up procedure of the card. + They will be de-asserted right after the power has been provided to the + card. + + clocks: + minItems: 1 + description: Handle for the entry in clock-names. + + clock-names: + items: + - const: ext_clock + description: External clock provided to the card. + + post-power-on-delay-ms: + description: + Delay in ms after powering the card and de-asserting the + reset-gpios (if any). + $ref: /schemas/types.yaml#/definitions/uint32 + + power-off-delay-us: + description: + Delay in us after asserting the reset-gpios (if any) + during power off of the card. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + +examples: + - | + #include + sdhci0_pwrseq { + compatible = "mmc-pwrseq-simple"; + reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + clocks = <&clk_32768_ck>; + clock-names = "ext_clock"; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index 8a532f4453f2..0c9cf6a8808c 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183 "mediatek,mt8516-mmc": for mmc host ip compatible with mt8516 + "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779 "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 "mediatek,mt7622-mmc": for MT7622 SoC diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt deleted file mode 100644 index 515addc20070..000000000000 --- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Freescale MXS MMC controller - -The Freescale MXS Synchronous Serial Ports (SSP) 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 mxsmmc driver. - -Required properties: -- compatible: Should be "fsl,-mmc". The supported chips include - imx23 and imx28. -- interrupts: Should contain ERROR interrupt number -- dmas: DMA specifier, consisting of a phandle to DMA controller node - and SSP DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. -- dma-names: Must be "rx-tx". - -Examples: - -ssp0: ssp@80010000 { - compatible = "fsl,imx28-mmc"; - reg = <0x80010000 2000>; - interrupts = <96>; - dmas = <&dma_apbh 0>; - dma-names = "rx-tx"; - bus-width = <8>; -}; diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml new file mode 100644 index 000000000000..1cccc0478d49 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mxs-mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS MMC controller + +maintainers: + - Shawn Guo + +description: | + The Freescale MXS Synchronous Serial Ports (SSP) 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 mxsmmc driver. + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + enum: + - fsl,imx23-mmc + - fsl,imx28-mmc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + mmc@80010000 { + compatible = "fsl,imx28-mmc"; + reg = <0x80010000 2000>; + interrupts = <96>; + dmas = <&dma_apbh 0>; + dma-names = "rx-tx"; + bus-width = <8>; + }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt b/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt deleted file mode 100644 index 0ca9a622cce0..000000000000 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt +++ /dev/null @@ -1,114 +0,0 @@ -* Renesas SDHI SD/MMC controller - -Required properties: -- compatible: should contain one or more of the following: - "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC - "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC - "renesas,sdhi-r7s9210" - SDHI IP on R7S9210 SoC - "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC - "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC - "renesas,sdhi-r8a7742" - SDHI IP on R8A7742 SoC - "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC - "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC - "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC - "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC - "renesas,sdhi-r8a774b1" - SDHI IP on R8A774B1 SoC - "renesas,sdhi-r8a774c0" - SDHI IP on R8A774C0 SoC - "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC - "renesas,sdhi-mmc-r8a77470" - SDHI/MMC IP on R8A77470 SoC - "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC - "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC - "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC - "renesas,sdhi-r8a7791" - SDHI IP on R8A7791 SoC - "renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC - "renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC - "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC - "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC - "renesas,sdhi-r8a7796" - SDHI IP on R8A77960 SoC - "renesas,sdhi-r8a77961" - SDHI IP on R8A77961 SoC - "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC - "renesas,sdhi-r8a77970" - SDHI IP on R8A77970 SoC - "renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC - "renesas,sdhi-r8a77990" - SDHI IP on R8A77990 SoC - "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC - "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller - "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller - "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 SDHI - (not SDHI/MMC) controller - "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 - SDHI controller - - - When compatible with the generic version, nodes must list - the SoC-specific version corresponding to the platform - first followed by the generic version. - -- clocks: Most controllers only have 1 clock source per channel. However, on - some variations of this controller, the internal card detection - logic that exists in this controller is sectioned off to be run by a - separate second clock source to allow the main core clock to be turned - off to save power. - If 2 clocks are specified by the hardware, you must name them as - "core" and "cd". If the controller only has 1 clock, naming is not - required. - Devices which have more than 1 clock are listed below: - 2: R7S72100, R7S9210 - -Optional properties: -- pinctrl-names: should be "default", "state_uhs" -- pinctrl-0: should contain default/high speed pin ctrl -- pinctrl-1: should contain uhs mode pin ctrl - -Example: R8A7790 (R-Car H2) SDHI controller nodes - - sdhi0: sd@ee100000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee100000 0 0x328>; - interrupts = ; - clocks = <&cpg CPG_MOD 314>; - dmas = <&dmac0 0xcd>, <&dmac0 0xce>, - <&dmac1 0xcd>, <&dmac1 0xce>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <195000000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 314>; - }; - - sdhi1: sd@ee120000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee120000 0 0x328>; - interrupts = ; - clocks = <&cpg CPG_MOD 313>; - dmas = <&dmac0 0xc9>, <&dmac0 0xca>, - <&dmac1 0xc9>, <&dmac1 0xca>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <195000000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 313>; - }; - - sdhi2: sd@ee140000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee140000 0 0x100>; - interrupts = ; - clocks = <&cpg CPG_MOD 312>; - dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, - <&dmac1 0xc1>, <&dmac1 0xc2>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <97500000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 312>; - }; - - sdhi3: sd@ee160000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee160000 0 0x100>; - interrupts = ; - clocks = <&cpg CPG_MOD 311>; - dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, - <&dmac1 0xd3>, <&dmac1 0xd4>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <97500000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 311>; - }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml new file mode 100644 index 000000000000..e5dbc20456e5 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mmc/renesas,sdhi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas SDHI SD/MMC controller + +maintainers: + - Wolfram Sang + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + oneOf: + - items: + - const: renesas,sdhi-sh73a0 # R-Mobile APE6 + - items: + - const: renesas,sdhi-r7s72100 # RZ/A1H + - items: + - const: renesas,sdhi-r7s9210 # SH-Mobile AG5 + - items: + - const: renesas,sdhi-r8a73a4 # R-Mobile APE6 + - items: + - const: renesas,sdhi-r8a7740 # R-Mobile A1 + - items: + - enum: + - renesas,sdhi-r8a7778 # R-Car M1 + - renesas,sdhi-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-sdhi # R-Car Gen1 + - items: + - enum: + - renesas,sdhi-r8a7742 # RZ/G1H + - renesas,sdhi-r8a7743 # RZ/G1M + - renesas,sdhi-r8a7744 # RZ/G1N + - renesas,sdhi-r8a7745 # RZ/G1E + - renesas,sdhi-r8a77470 # RZ/G1C + - renesas,sdhi-r8a7790 # R-Car H2 + - renesas,sdhi-r8a7791 # R-Car M2-W + - renesas,sdhi-r8a7792 # R-Car V2H + - renesas,sdhi-r8a7793 # R-Car M2-N + - renesas,sdhi-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-sdhi # R-Car Gen2 and RZ/G1 + - items: + - const: renesas,sdhi-mmc-r8a77470 # RZ/G1C (SDHI/MMC IP) + - items: + - enum: + - renesas,sdhi-r8a774a1 # RZ/G2M + - renesas,sdhi-r8a774b1 # RZ/G2N + - renesas,sdhi-r8a774c0 # RZ/G2E + - renesas,sdhi-r8a7795 # R-Car H3 + - renesas,sdhi-r8a7796 # R-Car M3-W + - renesas,sdhi-r8a77961 # R-Car M3-W+ + - renesas,sdhi-r8a77965 # R-Car M3-N + - renesas,sdhi-r8a77970 # R-Car V3M + - renesas,sdhi-r8a77980 # R-Car V3H + - renesas,sdhi-r8a77990 # R-Car E3 + - renesas,sdhi-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 3 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: core + - const: cd + + dmas: + minItems: 4 + maxItems: 4 + + dma-names: + minItems: 4 + maxItems: 4 + items: + enum: + - tx + - rx + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + pinctrl-0: + minItems: 1 + maxItems: 2 + + pinctrl-1: + maxItems: 1 + + pinctrl-names: + minItems: 1 + maxItems: 2 + items: + - const: default + - const: state_uhs + + max-frequency: true + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + +if: + properties: + compatible: + items: + enum: + - renesas,sdhi-r7s72100 + - renesas,sdhi-r7s9210 +then: + required: + - clock-names + description: + The internal card detection logic that exists in these controllers is + sectioned off to be run by a separate second clock source to allow + the main core clock to be turned off to save power. + +unevaluatedProperties: false + +examples: + - | + #include + #include + #include + + sdhi0: mmc@ee100000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee100000 0x328>; + interrupts = ; + clocks = <&cpg CPG_MOD 314>; + dmas = <&dmac0 0xcd>, <&dmac0 0xce>, <&dmac1 0xcd>, <&dmac1 0xce>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <195000000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 314>; + }; + + sdhi1: mmc@ee120000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee120000 0x328>; + interrupts = ; + clocks = <&cpg CPG_MOD 313>; + dmas = <&dmac0 0xc9>, <&dmac0 0xca>, <&dmac1 0xc9>, <&dmac1 0xca>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <195000000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 313>; + }; + + sdhi2: mmc@ee140000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee140000 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 312>; + dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, <&dmac1 0xc1>, <&dmac1 0xc2>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 312>; + }; + + sdhi3: mmc@ee160000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee160000 0x100>; + interrupts = ; + clocks = <&cpg CPG_MOD 311>; + dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, <&dmac1 0xd3>, <&dmac1 0xd4>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 311>; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt index c6ccecb9ae5a..6d202f4d9249 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt @@ -39,6 +39,7 @@ Optional Properties (Required for ti,am654-sdhci-5.1 and ti,j721e-sdhci-8bit): Valid values are 33, 40, 50, 66 and 100 ohms. Optional Properties: - ti,strobe-sel: strobe select delay for HS400 speed mode. Default value: 0x0. + - ti,clkbuf-sel: Clock Delay Buffer Select Example: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index b8e1d2b7aea9..3b602fd6180b 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -54,6 +54,21 @@ Required properties: - qcom,dll-config: Chipset and Platform specific value. Use this field to specify the DLL_CONFIG register value as per Hardware Programming Guide. +Optional Properties: +* Following bus parameters are required for interconnect bandwidth scaling: +- interconnects: Pairs of phandles and interconnect provider specifier + to denote the edge source and destination ports of + the interconnect path. + +- interconnect-names: For sdhc, we have two main paths. + 1. Data path : sdhc to ddr + 2. Config path : cpu to sdhc + For Data interconnect path the name supposed to be + is "sdhc-ddr" and for config interconnect path it is + "cpu-sdhc". + Please refer to Documentation/devicetree/bindings/ + interconnect/ for more details. + Example: sdhc_1: sdhci@f9824900 { @@ -71,6 +86,9 @@ Example: clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; clock-names = "core", "iface"; + interconnects = <&qnoc MASTER_SDCC_ID &qnoc SLAVE_DDR_ID>, + <&qnoc MASTER_CPU_ID &qnoc SLAVE_SDCC_ID>; + interconnect-names = "sdhc-ddr","cpu-sdhc"; qcom,dll-config = <0x000f642c>; qcom,ddr-config = <0x80040868>; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt deleted file mode 100644 index 393588385c6e..000000000000 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt +++ /dev/null @@ -1,75 +0,0 @@ -* Freescale General-Purpose Media Interface (GPMI) - -The GPMI nand controller provides an interface to control the -NAND flash chips. - -Required properties: - - compatible : should be "fsl,-gpmi-nand", chip can be: - * imx23 - * imx28 - * imx6q - * imx6sx - * imx7d - - reg : should contain registers location and length for gpmi and bch. - - reg-names: Should contain the reg names "gpmi-nand" and "bch" - - interrupts : BCH interrupt number. - - interrupt-names : Should be "bch". - - dmas: DMA specifier, consisting of a phandle to DMA controller node - and GPMI DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. - - dma-names: Must be "rx-tx". - - clocks : clocks phandle and clock specifier corresponding to each clock - specified in clock-names. - - clock-names : The "gpmi_io" clock is always required. Which clocks are - exactly required depends on chip: - * imx23/imx28 : "gpmi_io" - * imx6q/sx : "gpmi_io", "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch" - * imx7d : "gpmi_io", "gpmi_bch_apb" - -Optional properties: - - nand-on-flash-bbt: boolean to enable on flash bbt option if not - present false - - fsl,use-minimum-ecc: Protect this NAND flash with the minimum ECC - strength required. The required ECC strength is - automatically discoverable for some flash - (e.g., according to the ONFI standard). - However, note that if this strength is not - discoverable or this property is not enabled, - the software may chooses an implementation-defined - ECC scheme. - - fsl,no-blockmark-swap: Don't swap the bad block marker from the OOB - area with the byte in the data area but rely on the - flash based BBT for identifying bad blocks. - NOTE: this is only valid in conjunction with - 'nand-on-flash-bbt'. - WARNING: on i.MX28 blockmark swapping cannot be - disabled for the BootROM in the FCB. Thus, - partitions written from Linux with this feature - turned on may not be accessible by the BootROM - code. - - nand-ecc-strength: integer representing the number of bits to correct - per ECC step. Needs to be a multiple of 2. - - nand-ecc-step-size: integer representing the number of data bytes - that are covered by a single ECC step. The driver - supports 512 and 1024. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Examples: - -gpmi-nand@8000c000 { - compatible = "fsl,imx28-gpmi-nand"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x8000c000 2000>, <0x8000a000 2000>; - reg-names = "gpmi-nand", "bch"; - interrupts = <41>; - interrupt-names = "bch"; - dmas = <&dma_apbh 4>; - dma-names = "rx-tx"; - - partition@0 { - ... - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml new file mode 100644 index 000000000000..354cb63feea3 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/gpmi-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale General-Purpose Media Interface (GPMI) binding + +maintainers: + - Han Xu + +allOf: + - $ref: "nand-controller.yaml" + +description: | + The GPMI nand controller provides an interface to control the NAND + flash chips. The device tree may optionally contain sub-nodes + describing partitions of the address space. See partition.txt for + more detail. + +properties: + compatible: + enum: + - fsl,imx23-gpmi-nand + - fsl,imx28-gpmi-nand + - fsl,imx6q-gpmi-nand + - fsl,imx6sx-gpmi-nand + - fsl,imx7d-gpmi-nand + + reg: + items: + - description: Address and length of gpmi block. + - description: Address and length of bch block. + + reg-names: + items: + - const: gpmi-nand + - const: bch + + interrupts: + maxItems: 1 + + interrupt-names: + const: bch + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + + clocks: + minItems: 1 + maxItems: 5 + items: + - description: SoC gpmi io clock + - description: SoC gpmi apb clock + - description: SoC gpmi bch clock + - description: SoC gpmi bch apb clock + - description: SoC per1 bch clock + + clock-names: + minItems: 1 + maxItems: 5 + items: + - const: gpmi_io + - const: gpmi_apb + - const: gpmi_bch + - const: gpmi_bch_apb + - const: per1_bch + + fsl,use-minimum-ecc: + type: boolean + description: | + Protect this NAND flash with the minimum ECC strength required. + The required ECC strength is automatically discoverable for some + flash (e.g., according to the ONFI standard). However, note that + if this strength is not discoverable or this property is not enabled, + the software may chooses an implementation-defined ECC scheme. + + fsl,no-blockmark-swap: + type: boolean + description: | + Don't swap the bad block marker from the OOB area with the byte in + the data area but rely on the flash based BBT for identifying bad blocks. + NOTE: this is only valid in conjunction with 'nand-on-flash-bbt'. + WARNING: on i.MX28 blockmark swapping cannot be disabled for the BootROM + in the FCB. Thus, partitions written from Linux with this feature turned + on may not be accessible by the BootROM code. + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - clock-names + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + nand-controller@8000c000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx28-gpmi-nand"; + reg = <0x8000c000 0x2000>, <0x8000a000 0x2000>; + reg-names = "gpmi-nand", "bch"; + interrupts = <41>; + interrupt-names = "bch"; + clocks = <&clks 50>; + clock-names = "gpmi_io"; + dmas = <&dma_apbh 4>; + dma-names = "rx-tx"; + }; diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.txt b/Documentation/devicetree/bindings/mtd/mxc-nand.txt deleted file mode 100644 index 2857c628fba4..000000000000 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Freescale's mxc_nand - -Required properties: -- compatible: "fsl,imxXX-nand" -- reg: address range of the nfc block -- interrupts: irq to be used -- nand-bus-width: see nand-controller.yaml -- nand-ecc-mode: see nand-controller.yaml -- nand-on-flash-bbt: see nand-controller.yaml - -Example: - - nand@d8000000 { - compatible = "fsl,imx27-nand"; - reg = <0xd8000000 0x1000>; - interrupts = <29>; - nand-bus-width = <8>; - nand-ecc-mode = "hw"; - }; diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml new file mode 100644 index 000000000000..ee4d1d026fd8 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mxc-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale's mxc_nand binding + +maintainers: + - Uwe Kleine-König + +allOf: + - $ref: "nand-controller.yaml" + +properties: + compatible: + const: fsl,imx27-nand + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + nand-controller@d8000000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx27-nand"; + reg = <0xd8000000 0x1000>; + interrupts = <29>; + nand-bus-width = <8>; + nand-ecc-mode = "hw"; + }; diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 64c20c92c07d..85fefe3a0444 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -22,6 +22,7 @@ select: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - amlogic,meson-g12a-dwmac required: - compatible @@ -36,6 +37,7 @@ allOf: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - amlogic,meson-g12a-dwmac then: properties: @@ -95,6 +97,7 @@ properties: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - amlogic,meson-g12a-dwmac contains: enum: - snps,dwmac-3.70a diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt index f66bb7ecdb82..bf7328aba330 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.txt +++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt @@ -1,257 +1,4 @@ Distributed Switch Architecture Device Tree Bindings ---------------------------------------------------- -Switches are true Linux devices and can be probed by any means. Once -probed, they register to the DSA framework, passing a node -pointer. This node is expected to fulfil the following binding, and -may contain additional properties as required by the device it is -embedded within. - -Required properties: - -- ports : A container for child nodes representing switch ports. - -Optional properties: - -- dsa,member : A two element list indicates which DSA cluster, and position - within the cluster a switch takes. <0 0> is cluster 0, - switch 0. <0 1> is cluster 0, switch 1. <1 0> is cluster 1, - switch 0. A switch not part of any cluster (single device - hanging off a CPU port) must not specify this property - -The ports container has the following properties - -Required properties: - -- #address-cells : Must be 1 -- #size-cells : Must be 0 - -Each port children node must have the following mandatory properties: -- reg : Describes the port address in the switch - -An uplink/downlink port between switches in the cluster has the following -mandatory property: - -- link : Should be a list of phandles to other switch's DSA - port. This port is used as the outgoing port - towards the phandle ports. The full routing - information must be given, not just the one hop - routes to neighbouring switches. - -A CPU port has the following mandatory property: - -- ethernet : Should be a phandle to a valid Ethernet device node. - This host device is what the switch port is - connected to. - -A user port has the following optional property: - -- label : Describes the label associated with this port, which - will become the netdev name. - -Port child nodes may also contain the following optional standardised -properties, described in binding documents: - -- phy-handle : Phandle to a PHY on an MDIO bus. See - Documentation/devicetree/bindings/net/ethernet.txt - for details. - -- phy-mode : See - Documentation/devicetree/bindings/net/ethernet.txt - for details. - -- fixed-link : Fixed-link subnode describing a link to a non-MDIO - managed entity. See - Documentation/devicetree/bindings/net/fixed-link.txt - for details. - -The MAC address will be determined using the optional properties -defined in ethernet.txt. - -Example - -The following example shows three switches on three MDIO busses, -linked into one DSA cluster. - -&mdio1 { - #address-cells = <1>; - #size-cells = <0>; - - switch0: switch0@0 { - compatible = "marvell,mv88e6085"; - reg = <0>; - - dsa,member = <0 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan0"; - }; - - port@1 { - reg = <1>; - label = "lan1"; - local-mac-address = [00 00 00 00 00 00]; - }; - - port@2 { - reg = <2>; - label = "lan2"; - }; - - switch0port5: port@5 { - reg = <5>; - phy-mode = "rgmii-txid"; - link = <&switch1port6 - &switch2port9>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - - port@6 { - reg = <6>; - ethernet = <&fec1>; - fixed-link { - speed = <100>; - full-duplex; - }; - }; - }; - }; -}; - -&mdio2 { - #address-cells = <1>; - #size-cells = <0>; - - switch1: switch1@0 { - compatible = "marvell,mv88e6085"; - reg = <0>; - - dsa,member = <0 1>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan3"; - phy-handle = <&switch1phy0>; - }; - - port@1 { - reg = <1>; - label = "lan4"; - phy-handle = <&switch1phy1>; - }; - - port@2 { - reg = <2>; - label = "lan5"; - phy-handle = <&switch1phy2>; - }; - - switch1port5: port@5 { - reg = <5>; - link = <&switch2port9>; - phy-mode = "rgmii-txid"; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - - switch1port6: port@6 { - reg = <6>; - phy-mode = "rgmii-txid"; - link = <&switch0port5>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - mdio-bus { - #address-cells = <1>; - #size-cells = <0>; - switch1phy0: switch1phy0@0 { - reg = <0>; - }; - switch1phy1: switch1phy0@1 { - reg = <1>; - }; - switch1phy2: switch1phy0@2 { - reg = <2>; - }; - }; - }; -}; - -&mdio4 { - #address-cells = <1>; - #size-cells = <0>; - - switch2: switch2@0 { - compatible = "marvell,mv88e6085"; - reg = <0>; - - dsa,member = <0 2>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan6"; - }; - - port@1 { - reg = <1>; - label = "lan7"; - }; - - port@2 { - reg = <2>; - label = "lan8"; - }; - - port@3 { - reg = <3>; - label = "optical3"; - fixed-link { - speed = <1000>; - full-duplex; - link-gpios = <&gpio6 2 - GPIO_ACTIVE_HIGH>; - }; - }; - - port@4 { - reg = <4>; - label = "optical4"; - fixed-link { - speed = <1000>; - full-duplex; - link-gpios = <&gpio6 3 - GPIO_ACTIVE_HIGH>; - }; - }; - - switch2port9: port@9 { - reg = <9>; - phy-mode = "rgmii-txid"; - link = <&switch1port5 - &switch0port5>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; -}; +See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documenation. diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml new file mode 100644 index 000000000000..faea214339ca --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/dsa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ethernet Switch Device Tree Bindings + +maintainers: + - Andrew Lunn + - Florian Fainelli + - Vivien Didelot + +description: + This binding represents Ethernet Switches which have a dedicated CPU + port. That port is usually connected to an Ethernet Controller of the + SoC. Such setups are typical for embedded devices. + +select: false + +properties: + $nodename: + pattern: "^switch(@.*)?$" + + dsa,member: + minItems: 2 + maxItems: 2 + description: + A two element list indicates which DSA cluster, and position within the + cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0, + switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster + (single device hanging off a CPU port) must not specify this property + $ref: /schemas/types.yaml#/definitions/uint32-array + +patternProperties: + "^(ethernet-)?ports$": + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^(ethernet-)?port@[0-9]+$": + type: object + description: Ethernet switch ports + + properties: + reg: + description: Port number + + label: + description: + Describes the label associated with this port, which will become + the netdev name + $ref: /schemas/types.yaml#definitions/string + + link: + description: + Should be a list of phandles to other switch's DSA port. This + port is used as the outgoing port towards the phandle ports. The + full routing information must be given, not just the one hop + routes to neighbouring switches + $ref: /schemas/types.yaml#definitions/phandle-array + + ethernet: + description: + Should be a phandle to a valid Ethernet device node. This host + device is what the switch port is connected to + $ref: /schemas/types.yaml#definitions/phandle + + phy-handle: true + + phy-mode: true + + fixed-link: true + + mac-address: true + + required: + - reg + + additionalProperties: false + +oneOf: + - required: + - ports + - required: + - ethernet-ports + +... diff --git a/Documentation/devicetree/bindings/net/dsa/ocelot.txt b/Documentation/devicetree/bindings/net/dsa/ocelot.txt index 66a129fea705..7a271d070b72 100644 --- a/Documentation/devicetree/bindings/net/dsa/ocelot.txt +++ b/Documentation/devicetree/bindings/net/dsa/ocelot.txt @@ -4,10 +4,15 @@ Microchip Ocelot switch driver family Felix ----- -The VSC9959 core is currently the only switch supported by the driver, and is -found in the NXP LS1028A. It is a PCI device, part of the larger ENETC root -complex. As a result, the ethernet-switch node is a sub-node of the PCIe root -complex node and its "reg" property conforms to the parent node bindings: +Currently the switches supported by the felix driver are: + +- VSC9959 (Felix) +- VSC9953 (Seville) + +The VSC9959 switch is found in the NXP LS1028A. It is a PCI device, part of the +larger ENETC root complex. As a result, the ethernet-switch node is a sub-node +of the PCIe root complex node and its "reg" property conforms to the parent +node bindings: * reg: Specifies PCIe Device Number and Function Number of the endpoint device, in this case for the Ethernet L2Switch it is PF5 (of device 0, bus 0). @@ -114,3 +119,95 @@ Example: }; }; }; + +The VSC9953 switch is found inside NXP T1040. It is a platform device with the +following required properties: + +- compatible: + Must be "mscc,vsc9953-switch". + +Supported PHY interface types (appropriate SerDes protocol setting changes are +needed in the RCW binary): + +* phy_mode = "internal": on ports 8 and 9 +* phy_mode = "sgmii": on ports 0, 1, 2, 3, 4, 5, 6, 7 +* phy_mode = "qsgmii": on ports 0, 1, 2, 3, 4, 5, 6, 7 + +Example: + +&soc { + ethernet-switch@800000 { + #address-cells = <0x1>; + #size-cells = <0x0>; + compatible = "mscc,vsc9953-switch"; + little-endian; + reg = <0x800000 0x290000>; + + ports { + #address-cells = <0x1>; + #size-cells = <0x0>; + + port@0 { + reg = <0x0>; + label = "swp0"; + }; + + port@1 { + reg = <0x1>; + label = "swp1"; + }; + + port@2 { + reg = <0x2>; + label = "swp2"; + }; + + port@3 { + reg = <0x3>; + label = "swp3"; + }; + + port@4 { + reg = <0x4>; + label = "swp4"; + }; + + port@5 { + reg = <0x5>; + label = "swp5"; + }; + + port@6 { + reg = <0x6>; + label = "swp6"; + }; + + port@7 { + reg = <0x7>; + label = "swp7"; + }; + + port@8 { + reg = <0x8>; + phy-mode = "internal"; + ethernet = <&enet0>; + + fixed-link { + speed = <2500>; + full-duplex; + }; + }; + + port@9 { + reg = <0x9>; + phy-mode = "internal"; + status = "disabled"; + + fixed-link { + speed = <2500>; + full-duplex; + }; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 9b1f1147ca36..a9e547ac7905 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -162,6 +162,18 @@ properties: description: Specifies a reference to a node representing a SFP cage. + rx-internal-delay-ps: + description: | + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for + PHY's that have configurable RX internal delays. If this property is + present then the PHY applies the RX delay. + + tx-internal-delay-ps: + description: | + RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for + PHY's that have configurable TX internal delays. If this property is + present then the PHY applies the TX delay. + required: - reg diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml index d6a3bf8550eb..26afb556dfae 100644 --- a/Documentation/devicetree/bindings/net/mdio.yaml +++ b/Documentation/devicetree/bindings/net/mdio.yaml @@ -39,6 +39,13 @@ properties: and must therefore be appropriately determined based on all devices requirements (maximum value of all per-device RESET pulse widths). + reset-post-delay-us: + description: + Delay after reset deassert in microseconds. It applies to all MDIO + devices and it's determined by how fast all devices are ready for + communication. This delay happens just before e.g. Ethernet PHY + type ID auto detection. + clock-frequency: description: Desired MDIO bus clock frequency in Hz. Values greater than IEEE 802.3 diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt index 5ff37c68c941..87a27d775d48 100644 --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt @@ -31,6 +31,8 @@ Optional properties: VSC8531_LINK_100_ACTIVITY (2), VSC8531_LINK_ACTIVITY (0) and VSC8531_DUPLEX_COLLISION (8). +- load-save-gpios : GPIO used for the load/save operation of the PTP + hardware clock (PHC). Table: 1 - Edge rate change @@ -67,4 +69,5 @@ Example: vsc8531,edge-slowdown = <7>; vsc8531,led-0-mode = ; vsc8531,led-1-mode = ; + load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; }; diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml index f15a5e5e4859..c488f24ed38f 100644 --- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml @@ -44,7 +44,7 @@ examples: uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; - uart-has-rtscts = <1>; + uart-has-rtscts; bluetooth { compatible = "realtek,rtl8723bs-bt"; diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml index 554dcd7a40a9..c6716ac6cbcc 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml @@ -24,7 +24,7 @@ description: | IEEE 802.3 Standard Media Independent Interface (MII), the IEEE 802.3 Gigabit Media Independent Interface (GMII) or Reduced GMII (RGMII). - Specifications about the charger can be found at: + Specifications about the Ethernet PHY can be found at: https://www.ti.com/lit/gpn/dp83867ir properties: diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 5b69ef03bbf7..cf40b469c719 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: TI DP83869 ethernet PHY allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: "ethernet-phy.yaml#" maintainers: - Dan Murphy @@ -24,7 +24,7 @@ description: | conversions. The DP83869HM can also support Bridge Conversion from RGMII to SGMII and SGMII to RGMII. - Specifications about the charger can be found at: + Specifications about the Ethernet PHY can be found at: http://www.ti.com/lit/ds/symlink/dp83869hm.pdf properties: @@ -64,6 +64,18 @@ properties: Operational mode for the PHY. If this is not set then the operational mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values + rx-internal-delay-ps: + description: Delay is in pico seconds + enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, + 3250, 3500, 3750, 4000 ] + default: 2000 + + tx-internal-delay-ps: + description: Delay is in pico seconds + enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, + 3250, 3500, 3750, 4000 ] + default: 2000 + required: - reg @@ -80,5 +92,7 @@ examples: ti,op-mode = ; ti,max-output-impedance = "true"; ti,clk-output-sel = ; + rx-internal-delay-ps = <2000>; + tx-internal-delay-ps = <2000>; }; }; diff --git a/drivers/staging/wilc1000/microchip,wilc1000.yaml b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml similarity index 100% rename from drivers/staging/wilc1000/microchip,wilc1000.yaml rename to Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml index daf1321d76ad..6687ab720304 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -15,14 +15,17 @@ allOf: properties: compatible: - enum: - - allwinner,sun4i-a10-sid - - allwinner,sun7i-a20-sid - - allwinner,sun8i-a83t-sid - - allwinner,sun8i-h3-sid - - allwinner,sun50i-a64-sid - - allwinner,sun50i-h5-sid - - allwinner,sun50i-h6-sid + oneOf: + - const: allwinner,sun4i-a10-sid + - const: allwinner,sun7i-a20-sid + - const: allwinner,sun8i-a83t-sid + - const: allwinner,sun8i-h3-sid + - const: allwinner,sun50i-a64-sid + - items: + - const: allwinner,sun50i-a100-sid + - const: allwinner,sun50i-a64-sid + - const: allwinner,sun50i-h5-sid + - const: allwinner,sun50i-h6-sid reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml new file mode 100644 index 000000000000..d10a0cf91ba7 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/qcom,qfprom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies Inc, QFPROM Efuse bindings + +maintainers: + - Srinivas Kandagatla + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + const: qcom,qfprom + + reg: + # If the QFPROM is read-only OS image then only the corrected region + # needs to be provided. If the QFPROM is writable then all 4 regions + # must be provided. + oneOf: + - items: + - description: The corrected region. + - items: + - description: The corrected region. + - description: The raw region. + - description: The config region. + - description: The security control region. + + # Clock must be provided if QFPROM is writable from the OS image. + clocks: + maxItems: 1 + clock-names: + const: core + + # Supply reference must be provided if QFPROM is writable from the OS image. + vcc-supply: + description: Our power supply. + + # Needed if any child nodes are present. + "#address-cells": + const: 1 + "#size-cells": + const: 1 + +required: + - compatible + - reg + +examples: + - | + #include + + soc { + #address-cells = <2>; + #size-cells = <2>; + + efuse@784000 { + compatible = "qcom,qfprom"; + reg = <0 0x00784000 0 0x8ff>, + <0 0x00780000 0 0x7a0>, + <0 0x00782000 0 0x100>, + <0 0x00786000 0 0x1fff>; + clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>; + clock-names = "core"; + #address-cells = <1>; + #size-cells = <1>; + + vcc-supply = <&vreg_l11a_1p8>; + + hstx-trim-primary@25b { + reg = <0x25b 0x1>; + bits = <1 3>; + }; + }; + }; + + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + efuse@784000 { + compatible = "qcom,qfprom"; + reg = <0 0x00784000 0 0x8ff>; + #address-cells = <1>; + #size-cells = <1>; + + hstx-trim-primary@1eb { + reg = <0x1eb 0x1>; + bits = <1 4>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.txt b/Documentation/devicetree/bindings/nvmem/qfprom.txt deleted file mode 100644 index 26fe878d5c86..000000000000 --- a/Documentation/devicetree/bindings/nvmem/qfprom.txt +++ /dev/null @@ -1,35 +0,0 @@ -= Qualcomm QFPROM device tree bindings = - -This binding is intended to represent QFPROM which is found in most QCOM SOCs. - -Required properties: -- compatible: should be "qcom,qfprom" -- reg: Should contain registers location and length - -= Data cells = -Are child nodes of qfprom, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example: - - qfprom: qfprom@700000 { - compatible = "qcom,qfprom"; - reg = <0x00700000 0x8000>; - ... - /* Data cells */ - tsens_calibration: calib@404 { - reg = <0x4404 0x10>; - }; - }; - - -= Data consumers = -Are device nodes which consume nvmem data cells. - -For example: - - tsens { - ... - nvmem-cells = <&tsens_calibration>; - nvmem-cell-names = "calibration"; - }; diff --git a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml new file mode 100644 index 000000000000..9a2e779e6d38 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/brcm,bcm63xx-usbh-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: BCM63xx USBH PHY + +maintainers: + - Álvaro Fernández Rojas + +properties: + compatible: + enum: + - brcm,bcm6318-usbh-phy + - brcm,bcm6328-usbh-phy + - brcm,bcm6358-usbh-phy + - brcm,bcm6362-usbh-phy + - brcm,bcm6368-usbh-phy + - brcm,bcm63268-usbh-phy + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: usbh + - const: usb_ref + + resets: + maxItems: 1 + + "#phy-cells": + const: 1 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - "#phy-cells" + +if: + properties: + compatible: + enum: + - brcm,bcm6318-usbh-phy + - brcm,bcm6328-usbh-phy + - brcm,bcm6362-usbh-phy + - brcm,bcm63268-usbh-phy +then: + properties: + power-domains: + maxItems: 1 + required: + - power-domains +else: + properties: + power-domains: false + +examples: + - | + usbh: usb-phy@10001700 { + compatible = "brcm,bcm6368-usbh-phy"; + reg = <0x10001700 0x38>; + clocks = <&periph_clk 15>; + clock-names = "usbh"; + resets = <&periph_rst 12>; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt index ad49e5c01334..8b5a7a28a35b 100644 --- a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt @@ -12,6 +12,13 @@ Required properties: - #address-cells: should be 1. - #size-cells: should be 0. +Optional properties: + +- reg-names: must be "comphy" as the first name, and "conf". +- reg: must contain the comphy register location and length as the first + pair, followed by an optional configuration register address and + length pair. + A sub-node is required for each comphy lane provided by the comphy. Required properties (child nodes): @@ -24,7 +31,8 @@ Example: comphy: phy@18300 { compatible = "marvell,armada-380-comphy"; - reg = <0x18300 0x100>; + reg-names = "comphy", "conf"; + reg = <0x18300 0x100>, <0x18460 4>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml new file mode 100644 index 000000000000..23887ebe08fd --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,ipq806x-usb-phy-hs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm ipq806x usb DWC3 HS PHY CONTROLLER + +maintainers: + - Ansuel Smith + +description: + DWC3 PHY nodes are defined to describe on-chip Synopsis Physical layer + controllers used in ipq806x. Each DWC3 PHY controller should have its + own node. + +properties: + compatible: + const: qcom,ipq806x-usb-phy-hs + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: ref + - const: xo + +required: + - compatible + - "#phy-cells" + - reg + - clocks + - clock-names + +examples: + - | + #include + + hs_phy_0: phy@110f8800 { + compatible = "qcom,ipq806x-usb-phy-hs"; + reg = <0x110f8800 0x30>; + clocks = <&gcc USB30_0_UTMI_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml new file mode 100644 index 000000000000..fa30c24b4405 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,ipq806x-usb-phy-ss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm ipq806x usb DWC3 SS PHY CONTROLLER + +maintainers: + - Ansuel Smith + +description: + DWC3 PHY nodes are defined to describe on-chip Synopsis Physical layer + controllers used in ipq806x. Each DWC3 PHY controller should have its + own node. + +properties: + compatible: + const: qcom,ipq806x-usb-phy-ss + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: ref + - const: xo + + qcom,rx-eq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Override value for rx_eq. + default: 4 + maximum: 7 + + qcom,tx-deamp-3_5db: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Override value for transmit preemphasis. + default: 23 + maximum: 63 + + qcom,mpll: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Override value for mpll. + default: 0 + maximum: 7 + +required: + - compatible + - "#phy-cells" + - reg + - clocks + - clock-names + +examples: + - | + #include + + ss_phy_0: phy@110f8830 { + compatible = "qcom,ipq806x-usb-phy-ss"; + reg = <0x110f8830 0x30>; + clocks = <&gcc USB30_0_MASTER_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f80f8896d527..e4cd4a1deae9 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq8074-qmp-pcie-phy + - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy - qcom,msm8996-qmp-ufs-phy - qcom,msm8996-qmp-usb3-phy @@ -161,6 +162,7 @@ allOf: compatible: contains: enum: + - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-usb3-phy - qcom,msm8998-qmp-pcie-phy - qcom,msm8998-qmp-usb3-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index b5a6195de7ff..9ba62dcb1e5d 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -18,6 +18,7 @@ properties: oneOf: - items: - enum: + - qcom,ipq8074-qusb2-phy - qcom,msm8996-qusb2-phy - qcom,msm8998-qusb2-phy - items: diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 440f09fddf93..829e8c7e467a 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -21,6 +21,7 @@ properties: - renesas,usb2-phy-r8a774a1 # RZ/G2M - renesas,usb2-phy-r8a774b1 # RZ/G2N - renesas,usb2-phy-r8a774c0 # RZ/G2E + - renesas,usb2-phy-r8a774e1 # RZ/G2H - renesas,usb2-phy-r8a7795 # R-Car H3 - renesas,usb2-phy-r8a7796 # R-Car M3-W - renesas,usb2-phy-r8a77961 # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml index 68cf9dd0390d..f3ef738a3ff6 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml @@ -15,6 +15,7 @@ properties: - enum: - renesas,r8a774a1-usb3-phy # RZ/G2M - renesas,r8a774b1-usb3-phy # RZ/G2N + - renesas,r8a774e1-usb3-phy # RZ/G2H - renesas,r8a7795-usb3-phy # R-Car H3 - renesas,r8a7796-usb3-phy # R-Car M3-W - renesas,r8a77961-usb3-phy # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml new file mode 100644 index 000000000000..636cc501b54f --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,ufs-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SoC series UFS PHY Device Tree Bindings + +maintainers: + - Alim Akhtar + +properties: + "#phy-cells": + const: 0 + + compatible: + enum: + - samsung,exynos7-ufs-phy + + reg: + maxItems: 1 + + reg-names: + items: + - const: phy-pma + + clocks: + items: + - description: PLL reference clock + - description: symbol clock for input symbol ( rx0-ch0 symbol clock) + - description: symbol clock for input symbol ( rx1-ch1 symbol clock) + - description: symbol clock for output symbol ( tx0 symbol clock) + + clock-names: + items: + - const: ref_clk + - const: rx1_symbol_clk + - const: rx0_symbol_clk + - const: tx0_symbol_clk + + samsung,pmu-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle for PMU system controller interface, used to + control pmu registers bits for ufs m-phy + +required: + - "#phy-cells" + - compatible + - reg + - reg-names + - clocks + - clock-names + - samsung,pmu-syscon + +additionalProperties: false + +examples: + - | + #include + + ufs_phy: ufs-phy@15571800 { + compatible = "samsung,exynos7-ufs-phy"; + reg = <0x15571800 0x240>; + reg-names = "phy-pma"; + samsung,pmu-syscon = <&pmu_system_controller>; + #phy-cells = <0>; + clocks = <&clock_fsys1 SCLK_COMBO_PHY_EMBEDDED_26M>, + <&clock_fsys1 PHYCLK_UFS20_RX1_SYMBOL_USER>, + <&clock_fsys1 PHYCLK_UFS20_RX0_SYMBOL_USER>, + <&clock_fsys1 PHYCLK_UFS20_TX0_SYMBOL_USER>; + clock-names = "ref_clk", "rx1_symbol_clk", + "rx0_symbol_clk", "tx0_symbol_clk"; + + }; +... diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml index f88d36207b87..c871d462c952 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml @@ -31,12 +31,16 @@ properties: clocks: minItems: 1 - maxItems: 2 + maxItems: 3 clock-names: oneOf: - const: link # for PXs2 - - items: # for PXs3 + - items: # for PXs3 with phy-ext + - const: link + - const: phy + - const: phy-ext + - items: # for others - const: link - const: phy diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml new file mode 100644 index 000000000000..bcec422d7734 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/ti,phy-gmii-sel.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: CPSW Port's Interface Mode Selection PHY Tree Bindings + +maintainers: + - Kishon Vijay Abraham I + +description: | + TI am335x/am437x/dra7(am5)/dm814x CPSW3G Ethernet Subsystem supports + two 10/100/1000 Ethernet ports with selectable G/MII, RMII, and RGMII interfaces. + The interface mode is selected by configuring the MII mode selection register(s) + (GMII_SEL) in the System Control Module chapter (SCM). GMII_SEL register(s) and + bit fields placement in SCM are different between SoCs while fields meaning + is the same. + +--------------+ + +-------------------------------+ |SCM | + | CPSW | | +---------+ | + | +--------------------------------+gmii_sel | | + | | | | +---------+ | + | +----v---+ +--------+ | +--------------+ + | |Port 1..<--+-->GMII/MII<-------> + | | | | | | | + | +--------+ | +--------+ | + | | | + | | +--------+ | + | | | RMII <-------> + | +--> | | + | | +--------+ | + | | | + | | +--------+ | + | | | RGMII <-------> + | +--> | | + | +--------+ | + +-------------------------------+ + + CPSW Port's Interface Mode Selection PHY describes MII interface mode between + CPSW Port and Ethernet PHY which depends on Eth PHY and board configuration. + | + CPSW Port's Interface Mode Selection PHY device should defined as child device + of SCM node (scm_conf) and can be attached to each CPSW port node using standard + PHY bindings. + +properties: + compatible: + enum: + - ti,am3352-phy-gmii-sel + - ti,dra7xx-phy-gmii-sel + - ti,am43xx-phy-gmii-sel + - ti,dm814-phy-gmii-sel + - ti,am654-phy-gmii-sel + + reg: + description: Address and length of the register set for the device + + '#phy-cells': true + +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,dra7xx-phy-gmii-sel + - ti,dm814-phy-gmii-sel + - ti,am654-phy-gmii-sel + then: + properties: + '#phy-cells': + const: 1 + description: CPSW port number (starting from 1) + - if: + properties: + compatible: + contains: + enum: + - ti,am3352-phy-gmii-sel + - ti,am43xx-phy-gmii-sel + then: + properties: + '#phy-cells': + const: 2 + description: | + - CPSW port number (starting from 1) + - RMII refclk mode + +required: + - compatible + - reg + - '#phy-cells' + +additionalProperties: false + +examples: + - | + phy_gmii_sel: phy-gmii-sel@650 { + compatible = "ti,am3352-phy-gmii-sel"; + reg = <0x650 0x4>; + #phy-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt b/Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt deleted file mode 100644 index 83b78c1c0644..000000000000 --- a/Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt +++ /dev/null @@ -1,69 +0,0 @@ -CPSW Port's Interface Mode Selection PHY Tree Bindings ------------------------------------------------ - -TI am335x/am437x/dra7(am5)/dm814x CPSW3G Ethernet Subsystem supports -two 10/100/1000 Ethernet ports with selectable G/MII, RMII, and RGMII interfaces. -The interface mode is selected by configuring the MII mode selection register(s) -(GMII_SEL) in the System Control Module chapter (SCM). GMII_SEL register(s) and -bit fields placement in SCM are different between SoCs while fields meaning -is the same. - +--------------+ - +-------------------------------+ |SCM | - | CPSW | | +---------+ | - | +--------------------------------+gmii_sel | | - | | | | +---------+ | - | +----v---+ +--------+ | +--------------+ - | |Port 1..<--+-->GMII/MII<-------> - | | | | | | | - | +--------+ | +--------+ | - | | | - | | +--------+ | - | | | RMII <-------> - | +--> | | - | | +--------+ | - | | | - | | +--------+ | - | | | RGMII <-------> - | +--> | | - | +--------+ | - +-------------------------------+ - -CPSW Port's Interface Mode Selection PHY describes MII interface mode between -CPSW Port and Ethernet PHY which depends on Eth PHY and board configuration. - -CPSW Port's Interface Mode Selection PHY device should defined as child device -of SCM node (scm_conf) and can be attached to each CPSW port node using standard -PHY bindings (See phy/phy-bindings.txt). - -Required properties: -- compatible : Should be "ti,am3352-phy-gmii-sel" for am335x platform - "ti,dra7xx-phy-gmii-sel" for dra7xx/am57xx platform - "ti,am43xx-phy-gmii-sel" for am43xx platform - "ti,dm814-phy-gmii-sel" for dm814x platform - "ti,am654-phy-gmii-sel" for AM654x/J721E platform -- reg : Address and length of the register set for the device -- #phy-cells : must be 2. - cell 1 - CPSW port number (starting from 1) - cell 2 - RMII refclk mode - -Examples: - phy_gmii_sel: phy-gmii-sel { - compatible = "ti,am3352-phy-gmii-sel"; - reg = <0x650 0x4>; - #phy-cells = <2>; - }; - - mac: ethernet@4a100000 { - compatible = "ti,am335x-cpsw","ti,cpsw"; - ... - - cpsw_emac0: slave@4a100200 { - ... - phys = <&phy_gmii_sel 1 1>; - }; - - cpsw_emac1: slave@4a100300 { - ... - phys = <&phy_gmii_sel 2 1>; - }; - }; diff --git a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml new file mode 100644 index 000000000000..04d5654efb38 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/xlnx,zynqmp-psgtr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP Gigabit Transceiver PHY Device Tree Bindings + +maintainers: + - Laurent Pinchart + +description: | + This binding describes the Xilinx ZynqMP Gigabit Transceiver (GTR) PHY. The + GTR provides four lanes and is used by USB, SATA, PCIE, Display port and + Ethernet SGMII controllers. + +properties: + "#phy-cells": + const: 4 + description: | + The cells contain the following arguments. + + - description: The GTR lane + minimum: 0 + maximum: 3 + - description: The PHY type + enum: + - PHY_TYPE_DP + - PHY_TYPE_PCIE + - PHY_TYPE_SATA + - PHY_TYPE_SGMII + - PHY_TYPE_USB + - description: The PHY instance + minimum: 0 + maximum: 1 # for DP, SATA or USB + maximum: 3 # for PCIE or SGMII + - description: The reference clock number + minimum: 0 + maximum: 3 + + compatible: + enum: + - xlnx,zynqmp-psgtr-v1.1 + - xlnx,zynqmp-psgtr + + clocks: + minItems: 1 + maxItems: 4 + description: | + Clock for each PS_MGTREFCLK[0-3] reference clock input. Unconnected + inputs shall not have an entry. + + clock-names: + minItems: 1 + maxItems: 4 + items: + pattern: "^ref[0-3]$" + + reg: + items: + - description: SERDES registers block + - description: SIOU registers block + + reg-names: + items: + - const: serdes + - const: siou + + xlnx,tx-termination-fix: + description: | + Include this for fixing functional issue with the TX termination + resistance in GT, which can be out of spec for the XCZU9EG silicon + version. + type: boolean + +required: + - "#phy-cells" + - compatible + - reg + - reg-names + +if: + properties: + compatible: + const: xlnx,zynqmp-psgtr-v1.1 + +then: + properties: + xlnx,tx-termination-fix: false + +additionalProperties: false + +examples: + - | + phy: phy@fd400000 { + compatible = "xlnx,zynqmp-psgtr-v1.1"; + reg = <0xfd400000 0x40000>, + <0xfd3d0000 0x1000>; + reg-names = "serdes", "siou"; + clocks = <&refclks 3>, <&refclks 2>, <&refclks 0>; + clock-names = "ref1", "ref2", "ref3"; + #phy-cells = <4>; + }; + +... diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index 55b6ab2d8784..ec2aaeee78dc 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -25,6 +25,7 @@ properties: - renesas,r8a774a1-sysc # RZ/G2M - renesas,r8a774b1-sysc # RZ/G2N - renesas,r8a774c0-sysc # RZ/G2E + - renesas,r8a774e1-sysc # RZ/G2H - renesas,r8a7779-sysc # R-Car H1 - renesas,r8a7790-sysc # R-Car H2 - renesas,r8a7791-sysc # R-Car M2-W diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt index c80a110c1e26..218f99fa311f 100644 --- a/Documentation/devicetree/bindings/property-units.txt +++ b/Documentation/devicetree/bindings/property-units.txt @@ -17,6 +17,7 @@ Time/Frequency -ms : millisecond -us : microsecond -ns : nanosecond +-ps : picosecond Distance ---------------------------------------- diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml index fc799b0577d4..188679cb8b8c 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml @@ -18,9 +18,6 @@ description: |+ Be aware that the clocksource driver supports only uniprocessor systems. -allOf: - - $ref: pwm.yaml# - properties: compatible: enum: @@ -63,7 +60,8 @@ properties: interrupts: description: - One interrupt per timer, starting at timer 0. + One interrupt per timer, starting at timer 0. Necessary only for SoCs which + use PWM clocksource. minItems: 1 maxItems: 5 @@ -88,12 +86,27 @@ required: - clocks - clock-names - compatible - - interrupts - "#pwm-cells" - reg additionalProperties: false +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2410-pwm + - samsung,s3c6400-pwm + - samsung,s5p6440-pwm + - samsung,s5pc100-pwm + then: + required: + - interrupts + examples: - | pwm@7f006000 { diff --git a/Documentation/devicetree/bindings/regulator/da9211.txt b/Documentation/devicetree/bindings/regulator/da9211.txt index 27717e816e71..eb871447d508 100644 --- a/Documentation/devicetree/bindings/regulator/da9211.txt +++ b/Documentation/devicetree/bindings/regulator/da9211.txt @@ -15,6 +15,8 @@ Required properties: Optional properties: - enable-gpios: platform gpio for control of BUCKA/BUCKB. - Any optional property defined in regulator.txt + - regulator-initial-mode and regulator-allowed-modes may be specified using + mode values from dt-bindings/regulator/dlg,da9211-regulator.h Example 1) DA9211 pmic: da9211@68 { @@ -30,6 +32,8 @@ Example 1) DA9211 regulator-min-microamp = <2000000>; regulator-max-microamp = <5000000>; enable-gpios = <&gpio 27 0>; + regulator-allowed-modes = ; }; }; }; diff --git a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml new file mode 100644 index 000000000000..c9453d7ce227 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/google,cros-ec-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ChromeOS EC controlled voltage regulators + +maintainers: + - Pi-Hsun Shih + +description: + Any property defined as part of the core regulator binding, defined in + regulator.yaml, can also be used. + +allOf: + - $ref: "regulator.yaml#" + +properties: + compatible: + const: google,cros-ec-regulator + + reg: + maxItems: 1 + description: Identifier for the voltage regulator to ChromeOS EC. + +required: + - compatible + - reg + +examples: + - | + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + cros_ec: ec@0 { + compatible = "google,cros-ec-spi"; + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + regulator@0 { + compatible = "google,cros-ec-regulator"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + reg = <0>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt index ca58a68ffdf1..ab895cd1cac1 100644 --- a/Documentation/devicetree/bindings/regulator/lp872x.txt +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt @@ -37,8 +37,8 @@ Optional properties: (Documentation/devicetree/bindings/regulator/regulator.txt) Datasheet - - LP8720: http://www.ti.com/lit/ds/symlink/lp8720.pdf - - LP8725: http://www.ti.com/lit/ds/symlink/lp8725.pdf + - LP8720: https://www.ti.com/lit/ds/symlink/lp8720.pdf + - LP8725: https://www.ti.com/lit/ds/symlink/lp8725.pdf Example 1) LP8720 diff --git a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt index 01141fb00875..c080086d3e62 100644 --- a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt @@ -16,6 +16,9 @@ LDO: ldo_vemc3v3, ldo_vgp1, ldo_vgp2, ldo_vgp3, ldo_vgp4, ldo_vgp5, ldo_vgp6, ldo_vibr +BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to +values specified in dt-bindings/regulator/mediatek,mt6397-regulator.h + Example: pmic { compatible = "mediatek,mt6397"; diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml new file mode 100644 index 000000000000..c2b0a8b6da1e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -0,0 +1,190 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/nxp,pca9450-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA9450A/B/C Power Management Integrated Circuit regulators + +maintainers: + - Robin Gong + +description: | + Regulator nodes should be named to BUCK_ and LDO_. The + definition for each of these nodes is defined using the standard + binding for regulators at + Documentation/devicetree/bindings/regulator/regulator.txt. + Datasheet is available at + https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf + +#The valid names for PCA9450 regulator nodes are: +#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, +#LDO1, LDO2, LDO3, LDO4, LDO5 +#Note: Buck3 removed on PCA9450B and connect with Buck1 on PCA9450C. + +properties: + compatible: + enum: + - nxp,pca9450a + - nxp,pca9450b + - nxp,pca9450c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + regulators: + type: object + description: | + list of regulators provided by this controller + + patternProperties: + "^LDO[1-5]$": + type: object + $ref: regulator.yaml# + description: + Properties for single LDO regulator. + + properties: + regulator-name: + pattern: "^LDO[1-5]$" + description: + should be "LDO1", ..., "LDO5" + + unevaluatedProperties: false + + "^BUCK[1-6]$": + type: object + $ref: regulator.yaml# + description: + Properties for single BUCK regulator. + + properties: + regulator-name: + pattern: "^BUCK[1-6]$" + description: + should be "BUCK1", ..., "BUCK6" + + nxp,dvs-run-voltage: + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 600000 + maximum: 2187500 + description: + PMIC default "RUN" state voltage in uV. Only Buck1~3 have such + dvs(dynamic voltage scaling) property. + + nxp,dvs-standby-voltage: + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 600000 + maximum: 2187500 + description: + PMIC default "STANDBY" state voltage in uV. Only Buck1~3 have such + dvs(dynamic voltage scaling) property. + + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - regulators + +additionalProperties: false + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + pmic: pmic@25 { + compatible = "nxp,pca9450b"; + reg = <0x25>; + pinctrl-0 = <&pinctrl_pmic>; + interrupt-parent = <&gpio1>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + + regulators { + buck1: BUCK1 { + regulator-name = "BUCK1"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; + regulator-boot-on; + regulator-always-on; + regulator-ramp-delay = <3125>; + }; + buck2: BUCK2 { + regulator-name = "BUCK2"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <2187500>; + regulator-boot-on; + regulator-always-on; + regulator-ramp-delay = <3125>; + nxp,dvs-run-voltage = <950000>; + nxp,dvs-standby-voltage = <850000>; + }; + buck4: BUCK4 { + regulator-name = "BUCK4"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + regulator-always-on; + }; + buck5: BUCK5 { + regulator-name = "BUCK5"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + regulator-always-on; + }; + buck6: BUCK6 { + regulator-name = "BUCK6"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo1: LDO1 { + regulator-name = "LDO1"; + regulator-min-microvolt = <1600000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + ldo2: LDO2 { + regulator-name = "LDO2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1150000>; + regulator-boot-on; + regulator-always-on; + }; + ldo3: LDO3 { + regulator-name = "LDO3"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + ldo4: LDO4 { + regulator-name = "LDO4"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + ldo5: LDO5 { + regulator-name = "LDO5"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml new file mode 100644 index 000000000000..eb61e04ef852 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/onnn,fan53880.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/onnn,fan53880.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Onsemi FAN53880 PMIC + +maintainers: + - Christoph Fritz + +description: | + The FAN53880 is an I2C porgrammable power management IC (PMIC) + that contains a BUCK (step-down converter), four low dropouts (LDO) + and one BOOST (step-up converter) output. It is designed for mobile + power applications. + +properties: + $nodename: + pattern: "pmic@[0-9a-f]{1,2}" + compatible: + enum: + - onnn,fan53880 + + reg: + maxItems: 1 + + VIN12-supply: + description: Input supply phandle(s) for LDO1 and LDO2 + + VIN3-supply: + description: Input supply phandle(s) for LDO3 + + VIN4-supply: + description: Input supply phandle(s) for LDO4 + + PVIN-supply: + description: Input supply phandle(s) for BUCK and BOOST + + regulators: + type: object + $ref: regulator.yaml# + description: | + list of regulators provided by this controller, must be named + after their hardware counterparts LDO[1-4], BUCK and BOOST + + patternProperties: + "^LDO[1-4]$": + type: object + $ref: regulator.yaml# + + "^BUCK|BOOST$": + type: object + $ref: regulator.yaml# + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@35 { + compatible = "onnn,fan53880"; + reg = <0x35>; + + PVIN-supply = <&fixreg_example_vcc>; + + regulators { + BUCK { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt deleted file mode 100644 index dea4384f4c03..000000000000 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt +++ /dev/null @@ -1,320 +0,0 @@ -QCOM SMD RPM REGULATOR - -The Qualcomm RPM over SMD regulator is modelled as a subdevice of the RPM. -Because SMD is used as the communication transport mechanism, the RPM resides as -a subnode of the SMD. As such, the SMD-RPM regulator requires that the SMD and -RPM nodes be present. - -Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt for -information pertaining to the SMD node. - -Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt for -information regarding the RPM node. - -== Regulator - -Regulator nodes are identified by their compatible: - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,rpm-pm8841-regulators" - "qcom,rpm-pm8916-regulators" - "qcom,rpm-pm8941-regulators" - "qcom,rpm-pm8950-regulators" - "qcom,rpm-pm8994-regulators" - "qcom,rpm-pm8998-regulators" - "qcom,rpm-pma8084-regulators" - "qcom,rpm-pmi8994-regulators" - "qcom,rpm-pmi8998-regulators" - "qcom,rpm-pms405-regulators" - -- 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: - 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_l2_l3-supply: -- vdd_l4_l5_l6-supply: -- vdd_l7-supply: -- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18-supply: - Usage: optional (pm8916 only) - Value type: - 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_s4-supply: -- vdd_s5-supply: -- vdd_s6-supply: -- vdd_l1_l19-supply: -- vdd_l2_l23-supply: -- vdd_l3-supply: -- vdd_l4_l5_l6_l7_l16-supply: -- vdd_l8_l11_l12_l17_l22-supply: -- vdd_l9_l10_l13_l14_l15_l18-supply: -- vdd_l20-supply: -- vdd_l21-supply: - Usage: optional (pm8950 only) - Value type: - 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_lvs1_2_3-supply: -- vdd_l4_l11-supply: -- vdd_l5_l7-supply: -- vdd_l6_l12_l14_l15-supply: -- vdd_l8_l16_l18_l19-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: - 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_s5-supply: -- vdd_s6-supply: -- vdd_s7-supply: -- vdd_s8-supply: -- vdd_s9-supply: -- vdd_s10-supply: -- vdd_s11-supply: -- vdd_s12-supply: -- vdd_l1-supply: -- vdd_l2_l26_l28-supply: -- vdd_l3_l11-supply: -- vdd_l4_l27_l31-supply: -- vdd_l5_l7-supply: -- vdd_l6_l12_l32-supply: -- vdd_l5_l7-supply: -- vdd_l8_l16_l30-supply: -- vdd_l9_l10_l18_l22-supply: -- vdd_l9_l10_l18_l22-supply: -- vdd_l3_l11-supply: -- vdd_l6_l12_l32-supply: -- vdd_l13_l19_l23_l24-supply: -- vdd_l14_l15-supply: -- vdd_l14_l15-supply: -- vdd_l8_l16_l30-supply: -- vdd_l17_l29-supply: -- vdd_l9_l10_l18_l22-supply: -- vdd_l13_l19_l23_l24-supply: -- vdd_l20_l21-supply: -- vdd_l20_l21-supply: -- vdd_l9_l10_l18_l22-supply: -- vdd_l13_l19_l23_l24-supply: -- vdd_l13_l19_l23_l24-supply: -- vdd_l25-supply: -- vdd_l2_l26_l28-supply: -- vdd_l4_l27_l31-supply: -- vdd_l2_l26_l28-supply: -- vdd_l17_l29-supply: -- vdd_l8_l16_l30-supply: -- vdd_l4_l27_l31-supply: -- vdd_l6_l12_l32-supply: -- vdd_lvs1_2-supply: - Usage: optional (pm8994 only) - Value type: - Definition: reference to regulator supplying the input pin, as - described in the data sheet - -- vdd_s1-supply: -- vdd_s2-supply: -- vdd_s3-supply: -- vdd_bst_byp-supply: - Usage: optional (pmi8994 only) - Value type: - 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_s5-supply: -- vdd_s6-supply: -- vdd_s7-supply: -- vdd_s8-supply: -- vdd_s9-supply: -- vdd_s10-supply: -- vdd_s11-supply: -- vdd_s12-supply: -- vdd_s13-supply: -- vdd_l1_l27-supply: -- vdd_l20_l24-supply: -- vdd_l26-supply: -- vdd_l2_l8_l17-supply: -- vdd_l3_l11-supply: -- vdd_l4_l5-supply: -- vdd_l6-supply: -- vdd_l7_l12_l14_l15-supply: -- vdd_l9-supply: -- vdd_l10_l23_l25-supply: -- vdd_l13_l19_l21-supply: -- vdd_l16_l28-supply: -- vdd_l18_l22-supply: -- vdd_lvs1_lvs2-supply: - Usage: optional (pmi8998 only) - Value type: - 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_s5-supply: -- vdd_s6-supply: -- vdd_s7-supply: -- vdd_s8-supply: -- vdd_s9-supply: -- vdd_s10-supply: -- vdd_s11-supply: -- vdd_s12-supply: -- vdd_l1_l11-supply: -- vdd_l2_l3_l4_l27-supply: -- vdd_l5_l7-supply: -- vdd_l6_l12_l14_l15_l26-supply: -- vdd_l8-supply: -- vdd_l9_l10_l13_l20_l23_l24-supply: -- vdd_l16_l25-supply: -- vdd_l17-supply: -- vdd_l18-supply: -- vdd_l19-supply: -- vdd_l21-supply: -- vdd_l22-supply: - Usage: optional (pma8084 only) - Value type: - Definition: reference to regulator supplying the input pin, as - described in the data sheet - -- vdd_bob-supply: - Usage: optional (pmi8998 only) - Value type: - 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_s5-supply: -- vdd_l1_l2-supply: -- vdd_l3_l8-supply: -- vdd_l4-supply: -- vdd_l5_l6-supply: -- vdd_l7-supply: -- vdd_l3_l8-supply: -- vdd_l9-supply: -- vdd_l10_l11_l12_l13-supply: - Usage: optional (pms405 only) - Value type: - 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, s4, 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, 5vs1, 5vs2 - -pm8994: - s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5, - l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, - l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2 - -pm8998: - s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, l1, l2, l3, l4, - l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, - l20, l21, l22, l23, l24, l25, l26, l27, l28, lvs1, lvs2 - -pma8084: - s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5, - l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, - l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1 - -pmi8994: - s1, s2, s3, boost-bypass - -pmi8998: - bob - -pms405: - s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, - l13 - -The content of each sub-node is defined by the standard binding for regulators - -see regulator.txt. - -= EXAMPLE - - smd { - compatible = "qcom,smd"; - - rpm { - interrupts = <0 168 1>; - qcom,ipc = <&apcs 8 0>; - qcom,smd-edge = <15>; - - rpm_requests { - compatible = "qcom,rpm-msm8974"; - qcom,smd-channels = "rpm_requests"; - - pm8941-regulators { - compatible = "qcom,rpm-pm8941-regulators"; - vdd_l13_l20_l23_l24-supply = <&pm8941_boost>; - - pm8941_s3: s3 { - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - }; - - pm8941_boost: s4 { - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - }; - - pm8941_l20: l20 { - regulator-min-microvolt = <2950000>; - regulator-max-microvolt = <2950000>; - }; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml new file mode 100644 index 000000000000..d2022206081f --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/qcom,smd-rpm-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QCOM SMD RPM REGULATOR + +description: + The Qualcomm RPM over SMD regulator is modelled as a subdevice of the RPM. + Because SMD is used as the communication transport mechanism, the RPM + resides as a subnode of the SMD. As such, the SMD-RPM regulator requires + that the SMD and RPM nodes be present. + + Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt for + information pertaining to the SMD node. + + Please refer to Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml + for information regarding the RPM node. + + 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. + + For mp5496, s2 + + For pm8841, s1, s2, s3, s4, s5, s6, s7, s8 + + For pm8916, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, + l12, l13, l14, l15, l16, l17, l18 + + For pm8941, s1, s2, s3, s4, 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, 5vs1, 5vs2 + + For pm8994, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, + l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, + l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2 + + For pm8998, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, l1, l2, + l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, + l20, l21, l22, l23, l24, l25, l26, l27, l28, lvs1, lvs2 + + For pma8084, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, + l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, + l20, l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1 + + For pmi8994, s1, s2, s3, boost-bypass + + For pmi8998, bob + + For pms405, s1, s2, s3, s4, s5, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, + l12, l13 + +maintainers: + - Kathiravan T + +properties: + compatible: + enum: + - qcom,rpm-mp5496-regulators + - qcom,rpm-pm8841-regulators + - qcom,rpm-pm8916-regulators + - qcom,rpm-pm8941-regulators + - qcom,rpm-pm8950-regulators + - qcom,rpm-pm8994-regulators + - qcom,rpm-pm8998-regulators + - qcom,rpm-pma8084-regulators + - qcom,rpm-pmi8994-regulators + - qcom,rpm-pmi8998-regulators + - qcom,rpm-pms405-regulators + +patternProperties: + ".*-supply$": + description: Input supply phandle(s) for this node + + "^((s|l|lvs|5vs)[0-9]*)|(boost-bypass)|(bob)$": + description: List of regulators and its properties + allOf: + - $ref: regulator.yaml# + +additionalProperties: false + +required: + - compatible + +examples: + - | + pm8941-regulators { + compatible = "qcom,rpm-pm8941-regulators"; + vdd_l13_l20_l23_l24-supply = <&pm8941_boost>; + + pm8941_s3: s3 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + pm8941_boost: s4 { + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + }; + + pm8941_l20: l20 { + regulator-min-microvolt = <2950000>; + regulator-max-microvolt = <2950000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml new file mode 100644 index 000000000000..12ed98c28aaa --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: The Qualcomm PMIC VBUS output regulator driver + +maintainers: + - Wesley Cheng + +description: | + This regulator driver controls the VBUS output by the Qualcomm PMIC. This + regulator will be enabled in situations where the device is required to + provide power to the connected peripheral. + +properties: + compatible: + enum: + - qcom,pm8150b-vbus-reg + + reg: + maxItems: 1 + description: VBUS output base address + +required: + - compatible + +additionalProperties: false + +examples: + - | + pm8150b { + #address-cells = <1>; + #size-cells = <0>; + pm8150b_vbus: dcdc@1100 { + compatible = "qcom,pm8150b-vbus-reg"; + reg = <0x1100>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml new file mode 100644 index 000000000000..085cbd1ad8d0 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/qcom-labibb-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator + +maintainers: + - Sumit Semwal + +description: + LAB can be used as a positive boost power supply and IBB can be used as a + negative boost power supply for display panels. Currently implemented for + pmi8998. + +properties: + compatible: + const: qcom,pmi8998-lab-ibb + + lab: + type: object + + properties: + + interrupts: + maxItems: 1 + description: + Short-circuit interrupt for lab. + + required: + - interrupts + + ibb: + type: object + + properties: + + interrupts: + maxItems: 1 + description: + Short-circuit interrupt for lab. + + required: + - interrupts + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include + + labibb { + compatible = "qcom,pmi8998-lab-ibb"; + + lab { + interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "sc-err"; + }; + + ibb { + interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "sc-err"; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml b/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml new file mode 100644 index 000000000000..15983cdc7c28 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/silergy,sy8827n.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/silergy,sy8827n.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: silergy sy8827n PMIC + +maintainers: + - Jisheng Zhang + +properties: + compatible: + enum: + - silergy,sy8827n + + reg: + maxItems: 1 + + enable-gpios: + description: GPIO to enable/disable the regulator. + maxItems: 1 + + silergy,vsel-state-high: + type: boolean + description: + Indicates if the VSEL pin is set to high. + If this property is missing, assume the VSEL pin is set to low. + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + regulator@60 { + compatible = "silergy,sy8827n"; + reg = <0x60>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx-src.txt deleted file mode 100644 index 6ed79e60248a..000000000000 --- a/Documentation/devicetree/bindings/reset/fsl,imx-src.txt +++ /dev/null @@ -1,49 +0,0 @@ -Freescale i.MX System Reset Controller -====================================== - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -Required properties: -- compatible: Should be "fsl,-src" -- reg: should be register base and length as documented in the - datasheet -- interrupts: Should contain SRC interrupt and CPU WDOG interrupt, - in this order. -- #reset-cells: 1, see below - -example: - -src: src@20d8000 { - compatible = "fsl,imx6q-src"; - reg = <0x020d8000 0x4000>; - interrupts = <0 91 0x04 0 96 0x04>; - #reset-cells = <1>; -}; - -Specifying reset lines connected to IP modules -============================================== - -The system reset controller can be used to reset the GPU, VPU, -IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device -nodes should specify the reset line on the SRC in their resets -property, containing a phandle to the SRC device node and a -RESET_INDEX specifying which module to reset, as described in -reset.txt - -example: - - ipu1: ipu@2400000 { - resets = <&src 2>; - }; - ipu2: ipu@2800000 { - resets = <&src 4>; - }; - -The following RESET_INDEX values are valid for i.MX5: -GPU_RESET 0 -VPU_RESET 1 -IPU1_RESET 2 -OPEN_VG_RESET 3 -The following additional RESET_INDEX value is valid for i.MX6: -IPU2_RESET 4 diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml new file mode 100644 index 000000000000..27c5e34a3ac6 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/fsl,imx-src.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX System Reset Controller + +maintainers: + - Philipp Zabel + +description: | + The system reset controller can be used to reset the GPU, VPU, + IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device + nodes should specify the reset line on the SRC in their resets + property, containing a phandle to the SRC device node and a + RESET_INDEX specifying which module to reset, as described in + reset.txt + + The following RESET_INDEX values are valid for i.MX5: + GPU_RESET 0 + VPU_RESET 1 + IPU1_RESET 2 + OPEN_VG_RESET 3 + The following additional RESET_INDEX value is valid for i.MX6: + IPU2_RESET 4 + +properties: + compatible: + oneOf: + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx50-src" + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx53-src" + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx6q-src" + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx6sx-src" + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx6sl-src" + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx6ul-src" + - const: "fsl,imx51-src" + - items: + - const: "fsl,imx6sll-src" + - const: "fsl,imx51-src" + + reg: + maxItems: 1 + + interrupts: + items: + - description: SRC interrupt + - description: CPU WDOG interrupts out of SRC + minItems: 1 + maxItems: 2 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#reset-cells' + +additionalProperties: false + +examples: + - | + reset-controller@73fd0000 { + compatible = "fsl,imx51-src"; + reg = <0x73fd0000 0x4000>; + interrupts = <75>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt deleted file mode 100644 index e10502d9153e..000000000000 --- a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt +++ /dev/null @@ -1,56 +0,0 @@ -Freescale i.MX7 System Reset Controller -====================================== - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -Required properties: -- compatible: - - For i.MX7 SoCs should be "fsl,imx7d-src", "syscon" - - For i.MX8MQ SoCs should be "fsl,imx8mq-src", "syscon" - - For i.MX8MM SoCs should be "fsl,imx8mm-src", "fsl,imx8mq-src", "syscon" - - For i.MX8MN SoCs should be "fsl,imx8mn-src", "fsl,imx8mq-src", "syscon" - - For i.MX8MP SoCs should be "fsl,imx8mp-src", "syscon" -- reg: should be register base and length as documented in the - datasheet -- interrupts: Should contain SRC interrupt -- #reset-cells: 1, see below - -example: - -src: reset-controller@30390000 { - compatible = "fsl,imx7d-src", "syscon"; - reg = <0x30390000 0x2000>; - interrupts = ; - #reset-cells = <1>; -}; - - -Specifying reset lines connected to IP modules -============================================== - -The system reset controller can be used to reset various set of -peripherals. Device nodes that need access to reset lines should -specify them as a reset phandle in their corresponding node as -specified in reset.txt. - -Example: - - pcie: pcie@33800000 { - - ... - - resets = <&src IMX7_RESET_PCIEPHY>, - <&src IMX7_RESET_PCIE_CTRL_APPS_EN>; - reset-names = "pciephy", "apps"; - - ... - }; - - -For list of all valid reset indices see - for i.MX7, - for i.MX8MQ and - for i.MX8MM and - for i.MX8MN and - for i.MX8MP diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml new file mode 100644 index 000000000000..b1a71c1bb05b --- /dev/null +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/fsl,imx7-src.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX7 System Reset Controller + +maintainers: + - Andrey Smirnov + +description: | + The system reset controller can be used to reset various set of + peripherals. Device nodes that need access to reset lines should + specify them as a reset phandle in their corresponding node as + specified in reset.txt. + + For list of all valid reset indices see + for i.MX7, + for i.MX8MQ, i.MX8MM and i.MX8MN, + for i.MX8MP. + +properties: + compatible: + items: + - enum: + - fsl,imx7d-src + - fsl,imx8mq-src + - fsl,imx8mp-src + - const: syscon + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include + + reset-controller@30390000 { + compatible = "fsl,imx7d-src", "syscon"; + reg = <0x30390000 0x2000>; + interrupts = ; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml index 4c2b429ac702..2849ce45703c 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml @@ -31,6 +31,7 @@ properties: - renesas,r8a774a1-rst # RZ/G2M - renesas,r8a774b1-rst # RZ/G2N - renesas,r8a774c0-rst # RZ/G2E + - renesas,r8a774e1-rst # RZ/G2H - renesas,r8a7778-reset-wdt # R-Car M1A - renesas,r8a7779-reset-wdt # R-Car H1 - renesas,r8a7790-rst # R-Car H2 diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml new file mode 100644 index 000000000000..4c9b0ebf6869 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/socionext,uniphier-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UniPhier reset controller + +maintainers: + - Masahiro Yamada + +properties: + compatible: + oneOf: + - description: System reset + enum: + - socionext,uniphier-ld4-reset + - socionext,uniphier-pro4-reset + - socionext,uniphier-sld8-reset + - socionext,uniphier-pro5-reset + - socionext,uniphier-pxs2-reset + - socionext,uniphier-ld6b-reset + - socionext,uniphier-ld11-reset + - socionext,uniphier-ld20-reset + - socionext,uniphier-pxs3-reset + - description: Media I/O (MIO) reset, SD reset + enum: + - socionext,uniphier-ld4-mio-reset + - socionext,uniphier-pro4-mio-reset + - socionext,uniphier-sld8-mio-reset + - socionext,uniphier-pro5-sd-reset + - socionext,uniphier-pxs2-sd-reset + - socionext,uniphier-ld11-mio-reset + - socionext,uniphier-ld11-sd-reset + - socionext,uniphier-ld20-sd-reset + - socionext,uniphier-pxs3-sd-reset + - description: Peripheral reset + enum: + - socionext,uniphier-ld4-peri-reset + - socionext,uniphier-pro4-peri-reset + - socionext,uniphier-sld8-peri-reset + - socionext,uniphier-pro5-peri-reset + - socionext,uniphier-pxs2-peri-reset + - socionext,uniphier-ld11-peri-reset + - socionext,uniphier-ld20-peri-reset + - socionext,uniphier-pxs3-peri-reset + - description: Analog signal amplifier reset + enum: + - socionext,uniphier-ld11-adamv-reset + - socionext,uniphier-ld20-adamv-reset + + "#reset-cells": + const: 1 + +additionalProperties: false + +required: + - compatible + - "#reset-cells" + +examples: + - | + sysctrl@61840000 { + compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon"; + reg = <0x61840000 0x4000>; + + reset { + compatible = "socionext,uniphier-ld11-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; + + - | + mioctrl@59810000 { + compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon"; + reg = <0x59810000 0x800>; + + reset { + compatible = "socionext,uniphier-ld11-mio-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; + + - | + perictrl@59820000 { + compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon"; + reg = <0x59820000 0x200>; + + reset { + compatible = "socionext,uniphier-ld11-peri-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; + + - | + adamv@57920000 { + compatible = "socionext,uniphier-ld11-adamv", "simple-mfd", "syscon"; + reg = <0x57920000 0x1000>; + + reset { + compatible = "socionext,uniphier-ld11-adamv-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt index e320a8cc9e4d..88e06e5e8d23 100644 --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt @@ -1,123 +1,4 @@ -UniPhier reset controller - - -System reset ------------- - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld4-reset" - for LD4 SoC - "socionext,uniphier-pro4-reset" - for Pro4 SoC - "socionext,uniphier-sld8-reset" - for sLD8 SoC - "socionext,uniphier-pro5-reset" - for Pro5 SoC - "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC - "socionext,uniphier-ld11-reset" - for LD11 SoC - "socionext,uniphier-ld20-reset" - for LD20 SoC - "socionext,uniphier-pxs3-reset" - for PXs3 SoC -- #reset-cells: should be 1. - -Example: - - sysctrl@61840000 { - compatible = "socionext,uniphier-ld11-sysctrl", - "simple-mfd", "syscon"; - reg = <0x61840000 0x4000>; - - reset { - compatible = "socionext,uniphier-ld11-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; - - -Media I/O (MIO) reset, SD reset -------------------------------- - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld4-mio-reset" - for LD4 SoC - "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC - "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC - "socionext,uniphier-pro5-sd-reset" - for Pro5 SoC - "socionext,uniphier-pxs2-sd-reset" - for PXs2/LD6b SoC - "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO) - "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD) - "socionext,uniphier-ld20-sd-reset" - for LD20 SoC - "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC -- #reset-cells: should be 1. - -Example: - - mioctrl@59810000 { - compatible = "socionext,uniphier-ld11-mioctrl", - "simple-mfd", "syscon"; - reg = <0x59810000 0x800>; - - reset { - compatible = "socionext,uniphier-ld11-mio-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; - - -Peripheral reset ----------------- - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld4-peri-reset" - for LD4 SoC - "socionext,uniphier-pro4-peri-reset" - for Pro4 SoC - "socionext,uniphier-sld8-peri-reset" - for sLD8 SoC - "socionext,uniphier-pro5-peri-reset" - for Pro5 SoC - "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC - "socionext,uniphier-ld11-peri-reset" - for LD11 SoC - "socionext,uniphier-ld20-peri-reset" - for LD20 SoC - "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC -- #reset-cells: should be 1. - -Example: - - perictrl@59820000 { - compatible = "socionext,uniphier-ld11-perictrl", - "simple-mfd", "syscon"; - reg = <0x59820000 0x200>; - - reset { - compatible = "socionext,uniphier-ld11-peri-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; - - -Analog signal amplifier reset ------------------------------ - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld11-adamv-reset" - for LD11 SoC - "socionext,uniphier-ld20-adamv-reset" - for LD20 SoC -- #reset-cells: should be 1. - -Example: - - adamv@57920000 { - compatible = "socionext,uniphier-ld11-adamv", - "simple-mfd", "syscon"; - reg = <0x57920000 0x1000>; - - adamv_rst: reset { - compatible = "socionext,uniphier-ld11-adamv-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; +UniPhier glue reset controller Peripheral core reset in glue layer diff --git a/Documentation/devicetree/bindings/rng/imx-rng.txt b/Documentation/devicetree/bindings/rng/imx-rng.txt index 405c2b00ccb0..659d4efdd664 100644 --- a/Documentation/devicetree/bindings/rng/imx-rng.txt +++ b/Documentation/devicetree/bindings/rng/imx-rng.txt @@ -5,6 +5,9 @@ Required properties: "fsl,imx21-rnga" "fsl,imx31-rnga" (backward compatible with "fsl,imx21-rnga") "fsl,imx25-rngb" + "fsl,imx6sl-rngb" (backward compatible with "fsl,imx25-rngb") + "fsl,imx6sll-rngb" (backward compatible with "fsl,imx25-rngb") + "fsl,imx6ull-rngb" (backward compatible with "fsl,imx25-rngb") "fsl,imx35-rngc" - reg : offset and length of the register set of this block - interrupts : the interrupt number for the RNG block diff --git a/Documentation/devicetree/bindings/rng/ingenic,rng.yaml b/Documentation/devicetree/bindings/rng/ingenic,rng.yaml new file mode 100644 index 000000000000..b2e4a6a7f93a --- /dev/null +++ b/Documentation/devicetree/bindings/rng/ingenic,rng.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/ingenic,rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for RNG in Ingenic SoCs + +maintainers: + - 周琰杰 (Zhou Yanjie) + +description: + The Random Number Generator in Ingenic SoCs. + +properties: + compatible: + enum: + - ingenic,jz4780-rng + - ingenic,x1000-rng + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + rng: rng@d8 { + compatible = "ingenic,jz4780-rng"; + reg = <0xd8 0x8>; + }; +... diff --git a/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml b/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml new file mode 100644 index 000000000000..48ab82abf50e --- /dev/null +++ b/Documentation/devicetree/bindings/rng/silex-insight,ba431-rng.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/silex-insight,ba431-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silex Insight BA431 RNG bindings + +description: | + The BA431 hardware random number generator is an IP that is FIPS-140-2/3 + certified. + +maintainers: + - Olivier Sobrie + +properties: + compatible: + const: silex-insight,ba431-rng + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + rng@42800000 { + compatible = "silex-insight,ba431-rng"; + reg = <0x42800000 0x1000>; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt index 6ae79d1843f3..3f0e2a5950eb 100644 --- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt @@ -1,7 +1,9 @@ Atmel AT91SAM9260 Real Time Timer Required properties: -- compatible: should be: "atmel,at91sam9260-rtt" +- compatible: should be one of the following: + - "atmel,at91sam9260-rtt" + - "microchip,sam9x60-rtt", "atmel,at91sam9260-rtt" - reg: should encode the memory region of the RTT controller - interrupts: rtt alarm/event interrupt - clocks: should contain the 32 KHz slow clk that will drive the RTT block. diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt deleted file mode 100644 index c797bc9d77d2..000000000000 --- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt +++ /dev/null @@ -1,20 +0,0 @@ -* i.MX25 Real Time Clock controller - -Required properties: -- compatible: should be: "fsl,imx25-rtc" -- reg: physical base address of the controller and length of memory mapped - region. -- clocks: should contain the phandle for the rtc clock -- interrupts: rtc alarm interrupt - -Optional properties: -- interrupts: dryice security violation interrupt (second entry) - -Example: - -rtc@53ffc000 { - compatible = "fsl,imx25-rtc"; - reg = <0x53ffc000 0x4000>; - clocks = <&clks 81>; - interrupts = <25 56>; -}; diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml new file mode 100644 index 000000000000..06bd737821c1 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/imxdi-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX25 Real Time Clock controller + +maintainers: + - Roland Stigge + +properties: + compatible: + const: fsl,imx25-rtc + + reg: + maxItems: 1 + + interrupts: + items: + - description: rtc alarm interrupt + - description: dryice security violation interrupt + minItems: 1 + maxItems: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + rtc@53ffc000 { + compatible = "fsl,imx25-rtc"; + reg = <0x53ffc000 0x4000>; + clocks = <&clks 81>; + interrupts = <25>, <56>; + }; diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt deleted file mode 100644 index 968ac820254b..000000000000 --- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Marvell Real Time Clock controller - -Required properties: -- compatible: should be "mrvl,sa1100-rtc" -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: Should be two. The first interrupt number is the rtc alarm - interrupt and the second interrupt number is the rtc hz interrupt. -- interrupt-names: Assign name of irq resource. - -Example: - rtc: rtc@d4010000 { - compatible = "mrvl,mmp-rtc"; - reg = <0xd4010000 0x1000>; - interrupts = <5>, <6>; - interrupt-names = "rtc 1Hz", "rtc alarm"; - }; diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml new file mode 100644 index 000000000000..482e5af215b3 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/sa1100-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Real Time Clock controller bindings + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Alessandro Zummo + - Alexandre Belloni + - Rob Herring + +properties: + compatible: + enum: + - mrvl,sa1100-rtc + - mrvl,mmp-rtc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + minItems: 2 + + interrupt-names: + items: + - const: 'rtc 1Hz' + - const: 'rtc alarm' + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + rtc: rtc@d4010000 { + compatible = "mrvl,mmp-rtc"; + reg = <0xd4010000 0x1000>; + interrupts = <5>, <6>; + interrupt-names = "rtc 1Hz", "rtc alarm"; + }; + +... diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml new file mode 100644 index 000000000000..d226fd7d5258 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/microchip/atmel,at91rm9200-tcb.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Atmel Timer Counter Block + +maintainers: + - Alexandre Belloni + +description: | + The Atmel (now Microchip) SoCs have timers named Timer Counter Block. Each + timer has three channels with two counters each. + +properties: + compatible: + items: + - enum: + - atmel,at91rm9200-tcb + - atmel,at91sam9x5-tcb + - atmel,sama5d2-tcb + - const: simple-mfd + - const: syscon + + reg: + maxItems: 1 + + interrupts: + description: + List of interrupts. One interrupt per TCB channel if available or one + interrupt for the TC block + minItems: 1 + maxItems: 3 + + clock-names: + description: + List of clock names. Always includes t0_clk and slow clk. Also includes + t1_clk and t2_clk if a clock per channel is available. + minItems: 2 + maxItems: 4 + + clocks: + minItems: 2 + maxItems: 4 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^timer@[0-2]$": + description: The timer block channels that are used as timers. + type: object + properties: + compatible: + const: atmel,tcb-timer + reg: + description: + List of channels to use for this particular timer. + minItems: 1 + maxItems: 3 + + required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: atmel,sama5d2-tcb + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: t0_clk + - const: gclk + - const: slow_clk + else: + properties: + clocks: + minItems: 2 + maxItems: 4 + clock-names: + oneOf: + - items: + - const: t0_clk + - const: slow_clk + - items: + - const: t0_clk + - const: t1_clk + - const: t2_clk + - const: slow_clk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + /* One interrupt per TC block: */ + tcb0: timer@fff7c000 { + compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfff7c000 0x100>; + interrupts = <18 4>; + clocks = <&tcb0_clk>, <&clk32k>; + clock-names = "t0_clk", "slow_clk"; + + timer@0 { + compatible = "atmel,tcb-timer"; + reg = <0>, <1>; + }; + + timer@2 { + compatible = "atmel,tcb-timer"; + reg = <2>; + }; + }; + + /* One interrupt per TC channel in a TC block: */ + tcb1: timer@fffdc000 { + compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfffdc000 0x100>; + interrupts = <26 4>, <27 4>, <28 4>; + clocks = <&tcb1_clk>, <&clk32k>; + clock-names = "t0_clk", "slow_clk"; + + timer@0 { + compatible = "atmel,tcb-timer"; + reg = <0>; + }; + + timer@1 { + compatible = "atmel,tcb-timer"; + reg = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt deleted file mode 100644 index 616fddcd09fd..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt +++ /dev/null @@ -1,62 +0,0 @@ -Qualcomm Resource Power Manager (RPM) over SMD - -This driver is used to interface with the Resource Power Manager (RPM) found in -various Qualcomm platforms. The RPM allows each component in the system to vote -for state of the system resources, such as clocks, regulators and bus -frequencies. - -The SMD information for the RPM edge should be filled out. See qcom,smd.txt for -the required edge properties. All SMD related properties will reside within the -RPM node itself. - -= SUBDEVICES - -The RPM exposes resources to its subnodes. The rpm_requests node must be -present and this subnode may contain children that designate regulator -resources. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,rpm-apq8084" - "qcom,rpm-msm8916" - "qcom,rpm-msm8974" - "qcom,rpm-msm8976" - "qcom,rpm-msm8998" - "qcom,rpm-sdm660" - "qcom,rpm-qcs404" - -- qcom,smd-channels: - Usage: required - Value type: - Definition: must be "rpm_requests" - -Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt -for information on the regulator subnodes that can exist under the rpm_requests. - -Example: - - soc { - apcs: syscon@f9011000 { - compatible = "syscon"; - reg = <0xf9011000 0x1000>; - }; - }; - - smd { - compatible = "qcom,smd"; - - rpm { - interrupts = <0 168 1>; - qcom,ipc = <&apcs 8 0>; - qcom,smd-edge = <15>; - - rpm_requests { - compatible = "qcom,rpm-msm8974"; - qcom,smd-channels = "rpm_requests"; - - ... - }; - }; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml new file mode 100644 index 000000000000..468d658ce3e7 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Resource Power Manager (RPM) over SMD + +description: | + This driver is used to interface with the Resource Power Manager (RPM) found + in various Qualcomm platforms. The RPM allows each component in the system + to vote for state of the system resources, such as clocks, regulators and bus + frequencies. + + The SMD information for the RPM edge should be filled out. See qcom,smd.txt + for the required edge properties. All SMD related properties will reside + within the RPM node itself. + + The RPM exposes resources to its subnodes. The rpm_requests node must be + present and this subnode may contain children that designate regulator + resources. + + Refer to Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.txt + for information on the regulator subnodes that can exist under the + rpm_requests. + +maintainers: + - Kathiravan T + +properties: + compatible: + enum: + - qcom,rpm-apq8084 + - qcom,rpm-ipq6018 + - qcom,rpm-msm8916 + - qcom,rpm-msm8974 + - qcom,rpm-msm8976 + - qcom,rpm-msm8996 + - qcom,rpm-msm8998 + - qcom,rpm-sdm660 + - qcom,rpm-qcs404 + + qcom,smd-channels: + $ref: /schemas/types.yaml#/definitions/string-array + description: Channel name used for the RPM communication + items: + - const: rpm_requests + +if: + properties: + compatible: + contains: + enum: + - qcom,rpm-apq8084 + - qcom,rpm-msm8916 + - qcom,rpm-msm8974 +then: + required: + - qcom,smd-channels + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include + #include + + smd { + compatible = "qcom,smd"; + + rpm { + interrupts = ; + qcom,ipc = <&apcs 8 0>; + qcom,smd-edge = <15>; + + rpm_requests { + compatible = "qcom,rpm-msm8974"; + qcom,smd-channels = "rpm_requests"; + + /* Regulator nodes to follow */ + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt deleted file mode 100644 index 59758ccce809..000000000000 --- a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt +++ /dev/null @@ -1,59 +0,0 @@ -* Texas Instruments K3 NavigatorSS Ring Accelerator - -The Ring Accelerator (RA) is a machine which converts read/write accesses -from/to a constant address into corresponding read/write accesses from/to a -circular data structure in memory. The RA eliminates the need for each DMA -controller which needs to access ring elements from having to know the current -state of the ring (base address, current offset). The DMA controller -performs a read or write access to a specific address range (which maps to the -source interface on the RA) and the RA replaces the address for the transaction -with a new address which corresponds to the head or tail element of the ring -(head for reads, tail for writes). - -The Ring Accelerator is a hardware module that is responsible for accelerating -management of the packet queues. The K3 SoCs can have more than one RA instances - -Required properties: -- compatible : Must be "ti,am654-navss-ringacc"; -- reg : Should contain register location and length of the following - named register regions. -- reg-names : should be - "rt" - The RA Ring Real-time Control/Status Registers - "fifos" - The RA Queues Registers - "proxy_gcfg" - The RA Proxy Global Config Registers - "proxy_target" - The RA Proxy Datapath Registers -- ti,num-rings : Number of rings supported by RA -- ti,sci-rm-range-gp-rings : TI-SCI RM subtype for GP ring range -- ti,sci : phandle on TI-SCI compatible System controller node -- ti,sci-dev-id : TI-SCI device id of the ring accelerator -- msi-parent : phandle for "ti,sci-inta" interrupt controller - -Optional properties: - -- ti,dma-ring-reset-quirk : enable ringacc / udma ring state interoperability - issue software w/a - -Example: - -ringacc: ringacc@3c000000 { - compatible = "ti,am654-navss-ringacc"; - reg = <0x0 0x3c000000 0x0 0x400000>, - <0x0 0x38000000 0x0 0x400000>, - <0x0 0x31120000 0x0 0x100>, - <0x0 0x33000000 0x0 0x40000>; - reg-names = "rt", "fifos", - "proxy_gcfg", "proxy_target"; - ti,num-rings = <818>; - ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */ - ti,dma-ring-reset-quirk; - ti,sci = <&dmsc>; - ti,sci-dev-id = <187>; - msi-parent = <&inta_main_udmass>; -}; - -client: - -dma_ipx: dma_ipx@ { - ... - ti,ringacc = <&ringacc>; - ... -} diff --git a/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml new file mode 100644 index 000000000000..ae33fc957141 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/ti/k3-ringacc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments K3 NavigatorSS Ring Accelerator + +maintainers: + - Santosh Shilimkar + - Grygorii Strashko + +description: | + The Ring Accelerator (RA) is a machine which converts read/write accesses + from/to a constant address into corresponding read/write accesses from/to a + circular data structure in memory. The RA eliminates the need for each DMA + controller which needs to access ring elements from having to know the current + state of the ring (base address, current offset). The DMA controller + performs a read or write access to a specific address range (which maps to the + source interface on the RA) and the RA replaces the address for the transaction + with a new address which corresponds to the head or tail element of the ring + (head for reads, tail for writes). + + The Ring Accelerator is a hardware module that is responsible for accelerating + management of the packet queues. The K3 SoCs can have more than one RA instances + +properties: + compatible: + items: + - const: ti,am654-navss-ringacc + + reg: + items: + - description: real time registers regions + - description: fifos registers regions + - description: proxy gcfg registers regions + - description: proxy target registers regions + + reg-names: + items: + - const: rt + - const: fifos + - const: proxy_gcfg + - const: proxy_target + + msi-parent: true + + ti,num-rings: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of rings supported by RA + + ti,sci-rm-range-gp-rings: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TI-SCI RM subtype for GP ring range + + ti,sci: + $ref: /schemas/types.yaml#definitions/phandle-array + description: phandle on TI-SCI compatible System controller node + + ti,sci-dev-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TI-SCI device id of the ring accelerator + + ti,dma-ring-reset-quirk: + $ref: /schemas/types.yaml#definitions/flag + description: | + enable ringacc/udma ring state interoperability issue software w/a + +required: + - compatible + - reg + - reg-names + - msi-parent + - ti,num-rings + - ti,sci-rm-range-gp-rings + - ti,sci + - ti,sci-dev-id + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + ringacc: ringacc@3c000000 { + compatible = "ti,am654-navss-ringacc"; + reg = <0x0 0x3c000000 0x0 0x400000>, + <0x0 0x38000000 0x0 0x400000>, + <0x0 0x31120000 0x0 0x100>, + <0x0 0x33000000 0x0 0x40000>; + reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target"; + ti,num-rings = <818>; + ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */ + ti,dma-ring-reset-quirk; + ti,sci = <&dmsc>; + ti,sci-dev-id = <187>; + msi-parent = <&inta_main_udmass>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt index f11f295c8450..3d55dd64b1be 100644 --- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt +++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt @@ -5,7 +5,8 @@ SPI0, and the other known as the "Universal SPI Master"; part of the auxiliary block. This binding applies to the SPI0 controller. Required properties: -- compatible: Should be "brcm,bcm2835-spi". +- compatible: Should be one of "brcm,bcm2835-spi" for BCM2835/2836/2837 or + "brcm,bcm2711-spi" for BCM2711 or "brcm,bcm7211-spi" for BCM7211. - reg: Should contain register location and length. - interrupts: Should contain interrupt. - clocks: The clock feeding the SPI controller. diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt deleted file mode 100644 index 33bc58f4cf4b..000000000000 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt +++ /dev/null @@ -1,56 +0,0 @@ -* Freescale (Enhanced) Configurable Serial Peripheral Interface - (CSPI/eCSPI) for i.MX - -Required properties: -- compatible : - - "fsl,imx1-cspi" for SPI compatible with the one integrated on i.MX1 - - "fsl,imx21-cspi" for SPI compatible with the one integrated on i.MX21 - - "fsl,imx27-cspi" for SPI compatible with the one integrated on i.MX27 - - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31 - - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 - - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51 - - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and later Soc - - "fsl,imx8mq-ecspi" for SPI compatible with the one integrated on i.MX8MQ - - "fsl,imx8mm-ecspi" for SPI compatible with the one integrated on i.MX8MM - - "fsl,imx8mn-ecspi" for SPI compatible with the one integrated on i.MX8MN - - "fsl,imx8mp-ecspi" for SPI compatible with the one integrated on i.MX8MP -- reg : Offset and length of the register set for the device -- interrupts : Should contain CSPI/eCSPI interrupt -- clocks : Clock specifiers for both ipg and per clocks. -- clock-names : Clock names should include both "ipg" and "per" -See the clock consumer binding, - Documentation/devicetree/bindings/clock/clock-bindings.txt - -Recommended properties: -- cs-gpios : GPIOs to use as chip selects, see spi-bus.txt. While the native chip -select lines can be used, they appear to always generate a pulse between each -word of a transfer. Most use cases will require GPIO based chip selects to -generate a valid transaction. - -Optional properties: -- num-cs : Number of total chip selects, see spi-bus.txt. -- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, -Documentation/devicetree/bindings/dma/dma.txt. -- dma-names: DMA request names, if present, should include "tx" and "rx". -- fsl,spi-rdy-drctl: Integer, representing the value of DRCTL, the register -controlling the SPI_READY handling. Note that to enable the DRCTL consideration, -the SPI_READY mode-flag needs to be set too. -Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 (level-triggered burst). - -Obsolete properties: -- fsl,spi-num-chipselects : Contains the number of the chipselect - -Example: - -ecspi@70010000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,imx51-ecspi"; - reg = <0x70010000 0x4000>; - interrupts = <36>; - cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */ - <&gpio3 25 0>; /* GPIO3_25 */ - dmas = <&sdma 3 7 1>, <&sdma 4 7 2>; - dma-names = "rx", "tx"; - fsl,spi-rdy-drctl = <1>; -}; diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml new file mode 100644 index 000000000000..6e44c9c2aeba --- /dev/null +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/fsl-imx-cspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale (Enhanced) Configurable Serial Peripheral Interface (CSPI/eCSPI) for i.MX + +maintainers: + - Shawn Guo + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + oneOf: + - const: fsl,imx1-cspi + - const: fsl,imx21-cspi + - const: fsl,imx27-cspi + - const: fsl,imx31-cspi + - const: fsl,imx35-cspi + - const: fsl,imx51-ecspi + - const: fsl,imx53-ecspi + - items: + - enum: + - fsl,imx50-ecspi + - fsl,imx6q-ecspi + - fsl,imx6sx-ecspi + - fsl,imx6sl-ecspi + - fsl,imx6sll-ecspi + - fsl,imx6ul-ecspi + - fsl,imx7d-ecspi + - fsl,imx8mq-ecspi + - fsl,imx8mm-ecspi + - fsl,imx8mn-ecspi + - fsl,imx8mp-ecspi + - const: fsl,imx51-ecspi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SoC SPI ipg clock + - description: SoC SPI per clock + + clock-names: + items: + - const: ipg + - const: per + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + + fsl,spi-rdy-drctl: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Integer, representing the value of DRCTL, the register controlling + the SPI_READY handling. Note that to enable the DRCTL consideration, + the SPI_READY mode-flag needs to be set too. + Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 (level-triggered burst). + enum: [0, 1, 2] + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include + + spi@70010000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx51-ecspi"; + reg = <0x70010000 0x4000>; + interrupts = <36>; + clocks = <&clks IMX5_CLK_ECSPI1_IPG_GATE>, + <&clks IMX5_CLK_ECSPI1_PER_GATE>; + clock-names = "ipg", "per"; + }; diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.txt b/Documentation/devicetree/bindings/spi/mxs-spi.txt deleted file mode 100644 index 3499b73293c2..000000000000 --- a/Documentation/devicetree/bindings/spi/mxs-spi.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Freescale MX233/MX28 SSP/SPI - -Required properties: -- compatible: Should be "fsl,-spi", where soc is "imx23" or "imx28" -- reg: Offset and length of the register set for the device -- interrupts: Should contain SSP ERROR interrupt -- dmas: DMA specifier, consisting of a phandle to DMA controller node - and SSP DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. -- dma-names: Must be "rx-tx". - -Optional properties: -- clock-frequency : Input clock frequency to the SPI block in Hz. - Default is 160000000 Hz. - -Example: - -ssp0: ssp@80010000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,imx28-spi"; - reg = <0x80010000 0x2000>; - interrupts = <96>; - dmas = <&dma_apbh 0>; - dma-names = "rx-tx"; -}; diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.yaml b/Documentation/devicetree/bindings/spi/mxs-spi.yaml new file mode 100644 index 000000000000..51f8c664323e --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mxs-spi.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mxs-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MX233/MX28 SSP/SPI + +maintainers: + - Marek Vasut + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + enum: + - fsl,imx23-spi + - fsl,imx28-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + + clock-frequency: + description: input clock frequency to the SPI block in Hz. + default: 160000000 + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + spi@80010000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx28-spi"; + reg = <0x80010000 0x2000>; + interrupts = <96>; + dmas = <&dma_apbh 0>; + dma-names = "rx-tx"; + }; diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml index e84edcf8b332..9f7b118adcaf 100644 --- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml @@ -21,6 +21,7 @@ properties: # device - items: - enum: + - renesas,msiof-r8a7742 # RZ/G1H - renesas,msiof-r8a7743 # RZ/G1M - renesas,msiof-r8a7744 # RZ/G1N - renesas,msiof-r8a7745 # RZ/G1E @@ -37,6 +38,7 @@ properties: - renesas,msiof-r8a774a1 # RZ/G2M - renesas,msiof-r8a774b1 # RZ/G2N - renesas,msiof-r8a774c0 # RZ/G2E + - renesas,msiof-r8a774e1 # RZ/G2H - renesas,msiof-r8a7795 # R-Car H3 - renesas,msiof-r8a7796 # R-Car M3-W - renesas,msiof-r8a77965 # R-Car M3-N diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index 9f5b4c7c0c08..e2198a389484 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -1,8 +1,8 @@ Davinci SPI controller device bindings Links on DM: -Keystone 2 - http://www.ti.com/lit/ug/sprugp2a/sprugp2a.pdf -dm644x - http://www.ti.com/lit/ug/sprue32a/sprue32a.pdf +Keystone 2 - https://www.ti.com/lit/ug/sprugp2a/sprugp2a.pdf +dm644x - https://www.ti.com/lit/ug/sprue32a/sprue32a.pdf OMAP-L138/da830 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf Required properties: diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt deleted file mode 100644 index e71b81a41ac0..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt +++ /dev/null @@ -1,29 +0,0 @@ -* Freescale Low Power SPI (LPSPI) for i.MX - -Required properties: -- compatible : - - "fsl,imx7ulp-spi" for LPSPI compatible with the one integrated on i.MX7ULP soc - - "fsl,imx8qxp-spi" for LPSPI compatible with the one integrated on i.MX8QXP soc -- reg : address and length of the lpspi master registers -- interrupt-parent : core interrupt controller -- interrupts : lpspi interrupt -- clocks : lpspi clock specifier. Its number and order need to correspond to the - value in clock-names. -- clock-names : Corresponding to per clock and ipg clock in "clocks" - respectively. In i.MX7ULP, it only has per clk, so use CLK_DUMMY - to fill the "ipg" blank. -- spi-slave : spi slave mode support. In slave mode, add this attribute without - value. In master mode, remove it. - -Examples: - -lpspi2: lpspi@40290000 { - compatible = "fsl,imx7ulp-spi"; - reg = <0x40290000 0x10000>; - interrupt-parent = <&intc>; - interrupts = ; - clocks = <&clks IMX7ULP_CLK_LPSPI2>, - <&clks IMX7ULP_CLK_DUMMY>; - clock-names = "per", "ipg"; - spi-slave; -}; diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml new file mode 100644 index 000000000000..22882e769e26 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-fsl-lpspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Low Power SPI (LPSPI) for i.MX + +maintainers: + - Anson Huang + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + enum: + - fsl,imx7ulp-spi + - fsl,imx8qxp-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: SoC SPI per clock + - description: SoC SPI ipg clock + + clock-names: + items: + - const: per + - const: ipg + + fsl,spi-only-use-cs1-sel: + description: + spi common code does not support use of CS signals discontinuously. + i.MX8DXL-EVK board only uses CS1 without using CS0. Therefore, add + this property to re-config the chipselect value in the LPSPI driver. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include + #include + + spi@40290000 { + compatible = "fsl,imx7ulp-spi"; + reg = <0x40290000 0x10000>; + interrupt-parent = <&intc>; + interrupts = ; + clocks = <&clks IMX7ULP_CLK_LPSPI2>, + <&clks IMX7ULP_CLK_DUMMY>; + clock-names = "per", "ipg"; + spi-slave; + fsl,spi-only-use-cs1-sel; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-lantiq-ssc.txt b/Documentation/devicetree/bindings/spi/spi-lantiq-ssc.txt index ce3230c8e28d..76a3dd35f796 100644 --- a/Documentation/devicetree/bindings/spi/spi-lantiq-ssc.txt +++ b/Documentation/devicetree/bindings/spi/spi-lantiq-ssc.txt @@ -1,11 +1,17 @@ Lantiq Synchronous Serial Controller (SSC) SPI master driver Required properties: -- compatible: "lantiq,ase-spi", "lantiq,falcon-spi", "lantiq,xrx100-spi" +- compatible: "lantiq,ase-spi", "lantiq,falcon-spi", "lantiq,xrx100-spi", + "intel,lgm-spi" - #address-cells: see spi-bus.txt - #size-cells: see spi-bus.txt - reg: address and length of the spi master registers -- interrupts: should contain the "spi_rx", "spi_tx" and "spi_err" interrupt. +- interrupts: + For compatible "intel,lgm-ssc" - the common interrupt number for + all of tx rx & err interrupts. + or + For rest of the compatibles, should contain the "spi_rx", "spi_tx" and + "spi_err" interrupt. Optional properties: @@ -27,3 +33,14 @@ spi: spi@e100800 { num-cs = <6>; base-cs = <1>; }; + +ssc0: spi@e0800000 { + compatible = "intel,lgm-spi"; + reg = <0xe0800000 0x400>; + interrupt-parent = <&ioapic1>; + interrupts = <35 1>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cgu0 LGM_CLK_NGI>, <&cgu0 LGM_GCLK_SSC0>; + clock-names = "freq", "gate"; +}; diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index 3a8079eb18c8..9e43721fa7d6 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -11,6 +11,7 @@ Required properties: - mediatek,mt8135-spi: for mt8135 platforms - mediatek,mt8173-spi: for mt8173 platforms - mediatek,mt8183-spi: for mt8183 platforms + - "mediatek,mt8192-spi", "mediatek,mt6765-spi": for mt8192 platforms - "mediatek,mt8516-spi", "mediatek,mt2712-spi": for mt8516 platforms - #address-cells: should be 1. diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index d7be931b42d2..adac01c9d9cd 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: QCOM SoC Temperature Sensor (TSENS) maintainers: - - Amit Kucheria + - Amit Kucheria description: | QCOM SoCs have TSENS IP to allow temperature measurement. There are currently @@ -40,6 +40,8 @@ properties: - qcom,msm8998-tsens - qcom,sc7180-tsens - qcom,sdm845-tsens + - qcom,sm8150-tsens + - qcom,sm8250-tsens - const: qcom,tsens-v2 reg: diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt deleted file mode 100644 index 28f2cbaf1702..000000000000 --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt +++ /dev/null @@ -1,71 +0,0 @@ -* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs - -Required properties: -- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The - version of the device is determined by the TMU IP Block Revision - Register (IPBRR0) at offset 0x0BF8. - Table of correspondences between IPBRR0 values and example chips: - Value Device - ---------- ----- - 0x01900102 T1040 -- reg : Address range of TMU registers. -- interrupts : Contains the interrupt for TMU. -- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by - the SoC reference manual. The first cell is TTR0CR, the second is - TTR1CR, etc. -- fsl,tmu-calibration : A list of cell pairs containing temperature - calibration data, as specified by the SoC reference manual. - The first cell of each pair is the value to be written to TTCFGR, - and the second is the value to be written to TSCFGR. -- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring - site ID, and represents the "n" in TRITSRn and TRATSRn. - -Optional property: -- little-endian : If present, the TMU registers are little endian. If absent, - the default is big endian. -- clocks : the clock for clocking the TMU silicon. - -Example: - -tmu@f0000 { - compatible = "fsl,qoriq-tmu"; - reg = <0xf0000 0x1000>; - interrupts = <18 2 0 0>; - fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>; - fsl,tmu-calibration = <0x00000000 0x00000025 - 0x00000001 0x00000028 - 0x00000002 0x0000002d - 0x00000003 0x00000031 - 0x00000004 0x00000036 - 0x00000005 0x0000003a - 0x00000006 0x00000040 - 0x00000007 0x00000044 - 0x00000008 0x0000004a - 0x00000009 0x0000004f - 0x0000000a 0x00000054 - - 0x00010000 0x0000000d - 0x00010001 0x00000013 - 0x00010002 0x00000019 - 0x00010003 0x0000001f - 0x00010004 0x00000025 - 0x00010005 0x0000002d - 0x00010006 0x00000033 - 0x00010007 0x00000043 - 0x00010008 0x0000004b - 0x00010009 0x00000053 - - 0x00020000 0x00000010 - 0x00020001 0x00000017 - 0x00020002 0x0000001f - 0x00020003 0x00000029 - 0x00020004 0x00000031 - 0x00020005 0x0000003c - 0x00020006 0x00000042 - 0x00020007 0x0000004d - 0x00020008 0x00000056 - - 0x00030000 0x00000012 - 0x00030001 0x0000001d>; - #thermal-sensor-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml new file mode 100644 index 000000000000..f09e8723ca2b --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs + +maintainers: + - Anson Huang + +properties: + compatible: + description: | + The version of the device is determined by the TMU IP Block Revision + Register (IPBRR0) at offset 0x0BF8. + Table of correspondences between IPBRR0 values and example chips: + Value Device + ---------- ----- + 0x01900102 T1040 + enum: + - fsl,qoriq-tmu + - fsl,imx8mq-tmu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,tmu-range: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + description: | + The values to be programmed into TTRnCR, as specified by the SoC + reference manual. The first cell is TTR0CR, the second is TTR1CR, etc. + maxItems: 4 + + fsl,tmu-calibration: + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' + description: | + A list of cell pairs containing temperature calibration data, as + specified by the SoC reference manual. The first cell of each pair + is the value to be written to TTCFGR, and the second is the value + to be written to TSCFGR. + items: + items: + - description: value for TTCFGR + - description: value for TSCFGR + minItems: 1 + maxItems: 64 + + little-endian: + description: | + boolean, if present, the TMU registers are little endian. If absent, + the default is big endian. + type: boolean + + clocks: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - fsl,tmu-range + - fsl,tmu-calibration + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + tmu@f0000 { + compatible = "fsl,qoriq-tmu"; + reg = <0xf0000 0x1000>; + interrupts = <18 2 0 0>; + fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>; + fsl,tmu-calibration = <0x00000000 0x00000025>, + <0x00000001 0x00000028>, + <0x00000002 0x0000002d>, + <0x00000003 0x00000031>, + <0x00000004 0x00000036>, + <0x00000005 0x0000003a>, + <0x00000006 0x00000040>, + <0x00000007 0x00000044>, + <0x00000008 0x0000004a>, + <0x00000009 0x0000004f>, + <0x0000000a 0x00000054>, + <0x00010000 0x0000000d>, + <0x00010001 0x00000013>, + <0x00010002 0x00000019>, + <0x00010003 0x0000001f>, + <0x00010004 0x00000025>, + <0x00010005 0x0000002d>, + <0x00010006 0x00000033>, + <0x00010007 0x00000043>, + <0x00010008 0x0000004b>, + <0x00010009 0x00000053>, + <0x00020000 0x00000010>, + <0x00020001 0x00000017>, + <0x00020002 0x0000001f>, + <0x00020003 0x00000029>, + <0x00020004 0x00000031>, + <0x00020005 0x0000003c>, + <0x00020006 0x00000042>, + <0x00020007 0x0000004d>, + <0x00020008 0x00000056>, + <0x00030000 0x00000012>, + <0x00030001 0x0000001d>; + #thermal-sensor-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml new file mode 100644 index 000000000000..df3eb76045e0 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/ingenic,sysost.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/ingenic,sysost.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for SYSOST in Ingenic XBurst family SoCs + +maintainers: + - 周琰杰 (Zhou Yanjie) + +description: + The SYSOST in an Ingenic SoC provides one 64bit timer for clocksource + and one or more 32bit timers for clockevent. + +properties: + "#clock-cells": + const: 1 + + compatible: + enum: + - ingenic,x1000-ost + - ingenic,x2000-ost + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ost + + interrupts: + maxItems: 1 + +required: + - "#clock-cells" + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include + + ost: timer@12000000 { + compatible = "ingenic,x1000-ost"; + reg = <0x12000000 0x3c>; + + #clock-cells = <1>; + + clocks = <&cgu X1000_CLK_OST>; + clock-names = "ost"; + + interrupt-parent = <&cpuintc>; + interrupts = <3>; + }; +... diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt deleted file mode 100644 index b8f02c663521..000000000000 --- a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Marvell MMP Timer controller - -Required properties: -- compatible : Should be "mrvl,mmp-timer". -- reg : Address and length of the register set of timer controller. -- interrupts : Should be the interrupt number. - -Optional properties: -- clocks : Should contain a single entry describing the clock input. - -Example: - timer0: timer@d4014000 { - compatible = "mrvl,mmp-timer"; - reg = <0xd4014000 0x100>; - interrupts = <13>; - clocks = <&coreclk 2>; - }; diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml new file mode 100644 index 000000000000..1fbc260a0cbd --- /dev/null +++ b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/mrvl,mmp-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP Timer bindings + +maintainers: + - Daniel Lezcano + - Thomas Gleixner + - Rob Herring + +properties: + $nodename: + pattern: '^timer@[a-f0-9]+$' + + compatible: + const: mrvl,mmp-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + timer@d4014000 { + compatible = "mrvl,mmp-timer"; + reg = <0xd4014000 0x100>; + interrupts = <13>; + clocks = <&coreclk 2>; + }; + +... diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt index 5fbe361252b4..d3905a5412b8 100644 --- a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt +++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt @@ -10,7 +10,7 @@ It is global timer is a free running up-counter and can generate interrupt when the counter reaches preset counter values. Documentation: -http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf +https://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf Required properties: diff --git a/Documentation/devicetree/bindings/usb/brcm,bdc.txt b/Documentation/devicetree/bindings/usb/brcm,bdc.txt index 63e63af3bf59..c9f52b97cef1 100644 --- a/Documentation/devicetree/bindings/usb/brcm,bdc.txt +++ b/Documentation/devicetree/bindings/usb/brcm,bdc.txt @@ -4,7 +4,7 @@ Broadcom USB Device Controller (BDC) Required properties: - compatible: must be one of: - "brcm,bdc-v0.16" + "brcm,bdc-udc-v2" "brcm,bdc" - reg: the base register address and length - interrupts: the interrupt line for this controller @@ -21,7 +21,7 @@ On Broadcom STB platforms, these properties are required: Example: bdc@f0b02000 { - compatible = "brcm,bdc-v0.16"; + compatible = "brcm,bdc-udc-v2"; reg = <0xf0b02000 0xfc4>; interrupts = <0x0 0x60 0x0>; phys = <&usbphy_0 0x0>; diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 9352a8ef60a6..4ff632d82858 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -44,7 +44,9 @@ properties: - const: st,stm32f4x9-hsotg - const: st,stm32f7-hsotg - const: st,stm32mp15-fsotg - - const: st,stm32mp15-hsotg + - items: + - const: st,stm32mp15-hsotg + - const: snps,dwc2 - const: samsung,s3c6400-hsotg reg: @@ -93,7 +95,7 @@ properties: vusb_a-supply: description: phandle to voltage regulator of analog section. - vusb33d-supply: + usb33d-supply: description: reference to the VBUS and ID sensing comparators supply, in order to perform OTG operation, used on STM32MP15 SoCs. diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml index a81b0b1a2226..2d61166ea5cf 100644 --- a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml +++ b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml @@ -4,10 +4,11 @@ $id: http://devicetree.org/schemas/usb/ingenic,jz4770-phy.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ingenic JZ4770 USB PHY devicetree bindings +title: Ingenic SoCs USB PHY devicetree bindings maintainers: - Paul Cercueil + - 周琰杰 (Zhou Yanjie) properties: $nodename: @@ -16,6 +17,9 @@ properties: compatible: enum: - ingenic,jz4770-phy + - ingenic,jz4780-phy + - ingenic,x1000-phy + - ingenic,x1830-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml new file mode 100644 index 000000000000..add9f7b66da0 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/renesas,usb-xhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas USB xHCI controllers + +maintainers: + - Lad Prabhakar + - Yoshihiro Shimoda + +allOf: + - $ref: "usb-hcd.yaml" + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,xhci-r8a7742 # RZ/G1H + - renesas,xhci-r8a7743 # RZ/G1M + - renesas,xhci-r8a7744 # RZ/G1N + - renesas,xhci-r8a7790 # R-Car H2 + - renesas,xhci-r8a7791 # R-Car M2-W + - renesas,xhci-r8a7793 # R-Car M2-N + - const: renesas,rcar-gen2-xhci # R-Car Gen2 and RZ/G1 + - items: + - enum: + - renesas,xhci-r8a774a1 # RZ/G2M + - renesas,xhci-r8a774b1 # RZ/G2N + - renesas,xhci-r8a774c0 # RZ/G2E + - renesas,xhci-r8a7795 # R-Car H3 + - renesas,xhci-r8a7796 # R-Car M3-W + - renesas,xhci-r8a77961 # R-Car M3-W+ + - renesas,xhci-r8a77965 # R-Car M3-N + - renesas,xhci-r8a77990 # R-Car E3 + - const: renesas,rcar-gen3-xhci # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + maxItems: 1 + items: + - const: usb + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include + #include + #include + + xhci0: usb@ee000000 { + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; + reg = <0xee000000 0xc00>; + interrupts = ; + clocks = <&cpg CPG_MOD 328>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 328>; + }; diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index f127535feb0b..804b9b4f6654 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -11,22 +11,36 @@ maintainers: properties: compatible: - oneOf: - - const: "ti,keystone-dwc3" - - const: "ti,am654-dwc3" + items: + - enum: + - ti,keystone-dwc3 + - ti,am654-dwc3 reg: maxItems: 1 - description: Address and length of the register set for the USB subsystem on - the SOC. + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true interrupts: maxItems: 1 - description: The irq number of this device that is used to interrupt the MPU. - clocks: - description: Clock ID for USB functional clock. + minItems: 1 + maxItems: 2 + + assigned-clocks: + minItems: 1 + maxItems: 2 + + assigned-clock-parents: + minItems: 1 + maxItems: 2 power-domains: description: Should contain a phandle to a PM domain provider node @@ -42,33 +56,42 @@ properties: phy-names: items: - - const: "usb3-phy" + - const: usb3-phy - dwc3: + dma-coherent: true + + dma-ranges: true + +patternProperties: + "usb@[a-f0-9]+$": + type: object description: This is the node representing the DWC3 controller instance Documentation/devicetree/bindings/usb/dwc3.txt required: - compatible - reg + - "#address-cells" + - "#size-cells" + - ranges - interrupts - - clocks + +additionalProperties: false examples: - | #include - usb: usb@2680000 { + dwc3@2680000 { compatible = "ti,keystone-dwc3"; #address-cells = <1>; #size-cells = <1>; reg = <0x2680000 0x10000>; clocks = <&clkusb>; - clock-names = "usb"; interrupts = ; ranges; - dwc3@2690000 { + usb@2690000 { compatible = "synopsys,dwc3"; reg = <0x2690000 0x70000>; interrupts = ; diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index b120dd6612a2..0c5cff84a969 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -7,24 +7,6 @@ Required properties: - "marvell,armada3700-xhci" for Armada 37xx SoCs - "marvell,armada-375-xhci" for Armada 375 SoCs - "marvell,armada-380-xhci" for Armada 38x SoCs - - "renesas,xhci-r8a7742" for r8a7742 SoC - - "renesas,xhci-r8a7743" for r8a7743 SoC - - "renesas,xhci-r8a7744" for r8a7744 SoC - - "renesas,xhci-r8a774a1" for r8a774a1 SoC - - "renesas,xhci-r8a774b1" for r8a774b1 SoC - - "renesas,xhci-r8a774c0" for r8a774c0 SoC - - "renesas,xhci-r8a7790" for r8a7790 SoC - - "renesas,xhci-r8a7791" for r8a7791 SoC - - "renesas,xhci-r8a7793" for r8a7793 SoC - - "renesas,xhci-r8a7795" for r8a7795 SoC - - "renesas,xhci-r8a7796" for r8a77960 SoC - - "renesas,xhci-r8a77961" for r8a77961 SoC - - "renesas,xhci-r8a77965" for r8a77965 SoC - - "renesas,xhci-r8a77990" for r8a77990 SoC - - "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 or RZ/G1 compatible - device - - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 or RZ/G2 compatible - device - "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI - "xhci-platform" (deprecated) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9aeab66be85f..f4dec98d6eba 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -23,10 +23,14 @@ patternProperties: "^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true # Keep list in alphabetical order. + "^70mai,.*": + description: 70mai Co., Ltd. "^abilis,.*": description: Abilis Systems "^abracon,.*": description: Abracon Corporation + "^acer,.*": + description: Acer Inc. "^acme,.*": description: Acme Systems srl "^actions,.*": @@ -680,6 +684,8 @@ patternProperties: description: Microsemi Corporation "^msi,.*": description: Micro-Star International Co. Ltd. + "^mstar,.*": + description: MStar Semiconductor, Inc. (acquired by MediaTek Inc.) "^mti,.*": description: Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) "^multi-inno,.*": @@ -984,6 +990,8 @@ patternProperties: description: Spreadtrum Communications Inc. "^sst,.*": description: Silicon Storage Technology, Inc. + "^sstar,.*": + description: Xiamen Xingchen(SigmaStar) Technology Co., Ltd. (formerly part of MStar Semiconductor, Inc.) "^st,.*": description: STMicroelectronics "^starry,.*": @@ -1032,6 +1040,8 @@ patternProperties: description: Three Five Corp "^thine,.*": description: THine Electronics, Inc. + "^thingyjp,.*": + description: thingy.jp "^ti,.*": description: Texas Instruments "^tianma,.*": @@ -1157,6 +1167,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": + description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt index 21af30fbb81f..0a575f329f6e 100644 --- a/Documentation/devicetree/bindings/virtio/mmio.txt +++ b/Documentation/devicetree/bindings/virtio/mmio.txt @@ -1,6 +1,6 @@ * virtio memory mapped device -See http://ozlabs.org/~rusty/virtio-spec/ for more details. +See https://ozlabs.org/~rusty/virtio-spec/ for more details. Required properties: diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.rst similarity index 90% rename from Documentation/devicetree/booting-without-of.txt rename to Documentation/devicetree/booting-without-of.rst index 4660ccee35a3..e9433350a20f 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.rst @@ -1,15 +1,19 @@ - Booting the Linux/ppc kernel without Open Firmware - -------------------------------------------------- +.. SPDX-License-Identifier: GPL-2.0 -(c) 2005 Benjamin Herrenschmidt , - IBM Corp. -(c) 2005 Becky Bruce , - Freescale Semiconductor, FSL SOC and 32-bit additions -(c) 2006 MontaVista Software, Inc. - Flash chip node definition +================================================== +Booting the Linux/ppc kernel without Open Firmware +================================================== -Table of Contents -================= +Copyright (c) 2005 Benjamin Herrenschmidt , +IBM Corp. + +Copyright (c) 2005 Becky Bruce , +Freescale Semiconductor, FSL SOC and 32-bit additions + +Copyright (c) 2006 MontaVista Software, Inc. +Flash chip node definition + +.. Table of Contents I - Introduction 1) Entry point for arch/arm @@ -61,15 +65,18 @@ Table of Contents Revision Information ==================== - May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet. + May 18, 2005: Rev 0.1 + - Initial draft, no chapter III yet. - May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or + May 19, 2005: Rev 0.2 + - Add chapter III and bits & pieces here or clarifies the fact that a lot of things are optional, the kernel only requires a very small device tree, though it is encouraged to provide an as complete one as possible. - May 24, 2005: Rev 0.3 - Precise that DT block has to be in RAM + May 24, 2005: Rev 0.3 + - Precise that DT block has to be in RAM - Misc fixes - Define version 3 and new format version 16 for the DT block (version 16 needs kernel @@ -82,7 +89,8 @@ Revision Information "name" property is now automatically deduced from the unit name - June 1, 2005: Rev 0.4 - Correct confusion between OF_DT_END and + June 1, 2005: Rev 0.4 + - Correct confusion between OF_DT_END and OF_DT_END_NODE in structure definition. - Change version 16 format to always align property data to 4 bytes. Since tokens are @@ -115,7 +123,7 @@ Revision Information - Compare FSL SOC use of PCI to standard and make sure no new node definition required. - Add more information about node definitions for SOC devices - that currently have no standard, like the FSL CPM. + that currently have no standard, like the FSL CPM. I - Introduction @@ -260,7 +268,7 @@ it with special cases. b) create your main platform file as "arch/powerpc/platforms/myplatform/myboard_setup.c" and add it - to the Makefile under the condition of your CONFIG_ + to the Makefile under the condition of your ``CONFIG_`` option. This file will define a structure of type "ppc_md" containing the various callbacks that the generic code will use to get to your platform specific code @@ -271,7 +279,7 @@ it with special cases. with classic Powerpc architectures. 3) Entry point for arch/x86 -------------------------------- +--------------------------- There is one single 32bit entry point to the kernel at code32_start, the decompressor (the real mode entry point goes to the same 32bit @@ -280,9 +288,9 @@ it with special cases. Documentation/x86/boot.rst The physical pointer to the device-tree block (defined in chapter II) is passed via setup_data which requires at least boot protocol 2.09. - The type filed is defined as + The type filed is defined as:: - #define SETUP_DTB 2 + #define SETUP_DTB 2 This device-tree is used as an extension to the "boot page". As such it does not parse / consider data which is already covered by the boot @@ -354,9 +362,9 @@ the block to RAM before passing it to the kernel. The kernel is passed the physical address pointing to an area of memory that is roughly described in include/linux/of_fdt.h by the structure - boot_param_header: + boot_param_header::: -struct boot_param_header { + struct boot_param_header { u32 magic; /* magic word OF_DT_HEADER */ u32 totalsize; /* total size of DT block */ u32 off_dt_struct; /* offset to structure */ @@ -374,19 +382,19 @@ struct boot_param_header { /* version 17 fields below */ u32 size_dt_struct; /* size of the DT structure block */ -}; + }; - Along with the constants: + Along with the constants:: -/* Definitions used by the flattened device tree */ -#define OF_DT_HEADER 0xd00dfeed /* 4: version, - 4: total size */ -#define OF_DT_BEGIN_NODE 0x1 /* Start node: full name - */ -#define OF_DT_END_NODE 0x2 /* End node */ -#define OF_DT_PROP 0x3 /* Property: name off, - size, content */ -#define OF_DT_END 0x9 + /* Definitions used by the flattened device tree */ + #define OF_DT_HEADER 0xd00dfeed /* 4: version, + 4: total size */ + #define OF_DT_BEGIN_NODE 0x1 /* Start node: full name + */ + #define OF_DT_END_NODE 0x2 /* End node */ + #define OF_DT_PROP 0x3 /* Property: name off, + size, content */ + #define OF_DT_END 0x9 All values in this header are in big endian format, the various fields in this header are defined more precisely below. All @@ -430,7 +438,7 @@ struct boot_param_header { way to avoid overriding critical things like, on Open Firmware capable machines, the RTAS instance, or on some pSeries, the TCE tables used for the iommu. Typically, the reserve map should - contain _at least_ this DT block itself (header,total_size). If + contain **at least** this DT block itself (header,total_size). If you are passing an initrd to the kernel, you should reserve it as well. You do not need to reserve the kernel image itself. The map should be 64-bit aligned. @@ -485,7 +493,7 @@ struct boot_param_header { So the typical layout of a DT block (though the various parts don't need to be in that order) looks like this (addresses go from top to - bottom): + bottom):: ------------------------------ @@ -511,9 +519,9 @@ struct boot_param_header { | --- (base + totalsize) - (*) The alignment gaps are not necessarily present; their presence - and size are dependent on the various alignment requirements of - the individual data blocks. + (*) The alignment gaps are not necessarily present; their presence + and size are dependent on the various alignment requirements of + the individual data blocks. 2) Device tree generalities @@ -600,7 +608,7 @@ discussed in a later chapter. At this point, it is only meant to give you a idea of what a device-tree looks like. I have purposefully kept the "name" and "linux,phandle" properties which aren't necessary in order to give you a better idea of what the tree looks like in -practice. +practice:: / o device-tree |- name = "device-tree" @@ -650,6 +658,7 @@ properties and their content. 3) Device tree "structure" block +-------------------------------- The structure of the device tree is a linearized tree structure. The "OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END_NODE" @@ -666,12 +675,14 @@ Here's the basic structure of a single node: root node) * [align gap to next 4 bytes boundary] * for each property: + * token OF_DT_PROP (that is 0x00000003) * 32-bit value of property value size in bytes (or 0 if no value) * 32-bit value of offset in string block of property name * property value data if any * [align gap to next 4 bytes boundary] + * [child nodes if any] * token OF_DT_END_NODE (that is 0x00000002) @@ -688,6 +699,7 @@ manipulating a flattened tree must take care to preserve this constraint. 4) Device tree "strings" block +------------------------------ In order to save space, property names, which are generally redundant, are stored separately in the "strings" block. This block is simply the @@ -700,15 +712,17 @@ strings block. III - Required content of the device tree ========================================= -WARNING: All "linux,*" properties defined in this document apply only -to a flattened device-tree. If your platform uses a real -implementation of Open Firmware or an implementation compatible with -the Open Firmware client interface, those properties will be created -by the trampoline code in the kernel's prom_init() file. For example, -that's where you'll have to add code to detect your board model and -set the platform number. However, when using the flattened device-tree -entry point, there is no prom_init() pass, and thus you have to -provide those properties yourself. +.. Warning:: + + All ``linux,*`` properties defined in this document apply only + to a flattened device-tree. If your platform uses a real + implementation of Open Firmware or an implementation compatible with + the Open Firmware client interface, those properties will be created + by the trampoline code in the kernel's prom_init() file. For example, + that's where you'll have to add code to detect your board model and + set the platform number. However, when using the flattened device-tree + entry point, there is no prom_init() pass, and thus you have to + provide those properties yourself. 1) Note about cells and address representation @@ -769,7 +783,7 @@ addresses), all buses must contain a "ranges" property. If the "ranges" property is missing at a given level, it's assumed that translation isn't possible, i.e., the registers are not visible on the parent bus. The format of the "ranges" property for a bus is a list -of: +of:: bus address, parent bus address, size @@ -877,7 +891,7 @@ address which can extend beyond that limit. This node is the parent of all individual CPU nodes. It doesn't have any specific requirements, though it's generally good practice - to have at least: + to have at least:: #address-cells = <00000001> #size-cells = <00000000> @@ -887,7 +901,7 @@ address which can extend beyond that limit. that format when reading the "reg" properties of a CPU node, see below - c) The /cpus/* nodes + c) The ``/cpus/*`` nodes So under /cpus, you are supposed to create a node for every CPU on the machine. There is no specific restriction on the name of the @@ -903,21 +917,23 @@ address which can extend beyond that limit. - reg : This is the physical CPU number, it's a single 32-bit cell and is also used as-is as the unit number for constructing the unit name in the full path. For example, with 2 CPUs, you would - have the full path: + have the full path:: + /cpus/PowerPC,970FX@0 /cpus/PowerPC,970FX@1 + (unit addresses do not require leading zeroes) - - d-cache-block-size : one cell, L1 data cache block size in bytes (*) + - d-cache-block-size : one cell, L1 data cache block size in bytes [#]_ - i-cache-block-size : one cell, L1 instruction cache block size in bytes - d-cache-size : one cell, size of L1 data cache in bytes - i-cache-size : one cell, size of L1 instruction cache in bytes -(*) The cache "block" size is the size on which the cache management -instructions operate. Historically, this document used the cache -"line" size here which is incorrect. The kernel will prefer the cache -block size and will fallback to cache line size for backward -compatibility. + .. [#] The cache "block" size is the size on which the cache management + instructions operate. Historically, this document used the cache + "line" size here which is incorrect. The kernel will prefer the cache + block size and will fallback to cache line size for backward + compatibility. Recommended properties: @@ -963,10 +979,10 @@ compatibility. #address-cells and #size-cells of the root node. For example, with both of these properties being 2 like in the example given earlier, a 970 based machine with 6Gb of RAM could typically - have a "reg" property here that looks like: + have a "reg" property here that looks like:: - 00000000 00000000 00000000 80000000 - 00000001 00000000 00000001 00000000 + 00000000 00000000 00000000 80000000 + 00000001 00000000 00000001 00000000 That is a range starting at 0 of 0x80000000 bytes and a range starting at 0x100000000 and of 0x100000000 bytes. You can see @@ -1047,18 +1063,18 @@ compatibility. See 1) above for more details on defining #address-cells. - #size-cells : Size representation for "soc" devices - #interrupt-cells : Defines the width of cells used to represent - interrupts. Typically this value is <2>, which includes a - 32-bit number that represents the interrupt number, and a - 32-bit number that represents the interrupt sense and level. - This field is only needed if the SOC contains an interrupt - controller. + interrupts. Typically this value is <2>, which includes a + 32-bit number that represents the interrupt number, and a + 32-bit number that represents the interrupt sense and level. + This field is only needed if the SOC contains an interrupt + controller. The SOC node may contain child nodes for each SOC device that the platform uses. Nodes should not be created for devices which exist on the SOC but are not used by a particular platform. See chapter VI for more information on how to specify devices that are part of a SOC. - Example SOC node for the MPC8540: + Example SOC node for the MPC8540:: soc8540@e0000000 { #address-cells = <1>; @@ -1079,31 +1095,33 @@ IV - "dtc", the device tree compiler dtc source code can be found at -WARNING: This version is still in early development stage; the -resulting device-tree "blobs" have not yet been validated with the -kernel. The current generated block lacks a useful reserve map (it will -be fixed to generate an empty one, it's up to the bootloader to fill -it up) among others. The error handling needs work, bugs are lurking, -etc... +.. Warning:: + + This version is still in early development stage; the + resulting device-tree "blobs" have not yet been validated with the + kernel. The current generated block lacks a useful reserve map (it will + be fixed to generate an empty one, it's up to the bootloader to fill + it up) among others. The error handling needs work, bugs are lurking, + etc... dtc basically takes a device-tree in a given format and outputs a device-tree in another format. The currently supported formats are: - Input formats: - ------------- +Input formats +------------- - "dtb": "blob" format, that is a flattened device-tree block with - header all in a binary blob. + header all in a binary blob. - "dts": "source" format. This is a text file containing a "source" for a device-tree. The format is defined later in this - chapter. + chapter. - "fs" format. This is a representation equivalent to the - output of /proc/device-tree, that is nodes are directories and - properties are files + output of /proc/device-tree, that is nodes are directories and + properties are files - Output formats: - --------------- +Output formats +-------------- - "dtb": "blob" format - "dts": "source" format @@ -1113,7 +1131,7 @@ device-tree in another format. The currently supported formats are: assembly file exports some symbols that can be used. -The syntax of the dtc tool is +The syntax of the dtc tool is:: dtc [-I ] [-O ] [-o output-filename] [-V output_version] input_filename @@ -1127,43 +1145,45 @@ Additionally, dtc performs various sanity checks on the tree, like the uniqueness of linux, phandle properties, validity of strings, etc... The format of the .dts "source" file is "C" like, supports C and C++ -style comments. +style comments:: -/ { -} + / { + } The above is the "device-tree" definition. It's the only statement supported currently at the toplevel. -/ { - property1 = "string_value"; /* define a property containing a 0 - * terminated string - */ +:: - property2 = <0x1234abcd>; /* define a property containing a - * numerical 32-bit value (hexadecimal) - */ + / { + property1 = "string_value"; /* define a property containing a 0 + * terminated string + */ - property3 = <0x12345678 0x12345678 0xdeadbeef>; - /* define a property containing 3 - * numerical 32-bit values (cells) in - * hexadecimal - */ - property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef]; - /* define a property whose content is - * an arbitrary array of bytes - */ + property2 = <0x1234abcd>; /* define a property containing a + * numerical 32-bit value (hexadecimal) + */ - childnode@address { /* define a child node named "childnode" - * whose unit name is "childnode at - * address" - */ + property3 = <0x12345678 0x12345678 0xdeadbeef>; + /* define a property containing 3 + * numerical 32-bit values (cells) in + * hexadecimal + */ + property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef]; + /* define a property whose content is + * an arbitrary array of bytes + */ - childprop = "hello\n"; /* define a property "childprop" of - * childnode (in this case, a string) - */ - }; -}; + childnode@address { /* define a child node named "childnode" + * whose unit name is "childnode at + * address" + */ + + childprop = "hello\n"; /* define a property "childprop" of + * childnode (in this case, a string) + */ + }; + }; Nodes can contain other nodes etc... thus defining the hierarchical structure of the tree. @@ -1322,7 +1342,7 @@ phandle of the parent node. If the interrupt-parent property is not defined for a node, its interrupt parent is assumed to be an ancestor in the node's -_device tree_ hierarchy. +*device tree* hierarchy. 3) OpenPIC Interrupt Controllers -------------------------------- @@ -1334,10 +1354,12 @@ information. Sense and level information should be encoded as follows: - 0 = low to high edge sensitive type enabled - 1 = active low level sensitive type enabled - 2 = active high level sensitive type enabled - 3 = high to low edge sensitive type enabled + == ======================================== + 0 low to high edge sensitive type enabled + 1 active low level sensitive type enabled + 2 active high level sensitive type enabled + 3 high to low edge sensitive type enabled + == ======================================== 4) ISA Interrupt Controllers ---------------------------- @@ -1350,13 +1372,15 @@ information. ISA PIC interrupt controllers should adhere to the ISA PIC encodings listed below: - 0 = active low level sensitive type enabled - 1 = active high level sensitive type enabled - 2 = high to low edge sensitive type enabled - 3 = low to high edge sensitive type enabled + == ======================================== + 0 active low level sensitive type enabled + 1 active high level sensitive type enabled + 2 high to low edge sensitive type enabled + 3 low to high edge sensitive type enabled + == ======================================== VIII - Specifying Device Power Management Information (sleep property) -=================================================================== +====================================================================== Devices on SOCs often have mechanisms for placing devices into low-power states that are decoupled from the devices' own register blocks. Sometimes, @@ -1387,6 +1411,7 @@ reasonably grouped in this manner, then create a virtual sleep controller sleep-map should wait until its necessity is demonstrated). IX - Specifying dma bus information +=================================== Some devices may have DMA memory range shifted relatively to the beginning of RAM, or even placed outside of kernel RAM. For example, the Keystone 2 SoC @@ -1404,25 +1429,30 @@ coherent DMA operations. The "dma-coherent" property is intended to be used for identifying devices supported coherent DMA operations in DT. * DMA Bus master + Optional property: + - dma-ranges: encoded as arbitrary number of triplets of - (child-bus-address, parent-bus-address, length). Each triplet specified - describes a contiguous DMA address range. - The dma-ranges property is used to describe the direct memory access (DMA) - structure of a memory-mapped bus whose device tree parent can be accessed - from DMA operations originating from the bus. It provides a means of - defining a mapping or translation between the physical address space of - the bus and the physical address space of the parent of the bus. - (for more information see the Devicetree Specification) + (child-bus-address, parent-bus-address, length). Each triplet specified + describes a contiguous DMA address range. + The dma-ranges property is used to describe the direct memory access (DMA) + structure of a memory-mapped bus whose device tree parent can be accessed + from DMA operations originating from the bus. It provides a means of + defining a mapping or translation between the physical address space of + the bus and the physical address space of the parent of the bus. + (for more information see the Devicetree Specification) * DMA Bus child + Optional property: + - dma-ranges: value. if present - It means that DMA addresses - translation has to be enabled for this device. + translation has to be enabled for this device. - dma-coherent: Present if dma operations are coherent -Example: -soc { +Example:: + + soc { compatible = "ti,keystone","simple-bus"; ranges = <0x0 0x0 0x0 0xc0000000>; dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>; @@ -1435,11 +1465,13 @@ soc { [...] dma-coherent; }; -}; + }; Appendix A - Sample SOC node for MPC8540 ======================================== +:: + soc@e0000000 { #address-cells = <1>; #size-cells = <1>; diff --git a/Documentation/devicetree/index.rst b/Documentation/devicetree/index.rst index 54026763916d..d2a96e1af23e 100644 --- a/Documentation/devicetree/index.rst +++ b/Documentation/devicetree/index.rst @@ -15,3 +15,4 @@ Open Firmware and Device Tree overlay-notes bindings/index + booting-without-of diff --git a/Documentation/dontdiff b/Documentation/dontdiff index ef9519c32c55..e361fc95ca29 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -55,6 +55,7 @@ *.ver *.xml *.xz +*.zst *_MODULES *_vga16.c *~ diff --git a/Documentation/driver-api/connector.rst b/Documentation/driver-api/connector.rst index c100c7482289..23d068191fb1 100644 --- a/Documentation/driver-api/connector.rst +++ b/Documentation/driver-api/connector.rst @@ -26,7 +26,7 @@ netlink based networking for inter-process communication in a significantly easier way:: int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); - void cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask); + void cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask); void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask); struct cb_id @@ -48,7 +48,8 @@ be dereferenced to `struct cn_msg *`:: __u32 seq; __u32 ack; - __u32 len; /* Length of the following data */ + __u16 len; /* Length of the following data */ + __u16 flags; __u8 data[0]; }; diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst index 0e389378f71d..764963876d08 100644 --- a/Documentation/driver-api/device-io.rst +++ b/Documentation/driver-api/device-io.rst @@ -36,14 +36,14 @@ are starting with one. Physical addresses are of type unsigned long. This address should not be used directly. Instead, to get an address suitable for passing to the accessor functions described below, you -should call :c:func:`ioremap()`. An address suitable for accessing +should call ioremap(). An address suitable for accessing the device will be returned to you. After you've finished using the device (say, in your module's exit -routine), call :c:func:`iounmap()` in order to return the address +routine), call iounmap() in order to return the address space to the kernel. Most architectures allocate new address space each -time you call :c:func:`ioremap()`, and they can run out unless you -call :c:func:`iounmap()`. +time you call ioremap(), and they can run out unless you +call iounmap(). Accessing the device -------------------- @@ -60,8 +60,8 @@ readb_relaxed(), readw_relaxed(), readl_relaxed(), readq_relaxed(), writeb(), writew(), writel() and writeq(). Some devices (such as framebuffers) would like to use larger transfers than -8 bytes at a time. For these devices, the :c:func:`memcpy_toio()`, -:c:func:`memcpy_fromio()` and :c:func:`memset_io()` functions are +8 bytes at a time. For these devices, the memcpy_toio(), +memcpy_fromio() and memset_io() functions are provided. Do not use memset or memcpy on IO addresses; they are not guaranteed to copy data in order. @@ -135,15 +135,15 @@ Accessing Port Space Accesses to this space are provided through a set of functions which allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and -long. These functions are :c:func:`inb()`, :c:func:`inw()`, -:c:func:`inl()`, :c:func:`outb()`, :c:func:`outw()` and -:c:func:`outl()`. +long. These functions are inb(), inw(), +inl(), outb(), outw() and +outl(). Some variants are provided for these functions. Some devices require that accesses to their ports are slowed down. This functionality is provided by appending a ``_p`` to the end of the function. -There are also equivalents to memcpy. The :c:func:`ins()` and -:c:func:`outs()` functions copy bytes, words or longs to the given +There are also equivalents to memcpy. The ins() and +outs() functions copy bytes, words or longs to the given port. Public Functions Provided diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 63dec76d1d8d..100bfd227265 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: cpu access -Fence Poll Support -~~~~~~~~~~~~~~~~~~ +Implicit Fence Poll Support +~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. kernel-doc:: drivers/dma-buf/dma-buf.c - :doc: fence polling + :doc: implicit fence polling Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -133,6 +133,18 @@ DMA Fences .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: DMA fences overview +DMA Fence Cross-Driver Contract +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence cross-driver contract + +DMA Fence Signalling Annotations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence signalling annotation + DMA Fences Functions Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -166,3 +178,73 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: +Indefinite DMA Fences +~~~~~~~~~~~~~~~~~~~~ + +At various times &dma_fence with an indefinite time until dma_fence_wait() +finishes have been proposed. Examples include: + +* Future fences, used in HWC1 to signal when a buffer isn't used by the display + any longer, and created with the screen update that makes the buffer visible. + The time this fence completes is entirely under userspace's control. + +* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet + been set. Used to asynchronously delay command submission. + +* Userspace fences or gpu futexes, fine-grained locking within a command buffer + that userspace uses for synchronization across engines or with the CPU, which + are then imported as a DMA fence for integration into existing winsys + protocols. + +* Long-running compute command buffers, while still using traditional end of + batch DMA fences for memory management instead of context preemption DMA + fences which get reattached when the compute job is rescheduled. + +Common to all these schemes is that userspace controls the dependencies of these +fences and controls when they fire. Mixing indefinite fences with normal +in-kernel DMA fences does not work, even when a fallback timeout is included to +protect against malicious userspace: + +* Only the kernel knows about all DMA fence dependencies, userspace is not aware + of dependencies injected due to memory management or scheduler decisions. + +* Only userspace knows about all dependencies in indefinite fences and when + exactly they will complete, the kernel has no visibility. + +Furthermore the kernel has to be able to hold up userspace command submission +for memory management needs, which means we must support indefinite fences being +dependent upon DMA fences. If the kernel also support indefinite fences in the +kernel like a DMA fence, like any of the above proposal would, there is the +potential for deadlocks. + +.. kernel-render:: DOT + :alt: Indefinite Fencing Dependency Cycle + :caption: Indefinite Fencing Dependency Cycle + + digraph "Fencing Cycle" { + node [shape=box bgcolor=grey style=filled] + kernel [label="Kernel DMA Fences"] + userspace [label="userspace controlled fences"] + kernel -> userspace [label="memory management"] + userspace -> kernel [label="Future fence, fence proxy, ..."] + + { rank=same; kernel userspace } + } + +This means that the kernel might accidentally create deadlocks +through memory management dependencies which userspace is unaware of, which +randomly hangs workloads until the timeout kicks in. Workloads, which from +userspace's perspective, do not contain a deadlock. In such a mixed fencing +architecture there is no single entity with knowledge of all dependencies. +Thefore preventing such deadlocks from within the kernel is not possible. + +The only solution to avoid dependencies loops is by not allowing indefinite +fences in the kernel. This means: + +* No future fences, proxy fences or userspace fences imported as DMA fences, + with or without a timeout. + +* No DMA fences that signal end of batchbuffer for command submission where + userspace is allowed to use userspace fencing or long running compute + workloads. This also means no implicit fencing for shared buffers in these + cases. diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst index 2104830a99ae..09a3f66dcd26 100644 --- a/Documentation/driver-api/dmaengine/client.rst +++ b/Documentation/driver-api/dmaengine/client.rst @@ -5,7 +5,7 @@ DMA Engine API Guide Vinod Koul .. note:: For DMA Engine usage in async_tx please see: - ``Documentation/crypto/async-tx-api.txt`` + ``Documentation/crypto/async-tx-api.rst`` Below is a guide to device driver writers on how to use the Slave-DMA API of the @@ -86,7 +86,9 @@ The details of these operations are: - interleaved_dma: This is common to Slave as well as M2M clients. For slave address of devices' fifo could be already known to the driver. Various types of operations could be expressed by setting - appropriate values to the 'dma_interleaved_template' members. + appropriate values to the 'dma_interleaved_template' members. Cyclic + interleaved DMA transfers are also possible if supported by the channel by + setting the DMA_PREP_REPEAT transfer flag. A non-NULL return of this transfer API represents a "descriptor" for the given transaction. diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index 56e5833e8a07..ab82c8f21d31 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -95,7 +95,7 @@ accommodates that API in some cases, and made some design choices to ensure that it stayed compatible. For more information on the Async TX API, please look the relevant -documentation file in Documentation/crypto/async-tx-api.txt. +documentation file in Documentation/crypto/async-tx-api.rst. DMAEngine APIs ============== @@ -239,6 +239,27 @@ Currently, the types available are: want to transfer a portion of uncompressed data directly to the display to print it +- DMA_REPEAT + + - The device supports repeated transfers. A repeated transfer, indicated by + the DMA_PREP_REPEAT transfer flag, is similar to a cyclic transfer in that + it gets automatically repeated when it ends, but can additionally be + replaced by the client. + + - This feature is limited to interleaved transfers, this flag should thus not + be set if the DMA_INTERLEAVE flag isn't set. This limitation is based on + the current needs of DMA clients, support for additional transfer types + should be added in the future if and when the need arises. + +- DMA_LOAD_EOT + + - The device supports replacing repeated transfers at end of transfer (EOT) + by queuing a new transfer with the DMA_PREP_LOAD_EOT flag set. + + - Support for replacing a currently running transfer at another point (such + as end of burst instead of end of transfer) will be added in the future + based on DMA clients needs, if and when the need arises. + These various types will also affect how the source and destination addresses change over time. @@ -531,6 +552,34 @@ DMA_CTRL_REUSE writes for which the descriptor should be in different format from normal data descriptors. +- DMA_PREP_REPEAT + + - If set, the transfer will be automatically repeated when it ends until a + new transfer is queued on the same channel with the DMA_PREP_LOAD_EOT flag. + If the next transfer to be queued on the channel does not have the + DMA_PREP_LOAD_EOT flag set, the current transfer will be repeated until the + client terminates all transfers. + + - This flag is only supported if the channel reports the DMA_REPEAT + capability. + +- DMA_PREP_LOAD_EOT + + - If set, the transfer will replace the transfer currently being executed at + the end of the transfer. + + - This is the default behaviour for non-repeated transfers, specifying + DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference. + + - When using repeated transfers, DMA clients will usually need to set the + DMA_PREP_LOAD_EOT flag on all transfers, otherwise the channel will keep + repeating the last repeated transfer and ignore the new transfers being + queued. Failure to set DMA_PREP_LOAD_EOT will appear as if the channel was + stuck on the previous transfer. + + - This flag is only supported if the channel reports the DMA_LOAD_EOT + capability. + General Design Notes ==================== diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index e0b58c392e4f..eaaaafc21134 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -342,7 +342,8 @@ LED MDIO devm_mdiobus_alloc() devm_mdiobus_alloc_size() - devm_mdiobus_free() + devm_mdiobus_register() + devm_of_mdiobus_register() MEM devm_free_pages() diff --git a/Documentation/driver-api/driver-model/driver.rst b/Documentation/driver-api/driver-model/driver.rst index 7d5040f6a3d8..06f818b1d622 100644 --- a/Documentation/driver-api/driver-model/driver.rst +++ b/Documentation/driver-api/driver-model/driver.rst @@ -228,8 +228,6 @@ over management of devices from the bootloader, the usage of sync_state() is not restricted to that. Use it whenever it makes sense to take an action after all the consumers of a device have probed:: -:: - int (*remove) (struct device *dev); remove is called to unbind a driver from a device. This may be diff --git a/Documentation/driver-api/driver-model/platform.rst b/Documentation/driver-api/driver-model/platform.rst index 334dd4071ae4..1fe5c6c6199c 100644 --- a/Documentation/driver-api/driver-model/platform.rst +++ b/Documentation/driver-api/driver-model/platform.rst @@ -108,7 +108,7 @@ field to hold additional information. Embedded systems frequently need one or more clocks for platform devices, which are normally kept off until they're actively needed (to save power). -System setup also associates those clocks with the device, so that that +System setup also associates those clocks with the device, so that calls to clk_get(&pdev->dev, clock_name) return them as needed. diff --git a/Documentation/driver-api/early-userspace/early_userspace_support.rst b/Documentation/driver-api/early-userspace/early_userspace_support.rst index 3deefb34046b..8a58c61932ff 100644 --- a/Documentation/driver-api/early-userspace/early_userspace_support.rst +++ b/Documentation/driver-api/early-userspace/early_userspace_support.rst @@ -92,7 +92,7 @@ You can obtain somewhat infrequent snapshots of klibc from https://www.kernel.org/pub/linux/libs/klibc/ For active users, you are better off using the klibc git -repository, at http://git.kernel.org/?p=libs/klibc/klibc.git +repository, at https://git.kernel.org/?p=libs/klibc/klibc.git The standalone klibc distribution currently provides three components, in addition to the klibc library: @@ -122,7 +122,7 @@ and a number of other utilities, so you can replace kinit and build custom initramfs images that meet your needs exactly. For questions and help, you can sign up for the early userspace -mailing list at http://www.zytor.com/mailman/listinfo/klibc +mailing list at https://www.zytor.com/mailman/listinfo/klibc How does it work? ================= diff --git a/Documentation/driver-api/firmware/built-in-fw.rst b/Documentation/driver-api/firmware/built-in-fw.rst index 396cdf591ac5..bc1c961bace1 100644 --- a/Documentation/driver-api/firmware/built-in-fw.rst +++ b/Documentation/driver-api/firmware/built-in-fw.rst @@ -28,6 +28,6 @@ able to make use of built-in firmware: * Some firmware files may be really large in size. The remote-proc subsystem is an example subsystem which deals with these sorts of firmware * The firmware may need to be scraped out from some device specific location - dynamically, an example is calibration data for for some WiFi chipsets. This + dynamically, an example is calibration data for some WiFi chipsets. This calibration data can be unique per sold device. diff --git a/Documentation/driver-api/firmware/direct-fs-lookup.rst b/Documentation/driver-api/firmware/direct-fs-lookup.rst index 82b4d585a213..e04353d1b06b 100644 --- a/Documentation/driver-api/firmware/direct-fs-lookup.rst +++ b/Documentation/driver-api/firmware/direct-fs-lookup.rst @@ -24,7 +24,7 @@ available. Stuffing the firmware into initramfs resolves this race issue, however note that using initrd does not suffice to address the same race. There are circumstances that justify not wanting to include firmware into -initramfs, such as dealing with large firmware firmware files for the +initramfs, such as dealing with large firmware files for the remote-proc subsystem. For such cases using a userspace fallback mechanism is currently the only viable solution as only userspace can know for sure when the real rootfs is ready and mounted. diff --git a/Documentation/driver-api/firmware/firmware_cache.rst b/Documentation/driver-api/firmware/firmware_cache.rst index c2e69d9c6bf1..417b9e8347f0 100644 --- a/Documentation/driver-api/firmware/firmware_cache.rst +++ b/Documentation/driver-api/firmware/firmware_cache.rst @@ -27,7 +27,7 @@ Some implementation details about the firmware cache setup: uses all synchronous call except :c:func:`request_firmware_into_buf`. * If an asynchronous call is used the firmware cache is only set up for a - device if if the second argument (uevent) to request_firmware_nowait() is + device if the second argument (uevent) to request_firmware_nowait() is true. When uevent is true it requests that a kobject uevent be sent to userspace for the firmware request through the sysfs fallback mechanism if the firmware file is not found. diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst index cd076462d235..0d6ea0329995 100644 --- a/Documentation/driver-api/firmware/request_firmware.rst +++ b/Documentation/driver-api/firmware/request_firmware.rst @@ -76,5 +76,5 @@ firmware. For example if you used request_firmware() and it returns, the driver has the firmware image accessible in fw_entry->{data,size}. If something went wrong request_firmware() returns non-zero and fw_entry is set to NULL. Once your driver is done with processing the firmware it -can call call release_firmware(fw_entry) to release the firmware image +can call release_firmware(fw_entry) to release the firmware image and any related resource. diff --git a/Documentation/driver-api/gpio/drivers-on-gpio.rst b/Documentation/driver-api/gpio/drivers-on-gpio.rst index 820b403d50f6..41ec3cc72d32 100644 --- a/Documentation/driver-api/gpio/drivers-on-gpio.rst +++ b/Documentation/driver-api/gpio/drivers-on-gpio.rst @@ -89,6 +89,13 @@ hardware descriptions such as device tree or ACPI: Consumer Electronics Control bus using only GPIO. It is used to communicate with devices on the HDMI bus. +- gpio-charger: drivers/power/supply/gpio-charger.c is used if you need to do + battery charging and all you have to go by to check the presence of the + AC charger or more complex tasks such as indicating charging status using + nothing but GPIO lines, this driver provides that and also a clearly defined + way to pass the charging parameters from hardware descriptions such as the + device tree. + Apart from this there are special GPIO drivers in subsystems like MMC/SD to read card detect and write protect GPIO lines, and in the TTY serial subsystem to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The diff --git a/Documentation/driver-api/i3c/protocol.rst b/Documentation/driver-api/i3c/protocol.rst index dae3b6d32c6b..02653defa011 100644 --- a/Documentation/driver-api/i3c/protocol.rst +++ b/Documentation/driver-api/i3c/protocol.rst @@ -14,7 +14,7 @@ collisions are prevented, ...) please have a look at the I3C specification. This document is just a brief introduction to the I3C protocol and the concepts it brings to the table. If you need more information, please refer to the MIPI I3C specification (can be downloaded here -http://resources.mipi.org/mipi-i3c-v1-download). +https://resources.mipi.org/mipi-i3c-v1-download). Introduction ============ diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 6567187e7687..902b93b17235 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -48,6 +48,7 @@ available subsections can be seen below. scsi libata target + mailbox mtdnand miscellaneous mei/index @@ -95,6 +96,7 @@ available subsections can be seen below. phy/index pti_intel_mid pwm + pldmfw/index rfkill serial/index sm501 diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst index 5ef1047e2e66..292f587fccdd 100644 --- a/Documentation/driver-api/ipmi.rst +++ b/Documentation/driver-api/ipmi.rst @@ -18,7 +18,7 @@ management software that can use the IPMI system. This document describes how to use the IPMI driver for Linux. If you are not familiar with IPMI itself, see the web site at -http://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big +https://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big subject and I can't cover it all here! Configuration diff --git a/Documentation/mailbox.txt b/Documentation/driver-api/mailbox.rst similarity index 100% rename from Documentation/mailbox.txt rename to Documentation/driver-api/mailbox.rst diff --git a/Documentation/driver-api/memory-devices/ti-gpmc.rst b/Documentation/driver-api/memory-devices/ti-gpmc.rst index 33efcb81f080..b1bb86871ad7 100644 --- a/Documentation/driver-api/memory-devices/ti-gpmc.rst +++ b/Documentation/driver-api/memory-devices/ti-gpmc.rst @@ -14,7 +14,7 @@ memory devices like * Pseudo-SRAM devices GPMC is found on Texas Instruments SoC's (OMAP based) -IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1 +IP details: https://www.ti.com/lit/pdf/spruh73 section 7.1 GPMC generic timing calculation: diff --git a/Documentation/driver-api/mmc/mmc-tools.rst b/Documentation/driver-api/mmc/mmc-tools.rst index 54406093768b..a231e9644351 100644 --- a/Documentation/driver-api/mmc/mmc-tools.rst +++ b/Documentation/driver-api/mmc/mmc-tools.rst @@ -5,7 +5,7 @@ MMC tools introduction There is one MMC test tools called mmc-utils, which is maintained by Chris Ball, you can find it at the below public git repository: - http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ + https://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/ Functions ========= diff --git a/Documentation/driver-api/ntb.rst b/Documentation/driver-api/ntb.rst index 87d1372da879..11577c2105c5 100644 --- a/Documentation/driver-api/ntb.rst +++ b/Documentation/driver-api/ntb.rst @@ -9,7 +9,7 @@ registers and memory translation windows, as well as non common features like scratchpad and message registers. Scratchpad registers are read-and-writable registers that are accessible from either side of the device, so that peers can exchange a small amount of information at a fixed address. Message registers can -be utilized for the same purpose. Additionally they are provided with with +be utilized for the same purpose. Additionally they are provided with special status bits to make sure the information isn't rewritten by another peer. Doorbell registers provide a way for peers to send interrupt events. Memory windows allow translated read and write access to the peer memory. diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index 79c0fd39f2af..ef6d59e0978e 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -73,7 +73,7 @@ DAX: process address space. DSM: - Device Specific Method: ACPI method to to control specific + Device Specific Method: ACPI method to control specific device - in this case the firmware. DCR: @@ -113,13 +113,13 @@ Supporting Documents -------------------- ACPI 6: - http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf + https://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf NVDIMM Namespace: - http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf + https://pmem.io/documents/NVDIMM_Namespace_Spec.pdf DSM Interface Example: - http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf + https://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf Driver Writer's Guide: - http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf + https://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf Git Trees --------- @@ -778,7 +778,7 @@ Why the Term "namespace"? 2. The term originated to describe the sub-devices that can be created within a NVME controller (see the nvme specification: - http://www.nvmexpress.org/specifications/), and NFIT namespaces are + https://www.nvmexpress.org/specifications/), and NFIT namespaces are meant to parallel the capabilities and configurability of NVME-namespaces. @@ -786,7 +786,7 @@ Why the Term "namespace"? LIBNVDIMM/LIBNDCTL: Block Translation Table "btt" ------------------------------------------------- -A BTT (design document: http://pmem.io/2014/09/23/btt.html) is a stacked +A BTT (design document: https://pmem.io/2014/09/23/btt.html) is a stacked block device driver that fronts either the whole block device or a partition of a block device emitted by either a PMEM or BLK NAMESPACE. diff --git a/Documentation/driver-api/nvdimm/security.rst b/Documentation/driver-api/nvdimm/security.rst index ad9dea099b34..7aab71524116 100644 --- a/Documentation/driver-api/nvdimm/security.rst +++ b/Documentation/driver-api/nvdimm/security.rst @@ -138,6 +138,6 @@ another encrypted-key. This command is only available when the master security is enabled, indicated by the extended security status. -[1]: http://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf +[1]: https://pmem.io/documents/NVDIMM_DSM_Interface-V1.8.pdf [2]: http://www.t13.org/documents/UploadedDocuments/docs2006/e05179r4-ACS-SecurityClarifications.pdf diff --git a/Documentation/driver-api/pldmfw/driver-ops.rst b/Documentation/driver-api/pldmfw/driver-ops.rst new file mode 100644 index 000000000000..f0654783d3b3 --- /dev/null +++ b/Documentation/driver-api/pldmfw/driver-ops.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +========================= +Driver-specific callbacks +========================= + +The ``pldmfw`` module relies on the device driver for implementing device +specific behavior using the following operations. + +``.match_record`` +----------------- + +The ``.match_record`` operation is used to determine whether a given PLDM +record matches the device being updated. This requires comparing the record +descriptors in the record with information from the device. Many record +descriptors are defined by the PLDM standard, but it is also allowed for +devices to implement their own descriptors. + +The ``.match_record`` operation should return true if a given record matches +the device. + +``.send_package_data`` +---------------------- + +The ``.send_package_data`` operation is used to send the device-specific +package data in a record to the device firmware. If the matching record +provides package data, ``pldmfw`` will call the ``.send_package_data`` +function with a pointer to the package data and with the package data +length. The device driver should send this data to firmware. + +``.send_component_table`` +------------------------- + +The ``.send_component_table`` operation is used to forward component +information to the device. It is called once for each applicable component, +that is, for each component indicated by the matching record. The +device driver should send the component information to the device firmware, +and wait for a response. The provided transfer flag indicates whether this +is the first, last, or a middle component, and is expected to be forwarded +to firmware as part of the component table information. The driver should an +error in the case when the firmware indicates that the component cannot be +updated, or return zero if the component can be updated. + +``.flash_component`` +-------------------- + +The ``.flash_component`` operation is used to inform the device driver to +flash a given component. The driver must perform any steps necessary to send +the component data to the device. + +``.finalize_update`` +-------------------- + +The ``.finalize_update`` operation is used by the ``pldmfw`` library in +order to allow the device driver to perform any remaining device specific +logic needed to finish the update. diff --git a/Documentation/driver-api/pldmfw/file-format.rst b/Documentation/driver-api/pldmfw/file-format.rst new file mode 100644 index 000000000000..b7a9cebe09c6 --- /dev/null +++ b/Documentation/driver-api/pldmfw/file-format.rst @@ -0,0 +1,203 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +================================== +PLDM Firmware file format overview +================================== + +A PLDM firmware package is a binary file which contains a header that +describes the contents of the firmware package. This includes an initial +package header, one or more firmware records, and one or more components +describing the actual flash contents to program. + +This diagram provides an overview of the file format:: + + overall file layout + +----------------------+ + | | + | Package Header | + | | + +----------------------+ + | | + | Device Records | + | | + +----------------------+ + | | + | Component Info | + | | + +----------------------+ + | | + | Package Header CRC | + | | + +----------------------+ + | | + | Component Image 1 | + | | + +----------------------+ + | | + | Component Image 2 | + | | + +----------------------+ + | | + | ... | + | | + +----------------------+ + | | + | Component Image N | + | | + +----------------------+ + +Package Header +============== + +The package header begins with the UUID of the PLDM file format, and +contains information about the version of the format that the file uses. It +also includes the total header size, a release date, the size of the +component bitmap, and an overall package version. + +The following diagram provides an overview of the package header:: + + header layout + +-------------------------+ + | PLDM UUID | + +-------------------------+ + | Format Revision | + +-------------------------+ + | Header Size | + +-------------------------+ + | Release Date | + +-------------------------+ + | Component Bitmap Length | + +-------------------------+ + | Package Version Info | + +-------------------------+ + +Device Records +============== + +The device firmware records area starts with a count indicating the total +number of records in the file, followed by each record. A single device +record describes what device matches this record. All valid PLDM firmware +files must contain at least one record, but optionally may contain more than +one record if they support multiple devices. + +Each record will identify the device it supports via TLVs that describe the +device, such as the PCI device and vendor information. It will also indicate +which set of components that are used by this device. It is possible that +only subset of provided components will be used by a given record. A record +may also optionally contain device-specific package data that will be used +by the device firmware during the update process. + +The following diagram provides an overview of the device record area:: + + area layout + +---------------+ + | | + | Record Count | + | | + +---------------+ + | | + | Record 1 | + | | + +---------------+ + | | + | Record 2 | + | | + +---------------+ + | | + | ... | + | | + +---------------+ + | | + | Record N | + | | + +---------------+ + + record layout + +-----------------------+ + | Record Length | + +-----------------------+ + | Descriptor Count | + +-----------------------+ + | Option Flags | + +-----------------------+ + | Version Settings | + +-----------------------+ + | Package Data Length | + +-----------------------+ + | Applicable Components | + +-----------------------+ + | Version String | + +-----------------------+ + | Descriptor TLVs | + +-----------------------+ + | Package Data | + +-----------------------+ + +Component Info +============== + +The component information area begins with a count of the number of +components. Following this count is a description for each component. The +component information points to the location in the file where the component +data is stored, and includes version data used to identify the version of +the component. + +The following diagram provides an overview of the component area:: + + area layout + +-----------------+ + | | + | Component Count | + | | + +-----------------+ + | | + | Component 1 | + | | + +-----------------+ + | | + | Component 2 | + | | + +-----------------+ + | | + | ... | + | | + +-----------------+ + | | + | Component N | + | | + +-----------------+ + + component layout + +------------------------+ + | Classification | + +------------------------+ + | Component Identifier | + +------------------------+ + | Comparison Stamp | + +------------------------+ + | Component Options | + +------------------------+ + | Activation Method | + +------------------------+ + | Location Offset | + +------------------------+ + | Component Size | + +------------------------+ + | Component Version Info | + +------------------------+ + | Package Data | + +------------------------+ + + +Package Header CRC +================== + +Following the component information is a short 4-byte CRC calculated over +the contents of all of the header information. + +Component Images +================ + +The component images follow the package header information in the PLDM +firmware file. Each of these is simply a binary chunk with its start and +size defined by the matching component structure in the component info area. diff --git a/Documentation/driver-api/pldmfw/index.rst b/Documentation/driver-api/pldmfw/index.rst new file mode 100644 index 000000000000..ad2c33ece30f --- /dev/null +++ b/Documentation/driver-api/pldmfw/index.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +================================== +PLDM Firmware Flash Update Library +================================== + +``pldmfw`` implements functionality for updating the flash on a device using +the PLDM for Firmware Update standard +. + +.. toctree:: + :maxdepth: 1 + + file-format + driver-ops + +================================== +Overview of the ``pldmfw`` library +================================== + +The ``pldmfw`` library is intended to be used by device drivers for +implementing device flash update based on firmware files following the PLDM +firwmare file format. + +It is implemented using an ops table that allows device drivers to provide +the underlying device specific functionality. + +``pldmfw`` implements logic to parse the packed binary format of the PLDM +firmware file into data structures, and then uses the provided function +operations to determine if the firmware file is a match for the device. If +so, it sends the record and component data to the firmware using the device +specific implementations provided by device drivers. Once the device +firmware indicates that the update may be performed, the firmware data is +sent to the device for programming. + +Parsing the PLDM file +===================== + +The PLDM file format uses packed binary data, with most multi-byte fields +stored in the Little Endian format. Several pieces of data are variable +length, including version strings and the number of records and components. +Due to this, it is not straight forward to index the record, record +descriptors, or components. + +To avoid proliferating access to the packed binary data, the ``pldmfw`` +library parses and extracts this data into simpler structures for ease of +access. + +In order to safely process the firmware file, care is taken to avoid +unaligned access of multi-byte fields, and to properly convert from Little +Endian to CPU host format. Additionally the records, descriptors, and +components are stored in linked lists. + +Performing a flash update +========================= + +To perform a flash update, the ``pldmfw`` module performs the following +steps + +1. Parse the firmware file for record and component information +2. Scan through the records and determine if the device matches any record + in the file. The first matched record will be used. +3. If the matching record provides package data, send this package data to + the device. +4. For each component that the record indicates, send the component data to + the device. For each component, the firmware may respond with an + indication of whether the update is suitable or not. If any component is + not suitable, the update is canceled. +5. For each component, send the binary data to the device firmware for + updating. +6. After all components are programmed, perform any final device-specific + actions to finalize the update. diff --git a/Documentation/driver-api/rapidio/rapidio.rst b/Documentation/driver-api/rapidio/rapidio.rst index fb8942d3ba85..74c552ad3eb8 100644 --- a/Documentation/driver-api/rapidio/rapidio.rst +++ b/Documentation/driver-api/rapidio/rapidio.rst @@ -356,7 +356,7 @@ NOTE: http://www.rapidio.org/education/technology_comparisons/ [3] RapidIO support for Linux. - http://lwn.net/Articles/139118/ + https://lwn.net/Articles/139118/ [4] Matt Porter. RapidIO for Linux. Ottawa Linux Symposium, 2005 - http://www.kernel.org/doc/ols/2005/ols2005v2-pages-43-56.pdf + https://www.kernel.org/doc/ols/2005/ols2005v2-pages-43-56.pdf diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index 1b386076402c..8858cea7bfe0 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -293,6 +293,10 @@ per stream. From ASoC DPCM framework, this stream state maybe linked to int sdw_alloc_stream(char * stream_name); +The SoundWire core provides a sdw_startup_stream() helper function, +typically called during a dailink .startup() callback, which performs +stream allocation and sets the stream pointer for all DAIs +connected to a stream. SDW_STREAM_CONFIGURED ~~~~~~~~~~~~~~~~~~~~~ @@ -509,7 +513,12 @@ In .shutdown() the data structure maintaining stream state are freed up. void sdw_release_stream(struct sdw_stream_runtime * stream); -Not Supported +The SoundWire core provides a sdw_shutdown_stream() helper function, +typically called during a dailink .shutdown() callback, which clears +the stream pointer for all DAIS connected to a stream and releases the +memory allocated for the stream. + + Not Supported ============= 1. A single port with multiple channels supported cannot be used between two diff --git a/Documentation/driver-api/thermal/cpu-idle-cooling.rst b/Documentation/driver-api/thermal/cpu-idle-cooling.rst index b9f34ceb2a38..c2a7ca676853 100644 --- a/Documentation/driver-api/thermal/cpu-idle-cooling.rst +++ b/Documentation/driver-api/thermal/cpu-idle-cooling.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ================ CPU Idle Cooling ================ @@ -48,7 +50,7 @@ idle state target residency, we lead to dropping the static and the dynamic leakage for this period (modulo the energy needed to enter this state). So the sustainable power with idle cycles has a linear relation with the OPP’s sustainable power and can be computed with a -coefficient similar to: +coefficient similar to:: Power(IdleCycle) = Coef x Power(OPP) @@ -139,7 +141,7 @@ Power considerations -------------------- When we reach the thermal trip point, we have to sustain a specified -power for a specific temperature but at this time we consume: +power for a specific temperature but at this time we consume:: Power = Capacitance x Voltage^2 x Frequency x Utilisation @@ -148,7 +150,7 @@ wrong in the system setup). The ‘Capacitance’ and ‘Utilisation’ are a fixed value, ‘Voltage’ and the ‘Frequency’ are fixed artificially because we don’t want to change the OPP. We can group the ‘Capacitance’ and the ‘Utilisation’ into a single term which is the -‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have: +‘Dynamic Power Coefficient (Cdyn)’ Simplifying the above, we have:: Pdyn = Cdyn x Voltage^2 x Frequency @@ -157,7 +159,7 @@ in order to target the sustainable power defined in the device tree. So with the idle injection mechanism, we want an average power (Ptarget) resulting in an amount of time running at full power on a specific OPP and idle another amount of time. That could be put in a -equation: +equation:: P(opp)target = ((Trunning x (P(opp)running) + (Tidle x P(opp)idle)) / (Trunning + Tidle) @@ -168,7 +170,7 @@ equation: At this point if we know the running period for the CPU, that gives us the idle injection we need. Alternatively if we have the idle -injection duration, we can compute the running duration with: +injection duration, we can compute the running duration with:: Trunning = Tidle / ((P(opp)running / P(opp)target) - 1) @@ -191,7 +193,7 @@ However, in this demonstration we ignore three aspects: target residency, otherwise we end up consuming more energy and potentially invert the mitigation effect -So the final equation is: +So the final equation is:: Trunning = (Tidle - Twakeup ) x (((P(opp)dyn + P(opp)static ) - P(opp)target) / P(opp)target ) diff --git a/Documentation/driver-api/thermal/nouveau_thermal.rst b/Documentation/driver-api/thermal/nouveau_thermal.rst index 37255fd6735d..79ece266cf6d 100644 --- a/Documentation/driver-api/thermal/nouveau_thermal.rst +++ b/Documentation/driver-api/thermal/nouveau_thermal.rst @@ -93,4 +93,4 @@ Thermal management on Nouveau is new and may not work on all cards. If you have inquiries, please ping mupuf on IRC (#nouveau, freenode). Bug reports should be filled on Freedesktop's bug tracker. Please follow -http://nouveau.freedesktop.org/wiki/Bugs +https://nouveau.freedesktop.org/wiki/Bugs diff --git a/Documentation/driver-api/uio-howto.rst b/Documentation/driver-api/uio-howto.rst index 84091cd25dc4..907ffa3b38f5 100644 --- a/Documentation/driver-api/uio-howto.rst +++ b/Documentation/driver-api/uio-howto.rst @@ -274,7 +274,7 @@ fields of ``struct uio_mem``: region, it will show up in the corresponding sysfs node. - ``int memtype``: Required if the mapping is used. Set this to - ``UIO_MEM_PHYS`` if you you have physical memory on your card to be + ``UIO_MEM_PHYS`` if you have physical memory on your card to be mapped. Use ``UIO_MEM_LOGICAL`` for logical memory (e.g. allocated with :c:func:`__get_free_pages()` but not kmalloc()). There's also ``UIO_MEM_VIRTUAL`` for virtual memory. diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 61a54da9fce9..1e4abc896a0d 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -240,7 +240,7 @@ How to do isochronous (ISO) transfers? ====================================== Besides the fields present on a bulk transfer, for ISO, you also -also have to set ``urb->interval`` to say how often to make transfers; it's +have to set ``urb->interval`` to say how often to make transfers; it's often one per frame (which is once every microframe for highspeed devices). The actual interval used will be a power of two that's no bigger than what you specify. You can use the :c:func:`usb_fill_int_urb` macro to fill diff --git a/Documentation/driver-api/usb/dma.rst b/Documentation/driver-api/usb/dma.rst index 59d5aee89e37..2b3dbd3265b4 100644 --- a/Documentation/driver-api/usb/dma.rst +++ b/Documentation/driver-api/usb/dma.rst @@ -10,7 +10,7 @@ API overview The big picture is that USB drivers can continue to ignore most DMA issues, though they still must provide DMA-ready buffers (see -``Documentation/DMA-API-HOWTO.txt``). That's how they've worked through +:doc:`/core-api/dma-api-howto`). That's how they've worked through the 2.4 (and earlier) kernels, or they can now be DMA-aware. DMA-aware usb drivers: @@ -60,7 +60,7 @@ and effects like cache-trashing can impose subtle penalties. force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on systems where the I/O would otherwise thrash an IOMMU mapping. (See - ``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and + :doc:`/core-api/dma-api-howto` for definitions of "coherent" and "streaming" DMA mappings.) Asking for 1/Nth of a page (as well as asking for N pages) is reasonably @@ -91,7 +91,7 @@ Working with existing buffers Existing buffers aren't usable for DMA without first being mapped into the DMA address space of the device. However, most buffers passed to your driver can safely be used with such DMA mapping. (See the first section -of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?") +of :doc:`/core-api/dma-api-howto`, titled "What memory is DMA-able?") - When you're using scatterlists, you can map everything at once. On some systems, this kicks in an IOMMU and turns the scatterlists into single diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst b/Documentation/driver-api/usb/writing_usb_driver.rst index 0b3d9ff221bb..2176297e5765 100644 --- a/Documentation/driver-api/usb/writing_usb_driver.rst +++ b/Documentation/driver-api/usb/writing_usb_driver.rst @@ -318,6 +318,6 @@ linux-usb Mailing List Archives: https://lore.kernel.org/linux-usb/ Programming Guide for Linux USB Device Drivers: -http://lmu.web.psi.ch/docu/manuals/software_manuals/linux_sl/usb_linux_programming_guide.pdf +https://lmu.web.psi.ch/docu/manuals/software_manuals/linux_sl/usb_linux_programming_guide.pdf -USB Home Page: http://www.usb.org +USB Home Page: https://www.usb.org diff --git a/Documentation/driver-api/xillybus.rst b/Documentation/driver-api/xillybus.rst index 2446ee303c09..a3ab832cb22b 100644 --- a/Documentation/driver-api/xillybus.rst +++ b/Documentation/driver-api/xillybus.rst @@ -273,7 +273,7 @@ buffer is full, the FPGA informs the host about that (appending a XILLYMSG_OPCODE_RELEASEBUF message channel 0 and sending an interrupt if necessary). The host responds by making the data available for reading through the character device. When all data has been read, the host writes on the -the FPGA's buffer control register, allowing the buffer's overwriting. Flow +FPGA's buffer control register, allowing the buffer's overwriting. Flow control mechanisms exist on both sides to prevent underflows and overflows. This is not good enough for creating a TCP/IP-like stream: If the data flow diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index f51bb21d20e4..f850ad018b70 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -24,7 +24,7 @@ Available fault injection capabilities injects disk IO errors on devices permitted by setting /sys/block//make-it-fail or - /sys/block///make-it-fail. (generic_make_request()) + /sys/block///make-it-fail. (submit_bio_noacct()) - fail_mmc_request diff --git a/Documentation/fb/ep93xx-fb.rst b/Documentation/fb/ep93xx-fb.rst index 6f7767926d1a..1dd67f4688c7 100644 --- a/Documentation/fb/ep93xx-fb.rst +++ b/Documentation/fb/ep93xx-fb.rst @@ -127,7 +127,7 @@ At least on the EP9315 there is a silicon bug which causes bit 27 of the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is an unofficial errata for this bug at:: - http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 + https://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 By default the EP93xx framebuffer driver checks if the allocated physical address has bit 27 set. If it does, then the memory is freed and an diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst index 624d08fd2856..4d2411e32ebb 100644 --- a/Documentation/fb/modedb.rst +++ b/Documentation/fb/modedb.rst @@ -152,7 +152,7 @@ To specify a video mode at bootup, use the following boot options:: video=:x[-][@refresh] where is a name from the table below. Valid default modes can be -found in linux/drivers/video/modedb.c. Check your driver's documentation. +found in drivers/video/fbdev/core/modedb.c. Check your driver's documentation. There may be more modes:: Drivers that support modedb boot options diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt b/Documentation/features/core/cBPF-JIT/arch-support.txt index 8620c38d4db0..399935616813 100644 --- a/Documentation/features/core/cBPF-JIT/arch-support.txt +++ b/Documentation/features/core/cBPF-JIT/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | ok | | um: | TODO | - | unicore32: | TODO | | x86: | TODO | | xtensa: | TODO | ----------------------- diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt index 9ed964f65224..79409bfe0263 100644 --- a/Documentation/features/core/eBPF-JIT/arch-support.txt +++ b/Documentation/features/core/eBPF-JIT/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | ok | | 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 index 365df2c2ff0b..9ea60e416efd 100644 --- a/Documentation/features/core/generic-idle-thread/arch-support.txt +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | ok | | 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 index 632a1c7aefa2..f8ec5c13cde4 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | ok | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | ok | ----------------------- diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt index 964667052eda..cd3510e2eedb 100644 --- a/Documentation/features/core/tracehook/arch-support.txt +++ b/Documentation/features/core/tracehook/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | ok | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | ok | ----------------------- diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index 6ff38548923e..c3fe9b266e7b 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | ok | ----------------------- diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index c527d05c0459..ca6bacb1e99e 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index 210256f6a4cf..7563a494ddb8 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | TODO | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | TODO | ----------------------- diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt new file mode 100644 index 000000000000..ab0ee1c933c2 --- /dev/null +++ b/Documentation/features/debug/kcov/arch-support.txt @@ -0,0 +1,33 @@ +# +# Feature name: kcov +# Kconfig: ARCH_HAS_KCOV +# description: arch supports kcov for coverage-guided fuzzing +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | TODO | + | arm: | ok | + | arm64: | ok | + | c6x: | TODO | + | csky: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m68k: | TODO | + | microblaze: | TODO | + | mips: | ok | + | nds32: | TODO | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | riscv: | ok | + | s390: | ok | + | sh: | TODO | + | sparc: | TODO | + | um: | ok | + | x86: | ok | + | xtensa: | TODO | + ----------------------- diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt index 38c40cfa0578..bc45bac20442 100644 --- a/Documentation/features/debug/kgdb/arch-support.txt +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -23,12 +23,11 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | TODO | | sh: | ok | | sparc: | ok | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | TODO | ----------------------- diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt new file mode 100644 index 000000000000..b7e4f3608838 --- /dev/null +++ b/Documentation/features/debug/kmemleak/arch-support.txt @@ -0,0 +1,33 @@ +# +# Feature name: kmemleak +# Kconfig: HAVE_DEBUG_KMEMLEAK +# description: arch supports the kernel memory leak detector +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | ok | + | arm: | ok | + | arm64: | ok | + | c6x: | TODO | + | csky: | TODO | + | h8300: | TODO | + | hexagon: | TODO | + | ia64: | TODO | + | m68k: | TODO | + | microblaze: | ok | + | mips: | ok | + | nds32: | ok | + | nios2: | TODO | + | openrisc: | TODO | + | parisc: | TODO | + | powerpc: | ok | + | riscv: | TODO | + | s390: | ok | + | sh: | ok | + | sparc: | ok | + | um: | ok | + | x86: | ok | + | xtensa: | ok | + ----------------------- diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 97cd7aa74905..6225cfe0c5bf 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index 8b316c6e03d4..371f0ac488f5 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index b805aada395e..38e95251deed 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index fb297a88f62c..7f4a20e6a12b 100644 --- a/Documentation/features/debug/optprobes/arch-support.txt +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | 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 index 12410f606edc..3db4763aa3f5 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | TODO | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | ok | ----------------------- diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index be8acbb95b54..43cac6ee0c68 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | ok | | 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 index 6bfa36b0e017..d636ed0e679f 100644 --- a/Documentation/features/debug/user-ret-profiler/arch-support.txt +++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | 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 index 895c3b0f6492..dfc93d074e3d 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | ok | ----------------------- diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt index 242ff5a6586e..1815c7fed06d 100644 --- a/Documentation/features/locking/cmpxchg-local/arch-support.txt +++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index 98cb9d85c55d..4f844ecd0680 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index ee922746a64c..5c6bcfcf8e1f 100644 --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | ok | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | ok | ----------------------- diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt index c52116c1a049..b55e420a34ea 100644 --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | ok | | 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 index 518f352fc727..04c17c2106a4 100644 --- a/Documentation/features/perf/kprobes-event/arch-support.txt +++ b/Documentation/features/perf/kprobes-event/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index c22cd6f8aa5e..e7450fbb8253 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index 527fe4d0b074..98e79d128d9b 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | TODO | ----------------------- diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 8a521a622966..68658a6f8c5b 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -51,7 +51,6 @@ | sh: | TODO | | sparc: | 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 index 350823692f28..964457ad26c1 100644 --- a/Documentation/features/sched/numa-balancing/arch-support.txt +++ b/Documentation/features/sched/numa-balancing/arch-support.txt @@ -28,7 +28,6 @@ | sh: | .. | | sparc: | 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 index c7b837f735b1..f54ddfc06a12 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | um: | ok | - | 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 index 593536f7925b..4d11cbb3c09b 100644 --- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index 7a27157da408..8287b6aa522e 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index 048bfb6d3872..a71f3a945285 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index a14bbad8e948..d9082b91f10e 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | .. | | 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 index 1d46da165b75..a84c3b9d9a94 100644 --- a/Documentation/features/time/modern-timekeeping/arch-support.txt +++ b/Documentation/features/time/modern-timekeeping/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index fb0d0cab9cab..56b372da6b01 100644 --- a/Documentation/features/time/virt-cpuacct/arch-support.txt +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index adc25878d217..eccda0732474 100644 --- a/Documentation/features/vm/ELF-ASLR/arch-support.txt +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index f05588f9e4b4..c74e3f8040e1 100644 --- a/Documentation/features/vm/PG_uncached/arch-support.txt +++ b/Documentation/features/vm/PG_uncached/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index cdfe8925f881..1c0b95f2b40d 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -28,7 +28,6 @@ | sh: | .. | | sparc: | ok | | um: | .. | - | unicore32: | .. | | x86: | ok | | xtensa: | .. | ----------------------- diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index 2bdd3b6cee3c..30f75a79ce01 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | TODO | | um: | .. | - | unicore32: | .. | | x86: | ok | | xtensa: | TODO | ----------------------- diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index 8525f1981f19..c5ff3a427722 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -28,7 +28,6 @@ | sh: | TODO | | sparc: | 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 index 3a6b87de6a19..1cb7406cd858 100644 --- a/Documentation/features/vm/ioremap_prot/arch-support.txt +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | 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 index 2e017387e228..13d0e1e17001 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -28,7 +28,6 @@ | sh: | ok | | sparc: | ok | | um: | TODO | - | unicore32: | TODO | | x86: | ok | | xtensa: | TODO | ----------------------- diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index 2995279ddc24..7b5964bc8865 100644 --- a/Documentation/filesystems/9p.rst +++ b/Documentation/filesystems/9p.rst @@ -18,7 +18,7 @@ and Maya Gokhale. Additional development by Greg Watson The best detailed explanation of the Linux implementation and applications of the 9p client is available in the form of a USENIX paper: - http://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html + https://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html Other applications are described in the following papers: diff --git a/Documentation/filesystems/afs.rst b/Documentation/filesystems/afs.rst index cada9464d6bd..0abb155ac666 100644 --- a/Documentation/filesystems/afs.rst +++ b/Documentation/filesystems/afs.rst @@ -190,7 +190,7 @@ Security Secure operations are initiated by acquiring a key using the klog program. A very primitive klog program is available at: - http://people.redhat.com/~dhowells/rxrpc/klog.c + https://people.redhat.com/~dhowells/rxrpc/klog.c This should be compiled by:: diff --git a/Documentation/filesystems/autofs-mount-control.rst b/Documentation/filesystems/autofs-mount-control.rst index 2903aed92316..bf4b511cdbe8 100644 --- a/Documentation/filesystems/autofs-mount-control.rst +++ b/Documentation/filesystems/autofs-mount-control.rst @@ -391,7 +391,7 @@ variation uses the path and optionally in.type field of struct args_ismountpoint set to an autofs mount type. The call returns 1 if this is a mount point and sets out.devid field to the device number of the mount and out.magic field to the relevant super block magic number (described below) or 0 if -it isn't a mountpoint. In both cases the the device number (as returned +it isn't a mountpoint. In both cases the device number (as returned by new_encode_dev()) is returned in out.devid field. If supplied with a file descriptor we're looking for a specific mount, @@ -399,12 +399,12 @@ not necessarily at the top of the mounted stack. In this case the path the descriptor corresponds to is considered a mountpoint if it is itself a mountpoint or contains a mount, such as a multi-mount without a root mount. In this case we return 1 if the descriptor corresponds to a mount -point and and also returns the super magic of the covering mount if there +point and also returns the super magic of the covering mount if there is one or 0 if it isn't a mountpoint. If a path is supplied (and the ioctlfd field is set to -1) then the path is looked up and is checked to see if it is the root of a mount. If a type is also given we are looking for a particular autofs mount and if -a match isn't found a fail is returned. If the the located path is the +a match isn't found a fail is returned. If the located path is the root of a mount 1 is returned along with the super magic of the mount or 0 otherwise. diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst index 65d3db476765..e58bc1fd312a 100644 --- a/Documentation/filesystems/caching/cachefiles.rst +++ b/Documentation/filesystems/caching/cachefiles.rst @@ -348,7 +348,7 @@ data cached therein; nor is it permitted to create new files in the cache. There are policy source files available in: - http://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2 + https://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2 and later versions. In that tarball, see the files:: diff --git a/Documentation/filesystems/caching/operations.rst b/Documentation/filesystems/caching/operations.rst index f7ddcc028939..9983e1675447 100644 --- a/Documentation/filesystems/caching/operations.rst +++ b/Documentation/filesystems/caching/operations.rst @@ -27,7 +27,7 @@ data storage and retrieval routines. Its operations are represented by fscache_operation structs, though these are usually embedded into some other structure. -This facility is available to and expected to be be used by the cache backends, +This facility is available to and expected to be used by the cache backends, and FS-Cache will create operations and pass them off to the appropriate cache backend for completion. diff --git a/Documentation/filesystems/coda.rst b/Documentation/filesystems/coda.rst index 84c860c89887..bdde7e4e010b 100644 --- a/Documentation/filesystems/coda.rst +++ b/Documentation/filesystems/coda.rst @@ -524,7 +524,7 @@ kernel support. Description This call is made to determine the ViceFid and filetype of - a directory entry. The directory entry requested carries name name + a directory entry. The directory entry requested carries name 'name' and Venus will search the directory identified by cfs_lookup_in.VFid. The result may indicate that the name does not exist, or that difficulty was encountered in finding it (e.g. due to disconnection). @@ -886,7 +886,7 @@ kernel support. none Description - Remove the directory with name name from the directory + Remove the directory with name 'name' from the directory identified by VFid. .. Note:: The attributes of the parent directory should be returned since diff --git a/Documentation/filesystems/configfs.rst b/Documentation/filesystems/configfs.rst index f8941954c667..1d3d6f4a82a9 100644 --- a/Documentation/filesystems/configfs.rst +++ b/Documentation/filesystems/configfs.rst @@ -226,7 +226,7 @@ filename. configfs_attribute->ca_mode specifies the file permissions. If an attribute is readable and provides a ->show method, that method will be called whenever userspace asks for a read(2) on the attribute. If an attribute is writable and provides a ->store method, that method will be -be called whenever userspace asks for a write(2) on the attribute. +called whenever userspace asks for a write(2) on the attribute. struct configfs_bin_attribute ============================= diff --git a/Documentation/filesystems/debugfs.rst b/Documentation/filesystems/debugfs.rst index 1da7a4b7383d..728ab57a611a 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst @@ -185,13 +185,17 @@ byte offsets over a base for the register block. If you want to dump an u32 array in debugfs, you can create file with:: + struct debugfs_u32_array { + u32 *array; + u32 n_elements; + }; + void debugfs_create_u32_array(const char *name, umode_t mode, struct dentry *parent, - u32 *array, u32 elements); + struct debugfs_u32_array *array); -The "array" argument provides data, and the "elements" argument is -the number of elements in the array. Note: Once array is created its -size can not be changed. +The "array" argument wraps a pointer to the array's data and the number +of its elements. Note: Once array is created its size can not be changed. There is a helper function to create device related seq_file:: diff --git a/Documentation/filesystems/directory-locking.rst b/Documentation/filesystems/directory-locking.rst index de12016ee419..504ba940c36c 100644 --- a/Documentation/filesystems/directory-locking.rst +++ b/Documentation/filesystems/directory-locking.rst @@ -28,7 +28,7 @@ RENAME_EXCHANGE in flags argument) lock both. In any case, if the target already exists, lock it. If the source is a non-directory, lock it. If we need to lock both, lock them in inode pointer order. Then call the method. All locks are exclusive. -NB: we might get away with locking the the source (and target in exchange +NB: we might get away with locking the source (and target in exchange case) shared. 5) link creation. Locking rules: @@ -56,7 +56,7 @@ rules: * call the method. All ->i_rwsem are taken exclusive. Again, we might get away with locking -the the source (and target in exchange case) shared. +the source (and target in exchange case) shared. The rules above obviously guarantee that all directories that are going to be read, modified or removed by method will be locked by caller. diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 099d45ac8d8f..a11d329542f9 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -101,164 +101,170 @@ Mount Options ============= -====================== ============================================================ -background_gc=%s Turn on/off cleaning operations, namely garbage - collection, triggered in background when I/O subsystem is - idle. If background_gc=on, it will turn on the garbage - collection and if background_gc=off, garbage collection - will be turned off. If background_gc=sync, it will turn - on synchronous garbage collection running in background. - Default value for this option is on. So garbage - collection is on by default. -disable_roll_forward Disable the roll-forward recovery routine -norecovery Disable the roll-forward recovery routine, mounted read- - only (i.e., -o ro,disable_roll_forward) -discard/nodiscard Enable/disable real-time discard in f2fs, if discard is - enabled, f2fs will issue discard/TRIM commands when a - segment is cleaned. -no_heap Disable heap-style segment allocation which finds free - segments for data from the beginning of main area, while - for node from the end of main area. -nouser_xattr Disable Extended User Attributes. Note: xattr is enabled - by default if CONFIG_F2FS_FS_XATTR is selected. -noacl Disable POSIX Access Control List. Note: acl is enabled - by default if CONFIG_F2FS_FS_POSIX_ACL is selected. -active_logs=%u Support configuring the number of active logs. In the - current design, f2fs supports only 2, 4, and 6 logs. - Default number is 6. -disable_ext_identify Disable the extension list configured by mkfs, so f2fs - does not aware of cold files such as media files. -inline_xattr Enable the inline xattrs feature. -noinline_xattr Disable the inline xattrs feature. -inline_xattr_size=%u Support configuring inline xattr size, it depends on - flexible inline xattr feature. -inline_data Enable the inline data feature: New created small(<~3.4k) - files can be written into inode block. -inline_dentry Enable the inline dir feature: data in new created - directory entries can be written into inode block. The - space of inode block which is used to store inline - dentries is limited to ~3.4k. -noinline_dentry Disable the inline dentry feature. -flush_merge Merge concurrent cache_flush commands as much as possible - to eliminate redundant command issues. If the underlying - device handles the cache_flush command relatively slowly, - recommend to enable this option. -nobarrier This option can be used if underlying storage guarantees - its cached data should be written to the novolatile area. - If this option is set, no cache_flush commands are issued - but f2fs still guarantees the write ordering of all the - data writes. -fastboot This option is used when a system wants to reduce mount - time as much as possible, even though normal performance - can be sacrificed. -extent_cache Enable an extent cache based on rb-tree, it can cache - as many as extent which map between contiguous logical - address and physical address per inode, resulting in - increasing the cache hit ratio. Set by default. -noextent_cache Disable an extent cache based on rb-tree explicitly, see - the above extent_cache mount option. -noinline_data Disable the inline data feature, inline data feature is - enabled by default. -data_flush Enable data flushing before checkpoint in order to - persist data of regular and symlink. -reserve_root=%d Support configuring reserved space which is used for - allocation from a privileged user with specified uid or - gid, unit: 4KB, the default limit is 0.2% of user blocks. -resuid=%d The user ID which may use the reserved blocks. -resgid=%d The group ID which may use the reserved blocks. -fault_injection=%d Enable fault injection in all supported types with - specified injection rate. -fault_type=%d Support configuring fault injection type, should be - enabled with fault_injection option, fault type value - is shown below, it supports single or combined type. +======================== ============================================================ +background_gc=%s Turn on/off cleaning operations, namely garbage + collection, triggered in background when I/O subsystem is + idle. If background_gc=on, it will turn on the garbage + collection and if background_gc=off, garbage collection + will be turned off. If background_gc=sync, it will turn + on synchronous garbage collection running in background. + Default value for this option is on. So garbage + collection is on by default. +disable_roll_forward Disable the roll-forward recovery routine +norecovery Disable the roll-forward recovery routine, mounted read- + only (i.e., -o ro,disable_roll_forward) +discard/nodiscard Enable/disable real-time discard in f2fs, if discard is + enabled, f2fs will issue discard/TRIM commands when a + segment is cleaned. +no_heap Disable heap-style segment allocation which finds free + segments for data from the beginning of main area, while + for node from the end of main area. +nouser_xattr Disable Extended User Attributes. Note: xattr is enabled + by default if CONFIG_F2FS_FS_XATTR is selected. +noacl Disable POSIX Access Control List. Note: acl is enabled + by default if CONFIG_F2FS_FS_POSIX_ACL is selected. +active_logs=%u Support configuring the number of active logs. In the + current design, f2fs supports only 2, 4, and 6 logs. + Default number is 6. +disable_ext_identify Disable the extension list configured by mkfs, so f2fs + does not aware of cold files such as media files. +inline_xattr Enable the inline xattrs feature. +noinline_xattr Disable the inline xattrs feature. +inline_xattr_size=%u Support configuring inline xattr size, it depends on + flexible inline xattr feature. +inline_data Enable the inline data feature: New created small(<~3.4k) + files can be written into inode block. +inline_dentry Enable the inline dir feature: data in new created + directory entries can be written into inode block. The + space of inode block which is used to store inline + dentries is limited to ~3.4k. +noinline_dentry Disable the inline dentry feature. +flush_merge Merge concurrent cache_flush commands as much as possible + to eliminate redundant command issues. If the underlying + device handles the cache_flush command relatively slowly, + recommend to enable this option. +nobarrier This option can be used if underlying storage guarantees + its cached data should be written to the novolatile area. + If this option is set, no cache_flush commands are issued + but f2fs still guarantees the write ordering of all the + data writes. +fastboot This option is used when a system wants to reduce mount + time as much as possible, even though normal performance + can be sacrificed. +extent_cache Enable an extent cache based on rb-tree, it can cache + as many as extent which map between contiguous logical + address and physical address per inode, resulting in + increasing the cache hit ratio. Set by default. +noextent_cache Disable an extent cache based on rb-tree explicitly, see + the above extent_cache mount option. +noinline_data Disable the inline data feature, inline data feature is + enabled by default. +data_flush Enable data flushing before checkpoint in order to + persist data of regular and symlink. +reserve_root=%d Support configuring reserved space which is used for + allocation from a privileged user with specified uid or + gid, unit: 4KB, the default limit is 0.2% of user blocks. +resuid=%d The user ID which may use the reserved blocks. +resgid=%d The group ID which may use the reserved blocks. +fault_injection=%d Enable fault injection in all supported types with + specified injection rate. +fault_type=%d Support configuring fault injection type, should be + enabled with fault_injection option, fault type value + is shown below, it supports single or combined type. - =================== =========== - Type_Name Type_Value - =================== =========== - FAULT_KMALLOC 0x000000001 - FAULT_KVMALLOC 0x000000002 - FAULT_PAGE_ALLOC 0x000000004 - FAULT_PAGE_GET 0x000000008 - FAULT_ALLOC_BIO 0x000000010 - FAULT_ALLOC_NID 0x000000020 - FAULT_ORPHAN 0x000000040 - FAULT_BLOCK 0x000000080 - FAULT_DIR_DEPTH 0x000000100 - FAULT_EVICT_INODE 0x000000200 - FAULT_TRUNCATE 0x000000400 - FAULT_READ_IO 0x000000800 - FAULT_CHECKPOINT 0x000001000 - FAULT_DISCARD 0x000002000 - FAULT_WRITE_IO 0x000004000 - =================== =========== -mode=%s Control block allocation mode which supports "adaptive" - and "lfs". In "lfs" mode, there should be no random - writes towards main area. -io_bits=%u Set the bit size of write IO requests. It should be set - with "mode=lfs". -usrquota Enable plain user disk quota accounting. -grpquota Enable plain group disk quota accounting. -prjquota Enable plain project quota accounting. -usrjquota= Appoint specified file and type during mount, so that quota -grpjquota= information can be properly updated during recovery flow, -prjjquota= : must be in root directory; -jqfmt= : [vfsold,vfsv0,vfsv1]. -offusrjquota Turn off user journelled quota. -offgrpjquota Turn off group journelled quota. -offprjjquota Turn off project journelled quota. -quota Enable plain user disk quota accounting. -noquota Disable all plain disk quota option. -whint_mode=%s Control which write hints are passed down to block - layer. This supports "off", "user-based", and - "fs-based". In "off" mode (default), f2fs does not pass - down hints. In "user-based" mode, f2fs tries to pass - down hints given by users. And in "fs-based" mode, f2fs - passes down hints with its policy. -alloc_mode=%s Adjust block allocation policy, which supports "reuse" - and "default". -fsync_mode=%s Control the policy of fsync. Currently supports "posix", - "strict", and "nobarrier". In "posix" mode, which is - default, fsync will follow POSIX semantics and does a - light operation to improve the filesystem performance. - In "strict" mode, fsync will be heavy and behaves in line - with xfs, ext4 and btrfs, where xfstest generic/342 will - pass, but the performance will regress. "nobarrier" is - based on "posix", but doesn't issue flush command for - non-atomic files likewise "nobarrier" mount option. + =================== =========== + Type_Name Type_Value + =================== =========== + FAULT_KMALLOC 0x000000001 + FAULT_KVMALLOC 0x000000002 + FAULT_PAGE_ALLOC 0x000000004 + FAULT_PAGE_GET 0x000000008 + FAULT_ALLOC_BIO 0x000000010 + FAULT_ALLOC_NID 0x000000020 + FAULT_ORPHAN 0x000000040 + FAULT_BLOCK 0x000000080 + FAULT_DIR_DEPTH 0x000000100 + FAULT_EVICT_INODE 0x000000200 + FAULT_TRUNCATE 0x000000400 + FAULT_READ_IO 0x000000800 + FAULT_CHECKPOINT 0x000001000 + FAULT_DISCARD 0x000002000 + FAULT_WRITE_IO 0x000004000 + =================== =========== +mode=%s Control block allocation mode which supports "adaptive" + and "lfs". In "lfs" mode, there should be no random + writes towards main area. +io_bits=%u Set the bit size of write IO requests. It should be set + with "mode=lfs". +usrquota Enable plain user disk quota accounting. +grpquota Enable plain group disk quota accounting. +prjquota Enable plain project quota accounting. +usrjquota= Appoint specified file and type during mount, so that quota +grpjquota= information can be properly updated during recovery flow, +prjjquota= : must be in root directory; +jqfmt= : [vfsold,vfsv0,vfsv1]. +offusrjquota Turn off user journelled quota. +offgrpjquota Turn off group journelled quota. +offprjjquota Turn off project journelled quota. +quota Enable plain user disk quota accounting. +noquota Disable all plain disk quota option. +whint_mode=%s Control which write hints are passed down to block + layer. This supports "off", "user-based", and + "fs-based". In "off" mode (default), f2fs does not pass + down hints. In "user-based" mode, f2fs tries to pass + down hints given by users. And in "fs-based" mode, f2fs + passes down hints with its policy. +alloc_mode=%s Adjust block allocation policy, which supports "reuse" + and "default". +fsync_mode=%s Control the policy of fsync. Currently supports "posix", + "strict", and "nobarrier". In "posix" mode, which is + default, fsync will follow POSIX semantics and does a + light operation to improve the filesystem performance. + In "strict" mode, fsync will be heavy and behaves in line + with xfs, ext4 and btrfs, where xfstest generic/342 will + pass, but the performance will regress. "nobarrier" is + based on "posix", but doesn't issue flush command for + non-atomic files likewise "nobarrier" mount option. test_dummy_encryption test_dummy_encryption=%s - Enable dummy encryption, which provides a fake fscrypt - context. The fake fscrypt context is used by xfstests. - The argument may be either "v1" or "v2", in order to - select the corresponding fscrypt policy version. -checkpoint=%s[:%u[%]] Set to "disable" to turn off checkpointing. Set to "enable" - to reenable checkpointing. Is enabled by default. While - disabled, any unmounting or unexpected shutdowns will cause - the filesystem contents to appear as they did when the - filesystem was mounted with that option. - While mounting with checkpoint=disabled, the filesystem must - run garbage collection to ensure that all available space can - be used. If this takes too much time, the mount may return - EAGAIN. You may optionally add a value to indicate how much - of the disk you would be willing to temporarily give up to - avoid additional garbage collection. This can be given as a - number of blocks, or as a percent. For instance, mounting - with checkpoint=disable:100% would always succeed, but it may - hide up to all remaining free space. The actual space that - would be unusable can be viewed at /sys/fs/f2fs//unusable - This space is reclaimed once checkpoint=enable. -compress_algorithm=%s Control compress algorithm, currently f2fs supports "lzo", - "lz4", "zstd" and "lzo-rle" algorithm. -compress_log_size=%u Support configuring compress cluster size, the size will - be 4KB * (1 << %u), 16KB is minimum size, also it's - default size. -compress_extension=%s Support adding specified extension, so that f2fs can enable - compression on those corresponding files, e.g. if all files - with '.ext' has high compression rate, we can set the '.ext' - on compression extension list and enable compression on - these file by default rather than to enable it via ioctl. - For other files, we can still enable compression via ioctl. -====================== ============================================================ + Enable dummy encryption, which provides a fake fscrypt + context. The fake fscrypt context is used by xfstests. + The argument may be either "v1" or "v2", in order to + select the corresponding fscrypt policy version. +checkpoint=%s[:%u[%]] Set to "disable" to turn off checkpointing. Set to "enable" + to reenable checkpointing. Is enabled by default. While + disabled, any unmounting or unexpected shutdowns will cause + the filesystem contents to appear as they did when the + filesystem was mounted with that option. + While mounting with checkpoint=disabled, the filesystem must + run garbage collection to ensure that all available space can + be used. If this takes too much time, the mount may return + EAGAIN. You may optionally add a value to indicate how much + of the disk you would be willing to temporarily give up to + avoid additional garbage collection. This can be given as a + number of blocks, or as a percent. For instance, mounting + with checkpoint=disable:100% would always succeed, but it may + hide up to all remaining free space. The actual space that + would be unusable can be viewed at /sys/fs/f2fs//unusable + This space is reclaimed once checkpoint=enable. +compress_algorithm=%s Control compress algorithm, currently f2fs supports "lzo", + "lz4", "zstd" and "lzo-rle" algorithm. +compress_log_size=%u Support configuring compress cluster size, the size will + be 4KB * (1 << %u), 16KB is minimum size, also it's + default size. +compress_extension=%s Support adding specified extension, so that f2fs can enable + compression on those corresponding files, e.g. if all files + with '.ext' has high compression rate, we can set the '.ext' + on compression extension list and enable compression on + these file by default rather than to enable it via ioctl. + For other files, we can still enable compression via ioctl. +inlinecrypt When possible, encrypt/decrypt the contents of encrypted + files using the blk-crypto framework rather than + filesystem-layer encryption. This allows the use of + inline encryption hardware. The on-disk format is + unaffected. For more details, see + Documentation/block/inline-encryption.rst. +======================== ============================================================ Debugfs Entries =============== diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index f517af8ec11c..423c5a0daf45 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -1158,7 +1158,7 @@ setxattr() because of the special semantics of the encryption xattr. were to be added to or removed from anything other than an empty directory.) These structs are defined as follows:: - #define FS_KEY_DERIVATION_NONCE_SIZE 16 + #define FSCRYPT_FILE_NONCE_SIZE 16 #define FSCRYPT_KEY_DESCRIPTOR_SIZE 8 struct fscrypt_context_v1 { @@ -1167,7 +1167,7 @@ directory.) These structs are defined as follows:: u8 filenames_encryption_mode; u8 flags; u8 master_key_descriptor[FSCRYPT_KEY_DESCRIPTOR_SIZE]; - u8 nonce[FS_KEY_DERIVATION_NONCE_SIZE]; + u8 nonce[FSCRYPT_FILE_NONCE_SIZE]; }; #define FSCRYPT_KEY_IDENTIFIER_SIZE 16 @@ -1178,7 +1178,7 @@ directory.) These structs are defined as follows:: u8 flags; u8 __reserved[4]; u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE]; - u8 nonce[FS_KEY_DERIVATION_NONCE_SIZE]; + u8 nonce[FSCRYPT_FILE_NONCE_SIZE]; }; The context structs contain the same information as the corresponding @@ -1204,6 +1204,18 @@ buffer. Some filesystems, such as UBIFS, already use temporary buffers regardless of encryption. Other filesystems, such as ext4 and F2FS, have to allocate bounce pages specially for encryption. +Fscrypt is also able to use inline encryption hardware instead of the +kernel crypto API for en/decryption of file contents. When possible, +and if directed to do so (by specifying the 'inlinecrypt' mount option +for an ext4/F2FS filesystem), it adds encryption contexts to bios and +uses blk-crypto to perform the en/decryption instead of making use of +the above read/write path changes. Of course, even if directed to +make use of inline encryption, fscrypt will only be able to do so if +either hardware inline encryption support is available for the +selected encryption algorithm or CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK +is selected. If neither is the case, fscrypt will fall back to using +the above mentioned read/write path changes for en/decryption. + Filename hashing and encoding ----------------------------- @@ -1250,11 +1262,14 @@ Tests To test fscrypt, use xfstests, which is Linux's de facto standard filesystem test suite. First, run all the tests in the "encrypt" -group on the relevant filesystem(s). For example, to test ext4 and +group on the relevant filesystem(s). One can also run the tests +with the 'inlinecrypt' mount option to test the implementation for +inline encryption support. For example, to test ext4 and f2fs encryption using `kvm-xfstests `_:: kvm-xfstests -c ext4,f2fs -g encrypt + kvm-xfstests -c ext4,f2fs -g encrypt -m inlinecrypt UBIFS encryption can also be tested this way, but it should be done in a separate command, and it takes some time for kvm-xfstests to set up @@ -1276,6 +1291,7 @@ This tests the encrypted I/O paths more thoroughly. To do this with kvm-xfstests, use the "encrypt" filesystem configuration:: kvm-xfstests -c ext4/encrypt,f2fs/encrypt -g auto + kvm-xfstests -c ext4/encrypt,f2fs/encrypt -g auto -m inlinecrypt Because this runs many more tests than "-g encrypt" does, it takes much longer to run; so also consider using `gce-xfstests @@ -1283,3 +1299,4 @@ much longer to run; so also consider using `gce-xfstests instead of kvm-xfstests:: gce-xfstests -c ext4/encrypt,f2fs/encrypt -g auto + gce-xfstests -c ext4/encrypt,f2fs/encrypt -g auto -m inlinecrypt diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index a95536b6443c..6c8944f6f0f7 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -659,7 +659,7 @@ weren't already directly answered in other parts of this document. retrofit existing filesystems with new consistency mechanisms. Data journalling is available on ext4, but is very slow. - - Rebuilding the the Merkle tree after every write, which would be + - Rebuilding the Merkle tree after every write, which would be extremely inefficient. Alternatively, a different authenticated dictionary structure such as an "authenticated skiplist" could be used. However, this would be far more complex. diff --git a/Documentation/filesystems/hfs.rst b/Documentation/filesystems/hfs.rst index ab17a005e9b1..776015c80e3f 100644 --- a/Documentation/filesystems/hfs.rst +++ b/Documentation/filesystems/hfs.rst @@ -76,7 +76,7 @@ Creating HFS filesystems The hfsutils package from Robert Leslie contains a program called hformat that can be used to create HFS filesystem. See - for details. + for details. Credits diff --git a/Documentation/filesystems/hpfs.rst b/Documentation/filesystems/hpfs.rst index 0db152278572..7e0dd2f4373e 100644 --- a/Documentation/filesystems/hpfs.rst +++ b/Documentation/filesystems/hpfs.rst @@ -7,7 +7,7 @@ Read/Write HPFS 2.09 1998-2004, Mikulas Patocka :email: mikulas@artax.karlin.mff.cuni.cz -:homepage: http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/hpfs/index-e.cgi +:homepage: https://artax.karlin.mff.cuni.cz/~mikulas/vyplody/hpfs/index-e.cgi Credits ======= diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 318605de83f3..64f94a18d97e 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -433,15 +433,15 @@ prototypes:: locking rules: -========== ============= ================= ========= +====================== ============= ================= ========= ops inode->i_lock blocked_lock_lock may block -========== ============= ================= ========= +====================== ============= ================= ========= lm_notify: yes yes no lm_grant: no no no lm_break: yes no no lm_change yes no no lm_breaker_owns_lease: no no no -========== ============= ================= ========= +====================== ============= ================= ========= buffer_head =========== @@ -467,7 +467,6 @@ prototypes:: int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long); int (*direct_access) (struct block_device *, sector_t, void **, unsigned long *); - int (*media_changed) (struct gendisk *); void (*unlock_native_capacity) (struct gendisk *); int (*revalidate_disk) (struct gendisk *); int (*getgeo)(struct block_device *, struct hd_geometry *); @@ -483,14 +482,13 @@ release: yes ioctl: no compat_ioctl: no direct_access: no -media_changed: no unlock_native_capacity: no revalidate_disk: no getgeo: no swap_slot_free_notify: no (see below) ======================= =================== -media_changed, unlock_native_capacity and revalidate_disk are called only from +unlock_native_capacity and revalidate_disk are called only from check_disk_change(). swap_slot_free_notify is called with swap_lock and sometimes the page lock @@ -616,9 +614,9 @@ prototypes:: locking rules: -============= ======== =========================== +============= ========= =========================== ops mmap_lock PageLocked(page) -============= ======== =========================== +============= ========= =========================== open: yes close: yes fault: yes can return with page locked @@ -626,7 +624,7 @@ map_pages: yes page_mkwrite: yes can return with page locked pfn_mkwrite: yes access: yes -============= ======== =========================== +============= ========= =========================== ->fault() is called when a previously not present pte is about to be faulted in. The filesystem must find and return the page associated diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst index dea22d64f060..29c169c68961 100644 --- a/Documentation/filesystems/mount_api.rst +++ b/Documentation/filesystems/mount_api.rst @@ -213,7 +213,7 @@ The filesystem context points to a table of operations:: void (*free)(struct fs_context *fc); int (*dup)(struct fs_context *fc, struct fs_context *src_fc); int (*parse_param)(struct fs_context *fc, - struct struct fs_parameter *param); + struct fs_parameter *param); int (*parse_monolithic)(struct fs_context *fc, void *data); int (*get_tree)(struct fs_context *fc); int (*reconfigure)(struct fs_context *fc); @@ -247,7 +247,7 @@ manage the filesystem context. They are as follows: * :: int (*parse_param)(struct fs_context *fc, - struct struct fs_parameter *param); + struct fs_parameter *param); Called when a parameter is being added to the filesystem context. param points to the key name and maybe a value object. VFS-specific options diff --git a/Documentation/filesystems/nfs/rpc-server-gss.rst b/Documentation/filesystems/nfs/rpc-server-gss.rst index 812754576845..abed4a2b1b82 100644 --- a/Documentation/filesystems/nfs/rpc-server-gss.rst +++ b/Documentation/filesystems/nfs/rpc-server-gss.rst @@ -10,12 +10,12 @@ purposes of authentication.) RPCGSS is specified in a few IETF documents: - - RFC2203 v1: http://tools.ietf.org/rfc/rfc2203.txt - - RFC5403 v2: http://tools.ietf.org/rfc/rfc5403.txt + - RFC2203 v1: https://tools.ietf.org/rfc/rfc2203.txt + - RFC5403 v2: https://tools.ietf.org/rfc/rfc5403.txt and there is a 3rd version being proposed: - - http://tools.ietf.org/id/draft-williams-rpcsecgssv3.txt + - https://tools.ietf.org/id/draft-williams-rpcsecgssv3.txt (At draft n. 02 at the time of writing) Background diff --git a/Documentation/filesystems/omfs.rst b/Documentation/filesystems/omfs.rst index 4c8bb3074169..a104c25b7a2f 100644 --- a/Documentation/filesystems/omfs.rst +++ b/Documentation/filesystems/omfs.rst @@ -24,7 +24,7 @@ More information is available at: Various utilities, including mkomfs and omfsck, are included with omfsprogs, available at: - http://bobcopeland.com/karma/ + https://bobcopeland.com/karma/ Instructions are included in its README. diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index fcda5d6ba9ac..8ea83a51c266 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -328,7 +328,7 @@ the time of copy (on-demand vs. up-front). Multiple lower layers --------------------- -Multiple lower layers can now be given using the the colon (":") as a +Multiple lower layers can now be given using the colon (":") as a separator character between the directory names. For example: mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index f46b05e9b96c..c482e1619e77 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -43,15 +43,15 @@ characters, and "components" that are sequences of one or more non-"``/``" characters. These form two kinds of paths. Those that start with slashes are "absolute" and start from the filesystem root. The others are "relative" and start from the current directory, or -from some other location specified by a file descriptor given to a -"``XXXat``" system call such as `openat() `_. +from some other location specified by a file descriptor given to +"``*at()``" system calls such as `openat() `_. .. _execveat: http://man7.org/linux/man-pages/man2/execveat.2.html It is tempting to describe the second kind as starting with a component, but that isn't always accurate: a pathname can lack both slashes and components, it can be empty, in other words. This is -generally forbidden in POSIX, but some of those "xxx``at``" system calls +generally forbidden in POSIX, but some of those "``*at()``" system calls in Linux permit it when the ``AT_EMPTY_PATH`` flag is given. For example, if you have an open file descriptor on an executable file you can execute it by calling `execveat() `_ passing @@ -69,17 +69,17 @@ pathname that is just slashes have a final component. If it does exist, it could be "``.``" or "``..``" which are handled quite differently from other components. -.. _POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12 +.. _POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12 If a pathname ends with a slash, such as "``/tmp/foo/``" it might be tempting to consider that to have an empty final component. In many ways that would lead to correct results, but not always. In particular, ``mkdir()`` and ``rmdir()`` each create or remove a directory named by the final component, and they are required to work with pathnames -ending in "``/``". According to POSIX_ +ending in "``/``". According to POSIX_: - A pathname that contains at least one non- <slash> character and - that ends with one or more trailing <slash> characters shall not + A pathname that contains at least one non- character and + that ends with one or more trailing characters shall not be resolved successfully unless the last pathname component before the trailing characters names an existing directory or a directory entry that is to be created for a directory immediately @@ -229,7 +229,7 @@ happened to be looking at a dentry that was moved in this way, it might end up continuing the search down the wrong chain, and so miss out on part of the correct chain. -The name-lookup process (``d_lookup()``) does _not_ try to prevent this +The name-lookup process (``d_lookup()``) does *not* try to prevent this from happening, but only to detect when it happens. ``rename_lock`` is a seqlock that is updated whenever any dentry is renamed. If ``d_lookup`` finds that a rename happened while it @@ -376,7 +376,7 @@ table, and the mount point hash table. Bringing it together with ``struct nameidata`` ---------------------------------------------- -.. _First edition Unix: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s +.. _First edition Unix: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s Throughout the process of walking a path, the current status is stored in a ``struct nameidata``, "namei" being the traditional name - dating @@ -398,7 +398,7 @@ held. ``struct qstr last`` ~~~~~~~~~~~~~~~~~~~~ -This is a string together with a length (i.e. _not_ ``nul`` terminated) +This is a string together with a length (i.e. *not* ``nul`` terminated) that is the "next" component in the pathname. ``int last_type`` @@ -655,8 +655,8 @@ This pattern of "try RCU-walk, if that fails try REF-walk" can be clearly seen in functions like ``filename_lookup()``, ``filename_parentat()``, ``filename_mountpoint()``, ``do_filp_open()``, and ``do_file_open_root()``. These five -correspond roughly to the four ``path_``* functions we met earlier, -each of which calls ``link_path_walk()``. The ``path_*`` functions are +correspond roughly to the four ``path_*()`` functions we met earlier, +each of which calls ``link_path_walk()``. The ``path_*()`` functions are called using different mode flags until a mode is found which works. They are first called with ``LOOKUP_RCU`` set to request "RCU-walk". If that fails with the error ``ECHILD`` they are called again with no @@ -720,7 +720,7 @@ against a dentry. The length and name pointer are copied into local variables, then ``read_seqcount_retry()`` is called to confirm the two are consistent, and only then is ``->d_compare()`` called. When standard filename comparison is used, ``dentry_cmp()`` is called -instead. Notably it does _not_ use ``read_seqcount_retry()``, but +instead. Notably it does *not* use ``read_seqcount_retry()``, but instead has a large comment explaining why the consistency guarantee isn't necessary. A subsequent ``read_seqcount_retry()`` will be sufficient to catch any problem that could occur at this point. @@ -928,7 +928,7 @@ if anything goes wrong it is much safer to just abort and try a more sedate approach. The emphasis here is "try quickly and check". It should probably be -"try quickly _and carefully,_ then check". The fact that checking is +"try quickly *and carefully*, then check". The fact that checking is needed is a reminder that the system is dynamic and only a limited number of things are safe at all. The most likely cause of errors in this whole process is assuming something is safe when in reality it @@ -1265,7 +1265,7 @@ Symlinks are different it seems. Both reading a symlink (with ``readlink()``) and looking up a symlink on the way to some other destination can update the atime on that symlink. -.. _clearest statement: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_08 +.. _clearest statement: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_08 It is not clear why this is the case; POSIX has little to say on the subject. The `clearest statement`_ is that, if a particular implementation @@ -1365,7 +1365,7 @@ as well as blocking ".." if it would jump outside the starting point. resolution of "..". Magic-links are also blocked. ``LOOKUP_IN_ROOT`` resolves all path components as though the starting point -were the filesystem root. ``nd_jump_root()`` brings the resolution back to to +were the filesystem root. ``nd_jump_root()`` brings the resolution back to the starting point, and ".." at the starting point will act as a no-op. As with ``LOOKUP_BENEATH``, ``rename_lock`` and ``mount_lock`` are used to detect attacks against ".." resolution. Magic-links are also blocked. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 996f3cfe7030..e024a9efffd8 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -123,10 +123,10 @@ show you how you can use /proc/sys to change settings. The directory /proc contains (among other things) one subdirectory for each process running on the system, which is named after the process ID (PID). -The link self points to the process reading the file system. Each process +The link 'self' points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. -Note that an open a file descriptor to /proc/ or to any of its +Note that an open file descriptor to /proc/ or to any of its contained files or subdirectories does not prevent being reused for some other process in the event that exits. Operations on open /proc/ file descriptors corresponding to dead processes @@ -220,7 +220,7 @@ file /proc/PID/status. It fields are described in table 1-2. The statm file contains more detailed information about the process memory usage. Its seven fields are explained in Table 1-3. The stat file -contains details information about the process itself. Its fields are +contains detailed information about the process itself. Its fields are explained in Table 1-4. (for SMP CONFIG users) @@ -545,7 +545,7 @@ encoded manner. The codes are the following: hg huge page advise flag nh no huge page advise flag mg mergable advise flag - bt - arm64 BTI guarded page + bt arm64 BTI guarded page == ======================================= Note that there is no guarantee that every flag and associated mnemonic will @@ -782,7 +782,7 @@ SPU For this case the APIC will generate the interrupt with a IRQ vector of 0xff. This might also be generated by chipset bugs. -RES, CAL, TLB] +RES, CAL, TLB rescheduling, call and TLB flush interrupts are sent from one CPU to another per the needs of the OS. Typically, their statistics are used by kernel developers and interested users to @@ -794,7 +794,7 @@ suppressed when the system is a uniprocessor. As of this writing, only i386 and x86_64 platforms support the new IRQ vector displays. Of some interest is the introduction of the /proc/irq directory to 2.4. -It could be used to set IRQ to CPU affinity, this means that you can "hook" an +It could be used to set IRQ to CPU affinity. This means that you can "hook" an IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the irq subdir is one subdir for each IRQ, and two files; default_smp_affinity and prof_cpu_mask. @@ -808,7 +808,7 @@ For example:: smp_affinity smp_affinity is a bitmask, in which you can specify which CPUs can handle the -IRQ, you can set it by doing:: +IRQ. You can set it by doing:: > echo 1 > /proc/irq/10/smp_affinity @@ -821,7 +821,7 @@ The contents of each smp_affinity file is the same by default:: ffffffff There is an alternate interface, smp_affinity_list which allows specifying -a cpu range instead of a bitmask:: +a CPU range instead of a bitmask:: > cat /proc/irq/0/smp_affinity_list 1024-1031 @@ -835,7 +835,7 @@ reports itself as being attached. This hardware locality information does not include information about any possible driver locality preference. prof_cpu_mask specifies which CPUs are to be profiled by the system wide -profiler. Default value is ffffffff (all cpus if there are only 32 of them). +profiler. Default value is ffffffff (all CPUs if there are only 32 of them). The way IRQs are routed is handled by the IO-APIC, and it's Round Robin between all the CPUs which are allowed to handle it. As usual the kernel has @@ -897,7 +897,7 @@ pagetypeinfo:: Fragmentation avoidance in the kernel works by grouping pages of different migrate types into the same contiguous regions of memory called page blocks. -A page block is typically the size of the default hugepage size e.g. 2MB on +A page block is typically the size of the default hugepage size, e.g. 2MB on X86-64. By keeping pages grouped based on their ability to move, the kernel can reclaim pages within a page block to satisfy a high-order allocation. @@ -965,7 +965,7 @@ varies by architecture and compile options. The following is from a ShmemPmdMapped: 0 kB MemTotal - Total usable ram (i.e. physical ram minus a few reserved + Total usable RAM (i.e. physical RAM minus a few reserved bits and the kernel binary code) MemFree The sum of LowFree+HighFree @@ -996,7 +996,7 @@ Inactive Memory which has been less recently used. It is more eligible to be reclaimed for other purposes HighTotal, HighFree - Highmem is all memory above ~860MB of physical memory + Highmem is all memory above ~860MB of physical memory. Highmem areas are for use by userspace programs, or for the pagecache. The kernel must use tricks to access this memory, making it slower to access than lowmem. @@ -1078,7 +1078,7 @@ Committed_AS using 1G. This 1G is memory which has been "committed" to by the VM and can be used at any time by the allocating application. With strict overcommit enabled on the system - (mode 2 in 'vm.overcommit_memory'),allocations which would + (mode 2 in 'vm.overcommit_memory'), allocations which would exceed the CommitLimit (detailed above) will not be permitted. This is useful if one needs to guarantee that processes will not fail due to lack of memory once that memory has been @@ -1099,7 +1099,7 @@ vmallocinfo Provides information about vmalloced/vmaped areas. One line per area, containing the virtual address range of the area, size in bytes, caller information of the creator, and optional information depending -on the kind of area : +on the kind of area: ========== =================================================== pages=nr number of pages @@ -1144,21 +1144,21 @@ on the kind of area : softirqs ~~~~~~~~ -Provides counts of softirq handlers serviced since boot time, for each cpu. +Provides counts of softirq handlers serviced since boot time, for each CPU. :: > cat /proc/softirqs - CPU0 CPU1 CPU2 CPU3 + CPU0 CPU1 CPU2 CPU3 HI: 0 0 0 0 - TIMER: 27166 27120 27097 27034 + TIMER: 27166 27120 27097 27034 NET_TX: 0 0 0 17 NET_RX: 42 0 0 39 - BLOCK: 0 0 107 1121 - TASKLET: 0 0 0 290 - SCHED: 27035 26983 26971 26746 - HRTIMER: 0 0 0 0 - RCU: 1678 1769 2178 2250 + BLOCK: 0 0 107 1121 + TASKLET: 0 0 0 290 + SCHED: 27035 26983 26971 26746 + HRTIMER: 0 0 0 0 + RCU: 1678 1769 2178 2250 1.3 IDE devices in /proc/ide @@ -1169,7 +1169,7 @@ the kernel is aware. There is one subdirectory for each IDE controller, the file drivers and a link for each IDE device, pointing to the device directory in the controller specific subtree. -The file drivers contains general information about the drivers used for the +The file 'drivers' contains general information about the drivers used for the IDE devices:: > cat /proc/ide/drivers @@ -1409,7 +1409,7 @@ These directories contain the four files shown in Table 1-10. ------------------------- Information about the available and actually used tty's can be found in the -directory /proc/tty.You'll find entries for drivers and line disciplines in +directory /proc/tty. You'll find entries for drivers and line disciplines in this directory, as shown in Table 1-11. @@ -1471,9 +1471,9 @@ second). The meanings of the columns are as follows, from left to right: - iowait: In a word, iowait stands for waiting for I/O to complete. But there are several problems: - 1. Cpu will not wait for I/O to complete, iowait is the time that a task is - waiting for I/O to complete. When cpu goes into idle state for - outstanding task io, another task will be scheduled on this CPU. + 1. CPU will not wait for I/O to complete, iowait is the time that a task is + waiting for I/O to complete. When CPU goes into idle state for + outstanding task I/O, another task will be scheduled on this CPU. 2. In a multi-core CPU, the task waiting for I/O to complete is not running on any CPU, so the iowait of each CPU is difficult to calculate. 3. The value of iowait field in /proc/stat will decrease in certain @@ -1529,8 +1529,8 @@ in Table 1-12, below. mb_groups details of multiblock allocator buddy cache of free blocks ============== ========================================================== -2.0 /proc/consoles ------------------- +1.10 /proc/consoles +------------------- Shows registered system console lines. To see which character device lines are currently used for the system console @@ -1590,10 +1590,9 @@ production system. Set up a development machine and test to make sure that everything works the way you want it to. You may have no alternative but to reboot the machine once an error has been made. -To change a value, simply echo the new value into the file. An example is -given below in the section on the file system data. You need to be root to do -this. You can create your own boot script to perform this every time your -system boots. +To change a value, simply echo the new value into the file. +You need to be root to do this. You can create your own boot script +to perform this every time your system boots. The files in /proc/sys can be used to fine tune and monitor miscellaneous and general things in the operation of the Linux kernel. Since some of the files @@ -1624,8 +1623,8 @@ Chapter 3: Per-process Parameters 3.1 /proc//oom_adj & /proc//oom_score_adj- Adjust the oom-killer score -------------------------------------------------------------------------------- -These file can be used to adjust the badness heuristic used to select which -process gets killed in out of memory conditions. +These files can be used to adjust the badness heuristic used to select which +process gets killed in out of memory (oom) conditions. The badness heuristic assigns a value to each candidate task ranging from 0 (never kill) to 1000 (always kill) to determine which process is targeted. The @@ -1681,7 +1680,7 @@ minimal amount of work. 3.2 /proc//oom_score - Display current oom-killer score ------------------------------------------------------------- -This file can be used to check the current score used by the oom-killer is for +This file can be used to check the current score used by the oom-killer for any given . Use it together with /proc//oom_score_adj to tune which process should be killed in an out-of-memory situation. @@ -1689,7 +1688,7 @@ process should be killed in an out-of-memory situation. 3.3 /proc//io - Display the IO accounting fields ------------------------------------------------------- -This file contains IO statistics for each running process +This file contains IO statistics for each running process. Example ~~~~~~~ @@ -1720,7 +1719,7 @@ The number of bytes which this task has caused to be read from storage. This is simply the sum of bytes which this process passed to read() and pread(). It includes things like tty IO and it is unaffected by whether or not actual physical disk IO was required (the read might have been satisfied from -pagecache) +pagecache). wchar @@ -1878,7 +1877,7 @@ For more information on mount propagation see: 3.6 /proc//comm & /proc//task//comm -------------------------------------------------------- -These files provide a method to access a tasks comm value. It also allows for +These files provide a method to access a task's comm value. It also allows for a task to set its own or one of its thread siblings comm value. The comm value is limited in size compared to the cmdline value, so writing anything longer then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated @@ -1891,21 +1890,21 @@ This file provides a fast way to retrieve first level children pids of a task pointed by / pair. The format is a space separated stream of pids. -Note the "first level" here -- if a child has own children they will -not be listed here, one needs to read /proc//task//children +Note the "first level" here -- if a child has its own children they will +not be listed here; one needs to read /proc//task//children to obtain the descendants. Since this interface is intended to be fast and cheap it doesn't guarantee to provide precise results and some children might be skipped, especially if they've exited right after we printed their -pids, so one need to either stop or freeze processes being inspected +pids, so one needs to either stop or freeze processes being inspected if precise results are needed. 3.8 /proc//fdinfo/ - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least three fields -- 'pos', 'flags' and mnt_id. The 'pos' +files have at least three fields -- 'pos', 'flags' and 'mnt_id'. The 'pos' represents the current offset of the opened file in decimal form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the file has been created with [see open(2) for details] and 'mnt_id' represents mount ID of @@ -1976,7 +1975,7 @@ For inotify files the format is the following:: flags: 02000000 inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d -where 'wd' is a watch descriptor in decimal form, ie a target file +where 'wd' is a watch descriptor in decimal form, i.e. a target file descriptor number, 'ino' and 'sdev' are inode and device where the target file resides and the 'mask' is the mask of events, all in hex form [see inotify(7) for more details]. @@ -2003,10 +2002,10 @@ For fanotify files the format is:: where fanotify 'flags' and 'event-flags' are values used in fanotify_init call, 'mnt_id' is the mount point identifier, 'mflags' is the value of flags associated with mark which are tracked separately from events -mask. 'ino', 'sdev' are target inode and device, 'mask' is the events +mask. 'ino' and 'sdev' are target inode and device, 'mask' is the events mask and 'ignored_mask' is the mask of events which are to be ignored. -All in hex format. Incorporation of 'mflags', 'mask' and 'ignored_mask' -does provide information about flags and mask used in fanotify_mark +All are in hex format. Incorporation of 'mflags', 'mask' and 'ignored_mask' +provide information about flags and mask used in fanotify_mark call [see fsnotify manpage for details]. While the first three lines are mandatory and always printed, the rest is @@ -2029,7 +2028,7 @@ Timerfd files where 'clockid' is the clock type and 'ticks' is the number of the timer expirations that have occurred [see timerfd_create(2) for details]. 'settime flags' are flags in octal form been used to setup the timer [see timerfd_settime(2) for -details]. 'it_value' is remaining time until the timer exiration. +details]. 'it_value' is remaining time until the timer expiration. 'it_interval' is the interval for the timer. Note the timer might be set up with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' still exhibits timer's remaining time. @@ -2059,13 +2058,13 @@ are actually shared. 3.10 /proc//timerslack_ns - Task timerslack value --------------------------------------------------------- This file provides the value of the task's timerslack value in nanoseconds. -This value specifies a amount of time that normal timers may be deferred +This value specifies an amount of time that normal timers may be deferred in order to coalesce timers and avoid unnecessary wakeups. -This allows a task's interactivity vs power consumption trade off to be +This allows a task's interactivity vs power consumption tradeoff to be adjusted. -Writing 0 to the file will set the tasks timerslack to the default value. +Writing 0 to the file will set the task's timerslack to the default value. Valid values are from 0 - ULLONG_MAX @@ -2105,10 +2104,10 @@ Example Description ~~~~~~~~~~~ -x86 specific entries: +x86 specific entries ~~~~~~~~~~~~~~~~~~~~~ -AVX512_elapsed_ms: +AVX512_elapsed_ms ^^^^^^^^^^^^^^^^^^ If AVX512 is supported on the machine, this entry shows the milliseconds @@ -2134,8 +2133,8 @@ AVX512_elapsed_ms: the task is unlikely an AVX512 user, but depends on the workload and the scheduling scenario, it also could be a false negative mentioned above. -Configuring procfs ------------------- +Chapter 4: Configuring procfs +============================= 4.1 Mount options --------------------- @@ -2178,47 +2177,45 @@ information about processes information, just add identd to this group. subset=pid hides all top level files and directories in the procfs that are not related to tasks. -5 Filesystem behavior ----------------------------- +Chapter 5: Filesystem behavior +============================== Originally, before the advent of pid namepsace, procfs was a global file system. It means that there was only one procfs instance in the system. When pid namespace was added, a separate procfs instance was mounted in each pid namespace. So, procfs mount options are global among all -mountpoints within the same namespace. +mountpoints within the same namespace:: -:: + # grep ^proc /proc/mounts + proc /proc proc rw,relatime,hidepid=2 0 0 -# grep ^proc /proc/mounts -proc /proc proc rw,relatime,hidepid=2 0 0 + # strace -e mount mount -o hidepid=1 -t proc proc /tmp/proc + mount("proc", "/tmp/proc", "proc", 0, "hidepid=1") = 0 + +++ exited with 0 +++ -# strace -e mount mount -o hidepid=1 -t proc proc /tmp/proc -mount("proc", "/tmp/proc", "proc", 0, "hidepid=1") = 0 -+++ exited with 0 +++ - -# grep ^proc /proc/mounts -proc /proc proc rw,relatime,hidepid=2 0 0 -proc /tmp/proc proc rw,relatime,hidepid=2 0 0 + # grep ^proc /proc/mounts + proc /proc proc rw,relatime,hidepid=2 0 0 + proc /tmp/proc proc rw,relatime,hidepid=2 0 0 and only after remounting procfs mount options will change at all -mountpoints. +mountpoints:: -# mount -o remount,hidepid=1 -t proc proc /tmp/proc + # mount -o remount,hidepid=1 -t proc proc /tmp/proc -# grep ^proc /proc/mounts -proc /proc proc rw,relatime,hidepid=1 0 0 -proc /tmp/proc proc rw,relatime,hidepid=1 0 0 + # grep ^proc /proc/mounts + proc /proc proc rw,relatime,hidepid=1 0 0 + proc /tmp/proc proc rw,relatime,hidepid=1 0 0 This behavior is different from the behavior of other filesystems. The new procfs behavior is more like other filesystems. Each procfs mount creates a new procfs instance. Mount options affect own procfs instance. It means that it became possible to have several procfs instances -displaying tasks with different filtering options in one pid namespace. +displaying tasks with different filtering options in one pid namespace:: -# mount -o hidepid=invisible -t proc proc /proc -# mount -o hidepid=noaccess -t proc proc /tmp/proc -# grep ^proc /proc/mounts -proc /proc proc rw,relatime,hidepid=invisible 0 0 -proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0 + # mount -o hidepid=invisible -t proc proc /proc + # mount -o hidepid=noaccess -t proc proc /tmp/proc + # grep ^proc /proc/mounts + proc /proc proc rw,relatime,hidepid=invisible 0 0 + proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0 diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst index 3fddacc6bf14..4598b0d90b60 100644 --- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst @@ -246,15 +246,15 @@ If you don't already understand what shared libraries, devices, and paths you need to get a minimal root filesystem up and running, here are some references: -- http://www.tldp.org/HOWTO/Bootdisk-HOWTO/ -- http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html +- https://www.tldp.org/HOWTO/Bootdisk-HOWTO/ +- https://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html - http://www.linuxfromscratch.org/lfs/view/stable/ -The "klibc" package (http://www.kernel.org/pub/linux/libs/klibc) is +The "klibc" package (https://www.kernel.org/pub/linux/libs/klibc) is designed to be a tiny C library to statically link early userspace code against, along with some related utilities. It is BSD licensed. -I use uClibc (http://www.uclibc.org) and busybox (http://www.busybox.net) +I use uClibc (https://www.uclibc.org) and busybox (https://www.busybox.net) myself. These are LGPL and GPL, respectively. (A self-contained initramfs package is planned for the busybox 1.3 release.) diff --git a/Documentation/filesystems/sysfs-pci.rst b/Documentation/filesystems/sysfs-pci.rst index a265f3e2cc80..742fbd21dc1f 100644 --- a/Documentation/filesystems/sysfs-pci.rst +++ b/Documentation/filesystems/sysfs-pci.rst @@ -63,7 +63,7 @@ files, each with their own function. binary - file contains binary data cpumask - file contains a cpumask type -.. [1] rw for RESOURCE_IO (I/O port) regions only +.. [1] rw for IORESOURCE_IO (I/O port) regions only The read only files are informational, writes to them will be ignored, with the exception of the 'rom' file. Writable files can be used to perform diff --git a/Documentation/filesystems/sysfs-tagging.rst b/Documentation/filesystems/sysfs-tagging.rst index 8888a05c398e..83647e10c207 100644 --- a/Documentation/filesystems/sysfs-tagging.rst +++ b/Documentation/filesystems/sysfs-tagging.rst @@ -15,7 +15,7 @@ To avoid that problem and allow existing applications in network namespaces to see the same interface that is currently presented in sysfs, sysfs now has tagging directory support. -By using the network namespace pointers as tags to separate out the +By using the network namespace pointers as tags to separate out the sysfs directory entries we ensure that we don't have conflicts in the directories and applications only see a limited set of the network devices. diff --git a/Documentation/filesystems/ubifs-authentication.rst b/Documentation/filesystems/ubifs-authentication.rst index 16efd729bf7c..1f39c8cea702 100644 --- a/Documentation/filesystems/ubifs-authentication.rst +++ b/Documentation/filesystems/ubifs-authentication.rst @@ -433,9 +433,9 @@ will then have to be provided beforehand in the normal way. References ========== -[CRYPTSETUP2] http://www.saout.de/pipermail/dm-crypt/2017-November/005745.html +[CRYPTSETUP2] https://www.saout.de/pipermail/dm-crypt/2017-November/005745.html -[DMC-CBC-ATTACK] http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ +[DMC-CBC-ATTACK] https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ [DM-INTEGRITY] https://www.kernel.org/doc/Documentation/device-mapper/dm-integrity.rst diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index ed17771c212b..ca52c82e5bb5 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -392,7 +392,7 @@ Extended attributes are name:value pairs. ``set`` Called by the VFS to set the value of a particular extended attribute. When the new value is NULL, called to remove a - particular extended attribute. This method is called by the the + particular extended attribute. This method is called by the setxattr(2) and removexattr(2) system calls. When none of the xattr handlers of a filesystem match the specified @@ -652,7 +652,7 @@ at any point after PG_Dirty is clear. Once it is known to be safe, PG_Writeback is cleared. Writeback makes use of a writeback_control structure to direct the -operations. This gives the the writepage and writepages operations some +operations. This gives the writepage and writepages operations some information about the nature of and reason for the writeback request, and the constraints under which it is being done. It is also used to return information back to the caller about the result of a writepage or @@ -766,9 +766,9 @@ cache in your filesystem. The following members are defined: ``writepages`` called by the VM to write out pages associated with the - address_space object. If wbc->sync_mode is WBC_SYNC_ALL, then + address_space object. If wbc->sync_mode is WB_SYNC_ALL, then the writeback_control will specify a range of pages that must be - written out. If it is WBC_SYNC_NONE, then a nr_to_write is + written out. If it is WB_SYNC_NONE, then a nr_to_write is given and that many pages should be written if possible. If no ->writepages is given, then mpage_writepages is used instead. This will choose pages from the address space that are tagged as @@ -1116,7 +1116,7 @@ otherwise noted. before any bytes were remapped. The remap_flags parameter accepts REMAP_FILE_* flags. If REMAP_FILE_DEDUP is set then the implementation must only remap if the requested file ranges have - identical contents. If REMAP_CAN_SHORTEN is set, the caller is + identical contents. If REMAP_FILE_CAN_SHORTEN is set, the caller is ok with the implementation shortening the request length to satisfy alignment or EOF requirements (or any other reason). @@ -1431,13 +1431,13 @@ Resources version.) Creating Linux virtual filesystems. 2002 - + The Linux Virtual File-system Layer by Neil Brown. 1999 A tour of the Linux VFS by Michael K. Johnson. 1996 - + A small trail through the Linux kernel by Andries Brouwer. 2001 - + diff --git a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst index 4306f29b6103..8b2d8d0864c2 100644 --- a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst +++ b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst @@ -96,5 +96,5 @@ contents. References ========== -.. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf -.. [2] http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf +.. [1] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf +.. [2] https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst index febccbc5689d..9b17dc77d18c 100644 --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -85,9 +85,9 @@ References ========== [1] Hierarchical Data Extension UUID For _DSD. -, +, referenced 2018-07-17. [2] Device Properties UUID For _DSD. -, +, referenced 2016-10-04. diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index 1a6ce7afba5e..7072db801aeb 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -154,23 +154,23 @@ References ========== [1] _DSD (Device Specific Data) Implementation Guide. - http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm, + https://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm, referenced 2016-10-03. -[2] Devicetree. http://www.devicetree.org, referenced 2016-10-03. +[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03. [3] Documentation/devicetree/bindings/graph.txt [4] Device Properties UUID For _DSD. - http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, + https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, referenced 2016-10-04. [5] Hierarchical Data Extension UUID For _DSD. - http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, + https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, referenced 2016-10-04. [6] Advanced Configuration and Power Interface Specification. - http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf, + https://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf, referenced 2016-10-04. [7] _DSD Device Properties Usage Rules. diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst index 946efe2b2936..aba1e9abfeeb 100644 --- a/Documentation/firmware-guide/acpi/dsd/leds.rst +++ b/Documentation/firmware-guide/acpi/dsd/leds.rst @@ -90,7 +90,7 @@ where References ========== -[1] Device tree. , referenced 2019-02-21. +[1] Device tree. , referenced 2019-02-21. [2] Advanced Configuration and Power Interface Specification. , @@ -101,11 +101,11 @@ References [4] Documentation/devicetree/bindings/media/video-interfaces.txt [5] Device Properties UUID For _DSD. - , + , referenced 2019-02-21. [6] Hierarchical Data Extension UUID For _DSD. - , + , referenced 2019-02-21. [7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst diff --git a/Documentation/firmware-guide/acpi/lpit.rst b/Documentation/firmware-guide/acpi/lpit.rst index aca928fab027..37922a903573 100644 --- a/Documentation/firmware-guide/acpi/lpit.rst +++ b/Documentation/firmware-guide/acpi/lpit.rst @@ -7,7 +7,7 @@ Low Power Idle Table (LPIT) To enumerate platform Low Power Idle states, Intel platforms are using “Low Power Idle Table” (LPIT). More details about this table can be downloaded from: -http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf +https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Residencies for each low power state can be read via FFH (Function fixed hardware) or a memory mapped interface. diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index 978c4af416a4..0404fe6ffc74 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -8,7 +8,7 @@ Authors: - Xiao Guangrong - Wu Hao -The Device Feature List (DFL) FPGA framework (and drivers according to this +The Device Feature List (DFL) FPGA framework (and drivers according to this framework) hides the very details of low layer hardwares and provides unified interfaces to userspace. Applications could use these interfaces to configure, enumerate, open and access FPGA accelerators on platforms which @@ -89,6 +89,8 @@ The following functions are exposed through ioctls: - Program bitstream (DFL_FPGA_FME_PORT_PR) - Assign port to PF (DFL_FPGA_FME_PORT_ASSIGN) - Release port from PF (DFL_FPGA_FME_PORT_RELEASE) +- Get number of irqs of FME global error (DFL_FPGA_FME_ERR_GET_IRQ_NUM) +- Set interrupt trigger for FME error (DFL_FPGA_FME_ERR_SET_IRQ) More functions are exposed through sysfs (/sys/class/fpga_region/regionX/dfl-fme.n/): @@ -149,6 +151,10 @@ The following functions are exposed through ioctls: - Map DMA buffer (DFL_FPGA_PORT_DMA_MAP) - Unmap DMA buffer (DFL_FPGA_PORT_DMA_UNMAP) - Reset AFU (DFL_FPGA_PORT_RESET) +- Get number of irqs of port error (DFL_FPGA_PORT_ERR_GET_IRQ_NUM) +- Set interrupt trigger for port error (DFL_FPGA_PORT_ERR_SET_IRQ) +- Get number of irqs of UINT (DFL_FPGA_PORT_UINT_GET_IRQ_NUM) +- Set interrupt trigger for UINT (DFL_FPGA_PORT_UINT_SET_IRQ) DFL_FPGA_PORT_RESET: reset the FPGA Port and its AFU. Userspace can do Port @@ -462,6 +468,19 @@ since they are system-wide counters on FPGA device. The current driver does not support sampling. So "perf record" is unsupported. +Interrupt support +================= +Some FME and AFU private features are able to generate interrupts. As mentioned +above, users could call ioctl (DFL_FPGA_*_GET_IRQ_NUM) to know whether or how +many interrupts are supported for this private feature. Drivers also implement +an eventfd based interrupt handling mechanism for users to get notified when +interrupt happens. Users could set eventfds to driver via +ioctl (DFL_FPGA_*_SET_IRQ), and then poll/select on these eventfds waiting for +notification. +In Current DFL, 3 sub features (Port error, FME global error and AFU interrupt) +support interrupts. + + Add new FIUs support ==================== It's possible that developers made some new function blocks (FIUs) under this diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index ee730457bf4e..b89ddd06dabb 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -411,15 +411,3 @@ Legacy CRTC/Modeset Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c :export: - -SHMEM GEM Helper Reference -========================== - -.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c - :doc: overview - -.. kernel-doc:: include/drm/drm_gem_shmem_helper.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c - :export: diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 397314d08f77..3c5ae4f6dfd2 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -460,6 +460,12 @@ HDMI Specific Connector Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: HDMI connector properties +Standard CRTC Properties +------------------------ + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: standard CRTC properties + Plane Composition Properties ---------------------------- @@ -537,3 +543,18 @@ Vertical Blanking and Interrupt Handling Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_vblank.c :export: + +Vertical Blank Work +=================== + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c + :doc: vblank works + +Vertical Blank Work Functions Reference +--------------------------------------- + +.. kernel-doc:: include/drm/drm_vblank_work.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c + :export: diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 1839762044be..9abee1589c1e 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -179,10 +179,7 @@ GEM Objects Lifetime All GEM objects are reference-counted by the GEM core. References can be acquired and release by calling drm_gem_object_get() and drm_gem_object_put() -respectively. The caller must hold the :c:type:`struct drm_device ` -struct_mutex lock when calling drm_gem_object_get(). As a convenience, GEM -provides drm_gem_object_put_unlocked() functions that can be called without -holding the lock. +respectively. When the last reference to a GEM object is released the GEM core calls the :c:type:`struct drm_driver ` gem_free_object_unlocked @@ -314,7 +311,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill the struct a pointer on drm_gem_cma_get_unmapped_area(). More detailed information about get_unmapped_area can be found in -Documentation/nommu-mmap.txt +Documentation/admin-guide/mm/nommu-mmap.rst Memory Coherency ---------------- @@ -373,6 +370,18 @@ GEM CMA Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c :export: +GEM SHMEM Helper Function Reference +----------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c + :doc: overview + +.. kernel-doc:: include/drm/drm_gem_shmem_helper.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c + :export: + GEM VRAM Helper Functions Reference ----------------------------------- diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 56fec6ed1ad8..496d8fcd4da0 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -195,7 +195,7 @@ ENOSPC: EPERM/EACCES: Returned for an operation that is valid, but needs more privileges. E.g. root-only or much more common, DRM master-only operations return - this when when called by unpriviledged clients. There's no clear + this when called by unpriviledged clients. There's no clear difference between EACCES and EPERM. ENODEV: diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst index b08da1cffecc..eb693c857e2d 100644 --- a/Documentation/gpu/komeda-kms.rst +++ b/Documentation/gpu/komeda-kms.rst @@ -41,7 +41,7 @@ Compositor blends multiple layers or pixel data flows into one single display frame. its output frame can be fed into post image processor for showing it on the monitor or fed into wb_layer and written to memory at the same time. user can also insert a scaler between compositor and wb_layer to down scale -the display frame first and and then write to memory. +the display frame first and then write to memory. Writeback Layer (wb_layer) -------------------------- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 658b52f7ffc6..7969f106877d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -157,8 +157,8 @@ private lock. The tricky part is the BO free functions, since those can't reliably take that lock any more. Instead state needs to be protected with suitable subordinate locks or some cleanup work pushed to a worker thread. For performance-critical drivers it might also be better to go with a more -fine-grained per-buffer object and per-context lockings scheme. Currently only the -``msm`` driver still use ``struct_mutex``. +fine-grained per-buffer object and per-context lockings scheme. Currently only +the ``msm`` and `i915` drivers use ``struct_mutex``. Contact: Daniel Vetter, respective driver maintainers @@ -305,7 +305,7 @@ acquire context. Replace the boilerplate code surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() instead. -This should also be done for all places where drm_modest_lock_all() is still +This should also be done for all places where drm_modeset_lock_all() is still used. As a reference, take a look at the conversions already completed in drm core. @@ -327,26 +327,6 @@ Contact: Laurent Pinchart, Daniel Vetter Level: Intermediate (mostly because it is a huge tasks without good partial milestones, not technically itself that challenging) -Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() ----------------------------------------------------------------- - -drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it -is risky and has been known to cause div-by-zero bugs. Fortunately, drm core -has helper which will use mode.vrefresh if it's !0 and will calculate it from -the timings when it's 0. - -Use simple search/replace, or (more fun) cocci to replace instances of direct -vrefresh access with a call to the helper. Check out -https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for -inspiration. - -Once all instances of vrefresh have been converted, remove vrefresh from -drm_display_mode to avoid future use. - -Contact: Sean Paul - -Level: Starter - connector register/unregister fixes ----------------------------------- @@ -392,6 +372,38 @@ Contact: Laurent Pinchart, respective driver maintainers Level: Intermediate +Consolidate custom driver modeset properties +-------------------------------------------- + +Before atomic modeset took place, many drivers where creating their own +properties. Among other things, atomic brought the requirement that custom, +driver specific properties should not be used. + +For this task, we aim to introduce core helpers or reuse the existing ones +if available: + +A quick, unconfirmed, examples list. + +Introduce core helpers: +- audio (amdgpu, intel, gma500, radeon) +- brightness, contrast, etc (armada, nouveau) - overlay only (?) +- broadcast rgb (gma500, intel) +- colorkey (armada, nouveau, rcar) - overlay only (?) +- dither (amdgpu, nouveau, radeon) - varies across drivers +- underscan family (amdgpu, radeon, nouveau) + +Already in core: +- colorspace (sti) +- tv format names, enhancements (gma500, intel) +- tv overscan, margins, etc. (gma500, intel) +- zorder (omapdrm) - same as zpos (?) + + +Contact: Emil Velikov, respective driver maintainers + +Level: Intermediate + + Core refactorings ================= diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst index 0b41b051d021..339ed5fecd2e 100644 --- a/Documentation/gpu/vgaarbiter.rst +++ b/Documentation/gpu/vgaarbiter.rst @@ -185,7 +185,7 @@ enhancing the kernel code to adapt as a kernel module and also did the implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree. -0) http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347 -1) http://lists.freedesktop.org/archives/xorg/2005-March/006663.html -2) http://lists.freedesktop.org/archives/xorg/2005-March/006745.html -3) http://lists.freedesktop.org/archives/xorg/2007-October/029507.html +0) https://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347 +1) https://lists.freedesktop.org/archives/xorg/2005-March/006663.html +2) https://lists.freedesktop.org/archives/xorg/2005-March/006745.html +3) https://lists.freedesktop.org/archives/xorg/2007-October/029507.html diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst index 209e6ba4e019..9b28a97c03e6 100644 --- a/Documentation/hid/hiddev.rst +++ b/Documentation/hid/hiddev.rst @@ -65,7 +65,7 @@ The HIDDEV API ============== This description should be read in conjunction with the HID -specification, freely available from http://www.usb.org, and +specification, freely available from https://www.usb.org, and conveniently linked of http://www.linux-usb.org. The hiddev API uses a read() interface, and a set of ioctl() calls. diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst index cccbf4be17d7..d4785cf6eefd 100644 --- a/Documentation/hid/intel-ish-hid.rst +++ b/Documentation/hid/intel-ish-hid.rst @@ -235,7 +235,7 @@ There can be multiple sensor clients and clients for calibration function. To ease in implantation and allow independent driver handle each client this transport layer takes advantage of Linux Bus driver model. Each -client is registered as device on the the transport bus (ishtp bus). +client is registered as device on the transport bus (ishtp bus). Enumeration sequence of messages: diff --git a/Documentation/hwmon/acpi_power_meter.rst b/Documentation/hwmon/acpi_power_meter.rst index 4a0941ade0ca..8628c1161015 100644 --- a/Documentation/hwmon/acpi_power_meter.rst +++ b/Documentation/hwmon/acpi_power_meter.rst @@ -9,7 +9,7 @@ Supported systems: Prefix: 'power_meter' - Datasheet: http://acpi.info/, section 10.4. + Datasheet: https://uefi.org/specifications, section 10.4. Author: Darrick J. Wong diff --git a/Documentation/hwmon/adc128d818.rst b/Documentation/hwmon/adc128d818.rst index 6753468932ab..d2488023430f 100644 --- a/Documentation/hwmon/adc128d818.rst +++ b/Documentation/hwmon/adc128d818.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: I2C 0x1d, 0x1e, 0x1f, 0x2d, 0x2e, 0x2f - Datasheet: Publicly available at the TI website http://www.ti.com/ + Datasheet: Publicly available at the TI website https://www.ti.com/ Author: Guenter Roeck diff --git a/Documentation/hwmon/adm1026.rst b/Documentation/hwmon/adm1026.rst index 35d63e6498a3..66f996fa3031 100644 --- a/Documentation/hwmon/adm1026.rst +++ b/Documentation/hwmon/adm1026.rst @@ -10,7 +10,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.onsemi.com/PowerSolutions/product.do?id=ADM1026 + https://www.onsemi.com/PowerSolutions/product.do?id=ADM1026 Authors: - Philip Pokorny for Penguin Computing diff --git a/Documentation/hwmon/adm1031.rst b/Documentation/hwmon/adm1031.rst index a677c3ab5574..be74ec1f3e73 100644 --- a/Documentation/hwmon/adm1031.rst +++ b/Documentation/hwmon/adm1031.rst @@ -10,7 +10,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/en/prod/0%2C2877%2CADM1030%2C00.html + https://www.analog.com/en/prod/0%2C2877%2CADM1030%2C00.html * Analog Devices ADM1031 @@ -20,7 +20,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/en/prod/0%2C2877%2CADM1031%2C00.html + https://www.analog.com/en/prod/0%2C2877%2CADM1031%2C00.html Authors: - Alexandre d'Alton diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst index 49966ed70ec6..ce6528f90e4a 100644 --- a/Documentation/hwmon/adm1275.rst +++ b/Documentation/hwmon/adm1275.rst @@ -49,7 +49,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1293_1294.pdf + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1293_1294.pdf Author: Guenter Roeck diff --git a/Documentation/hwmon/adt7410.rst b/Documentation/hwmon/adt7410.rst index 24caaa83c8ec..3f5a43561bf1 100644 --- a/Documentation/hwmon/adt7410.rst +++ b/Documentation/hwmon/adt7410.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf * Analog Devices ADT7420 Prefix: 'adt7420' @@ -20,7 +20,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf * Analog Devices ADT7310 @@ -30,7 +30,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf * Analog Devices ADT7320 @@ -40,7 +40,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf Author: Hartmut Knaack diff --git a/Documentation/hwmon/corsair-cpro.rst b/Documentation/hwmon/corsair-cpro.rst new file mode 100644 index 000000000000..751f95476b57 --- /dev/null +++ b/Documentation/hwmon/corsair-cpro.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver corsair-cpro +========================== + +Supported devices: + + * Corsair Commander Pro + * Corsair Commander Pro (1000D) + +Author: Marius Zachmann + +Description +----------- + +This driver implements the sysfs interface for the Corsair Commander Pro. +The Corsair Commander Pro is a USB device with 6 fan connectors, +4 temperature sensor connectors and 2 Corsair LED connectors. +It can read the voltage levels on the SATA power connector. + +Usage Notes +----------- + +Since it is a USB device, hotswapping is possible. The device is autodetected. + +Sysfs entries +------------- + +======================= ===================================================================== +in0_input Voltage on SATA 12v +in1_input Voltage on SATA 5v +in2_input Voltage on SATA 3.3v +temp[1-4]_input Temperature on connected temperature sensors +fan[1-6]_input Connected fan rpm. +fan[1-6]_label Shows fan type as detected by the device. +fan[1-6]_target Sets fan speed target rpm. + When reading, it reports the last value if it was set by the driver. + Otherwise returns an error. +pwm[1-6] Sets the fan speed. Values from 0-255. Can only be read if pwm + was set directly. +======================= ===================================================================== diff --git a/Documentation/hwmon/emc1403.rst b/Documentation/hwmon/emc1403.rst index 3a4913b63ef3..0de9616b24ed 100644 --- a/Documentation/hwmon/emc1403.rst +++ b/Documentation/hwmon/emc1403.rst @@ -12,7 +12,7 @@ Supported chips: Datasheets: - http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf - - http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414 @@ -33,7 +33,7 @@ Supported chips: Datasheet: - - http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf * SMSC / Microchip EMC1423, EMC1424 @@ -43,7 +43,7 @@ Supported chips: Datasheet: - - http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf Author: Kalhan Trisal diff --git a/Documentation/hwmon/ina2xx.rst b/Documentation/hwmon/ina2xx.rst index ed81f5416331..f78a5cd44c4c 100644 --- a/Documentation/hwmon/ina2xx.rst +++ b/Documentation/hwmon/ina2xx.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA220 @@ -21,7 +21,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA226 @@ -31,7 +31,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA230 @@ -41,7 +41,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA231 @@ -51,7 +51,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ Author: Lothar Felten diff --git a/Documentation/hwmon/ina3221.rst b/Documentation/hwmon/ina3221.rst index 297f7323b441..8c12c54d2c24 100644 --- a/Documentation/hwmon/ina3221.rst +++ b/Documentation/hwmon/ina3221.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ Author: Andrew F. Davis diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 55ff4b7c5349..750d3a975d82 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -47,6 +47,7 @@ Hardware Monitoring Kernel Drivers bel-pfe bt1-pvt coretemp + corsair-cpro da9052 da9055 dell-smm-hwmon diff --git a/Documentation/hwmon/jc42.rst b/Documentation/hwmon/jc42.rst index 5b14b49bb6f7..19d10512f6c0 100644 --- a/Documentation/hwmon/jc42.rst +++ b/Documentation/hwmon/jc42.rst @@ -7,7 +7,7 @@ Supported chips: Datasheets: - http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf * Atmel AT30TS00, AT30TS002A/B, AT30TSE004A @@ -39,37 +39,37 @@ Supported chips: Datasheets: - http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf * NXP Semiconductors SE97, SE97B, SE98, SE98A Datasheets: - http://www.nxp.com/documents/data_sheet/SE97.pdf + https://www.nxp.com/documents/data_sheet/SE97.pdf - http://www.nxp.com/documents/data_sheet/SE97B.pdf + https://www.nxp.com/documents/data_sheet/SE97B.pdf - http://www.nxp.com/documents/data_sheet/SE98.pdf + https://www.nxp.com/documents/data_sheet/SE98.pdf - http://www.nxp.com/documents/data_sheet/SE98A.pdf + https://www.nxp.com/documents/data_sheet/SE98A.pdf * ON Semiconductor CAT34TS02, CAT6095 Datasheet: - http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF + https://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF - http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF + https://www.onsemi.com/pub/Collateral/CAT6095-D.PDF * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000 diff --git a/Documentation/hwmon/k8temp.rst b/Documentation/hwmon/k8temp.rst index fe9109521056..ab25a73e778f 100644 --- a/Documentation/hwmon/k8temp.rst +++ b/Documentation/hwmon/k8temp.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: PCI space - Datasheet: http://www.amd.com/system/files/TechDocs/32559.pdf + Datasheet: https://www.amd.com/system/files/TechDocs/32559.pdf Author: Rudolf Marek diff --git a/Documentation/hwmon/lm25066.rst b/Documentation/hwmon/lm25066.rst index 30e6e77fb3c8..9f1d7e4d3ca1 100644 --- a/Documentation/hwmon/lm25066.rst +++ b/Documentation/hwmon/lm25066.rst @@ -11,9 +11,9 @@ Supported chips: Datasheets: - http://www.ti.com/lit/gpn/lm25056 + https://www.ti.com/lit/gpn/lm25056 - http://www.ti.com/lit/gpn/lm25056a + https://www.ti.com/lit/gpn/lm25056a * National Semiconductor LM25066 @@ -55,7 +55,7 @@ Supported chips: Datasheet: - http://www.ti.com/product/LM5066I + https://www.ti.com/product/LM5066I Author: Guenter Roeck diff --git a/Documentation/hwmon/lm63.rst b/Documentation/hwmon/lm63.rst index f478132b0408..9e27367d7405 100644 --- a/Documentation/hwmon/lm63.rst +++ b/Documentation/hwmon/lm63.rst @@ -39,7 +39,7 @@ Author: Jean Delvare Thanks go to Tyan and especially Alex Buckingham for setting up a remote access to their S4882 test platform for this driver. - http://www.tyan.com/ + https://www.tyan.com/ Description ----------- diff --git a/Documentation/hwmon/lm70.rst b/Documentation/hwmon/lm70.rst index f259bc1fcd91..6ddc5b67ccb5 100644 --- a/Documentation/hwmon/lm70.rst +++ b/Documentation/hwmon/lm70.rst @@ -13,15 +13,15 @@ Supported chips: * Texas Instruments TMP122/TMP124 - Information: http://www.ti.com/product/tmp122 + Information: https://www.ti.com/product/tmp122 * National Semiconductor LM71 - Datasheet: http://www.ti.com/product/LM71 + Datasheet: https://www.ti.com/product/LM71 * National Semiconductor LM74 - Datasheet: http://www.ti.com/product/LM74 + Datasheet: https://www.ti.com/product/LM74 Author: diff --git a/Documentation/hwmon/lm73.rst b/Documentation/hwmon/lm73.rst index 1d6a46844e85..74e909be6ef7 100644 --- a/Documentation/hwmon/lm73.rst +++ b/Documentation/hwmon/lm73.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/lm73 + https://www.ti.com/product/lm73 Author: Guillaume Ligneul diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst index e749f827c002..81257d5fc48f 100644 --- a/Documentation/hwmon/lm75.rst +++ b/Documentation/hwmon/lm75.rst @@ -31,7 +31,7 @@ Supported chips: Datasheet: Publicly available at the Maxim website - http://www.maximintegrated.com/ + https://www.maximintegrated.com/ * Maxim MAX6625, MAX6626, MAX31725, MAX31726 @@ -71,7 +71,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/adt75 + https://www.analog.com/adt75 * ST Microelectronics STDS75 @@ -101,23 +101,23 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/tmp100 + https://www.ti.com/product/tmp100 - http://www.ti.com/product/tmp101 + https://www.ti.com/product/tmp101 - http://www.ti.com/product/tmp105 + https://www.ti.com/product/tmp105 - http://www.ti.com/product/tmp112 + https://www.ti.com/product/tmp112 - http://www.ti.com/product/tmp75 + https://www.ti.com/product/tmp75 - http://www.ti.com/product/tmp75b + https://www.ti.com/product/tmp75b - http://www.ti.com/product/tmp75c + https://www.ti.com/product/tmp75c - http://www.ti.com/product/tmp175 + https://www.ti.com/product/tmp175 - http://www.ti.com/product/tmp275 + https://www.ti.com/product/tmp275 * NXP LM75B, PCT2075 @@ -127,9 +127,9 @@ Supported chips: Datasheet: Publicly available at the NXP website - http://www.nxp.com/documents/data_sheet/LM75B.pdf + https://www.nxp.com/documents/data_sheet/LM75B.pdf - http://www.nxp.com/docs/en/data-sheet/PCT2075.pdf + https://www.nxp.com/docs/en/data-sheet/PCT2075.pdf Author: Frodo Looijaard diff --git a/Documentation/hwmon/lm85.rst b/Documentation/hwmon/lm85.rst index faa92f54431c..55e1d9cdaaae 100644 --- a/Documentation/hwmon/lm85.rst +++ b/Documentation/hwmon/lm85.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.ti.com/lit/ds/symlink/lm96000.pdf + Datasheet: https://www.ti.com/lit/ds/symlink/lm96000.pdf * Analog Devices ADM1027 @@ -25,7 +25,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADM1027 + Datasheet: https://www.onsemi.com/PowerSolutions/product.do?id=ADM1027 * Analog Devices ADT7463 @@ -33,7 +33,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 + Datasheet: https://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 * Analog Devices ADT7468 @@ -41,7 +41,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7468 + Datasheet: https://www.onsemi.com/PowerSolutions/product.do?id=ADT7468 * SMSC EMC6D100, SMSC EMC6D101 diff --git a/Documentation/hwmon/lm87.rst b/Documentation/hwmon/lm87.rst index 72fcb577ef2a..b8fec5689648 100644 --- a/Documentation/hwmon/lm87.rst +++ b/Documentation/hwmon/lm87.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x2c - 0x2e - Datasheet: http://www.analog.com/en/prod/0,2877,ADM1024,00.html + Datasheet: https://www.analog.com/en/prod/0,2877,ADM1024,00.html Authors: diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 78dfc01b47a2..3da8c6e06a36 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -51,7 +51,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=ADM1032 + https://www.onsemi.com/PowerSolutions/product.do?id=ADM1032 * Analog Devices ADT7461 @@ -61,7 +61,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461 + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7461 * Analog Devices ADT7461A @@ -71,7 +71,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A * ON Semiconductor NCT1008 @@ -81,7 +81,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008 + https://www.onsemi.com/PowerSolutions/product.do?id=NCT1008 * Maxim MAX6646 @@ -263,7 +263,7 @@ Supported chips: Datasheet: Publicly available at TI website - http://www.ti.com/litv/pdf/sbos686 + https://www.ti.com/litv/pdf/sbos686 Author: Jean Delvare diff --git a/Documentation/hwmon/lm93.rst b/Documentation/hwmon/lm93.rst index 49d199b45b67..369e15898af9 100644 --- a/Documentation/hwmon/lm93.rst +++ b/Documentation/hwmon/lm93.rst @@ -133,7 +133,7 @@ Smart Tach Mode (from the datasheet):: four signals are measured within 4 seconds. Smart tach mode is enabled by the driver by writing 1 or 2 (associating the -the fan tachometer with a pwm) to the sysfs file fan_smart_tach. A zero +fan tachometer with a pwm) to the sysfs file fan_smart_tach. A zero will disable the function for that fan. Note that Smart tach mode cannot be enabled if the PWM output frequency is 22500 Hz (see below). diff --git a/Documentation/hwmon/lm95234.rst b/Documentation/hwmon/lm95234.rst index e4c14bea5efd..a44e8f529826 100644 --- a/Documentation/hwmon/lm95234.rst +++ b/Documentation/hwmon/lm95234.rst @@ -9,7 +9,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/lm95233 + https://www.ti.com/product/lm95233 * National Semiconductor / Texas Instruments LM95234 @@ -17,7 +17,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/lm95234 + https://www.ti.com/product/lm95234 Author: Guenter Roeck diff --git a/Documentation/hwmon/lm95245.rst b/Documentation/hwmon/lm95245.rst index 566d1dc8c5a6..836d9a3f53f9 100644 --- a/Documentation/hwmon/lm95245.rst +++ b/Documentation/hwmon/lm95245.rst @@ -9,7 +9,7 @@ Supported chips: Datasheet: Publicly available at the TI website - http://www.ti.com/lit/ds/symlink/lm95235.pdf + https://www.ti.com/lit/ds/symlink/lm95235.pdf * TI / National Semiconductor LM95245 @@ -17,7 +17,7 @@ Supported chips: Datasheet: Publicly available at the TI website - http://www.ti.com/lit/ds/symlink/lm95245.pdf + https://www.ti.com/lit/ds/symlink/lm95245.pdf Author: Alexander Stein diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst index bc5270e5a477..b99a63965cfb 100644 --- a/Documentation/hwmon/ltc2978.rst +++ b/Documentation/hwmon/ltc2978.rst @@ -179,7 +179,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/ltm4680 + Datasheet: https://www.analog.com/ltm4680 * Analog Devices LTM4686 @@ -187,7 +187,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/ltm4686 + Datasheet: https://www.analog.com/ltm4686 * Analog Devices LTM4700 @@ -195,7 +195,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/ltm4700 + Datasheet: https://www.analog.com/ltm4700 diff --git a/Documentation/hwmon/max20730.rst b/Documentation/hwmon/max20730.rst index cea7ae58c2f7..cb0c95b2b1f6 100644 --- a/Documentation/hwmon/max20730.rst +++ b/Documentation/hwmon/max20730.rst @@ -5,6 +5,14 @@ Kernel driver max20730 Supported chips: + * Maxim MAX20710 + + Prefix: 'max20710' + + Addresses scanned: - + + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20710.pdf + * Maxim MAX20730 Prefix: 'max20730' @@ -35,7 +43,7 @@ Author: Guenter Roeck Description ----------- -This driver implements support for Maxim MAX20730, MAX20734, and MAX20743 +This driver implements support for Maxim MAX20710, MAX20730, MAX20734, and MAX20743 Integrated, Step-Down Switching Regulators with PMBus support. The driver is a client driver to the core PMBus driver. diff --git a/Documentation/hwmon/max20751.rst b/Documentation/hwmon/max20751.rst index fe701e07eaf5..f9febefce02d 100644 --- a/Documentation/hwmon/max20751.rst +++ b/Documentation/hwmon/max20751.rst @@ -9,9 +9,9 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX20751.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20751.pdf - Application note: http://pdfserv.maximintegrated.com/en/an/AN5941.pdf + Application note: https://pdfserv.maximintegrated.com/en/an/AN5941.pdf Author: Guenter Roeck diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst index 84c62a12ef3a..f301385d8cef 100644 --- a/Documentation/hwmon/max31790.rst +++ b/Documentation/hwmon/max31790.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://pdfserv.maximintegrated.com/en/ds/MAX31790.pdf + Datasheet: https://pdfserv.maximintegrated.com/en/ds/MAX31790.pdf Author: Il Han diff --git a/Documentation/hwmon/max34440.rst b/Documentation/hwmon/max34440.rst index 5744df100a5d..162d289f0814 100644 --- a/Documentation/hwmon/max34440.rst +++ b/Documentation/hwmon/max34440.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34440.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34440.pdf * Maxim MAX34441 @@ -19,7 +19,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34441.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34441.pdf * Maxim MAX34446 @@ -29,7 +29,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34446.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34446.pdf * Maxim MAX34451 @@ -39,7 +39,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34451.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34451.pdf * Maxim MAX34460 @@ -49,7 +49,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34460.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34460.pdf * Maxim MAX34461 @@ -59,7 +59,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34461.pdf Author: Guenter Roeck diff --git a/Documentation/hwmon/nct6775.rst b/Documentation/hwmon/nct6775.rst index 1d0315c40952..5ba8276aad4b 100644 --- a/Documentation/hwmon/nct6775.rst +++ b/Documentation/hwmon/nct6775.rst @@ -276,5 +276,5 @@ temperature measurement device. As a result, the temperature reported on CPUTIN will not reflect a usable value. It often reports unreasonably high temperatures, and in some cases the reported temperature declines if the actual temperature increases (similar to the raw PECI temperature value - see PECI -specification for details). CPUTIN should therefore be be ignored on ASUS +specification for details). CPUTIN should therefore be ignored on ASUS boards. The CPU temperature on ASUS boards is reported from PECI 0. diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst index 2658ddee70eb..66b3e894612f 100644 --- a/Documentation/hwmon/pmbus.rst +++ b/Documentation/hwmon/pmbus.rst @@ -21,11 +21,11 @@ Supported chips: Datasheets: - http://www.onsemi.com/pub_link/Collateral/ADP4000-D.PDF + https://www.onsemi.com/pub_link/Collateral/ADP4000-D.PDF - http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF + https://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF - http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF + https://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF * Lineage Power @@ -53,15 +53,15 @@ Supported chips: Datasheets: - http://www.ti.com/lit/gpn/tps40400 + https://www.ti.com/lit/gpn/tps40400 - http://www.ti.com/lit/gpn/tps544b20 + https://www.ti.com/lit/gpn/tps544b20 - http://www.ti.com/lit/gpn/tps544b25 + https://www.ti.com/lit/gpn/tps544b25 - http://www.ti.com/lit/gpn/tps544c20 + https://www.ti.com/lit/gpn/tps544c20 - http://www.ti.com/lit/gpn/tps544c25 + https://www.ti.com/lit/gpn/tps544c25 * Maxim MAX20796 diff --git a/Documentation/hwmon/sht21.rst b/Documentation/hwmon/sht21.rst index f1f5da030108..1bccc8e8aac8 100644 --- a/Documentation/hwmon/sht21.rst +++ b/Documentation/hwmon/sht21.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Sensirion website - http://www.sensirion.com/file/datasheet_sht21 + https://www.sensirion.com/file/datasheet_sht21 @@ -23,7 +23,7 @@ Supported chips: Datasheet: Publicly available at the Sensirion website - http://www.sensirion.com/file/datasheet_sht25 + https://www.sensirion.com/file/datasheet_sht25 diff --git a/Documentation/hwmon/shtc1.rst b/Documentation/hwmon/shtc1.rst index 08380f21ab6a..f38c4c9d2f74 100644 --- a/Documentation/hwmon/shtc1.rst +++ b/Documentation/hwmon/shtc1.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.sensirion.com/file/datasheet_shtc1 + Datasheet: https://www.sensirion.com/file/datasheet_shtc1 @@ -19,7 +19,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.sensirion.com/file/datasheet_shtw1 + Datasheet: https://www.sensirion.com/file/datasheet_shtw1 @@ -29,7 +29,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.sensirion.com/file/datasheet_shtc3 + Datasheet: https://www.sensirion.com/file/datasheet_shtc3 diff --git a/Documentation/hwmon/sparx5-temp.rst b/Documentation/hwmon/sparx5-temp.rst new file mode 100644 index 000000000000..014080908954 --- /dev/null +++ b/Documentation/hwmon/sparx5-temp.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +Microchip SparX-5 SoC +===================== + +Supported chips: + + * VSC7546, VSC7549, VSC755, VSC7556, and VSC7558 (Sparx5 series) + + Prefix: 'sparx5-temp' + + Addresses scanned: - + + Datasheet: Provided by Microchip upon request and under NDA + +Author: Lars Povlsen + +Description +----------- + +The Sparx5 SoC contains a temperature sensor based on the MR74060 +Moortec IP. + +The sensor has a range of -40°C to +125°C and an accuracy of +/-5°C. + +Sysfs entries +------------- + +The following attributes are supported. + +======================= ======================================================== +temp1_input Die temperature (in millidegree Celsius.) +======================= ======================================================== diff --git a/Documentation/hwmon/thmc50.rst b/Documentation/hwmon/thmc50.rst index cfff3885287d..090f040294a3 100644 --- a/Documentation/hwmon/thmc50.rst +++ b/Documentation/hwmon/thmc50.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x2c - 0x2e - Datasheet: http://www.ti.com/ + Datasheet: https://www.ti.com/ Author: Krzysztof Helt diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst index 205de6148fcb..e195a7d14309 100644 --- a/Documentation/hwmon/tmp103.rst +++ b/Documentation/hwmon/tmp103.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: none - Product info and datasheet: http://www.ti.com/product/tmp103 + Product info and datasheet: https://www.ti.com/product/tmp103 Author: diff --git a/Documentation/hwmon/tmp108.rst b/Documentation/hwmon/tmp108.rst index 5f4266a16cb2..6df7cf1b42f4 100644 --- a/Documentation/hwmon/tmp108.rst +++ b/Documentation/hwmon/tmp108.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.ti.com/product/tmp108 + Datasheet: https://www.ti.com/product/tmp108 Author: diff --git a/Documentation/hwmon/tmp401.rst b/Documentation/hwmon/tmp401.rst index 6a05a0719bc7..14bf1fbf4493 100644 --- a/Documentation/hwmon/tmp401.rst +++ b/Documentation/hwmon/tmp401.rst @@ -47,7 +47,7 @@ Supported chips: Prefix: 'tmp461' - Datasheet: http://www.ti.com/product/tmp461 + Datasheet: https://www.ti.com/product/tmp461 diff --git a/Documentation/hwmon/tmp421.rst b/Documentation/hwmon/tmp421.rst index 1ba926a3605c..ddcd5159c75d 100644 --- a/Documentation/hwmon/tmp421.rst +++ b/Documentation/hwmon/tmp421.rst @@ -33,7 +33,7 @@ Supported chips: Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f - Datasheet: http://www.ti.com/product/tmp441 + Datasheet: https://www.ti.com/product/tmp441 * Texas Instruments TMP442 @@ -41,7 +41,7 @@ Supported chips: Addresses scanned: I2C 0x4c and 0x4d - Datasheet: http://www.ti.com/product/tmp442 + Datasheet: https://www.ti.com/product/tmp442 Authors: diff --git a/Documentation/hwmon/tmp513.rst b/Documentation/hwmon/tmp513.rst index 6c8fae4b1a75..f2dfc1677ad9 100644 --- a/Documentation/hwmon/tmp513.rst +++ b/Documentation/hwmon/tmp513.rst @@ -9,13 +9,13 @@ Supported chips: Prefix: 'tmp512' - Datasheet: http://www.ti.com/lit/ds/symlink/tmp512.pdf + Datasheet: https://www.ti.com/lit/ds/symlink/tmp512.pdf * Texas Instruments TMP513 Prefix: 'tmp513' - Datasheet: http://www.ti.com/lit/ds/symlink/tmp513.pdf + Datasheet: https://www.ti.com/lit/ds/symlink/tmp513.pdf Authors: diff --git a/Documentation/hwmon/tps40422.rst b/Documentation/hwmon/tps40422.rst index 8fe3e1c3572e..32a62ccea192 100644 --- a/Documentation/hwmon/tps40422.rst +++ b/Documentation/hwmon/tps40422.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/tps40422 + Datasheet: https://www.ti.com/lit/gpn/tps40422 Author: Zhu Laiwen diff --git a/Documentation/hwmon/tps53679.rst b/Documentation/hwmon/tps53679.rst index be94cab78967..c7c589e49789 100644 --- a/Documentation/hwmon/tps53679.rst +++ b/Documentation/hwmon/tps53679.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/tps53647 + Datasheet: https://www.ti.com/lit/gpn/tps53647 * Texas Instruments TPS53667 @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/TPS53667 + Datasheet: https://www.ti.com/lit/gpn/TPS53667 * Texas Instruments TPS53679 @@ -25,7 +25,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/TPS53679 (short version) + Datasheet: https://www.ti.com/lit/gpn/TPS53679 (short version) * Texas Instruments TPS53681 @@ -33,7 +33,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/TPS53681 + Datasheet: https://www.ti.com/lit/gpn/TPS53681 * Texas Instruments TPS53688 diff --git a/Documentation/hwmon/w83627ehf.rst b/Documentation/hwmon/w83627ehf.rst index 74d19ef11e1f..7bb557c94858 100644 --- a/Documentation/hwmon/w83627ehf.rst +++ b/Documentation/hwmon/w83627ehf.rst @@ -96,7 +96,7 @@ sensors. The configured source for each of the temperature sensors is provided in tempX_label. Temperatures are measured in degrees Celsius and measurement resolution is 1 -degC for temp1 and and 0.5 degC for temp2 and temp3. For temp4 and higher, +degC for temp1 and 0.5 degC for temp2 and temp3. For temp4 and higher, resolution is 1 degC for W83667HG-B and 0.0 degC for NCT6775F and NCT6776F. An alarm is triggered when the temperature gets higher than high limit; it stays on until the temperature falls below the hysteresis value. diff --git a/Documentation/hwmon/w83781d.rst b/Documentation/hwmon/w83781d.rst index f36d33dfb704..c2dcb6856012 100644 --- a/Documentation/hwmon/w83781d.rst +++ b/Documentation/hwmon/w83781d.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x28 - 0x2f, ISA 0x290 (8 I/O ports) - Datasheet: http://www.winbond.com + Datasheet: https://www.winbond.com * Winbond W83783S diff --git a/Documentation/hwmon/w83l786ng.rst b/Documentation/hwmon/w83l786ng.rst index 2b7776190de3..06234dea42a2 100644 --- a/Documentation/hwmon/w83l786ng.rst +++ b/Documentation/hwmon/w83l786ng.rst @@ -36,7 +36,7 @@ Temperatures are measured in degrees Celsius and measurement resolution is 1 degC for temp1 and temp2. Fan rotation speeds are reported in RPM (rotations per minute). Fan readings -readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 +can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or 128 for fan 1/2) to give the readings more range or accuracy. Voltage sensors (also known as IN sensors) report their values in millivolts. diff --git a/Documentation/i2c/upgrading-clients.rst b/Documentation/i2c/upgrading-clients.rst index 27d29032c138..1708090d7b8f 100644 --- a/Documentation/i2c/upgrading-clients.rst +++ b/Documentation/i2c/upgrading-clients.rst @@ -8,7 +8,7 @@ Introduction ------------ This guide outlines how to alter existing Linux 2.6 client drivers from -the old to the new new binding methods. +the old to the new binding methods. Example old-style driver diff --git a/Documentation/ia64/efirtc.rst b/Documentation/ia64/efirtc.rst index 2f7ff5026308..fd8328408301 100644 --- a/Documentation/ia64/efirtc.rst +++ b/Documentation/ia64/efirtc.rst @@ -113,7 +113,7 @@ We have added 2 new ioctl()s that are specific to the EFI driver: Read the current state of the alarm:: - ioctl(d, RTC_WKLAM_RD, &wkt) + ioctl(d, RTC_WKALM_RD, &wkt) Set the alarm or change its status:: diff --git a/Documentation/index.rst b/Documentation/index.rst index 71eca3171574..57719744774c 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -182,6 +182,20 @@ subprojects. filesystems/ext4/index +Other documentation +------------------- + +There are several unsorted documents that don't seem to fit on other parts +of the documentation body, or may require some adjustments and/or conversion +to ReStructured Text format, or are simply too old. + +.. toctree:: + :maxdepth: 2 + + staging/index + watch_queue + + Translations ------------ diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index a1601ec3317b..39881b719782 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -681,7 +681,7 @@ translate Kconfig logic into boolean formulas and run a SAT solver on this to find dead code / features (always inactive), 114 dead features were found in Linux using this methodology [1]_ (Section 8: Threats to validity). -Confirming this could prove useful as Kconfig stands as one of the the leading +Confirming this could prove useful as Kconfig stands as one of the leading industrial variability modeling languages [1]_ [2]_. Its study would help evaluate practical uses of such languages, their use was only theoretical and real world requirements were not well understood. As it stands though diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index 060f4e485897..bc70c6aa7138 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -9,6 +9,7 @@ LEDs leds-class leds-class-flash + leds-class-multicolor ledtrig-oneshot ledtrig-transient ledtrig-usbport diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst new file mode 100644 index 000000000000..c57b98bfd387 --- /dev/null +++ b/Documentation/leds/leds-class-multicolor.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================== +Multicolor LED handling under Linux +==================================== + +Description +=========== +The multicolor class groups monochrome LEDs and allows controlling two +aspects of the final combined color: hue and lightness. The former is +controlled via the multi_intensity array file and the latter is controlled +via brightness file. + +Multicolor Class Control +======================== +The multicolor class presents files that groups the colors as indexes in an +array. These files are children under the LED parent node created by the +led_class framework. The led_class framework is documented in led-class.rst +within this documentation directory. + +Each colored LED will be indexed under the multi_* files. The order of the +colors will be arbitrary. The multi_index file can be read to determine the +color name to indexed value. + +The multi_index file is an array that contains the string list of the colors as +they are defined in each multi_* array file. + +The multi_intensity is an array that can be read or written to for the +individual color intensities. All elements within this array must be written in +order for the color LED intensities to be updated. + +Directory Layout Example +======================== +root:/sys/class/leds/multicolor:status# ls -lR +-rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness +-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness +-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index +-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity + +Multicolor Class Brightness Control +=================================== +The brightness level for each LED is calculated based on the color LED +intensity setting divided by the global max_brightness setting multiplied by +the requested brightness. + +led_brightness = brightness * multi_intensity/max_brightness + +Example: +A user first writes the multi_intensity file with the brightness levels +for each LED that are necessary to achieve a certain color output from a +multicolor LED group. + +cat /sys/class/leds/multicolor:status/multi_index +green blue red + +echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity + +red - + intensity = 138 + max_brightness = 255 +green - + intensity = 43 + max_brightness = 255 +blue - + intensity = 226 + max_brightness = 255 + +The user can control the brightness of that multicolor LED group by writing the +global 'brightness' control. Assuming a max_brightness of 255 the user +may want to dim the LED color group to half. The user would write a value of +128 to the global brightness file then the values written to each LED will be +adjusted base on this value. + +cat /sys/class/leds/multicolor:status/max_brightness +255 +echo 128 > /sys/class/leds/multicolor:status/brightness + +adjusted_red_value = 128 * 138/255 = 69 +adjusted_green_value = 128 * 43/255 = 21 +adjusted_blue_value = 128 * 226/255 = 113 + +Reading the global brightness file will return the current brightness value of +the color LED group. + +cat /sys/class/leds/multicolor:status/brightness +128 diff --git a/Documentation/leds/ledtrig-transient.rst b/Documentation/leds/ledtrig-transient.rst index d921dc830cd0..eedfa1626e8a 100644 --- a/Documentation/leds/ledtrig-transient.rst +++ b/Documentation/leds/ledtrig-transient.rst @@ -157,7 +157,7 @@ repeat the following step as needed:: echo 1 > activate - start timer = duration to run once echo none > trigger -This trigger is intended to be used for for the following example use cases: +This trigger is intended to be used for the following example use cases: - Control of vibrate (phones, tablets etc.) hardware by user space app. - Use of LED by user space app as activity indicator. diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README new file mode 100644 index 000000000000..7f5c6c3ed6c3 --- /dev/null +++ b/Documentation/litmus-tests/README @@ -0,0 +1,35 @@ +============ +LITMUS TESTS +============ + +Each subdirectory contains litmus tests that are typical to describe the +semantics of respective kernel APIs. +For more information about how to "run" a litmus test or how to generate +a kernel test module based on a litmus test, please see +tools/memory-model/README. + + +atomic (/atomic derectory) +-------------------------- + +Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus + Test that an atomic RMW followed by a smp_mb__after_atomic() is + stronger than a normal acquire: both the read and write parts of + the RMW are ordered before the subsequential memory accesses. + +Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus + Test that atomic_set() cannot break the atomicity of atomic RMWs. + NOTE: Require herd7 7.56 or later which supports "(void)expr". + + +RCU (/rcu directory) +-------------------- + +MP+onceassign+derefonce.litmus (under tools/memory-model/litmus-tests/) + Demonstrates the use of rcu_assign_pointer() and rcu_dereference() to + ensure that an RCU reader will not see pre-initialization garbage. + +RCU+sync+read.litmus +RCU+sync+free.litmus + Both the above litmus tests demonstrate the RCU grace period guarantee + that an RCU read-side critical section can never span a grace period. diff --git a/Documentation/litmus-tests/atomic/Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus b/Documentation/litmus-tests/atomic/Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus new file mode 100644 index 000000000000..9a8e31a44b28 --- /dev/null +++ b/Documentation/litmus-tests/atomic/Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus @@ -0,0 +1,32 @@ +C Atomic-RMW+mb__after_atomic-is-stronger-than-acquire + +(* + * Result: Never + * + * Test that an atomic RMW followed by a smp_mb__after_atomic() is + * stronger than a normal acquire: both the read and write parts of + * the RMW are ordered before the subsequential memory accesses. + *) + +{ +} + +P0(int *x, atomic_t *y) +{ + int r0; + int r1; + + r0 = READ_ONCE(*x); + smp_rmb(); + r1 = atomic_read(y); +} + +P1(int *x, atomic_t *y) +{ + atomic_inc(y); + smp_mb__after_atomic(); + WRITE_ONCE(*x, 1); +} + +exists +(0:r0=1 /\ 0:r1=0) diff --git a/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus b/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus new file mode 100644 index 000000000000..ffd4d3e79c4a --- /dev/null +++ b/Documentation/litmus-tests/atomic/Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus @@ -0,0 +1,25 @@ +C Atomic-RMW-ops-are-atomic-WRT-atomic_set + +(* + * Result: Never + * + * Test that atomic_set() cannot break the atomicity of atomic RMWs. + * NOTE: This requires herd7 7.56 or later which supports "(void)expr". + *) + +{ + atomic_t v = ATOMIC_INIT(1); +} + +P0(atomic_t *v) +{ + (void)atomic_add_unless(v, 1, 0); +} + +P1(atomic_t *v) +{ + atomic_set(v, 0); +} + +exists +(v=2) diff --git a/Documentation/litmus-tests/rcu/RCU+sync+free.litmus b/Documentation/litmus-tests/rcu/RCU+sync+free.litmus new file mode 100644 index 000000000000..4ee67e12f513 --- /dev/null +++ b/Documentation/litmus-tests/rcu/RCU+sync+free.litmus @@ -0,0 +1,42 @@ +C RCU+sync+free + +(* + * Result: Never + * + * This litmus test demonstrates that an RCU reader can never see a write that + * follows a grace period, if it did not see writes that precede that grace + * period. + * + * This is a typical pattern of RCU usage, where the write before the grace + * period assigns a pointer, and the writes following the grace period destroy + * the object that the pointer used to point to. + * + * This is one implication of the RCU grace-period guarantee, which says (among + * other things) that an RCU read-side critical section cannot span a grace period. + *) + +{ +int x = 1; +int *y = &x; +int z = 1; +} + +P0(int *x, int *z, int **y) +{ + int *r0; + int r1; + + rcu_read_lock(); + r0 = rcu_dereference(*y); + r1 = READ_ONCE(*r0); + rcu_read_unlock(); +} + +P1(int *x, int *z, int **y) +{ + rcu_assign_pointer(*y, z); + synchronize_rcu(); + WRITE_ONCE(*x, 0); +} + +exists (0:r0=x /\ 0:r1=0) diff --git a/Documentation/litmus-tests/rcu/RCU+sync+read.litmus b/Documentation/litmus-tests/rcu/RCU+sync+read.litmus new file mode 100644 index 000000000000..f34176720231 --- /dev/null +++ b/Documentation/litmus-tests/rcu/RCU+sync+read.litmus @@ -0,0 +1,37 @@ +C RCU+sync+read + +(* + * Result: Never + * + * This litmus test demonstrates that after a grace period, an RCU updater always + * sees all stores done in prior RCU read-side critical sections. Such + * read-side critical sections would have ended before the grace period ended. + * + * This is one implication of the RCU grace-period guarantee, which says (among + * other things) that an RCU read-side critical section cannot span a grace period. + *) + +{ +int x = 0; +int y = 0; +} + +P0(int *x, int *y) +{ + rcu_read_lock(); + WRITE_ONCE(*x, 1); + WRITE_ONCE(*y, 1); + rcu_read_unlock(); +} + +P1(int *x, int *y) +{ + int r0; + int r1; + + r0 = READ_ONCE(*x); + synchronize_rcu(); + r1 = READ_ONCE(*y); +} + +exists (1:r0=1 /\ 1:r1=0) diff --git a/Documentation/locking/index.rst b/Documentation/locking/index.rst index d785878cad65..7003bd5aeff4 100644 --- a/Documentation/locking/index.rst +++ b/Documentation/locking/index.rst @@ -14,6 +14,7 @@ locking mutex-design rt-mutex-design rt-mutex + seqlock spinlocks ww-mutex-design preempt-locking diff --git a/Documentation/locking/locktorture.rst b/Documentation/locking/locktorture.rst index 8012a74555e7..dfaf9fc883f4 100644 --- a/Documentation/locking/locktorture.rst +++ b/Documentation/locking/locktorture.rst @@ -166,4 +166,4 @@ checked for such errors. The "rmmod" command forces a "SUCCESS", two are self-explanatory, while the last indicates that while there were no locking failures, CPU-hotplug problems were detected. -Also see: Documentation/RCU/torture.txt +Also see: Documentation/RCU/torture.rst diff --git a/Documentation/locking/mutex-design.rst b/Documentation/locking/mutex-design.rst index 4d8236b81fa5..78540cd7f54b 100644 --- a/Documentation/locking/mutex-design.rst +++ b/Documentation/locking/mutex-design.rst @@ -18,7 +18,7 @@ as an alternative to these. This new data structure provided a number of advantages, including simpler interfaces, and at that time smaller code (see Disadvantages). -[1] http://lwn.net/Articles/164802/ +[1] https://lwn.net/Articles/164802/ Implementation -------------- @@ -28,7 +28,7 @@ and implemented in kernel/locking/mutex.c. These locks use an atomic variable (->owner) to keep track of the lock state during its lifetime. Field owner actually contains `struct task_struct *` to the current lock owner and it is therefore NULL if not currently owned. Since task_struct pointers are aligned -at at least L1_CACHE_BYTES, low bits (3) are used to store extra state (e.g., +to at least L1_CACHE_BYTES, low bits (3) are used to store extra state (e.g., if waiter list is non-empty). In its most basic form it also includes a wait-queue and a spinlock that serializes access to it. Furthermore, CONFIG_MUTEX_SPIN_ON_OWNER=y systems use a spinner MCS lock (->osq), described diff --git a/Documentation/locking/seqlock.rst b/Documentation/locking/seqlock.rst new file mode 100644 index 000000000000..366dd368d90a --- /dev/null +++ b/Documentation/locking/seqlock.rst @@ -0,0 +1,170 @@ +====================================== +Sequence counters and sequential locks +====================================== + +Introduction +============ + +Sequence counters are a reader-writer consistency mechanism with +lockless readers (read-only retry loops), and no writer starvation. They +are used for data that's rarely written to (e.g. system time), where the +reader wants a consistent set of information and is willing to retry if +that information changes. + +A data set is consistent when the sequence count at the beginning of the +read side critical section is even and the same sequence count value is +read again at the end of the critical section. The data in the set must +be copied out inside the read side critical section. If the sequence +count has changed between the start and the end of the critical section, +the reader must retry. + +Writers increment the sequence count at the start and the end of their +critical section. After starting the critical section the sequence count +is odd and indicates to the readers that an update is in progress. At +the end of the write side critical section the sequence count becomes +even again which lets readers make progress. + +A sequence counter write side critical section must never be preempted +or interrupted by read side sections. Otherwise the reader will spin for +the entire scheduler tick due to the odd sequence count value and the +interrupted writer. If that reader belongs to a real-time scheduling +class, it can spin forever and the kernel will livelock. + +This mechanism cannot be used if the protected data contains pointers, +as the writer can invalidate a pointer that the reader is following. + + +.. _seqcount_t: + +Sequence counters (``seqcount_t``) +================================== + +This is the the raw counting mechanism, which does not protect against +multiple writers. Write side critical sections must thus be serialized +by an external lock. + +If the write serialization primitive is not implicitly disabling +preemption, preemption must be explicitly disabled before entering the +write side section. If the read section can be invoked from hardirq or +softirq contexts, interrupts or bottom halves must also be respectively +disabled before entering the write section. + +If it's desired to automatically handle the sequence counter +requirements of writer serialization and non-preemptibility, use +:ref:`seqlock_t` instead. + +Initialization:: + + /* dynamic */ + seqcount_t foo_seqcount; + seqcount_init(&foo_seqcount); + + /* static */ + static seqcount_t foo_seqcount = SEQCNT_ZERO(foo_seqcount); + + /* C99 struct init */ + struct { + .seq = SEQCNT_ZERO(foo.seq), + } foo; + +Write path:: + + /* Serialized context with disabled preemption */ + + write_seqcount_begin(&foo_seqcount); + + /* ... [[write-side critical section]] ... */ + + write_seqcount_end(&foo_seqcount); + +Read path:: + + do { + seq = read_seqcount_begin(&foo_seqcount); + + /* ... [[read-side critical section]] ... */ + + } while (read_seqcount_retry(&foo_seqcount, seq)); + + +.. _seqlock_t: + +Sequential locks (``seqlock_t``) +================================ + +This contains the :ref:`seqcount_t` mechanism earlier discussed, plus an +embedded spinlock for writer serialization and non-preemptibility. + +If the read side section can be invoked from hardirq or softirq context, +use the write side function variants which disable interrupts or bottom +halves respectively. + +Initialization:: + + /* dynamic */ + seqlock_t foo_seqlock; + seqlock_init(&foo_seqlock); + + /* static */ + static DEFINE_SEQLOCK(foo_seqlock); + + /* C99 struct init */ + struct { + .seql = __SEQLOCK_UNLOCKED(foo.seql) + } foo; + +Write path:: + + write_seqlock(&foo_seqlock); + + /* ... [[write-side critical section]] ... */ + + write_sequnlock(&foo_seqlock); + +Read path, three categories: + +1. Normal Sequence readers which never block a writer but they must + retry if a writer is in progress by detecting change in the sequence + number. Writers do not wait for a sequence reader:: + + do { + seq = read_seqbegin(&foo_seqlock); + + /* ... [[read-side critical section]] ... */ + + } while (read_seqretry(&foo_seqlock, seq)); + +2. Locking readers which will wait if a writer or another locking reader + is in progress. A locking reader in progress will also block a writer + from entering its critical section. This read lock is + exclusive. Unlike rwlock_t, only one locking reader can acquire it:: + + read_seqlock_excl(&foo_seqlock); + + /* ... [[read-side critical section]] ... */ + + read_sequnlock_excl(&foo_seqlock); + +3. Conditional lockless reader (as in 1), or locking reader (as in 2), + according to a passed marker. This is used to avoid lockless readers + starvation (too much retry loops) in case of a sharp spike in write + activity. First, a lockless read is tried (even marker passed). If + that trial fails (odd sequence counter is returned, which is used as + the next iteration marker), the lockless read is transformed to a + full locking read and no retry loop is necessary:: + + /* marker; even initialization */ + int seq = 0; + do { + read_seqbegin_or_lock(&foo_seqlock, &seq); + + /* ... [[read-side critical section]] ... */ + + } while (need_seqretry(&foo_seqlock, seq)); + done_seqretry(&foo_seqlock, seq); + + +API documentation +================= + +.. kernel-doc:: include/linux/seqlock.h diff --git a/Documentation/locking/ww-mutex-design.rst b/Documentation/locking/ww-mutex-design.rst index 1846c199da23..54d9c17bb66b 100644 --- a/Documentation/locking/ww-mutex-design.rst +++ b/Documentation/locking/ww-mutex-design.rst @@ -49,7 +49,7 @@ However, the Wound-Wait algorithm is typically stated to generate fewer backoffs compared to Wait-Die, but is, on the other hand, associated with more work than Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive algorithm in that transactions are wounded by other transactions, and that -requires a reliable way to pick up up the wounded condition and preempt the +requires a reliable way to pick up the wounded condition and preempt the running transaction. Note that this is not the same as process preemption. A Wound-Wait transaction is considered preempted when it dies (returning -EDEADLK) following a wound. diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index 77e43c8b24b4..227f427118e8 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -31,7 +31,7 @@ Example questions to consider: - What branch should contributors submit against? - Links to any other Maintainer Entry Profiles? For example a device-driver may point to an entry for its parent subsystem. This makes - the contributor aware of obligations a maintainer may have have for + the contributor aware of obligations a maintainer may have for other maintainers in the submission chain. diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index eaabc3134294..4e55aba3eb4a 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -553,12 +553,12 @@ There are certain things that the Linux kernel memory barriers do not guarantee: DATA DEPENDENCY BARRIERS (HISTORICAL) ------------------------------------- -As of v4.15 of the Linux kernel, an smp_read_barrier_depends() was -added to READ_ONCE(), which means that about the only people who -need to pay attention to this section are those working on DEC Alpha -architecture-specific code and those working on READ_ONCE() itself. -For those who need it, and for those who are interested in the history, -here is the story of data-dependency barriers. +As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for +DEC Alpha, which means that about the only people who need to pay attention +to this section are those working on DEC Alpha architecture-specific code +and those working on READ_ONCE() itself. For those who need it, and for +those who are interested in the history, here is the story of +data-dependency barriers. The usage requirements of data dependency barriers are a little subtle, and it's not always obvious that they're needed. To illustrate, consider the @@ -2708,144 +2708,6 @@ the properties of the memory window through which devices are accessed and/or the use of any special device communication instructions the CPU may have. -CACHE COHERENCY ---------------- - -Life isn't quite as simple as it may appear above, however: for while the -caches are expected to be coherent, there's no guarantee that that coherency -will be ordered. This means that while changes made on one CPU will -eventually become visible on all CPUs, there's no guarantee that they will -become apparent in the same order on those other CPUs. - - -Consider dealing with a system that has a pair of CPUs (1 & 2), each of which -has a pair of parallel data caches (CPU 1 has A/B, and CPU 2 has C/D): - - : - : +--------+ - : +---------+ | | - +--------+ : +--->| Cache A |<------->| | - | | : | +---------+ | | - | CPU 1 |<---+ | | - | | : | +---------+ | | - +--------+ : +--->| Cache B |<------->| | - : +---------+ | | - : | Memory | - : +---------+ | System | - +--------+ : +--->| Cache C |<------->| | - | | : | +---------+ | | - | CPU 2 |<---+ | | - | | : | +---------+ | | - +--------+ : +--->| Cache D |<------->| | - : +---------+ | | - : +--------+ - : - -Imagine the system has the following properties: - - (*) an odd-numbered cache line may be in cache A, cache C or it may still be - resident in memory; - - (*) an even-numbered cache line may be in cache B, cache D or it may still be - resident in memory; - - (*) while the CPU core is interrogating one cache, the other cache may be - making use of the bus to access the rest of the system - perhaps to - displace a dirty cacheline or to do a speculative load; - - (*) each cache has a queue of operations that need to be applied to that cache - to maintain coherency with the rest of the system; - - (*) the coherency queue is not flushed by normal loads to lines already - present in the cache, even though the contents of the queue may - potentially affect those loads. - -Imagine, then, that two writes are made on the first CPU, with a write barrier -between them to guarantee that they will appear to reach that CPU's caches in -the requisite order: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); Make sure change to v is visible before - change to p - v is now in cache A exclusively - p = &v; - p is now in cache B exclusively - -The write memory barrier forces the other CPUs in the system to perceive that -the local CPU's caches have apparently been updated in the correct order. But -now imagine that the second CPU wants to read those values: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - ... - q = p; - x = *q; - -The above pair of reads may then fail to happen in the expected order, as the -cacheline holding p may get updated in one of the second CPU's caches while -the update to the cacheline holding v is delayed in the other of the second -CPU's caches by some other cache event: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); - - - p = &v; q = p; - - - - x = *q; - Reads from v before v updated in cache - - - -Basically, while both cachelines will be updated on CPU 2 eventually, there's -no guarantee that, without intervention, the order of update will be the same -as that committed on CPU 1. - - -To intervene, we need to interpolate a data dependency barrier or a read -barrier between the loads (which as of v4.15 is supplied unconditionally -by the READ_ONCE() macro). This will force the cache to commit its -coherency queue before processing any further requests: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); - - - p = &v; q = p; - - - - smp_read_barrier_depends() - - - x = *q; - Reads from v after v updated in cache - - -This sort of problem can be encountered on DEC Alpha processors as they have a -split cache that improves performance by making better use of the data bus. -While most CPUs do imply a data dependency barrier on the read when a memory -access depends on a read, not all do, so it may not be relied on. - -Other CPUs may also have split caches, but must coordinate between the various -cachelets for normal memory accesses. The semantics of the Alpha removes the -need for hardware coordination in the absence of memory barriers, which -permitted Alpha to sport higher CPU clock rates back in the day. However, -please note that (again, as of v4.15) smp_read_barrier_depends() should not -be used except in Alpha arch-specific code and within the READ_ONCE() macro. - - CACHE COHERENCY VS DMA ---------------------- @@ -3009,10 +2871,8 @@ caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. The Alpha defines the Linux kernel's memory model, although as of v4.15 -the Linux kernel's addition of smp_read_barrier_depends() to READ_ONCE() -greatly reduced Alpha's impact on the memory model. - -See the subsection on "Cache Coherency" above. +the Linux kernel's addition of smp_mb() to READ_ONCE() on Alpha greatly +reduced its impact on the memory model. VIRTUAL MACHINE GUESTS diff --git a/Documentation/mips/ingenic-tcu.rst b/Documentation/mips/ingenic-tcu.rst index 2b75760619b4..2ce4cb1314dc 100644 --- a/Documentation/mips/ingenic-tcu.rst +++ b/Documentation/mips/ingenic-tcu.rst @@ -5,7 +5,7 @@ Ingenic JZ47xx SoCs Timer/Counter Unit hardware =============================================== The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function -hardware block. It features up to to eight channels, that can be used as +hardware block. It features up to eight channels, that can be used as counters, timers, or PWM. - JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all diff --git a/Documentation/misc-devices/ad525x_dpot.txt b/Documentation/misc-devices/ad525x_dpot.rst similarity index 85% rename from Documentation/misc-devices/ad525x_dpot.txt rename to Documentation/misc-devices/ad525x_dpot.rst index 0c9413b1cbf3..6483ec254520 100644 --- a/Documentation/misc-devices/ad525x_dpot.txt +++ b/Documentation/misc-devices/ad525x_dpot.rst @@ -1,6 +1,8 @@ ---------------------------------- - AD525x Digital Potentiometers ---------------------------------- +.. SPDX-License-Identifier: GPL-2.0 + +============================= +AD525x Digital Potentiometers +============================= The ad525x_dpot driver exports a simple sysfs interface. This allows you to work with the immediate resistance settings as well as update the saved startup @@ -8,9 +10,8 @@ settings. Access to the factory programmed tolerance is also provided, but interpretation of this settings is required by the end application according to the specific part in use. ---------- - Files ---------- +Files +===== Each dpot device will have a set of eeprom, rdac, and tolerance files. How many depends on the actual part you have, as will the range of allowed values. @@ -24,23 +25,22 @@ and may vary greatly on a part-by-part basis. For exact interpretation of this field, please consult the datasheet for your part. This is presented as a hex file for easier parsing. ------------ - Example ------------ +Example +======= Locate the device in your sysfs tree. This is probably easiest by going into -the common i2c directory and locating the device by the i2c slave address. +the common i2c directory and locating the device by the i2c slave address:: # ls /sys/bus/i2c/devices/ 0-0022 0-0027 0-002f So assuming the device in question is on the first i2c bus and has the slave -address of 0x2f, we descend (unrelated sysfs entries have been trimmed). +address of 0x2f, we descend (unrelated sysfs entries have been trimmed):: # ls /sys/bus/i2c/devices/0-002f/ eeprom0 rdac0 tolerance0 -You can use simple reads/writes to access these files: +You can use simple reads/writes to access these files:: # cd /sys/bus/i2c/devices/0-002f/ diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.rst similarity index 86% rename from Documentation/misc-devices/apds990x.txt rename to Documentation/misc-devices/apds990x.rst index 454d95d623b3..e2f75577f731 100644 --- a/Documentation/misc-devices/apds990x.txt +++ b/Documentation/misc-devices/apds990x.rst @@ -1,3 +1,6 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== Kernel driver apds990x ====================== @@ -50,14 +53,18 @@ chip_id power_state RW - enable / disable chip. Uses counting logic + 1 enables the chip 0 disables the chip lux0_input RO - measured lux value + sysfs_notify called when threshold interrupt occurs lux0_sensor_range - RO - lux0_input max value. Actually never reaches since sensor tends + RO - lux0_input max value. + + Actually never reaches since sensor tends to saturate much before that. Real max value varies depending on the light spectrum etc. @@ -68,7 +75,9 @@ lux0_rate_avail RO - supported measurement rates lux0_calibscale - RW - calibration value. Set to neutral value by default. + RW - calibration value. + + Set to neutral value by default. Output results are multiplied with calibscale / calibscale_default value. @@ -76,16 +85,21 @@ lux0_calibscale_default RO - neutral calibration value lux0_thresh_above_value - RW - HI level threshold value. All results above the value + RW - HI level threshold value. + + All results above the value trigs an interrupt. 65535 (i.e. sensor_range) disables the above interrupt. lux0_thresh_below_value - RW - LO level threshold value. All results below the value + RW - LO level threshold value. + + All results below the value trigs an interrupt. 0 disables the below interrupt. prox0_raw RO - measured proximity value + sysfs_notify called when threshold interrupt occurs prox0_sensor_range @@ -93,11 +107,14 @@ prox0_sensor_range prox0_raw_en RW - enable / disable proximity - uses counting logic - 1 enables the proximity - 0 disables the proximity + + - 1 enables the proximity + - 0 disables the proximity prox0_reporting_mode - RW - trigger / periodic. In "trigger" mode the driver tells two possible + RW - trigger / periodic. + + In "trigger" mode the driver tells two possible values: 0 or prox0_sensor_range value. 0 means no proximity, 1023 means proximity. This causes minimal number of interrupts. In "periodic" mode the driver reports all values above diff --git a/Documentation/misc-devices/bh1770glc.txt b/Documentation/misc-devices/bh1770glc.rst similarity index 83% rename from Documentation/misc-devices/bh1770glc.txt rename to Documentation/misc-devices/bh1770glc.rst index 7d64c014dc70..ea5ca58bb958 100644 --- a/Documentation/misc-devices/bh1770glc.txt +++ b/Documentation/misc-devices/bh1770glc.rst @@ -1,9 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= Kernel driver bh1770glc ======================= Supported chips: -ROHM BH1770GLC -OSRAM SFH7770 + +- ROHM BH1770GLC +- OSRAM SFH7770 Data sheet: Not freely available @@ -48,12 +52,16 @@ chip_id RO - shows detected chip type and version power_state - RW - enable / disable chip. Uses counting logic - 1 enables the chip - 0 disables the chip + RW - enable / disable chip + + Uses counting logic + + - 1 enables the chip + - 0 disables the chip lux0_input RO - measured lux value + sysfs_notify called when threshold interrupt occurs lux0_sensor_range @@ -66,16 +74,22 @@ lux0_rate_avail RO - supported measurement rates lux0_thresh_above_value - RW - HI level threshold value. All results above the value + RW - HI level threshold value + + All results above the value trigs an interrupt. 65535 (i.e. sensor_range) disables the above interrupt. lux0_thresh_below_value - RW - LO level threshold value. All results below the value + RW - LO level threshold value + + All results below the value trigs an interrupt. 0 disables the below interrupt. lux0_calibscale - RW - calibration value. Set to neutral value by default. + RW - calibration value + + Set to neutral value by default. Output results are multiplied with calibscale / calibscale_default value. @@ -84,32 +98,37 @@ lux0_calibscale_default prox0_raw RO - measured proximity value + sysfs_notify called when threshold interrupt occurs prox0_sensor_range RO - prox0_raw max value prox0_raw_en - RW - enable / disable proximity - uses counting logic - 1 enables the proximity - 0 disables the proximity + RW - enable / disable proximity + + Uses counting logic + + - 1 enables the proximity + - 0 disables the proximity prox0_thresh_above_count RW - number of proximity interrupts needed before triggering the event prox0_rate_above RW - Measurement rate (in Hz) when the level is above threshold - i.e. when proximity on has been reported. + i.e. when proximity on has been reported. prox0_rate_below RW - Measurement rate (in Hz) when the level is below threshold - i.e. when proximity off has been reported. + i.e. when proximity off has been reported. prox0_rate_avail RO - Supported proximity measurement rates in Hz prox0_thresh_above0_value RW - threshold level which trigs proximity events. + Filtered by persistence filter (prox0_thresh_above_count) prox0_thresh_above1_value diff --git a/Documentation/misc-devices/c2port.txt b/Documentation/misc-devices/c2port.rst similarity index 61% rename from Documentation/misc-devices/c2port.txt rename to Documentation/misc-devices/c2port.rst index 31351b1a5a1f..7e4f6a79418a 100644 --- a/Documentation/misc-devices/c2port.txt +++ b/Documentation/misc-devices/c2port.rst @@ -1,5 +1,9 @@ - C2 port support - --------------- +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=============== +C2 port support +=============== (C) Copyright 2007 Rodolfo Giometti @@ -32,10 +36,10 @@ The C2 Interface main references are at (https://www.silabs.com) Silicon Laboratories site], see: - AN127: FLASH Programming via the C2 Interface at -https://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf + https://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf - C2 Specification at -https://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults + https://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults however it implements a two wire serial communication protocol (bit banging) designed to enable in-system programming, debugging, and @@ -47,44 +51,44 @@ Using the driver ---------------- Once the driver is loaded you can use sysfs support to get C2port's -info or read/write in-system flash. +info or read/write in-system flash:: -# ls /sys/class/c2port/c2port0/ -access flash_block_size flash_erase rev_id -dev_id flash_blocks_num flash_size subsystem/ -flash_access flash_data reset uevent + # ls /sys/class/c2port/c2port0/ + access flash_block_size flash_erase rev_id + dev_id flash_blocks_num flash_size subsystem/ + flash_access flash_data reset uevent Initially the C2port access is disabled since you hardware may have such lines multiplexed with other devices so, to get access to the -C2port, you need the command: +C2port, you need the command:: -# echo 1 > /sys/class/c2port/c2port0/access + # echo 1 > /sys/class/c2port/c2port0/access after that you should read the device ID and revision ID of the -connected micro controller: +connected micro controller:: -# cat /sys/class/c2port/c2port0/dev_id -8 -# cat /sys/class/c2port/c2port0/rev_id -1 + # cat /sys/class/c2port/c2port0/dev_id + 8 + # cat /sys/class/c2port/c2port0/rev_id + 1 However, for security reasons, the in-system flash access in not -enabled yet, to do so you need the command: +enabled yet, to do so you need the command:: -# echo 1 > /sys/class/c2port/c2port0/flash_access + # echo 1 > /sys/class/c2port/c2port0/flash_access -After that you can read the whole flash: +After that you can read the whole flash:: -# cat /sys/class/c2port/c2port0/flash_data > image + # cat /sys/class/c2port/c2port0/flash_data > image -erase it: +erase it:: -# echo 1 > /sys/class/c2port/c2port0/flash_erase + # echo 1 > /sys/class/c2port/c2port0/flash_erase -and write it: +and write it:: -# cat image > /sys/class/c2port/c2port0/flash_data + # cat image > /sys/class/c2port/c2port0/flash_data -after writing you have to reset the device to execute the new code: +after writing you have to reset the device to execute the new code:: -# echo 1 > /sys/class/c2port/c2port0/reset + # echo 1 > /sys/class/c2port/c2port0/reset diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst index 1ecc05fbe6f4..46072ce3d7ef 100644 --- a/Documentation/misc-devices/index.rst +++ b/Documentation/misc-devices/index.rst @@ -14,12 +14,18 @@ fit into other categories. .. toctree:: :maxdepth: 2 + ad525x_dpot + apds990x + bh1770glc eeprom + c2port ibmvmc ics932s401 isl29003 lis3lv02d max6875 mic/index + pci-endpoint-test + spear-pcie-gadget uacce xilinx_sdfec diff --git a/Documentation/misc-devices/pci-endpoint-test.rst b/Documentation/misc-devices/pci-endpoint-test.rst new file mode 100644 index 000000000000..4cf3f4433be7 --- /dev/null +++ b/Documentation/misc-devices/pci-endpoint-test.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Driver for PCI Endpoint Test Function +===================================== + +This driver should be used as a host side driver if the root complex is +connected to a configurable PCI endpoint running ``pci_epf_test`` function +driver configured according to [1]_. + +The "pci_endpoint_test" driver can be used to perform the following tests. + +The PCI driver for the test device performs the following tests: + + #) verifying addresses programmed in BAR + #) raise legacy IRQ + #) raise MSI IRQ + #) raise MSI-X IRQ + #) read data + #) write data + #) copy data + +This misc driver creates /dev/pci-endpoint-test. for every +``pci_epf_test`` function connected to the root complex and "ioctls" +should be used to perform the above tests. + +ioctl +----- + + PCITEST_BAR: + Tests the BAR. The number of the BAR to be tested + should be passed as argument. + PCITEST_LEGACY_IRQ: + Tests legacy IRQ + PCITEST_MSI: + Tests message signalled interrupts. The MSI number + to be tested should be passed as argument. + PCITEST_MSIX: + Tests message signalled interrupts. The MSI-X number + to be tested should be passed as argument. + PCITEST_SET_IRQTYPE: + Changes driver IRQ type configuration. The IRQ type + should be passed as argument (0: Legacy, 1:MSI, 2:MSI-X). + PCITEST_GET_IRQTYPE: + Gets driver IRQ type configuration. + PCITEST_WRITE: + Perform write tests. The size of the buffer should be passed + as argument. + PCITEST_READ: + Perform read tests. The size of the buffer should be passed + as argument. + PCITEST_COPY: + Perform read tests. The size of the buffer should be passed + as argument. + +.. [1] Documentation/PCI/endpoint/function/binding/pci-test.rst diff --git a/Documentation/misc-devices/pci-endpoint-test.txt b/Documentation/misc-devices/pci-endpoint-test.txt deleted file mode 100644 index 58ccca4416b1..000000000000 --- a/Documentation/misc-devices/pci-endpoint-test.txt +++ /dev/null @@ -1,41 +0,0 @@ -Driver for PCI Endpoint Test Function - -This driver should be used as a host side driver if the root complex is -connected to a configurable PCI endpoint running *pci_epf_test* function -driver configured according to [1]. - -The "pci_endpoint_test" driver can be used to perform the following tests. - -The PCI driver for the test device performs the following tests - *) verifying addresses programmed in BAR - *) raise legacy IRQ - *) raise MSI IRQ - *) raise MSI-X IRQ - *) read data - *) write data - *) copy data - -This misc driver creates /dev/pci-endpoint-test. for every -*pci_epf_test* function connected to the root complex and "ioctls" -should be used to perform the above tests. - -ioctl ------ - PCITEST_BAR: Tests the BAR. The number of the BAR to be tested - should be passed as argument. - PCITEST_LEGACY_IRQ: Tests legacy IRQ - PCITEST_MSI: Tests message signalled interrupts. The MSI number - to be tested should be passed as argument. - PCITEST_MSIX: Tests message signalled interrupts. The MSI-X number - to be tested should be passed as argument. - PCITEST_SET_IRQTYPE: Changes driver IRQ type configuration. The IRQ type - should be passed as argument (0: Legacy, 1:MSI, 2:MSI-X). - PCITEST_GET_IRQTYPE: Gets driver IRQ type configuration. - PCITEST_WRITE: Perform write tests. The size of the buffer should be passed - as argument. - PCITEST_READ: Perform read tests. The size of the buffer should be passed - as argument. - PCITEST_COPY: Perform read tests. The size of the buffer should be passed - as argument. - -[1] -> Documentation/PCI/endpoint/function/binding/pci-test.txt diff --git a/Documentation/misc-devices/spear-pcie-gadget.rst b/Documentation/misc-devices/spear-pcie-gadget.rst new file mode 100644 index 000000000000..09b9d6c7ac15 --- /dev/null +++ b/Documentation/misc-devices/spear-pcie-gadget.rst @@ -0,0 +1,170 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +Spear PCIe Gadget Driver +======================== + +Author +====== +Pratyush Anand (pratyush.anand@gmail.com) + +Location +======== +driver/misc/spear13xx_pcie_gadget.c + +Supported Chip: +=============== +SPEAr1300 +SPEAr1310 + +Menuconfig option: +================== +Device Drivers + Misc devices + PCIe gadget support for SPEAr13XX platform + +purpose +======= +This driver has several nodes which can be read/written by configfs interface. +Its main purpose is to configure selected dual mode PCIe controller as device +and then program its various registers to configure it as a particular device +type. This driver can be used to show spear's PCIe device capability. + +Description of different nodes: +=============================== + +read behavior of nodes: +----------------------- + +=============== ============================================================== +link gives ltssm status. +int_type type of supported interrupt +no_of_msi zero if MSI is not enabled by host. A positive value is the + number of MSI vector granted. +vendor_id returns programmed vendor id (hex) +device_id returns programmed device id(hex) +bar0_size: returns size of bar0 in hex. +bar0_address returns address of bar0 mapped area in hex. +bar0_rw_offset returns offset of bar0 for which bar0_data will return value. +bar0_data returns data at bar0_rw_offset. +=============== ============================================================== + +write behavior of nodes: +------------------------ + +=============== ================================================================ +link write UP to enable ltsmm DOWN to disable +int_type write interrupt type to be configured and (int_type could be + INTA, MSI or NO_INT). Select MSI only when you have programmed + no_of_msi node. +no_of_msi number of MSI vector needed. +inta write 1 to assert INTA and 0 to de-assert. +send_msi write MSI vector to be sent. +vendor_id write vendor id(hex) to be programmed. +device_id write device id(hex) to be programmed. +bar0_size write size of bar0 in hex. default bar0 size is 1000 (hex) + bytes. +bar0_address write address of bar0 mapped area in hex. (default mapping of + bar0 is SYSRAM1(E0800000). Always program bar size before bar + address. Kernel might modify bar size and address for alignment, + so read back bar size and address after writing to cross check. +bar0_rw_offset write offset of bar0 for which bar0_data will write value. +bar0_data write data to be written at bar0_rw_offset. +=============== ================================================================ + +Node programming example +======================== + +Program all PCIe registers in such a way that when this device is connected +to the PCIe host, then host sees this device as 1MB RAM. + +:: + + #mount -t configfs none /Config + +For nth PCIe Device Controller:: + + # cd /config/pcie_gadget.n/ + +Now you have all the nodes in this directory. +program vendor id as 0x104a:: + + # echo 104A >> vendor_id + +program device id as 0xCD80:: + + # echo CD80 >> device_id + +program BAR0 size as 1MB:: + + # echo 100000 >> bar0_size + +check for programmed bar0 size:: + + # cat bar0_size + +Program BAR0 Address as DDR (0x2100000). This is the physical address of +memory, which is to be made visible to PCIe host. Similarly any other peripheral +can also be made visible to PCIe host. E.g., if you program base address of UART +as BAR0 address then when this device will be connected to a host, it will be +visible as UART. + +:: + + # echo 2100000 >> bar0_address + +program interrupt type : INTA:: + + # echo INTA >> int_type + +go for link up now:: + + # echo UP >> link + +It will have to be insured that, once link up is done on gadget, then only host +is initialized and start to search PCIe devices on its port. + +:: + + /*wait till link is up*/ + # cat link + +Wait till it returns UP. + +To assert INTA:: + + # echo 1 >> inta + +To de-assert INTA:: + + # echo 0 >> inta + +if MSI is to be used as interrupt, program no of msi vector needed (say4):: + + # echo 4 >> no_of_msi + +select MSI as interrupt type:: + + # echo MSI >> int_type + +go for link up now:: + + # echo UP >> link + +wait till link is up:: + + # cat link + +An application can repetitively read this node till link is found UP. It can +sleep between two read. + +wait till msi is enabled:: + + # cat no_of_msi + +Should return 4 (number of requested MSI vector) + +to send msi vector 2:: + + # echo 2 >> send_msi + # cd - diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt deleted file mode 100644 index 89b88dee4143..000000000000 --- a/Documentation/misc-devices/spear-pcie-gadget.txt +++ /dev/null @@ -1,130 +0,0 @@ -Spear PCIe Gadget Driver: - -Author -============= -Pratyush Anand (pratyush.anand@gmail.com) - -Location -============ -driver/misc/spear13xx_pcie_gadget.c - -Supported Chip: -=================== -SPEAr1300 -SPEAr1310 - -Menuconfig option: -========================== -Device Drivers - Misc devices - PCIe gadget support for SPEAr13XX platform -purpose -=========== -This driver has several nodes which can be read/written by configfs interface. -Its main purpose is to configure selected dual mode PCIe controller as device -and then program its various registers to configure it as a particular device -type. This driver can be used to show spear's PCIe device capability. - -Description of different nodes: -================================= - -read behavior of nodes: ------------------------------- -link :gives ltssm status. -int_type :type of supported interrupt -no_of_msi :zero if MSI is not enabled by host. A positive value is the - number of MSI vector granted. -vendor_id :returns programmed vendor id (hex) -device_id :returns programmed device id(hex) -bar0_size: :returns size of bar0 in hex. -bar0_address :returns address of bar0 mapped area in hex. -bar0_rw_offset :returns offset of bar0 for which bar0_data will return value. -bar0_data :returns data at bar0_rw_offset. - -write behavior of nodes: ------------------------------- -link :write UP to enable ltsmm DOWN to disable -int_type :write interrupt type to be configured and (int_type could be - INTA, MSI or NO_INT). Select MSI only when you have programmed - no_of_msi node. -no_of_msi :number of MSI vector needed. -inta :write 1 to assert INTA and 0 to de-assert. -send_msi :write MSI vector to be sent. -vendor_id :write vendor id(hex) to be programmed. -device_id :write device id(hex) to be programmed. -bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex) - bytes. -bar0_address :write address of bar0 mapped area in hex. (default mapping of - bar0 is SYSRAM1(E0800000). Always program bar size before bar - address. Kernel might modify bar size and address for alignment, so - read back bar size and address after writing to cross check. -bar0_rw_offset :write offset of bar0 for which bar0_data will write value. -bar0_data :write data to be written at bar0_rw_offset. - -Node programming example -=========================== -Program all PCIe registers in such a way that when this device is connected -to the PCIe host, then host sees this device as 1MB RAM. -#mount -t configfs none /Config -For nth PCIe Device Controller -# cd /config/pcie_gadget.n/ -Now you have all the nodes in this directory. -program vendor id as 0x104a -# echo 104A >> vendor_id - -program device id as 0xCD80 -# echo CD80 >> device_id - -program BAR0 size as 1MB -# echo 100000 >> bar0_size - -check for programmed bar0 size -# cat bar0_size - -Program BAR0 Address as DDR (0x2100000). This is the physical address of -memory, which is to be made visible to PCIe host. Similarly any other peripheral -can also be made visible to PCIe host. E.g., if you program base address of UART -as BAR0 address then when this device will be connected to a host, it will be -visible as UART. -# echo 2100000 >> bar0_address - -program interrupt type : INTA -# echo INTA >> int_type - -go for link up now. -# echo UP >> link - -It will have to be insured that, once link up is done on gadget, then only host -is initialized and start to search PCIe devices on its port. - -/*wait till link is up*/ -# cat link -wait till it returns UP. - -To assert INTA -# echo 1 >> inta - -To de-assert INTA -# echo 0 >> inta - -if MSI is to be used as interrupt, program no of msi vector needed (say4) -# echo 4 >> no_of_msi - -select MSI as interrupt type -# echo MSI >> int_type - -go for link up now -# echo UP >> link - -wait till link is up -# cat link -An application can repetitively read this node till link is found UP. It can -sleep between two read. - -wait till msi is enabled -# cat no_of_msi -Should return 4 (number of requested MSI vector) - -to send msi vector 2 -# echo 2 >> send_msi -#cd - diff --git a/Documentation/misc-devices/xilinx_sdfec.rst b/Documentation/misc-devices/xilinx_sdfec.rst index 7a47075c171c..8c8a289d69a3 100644 --- a/Documentation/misc-devices/xilinx_sdfec.rst +++ b/Documentation/misc-devices/xilinx_sdfec.rst @@ -78,7 +78,7 @@ application interfaces: - open: Implements restriction that only a single file descriptor can be open per SD-FEC instance at any time - release: Allows another file descriptor to be open, that is after current file descriptor is closed - poll: Provides a method to monitor for SD-FEC Error events - - unlocked_ioctl: Provides the the following ioctl commands that allows the application configure the SD-FEC core: + - unlocked_ioctl: Provides the following ioctl commands that allows the application configure the SD-FEC core: - :c:macro:`XSDFEC_START_DEV` - :c:macro:`XSDFEC_STOP_DEV` diff --git a/Documentation/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 18020943ba25..74821d29a22f 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -73,7 +73,7 @@ lower value. This will make the mesh more responsive to topology changes, but will also increase the overhead. Information about the current state can be accessed via the batadv generic -netlink family. batctl provides human readable version via its debug tables +netlink family. batctl provides a human readable version via its debug tables subcommands. @@ -115,8 +115,8 @@ are prefixed with "batman-adv:" So to see just these messages try:: $ dmesg | grep batman-adv When investigating problems with your mesh network, it is sometimes necessary to -see more detail debug messages. This must be enabled when compiling the -batman-adv module. When building batman-adv as part of kernel, use "make +see more detailed debug messages. This must be enabled when compiling the +batman-adv module. When building batman-adv as part of the kernel, use "make menuconfig" and enable the option ``B.A.T.M.A.N. debugging`` (``CONFIG_BATMAN_ADV_DEBUG=y``). @@ -160,7 +160,7 @@ IRC: #batman on irc.freenode.org Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription at - https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) + https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/) You can also contact the Authors: diff --git a/Documentation/networking/dccp.rst b/Documentation/networking/dccp.rst index dde16be04456..91e5c33ba3ff 100644 --- a/Documentation/networking/dccp.rst +++ b/Documentation/networking/dccp.rst @@ -192,6 +192,9 @@ FIONREAD Works as in udp(7): returns in the ``int`` argument pointer the size of the next pending datagram in bytes, or 0 when no datagram is pending. +SIOCOUTQ + Returns the number of unsent data bytes in the socket send queue as ``int`` + into the buffer specified by the argument pointer. Other tunables ============== diff --git a/Documentation/networking/cops.rst b/Documentation/networking/device_drivers/appletalk/cops.rst similarity index 100% rename from Documentation/networking/cops.rst rename to Documentation/networking/device_drivers/appletalk/cops.rst diff --git a/Documentation/networking/device_drivers/appletalk/index.rst b/Documentation/networking/device_drivers/appletalk/index.rst new file mode 100644 index 000000000000..de7507f02037 --- /dev/null +++ b/Documentation/networking/device_drivers/appletalk/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +AppleTalk Device Drivers +======================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + cops + ltpc + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/ltpc.rst b/Documentation/networking/device_drivers/appletalk/ltpc.rst similarity index 100% rename from Documentation/networking/ltpc.rst rename to Documentation/networking/device_drivers/appletalk/ltpc.rst diff --git a/Documentation/networking/cxacru-cf.py b/Documentation/networking/device_drivers/atm/cxacru-cf.py similarity index 100% rename from Documentation/networking/cxacru-cf.py rename to Documentation/networking/device_drivers/atm/cxacru-cf.py diff --git a/Documentation/networking/cxacru.rst b/Documentation/networking/device_drivers/atm/cxacru.rst similarity index 100% rename from Documentation/networking/cxacru.rst rename to Documentation/networking/device_drivers/atm/cxacru.rst diff --git a/Documentation/networking/fore200e.rst b/Documentation/networking/device_drivers/atm/fore200e.rst similarity index 100% rename from Documentation/networking/fore200e.rst rename to Documentation/networking/device_drivers/atm/fore200e.rst diff --git a/Documentation/networking/device_drivers/atm/index.rst b/Documentation/networking/device_drivers/atm/index.rst new file mode 100644 index 000000000000..7b593f031a60 --- /dev/null +++ b/Documentation/networking/device_drivers/atm/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Asynchronous Transfer Mode (ATM) Device Drivers +=============================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + cxacru + fore200e + iphase + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/iphase.rst b/Documentation/networking/device_drivers/atm/iphase.rst similarity index 100% rename from Documentation/networking/iphase.rst rename to Documentation/networking/device_drivers/atm/iphase.rst diff --git a/Documentation/networking/device_drivers/cable/index.rst b/Documentation/networking/device_drivers/cable/index.rst new file mode 100644 index 000000000000..cce3c4392972 --- /dev/null +++ b/Documentation/networking/device_drivers/cable/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Cable Modem Device Drivers +========================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + sb1000 + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/sb1000.rst b/Documentation/networking/device_drivers/cable/sb1000.rst similarity index 100% rename from Documentation/networking/device_drivers/sb1000.rst rename to Documentation/networking/device_drivers/cable/sb1000.rst diff --git a/Documentation/networking/device_drivers/cellular/index.rst b/Documentation/networking/device_drivers/cellular/index.rst new file mode 100644 index 000000000000..fc1812d3fc70 --- /dev/null +++ b/Documentation/networking/device_drivers/cellular/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Cellular Modem Device Drivers +============================= + +Contents: + +.. toctree:: + :maxdepth: 2 + + qualcomm/rmnet + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst similarity index 100% rename from Documentation/networking/device_drivers/qualcomm/rmnet.rst rename to Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst diff --git a/Documentation/networking/device_drivers/3com/3c509.rst b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst similarity index 100% rename from Documentation/networking/device_drivers/3com/3c509.rst rename to Documentation/networking/device_drivers/ethernet/3com/3c509.rst diff --git a/Documentation/networking/device_drivers/3com/vortex.rst b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst similarity index 99% rename from Documentation/networking/device_drivers/3com/vortex.rst rename to Documentation/networking/device_drivers/ethernet/3com/vortex.rst index 800add5be338..eab10fc6da5c 100644 --- a/Documentation/networking/device_drivers/3com/vortex.rst +++ b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst @@ -4,8 +4,6 @@ 3Com Vortex device driver ========================= -Documentation/networking/device_drivers/3com/vortex.rst - Andrew Morton 30 April 2000 diff --git a/Documentation/networking/altera_tse.rst b/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst similarity index 100% rename from Documentation/networking/altera_tse.rst rename to Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst diff --git a/Documentation/networking/device_drivers/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst similarity index 100% rename from Documentation/networking/device_drivers/amazon/ena.rst rename to Documentation/networking/device_drivers/ethernet/amazon/ena.rst diff --git a/Documentation/networking/device_drivers/aquantia/atlantic.rst b/Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst similarity index 100% rename from Documentation/networking/device_drivers/aquantia/atlantic.rst rename to Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst diff --git a/Documentation/networking/device_drivers/chelsio/cxgb.rst b/Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst similarity index 100% rename from Documentation/networking/device_drivers/chelsio/cxgb.rst rename to Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst diff --git a/Documentation/networking/device_drivers/cirrus/cs89x0.rst b/Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst similarity index 100% rename from Documentation/networking/device_drivers/cirrus/cs89x0.rst rename to Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst diff --git a/Documentation/networking/device_drivers/davicom/dm9000.rst b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst similarity index 100% rename from Documentation/networking/device_drivers/davicom/dm9000.rst rename to Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst diff --git a/Documentation/networking/device_drivers/dec/de4x5.rst b/Documentation/networking/device_drivers/ethernet/dec/de4x5.rst similarity index 100% rename from Documentation/networking/device_drivers/dec/de4x5.rst rename to Documentation/networking/device_drivers/ethernet/dec/de4x5.rst diff --git a/Documentation/networking/device_drivers/dec/dmfe.rst b/Documentation/networking/device_drivers/ethernet/dec/dmfe.rst similarity index 100% rename from Documentation/networking/device_drivers/dec/dmfe.rst rename to Documentation/networking/device_drivers/ethernet/dec/dmfe.rst diff --git a/Documentation/networking/device_drivers/dlink/dl2k.rst b/Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst similarity index 100% rename from Documentation/networking/device_drivers/dlink/dl2k.rst rename to Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst similarity index 100% rename from Documentation/networking/device_drivers/freescale/dpaa.rst rename to Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst similarity index 97% rename from Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst rename to Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst index 17dbee1ac53e..c50fd46631e0 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst @@ -19,8 +19,10 @@ pool management for network interfaces. This document provides an overview the Linux DPIO driver, its subcomponents, and its APIs. -See Documentation/networking/device_drivers/freescale/dpaa2/overview.rst for -a general overview of DPAA2 and the general DPAA2 driver architecture in Linux. +See +Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst +for a general overview of DPAA2 and the general DPAA2 driver architecture +in Linux. Driver Overview --------------- diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst similarity index 98% rename from Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst rename to Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst index cb4c9a0c5a17..682f3986c15b 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst @@ -33,7 +33,8 @@ hardware resources, like queues, do not have a corresponding MC object and are treated as internal resources of other objects. For a more detailed description of the DPAA2 architecture and its object -abstractions see *Documentation/networking/device_drivers/freescale/dpaa2/overview.rst*. +abstractions see +*Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst*. Each Linux net device is built on top of a Datapath Network Interface (DPNI) object and uses Buffer Pools (DPBPs), I/O Portals (DPIOs) and Concentrators diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/index.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst similarity index 100% rename from Documentation/networking/device_drivers/freescale/dpaa2/index.rst rename to Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/mac-phy-support.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst similarity index 100% rename from Documentation/networking/device_drivers/freescale/dpaa2/mac-phy-support.rst rename to Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst similarity index 100% rename from Documentation/networking/device_drivers/freescale/dpaa2/overview.rst rename to Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst diff --git a/Documentation/networking/device_drivers/freescale/gianfar.rst b/Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst similarity index 100% rename from Documentation/networking/device_drivers/freescale/gianfar.rst rename to Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst diff --git a/Documentation/networking/device_drivers/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst similarity index 100% rename from Documentation/networking/device_drivers/google/gve.rst rename to Documentation/networking/device_drivers/ethernet/google/gve.rst diff --git a/Documentation/networking/hinic.rst b/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst similarity index 100% rename from Documentation/networking/hinic.rst rename to Documentation/networking/device_drivers/ethernet/huawei/hinic.rst diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst new file mode 100644 index 000000000000..cbb75a1818c0 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Ethernet Device Drivers +======================= + +Device drivers for Ethernet and Ethernet-based virtual function devices. + +Contents: + +.. toctree:: + :maxdepth: 2 + + 3com/3c509 + 3com/vortex + amazon/ena + altera/altera_tse + aquantia/atlantic + chelsio/cxgb + cirrus/cs89x0 + dlink/dl2k + davicom/dm9000 + dec/de4x5 + dec/dmfe + freescale/dpaa + freescale/dpaa2/index + freescale/gianfar + google/gve + huawei/hinic + intel/e100 + intel/e1000 + intel/e1000e + intel/fm10k + intel/igb + intel/igbvf + intel/ixgb + intel/ixgbe + intel/ixgbevf + intel/i40e + intel/iavf + intel/ice + marvell/octeontx2 + mellanox/mlx5 + microsoft/netvsc + neterion/s2io + neterion/vxge + netronome/nfp + pensando/ionic + smsc/smc9 + stmicro/stmmac + ti/cpsw + ti/cpsw_switchdev + ti/tlan + toshiba/spider_net + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/intel/e100.rst b/Documentation/networking/device_drivers/ethernet/intel/e100.rst similarity index 99% rename from Documentation/networking/device_drivers/intel/e100.rst rename to Documentation/networking/device_drivers/ethernet/intel/e100.rst index 3ac21e7119a7..3d4a9ba21946 100644 --- a/Documentation/networking/device_drivers/intel/e100.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e100.rst @@ -41,7 +41,7 @@ Identifying Your Adapter For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Driver Configuration Parameters =============================== @@ -179,7 +179,7 @@ filtering by Support ======= For general information, go to the Intel support website at: -http://www.intel.com/support/ +https://www.intel.com/support/ or the Intel Wired Networking project hosted by Sourceforge at: http://sourceforge.net/projects/e1000 diff --git a/Documentation/networking/device_drivers/intel/e1000.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/e1000.rst rename to Documentation/networking/device_drivers/ethernet/intel/e1000.rst diff --git a/Documentation/networking/device_drivers/intel/e1000e.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/e1000e.rst rename to Documentation/networking/device_drivers/ethernet/intel/e1000e.rst diff --git a/Documentation/networking/device_drivers/intel/fm10k.rst b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst similarity index 99% rename from Documentation/networking/device_drivers/intel/fm10k.rst rename to Documentation/networking/device_drivers/ethernet/intel/fm10k.rst index 4d279e64e221..9258ef6f515c 100644 --- a/Documentation/networking/device_drivers/intel/fm10k.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst @@ -22,7 +22,7 @@ Ethernet Multi-host Controller. For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Flow Control diff --git a/Documentation/networking/device_drivers/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/i40e.rst rename to Documentation/networking/device_drivers/ethernet/intel/i40e.rst diff --git a/Documentation/networking/device_drivers/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst similarity index 99% rename from Documentation/networking/device_drivers/intel/iavf.rst rename to Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 84ac7e75f363..52e037b11c97 100644 --- a/Documentation/networking/device_drivers/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -43,7 +43,7 @@ device. For information on how to identify your adapter, and for the latest NVM/FW images and Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Additional Features and Configurations diff --git a/Documentation/networking/device_drivers/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/ice.rst rename to Documentation/networking/device_drivers/ethernet/intel/ice.rst diff --git a/Documentation/networking/device_drivers/intel/igb.rst b/Documentation/networking/device_drivers/ethernet/intel/igb.rst similarity index 99% rename from Documentation/networking/device_drivers/intel/igb.rst rename to Documentation/networking/device_drivers/ethernet/intel/igb.rst index 87e560fe5eaa..d46289e182cf 100644 --- a/Documentation/networking/device_drivers/intel/igb.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igb.rst @@ -20,7 +20,7 @@ Identifying Your Adapter ======================== For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Command Line Parameters diff --git a/Documentation/networking/device_drivers/intel/igbvf.rst b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst similarity index 98% rename from Documentation/networking/device_drivers/intel/igbvf.rst rename to Documentation/networking/device_drivers/ethernet/intel/igbvf.rst index 557fc020ef31..40fa210c5e14 100644 --- a/Documentation/networking/device_drivers/intel/igbvf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst @@ -35,7 +35,7 @@ Identifying Your Adapter ======================== For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Additional Features and Configurations diff --git a/Documentation/networking/device_drivers/intel/ixgb.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst similarity index 99% rename from Documentation/networking/device_drivers/intel/ixgb.rst rename to Documentation/networking/device_drivers/ethernet/intel/ixgb.rst index ab624f1a44a8..c6a233e68ad6 100644 --- a/Documentation/networking/device_drivers/intel/ixgb.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst @@ -203,7 +203,7 @@ With the 10 Gigabit server adapters, the default Linux configuration will very likely limit the total available throughput artificially. There is a set of configuration changes that, when applied together, will increase the ability of Linux to transmit and receive data. The following enhancements were -originally acquired from settings published at http://www.spec.org/web99/ for +originally acquired from settings published at https://www.spec.org/web99/ for various submitted results using Linux. NOTE: diff --git a/Documentation/networking/device_drivers/intel/ixgbe.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/ixgbe.rst rename to Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst diff --git a/Documentation/networking/device_drivers/intel/ixgbevf.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/ixgbevf.rst rename to Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst diff --git a/Documentation/networking/device_drivers/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst similarity index 100% rename from Documentation/networking/device_drivers/marvell/octeontx2.rst rename to Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst diff --git a/Documentation/networking/device_drivers/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst similarity index 100% rename from Documentation/networking/device_drivers/mellanox/mlx5.rst rename to Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst diff --git a/Documentation/networking/device_drivers/microsoft/netvsc.rst b/Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst similarity index 100% rename from Documentation/networking/device_drivers/microsoft/netvsc.rst rename to Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst diff --git a/Documentation/networking/device_drivers/neterion/s2io.rst b/Documentation/networking/device_drivers/ethernet/neterion/s2io.rst similarity index 100% rename from Documentation/networking/device_drivers/neterion/s2io.rst rename to Documentation/networking/device_drivers/ethernet/neterion/s2io.rst diff --git a/Documentation/networking/device_drivers/neterion/vxge.rst b/Documentation/networking/device_drivers/ethernet/neterion/vxge.rst similarity index 100% rename from Documentation/networking/device_drivers/neterion/vxge.rst rename to Documentation/networking/device_drivers/ethernet/neterion/vxge.rst diff --git a/Documentation/networking/device_drivers/netronome/nfp.rst b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst similarity index 100% rename from Documentation/networking/device_drivers/netronome/nfp.rst rename to Documentation/networking/device_drivers/ethernet/netronome/nfp.rst diff --git a/Documentation/networking/device_drivers/pensando/ionic.rst b/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst similarity index 100% rename from Documentation/networking/device_drivers/pensando/ionic.rst rename to Documentation/networking/device_drivers/ethernet/pensando/ionic.rst diff --git a/Documentation/networking/device_drivers/smsc/smc9.rst b/Documentation/networking/device_drivers/ethernet/smsc/smc9.rst similarity index 100% rename from Documentation/networking/device_drivers/smsc/smc9.rst rename to Documentation/networking/device_drivers/ethernet/smsc/smc9.rst diff --git a/Documentation/networking/device_drivers/stmicro/stmmac.rst b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst similarity index 100% rename from Documentation/networking/device_drivers/stmicro/stmmac.rst rename to Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst diff --git a/Documentation/networking/device_drivers/ti/cpsw.rst b/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst similarity index 100% rename from Documentation/networking/device_drivers/ti/cpsw.rst rename to Documentation/networking/device_drivers/ethernet/ti/cpsw.rst diff --git a/Documentation/networking/device_drivers/ti/cpsw_switchdev.rst b/Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst similarity index 100% rename from Documentation/networking/device_drivers/ti/cpsw_switchdev.rst rename to Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst diff --git a/Documentation/networking/device_drivers/ti/tlan.rst b/Documentation/networking/device_drivers/ethernet/ti/tlan.rst similarity index 100% rename from Documentation/networking/device_drivers/ti/tlan.rst rename to Documentation/networking/device_drivers/ethernet/ti/tlan.rst diff --git a/Documentation/networking/device_drivers/toshiba/spider_net.rst b/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst similarity index 100% rename from Documentation/networking/device_drivers/toshiba/spider_net.rst rename to Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst diff --git a/Documentation/networking/defza.rst b/Documentation/networking/device_drivers/fddi/defza.rst similarity index 100% rename from Documentation/networking/defza.rst rename to Documentation/networking/device_drivers/fddi/defza.rst diff --git a/Documentation/networking/device_drivers/fddi/index.rst b/Documentation/networking/device_drivers/fddi/index.rst new file mode 100644 index 000000000000..0b75294e6c8b --- /dev/null +++ b/Documentation/networking/device_drivers/fddi/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Fiber Distributed Data Interface (FDDI) Device Drivers +====================================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + defza + skfp + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/skfp.rst b/Documentation/networking/device_drivers/fddi/skfp.rst similarity index 100% rename from Documentation/networking/skfp.rst rename to Documentation/networking/device_drivers/fddi/skfp.rst diff --git a/Documentation/networking/baycom.rst b/Documentation/networking/device_drivers/hamradio/baycom.rst similarity index 100% rename from Documentation/networking/baycom.rst rename to Documentation/networking/device_drivers/hamradio/baycom.rst diff --git a/Documentation/networking/device_drivers/hamradio/index.rst b/Documentation/networking/device_drivers/hamradio/index.rst new file mode 100644 index 000000000000..7e731732057b --- /dev/null +++ b/Documentation/networking/device_drivers/hamradio/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Amateur Radio Device Drivers +============================ + +Contents: + +.. toctree:: + :maxdepth: 2 + + baycom + z8530drv + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/z8530drv.rst b/Documentation/networking/device_drivers/hamradio/z8530drv.rst similarity index 100% rename from Documentation/networking/z8530drv.rst rename to Documentation/networking/device_drivers/hamradio/z8530drv.rst diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index e18dad11bc72..a3113ffd7a16 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -1,56 +1,22 @@ .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -Vendor Device Drivers -===================== +Hardware Device Drivers +======================= Contents: .. toctree:: :maxdepth: 2 - freescale/dpaa2/index - intel/e100 - intel/e1000 - intel/e1000e - intel/fm10k - intel/igb - intel/igbvf - intel/ixgb - intel/ixgbe - intel/ixgbevf - intel/i40e - intel/iavf - intel/ice - google/gve - marvell/octeontx2 - mellanox/mlx5 - netronome/nfp - pensando/ionic - stmicro/stmmac - 3com/3c509 - 3com/vortex - amazon/ena - aquantia/atlantic - chelsio/cxgb - cirrus/cs89x0 - davicom/dm9000 - dec/de4x5 - dec/dmfe - dlink/dl2k - freescale/dpaa - freescale/gianfar - intel/ipw2100 - intel/ipw2200 - microsoft/netvsc - neterion/s2io - neterion/vxge - qualcomm/rmnet - sb1000 - smsc/smc9 - ti/cpsw_switchdev - ti/cpsw - ti/tlan - toshiba/spider_net + appletalk/index + atm/index + cable/index + cellular/index + ethernet/index + fddi/index + hamradio/index + wan/index + wifi/index .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/wan/index.rst b/Documentation/networking/device_drivers/wan/index.rst new file mode 100644 index 000000000000..9d9ae94f00b4 --- /dev/null +++ b/Documentation/networking/device_drivers/wan/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Classic WAN Device Drivers +========================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + z8530book + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/z8530book.rst b/Documentation/networking/device_drivers/wan/z8530book.rst similarity index 100% rename from Documentation/networking/z8530book.rst rename to Documentation/networking/device_drivers/wan/z8530book.rst diff --git a/Documentation/networking/device_drivers/wifi/index.rst b/Documentation/networking/device_drivers/wifi/index.rst new file mode 100644 index 000000000000..bf91a87c7acf --- /dev/null +++ b/Documentation/networking/device_drivers/wifi/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Wi-Fi Device Drivers +==================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + intel/ipw2100 + intel/ipw2200 + ray_cs + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/intel/ipw2100.rst b/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst similarity index 99% rename from Documentation/networking/device_drivers/intel/ipw2100.rst rename to Documentation/networking/device_drivers/wifi/intel/ipw2100.rst index d54ad522f937..883e96355799 100644 --- a/Documentation/networking/device_drivers/intel/ipw2100.rst +++ b/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst @@ -78,7 +78,7 @@ such, if you are interested in deploying or shipping a driver as part of solution intended to be used for purposes other than development, please obtain a tested driver from Intel Customer Support at: -http://www.intel.com/support/wireless/sb/CS-006408.htm +https://www.intel.com/support/wireless/sb/CS-006408.htm 1. Introduction =============== diff --git a/Documentation/networking/device_drivers/intel/ipw2200.rst b/Documentation/networking/device_drivers/wifi/intel/ipw2200.rst similarity index 100% rename from Documentation/networking/device_drivers/intel/ipw2200.rst rename to Documentation/networking/device_drivers/wifi/intel/ipw2200.rst diff --git a/Documentation/networking/ray_cs.rst b/Documentation/networking/device_drivers/wifi/ray_cs.rst similarity index 100% rename from Documentation/networking/ray_cs.rst rename to Documentation/networking/device_drivers/wifi/ray_cs.rst diff --git a/Documentation/networking/devlink/devlink-info.rst b/Documentation/networking/devlink/devlink-info.rst index 3fe11401b838..7572bf6de5c1 100644 --- a/Documentation/networking/devlink/devlink-info.rst +++ b/Documentation/networking/devlink/devlink-info.rst @@ -44,9 +44,11 @@ versions is generally discouraged - here, and via any other Linux API. reported for two ports of the same device or on two hosts of a multi-host device should be identical. - .. note:: ``devlink-info`` API should be extended with a new field - if devices want to report board/product serial number (often - reported in PCI *Vital Product Data* capability). + * - ``board.serial_number`` + - Board serial number of the device. + + This is usually the serial number of the board, often available in + PCI *Vital Product Data*. * - ``fixed`` - Group for hardware identifiers, and versions of components @@ -201,10 +203,6 @@ Future work The following extensions could be useful: - - product serial number - NIC boards often get labeled with a board serial - number rather than ASIC serial number; it'd be useful to add board serial - numbers to the API if they can be retrieved from the device; - - on-disk firmware file names - drivers list the file names of firmware they may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These, however, are per module, rather than per device. It'd be useful to list diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index 2014307fbe63..7a798352b45d 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -405,6 +405,10 @@ be added to the following table: - ``control`` - Traps packets logged during processing of flow action trap (e.g., via tc's trap action) + * - ``early_drop`` + - ``drop`` + - Traps packets dropped due to the RED (Random Early Detection) algorithm + (i.e., early drops) Driver-specific Packet Traps ============================ diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 72ea8d295724..237848d56f9b 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -84,8 +84,20 @@ The ``ice`` driver reports the following versions Regions ======= -The ``ice`` driver enables access to the contents of the Non Volatile Memory -flash chip via the ``nvm-flash`` region. +The ``ice`` driver implements the following regions for accessing internal +device data. + +.. list-table:: regions implemented + :widths: 15 85 + + * - Name + - Description + * - ``nvm-flash`` + - The contents of the entire flash chip, sometimes referred to as + the device's Non Volatile Memory. + * - ``device-caps`` + - The contents of the device firmware's capabilities buffer. Useful to + determine the current state and configuration of the device. Users can request an immediate capture of a snapshot via the ``DEVLINK_CMD_REGION_NEW`` @@ -105,3 +117,42 @@ Users can request an immediate capture of a snapshot via the 0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30 $ devlink region delete pci/0000:01:00.0/nvm-flash snapshot 1 + + $ devlink region new pci/0000:01:00.0/device-caps snapshot 1 + $ devlink region dump pci/0000:01:00.0/device-caps snapshot 1 + 0000000000000000 01 00 01 00 00 00 00 00 01 00 00 00 00 00 00 00 + 0000000000000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000020 02 00 02 01 32 03 00 00 0a 00 00 00 25 00 00 00 + 0000000000000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000040 04 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000060 05 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000080 06 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000a0 08 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000c0 12 00 01 00 01 00 00 00 01 00 01 00 00 00 00 00 + 00000000000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000e0 13 00 01 00 00 01 00 00 00 00 00 00 00 00 00 00 + 00000000000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000100 14 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000120 15 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000140 16 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000160 17 00 01 00 06 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000180 18 00 01 00 01 00 00 00 01 00 00 00 08 00 00 00 + 0000000000000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001a0 22 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001c0 40 00 01 00 00 08 00 00 08 00 00 00 00 00 00 00 + 00000000000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001e0 41 00 01 00 00 08 00 00 00 00 00 00 00 00 00 00 + 00000000000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000200 42 00 01 00 00 08 00 00 00 00 00 00 00 00 00 00 + 0000000000000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + $ devlink region delete pci/0000:01:00.0/device-caps snapshot 1 diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 82470c36c27a..d53bcb31645a 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -443,10 +443,11 @@ supports. LINKSTATE_GET ============= -Requests link state information. At the moment, only link up/down flag (as -provided by ``ETHTOOL_GLINK`` ioctl command) is provided but some future -extensions are planned (e.g. link down reason). This request does not have any -attributes. +Requests link state information. Link up/down flag (as provided by +``ETHTOOL_GLINK`` ioctl command) is provided. Optionally, extended state might +be provided as well. In general, extended state describes reasons for why a port +is down, or why it operates in some non-obvious mode. This request does not have +any attributes. Request contents: @@ -461,16 +462,135 @@ Kernel response contents: ``ETHTOOL_A_LINKSTATE_LINK`` bool link state (up/down) ``ETHTOOL_A_LINKSTATE_SQI`` u32 Current Signal Quality Index ``ETHTOOL_A_LINKSTATE_SQI_MAX`` u32 Max support SQI value + ``ETHTOOL_A_LINKSTATE_EXT_STATE`` u8 link extended state + ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE`` u8 link extended substate ==================================== ====== ============================ For most NIC drivers, the value of ``ETHTOOL_A_LINKSTATE_LINK`` returns carrier flag provided by ``netif_carrier_ok()`` but there are drivers which define their own handler. +``ETHTOOL_A_LINKSTATE_EXT_STATE`` and ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE`` are +optional values. ethtool core can provide either both +``ETHTOOL_A_LINKSTATE_EXT_STATE`` and ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE``, +or only ``ETHTOOL_A_LINKSTATE_EXT_STATE``, or none of them. + ``LINKSTATE_GET`` allows dump requests (kernel returns reply messages for all devices supporting the request). +Link extended states: + + ================================================ ============================================ + ``ETHTOOL_LINK_EXT_STATE_AUTONEG`` States relating to the autonegotiation or + issues therein + + ``ETHTOOL_LINK_EXT_STATE_LINK_TRAINING_FAILURE`` Failure during link training + + ``ETHTOOL_LINK_EXT_STATE_LINK_LOGICAL_MISMATCH`` Logical mismatch in physical coding sublayer + or forward error correction sublayer + + ``ETHTOOL_LINK_EXT_STATE_BAD_SIGNAL_INTEGRITY`` Signal integrity issues + + ``ETHTOOL_LINK_EXT_STATE_NO_CABLE`` No cable connected + + ``ETHTOOL_LINK_EXT_STATE_CABLE_ISSUE`` Failure is related to cable, + e.g., unsupported cable + + ``ETHTOOL_LINK_EXT_STATE_EEPROM_ISSUE`` Failure is related to EEPROM, e.g., failure + during reading or parsing the data + + ``ETHTOOL_LINK_EXT_STATE_CALIBRATION_FAILURE`` Failure during calibration algorithm + + ``ETHTOOL_LINK_EXT_STATE_POWER_BUDGET_EXCEEDED`` The hardware is not able to provide the + power required from cable or module + + ``ETHTOOL_LINK_EXT_STATE_OVERHEAT`` The module is overheated + ================================================ ============================================ + +Link extended substates: + + Autoneg substates: + + =============================================================== ================================ + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED`` Peer side is down + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_ACK_NOT_RECEIVED`` Ack not received from peer side + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NEXT_PAGE_EXCHANGE_FAILED`` Next page exchange failed + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED_FORCE_MODE`` Peer side is down during force + mode or there is no agreement of + speed + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_FEC_MISMATCH_DURING_OVERRIDE`` Forward error correction modes + in both sides are mismatched + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_HCD`` No Highest Common Denominator + =============================================================== ================================ + + Link training substates: + + =========================================================================== ==================== + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_FRAME_LOCK_NOT_ACQUIRED`` Frames were not + recognized, the + lock failed + + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_INHIBIT_TIMEOUT`` The lock did not + occur before + timeout + + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_PARTNER_DID_NOT_SET_RECEIVER_READY`` Peer side did not + send ready signal + after training + process + + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_REMOTE_FAULT`` Remote side is not + ready yet + =========================================================================== ==================== + + Link logical mismatch substates: + + ================================================================ =============================== + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_BLOCK_LOCK`` Physical coding sublayer was + not locked in first phase - + block lock + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_AM_LOCK`` Physical coding sublayer was + not locked in second phase - + alignment markers lock + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_GET_ALIGN_STATUS`` Physical coding sublayer did + not get align status + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_FC_FEC_IS_NOT_LOCKED`` FC forward error correction is + not locked + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_RS_FEC_IS_NOT_LOCKED`` RS forward error correction is + not locked + ================================================================ =============================== + + Bad signal integrity substates: + + ================================================================= ============================= + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_LARGE_NUMBER_OF_PHYSICAL_ERRORS`` Large number of physical + errors + + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_UNSUPPORTED_RATE`` The system attempted to + operate the cable at a rate + that is not formally + supported, which led to + signal integrity issues + ================================================================= ============================= + + Cable issue substates: + + =================================================== ============================================ + ``ETHTOOL_LINK_EXT_SUBSTATE_CI_UNSUPPORTED_CABLE`` Unsupported cable + + ``ETHTOOL_LINK_EXT_SUBSTATE_CI_CABLE_TEST_FAILURE`` Cable test failure + =================================================== ============================================ + DEBUG_GET ========= @@ -1110,6 +1230,42 @@ used to report the amplitude of the reflection for a given pair. | | | ``ETHTOOL_A_CABLE_AMPLITUDE_mV`` | s16 | Reflection amplitude | +-+-+-----------------------------------------+--------+----------------------+ +TUNNEL_INFO +=========== + +Gets information about the tunnel state NIC is aware of. + +Request contents: + + ===================================== ====== ========================== + ``ETHTOOL_A_TUNNEL_INFO_HEADER`` nested request header + ===================================== ====== ========================== + +Kernel response contents: + + +---------------------------------------------+--------+---------------------+ + | ``ETHTOOL_A_TUNNEL_INFO_HEADER`` | nested | reply header | + +---------------------------------------------+--------+---------------------+ + | ``ETHTOOL_A_TUNNEL_INFO_UDP_PORTS`` | nested | all UDP port tables | + +-+-------------------------------------------+--------+---------------------+ + | | ``ETHTOOL_A_TUNNEL_UDP_TABLE`` | nested | one UDP port table | + +-+-+-----------------------------------------+--------+---------------------+ + | | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_SIZE`` | u32 | max size of the | + | | | | | table | + +-+-+-----------------------------------------+--------+---------------------+ + | | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` | bitset | tunnel types which | + | | | | | table can hold | + +-+-+-----------------------------------------+--------+---------------------+ + | | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_ENTRY`` | nested | offloaded UDP port | + +-+-+-+---------------------------------------+--------+---------------------+ + | | | | ``ETHTOOL_A_TUNNEL_UDP_ENTRY_PORT`` | be16 | UDP port | + +-+-+-+---------------------------------------+--------+---------------------+ + | | | | ``ETHTOOL_A_TUNNEL_UDP_ENTRY_TYPE`` | u32 | tunnel type | + +-+-+-+---------------------------------------+--------+---------------------+ + +For UDP tunnel table empty ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` indicates that +the table contains static entries, hard-coded by the NIC. + Request translation =================== diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index a1d3e192b9fa..debb59e374de 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _networking-filter: + ======================================================= Linux Socket Filtering aka Berkeley Packet Filter (BPF) ======================================================= diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 0186e276690a..c29496fff81c 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -20,7 +20,6 @@ Contents: ieee802154 j1939 kapi - z8530book msg_zerocopy failover net_dim @@ -39,36 +38,28 @@ Contents: nfc 6lowpan 6pack - altera_tse arcnet-hardware arcnet atm ax25 - baycom bonding cdc_mbim - cops - cxacru dccp dctcp decnet - defza dns_resolver driver eql fib_trie filter - fore200e framerelay generic-hdlc generic_netlink gen_stats gtp - hinic ila ipddp ip_dynaddr - iphase ipsec ip-sysctl ipv6 @@ -77,7 +68,6 @@ Contents: kcm l2tp lapb-module - ltpc mac80211-injection mpls-sysctl multiqueue @@ -97,14 +87,12 @@ Contents: ppp_generic proc_net_tcp radiotap-headers - ray_cs rds regulatory rxrpc sctp secid seg6-sysctl - skfp strparser switchdev tc-actions-env-rules @@ -122,7 +110,6 @@ Contents: xfrm_proc xfrm_sync xfrm_sysctl - z8530drv .. only:: subproject and html diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index 1adead6a4527..03f7beade470 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -589,3 +589,168 @@ Time stamps for outgoing packets are to be generated as follows: this would occur at a later time in the processing pipeline than other software time stamping and therefore could lead to unexpected deltas between time stamps. + +3.2 Special considerations for stacked PTP Hardware Clocks +---------------------------------------------------------- + +There are situations when there may be more than one PHC (PTP Hardware Clock) +in the data path of a packet. The kernel has no explicit mechanism to allow the +user to select which PHC to use for timestamping Ethernet frames. Instead, the +assumption is that the outermost PHC is always the most preferable, and that +kernel drivers collaborate towards achieving that goal. Currently there are 3 +cases of stacked PHCs, detailed below: + +3.2.1 DSA (Distributed Switch Architecture) switches +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These are Ethernet switches which have one of their ports connected to an +(otherwise completely unaware) host Ethernet interface, and perform the role of +a port multiplier with optional forwarding acceleration features. Each DSA +switch port is visible to the user as a standalone (virtual) network interface, +and its network I/O is performed, under the hood, indirectly through the host +interface (redirecting to the host port on TX, and intercepting frames on RX). + +When a DSA switch is attached to a host port, PTP synchronization has to +suffer, since the switch's variable queuing delay introduces a path delay +jitter between the host port and its PTP partner. For this reason, some DSA +switches include a timestamping clock of their own, and have the ability to +perform network timestamping on their own MAC, such that path delays only +measure wire and PHY propagation latencies. Timestamping DSA switches are +supported in Linux and expose the same ABI as any other network interface (save +for the fact that the DSA interfaces are in fact virtual in terms of network +I/O, they do have their own PHC). It is typical, but not mandatory, for all +interfaces of a DSA switch to share the same PHC. + +By design, PTP timestamping with a DSA switch does not need any special +handling in the driver for the host port it is attached to. However, when the +host port also supports PTP timestamping, DSA will take care of intercepting +the ``.ndo_do_ioctl`` calls towards the host port, and block attempts to enable +hardware timestamping on it. This is because the SO_TIMESTAMPING API does not +allow the delivery of multiple hardware timestamps for the same packet, so +anybody else except for the DSA switch port must be prevented from doing so. + +In code, DSA provides for most of the infrastructure for timestamping already, +in generic code: a BPF classifier (``ptp_classify_raw``) is used to identify +PTP event messages (any other packets, including PTP general messages, are not +timestamped), and provides two hooks to drivers: + +- ``.port_txtstamp()``: The driver is passed a clone of the timestampable skb + to be transmitted, before actually transmitting it. Typically, a switch will + have a PTP TX timestamp register (or sometimes a FIFO) where the timestamp + becomes available. There may be an IRQ that is raised upon this timestamp's + availability, or the driver might have to poll after invoking + ``dev_queue_xmit()`` towards the host interface. Either way, in the + ``.port_txtstamp()`` method, the driver only needs to save the clone for + later use (when the timestamp becomes available). Each skb is annotated with + a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the driver's + job of keeping track of which clone belongs to which skb. + +- ``.port_rxtstamp()``: The original (and only) timestampable skb is provided + to the driver, for it to annotate it with a timestamp, if that is immediately + available, or defer to later. On reception, timestamps might either be + available in-band (through metadata in the DSA header, or attached in other + ways to the packet), or out-of-band (through another RX timestamping FIFO). + Deferral on RX is typically necessary when retrieving the timestamp needs a + sleepable context. In that case, it is the responsibility of the DSA driver + to call ``netif_rx_ni()`` on the freshly timestamped skb. + +3.2.2 Ethernet PHYs +^^^^^^^^^^^^^^^^^^^ + +These are devices that typically fulfill a Layer 1 role in the network stack, +hence they do not have a representation in terms of a network interface as DSA +switches do. However, PHYs may be able to detect and timestamp PTP packets, for +performance reasons: timestamps taken as close as possible to the wire have the +potential to yield a more stable and precise synchronization. + +A PHY driver that supports PTP timestamping must create a ``struct +mii_timestamper`` and add a pointer to it in ``phydev->mii_ts``. The presence +of this pointer will be checked by the networking stack. + +Since PHYs do not have network interface representations, the timestamping and +ethtool ioctl operations for them need to be mediated by their respective MAC +driver. Therefore, as opposed to DSA switches, modifications need to be done +to each individual MAC driver for PHY timestamping support. This entails: + +- Checking, in ``.ndo_do_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)`` + is true or not. If it is, then the MAC driver should not process this request + but instead pass it on to the PHY using ``phy_mii_ioctl()``. + +- On RX, special intervention may or may not be needed, depending on the + function used to deliver skb's up the network stack. In the case of plain + ``netif_rx()`` and similar, MAC drivers must check whether + ``skb_defer_rx_timestamp(skb)`` is necessary or not - and if it is, don't + call ``netif_rx()`` at all. If ``CONFIG_NETWORK_PHY_TIMESTAMPING`` is + enabled, and ``skb->dev->phydev->mii_ts`` exists, its ``.rxtstamp()`` hook + will be called now, to determine, using logic very similar to DSA, whether + deferral for RX timestamping is necessary. Again like DSA, it becomes the + responsibility of the PHY driver to send the packet up the stack when the + timestamp is available. + + For other skb receive functions, such as ``napi_gro_receive`` and + ``netif_receive_skb``, the stack automatically checks whether + ``skb_defer_rx_timestamp()`` is necessary, so this check is not needed inside + the driver. + +- On TX, again, special intervention might or might not be needed. The + function that calls the ``mii_ts->txtstamp()`` hook is named + ``skb_clone_tx_timestamp()``. This function can either be called directly + (case in which explicit MAC driver support is indeed needed), but the + function also piggybacks from the ``skb_tx_timestamp()`` call, which many MAC + drivers already perform for software timestamping purposes. Therefore, if a + MAC supports software timestamping, it does not need to do anything further + at this stage. + +3.2.3 MII bus snooping devices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These perform the same role as timestamping Ethernet PHYs, save for the fact +that they are discrete devices and can therefore be used in conjunction with +any PHY even if it doesn't support timestamping. In Linux, they are +discoverable and attachable to a ``struct phy_device`` through Device Tree, and +for the rest, they use the same mii_ts infrastructure as those. See +Documentation/devicetree/bindings/ptp/timestamper.txt for more details. + +3.2.4 Other caveats for MAC drivers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Stacked PHCs, especially DSA (but not only) - since that doesn't require any +modification to MAC drivers, so it is more difficult to ensure correctness of +all possible code paths - is that they uncover bugs which were impossible to +trigger before the existence of stacked PTP clocks. One example has to do with +this line of code, already presented earlier:: + + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS; + +Any TX timestamping logic, be it a plain MAC driver, a DSA switch driver, a PHY +driver or a MII bus snooping device driver, should set this flag. +But a MAC driver that is unaware of PHC stacking might get tripped up by +somebody other than itself setting this flag, and deliver a duplicate +timestamp. +For example, a typical driver design for TX timestamping might be to split the +transmission part into 2 portions: + +1. "TX": checks whether PTP timestamping has been previously enabled through + the ``.ndo_do_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the + current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags & + SKBTX_HW_TSTAMP``"). If this is true, it sets the + "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as + described above, in the case of a stacked PHC system, this condition should + never trigger, as this MAC is certainly not the outermost PHC. But this is + not where the typical issue is. Transmission proceeds with this packet. + +2. "TX confirmation": Transmission has finished. The driver checks whether it + is necessary to collect any TX timestamp for it. Here is where the typical + issues are: the MAC driver takes a shortcut and only checks whether + "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``" was set. With a stacked + PHC system, this is incorrect because this MAC driver is not the only entity + in the TX data path who could have enabled SKBTX_IN_PROGRESS in the first + place. + +The correct solution for this problem is for MAC drivers to have a compound +check in their "TX confirmation" portion, not only for +"``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``", but also for +"``priv->hwtstamp_tx_enabled == true``". Because the rest of the system ensures +that PTP timestamping is not enabled for anything other than the outermost PHC, +this enhanced check will avoid delivering a duplicated TX timestamp to user +space. diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst index f914e81fd3a6..37773da2bee5 100644 --- a/Documentation/networking/tls-offload.rst +++ b/Documentation/networking/tls-offload.rst @@ -428,6 +428,24 @@ by the driver: which were part of a TLS stream. * ``rx_tls_decrypted_bytes`` - number of TLS payload bytes in RX packets which were successfully decrypted. + * ``rx_tls_ctx`` - number of TLS RX HW offload contexts added to device for + decryption. + * ``rx_tls_del`` - number of TLS RX HW offload contexts deleted from device + (connection has finished). + * ``rx_tls_resync_req_pkt`` - number of received TLS packets with a resync + request. + * ``rx_tls_resync_req_start`` - number of times the TLS async resync request + was started. + * ``rx_tls_resync_req_end`` - number of times the TLS async resync request + properly ended with providing the HW tracked tcp-seq. + * ``rx_tls_resync_req_skip`` - number of times the TLS async resync request + procedure was started by not properly ended. + * ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to + the driver was successfully handled. + * ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to + the driver was terminated unsuccessfully. + * ``rx_tls_err`` - number of RX packets which were part of a TLS stream + but were not decrypted due to unexpected error in the state machine. * ``tx_tls_encrypted_packets`` - number of TX packets passed to the device for encryption of their TLS payload. * ``tx_tls_encrypted_bytes`` - number of TLS payload bytes in TX packets diff --git a/Documentation/openrisc/openrisc_port.rst b/Documentation/openrisc/openrisc_port.rst index 4b2c437942a0..657ac4af7be6 100644 --- a/Documentation/openrisc/openrisc_port.rst +++ b/Documentation/openrisc/openrisc_port.rst @@ -8,7 +8,7 @@ target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k). For information about OpenRISC processors and ongoing development: ======= ============================= - website http://openrisc.io + website https://openrisc.io email openrisc@lists.librecores.org ======= ============================= diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 90a345d57ae9..a6fb986abe3c 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -1,15 +1,17 @@ -==================== -Energy Model of CPUs -==================== +.. SPDX-License-Identifier: GPL-2.0 + +======================= +Energy Model of devices +======================= 1. Overview ----------- The Energy Model (EM) framework serves as an interface between drivers knowing -the power consumed by CPUs at various performance levels, and the kernel +the power consumed by devices at various performance levels, and the kernel subsystems willing to use that information to make energy-aware decisions. -The source of the information about the power consumed by CPUs can vary greatly +The source of the information about the power consumed by devices can vary greatly from one platform to another. These power costs can be estimated using devicetree data in some cases. In others, the firmware will know better. Alternatively, userspace might be best positioned. And so on. In order to avoid @@ -25,7 +27,7 @@ framework, and interested clients reading the data from it:: +---------------+ +-----------------+ +---------------+ | Thermal (IPA) | | Scheduler (EAS) | | Other | +---------------+ +-----------------+ +---------------+ - | | em_pd_energy() | + | | em_cpu_energy() | | | em_cpu_get() | +---------+ | +---------+ | | | @@ -35,7 +37,7 @@ framework, and interested clients reading the data from it:: | Framework | +---------------------+ ^ ^ ^ - | | | em_register_perf_domain() + | | | em_dev_register_perf_domain() +----------+ | +---------+ | | | +---------------+ +---------------+ +--------------+ @@ -47,12 +49,12 @@ framework, and interested clients reading the data from it:: | Device Tree | | Firmware | | ? | +--------------+ +---------------+ +--------------+ -The EM framework manages power cost tables per 'performance domain' in the -system. A performance domain is a group of CPUs whose performance is scaled -together. Performance domains generally have a 1-to-1 mapping with CPUFreq -policies. All CPUs in a performance domain are required to have the same -micro-architecture. CPUs in different performance domains can have different -micro-architectures. +In case of CPU devices the EM framework manages power cost tables per +'performance domain' in the system. A performance domain is a group of CPUs +whose performance is scaled together. Performance domains generally have a +1-to-1 mapping with CPUFreq policies. All CPUs in a performance domain are +required to have the same micro-architecture. CPUs in different performance +domains can have different micro-architectures. 2. Core APIs @@ -70,14 +72,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. Drivers are expected to register performance domains into the EM framework by calling the following API:: - int em_register_perf_domain(cpumask_t *span, unsigned int nr_states, - struct em_data_callback *cb); + int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, + struct em_data_callback *cb, cpumask_t *cpus); -Drivers must specify the CPUs of the performance domains using the cpumask -argument, and provide a callback function returning tuples -for each capacity state. The callback function provided by the driver is free +Drivers must provide a callback function returning tuples +for each performance state. The callback function provided by the driver is free to fetch data from any relevant location (DT, firmware, ...), and by any mean -deemed necessary. See Section 3. for an example of driver implementing this +deemed necessary. Only for CPU devices, drivers must specify the CPUs of the +performance domains using cpumask. For other devices than CPUs the last +argument must be set to NULL. +See Section 3. for an example of driver implementing this callback, and kernel/power/energy_model.c for further documentation on this API. @@ -85,13 +89,20 @@ API. 2.3 Accessing performance domains ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +There are two API functions which provide the access to the energy model: +em_cpu_get() which takes CPU id as an argument and em_pd_get() with device +pointer as an argument. It depends on the subsystem which interface it is +going to use, but in case of CPU devices both functions return the same +performance domain. + Subsystems interested in the energy model of a CPU can retrieve it using the em_cpu_get() API. The energy model tables are allocated once upon creation of the performance domains, and kept in memory untouched. The energy consumed by a performance domain can be estimated using the -em_pd_energy() API. The estimation is performed assuming that the schedutil -CPUfreq governor is in use. +em_cpu_energy() API. The estimation is performed assuming that the schedutil +CPUfreq governor is in use in case of CPU device. Currently this calculation is +not provided for other type of devices. More details about the above APIs can be found in include/linux/energy_model.h. @@ -106,42 +117,46 @@ EM framework:: -> drivers/cpufreq/foo_cpufreq.c - 01 static int est_power(unsigned long *mW, unsigned long *KHz, int cpu) - 02 { - 03 long freq, power; - 04 - 05 /* Use the 'foo' protocol to ceil the frequency */ - 06 freq = foo_get_freq_ceil(cpu, *KHz); - 07 if (freq < 0); - 08 return freq; - 09 - 10 /* Estimate the power cost for the CPU at the relevant freq. */ - 11 power = foo_estimate_power(cpu, freq); - 12 if (power < 0); - 13 return power; - 14 - 15 /* Return the values to the EM framework */ - 16 *mW = power; - 17 *KHz = freq; - 18 - 19 return 0; - 20 } - 21 - 22 static int foo_cpufreq_init(struct cpufreq_policy *policy) - 23 { - 24 struct em_data_callback em_cb = EM_DATA_CB(est_power); - 25 int nr_opp, ret; - 26 - 27 /* Do the actual CPUFreq init work ... */ - 28 ret = do_foo_cpufreq_init(policy); - 29 if (ret) - 30 return ret; - 31 - 32 /* Find the number of OPPs for this policy */ - 33 nr_opp = foo_get_nr_opp(policy); - 34 - 35 /* And register the new performance domain */ - 36 em_register_perf_domain(policy->cpus, nr_opp, &em_cb); - 37 - 38 return 0; - 39 } + 01 static int est_power(unsigned long *mW, unsigned long *KHz, + 02 struct device *dev) + 03 { + 04 long freq, power; + 05 + 06 /* Use the 'foo' protocol to ceil the frequency */ + 07 freq = foo_get_freq_ceil(dev, *KHz); + 08 if (freq < 0); + 09 return freq; + 10 + 11 /* Estimate the power cost for the dev at the relevant freq. */ + 12 power = foo_estimate_power(dev, freq); + 13 if (power < 0); + 14 return power; + 15 + 16 /* Return the values to the EM framework */ + 17 *mW = power; + 18 *KHz = freq; + 19 + 20 return 0; + 21 } + 22 + 23 static int foo_cpufreq_init(struct cpufreq_policy *policy) + 24 { + 25 struct em_data_callback em_cb = EM_DATA_CB(est_power); + 26 struct device *cpu_dev; + 27 int nr_opp, ret; + 28 + 29 cpu_dev = get_cpu_device(cpumask_first(policy->cpus)); + 30 + 31 /* Do the actual CPUFreq init work ... */ + 32 ret = do_foo_cpufreq_init(policy); + 33 if (ret) + 34 return ret; + 35 + 36 /* Find the number of OPPs for this policy */ + 37 nr_opp = foo_get_nr_opp(policy); + 38 + 39 /* And register the new performance domain */ + 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus); + 41 + 42 return 0; + 43 } diff --git a/Documentation/power/powercap/powercap.rst b/Documentation/power/powercap/powercap.rst index 7ae3b44c7624..e75d12596dac 100644 --- a/Documentation/power/powercap/powercap.rst +++ b/Documentation/power/powercap/powercap.rst @@ -167,11 +167,13 @@ For example:: package-0 --------- -The Intel RAPL technology allows two constraints, short term and long term, -with two different time windows to be applied to each power zone. Thus for -each zone there are 2 attributes representing the constraint names, 2 power -limits and 2 attributes representing the sizes of the time windows. Such that, -constraint_j_* attributes correspond to the jth constraint (j = 0,1). +Depending on different power zones, the Intel RAPL technology allows +one or multiple constraints like short term, long term and peak power, +with different time windows to be applied to each power zone. +All the zones contain attributes representing the constraint names, +power limits and the sizes of the time windows. Note that time window +is not applicable to peak power. Here, constraint_j_* attributes +correspond to the jth constraint (j = 0,1,2). For example:: @@ -181,6 +183,9 @@ For example:: constraint_1_name constraint_1_power_limit_uw constraint_1_time_window_us + constraint_2_name + constraint_2_power_limit_uw + constraint_2_time_window_us Power Zone Attributes ===================== diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst index afe2d5e54db6..748bf483b1c2 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -31,6 +31,7 @@ powerpc transactional_memory ultravisor vas-api + vcpudispatch_stats .. only:: subproject and html diff --git a/Documentation/powerpc/vas-api.rst b/Documentation/powerpc/vas-api.rst index 788dc8375a0e..90c50ed839f3 100644 --- a/Documentation/powerpc/vas-api.rst +++ b/Documentation/powerpc/vas-api.rst @@ -43,7 +43,7 @@ engine for this process. Once a connection is established, the application should use the mmap() system call to map the hardware address of engine's request queue into the application's virtual address space. -The application can then submit one or more requests to the the engine by +The application can then submit one or more requests to the engine by using copy/paste instructions and pasting the CRBs to the virtual address (aka paste_address) returned by mmap(). User space can close the established connection or send window by closing the file descriptior @@ -87,6 +87,7 @@ Applications may chose a specific instance of the NX co-processor using the vas_id field in the VAS_TX_WIN_OPEN ioctl as detailed below. A userspace library libnxz is available here but still in development: + https://github.com/abalib/power-gzip Applications that use inflate / deflate calls can link with libnxz @@ -110,6 +111,7 @@ Applications should use the VAS_TX_WIN_OPEN ioctl as follows to establish a connection with NX co-processor engine: :: + struct vas_tx_win_open_attr { __u32 version; __s16 vas_id; /* specific instance of vas or -1 @@ -119,8 +121,10 @@ a connection with NX co-processor engine: __u64 reserved2[6]; }; - version: The version field must be currently set to 1. - vas_id: If '-1' is passed, kernel will make a best-effort attempt + version: + The version field must be currently set to 1. + vas_id: + If '-1' is passed, kernel will make a best-effort attempt to assign an optimal instance of NX for the process. To select the specific VAS instance, refer "Discovery of available VAS engines" section below. @@ -129,7 +133,8 @@ a connection with NX co-processor engine: and must be set to 0. The attributes attr for the VAS_TX_WIN_OPEN ioctl are defined as - follows: + follows:: + #define VAS_MAGIC 'v' #define VAS_TX_WIN_OPEN _IOW(VAS_MAGIC, 1, struct vas_tx_win_open_attr) @@ -141,6 +146,8 @@ a connection with NX co-processor engine: returns -1 and sets the errno variable to indicate the error. Error conditions: + + ====== ================================================ EINVAL fd does not refer to a valid VAS device. EINVAL Invalid vas ID EINVAL version is not set with proper value @@ -149,6 +156,7 @@ a connection with NX co-processor engine: ENOSPC System has too many active windows (connections) opened EINVAL reserved fields are not set to 0. + ====== ================================================ See the ioctl(2) man page for more details, error codes and restrictions. @@ -158,11 +166,13 @@ mmap() NX-GZIP device The mmap() system call for a NX-GZIP device fd returns a paste_address that the application can use to copy/paste its CRB to the hardware engines. + :: paste_addr = mmap(addr, size, prot, flags, fd, offset); Only restrictions on mmap for a NX-GZIP device fd are: + * size should be PAGE_SIZE * offset parameter should be 0ULL @@ -170,10 +180,12 @@ that the application can use to copy/paste its CRB to the hardware engines. In addition to the error conditions listed on the mmap(2) man page, can also fail with one of the following error codes: + ====== ============================================= EINVAL fd is not associated with an open window (i.e mmap() does not follow a successful call to the VAS_TX_WIN_OPEN ioctl). EINVAL offset field is not 0ULL. + ====== ============================================= Discovery of available VAS engines ================================== @@ -210,7 +222,7 @@ In case if NX encounters translation error (called NX page fault) on CSB address or any request buffer, raises an interrupt on the CPU to handle the fault. Page fault can happen if an application passes invalid addresses or request buffers are not in memory. The operating system handles the fault by -updating CSB with the following data: +updating CSB with the following data:: csb.flags = CSB_V; csb.cc = CSB_CC_FAULT_ADDRESS; @@ -223,7 +235,7 @@ the application can resend this request to NX. If the OS can not update CSB due to invalid CSB address, sends SEGV signal to the process who opened the send window on which the original request was -issued. This signal returns with the following siginfo struct: +issued. This signal returns with the following siginfo struct:: siginfo.si_signo = SIGSEGV; siginfo.si_errno = EFAULT; @@ -248,6 +260,7 @@ Simple example ============== :: + int use_nx_gzip() { int rc, fd; diff --git a/Documentation/powerpc/vcpudispatch_stats.txt b/Documentation/powerpc/vcpudispatch_stats.rst similarity index 94% rename from Documentation/powerpc/vcpudispatch_stats.txt rename to Documentation/powerpc/vcpudispatch_stats.rst index e21476bfd78c..5704657a5987 100644 --- a/Documentation/powerpc/vcpudispatch_stats.txt +++ b/Documentation/powerpc/vcpudispatch_stats.rst @@ -1,5 +1,8 @@ -VCPU Dispatch Statistics: -========================= +.. SPDX-License-Identifier: GPL-2.0 + +======================== +VCPU Dispatch Statistics +======================== For Shared Processor LPARs, the POWER Hypervisor maintains a relatively static mapping of the LPAR processors (vcpus) to physical processor @@ -20,25 +23,29 @@ The statistics themselves are available by reading the procfs file a vcpu as represented by the first field, followed by 8 numbers. The first number corresponds to: + 1. total vcpu dispatches since the beginning of statistics collection The next 4 numbers represent vcpu dispatch dispersions: + 2. number of times this vcpu was dispatched on the same processor as last time 3. number of times this vcpu was dispatched on a different processor core as last time, but within the same chip 4. number of times this vcpu was dispatched on a different chip 5. number of times this vcpu was dispatches on a different socket/drawer -(next numa boundary) + (next numa boundary) The final 3 numbers represent statistics in relation to the home node of the vcpu: + 6. number of times this vcpu was dispatched in its home node (chip) 7. number of times this vcpu was dispatched in a different node 8. number of times this vcpu was dispatched in a node further away (numa -distance) + distance) + +An example output:: -An example output: $ sudo cat /proc/powerpc/vcpudispatch_stats cpu0 6839 4126 2683 30 0 6821 18 0 cpu1 2515 1274 1229 12 0 2509 6 0 diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst index b21b5b245d13..3588f48841eb 100644 --- a/Documentation/process/2.Process.rst +++ b/Documentation/process/2.Process.rst @@ -295,7 +295,7 @@ mainline get there via -mm. The current -mm patch is available in the "mmotm" (-mm of the moment) directory at: - http://www.ozlabs.org/~akpm/mmotm/ + https://www.ozlabs.org/~akpm/mmotm/ Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. @@ -306,7 +306,7 @@ the mainline is expected to look like after the next merge window closes. Linux-next trees are announced on the linux-kernel and linux-next mailing lists when they are assembled; they can be downloaded from: - http://www.kernel.org/pub/linux/kernel/next/ + https://www.kernel.org/pub/linux/kernel/next/ Linux-next has become an integral part of the kernel development process; all patches merged during a given merge window should really have found @@ -365,21 +365,21 @@ to keep up with what other developers (and the mainline) are doing. Git is now packaged by almost all Linux distributions. There is a home page at: - http://git-scm.com/ + https://git-scm.com/ That page has pointers to documentation and tutorials. Among the kernel developers who do not use git, the most popular choice is almost certainly Mercurial: - http://www.selenic.com/mercurial/ + https://www.selenic.com/mercurial/ Mercurial shares many features with git, but it provides an interface which many find easier to use. The other tool worth knowing about is Quilt: - http://savannah.nongnu.org/projects/quilt/ + https://savannah.nongnu.org/projects/quilt/ Quilt is a patch management system, rather than a source code management system. It does not track history over time; it is, instead, oriented @@ -494,7 +494,7 @@ Andrew Morton gives this advice for aspiring kernel developers with others on getting things fixed up (this can require persistence!) but that's fine - it's a part of kernel development. -(http://lwn.net/Articles/283982/). +(https://lwn.net/Articles/283982/). In the absence of obvious problems to fix, developers are advised to look at the current lists of regressions and open bugs in general. There is diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst index 13dd893c9f88..c27e59d2f702 100644 --- a/Documentation/process/4.Coding.rst +++ b/Documentation/process/4.Coding.rst @@ -210,7 +210,7 @@ breaks? The best answer to this question was expressed by Linus in July, progress at all. Is it two steps forwards, one step back, or one step forward and two steps back? -(http://lwn.net/Articles/243460/). +(https://lwn.net/Articles/243460/). An especially unwelcome type of regression is any sort of change to the user-space ABI. Once an interface has been exported to user space, it must @@ -323,7 +323,7 @@ other architectures. If you do not happen to have an S/390 system or a Blackfin development board handy, you can still perform the compilation step. A large set of cross compilers for x86 systems can be found at - http://www.kernel.org/pub/tools/crosstool/ + https://www.kernel.org/pub/tools/crosstool/ Some time spent installing and using these compilers will help avoid embarrassment later. diff --git a/Documentation/process/botching-up-ioctls.rst b/Documentation/process/botching-up-ioctls.rst index 2d4829b2fb09..ba4667ab396b 100644 --- a/Documentation/process/botching-up-ioctls.rst +++ b/Documentation/process/botching-up-ioctls.rst @@ -2,7 +2,7 @@ (How to avoid) Botching up ioctls ================================= -From: http://blog.ffwll.ch/2013/11/botching-up-ioctls.html +From: https://blog.ffwll.ch/2013/11/botching-up-ioctls.html By: Daniel Vetter, Copyright © 2013 Intel Corporation diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 8f68e728ae6b..ee741763a3fc 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -129,7 +129,7 @@ Architectural changes --------------------- DevFS has been obsoleted in favour of udev -(http://www.kernel.org/pub/linux/utils/kernel/hotplug/) +(https://www.kernel.org/pub/linux/utils/kernel/hotplug/) 32-bit UID support is now in place. Have fun! @@ -421,7 +421,7 @@ Intel P6 microcode udev ---- -- +- FUSE ---- @@ -474,4 +474,4 @@ Kernel documentation Sphinx ------ -- +- diff --git a/Documentation/process/clang-format.rst b/Documentation/process/clang-format.rst index 6710c0707721..82676e5a7c6e 100644 --- a/Documentation/process/clang-format.rst +++ b/Documentation/process/clang-format.rst @@ -32,7 +32,7 @@ Linux distributions for a long time. Search for ``clang-format`` in your repositories. Otherwise, you can either download pre-built LLVM/clang binaries or build the source code from: - http://releases.llvm.org/download.html + https://releases.llvm.org/download.html See more information about the tool at: diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 1bee6f8affdb..98227226c4e5 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -1149,7 +1149,7 @@ Addison-Wesley, Inc., 1999. ISBN 0-201-61586-X. GNU manuals - where in compliance with K&R and this text - for cpp, gcc, -gcc internals and indent, all available from http://www.gnu.org/manual/ +gcc internals and indent, all available from https://www.gnu.org/manual/ WG14 is the international standardization working group for the programming language C, URL: http://www.open-std.org/JTC1/SC22/WG14/ diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 652e2aa02a66..4a9aa4f0681e 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -51,6 +51,24 @@ to make sure their systems do not continue running in the face of "unreachable" conditions. (For example, see commits like `this one `_.) +uninitialized_var() +------------------- +For any compiler warnings about uninitialized variables, just add +an initializer. Using the uninitialized_var() macro (or similar +warning-silencing tricks) is dangerous as it papers over `real bugs +`_ +(or can in the future), and suppresses unrelated compiler warnings +(e.g. "unused variable"). If the compiler thinks it is uninitialized, +either simply initialize the variable or make compiler changes. Keep in +mind that in most cases, if an initialization is obviously redundant, +the compiler's dead-store elimination pass will make sure there are no +needless variable writes. + +As Linus has said, this macro +`must `_ +`be `_ +`removed `_. + open-coded arithmetic in allocator arguments -------------------------------------------- Dynamic size calculations (especially multiplication) should not be @@ -85,6 +103,11 @@ Instead, use the helper:: header = kzalloc(struct_size(header, item, count), GFP_KERNEL); +.. note:: If you are using struct_size() on a structure containing a zero-length + or a one-element array as a trailing array member, please refactor such + array usage and switch to a `flexible array member + <#zero-length-and-one-element-arrays>`_ instead. + See array_size(), array3_size(), and struct_size(), for more details as well as the related check_add_overflow() and check_mul_overflow() family of functions. @@ -200,3 +223,116 @@ All switch/case blocks must end in one of: * continue; * goto