Commit b51594df authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'docs-5.9-3' of git://git.lwn.net/linux

Pull documentation fixes from Jonathan Corbet:
 "A handful of documentation fixes for 5.9"

* tag 'docs-5.9-3' of git://git.lwn.net/linux:
  Documentation: laptops: thinkpad-acpi: fix underline length build warning
  Documentation: fix typo for abituguru documentation
  docs: Fix function name trailing double-()s
  devices.txt: fix typo of "ubd" as "udb"
  Documentation: add riscv entry in list of existing profiles
  MAINTAINERS: mention documentation maintainer entry profile
  Fpga: Documentation: Replace deprecated :c:func: Usage
  IIO: Documentation: Replace deprecated :c:func: Usage
  Documentation/locking/locktypes: fix local_locks documentation
parents 59815d6d 92001bc0
...@@ -49,7 +49,7 @@ checking of rcu_dereference() primitives: ...@@ -49,7 +49,7 @@ checking of rcu_dereference() primitives:
is invoked by both RCU-sched readers and updaters. is invoked by both RCU-sched readers and updaters.
srcu_dereference_check(p, c): srcu_dereference_check(p, c):
Use explicit check expression "c" along with Use explicit check expression "c" along with
srcu_read_lock_held()(). This is useful in code that srcu_read_lock_held(). This is useful in code that
is invoked by both SRCU readers and updaters. is invoked by both SRCU readers and updaters.
rcu_dereference_raw(p): rcu_dereference_raw(p):
Don't check. (Use sparingly, if at all.) Don't check. (Use sparingly, if at all.)
......
...@@ -1662,7 +1662,7 @@ ...@@ -1662,7 +1662,7 @@
98 block User-mode virtual block device 98 block User-mode virtual block device
0 = /dev/ubda First user-mode block device 0 = /dev/ubda First user-mode block device
16 = /dev/udbb Second user-mode block device 16 = /dev/ubdb Second user-mode block device
... ...
Partitions are handled in the same way as for IDE Partitions are handled in the same way as for IDE
......
...@@ -1434,7 +1434,7 @@ on the feature, restricting the viewing angles. ...@@ -1434,7 +1434,7 @@ on the feature, restricting the viewing angles.
DYTC Lapmode sensor DYTC Lapmode sensor
------------------ -------------------
sysfs: dytc_lapmode sysfs: dytc_lapmode
......
...@@ -6,9 +6,9 @@ API to implement a new FPGA bridge ...@@ -6,9 +6,9 @@ API to implement a new FPGA bridge
* struct :c:type:`fpga_bridge` — The FPGA Bridge structure * struct :c:type:`fpga_bridge` — The FPGA Bridge structure
* struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops * struct :c:type:`fpga_bridge_ops` — Low level Bridge driver ops
* :c:func:`devm_fpga_bridge_create()` — Allocate and init a bridge struct * devm_fpga_bridge_create() — Allocate and init a bridge struct
* :c:func:`fpga_bridge_register()` — Register a bridge * fpga_bridge_register() — Register a bridge
* :c:func:`fpga_bridge_unregister()` — Unregister a bridge * fpga_bridge_unregister() — Unregister a bridge
.. kernel-doc:: include/linux/fpga/fpga-bridge.h .. kernel-doc:: include/linux/fpga/fpga-bridge.h
:functions: fpga_bridge :functions: fpga_bridge
......
...@@ -104,9 +104,9 @@ API for implementing a new FPGA Manager driver ...@@ -104,9 +104,9 @@ API for implementing a new FPGA Manager driver
* ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`. * ``fpga_mgr_states`` — Values for :c:member:`fpga_manager->state`.
* struct :c:type:`fpga_manager` — the FPGA manager struct * struct :c:type:`fpga_manager` — the FPGA manager struct
* struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops * struct :c:type:`fpga_manager_ops` — Low level FPGA manager driver ops
* :c:func:`devm_fpga_mgr_create` — Allocate and init a manager struct * devm_fpga_mgr_create() — Allocate and init a manager struct
* :c:func:`fpga_mgr_register` — Register an FPGA manager * fpga_mgr_register() — Register an FPGA manager
* :c:func:`fpga_mgr_unregister` — Unregister an FPGA manager * fpga_mgr_unregister() — Unregister an FPGA manager
.. kernel-doc:: include/linux/fpga/fpga-mgr.h .. kernel-doc:: include/linux/fpga/fpga-mgr.h
:functions: fpga_mgr_states :functions: fpga_mgr_states
......
...@@ -6,9 +6,9 @@ Overview ...@@ -6,9 +6,9 @@ Overview
The in-kernel API for FPGA programming is a combination of APIs from The in-kernel API for FPGA programming is a combination of APIs from
FPGA manager, bridge, and regions. The actual function used to FPGA manager, bridge, and regions. The actual function used to
trigger FPGA programming is :c:func:`fpga_region_program_fpga()`. trigger FPGA programming is fpga_region_program_fpga().
:c:func:`fpga_region_program_fpga()` uses functionality supplied by fpga_region_program_fpga() uses functionality supplied by
the FPGA manager and bridges. It will: the FPGA manager and bridges. It will:
* lock the region's mutex * lock the region's mutex
...@@ -20,8 +20,8 @@ the FPGA manager and bridges. It will: ...@@ -20,8 +20,8 @@ the FPGA manager and bridges. It will:
* release the locks * release the locks
The struct fpga_image_info specifies what FPGA image to program. It is The struct fpga_image_info specifies what FPGA image to program. It is
allocated/freed by :c:func:`fpga_image_info_alloc()` and freed with allocated/freed by fpga_image_info_alloc() and freed with
:c:func:`fpga_image_info_free()` fpga_image_info_free()
How to program an FPGA using a region How to program an FPGA using a region
------------------------------------- -------------------------------------
...@@ -84,10 +84,10 @@ will generate that list. Here's some sample code of what to do next:: ...@@ -84,10 +84,10 @@ will generate that list. Here's some sample code of what to do next::
API for programming an FPGA API for programming an FPGA
--------------------------- ---------------------------
* :c:func:`fpga_region_program_fpga` — Program an FPGA * fpga_region_program_fpga() — Program an FPGA
* :c:type:`fpga_image_info` — Specifies what FPGA image to program * fpga_image_info() — Specifies what FPGA image to program
* :c:func:`fpga_image_info_alloc()` — Allocate an FPGA image info struct * fpga_image_info_alloc() — Allocate an FPGA image info struct
* :c:func:`fpga_image_info_free()` — Free an FPGA image info struct * fpga_image_info_free() — Free an FPGA image info struct
.. kernel-doc:: drivers/fpga/fpga-region.c .. kernel-doc:: drivers/fpga/fpga-region.c
:functions: fpga_region_program_fpga :functions: fpga_region_program_fpga
......
...@@ -46,18 +46,18 @@ API to add a new FPGA region ...@@ -46,18 +46,18 @@ API to add a new FPGA region
---------------------------- ----------------------------
* struct :c:type:`fpga_region` — The FPGA region struct * struct :c:type:`fpga_region` — The FPGA region struct
* :c:func:`devm_fpga_region_create` — Allocate and init a region struct * devm_fpga_region_create() — Allocate and init a region struct
* :c:func:`fpga_region_register` — Register an FPGA region * fpga_region_register() — Register an FPGA region
* :c:func:`fpga_region_unregister` — Unregister an FPGA region * fpga_region_unregister() — Unregister an FPGA region
The FPGA region's probe function will need to get a reference to the FPGA The FPGA region's probe function will need to get a reference to the FPGA
Manager it will be using to do the programming. This usually would happen Manager it will be using to do the programming. This usually would happen
during the region's probe function. during the region's probe function.
* :c:func:`fpga_mgr_get` — Get a reference to an FPGA manager, raise ref count * fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count
* :c:func:`of_fpga_mgr_get` — Get a reference to an FPGA manager, raise ref count, * of_fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count,
given a device node. given a device node.
* :c:func:`fpga_mgr_put` — Put an FPGA manager * fpga_mgr_put() — Put an FPGA manager
The FPGA region will need to specify which bridges to control while programming The FPGA region will need to specify which bridges to control while programming
the FPGA. The region driver can build a list of bridges during probe time the FPGA. The region driver can build a list of bridges during probe time
...@@ -66,11 +66,11 @@ the list of bridges to program just before programming ...@@ -66,11 +66,11 @@ the list of bridges to program just before programming
(:c:member:`fpga_region->get_bridges`). The FPGA bridge framework supplies the (:c:member:`fpga_region->get_bridges`). The FPGA bridge framework supplies the
following APIs to handle building or tearing down that list. following APIs to handle building or tearing down that list.
* :c:func:`fpga_bridge_get_to_list` — Get a ref of an FPGA bridge, add it to a * fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
list list
* :c:func:`of_fpga_bridge_get_to_list` — Get a ref of an FPGA bridge, add it to a * of_fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a
list, given a device node list, given a device node
* :c:func:`fpga_bridges_put` — Given a list of bridges, put them * fpga_bridges_put() — Given a list of bridges, put them
.. kernel-doc:: include/linux/fpga/fpga-region.h .. kernel-doc:: include/linux/fpga/fpga-region.h
:functions: fpga_region :functions: fpga_region
......
...@@ -11,10 +11,10 @@ Industrial I/O Devices ...@@ -11,10 +11,10 @@ Industrial I/O Devices
---------------------- ----------------------
* struct :c:type:`iio_dev` - industrial I/O device * struct :c:type:`iio_dev` - industrial I/O device
* :c:func:`iio_device_alloc()` - allocate an :c:type:`iio_dev` from a driver * iio_device_alloc() - allocate an :c:type:`iio_dev` from a driver
* :c:func:`iio_device_free()` - free an :c:type:`iio_dev` from a driver * iio_device_free() - free an :c:type:`iio_dev` from a driver
* :c:func:`iio_device_register()` - register a device with the IIO subsystem * iio_device_register() - register a device with the IIO subsystem
* :c:func:`iio_device_unregister()` - unregister a device from the IIO * iio_device_unregister() - unregister a device from the IIO
subsystem subsystem
An IIO device usually corresponds to a single hardware sensor and it An IIO device usually corresponds to a single hardware sensor and it
...@@ -34,17 +34,17 @@ A typical IIO driver will register itself as an :doc:`I2C <../i2c>` or ...@@ -34,17 +34,17 @@ A typical IIO driver will register itself as an :doc:`I2C <../i2c>` or
At probe: At probe:
1. Call :c:func:`iio_device_alloc()`, which allocates memory for an IIO device. 1. Call iio_device_alloc(), which allocates memory for an IIO device.
2. Initialize IIO device fields with driver specific information (e.g. 2. Initialize IIO device fields with driver specific information (e.g.
device name, device channels). device name, device channels).
3. Call :c:func:`iio_device_register()`, this registers the device with the 3. Call iio_device_register(), this registers the device with the
IIO core. After this call the device is ready to accept requests from user IIO core. After this call the device is ready to accept requests from user
space applications. space applications.
At remove, we free the resources allocated in probe in reverse order: At remove, we free the resources allocated in probe in reverse order:
1. :c:func:`iio_device_unregister()`, unregister the device from the IIO core. 1. iio_device_unregister(), unregister the device from the IIO core.
2. :c:func:`iio_device_free()`, free the memory allocated for the IIO device. 2. iio_device_free(), free the memory allocated for the IIO device.
IIO device sysfs interface IIO device sysfs interface
========================== ==========================
......
...@@ -68,7 +68,7 @@ See below for all known bank addresses, numbers of sensors in that bank, ...@@ -68,7 +68,7 @@ See below for all known bank addresses, numbers of sensors in that bank,
number of bytes data per sensor and contents/meaning of those bytes. number of bytes data per sensor and contents/meaning of those bytes.
Although both this document and the kernel driver have kept the sensor Although both this document and the kernel driver have kept the sensor
terminoligy for the addressing within a bank this is not 100% correct, in terminology for the addressing within a bank this is not 100% correct, in
bank 0x24 for example the addressing within the bank selects a PWM output not bank 0x24 for example the addressing within the bank selects a PWM output not
a sensor. a sensor.
...@@ -155,7 +155,7 @@ After wider testing of the Linux kernel driver some variants of the uGuru have ...@@ -155,7 +155,7 @@ After wider testing of the Linux kernel driver some variants of the uGuru have
turned up which do not hold 0x08 at DATA within 250 reads after writing the turned up which do not hold 0x08 at DATA within 250 reads after writing the
bank address. With these versions this happens quite frequent, using larger bank address. With these versions this happens quite frequent, using larger
timeouts doesn't help, they just go offline for a second or 2, doing some timeouts doesn't help, they just go offline for a second or 2, doing some
internal callibration or whatever. Your code should be prepared to handle internal calibration or whatever. Your code should be prepared to handle
this and in case of no response in this specific case just goto sleep for a this and in case of no response in this specific case just goto sleep for a
while and then retry. while and then retry.
...@@ -331,6 +331,6 @@ the voltage / clock programming out, I tried reading and only reading banks ...@@ -331,6 +331,6 @@ the voltage / clock programming out, I tried reading and only reading banks
0-0x30 with the reading code used for the sensor banks (0x20-0x28) and this 0-0x30 with the reading code used for the sensor banks (0x20-0x28) and this
resulted in a _permanent_ reprogramming of the voltages, luckily I had the resulted in a _permanent_ reprogramming of the voltages, luckily I had the
sensors part configured so that it would shutdown my system on any out of spec sensors part configured so that it would shutdown my system on any out of spec
voltages which proprably safed my computer (after a reboot I managed to voltages which probably safed my computer (after a reboot I managed to
immediately enter the bios and reload the defaults). This probably means that immediately enter the bios and reload the defaults). This probably means that
the read/write cycle for the non sensor part is different from the sensor part. the read/write cycle for the non sensor part is different from the sensor part.
...@@ -17,7 +17,7 @@ Supported chips: ...@@ -17,7 +17,7 @@ Supported chips:
Note: Note:
The uGuru is a microcontroller with onboard firmware which programs The uGuru is a microcontroller with onboard firmware which programs
it to behave as a hwmon IC. There are many different revisions of the it to behave as a hwmon IC. There are many different revisions of the
firmware and thus effectivly many different revisions of the uGuru. firmware and thus effectively many different revisions of the uGuru.
Below is an incomplete list with which revisions are used for which Below is an incomplete list with which revisions are used for which
Motherboards: Motherboards:
...@@ -33,7 +33,7 @@ Supported chips: ...@@ -33,7 +33,7 @@ Supported chips:
sensortype (Volt or Temp) for bank1 sensors, for revision 1 uGuru's sensortype (Volt or Temp) for bank1 sensors, for revision 1 uGuru's
this does not always work. For these uGuru's the autodetection can this does not always work. For these uGuru's the autodetection can
be overridden with the bank1_types module param. For all 3 known be overridden with the bank1_types module param. For all 3 known
revison 1 motherboards the correct use of this param is: revision 1 motherboards the correct use of this param is:
bank1_types=1,1,0,0,0,0,0,2,0,0,0,0,2,0,0,1 bank1_types=1,1,0,0,0,0,0,2,0,0,0,0,2,0,0,1
You may also need to specify the fan_sensors option for these boards You may also need to specify the fan_sensors option for these boards
fan_sensors=5 fan_sensors=5
......
...@@ -13,7 +13,7 @@ Supported chips: ...@@ -13,7 +13,7 @@ Supported chips:
Note: Note:
The uGuru is a microcontroller with onboard firmware which programs The uGuru is a microcontroller with onboard firmware which programs
it to behave as a hwmon IC. There are many different revisions of the it to behave as a hwmon IC. There are many different revisions of the
firmware and thus effectivly many different revisions of the uGuru. firmware and thus effectively many different revisions of the uGuru.
Below is an incomplete list with which revisions are used for which Below is an incomplete list with which revisions are used for which
Motherboards: Motherboards:
...@@ -24,7 +24,7 @@ Supported chips: ...@@ -24,7 +24,7 @@ Supported chips:
- uGuru 3.0.0.0 ~ 3.0.x.x (AW8, AL8, AT8, NI8 SLI, AT8 32X, AN8 32X, - uGuru 3.0.0.0 ~ 3.0.x.x (AW8, AL8, AT8, NI8 SLI, AT8 32X, AN8 32X,
AW9D-MAX) AW9D-MAX)
The abituguru3 driver is only for revison 3.0.x.x motherboards, The abituguru3 driver is only for revision 3.0.x.x motherboards,
this driver will not work on older motherboards. For older this driver will not work on older motherboards. For older
motherboards use the abituguru (without the 3 !) driver. motherboards use the abituguru (without the 3 !) driver.
......
...@@ -164,14 +164,14 @@ by disabling preemption or interrupts. ...@@ -164,14 +164,14 @@ by disabling preemption or interrupts.
On non-PREEMPT_RT kernels local_lock operations map to the preemption and On non-PREEMPT_RT kernels local_lock operations map to the preemption and
interrupt disabling and enabling primitives: interrupt disabling and enabling primitives:
=========================== ====================== =============================== ======================
local_lock(&llock) preempt_disable() local_lock(&llock) preempt_disable()
local_unlock(&llock) preempt_enable() local_unlock(&llock) preempt_enable()
local_lock_irq(&llock) local_irq_disable() local_lock_irq(&llock) local_irq_disable()
local_unlock_irq(&llock) local_irq_enable() local_unlock_irq(&llock) local_irq_enable()
local_lock_save(&llock) local_irq_save() local_lock_irqsave(&llock) local_irq_save()
local_lock_restore(&llock) local_irq_save() local_unlock_irqrestore(&llock) local_irq_restore()
=========================== ====================== =============================== ======================
The named scope of local_lock has two advantages over the regular The named scope of local_lock has two advantages over the regular
primitives: primitives:
...@@ -353,14 +353,14 @@ protection scope. So the following substitution is wrong:: ...@@ -353,14 +353,14 @@ protection scope. So the following substitution is wrong::
{ {
local_irq_save(flags); -> local_lock_irqsave(&local_lock_1, flags); local_irq_save(flags); -> local_lock_irqsave(&local_lock_1, flags);
func3(); func3();
local_irq_restore(flags); -> local_lock_irqrestore(&local_lock_1, flags); local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock_1, flags);
} }
func2() func2()
{ {
local_irq_save(flags); -> local_lock_irqsave(&local_lock_2, flags); local_irq_save(flags); -> local_lock_irqsave(&local_lock_2, flags);
func3(); func3();
local_irq_restore(flags); -> local_lock_irqrestore(&local_lock_2, flags); local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock_2, flags);
} }
func3() func3()
...@@ -379,14 +379,14 @@ PREEMPT_RT-specific semantics of spinlock_t. The correct substitution is:: ...@@ -379,14 +379,14 @@ PREEMPT_RT-specific semantics of spinlock_t. The correct substitution is::
{ {
local_irq_save(flags); -> local_lock_irqsave(&local_lock, flags); local_irq_save(flags); -> local_lock_irqsave(&local_lock, flags);
func3(); func3();
local_irq_restore(flags); -> local_lock_irqrestore(&local_lock, flags); local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock, flags);
} }
func2() func2()
{ {
local_irq_save(flags); -> local_lock_irqsave(&local_lock, flags); local_irq_save(flags); -> local_lock_irqsave(&local_lock, flags);
func3(); func3();
local_irq_restore(flags); -> local_lock_irqrestore(&local_lock, flags); local_irq_restore(flags); -> local_unlock_irqrestore(&local_lock, flags);
} }
func3() func3()
......
...@@ -101,3 +101,4 @@ to do something different in the near future. ...@@ -101,3 +101,4 @@ to do something different in the near future.
../doc-guide/maintainer-profile ../doc-guide/maintainer-profile
../nvdimm/maintainer-entry-profile ../nvdimm/maintainer-entry-profile
../riscv/patch-acceptance
...@@ -142,7 +142,7 @@ only NUL-terminated strings. The safe replacement is strscpy(). ...@@ -142,7 +142,7 @@ only NUL-terminated strings. The safe replacement is strscpy().
(Users of strscpy() still needing NUL-padding should instead (Users of strscpy() still needing NUL-padding should instead
use strscpy_pad().) use strscpy_pad().)
If a caller is using non-NUL-terminated strings, strncpy()() can If a caller is using non-NUL-terminated strings, strncpy() can
still be used, but destinations should be marked with the `__nonstring still be used, but destinations should be marked with the `__nonstring
<https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_ <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
attribute to avoid future compiler warnings. attribute to avoid future compiler warnings.
......
...@@ -130,7 +130,7 @@ chi usa solo stringe terminate. La versione sicura da usare è ...@@ -130,7 +130,7 @@ chi usa solo stringe terminate. La versione sicura da usare è
strscpy(). (chi usa strscpy() e necessita di estendere la strscpy(). (chi usa strscpy() e necessita di estendere la
terminazione con NUL deve aggiungere una chiamata a memset()) terminazione con NUL deve aggiungere una chiamata a memset())
Se il chiamate no usa stringhe terminate con NUL, allore strncpy()() Se il chiamate no usa stringhe terminate con NUL, allore strncpy()
può continuare ad essere usata, ma i buffer di destinazione devono essere può continuare ad essere usata, ma i buffer di destinazione devono essere
marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_ marchiati con l'attributo `__nonstring <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_
per evitare avvisi durante la compilazione. per evitare avvisi durante la compilazione.
......
...@@ -5240,6 +5240,7 @@ DOCUMENTATION ...@@ -5240,6 +5240,7 @@ DOCUMENTATION
M: Jonathan Corbet <corbet@lwn.net> M: Jonathan Corbet <corbet@lwn.net>
L: linux-doc@vger.kernel.org L: linux-doc@vger.kernel.org
S: Maintained S: Maintained
P: Documentation/doc-guide/maintainer-profile.rst
T: git git://git.lwn.net/linux.git docs-next T: git git://git.lwn.net/linux.git docs-next
F: Documentation/ F: Documentation/
F: scripts/documentation-file-ref-check F: scripts/documentation-file-ref-check
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment