Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935677AbcCQKjC (ORCPT ); Thu, 17 Mar 2016 06:39:02 -0400 Received: from mga11.intel.com ([192.55.52.93]:44948 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932931AbcCQKjA (ORCPT ); Thu, 17 Mar 2016 06:39:00 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,349,1455004800"; d="scan'208";a="935896933" From: "Pan, Harry" To: "broonie@kernel.org" CC: "lgirdwood@gmail.com" , "linux-kernel@vger.kernel.org" , "gs0622@gmail.com" , "alsa-devel@alsa-project.org" , "tiwai@suse.com" , "perex@perex.cz" Subject: Re: [PATCH] ASoC: dapm: Do not traverse widget hooks to snd-soc-dummy Thread-Topic: [PATCH] ASoC: dapm: Do not traverse widget hooks to snd-soc-dummy Thread-Index: AQHRf3aMxa2bWOYG7kihrqwHUdc/3p9c4P8AgAAMSIA= Date: Thu, 17 Mar 2016 10:38:36 +0000 Message-ID: <1458211115.965.13.camel@intel.com> References: <1458127071-14417-1-git-send-email-harry.pan@intel.com> <20160317095438.GD2566@sirena.org.uk> In-Reply-To: <20160317095438.GD2566@sirena.org.uk> Accept-Language: zh-TW, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.5.232.36] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u2HAdBda018348 Content-Length: 1292 Lines: 36 On Thu, 2016-03-17 at 09:54 +0000, Mark Brown wrote: > On Wed, Mar 16, 2016 at 07:17:51PM +0800, Harry Pan wrote: > > > Conflicts: > > sound/soc/soc-dapm.c > > Don't include noise like this in upstream submissions. > I learned, thanks. > > + if (!strcmp(cmpnt->name, "snd-soc-dummy")) > > + return 0; > > + > > This doesn't make much sense and is going to be very fragile. We > should either make the dummy component look like other components or > make the code cope with them as they stand, that way we don't have > random undocumented special cases scattered through the code. Probably > it's better to make the dummy component look like others. I do agree, basically. Allow me to explain more detail that I saw during debug; since the commit 6e78108bda78 (ASoC: core: Don't probe the component which is dummy), an exception has been made that dummy component won't be probed, thus the 'card' passed into soc_probe_component() would not be assigned to this component. In the other hand, the component struct is initially created in snd_soc_register_platform() by kzalloc() of platform struct, its 'card' pointer is remaining an NULL pointer even the widget node being read. Perhaps another option is to refine soc_probe_component(), which I have not dive in. Sincerely, Harry