Manually convert thermal, crypto and misc devices to ReST
Subsystems (13)
v2 cover Manually convert thermal, crypto and misc devices to ReST
Manually convert some files from thermal, crypto and misc-devices to ReST format.
This patch is against linux-next 20200217 tag.
v2:
- a small change at patch 2 to avoid uneeded whitespace changes;
- added 13 new patches at the end
Mauro Carvalho Chehab (24):
docs: thermal: convert cpu-idle-cooling.rst to ReST
docs: crypto: convert asymmetric-keys.txt to ReST
docs: crypto: convert api-intro.txt to ReST format
docs: crypto: convert async-tx-api.txt to ReST format
docs: crypto: descore-readme.txt: convert to ReST format
docs: misc-devices/spear-pcie-gadget.txt: convert to ReST
docs: misc-devices/pci-endpoint-test.txt: convert to ReST
docs: misc-devices/pci-endpoint-test.txt: convert to ReST
docs: misc-devices/c2port.txt: convert to ReST format
docs: misc-devices/bh1770glc.txt: convert to ReST
docs: misc-devices/apds990x.txt: convert to ReST format
docs: pci: endpoint/function/binding/pci-test.txt convert to ReST
docs: arm64: convert perf.txt to ReST format
docs: cpu-freq: convert index.txt to ReST
docs: cpu-freq: convert amd-powernow.txt to ReST
docs: cpu-freq: convert core.txt to ReST
docs: cpu-freq: convert cpu-drivers.txt to ReST
docs: cpu-freq: convert cpufreq-nforce2.txt to ReST
docs: cpu-freq: convert cpufreq-stats.txt to ReST
docs: cpu-freq: convert pcc-cpufreq.txt to ReST
docs: powerpc: convert vcpudispatch_stats.txt to ReST
docs: sh: convert new-machine.txt to ReST
docs: sh: convert register-banks.txt to ReST
docs: trace: ring-buffer-design.txt: convert to ReST format
.../endpoint/function/binding/pci-test.rst | 26 +
.../endpoint/function/binding/pci-test.txt | 19 -
Documentation/PCI/endpoint/index.rst | 2 +
Documentation/arm64/index.rst | 1 +
Documentation/arm64/{perf.txt => perf.rst} | 7 +-
.../{amd-powernow.txt => amd-powernow.rst} | 12 +-
Documentation/cpu-freq/{core.txt => core.rst} | 65 +-
.../{cpu-drivers.txt => cpu-drivers.rst} | 129 ++-
...pufreq-nforce2.txt => cpufreq-nforce2.rst} | 18 +-
.../{cpufreq-stats.txt => cpufreq-stats.rst} | 121 +--
Documentation/cpu-freq/index.rst | 42 +
Documentation/cpu-freq/index.txt | 56 --
.../{pcc-cpufreq.txt => pcc-cpufreq.rst} | 86 +-
.../crypto/{api-intro.txt => api-intro.rst} | 186 ++--
...symmetric-keys.txt => asymmetric-keys.rst} | 91 +-
.../{async-tx-api.txt => async-tx-api.rst} | 253 +++---
...{descore-readme.txt => descore-readme.rst} | 152 +++-
Documentation/crypto/index.rst | 5 +
.../driver-api/thermal/cpu-idle-cooling.rst | 18 +-
Documentation/driver-api/thermal/index.rst | 1 +
Documentation/index.rst | 1 +
.../{ad525x_dpot.txt => ad525x_dpot.rst} | 24 +-
.../{apds990x.txt => apds990x.rst} | 31 +-
.../{bh1770glc.txt => bh1770glc.rst} | 45 +-
.../misc-devices/{c2port.txt => c2port.rst} | 58 +-
Documentation/misc-devices/index.rst | 6 +
.../misc-devices/pci-endpoint-test.rst | 56 ++
.../misc-devices/pci-endpoint-test.txt | 41 -
.../misc-devices/spear-pcie-gadget.rst | 170 ++++
.../misc-devices/spear-pcie-gadget.txt | 130 ---
Documentation/powerpc/index.rst | 1 +
...patch_stats.txt => vcpudispatch_stats.rst} | 17 +-
Documentation/sh/index.rst | 6 +
.../sh/{new-machine.txt => new-machine.rst} | 193 +++--
...{register-banks.txt => register-banks.rst} | 12 +-
Documentation/trace/index.rst | 1 +
...ffer-design.txt => ring-buffer-design.rst} | 802 ++++++++++--------
37 files changed, 1603 insertions(+), 1281 deletions(-)
create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.rst
delete mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt
rename Documentation/arm64/{perf.txt => perf.rst} (95%)
rename Documentation/cpu-freq/{amd-powernow.txt => amd-powernow.rst} (89%)
rename Documentation/cpu-freq/{core.txt => core.rst} (69%)
rename Documentation/cpu-freq/{cpu-drivers.txt => cpu-drivers.rst} (72%)
rename Documentation/cpu-freq/{cpufreq-nforce2.txt => cpufreq-nforce2.rst} (55%)
rename Documentation/cpu-freq/{cpufreq-stats.txt => cpufreq-stats.rst} (53%)
create mode 100644 Documentation/cpu-freq/index.rst
delete mode 100644 Documentation/cpu-freq/index.txt
rename Documentation/cpu-freq/{pcc-cpufreq.txt => pcc-cpufreq.rst} (80%)
rename Documentation/crypto/{api-intro.txt => api-intro.rst} (70%)
rename Documentation/crypto/{asymmetric-keys.txt => asymmetric-keys.rst} (91%)
rename Documentation/crypto/{async-tx-api.txt => async-tx-api.rst} (55%)
rename Documentation/crypto/{descore-readme.txt => descore-readme.rst} (81%)
rename Documentation/misc-devices/{ad525x_dpot.txt => ad525x_dpot.rst} (85%)
rename Documentation/misc-devices/{apds990x.txt => apds990x.rst} (86%)
rename Documentation/misc-devices/{bh1770glc.txt => bh1770glc.rst} (83%)
rename Documentation/misc-devices/{c2port.txt => c2port.rst} (59%)
create mode 100644 Documentation/misc-devices/pci-endpoint-test.rst
delete mode 100644 Documentation/misc-devices/pci-endpoint-test.txt
create mode 100644 Documentation/misc-devices/spear-pcie-gadget.rst
delete mode 100644 Documentation/misc-devices/spear-pcie-gadget.txt
rename Documentation/powerpc/{vcpudispatch_stats.txt => vcpudispatch_stats.rst} (94%)
rename Documentation/sh/{new-machine.txt => new-machine.rst} (73%)
rename Documentation/sh/{register-banks.txt => register-banks.rst} (88%)
rename Documentation/trace/{ring-buffer-design.txt => ring-buffer-design.rst} (55%)Signature · 1 line
2.24.1
PATCH v2 1/24 docs: thermal: convert cpu-idle-cooling.rst to ReST
Despite being named with .rst extension, this file doesn't match the ReST standard. It actually causes a crash at Sphinx:
Sphinx parallel build error:
docutils.utils.SystemMessage: /devel/v4l/docs/Documentation/driver-api/thermal/cpu-idle-cooling.rst:69: (SEVERE/4) Unexpected section title.
Add needed markups for it to be properly parsed.
While here, add it to the thermal index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
--- .../driver-api/thermal/cpu-idle-cooling.rst | 18 ++++++++++++------ Documentation/driver-api/thermal/index.rst | 1 + 2 files changed, 13 insertions(+), 6 deletions(-)
Documentation/driver-api/thermal/cpu-idle-cooling.rst +12 -6
@@ -1,3 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +CPU Idle Cooling +================ + Situation: ----------
@@ -45,7 +51,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)
@@ -136,7 +142,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
@@ -145,7 +151,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
@@ -154,7 +160,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)
@@ -165,7 +171,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)
@@ -188,7 +194,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 )
Documentation/driver-api/thermal/index.rst +1 -0
@@ -8,6 +8,7 @@ Thermal :maxdepth: 1 cpu-cooling-api + cpu-idle-cooling sysfs-api power_allocator
Signature · 1 line
2.24.1
PATCH v2 2/24 docs: crypto: convert asymmetric-keys.txt to ReST
In reply to Mauro Carvalho ChehabThis file is almost compatible with ReST. Just minor changes were needed:
- Adjust document and titles markups;
- Adjust numbered list markups;
- Add a comments markup for the Contents section;
- Add markups for literal blocks.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
...symmetric-keys.txt => asymmetric-keys.rst} | 91 +++++++++----------
Documentation/crypto/index.rst | 1 +
2 files changed, 44 insertions(+), 48 deletions(-)
rename Documentation/crypto/{asymmetric-keys.txt => asymmetric-keys.rst} (91%)Documentation/crypto/asymmetric-keys.rst renamed from Documentation/crypto/asymmetric-keys.txt +40 -44
@@ -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:<hexdigits>" then the match + 1) If the criterion string is of the form "id:<hexdigits>" 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 "<subtype>:<hexdigits>" then the + 2) If the criterion string is of the form "<subtype>:<hexdigits>" 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 <crypto/public_key.h> 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 <keys/asymmetric-subtype.h> -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 <keys/asymmetric-parser.h> -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:<key or keyring serial number>[: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`
Documentation/crypto/index.rst +1 -0
@@ -18,6 +18,7 @@ for cryptographic use cases, as well as programming examples. intro architecture + asymmetric-keys devel-algos userspace-if crypto_engine
Signature · 1 line
2.24.1
PATCH v2 3/24 docs: crypto: convert api-intro.txt to ReST format
In reply to Mauro Carvalho Chehab- Change title markups;
- Mark literal blocks;
- Use list markups at authors/credits;
- Add blank lines when needed;
- Remove trailing whitespaces.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../crypto/{api-intro.txt => api-intro.rst} | 186 ++++++++++--------
Documentation/crypto/index.rst | 1 +
2 files changed, 100 insertions(+), 87 deletions(-)
rename Documentation/crypto/{api-intro.txt => api-intro.rst} (70%)Documentation/crypto/api-intro.rst renamed from Documentation/crypto/api-intro.txt +99 -87
@@ -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 <crypto/hash.h> #include <linux/err.h> #include <linux/scatterlist.h> - + 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: [email protected] -Cc: Herbert Xu <[email protected]>, + [email protected] + +Cc: + Herbert Xu <[email protected]>, David S. Miller <[email protected]> -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 + - 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 <[email protected]> Please send any credits updates or corrections to: Herbert Xu <[email protected]> -
Documentation/crypto/index.rst +1 -0
@@ -17,6 +17,7 @@ for cryptographic use cases, as well as programming examples. :maxdepth: 2 intro + api-intro architecture asymmetric-keys devel-algos
Signature · 1 line
2.24.1
PATCH v2 4/24 docs: crypto: convert async-tx-api.txt to ReST format
In reply to Mauro Carvalho Chehab- Place the txt index inside a comment;
- Use title and chapter markups;
- Adjust markups for numbered list;
- Mark literal blocks as such;
- Use tables markup.
- Adjust indentation when needed.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../{async-tx-api.txt => async-tx-api.rst} | 253 +++++++++++-------
Documentation/crypto/index.rst | 2 +
2 files changed, 151 insertions(+), 104 deletions(-)
rename Documentation/crypto/{async-tx-api.txt => async-tx-api.rst} (55%)Documentation/crypto/async-tx-api.rst renamed from Documentation/crypto/async-tx-api.txt +149 -104
@@ -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_<operation>(<op specific parameters>, 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_<operation>(<op specific parameters>, 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_<operation> 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_<operation> are not permitted in IRQ context. Other +3.6 Constraints +--------------- + +1. Calls to async_<operation> 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: - -void callback(void *param) -{ - struct completion *cmp = param; - - 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; - - 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); - - 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(); - - wait_for_completion(&cmp); -} +result from the previous operation:: + + void callback(void *param) + { + struct completion *cmp = param; + + 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; + + 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); + + 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(); + + 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
Documentation/crypto/index.rst +2 -0
@@ -19,6 +19,8 @@ for cryptographic use cases, as well as programming examples. intro api-intro architecture + + async-tx-api asymmetric-keys devel-algos userspace-if
Signature · 1 line
2.24.1
PATCH v2 5/24 docs: crypto: descore-readme.txt: convert to ReST format
In reply to Mauro Carvalho ChehabConvert this readme file to ReST file format, preserving its contents as-is as much as possible. The only changes are:
- Added chapter and title markups;
- Added blank lines where needed;
- Added list markups where needed;
- Use a table markup;
- replace markups like `foo' to ``foo``;
- add one extra literal markup to avoid warnings.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
...{descore-readme.txt => descore-readme.rst} | 152 ++++++++++++------
Documentation/crypto/index.rst | 1 +
2 files changed, 108 insertions(+), 45 deletions(-)
rename Documentation/crypto/{descore-readme.txt => descore-readme.rst} (81%)Documentation/crypto/descore-readme.rst renamed from Documentation/crypto/descore-readme.txt +107 -45
@@ -1,8 +1,20 @@ -Below is the original README file from the descore.shar package. +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +=========================================== +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: [email protected] -$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, [email protected], 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 [email protected] 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 [email protected] 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 [email protected] 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.
Documentation/crypto/index.rst +1 -0
@@ -27,3 +27,4 @@ for cryptographic use cases, as well as programming examples. crypto_engine api api-samples + descore-readme
Signature · 1 line
2.24.1
PATCH v2 6/24 docs: misc-devices/spear-pcie-gadget.txt: convert to ReST
In reply to Mauro Carvalho Chehab- Use title/chapter markups;
- Use table markups;
- Mark literal blocks as such;
- Adjust indentation.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
--- Documentation/misc-devices/index.rst | 1 + .../misc-devices/spear-pcie-gadget.rst | 170 ++++++++++++++++++ .../misc-devices/spear-pcie-gadget.txt | 130 -------------- 3 files changed, 171 insertions(+), 130 deletions(-) create mode 100644 Documentation/misc-devices/spear-pcie-gadget.rst delete mode 100644 Documentation/misc-devices/spear-pcie-gadget.txt
Documentation/misc-devices/index.rst +1 -0
@@ -20,4 +20,5 @@ fit into other categories. isl29003 lis3lv02d max6875 + spear-pcie-gadget xilinx_sdfec
Documentation/misc-devices/spear-pcie-gadget.rst new file +170 -0
170 lines not on this page · raw message
Documentation/misc-devices/spear-pcie-gadget.txt deleted +0 -130
130 lines not on this page · raw message
Signature · 1 line
2.24.1
PATCH v2 7/24 docs: misc-devices/pci-endpoint-test.txt: convert to ReST
In reply to Mauro Carvalho Chehab- use title markups;
- mark literal blocks.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../{ad525x_dpot.txt => ad525x_dpot.rst} | 24 +++++++++----------
Documentation/misc-devices/index.rst | 1 +
2 files changed, 13 insertions(+), 12 deletions(-)
rename Documentation/misc-devices/{ad525x_dpot.txt => ad525x_dpot.rst} (85%)Documentation/misc-devices/ad525x_dpot.rst renamed from Documentation/misc-devices/ad525x_dpot.txt +12 -12
@@ -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/
Documentation/misc-devices/index.rst +1 -0
@@ -14,6 +14,7 @@ fit into other categories. .. toctree:: :maxdepth: 2 + ad525x_dpot eeprom ibmvmc ics932s401
Signature · 1 line
2.24.1
PATCH v2 8/24 docs: misc-devices/pci-endpoint-test.txt: convert to ReST
In reply to Mauro Carvalho Chehab- Use titles markups;
- Adjust identation;
- use literal markup;
- Use the proper notation for footnotes.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
--- Documentation/misc-devices/index.rst | 1 + .../misc-devices/pci-endpoint-test.rst | 56 +++++++++++++++++++ .../misc-devices/pci-endpoint-test.txt | 41 -------------- 3 files changed, 57 insertions(+), 41 deletions(-) create mode 100644 Documentation/misc-devices/pci-endpoint-test.rst delete mode 100644 Documentation/misc-devices/pci-endpoint-test.txt
Documentation/misc-devices/index.rst +1 -0
@@ -21,5 +21,6 @@ fit into other categories. isl29003 lis3lv02d max6875 + pci-endpoint-test spear-pcie-gadget xilinx_sdfec
Documentation/misc-devices/pci-endpoint-test.rst new file +56 -0
56 lines not on this page · raw message
Documentation/misc-devices/pci-endpoint-test.txt deleted +0 -41
41 lines not on this page · raw message
Signature · 1 line
2.24.1
PATCH v2 9/24 docs: misc-devices/c2port.txt: convert to ReST format
In reply to Mauro Carvalho Chehab- Use copyright symbol;
- use title markups;
- adjust indentation;
- mark literal blocks as such.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../misc-devices/{c2port.txt => c2port.rst} | 58 ++++++++++---------
Documentation/misc-devices/index.rst | 1 +
2 files changed, 32 insertions(+), 27 deletions(-)
rename Documentation/misc-devices/{c2port.txt => c2port.rst} (59%)Documentation/misc-devices/c2port.rst renamed from Documentation/misc-devices/c2port.txt +31 -27
@@ -1,7 +1,11 @@ - C2 port support - --------------- +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> -(C) Copyright 2007 Rodolfo Giometti <[email protected]> +=============== +C2 port support +=============== + +|copy| Copyright 2007 Rodolfo Giometti <[email protected]> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by
@@ -32,10 +36,10 @@ The C2 Interface main references are at (http://www.silabs.com) Silicon Laboratories site], see: - AN127: FLASH Programming via the C2 Interface at -http://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf + http://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf - C2 Specification at -http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults + http://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
Documentation/misc-devices/index.rst +1 -0
@@ -16,6 +16,7 @@ fit into other categories. ad525x_dpot eeprom + c2port ibmvmc ics932s401 isl29003
Signature · 1 line
2.24.1
PATCH v2 10/24 docs: misc-devices/bh1770glc.txt: convert to ReST
In reply to Mauro Carvalho Chehab- Adjust document title markup;
- use list markups;
- Adjust identations to display properly at ReST output.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../{bh1770glc.txt => bh1770glc.rst} | 45 +++++++++++++------
Documentation/misc-devices/index.rst | 1 +
2 files changed, 33 insertions(+), 13 deletions(-)
rename Documentation/misc-devices/{bh1770glc.txt => bh1770glc.rst} (83%)Documentation/misc-devices/bh1770glc.rst renamed from Documentation/misc-devices/bh1770glc.txt +32 -13
@@ -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
Documentation/misc-devices/index.rst +1 -0
@@ -15,6 +15,7 @@ fit into other categories. :maxdepth: 2 ad525x_dpot + bh1770glc eeprom c2port ibmvmc
Signature · 1 line
2.24.1
PATCH v2 11/24 docs: misc-devices/apds990x.txt: convert to ReST format
In reply to Mauro Carvalho Chehab- Adjust title markup;
- Adjust identation.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../{apds990x.txt => apds990x.rst} | 31 ++++++++++++++-----
Documentation/misc-devices/index.rst | 1 +
2 files changed, 25 insertions(+), 7 deletions(-)
rename Documentation/misc-devices/{apds990x.txt => apds990x.rst} (86%)Documentation/misc-devices/apds990x.rst renamed from Documentation/misc-devices/apds990x.txt +24 -7
@@ -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
Documentation/misc-devices/index.rst +1 -0
@@ -15,6 +15,7 @@ fit into other categories. :maxdepth: 2 ad525x_dpot + apds990x bh1770glc eeprom c2port
Signature · 1 line
2.24.1
PATCH v2 12/24 docs: pci: endpoint/function/binding/pci-test.txt convert to ReST
In reply to Mauro Carvalho ChehabConvert this file to ReST by adding a proper title to it and use the right markups for a table.
While here, add a SPDX header.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
--- .../endpoint/function/binding/pci-test.rst | 26 +++++++++++++++++++ .../endpoint/function/binding/pci-test.txt | 19 -------------- Documentation/PCI/endpoint/index.rst | 2 ++ 3 files changed, 28 insertions(+), 19 deletions(-) create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.rst delete mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt
Documentation/PCI/endpoint/function/binding/pci-test.rst new file +26 -0
@@ -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 +================ ===========================================================
Documentation/PCI/endpoint/function/binding/pci-test.txt deleted +0 -19
@@ -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
Documentation/PCI/endpoint/index.rst +2 -0
@@ -11,3 +11,5 @@ PCI Endpoint Framework pci-endpoint-cfs pci-test-function pci-test-howto + + function/binding/pci-test
Signature · 1 line
2.24.1
Re: [PATCH v2 12/24] docs: pci: endpoint/function/binding/pci-test.txt convert to ReST
Quoted 6 lines · Mauro Carvalho Chehab
Convert this file to ReST by adding a proper title to it and use the right markups for a table.
While here, add a SPDX header.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
FWIW,
Acked-by Bjorn Helgaas <[email protected]>
I assume you'll merge this, Jonathan. Let me know if I should do anything else with this.
Quoted 78 lines
--- .../endpoint/function/binding/pci-test.rst | 26 +++++++++++++++++++ .../endpoint/function/binding/pci-test.txt | 19 -------------- Documentation/PCI/endpoint/index.rst | 2 ++ 3 files changed, 28 insertions(+), 19 deletions(-) create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.rst delete mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txtDocumentation/PCI/endpoint/function/binding/pci-test.rst new file +26
-0@@ -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 +================ ===========================================================Documentation/PCI/endpoint/function/binding/pci-test.txt deleted +0
-19@@ -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 testDocumentation/PCI/endpoint/index.rst +2
-0@@ -11,3 +11,5 @@ PCI Endpoint Framework pci-endpoint-cfs pci-test-function pci-test-howto + + function/binding/pci-testSignature · 1 line
2.24.1
PATCH v2 13/24 docs: arm64: convert perf.txt to ReST format
In reply to Mauro Carvalho ChehabThis file is almost in ReST. All it needs is a rename and adding a :field: for the two fields at the beginning (author and date).
While here, add a proper SPDX header, and use the standard markup for document titles, just for consistency.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/arm64/index.rst | 1 +
Documentation/arm64/{perf.txt => perf.rst} | 7 +++++--
2 files changed, 6 insertions(+), 2 deletions(-)
rename Documentation/arm64/{perf.txt => perf.rst} (95%)Documentation/arm64/index.rst +1 -0
@@ -13,6 +13,7 @@ ARM64 Architecture hugetlbpage legacy_instructions memory + perf pointer-authentication silicon-errata sve
Documentation/arm64/perf.rst renamed from Documentation/arm64/perf.txt +5 -2
@@ -1,8 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== Perf Event Attributes ===================== -Author: Andrew Murray <[email protected]> -Date: 2019-03-06 +:Author: Andrew Murray <[email protected]> +:Date: 2019-03-06 exclude_user ------------
Signature · 1 line
2.24.1
Re: [PATCH v2 13/24] docs: arm64: convert perf.txt to ReST format
Quoted 7 lines · Mauro Carvalho Chehab
This file is almost in ReST. All it needs is a rename and adding a :field: for the two fields at the beginning (author and date).
While here, add a proper SPDX header, and use the standard markup for document titles, just for consistency.
Quoted 6 lines
Signed-off-by Mauro Carvalho Chehab <[email protected]>--- Documentation/arm64/index.rst | 1 + Documentation/arm64/{perf.txt => perf.rst} | 7 +++++-- 2 files changed, 6 insertions(+), 2 deletions(-) rename Documentation/arm64/{perf.txt => perf.rst} (95%)
Is there some reason this hasn't been merged or commented on?
Quoted 20 lines
Documentation/arm64/index.rst +1
-0@@ -13,6 +13,7 @@ ARM64 Architecture hugetlbpage legacy_instructions memory + perf pointer-authentication silicon-errata sveDocumentation/arm64/perf.rst renamed from Documentation/arm64/perf.txt +0
-0
Documentation/arm64/perf.rst line 8
Quoted 10 lines
Documentation/arm64/perf.rst renamed from Documentation/arm64/perf.txt +5
-2@@ -1,8 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== Perf Event Attributes ===================== -Author: Andrew Murray <[email protected]> -Date: 2019-03-06 +:Author: Andrew Murray <[email protected]> +:Date: 2019-03-06
Andrew is no long with Arm. Both lines look like things that become stale, so I'd just remove them.
Rob
PATCH v2 14/24 docs: cpu-freq: convert index.txt to ReST
In reply to Mauro Carvalho Chehabmost of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
--- Documentation/cpu-freq/index.rst | 35 ++++++++++++++++++++ Documentation/cpu-freq/index.txt | 56 -------------------------------- Documentation/index.rst | 1 + 3 files changed, 36 insertions(+), 56 deletions(-) create mode 100644 Documentation/cpu-freq/index.rst delete mode 100644 Documentation/cpu-freq/index.txt
Documentation/cpu-freq/index.rst new file +35 -0
@@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================================== +Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel +============================================================================== + +Author: Dominik Brodowski <[email protected]> + + Clock scaling allows you to change the clock speed of the CPUs on the + fly. This is a nice method to save battery power, because the lower + the clock speed, the less power the CPU consumes. + + +.. toctree:: + :maxdepth: 1 + +Mailing List +------------ +There is a CPU frequency changing CVS commit and general list where +you can report bugs, problems or submit patches. To post a message, +send an email to [email protected]. + +Links +----- +the FTP archives: +* ftp://ftp.linux.org.uk/pub/linux/cpufreq/ + +how to access the CVS repository: +* http://cvs.arm.linux.org.uk/ + +the CPUFreq Mailing list: +* http://vger.kernel.org/vger-lists.html#linux-pm + +Clock and voltage scaling for the SA-1100: +* http://www.lartmaker.nl/projects/scaling
Documentation/cpu-freq/index.txt deleted +0 -56
56 lines not on this page · raw message
Documentation/index.rst +1 -0
@@ -99,6 +99,7 @@ needed). accounting/index block/index cdrom/index + cpu-freq/index ide/index fb/index fpga/index
Signature · 1 line
2.24.1
Rafael J. Wysocki
maintainerRe: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
Quoted 5 lines · Mauro Carvalho Chehab
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
I see a very little value in converting the files in the cpu-freq directory from .txt to .rst, which I have told you at least twice.
They are just old-style driver API documents for cpufreq, but moving them under driver-api/ as they are would not be a good idea IMO, because at least some of them are outdated (note that the admin-guide part of the cpufreq documentation, in the .rst format, is located under admin-guide/).
I haven't had the time to write a proper replacement for them yet and honestly I find it quite obnoxious to see these reoccurring attempts to blindly convert them to .rst without taking care of their contents and location.
I will take care of these files at one point as promised, but that's not going to happen today or tomorrow and please just leave them alone if that is not a big deal.
Thanks!
Quoted 127 lines
Signed-off-by Mauro Carvalho Chehab <[email protected]>--- Documentation/cpu-freq/index.rst | 35 ++++++++++++++++++++ Documentation/cpu-freq/index.txt | 56 -------------------------------- Documentation/index.rst | 1 + 3 files changed, 36 insertions(+), 56 deletions(-) create mode 100644 Documentation/cpu-freq/index.rst delete mode 100644 Documentation/cpu-freq/index.txtDocumentation/cpu-freq/index.rst new file +35
-0@@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================================== +Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel +============================================================================== + +Author: Dominik Brodowski <[email protected]> + + Clock scaling allows you to change the clock speed of the CPUs on the + fly. This is a nice method to save battery power, because the lower + the clock speed, the less power the CPU consumes. + + +.. toctree:: + :maxdepth: 1 + +Mailing List +------------ +There is a CPU frequency changing CVS commit and general list where +you can report bugs, problems or submit patches. To post a message, +send an email to [email protected]. + +Links +----- +the FTP archives: +* ftp://ftp.linux.org.uk/pub/linux/cpufreq/ + +how to access the CVS repository: +* http://cvs.arm.linux.org.uk/ + +the CPUFreq Mailing list: +* http://vger.kernel.org/vger-lists.html#linux-pm + +Clock and voltage scaling for the SA-1100: +* http://www.lartmaker.nl/projects/scalingDocumentation/cpu-freq/index.txt deleted +0
-56@@ -1,56 +0,0 @@ - CPU frequency and voltage scaling code in the Linux(TM) kernel - - - L i n u x C P U F r e q - - - - - Dominik Brodowski <[email protected]> - - - - Clock scaling allows you to change the clock speed of the CPUs on the - fly. This is a nice method to save battery power, because the lower - the clock speed, the less power the CPU consumes. - - - -Documents in this directory: ----------------------------- - -amd-powernow.txt - AMD powernow driver specific file. - -core.txt - General description of the CPUFreq core and - of CPUFreq notifiers. - -cpu-drivers.txt - How to implement a new cpufreq processor driver. - -cpufreq-nforce2.txt - nVidia nForce2 platform specific file. - -cpufreq-stats.txt - General description of sysfs cpufreq stats. - -index.txt - File index, Mailing list and Links (this document) - -pcc-cpufreq.txt - PCC cpufreq driver specific file. - - -Mailing List ------------- -There is a CPU frequency changing CVS commit and general list where -you can report bugs, problems or submit patches. To post a message, -send an email to [email protected]. - -Links ------ -the FTP archives: -* ftp://ftp.linux.org.uk/pub/linux/cpufreq/ - -how to access the CVS repository: -* http://cvs.arm.linux.org.uk/ - -the CPUFreq Mailing list: -* http://vger.kernel.org/vger-lists.html#linux-pm - -Clock and voltage scaling for the SA-1100: -* http://www.lartmaker.nl/projects/scalingDocumentation/index.rst +1
-1@@ -99,6 +99,7 @@ needed). accounting/index block/index cdrom/index + cpu-freq/index ide/index fb/index fpga/index --2.24.1
Re: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
Hi Rafael,
Em Mon, 17 Feb 2020 21:06:20 +0100
"Rafael J. Wysocki" <[email protected]> escreveu:
Quoted 17 lines
Quoted 5 lines · Mauro Carvalho Chehab
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
I see a very little value in converting the files in the cpu-freq directory from .txt to .rst, which I have told you at least twice.
They are just old-style driver API documents for cpufreq, but moving them under driver-api/ as they are would not be a good idea IMO, because at least some of them are outdated (note that the admin-guide part of the cpufreq documentation, in the .rst format, is located under admin-guide/).
Quoted 8 lines
I haven't had the time to write a proper replacement for them yet and honestly I find it quite obnoxious to see these reoccurring attempts to blindly convert them to .rst without taking care of their contents and location.
I will take care of these files at one point as promised, but that's not going to happen today or tomorrow and please just leave them alone if that is not a big deal.
Sorry, I completely forgot that you asked to skip the old cpufreq docs. My bad!
The thing is that I have now fully converted all docs to ReST (with a handful exceptions for things that may not make sense to convert, like configuration files that ends with .txt).
As a matter of helping those (like me) that are trying to finish this huge conversion/reorganize task, I would very much prefer to keep those files converted somewhere (or trashed, if their contents is now completely garbage).
One of the things we discussed at linux-doc ML is to create a "staging" area where we can place:
- things that aren't ready to be at the main documentation body yet;
- too obsolete docs that may require major work;
- things that we didn't find a good place to put yet.
From the last discussions, it seems we reach a consensus about creating that.
So, I should be preparing a separate patchset adding a Documentation/staging dir.
Would it be OK for you if I change the cpufreq patches on this series to be moving those into a new Documentation/staging/cpufreq directory?
Regards,
Mauro
Rafael J. Wysocki
maintainerRe: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
Quoted 32 lines · Mauro Carvalho Chehab
Hi Rafael,
Em Mon, 17 Feb 2020 21:06:20 +0100
"Rafael J. Wysocki" <[email protected]> escreveu:Quoted 17 lines
Quoted 5 lines · Mauro Carvalho Chehab
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
I see a very little value in converting the files in the cpu-freq directory from .txt to .rst, which I have told you at least twice.
They are just old-style driver API documents for cpufreq, but moving them under driver-api/ as they are would not be a good idea IMO, because at least some of them are outdated (note that the admin-guide part of the cpufreq documentation, in the .rst format, is located under admin-guide/).
Quoted 8 lines
I haven't had the time to write a proper replacement for them yet and honestly I find it quite obnoxious to see these reoccurring attempts to blindly convert them to .rst without taking care of their contents and location.
I will take care of these files at one point as promised, but that's not going to happen today or tomorrow and please just leave them alone if that is not a big deal.
Quoted 6 lines
Sorry, I completely forgot that you asked to skip the old cpufreq docs. My bad!
The thing is that I have now fully converted all docs to ReST (with a handful exceptions for things that may not make sense to convert, like configuration files that ends with .txt).
And I have this patch:
https://patchwork.kernel.org/patch/11411035/
so at least please drop the commits converting the three files affected by it.
Quoted 5 lines
As a matter of helping those (like me) that are trying to finish this huge conversion/reorganize task, I would very much prefer to keep those files converted somewhere (or trashed, if their contents is now completely garbage).
Quoted 8 lines
One of the things we discussed at linux-doc ML is to create a "staging" area where we can place:
- things that aren't ready to be at the main documentation body yet;
- too obsolete docs that may require major work;
- things that we didn't find a good place to put yet.From the last discussions, it seems we reach a consensus about creating that.
So the other files in Documentation/cpu-freq/ can be converted to .rst as far as I'm concerned (even though I still don't see much value in doing that, just for the record).
They will be going away anyway in the future, regardless of the format in which they are at that time. :-)
Cheers!
Jonathan Corbet
maintainerRe: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
In reply to Mauro Carvalho ChehabQuoted 6 lines · On Mon, 17 Feb 2020 17:20:32 +0100 Mauro Carvalho Chehab…
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
Rafael, do you want to carry the cpu-freq changes from this set, or should I just apply the whole thing over here?
Thanks,
jon
Rafael J. Wysocki
maintainerRe: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
Quoted 9 lines · Jonathan Corbet
Quoted 5 lines · On Mon, 17 Feb 2020 17:20:32 +0100 Mauro Carvalho Chehab…
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
Quoted 4 lines
Quoted 1 line
Signed-off-by Mauro Carvalho Chehab <[email protected]>Rafael, do you want to carry the cpu-freq changes from this set, or should I just apply the whole thing over here?
I will take the ones that are applicable after rebasing on top of
https://patchwork.kernel.org/patch/11411035/
Cheers!
Re: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
Em Mon, 2 Mar 2020 23:16:10 +0100
"Rafael J. Wysocki" <[email protected]> escreveu:
Quoted 10 lines · Jonathan Corbet
Quoted 9 lines
Quoted 5 lines · On Mon, 17 Feb 2020 17:20:32 +0100 Mauro Carvalho Chehab…
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Mauro Carvalho Chehab <[email protected]>Rafael, do you want to carry the cpu-freq changes from this set, or should I just apply the whole thing over here?
I will take the ones that are applicable after rebasing on top of
https://patchwork.kernel.org/patch/11411035/
Just rebased on the top of it (plus next-20200303) and sent.
Btw, patch 1/5 of such series is just a small fix for the above. It addresses a Kconfig.x86 pointer to a documentation file that were moved by the above patch.
Feel free to merge it with patch #11411035 if you want.
Regards,
Mauro
Re: [PATCH v2 14/24] docs: cpu-freq: convert index.txt to ReST
In reply to Jonathan CorbetEm Mon, 2 Mar 2020 14:19:16 -0700
Jonathan Corbet <[email protected]> escreveu:
Quoted 8 lines
Quoted 5 lines · On Mon, 17 Feb 2020 17:20:32 +0100 Mauro Carvalho Chehab…
most of the stuff there can be re-used with ReST format, but we need to add an empty TOC and remove the existing entries, as the following conversion patches will be re-adding them, as they're converted.
Quoted 4 lines
Quoted 1 line
Signed-off-by Mauro Carvalho Chehab <[email protected]>Rafael, do you want to carry the cpu-freq changes from this set, or should I just apply the whole thing over here?
Hi Jon,
As Rafael should be applying the cpu-freq via his tree, I'm re-sending the remaining patches on this series as:
[PATCH v3 00/18] Manually convert thermal, crypto and misc devices to ReST
Regards,
Mauro
PATCH v2 15/24 docs: cpu-freq: convert amd-powernow.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Add a document title, based on the original contents of cpu-freq/index.txt;
- some whitespace fixes and new line breaks;
- Add it to cpu-freq/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../cpu-freq/{amd-powernow.txt => amd-powernow.rst} | 12 ++++++++++--
Documentation/cpu-freq/index.rst | 2 ++
2 files changed, 12 insertions(+), 2 deletions(-)
rename Documentation/cpu-freq/{amd-powernow.txt => amd-powernow.rst} (89%)Documentation/cpu-freq/amd-powernow.rst renamed from Documentation/cpu-freq/amd-powernow.txt +10 -2
@@ -1,3 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +AMD PowerNow Driver Specifics +============================= + PowerNow! and Cool'n'Quiet are AMD names for frequency management capabilities in AMD processors. As the hardware
@@ -23,16 +29,18 @@ not supply these tables. 7th Generation: powernow-k7: Athlon, Duron, Geode. 8th Generation: powernow-k8: Athlon, Athlon 64, Opteron, Sempron. + Documentation on this functionality in 8th generation processors is available in the "BIOS and Kernel Developer's Guide", publication -26094, in chapter 9, available for download from www.amd.com. +26094, in chapter 9, available for download from www.amd.com. BIOS supplied data, for powernow-k7 and for powernow-k8, may be from either the PSB table or from ACPI objects. The ACPI support is only available if the kernel config sets CONFIG_ACPI_PROCESSOR. The powernow-k8 driver will attempt to use ACPI if so configured, and fall back to PST if that fails. + The powernow-k7 driver will try to use the PSB support first, and fall back to ACPI if the PSB support fails. A module parameter, -acpi_force, is provided to force ACPI support to be used instead +acpi_force, is provided to force ACPI support to be used instead of PSB support.
Documentation/cpu-freq/index.rst +2 -0
@@ -14,6 +14,8 @@ Author: Dominik Brodowski <[email protected]> .. toctree:: :maxdepth: 1 + amd-powernow + Mailing List ------------ There is a CPU frequency changing CVS commit and general list where
Signature · 1 line
2.24.1
PATCH v2 16/24 docs: cpu-freq: convert core.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Adjust the document title, based on the original contents of cpu-freq/index.txt;
- Use lists where needed;
- Comment out the existing text-only index;
- use ``foo`` to mark a literal expression with asterisk;
- Adjust some title marks;
- Add table markups;
- Add notes markups;
- Some whitespace fixes and new line breaks;
- Add it to cpu-freq/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/cpu-freq/{core.txt => core.rst} | 65 ++++++++++---------
Documentation/cpu-freq/index.rst | 1 +
2 files changed, 34 insertions(+), 32 deletions(-)
rename Documentation/cpu-freq/{core.txt => core.rst} (69%)Documentation/cpu-freq/core.rst renamed from Documentation/cpu-freq/core.txt +33 -32
@@ -1,31 +1,23 @@ - CPU frequency and voltage scaling code in the Linux(TM) kernel +.. SPDX-License-Identifier: GPL-2.0 +============================================================= +General description of the CPUFreq core and CPUFreq notifiers +============================================================= - L i n u x C P U F r e q +Authors: + - Dominik Brodowski <[email protected]> + - David Kimdon <[email protected]> + - Rafael J. Wysocki <[email protected]> + - Viresh Kumar <[email protected]> - C P U F r e q C o r e +.. Contents: - - Dominik Brodowski <[email protected]> - David Kimdon <[email protected]> - Rafael J. Wysocki <[email protected]> - Viresh Kumar <[email protected]> - - - - Clock scaling allows you to change the clock speed of the CPUs on the - fly. This is a nice method to save battery power, because the lower - the clock speed, the less power the CPU consumes. - - -Contents: ---------- -1. CPUFreq core and interfaces -2. CPUFreq notifiers -3. CPUFreq Table Generation with Operating Performance Point (OPP) + 1. CPUFreq core and interfaces + 2. CPUFreq notifiers + 3. CPUFreq Table Generation with Operating Performance Point (OPP) 1. General Information -======================= +====================== The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This cpufreq code offers a standardized interface for the CPUFreq
@@ -63,7 +55,7 @@ The phase is specified in the second argument to the notifier. The phase is CPUFREQ_CREATE_POLICY when the policy is first created and it is CPUFREQ_REMOVE_POLICY when the policy is removed. -The third argument, a void *pointer, points to a struct cpufreq_policy +The third argument, a ``void *pointer``, points to a struct cpufreq_policy consisting of several values, including min, max (the lower and upper frequencies (in kHz) of the new policy).
@@ -80,10 +72,13 @@ CPUFREQ_POSTCHANGE. The third argument is a struct cpufreq_freqs with the following values: -cpu - number of the affected CPU -old - old frequency -new - new frequency -flags - flags of the cpufreq driver + +===== =========================== +cpu number of the affected CPU +old old frequency +new new frequency +flags flags of the cpufreq driver +===== =========================== 3. CPUFreq Table Generation with Operating Performance Point (OPP) ==================================================================
@@ -94,9 +89,12 @@ dev_pm_opp_init_cpufreq_table - the OPP layer's internal information about the available frequencies into a format readily providable to cpufreq. - WARNING: Do not use this function in interrupt context. + .. Warning:: + + Do not use this function in interrupt context. + + Example:: - Example: soc_pm_init() { /* Do things */
@@ -106,7 +104,10 @@ dev_pm_opp_init_cpufreq_table - /* Do other things */ } - NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in - addition to CONFIG_PM_OPP. + .. note:: -dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table + This function is available only if CONFIG_CPU_FREQ is enabled in + addition to CONFIG_PM_OPP. + +dev_pm_opp_free_cpufreq_table + Free up the table allocated by dev_pm_opp_init_cpufreq_table
Documentation/cpu-freq/index.rst +1 -0
@@ -15,6 +15,7 @@ Author: Dominik Brodowski <[email protected]> :maxdepth: 1 amd-powernow + core Mailing List ------------
Signature · 1 line
2.24.1
PATCH v2 17/24 docs: cpu-freq: convert cpu-drivers.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Add a document title, based on the original contents of cpu-freq/index.txt;
- Use lists where needed;
- Comment out the existing text-only index;
- Adjust some title marks;
- Add table markups;
- Add notes markups;
- Mark literal blocks as such;
- use ``foo`` for literal texts;
- Some whitespace fixes and new line breaks;
- Add it to cpu-freq/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../{cpu-drivers.txt => cpu-drivers.rst} | 129 +++++++++---------
Documentation/cpu-freq/index.rst | 1 +
2 files changed, 64 insertions(+), 66 deletions(-)
rename Documentation/cpu-freq/{cpu-drivers.txt => cpu-drivers.rst} (72%)Documentation/cpu-freq/cpu-drivers.rst renamed from Documentation/cpu-freq/cpu-drivers.txt +63 -66
@@ -1,35 +1,27 @@ - CPU frequency and voltage scaling code in the Linux(TM) kernel +.. SPDX-License-Identifier: GPL-2.0 +=============================================== +How to Implement a new CPUFreq Processor Driver +=============================================== - L i n u x C P U F r e q +Authors: - C P U D r i v e r s - - information for developers - + - Dominik Brodowski <[email protected]> + - Rafael J. Wysocki <[email protected]> + - Viresh Kumar <[email protected]> +.. Contents - Dominik Brodowski <[email protected]> - Rafael J. Wysocki <[email protected]> - Viresh Kumar <[email protected]> - - - - Clock scaling allows you to change the clock speed of the CPUs on the - fly. This is a nice method to save battery power, because the lower - the clock speed, the less power the CPU consumes. - - -Contents: ---------- -1. What To Do? -1.1 Initialization -1.2 Per-CPU Initialization -1.3 verify -1.4 target/target_index or setpolicy? -1.5 target/target_index -1.6 setpolicy -1.7 get_intermediate and target_intermediate -2. Frequency Table Helpers + 1. What To Do? + 1.1 Initialization + 1.2 Per-CPU Initialization + 1.3 verify + 1.4 target/target_index or setpolicy? + 1.5 target/target_index + 1.6 setpolicy + 1.7 get_intermediate and target_intermediate + 2. Frequency Table Helpers
@@ -49,7 +41,7 @@ function check whether this kernel runs on the right CPU and the right chipset. If so, register a struct cpufreq_driver with the CPUfreq core using cpufreq_register_driver() -What shall this struct cpufreq_driver contain? +What shall this struct cpufreq_driver contain? .name - The name of this driver.
@@ -108,37 +100,42 @@ Whenever a new CPU is registered with the device model, or after the cpufreq driver registers itself, the per-policy initialization function cpufreq_driver.init is called if no cpufreq policy existed for the CPU. Note that the .init() and .exit() routines are called only once for the -policy and not for each CPU managed by the policy. It takes a struct -cpufreq_policy *policy as argument. What to do now? +policy and not for each CPU managed by the policy. It takes a ``struct +cpufreq_policy *policy`` as argument. What to do now? If necessary, activate the CPUfreq support on your CPU. Then, the driver must fill in the following values: -policy->cpuinfo.min_freq _and_ -policy->cpuinfo.max_freq - the minimum and maximum frequency - (in kHz) which is supported by - this CPU -policy->cpuinfo.transition_latency the time it takes on this CPU to - switch between two frequencies in - nanoseconds (if appropriate, else - specify CPUFREQ_ETERNAL) - -policy->cur The current operating frequency of - this CPU (if appropriate) -policy->min, -policy->max, -policy->policy and, if necessary, -policy->governor must contain the "default policy" for - this CPU. A few moments later, - cpufreq_driver.verify and either - cpufreq_driver.setpolicy or - cpufreq_driver.target/target_index is called - with these values. -policy->cpus Update this with the masks of the - (online + offline) CPUs that do DVFS - along with this CPU (i.e. that share - clock/voltage rails with it). ++-----------------------------------+--------------------------------------+ +|policy->cpuinfo.min_freq _and_ | | +|policy->cpuinfo.max_freq | the minimum and maximum frequency | +| | (in kHz) which is supported by | +| | this CPU | ++-----------------------------------+--------------------------------------+ +|policy->cpuinfo.transition_latency | the time it takes on this CPU to | +| | switch between two frequencies in | +| | nanoseconds (if appropriate, else | +| | specify CPUFREQ_ETERNAL) | ++-----------------------------------+--------------------------------------+ +|policy->cur | The current operating frequency of | +| | this CPU (if appropriate) | ++-----------------------------------+--------------------------------------+ +|policy->min, | | +|policy->max, | | +|policy->policy and, if necessary, | | +|policy->governor | must contain the "default policy" for| +| | this CPU. A few moments later, | +| | cpufreq_driver.verify and either | +| | cpufreq_driver.setpolicy or | +| | cpufreq_driver.target/target_index is| +| | called with these values. | ++-----------------------------------+--------------------------------------+ +|policy->cpus | Update this with the masks of the | +| | (online + offline) CPUs that do DVFS | +| | along with this CPU (i.e. that share| +| | clock/voltage rails with it). | ++-----------------------------------+--------------------------------------+ For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the frequency table helpers might be helpful. See the section 2 for more information
@@ -151,8 +148,8 @@ on them. When the user decides a new policy (consisting of "policy,governor,min,max") shall be set, this policy must be validated so that incompatible values can be corrected. For verifying these -values cpufreq_verify_within_limits(struct cpufreq_policy *policy, -unsigned int min_freq, unsigned int max_freq) function might be helpful. +values cpufreq_verify_within_limits(``struct cpufreq_policy *policy``, +``unsigned int min_freq``, ``unsigned int max_freq``) function might be helpful. See section 2 for details on frequency table helpers. You need to make sure that at least one valid frequency (or operating
@@ -163,7 +160,7 @@ policy->max first, and only if this is no solution, decrease policy->min. 1.4 target or target_index or setpolicy or fast_switch? ------------------------------------------------------- -Most cpufreq drivers or even most cpu frequency scaling algorithms +Most cpufreq drivers or even most cpu frequency scaling algorithms only allow the CPU frequency to be set to predefined fixed values. For these, you use the ->target(), ->target_index() or ->fast_switch() callbacks.
@@ -175,8 +172,8 @@ limits on their own. These shall use the ->setpolicy() callback. 1.5. target/target_index ------------------------ -The target_index call has two arguments: struct cpufreq_policy *policy, -and unsigned int index (into the exposed frequency table). +The target_index call has two arguments: ``struct cpufreq_policy *policy``, +and ``unsigned int`` index (into the exposed frequency table). The CPUfreq driver must set the new frequency when called here. The actual frequency must be determined by freq_table[index].frequency.
@@ -184,9 +181,9 @@ actual frequency must be determined by freq_table[index].frequency. It should always restore to earlier frequency (i.e. policy->restore_freq) in case of errors, even if we switched to intermediate frequency earlier. -Deprecated: +Deprecated ---------- -The target call has three arguments: struct cpufreq_policy *policy, +The target call has three arguments: ``struct cpufreq_policy *policy``, unsigned int target_frequency, unsigned int relation. The CPUfreq driver must set the new frequency when called here. The
@@ -210,14 +207,14 @@ Not all drivers are expected to implement it, as sleeping from within this callback isn't allowed. This callback must be highly optimized to do switching as fast as possible. -This function has two arguments: struct cpufreq_policy *policy and -unsigned int target_frequency. +This function has two arguments: ``struct cpufreq_policy *policy`` and +``unsigned int target_frequency``. 1.7 setpolicy ------------- -The setpolicy call only takes a struct cpufreq_policy *policy as +The setpolicy call only takes a ``struct cpufreq_policy *policy`` as argument. You need to set the lower limit of the in-processor or in-chipset dynamic frequency switching to policy->min, the upper limit to policy->max, and -if supported- select a performance-oriented
@@ -278,10 +275,10 @@ table. cpufreq_for_each_valid_entry(pos, table) - iterates over all entries, excluding CPUFREQ_ENTRY_INVALID frequencies. -Use arguments "pos" - a cpufreq_frequency_table * as a loop cursor and -"table" - the cpufreq_frequency_table * you want to iterate over. +Use arguments "pos" - a ``cpufreq_frequency_table *`` as a loop cursor and +"table" - the ``cpufreq_frequency_table *`` you want to iterate over. -For example: +For example:: struct cpufreq_frequency_table *pos, *driver_freq_table;
Documentation/cpu-freq/index.rst +1 -0
@@ -16,6 +16,7 @@ Author: Dominik Brodowski <[email protected]> amd-powernow core + cpu-drivers Mailing List ------------
Signature · 1 line
2.24.1
PATCH v2 18/24 docs: cpu-freq: convert cpufreq-nforce2.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Add a document title, based on the original contents of cpu-freq/index.txt;
- Add table markups;
- Add notes markups;
- Add it to cpu-freq/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
...cpufreq-nforce2.txt => cpufreq-nforce2.rst} | 18 ++++++++++++++----
Documentation/cpu-freq/index.rst | 1 +
2 files changed, 15 insertions(+), 4 deletions(-)
rename Documentation/cpu-freq/{cpufreq-nforce2.txt => cpufreq-nforce2.rst} (55%)Documentation/cpu-freq/cpufreq-nforce2.rst renamed from Documentation/cpu-freq/cpufreq-nforce2.txt +14 -4
@@ -1,3 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +nVidia nForce2 Platform Specifics +================================= The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
@@ -6,14 +11,19 @@ can be controlled independently from the PCI/AGP clock. The module has two options: - fid: multiplier * 10 (for example 8.5 = 85) - min_fsb: minimum FSB + ======= ====================================== + fid multiplier * 10 (for example 8.5 = 85) + min_fsb minimum FSB + ======= ====================================== If not set, fid is calculated from the current CPU speed and the FSB. min_fsb defaults to FSB at boot time - 50 MHz. -IMPORTANT: The available range is limited downwards! - Also the minimum available FSB can differ, for systems +.. Important:: + + The available range is limited downwards! + + Also the minimum available FSB can differ, for systems booting with 200 MHz, 150 should always work.
Documentation/cpu-freq/index.rst +1 -0
@@ -17,6 +17,7 @@ Author: Dominik Brodowski <[email protected]> amd-powernow core cpu-drivers + cpufreq-nforce2 Mailing List ------------
Signature · 1 line
2.24.1
PATCH v2 19/24 docs: cpu-freq: convert cpufreq-stats.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Add a document title, based on the original contents of cpu-freq/index.txt;
- Use lists where needed;
- Comment out the existing text-only index;
- Adjust some title marks;
- Use bold on some places;
- Mark literal blocks as such;
- Some whitespace fixes and new line breaks;
- Add it to cpu-freq/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
.../{cpufreq-stats.txt => cpufreq-stats.rst} | 121 ++++++++++--------
Documentation/cpu-freq/index.rst | 1 +
2 files changed, 66 insertions(+), 56 deletions(-)
rename Documentation/cpu-freq/{cpufreq-stats.txt => cpufreq-stats.rst} (53%)Documentation/cpu-freq/cpufreq-stats.rst renamed from Documentation/cpu-freq/cpufreq-stats.txt +65 -56
@@ -1,21 +1,23 @@ +.. SPDX-License-Identifier: GPL-2.0 - CPU frequency and voltage scaling statistics in the Linux(TM) kernel +========================================== +General Description of sysfs CPUFreq Stats +========================================== +information for users - L i n u x c p u f r e q - s t a t s d r i v e r - - information for users - +Author: Venkatesh Pallipadi <[email protected]> +.. Contents - Venkatesh Pallipadi <[email protected]> - -Contents -1. Introduction -2. Statistics Provided (with example) -3. Configuring cpufreq-stats + 1. Introduction + 2. Statistics Provided (with example) + 3. Configuring cpufreq-stats 1. Introduction +=============== cpufreq-stats is a driver that provides CPU frequency statistics for each CPU. These statistics are provided in /sysfs as a bunch of read_only interfaces. This
@@ -28,8 +30,10 @@ that may be running on your CPU. So, it will work with any cpufreq_driver. 2. Statistics Provided (with example) +===================================== cpufreq stats provides following statistics (explained in detail below). + - time_in_state - total_trans - trans_table
@@ -39,53 +43,57 @@ All the statistics will be from the time the stats driver has been inserted statistic is done. Obviously, stats driver will not have any information about the frequency transitions before the stats driver insertion. --------------------------------------------------------------------------------- -<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l -total 0 -drwxr-xr-x 2 root root 0 May 14 16:06 . -drwxr-xr-x 3 root root 0 May 14 15:58 .. ---w------- 1 root root 4096 May 14 16:06 reset --r--r--r-- 1 root root 4096 May 14 16:06 time_in_state --r--r--r-- 1 root root 4096 May 14 16:06 total_trans --r--r--r-- 1 root root 4096 May 14 16:06 trans_table --------------------------------------------------------------------------------- +:: + + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l + total 0 + drwxr-xr-x 2 root root 0 May 14 16:06 . + drwxr-xr-x 3 root root 0 May 14 15:58 .. + --w------- 1 root root 4096 May 14 16:06 reset + -r--r--r-- 1 root root 4096 May 14 16:06 time_in_state + -r--r--r-- 1 root root 4096 May 14 16:06 total_trans + -r--r--r-- 1 root root 4096 May 14 16:06 trans_table + +- **reset** -- reset Write-only attribute that can be used to reset the stat counters. This can be useful for evaluating system behaviour under different governors without the need for a reboot. -- time_in_state +- **time_in_state** + This gives the amount of time spent in each of the frequencies supported by this CPU. The cat output will have "<frequency> <time>" pair in each line, which will mean this CPU spent <time> usertime units of time at <frequency>. Output -will have one line for each of the supported frequencies. usertime units here +will have one line for each of the supported frequencies. usertime units here is 10mS (similar to other time exported in /proc). --------------------------------------------------------------------------------- -<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state -3600000 2089 -3400000 136 -3200000 34 -3000000 67 -2800000 172488 --------------------------------------------------------------------------------- - - -- total_trans -This gives the total number of frequency transitions on this CPU. The cat +:: + + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state + 3600000 2089 + 3400000 136 + 3200000 34 + 3000000 67 + 2800000 172488 + + +- **total_trans** + +This gives the total number of frequency transitions on this CPU. The cat output will have a single count which is the total number of frequency transitions. --------------------------------------------------------------------------------- -<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans -20 --------------------------------------------------------------------------------- +:: + + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans + 20 + +- **trans_table** -- trans_table This will give a fine grained information about all the CPU frequency transitions. The cat output here is a two dimensional matrix, where an entry -<i,j> (row i, column j) represents the count of number of transitions from +<i,j> (row i, column j) represents the count of number of transitions from Freq_i to Freq_j. Freq_i rows and Freq_j columns follow the sorting order in which the driver has provided the frequency table initially to the cpufreq core and so can be sorted (ascending or descending) or unsorted. The output here
@@ -95,26 +103,27 @@ readability. If the transition table is bigger than PAGE_SIZE, reading this will return an -EFBIG error. --------------------------------------------------------------------------------- -<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table - From : To - : 3600000 3400000 3200000 3000000 2800000 - 3600000: 0 5 0 0 0 - 3400000: 4 0 2 0 0 - 3200000: 0 1 0 2 0 - 3000000: 0 0 1 0 3 - 2800000: 0 0 0 2 0 --------------------------------------------------------------------------------- +:: + <mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table + From : To + : 3600000 3400000 3200000 3000000 2800000 + 3600000: 0 5 0 0 0 + 3400000: 4 0 2 0 0 + 3200000: 0 1 0 2 0 + 3000000: 0 0 1 0 3 + 2800000: 0 0 0 2 0 3. Configuring cpufreq-stats +============================ -To configure cpufreq-stats in your kernel -Config Main Menu - Power management options (ACPI, APM) ---> - CPU Frequency scaling ---> - [*] CPU Frequency scaling - [*] CPU frequency translation statistics +To configure cpufreq-stats in your kernel:: + + Config Main Menu + Power management options (ACPI, APM) ---> + CPU Frequency scaling ---> + [*] CPU Frequency scaling + [*] CPU frequency translation statistics "CPU Frequency scaling" (CONFIG_CPU_FREQ) should be enabled to configure
Documentation/cpu-freq/index.rst +1 -0
@@ -18,6 +18,7 @@ Author: Dominik Brodowski <[email protected]> core cpu-drivers cpufreq-nforce2 + cpufreq-stats Mailing List ------------
Signature · 1 line
2.24.1
PATCH v2 20/24 docs: cpu-freq: convert pcc-cpufreq.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Add a document title, based on the original contents of cpu-freq/index.txt;
- Add copyright symbol;
- Remove a c-like comment, adding the useful info not covered by the SPDX and document title headers as text;
- Comment out the existing text-only index;
- Mark literal blocks as such;
- Some whitespace fixes and new line breaks;
- Add it to cpu-freq/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/cpu-freq/index.rst | 1 +
.../{pcc-cpufreq.txt => pcc-cpufreq.rst} | 86 ++++++++-----------
2 files changed, 38 insertions(+), 49 deletions(-)
rename Documentation/cpu-freq/{pcc-cpufreq.txt => pcc-cpufreq.rst} (80%)Documentation/cpu-freq/index.rst +1 -0
@@ -19,6 +19,7 @@ Author: Dominik Brodowski <[email protected]> cpu-drivers cpufreq-nforce2 cpufreq-stats + pcc-cpufreq Mailing List ------------
Documentation/cpu-freq/pcc-cpufreq.rst renamed from Documentation/cpu-freq/pcc-cpufreq.txt +37 -49
118 lines not on this page · raw message
Signature · 1 line
2.24.1
PATCH v2 21/24 docs: powerpc: convert vcpudispatch_stats.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Use standard markup for document title;
- Adjust identation on lists and add blank lines where needed;
- Add it to the powerpc index.rst file.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/powerpc/index.rst | 1 +
...ispatch_stats.txt => vcpudispatch_stats.rst} | 17 ++++++++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
rename Documentation/powerpc/{vcpudispatch_stats.txt => vcpudispatch_stats.rst} (94%)Documentation/powerpc/index.rst +1 -0
@@ -30,6 +30,7 @@ powerpc syscall64-abi transactional_memory ultravisor + vcpudispatch_stats .. only:: subproject and html
Documentation/powerpc/vcpudispatch_stats.rst renamed from Documentation/powerpc/vcpudispatch_stats.txt +12 -5
@@ -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
Signature · 1 line
2.24.1
PATCH v2 22/24 docs: sh: convert new-machine.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Adjust document title to follow ReST style;
- Mark literal blocks as such;
- Mark a table as such;
- Add it to sh/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/sh/index.rst | 5 +
.../sh/{new-machine.txt => new-machine.rst} | 193 +++++++++---------
2 files changed, 105 insertions(+), 93 deletions(-)
rename Documentation/sh/{new-machine.txt => new-machine.rst} (73%)Documentation/sh/index.rst +5 -0
@@ -4,6 +4,11 @@ SuperH Interfaces Guide :Author: Paul Mundt +.. toctree:: + :maxdepth: 1 + + new-machine + Memory Management ========
Documentation/sh/new-machine.rst renamed from Documentation/sh/new-machine.txt +98 -93
257 lines not on this page · raw message
Signature · 1 line
2.24.1
PATCH v2 23/24 docs: sh: convert register-banks.txt to ReST
In reply to Mauro Carvalho Chehab- Add a SPDX header;
- Adjust document title to follow ReST style;
- Add blank lines to make ReST markup happy
- Add it to sh/index.rst.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/sh/index.rst | 1 +
.../sh/{register-banks.txt => register-banks.rst} | 12 ++++++++++--
2 files changed, 11 insertions(+), 2 deletions(-)
rename Documentation/sh/{register-banks.txt => register-banks.rst} (88%)Documentation/sh/index.rst +1 -0
@@ -8,6 +8,7 @@ SuperH Interfaces Guide :maxdepth: 1 new-machine + register-banks Memory Management ========diff --git a/Documentation/sh/register-banks.txt b/Documentation/sh/register-banks.rst
similarity index 88%
rename from Documentation/sh/register-banks.txt
rename to Documentation/sh/register-banks.rst
index a6719f2f6594..2f51212043f4 100644
Documentation/sh/register-banks.rst renamed from Documentation/sh/register-banks.txt +10 -2
@@ -1,5 +1,8 @@ - Notes on register bank usage in the kernel - ===================== +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Notes on register bank usage in the kernel +===================== Introduction ------------
@@ -23,11 +26,16 @@ Presently the kernel uses several of these registers. - r0_bank, r1_bank (referenced as k0 and k1, used for scratch registers when doing exception handling). + - r2_bank (used to track the EXPEVT/INTEVT code) + - Used by do_IRQ() and friends for doing irq mapping based off of the interrupt exception vector jump table offset + - r6_bank (global interrupt mask) + - The SR.IMASK interrupt handler makes use of this to set the interrupt priority level (used by local_irq_enable()) + - r7_bank (current)
Signature · 1 line
2.24.1
PATCH v2 24/24 docs: trace: ring-buffer-design.txt: convert to ReST format
In reply to Mauro Carvalho Chehab- Just like some media documents, this file is dual licensed with GPL and GFDL. As right now the GFDL SPDX definition is bogus (as it doesn't tell anything about invariant parts), let's not use SPDX here. Let's use, instead, the same test as we have on media.
- Convert title to ReST format;
- use :field: markup;
- Proper mark literal blocks as such;
- Add it to trace/index.rst file.
Signed-off-by Mauro Carvalho Chehab <[email protected]>
---
Documentation/trace/index.rst | 1 +
...ffer-design.txt => ring-buffer-design.rst} | 802 ++++++++++--------
2 files changed, 428 insertions(+), 375 deletions(-)
rename Documentation/trace/{ring-buffer-design.txt => ring-buffer-design.rst} (55%)Documentation/trace/index.rst +1 -0
@@ -22,6 +22,7 @@ Linux Tracing Technologies boottime-trace hwlat_detector intel_th + ring-buffer-design stm sys-t coresight/index
Documentation/trace/ring-buffer-design.rst renamed from Documentation/trace/ring-buffer-design.txt +427 -375
1,094 lines not on this page · raw message
Signature · 1 line
2.24.1