From: Anton Yakovlev <anton.yakovlev@opensynergy.com>
To: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Cc: <virtualization@lists.linux-foundation.org>,
<alsa-devel@alsa-project.org>, <virtio-dev@lists.oasis-open.org>,
<linux-kernel@vger.kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [virtio-dev] Re: [PATCH v2 2/9] ALSA: virtio: add virtio sound driver
Date: Tue, 2 Feb 2021 00:18:09 +0100 [thread overview]
Message-ID: <52f71ac6-3ec7-2884-7a64-1995f416d20a@opensynergy.com> (raw)
In-Reply-To: <8754dae8-114-6383-510-de2ba9dc4fa@intel.com>
Hi Guennadi,
Sorry for the late reply and thanks for your comments, they helped me a
lot! Please see my answers inline.
On 25.01.2021 15:54, Guennadi Liakhovetski wrote:
...[snip]...
>
>> + * 1. Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in
>> the
>> + * documentation and/or other materials provided with the
>> distribution.
>> + * 3. Neither the name of OpenSynergy GmbH nor the names of its
>> contributors
>> + * may be used to endorse or promote products derived from this
>> software
>> + * without specific prior written permission.
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
>> + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL IBM OR
>
> IBM? Also no idea whether this warranty disclaimer is appropriate here. I
> thought we were transitioning to those SPDX identifiers to eliminate all
> these headers.
It was a copy-paste mistake, I will edit these lines.
...[snip]...
>> +
>> +/**
>> + * virtsnd_disable_vqs() - Disable all virtqueues.
>> + * @snd: VirtIO sound device.
>> + *
>> + * Also free all allocated events and control messages.
>> + *
>> + * Context: Any context.
>> + */
>> +static void virtsnd_disable_vqs(struct virtio_snd *snd)
>> +{
>> + struct virtio_device *vdev = snd->vdev;
>> + unsigned int i;
>> + unsigned long flags;
>> +
>> + for (i = 0; i < VIRTIO_SND_VQ_MAX; ++i) {
>> + struct virtio_snd_queue *queue = &snd->queues[i];
>> +
>> + spin_lock_irqsave(&queue->lock, flags);
>> + /* Prohibit the use of the queue */
>> + if (queue->vqueue)
>> + virtqueue_disable_cb(queue->vqueue);
>> + queue->vqueue = NULL;
>> + spin_unlock_irqrestore(&queue->lock, flags);
>> + }
>> +
>> + if (snd->event_msgs)
>
> Check not needed, kfree(NULL) is ok.
Yes, you are right here. I didn't notice that devm_kfree() now works
fine with NULL argument too.
>> + devm_kfree(&vdev->dev, snd->event_msgs);
>
> I think there are very few cases when managed resources have to be
> explicitly freed. If explicit freeing is always required, then there's no
> need to have them managed. If there's a clear case for managed resources,
> usually you don't need to free them explicitly. Here.event_msgs are
> allocated in virtsnd_find_vqs() above, which is only called during
> probing. And this function is only called during release. So, I'd assume,
> that you don't need to free memory explicitly here.
Here, the reason for explicitly freeing managed resources is in the
current device reset handling logic. At the moment, executing the reset
worker results in a call to virtsnd_disable_vqs. After which the device
is recreated. And since in this case the driver is not detached from the
device, the managed resources are not automatically freed. On the other
hand, managed resources allow not to worry about deallocation if the
probing function returns an error.
>> +
>> + snd->event_msgs = NULL;
>
> snd is about to be freed, so do you really need this?
No :)
>> +}
>> +
>> +/**
>> + * virtsnd_reset_fn() - Kernel worker's function to reset the device.
>> + * @work: Reset device work.
>> + *
>> + * Context: Process context.
>> + */
>> +static void virtsnd_reset_fn(struct work_struct *work)
>> +{
>> + struct virtio_snd *snd =
>> + container_of(work, struct virtio_snd, reset_work);
>> + struct virtio_device *vdev = snd->vdev;
>> + struct device *dev = &vdev->dev;
>> + int rc;
>> +
>> + dev_info(dev, "sound device needs reset\n");
>> +
>> + /*
>> + * It seems that the only way to properly reset the device is to
>> remove
>> + * and re-create the ALSA sound card device.
>> + *
>> + * Also resetting the device involves a number of steps with
>> setting the
>> + * status bits described in the virtio specification. And the
>> easiest
>> + * way to get everything right is to use the virtio bus interface.
>> + */
>> + rc = dev->bus->remove(dev);
>> + if (rc)
>> + dev_warn(dev, "bus->remove() failed: %d", rc);
>> +
>> + rc = dev->bus->probe(dev);
>> + if (rc)
>> + dev_err(dev, "bus->probe() failed: %d", rc);
>
> This looks very suspicious to me. Wondering what ALSA maintainers
will say
> to this.
I'm also wondering what the virtio people have to say. This part is a
purely virtio specific thing. And since none of the existing virtio
drivers processes the request to reset the device, it is not clear what
is the best way to proceed here. For this reason, the most
straightforward and simple solution was chosen.
...[snip]...
>
> Thanks
> Guennadi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
>
--
Anton Yakovlev
Senior Software Engineer
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
www.opensynergy.com
next prev parent reply other threads:[~2021-02-01 23:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210124165408.1122868-1-anton.yakovlev@opensynergy.com>
2021-01-24 16:54 ` [PATCH v2 1/9] uapi: virtio_ids: add a sound device type ID from OASIS spec Anton Yakovlev
2021-01-24 16:54 ` [PATCH v2 2/9] ALSA: virtio: add virtio sound driver Anton Yakovlev
2021-01-25 14:54 ` Guennadi Liakhovetski
2021-02-01 23:18 ` Anton Yakovlev [this message]
2021-02-03 16:59 ` [virtio-dev] " Takashi Iwai
2021-02-03 17:34 ` Anton Yakovlev
2021-02-03 17:39 ` Takashi Iwai
2021-01-24 16:54 ` [PATCH v2 3/9] ALSA: virtio: handling control messages Anton Yakovlev
2021-01-25 15:22 ` Guennadi Liakhovetski
2021-02-01 23:18 ` [virtio-dev] " Anton Yakovlev
2021-01-24 16:54 ` [PATCH v2 4/9] ALSA: virtio: build PCM devices and substream hardware descriptors Anton Yakovlev
2021-01-25 15:44 ` Guennadi Liakhovetski
2021-02-01 23:19 ` [virtio-dev] " Anton Yakovlev
2021-01-24 16:54 ` [PATCH v2 5/9] ALSA: virtio: handling control and I/O messages for the PCM device Anton Yakovlev
2021-01-25 16:25 ` Guennadi Liakhovetski
2021-02-01 23:20 ` Anton Yakovlev
2021-01-24 16:54 ` [PATCH v2 6/9] ALSA: virtio: PCM substream operators Anton Yakovlev
2021-01-25 16:59 ` Guennadi Liakhovetski
2021-01-26 7:25 ` Guennadi Liakhovetski
2021-02-01 23:21 ` Anton Yakovlev
2021-01-24 16:54 ` [PATCH v2 7/9] ALSA: virtio: introduce jack support Anton Yakovlev
2021-01-26 7:40 ` Guennadi Liakhovetski
2021-01-24 16:54 ` [PATCH v2 8/9] ALSA: virtio: introduce PCM channel map support Anton Yakovlev
2021-01-26 9:22 ` Guennadi Liakhovetski
2021-02-01 23:21 ` Anton Yakovlev
2021-01-24 16:54 ` [PATCH v2 9/9] ALSA: virtio: introduce device suspend/resume support Anton Yakovlev
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=52f71ac6-3ec7-2884-7a64-1995f416d20a@opensynergy.com \
--to=anton.yakovlev@opensynergy.com \
--cc=alsa-devel@alsa-project.org \
--cc=guennadi.liakhovetski@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®