Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp905666pxb; Fri, 21 Jan 2022 06:05:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJzG+tw4E3sSeXsfZP4eUrPIJbUzXMiflD+MnDjzR0sEdxDSQJvwMv7LfW0cQ+OFMP21Mp8N X-Received: by 2002:a17:902:bd05:b0:148:a2e8:2c3d with SMTP id p5-20020a170902bd0500b00148a2e82c3dmr4102151pls.140.1642773932437; Fri, 21 Jan 2022 06:05:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642773932; cv=none; d=google.com; s=arc-20160816; b=ma+2bre8B+MHUdfKa141RF6bzZk9GaplC2wWuAyMLNI/2tojGj5Ak9l6NMGVqZNoTn BG7Cxv/vrmDoYtvQ4CgA7SXrZkDRKXD4/uHHji5XC1t570Y9EBn2oS9ymSZviHAQ7OsV ecU5dbPzjSlTBFSPwEHFKze74LvbYPmyhiw/SCPwil/TODfajt/+5YopdtHMJ2ucDKsg jW9xzHfcEBT9/gj3xhxkFwftkdysZI6zG6pbUxm4YR3H2sGmTwQYAPdDo/hak1WfLp28 nJTDr6Ux+ec0d1L1eafa2Yocc3rBRg9+scu1llD2OpDJ5MPW+9l7RmNMeMfVeTVGFJSe mvFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:date:to:cc:from:subject :references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=9Tgdlz0ti2j/0aPwOiAjBa6VCSaOQWR/5zSY8VCtax4=; b=HoRBvUo9XQYIz6Si8CjsC7CYpe6GB4JXMGWw8CDGsAe92shXxgqfkkieY0rOaexj37 nZrHNriB1/CpTmun3J99p7imDYgZnlkMVQBrWcDo9tSPk/pUV6QBqY+3n0C1TZOsY9Re gG2j2jJ0ZdXl46pZtVMU4gWS12z660Yq1f5CVzHFzlDy1CAS3n4CtA2NxrKI7nKBVce3 cqd4t2cCCScj9L67DQL+TCCZOm6vJNcRSUrDVeEJIOr9//x8Dj/BQJkOSNzNiuJftvjh y1hpxYe9E7n69+ZrhGO/+XqbWbxg6JIXG5i7Qlb2v418awbMqt6hpg6Ci9rEjBy7YX6n jnLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gQBiIfrS; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l68si272657pfl.186.2022.01.21.06.05.20; Fri, 21 Jan 2022 06:05:32 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=gQBiIfrS; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350915AbiASCWX (ORCPT + 99 others); Tue, 18 Jan 2022 21:22:23 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:38574 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238636AbiASCWW (ORCPT ); Tue, 18 Jan 2022 21:22:22 -0500 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 dfw.source.kernel.org (Postfix) with ESMTPS id E5DE861523; Wed, 19 Jan 2022 02:22:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AF83C340E0; Wed, 19 Jan 2022 02:22:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642558941; bh=TUaPuu1VvMddn53j9AqDwXehQaQWuB7rudQxVqafxIs=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=gQBiIfrSi8SbwNyqk7TR3sDQFgUvzBwxm3ZoeDaZR5VtOKRqN8TS/8qo+1lH1yeHX p+orgMaJd33+92x7qXCFDIam92CgcOvBXrmCMRVVmr9E/JcIojjNXaqLbU4djY5lxP 0Sqj6okrbhJoDOYGgqdzKltj3n+0bl6WNCHYx5liZP0qw9BZknOw15II9dwLWHkWFV 11BsWVmQqE2jdrGu30C+fycF2JZDlowOpe2sbKT6NMBtEzHj9THC4bSHxpJuZLz+Ma Yo8rEzWLIism0INmF+JM4e2OQTfvIkMkwgKGvaOCV0lKw6ZbQKHKi36hzHpEbK/xFg Kg3oXwQZrB4EQ== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20220113115745.45826-1-liang.yang@amlogic.com> <20220113115745.45826-5-liang.yang@amlogic.com> <20220113213513.9819AC36AEA@smtp.kernel.org> <09ff9044-9abc-d1ad-26c1-5e6ece56d30c@amlogic.com> <20220114230130.35EAAC36AE7@smtp.kernel.org> Subject: Re: [PATCH v9 4/4] clk: meson: add sub MMC clock controller driver From: Stephen Boyd Cc: Martin Blumenstingl , Jianxin Pan , Victor Wan , XianWei Zhao , Kelvin Zhang , BiChao Zheng , YongHui Yu , linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org To: Jerome Brunet , Kevin Hilman , Liang Yang , Michael Turquette , Neil Armstrong , Rob Herring , linux-clk@vger.kernel.org Date: Tue, 18 Jan 2022 18:22:19 -0800 User-Agent: alot/0.10 Message-Id: <20220119022221.3AF83C340E0@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Liang Yang (2022-01-16 22:24:28) >=20 >=20 > On 2022/1/15 7:01, Stephen Boyd wrote: > > [ EXTERNAL EMAIL ] > >=20 > > Quoting Liang Yang (2022-01-13 21:14:46) > >> On 2022/1/14 5:35, Stephen Boyd wrote: > >>> Quoting Liang Yang (2022-01-13 03:57:45) > >>>> diff --git a/drivers/clk/meson/mmc-clkc.c b/drivers/clk/meson/mmc-cl= kc.c > >>>> new file mode 100644 > >>>> index 000000000000..f53977f61390 > >>>> --- /dev/null > >>>> +++ b/drivers/clk/meson/mmc-clkc.c > >>>> @@ -0,0 +1,300 @@ > > [..] > >>>> + > >>>> +static int mmc_clkc_probe(struct platform_device *pdev) > >>>> +{ > >>>> + struct clk_hw_onecell_data *onecell_data; > >>>> + struct device *dev =3D &pdev->dev; > >>>> + struct mmc_clkc_data *data; > >>>> + struct regmap *map; > >>>> + struct clk_regmap *clk, *core; > >>>> + struct meson_sclk_div_data *div_data; > >>>> + > >>>> + /*cast to drop the const in match->data*/ > >>> > >>> Space after *, also why do we need to cast away const? The user of th= is > >>> pointer passes it all the way down to mmc_clkc_register_clk() which > >>> could take the data as const void pointer and decide to cast away con= st > >>> there. > >> > >> if use 'const' here, it will report a warning: > >> drivers/clk/meson/mmc-clkc.c:224:7: error: assignment discards =E2=80= =98const=E2=80=99 > >> qualifier from pointer targe > >> t type [-Werror=3Ddiscarded-qualifiers] > >> > >> data =3D (const struct mmc_clkc_data *)of_device_get_match_data(de= v); > >=20 > > Of course. The type declaration up above needs const added to it.The pa= rm of mmc_clkc_register_clk_with_parent(...., void *data) does not=20 > have 'const', so make the type declaration cause a further 'const' cast=20 > warning. Could i copy these infos just like below: Why can't you push const down to the function that really cares to remove const?