Received: by 10.223.148.5 with SMTP id 5csp6344644wrq; Wed, 17 Jan 2018 12:29:37 -0800 (PST) X-Google-Smtp-Source: ACJfBothQsoLbeXgbx8HOJ/5Ss2W/XNiEjv/8wlIlGJ8My/9zoS05xyQSOEN/PCyKJRMbKGRzdDG X-Received: by 10.84.130.68 with SMTP id 62mr12227894plc.409.1516220977775; Wed, 17 Jan 2018 12:29:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516220977; cv=none; d=google.com; s=arc-20160816; b=urTnfvcralVA5AqfnaOGsnNCE4QHULdE7zzVrae+Vvs7GskXxLx5ngX6ClI/IdT+6P M5NZeqD1zBssnuzO/gol2+SYStrxbPL8Wwuna3VaRy3XZWS50q/RGcWkx0aTcYmI6zbW odUefpdQ5M5tTR7/IREEvd7x5bp6hQ0L/LMpppAcF7KBcZSxke4r66Xu0ndyae8V+UTq 0Pr4NrkTmwmztyNFQs56/hXChzAyK7Oj439w599J4c1c+jbRpGniseSSDIQjvdk+pFXM uh9gq0C+A8PavS67bCPfDhYIzB1M8AE7vXUCMRqsGd9WFvyMaH2xXwM7EiH6Pq5Ohrxn 2DnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=FSPqAqvpfzXAFzT69GTCAJak1iklLoSktebG+NcZvjY=; b=HRYWvgQbVT0kc1LKANmpdLplqJgSnKSB7jm13JK/YNVv2Faqgh2h17m1vaOFwX446z 3LwGhnOC4nrkMBlEVKG8niZkOPs5z4AouyNd1cWF9KxqH22/NmIW009B9KlwrMuawNhd YBShiVp3HrYupS4OqT1DLp06U+kIbioJX4eMy+H1oVcc3CL4/TY/PCRsbpADEKAzm7Bo O5HAbpwkhHs078zwxpTWxxB/sYAQi/6/YBUFlAEJSRGMUiBroweNv1vNk8Y0G9JI+rGn IzY6JqoBQq+Sc0HlrxDggVBv942H/uhrtrBDJA67gdI2PR5hf5Qq5vH++u0+8mCPpcmm 3lUA== 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 44si5272174plc.40.2018.01.17.12.29.23; Wed, 17 Jan 2018 12:29:37 -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 S1754415AbeAQU2N (ORCPT + 99 others); Wed, 17 Jan 2018 15:28:13 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:40676 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753278AbeAQU2L (ORCPT ); Wed, 17 Jan 2018 15:28:11 -0500 Received: by vps-vb.mhejs.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ebuJP-0000NP-6K; Wed, 17 Jan 2018 21:27:55 +0100 Subject: Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level To: Nicolin Chen Cc: timur@tabi.org, broonie@kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, alsa-devel@alsa-project.org, lgirdwood@gmail.com, fabio.estevam@nxp.com, caleb@crome.org, arnaud.mouiche@invoxia.com, lukma@denx.de, kernel@pengutronix.de References: <1516171902-32669-1-git-send-email-nicoleotsuka@gmail.com> <20180117200210.GA9523@Asurada-Nvidia> From: "Maciej S. Szmigiero" Message-ID: <708b241d-43b3-96af-909c-81093f9753e9@maciej.szmigiero.name> Date: Wed, 17 Jan 2018 21:27:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20180117200210.GA9523@Asurada-Nvidia> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17.01.2018 21:02, Nicolin Chen wrote: > On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote: > >> However, I have a small nitpick regarding a comment newly added in >> this version of patch 16: >> + /* >> + * Do not set SSI dev as the parent of AC97 CODEC device since >> + * it does not have a DT node. Otherwise ASoC core will assume >> + * CODEC has the same DT node as the SSI, so it may return a >> + * NULL pointer of CODEC when asked for SSI via the DT node >> >> The second part of the last sentence isn't really true, the ASoC core >> will return a (valid, non-NULL) CODEC object pointer when asked for >> the SSI one if we set the SSI as the parent device of a AC'97 CODEC >> platform device. >> >> The NULL pointer dereference when starting a playback that I wrote >> about in my previous message happens because in this situation the SSI >> DAI probe callback won't ever get called and so won't setup DMA data >> pointers (they will remain NULL). > > Well, somehow the DMA data pointer of CODEC could be described > as "a NULL pointer of CODEC" reluctantly...it confuses people > though. > >> And this in turn will cause the ASoC DMA code to dereference these >> NULL pointers when starting a playback (the same will probably happen >> also when starting a capture). >> >> Sorry if I wasn't 100% clear about these details in my previous >> message describing this issue. > > I would prefer to send an incremental patch later to update it, > if there are no new comments against this version; Otherwise, I > will update it in a next version once there is a need to send a > v6 anyway. IMHO it is such a tiny thing that it isn't worth respinning 17 patch series just for it, it can be easily improved later via a separate patch. > Thanks > Thanks, Maciej