From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> To: Linux Doc Mailing List <linux-doc@vger.kernel.org> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, "Jonathan Corbet" <corbet@lwn.net>, Arnd Bergmann <arnd@arndb.de>, Jaroslav Kysela <perex@perex.cz>, Julia Lawall <Julia.Lawall@inria.fr>, Takashi Iwai <tiwai@suse.com>, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de> Subject: [PATCH v6 37/80] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type Date: Tue, 13 Oct 2020 13:53:52 +0200 [thread overview] Message-ID: <dd2268b8e6c088c7978783a807528ae0444a5a06.1602589096.git.mchehab+huawei@kernel.org> (raw) In-Reply-To: <cover.1602589096.git.mchehab+huawei@kernel.org> the :c:type shouldn't be used with structs with Sphinx 3, as the C domain there uses .. c:struct for structs. As we have the automarkup extension, let's just get rid of all :c:type as a whole, as those will be automagically marked as such. This solves a bunch of warnings with Sphinx 3, like those: .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:490: WARNING: Unparseable C cross-reference: 'calling snd_card_free' Invalid C declaration: Expected end of definition. [error at 8] calling snd_card_free --------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3328: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3928: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> --- .../kernel-api/writing-an-alsa-driver.rst | 105 ++++++++---------- 1 file changed, 47 insertions(+), 58 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index aa9d5ab183d2..85d6e9c643ef 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows: - create ``remove`` callback. -- create a :c:type:`struct pci_driver <pci_driver>` structure +- create a struct pci_driver structure containing the three pointers above. - create an ``init`` function just calling the @@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then the ALSA middle layer will release all the attached components automatically. -It would be typically just :c:func:`calling snd_card_free()`: +It would be typically just calling :c:func:`snd_card_free()`: :: @@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data are allocated by :c:func:`snd_card_new()`. -The first argument, the pointer of struct :c:type:`struct device -<device>`, specifies the parent device. For PCI devices, typically -``&pci->`` is passed there. +The first argument, the pointer of struct device, specifies the parent +device. For PCI devices, typically ``&pci->`` is passed there. Components ---------- After the card is created, you can attach the components (devices) to the card instance. In an ALSA driver, a component is represented as a -:c:type:`struct snd_device <snd_device>` object. A component +struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. @@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e. err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); -:c:type:`struct mychip <mychip>` is the type of the chip record. +struct mychip is the type of the chip record. In return, the allocated record can be accessed as @@ -890,7 +889,7 @@ functions. These resources must be released in the destructor function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an -interrupt. Then :c:type:`struct mychip <mychip>` will have the +interrupt. Then struct mychip will have the following fields: :: @@ -1094,7 +1093,7 @@ PCI Entries ----------- So far, so good. Let's finish the missing PCI stuff. At first, we need a -:c:type:`struct pci_device_id <pci_device_id>` table for +struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. @@ -1110,19 +1109,17 @@ For example, }; MODULE_DEVICE_TABLE(pci, snd_mychip_ids); -The first and second fields of the :c:type:`struct pci_device_id -<pci_device_id>` structure are the vendor and device IDs. If you -have no reason to filter the matching devices, you can leave the -remaining fields as above. The last field of the :c:type:`struct -pci_device_id <pci_device_id>` struct contains private data -for this entry. You can specify any value here, for example, to define -specific operations for supported device IDs. Such an example is found -in the intel8x0 driver. +The first and second fields of the struct pci_device_id are the vendor +and device IDs. If you have no reason to filter the matching devices, you can +leave the remaining fields as above. The last field of the +struct pci_device_id contains private data for this entry. You can specify +any value here, for example, to define specific operations for supported +device IDs. Such an example is found in the intel8x0 driver. The last entry of this list is the terminator. You must specify this all-zero entry. -Then, prepare the :c:type:`struct pci_driver <pci_driver>` +Then, prepare the struct pci_driver record: :: @@ -1439,8 +1436,8 @@ corresponding argument. If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, -then it can be obtained from :c:type:`struct snd_pcm_substream -<snd_pcm_substream>` data passed to each callback as follows: +then it can be obtained from struct snd_pcm_substream data passed to each +callback as follows: :: @@ -1639,10 +1636,9 @@ In the sections below, important records are explained. Hardware Description ~~~~~~~~~~~~~~~~~~~~ -The hardware descriptor (:c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>`) contains the definitions of the fundamental -hardware configuration. Above all, you'll need to define this in the -`PCM open callback`_. Note that the runtime instance holds the copy of +The hardware descriptor (struct snd_pcm_hardware) contains the definitions of +the fundamental hardware configuration. Above all, you'll need to define this +in the `PCM open callback`_. Note that the runtime instance holds the copy of the descriptor, not the pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of @@ -1800,14 +1796,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the :c:type:`struct snd_pcm_mmap_status -<snd_pcm_mmap_status>` record. For example, you can get the current +the pointer to the struct snd_pcm_mmap_status record. +For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the :c:type:`struct snd_pcm_mmap_control -<snd_pcm_mmap_control>` record. However, accessing directly to -this value is not recommended. +which points to the struct snd_pcm_mmap_control record. +However, accessing directly to this value is not recommended. Private Data ~~~~~~~~~~~~ @@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with :c:type:`struct -snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip +The callback function takes at least the argument with +struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following macro. @@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm -<snd_pcm>` object after creating it. When this flag is set, mutex -and rwsem are used internally in the PCM core instead of spin and -rwlocks, so that you can call all PCM functions safely in a non-atomic +a case, you can set ``nonatomic`` filed of struct snd_pcm object +after creating it. When this flag is set, mutex and rwsem are used internally +in the PCM core instead of spin and rwlocks, so that you can call all PCM +functions safely in a non-atomic context. Constraints @@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in the :c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>` structure (or in any other +specified in struct snd_pcm_hardware> (or in any other constraint_list). You can build a rule like this: :: @@ -2467,7 +2461,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as: +struct snd_kcontrol_new record, such as: :: @@ -2602,8 +2596,8 @@ info callback ~~~~~~~~~~~~~ The ``info`` callback is used to get detailed information on this -control. This must store the values of the given :c:type:`struct -snd_ctl_elem_info <snd_ctl_elem_info>` object. For example, +control. This must store the values of the given +struct snd_ctl_elem_info object. For example, for a boolean control with a single element: :: @@ -2774,13 +2768,11 @@ In the simplest way, you can do like this: if (err < 0) return err; -where ``my_control`` is the :c:type:`struct snd_kcontrol_new -<snd_kcontrol_new>` object defined above, and chip is the object -pointer to be passed to kcontrol->private_data which can be referred -to in callbacks. +where ``my_control`` is the struct snd_kcontrol_new object defined above, +and chip is the object pointer to be passed to kcontrol->private_data which +can be referred to in callbacks. -:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct -snd_kcontrol <snd_kcontrol>` instance, and +:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and :c:func:`snd_ctl_add()` assigns the given control component to the card. @@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example, This function takes the card pointer, the event-mask, and the control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control -values is notified. The id pointer is the pointer of :c:type:`struct -snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can -find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume -interrupts. +values is notified. The id pointer is the pointer of struct snd_ctl_elem_id +to be notified. You can find some examples in ``es1938.c`` or ``es1968.c`` +for hardware volume interrupts. Metadata -------- @@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct -snd_ac97_template <snd_ac97_template>` record together with -the bus pointer created above. +And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template +record together with the bus pointer created above. :: @@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` -field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward. -However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is +field of struct snd_mpu401 manually afterward. +However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401 -<snd_mpu401>` explicitly, +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, :: @@ -3772,7 +3761,7 @@ For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer_all()` with ``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI pre-allocator. You need to pass ``&pci->dev``, where pci is -the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as +the struct pci_dev pointer of the chip as well. :: -- 2.26.2
WARNING: multiple messages have this Message-ID (diff)
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> To: Linux Doc Mailing List <linux-doc@vger.kernel.org> Cc: alsa-devel@alsa-project.org, Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.com>, Julia Lawall <Julia.Lawall@inria.fr>, Takashi Iwai <tiwai@suse.de> Subject: [PATCH v6 37/80] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type Date: Tue, 13 Oct 2020 13:53:52 +0200 [thread overview] Message-ID: <dd2268b8e6c088c7978783a807528ae0444a5a06.1602589096.git.mchehab+huawei@kernel.org> (raw) In-Reply-To: <cover.1602589096.git.mchehab+huawei@kernel.org> the :c:type shouldn't be used with structs with Sphinx 3, as the C domain there uses .. c:struct for structs. As we have the automarkup extension, let's just get rid of all :c:type as a whole, as those will be automagically marked as such. This solves a bunch of warnings with Sphinx 3, like those: .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:490: WARNING: Unparseable C cross-reference: 'calling snd_card_free' Invalid C declaration: Expected end of definition. [error at 8] calling snd_card_free --------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3328: WARNING: Unparseable C cross-reference: 'snd_rawmidi_transmit*' Invalid C declaration: Expected end of definition. [error at 20] snd_rawmidi_transmit* --------------------^ .../Documentation/sound/kernel-api/writing-an-alsa-driver.rst:3928: WARNING: Unparseable C cross-reference: 'copy_from/to_user' Invalid C declaration: Expected end of definition. [error at 9] copy_from/to_user ---------^ Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> --- .../kernel-api/writing-an-alsa-driver.rst | 105 ++++++++---------- 1 file changed, 47 insertions(+), 58 deletions(-) diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index aa9d5ab183d2..85d6e9c643ef 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows: - create ``remove`` callback. -- create a :c:type:`struct pci_driver <pci_driver>` structure +- create a struct pci_driver structure containing the three pointers above. - create an ``init`` function just calling the @@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then the ALSA middle layer will release all the attached components automatically. -It would be typically just :c:func:`calling snd_card_free()`: +It would be typically just calling :c:func:`snd_card_free()`: :: @@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data are allocated by :c:func:`snd_card_new()`. -The first argument, the pointer of struct :c:type:`struct device -<device>`, specifies the parent device. For PCI devices, typically -``&pci->`` is passed there. +The first argument, the pointer of struct device, specifies the parent +device. For PCI devices, typically ``&pci->`` is passed there. Components ---------- After the card is created, you can attach the components (devices) to the card instance. In an ALSA driver, a component is represented as a -:c:type:`struct snd_device <snd_device>` object. A component +struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. @@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e. err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); -:c:type:`struct mychip <mychip>` is the type of the chip record. +struct mychip is the type of the chip record. In return, the allocated record can be accessed as @@ -890,7 +889,7 @@ functions. These resources must be released in the destructor function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an -interrupt. Then :c:type:`struct mychip <mychip>` will have the +interrupt. Then struct mychip will have the following fields: :: @@ -1094,7 +1093,7 @@ PCI Entries ----------- So far, so good. Let's finish the missing PCI stuff. At first, we need a -:c:type:`struct pci_device_id <pci_device_id>` table for +struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. @@ -1110,19 +1109,17 @@ For example, }; MODULE_DEVICE_TABLE(pci, snd_mychip_ids); -The first and second fields of the :c:type:`struct pci_device_id -<pci_device_id>` structure are the vendor and device IDs. If you -have no reason to filter the matching devices, you can leave the -remaining fields as above. The last field of the :c:type:`struct -pci_device_id <pci_device_id>` struct contains private data -for this entry. You can specify any value here, for example, to define -specific operations for supported device IDs. Such an example is found -in the intel8x0 driver. +The first and second fields of the struct pci_device_id are the vendor +and device IDs. If you have no reason to filter the matching devices, you can +leave the remaining fields as above. The last field of the +struct pci_device_id contains private data for this entry. You can specify +any value here, for example, to define specific operations for supported +device IDs. Such an example is found in the intel8x0 driver. The last entry of this list is the terminator. You must specify this all-zero entry. -Then, prepare the :c:type:`struct pci_driver <pci_driver>` +Then, prepare the struct pci_driver record: :: @@ -1439,8 +1436,8 @@ corresponding argument. If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, -then it can be obtained from :c:type:`struct snd_pcm_substream -<snd_pcm_substream>` data passed to each callback as follows: +then it can be obtained from struct snd_pcm_substream data passed to each +callback as follows: :: @@ -1639,10 +1636,9 @@ In the sections below, important records are explained. Hardware Description ~~~~~~~~~~~~~~~~~~~~ -The hardware descriptor (:c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>`) contains the definitions of the fundamental -hardware configuration. Above all, you'll need to define this in the -`PCM open callback`_. Note that the runtime instance holds the copy of +The hardware descriptor (struct snd_pcm_hardware) contains the definitions of +the fundamental hardware configuration. Above all, you'll need to define this +in the `PCM open callback`_. Note that the runtime instance holds the copy of the descriptor, not the pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of @@ -1800,14 +1796,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the :c:type:`struct snd_pcm_mmap_status -<snd_pcm_mmap_status>` record. For example, you can get the current +the pointer to the struct snd_pcm_mmap_status record. +For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the :c:type:`struct snd_pcm_mmap_control -<snd_pcm_mmap_control>` record. However, accessing directly to -this value is not recommended. +which points to the struct snd_pcm_mmap_control record. +However, accessing directly to this value is not recommended. Private Data ~~~~~~~~~~~~ @@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with :c:type:`struct -snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip +The callback function takes at least the argument with +struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following macro. @@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm -<snd_pcm>` object after creating it. When this flag is set, mutex -and rwsem are used internally in the PCM core instead of spin and -rwlocks, so that you can call all PCM functions safely in a non-atomic +a case, you can set ``nonatomic`` filed of struct snd_pcm object +after creating it. When this flag is set, mutex and rwsem are used internally +in the PCM core instead of spin and rwlocks, so that you can call all PCM +functions safely in a non-atomic context. Constraints @@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in the :c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>` structure (or in any other +specified in struct snd_pcm_hardware> (or in any other constraint_list). You can build a rule like this: :: @@ -2467,7 +2461,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as: +struct snd_kcontrol_new record, such as: :: @@ -2602,8 +2596,8 @@ info callback ~~~~~~~~~~~~~ The ``info`` callback is used to get detailed information on this -control. This must store the values of the given :c:type:`struct -snd_ctl_elem_info <snd_ctl_elem_info>` object. For example, +control. This must store the values of the given +struct snd_ctl_elem_info object. For example, for a boolean control with a single element: :: @@ -2774,13 +2768,11 @@ In the simplest way, you can do like this: if (err < 0) return err; -where ``my_control`` is the :c:type:`struct snd_kcontrol_new -<snd_kcontrol_new>` object defined above, and chip is the object -pointer to be passed to kcontrol->private_data which can be referred -to in callbacks. +where ``my_control`` is the struct snd_kcontrol_new object defined above, +and chip is the object pointer to be passed to kcontrol->private_data which +can be referred to in callbacks. -:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct -snd_kcontrol <snd_kcontrol>` instance, and +:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and :c:func:`snd_ctl_add()` assigns the given control component to the card. @@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example, This function takes the card pointer, the event-mask, and the control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control -values is notified. The id pointer is the pointer of :c:type:`struct -snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can -find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume -interrupts. +values is notified. The id pointer is the pointer of struct snd_ctl_elem_id +to be notified. You can find some examples in ``es1938.c`` or ``es1968.c`` +for hardware volume interrupts. Metadata -------- @@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct -snd_ac97_template <snd_ac97_template>` record together with -the bus pointer created above. +And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template +record together with the bus pointer created above. :: @@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` -field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward. -However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is +field of struct snd_mpu401 manually afterward. +However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401 -<snd_mpu401>` explicitly, +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, :: @@ -3772,7 +3761,7 @@ For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer_all()` with ``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI pre-allocator. You need to pass ``&pci->dev``, where pci is -the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as +the struct pci_dev pointer of the chip as well. :: -- 2.26.2
next prev parent reply other threads:[~2020-10-13 11:58 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-13 11:53 [PATCH v6 00/80] htmldoc build fixes with Sphinx 2.x and 3.x Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 01/80] scripts: kernel-doc: add support for typedef enum Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 02/80] scripts: kernel-doc: make it more compatible with Sphinx 3.x Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 03/80] scripts: kernel-doc: use a less pedantic markup for funcs on " Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 04/80] scripts: kernel-doc: fix troubles with line counts Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 05/80] scripts: kernel-doc: reimplement -nofunction argument Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 06/80] scripts: kernel-doc: fix typedef identification Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 07/80] scripts: kernel-doc: don't mangle with parameter list Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 08/80] scripts: kernel-doc: allow passing desired Sphinx C domain dialect Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 09/80] scripts: kernel-doc: fix line number handling Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 10/80] scripts: kernel-doc: try to use c:function if possible Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 11/80] docs: cdomain.py: add support for a new Sphinx 3.1+ tag Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 12/80] docs: cdomain.py: extend it to handle new Sphinx 3.x tags Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 13/80] docs: automarkup.py: make it ready for Sphinx 3.1+ Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 14/80] docs: kerneldoc.py: append the name of the parsed doc file Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 15/80] docs: kerneldoc.py: add support for kerneldoc -nosymbol Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 16/80] media: docs: make CEC documents compatible with Sphinx 3.1+ Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 17/80] media: docs: make V4L documents more " Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 18/80] media: docs: make DVB " Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 19/80] media: docs: make MC " Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 20/80] media: docs: make RC " Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 21/80] media: cec-core.rst: don't use c:type for structs Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 22/80] docs: remove some replace macros like |struct foo| Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 23/80] docs: get rid of :c:type explicit declarations for structs Mauro Carvalho Chehab 2020-10-13 11:53 ` Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 24/80] docs: trace-uses.rst: remove bogus c-domain tags Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 25/80] docs: it_IT: fix namespace collisions at locking.rst Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 26/80] docs: net: ieee802154.rst: fix C expressions Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 27/80] docs: genericirq.rst: don't document chip.c functions twice Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 28/80] docs: kernel-api.rst: drop kernel/irq/manage.c kernel-doc tag Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 29/80] docs: remove sound API duplication Mauro Carvalho Chehab 2020-10-13 11:53 ` Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 30/80] docs: basics.rst: move kernel-doc workqueue markups to workqueue.rst Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 31/80] docs: scsi: target.rst: remove iSCSI transport class kernel-doc markup Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 32/80] docs: device_link.rst: remove duplicated kernel-doc include Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 33/80] docs: basics.rst: get rid of rcu kernel-doc macros Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 34/80] docs: pstore-blk.rst: fix kernel-doc tags Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 35/80] docs: fs: fscrypt.rst: get rid of :c:type: tags Mauro Carvalho Chehab 2020-10-13 17:25 ` Eric Biggers 2020-10-14 6:59 ` Mauro Carvalho Chehab 2020-10-14 21:59 ` Eric Biggers 2020-10-15 5:32 ` Mauro Carvalho Chehab 2020-10-15 16:36 ` Eric Biggers 2020-10-15 16:56 ` Mauro Carvalho Chehab 2020-10-15 21:26 ` Jonathan Corbet 2020-10-13 11:53 ` [PATCH v6 36/80] docs: devices.rst: get rid of :c:type macros Mauro Carvalho Chehab 2020-10-13 11:53 ` Mauro Carvalho Chehab [this message] 2020-10-13 11:53 ` [PATCH v6 37/80] docs: sound: writing-an-alsa-driver.rst: get rid of :c:type Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 38/80] docs: block: blk-mq.rst: " Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 39/80] docs: writing-an-alsa-driver.rst: fix some bad c:func: markups Mauro Carvalho Chehab 2020-10-13 11:53 ` Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 40/80] docs: fpga: replace :c:member: macros Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 41/80] docs: kgdb.rst: fix :c:type: usages Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 42/80] docs: libata.rst: fix a wrong usage of :c:type: tag Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 43/80] docs: infrastructure.rst: don't include firmware kernel-doc Mauro Carvalho Chehab 2020-10-13 11:53 ` [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings Mauro Carvalho Chehab 2020-10-13 11:53 ` [Intel-gfx] " Mauro Carvalho Chehab 2020-10-13 11:53 ` Mauro Carvalho Chehab 2020-10-16 11:01 ` Joonas Lahtinen 2020-10-16 11:01 ` [Intel-gfx] " Joonas Lahtinen 2020-10-16 11:01 ` Joonas Lahtinen 2020-10-16 11:37 ` Mauro Carvalho Chehab 2020-10-16 11:37 ` [Intel-gfx] " Mauro Carvalho Chehab 2020-10-16 11:37 ` Mauro Carvalho Chehab 2020-10-16 11:39 ` Lionel Landwerlin 2020-10-16 11:39 ` [Intel-gfx] " Lionel Landwerlin 2020-10-16 11:39 ` Lionel Landwerlin 2020-10-16 11:50 ` Jani Nikula 2020-10-16 11:50 ` [Intel-gfx] " Jani Nikula 2020-10-16 11:50 ` Jani Nikula 2020-10-16 12:02 ` Lionel Landwerlin 2020-10-16 12:02 ` [Intel-gfx] " Lionel Landwerlin 2020-10-16 12:02 ` Lionel Landwerlin 2020-10-16 12:02 ` Lionel Landwerlin 2020-10-16 12:03 ` Lionel Landwerlin 2020-10-16 12:03 ` [Intel-gfx] " Lionel Landwerlin 2020-10-16 12:03 ` Lionel Landwerlin 2020-10-13 11:54 ` [PATCH v6 45/80] docs: devices.rst: fix a C reference markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 46/80] docs: it_IT: hacking.rst: fix a typo on a markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 47/80] docs: mei.rst: fix a C expression markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 48/80] docs: basics.rst: avoid duplicated C function declaration Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 49/80] docs: conf.py: fix c:function support with Sphinx 3.x Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 50/80] docs: conf.py: change the Sphinx 3.x+ text Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 51/80] docs: infrastructure.rst: exclude device_link_state from device.h Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 52/80] docs: zh_CN: amu.rst: fix document title markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 53/80] media: uAPI: buffer.rst: remove a left-over documentation Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 54/80] math64.h: kernel-docs: Convert some markups into normal comments Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 55/80] memblock: get rid of a :c:type leftover Mauro Carvalho Chehab 2020-10-13 12:02 ` Mike Rapoport 2020-10-13 11:54 ` [PATCH v6 56/80] dt-bindings: fix references to files converted to yaml Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 57/80] net: appletalk: Kconfig: Fix docs location Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 58/80] drivers: net: hamradio: fix document location Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 59/80] docs: powerpc: syscall64-abi.rst: fix a malformed table Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 60/80] block: bio: fix a warning at the kernel-doc markups Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 61/80] kunit: test.h: solve kernel-doc warnings Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 62/80] docs: bio: fix a kerneldoc markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 63/80] drivers: core: fix kernel-doc markup for dev_err_probe() Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 64/80] kunit: test.h: fix a bad kernel-doc markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 65/80] docs: amdgpu: fix a warning when building the documentation Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 13:19 ` Alex Deucher 2020-10-13 13:19 ` Alex Deucher 2020-10-13 11:54 ` [PATCH v6 66/80] locking/refcount: document the new "oldp" pointer value Mauro Carvalho Chehab 2020-10-13 12:47 ` Peter Zijlstra 2020-10-13 11:54 ` [PATCH v6 67/80] usb: docs: document altmode register/unregister functions Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 68/80] nl80211: docs: add a description for s1g_cap parameter Mauro Carvalho Chehab 2020-10-13 16:45 ` Thomas Pedersen 2020-10-13 18:47 ` Johannes Berg 2020-10-13 20:41 ` Mauro Carvalho Chehab 2020-10-13 20:43 ` Johannes Berg 2020-10-13 11:54 ` [PATCH v6 69/80] IB/srpt: docs: add a description for cq_size member Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-15 4:32 ` Bart Van Assche 2020-10-15 4:32 ` Bart Van Assche 2020-10-13 11:54 ` [PATCH v6 70/80] rcu/tree: docs: document bkvcache new members at struct kfree_rcu_cpu Mauro Carvalho Chehab 2020-10-13 16:34 ` Paul E. McKenney 2020-10-13 20:46 ` Mauro Carvalho Chehab 2020-10-14 1:55 ` Paul E. McKenney 2020-10-13 11:54 ` [PATCH v6 71/80] Input: sparse-keymap: add a description for @sw Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 72/80] drm/amd/display: kernel-doc: document force_timing_sync Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 13:16 ` Alex Deucher 2020-10-13 13:16 ` Alex Deucher 2020-10-13 13:16 ` Alex Deucher 2020-10-13 11:54 ` [PATCH v6 73/80] drm: kernel-doc: drm_dp_helper.h: fix a typo Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 74/80] gpu: docs: amdgpu.rst: get rid of wrong kernel-doc markups Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 75/80] drm: kernel-doc: add description for a new function parameter Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 76/80] docs: virt: user_mode_linux_howto_v2.rst: fix a literal block markup Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 77/80] workqueue: fix a kernel-doc warning Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 78/80] mm/doc: fix a literal block markup Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 79/80] drm: drm_edid: remove a duplicated kernel-doc declaration Mauro Carvalho Chehab 2020-10-13 11:54 ` Mauro Carvalho Chehab 2020-10-13 11:54 ` [PATCH v6 80/80] PM / devfreq: remove a duplicated kernel-doc markup Mauro Carvalho Chehab 2020-10-15 15:49 ` [PATCH v6 00/80] htmldoc build fixes with Sphinx 2.x and 3.x Daniel Vetter 2020-10-15 16:30 ` Mauro Carvalho Chehab 2020-10-15 16:30 ` Mauro Carvalho Chehab
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=dd2268b8e6c088c7978783a807528ae0444a5a06.1602589096.git.mchehab+huawei@kernel.org \ --to=mchehab+huawei@kernel.org \ --cc=Julia.Lawall@inria.fr \ --cc=alsa-devel@alsa-project.org \ --cc=arnd@arndb.de \ --cc=corbet@lwn.net \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=perex@perex.cz \ --cc=tiwai@suse.com \ --cc=tiwai@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.