On Wed, 03 Feb 2021 18:34:12 +0100, Anton Yakovlev wrote: > > Hi Takashi, > > > On 03.02.2021 17:59, Takashi Iwai wrote: > > On Tue, 02 Feb 2021 00:18:09 +0100, > > Anton Yakovlev wrote: > >>>> +/** > >>>> + * 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. > > > > What is this "reset" actually supposed to do? Reconfguring > > everything, or changing only certain parameters, devices, whatever? > > It means bringing this particular device to its initial state. > > After that, the driver can re-read the configurations from the device > and reconfigure everything. So all running processes have to be finished before starting resetting? It sounds indeed like a complete device re-binding, and if so, doing with the proper dev_*() API might be saner than the brute force bus->remove() and bus->probe() calls... thanks, Takashi