[PATCH v2 00/11] pwm: Allow .get_state to fail

* [PATCH v2 00/11] pwm: Allow .get_state to fail
@ 2022-11-30 15:21 ` Uwe Kleine-König
  0 siblings, 0 replies; 153+ messages in thread
From: Uwe Kleine-König @ 2022-11-30 15:21 UTC (permalink / raw)
  To: Thierry Reding
  Cc: Conor Dooley, Linus Walleij, Bartosz Golaszewski,
	Douglas Anderson, Pavel Machek, Claudiu Beznea, Nicolas Ferre,
	Alexandre Belloni, Ray Jui, Scott Branden,
	Broadcom internal kernel review list, Benson Leung,
	Guenter Roeck, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
	Fabio Estevam, NXP Linux Team, Kevin Hilman, Jerome Brunet,
	Martin Blumenstingl, Matthias Brugger, Florian Fainelli,
	Heiko Stuebner, Palmer Dabbelt, Paul Walmsley, Michael Walle,
	Orson Zhai, Baolin Wang, Chunyan Zhang, Fabrice Gasnier,
	Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai, Samuel Holland,
	Hammer Hsieh, Nobuhiro Iwamatsu, Sean Anderson, Michal Simek,
	Bjorn Andersson, Stephen Boyd, Matthias Kaehlcke, Satya Priya,
	linux-pwm, linux-gpio, dri-devel, linux-leds, linux-arm-kernel,
	chrome-platform, linux-amlogic, linux-mediatek, linux-rpi-kernel,
	linux-rockchip, linux-riscv, linux-stm32, linux-sunxi,
	Steven Rostedt, Masami Hiramatsu, Marijn Suijten

Hello,

I forgot about this series and was remembered when I talked to Conor
Dooley about how .get_state() should behave in an error case.

Compared to (implicit) v1, sent with Message-Id: 20220916151506.298488-1-u.kleine-koenig@pengutronix.de
I changed:

 - Patch #1 which does the prototype change now just adds "return 0" to
   all implementations and so gets simpler and doesn't change behaviour.
   The adaptions to the different .get_state() implementations are split
   out into individual patches to ease review.
 - One minor inconsistency fixed in "pwm: Handle .get_state() failures"
   that I noticed while looking into this patch.
 - I skipped changing sun4i.c as I don't know how to handle the error
   there. Someone might want to have a look. (That's not ideal, but it's
   not worse than the same issue before this series.)

In v1 Thierry had the concern:

| That raises the question about what to do in these cases. If we return
| an error, that could potentially throw off consumers. So perhaps the
| closest would be to return a disabled PWM? Or perhaps it'd be up to the
| consumer to provide some fallback configuration for invalidly configured
| or unconfigured PWMs.

.get_state() is only called in pwm_device_request on a pwm_state that a
consumer might see. Before my series a consumer might have seen a
partial modified pwm_state (because .get_state() might have modified
.period, then stumbled and returned silently). The last patch ensures
that this partial modification isn't given out to the consumer. Instead
they now see the same as if .get_state wasn't implemented at all.

Best regards
Uwe

Uwe Kleine-König (11):
  pwm: Make .get_state() callback return an error code
  pwm/tracing: Also record trace events for failed API calls
  drm/bridge: ti-sn65dsi86: Propagate errors in .get_state() to the
    caller
  leds: qcom-lpg: Propagate errors in .get_state() to the caller
  pwm: crc: Propagate errors in .get_state() to the caller
  pwm: cros-ec: Propagate errors in .get_state() to the caller
  pwm: imx27: Propagate errors in .get_state() to the caller
  pwm: mtk-disp: Propagate errors in .get_state() to the caller
  pwm: rockchip: Propagate errors in .get_state() to the caller
  pwm: sprd: Propagate errors in .get_state() to the caller
  pwm: Handle .get_state() failures

 drivers/gpio/gpio-mvebu.c             |  9 ++++++---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 14 ++++++++------
 drivers/leds/rgb/leds-qcom-lpg.c      | 14 ++++++++------
 drivers/pwm/core.c                    | 28 +++++++++++++++++----------
 drivers/pwm/pwm-atmel.c               |  6 ++++--
 drivers/pwm/pwm-bcm-iproc.c           |  8 +++++---
 drivers/pwm/pwm-crc.c                 | 10 ++++++----
 drivers/pwm/pwm-cros-ec.c             |  8 +++++---
 drivers/pwm/pwm-dwc.c                 |  6 ++++--
 drivers/pwm/pwm-hibvt.c               |  6 ++++--
 drivers/pwm/pwm-imx-tpm.c             |  8 +++++---
 drivers/pwm/pwm-imx27.c               |  8 +++++---
 drivers/pwm/pwm-intel-lgm.c           |  6 ++++--
 drivers/pwm/pwm-iqs620a.c             |  6 ++++--
 drivers/pwm/pwm-keembay.c             |  6 ++++--
 drivers/pwm/pwm-lpss.c                |  6 ++++--
 drivers/pwm/pwm-meson.c               |  8 +++++---
 drivers/pwm/pwm-mtk-disp.c            | 12 +++++++-----
 drivers/pwm/pwm-pca9685.c             |  8 +++++---
 drivers/pwm/pwm-raspberrypi-poe.c     |  8 +++++---
 drivers/pwm/pwm-rockchip.c            | 12 +++++++-----
 drivers/pwm/pwm-sifive.c              |  6 ++++--
 drivers/pwm/pwm-sl28cpld.c            |  8 +++++---
 drivers/pwm/pwm-sprd.c                |  8 +++++---
 drivers/pwm/pwm-stm32-lp.c            |  8 +++++---
 drivers/pwm/pwm-sun4i.c               | 12 +++++++-----
 drivers/pwm/pwm-sunplus.c             |  6 ++++--
 drivers/pwm/pwm-visconti.c            |  6 ++++--
 drivers/pwm/pwm-xilinx.c              |  8 +++++---
 include/linux/pwm.h                   |  4 ++--
 include/trace/events/pwm.h            | 20 +++++++++----------
 31 files changed, 174 insertions(+), 109 deletions(-)

base-commit: 50315945d178eebec4e8e2c50c265767ddb926eb
-- 
2.38.1

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