From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Ban Tao <fengzheng923@gmail.com>,
mripard@kernel.org, wens@csie.org, linux-kernel@vger.kernel.org,
linux-pwm@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH v2] pwm: sunxi: Add Allwinner SoC PWM controller driver
Date: Wed, 3 Feb 2021 17:33:16 +0100 [thread overview]
Message-ID: <YBrQTM5iADZgA2v1@ulmo> (raw)
In-Reply-To: <20210203151200.fdzzq23teoypbxad@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]
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.
> > +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.
[...]
> > +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. sun50i_pwm_chip is
consistent with what other drivers name this, so I think that's fine.
Agreed on "pwm" being a bad choice here, though.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-02-03 16:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 12:53 [PATCH v2] pwm: sunxi: Add Allwinner SoC PWM controller driver Ban Tao
2021-02-03 15:12 ` Uwe Kleine-König
2021-02-03 16:33 ` Thierry Reding [this message]
2021-02-03 20:59 ` Uwe Kleine-König
2021-02-04 13:38 ` Thierry Reding
2021-02-04 13:54 ` Uwe Kleine-König
2021-02-04 22:05 ` Thierry Reding
2021-02-20 1:47 ` 班涛
2021-02-20 2:18 ` 班涛
2021-02-22 7:22 ` Uwe Kleine-König
2021-02-03 15:46 ` Maxime Ripard
2021-02-04 3:47 ` 班涛
2021-02-05 16:11 ` Maxime Ripard
2021-02-06 13:27 ` 班涛
2021-02-10 9:33 ` Maxime Ripard
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=YBrQTM5iADZgA2v1@ulmo \
--to=thierry.reding@gmail.com \
--cc=fengzheng923@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.