From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-pwm@vger.kernel.org, kernel@pengutronix.de,
Bartosz Golaszewski <brgl@bgdev.pl>,
Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH v1 001/101] pwm: Provide devm_pwmchip_alloc() function
Date: Fri, 6 Oct 2023 11:23:49 +0200 [thread overview]
Message-ID: <ZR_SJW9vxOYoAC6N@orome.fritz.box> (raw)
In-Reply-To: <20230808171931.944154-2-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 5834 bytes --]
On Tue, Aug 08, 2023 at 07:17:51PM +0200, Uwe Kleine-König wrote:
> This function allocates a struct pwm_chip and driver data. Compared to
> the status quo the split into pwm_chip and driver data is new, otherwise
> it doesn't change anything relevant (yet).
>
> The intention is that after all drivers are switched to use this
> allocation function, its possible to add a struct device to struct
> pwm_chip to properly track the latter's lifetime without touching all
> drivers again. Proper lifetime tracking is a necessary precondition to
> introduce character device support for PWMs (that implements atomic
> setting and doesn't suffer from the sysfs overhead of the /sys/class/pwm
> userspace support).
>
> The new function pwmchip_priv() (obviously?) only works for chips
> allocated with devm_pwmchip_alloc().
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> .../driver-api/driver-model/devres.rst | 1 +
> Documentation/driver-api/pwm.rst | 10 +++----
> drivers/pwm/core.c | 30 ++++++++++++++++---
> include/linux/pwm.h | 5 ++++
> 4 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
> index 8be086b3f829..73a9ee074737 100644
> --- a/Documentation/driver-api/driver-model/devres.rst
> +++ b/Documentation/driver-api/driver-model/devres.rst
> @@ -414,6 +414,7 @@ POWER
> devm_reboot_mode_unregister()
>
> PWM
> + devm_pwmchip_alloc()
> devm_pwmchip_add()
> devm_pwm_get()
> devm_fwnode_pwm_get()
> diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
> index 3fdc95f7a1d1..a3824bd58e4c 100644
> --- a/Documentation/driver-api/pwm.rst
> +++ b/Documentation/driver-api/pwm.rst
> @@ -134,11 +134,11 @@ to implement the pwm_*() functions itself. This means that it's impossible
> to have multiple PWM drivers in the system. For this reason it's mandatory
> for new drivers to use the generic PWM framework.
>
> -A new PWM controller/chip can be added using pwmchip_add() and removed
> -again with pwmchip_remove(). pwmchip_add() takes a filled in struct
> -pwm_chip as argument which provides a description of the PWM chip, the
> -number of PWM devices provided by the chip and the chip-specific
> -implementation of the supported PWM operations to the framework.
> +A new PWM controller/chip can be allocated using devm_pwmchip_alloc, then added
> +using pwmchip_add() and removed again with pwmchip_remove(). pwmchip_add()
> +takes a filled in struct pwm_chip as argument which provides a description of
> +the PWM chip, the number of PWM devices provided by the chip and the
> +chip-specific implementation of the supported PWM operations to the framework.
>
> When implementing polarity support in a PWM driver, make sure to respect the
> signal conventions in the PWM framework. By definition, normal polarity
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 8aa3feec12a9..cfcddf62ab01 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -196,6 +196,31 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
> return true;
> }
>
> +void *pwmchip_priv(struct pwm_chip *chip)
> +{
> + return &chip[1];
> +}
> +EXPORT_SYMBOL_GPL(pwmchip_priv);
> +
> +struct pwm_chip *devm_pwmchip_alloc(struct device *parent, unsigned int npwm, size_t sizeof_priv)
> +{
> + struct pwm_chip *chip;
> + size_t alloc_size;
> + unsigned int i;
> +
> + alloc_size = sizeof(*chip) + sizeof_priv;
> +
> + chip = devm_kzalloc(parent, alloc_size, GFP_KERNEL);
Are you sure this works the way you want it to? If you allocate using
device-managed functions, this memory will be released when the driver
is unbound from the device, so we're basically back to square one,
aren't we?
> + if (!chip)
> + return ERR_PTR(-ENOMEM);
> +
> + chip->dev = parent;
> + chip->npwm = npwm;
> +
> + return chip;
> +}
> +EXPORT_SYMBOL_GPL(devm_pwmchip_alloc);
> +
> /**
> * __pwmchip_add() - register a new PWM chip
> * @chip: the PWM chip to add
> @@ -208,8 +233,6 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
> */
> int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
> {
> - struct pwm_device *pwm;
> - unsigned int i;
Am I missing something? You seem to be using this variable in the for
loop below, so how can you remove it?
Thierry
> int ret;
>
> if (!chip || !chip->dev || !chip->ops || !chip->npwm)
> @@ -234,9 +257,8 @@ int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
> }
>
> chip->id = ret;
> -
> for (i = 0; i < chip->npwm; i++) {
> - pwm = &chip->pwms[i];
> + struct pwm_device *pwm = &chip->pwms[i];
>
> pwm->chip = chip;
> pwm->hwpwm = i;
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 6f139784d6f5..3c0da17e193c 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -5,6 +5,7 @@
> #include <linux/err.h>
> #include <linux/mutex.h>
> #include <linux/of.h>
> +#include <linux/compiler_attributes.h>
>
> struct pwm_chip;
>
> @@ -380,6 +381,10 @@ static inline void pwm_disable(struct pwm_device *pwm)
> int pwm_capture(struct pwm_device *pwm, struct pwm_capture *result,
> unsigned long timeout);
>
> +void *pwmchip_priv(struct pwm_chip *chip) __attribute_const__;
> +
> +struct pwm_chip *devm_pwmchip_alloc(struct device *parent, unsigned int npwm, size_t sizeof_priv);
> +
> int __pwmchip_add(struct pwm_chip *chip, struct module *owner);
> #define pwmchip_add(chip) __pwmchip_add(chip, THIS_MODULE)
> void pwmchip_remove(struct pwm_chip *chip);
> --
> 2.40.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-10-06 9:23 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 17:17 [PATCH v1 000/101] pwm: Fix lifetime issues for pwm_chips Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 001/101] pwm: Provide devm_pwmchip_alloc() function Uwe Kleine-König
2023-10-06 9:23 ` Thierry Reding [this message]
2023-10-06 10:56 ` Uwe Kleine-König
2023-10-06 11:08 ` Thierry Reding
2023-10-06 12:36 ` Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 002/101] pwm: ab8500: Make use of " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 003/101] pwm: apple: " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 004/101] pwm: atmel-hlcdc: " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 005/101] pwm: atmel: " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 006/101] pwm: atmel-tcb: " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 007/101] pwm: bcm2835: " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 008/101] pwm: bcm-iproc: " Uwe Kleine-König
2023-08-08 17:17 ` [PATCH v1 009/101] pwm: bcm-kona: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 010/101] pwm: berlin: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 011/101] pwm: brcmstb: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 012/101] pwm: clk: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 013/101] pwm: clps711x: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 014/101] pwm: crc: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 015/101] pwm: cros-ec: Change prototype of helper to prepare further changes Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 016/101] pwm: cros-ec: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 017/101] pwm: dwc: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 018/101] pwm: ep93xx: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 019/101] pwm: fsl-ftm: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 020/101] pwm: hibvt: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 021/101] pwm: img: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 022/101] pwm: imx1: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 023/101] pwm: imx27: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 024/101] pwm: imx-tpm: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 025/101] pwm: intel-lgm: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 026/101] pwm: iqs620a: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 027/101] pwm: jz4740: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 028/101] pwm: keembay: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 029/101] pwm: lp3943: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 030/101] pwm: lpc18xx-sct: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 031/101] pwm: lpc32xx: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 032/101] pwm: lpss-*: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 033/101] pwm: mediatek: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 034/101] pwm: meson: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 035/101] pwm: microchip-core: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 036/101] pwm: mtk-disp: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 037/101] pwm: mxs: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 038/101] pwm: ntxec: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 039/101] pwm: omap-dmtimer: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 040/101] pwm: pca9685: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 041/101] pwm: pxa: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 042/101] pwm: raspberrypi-poe: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 043/101] pwm: rcar: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 044/101] pwm: renesas-tpu: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 045/101] pwm: rockchip: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 046/101] pwm: rz-mtu3: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 047/101] pwm: samsung: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 048/101] pwm: sifive: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 049/101] pwm: sl28cpld: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 050/101] pwm: spear: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 051/101] pwm: sprd: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 052/101] pwm: sti: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 053/101] pwm: stm32-lp: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 054/101] pwm: stm32: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 055/101] pwm: stmpe: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 056/101] pwm: sun4i: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 057/101] pwm: sunplus: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 058/101] pwm: tegra: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 059/101] pwm: tiecap: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 060/101] pwm: tiehrpwm: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 061/101] pwm: twl-led: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 062/101] pwm: twl: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 063/101] pwm: visconti: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 064/101] pwm: vt8500: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 065/101] pwm: xilinx: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 066/101] gpio: mvebu: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 067/101] drm/bridge: ti-sn65dsi86: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 068/101] leds: qcom-lpg: " Uwe Kleine-König
2023-08-08 17:18 ` [PATCH v1 069/101] staging: greybus: pwm: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 070/101] pwm: Ensure a struct pwm have the same lifetime as its pwm_chip Uwe Kleine-König
2023-10-06 9:38 ` Thierry Reding
2023-10-06 11:04 ` Uwe Kleine-König
2023-10-06 11:16 ` Thierry Reding
2023-10-06 17:04 ` Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 071/101] pwm: ab8500: Store parent device in driver data Uwe Kleine-König
2023-10-06 9:41 ` Thierry Reding
2023-10-06 11:09 ` Uwe Kleine-König
2023-10-06 11:20 ` Thierry Reding
2023-10-06 21:16 ` Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 072/101] pwm: atmel: Stop using struct pwm_chip::dev Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 073/101] pwm: dwc: Store parent device in driver data Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 074/101] pwm: ep93xx: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 075/101] pwm: fsl-ftm: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 076/101] pwm: img: Make use of parent device pointer " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 077/101] pwm: imx27: Store parent device " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 078/101] pwm: jz4740: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 079/101] pwm: lpc18xx-sct: Make use of parent device pointer " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 080/101] pwm: lpss: Store parent device " Uwe Kleine-König
2023-08-08 17:49 ` Andy Shevchenko
2023-08-09 6:10 ` Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 081/101] pwm: mediatek: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 082/101] pwm: meson: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 083/101] pwm: mtk-disp: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 084/101] pwm: omap: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 085/101] pwm: pca9685: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 086/101] pwm: raspberrypi-poe: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 087/101] pwm: rcar: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 088/101] pwm: rz-mtu3: Make use of parent device pointer " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 089/101] pwm: samsung: Store parent device " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 090/101] pwm: sifive: Make use of parent device pointer " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 091/101] pwm: stm32: Store parent device " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 092/101] pwm: stmpe: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 093/101] pwm: sun4i: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 094/101] pwm: tiecap: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 095/101] pwm: tiehrpwm: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 096/101] pwm: twl: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 097/101] pwm: twl-led: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 098/101] pwm: vt8500: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 099/101] staging: greybus: pwm: " Uwe Kleine-König
2023-08-08 17:19 ` [PATCH v1 100/101] pwm: Ensure the memory backing a PWM chip isn't freed while used Uwe Kleine-König
2023-10-06 12:37 ` Thierry Reding
2023-10-06 13:16 ` Uwe Kleine-König
2023-10-06 13:35 ` Andy Shevchenko
2023-08-08 17:19 ` [PATCH v1 101/101] pwm: Add more locking Uwe Kleine-König
2023-10-06 10:09 ` Thierry Reding
2023-10-06 11:14 ` Uwe Kleine-König
2023-09-26 10:06 ` [PATCH v1 000/101] pwm: Fix lifetime issues for pwm_chips Uwe Kleine-König
2023-10-01 11:10 ` Uwe Kleine-König
2023-10-06 10:15 ` Thierry Reding
2023-10-06 17:05 ` Uwe Kleine-König
2023-10-06 9:20 ` Thierry Reding
2023-10-06 10:41 ` Uwe Kleine-König
2023-10-06 11:50 ` Thierry Reding
2023-10-06 17:35 ` Uwe Kleine-König
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=ZR_SJW9vxOYoAC6N@orome.fritz.box \
--to=thierry.reding@gmail.com \
--cc=andy@kernel.org \
--cc=brgl@bgdev.pl \
--cc=kernel@pengutronix.de \
--cc=linux-pwm@vger.kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox