Re: [PATCH v2] pwm: sunxi: Add Allwinner SoC PWM controller driver

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 10033 bytes --]

On Wed, Feb 03, 2021 at 09:59:13PM +0100, Uwe Kleine-König wrote:
> Hello Thierry, hello Ban,
> 
> On Wed, Feb 03, 2021 at 05:33:16PM +0100, Thierry Reding wrote:
> > On Wed, Feb 03, 2021 at 04:12:00PM +0100, Uwe Kleine-König wrote:
> > > On Wed, Feb 03, 2021 at 08:53:17PM +0800, Ban Tao wrote:
> > [...]
> > > > +#define PWM_GET_CLK_OFFSET(chan)	(0x20 + ((chan >> 1) * 0x4))
> > > > +#define PWM_CLK_APB_SCR			BIT(7)
> > > > +#define PWM_DIV_M			0
> > > > +#define PWM_DIV_M_WIDTH			0x4
> > > > +
> > > > +#define PWM_CLK_REG			0x40
> > > > +#define PWM_CLK_GATING			BIT(0)
> > > > +
> > > > +#define PWM_ENABLE_REG			0x80
> > > > +#define PWM_EN				BIT(0)
> > > > +
> > > > +#define PWM_CTL_REG(chan)		(0x100 + 0x20 * chan)
> > > > +#define PWM_ACT_STA			BIT(8)
> > > > +#define PWM_PRESCAL_K			0
> > > > +#define PWM_PRESCAL_K_WIDTH		0x8
> > > > +
> > > > +#define PWM_PERIOD_REG(chan)		(0x104 + 0x20 * chan)
> > > > +#define PWM_ENTIRE_CYCLE		16
> > > > +#define PWM_ENTIRE_CYCLE_WIDTH		0x10
> > > > +#define PWM_ACT_CYCLE			0
> > > > +#define PWM_ACT_CYCLE_WIDTH		0x10
> > > 
> > > Please use a driver specific prefix for these defines.
> > 
> > These are nice and to the point, so I think it'd be fine to leave these
> > as-is. Unless of course if they conflict with something from the PWM
> > core, which I don't think any of these do.
> 
> In my eyes PWM_CLK_REG, PWM_CLK_GATING, PWM_ENABLE_REG and PWM_EN are
> not so nice. pwm-sun4i.c has already PWM_EN, pwm-mtk-disp.c has
> DISP_PWM_EN, pwm-zx.c has ZX_PWM_EN, pwm-berlin.c has BERLIN_PWM_EN.
> Luckily most of them already use a prefix. So it doesn't conflict with
> the core, but might with other drivers.

"Conflicts with another driver" is not something that makes sense. By
definition drivers should be specific to a given device, so you better
make sure there's no namespace sharing between them.

I'm fine if somebody wants to use a prefix, but I'm also fine if they
don't use a prefix, provided that there are no conflicts, which should
be immediately obvious because it typically causes build errors.

All I'm saying is that I don't think we need to require everyone to
adopt a prefix, especially if this hasn't been followed consistently,
because then we don't actually gain anything.

>                                         And also if you only care about
> conflicts with the core, using a prefix is the future-proof strategy.

It's not like these symbol names are carved in stone. If we ever
introduce a symbol in the PWM core that happens to conflicts with one or
more drivers, we can always fix the drivers at that point.

> For tools like ctags and cscope a unique name is great, too.
> 
> Also comparing
> 
> 	tmp |= BIT_CH(PWM_EN, pwm->hwpwm);
> 
> with (say)
> 
> 	tmp |= BIT_CH(SUN5I_PWM_PWM_EN, pwm->hwpwm);
> 
> I prefer the latter as it is obvious that this is a driver specific
> constant.

I think the context makes it plenty clear that this is driver specific,
so the prefix is a bit redundant.

> Having said that, I'm also a fan of having the register name in the bit
> field define to simplify spotting errors like 4b75f8000361 ("serial:
> imx: Fix DCD reading").
> 
> So looking at:
> 
> +       /* disable pwm controller */
> +       tmp = sun50i_pwm_readl(sun50i_pwm, PWM_ENABLE_REG);
> +       tmp &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> +       sun50i_pwm_writel(sun50i_pwm, tmp, PWM_ENABLE_REG);
> 
> my preferred version would be instead:
> 
> +       /* disable pwm controller */
> +       enable = sun50i_pwm_readl(sun50i_pwm, SUN50I_REG_PWM_ENABLE);
> +       enable &= ~SUN50I_REG_PWM_ENABLE_EN(pwm->hwpwm);
> +       sun50i_pwm_writel(sun50i_pwm, enable, SUN50I_REG_PWM_ENABLE);
> 
> where variable name, register name and bitfield name are obviously
> matching.

I don't have any particular objection to the above, but I've also seen
this kind of naming result in ridiculously long (as in almost impossible
to read) lines, so I think we need to strike the right balance. Given
that there aren't any rigorous rules for this, I don't think it's worth
requiring everyone to adopt some style that's not consistently followed
anyway.

> > > > +struct sun50i_pwm_data {
> > > > +	unsigned int npwm;
> > > > +};
> > > > +
> > > > +struct sun50i_pwm_chip {
> > > > +	struct pwm_chip chip;
> > > > +	struct clk *clk;
> > > > +	struct reset_control *rst_clk;
> > > > +	void __iomem *base;
> > > > +	const struct sun50i_pwm_data *data;
> > > > +};
> > > > +
> > > > +static inline struct sun50i_pwm_chip *sun50i_pwm_from_chip(struct pwm_chip *chip)
> > > > +{
> > > > +	return container_of(chip, struct sun50i_pwm_chip, chip);
> > > > +}
> > 
> > I wanted to reply to Uwe's comment on v1 but you sent this before I got
> > around to it, so I'll mention it here. I recognize the usefulness of
> > having a common prefix for function names, though admittedly it's not
> > totally necessary in these drivers because these are all local symbols.
> > But it does makes things a bit consistent and helps when looking at
> > backtraces and such, so that's all good.
> > 
> > That said, I consider these casting helpers a bit of a special case
> > because they usually won't show up in backtraces, or anywhere else for
> > that matter. Traditionally these have been named to_*(), so it'd be
> > entirely consistent to keep doing that.
> > 
> > But I don't have any strong objections to this variant either, so pick
> > whichever you want. Although, please, nobody take that as a hint that
> > any existing helpers should be converted.
> 
> @Thierry: I don't understand your motivation to write this.

I'm writing this because I think your recommendation was the wrong thing
to do here. Ban was obviously doing what *all* other drivers are doing
for this casting helper, so why should this one be different?

>                                                             For me
> consistence is a quite important aspect. Obviously for you it's less so
> and the code presented here over-fulfils your standards. So everything
> is fine as is, isn't it?

Like I said, 100% of the PWM drivers use to_*() for these, so how is it
consistent if we now start to change that?

What I was trying to say is that I would've been fine with this if the
original patch had named this sun50i_pwm_from_chip(). It wouldn't have
been consistent, but I would probably not have objected. However, the
original patch was making this consistent and then you suggested to
change it so that it became inconsistent.

I want to avoid a situation where there's a quasi-standard rule, even if
it's not written down anywhere, and then out of nowhere we change the
rule, for no obvious reason.

> I think using a rule like "A common prefix for driver specific functions"
> consistently is easier than allowing some exceptions. There is no gain
> in not using the prefix, so IMHO keep the rules simple without
> exceptions.

That's a matter of perspective. The way I see it, the simple rule here
is that these casting helpers should be named to_*(). Like I said, that
is what every single one of the existing drivers in drivers/pwm does, so
using the driver prefix breaks the rule and make things inconsistent.

> > [...]
> > > > +static int sun50i_pwm_probe(struct platform_device *pdev)
> > > > +{
> > > > +	struct sun50i_pwm_chip *pwm;
> > > 
> > > "pwm" isn't a good name, in PWM code this name is usually used for
> > > struct pwm_device pointers (and sometimes the global pwm id). I usually
> > > use "ddata" for driver data (and would have called "sun50i_pwm_chip"
> > > "sun50i_pwm_ddata" instead). Another common name is "priv".
> > 
> > This driver already declares sun50i_pwm_data for per-SoC data, so having
> > a struct sun50i_pwm_ddata would just be confusing.
> 
> Agreed. So maybe pick a better name for sun50i_pwm_data; my suggestion
> would be sun50i_pwm_soc_info.

Yeah, I think that'd make it much clearer what this is used for.

> > sun50i_pwm_chip is consistent with what other drivers name this, so I
> > think that's fine.
> 
> Either the name is good, then this alone justifies to use it. If however
> the name is bad, it IMHO doesn't matter if others use the same bad
> naming scheme and you better don't use it. So please don't let us
> consider it a good name *only* because it's used in several other
> places.

I don't consider this naming scheme good just because it's consistent.
The reason why it is used fairly consistently is because I think the
name is good and I've recommended it to be used when people chose what
I thought were bad names.

Now there are other cases that don't follow this scheme and that's fine
too. I think it's okay to let people be creative every once in a while.
As long as everybody understands what the purpose is and as long as it
doesn't conflict with anything or confuses anyone, that's fine with me.

> @Ban: You see Thierry and I don't agree in every aspect. So please take
> the feedback you get from us as cause for thought and then try to come
> up with a v3 with choices you can justify.

That's a bit unfair. The purpose of review is to identify things that
need to be changed. If we go around giving people a bunch of options and
tell them to pick one of them and try again isn't terribly helpful.

So I think either we have to write down the rules to make sure everybody
is on the same page, or we let people look at existing code and pick up
the rules. In the latter case we may have to accept that people have
different preferences, and not everything may be 100% consistent. I
think that's totally fine. Achieving 100% consistency is wishful
thinking anyway. Even if you manage to achieve it in the PWM subsystem,
you then move to the next subsystem and things are likely to be done
differently there. We might as well just get used to having a bit of
inconsistency.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]