linux-sunxi.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Samuel Holland <samuel@sholland.org>
Cc: Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/8] clk: sunxi-ng: Rename files to match Kconfig and drivers
Date: Tue, 7 Sep 2021 19:43:24 +0200	[thread overview]
Message-ID: <20210907174324.lho3vdl2z6uealnf@gilmour> (raw)
In-Reply-To: <1d269ff8-9219-cc0a-fda7-236bfd4b4510@sholland.org>

Hi,

On Fri, Sep 03, 2021 at 03:57:14PM -0500, Samuel Holland wrote:
> Hi Maxime,
> 
> On 9/3/21 4:10 AM, Maxime Ripard wrote:
> > Hi,
> > 
> > On Wed, Sep 01, 2021 at 12:05:22AM -0500, Samuel Holland wrote:
> >> When the drivers are built as modules, the file name will become the
> >> module name. Rename the files so everything matches: the Kconfig symbol,
> >> the platform driver name (as seen in sysfs), and the module name.
> >>
> >> Signed-off-by: Samuel Holland <samuel@sholland.org>
> > 
> > I'm not a big fan of big renames like this, it makes merging and
> > backporting patches harder in the long term.
> 
> I can split this into two commits, first the .c files and then the .h
> files, so everything is a 100% rename, if that makes a difference.
> 
> > I assume you did this to make the module autoloading work? If so, using
> > MODULE_ALIAS would be less intrusive
> 
> Autoloading should work anyway, since there is a module alias for the
> compatible string. This change is more about the principle of least
> surprise. The compatible is allwinner,sun50i-a64-ccu, the Kconfig symbol
> is SUN50I_A64_CCU, the driver name (in /sys/bus/platform/drivers) is
> sun50i_a64_ccu, but yet the module name is ccu-sun50i-a64???

We can't really do much for the compatible, and it's the standard
practice there anyway. However, it looks much more common for Kconfig to
have a pattern like $FRAMEWORK_$SOC, so maybe we could just rename the
Kconfig (and drivers name) to CCU_SUN50I_A64? It's not been exposed to
the defconfig so far anyway, so we can change them without any real harm

> Once we allow building modules, the names are ABI, and this
> inconsistency will bother me until the end of time :)
> 
> If there is a way to completely rename the module without renaming the
> files (not adding an alias), then that would be enough for me.

Otherwise, yeah, we can do what Stephen suggested

Maxime

  parent reply	other threads:[~2021-09-07 17:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  5:05 [PATCH 0/8] clk: sunxi-ng: Lifetime fixes and module support Samuel Holland
2021-09-01  5:05 ` [PATCH 1/8] clk: sunxi-ng: Unregister clocks/resets when unbinding Samuel Holland
2021-09-01  5:05 ` [PATCH 2/8] clk: sunxi-ng: Prevent unbinding CCUs via sysfs Samuel Holland
2021-09-01  5:05 ` [PATCH 3/8] clk: sunxi-ng: Use a separate lock for each CCU instance Samuel Holland
2021-09-03  9:09   ` Maxime Ripard
2021-09-01  5:05 ` [PATCH 4/8] clk: sunxi-ng: Rename files to match Kconfig and drivers Samuel Holland
2021-09-03  9:10   ` Maxime Ripard
2021-09-03 20:57     ` Samuel Holland
2021-09-05 20:51       ` Stephen Boyd
2021-09-07 17:43       ` Maxime Ripard [this message]
2021-09-01  5:05 ` [PATCH 5/8] clk: sunxi-ng: Export symbols used by CCU drivers Samuel Holland
2021-09-01 13:54   ` Chen-Yu Tsai
2021-09-01  5:05 ` [PATCH 6/8] clk: sunxi-ng: Allow drivers to be built as modules Samuel Holland
2021-09-01  5:05 ` [PATCH 7/8] clk: sunxi-ng: Convert early providers to platform drivers Samuel Holland
2021-09-03  9:19   ` Maxime Ripard
2021-09-01  5:05 ` [PATCH 8/8] clk: sunxi-ng: Allow the CCU core to be built as a module Samuel Holland

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=20210907174324.lho3vdl2z6uealnf@gilmour \
    --to=maxime@cerno.tech \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mturquette@baylibre.com \
    --cc=samuel@sholland.org \
    --cc=sboyd@kernel.org \
    --cc=wens@csie.org \
    /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;
as well as URLs for NNTP newsgroup(s).