Received: by 2002:a05:6a10:6d25:0:0:0:0 with SMTP id gq37csp1532043pxb; Sun, 12 Sep 2021 23:00:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVLF72GeeI0xUnwTFnutb+Jgm0hV6RAaRbhMQiwszpQ32xj/15mE3iDsPOiHR7aaJZ9iZs X-Received: by 2002:a17:906:7047:: with SMTP id r7mr10626871ejj.342.1631512807352; Sun, 12 Sep 2021 23:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631512807; cv=none; d=google.com; s=arc-20160816; b=HTFnNJkZ8Zo3cW3TM9enBd0BrA1Pwdy7v2qlWKNjpSy2jH3H/69hbIb7ynT+huM8XW XLMC948Jlvvx3NkwoJ+8crJ64YJSzKdoHKswLp5heTfj/8m6N2KxdxQNJ2al6Yqn9IQW EvGPYK/dAfbInnx0cQAfGGVQClU1gGUpDer1diLhHtghxMHOwywt3ILmVNcTnDInxVWB 2IVklb+fffNe4xbVB5TmqGvU2R650Qo4uT8hhTp9N4Gzkc7RPty/vp++VA0MZ9qb1Mb7 /6/VsuQBRV7MJ8/xwzQoY4lop90IaWzg81UIFpR+LjfYMC4py609SiDiOaFxnVE9Id4e Wzrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=u7buPNW+pfAeliRrTenGR69kaJ/O3uRi8ToYPHZhMmw=; b=K18hdy6cczBTdxazM2TE5ujAYzSixWTYq8nHUk67wwHnQMXrbN3r8cyfoexlchDul0 u2/XEfXdvQM2i1D9kz4myzoKtedj30zRlLM8y4W63RrdB/0eBJIfHBfb5Ju7zXF4EoUN nUYgPpMkaJ6SuQtl7b2J6XwhhY0yXHIWldiQhyWsqmNHeSus4JCZ979BoZXnA27P7LBX qFKDgZ011M+9gCeY5lX5Fx0YTaWDl1sCoys9M+YOcbg2M4eMCM7Bfg5Jv/joT0PohkBp LUBkPfDCon4AO7L1BzSg3V9g00t+wu+TbhDlMzbA8DfwrkbFfrn3sBP8URlHCTJLo5Rj Ikbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p16si6431621edq.563.2021.09.12.22.59.43; Sun, 12 Sep 2021 23:00:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237062AbhIMF47 (ORCPT + 99 others); Mon, 13 Sep 2021 01:56:59 -0400 Received: from mailgw01.mediatek.com ([60.244.123.138]:52842 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S237095AbhIMF46 (ORCPT ); Mon, 13 Sep 2021 01:56:58 -0400 X-UUID: a04d09bb2c8a4bf0aef64581cadeaee6-20210913 X-UUID: a04d09bb2c8a4bf0aef64581cadeaee6-20210913 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1343577215; Mon, 13 Sep 2021 13:55:40 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs06n2.mediatek.inc (172.21.101.130) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Sep 2021 13:55:38 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 13 Sep 2021 13:55:38 +0800 Message-ID: <5fa1e99f1b9097336a3e610dc383170f09036b14.camel@mediatek.com> Subject: Re: [PATCH v2] ASoC: mediatek: common: handle NULL case in suspend/resume function From: Trevor Wu To: Mark Brown CC: , , , , , , Date: Mon, 13 Sep 2021 13:55:38 +0800 In-Reply-To: <20210910102358.GC4474@sirena.org.uk> References: <20210910092613.30188-1-trevor.wu@mediatek.com> <20210910102358.GC4474@sirena.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2021-09-10 at 11:23 +0100, Mark Brown wrote: > On Fri, Sep 10, 2021 at 05:26:13PM +0800, Trevor Wu wrote: > > > When memory allocation for afe->reg_back_up fails, reg_back_up > > can't > > be used. > > Keep the suspend/resume flow but skip register backup when > > afe->reg_back_up is NULL, in case illegal memory access happens. > > It seems like it'd be better to just allocate the buffer at probe > time > and fail in case we can't get it, I'd be surprised if there's many > platforms using this hardware that don't also end up suspending and > resuming. Hi Mark, Thanks for your suggestion. I agree it's better to allocate the memory at probe time. I think we can still keep the implementation in the suspend/resume function as a fallback solution if user doesn't allocate the memory in probe function. In the new mediatek SOCs, regcache has been used to handle register backup. Do I need to add the buffer allocation on probe function to the platform in which mtk_afe_suspend and mtk_afe_resume are used? Thanks, Trevor