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=-0.8 required=3.0 tests=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 6C45FC433E0 for ; Tue, 26 May 2020 13:37:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4F7F4204EF for ; Tue, 26 May 2020 13:37:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729349AbgEZNhj (ORCPT ); Tue, 26 May 2020 09:37:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:47366 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729079AbgEZNhj (ORCPT ); Tue, 26 May 2020 09:37:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3777BADB3; Tue, 26 May 2020 13:37:40 +0000 (UTC) Date: Tue, 26 May 2020 15:37:36 +0200 Message-ID: From: Takashi Iwai To: Pierre-Louis Bossart Cc: Greg KH , Jason Gunthorpe , Ranjani Sridharan , Jeff Kirsher , davem@davemloft.net, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com, Fred Oh Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client In-Reply-To: References: <20200520070227.3392100-1-jeffrey.t.kirsher@intel.com> <20200520070227.3392100-11-jeffrey.t.kirsher@intel.com> <20200520125437.GH31189@ziepe.ca> <08fa562783e8a47f857d7f96859ab3617c47e81c.camel@linux.intel.com> <20200521233437.GF17583@ziepe.ca> <7abfbda8-2b4b-5301-6a86-1696d4898525@linux.intel.com> <20200523062351.GD3156699@kroah.com> <57185aae-e1c9-4380-7801-234a13deebae@linux.intel.com> <20200524063519.GB1369260@kroah.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 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Tue, 26 May 2020 15:15:26 +0200, Pierre-Louis Bossart wrote: > > > > On 5/24/20 1:35 AM, Greg KH wrote: > > On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote: > >> > >> > >> On 5/23/20 1:23 AM, Greg KH wrote: > >>> On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote: > >>>> This is not an hypothetical case, we've had this recurring problem when a > >>>> PCI device creates an audio card represented as a platform device. When the > >>>> card registration fails, typically due to configuration issues, the PCI > >>>> probe still completes. > >>> > >>> Then fix that problem there. The audio card should not be being created > >>> as a platform device, as that is not what it is. And even if it was, > >>> the probe should not complete, it should clean up after itself and error > >>> out. > >> > >> Did you mean 'the PCI probe should not complete and error out'? > > > > Yes. > > > >> If yes, that's yet another problem... During the PCI probe, we start a > >> workqueue and return success to avoid blocking everything. > > > > That's crazy. > > > >> And only 'later' do we actually create the card. So that's two levels > >> of probe that cannot report a failure. I didn't come up with this > >> design, IIRC this is due to audio-DRM dependencies and it's been used > >> for 10+ years. > > > > Then if the probe function fails, it needs to unwind everything itself > > and unregister the device with the PCI subsystem so that things work > > properly. If it does not do that today, that's a bug. > > > > What kind of crazy dependencies cause this type of "requirement"? > > I think it is related to the request_module("i915") in > snd_hdac_i915_init(), and possibly other firmware download. > > Adding Takashi for more details. Right, there are a few levels of complexity there. The HD-audio PCI controller driver, for example, is initialized in an async way with a work. It loads the firmware files with request_firmware_nowait() and also binds itself as a component master with the DRM graphics driver via component framework. Currently it has no way to unwind the PCI binding itself at the error path, though. In theory it should be possible to unregister the PCI from the driver itself in the work context, but it failed in the earlier experiments, hence the driver sets itself in a disabled state instead. Maybe worth to try again. But, to be noted, all belonging sub-devices aren't instantiated but deleted at the error path. Only the main PCI binding is kept in a disabled state just as a place holder until it's unbound explicitly. Takashi