| Message ID | 20221018160352.1591428-1-dario.binacchi@amarulasolutions.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-amarula+bncBCQ4XFG47UFRB3M4XONAMGQEZIKIJNA@amarulasolutions.com> X-Original-To: linux-amarula@patchwork.amarulasolutions.com Delivered-To: linux-amarula@patchwork.amarulasolutions.com Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by ganimede.amarulasolutions.com (Postfix) with ESMTPS id 926E140F4C for <linux-amarula@patchwork.amarulasolutions.com>; Tue, 18 Oct 2022 18:03:57 +0200 (CEST) Received: by mail-ej1-f71.google.com with SMTP id sh33-20020a1709076ea100b0078d28567b70sf6709441ejc.16 for <linux-amarula@patchwork.amarulasolutions.com>; Tue, 18 Oct 2022 09:03:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1666109037; cv=pass; d=google.com; s=arc-20160816; b=B0eVwk6KdxZ/NvopgDpCpjxJD+u+0D0hTGnczQl6Jfkn/KIQI43dqodQE/c4wBKlbX MbeaTinp9rylyTkF+109Dawswn3tlYyg1OZOGYAPWhL+A0wzbEVNiJfDKajkuH7srDFR K9paeZrRVkToSlkvWwWqHDTzLMfESp4i4WnJg7dgsdMGfiWZyDdb9ZjNmHIen0LjxgNV PiJawkYztP9yefQXOHbNDvqXVCtzFcRLvOgxDrylsMDp6v4O3bdslMG9RX2JkUyrVdra 91iMRZlyruIvNXFbvuUjoYAmmWlMdItp/J5FTfPyaQwewOGuo7g28pXHAdHKgtqq+9yP TOgQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:mime-version:message-id:date:subject:cc:to :from:dkim-signature; bh=GcXooDewB2Uu/2RKidNo2EFYvdUIKguHYovtCm1c7o4=; b=iQNNny7Elni3So5klbeNy6JNXVbpcxF2a6azV5vpszBOv8d0nz0UvoVanEmuDcYAJm uiA1TezXMX8hWVTYq6gJn0/6gA0wTNTdhwqcILNSuvreIgavm7n/FWr3EbACuXPQKQkH AROGSjtCIZI91HYOVY39RQ1oWN5FxizhaWnHoRCIu87igZUsL3ye//WtuskM1EPH+CrE fpcTienBz5mDzMkM24iygtQV5LsxlFh/wEzZdxJ0wLaEEdzI0o0OWOYclmslTxB3j60a oxSP+xxhbeypw7ljrwWkDhRoM4pVLWvU6/G8RpvnQggMaGs/9WPR7nsE1T8JVN/X0gVK 9cQA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=mxSI9U6A; spf=pass (google.com: domain of dario.binacchi@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=dario.binacchi@amarulasolutions.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:message-id:date:subject:cc:to:from :from:to:cc:subject:date:message-id:reply-to; bh=GcXooDewB2Uu/2RKidNo2EFYvdUIKguHYovtCm1c7o4=; b=ojPB+YwsgOQ8+bpfTsrx6u1eQiorvYNodpf0MRAdqKCMRq29OcYxHN1+dIOjUK0htP xDH92GlFC1KOT+CanzTggF2U55OecA7VaUonNwe7mxVbMSMAQ2infNicWddm/RMrhtFq HCC/1FhT+m3pkpEIFYPCUkdnhAxaYguLQ1DT4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=list-unsubscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence :x-original-authentication-results:x-original-sender:mime-version :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GcXooDewB2Uu/2RKidNo2EFYvdUIKguHYovtCm1c7o4=; b=gJScVgUYcL9WFHmQiMpW6J/ouJkqy2Yggt5EiCkZ1C8mWP2IJSZT36o0kyKMU4/g6Y XRisNpUxgRi1ZLqySGM8F51umAbYMkFLtjDCM9Y8lksfJiZa6d0y2t1hleOfN9mkH6Zl Rj8cm512LwmDI5DAQrUtl1LJR1VUXrSZP6Xo1YpXC+/gE+ORz8O2pKGTMJlr6vGd8tfS ymZmZ3sGjNkM9+3yBwJ3AJpolzJ9BqNdfYypWcBpdpHmkePD/tLaNBqI3QmspB8hQAoo AWlrg03a9V4xpKcRwDrLTLn/GVdaaoOhWfNytSYnYdX12nBx/iuvJHw6T/1uaAotwb9z Ywlw== X-Gm-Message-State: ACrzQf2fdJ/tlP7ysueeuIdoTyKRVsMVO4NmYxhXncl6h93wxTfL5fRT PTmMqXYDq1lIbd/BKQ2I236RjXiF X-Google-Smtp-Source: AMsMyM4bs7kRGRTLL8XsBjNxcYVJAmAOyRt/F0GFNJ7dCFar1FYkPNDzg2Z7L+IsV7Kh0pchJTHV3w== X-Received: by 2002:aa7:c40b:0:b0:45d:4492:a8cb with SMTP id j11-20020aa7c40b000000b0045d4492a8cbmr3240333edq.217.1666109037193; Tue, 18 Oct 2022 09:03:57 -0700 (PDT) X-BeenThere: linux-amarula@amarulasolutions.com Received: by 2002:a17:906:1dd1:b0:780:4a14:d3c7 with SMTP id v17-20020a1709061dd100b007804a14d3c7ls7933522ejh.0.-pod-prod-gmail; Tue, 18 Oct 2022 09:03:56 -0700 (PDT) X-Received: by 2002:a17:907:d07:b0:72e:ec79:ad0f with SMTP id gn7-20020a1709070d0700b0072eec79ad0fmr3125050ejc.296.1666109035839; Tue, 18 Oct 2022 09:03:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666109035; cv=none; d=google.com; s=arc-20160816; b=NC8VnyDHOcTla6iXENkB4xKGRkK4eG6DdCYt734STZzUwaFmeL6h5xBAWWqgNBYYWw nXkOwqMxUNYim2ee+LEzBvtxyOI1snrjav9f53wzdLjWFudVMk1exNVwLwrfBQcYAe7+ lNQTTCSWr14b95h86A79v1Wb1f7mOr/ksmVvTz/g2CdvXc8zzxmP7XO5oVS+3hb/YGg0 rBOA4AUjxpLzyeOwkE6yNLetv4J8aseaX9UJKNtpLHrJVUfMC/Zh8Q271rleONutRA7G AiK7xUFXEU5kG/SFoeEwOFrHefPCtlgyPcHskDImRb1B1GG37Many4TBB99plzoiNjLS u6lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:dkim-signature; bh=8JlbMErcGNycCCtodyD6GpAsyH/iGxyyMdZWiKDQlaU=; b=rR+BxYDEEO96GVle5fd0JOjHkT1VyQ+WdmgqoSHaSg0w0rQduOmI+4RC7o5aleI5of j3D2Ws1vG9I1kH3tiW5muhyMok9U3OKLp0BguNyVfFwoLASAEHQUocFgSSb11EwJcbK/ ikigRnTujTvGsdW6R7ZMxGM2Ud2IfoOvskQ/jT4dShDnBArYyzG+EYMndw90zx61utdI yrwAr8lDRj/JGv7mK6ycIAaSsnonqAIlWzZw/Kjt+tJEf7/Ri3GvZsddyEYX0PqXFe09 xBD78eygbu74noqgUApMxK0YKvJAsyk9BPzJmwUnN5odBNRqu8uImXPzjD6wxvBqx0/e HQQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=mxSI9U6A; spf=pass (google.com: domain of dario.binacchi@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=dario.binacchi@amarulasolutions.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id m6-20020a50cc06000000b0045c11c2b5e5sor6289109edi.70.2022.10.18.09.03.55 for <linux-amarula@amarulasolutions.com> (Google Transport Security); Tue, 18 Oct 2022 09:03:55 -0700 (PDT) Received-SPF: pass (google.com: domain of dario.binacchi@amarulasolutions.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a05:6402:34cd:b0:45d:a345:764 with SMTP id w13-20020a05640234cd00b0045da3450764mr3286646edc.415.1666109035532; Tue, 18 Oct 2022 09:03:55 -0700 (PDT) Received: from dario-ThinkPad-T14s-Gen-2i.homenet.telecomitalia.it (host-95-244-101-110.retail.telecomitalia.it. [95.244.101.110]) by smtp.gmail.com with ESMTPSA id j10-20020a17090623ea00b007919ba4295esm1166014ejg.216.2022.10.18.09.03.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 09:03:54 -0700 (PDT) From: Dario Binacchi <dario.binacchi@amarulasolutions.com> To: linux-kernel@vger.kernel.org Cc: Amarula patchwork <linux-amarula@amarulasolutions.com>, michael@amarulasolutions.com, Dario Binacchi <dario.binacchi@amarulasolutions.com>, kernel test robot <lkp@intel.com>, Allison Randal <allison@lohutok.net>, Miaoqian Lin <linmq006@gmail.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Tero Kristo <kristo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Tony Lindgren <tony@atomide.com>, linux-clk@vger.kernel.org, linux-omap@vger.kernel.org Subject: [PATCH v2] clk: ti: dra7-atl: don't allocate `parent_names' variable Date: Tue, 18 Oct 2022 18:03:52 +0200 Message-Id: <20221018160352.1591428-1-dario.binacchi@amarulasolutions.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 X-Original-Sender: dario.binacchi@amarulasolutions.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=mxSI9U6A; spf=pass (google.com: domain of dario.binacchi@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=dario.binacchi@amarulasolutions.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Content-Type: text/plain; charset="UTF-8" Precedence: list Mailing-list: list linux-amarula@amarulasolutions.com; contact linux-amarula+owners@amarulasolutions.com List-ID: <linux-amarula.amarulasolutions.com> X-Spam-Checked-In-Group: linux-amarula@amarulasolutions.com X-Google-Group-Id: 476853432473 List-Post: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/post>, <mailto:linux-amarula@amarulasolutions.com> List-Help: <https://support.google.com/a/amarulasolutions.com/bin/topic.py?topic=25838>, <mailto:linux-amarula+help@amarulasolutions.com> List-Archive: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/> List-Unsubscribe: <mailto:googlegroups-manage+476853432473+unsubscribe@googlegroups.com>, <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/subscribe> |
| Series |
[v2] clk: ti: dra7-atl: don't allocate `parent_names' variable
|
|
Commit Message
Dario Binacchi
Oct. 18, 2022, 4:03 p.m. UTC
The `parent_names' variable was freed also in case of kzalloc() error.
Instead of modifying the code to perform a proper memory release, I
decided to fix the bug by not allocating memory.
Since only one parent name is referenced, it is not necessary to
allocate this variable at runtime and therefore you can avoid calling
the kzalloc() function. This simplifies the code (even calls to kfree
can be removed) and improves the performance of the routine.
Note: Although no operation is performed by kfree() on a NULL pointer,
it was however suboptimal and semantically wrong doing it.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reported-by: kernel test robot <lkp@intel.com>
---
Changes in v2:
- Fix compiling error
- Add kernel test robot's Reported-by tag.
drivers/clk/ti/clk-dra7-atl.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
Comments
Quoting Dario Binacchi (2022-10-18 09:03:52) > diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c > index ff4d6a951681..78482d1a4a33 100644 > --- a/drivers/clk/ti/clk-dra7-atl.c > +++ b/drivers/clk/ti/clk-dra7-atl.c > @@ -188,24 +188,17 @@ static void __init of_dra7_atl_clock_setup(struct device_node *node) > goto cleanup; > } > > - parent_names = kzalloc(sizeof(char *), GFP_KERNEL); > - > - if (!parent_names) > - goto cleanup; > - > parent_names[0] = of_clk_get_parent_name(node, 0); Can you use struct clk_parent_data instead and assign index to 0? Then we don't even need to use of_clk_get_parent_name() here.
Hi Stephen, On Fri, Oct 28, 2022 at 2:27 AM Stephen Boyd <sboyd@kernel.org> wrote: > > Quoting Dario Binacchi (2022-10-18 09:03:52) > > diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c > > index ff4d6a951681..78482d1a4a33 100644 > > --- a/drivers/clk/ti/clk-dra7-atl.c > > +++ b/drivers/clk/ti/clk-dra7-atl.c > > @@ -188,24 +188,17 @@ static void __init of_dra7_atl_clock_setup(struct device_node *node) > > goto cleanup; > > } > > > > - parent_names = kzalloc(sizeof(char *), GFP_KERNEL); > > - > > - if (!parent_names) > > - goto cleanup; > > - > > parent_names[0] = of_clk_get_parent_name(node, 0); > > Can you use struct clk_parent_data instead and assign index to 0? Then > we don't even need to use of_clk_get_parent_name() here. I tried to test your suggestions on another platform (I don't have the hw to test the driver change) but if I don't add pdata.name = of_clk_get_parent_name () the board boot up fails. As far I can see from the clk_core_populate_parent_map() .... /* Copy everything over because it might be __initdata */ for (i = 0, parent = parents; i < num_parents; i++, parent++) { parent->index = -1; if (parent_names) { /* throw a WARN if any entries are NULL */ WARN(!parent_names[i], "%s: invalid NULL in %s's .parent_names\n", __func__, core->name); ret = clk_cpy_name(&parent->name, parent_names[i], true); } else if (parent_data) { parent->hw = parent_data[i].hw; parent->index = parent_data[i].index; ret = clk_cpy_name(&parent->fw_name, parent_data[i].fw_name, false); if (!ret) ret = clk_cpy_name(&parent->name, parent_data[i].name, false); ... The function clk_cpy_name() is called with the parameter "mus_exist" to true in the path "parent_names" and false in the path "parent_data". Therefore, in the path "parent_data" it is allowed that parent-> name is not set. In doing so, therefore, the change would not even be backward compatible. So, IMHO, there are 2 possible options: 1 okay to use parent_data, but we keep using of_clk_get_parent_name () to set parent_data::name. 2 okay to use the version v2 of the patch. What do you think? Thanks and regards, Dario
Quoting Dario Binacchi (2022-10-30 06:00:46) > > I tried to test your suggestions on another platform (I don't have the > hw to test the driver change) but if I > don't add pdata.name = of_clk_get_parent_name () the board boot up fails. > > As far I can see from the clk_core_populate_parent_map() > > .... > /* Copy everything over because it might be __initdata */ > for (i = 0, parent = parents; i < num_parents; i++, parent++) { > parent->index = -1; > if (parent_names) { > /* throw a WARN if any entries are NULL */ > WARN(!parent_names[i], > "%s: invalid NULL in %s's .parent_names\n", > __func__, core->name); > ret = clk_cpy_name(&parent->name, parent_names[i], > true); > } else if (parent_data) { > parent->hw = parent_data[i].hw; > parent->index = parent_data[i].index; > ret = clk_cpy_name(&parent->fw_name, > parent_data[i].fw_name, false); > if (!ret) > ret = clk_cpy_name(&parent->name, > parent_data[i].name, > false); > ... > > > The function clk_cpy_name() is called with the parameter "mus_exist" > to true in the path "parent_names" and false > in the path "parent_data". Therefore, in the path "parent_data" it is > allowed that parent-> name is not set. > In doing so, therefore, the change would not even be backward compatible. > > So, IMHO, there are 2 possible options: > 1 okay to use parent_data, but we keep using of_clk_get_parent_name > () to set parent_data::name. > 2 okay to use the version v2 of the patch. > > What do you think? I am confused. The struct clk_parent_data::name being used is whatever string is returned by of_clk_get_parent_name(node, 0). That is the same as setting struct clk_parent_data::index to 0, and not assigning the 'name' or 'fw_name' field of the parent data structure. This is a compatible change because of_clk_get_parent_name() is getting the name of the clk in 'clocks' for 'node' at index 0. Using the index 0 in clk_parent_data tells clk framework that the parent of the clk being registered is the clk in 'clocks' for the 'dev->node' that is passed in during clk_register(). If you don't have a device pointer, use of_clk_hw_register() to pass 'node' directly. It looks like you will have to do that in this case to get the node pointer registered with this clk.
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c index ff4d6a951681..78482d1a4a33 100644 --- a/drivers/clk/ti/clk-dra7-atl.c +++ b/drivers/clk/ti/clk-dra7-atl.c @@ -164,7 +164,7 @@ static void __init of_dra7_atl_clock_setup(struct device_node *node) { struct dra7_atl_desc *clk_hw = NULL; struct clk_init_data init = { NULL }; - const char **parent_names = NULL; + const char *parent_names[1]; const char *name; struct clk *clk; @@ -188,24 +188,17 @@ static void __init of_dra7_atl_clock_setup(struct device_node *node) goto cleanup; } - parent_names = kzalloc(sizeof(char *), GFP_KERNEL); - - if (!parent_names) - goto cleanup; - parent_names[0] = of_clk_get_parent_name(node, 0); init.parent_names = parent_names; clk = ti_clk_register(NULL, &clk_hw->hw, name); - if (!IS_ERR(clk)) { of_clk_add_provider(node, of_clk_src_simple_get, clk); - kfree(parent_names); return; } + cleanup: - kfree(parent_names); kfree(clk_hw); } CLK_OF_DECLARE(dra7_atl_clock, "ti,dra7-atl-clock", of_dra7_atl_clock_setup);