Thread (33 messages) 33 messages, 5 authors, 2019-04-03

Re: [linux-sunxi] Re: [PATCH 04/14] pinctrl: sunxi: v3: really introduce support for V3

From: Maxime Ripard <hidden>
Date: 2019-03-18 11:57:40
Also in: linux-arm-kernel, linux-clk, linux-gpio, lkml

On Mon, Mar 18, 2019 at 12:05:12PM +0100, Paul Kocialkowski wrote:
Hi,

Le mardi 12 mars 2019 à 23:45 +0800, Icenowy Zheng a écrit :
quoted
于 2019年3月12日 GMT+08:00 下午11:36:54, Maxime Ripard [off-list ref] 写到:
quoted
On Tue, Mar 12, 2019 at 11:22:46PM +0800, Icenowy Zheng wrote:
quoted
Introduce the GPIO pins that is only available on V3 (not on V3s) to
the
quoted
V3 pinctrl driver.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
 drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c | 291
+++++++++++++++++++++--
quoted
 drivers/pinctrl/sunxi/pinctrl-sunxi.h    |   2 +
 2 files changed, 275 insertions(+), 18 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
quoted
index 6704ce8e5e3d..54c210871a95 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3.c
@@ -1,5 +1,5 @@
 /*
- * Allwinner V3s SoCs pinctrl driver.
+ * Allwinner V3/V3s SoCs pinctrl driver.
  *
  * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
  *
@@ -23,7 +23,7 @@

 #include "pinctrl-sunxi.h"

-static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
+static const struct sunxi_desc_pin sun8i_v3_v3s_pins[] = {
I'm not sure all that remaining is worth it to be honest. It adds a
lot of noise for no particular reason (and the same goes for renaming
the file itself)
Maybe keeping names is okay "for historial reasons".

In fact I want to keep them.
My two cents about this: kernel development is plagued by the unability
to rename and rework things as soon as backward compatibility is
involved. I believe that renaming and reworking things is quite a good
thing to do when it leads to a situation that is easier to understand
and makes more sense.

In this case, I don't see any blockers that would prevent us from doing
this, so I am strongly in favor of it. I really don't see how increased
noise and "historical reasons" make up for better clarity.
It simplifies the git history, for once, which has the side effect of
reducing conflicts too.

A second one is: Do you prefer to review patches that have some
significant value (like a new feature, a bugfix, a new SoC support,
etc) or one that renames files and / or symbols?

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help