public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
* [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips
@ 2024-02-14  9:30 Uwe Kleine-König
  2024-02-14  9:30 ` [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip Uwe Kleine-König
                   ` (9 more replies)
  0 siblings, 10 replies; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:30 UTC (permalink / raw)
  To: linux-pwm, Jonathan Corbet, Jonathan Cameron, James Clark,
	Andy Shevchenko, Mark Brown, Hector Martin, Sven Peter,
	Claudiu Beznea, Nicolas Ferre, Alexandre Belloni,
	Florian Fainelli, Ray Jui, Scott Branden, Alexander Shiyan,
	Benson Leung, Philipp Zabel, Shawn Guo, Sascha Hauer,
	Paul Cercueil, Vladimir Zapolskiy, Mika Westerberg,
	Andy Shevchenko, Linus Walleij, Hans de Goede, Ilpo Järvinen,
	Matthias Brugger, AngeloGioacchino Del Regno, Neil Armstrong,
	Kevin Hilman, Conor Dooley, Daire McNamara,
	Jonathan Neuschäfer, Heiko Stuebner, Krzysztof Kozlowski,
	Palmer Dabbelt, Paul Walmsley, Michael Walle, Orson Zhai,
	Baolin Wang, Chunyan Zhang, Fabrice Gasnier, Maxime Coquelin,
	Alexandre Torgue, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
	Hammer Hsieh, Thierry Reding, Jonathan Hunter, Nobuhiro Iwamatsu,
	Sean Anderson, Michal Simek, Bartosz Golaszewski, Andrzej Hajda,
	Robert Foss, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter, Pavel Machek, Lee Jones,
	Anjelique Melendez, Bjorn Andersson, Kees Cook, Rob Herring,
	Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: kernel, linux-doc, Alyssa Rosenzweig, asahi, linux-arm-kernel,
	Broadcom internal kernel review list, linux-rpi-kernel,
	Guenter Roeck, chrome-platform, Fabio Estevam, NXP Linux Team,
	linux-mips, linux-gpio, platform-driver-x86, linux-mediatek,
	Jerome Brunet, Martin Blumenstingl, linux-amlogic, linux-riscv,
	linux-rockchip, Alim Akhtar, linux-samsung-soc, linux-stm32,
	linux-sunxi, linux-tegra, Douglas Anderson, Laurent Pinchart,
	Jonas Karlman, dri-devel, linux-leds, greybus-dev, linux-staging,
	Gustavo A. R. Silva, linux-hardening

Hello,

this is v6 of the series introducing better lifetime tracking for
pwmchips that addresses (for now theoretic) lifetime issues of pwm
chips. Addressing these is a necessary precondition to introduce chardev
support for PWMs.

Locking got more complicated due to non-sleeping chips, so I dropped
the character device patch because it got still more incomplete now.
Also I'm not yet entirely sure about patches #162 and #163 and I expect
them to change before they can go in. My plan for the next merge window
is to get the patches in up to #160. After that the addition of chardev
support (including correct locking) can continue without having to touch
the lowlevel driver. So the idea of this series is to get the driver
adaptions out of the way as this requires some cross-tree coordination.

The patches that touch files outside of drivers/pwm include:

 - gpio: mvebu: Make use of devm_pwmchip_alloc() function
   It already has an Ack by Linus Walleij.

 - drm/bridge: ti-sn65dsi86: Make use of pwmchip_parent() accessor
 - drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function
   The 2nd already has an Ack by Douglas Anderson which I tend to assume
   good enough to merge this via my pwm tree, too. An Ack for the first
   patch would be nice.

 - leds: qcom-lpg: Make use of devm_pwmchip_alloc() function
   Already has an Ack by Lee Jones.

 - staging: greybus: pwm: Change prototype of helpers to prepare further changes
 - staging: greybus: pwm: Make use of pwmchip_parent() accessor
 - staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm
 - staging: greybus: pwm: Drop unused gb_connection_set_data()
 - staging: greybus: pwm: Rework how the number of PWM lines is determined
 - staging: greybus: pwm: Make use of devm_pwmchip_alloc() function
   The greybus patches already got an Ack by Greg Kroah-Hartman in an
   earlier series, but I dropped it as the patches changed considerably.

For the patches that already have an Ack by the respective maintainers
I'll assume this is good enough to merge the patches via the pwm tree.
Please object if you don't agree.  For the others an Ack with that
semantic would be nice. If you want to merge via your tree, that would
need some coordination. The adaptions depend on patches #1 - #3, so this
would involve an immutable branch or waiting until these patches reached
your tree via the mainline tree. The series rebases fine on today's
next, so at least for now there are no conflicts that git cannot resolve
automatically.

The biggest changes compared to v5 are:

 - Make pwmchip_parent's parameter const
 - Use pwmchip_parent also in drivers/pwm/sysfs.c and drivers/pwm/core.c
 - Several bug fixes in the conversions I found during the rework
 - Provide a non-devm pwmchip_alloc() function earlier (for the greybus
   pwm driver)
 - Increase alignment of driver private data to ARCH_DMA_MINALIGN bytes
 - Split several patches to make the easier reviewable

The series is available via git at

	https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm-lifetime-tracking

if you want to give it a test. I'll keep this branch updated for the
feedback I get here.

Best regards
Uwe

Uwe Kleine-König (164):
  pwm: Provide an inline function to get the parent device of a given
    chip
  pwm: Provide wrappers for storing and getting driver private data
  pwm: Provide pwmchip_alloc() function and a devm variant of it
  pwm: ab8500: Make use of pwmchip_parent() accessor
  pwm: ab8500: Introduce a local pwm_chip variable in .probe()
  pwm: ab8500: Make use of devm_pwmchip_alloc() function
  pwm: apple: Make use of devm_pwmchip_alloc() function
  pwm: atmel: Change prototype of a helper to prepare further changes
  pwm: atmel: Make use of pwmchip_parent() accessor
  pwm: atmel: Make use of devm_pwmchip_alloc() function
  pwm: atmel-hlcdc: Prepare removing pwm_chip from driver data
  pwm: atmel-hlcdc: Make use of devm_pwmchip_alloc() function
  pwm: atmel-tcb: Make use of pwmchip_parent() accessor
  pwm: atmel-tcb: Prepare removing pwm_chip from driver data
  pwm: atmel-tcb: Make use of devm_pwmchip_alloc() function
  pwm: bcm2835: Make use of devm_pwmchip_alloc() function
  pwm: bcm-iproc: Make use of devm_pwmchip_alloc() function
  pwm: bcm-kona: Make use of pwmchip_parent() accessor
  pwm: bcm-kona: Make use of devm_pwmchip_alloc() function
  pwm: berlin: Prepare removing pwm_chip from driver data
  pwm: berlin: Make use of devm_pwmchip_alloc() function
  pwm: brcmstb: Make use of devm_pwmchip_alloc() function
  pwm: clk: Prepare removing pwm_chip from driver data
  pwm: clk: Make use of devm_pwmchip_alloc() function
  pwm: clps711x: Make use of devm_pwmchip_alloc() function
  pwm: crc: Simplify code to determine the pwmchip's parent device
  pwm: crc: Make use of pwmchip_parent() accessor
  pwm: crc: Make use of devm_pwmchip_alloc() function
  pwm: cros-ec: Change prototype of helpers to prepare further changes
  pwm: cros-ec: Make use of pwmchip_parent() accessor
  pwm: cros-ec: Make use of devm_pwmchip_alloc() function
  pwm: dwc: Prepare removing pwm_chip from driver data
  pwm: dwc: Make use of devm_pwmchip_alloc() function
  pwm: dwc-core: Make use of pwmchip_parent() accessor
  pwm: ep93xx: Make use of pwmchip_parent() accessor
  pwm: ep93xx: Make use of devm_pwmchip_alloc() function
  pwm: fsl-ftm: Change prototype of a helper to prepare further changes
  pwm: fsl-ftm: Make use of pwmchip_parent() accessor
  pwm: fsl-ftm: Prepare removing pwm_chip from driver data
  pwm: fsl-ftm: Make use of devm_pwmchip_alloc() function
  pwm: hibvt: Consistently name driver data hi_pwm_chip
  pwm: hibvt: Make use of devm_pwmchip_alloc() function
  pwm: img: Drop write-only variable from driver private data
  pwm: img: Make use of pwmchip_parent() accessor
  pwm: img: Prepare removing pwm_chip from driver data
  pwm: img: Make use of devm_pwmchip_alloc() function
  pwm: imx1: Make use of devm_pwmchip_alloc() function
  pwm: imx27: Make use of pwmchip_parent() accessor
  pwm: imx27: Make use of devm_pwmchip_alloc() function
  pwm: imx-tpm: Make use of devm_pwmchip_alloc() function
  pwm: intel-lgm: Make use of devm_pwmchip_alloc() function
  pwm: iqs620a: Create a wrapper for converting a pwm_chip to driver
    data
  pwm: iqs620a: Prepare removing pwm_chip from driver data
  pwm: iqs620a: Make use of devm_pwmchip_alloc() function
  pwm: jz4740: Change prototype of a helper to prepare further changes
  pwm: jz4740: Make use of pwmchip_parent() accessor
  pwm: jz4740: Make use of devm_pwmchip_alloc() function
  pwm: keembay: Make use of devm_pwmchip_alloc() function
  pwm: lp3943: Make use of devm_pwmchip_alloc() function
  pwm: lpc18xx-sct: Drop hardly used member from driver private data
  pwm: lpc18xx-sct: Make use of pwmchip_parent() accessor
  pwm: lpc18xx-sct: Prepare removing pwm_chip from driver data
  pwm: lpc18xx-sct: Make use of devm_pwmchip_alloc() function
  pwm: lpc32xx: Make use of devm_pwmchip_alloc() function
  pwm: lpss: Make use of pwmchip_parent() accessor
  pwm: lpss: Don't set driver data
  pwm: lpss-*: Make use of devm_pwmchip_alloc() function
  pwm: mediatek: Make use of pwmchip_parent() accessor
  pwm: mediatek: Make use of devm_pwmchip_alloc() function
  pwm: meson: Change prototype of a few helpers to prepare further
    changes
  pwm: meson: Make use of pwmchip_parent() accessor
  pwm: meson: Make use of devm_pwmchip_alloc() function
  pwm: microchip-core: Make use of devm_pwmchip_alloc() function
  pwm: mtk-disp: Make use of pwmchip_parent() accessor
  pwm: mtk-disp: Make use of devm_pwmchip_alloc() function
  pwm: mxs: Make use of devm_pwmchip_alloc() function
  pwm: ntxec: Make use of devm_pwmchip_alloc() function
  pwm: omap-dmtimer: Make use of pwmchip_parent() accessor
  pwm: omap-dmtimer: Prepare removing pwm_chip from driver data
  pwm: omap-dmtimer: Make use of devm_pwmchip_alloc() function
  pwm: pca9685: Prepare removing pwm_chip from driver data
  pwm: pca9685: Make use of pwmchip_parent() accessor
  pwm: pca9685: Make use of devm_pwmchip_alloc() function
  pwm: pxa: Make use of devm_pwmchip_alloc() function
  pwm: raspberrypi-poe: Make use of pwmchip_parent() accessor
  pwm: raspberrypi-poe: Make use of devm_pwmchip_alloc() function
  pwm: rcar: Make use of pwmchip_parent() accessor
  pwm: rcar: Prepare removing pwm_chip from driver data
  pwm: rcar: Make use of devm_pwmchip_alloc() function
  pwm: renesas-tpu: Make use of devm_pwmchip_alloc() function
  pwm: rochchip: Prepare removing pwm_chip from driver data
  pwm: rockchip: Make use of devm_pwmchip_alloc() function
  pwm: rz-mtu3: Make use of pwmchip_parent() accessor
  pwm: rz-mtu3: Prepare removing pwm_chip from driver data
  pwm: rz-mtu3: Make use of devm_pwmchip_alloc() function
  pwm: samsung: Simplify code to determine the pwmchip's parent device
  pwm: samsung: Change prototype of helpers to prepare further changes
  pwm: samsung: Make use of pwmchip_parent() accessor
  pwm: samsung: Simplify by using devm functions in probe
  pwm: samsung: Simplify using dev_err_probe()
  pwm: samsung: Make use of devm_pwmchip_alloc() function
  pwm: sifive: Simplify code to determine the pwmchip's parent device
  pwm: sifive: Prepare removing pwm_chip from driver data
  pwm: sifive: Make use of pwmchip_parent() accessor
  pwm: sifive: Make use of devm_pwmchip_alloc() function
  pwm: sl28cpld: Make use of devm_pwmchip_alloc() function
  pwm: spear: Make use of devm_pwmchip_alloc() function
  pwm: sprd: Rework how the available channels are counted
  pwm: sprd: Drop duplicated tracking of the parent device
  pwm: sprd: Make use of devm_pwmchip_alloc() function
  pwm: sti: Prepare removing pwm_chip from driver data
  pwm: sti: Make use of devm_pwmchip_alloc() function
  pwm: stm32: Simplify code to determine the pwmchip's parent device
  pwm: stm32: Change prototype of a helper to prepare further changes
  pwm: stm32: Prepare removing pwm_chip from driver data
  pwm: stm32: Change prototype of helper that detects npwm to prepare
    further changes
  pwm: stm32: Make use of devm_pwmchip_alloc() function
  pwm: stm32-lp: Simplify code to determine the pwmchip's parent device
  pwm: stm32-lp: Prepare removing pwm_chip from driver data
  pwm: stm32-lp: Make use of pwmchip_parent() accessor
  pwm: stm32-lp: Make use of devm_pwmchip_alloc() function
  pwm: stmpe: Make use of pwmchip_parent() accessor
  pwm: stmpe: Make use of devm_pwmchip_alloc() function
  pwm: sun4i: Make use of pwmchip_parent() accessor
  pwm: sun4i: Prepare removing pwm_chip from driver data
  pwm: sun4i: Consistently name driver data sun4ichip
  pwm: sun4i: Make use of devm_pwmchip_alloc() function
  pwm: sunplus: Make use of devm_pwmchip_alloc() function
  pwm: tegra: Drop duplicated tracking of the parent device
  pwm: tegra: Prepare removing pwm_chip from driver data
  pwm: tegra: Make use of devm_pwmchip_alloc() function
  pwm: tiecap: Simplify code to determine the pwmchip's parent device
  pwm: tiecap: Change prototype of helpers to prepare further changes
  pwm: tiecap: Make use of pwmchip_parent() accessor
  pwm: tiecap: Make use of devm_pwmchip_alloc() function
  pwm: tiehrpwm: Simplify code to determine the pwmchip's parent device
  pwm: tiehrpwm: Change prototype of helpers to prepare further changes
  pwm: tiehrpwm: Make use of pwmchip_parent() accessor
  pwm: tiehrpwm: Make use of devm_pwmchip_alloc() function
  pwm: twl: Make use of pwmchip_parent() accessor
  pwm: twl: Make use of devm_pwmchip_alloc() function
  pwm: twl-led: Make use of pwmchip_parent() accessor
  pwm: twl-led: Make use of devm_pwmchip_alloc() function
  pwm: visconti: Make use of devm_pwmchip_alloc() function
  pwm: vt8500: Change prototype of a helper to prepare further changes
  pwm: vt8500: Introduce a local pwm_chip variable in .probe()
  pwm: vt8500: Make use of pwmchip_parent() accessor
  pwm: vt8500: Make use of devm_pwmchip_alloc() function
  pwm: xilinx: Prepare removing pwm_chip from driver data
  pwm: xilinx: Make use of devm_pwmchip_alloc() function
  gpio: mvebu: Make use of devm_pwmchip_alloc() function
  drm/bridge: ti-sn65dsi86: Make use of pwmchip_parent() accessor
  drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function
  leds: qcom-lpg: Make use of devm_pwmchip_alloc() function
  staging: greybus: pwm: Change prototype of helpers to prepare further
    changes
  staging: greybus: pwm: Make use of pwmchip_parent() accessor
  staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm
  staging: greybus: pwm: Drop unused gb_connection_set_data()
  staging: greybus: pwm: Rework how the number of PWM lines is
    determined
  staging: greybus: pwm: Make use of devm_pwmchip_alloc() function
  pwm: Ensure that pwm_chips are allocated using pwmchip_alloc()
  pwm: Ensure a struct pwm has the same lifetime as its pwm_chip
  pwm: Ensure the memory backing a PWM chip isn't freed while used
  pwm: Make pwmchip_[sg]et_drvdata() a wrapper around dev_set_drvdata()

 .../driver-api/driver-model/devres.rst        |   1 +
 Documentation/driver-api/pwm.rst              |  11 +-
 drivers/gpio/gpio-mvebu.c                     |  18 +-
 drivers/gpu/drm/bridge/ti-sn65dsi86.c         |  31 +--
 drivers/leds/rgb/leds-qcom-lpg.c              |  16 +-
 drivers/pinctrl/intel/pinctrl-intel.c         |   6 +-
 drivers/pwm/Kconfig                           |   4 -
 drivers/pwm/Makefile                          |   3 +-
 drivers/pwm/core.c                            | 184 +++++++++++++-----
 drivers/pwm/pwm-ab8500.c                      |  36 ++--
 drivers/pwm/pwm-apple.c                       |  18 +-
 drivers/pwm/pwm-atmel-hlcdc.c                 |  37 ++--
 drivers/pwm/pwm-atmel-tcb.c                   |  32 +--
 drivers/pwm/pwm-atmel.c                       |  34 ++--
 drivers/pwm/pwm-bcm-iproc.c                   |  19 +-
 drivers/pwm/pwm-bcm-kona.c                    |  23 ++-
 drivers/pwm/pwm-bcm2835.c                     |  19 +-
 drivers/pwm/pwm-berlin.c                      |  29 +--
 drivers/pwm/pwm-brcmstb.c                     |  17 +-
 drivers/pwm/pwm-clk.c                         |  27 +--
 drivers/pwm/pwm-clps711x.c                    |  17 +-
 drivers/pwm/pwm-crc.c                         |  22 +--
 drivers/pwm/pwm-cros-ec.c                     |  58 +++---
 drivers/pwm/pwm-dwc-core.c                    |  26 +--
 drivers/pwm/pwm-dwc.c                         |  17 +-
 drivers/pwm/pwm-dwc.h                         |   9 +-
 drivers/pwm/pwm-ep93xx.c                      |  21 +-
 drivers/pwm/pwm-fsl-ftm.c                     |  49 ++---
 drivers/pwm/pwm-hibvt.c                       |  70 ++++---
 drivers/pwm/pwm-img.c                         |  60 +++---
 drivers/pwm/pwm-imx-tpm.c                     |  34 ++--
 drivers/pwm/pwm-imx1.c                        |  20 +-
 drivers/pwm/pwm-imx27.c                       |  26 +--
 drivers/pwm/pwm-intel-lgm.c                   |  17 +-
 drivers/pwm/pwm-iqs620a.c                     |  30 +--
 drivers/pwm/pwm-jz4740.c                      |  36 ++--
 drivers/pwm/pwm-keembay.c                     |  17 +-
 drivers/pwm/pwm-lp3943.c                      |  17 +-
 drivers/pwm/pwm-lpc18xx-sct.c                 |  34 ++--
 drivers/pwm/pwm-lpc32xx.c                     |  21 +-
 drivers/pwm/pwm-lpss-pci.c                    |  10 +-
 drivers/pwm/pwm-lpss-platform.c               |  10 +-
 drivers/pwm/pwm-lpss.c                        |  34 ++--
 drivers/pwm/pwm-lpss.h                        |   1 -
 drivers/pwm/pwm-mediatek.c                    |  29 +--
 drivers/pwm/pwm-meson.c                       |  57 +++---
 drivers/pwm/pwm-microchip-core.c              |  17 +-
 drivers/pwm/pwm-mtk-disp.c                    |  25 ++-
 drivers/pwm/pwm-mxs.c                         |  32 +--
 drivers/pwm/pwm-ntxec.c                       |  14 +-
 drivers/pwm/pwm-omap-dmtimer.c                |  47 +++--
 drivers/pwm/pwm-pca9685.c                     | 161 +++++++--------
 drivers/pwm/pwm-pxa.c                         |  21 +-
 drivers/pwm/pwm-raspberrypi-poe.c             |  20 +-
 drivers/pwm/pwm-rcar.c                        |  27 ++-
 drivers/pwm/pwm-renesas-tpu.c                 |  20 +-
 drivers/pwm/pwm-rockchip.c                    |  24 +--
 drivers/pwm/pwm-rz-mtu3.c                     |  60 +++---
 drivers/pwm/pwm-samsung.c                     |  94 ++++-----
 drivers/pwm/pwm-sifive.c                      |  30 +--
 drivers/pwm/pwm-sl28cpld.c                    |  13 +-
 drivers/pwm/pwm-spear.c                       |  18 +-
 drivers/pwm/pwm-sprd.c                        |  58 +++---
 drivers/pwm/pwm-sti.c                         |  61 +++---
 drivers/pwm/pwm-stm32-lp.c                    |  31 ++-
 drivers/pwm/pwm-stm32.c                       |  56 +++---
 drivers/pwm/pwm-stmpe.c                       |  58 +++---
 drivers/pwm/pwm-sun4i.c                       | 100 +++++-----
 drivers/pwm/pwm-sunplus.c                     |  17 +-
 drivers/pwm/pwm-tegra.c                       |  50 ++---
 drivers/pwm/pwm-tiecap.c                      |  55 +++---
 drivers/pwm/pwm-tiehrpwm.c                    |  72 +++----
 drivers/pwm/pwm-twl-led.c                     |  55 +++---
 drivers/pwm/pwm-twl.c                         |  50 +++--
 drivers/pwm/pwm-visconti.c                    |  17 +-
 drivers/pwm/pwm-vt8500.c                      |  43 ++--
 drivers/pwm/pwm-xilinx.c                      |  34 ++--
 drivers/pwm/sysfs.c                           |  45 +----
 drivers/staging/greybus/pwm.c                 | 133 ++++++-------
 include/linux/platform_data/x86/pwm-lpss.h    |   4 +-
 include/linux/pwm.h                           |  56 ++++--
 81 files changed, 1502 insertions(+), 1423 deletions(-)


base-commit: ab105bfee27776dd946f8003d1e895fbf7674a3f
-- 
2.43.0


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
@ 2024-02-14  9:30 ` Uwe Kleine-König
  2024-02-14 10:39   ` Greg Kroah-Hartman
  2024-02-14  9:33 ` [PATCH v6 155/164] staging: greybus: pwm: Change prototype of helpers to prepare further changes Uwe Kleine-König
                   ` (8 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:30 UTC (permalink / raw)
  To: linux-pwm, Claudiu Beznea, Nicolas Ferre, Alexandre Belloni,
	Florian Fainelli, Ray Jui, Scott Branden, Benson Leung, Shawn Guo,
	Sascha Hauer, Paul Cercueil, Vladimir Zapolskiy, Matthias Brugger,
	AngeloGioacchino Del Regno, Neil Armstrong, Kevin Hilman,
	Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
	Fabrice Gasnier, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
	Jernej Skrabec, Samuel Holland, Johan Hovold, Alex Elder,
	Greg Kroah-Hartman
  Cc: kernel, linux-arm-kernel, Broadcom internal kernel review list,
	Guenter Roeck, chrome-platform, Fabio Estevam, NXP Linux Team,
	linux-mips, linux-mediatek, Jerome Brunet, Martin Blumenstingl,
	linux-amlogic, linux-rpi-kernel, Alim Akhtar, linux-samsung-soc,
	linux-riscv, linux-stm32, linux-sunxi, greybus-dev, linux-staging

Currently a pwm_chip stores in its struct device *dev member a pointer
to the parent device. Preparing a change that embeds a full struct
device in struct pwm_chip, this accessor function should be used in all
drivers directly accessing chip->dev now. This way struct pwm_chip and
this new function can be changed without having to touch all drivers in
the same change set.

Make use of this function in the framework's core sources.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/pwm/core.c  | 42 +++++++++++++++++++++---------------------
 drivers/pwm/sysfs.c |  4 ++--
 include/linux/pwm.h |  5 +++++
 3 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1b4c3d0caa82..830a697826af 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -71,18 +71,18 @@ static void pwm_apply_debug(struct pwm_device *pwm,
 
 	if (s2.polarity != state->polarity &&
 	    state->duty_cycle < state->period)
-		dev_warn(chip->dev, ".apply ignored .polarity\n");
+		dev_warn(pwmchip_parent(chip), ".apply ignored .polarity\n");
 
 	if (state->enabled &&
 	    last->polarity == state->polarity &&
 	    last->period > s2.period &&
 	    last->period <= state->period)
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 ".apply didn't pick the best available period (requested: %llu, applied: %llu, possible: %llu)\n",
 			 state->period, s2.period, last->period);
 
 	if (state->enabled && state->period < s2.period)
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 ".apply is supposed to round down period (requested: %llu, applied: %llu)\n",
 			 state->period, s2.period);
 
@@ -91,20 +91,20 @@ static void pwm_apply_debug(struct pwm_device *pwm,
 	    last->period == s2.period &&
 	    last->duty_cycle > s2.duty_cycle &&
 	    last->duty_cycle <= state->duty_cycle)
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 ".apply didn't pick the best available duty cycle (requested: %llu/%llu, applied: %llu/%llu, possible: %llu/%llu)\n",
 			 state->duty_cycle, state->period,
 			 s2.duty_cycle, s2.period,
 			 last->duty_cycle, last->period);
 
 	if (state->enabled && state->duty_cycle < s2.duty_cycle)
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 ".apply is supposed to round down duty_cycle (requested: %llu/%llu, applied: %llu/%llu)\n",
 			 state->duty_cycle, state->period,
 			 s2.duty_cycle, s2.period);
 
 	if (!state->enabled && s2.enabled && s2.duty_cycle > 0)
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 "requested disabled, but yielded enabled with duty > 0\n");
 
 	/* reapply the state that the driver reported being configured. */
@@ -112,7 +112,7 @@ static void pwm_apply_debug(struct pwm_device *pwm,
 	trace_pwm_apply(pwm, &s1, err);
 	if (err) {
 		*last = s1;
-		dev_err(chip->dev, "failed to reapply current setting\n");
+		dev_err(pwmchip_parent(chip), "failed to reapply current setting\n");
 		return;
 	}
 
@@ -127,7 +127,7 @@ static void pwm_apply_debug(struct pwm_device *pwm,
 	    s1.polarity != last->polarity ||
 	    (s1.enabled && s1.period != last->period) ||
 	    (s1.enabled && s1.duty_cycle != last->duty_cycle)) {
-		dev_err(chip->dev,
+		dev_err(pwmchip_parent(chip),
 			".apply is not idempotent (ena=%d pol=%d %llu/%llu) -> (ena=%d pol=%d %llu/%llu)\n",
 			s1.enabled, s1.polarity, s1.duty_cycle, s1.period,
 			last->enabled, last->polarity, last->duty_cycle,
@@ -318,7 +318,7 @@ static struct pwm_chip *pwmchip_find_by_name(const char *name)
 	mutex_lock(&pwm_lock);
 
 	idr_for_each_entry_ul(&pwm_chips, chip, tmp, id) {
-		const char *chip_name = dev_name(chip->dev);
+		const char *chip_name = dev_name(pwmchip_parent(chip));
 
 		if (chip_name && strcmp(chip_name, name) == 0) {
 			mutex_unlock(&pwm_lock);
@@ -456,19 +456,19 @@ EXPORT_SYMBOL_GPL(of_pwm_single_xlate);
 
 static void of_pwmchip_add(struct pwm_chip *chip)
 {
-	if (!chip->dev || !chip->dev->of_node)
+	if (!pwmchip_parent(chip) || !pwmchip_parent(chip)->of_node)
 		return;
 
 	if (!chip->of_xlate)
 		chip->of_xlate = of_pwm_xlate_with_flags;
 
-	of_node_get(chip->dev->of_node);
+	of_node_get(pwmchip_parent(chip)->of_node);
 }
 
 static void of_pwmchip_remove(struct pwm_chip *chip)
 {
-	if (chip->dev)
-		of_node_put(chip->dev->of_node);
+	if (pwmchip_parent(chip))
+		of_node_put(pwmchip_parent(chip)->of_node);
 }
 
 static bool pwm_ops_check(const struct pwm_chip *chip)
@@ -479,7 +479,7 @@ static bool pwm_ops_check(const struct pwm_chip *chip)
 		return false;
 
 	if (IS_ENABLED(CONFIG_PWM_DEBUG) && !ops->get_state)
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 "Please implement the .get_state() callback\n");
 
 	return true;
@@ -500,7 +500,7 @@ int __pwmchip_add(struct pwm_chip *chip, struct module *owner)
 	unsigned int i;
 	int ret;
 
-	if (!chip || !chip->dev || !chip->ops || !chip->npwm)
+	if (!chip || !pwmchip_parent(chip) || !chip->ops || !chip->npwm)
 		return -EINVAL;
 
 	if (!pwm_ops_check(chip))
@@ -594,15 +594,15 @@ static struct device_link *pwm_device_link_add(struct device *dev,
 		 * impact the PM sequence ordering: the PWM supplier may get
 		 * suspended before the consumer.
 		 */
-		dev_warn(pwm->chip->dev,
+		dev_warn(pwmchip_parent(pwm->chip),
 			 "No consumer device specified to create a link to\n");
 		return NULL;
 	}
 
-	dl = device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+	dl = device_link_add(dev, pwmchip_parent(pwm->chip), DL_FLAG_AUTOREMOVE_CONSUMER);
 	if (!dl) {
 		dev_err(dev, "failed to create device link to %s\n",
-			dev_name(pwm->chip->dev));
+			dev_name(pwmchip_parent(pwm->chip)));
 		return ERR_PTR(-EINVAL);
 	}
 
@@ -617,7 +617,7 @@ static struct pwm_chip *fwnode_to_pwmchip(struct fwnode_handle *fwnode)
 	mutex_lock(&pwm_lock);
 
 	idr_for_each_entry_ul(&pwm_chips, chip, tmp, id)
-		if (chip->dev && device_match_fwnode(chip->dev, fwnode)) {
+		if (pwmchip_parent(chip) && device_match_fwnode(pwmchip_parent(chip), fwnode)) {
 			mutex_unlock(&pwm_lock);
 			return chip;
 		}
@@ -1085,8 +1085,8 @@ static int pwm_seq_show(struct seq_file *s, void *v)
 
 	seq_printf(s, "%s%d: %s/%s, %d PWM device%s\n",
 		   (char *)s->private, chip->id,
-		   chip->dev->bus ? chip->dev->bus->name : "no-bus",
-		   dev_name(chip->dev), chip->npwm,
+		   pwmchip_parent(chip)->bus ? pwmchip_parent(chip)->bus->name : "no-bus",
+		   dev_name(pwmchip_parent(chip)), chip->npwm,
 		   (chip->npwm != 1) ? "s" : "");
 
 	pwm_dbg_show(chip, s);
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 1698609d91c8..3f434a771fb5 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -509,10 +509,10 @@ void pwmchip_sysfs_export(struct pwm_chip *chip)
 	 * If device_create() fails the pwm_chip is still usable by
 	 * the kernel it's just not exported.
 	 */
-	parent = device_create(&pwm_class, chip->dev, MKDEV(0, 0), chip,
+	parent = device_create(&pwm_class, pwmchip_parent(chip), MKDEV(0, 0), chip,
 			       "pwmchip%d", chip->id);
 	if (IS_ERR(parent)) {
-		dev_warn(chip->dev,
+		dev_warn(pwmchip_parent(chip),
 			 "device_create failed for pwm_chip sysfs export\n");
 	}
 }
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 8ffe9ae7a23a..07af6910bdce 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -289,6 +289,11 @@ struct pwm_chip {
 	struct pwm_device *pwms;
 };
 
+static inline struct device *pwmchip_parent(const struct pwm_chip *chip)
+{
+	return chip->dev;
+}
+
 #if IS_ENABLED(CONFIG_PWM)
 /* PWM user APIs */
 int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v6 155/164] staging: greybus: pwm: Change prototype of helpers to prepare further changes
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
  2024-02-14  9:30 ` [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip Uwe Kleine-König
@ 2024-02-14  9:33 ` Uwe Kleine-König
  2024-02-14 10:40   ` Greg Kroah-Hartman
  2024-02-14  9:33 ` [PATCH v6 156/164] staging: greybus: pwm: Make use of pwmchip_parent() accessor Uwe Kleine-König
                   ` (7 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:33 UTC (permalink / raw)
  To: Johan Hovold, Alex Elder, Greg Kroah-Hartman, linux-pwm
  Cc: greybus-dev, linux-staging, kernel

This prepares the driver for further changes that will make it harder to
determine the pwm_chip from a given gb_pwm_chip. To just not have
to do that, rework gb_pwm_activate_operation(),
gb_pwm_deactivate_operation(), gb_pwm_config_operation(),
gb_pwm_set_polarity_operation(), gb_pwm_enable_operation() and
gb_pwm_disable_operation() to take a pwm_chip. Also use the pwm_chip as
driver data instead of the gb_pwm_chip.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/staging/greybus/pwm.c | 60 +++++++++++++++++------------------
 1 file changed, 29 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index a3cb68cfa0f9..97b49d436c54 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -39,9 +39,9 @@ static int gb_pwm_count_operation(struct gb_pwm_chip *pwmc)
 	return 0;
 }
 
-static int gb_pwm_activate_operation(struct gb_pwm_chip *pwmc,
-				     u8 which)
+static int gb_pwm_activate_operation(struct pwm_chip *chip, u8 which)
 {
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_pwm_activate_request request;
 	struct gbphy_device *gbphy_dev;
 	int ret;
@@ -51,7 +51,7 @@ static int gb_pwm_activate_operation(struct gb_pwm_chip *pwmc,
 
 	request.which = which;
 
-	gbphy_dev = to_gbphy_dev(pwmc->chip.dev);
+	gbphy_dev = to_gbphy_dev(chip->dev);
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -64,9 +64,9 @@ static int gb_pwm_activate_operation(struct gb_pwm_chip *pwmc,
 	return ret;
 }
 
-static int gb_pwm_deactivate_operation(struct gb_pwm_chip *pwmc,
-				       u8 which)
+static int gb_pwm_deactivate_operation(struct pwm_chip *chip, u8 which)
 {
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_pwm_deactivate_request request;
 	struct gbphy_device *gbphy_dev;
 	int ret;
@@ -76,7 +76,7 @@ static int gb_pwm_deactivate_operation(struct gb_pwm_chip *pwmc,
 
 	request.which = which;
 
-	gbphy_dev = to_gbphy_dev(pwmc->chip.dev);
+	gbphy_dev = to_gbphy_dev(chip->dev);
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -89,9 +89,10 @@ static int gb_pwm_deactivate_operation(struct gb_pwm_chip *pwmc,
 	return ret;
 }
 
-static int gb_pwm_config_operation(struct gb_pwm_chip *pwmc,
+static int gb_pwm_config_operation(struct pwm_chip *chip,
 				   u8 which, u32 duty, u32 period)
 {
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_pwm_config_request request;
 	struct gbphy_device *gbphy_dev;
 	int ret;
@@ -103,7 +104,7 @@ static int gb_pwm_config_operation(struct gb_pwm_chip *pwmc,
 	request.duty = cpu_to_le32(duty);
 	request.period = cpu_to_le32(period);
 
-	gbphy_dev = to_gbphy_dev(pwmc->chip.dev);
+	gbphy_dev = to_gbphy_dev(chip->dev);
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -116,9 +117,10 @@ static int gb_pwm_config_operation(struct gb_pwm_chip *pwmc,
 	return ret;
 }
 
-static int gb_pwm_set_polarity_operation(struct gb_pwm_chip *pwmc,
+static int gb_pwm_set_polarity_operation(struct pwm_chip *chip,
 					 u8 which, u8 polarity)
 {
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_pwm_polarity_request request;
 	struct gbphy_device *gbphy_dev;
 	int ret;
@@ -129,7 +131,7 @@ static int gb_pwm_set_polarity_operation(struct gb_pwm_chip *pwmc,
 	request.which = which;
 	request.polarity = polarity;
 
-	gbphy_dev = to_gbphy_dev(pwmc->chip.dev);
+	gbphy_dev = to_gbphy_dev(chip->dev);
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -142,9 +144,9 @@ static int gb_pwm_set_polarity_operation(struct gb_pwm_chip *pwmc,
 	return ret;
 }
 
-static int gb_pwm_enable_operation(struct gb_pwm_chip *pwmc,
-				   u8 which)
+static int gb_pwm_enable_operation(struct pwm_chip *chip, u8 which)
 {
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_pwm_enable_request request;
 	struct gbphy_device *gbphy_dev;
 	int ret;
@@ -154,7 +156,7 @@ static int gb_pwm_enable_operation(struct gb_pwm_chip *pwmc,
 
 	request.which = which;
 
-	gbphy_dev = to_gbphy_dev(pwmc->chip.dev);
+	gbphy_dev = to_gbphy_dev(chip->dev);
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -167,9 +169,9 @@ static int gb_pwm_enable_operation(struct gb_pwm_chip *pwmc,
 	return ret;
 }
 
-static int gb_pwm_disable_operation(struct gb_pwm_chip *pwmc,
-				    u8 which)
+static int gb_pwm_disable_operation(struct pwm_chip *chip, u8 which)
 {
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_pwm_disable_request request;
 	struct gbphy_device *gbphy_dev;
 	int ret;
@@ -182,7 +184,7 @@ static int gb_pwm_disable_operation(struct gb_pwm_chip *pwmc,
 	ret = gb_operation_sync(pwmc->connection, GB_PWM_TYPE_DISABLE,
 				&request, sizeof(request), NULL, 0);
 
-	gbphy_dev = to_gbphy_dev(pwmc->chip.dev);
+	gbphy_dev = to_gbphy_dev(chip->dev);
 	gbphy_runtime_put_autosuspend(gbphy_dev);
 
 	return ret;
@@ -190,19 +192,15 @@ static int gb_pwm_disable_operation(struct gb_pwm_chip *pwmc,
 
 static int gb_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 {
-	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
-
-	return gb_pwm_activate_operation(pwmc, pwm->hwpwm);
+	return gb_pwm_activate_operation(chip, pwm->hwpwm);
 };
 
 static void gb_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 {
-	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
-
 	if (pwm_is_enabled(pwm))
 		dev_warn(chip->dev, "freeing PWM device without disabling\n");
 
-	gb_pwm_deactivate_operation(pwmc, pwm->hwpwm);
+	gb_pwm_deactivate_operation(chip, pwm->hwpwm);
 }
 
 static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -212,22 +210,21 @@ static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	bool enabled = pwm->state.enabled;
 	u64 period = state->period;
 	u64 duty_cycle = state->duty_cycle;
-	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 
 	/* Set polarity */
 	if (state->polarity != pwm->state.polarity) {
 		if (enabled) {
-			gb_pwm_disable_operation(pwmc, pwm->hwpwm);
+			gb_pwm_disable_operation(chip, pwm->hwpwm);
 			enabled = false;
 		}
-		err = gb_pwm_set_polarity_operation(pwmc, pwm->hwpwm, state->polarity);
+		err = gb_pwm_set_polarity_operation(chip, pwm->hwpwm, state->polarity);
 		if (err)
 			return err;
 	}
 
 	if (!state->enabled) {
 		if (enabled)
-			gb_pwm_disable_operation(pwmc, pwm->hwpwm);
+			gb_pwm_disable_operation(chip, pwm->hwpwm);
 		return 0;
 	}
 
@@ -243,13 +240,13 @@ static int gb_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	if (duty_cycle > period)
 		duty_cycle = period;
 
-	err = gb_pwm_config_operation(pwmc, pwm->hwpwm, duty_cycle, period);
+	err = gb_pwm_config_operation(chip, pwm->hwpwm, duty_cycle, period);
 	if (err)
 		return err;
 
 	/* enable/disable */
 	if (!enabled)
-		return gb_pwm_enable_operation(pwmc, pwm->hwpwm);
+		return gb_pwm_enable_operation(chip, pwm->hwpwm);
 
 	return 0;
 }
@@ -282,7 +279,7 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 
 	pwmc->connection = connection;
 	gb_connection_set_data(connection, pwmc);
-	gb_gbphy_set_data(gbphy_dev, pwmc);
+	gb_gbphy_set_data(gbphy_dev, chip);
 
 	ret = gb_connection_enable(connection);
 	if (ret)
@@ -320,7 +317,8 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 
 static void gb_pwm_remove(struct gbphy_device *gbphy_dev)
 {
-	struct gb_pwm_chip *pwmc = gb_gbphy_get_data(gbphy_dev);
+	struct pwm_chip *chip = gb_gbphy_get_data(gbphy_dev);
+	struct gb_pwm_chip *pwmc = pwm_chip_to_gb_pwm_chip(chip);
 	struct gb_connection *connection = pwmc->connection;
 	int ret;
 
@@ -328,7 +326,7 @@ static void gb_pwm_remove(struct gbphy_device *gbphy_dev)
 	if (ret)
 		gbphy_runtime_get_noresume(gbphy_dev);
 
-	pwmchip_remove(&pwmc->chip);
+	pwmchip_remove(chip);
 	gb_connection_disable(connection);
 	gb_connection_destroy(connection);
 	kfree(pwmc);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v6 156/164] staging: greybus: pwm: Make use of pwmchip_parent() accessor
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
  2024-02-14  9:30 ` [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip Uwe Kleine-König
  2024-02-14  9:33 ` [PATCH v6 155/164] staging: greybus: pwm: Change prototype of helpers to prepare further changes Uwe Kleine-König
@ 2024-02-14  9:33 ` Uwe Kleine-König
  2024-02-14 10:40   ` Greg Kroah-Hartman
  2024-02-14  9:33 ` [PATCH v6 157/164] staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm Uwe Kleine-König
                   ` (6 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:33 UTC (permalink / raw)
  To: linux-pwm, Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: greybus-dev, linux-staging, kernel

struct pwm_chip::dev is about to change. To not have to touch this
driver in the same commit as struct pwm_chip::dev, use the accessor
function provided for exactly this purpose.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/staging/greybus/pwm.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index 97b49d436c54..0cd1dab2d888 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -51,7 +51,7 @@ static int gb_pwm_activate_operation(struct pwm_chip *chip, u8 which)
 
 	request.which = which;
 
-	gbphy_dev = to_gbphy_dev(chip->dev);
+	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -76,7 +76,7 @@ static int gb_pwm_deactivate_operation(struct pwm_chip *chip, u8 which)
 
 	request.which = which;
 
-	gbphy_dev = to_gbphy_dev(chip->dev);
+	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -104,7 +104,7 @@ static int gb_pwm_config_operation(struct pwm_chip *chip,
 	request.duty = cpu_to_le32(duty);
 	request.period = cpu_to_le32(period);
 
-	gbphy_dev = to_gbphy_dev(chip->dev);
+	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -131,7 +131,7 @@ static int gb_pwm_set_polarity_operation(struct pwm_chip *chip,
 	request.which = which;
 	request.polarity = polarity;
 
-	gbphy_dev = to_gbphy_dev(chip->dev);
+	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -156,7 +156,7 @@ static int gb_pwm_enable_operation(struct pwm_chip *chip, u8 which)
 
 	request.which = which;
 
-	gbphy_dev = to_gbphy_dev(chip->dev);
+	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
 	ret = gbphy_runtime_get_sync(gbphy_dev);
 	if (ret)
 		return ret;
@@ -184,7 +184,7 @@ static int gb_pwm_disable_operation(struct pwm_chip *chip, u8 which)
 	ret = gb_operation_sync(pwmc->connection, GB_PWM_TYPE_DISABLE,
 				&request, sizeof(request), NULL, 0);
 
-	gbphy_dev = to_gbphy_dev(chip->dev);
+	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
 	gbphy_runtime_put_autosuspend(gbphy_dev);
 
 	return ret;
@@ -198,7 +198,7 @@ static int gb_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 static void gb_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 {
 	if (pwm_is_enabled(pwm))
-		dev_warn(chip->dev, "freeing PWM device without disabling\n");
+		dev_warn(pwmchip_parent(chip), "freeing PWM device without disabling\n");
 
 	gb_pwm_deactivate_operation(chip, pwm->hwpwm);
 }
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v6 157/164] staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (2 preceding siblings ...)
  2024-02-14  9:33 ` [PATCH v6 156/164] staging: greybus: pwm: Make use of pwmchip_parent() accessor Uwe Kleine-König
@ 2024-02-14  9:33 ` Uwe Kleine-König
  2024-02-14 10:40   ` Greg Kroah-Hartman
  2024-02-14  9:33 ` [PATCH v6 158/164] staging: greybus: pwm: Drop unused gb_connection_set_data() Uwe Kleine-König
                   ` (5 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:33 UTC (permalink / raw)
  To: linux-pwm, Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: greybus-dev, linux-staging, kernel

The pwm framework already asserts to only pass a hwpwm value (= which)
less than npwm (= pwmc->pwm_max + 1). So there is no need to recheck
this condition. Drop the respective checks.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/staging/greybus/pwm.c | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index 0cd1dab2d888..3099c2a3611c 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -46,9 +46,6 @@ static int gb_pwm_activate_operation(struct pwm_chip *chip, u8 which)
 	struct gbphy_device *gbphy_dev;
 	int ret;
 
-	if (which > pwmc->pwm_max)
-		return -EINVAL;
-
 	request.which = which;
 
 	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
@@ -71,9 +68,6 @@ static int gb_pwm_deactivate_operation(struct pwm_chip *chip, u8 which)
 	struct gbphy_device *gbphy_dev;
 	int ret;
 
-	if (which > pwmc->pwm_max)
-		return -EINVAL;
-
 	request.which = which;
 
 	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
@@ -97,9 +91,6 @@ static int gb_pwm_config_operation(struct pwm_chip *chip,
 	struct gbphy_device *gbphy_dev;
 	int ret;
 
-	if (which > pwmc->pwm_max)
-		return -EINVAL;
-
 	request.which = which;
 	request.duty = cpu_to_le32(duty);
 	request.period = cpu_to_le32(period);
@@ -125,9 +116,6 @@ static int gb_pwm_set_polarity_operation(struct pwm_chip *chip,
 	struct gbphy_device *gbphy_dev;
 	int ret;
 
-	if (which > pwmc->pwm_max)
-		return -EINVAL;
-
 	request.which = which;
 	request.polarity = polarity;
 
@@ -151,9 +139,6 @@ static int gb_pwm_enable_operation(struct pwm_chip *chip, u8 which)
 	struct gbphy_device *gbphy_dev;
 	int ret;
 
-	if (which > pwmc->pwm_max)
-		return -EINVAL;
-
 	request.which = which;
 
 	gbphy_dev = to_gbphy_dev(pwmchip_parent(chip));
@@ -176,9 +161,6 @@ static int gb_pwm_disable_operation(struct pwm_chip *chip, u8 which)
 	struct gbphy_device *gbphy_dev;
 	int ret;
 
-	if (which > pwmc->pwm_max)
-		return -EINVAL;
-
 	request.which = which;
 
 	ret = gb_operation_sync(pwmc->connection, GB_PWM_TYPE_DISABLE,
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v6 158/164] staging: greybus: pwm: Drop unused gb_connection_set_data()
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (3 preceding siblings ...)
  2024-02-14  9:33 ` [PATCH v6 157/164] staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm Uwe Kleine-König
@ 2024-02-14  9:33 ` Uwe Kleine-König
  2024-02-14 10:40   ` Greg Kroah-Hartman
  2024-02-14  9:33 ` [PATCH v6 159/164] staging: greybus: pwm: Rework how the number of PWM lines is determined Uwe Kleine-König
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:33 UTC (permalink / raw)
  To: linux-pwm, Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: greybus-dev, linux-staging, kernel

The driver never calls gb_connection_get_data(). If there was another
caller (say the greybus core) it cannot use the value because the type
of pwmc (= struct gb_pwm_chip) is only defined in the pwm driver.

So drop the call to gb_connection_set_data().

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/staging/greybus/pwm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index 3099c2a3611c..c7a2e874a62b 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -260,7 +260,6 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 	}
 
 	pwmc->connection = connection;
-	gb_connection_set_data(connection, pwmc);
 	gb_gbphy_set_data(gbphy_dev, chip);
 
 	ret = gb_connection_enable(connection);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v6 159/164] staging: greybus: pwm: Rework how the number of PWM lines is determined
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (4 preceding siblings ...)
  2024-02-14  9:33 ` [PATCH v6 158/164] staging: greybus: pwm: Drop unused gb_connection_set_data() Uwe Kleine-König
@ 2024-02-14  9:33 ` Uwe Kleine-König
  2024-02-14 10:40   ` Greg Kroah-Hartman
  2024-02-14  9:33 ` [PATCH v6 160/164] staging: greybus: pwm: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
                   ` (3 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:33 UTC (permalink / raw)
  To: linux-pwm, Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: greybus-dev, linux-staging, kernel

With a later patch it becomes necessary to already now the number of PWM
lines when pwmc is allocated. So make the function not use pwmc but a
plain connection and return the number of lines instead of storing it in
pwmc. This allows to get rid of the pwm_max member.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/staging/greybus/pwm.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index c7a2e874a62b..35e98e7c00c1 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -16,8 +16,6 @@
 
 struct gb_pwm_chip {
 	struct gb_connection	*connection;
-	u8			pwm_max;	/* max pwm number */
-
 	struct pwm_chip		chip;
 };
 
@@ -26,17 +24,21 @@ static inline struct gb_pwm_chip *pwm_chip_to_gb_pwm_chip(struct pwm_chip *chip)
 	return container_of(chip, struct gb_pwm_chip, chip);
 }
 
-static int gb_pwm_count_operation(struct gb_pwm_chip *pwmc)
+static int gb_pwm_get_npwm(struct gb_connection *connection)
 {
 	struct gb_pwm_count_response response;
 	int ret;
 
-	ret = gb_operation_sync(pwmc->connection, GB_PWM_TYPE_PWM_COUNT,
+	ret = gb_operation_sync(connection, GB_PWM_TYPE_PWM_COUNT,
 				NULL, 0, &response, sizeof(response));
 	if (ret)
 		return ret;
-	pwmc->pwm_max = response.count;
-	return 0;
+
+	/*
+	 * The request returns the highest allowed PWM id parameter. So add one
+	 * to get the number of PWMs.
+	 */
+	return response.count + 1;
 }
 
 static int gb_pwm_activate_operation(struct pwm_chip *chip, u8 which)
@@ -245,7 +247,7 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 	struct gb_connection *connection;
 	struct gb_pwm_chip *pwmc;
 	struct pwm_chip *chip;
-	int ret;
+	int ret, npwm;
 
 	pwmc = kzalloc(sizeof(*pwmc), GFP_KERNEL);
 	if (!pwmc)
@@ -267,15 +269,16 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 		goto exit_connection_destroy;
 
 	/* Query number of pwms present */
-	ret = gb_pwm_count_operation(pwmc);
-	if (ret)
+	ret = gb_pwm_get_npwm(connection);
+	if (ret < 0)
 		goto exit_connection_disable;
+	npwm = ret;
 
 	chip = &pwmc->chip;
 
 	chip->dev = &gbphy_dev->dev;
 	chip->ops = &gb_pwm_ops;
-	chip->npwm = pwmc->pwm_max + 1;
+	chip->npwm = npwm;
 
 	ret = pwmchip_add(chip);
 	if (ret) {
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v6 160/164] staging: greybus: pwm: Make use of devm_pwmchip_alloc() function
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (5 preceding siblings ...)
  2024-02-14  9:33 ` [PATCH v6 159/164] staging: greybus: pwm: Rework how the number of PWM lines is determined Uwe Kleine-König
@ 2024-02-14  9:33 ` Uwe Kleine-König
  2024-02-14 10:41   ` Greg Kroah-Hartman
  2024-02-15 11:46 ` [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (2 subsequent siblings)
  9 siblings, 1 reply; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-14  9:33 UTC (permalink / raw)
  To: linux-pwm, Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: greybus-dev, linux-staging, kernel

This prepares the greybus pwm driver to further changes of the pwm core
outlined in the commit introducing pwmchip_alloc(). There is no intended
semantical change and the driver should behave as before.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/staging/greybus/pwm.c | 33 +++++++++++++++------------------
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index 35e98e7c00c1..01883fbcd79b 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -249,20 +249,11 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 	struct pwm_chip *chip;
 	int ret, npwm;
 
-	pwmc = kzalloc(sizeof(*pwmc), GFP_KERNEL);
-	if (!pwmc)
-		return -ENOMEM;
-
 	connection = gb_connection_create(gbphy_dev->bundle,
 					  le16_to_cpu(gbphy_dev->cport_desc->id),
 					  NULL);
-	if (IS_ERR(connection)) {
-		ret = PTR_ERR(connection);
-		goto exit_pwmc_free;
-	}
-
-	pwmc->connection = connection;
-	gb_gbphy_set_data(gbphy_dev, chip);
+	if (IS_ERR(connection))
+		return PTR_ERR(connection);
 
 	ret = gb_connection_enable(connection);
 	if (ret)
@@ -274,28 +265,34 @@ static int gb_pwm_probe(struct gbphy_device *gbphy_dev,
 		goto exit_connection_disable;
 	npwm = ret;
 
-	chip = &pwmc->chip;
+	chip = pwmchip_alloc(&gbphy_dev->dev, npwm, sizeof(*pwmc));
+	if (IS_ERR(chip)) {
+		ret = PTR_ERR(chip);
+		goto exit_connection_disable;
+	}
+	gb_gbphy_set_data(gbphy_dev, chip);
+
+	pwmc = pwm_chip_to_gb_pwm_chip(chip);
+	pwmc->connection = connection;
 
-	chip->dev = &gbphy_dev->dev;
 	chip->ops = &gb_pwm_ops;
-	chip->npwm = npwm;
 
 	ret = pwmchip_add(chip);
 	if (ret) {
 		dev_err(&gbphy_dev->dev,
 			"failed to register PWM: %d\n", ret);
-		goto exit_connection_disable;
+		goto exit_pwmchip_put;
 	}
 
 	gbphy_runtime_put_autosuspend(gbphy_dev);
 	return 0;
 
+exit_pwmchip_put:
+	pwmchip_put(chip);
 exit_connection_disable:
 	gb_connection_disable(connection);
 exit_connection_destroy:
 	gb_connection_destroy(connection);
-exit_pwmc_free:
-	kfree(pwmc);
 	return ret;
 }
 
@@ -311,9 +308,9 @@ static void gb_pwm_remove(struct gbphy_device *gbphy_dev)
 		gbphy_runtime_get_noresume(gbphy_dev);
 
 	pwmchip_remove(chip);
+	pwmchip_put(chip);
 	gb_connection_disable(connection);
 	gb_connection_destroy(connection);
-	kfree(pwmc);
 }
 
 static const struct gbphy_device_id gb_pwm_id_table[] = {
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip
  2024-02-14  9:30 ` [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip Uwe Kleine-König
@ 2024-02-14 10:39   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:39 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-pwm, Claudiu Beznea, Nicolas Ferre, Alexandre Belloni,
	Florian Fainelli, Ray Jui, Scott Branden, Benson Leung, Shawn Guo,
	Sascha Hauer, Paul Cercueil, Vladimir Zapolskiy, Matthias Brugger,
	AngeloGioacchino Del Regno, Neil Armstrong, Kevin Hilman,
	Krzysztof Kozlowski, Palmer Dabbelt, Paul Walmsley,
	Fabrice Gasnier, Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai,
	Jernej Skrabec, Samuel Holland, Johan Hovold, Alex Elder, kernel,
	linux-arm-kernel, Broadcom internal kernel review list,
	Guenter Roeck, chrome-platform, Fabio Estevam, NXP Linux Team,
	linux-mips, linux-mediatek, Jerome Brunet, Martin Blumenstingl,
	linux-amlogic, linux-rpi-kernel, Alim Akhtar, linux-samsung-soc,
	linux-riscv, linux-stm32, linux-sunxi, greybus-dev, linux-staging

On Wed, Feb 14, 2024 at 10:30:48AM +0100, Uwe Kleine-König wrote:
> Currently a pwm_chip stores in its struct device *dev member a pointer
> to the parent device. Preparing a change that embeds a full struct
> device in struct pwm_chip, this accessor function should be used in all
> drivers directly accessing chip->dev now. This way struct pwm_chip and
> this new function can be changed without having to touch all drivers in
> the same change set.
> 
> Make use of this function in the framework's core sources.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 159/164] staging: greybus: pwm: Rework how the number of PWM lines is determined
  2024-02-14  9:33 ` [PATCH v6 159/164] staging: greybus: pwm: Rework how the number of PWM lines is determined Uwe Kleine-König
@ 2024-02-14 10:40   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:40 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-pwm, Johan Hovold, Alex Elder, greybus-dev, linux-staging,
	kernel

On Wed, Feb 14, 2024 at 10:33:26AM +0100, Uwe Kleine-König wrote:
> With a later patch it becomes necessary to already now the number of PWM
> lines when pwmc is allocated. So make the function not use pwmc but a
> plain connection and return the number of lines instead of storing it in
> pwmc. This allows to get rid of the pwm_max member.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 155/164] staging: greybus: pwm: Change prototype of helpers to prepare further changes
  2024-02-14  9:33 ` [PATCH v6 155/164] staging: greybus: pwm: Change prototype of helpers to prepare further changes Uwe Kleine-König
@ 2024-02-14 10:40   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:40 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: Johan Hovold, Alex Elder, linux-pwm, greybus-dev, linux-staging,
	kernel

On Wed, Feb 14, 2024 at 10:33:22AM +0100, Uwe Kleine-König wrote:
> This prepares the driver for further changes that will make it harder to
> determine the pwm_chip from a given gb_pwm_chip. To just not have
> to do that, rework gb_pwm_activate_operation(),
> gb_pwm_deactivate_operation(), gb_pwm_config_operation(),
> gb_pwm_set_polarity_operation(), gb_pwm_enable_operation() and
> gb_pwm_disable_operation() to take a pwm_chip. Also use the pwm_chip as
> driver data instead of the gb_pwm_chip.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 157/164] staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm
  2024-02-14  9:33 ` [PATCH v6 157/164] staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm Uwe Kleine-König
@ 2024-02-14 10:40   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:40 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-pwm, Johan Hovold, Alex Elder, greybus-dev, linux-staging,
	kernel

On Wed, Feb 14, 2024 at 10:33:24AM +0100, Uwe Kleine-König wrote:
> The pwm framework already asserts to only pass a hwpwm value (= which)
> less than npwm (= pwmc->pwm_max + 1). So there is no need to recheck
> this condition. Drop the respective checks.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 158/164] staging: greybus: pwm: Drop unused gb_connection_set_data()
  2024-02-14  9:33 ` [PATCH v6 158/164] staging: greybus: pwm: Drop unused gb_connection_set_data() Uwe Kleine-König
@ 2024-02-14 10:40   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:40 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-pwm, Johan Hovold, Alex Elder, greybus-dev, linux-staging,
	kernel

On Wed, Feb 14, 2024 at 10:33:25AM +0100, Uwe Kleine-König wrote:
> The driver never calls gb_connection_get_data(). If there was another
> caller (say the greybus core) it cannot use the value because the type
> of pwmc (= struct gb_pwm_chip) is only defined in the pwm driver.
> 
> So drop the call to gb_connection_set_data().
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 156/164] staging: greybus: pwm: Make use of pwmchip_parent() accessor
  2024-02-14  9:33 ` [PATCH v6 156/164] staging: greybus: pwm: Make use of pwmchip_parent() accessor Uwe Kleine-König
@ 2024-02-14 10:40   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:40 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-pwm, Johan Hovold, Alex Elder, greybus-dev, linux-staging,
	kernel

On Wed, Feb 14, 2024 at 10:33:23AM +0100, Uwe Kleine-König wrote:
> struct pwm_chip::dev is about to change. To not have to touch this
> driver in the same commit as struct pwm_chip::dev, use the accessor
> function provided for exactly this purpose.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 160/164] staging: greybus: pwm: Make use of devm_pwmchip_alloc() function
  2024-02-14  9:33 ` [PATCH v6 160/164] staging: greybus: pwm: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
@ 2024-02-14 10:41   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 18+ messages in thread
From: Greg Kroah-Hartman @ 2024-02-14 10:41 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-pwm, Johan Hovold, Alex Elder, greybus-dev, linux-staging,
	kernel

On Wed, Feb 14, 2024 at 10:33:27AM +0100, Uwe Kleine-König wrote:
> This prepares the greybus pwm driver to further changes of the pwm core
> outlined in the commit introducing pwmchip_alloc(). There is no intended
> semantical change and the driver should behave as before.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (6 preceding siblings ...)
  2024-02-14  9:33 ` [PATCH v6 160/164] staging: greybus: pwm: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
@ 2024-02-15 11:46 ` Uwe Kleine-König
  2024-03-25  1:54 ` patchwork-bot+chrome-platform
  2024-03-25  2:13 ` patchwork-bot+chrome-platform
  9 siblings, 0 replies; 18+ messages in thread
From: Uwe Kleine-König @ 2024-02-15 11:46 UTC (permalink / raw)
  To: linux-pwm, Jonathan Corbet, Jonathan Cameron, James Clark,
	Andy Shevchenko, Mark Brown, Hector Martin, Sven Peter,
	Claudiu Beznea, Nicolas Ferre, Alexandre Belloni,
	Florian Fainelli, Ray Jui, Scott Branden, Alexander Shiyan,
	Benson Leung, Philipp Zabel, Shawn Guo, Sascha Hauer,
	Paul Cercueil, Vladimir Zapolskiy, Mika Westerberg,
	Andy Shevchenko, Linus Walleij, Hans de Goede, Ilpo Järvinen,
	Matthias Brugger, AngeloGioacchino Del Regno, Neil Armstrong,
	Kevin Hilman, Conor Dooley, Daire McNamara,
	Jonathan Neuschäfer, Heiko Stuebner, Krzysztof Kozlowski,
	Palmer Dabbelt, Paul Walmsley, Michael Walle, Orson Zhai,
	Baolin Wang, Chunyan Zhang, Fabrice Gasnier, Maxime Coquelin,
	Alexandre Torgue, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
	Hammer Hsieh, Thierry Reding, Jonathan Hunter, Nobuhiro Iwamatsu,
	Sean Anderson, Michal Simek, Bartosz Golaszewski, Andrzej Hajda,
	Robert Foss, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter, Pavel Machek, Lee Jones,
	Anjelique Melendez, Bjorn Andersson, Kees Cook, Rob Herring,
	Johan Hovold, Alex Elder, Greg Kroah-Hartman
  Cc: Douglas Anderson, linux-doc, dri-devel, platform-driver-x86,
	Laurent Pinchart, Alim Akhtar, Guenter Roeck, linux-riscv,
	Fabio Estevam, linux-stm32, Alyssa Rosenzweig, Jerome Brunet,
	chrome-platform, linux-samsung-soc, linux-staging, linux-rockchip,
	Broadcom internal kernel review list, NXP Linux Team, linux-leds,
	linux-sunxi, Jonas Karlman, Martin Blumenstingl, linux-gpio,
	linux-mediatek, linux-rpi-kernel, linux-tegra, linux-amlogic,
	linux-arm-kernel, greybus-dev, Gustavo A. R. Silva, linux-mips,
	asahi, kernel, linux-hardening

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

Hello,

On Wed, Feb 14, 2024 at 10:30:47AM +0100, Uwe Kleine-König wrote:
> this is v6 of the series introducing better lifetime tracking for
> pwmchips that addresses (for now theoretic) lifetime issues of pwm
> chips. Addressing these is a necessary precondition to introduce chardev
> support for PWMs.
> 
> Locking got more complicated due to non-sleeping chips, so I dropped
> the character device patch because it got still more incomplete now.
> Also I'm not yet entirely sure about patches #162 and #163 and I expect
> them to change before they can go in. My plan for the next merge window
> is to get the patches in up to #160. After that the addition of chardev
> support (including correct locking) can continue without having to touch
> the lowlevel driver. So the idea of this series is to get the driver
> adaptions out of the way as this requires some cross-tree coordination.
> 
> The patches that touch files outside of drivers/pwm include:
> 
>  - gpio: mvebu: Make use of devm_pwmchip_alloc() function
>    It already has an Ack by Linus Walleij.
> 
>  - drm/bridge: ti-sn65dsi86: Make use of pwmchip_parent() accessor
>  - drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function
>    The 2nd already has an Ack by Douglas Anderson which I tend to assume
>    good enough to merge this via my pwm tree, too. An Ack for the first
>    patch would be nice.
> 
>  - leds: qcom-lpg: Make use of devm_pwmchip_alloc() function
>    Already has an Ack by Lee Jones.
> 
>  - staging: greybus: pwm: Change prototype of helpers to prepare further changes
>  - staging: greybus: pwm: Make use of pwmchip_parent() accessor
>  - staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm
>  - staging: greybus: pwm: Drop unused gb_connection_set_data()
>  - staging: greybus: pwm: Rework how the number of PWM lines is determined
>  - staging: greybus: pwm: Make use of devm_pwmchip_alloc() function
>    The greybus patches already got an Ack by Greg Kroah-Hartman in an
>    earlier series, but I dropped it as the patches changed considerably.

After getting the needed acks, I pushed out this series in

https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next

up to patch #161.

(But don't let you stop looking at the changes, reviews are still
welcome.)

Best regards
Uwe

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

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (7 preceding siblings ...)
  2024-02-15 11:46 ` [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
@ 2024-03-25  1:54 ` patchwork-bot+chrome-platform
  2024-03-25  2:13 ` patchwork-bot+chrome-platform
  9 siblings, 0 replies; 18+ messages in thread
From: patchwork-bot+chrome-platform @ 2024-03-25  1:54 UTC (permalink / raw)
  To: =?utf-8?q?Uwe_Kleine-K=C3=B6nig_=3Cu=2Ekleine-koenig=40pengutronix=2Ede=3E?=
  Cc: linux-pwm, corbet, Jonathan.Cameron, james.clark,
	andriy.shevchenko, broonie, marcan, sven, claudiu.beznea,
	nicolas.ferre, alexandre.belloni, florian.fainelli, rjui,
	sbranden, shc_work, bleung, p.zabel, shawnguo, s.hauer, paul, vz,
	mika.westerberg, andy, linus.walleij, hdegoede, ilpo.jarvinen,
	matthias.bgg, angelogioacchino.delregno, neil.armstrong, khilman,
	conor.dooley, daire.mcnamara, j.neuschaefer, heiko,
	krzysztof.kozlowski, palmer, paul.walmsley, mwalle, orsonzhai,
	baolin.wang, zhang.lyra, fabrice.gasnier, mcoquelin.stm32,
	alexandre.torgue, wens, jernej.skrabec, samuel, hammerh0314,
	thierry.reding, jonathanh, nobuhiro1.iwamatsu, sean.anderson,
	michal.simek, brgl, andrzej.hajda, rfoss, maarten.lankhorst,
	mripard, tzimmermann, airlied, daniel, pavel, lee, quic_amelende,
	quic_bjorande, keescook, robh, johan, elder, gregkh, kernel,
	linux-doc, alyssa, asahi, linux-arm-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, groeck,
	chrome-platform, festevam, linux-imx, linux-mips, linux-gpio,
	platform-driver-x86, linux-mediatek, jbrunet, martin.blumenstingl,
	linux-amlogic, linux-riscv, linux-rockchip, alim.akhtar,
	linux-samsung-soc, linux-stm32, linux-sunxi, linux-tegra,
	dianders, Laurent.pinchart, jonas, dri-devel, linux-leds,
	greybus-dev, linux-staging, gustavoars, linux-hardening

Hello:

This series was applied to chrome-platform/linux.git (for-kernelci)
by Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:

On Wed, 14 Feb 2024 10:30:47 +0100 you wrote:
> Hello,
> 
> this is v6 of the series introducing better lifetime tracking for
> pwmchips that addresses (for now theoretic) lifetime issues of pwm
> chips. Addressing these is a necessary precondition to introduce chardev
> support for PWMs.
> 
> [...]

Here is the summary with links:
  - [v6,001/164] pwm: Provide an inline function to get the parent device of a given chip
    https://git.kernel.org/chrome-platform/c/4e59267c7a20
  - [v6,003/164] pwm: Provide pwmchip_alloc() function and a devm variant of it
    https://git.kernel.org/chrome-platform/c/024913dbf99f
  - [v6,029/164] pwm: cros-ec: Change prototype of helpers to prepare further changes
    https://git.kernel.org/chrome-platform/c/7256c2e79b8e
  - [v6,030/164] pwm: cros-ec: Make use of pwmchip_parent() accessor
    https://git.kernel.org/chrome-platform/c/19a568a8d3c4
  - [v6,031/164] pwm: cros-ec: Make use of devm_pwmchip_alloc() function
    https://git.kernel.org/chrome-platform/c/452be9421eda

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips
  2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
                   ` (8 preceding siblings ...)
  2024-03-25  1:54 ` patchwork-bot+chrome-platform
@ 2024-03-25  2:13 ` patchwork-bot+chrome-platform
  9 siblings, 0 replies; 18+ messages in thread
From: patchwork-bot+chrome-platform @ 2024-03-25  2:13 UTC (permalink / raw)
  To: =?utf-8?q?Uwe_Kleine-K=C3=B6nig_=3Cu=2Ekleine-koenig=40pengutronix=2Ede=3E?=
  Cc: linux-pwm, corbet, Jonathan.Cameron, james.clark,
	andriy.shevchenko, broonie, marcan, sven, claudiu.beznea,
	nicolas.ferre, alexandre.belloni, florian.fainelli, rjui,
	sbranden, shc_work, bleung, p.zabel, shawnguo, s.hauer, paul, vz,
	mika.westerberg, andy, linus.walleij, hdegoede, ilpo.jarvinen,
	matthias.bgg, angelogioacchino.delregno, neil.armstrong, khilman,
	conor.dooley, daire.mcnamara, j.neuschaefer, heiko,
	krzysztof.kozlowski, palmer, paul.walmsley, mwalle, orsonzhai,
	baolin.wang, zhang.lyra, fabrice.gasnier, mcoquelin.stm32,
	alexandre.torgue, wens, jernej.skrabec, samuel, hammerh0314,
	thierry.reding, jonathanh, nobuhiro1.iwamatsu, sean.anderson,
	michal.simek, brgl, andrzej.hajda, rfoss, maarten.lankhorst,
	mripard, tzimmermann, airlied, daniel, pavel, lee, quic_amelende,
	quic_bjorande, keescook, robh, johan, elder, gregkh, kernel,
	linux-doc, alyssa, asahi, linux-arm-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, groeck,
	chrome-platform, festevam, linux-imx, linux-mips, linux-gpio,
	platform-driver-x86, linux-mediatek, jbrunet, martin.blumenstingl,
	linux-amlogic, linux-riscv, linux-rockchip, alim.akhtar,
	linux-samsung-soc, linux-stm32, linux-sunxi, linux-tegra,
	dianders, Laurent.pinchart, jonas, dri-devel, linux-leds,
	greybus-dev, linux-staging, gustavoars, linux-hardening

Hello:

This series was applied to chrome-platform/linux.git (for-next)
by Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:

On Wed, 14 Feb 2024 10:30:47 +0100 you wrote:
> Hello,
> 
> this is v6 of the series introducing better lifetime tracking for
> pwmchips that addresses (for now theoretic) lifetime issues of pwm
> chips. Addressing these is a necessary precondition to introduce chardev
> support for PWMs.
> 
> [...]

Here is the summary with links:
  - [v6,001/164] pwm: Provide an inline function to get the parent device of a given chip
    https://git.kernel.org/chrome-platform/c/4e59267c7a20
  - [v6,003/164] pwm: Provide pwmchip_alloc() function and a devm variant of it
    https://git.kernel.org/chrome-platform/c/024913dbf99f
  - [v6,029/164] pwm: cros-ec: Change prototype of helpers to prepare further changes
    https://git.kernel.org/chrome-platform/c/7256c2e79b8e
  - [v6,030/164] pwm: cros-ec: Make use of pwmchip_parent() accessor
    https://git.kernel.org/chrome-platform/c/19a568a8d3c4
  - [v6,031/164] pwm: cros-ec: Make use of devm_pwmchip_alloc() function
    https://git.kernel.org/chrome-platform/c/452be9421eda

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2024-03-25  2:13 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-14  9:30 [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
2024-02-14  9:30 ` [PATCH v6 001/164] pwm: Provide an inline function to get the parent device of a given chip Uwe Kleine-König
2024-02-14 10:39   ` Greg Kroah-Hartman
2024-02-14  9:33 ` [PATCH v6 155/164] staging: greybus: pwm: Change prototype of helpers to prepare further changes Uwe Kleine-König
2024-02-14 10:40   ` Greg Kroah-Hartman
2024-02-14  9:33 ` [PATCH v6 156/164] staging: greybus: pwm: Make use of pwmchip_parent() accessor Uwe Kleine-König
2024-02-14 10:40   ` Greg Kroah-Hartman
2024-02-14  9:33 ` [PATCH v6 157/164] staging: greybus: pwm: Rely on pwm framework to pass a valid hwpwm Uwe Kleine-König
2024-02-14 10:40   ` Greg Kroah-Hartman
2024-02-14  9:33 ` [PATCH v6 158/164] staging: greybus: pwm: Drop unused gb_connection_set_data() Uwe Kleine-König
2024-02-14 10:40   ` Greg Kroah-Hartman
2024-02-14  9:33 ` [PATCH v6 159/164] staging: greybus: pwm: Rework how the number of PWM lines is determined Uwe Kleine-König
2024-02-14 10:40   ` Greg Kroah-Hartman
2024-02-14  9:33 ` [PATCH v6 160/164] staging: greybus: pwm: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
2024-02-14 10:41   ` Greg Kroah-Hartman
2024-02-15 11:46 ` [PATCH v6 000/164] pwm: Improve lifetime tracking for pwm_chips Uwe Kleine-König
2024-03-25  1:54 ` patchwork-bot+chrome-platform
2024-03-25  2:13 ` patchwork-bot+chrome-platform

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox