Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp214816imu; Tue, 8 Jan 2019 18:10:54 -0800 (PST) X-Google-Smtp-Source: ALg8bN7N60Sed1+yPDy+6vgczjFmp3ie7p1iF7OQ13uoNvMZxS9wzArKWXVG6sr43p/4sHCftW8/ X-Received: by 2002:a63:5907:: with SMTP id n7mr3687555pgb.435.1546999854229; Tue, 08 Jan 2019 18:10:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546999854; cv=none; d=google.com; s=arc-20160816; b=j5fZhz88R3jPwq4emPGhHckIRg+4DwjOt9AtGz1Xu3xM7bEbgFFagFIWIBNICuNqlK SQocvz4XgCw7buVFWFEhxAfigQdZZ27xmOLusNeopUhNhBDeTt+S07ui7qWH/2exPTQL x/X27JBrRT1ccIa+DQ9DkBBuUPFI+CL9t9Oipx2rISQkr2ikqTJvAU887lZyiL67vl94 epekWsM9Gi9R7yEFzgU4EN6gYYI3PE+gbBe86hn+T/U44efjfZB9kLazWRtq6l6vqU3i URez6aBmSHd2VH2CJiBjcD+Ev2yWUzCTgefg9LihEZQ0+p8q8ejQcz0g85q8lT5P+m0c 2H3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=gXdwQeAlh9MBjGInew0xekEnrOAlo9n+g/iVlo2iVSA=; b=BIJKOfW9+qChSVkfal1OHIsPo9VC64oK+GnRW24BxqwFzQiAn/0lawUTi5kCiWJnZB ePZSGjqgl6gSjfQ+Du2l4SBZYwMlYESkCTwUF6ArwZf6zoN2TZmHJzPLcnfH6h9U9FpQ zlgdhuPFJgnyhEesVnEvWDS2YE6iIN7rMrRKQBgMRpa8IhdzswCsiZ8UQrnV6G4RBCoS C9D/Lo86g/ojY5ewC3I158jEW82WUyCYUASDibXKsd0G0Qsw7SkZaEcRdbvrbXcSOJwV U0EJauupOJeOPb7kLFYvtNmV/G45ElFGcUh93slHNliflkh0kPnekgGHgVRB8i0XASBn NKZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w185si23865958pgd.518.2019.01.08.18.10.38; Tue, 08 Jan 2019 18:10:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729380AbfAICJb (ORCPT + 99 others); Tue, 8 Jan 2019 21:09:31 -0500 Received: from relmlor2.renesas.com ([210.160.252.172]:11057 "EHLO relmlie6.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729120AbfAICJa (ORCPT ); Tue, 8 Jan 2019 21:09:30 -0500 Date: 09 Jan 2019 11:09:28 +0900 X-IronPort-AV: E=Sophos;i="5.56,455,1539615600"; d="scan'208";a="4500369" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie6.idc.renesas.com with ESMTP; 09 Jan 2019 11:09:28 +0900 Received: from morimoto-PC.renesas.com (unknown [10.166.18.140]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id 4233841A7CF7; Wed, 9 Jan 2019 11:09:28 +0900 (JST) Message-ID: <87imyy382r.wl-kuninori.morimoto.gx@renesas.com> From: Kuninori Morimoto To: Jon Hunter Cc: Liam Girdwood , Mark Brown , , , , Marcel Ziswiler , Matthias Reichl Subject: Re: [PATCH] ASoC: core: Fix deferral of machine drivers In-Reply-To: <1546968494-22993-1-git-send-email-jonathanh@nvidia.com> References: <1546968494-22993-1-git-send-email-jonathanh@nvidia.com> User-Agent: Wanderlust/2.15.9 Emacs/24.5 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jon > Commit daecf46ee0e5 ("ASoC: soc-core: use snd_soc_dai_link_component for > platform") added a new member to the snd_soc_dai_link structure for > storing a pointer for a platform link component. The pointer for this > platform link component was allocated, if not already populated by the > machine driver, using devm_kzalloc() such that the memory would be > automatically freed on error or removal of the soundcard. However, this > introduced a new problem, because if the probing of the soundcard is > deferred, then although the memory allocated for the platform link > component is freed, if the snd_soc_dai_link structure is declared > statically by the machine driver, then the pointer in the DAI link > structure will never be clearer. This means that when the soundcard is > probed again, memory for the platform link component will not be > allocated again because the address of the pointer was not cleared > and this causes sound core to access memory that is no longer valid. > > In most cases this causes the following error condition to be triggered > and causes probing the soundcard to fail. > > tegra-snd-sgtl5000 sound: ASoC: Both platform name/of_node are set for > sgtl5000 > > Unfortunately, because this platform link component is allocated before > the DAI links are added to the soundcard, there is no easy way to clear > this pointer on teardown if an error occurs. > > The pointer for this platform link component was added for future > proofing and communalising the structures for storing various data. > Although a machine driver maybe used by more than one platform and so > this platform data may vary from platform to platform, there is only > ever a single instance for a given platform. Therefore, rather than > dynamically allocate the platform link component structure, make it a > static member of the snd_soc_dai_link to fix the problem. > > It should be noted that if the platform_name of platform_of_node members > of the snd_soc_dai_link structure are populated, these will always be > used regardless of if the new platform.name or platform.of_node members > are populated. > > Fixes: daecf46ee0e5 ("ASoC: soc-core: use snd_soc_dai_link_component for platform") > > Reported-by: Marcel Ziswiler > Signed-off-by: Jon Hunter > --- Thank you for your patch. The reason why it is allocating memory is it is for glue Legacy vs Modern style. This means, this allocation style will be removed if ALSA SoC become modern style. The missing part so far is CPU. Only CPU is not yet supporting snd_soc_dai_link_component style. If all CPU/Codec/Platform supports snd_soc_dai_link_component style, all driver can switch to it, and then, all will be static style. Currently, simple card series is only(?) using this style. The reason why platform is using pointer style is that someone (not me ;P) will support multi platform style in the future. Best regards --- Kuninori Morimoto