From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0656C433E6 for ; Wed, 3 Feb 2021 17:41:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 914F664F87 for ; Wed, 3 Feb 2021 17:41:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231794AbhBCRkn (ORCPT ); Wed, 3 Feb 2021 12:40:43 -0500 Received: from mx2.suse.de ([195.135.220.15]:50088 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbhBCRkl (ORCPT ); Wed, 3 Feb 2021 12:40:41 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A736EACB7; Wed, 3 Feb 2021 17:39:59 +0000 (UTC) Date: Wed, 03 Feb 2021 18:39:59 +0100 Message-ID: From: Takashi Iwai To: Anton Yakovlev Cc: Guennadi Liakhovetski , , , , , Jaroslav Kysela , Takashi Iwai , "Michael S. Tsirkin" Subject: Re: [virtio-dev] Re: [PATCH v2 2/9] ALSA: virtio: add virtio sound driver In-Reply-To: References: <20210124165408.1122868-1-anton.yakovlev@opensynergy.com> <20210124165408.1122868-3-anton.yakovlev@opensynergy.com> <8754dae8-114-6383-510-de2ba9dc4fa@intel.com> <52f71ac6-3ec7-2884-7a64-1995f416d20a@opensynergy.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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