From: Brian Masney <bmasney@redhat.com>
To: Xuyang Dong <dongxuyang@eswincomputing.com>
Cc: sboyd@kernel.org, mturquette@baylibre.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, troy.mitchell@linux.dev,
ningyu@eswincomputing.com, linmin@eswincomputing.com,
huangyifeng@eswincomputing.com, pinkesh.vaghela@einfochips.com,
ganboing@gmail.com, marcel@ziswiler.com
Subject: Re: Re: [PATCH v13 2/3] clk: eswin: Add eic7700 clock driver
Date: Wed, 25 Feb 2026 08:29:30 -0500 [thread overview]
Message-ID: <aZ75OuPEw7co40J9@redhat.com> (raw)
In-Reply-To: <51ff08b4.38e3.19c9394ac61.Coremail.dongxuyang@eswincomputing.com>
On Wed, Feb 25, 2026 at 02:55:20PM +0800, Xuyang Dong wrote:
> > > +
> > > +int eswin_clk_register_divider(struct device *dev,
> > > + struct eswin_divider_clock *clks,
> > > + int nums, struct eswin_clock_data *data)
> > > +{
> > > + struct clk_hw *clk_hw;
> > > + int i;
> > > +
> > > + for (i = 0; i < nums; i++) {
> > > + clk_hw = clk_hw_register_divider_parent_data
> > > + (dev, clks[i].name, clks[i].parent_data,
> > > + clks[i].flags, data->base + clks[i].offset,
> > > + clks[i].shift, clks[i].width, clks[i].div_flags,
> > > + &data->lock);
> > > +
> > > + if (IS_ERR(clk_hw)) {
> > > + while (i--)
> > > + clk_hw_unregister_divider
> > > + (data->clk_data.hws[clks[i].id]);
> >
> > All of the other places you are using the devm_ variant to automate the
> > cleanup, such as devm_clk_hw_register_gate_parent_data(),
> > devm_clk_hw_register_mux_parent_data_table(), and
> > devm_clk_hw_register_divider_parent_hw(). What do you think about adding
> > a devm_clk_hw_register_divider_parent_data() for consistency?
> >
>
> Hi Brian and Stephen,
>
> Thank you for the suggestions. We agree that implementing
> devm_clk_hw_register_divider_parent_data() is a good approach.
> In v14, we'll add this function in clk-provider.h as a separate preparatory patch.
> The ESWIN clock driver will then switch to using
> devm_clk_hw_register_divider_parent_data() instead of
> clk_hw_register_divider_parent_data(), with the driver patch depending on the former.
> Does this approach better align with upstream conventions?
Yes, that sounds good.
> > You can now go out to 100 characters for the line lengths instead of 80, however,
> > I'm not sure how Stephen feels about that. Personally I think it'd make this
> > block, plus some others in this series a bit cleaner. Taking into account the
> > current indentation, this block could become this with 100 characters as the max:
> >
> > hw = eswin_register_clkdiv(dev, div->id, div->name, phw,
> > div->flags, data->base + div->offset,
> > div->shift, div->width, div->div_flags,
> > div->priv_flag, &data->lock);
> >
>
> Stephen,
> Brian's feedback on line length was very helpful.
> For v14, we've kept lines within 80 characters wherever possible.
> In a few cases, such as function calls with long parameter lists, we've kept
> slightly longer lines to preserve readability,
> but we're happy to rewrap them if preferred.
> Does this approach work for the clk subsystem?
I don't know when Stephen will be able to respond. I recommend just
posting a new version.
I apologize in advance if he asks you to do the opposite later.
Brian
next prev parent reply other threads:[~2026-02-25 13:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 10:14 [PATCH v13 0/3] Add driver support for ESWIN eic700 SoC clock controller dongxuyang
2026-02-14 10:15 ` [PATCH v13 1/3] dt-bindings: clock: eswin: Documentation for eic7700 SoC dongxuyang
2026-02-14 10:15 ` [PATCH v13 2/3] clk: eswin: Add eic7700 clock driver dongxuyang
2026-02-16 17:17 ` Brian Masney
2026-02-17 1:09 ` Brian Masney
2026-02-19 13:14 ` Marcel Ziswiler
2026-02-25 6:55 ` Xuyang Dong
2026-02-25 13:29 ` Brian Masney [this message]
2026-02-14 10:15 ` [PATCH v13 3/3] MAINTAINERS: Add entry for ESWIN EIC7700 " dongxuyang
2026-02-24 8:46 ` [PATCH v13 0/3] Add driver support for ESWIN eic700 SoC clock controller Bo Gan
2026-02-24 9:09 ` Xuyang Dong
2026-02-24 11:33 ` Brian Masney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZ75OuPEw7co40J9@redhat.com \
--to=bmasney@redhat.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dongxuyang@eswincomputing.com \
--cc=ganboing@gmail.com \
--cc=huangyifeng@eswincomputing.com \
--cc=krzk+dt@kernel.org \
--cc=linmin@eswincomputing.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@ziswiler.com \
--cc=mturquette@baylibre.com \
--cc=ningyu@eswincomputing.com \
--cc=pinkesh.vaghela@einfochips.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=troy.mitchell@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox