lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jd46vvxgrmpk7dhaogio6wsut4l7keshhujw6k3kw2enodgwiw@wtaxbwgaykrr>
Date: Mon, 7 Apr 2025 18:02:57 +0800
From: Longbin Li <looong.bin@...il.com>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Chen Wang <unicorn_wang@...look.com>, Inochi Amaoto <inochiama@...il.com>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>, linux-pwm@...r.kernel.org, 
	devicetree@...r.kernel.org, sophgo@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 2/2] pwm: sophgo: add driver for SG2044

On Mon, Apr 07, 2025 at 11:38:27AM +0200, Uwe Kleine-König wrote:
> On Mon, Apr 07, 2025 at 03:20:39PM +0800, Longbin Li wrote:
> > From: ghost <2990955050@...com>
> 
> Huh, is that a real name?
>

My fault,i will change it.
 
> > Add PWM controller for SG2044.
> > 
> > Signed-off-by: Longbin Li <looong.bin@...il.com>
> > ---
> >  drivers/pwm/pwm-sophgo-sg2042.c | 162 +++++++++++++++++++++++++++-----
> >  1 file changed, 138 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-sophgo-sg2042.c b/drivers/pwm/pwm-sophgo-sg2042.c
> > index ff4639d849ce..c62e8c758d87 100644
> > --- a/drivers/pwm/pwm-sophgo-sg2042.c
> > +++ b/drivers/pwm/pwm-sophgo-sg2042.c
> 
> The Limitations paragraph needs updating. E.g. SG2044 seems to support
> polarity while SG2042 doesn't.
> 

Thanks,i will add that.

> > @@ -26,20 +26,22 @@
> >  #include <linux/pwm.h>
> >  #include <linux/reset.h>
> > 
> > -/*
> > - * Offset RegisterName
> > - * 0x0000 HLPERIOD0
> > - * 0x0004 PERIOD0
> > - * 0x0008 HLPERIOD1
> > - * 0x000C PERIOD1
> > - * 0x0010 HLPERIOD2
> > - * 0x0014 PERIOD2
> > - * 0x0018 HLPERIOD3
> > - * 0x001C PERIOD3
> > - * Four groups and every group is composed of HLPERIOD & PERIOD
> > - */
> > -#define SG2042_PWM_HLPERIOD(chan) ((chan) * 8 + 0)
> > -#define SG2042_PWM_PERIOD(chan) ((chan) * 8 + 4)
> > +#define REG_HLPERIOD		0x0
> > +#define REG_PERIOD		0x4
> > +#define REG_GROUP		0x8
> 
> REG_GROUP belongs to a different category than REG_PERIOD. So please use
> a different schema to name it (or drop it, see below).
> 

I will improve it.

> > +#define REG_POLARITY		0x40
> > +
> > +#define REG_PWMSTART		0x44
> > +#define REG_PWMUPDATE		0x4C
> > +#define REG_SHIFTCOUNT		0x80
> > +#define REG_SHIFTSTART		0x90
> 
> REG_SHIFTCOUNT and REG_SHIFTSTART are unused.
> 

I will drop it.

> > +#define REG_PWM_OE		0xD0
> 
> Actually I liked the old prefix better. E.g. "REG_POLARITY" looks more
> generic that it actually is.
> 

I will reconsider that.

> > +
> > +#define PWM_REG_NUM		0x80
> 
> This is unused?
> 

I will drop it,thanks!

> > +
> > +#define PWM_POLARITY_MASK(n) BIT(n)
> > +#define PWM_HLPERIOD(chan) ((chan) * REG_GROUP + REG_HLPERIOD)
> > +#define PWM_PERIOD(chan) ((chan) * REG_GROUP + REG_PERIOD)
> 
> ((chan) * 8 + 0) is IMHO better. I guess this is subjective because at
> least the *8 is repeated several times, but the advantage of not using a
> define for 8 (and 0 and 4) is that by looking at
> 
> 	#define SG2042_PWM_HLPERIOD(chan) ((chan) * 8 + 0)
> 
> you immediatly see the offsets of the HLPERIOD register, while for
> 
> 	#define PWM_HLPERIOD(chan) ((chan) * REG_GROUP + REG_HLPERIOD)
> 
> you have to lookup two additional symbols.
> 
> Also PWM is a prefix that is too generic.
> 

I will reconsider that.

> >  #define SG2042_PWM_CHANNELNUM	4
> > 
> > @@ -51,6 +53,12 @@
> >  struct sg2042_pwm_ddata {
> >  	void __iomem *base;
> >  	unsigned long clk_rate_hz;
> > +	struct mutex lock;
> 
> What does this lock protect? Note that there is a chip lock that is held
> when .apply() is called, to serialize apply calls for a single chip. I
> guess this can and should be dropped.
> 

I will retest it, and if possible i will drop it, thanks.

> > +};
> > +
> > +struct sg2042_chip_data {
> > +	const struct pwm_ops ops;
> > +	bool atomic;
> >  };
> > 
> >  /*
> > @@ -62,8 +70,8 @@ static void pwm_sg2042_config(struct sg2042_pwm_ddata *ddata, unsigned int chan,
> >  {
> >  	void __iomem *base = ddata->base;
> > 
> > -	writel(period_ticks, base + SG2042_PWM_PERIOD(chan));
> > -	writel(hlperiod_ticks, base + SG2042_PWM_HLPERIOD(chan));
> > +	writel(period_ticks, base + PWM_PERIOD(chan));
> > +	writel(hlperiod_ticks, base + PWM_HLPERIOD(chan));
> 
> The register renaming adds really quite some noise that is actually
> unrelated to this patch. If you really think the register defines need
> renaming, do that in a separate patch (and justify it well).
> 

Sorry, i will modify here.

> >  }
> > 
> >  static int pwm_sg2042_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > @@ -104,8 +112,8 @@ static int pwm_sg2042_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> >  	u32 hlperiod_ticks;
> >  	u32 period_ticks;
> > 
> > -	period_ticks = readl(ddata->base + SG2042_PWM_PERIOD(chan));
> > -	hlperiod_ticks = readl(ddata->base + SG2042_PWM_HLPERIOD(chan));
> > +	period_ticks = readl(ddata->base + PWM_PERIOD(chan));
> > +	hlperiod_ticks = readl(ddata->base + PWM_HLPERIOD(chan));
> > 
> >  	if (!period_ticks) {
> >  		state->enabled = false;
> > @@ -123,13 +131,112 @@ static int pwm_sg2042_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> >  	return 0;
> >  }
> > 
> > -static const struct pwm_ops pwm_sg2042_ops = {
> > -	.apply = pwm_sg2042_apply,
> > -	.get_state = pwm_sg2042_get_state,
> > +static void pwm_sg2044_config(struct sg2042_pwm_ddata *ddata, struct pwm_device *pwm, bool enabled)
> > +{
> > +	u32 pwm_value;
> > +
> > +	pwm_value = readl(ddata->base + REG_PWMSTART);
> > +
> > +	if (enabled)
> > +		writel(pwm_value | BIT(pwm->hwpwm), ddata->base + REG_PWMSTART);
> > +	else
> > +		writel(pwm_value & ~BIT(pwm->hwpwm), ddata->base + REG_PWMSTART);
> > +}
> > +
> > +static void pwm_sg2044_set_outputenable(struct sg2042_pwm_ddata *ddata, struct pwm_device *pwm,
> > +					bool enabled)
> > +{
> > +	u32 pwm_value;
> > +
> > +	pwm_value = readl(ddata->base + REG_PWM_OE);
> > +
> > +	if (enabled)
> > +		writel(pwm_value | BIT(pwm->hwpwm), ddata->base + REG_PWM_OE);
> > +	else
> > +		writel(pwm_value & ~BIT(pwm->hwpwm), ddata->base + REG_PWM_OE);
> > +}
> > +
> > +static int pwm_sg2044_set_polarity(struct sg2042_pwm_ddata *ddata, struct pwm_device *pwm,
> > +				   const struct pwm_state *state)
> > +{
> > +	enum pwm_polarity polarity;
> > +	u32 pwm_value;
> > +
> > +	pwm_value = readl(ddata->base + REG_POLARITY);
> > +
> > +	polarity = state->polarity;
> > +
> > +	if (polarity == PWM_POLARITY_NORMAL)
> > +		pwm_value &= ~BIT(pwm->hwpwm);
> > +	else
> > +		pwm_value |= BIT(pwm->hwpwm);
> > +
> > +	writel(pwm_value, ddata->base + REG_POLARITY);
> 
> I like this idiom better than the one used in
> pwm_sg2044_set_outputenable() and pwm_sg2044_config(). However drop the
> local variable polarity.
> 

I will modify that, thanks.

> > +	return 0;
> > +}
> > +
> > +static int pwm_sg2044_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > +			    const struct pwm_state *state)
> > +{
> > +	struct sg2042_pwm_ddata *ddata = pwmchip_get_drvdata(chip);
> > +	u32 hlperiod_ticks;
> > +	u32 period_ticks;
> > +
> > +	if (!state->enabled) {
> > +		pwm_sg2044_config(ddata, pwm, false);
> > +		return 0;
> > +	}
> > +
> > +	pwm_sg2044_set_polarity(ddata, pwm, state);
> > +
> > +	/*
> > +	 * Duration of High level (duty_cycle) = HLPERIOD x Period_of_input_clk
> > +	 * Duration of One Cycle (period) = PERIOD x Period_of_input_clk
> > +	 */
> > +	period_ticks = min(mul_u64_u64_div_u64(ddata->clk_rate_hz, state->period,
> > +					       NSEC_PER_SEC), U32_MAX);
> > +	hlperiod_ticks = min(mul_u64_u64_div_u64(ddata->clk_rate_hz, state->duty_cycle,
> > +						 NSEC_PER_SEC), U32_MAX);
> 
> This is the same calculation as for sg2042. I think I'd put that in a
> function that is used by both variants.
> 

Thanks, i will modify that.

> > +	dev_dbg(pwmchip_parent(chip), "chan[%u]: PERIOD=%u, HLPERIOD=%u\n",
> > +		pwm->hwpwm, period_ticks, hlperiod_ticks);
> 
> Now that there are more register values, please add them all to the
> debug output.
> 

I will, thanks.

> > +	pwm_sg2042_config(ddata, pwm->hwpwm, period_ticks, hlperiod_ticks);
> > +
> > +	guard(mutex)(&ddata->lock);
> > +
> > +	/*
> > +	 * re-enable PWMSTART to refresh the register period
> > +	 */
> > +	pwm_sg2044_config(ddata, pwm, false);
> 
> pwm_sg2044_config() is conceptually different to pwm_sg2042_config().
> This is irritating, so please find a better name.
> 

I will modify that, thanks.

> > +	pwm_sg2044_set_outputenable(ddata, pwm, true);
> > +	pwm_sg2044_config(ddata, pwm, true);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct sg2042_chip_data sg2042_chip_data = {
> > +	.ops = {
> > +		.apply = pwm_sg2042_apply,
> > +		.get_state = pwm_sg2042_get_state,
> > +	},
> > +	.atomic = true,
> > +};
> > +
> > +static const struct sg2042_chip_data sg2044_chip_data = {
> > +	.ops = {
> > +		.apply = pwm_sg2044_apply,
> > +		.get_state = pwm_sg2042_get_state,
> > +	},
> > +	.atomic = false,
> 
> If you drop the mutex don't forget to drop this one, too.
> 

I will, thanks for your reminder.

> >  };
> 
> Best regards
> Uwe

Best regards
Longbin Li

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ