[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXv+5Fipb2Sjypv8ayRbHqNfiLxtaFXatM-vMRtX2UNFzZ-3g@mail.gmail.com>
Date: Fri, 13 May 2022 11:24:28 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: Miles Chen <miles.chen@...iatek.com>
Cc: angelogioacchino.delregno@...labora.com,
chun-jie.chen@...iatek.com, linux-arm-kernel@...ts.infradead.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mediatek@...ts.infradead.org, matthias.bgg@...il.com,
mturquette@...libre.com, rex-bc.chen@...iatek.com, sboyd@...nel.org
Subject: Re: [PATCH v2 05/11] clk: mediatek: mt27xx: Replace 'struct clk' with
'struct clk_hw'
On Thu, May 12, 2022 at 10:49 PM Miles Chen <miles.chen@...iatek.com> wrote:
>
> > static int clk_mt2701_bdp_probe(struct platform_device *pdev)
> > {
> > - struct clk_onecell_data *clk_data;
> > + struct clk_hw_onecell_data *clk_data;
> > int r;
> > struct device_node *node = pdev->dev.of_node;
> >
> > @@ -110,7 +110,7 @@ static int clk_mt2701_bdp_probe(struct platform_device *pdev)
> > mtk_clk_register_gates(node, bdp_clks, ARRAY_SIZE(bdp_clks),
> > clk_data);
> >
> > - r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> > + r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
>
> We have of_clk_add_provider() and of_clk_add_hw_provider() the same time,
> so we can convert of_clk_add_provider to of_clk_add_hw_provider by 2xxx, 6xxx, 8xxx,
> without introducing build breaks.
>
> However, there is no mtk_alloc_hw_clk_data() for mtk_alloc_clk_data() in [1]. (03/11 in this series).
> For bisectability, patch 3~8 should be one patch, or we should have mtk_alloc_hw_clk_data()
> to help us?
As mentioned in the cover letter, the patch is split between the manually
edited parts and the coccinelle converted parts. This should help with
review, especially trying to identify which part of the coccinelle scripts
failed. The split also reduces the size of each patch so that they don't
get blocked.
I opted not to add additional APIs, as we would just be removing them at
the end, and that just results in even more code churn.
ChenYu
> [1] https://lore.kernel.org/lkml/20220510104804.544597-4-wenst@chromium.org/
Powered by blists - more mailing lists