linux-kernel - Re: [PATCH v4 2/4] pwm: Add Apple PWM controller

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221219130610.yxggztlqnssm4k7c@pengutronix.de>
Date:   Mon, 19 Dec 2022 14:06:10 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Sasha Finkelstein <fnkl.kernel@...il.com>
Cc:     thierry.reding@...il.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, marcan@...can.st,
        sven@...npeter.dev, alyssa@...enzweig.io, asahi@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org, linux-pwm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/4] pwm: Add Apple PWM controller

Hello,

over all the driver looks good. Just a few smaller issues below.

I wonder if it's a good idea to call this driver "apple". SoC vendors
seem to reinvent their peripherals (or buy them somewhere else) for
their different generations of processors. Maybe call it "apple-s5l"
already today and not only when the next generation SoC appears?
(I don't feel strong here, if you want to delay that renaming until
there is an incompatible SoC that's fine for me.)

On Fri, Dec 09, 2022 at 02:13:11PM +0300, Sasha Finkelstein wrote:
> diff --git a/drivers/pwm/pwm-apple.c b/drivers/pwm/pwm-apple.c
> new file mode 100644
> index 000000000000..a85fecb20105
> --- /dev/null
> +++ b/drivers/pwm/pwm-apple.c
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Driver for the Apple SoC PWM controller
> + *
> + * Copyright The Asahi Linux Contributors
> + *
> + * Limitations:
> + * - The writes to cycle registers are shadowed until a write to
> + *   the control register.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/math64.h>

I didn't test, but I think you don't need pm_runtime.h here. Also maybe
the of headers are not needed?

> +#define APPLE_PWM_CONTROL     0x00
> +#define APPLE_PWM_ON_CYCLES   0x1c
> +#define APPLE_PWM_OFF_CYCLES  0x18
> +
> +#define APPLE_CTRL_ENABLE        BIT(0)
> +#define APPLE_CTRL_MODE          BIT(2)
> +#define APPLE_CTRL_UPDATE        BIT(5)
> +#define APPLE_CTRL_TRIGGER       BIT(9)
> +#define APPLE_CTRL_INVERT        BIT(10)
> +#define APPLE_CTRL_OUTPUT_ENABLE BIT(14)

Would be nice if the register prefix would match the register name. That
is please either rename APPLE_PWM_CONTROL to APPLE_PWM_CTRL or use
APPLE_PWM_CONTROL as prefix for the bit fields in that register.

> +
> +struct apple_pwm {
> +	struct pwm_chip chip;
> +	void __iomem *base;
> +	u64 clkrate;
> +};
> +
> +static inline struct apple_pwm *to_apple_pwm(struct pwm_chip *chip)
> +{
> +	return container_of(chip, struct apple_pwm, chip);
> +}
> +
> +static int apple_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			   const struct pwm_state *state)
> +{
> +	struct apple_pwm *fpwm;
> +	u64 on_cycles, off_cycles;

The declaration can move into the if block below.

> +
> +	fpwm = to_apple_pwm(chip);
> +	if (state->enabled) {
> +		on_cycles = mul_u64_u64_div_u64(fpwm->clkrate,
> +						state->duty_cycle, NSEC_PER_SEC);
> +		if (on_cycles > 0xFFFFFFFF)
> +			return -ERANGE;
> +
> +		off_cycles = mul_u64_u64_div_u64(fpwm->clkrate,
> +						 state->period, NSEC_PER_SEC) - on_cycles;
> +		if (off_cycles > 0xFFFFFFFF)
> +			return -ERANGE;
> +
> +		writel(on_cycles, fpwm->base + APPLE_PWM_ON_CYCLES);
> +		writel(off_cycles, fpwm->base + APPLE_PWM_OFF_CYCLES);
> +		writel(APPLE_CTRL_ENABLE | APPLE_CTRL_OUTPUT_ENABLE | APPLE_CTRL_UPDATE,
> +		       fpwm->base + APPLE_PWM_CONTROL);
> +	} else {
> +		writel(0, fpwm->base + APPLE_PWM_CONTROL);
> +	}
> +	return 0;

Assuming clkrate = 24000000, I wonder what happens if (duty_cycle and)
period are so small that on_cycles and off_cycles are both zero. How
does the hardware behave in this case?

> +}
> +
> +static void apple_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +			   struct pwm_state *state)
> +{
> +	struct apple_pwm *fpwm;
> +	u32 on_cycles, off_cycles, ctrl;
> +
> +	fpwm = to_apple_pwm(chip);
> +
> +	ctrl = readl(fpwm->base + APPLE_PWM_CONTROL);
> +	on_cycles = readl(fpwm->base + APPLE_PWM_ON_CYCLES);
> +	off_cycles = readl(fpwm->base + APPLE_PWM_OFF_CYCLES);
> +
> +	state->enabled = (ctrl & APPLE_CTRL_ENABLE) && (ctrl & APPLE_CTRL_OUTPUT_ENABLE);
> +	state->polarity = PWM_POLARITY_NORMAL;
> +	state->duty_cycle = mul_u64_u64_div_u64(on_cycles, NSEC_PER_SEC, fpwm->clkrate);
> +	state->period = mul_u64_u64_div_u64(off_cycles + on_cycles,
> +					    NSEC_PER_SEC, fpwm->clkrate);

Wrong rounding direction, you need to round up. Did you test with
PWM_DEBUG on? This should point out the more obvious cases. Assuming
clkrate = 24000000 for example setting .duty_cycle = 3 should trigger a
warning.

Unfortunately there is no variant of mul_u64_u64_div_u64 that rounds up,
maybe we need to introduce one.

> +}

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)