Message ID | 20230126135552.3625887-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp285468wrn; Thu, 26 Jan 2023 06:04:05 -0800 (PST) X-Google-Smtp-Source: AMrXdXs0jiex8Tl/RIYQ/JOW9d+0R53Q2AZSFte70RZwNzb2PMvz1lwoWq1nvfjVZZVmnVu8OcHz X-Received: by 2002:a17:902:8492:b0:18f:438a:cfe1 with SMTP id c18-20020a170902849200b0018f438acfe1mr32692252plo.59.1674741845054; Thu, 26 Jan 2023 06:04:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674741845; cv=none; d=google.com; s=arc-20160816; b=WAUuU6KzV3aYRwj2T+LPidlYGvcfOhgj8JCci0HhOVrunPhIQYvMQMt54j9cg/823q g6o/0/xiWsG7Tu33FOBbMfQYily65hpnxBzR/gvu88FWwbJ5suGITPgkPf3G4E5AZluW mW543dfvtYzeg3sq2o1a/9H239PIRVcuRU94uAPWJurVKES19NPrk4vtMu5XO9feglSj P4LSVmHrysyXfF9o1rWFWuzclF9W3Xdi5Css/xugSNv2zT9pal0djsgRDxFQT+Haukvn hwFz+MndQZkB3IOj+WH7m7zOg0YIW7ZbQUeGbaz+eQ43nh4rmvJwlX/VuAqh4hmRI8DM cVsA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=izw1QC1avhAlkHYZGGDfkuSWY5QLNju8yexTUXCaYr4=; b=cWCvjIcyUvHylnX6jCrJN89ZRMf+eis2UDKsRezwY1mcCMeg9n01uvY1aVW87qneFU nzg1TjD2WYKgRuum36CA7wQG5i1fDi23q+HCLJSKw2MuJ7nNJdWEGsriNYEHfkKxmjQ4 Q1bB6H0xU9EMrqGxrK/wSp+Xrel1o/ug5Zl4u8egmy+dmV72HeU14nmDtCwffFG1wVH0 v7I46oocl+UDlg9XGMbxjzc3HCLPs4dTiHkXZvE+Yowganlcr+cmUZNLq5l5uZqOVr1h Vutw/i8xbTb0v2o00tARpH6qH9TxwCEiQ0FdVhURN6t/fnaLM74qAZMSvNZr+kq2B68G o1WQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J+zABWma; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f6-20020a170902ce8600b00189239e6a29si1774649plg.95.2023.01.26.06.03.51; Thu, 26 Jan 2023 06:04:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=J+zABWma; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229791AbjAZN43 (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Thu, 26 Jan 2023 08:56:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229469AbjAZN42 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Jan 2023 08:56:28 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0ED940C7; Thu, 26 Jan 2023 05:56:06 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C4E70B81DC3; Thu, 26 Jan 2023 13:56:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 526B0C433EF; Thu, 26 Jan 2023 13:55:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674741359; bh=+zcnVOvMv0ffroVlt9v3selx4PLrSDPJU27GIQqf5CI=; h=From:To:Cc:Subject:Date:From; b=J+zABWmav20VRHzPY06ARHMEbCGnJ0Uw/wiRy/BiN4s57VOAn9bMYGW97ll3NRNth BbowmeIp/RsueWsVjFiO/oWS0EfEUTZrp1dw4vA9DAWvJNb4zVB2FPFcKo4VNnuB75 vtounBE55vnd87GjrqyqQ4aGNfFZqVPGZYEK33RjPntUPOg2npp4aZbpmerJweEcjP i5LgP7E8yldMVmt3+LVvgEjxBUB4d0YG1D+6w0VogOl9MpWtpDK/tWYs4WGL5Vi7UN s+YBYjxTxFGigs4H2uaJgcyIYVHQEMKn4+thdjtTfInYHnxdpMaHUsEVSilbHEobEi esTwUg22PgY7g== From: Arnd Bergmann <arnd@kernel.org> To: James Schulman <james.schulman@cirrus.com>, David Rhodes <david.rhodes@cirrus.com>, Lucas Tanure <tanureal@opensource.cirrus.com>, Richard Fitzgerald <rf@opensource.cirrus.com> Cc: linux-gpio@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Charles Keepax <ckeepax@opensource.cirrus.com>, Wolfram Sang <wsa@kernel.org>, alsa-devel@alsa-project.org, patches@opensource.cirrus.com, linux-kernel@vger.kernel.org Subject: [PATCH] ASoC: cs42l56: fix DT probe Date: Thu, 26 Jan 2023 14:55:29 +0100 Message-Id: <20230126135552.3625887-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756094105078247235?= X-GMAIL-MSGID: =?utf-8?q?1756094105078247235?= |
Series |
ASoC: cs42l56: fix DT probe
|
|
Commit Message
Arnd Bergmann
Jan. 26, 2023, 1:55 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> While looking through legacy platform data users, I noticed that this one could never be used with DT based probing as the platform_data structure gets overwritten directly after it is initialized. There have never been any boards defining the platform_data in the mainline kernel either, so this driver so far only worked with patched kernels. For the benefit of possible downstream users, fix the DT probe by no longer overwriting the data. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- sound/soc/codecs/cs42l56.c | 6 ------ 1 file changed, 6 deletions(-)
Comments
On Thu, Jan 26, 2023 at 02:55:29PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > While looking through legacy platform data users, I noticed that > this one could never be used with DT based probing as the > platform_data structure gets overwritten directly after it > is initialized. > > There have never been any boards defining the platform_data in > the mainline kernel either, so this driver so far only worked > with patched kernels. Or there is no mandatory properties/platform data and the defaults are fine for most systems (which is a common case).
On Thu, Jan 26, 2023 at 02:03:35PM +0000, Mark Brown wrote: > On Thu, Jan 26, 2023 at 02:55:29PM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > While looking through legacy platform data users, I noticed that > > this one could never be used with DT based probing as the > > platform_data structure gets overwritten directly after it > > is initialized. > > > > There have never been any boards defining the platform_data in > > the mainline kernel either, so this driver so far only worked > > with patched kernels. > > Or there is no mandatory properties/platform data and the > defaults are fine for most systems (which is a common case). I think Arnd is right here, the driver appears to allocate a big block of zeros and then blat that over the top of everything it read from device tree. So you can literally never use any of the DT properties as it stands. Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Thanks, Charles
On Thu, Jan 26, 2023 at 02:46:35PM +0000, Charles Keepax wrote: > On Thu, Jan 26, 2023 at 02:03:35PM +0000, Mark Brown wrote: > > Or there is no mandatory properties/platform data and the > > defaults are fine for most systems (which is a common case). > I think Arnd is right here, the driver appears to allocate a big > block of zeros and then blat that over the top of everything it > read from device tree. So you can literally never use any of the > DT properties as it stands. Oh, the fix is fixing a real issue - it's the claim in the commit log that the driver could never have worked that's not obviously correct.
diff --git a/sound/soc/codecs/cs42l56.c b/sound/soc/codecs/cs42l56.c index 26066682c983..3b0e715549c9 100644 --- a/sound/soc/codecs/cs42l56.c +++ b/sound/soc/codecs/cs42l56.c @@ -1191,18 +1191,12 @@ static int cs42l56_i2c_probe(struct i2c_client *i2c_client) if (pdata) { cs42l56->pdata = *pdata; } else { - pdata = devm_kzalloc(&i2c_client->dev, sizeof(*pdata), - GFP_KERNEL); - if (!pdata) - return -ENOMEM; - if (i2c_client->dev.of_node) { ret = cs42l56_handle_of_data(i2c_client, &cs42l56->pdata); if (ret != 0) return ret; } - cs42l56->pdata = *pdata; } if (cs42l56->pdata.gpio_nreset) {