* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: James, Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Edmund Dea, Qiang Yu, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Kevin Hilman, Rob Clark,
Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda,
Konrad Dybcio, Johan Hovold, Joel, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Tomeu Vizoso,
Kieran Bingham, Sandy Huang, Heiko Stübner, Orson Zhai,
Baolin Wang, Chunyan Zhang, Deepak R Varma, Alex Deucher,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Laurent Pinchart,
Alim Akhtar, Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Alyssa Rosenzweig,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
Hello,
this patch series adapts the platform drivers below drivers/gpu/drm
to use the .remove_new() callback. Compared to the traditional .remove()
callback .remove_new() returns no value. This is a good thing because
the driver core doesn't (and cannot) cope for errors during remove. The
only effect of a non-zero return value in .remove() is that the driver
core emits a warning. The device is removed anyhow and an early return
from .remove() usually yields a resource leak.
By changing the remove callback to return void driver authors cannot
reasonably (but wrongly) assume any more that there happens some kind of
cleanup later.
Best regards
Uwe
Uwe Kleine-König (53):
drm/komeda: Convert to platform remove callback returning void
drm/arm/hdlcd: Convert to platform remove callback returning void
drm/arm/malidp: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
drm/aspeed: Convert to platform remove callback returning void
drm/atmel-hlcdc: Convert to platform remove callback returning void
drm/bridge: cdns-dsi: Convert to platform remove callback returning
void
drm/bridge: display-connector: Convert to platform remove callback
returning void
drm/bridge: fsl-ldb: Convert to platform remove callback returning
void
drm/imx/imx8*: Convert to platform remove callback returning void
drm/bridge: lvds-codec: Convert to platform remove callback returning
void
drm/bridge: nwl-dsi: Convert to platform remove callback returning
void
drm/bridge: simple-bridge: Convert to platform remove callback
returning void
drm/bridge: synopsys: Convert to platform remove callback returning
void
drm/bridge: thc63lvd1024: Convert to platform remove callback
returning void
drm/bridge: tfp410: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/exynos: Convert to platform remove callback returning void
drm/fsl-dcu: Convert to platform remove callback returning void
drm/hisilicon: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/lima: Convert to platform remove callback returning void
drm/logicvc: Convert to platform remove callback returning void
drm/mcde: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/meson: Convert to platform remove callback returning void
drm/msm: Convert to platform remove callback returning void
drm/mxsfb: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/panel: Convert to platform remove callback returning void
drm/panfrost: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/rockchip: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/sti: Convert to platform remove callback returning void
drm/stm: Convert to platform remove callback returning void
drm/sun4i: Convert to platform remove callback returning void
drm/tegra: Convert to platform remove callback returning void
drm/tests: helpers: Convert to platform remove callback returning void
drm/tidss: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tve200: Convert to platform remove callback returning void
drm/v3d: Convert to platform remove callback returning void
drm/vc4: Convert to platform remove callback returning void
drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
void
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
drivers/gpu/drm/armada/armada_drv.c | 5 ++---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
drivers/gpu/drm/bridge/display-connector.c | 6 ++----
drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
drivers/gpu/drm/lima/lima_drv.c | 5 ++---
drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
drivers/gpu/drm/msm/msm_drv.c | 6 ++----
drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
drivers/gpu/drm/panel/panel-simple.c | 6 ++----
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
drivers/gpu/drm/sti/sti_drv.c | 6 ++----
drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
drivers/gpu/drm/sti/sti_hda.c | 5 ++---
drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
drivers/gpu/drm/stm/drv.c | 6 ++----
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
drivers/gpu/drm/tegra/dpaux.c | 6 ++----
drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
159 files changed, 319 insertions(+), 597 deletions(-)
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
2.39.2
^ permalink raw reply [flat|nested] 261+ messages in thread* [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: James, Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Edmund Dea, Qiang Yu, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Kevin Hilman, Rob Clark,
Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda,
Konrad Dybcio, Johan Hovold, Joel, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Tomeu Vizoso,
Kieran Bingham, Sandy Huang, Heiko Stübner, Orson Zhai,
Baolin Wang, Chunyan Zhang, Deepak R Varma, Alex Deucher,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Laurent Pinchart,
Alim Akhtar, Fabio Estevam, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, lima, Steven Price, linux-rockchip,
Xinwei Kong, Mali DP Maintainers, NXP Linux Team, Russell King,
linux-sunxi, Alyssa Rosenzweig, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
Hello,
this patch series adapts the platform drivers below drivers/gpu/drm
to use the .remove_new() callback. Compared to the traditional .remove()
callback .remove_new() returns no value. This is a good thing because
the driver core doesn't (and cannot) cope for errors during remove. The
only effect of a non-zero return value in .remove() is that the driver
core emits a warning. The device is removed anyhow and an early return
from .remove() usually yields a resource leak.
By changing the remove callback to return void driver authors cannot
reasonably (but wrongly) assume any more that there happens some kind of
cleanup later.
Best regards
Uwe
Uwe Kleine-König (53):
drm/komeda: Convert to platform remove callback returning void
drm/arm/hdlcd: Convert to platform remove callback returning void
drm/arm/malidp: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
drm/aspeed: Convert to platform remove callback returning void
drm/atmel-hlcdc: Convert to platform remove callback returning void
drm/bridge: cdns-dsi: Convert to platform remove callback returning
void
drm/bridge: display-connector: Convert to platform remove callback
returning void
drm/bridge: fsl-ldb: Convert to platform remove callback returning
void
drm/imx/imx8*: Convert to platform remove callback returning void
drm/bridge: lvds-codec: Convert to platform remove callback returning
void
drm/bridge: nwl-dsi: Convert to platform remove callback returning
void
drm/bridge: simple-bridge: Convert to platform remove callback
returning void
drm/bridge: synopsys: Convert to platform remove callback returning
void
drm/bridge: thc63lvd1024: Convert to platform remove callback
returning void
drm/bridge: tfp410: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/exynos: Convert to platform remove callback returning void
drm/fsl-dcu: Convert to platform remove callback returning void
drm/hisilicon: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/lima: Convert to platform remove callback returning void
drm/logicvc: Convert to platform remove callback returning void
drm/mcde: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/meson: Convert to platform remove callback returning void
drm/msm: Convert to platform remove callback returning void
drm/mxsfb: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/panel: Convert to platform remove callback returning void
drm/panfrost: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/rockchip: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/sti: Convert to platform remove callback returning void
drm/stm: Convert to platform remove callback returning void
drm/sun4i: Convert to platform remove callback returning void
drm/tegra: Convert to platform remove callback returning void
drm/tests: helpers: Convert to platform remove callback returning void
drm/tidss: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tve200: Convert to platform remove callback returning void
drm/v3d: Convert to platform remove callback returning void
drm/vc4: Convert to platform remove callback returning void
drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
void
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
drivers/gpu/drm/armada/armada_drv.c | 5 ++---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
drivers/gpu/drm/bridge/display-connector.c | 6 ++----
drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
drivers/gpu/drm/lima/lima_drv.c | 5 ++---
drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
drivers/gpu/drm/msm/msm_drv.c | 6 ++----
drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
drivers/gpu/drm/panel/panel-simple.c | 6 ++----
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
drivers/gpu/drm/sti/sti_drv.c | 6 ++----
drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
drivers/gpu/drm/sti/sti_hda.c | 5 ++---
drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
drivers/gpu/drm/stm/drv.c | 6 ++----
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
drivers/gpu/drm/tegra/dpaux.c | 6 ++----
drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
159 files changed, 319 insertions(+), 597 deletions(-)
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
2.39.2
^ permalink raw reply [flat|nested] 261+ messages in thread* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: James, Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Edmund Dea, Qiang Yu, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Kevin Hilman, Rob Clark,
Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda,
Konrad Dybcio, Johan Hovold, Joel, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Tomeu Vizoso,
Kieran Bingham, Sandy Huang, Heiko Stübner, Orson Zhai,
Baolin Wang, Chunyan Zhang, Deepak R Varma, Alex Deucher,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Laurent Pinchart, Jonas Karlman,
Fabio Estevam, NXP Linux Team, Russell King, Christian Gmeiner,
etnaviv, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Hello,
this patch series adapts the platform drivers below drivers/gpu/drm
to use the .remove_new() callback. Compared to the traditional .remove()
callback .remove_new() returns no value. This is a good thing because
the driver core doesn't (and cannot) cope for errors during remove. The
only effect of a non-zero return value in .remove() is that the driver
core emits a warning. The device is removed anyhow and an early return
from .remove() usually yields a resource leak.
By changing the remove callback to return void driver authors cannot
reasonably (but wrongly) assume any more that there happens some kind of
cleanup later.
Best regards
Uwe
Uwe Kleine-König (53):
drm/komeda: Convert to platform remove callback returning void
drm/arm/hdlcd: Convert to platform remove callback returning void
drm/arm/malidp: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
drm/aspeed: Convert to platform remove callback returning void
drm/atmel-hlcdc: Convert to platform remove callback returning void
drm/bridge: cdns-dsi: Convert to platform remove callback returning
void
drm/bridge: display-connector: Convert to platform remove callback
returning void
drm/bridge: fsl-ldb: Convert to platform remove callback returning
void
drm/imx/imx8*: Convert to platform remove callback returning void
drm/bridge: lvds-codec: Convert to platform remove callback returning
void
drm/bridge: nwl-dsi: Convert to platform remove callback returning
void
drm/bridge: simple-bridge: Convert to platform remove callback
returning void
drm/bridge: synopsys: Convert to platform remove callback returning
void
drm/bridge: thc63lvd1024: Convert to platform remove callback
returning void
drm/bridge: tfp410: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/exynos: Convert to platform remove callback returning void
drm/fsl-dcu: Convert to platform remove callback returning void
drm/hisilicon: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/lima: Convert to platform remove callback returning void
drm/logicvc: Convert to platform remove callback returning void
drm/mcde: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/meson: Convert to platform remove callback returning void
drm/msm: Convert to platform remove callback returning void
drm/mxsfb: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/panel: Convert to platform remove callback returning void
drm/panfrost: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/rockchip: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/sti: Convert to platform remove callback returning void
drm/stm: Convert to platform remove callback returning void
drm/sun4i: Convert to platform remove callback returning void
drm/tegra: Convert to platform remove callback returning void
drm/tests: helpers: Convert to platform remove callback returning void
drm/tidss: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tve200: Convert to platform remove callback returning void
drm/v3d: Convert to platform remove callback returning void
drm/vc4: Convert to platform remove callback returning void
drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
void
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
drivers/gpu/drm/armada/armada_drv.c | 5 ++---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
drivers/gpu/drm/bridge/display-connector.c | 6 ++----
drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
drivers/gpu/drm/lima/lima_drv.c | 5 ++---
drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
drivers/gpu/drm/msm/msm_drv.c | 6 ++----
drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
drivers/gpu/drm/panel/panel-simple.c | 6 ++----
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
drivers/gpu/drm/sti/sti_drv.c | 6 ++----
drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
drivers/gpu/drm/sti/sti_hda.c | 5 ++---
drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
drivers/gpu/drm/stm/drv.c | 6 ++----
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
drivers/gpu/drm/tegra/dpaux.c | 6 ++----
drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
159 files changed, 319 insertions(+), 597 deletions(-)
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
2.39.2
^ permalink raw reply [flat|nested] 261+ messages in thread* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: linux-aspeed
Hello,
this patch series adapts the platform drivers below drivers/gpu/drm
to use the .remove_new() callback. Compared to the traditional .remove()
callback .remove_new() returns no value. This is a good thing because
the driver core doesn't (and cannot) cope for errors during remove. The
only effect of a non-zero return value in .remove() is that the driver
core emits a warning. The device is removed anyhow and an early return
from .remove() usually yields a resource leak.
By changing the remove callback to return void driver authors cannot
reasonably (but wrongly) assume any more that there happens some kind of
cleanup later.
Best regards
Uwe
Uwe Kleine-K?nig (53):
drm/komeda: Convert to platform remove callback returning void
drm/arm/hdlcd: Convert to platform remove callback returning void
drm/arm/malidp: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
drm/aspeed: Convert to platform remove callback returning void
drm/atmel-hlcdc: Convert to platform remove callback returning void
drm/bridge: cdns-dsi: Convert to platform remove callback returning
void
drm/bridge: display-connector: Convert to platform remove callback
returning void
drm/bridge: fsl-ldb: Convert to platform remove callback returning
void
drm/imx/imx8*: Convert to platform remove callback returning void
drm/bridge: lvds-codec: Convert to platform remove callback returning
void
drm/bridge: nwl-dsi: Convert to platform remove callback returning
void
drm/bridge: simple-bridge: Convert to platform remove callback
returning void
drm/bridge: synopsys: Convert to platform remove callback returning
void
drm/bridge: thc63lvd1024: Convert to platform remove callback
returning void
drm/bridge: tfp410: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/exynos: Convert to platform remove callback returning void
drm/fsl-dcu: Convert to platform remove callback returning void
drm/hisilicon: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/lima: Convert to platform remove callback returning void
drm/logicvc: Convert to platform remove callback returning void
drm/mcde: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/meson: Convert to platform remove callback returning void
drm/msm: Convert to platform remove callback returning void
drm/mxsfb: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/panel: Convert to platform remove callback returning void
drm/panfrost: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/rockchip: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/sti: Convert to platform remove callback returning void
drm/stm: Convert to platform remove callback returning void
drm/sun4i: Convert to platform remove callback returning void
drm/tegra: Convert to platform remove callback returning void
drm/tests: helpers: Convert to platform remove callback returning void
drm/tidss: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tiny: Convert to platform remove callback returning void
drm/tve200: Convert to platform remove callback returning void
drm/v3d: Convert to platform remove callback returning void
drm/vc4: Convert to platform remove callback returning void
drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
void
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
drivers/gpu/drm/armada/armada_drv.c | 5 ++---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
drivers/gpu/drm/bridge/display-connector.c | 6 ++----
drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
drivers/gpu/drm/lima/lima_drv.c | 5 ++---
drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
drivers/gpu/drm/msm/msm_drv.c | 6 ++----
drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
drivers/gpu/drm/panel/panel-simple.c | 6 ++----
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
drivers/gpu/drm/sti/sti_drv.c | 6 ++----
drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
drivers/gpu/drm/sti/sti_hda.c | 5 ++---
drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
drivers/gpu/drm/stm/drv.c | 6 ++----
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
drivers/gpu/drm/tegra/dpaux.c | 6 ++----
drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
159 files changed, 319 insertions(+), 597 deletions(-)
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
2.39.2
^ permalink raw reply [flat|nested] 261+ messages in thread* [PATCH 01/53] drm/komeda: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (3 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-10 21:50 ` Liviu Dudau
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: James, Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter
Cc: Mali DP Maintainers, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 28f76e07dd95..c597c362f689 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -131,10 +131,9 @@ static int komeda_platform_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &komeda_master_ops, match);
}
-static int komeda_platform_remove(struct platform_device *pdev)
+static void komeda_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &komeda_master_ops);
- return 0;
}
static const struct of_device_id komeda_of_match[] = {
@@ -189,7 +188,7 @@ static const struct dev_pm_ops komeda_pm_ops = {
static struct platform_driver komeda_platform_driver = {
.probe = komeda_platform_probe,
- .remove = komeda_platform_remove,
+ .remove_new = komeda_platform_remove,
.driver = {
.name = "komeda",
.of_match_table = komeda_of_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 01/53] drm/komeda: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 01/53] drm/komeda: " Uwe Kleine-König
@ 2023-05-10 21:50 ` Liviu Dudau
0 siblings, 0 replies; 261+ messages in thread
From: Liviu Dudau @ 2023-05-10 21:50 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: kernel, James, dri-devel, Mali DP Maintainers, Mihail Atanassov
On Sun, May 07, 2023 at 06:25:24PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Thanks for the clean up!
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 28f76e07dd95..c597c362f689 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -131,10 +131,9 @@ static int komeda_platform_probe(struct platform_device *pdev)
> return component_master_add_with_match(dev, &komeda_master_ops, match);
> }
>
> -static int komeda_platform_remove(struct platform_device *pdev)
> +static void komeda_platform_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &komeda_master_ops);
> - return 0;
> }
>
> static const struct of_device_id komeda_of_match[] = {
> @@ -189,7 +188,7 @@ static const struct dev_pm_ops komeda_pm_ops = {
>
> static struct platform_driver komeda_platform_driver = {
> .probe = komeda_platform_probe,
> - .remove = komeda_platform_remove,
> + .remove_new = komeda_platform_remove,
> .driver = {
> .name = "komeda",
> .of_match_table = komeda_of_match,
> --
> 2.39.2
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 02/53] drm/arm/hdlcd: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (4 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-10 21:51 ` Liviu Dudau
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Liviu Dudau, Brian Starkey, David Airlie, Daniel Vetter
Cc: Mali DP Maintainers, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e3507dd6f82a..5e265c81a1b3 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -369,10 +369,9 @@ static int hdlcd_probe(struct platform_device *pdev)
match);
}
-static int hdlcd_remove(struct platform_device *pdev)
+static void hdlcd_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &hdlcd_master_ops);
- return 0;
}
static const struct of_device_id hdlcd_of_match[] = {
@@ -401,7 +400,7 @@ static SIMPLE_DEV_PM_OPS(hdlcd_pm_ops, hdlcd_pm_suspend, hdlcd_pm_resume);
static struct platform_driver hdlcd_platform_driver = {
.probe = hdlcd_probe,
- .remove = hdlcd_remove,
+ .remove_new = hdlcd_remove,
.driver = {
.name = "hdlcd",
.pm = &hdlcd_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 02/53] drm/arm/hdlcd: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 02/53] drm/arm/hdlcd: " Uwe Kleine-König
@ 2023-05-10 21:51 ` Liviu Dudau
0 siblings, 0 replies; 261+ messages in thread
From: Liviu Dudau @ 2023-05-10 21:51 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: dri-devel, Mali DP Maintainers, kernel
On Sun, May 07, 2023 at 06:25:25PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e3507dd6f82a..5e265c81a1b3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -369,10 +369,9 @@ static int hdlcd_probe(struct platform_device *pdev)
> match);
> }
>
> -static int hdlcd_remove(struct platform_device *pdev)
> +static void hdlcd_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &hdlcd_master_ops);
> - return 0;
> }
>
> static const struct of_device_id hdlcd_of_match[] = {
> @@ -401,7 +400,7 @@ static SIMPLE_DEV_PM_OPS(hdlcd_pm_ops, hdlcd_pm_suspend, hdlcd_pm_resume);
>
> static struct platform_driver hdlcd_platform_driver = {
> .probe = hdlcd_probe,
> - .remove = hdlcd_remove,
> + .remove_new = hdlcd_remove,
> .driver = {
> .name = "hdlcd",
> .pm = &hdlcd_pm_ops,
> --
> 2.39.2
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 03/53] drm/arm/malidp: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (5 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-10 21:52 ` Liviu Dudau
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Liviu Dudau, Brian Starkey, David Airlie, Daniel Vetter
Cc: Mali DP Maintainers, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 589c1c66a6dc..389ef1c3d9b6 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -936,10 +936,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
match);
}
-static int malidp_platform_remove(struct platform_device *pdev)
+static void malidp_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &malidp_master_ops);
- return 0;
}
static int __maybe_unused malidp_pm_suspend(struct device *dev)
@@ -982,7 +981,7 @@ static const struct dev_pm_ops malidp_pm_ops = {
static struct platform_driver malidp_platform_driver = {
.probe = malidp_platform_probe,
- .remove = malidp_platform_remove,
+ .remove_new = malidp_platform_remove,
.driver = {
.name = "mali-dp",
.pm = &malidp_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 03/53] drm/arm/malidp: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 03/53] drm/arm/malidp: " Uwe Kleine-König
@ 2023-05-10 21:52 ` Liviu Dudau
0 siblings, 0 replies; 261+ messages in thread
From: Liviu Dudau @ 2023-05-10 21:52 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: dri-devel, Mali DP Maintainers, kernel
On Sun, May 07, 2023 at 06:25:26PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> index 589c1c66a6dc..389ef1c3d9b6 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -936,10 +936,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
> match);
> }
>
> -static int malidp_platform_remove(struct platform_device *pdev)
> +static void malidp_platform_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &malidp_master_ops);
> - return 0;
> }
>
> static int __maybe_unused malidp_pm_suspend(struct device *dev)
> @@ -982,7 +981,7 @@ static const struct dev_pm_ops malidp_pm_ops = {
>
> static struct platform_driver malidp_platform_driver = {
> .probe = malidp_platform_probe,
> - .remove = malidp_platform_remove,
> + .remove_new = malidp_platform_remove,
> .driver = {
> .name = "mali-dp",
> .pm = &malidp_pm_ops,
> --
> 2.39.2
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 04/53] drm/armada: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (6 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Russell King, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the armada drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
drivers/gpu/drm/armada/armada_drv.c | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c b/drivers/gpu/drm/armada/armada_crtc.c
index 15dd667aa2e7..52d2c942d3d2 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1066,10 +1066,9 @@ static int armada_lcd_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &armada_lcd_ops);
}
-static int armada_lcd_remove(struct platform_device *pdev)
+static void armada_lcd_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &armada_lcd_ops);
- return 0;
}
static const struct of_device_id armada_lcd_of_match[] = {
@@ -1095,7 +1094,7 @@ MODULE_DEVICE_TABLE(platform, armada_lcd_platform_ids);
struct platform_driver armada_lcd_platform_driver = {
.probe = armada_lcd_probe,
- .remove = armada_lcd_remove,
+ .remove_new = armada_lcd_remove,
.driver = {
.name = "armada-lcd",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
index 142668cd6d7c..b8ff21f545cd 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -232,10 +232,9 @@ static int armada_drm_probe(struct platform_device *pdev)
match);
}
-static int armada_drm_remove(struct platform_device *pdev)
+static void armada_drm_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &armada_master_ops);
- return 0;
}
static const struct platform_device_id armada_drm_platform_ids[] = {
@@ -250,7 +249,7 @@ MODULE_DEVICE_TABLE(platform, armada_drm_platform_ids);
static struct platform_driver armada_drm_platform_driver = {
.probe = armada_drm_probe,
- .remove = armada_drm_remove,
+ .remove_new = armada_drm_remove,
.driver = {
.name = "armada-drm",
},
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 05/53] drm/aspeed: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: linux-aspeed
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index ecfb060d2557..d0089e7fbfae 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -351,20 +351,18 @@ static int aspeed_gfx_probe(struct platform_device *pdev)
return ret;
}
-static int aspeed_gfx_remove(struct platform_device *pdev)
+static void aspeed_gfx_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
sysfs_remove_group(&pdev->dev.kobj, &aspeed_sysfs_attr_group);
drm_dev_unregister(drm);
aspeed_gfx_unload(drm);
-
- return 0;
}
static struct platform_driver aspeed_gfx_platform_driver = {
.probe = aspeed_gfx_probe,
- .remove = aspeed_gfx_remove,
+ .remove_new = aspeed_gfx_remove,
.driver = {
.name = "aspeed_gfx",
.of_match_table = aspeed_gfx_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 05/53] drm/aspeed: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Joel Stanley, David Airlie, Daniel Vetter
Cc: Andrew Jeffery, kernel, dri-devel, linux-aspeed, linux-arm-kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index ecfb060d2557..d0089e7fbfae 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -351,20 +351,18 @@ static int aspeed_gfx_probe(struct platform_device *pdev)
return ret;
}
-static int aspeed_gfx_remove(struct platform_device *pdev)
+static void aspeed_gfx_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
sysfs_remove_group(&pdev->dev.kobj, &aspeed_sysfs_attr_group);
drm_dev_unregister(drm);
aspeed_gfx_unload(drm);
-
- return 0;
}
static struct platform_driver aspeed_gfx_platform_driver = {
.probe = aspeed_gfx_probe,
- .remove = aspeed_gfx_remove,
+ .remove_new = aspeed_gfx_remove,
.driver = {
.name = "aspeed_gfx",
.of_match_table = aspeed_gfx_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 05/53] drm/aspeed: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Joel Stanley, David Airlie, Daniel Vetter
Cc: Andrew Jeffery, linux-aspeed, dri-devel, linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index ecfb060d2557..d0089e7fbfae 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -351,20 +351,18 @@ static int aspeed_gfx_probe(struct platform_device *pdev)
return ret;
}
-static int aspeed_gfx_remove(struct platform_device *pdev)
+static void aspeed_gfx_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
sysfs_remove_group(&pdev->dev.kobj, &aspeed_sysfs_attr_group);
drm_dev_unregister(drm);
aspeed_gfx_unload(drm);
-
- return 0;
}
static struct platform_driver aspeed_gfx_platform_driver = {
.probe = aspeed_gfx_probe,
- .remove = aspeed_gfx_remove,
+ .remove_new = aspeed_gfx_remove,
.driver = {
.name = "aspeed_gfx",
.of_match_table = aspeed_gfx_match,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread
* [PATCH 06/53] drm/atmel-hlcdc: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Sam Ravnborg, Boris Brezillon, David Airlie, Daniel Vetter,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
Cc: dri-devel, linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 4e806b06d35d..e3960cd11a6b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -773,15 +773,13 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
return ret;
}
-static int atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
+static void atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
{
struct drm_device *ddev = platform_get_drvdata(pdev);
drm_dev_unregister(ddev);
atmel_hlcdc_dc_unload(ddev);
drm_dev_put(ddev);
-
- return 0;
}
static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
@@ -826,7 +824,7 @@ static const struct of_device_id atmel_hlcdc_dc_of_match[] = {
static struct platform_driver atmel_hlcdc_dc_platform_driver = {
.probe = atmel_hlcdc_dc_drm_probe,
- .remove = atmel_hlcdc_dc_drm_remove,
+ .remove_new = atmel_hlcdc_dc_drm_remove,
.driver = {
.name = "atmel-hlcdc-display-controller",
.pm = pm_sleep_ptr(&atmel_hlcdc_dc_drm_pm_ops),
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 06/53] drm/atmel-hlcdc: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Sam Ravnborg, Boris Brezillon, David Airlie, Daniel Vetter,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea
Cc: kernel, linux-arm-kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 4e806b06d35d..e3960cd11a6b 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -773,15 +773,13 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
return ret;
}
-static int atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
+static void atmel_hlcdc_dc_drm_remove(struct platform_device *pdev)
{
struct drm_device *ddev = platform_get_drvdata(pdev);
drm_dev_unregister(ddev);
atmel_hlcdc_dc_unload(ddev);
drm_dev_put(ddev);
-
- return 0;
}
static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
@@ -826,7 +824,7 @@ static const struct of_device_id atmel_hlcdc_dc_of_match[] = {
static struct platform_driver atmel_hlcdc_dc_platform_driver = {
.probe = atmel_hlcdc_dc_drm_probe,
- .remove = atmel_hlcdc_dc_drm_remove,
+ .remove_new = atmel_hlcdc_dc_drm_remove,
.driver = {
.name = "atmel-hlcdc-display-controller",
.pm = pm_sleep_ptr(&atmel_hlcdc_dc_drm_pm_ops),
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 06/53] drm/atmel-hlcdc: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:44 ` Sam Ravnborg
-1 siblings, 0 replies; 261+ messages in thread
From: Sam Ravnborg @ 2023-05-07 16:44 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Alexandre Belloni, kernel, Boris Brezillon, dri-devel,
Daniel Vetter, David Airlie, Claudiu Beznea, linux-arm-kernel
On Sun, May 07, 2023 at 06:25:29PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 06/53] drm/atmel-hlcdc: Convert to platform remove callback returning void
@ 2023-05-07 16:44 ` Sam Ravnborg
0 siblings, 0 replies; 261+ messages in thread
From: Sam Ravnborg @ 2023-05-07 16:44 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Alexandre Belloni, kernel, Boris Brezillon, Nicolas Ferre,
dri-devel, Claudiu Beznea, linux-arm-kernel
On Sun, May 07, 2023 at 06:25:29PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 06/53] drm/atmel-hlcdc: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
(?)
@ 2023-05-08 7:04 ` Claudiu.Beznea
-1 siblings, 0 replies; 261+ messages in thread
From: Claudiu.Beznea @ 2023-05-08 7:04 UTC (permalink / raw)
To: u.kleine-koenig, sam, bbrezillon, airlied, daniel, Nicolas.Ferre,
alexandre.belloni
Cc: kernel, linux-arm-kernel, dri-devel
On 07.05.2023 19:25, Uwe Kleine-König wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 07/53] drm/bridge: cdns-dsi: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (9 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:37 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter, Tomi Valkeinen, Rahul T R, Jayshri Pawar
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 5dbfc7226b31..f50d65f54314 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -1278,7 +1278,7 @@ static int cdns_dsi_drm_probe(struct platform_device *pdev)
return ret;
}
-static int cdns_dsi_drm_remove(struct platform_device *pdev)
+static void cdns_dsi_drm_remove(struct platform_device *pdev)
{
struct cdns_dsi *dsi = platform_get_drvdata(pdev);
@@ -1288,8 +1288,6 @@ static int cdns_dsi_drm_remove(struct platform_device *pdev)
dsi->platform_ops->deinit(dsi);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id cdns_dsi_of_match[] = {
@@ -1303,7 +1301,7 @@ MODULE_DEVICE_TABLE(of, cdns_dsi_of_match);
static struct platform_driver cdns_dsi_platform_driver = {
.probe = cdns_dsi_drm_probe,
- .remove = cdns_dsi_drm_remove,
+ .remove_new = cdns_dsi_drm_remove,
.driver = {
.name = "cdns-dsi",
.of_match_table = cdns_dsi_of_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 07/53] drm/bridge: cdns-dsi: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 07/53] drm/bridge: cdns-dsi: " Uwe Kleine-König
@ 2023-05-08 2:37 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Tomi Valkeinen, Jernej Skrabec, dri-devel, Jayshri Pawar, kernel,
Rahul T R
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:30PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> index 5dbfc7226b31..f50d65f54314 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> @@ -1278,7 +1278,7 @@ static int cdns_dsi_drm_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int cdns_dsi_drm_remove(struct platform_device *pdev)
> +static void cdns_dsi_drm_remove(struct platform_device *pdev)
> {
> struct cdns_dsi *dsi = platform_get_drvdata(pdev);
>
> @@ -1288,8 +1288,6 @@ static int cdns_dsi_drm_remove(struct platform_device *pdev)
> dsi->platform_ops->deinit(dsi);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id cdns_dsi_of_match[] = {
> @@ -1303,7 +1301,7 @@ MODULE_DEVICE_TABLE(of, cdns_dsi_of_match);
>
> static struct platform_driver cdns_dsi_platform_driver = {
> .probe = cdns_dsi_drm_probe,
> - .remove = cdns_dsi_drm_remove,
> + .remove_new = cdns_dsi_drm_remove,
> .driver = {
> .name = "cdns-dsi",
> .of_match_table = cdns_dsi_of_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 08/53] drm/bridge: display-connector: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (10 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:46 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/display-connector.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c
index 9a12449ad7b8..fbb3e102c02f 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -382,7 +382,7 @@ static int display_connector_probe(struct platform_device *pdev)
return 0;
}
-static int display_connector_remove(struct platform_device *pdev)
+static void display_connector_remove(struct platform_device *pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
@@ -396,8 +396,6 @@ static int display_connector_remove(struct platform_device *pdev)
if (!IS_ERR(conn->bridge.ddc))
i2c_put_adapter(conn->bridge.ddc);
-
- return 0;
}
static const struct of_device_id display_connector_match[] = {
@@ -426,7 +424,7 @@ MODULE_DEVICE_TABLE(of, display_connector_match);
static struct platform_driver display_connector_driver = {
.probe = display_connector_probe,
- .remove = display_connector_remove,
+ .remove_new = display_connector_remove,
.driver = {
.name = "display-connector",
.of_match_table = display_connector_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 08/53] drm/bridge: display-connector: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 08/53] drm/bridge: display-connector: " Uwe Kleine-König
@ 2023-05-08 2:46 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:46 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:31PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/display-connector.c b/drivers/gpu/drm/bridge/display-connector.c
> index 9a12449ad7b8..fbb3e102c02f 100644
> --- a/drivers/gpu/drm/bridge/display-connector.c
> +++ b/drivers/gpu/drm/bridge/display-connector.c
> @@ -382,7 +382,7 @@ static int display_connector_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int display_connector_remove(struct platform_device *pdev)
> +static void display_connector_remove(struct platform_device *pdev)
> {
> struct display_connector *conn = platform_get_drvdata(pdev);
>
> @@ -396,8 +396,6 @@ static int display_connector_remove(struct platform_device *pdev)
>
> if (!IS_ERR(conn->bridge.ddc))
> i2c_put_adapter(conn->bridge.ddc);
> -
> - return 0;
> }
>
> static const struct of_device_id display_connector_match[] = {
> @@ -426,7 +424,7 @@ MODULE_DEVICE_TABLE(of, display_connector_match);
>
> static struct platform_driver display_connector_driver = {
> .probe = display_connector_probe,
> - .remove = display_connector_remove,
> + .remove_new = display_connector_remove,
> .driver = {
> .name = "display-connector",
> .of_match_table = display_connector_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 09/53] drm/bridge: fsl-ldb: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (11 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:45 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
index 6bac160b395b..450b352914f4 100644
--- a/drivers/gpu/drm/bridge/fsl-ldb.c
+++ b/drivers/gpu/drm/bridge/fsl-ldb.c
@@ -347,13 +347,11 @@ static int fsl_ldb_probe(struct platform_device *pdev)
return 0;
}
-static int fsl_ldb_remove(struct platform_device *pdev)
+static void fsl_ldb_remove(struct platform_device *pdev)
{
struct fsl_ldb *fsl_ldb = platform_get_drvdata(pdev);
drm_bridge_remove(&fsl_ldb->bridge);
-
- return 0;
}
static const struct of_device_id fsl_ldb_match[] = {
@@ -367,7 +365,7 @@ MODULE_DEVICE_TABLE(of, fsl_ldb_match);
static struct platform_driver fsl_ldb_driver = {
.probe = fsl_ldb_probe,
- .remove = fsl_ldb_remove,
+ .remove_new = fsl_ldb_remove,
.driver = {
.name = "fsl-ldb",
.of_match_table = fsl_ldb_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 09/53] drm/bridge: fsl-ldb: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 09/53] drm/bridge: fsl-ldb: " Uwe Kleine-König
@ 2023-05-08 2:45 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:32PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/drivers/gpu/drm/bridge/fsl-ldb.c
> index 6bac160b395b..450b352914f4 100644
> --- a/drivers/gpu/drm/bridge/fsl-ldb.c
> +++ b/drivers/gpu/drm/bridge/fsl-ldb.c
> @@ -347,13 +347,11 @@ static int fsl_ldb_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int fsl_ldb_remove(struct platform_device *pdev)
> +static void fsl_ldb_remove(struct platform_device *pdev)
> {
> struct fsl_ldb *fsl_ldb = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&fsl_ldb->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id fsl_ldb_match[] = {
> @@ -367,7 +365,7 @@ MODULE_DEVICE_TABLE(of, fsl_ldb_match);
>
> static struct platform_driver fsl_ldb_driver = {
> .probe = fsl_ldb_probe,
> - .remove = fsl_ldb_remove,
> + .remove_new = fsl_ldb_remove,
> .driver = {
> .name = "fsl-ldb",
> .of_match_table = fsl_ldb_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 10/53] drm/imx/imx8*: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
David Airlie, Daniel Vetter, Shawn Guo, Sascha Hauer
Cc: Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Fabio Estevam,
NXP Linux Team, dri-devel, linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the imx8 drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
5 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
index 178af8d2d80b..386032a02599 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
@@ -532,7 +532,7 @@ static int imx8qm_ldb_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qm_ldb_remove(struct platform_device *pdev)
+static void imx8qm_ldb_remove(struct platform_device *pdev)
{
struct imx8qm_ldb *imx8qm_ldb = platform_get_drvdata(pdev);
struct ldb *ldb = &imx8qm_ldb->base;
@@ -540,8 +540,6 @@ static int imx8qm_ldb_remove(struct platform_device *pdev)
ldb_remove_bridge_helper(ldb);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static int __maybe_unused imx8qm_ldb_runtime_suspend(struct device *dev)
@@ -573,7 +571,7 @@ MODULE_DEVICE_TABLE(of, imx8qm_ldb_dt_ids);
static struct platform_driver imx8qm_ldb_driver = {
.probe = imx8qm_ldb_probe,
- .remove = imx8qm_ldb_remove,
+ .remove_new = imx8qm_ldb_remove,
.driver = {
.pm = &imx8qm_ldb_pm_ops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
index 63948d5d20fd..c806576b1e22 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
@@ -667,7 +667,7 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_ldb_remove(struct platform_device *pdev)
+static void imx8qxp_ldb_remove(struct platform_device *pdev)
{
struct imx8qxp_ldb *imx8qxp_ldb = platform_get_drvdata(pdev);
struct ldb *ldb = &imx8qxp_ldb->base;
@@ -675,8 +675,6 @@ static int imx8qxp_ldb_remove(struct platform_device *pdev)
ldb_remove_bridge_helper(ldb);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static int __maybe_unused imx8qxp_ldb_runtime_suspend(struct device *dev)
@@ -708,7 +706,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_ldb_dt_ids);
static struct platform_driver imx8qxp_ldb_driver = {
.probe = imx8qxp_ldb_probe,
- .remove = imx8qxp_ldb_remove,
+ .remove_new = imx8qxp_ldb_remove,
.driver = {
.pm = &imx8qxp_ldb_pm_ops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
index 503bd8db8afe..d0868a6ac6c9 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -357,7 +357,7 @@ static int imx8qxp_pc_bridge_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
+static void imx8qxp_pc_bridge_remove(struct platform_device *pdev)
{
struct imx8qxp_pc *pc = platform_get_drvdata(pdev);
struct imx8qxp_pc_channel *ch;
@@ -374,8 +374,6 @@ static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
}
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static int __maybe_unused imx8qxp_pc_runtime_suspend(struct device *dev)
@@ -435,7 +433,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pc_dt_ids);
static struct platform_driver imx8qxp_pc_bridge_driver = {
.probe = imx8qxp_pc_bridge_probe,
- .remove = imx8qxp_pc_bridge_remove,
+ .remove_new = imx8qxp_pc_bridge_remove,
.driver = {
.pm = &imx8qxp_pc_pm_ops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
index 9e5f2b4dc2e5..25dc82a44ef4 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -398,13 +398,11 @@ static int imx8qxp_pixel_link_bridge_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
+static void imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
{
struct imx8qxp_pixel_link *pl = platform_get_drvdata(pdev);
drm_bridge_remove(&pl->bridge);
-
- return 0;
}
static const struct of_device_id imx8qxp_pixel_link_dt_ids[] = {
@@ -416,7 +414,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pixel_link_dt_ids);
static struct platform_driver imx8qxp_pixel_link_bridge_driver = {
.probe = imx8qxp_pixel_link_bridge_probe,
- .remove = imx8qxp_pixel_link_bridge_remove,
+ .remove_new = imx8qxp_pixel_link_bridge_remove,
.driver = {
.of_match_table = imx8qxp_pixel_link_dt_ids,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index d0fec82f0cf8..4a886cb808ca 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -455,15 +455,13 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
+static void imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
{
struct imx8qxp_pxl2dpi *p2d = platform_get_drvdata(pdev);
drm_bridge_remove(&p2d->bridge);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id imx8qxp_pxl2dpi_dt_ids[] = {
@@ -474,7 +472,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pxl2dpi_dt_ids);
static struct platform_driver imx8qxp_pxl2dpi_bridge_driver = {
.probe = imx8qxp_pxl2dpi_bridge_probe,
- .remove = imx8qxp_pxl2dpi_bridge_remove,
+ .remove_new = imx8qxp_pxl2dpi_bridge_remove,
.driver = {
.of_match_table = imx8qxp_pxl2dpi_dt_ids,
.name = DRIVER_NAME,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 10/53] drm/imx/imx8*: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
David Airlie, Daniel Vetter, Shawn Guo, Sascha Hauer
Cc: Jernej Skrabec, Jonas Karlman, dri-devel, NXP Linux Team, kernel,
linux-arm-kernel, Laurent Pinchart
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the imx8 drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
5 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
index 178af8d2d80b..386032a02599 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
@@ -532,7 +532,7 @@ static int imx8qm_ldb_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qm_ldb_remove(struct platform_device *pdev)
+static void imx8qm_ldb_remove(struct platform_device *pdev)
{
struct imx8qm_ldb *imx8qm_ldb = platform_get_drvdata(pdev);
struct ldb *ldb = &imx8qm_ldb->base;
@@ -540,8 +540,6 @@ static int imx8qm_ldb_remove(struct platform_device *pdev)
ldb_remove_bridge_helper(ldb);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static int __maybe_unused imx8qm_ldb_runtime_suspend(struct device *dev)
@@ -573,7 +571,7 @@ MODULE_DEVICE_TABLE(of, imx8qm_ldb_dt_ids);
static struct platform_driver imx8qm_ldb_driver = {
.probe = imx8qm_ldb_probe,
- .remove = imx8qm_ldb_remove,
+ .remove_new = imx8qm_ldb_remove,
.driver = {
.pm = &imx8qm_ldb_pm_ops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
index 63948d5d20fd..c806576b1e22 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
@@ -667,7 +667,7 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_ldb_remove(struct platform_device *pdev)
+static void imx8qxp_ldb_remove(struct platform_device *pdev)
{
struct imx8qxp_ldb *imx8qxp_ldb = platform_get_drvdata(pdev);
struct ldb *ldb = &imx8qxp_ldb->base;
@@ -675,8 +675,6 @@ static int imx8qxp_ldb_remove(struct platform_device *pdev)
ldb_remove_bridge_helper(ldb);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static int __maybe_unused imx8qxp_ldb_runtime_suspend(struct device *dev)
@@ -708,7 +706,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_ldb_dt_ids);
static struct platform_driver imx8qxp_ldb_driver = {
.probe = imx8qxp_ldb_probe,
- .remove = imx8qxp_ldb_remove,
+ .remove_new = imx8qxp_ldb_remove,
.driver = {
.pm = &imx8qxp_ldb_pm_ops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
index 503bd8db8afe..d0868a6ac6c9 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -357,7 +357,7 @@ static int imx8qxp_pc_bridge_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
+static void imx8qxp_pc_bridge_remove(struct platform_device *pdev)
{
struct imx8qxp_pc *pc = platform_get_drvdata(pdev);
struct imx8qxp_pc_channel *ch;
@@ -374,8 +374,6 @@ static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
}
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static int __maybe_unused imx8qxp_pc_runtime_suspend(struct device *dev)
@@ -435,7 +433,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pc_dt_ids);
static struct platform_driver imx8qxp_pc_bridge_driver = {
.probe = imx8qxp_pc_bridge_probe,
- .remove = imx8qxp_pc_bridge_remove,
+ .remove_new = imx8qxp_pc_bridge_remove,
.driver = {
.pm = &imx8qxp_pc_pm_ops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
index 9e5f2b4dc2e5..25dc82a44ef4 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -398,13 +398,11 @@ static int imx8qxp_pixel_link_bridge_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
+static void imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
{
struct imx8qxp_pixel_link *pl = platform_get_drvdata(pdev);
drm_bridge_remove(&pl->bridge);
-
- return 0;
}
static const struct of_device_id imx8qxp_pixel_link_dt_ids[] = {
@@ -416,7 +414,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pixel_link_dt_ids);
static struct platform_driver imx8qxp_pixel_link_bridge_driver = {
.probe = imx8qxp_pixel_link_bridge_probe,
- .remove = imx8qxp_pixel_link_bridge_remove,
+ .remove_new = imx8qxp_pixel_link_bridge_remove,
.driver = {
.of_match_table = imx8qxp_pixel_link_dt_ids,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index d0fec82f0cf8..4a886cb808ca 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -455,15 +455,13 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct platform_device *pdev)
return ret;
}
-static int imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
+static void imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
{
struct imx8qxp_pxl2dpi *p2d = platform_get_drvdata(pdev);
drm_bridge_remove(&p2d->bridge);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id imx8qxp_pxl2dpi_dt_ids[] = {
@@ -474,7 +472,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pxl2dpi_dt_ids);
static struct platform_driver imx8qxp_pxl2dpi_bridge_driver = {
.probe = imx8qxp_pxl2dpi_bridge_probe,
- .remove = imx8qxp_pxl2dpi_bridge_remove,
+ .remove_new = imx8qxp_pxl2dpi_bridge_remove,
.driver = {
.of_match_table = imx8qxp_pxl2dpi_dt_ids,
.name = DRIVER_NAME,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 10/53] drm/imx/imx8*: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-08 2:43 ` Laurent Pinchart
-1 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:43 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
David Airlie, Daniel Vetter, Shawn Guo, Sascha Hauer,
Jonas Karlman, Jernej Skrabec, Fabio Estevam, NXP Linux Team,
dri-devel, linux-arm-kernel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:33PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the imx8 drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> 5 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> index 178af8d2d80b..386032a02599 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> @@ -532,7 +532,7 @@ static int imx8qm_ldb_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qm_ldb_remove(struct platform_device *pdev)
> +static void imx8qm_ldb_remove(struct platform_device *pdev)
> {
> struct imx8qm_ldb *imx8qm_ldb = platform_get_drvdata(pdev);
> struct ldb *ldb = &imx8qm_ldb->base;
> @@ -540,8 +540,6 @@ static int imx8qm_ldb_remove(struct platform_device *pdev)
> ldb_remove_bridge_helper(ldb);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static int __maybe_unused imx8qm_ldb_runtime_suspend(struct device *dev)
> @@ -573,7 +571,7 @@ MODULE_DEVICE_TABLE(of, imx8qm_ldb_dt_ids);
>
> static struct platform_driver imx8qm_ldb_driver = {
> .probe = imx8qm_ldb_probe,
> - .remove = imx8qm_ldb_remove,
> + .remove_new = imx8qm_ldb_remove,
> .driver = {
> .pm = &imx8qm_ldb_pm_ops,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> index 63948d5d20fd..c806576b1e22 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -667,7 +667,7 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_ldb_remove(struct platform_device *pdev)
> +static void imx8qxp_ldb_remove(struct platform_device *pdev)
> {
> struct imx8qxp_ldb *imx8qxp_ldb = platform_get_drvdata(pdev);
> struct ldb *ldb = &imx8qxp_ldb->base;
> @@ -675,8 +675,6 @@ static int imx8qxp_ldb_remove(struct platform_device *pdev)
> ldb_remove_bridge_helper(ldb);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static int __maybe_unused imx8qxp_ldb_runtime_suspend(struct device *dev)
> @@ -708,7 +706,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_ldb_dt_ids);
>
> static struct platform_driver imx8qxp_ldb_driver = {
> .probe = imx8qxp_ldb_probe,
> - .remove = imx8qxp_ldb_remove,
> + .remove_new = imx8qxp_ldb_remove,
> .driver = {
> .pm = &imx8qxp_ldb_pm_ops,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> index 503bd8db8afe..d0868a6ac6c9 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> @@ -357,7 +357,7 @@ static int imx8qxp_pc_bridge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
> +static void imx8qxp_pc_bridge_remove(struct platform_device *pdev)
> {
> struct imx8qxp_pc *pc = platform_get_drvdata(pdev);
> struct imx8qxp_pc_channel *ch;
> @@ -374,8 +374,6 @@ static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
> }
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static int __maybe_unused imx8qxp_pc_runtime_suspend(struct device *dev)
> @@ -435,7 +433,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pc_dt_ids);
>
> static struct platform_driver imx8qxp_pc_bridge_driver = {
> .probe = imx8qxp_pc_bridge_probe,
> - .remove = imx8qxp_pc_bridge_remove,
> + .remove_new = imx8qxp_pc_bridge_remove,
> .driver = {
> .pm = &imx8qxp_pc_pm_ops,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> index 9e5f2b4dc2e5..25dc82a44ef4 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> @@ -398,13 +398,11 @@ static int imx8qxp_pixel_link_bridge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
> +static void imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
> {
> struct imx8qxp_pixel_link *pl = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&pl->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id imx8qxp_pixel_link_dt_ids[] = {
> @@ -416,7 +414,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pixel_link_dt_ids);
>
> static struct platform_driver imx8qxp_pixel_link_bridge_driver = {
> .probe = imx8qxp_pixel_link_bridge_probe,
> - .remove = imx8qxp_pixel_link_bridge_remove,
> + .remove_new = imx8qxp_pixel_link_bridge_remove,
> .driver = {
> .of_match_table = imx8qxp_pixel_link_dt_ids,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> index d0fec82f0cf8..4a886cb808ca 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -455,15 +455,13 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
> +static void imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
> {
> struct imx8qxp_pxl2dpi *p2d = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&p2d->bridge);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id imx8qxp_pxl2dpi_dt_ids[] = {
> @@ -474,7 +472,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pxl2dpi_dt_ids);
>
> static struct platform_driver imx8qxp_pxl2dpi_bridge_driver = {
> .probe = imx8qxp_pxl2dpi_bridge_probe,
> - .remove = imx8qxp_pxl2dpi_bridge_remove,
> + .remove_new = imx8qxp_pxl2dpi_bridge_remove,
> .driver = {
> .of_match_table = imx8qxp_pxl2dpi_dt_ids,
> .name = DRIVER_NAME,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 10/53] drm/imx/imx8*: Convert to platform remove callback returning void
@ 2023-05-08 2:43 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:43 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: dri-devel, Neil Armstrong, Robert Foss, Andrzej Hajda,
Jonas Karlman, Liu Ying, Shawn Guo, Sascha Hauer, Jernej Skrabec,
NXP Linux Team, kernel, linux-arm-kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:33PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the imx8 drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> 5 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> index 178af8d2d80b..386032a02599 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> @@ -532,7 +532,7 @@ static int imx8qm_ldb_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qm_ldb_remove(struct platform_device *pdev)
> +static void imx8qm_ldb_remove(struct platform_device *pdev)
> {
> struct imx8qm_ldb *imx8qm_ldb = platform_get_drvdata(pdev);
> struct ldb *ldb = &imx8qm_ldb->base;
> @@ -540,8 +540,6 @@ static int imx8qm_ldb_remove(struct platform_device *pdev)
> ldb_remove_bridge_helper(ldb);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static int __maybe_unused imx8qm_ldb_runtime_suspend(struct device *dev)
> @@ -573,7 +571,7 @@ MODULE_DEVICE_TABLE(of, imx8qm_ldb_dt_ids);
>
> static struct platform_driver imx8qm_ldb_driver = {
> .probe = imx8qm_ldb_probe,
> - .remove = imx8qm_ldb_remove,
> + .remove_new = imx8qm_ldb_remove,
> .driver = {
> .pm = &imx8qm_ldb_pm_ops,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> index 63948d5d20fd..c806576b1e22 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -667,7 +667,7 @@ static int imx8qxp_ldb_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_ldb_remove(struct platform_device *pdev)
> +static void imx8qxp_ldb_remove(struct platform_device *pdev)
> {
> struct imx8qxp_ldb *imx8qxp_ldb = platform_get_drvdata(pdev);
> struct ldb *ldb = &imx8qxp_ldb->base;
> @@ -675,8 +675,6 @@ static int imx8qxp_ldb_remove(struct platform_device *pdev)
> ldb_remove_bridge_helper(ldb);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static int __maybe_unused imx8qxp_ldb_runtime_suspend(struct device *dev)
> @@ -708,7 +706,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_ldb_dt_ids);
>
> static struct platform_driver imx8qxp_ldb_driver = {
> .probe = imx8qxp_ldb_probe,
> - .remove = imx8qxp_ldb_remove,
> + .remove_new = imx8qxp_ldb_remove,
> .driver = {
> .pm = &imx8qxp_ldb_pm_ops,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> index 503bd8db8afe..d0868a6ac6c9 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
> @@ -357,7 +357,7 @@ static int imx8qxp_pc_bridge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
> +static void imx8qxp_pc_bridge_remove(struct platform_device *pdev)
> {
> struct imx8qxp_pc *pc = platform_get_drvdata(pdev);
> struct imx8qxp_pc_channel *ch;
> @@ -374,8 +374,6 @@ static int imx8qxp_pc_bridge_remove(struct platform_device *pdev)
> }
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static int __maybe_unused imx8qxp_pc_runtime_suspend(struct device *dev)
> @@ -435,7 +433,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pc_dt_ids);
>
> static struct platform_driver imx8qxp_pc_bridge_driver = {
> .probe = imx8qxp_pc_bridge_probe,
> - .remove = imx8qxp_pc_bridge_remove,
> + .remove_new = imx8qxp_pc_bridge_remove,
> .driver = {
> .pm = &imx8qxp_pc_pm_ops,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> index 9e5f2b4dc2e5..25dc82a44ef4 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
> @@ -398,13 +398,11 @@ static int imx8qxp_pixel_link_bridge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
> +static void imx8qxp_pixel_link_bridge_remove(struct platform_device *pdev)
> {
> struct imx8qxp_pixel_link *pl = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&pl->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id imx8qxp_pixel_link_dt_ids[] = {
> @@ -416,7 +414,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pixel_link_dt_ids);
>
> static struct platform_driver imx8qxp_pixel_link_bridge_driver = {
> .probe = imx8qxp_pixel_link_bridge_probe,
> - .remove = imx8qxp_pixel_link_bridge_remove,
> + .remove_new = imx8qxp_pixel_link_bridge_remove,
> .driver = {
> .of_match_table = imx8qxp_pixel_link_dt_ids,
> .name = DRIVER_NAME,
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> index d0fec82f0cf8..4a886cb808ca 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -455,15 +455,13 @@ static int imx8qxp_pxl2dpi_bridge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
> +static void imx8qxp_pxl2dpi_bridge_remove(struct platform_device *pdev)
> {
> struct imx8qxp_pxl2dpi *p2d = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&p2d->bridge);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id imx8qxp_pxl2dpi_dt_ids[] = {
> @@ -474,7 +472,7 @@ MODULE_DEVICE_TABLE(of, imx8qxp_pxl2dpi_dt_ids);
>
> static struct platform_driver imx8qxp_pxl2dpi_bridge_driver = {
> .probe = imx8qxp_pxl2dpi_bridge_probe,
> - .remove = imx8qxp_pxl2dpi_bridge_remove,
> + .remove_new = imx8qxp_pxl2dpi_bridge_remove,
> .driver = {
> .of_match_table = imx8qxp_pxl2dpi_dt_ids,
> .name = DRIVER_NAME,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 11/53] drm/bridge: lvds-codec: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (13 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:44 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
index 39e7004de720..67368f23d4aa 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -215,13 +215,11 @@ static int lvds_codec_probe(struct platform_device *pdev)
return 0;
}
-static int lvds_codec_remove(struct platform_device *pdev)
+static void lvds_codec_remove(struct platform_device *pdev)
{
struct lvds_codec *lvds_codec = platform_get_drvdata(pdev);
drm_bridge_remove(&lvds_codec->bridge);
-
- return 0;
}
static const struct of_device_id lvds_codec_match[] = {
@@ -243,7 +241,7 @@ MODULE_DEVICE_TABLE(of, lvds_codec_match);
static struct platform_driver lvds_codec_driver = {
.probe = lvds_codec_probe,
- .remove = lvds_codec_remove,
+ .remove_new = lvds_codec_remove,
.driver = {
.name = "lvds-codec",
.of_match_table = lvds_codec_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 11/53] drm/bridge: lvds-codec: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 11/53] drm/bridge: lvds-codec: " Uwe Kleine-König
@ 2023-05-08 2:44 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:44 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:34PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
> index 39e7004de720..67368f23d4aa 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -215,13 +215,11 @@ static int lvds_codec_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int lvds_codec_remove(struct platform_device *pdev)
> +static void lvds_codec_remove(struct platform_device *pdev)
> {
> struct lvds_codec *lvds_codec = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&lvds_codec->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id lvds_codec_match[] = {
> @@ -243,7 +241,7 @@ MODULE_DEVICE_TABLE(of, lvds_codec_match);
>
> static struct platform_driver lvds_codec_driver = {
> .probe = lvds_codec_probe,
> - .remove = lvds_codec_remove,
> + .remove_new = lvds_codec_remove,
> .driver = {
> .name = "lvds-codec",
> .of_match_table = lvds_codec_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 12/53] drm/bridge: nwl-dsi: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (14 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:36 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 6dc2a4e191d7..4a5f5c4f5dcc 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -1199,7 +1199,7 @@ static int nwl_dsi_probe(struct platform_device *pdev)
return 0;
}
-static int nwl_dsi_remove(struct platform_device *pdev)
+static void nwl_dsi_remove(struct platform_device *pdev)
{
struct nwl_dsi *dsi = platform_get_drvdata(pdev);
@@ -1207,12 +1207,11 @@ static int nwl_dsi_remove(struct platform_device *pdev)
mipi_dsi_host_unregister(&dsi->dsi_host);
drm_bridge_remove(&dsi->bridge);
pm_runtime_disable(&pdev->dev);
- return 0;
}
static struct platform_driver nwl_dsi_driver = {
.probe = nwl_dsi_probe,
- .remove = nwl_dsi_remove,
+ .remove_new = nwl_dsi_remove,
.driver = {
.of_match_table = nwl_dsi_dt_ids,
.name = DRV_NAME,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 12/53] drm/bridge: nwl-dsi: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 12/53] drm/bridge: nwl-dsi: " Uwe Kleine-König
@ 2023-05-08 2:36 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:35PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 6dc2a4e191d7..4a5f5c4f5dcc 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -1199,7 +1199,7 @@ static int nwl_dsi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int nwl_dsi_remove(struct platform_device *pdev)
> +static void nwl_dsi_remove(struct platform_device *pdev)
> {
> struct nwl_dsi *dsi = platform_get_drvdata(pdev);
>
> @@ -1207,12 +1207,11 @@ static int nwl_dsi_remove(struct platform_device *pdev)
> mipi_dsi_host_unregister(&dsi->dsi_host);
> drm_bridge_remove(&dsi->bridge);
> pm_runtime_disable(&pdev->dev);
> - return 0;
> }
>
> static struct platform_driver nwl_dsi_driver = {
> .probe = nwl_dsi_probe,
> - .remove = nwl_dsi_remove,
> + .remove_new = nwl_dsi_remove,
> .driver = {
> .of_match_table = nwl_dsi_dt_ids,
> .name = DRV_NAME,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 13/53] drm/bridge: simple-bridge: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (15 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:45 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 2c5c5211bdab..5ede3e111096 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -218,13 +218,11 @@ static int simple_bridge_probe(struct platform_device *pdev)
return 0;
}
-static int simple_bridge_remove(struct platform_device *pdev)
+static void simple_bridge_remove(struct platform_device *pdev)
{
struct simple_bridge *sbridge = platform_get_drvdata(pdev);
drm_bridge_remove(&sbridge->bridge);
-
- return 0;
}
/*
@@ -301,7 +299,7 @@ MODULE_DEVICE_TABLE(of, simple_bridge_match);
static struct platform_driver simple_bridge_driver = {
.probe = simple_bridge_probe,
- .remove = simple_bridge_remove,
+ .remove_new = simple_bridge_remove,
.driver = {
.name = "simple-bridge",
.of_match_table = simple_bridge_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 13/53] drm/bridge: simple-bridge: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 13/53] drm/bridge: simple-bridge: " Uwe Kleine-König
@ 2023-05-08 2:45 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:36PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> index 2c5c5211bdab..5ede3e111096 100644
> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> @@ -218,13 +218,11 @@ static int simple_bridge_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int simple_bridge_remove(struct platform_device *pdev)
> +static void simple_bridge_remove(struct platform_device *pdev)
> {
> struct simple_bridge *sbridge = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&sbridge->bridge);
> -
> - return 0;
> }
>
> /*
> @@ -301,7 +299,7 @@ MODULE_DEVICE_TABLE(of, simple_bridge_match);
>
> static struct platform_driver simple_bridge_driver = {
> .probe = simple_bridge_probe,
> - .remove = simple_bridge_remove,
> + .remove_new = simple_bridge_remove,
> .driver = {
> .name = "simple-bridge",
> .of_match_table = simple_bridge_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 14/53] drm/bridge: synopsys: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (16 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:37 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter, Minghao Chi, Mark Brown, Kuninori Morimoto
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the synopsis bridge drivers from always returning zero
in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
4 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 4efb62bcdb63..67b8d17a722a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -584,13 +584,11 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int snd_dw_hdmi_remove(struct platform_device *pdev)
+static void snd_dw_hdmi_remove(struct platform_device *pdev)
{
struct snd_dw_hdmi *dw = platform_get_drvdata(pdev);
snd_card_free(dw->card);
-
- return 0;
}
#if defined(CONFIG_PM_SLEEP) && defined(IS_NOT_BROKEN)
@@ -625,7 +623,7 @@ static SIMPLE_DEV_PM_OPS(snd_dw_hdmi_pm, snd_dw_hdmi_suspend,
static struct platform_driver snd_dw_hdmi_driver = {
.probe = snd_dw_hdmi_probe,
- .remove = snd_dw_hdmi_remove,
+ .remove_new = snd_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
.pm = PM_OPS,
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
index c8f44bcb298a..9389ce526eb1 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -296,19 +296,17 @@ static int dw_hdmi_cec_probe(struct platform_device *pdev)
return 0;
}
-static int dw_hdmi_cec_remove(struct platform_device *pdev)
+static void dw_hdmi_cec_remove(struct platform_device *pdev)
{
struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
cec_notifier_cec_adap_unregister(cec->notify, cec->adap);
cec_unregister_adapter(cec->adap);
-
- return 0;
}
static struct platform_driver dw_hdmi_cec_driver = {
.probe = dw_hdmi_cec_probe,
- .remove = dw_hdmi_cec_remove,
+ .remove_new = dw_hdmi_cec_remove,
.driver = {
.name = "dw-hdmi-cec",
},
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c
index 557966239677..423762da2ab4 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c
@@ -172,18 +172,16 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(dw->audio_pdev);
}
-static int snd_dw_hdmi_remove(struct platform_device *pdev)
+static void snd_dw_hdmi_remove(struct platform_device *pdev)
{
struct snd_dw_hdmi *dw = platform_get_drvdata(pdev);
platform_device_unregister(dw->audio_pdev);
-
- return 0;
}
static struct platform_driver snd_dw_hdmi_driver = {
.probe = snd_dw_hdmi_probe,
- .remove = snd_dw_hdmi_remove,
+ .remove_new = snd_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
},
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index d751820c6da6..26c187d20d97 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -216,18 +216,16 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
return 0;
}
-static int snd_dw_hdmi_remove(struct platform_device *pdev)
+static void snd_dw_hdmi_remove(struct platform_device *pdev)
{
struct platform_device *platform = dev_get_drvdata(&pdev->dev);
platform_device_unregister(platform);
-
- return 0;
}
static struct platform_driver snd_dw_hdmi_driver = {
.probe = snd_dw_hdmi_probe,
- .remove = snd_dw_hdmi_remove,
+ .remove_new = snd_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
},
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 14/53] drm/bridge: synopsys: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 14/53] drm/bridge: synopsys: " Uwe Kleine-König
@ 2023-05-08 2:37 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Kuninori Morimoto,
Jonas Karlman, dri-devel, Minghao Chi, Mark Brown, Jernej Skrabec,
kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:37PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the synopsis bridge drivers from always returning zero
> in the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> 4 files changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> index 4efb62bcdb63..67b8d17a722a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> @@ -584,13 +584,11 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int snd_dw_hdmi_remove(struct platform_device *pdev)
> +static void snd_dw_hdmi_remove(struct platform_device *pdev)
> {
> struct snd_dw_hdmi *dw = platform_get_drvdata(pdev);
>
> snd_card_free(dw->card);
> -
> - return 0;
> }
>
> #if defined(CONFIG_PM_SLEEP) && defined(IS_NOT_BROKEN)
> @@ -625,7 +623,7 @@ static SIMPLE_DEV_PM_OPS(snd_dw_hdmi_pm, snd_dw_hdmi_suspend,
>
> static struct platform_driver snd_dw_hdmi_driver = {
> .probe = snd_dw_hdmi_probe,
> - .remove = snd_dw_hdmi_remove,
> + .remove_new = snd_dw_hdmi_remove,
> .driver = {
> .name = DRIVER_NAME,
> .pm = PM_OPS,
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> index c8f44bcb298a..9389ce526eb1 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> @@ -296,19 +296,17 @@ static int dw_hdmi_cec_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int dw_hdmi_cec_remove(struct platform_device *pdev)
> +static void dw_hdmi_cec_remove(struct platform_device *pdev)
> {
> struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
>
> cec_notifier_cec_adap_unregister(cec->notify, cec->adap);
> cec_unregister_adapter(cec->adap);
> -
> - return 0;
> }
>
> static struct platform_driver dw_hdmi_cec_driver = {
> .probe = dw_hdmi_cec_probe,
> - .remove = dw_hdmi_cec_remove,
> + .remove_new = dw_hdmi_cec_remove,
> .driver = {
> .name = "dw-hdmi-cec",
> },
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c
> index 557966239677..423762da2ab4 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c
> @@ -172,18 +172,16 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(dw->audio_pdev);
> }
>
> -static int snd_dw_hdmi_remove(struct platform_device *pdev)
> +static void snd_dw_hdmi_remove(struct platform_device *pdev)
> {
> struct snd_dw_hdmi *dw = platform_get_drvdata(pdev);
>
> platform_device_unregister(dw->audio_pdev);
> -
> - return 0;
> }
>
> static struct platform_driver snd_dw_hdmi_driver = {
> .probe = snd_dw_hdmi_probe,
> - .remove = snd_dw_hdmi_remove,
> + .remove_new = snd_dw_hdmi_remove,
> .driver = {
> .name = DRIVER_NAME,
> },
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> index d751820c6da6..26c187d20d97 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -216,18 +216,16 @@ static int snd_dw_hdmi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int snd_dw_hdmi_remove(struct platform_device *pdev)
> +static void snd_dw_hdmi_remove(struct platform_device *pdev)
> {
> struct platform_device *platform = dev_get_drvdata(&pdev->dev);
>
> platform_device_unregister(platform);
> -
> - return 0;
> }
>
> static struct platform_driver snd_dw_hdmi_driver = {
> .probe = snd_dw_hdmi_probe,
> - .remove = snd_dw_hdmi_remove,
> + .remove_new = snd_dw_hdmi_remove,
> .driver = {
> .name = DRIVER_NAME,
> },
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 15/53] drm/bridge: thc63lvd1024: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (17 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:44 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c b/drivers/gpu/drm/bridge/thc63lvd1024.c
index e21078b2f8b5..d4c1a601bbb5 100644
--- a/drivers/gpu/drm/bridge/thc63lvd1024.c
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -230,13 +230,11 @@ static int thc63_probe(struct platform_device *pdev)
return 0;
}
-static int thc63_remove(struct platform_device *pdev)
+static void thc63_remove(struct platform_device *pdev)
{
struct thc63_dev *thc63 = platform_get_drvdata(pdev);
drm_bridge_remove(&thc63->bridge);
-
- return 0;
}
static const struct of_device_id thc63_match[] = {
@@ -247,7 +245,7 @@ MODULE_DEVICE_TABLE(of, thc63_match);
static struct platform_driver thc63_driver = {
.probe = thc63_probe,
- .remove = thc63_remove,
+ .remove_new = thc63_remove,
.driver = {
.name = "thc63lvd1024",
.of_match_table = thc63_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 15/53] drm/bridge: thc63lvd1024: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 15/53] drm/bridge: thc63lvd1024: " Uwe Kleine-König
@ 2023-05-08 2:44 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:44 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:38PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c b/drivers/gpu/drm/bridge/thc63lvd1024.c
> index e21078b2f8b5..d4c1a601bbb5 100644
> --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -230,13 +230,11 @@ static int thc63_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int thc63_remove(struct platform_device *pdev)
> +static void thc63_remove(struct platform_device *pdev)
> {
> struct thc63_dev *thc63 = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&thc63->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id thc63_match[] = {
> @@ -247,7 +245,7 @@ MODULE_DEVICE_TABLE(of, thc63_match);
>
> static struct platform_driver thc63_driver = {
> .probe = thc63_probe,
> - .remove = thc63_remove,
> + .remove_new = thc63_remove,
> .driver = {
> .name = "thc63lvd1024",
> .of_match_table = thc63_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 16/53] drm/bridge: tfp410: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (18 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:44 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel, Laurent Pinchart, Jernej Skrabec,
Jonas Karlman
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
index 6db69df0e18b..ab63225cd635 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -355,11 +355,9 @@ static int tfp410_probe(struct platform_device *pdev)
return tfp410_init(&pdev->dev, false);
}
-static int tfp410_remove(struct platform_device *pdev)
+static void tfp410_remove(struct platform_device *pdev)
{
tfp410_fini(&pdev->dev);
-
- return 0;
}
static const struct of_device_id tfp410_match[] = {
@@ -370,7 +368,7 @@ MODULE_DEVICE_TABLE(of, tfp410_match);
static struct platform_driver tfp410_platform_driver = {
.probe = tfp410_probe,
- .remove = tfp410_remove,
+ .remove_new = tfp410_remove,
.driver = {
.name = "tfp410-bridge",
.of_match_table = tfp410_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 16/53] drm/bridge: tfp410: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 16/53] drm/bridge: tfp410: " Uwe Kleine-König
@ 2023-05-08 2:44 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:44 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, Robert Foss, Andrzej Hajda, Jonas Karlman,
Jernej Skrabec, dri-devel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:39PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
> index 6db69df0e18b..ab63225cd635 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -355,11 +355,9 @@ static int tfp410_probe(struct platform_device *pdev)
> return tfp410_init(&pdev->dev, false);
> }
>
> -static int tfp410_remove(struct platform_device *pdev)
> +static void tfp410_remove(struct platform_device *pdev)
> {
> tfp410_fini(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id tfp410_match[] = {
> @@ -370,7 +368,7 @@ MODULE_DEVICE_TABLE(of, tfp410_match);
>
> static struct platform_driver tfp410_platform_driver = {
> .probe = tfp410_probe,
> - .remove = tfp410_remove,
> + .remove_new = tfp410_remove,
> .driver = {
> .name = "tfp410-bridge",
> .of_match_table = tfp410_match,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 17/53] drm/etnaviv: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (19 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Lucas Stach, David Airlie, Daniel Vetter
Cc: kernel, etnaviv, dri-devel, Russell King
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the etnaviv drm driver from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 31a7f59ccb49..071254653cf3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -641,16 +641,14 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &etnaviv_master_ops, match);
}
-static int etnaviv_pdev_remove(struct platform_device *pdev)
+static void etnaviv_pdev_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &etnaviv_master_ops);
-
- return 0;
}
static struct platform_driver etnaviv_platform_driver = {
.probe = etnaviv_pdev_probe,
- .remove = etnaviv_pdev_remove,
+ .remove_new = etnaviv_pdev_remove,
.driver = {
.name = "etnaviv",
},
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index de8c9894967c..52ab18a30b85 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1892,11 +1892,10 @@ static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
return 0;
}
-static int etnaviv_gpu_platform_remove(struct platform_device *pdev)
+static void etnaviv_gpu_platform_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &gpu_ops);
pm_runtime_disable(&pdev->dev);
- return 0;
}
static int etnaviv_gpu_rpm_suspend(struct device *dev)
@@ -1954,6 +1953,6 @@ struct platform_driver etnaviv_gpu_driver = {
.of_match_table = etnaviv_gpu_match,
},
.probe = etnaviv_gpu_platform_probe,
- .remove = etnaviv_gpu_platform_remove,
+ .remove_new = etnaviv_gpu_platform_remove,
.id_table = gpu_ids,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Daniel Vetter, Krzysztof Kozlowski, Jingoo Han
Cc: Alim Akhtar, dri-devel, linux-arm-kernel, linux-samsung-soc,
kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the exynos drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
14 files changed, 28 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2867b39fa35e..dd63418a9fd2 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct platform_device *pdev)
return ret;
}
-static int exynos5433_decon_remove(struct platform_device *pdev)
+static void exynos5433_decon_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &decon_component_ops);
-
- return 0;
}
struct platform_driver exynos5433_decon_driver = {
.probe = exynos5433_decon_probe,
- .remove = exynos5433_decon_remove,
+ .remove_new = exynos5433_decon_remove,
.driver = {
.name = "exynos5433-decon",
.pm = pm_ptr(&exynos5433_decon_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3126f735dedc..6fca23e04285 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -766,7 +766,7 @@ static int decon_probe(struct platform_device *pdev)
return ret;
}
-static int decon_remove(struct platform_device *pdev)
+static void decon_remove(struct platform_device *pdev)
{
struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
@@ -775,8 +775,6 @@ static int decon_remove(struct platform_device *pdev)
iounmap(ctx->regs);
component_del(&pdev->dev, &decon_component_ops);
-
- return 0;
}
static int exynos7_decon_suspend(struct device *dev)
@@ -841,7 +839,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops, exynos7_decon_suspend,
struct platform_driver decon_driver = {
.probe = decon_probe,
- .remove = decon_remove,
+ .remove_new = decon_remove,
.driver = {
.name = "exynos-decon",
.pm = pm_ptr(&exynos7_decon_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 3404ec1367fb..ca31bad6c576 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -250,14 +250,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &exynos_dp_ops);
}
-static int exynos_dp_remove(struct platform_device *pdev)
+static void exynos_dp_remove(struct platform_device *pdev)
{
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
component_del(&pdev->dev, &exynos_dp_ops);
analogix_dp_remove(dp->adp);
-
- return 0;
}
static int exynos_dp_suspend(struct device *dev)
@@ -285,7 +283,7 @@ MODULE_DEVICE_TABLE(of, exynos_dp_match);
struct platform_driver dp_driver = {
.probe = exynos_dp_probe,
- .remove = exynos_dp_remove,
+ .remove_new = exynos_dp_remove,
.driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 16c539657f73..67f2e68d6e3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -354,15 +354,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev)
match);
}
-static int exynos_drm_platform_remove(struct platform_device *pdev)
+static void exynos_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &exynos_drm_ops);
- return 0;
}
static struct platform_driver exynos_drm_platform_driver = {
.probe = exynos_drm_platform_probe,
- .remove = exynos_drm_platform_remove,
+ .remove_new = exynos_drm_platform_remove,
.driver = {
.name = "exynos-drm",
.pm = &exynos_drm_pm_ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 06d6513ddaae..96aa98945f18 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1744,13 +1744,11 @@ static int exynos_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int exynos_dsi_remove(struct platform_device *pdev)
+static void exynos_dsi_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &exynos_dsi_component_ops);
-
- return 0;
}
static int __maybe_unused exynos_dsi_suspend(struct device *dev)
@@ -1825,7 +1823,7 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
struct platform_driver dsi_driver = {
.probe = exynos_dsi_probe,
- .remove = exynos_dsi_remove,
+ .remove_new = exynos_dsi_remove,
.driver = {
.name = "exynos-dsi",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 8de2714599fc..e81a576de398 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1367,7 +1367,7 @@ static int fimc_probe(struct platform_device *pdev)
return ret;
}
-static int fimc_remove(struct platform_device *pdev)
+static void fimc_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct fimc_context *ctx = get_fimc_context(dev);
@@ -1377,8 +1377,6 @@ static int fimc_remove(struct platform_device *pdev)
pm_runtime_disable(dev);
fimc_put_clocks(ctx);
-
- return 0;
}
static int fimc_runtime_suspend(struct device *dev)
@@ -1410,7 +1408,7 @@ MODULE_DEVICE_TABLE(of, fimc_of_match);
struct platform_driver fimc_driver = {
.probe = fimc_probe,
- .remove = fimc_remove,
+ .remove_new = fimc_remove,
.driver = {
.of_match_table = fimc_of_match,
.name = "exynos-drm-fimc",
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7f4a0be03dd1..cab64bc2b332 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1278,13 +1278,11 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
-static int fimd_remove(struct platform_device *pdev)
+static void fimd_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &fimd_component_ops);
-
- return 0;
}
static int exynos_fimd_suspend(struct device *dev)
@@ -1326,7 +1324,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos_fimd_pm_ops, exynos_fimd_suspend,
struct platform_driver fimd_driver = {
.probe = fimd_probe,
- .remove = fimd_remove,
+ .remove_new = fimd_remove,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ec784e58da5c..1f327b06645c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1530,7 +1530,7 @@ static int g2d_probe(struct platform_device *pdev)
return ret;
}
-static int g2d_remove(struct platform_device *pdev)
+static void g2d_remove(struct platform_device *pdev)
{
struct g2d_data *g2d = platform_get_drvdata(pdev);
@@ -1545,8 +1545,6 @@ static int g2d_remove(struct platform_device *pdev)
g2d_fini_cmdlist(g2d);
destroy_workqueue(g2d->g2d_workq);
kmem_cache_destroy(g2d->runqueue_slab);
-
- return 0;
}
static int g2d_suspend(struct device *dev)
@@ -1609,7 +1607,7 @@ MODULE_DEVICE_TABLE(of, exynos_g2d_match);
struct platform_driver g2d_driver = {
.probe = g2d_probe,
- .remove = g2d_remove,
+ .remove_new = g2d_remove,
.driver = {
.name = "exynos-drm-g2d",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 964dceb28c1e..f9cf4461036c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1308,15 +1308,13 @@ static int gsc_probe(struct platform_device *pdev)
return ret;
}
-static int gsc_remove(struct platform_device *pdev)
+static void gsc_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &gsc_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int __maybe_unused gsc_runtime_suspend(struct device *dev)
@@ -1421,7 +1419,7 @@ MODULE_DEVICE_TABLE(of, exynos_drm_gsc_of_match);
struct platform_driver gsc_driver = {
.probe = gsc_probe,
- .remove = gsc_remove,
+ .remove_new = gsc_remove,
.driver = {
.name = "exynos-drm-gsc",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 17bab5b1663f..e2920960180f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -442,7 +442,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
return ret;
}
-static int exynos_mic_remove(struct platform_device *pdev)
+static void exynos_mic_remove(struct platform_device *pdev)
{
struct exynos_mic *mic = platform_get_drvdata(pdev);
@@ -450,8 +450,6 @@ static int exynos_mic_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
drm_bridge_remove(&mic->bridge);
-
- return 0;
}
static const struct of_device_id exynos_mic_of_match[] = {
@@ -462,7 +460,7 @@ MODULE_DEVICE_TABLE(of, exynos_mic_of_match);
struct platform_driver mic_driver = {
.probe = exynos_mic_probe,
- .remove = exynos_mic_remove,
+ .remove_new = exynos_mic_remove,
.driver = {
.name = "exynos-mic",
.pm = pm_ptr(&exynos_mic_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 8706f377c349..797424a5d83b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -329,15 +329,13 @@ static int rotator_probe(struct platform_device *pdev)
return ret;
}
-static int rotator_remove(struct platform_device *pdev)
+static void rotator_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &rotator_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int rotator_runtime_suspend(struct device *dev)
@@ -453,7 +451,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(rotator_pm_ops, rotator_runtime_suspend,
struct platform_driver rotator_driver = {
.probe = rotator_probe,
- .remove = rotator_remove,
+ .remove_new = rotator_remove,
.driver = {
.name = "exynos-rotator",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
index 20608e9780ce..b5cbb864c0c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
@@ -539,15 +539,13 @@ static int scaler_probe(struct platform_device *pdev)
return ret;
}
-static int scaler_remove(struct platform_device *pdev)
+static void scaler_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &scaler_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int clk_disable_unprepare_wrapper(struct clk *clk)
@@ -721,7 +719,7 @@ MODULE_DEVICE_TABLE(of, exynos_scaler_match);
struct platform_driver scaler_driver = {
.probe = scaler_probe,
- .remove = scaler_remove,
+ .remove_new = scaler_remove,
.driver = {
.name = "exynos-scaler",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b7c11bdce2c8..b03cc88f873b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2067,7 +2067,7 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int hdmi_remove(struct platform_device *pdev)
+static void hdmi_remove(struct platform_device *pdev)
{
struct hdmi_context *hdata = platform_get_drvdata(pdev);
@@ -2090,8 +2090,6 @@ static int hdmi_remove(struct platform_device *pdev)
put_device(&hdata->ddc_adpt->dev);
mutex_destroy(&hdata->mutex);
-
- return 0;
}
static int __maybe_unused exynos_hdmi_suspend(struct device *dev)
@@ -2123,7 +2121,7 @@ static const struct dev_pm_ops exynos_hdmi_pm_ops = {
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
- .remove = hdmi_remove,
+ .remove_new = hdmi_remove,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8d333db813b7..9aaf62c85cff 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1259,13 +1259,11 @@ static int mixer_probe(struct platform_device *pdev)
return ret;
}
-static int mixer_remove(struct platform_device *pdev)
+static void mixer_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &mixer_component_ops);
-
- return 0;
}
static int __maybe_unused exynos_mixer_suspend(struct device *dev)
@@ -1339,5 +1337,5 @@ struct platform_driver mixer_driver = {
.of_match_table = mixer_match_types,
},
.probe = mixer_probe,
- .remove = mixer_remove,
+ .remove_new = mixer_remove,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Daniel Vetter, Krzysztof Kozlowski, Jingoo Han
Cc: linux-arm-kernel, kernel, linux-samsung-soc, dri-devel,
Alim Akhtar
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the exynos drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
14 files changed, 28 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2867b39fa35e..dd63418a9fd2 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct platform_device *pdev)
return ret;
}
-static int exynos5433_decon_remove(struct platform_device *pdev)
+static void exynos5433_decon_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &decon_component_ops);
-
- return 0;
}
struct platform_driver exynos5433_decon_driver = {
.probe = exynos5433_decon_probe,
- .remove = exynos5433_decon_remove,
+ .remove_new = exynos5433_decon_remove,
.driver = {
.name = "exynos5433-decon",
.pm = pm_ptr(&exynos5433_decon_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3126f735dedc..6fca23e04285 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -766,7 +766,7 @@ static int decon_probe(struct platform_device *pdev)
return ret;
}
-static int decon_remove(struct platform_device *pdev)
+static void decon_remove(struct platform_device *pdev)
{
struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
@@ -775,8 +775,6 @@ static int decon_remove(struct platform_device *pdev)
iounmap(ctx->regs);
component_del(&pdev->dev, &decon_component_ops);
-
- return 0;
}
static int exynos7_decon_suspend(struct device *dev)
@@ -841,7 +839,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops, exynos7_decon_suspend,
struct platform_driver decon_driver = {
.probe = decon_probe,
- .remove = decon_remove,
+ .remove_new = decon_remove,
.driver = {
.name = "exynos-decon",
.pm = pm_ptr(&exynos7_decon_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 3404ec1367fb..ca31bad6c576 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -250,14 +250,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &exynos_dp_ops);
}
-static int exynos_dp_remove(struct platform_device *pdev)
+static void exynos_dp_remove(struct platform_device *pdev)
{
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
component_del(&pdev->dev, &exynos_dp_ops);
analogix_dp_remove(dp->adp);
-
- return 0;
}
static int exynos_dp_suspend(struct device *dev)
@@ -285,7 +283,7 @@ MODULE_DEVICE_TABLE(of, exynos_dp_match);
struct platform_driver dp_driver = {
.probe = exynos_dp_probe,
- .remove = exynos_dp_remove,
+ .remove_new = exynos_dp_remove,
.driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 16c539657f73..67f2e68d6e3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -354,15 +354,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev)
match);
}
-static int exynos_drm_platform_remove(struct platform_device *pdev)
+static void exynos_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &exynos_drm_ops);
- return 0;
}
static struct platform_driver exynos_drm_platform_driver = {
.probe = exynos_drm_platform_probe,
- .remove = exynos_drm_platform_remove,
+ .remove_new = exynos_drm_platform_remove,
.driver = {
.name = "exynos-drm",
.pm = &exynos_drm_pm_ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 06d6513ddaae..96aa98945f18 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1744,13 +1744,11 @@ static int exynos_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int exynos_dsi_remove(struct platform_device *pdev)
+static void exynos_dsi_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &exynos_dsi_component_ops);
-
- return 0;
}
static int __maybe_unused exynos_dsi_suspend(struct device *dev)
@@ -1825,7 +1823,7 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
struct platform_driver dsi_driver = {
.probe = exynos_dsi_probe,
- .remove = exynos_dsi_remove,
+ .remove_new = exynos_dsi_remove,
.driver = {
.name = "exynos-dsi",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 8de2714599fc..e81a576de398 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1367,7 +1367,7 @@ static int fimc_probe(struct platform_device *pdev)
return ret;
}
-static int fimc_remove(struct platform_device *pdev)
+static void fimc_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct fimc_context *ctx = get_fimc_context(dev);
@@ -1377,8 +1377,6 @@ static int fimc_remove(struct platform_device *pdev)
pm_runtime_disable(dev);
fimc_put_clocks(ctx);
-
- return 0;
}
static int fimc_runtime_suspend(struct device *dev)
@@ -1410,7 +1408,7 @@ MODULE_DEVICE_TABLE(of, fimc_of_match);
struct platform_driver fimc_driver = {
.probe = fimc_probe,
- .remove = fimc_remove,
+ .remove_new = fimc_remove,
.driver = {
.of_match_table = fimc_of_match,
.name = "exynos-drm-fimc",
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7f4a0be03dd1..cab64bc2b332 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1278,13 +1278,11 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
-static int fimd_remove(struct platform_device *pdev)
+static void fimd_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &fimd_component_ops);
-
- return 0;
}
static int exynos_fimd_suspend(struct device *dev)
@@ -1326,7 +1324,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos_fimd_pm_ops, exynos_fimd_suspend,
struct platform_driver fimd_driver = {
.probe = fimd_probe,
- .remove = fimd_remove,
+ .remove_new = fimd_remove,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ec784e58da5c..1f327b06645c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1530,7 +1530,7 @@ static int g2d_probe(struct platform_device *pdev)
return ret;
}
-static int g2d_remove(struct platform_device *pdev)
+static void g2d_remove(struct platform_device *pdev)
{
struct g2d_data *g2d = platform_get_drvdata(pdev);
@@ -1545,8 +1545,6 @@ static int g2d_remove(struct platform_device *pdev)
g2d_fini_cmdlist(g2d);
destroy_workqueue(g2d->g2d_workq);
kmem_cache_destroy(g2d->runqueue_slab);
-
- return 0;
}
static int g2d_suspend(struct device *dev)
@@ -1609,7 +1607,7 @@ MODULE_DEVICE_TABLE(of, exynos_g2d_match);
struct platform_driver g2d_driver = {
.probe = g2d_probe,
- .remove = g2d_remove,
+ .remove_new = g2d_remove,
.driver = {
.name = "exynos-drm-g2d",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 964dceb28c1e..f9cf4461036c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1308,15 +1308,13 @@ static int gsc_probe(struct platform_device *pdev)
return ret;
}
-static int gsc_remove(struct platform_device *pdev)
+static void gsc_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &gsc_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int __maybe_unused gsc_runtime_suspend(struct device *dev)
@@ -1421,7 +1419,7 @@ MODULE_DEVICE_TABLE(of, exynos_drm_gsc_of_match);
struct platform_driver gsc_driver = {
.probe = gsc_probe,
- .remove = gsc_remove,
+ .remove_new = gsc_remove,
.driver = {
.name = "exynos-drm-gsc",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 17bab5b1663f..e2920960180f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -442,7 +442,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
return ret;
}
-static int exynos_mic_remove(struct platform_device *pdev)
+static void exynos_mic_remove(struct platform_device *pdev)
{
struct exynos_mic *mic = platform_get_drvdata(pdev);
@@ -450,8 +450,6 @@ static int exynos_mic_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
drm_bridge_remove(&mic->bridge);
-
- return 0;
}
static const struct of_device_id exynos_mic_of_match[] = {
@@ -462,7 +460,7 @@ MODULE_DEVICE_TABLE(of, exynos_mic_of_match);
struct platform_driver mic_driver = {
.probe = exynos_mic_probe,
- .remove = exynos_mic_remove,
+ .remove_new = exynos_mic_remove,
.driver = {
.name = "exynos-mic",
.pm = pm_ptr(&exynos_mic_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 8706f377c349..797424a5d83b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -329,15 +329,13 @@ static int rotator_probe(struct platform_device *pdev)
return ret;
}
-static int rotator_remove(struct platform_device *pdev)
+static void rotator_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &rotator_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int rotator_runtime_suspend(struct device *dev)
@@ -453,7 +451,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(rotator_pm_ops, rotator_runtime_suspend,
struct platform_driver rotator_driver = {
.probe = rotator_probe,
- .remove = rotator_remove,
+ .remove_new = rotator_remove,
.driver = {
.name = "exynos-rotator",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
index 20608e9780ce..b5cbb864c0c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
@@ -539,15 +539,13 @@ static int scaler_probe(struct platform_device *pdev)
return ret;
}
-static int scaler_remove(struct platform_device *pdev)
+static void scaler_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &scaler_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int clk_disable_unprepare_wrapper(struct clk *clk)
@@ -721,7 +719,7 @@ MODULE_DEVICE_TABLE(of, exynos_scaler_match);
struct platform_driver scaler_driver = {
.probe = scaler_probe,
- .remove = scaler_remove,
+ .remove_new = scaler_remove,
.driver = {
.name = "exynos-scaler",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b7c11bdce2c8..b03cc88f873b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2067,7 +2067,7 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int hdmi_remove(struct platform_device *pdev)
+static void hdmi_remove(struct platform_device *pdev)
{
struct hdmi_context *hdata = platform_get_drvdata(pdev);
@@ -2090,8 +2090,6 @@ static int hdmi_remove(struct platform_device *pdev)
put_device(&hdata->ddc_adpt->dev);
mutex_destroy(&hdata->mutex);
-
- return 0;
}
static int __maybe_unused exynos_hdmi_suspend(struct device *dev)
@@ -2123,7 +2121,7 @@ static const struct dev_pm_ops exynos_hdmi_pm_ops = {
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
- .remove = hdmi_remove,
+ .remove_new = hdmi_remove,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8d333db813b7..9aaf62c85cff 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1259,13 +1259,11 @@ static int mixer_probe(struct platform_device *pdev)
return ret;
}
-static int mixer_remove(struct platform_device *pdev)
+static void mixer_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &mixer_component_ops);
-
- return 0;
}
static int __maybe_unused exynos_mixer_suspend(struct device *dev)
@@ -1339,5 +1337,5 @@ struct platform_driver mixer_driver = {
.of_match_table = mixer_match_types,
},
.probe = mixer_probe,
- .remove = mixer_remove,
+ .remove_new = mixer_remove,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Daniel Vetter, Krzysztof Kozlowski, Jingoo Han
Cc: Alim Akhtar, dri-devel, linux-arm-kernel, linux-samsung-soc,
kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the exynos drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
14 files changed, 28 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2867b39fa35e..dd63418a9fd2 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct platform_device *pdev)
return ret;
}
-static int exynos5433_decon_remove(struct platform_device *pdev)
+static void exynos5433_decon_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &decon_component_ops);
-
- return 0;
}
struct platform_driver exynos5433_decon_driver = {
.probe = exynos5433_decon_probe,
- .remove = exynos5433_decon_remove,
+ .remove_new = exynos5433_decon_remove,
.driver = {
.name = "exynos5433-decon",
.pm = pm_ptr(&exynos5433_decon_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3126f735dedc..6fca23e04285 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -766,7 +766,7 @@ static int decon_probe(struct platform_device *pdev)
return ret;
}
-static int decon_remove(struct platform_device *pdev)
+static void decon_remove(struct platform_device *pdev)
{
struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
@@ -775,8 +775,6 @@ static int decon_remove(struct platform_device *pdev)
iounmap(ctx->regs);
component_del(&pdev->dev, &decon_component_ops);
-
- return 0;
}
static int exynos7_decon_suspend(struct device *dev)
@@ -841,7 +839,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops, exynos7_decon_suspend,
struct platform_driver decon_driver = {
.probe = decon_probe,
- .remove = decon_remove,
+ .remove_new = decon_remove,
.driver = {
.name = "exynos-decon",
.pm = pm_ptr(&exynos7_decon_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 3404ec1367fb..ca31bad6c576 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -250,14 +250,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &exynos_dp_ops);
}
-static int exynos_dp_remove(struct platform_device *pdev)
+static void exynos_dp_remove(struct platform_device *pdev)
{
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
component_del(&pdev->dev, &exynos_dp_ops);
analogix_dp_remove(dp->adp);
-
- return 0;
}
static int exynos_dp_suspend(struct device *dev)
@@ -285,7 +283,7 @@ MODULE_DEVICE_TABLE(of, exynos_dp_match);
struct platform_driver dp_driver = {
.probe = exynos_dp_probe,
- .remove = exynos_dp_remove,
+ .remove_new = exynos_dp_remove,
.driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 16c539657f73..67f2e68d6e3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -354,15 +354,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev)
match);
}
-static int exynos_drm_platform_remove(struct platform_device *pdev)
+static void exynos_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &exynos_drm_ops);
- return 0;
}
static struct platform_driver exynos_drm_platform_driver = {
.probe = exynos_drm_platform_probe,
- .remove = exynos_drm_platform_remove,
+ .remove_new = exynos_drm_platform_remove,
.driver = {
.name = "exynos-drm",
.pm = &exynos_drm_pm_ops,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 06d6513ddaae..96aa98945f18 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1744,13 +1744,11 @@ static int exynos_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int exynos_dsi_remove(struct platform_device *pdev)
+static void exynos_dsi_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &exynos_dsi_component_ops);
-
- return 0;
}
static int __maybe_unused exynos_dsi_suspend(struct device *dev)
@@ -1825,7 +1823,7 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
struct platform_driver dsi_driver = {
.probe = exynos_dsi_probe,
- .remove = exynos_dsi_remove,
+ .remove_new = exynos_dsi_remove,
.driver = {
.name = "exynos-dsi",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 8de2714599fc..e81a576de398 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1367,7 +1367,7 @@ static int fimc_probe(struct platform_device *pdev)
return ret;
}
-static int fimc_remove(struct platform_device *pdev)
+static void fimc_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct fimc_context *ctx = get_fimc_context(dev);
@@ -1377,8 +1377,6 @@ static int fimc_remove(struct platform_device *pdev)
pm_runtime_disable(dev);
fimc_put_clocks(ctx);
-
- return 0;
}
static int fimc_runtime_suspend(struct device *dev)
@@ -1410,7 +1408,7 @@ MODULE_DEVICE_TABLE(of, fimc_of_match);
struct platform_driver fimc_driver = {
.probe = fimc_probe,
- .remove = fimc_remove,
+ .remove_new = fimc_remove,
.driver = {
.of_match_table = fimc_of_match,
.name = "exynos-drm-fimc",
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7f4a0be03dd1..cab64bc2b332 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1278,13 +1278,11 @@ static int fimd_probe(struct platform_device *pdev)
return ret;
}
-static int fimd_remove(struct platform_device *pdev)
+static void fimd_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &fimd_component_ops);
-
- return 0;
}
static int exynos_fimd_suspend(struct device *dev)
@@ -1326,7 +1324,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos_fimd_pm_ops, exynos_fimd_suspend,
struct platform_driver fimd_driver = {
.probe = fimd_probe,
- .remove = fimd_remove,
+ .remove_new = fimd_remove,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ec784e58da5c..1f327b06645c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1530,7 +1530,7 @@ static int g2d_probe(struct platform_device *pdev)
return ret;
}
-static int g2d_remove(struct platform_device *pdev)
+static void g2d_remove(struct platform_device *pdev)
{
struct g2d_data *g2d = platform_get_drvdata(pdev);
@@ -1545,8 +1545,6 @@ static int g2d_remove(struct platform_device *pdev)
g2d_fini_cmdlist(g2d);
destroy_workqueue(g2d->g2d_workq);
kmem_cache_destroy(g2d->runqueue_slab);
-
- return 0;
}
static int g2d_suspend(struct device *dev)
@@ -1609,7 +1607,7 @@ MODULE_DEVICE_TABLE(of, exynos_g2d_match);
struct platform_driver g2d_driver = {
.probe = g2d_probe,
- .remove = g2d_remove,
+ .remove_new = g2d_remove,
.driver = {
.name = "exynos-drm-g2d",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 964dceb28c1e..f9cf4461036c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1308,15 +1308,13 @@ static int gsc_probe(struct platform_device *pdev)
return ret;
}
-static int gsc_remove(struct platform_device *pdev)
+static void gsc_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &gsc_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int __maybe_unused gsc_runtime_suspend(struct device *dev)
@@ -1421,7 +1419,7 @@ MODULE_DEVICE_TABLE(of, exynos_drm_gsc_of_match);
struct platform_driver gsc_driver = {
.probe = gsc_probe,
- .remove = gsc_remove,
+ .remove_new = gsc_remove,
.driver = {
.name = "exynos-drm-gsc",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 17bab5b1663f..e2920960180f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -442,7 +442,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
return ret;
}
-static int exynos_mic_remove(struct platform_device *pdev)
+static void exynos_mic_remove(struct platform_device *pdev)
{
struct exynos_mic *mic = platform_get_drvdata(pdev);
@@ -450,8 +450,6 @@ static int exynos_mic_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
drm_bridge_remove(&mic->bridge);
-
- return 0;
}
static const struct of_device_id exynos_mic_of_match[] = {
@@ -462,7 +460,7 @@ MODULE_DEVICE_TABLE(of, exynos_mic_of_match);
struct platform_driver mic_driver = {
.probe = exynos_mic_probe,
- .remove = exynos_mic_remove,
+ .remove_new = exynos_mic_remove,
.driver = {
.name = "exynos-mic",
.pm = pm_ptr(&exynos_mic_pm_ops),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 8706f377c349..797424a5d83b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -329,15 +329,13 @@ static int rotator_probe(struct platform_device *pdev)
return ret;
}
-static int rotator_remove(struct platform_device *pdev)
+static void rotator_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &rotator_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int rotator_runtime_suspend(struct device *dev)
@@ -453,7 +451,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(rotator_pm_ops, rotator_runtime_suspend,
struct platform_driver rotator_driver = {
.probe = rotator_probe,
- .remove = rotator_remove,
+ .remove_new = rotator_remove,
.driver = {
.name = "exynos-rotator",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
index 20608e9780ce..b5cbb864c0c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
@@ -539,15 +539,13 @@ static int scaler_probe(struct platform_device *pdev)
return ret;
}
-static int scaler_remove(struct platform_device *pdev)
+static void scaler_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
component_del(dev, &scaler_component_ops);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
-
- return 0;
}
static int clk_disable_unprepare_wrapper(struct clk *clk)
@@ -721,7 +719,7 @@ MODULE_DEVICE_TABLE(of, exynos_scaler_match);
struct platform_driver scaler_driver = {
.probe = scaler_probe,
- .remove = scaler_remove,
+ .remove_new = scaler_remove,
.driver = {
.name = "exynos-scaler",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index b7c11bdce2c8..b03cc88f873b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2067,7 +2067,7 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int hdmi_remove(struct platform_device *pdev)
+static void hdmi_remove(struct platform_device *pdev)
{
struct hdmi_context *hdata = platform_get_drvdata(pdev);
@@ -2090,8 +2090,6 @@ static int hdmi_remove(struct platform_device *pdev)
put_device(&hdata->ddc_adpt->dev);
mutex_destroy(&hdata->mutex);
-
- return 0;
}
static int __maybe_unused exynos_hdmi_suspend(struct device *dev)
@@ -2123,7 +2121,7 @@ static const struct dev_pm_ops exynos_hdmi_pm_ops = {
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
- .remove = hdmi_remove,
+ .remove_new = hdmi_remove,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8d333db813b7..9aaf62c85cff 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1259,13 +1259,11 @@ static int mixer_probe(struct platform_device *pdev)
return ret;
}
-static int mixer_remove(struct platform_device *pdev)
+static void mixer_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
component_del(&pdev->dev, &mixer_component_ops);
-
- return 0;
}
static int __maybe_unused exynos_mixer_suspend(struct device *dev)
@@ -1339,5 +1337,5 @@ struct platform_driver mixer_driver = {
.of_match_table = mixer_match_types,
},
.probe = mixer_probe,
- .remove = mixer_remove,
+ .remove_new = mixer_remove,
};
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-15 7:32 ` Inki Dae
-1 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:32 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Seung-Woo Kim, Kyungmin Park, David Airlie, Daniel Vetter,
Krzysztof Kozlowski, Jingoo Han, linux-arm-kernel, kernel,
linux-samsung-soc, dri-devel, Alim Akhtar
Hi,
2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the exynos drm drivers from always returning zero in
> the remove callback to the void returning variant.
Could you please update exynos_drm_vidi.c also? Seems you missed.
Thanks,
Inki Dae
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> 14 files changed, 28 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2867b39fa35e..dd63418a9fd2 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int exynos5433_decon_remove(struct platform_device *pdev)
> +static void exynos5433_decon_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &decon_component_ops);
> -
> - return 0;
> }
>
> struct platform_driver exynos5433_decon_driver = {
> .probe = exynos5433_decon_probe,
> - .remove = exynos5433_decon_remove,
> + .remove_new = exynos5433_decon_remove,
> .driver = {
> .name = "exynos5433-decon",
> .pm = pm_ptr(&exynos5433_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 3126f735dedc..6fca23e04285 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -766,7 +766,7 @@ static int decon_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int decon_remove(struct platform_device *pdev)
> +static void decon_remove(struct platform_device *pdev)
> {
> struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
>
> @@ -775,8 +775,6 @@ static int decon_remove(struct platform_device *pdev)
> iounmap(ctx->regs);
>
> component_del(&pdev->dev, &decon_component_ops);
> -
> - return 0;
> }
>
> static int exynos7_decon_suspend(struct device *dev)
> @@ -841,7 +839,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops, exynos7_decon_suspend,
>
> struct platform_driver decon_driver = {
> .probe = decon_probe,
> - .remove = decon_remove,
> + .remove_new = decon_remove,
> .driver = {
> .name = "exynos-decon",
> .pm = pm_ptr(&exynos7_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
> index 3404ec1367fb..ca31bad6c576 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -250,14 +250,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &exynos_dp_ops);
> }
>
> -static int exynos_dp_remove(struct platform_device *pdev)
> +static void exynos_dp_remove(struct platform_device *pdev)
> {
> struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
> component_del(&pdev->dev, &exynos_dp_ops);
> analogix_dp_remove(dp->adp);
> -
> - return 0;
> }
>
> static int exynos_dp_suspend(struct device *dev)
> @@ -285,7 +283,7 @@ MODULE_DEVICE_TABLE(of, exynos_dp_match);
>
> struct platform_driver dp_driver = {
> .probe = exynos_dp_probe,
> - .remove = exynos_dp_remove,
> + .remove_new = exynos_dp_remove,
> .driver = {
> .name = "exynos-dp",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 16c539657f73..67f2e68d6e3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -354,15 +354,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev)
> match);
> }
>
> -static int exynos_drm_platform_remove(struct platform_device *pdev)
> +static void exynos_drm_platform_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &exynos_drm_ops);
> - return 0;
> }
>
> static struct platform_driver exynos_drm_platform_driver = {
> .probe = exynos_drm_platform_probe,
> - .remove = exynos_drm_platform_remove,
> + .remove_new = exynos_drm_platform_remove,
> .driver = {
> .name = "exynos-drm",
> .pm = &exynos_drm_pm_ops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 06d6513ddaae..96aa98945f18 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1744,13 +1744,11 @@ static int exynos_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int exynos_dsi_remove(struct platform_device *pdev)
> +static void exynos_dsi_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &exynos_dsi_component_ops);
> -
> - return 0;
> }
>
> static int __maybe_unused exynos_dsi_suspend(struct device *dev)
> @@ -1825,7 +1823,7 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
>
> struct platform_driver dsi_driver = {
> .probe = exynos_dsi_probe,
> - .remove = exynos_dsi_remove,
> + .remove_new = exynos_dsi_remove,
> .driver = {
> .name = "exynos-dsi",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 8de2714599fc..e81a576de398 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1367,7 +1367,7 @@ static int fimc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int fimc_remove(struct platform_device *pdev)
> +static void fimc_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct fimc_context *ctx = get_fimc_context(dev);
> @@ -1377,8 +1377,6 @@ static int fimc_remove(struct platform_device *pdev)
> pm_runtime_disable(dev);
>
> fimc_put_clocks(ctx);
> -
> - return 0;
> }
>
> static int fimc_runtime_suspend(struct device *dev)
> @@ -1410,7 +1408,7 @@ MODULE_DEVICE_TABLE(of, fimc_of_match);
>
> struct platform_driver fimc_driver = {
> .probe = fimc_probe,
> - .remove = fimc_remove,
> + .remove_new = fimc_remove,
> .driver = {
> .of_match_table = fimc_of_match,
> .name = "exynos-drm-fimc",
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 7f4a0be03dd1..cab64bc2b332 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1278,13 +1278,11 @@ static int fimd_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int fimd_remove(struct platform_device *pdev)
> +static void fimd_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &fimd_component_ops);
> -
> - return 0;
> }
>
> static int exynos_fimd_suspend(struct device *dev)
> @@ -1326,7 +1324,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos_fimd_pm_ops, exynos_fimd_suspend,
>
> struct platform_driver fimd_driver = {
> .probe = fimd_probe,
> - .remove = fimd_remove,
> + .remove_new = fimd_remove,
> .driver = {
> .name = "exynos4-fb",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index ec784e58da5c..1f327b06645c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1530,7 +1530,7 @@ static int g2d_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int g2d_remove(struct platform_device *pdev)
> +static void g2d_remove(struct platform_device *pdev)
> {
> struct g2d_data *g2d = platform_get_drvdata(pdev);
>
> @@ -1545,8 +1545,6 @@ static int g2d_remove(struct platform_device *pdev)
> g2d_fini_cmdlist(g2d);
> destroy_workqueue(g2d->g2d_workq);
> kmem_cache_destroy(g2d->runqueue_slab);
> -
> - return 0;
> }
>
> static int g2d_suspend(struct device *dev)
> @@ -1609,7 +1607,7 @@ MODULE_DEVICE_TABLE(of, exynos_g2d_match);
>
> struct platform_driver g2d_driver = {
> .probe = g2d_probe,
> - .remove = g2d_remove,
> + .remove_new = g2d_remove,
> .driver = {
> .name = "exynos-drm-g2d",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 964dceb28c1e..f9cf4461036c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1308,15 +1308,13 @@ static int gsc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int gsc_remove(struct platform_device *pdev)
> +static void gsc_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> component_del(dev, &gsc_component_ops);
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
> -
> - return 0;
> }
>
> static int __maybe_unused gsc_runtime_suspend(struct device *dev)
> @@ -1421,7 +1419,7 @@ MODULE_DEVICE_TABLE(of, exynos_drm_gsc_of_match);
>
> struct platform_driver gsc_driver = {
> .probe = gsc_probe,
> - .remove = gsc_remove,
> + .remove_new = gsc_remove,
> .driver = {
> .name = "exynos-drm-gsc",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 17bab5b1663f..e2920960180f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -442,7 +442,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int exynos_mic_remove(struct platform_device *pdev)
> +static void exynos_mic_remove(struct platform_device *pdev)
> {
> struct exynos_mic *mic = platform_get_drvdata(pdev);
>
> @@ -450,8 +450,6 @@ static int exynos_mic_remove(struct platform_device *pdev)
> pm_runtime_disable(&pdev->dev);
>
> drm_bridge_remove(&mic->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id exynos_mic_of_match[] = {
> @@ -462,7 +460,7 @@ MODULE_DEVICE_TABLE(of, exynos_mic_of_match);
>
> struct platform_driver mic_driver = {
> .probe = exynos_mic_probe,
> - .remove = exynos_mic_remove,
> + .remove_new = exynos_mic_remove,
> .driver = {
> .name = "exynos-mic",
> .pm = pm_ptr(&exynos_mic_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 8706f377c349..797424a5d83b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -329,15 +329,13 @@ static int rotator_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int rotator_remove(struct platform_device *pdev)
> +static void rotator_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> component_del(dev, &rotator_component_ops);
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
> -
> - return 0;
> }
>
> static int rotator_runtime_suspend(struct device *dev)
> @@ -453,7 +451,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(rotator_pm_ops, rotator_runtime_suspend,
>
> struct platform_driver rotator_driver = {
> .probe = rotator_probe,
> - .remove = rotator_remove,
> + .remove_new = rotator_remove,
> .driver = {
> .name = "exynos-rotator",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> index 20608e9780ce..b5cbb864c0c8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> @@ -539,15 +539,13 @@ static int scaler_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int scaler_remove(struct platform_device *pdev)
> +static void scaler_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> component_del(dev, &scaler_component_ops);
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
> -
> - return 0;
> }
>
> static int clk_disable_unprepare_wrapper(struct clk *clk)
> @@ -721,7 +719,7 @@ MODULE_DEVICE_TABLE(of, exynos_scaler_match);
>
> struct platform_driver scaler_driver = {
> .probe = scaler_probe,
> - .remove = scaler_remove,
> + .remove_new = scaler_remove,
> .driver = {
> .name = "exynos-scaler",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index b7c11bdce2c8..b03cc88f873b 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2067,7 +2067,7 @@ static int hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int hdmi_remove(struct platform_device *pdev)
> +static void hdmi_remove(struct platform_device *pdev)
> {
> struct hdmi_context *hdata = platform_get_drvdata(pdev);
>
> @@ -2090,8 +2090,6 @@ static int hdmi_remove(struct platform_device *pdev)
> put_device(&hdata->ddc_adpt->dev);
>
> mutex_destroy(&hdata->mutex);
> -
> - return 0;
> }
>
> static int __maybe_unused exynos_hdmi_suspend(struct device *dev)
> @@ -2123,7 +2121,7 @@ static const struct dev_pm_ops exynos_hdmi_pm_ops = {
>
> struct platform_driver hdmi_driver = {
> .probe = hdmi_probe,
> - .remove = hdmi_remove,
> + .remove_new = hdmi_remove,
> .driver = {
> .name = "exynos-hdmi",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 8d333db813b7..9aaf62c85cff 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1259,13 +1259,11 @@ static int mixer_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mixer_remove(struct platform_device *pdev)
> +static void mixer_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &mixer_component_ops);
> -
> - return 0;
> }
>
> static int __maybe_unused exynos_mixer_suspend(struct device *dev)
> @@ -1339,5 +1337,5 @@ struct platform_driver mixer_driver = {
> .of_match_table = mixer_match_types,
> },
> .probe = mixer_probe,
> - .remove = mixer_remove,
> + .remove_new = mixer_remove,
> };
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-15 7:32 ` Inki Dae
0 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:32 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-samsung-soc, kernel, Jingoo Han, Seung-Woo Kim,
Krzysztof Kozlowski, dri-devel, Kyungmin Park, Alim Akhtar,
linux-arm-kernel
Hi,
2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the exynos drm drivers from always returning zero in
> the remove callback to the void returning variant.
Could you please update exynos_drm_vidi.c also? Seems you missed.
Thanks,
Inki Dae
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> 14 files changed, 28 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2867b39fa35e..dd63418a9fd2 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -862,18 +862,16 @@ static int exynos5433_decon_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int exynos5433_decon_remove(struct platform_device *pdev)
> +static void exynos5433_decon_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &decon_component_ops);
> -
> - return 0;
> }
>
> struct platform_driver exynos5433_decon_driver = {
> .probe = exynos5433_decon_probe,
> - .remove = exynos5433_decon_remove,
> + .remove_new = exynos5433_decon_remove,
> .driver = {
> .name = "exynos5433-decon",
> .pm = pm_ptr(&exynos5433_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 3126f735dedc..6fca23e04285 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -766,7 +766,7 @@ static int decon_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int decon_remove(struct platform_device *pdev)
> +static void decon_remove(struct platform_device *pdev)
> {
> struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
>
> @@ -775,8 +775,6 @@ static int decon_remove(struct platform_device *pdev)
> iounmap(ctx->regs);
>
> component_del(&pdev->dev, &decon_component_ops);
> -
> - return 0;
> }
>
> static int exynos7_decon_suspend(struct device *dev)
> @@ -841,7 +839,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos7_decon_pm_ops, exynos7_decon_suspend,
>
> struct platform_driver decon_driver = {
> .probe = decon_probe,
> - .remove = decon_remove,
> + .remove_new = decon_remove,
> .driver = {
> .name = "exynos-decon",
> .pm = pm_ptr(&exynos7_decon_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
> index 3404ec1367fb..ca31bad6c576 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -250,14 +250,12 @@ static int exynos_dp_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &exynos_dp_ops);
> }
>
> -static int exynos_dp_remove(struct platform_device *pdev)
> +static void exynos_dp_remove(struct platform_device *pdev)
> {
> struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
> component_del(&pdev->dev, &exynos_dp_ops);
> analogix_dp_remove(dp->adp);
> -
> - return 0;
> }
>
> static int exynos_dp_suspend(struct device *dev)
> @@ -285,7 +283,7 @@ MODULE_DEVICE_TABLE(of, exynos_dp_match);
>
> struct platform_driver dp_driver = {
> .probe = exynos_dp_probe,
> - .remove = exynos_dp_remove,
> + .remove_new = exynos_dp_remove,
> .driver = {
> .name = "exynos-dp",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 16c539657f73..67f2e68d6e3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -354,15 +354,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev)
> match);
> }
>
> -static int exynos_drm_platform_remove(struct platform_device *pdev)
> +static void exynos_drm_platform_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &exynos_drm_ops);
> - return 0;
> }
>
> static struct platform_driver exynos_drm_platform_driver = {
> .probe = exynos_drm_platform_probe,
> - .remove = exynos_drm_platform_remove,
> + .remove_new = exynos_drm_platform_remove,
> .driver = {
> .name = "exynos-drm",
> .pm = &exynos_drm_pm_ops,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 06d6513ddaae..96aa98945f18 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1744,13 +1744,11 @@ static int exynos_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int exynos_dsi_remove(struct platform_device *pdev)
> +static void exynos_dsi_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &exynos_dsi_component_ops);
> -
> - return 0;
> }
>
> static int __maybe_unused exynos_dsi_suspend(struct device *dev)
> @@ -1825,7 +1823,7 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
>
> struct platform_driver dsi_driver = {
> .probe = exynos_dsi_probe,
> - .remove = exynos_dsi_remove,
> + .remove_new = exynos_dsi_remove,
> .driver = {
> .name = "exynos-dsi",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 8de2714599fc..e81a576de398 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1367,7 +1367,7 @@ static int fimc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int fimc_remove(struct platform_device *pdev)
> +static void fimc_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct fimc_context *ctx = get_fimc_context(dev);
> @@ -1377,8 +1377,6 @@ static int fimc_remove(struct platform_device *pdev)
> pm_runtime_disable(dev);
>
> fimc_put_clocks(ctx);
> -
> - return 0;
> }
>
> static int fimc_runtime_suspend(struct device *dev)
> @@ -1410,7 +1408,7 @@ MODULE_DEVICE_TABLE(of, fimc_of_match);
>
> struct platform_driver fimc_driver = {
> .probe = fimc_probe,
> - .remove = fimc_remove,
> + .remove_new = fimc_remove,
> .driver = {
> .of_match_table = fimc_of_match,
> .name = "exynos-drm-fimc",
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 7f4a0be03dd1..cab64bc2b332 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -1278,13 +1278,11 @@ static int fimd_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int fimd_remove(struct platform_device *pdev)
> +static void fimd_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &fimd_component_ops);
> -
> - return 0;
> }
>
> static int exynos_fimd_suspend(struct device *dev)
> @@ -1326,7 +1324,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(exynos_fimd_pm_ops, exynos_fimd_suspend,
>
> struct platform_driver fimd_driver = {
> .probe = fimd_probe,
> - .remove = fimd_remove,
> + .remove_new = fimd_remove,
> .driver = {
> .name = "exynos4-fb",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index ec784e58da5c..1f327b06645c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1530,7 +1530,7 @@ static int g2d_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int g2d_remove(struct platform_device *pdev)
> +static void g2d_remove(struct platform_device *pdev)
> {
> struct g2d_data *g2d = platform_get_drvdata(pdev);
>
> @@ -1545,8 +1545,6 @@ static int g2d_remove(struct platform_device *pdev)
> g2d_fini_cmdlist(g2d);
> destroy_workqueue(g2d->g2d_workq);
> kmem_cache_destroy(g2d->runqueue_slab);
> -
> - return 0;
> }
>
> static int g2d_suspend(struct device *dev)
> @@ -1609,7 +1607,7 @@ MODULE_DEVICE_TABLE(of, exynos_g2d_match);
>
> struct platform_driver g2d_driver = {
> .probe = g2d_probe,
> - .remove = g2d_remove,
> + .remove_new = g2d_remove,
> .driver = {
> .name = "exynos-drm-g2d",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 964dceb28c1e..f9cf4461036c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -1308,15 +1308,13 @@ static int gsc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int gsc_remove(struct platform_device *pdev)
> +static void gsc_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> component_del(dev, &gsc_component_ops);
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
> -
> - return 0;
> }
>
> static int __maybe_unused gsc_runtime_suspend(struct device *dev)
> @@ -1421,7 +1419,7 @@ MODULE_DEVICE_TABLE(of, exynos_drm_gsc_of_match);
>
> struct platform_driver gsc_driver = {
> .probe = gsc_probe,
> - .remove = gsc_remove,
> + .remove_new = gsc_remove,
> .driver = {
> .name = "exynos-drm-gsc",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 17bab5b1663f..e2920960180f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -442,7 +442,7 @@ static int exynos_mic_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int exynos_mic_remove(struct platform_device *pdev)
> +static void exynos_mic_remove(struct platform_device *pdev)
> {
> struct exynos_mic *mic = platform_get_drvdata(pdev);
>
> @@ -450,8 +450,6 @@ static int exynos_mic_remove(struct platform_device *pdev)
> pm_runtime_disable(&pdev->dev);
>
> drm_bridge_remove(&mic->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id exynos_mic_of_match[] = {
> @@ -462,7 +460,7 @@ MODULE_DEVICE_TABLE(of, exynos_mic_of_match);
>
> struct platform_driver mic_driver = {
> .probe = exynos_mic_probe,
> - .remove = exynos_mic_remove,
> + .remove_new = exynos_mic_remove,
> .driver = {
> .name = "exynos-mic",
> .pm = pm_ptr(&exynos_mic_pm_ops),
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 8706f377c349..797424a5d83b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -329,15 +329,13 @@ static int rotator_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int rotator_remove(struct platform_device *pdev)
> +static void rotator_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> component_del(dev, &rotator_component_ops);
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
> -
> - return 0;
> }
>
> static int rotator_runtime_suspend(struct device *dev)
> @@ -453,7 +451,7 @@ static DEFINE_RUNTIME_DEV_PM_OPS(rotator_pm_ops, rotator_runtime_suspend,
>
> struct platform_driver rotator_driver = {
> .probe = rotator_probe,
> - .remove = rotator_remove,
> + .remove_new = rotator_remove,
> .driver = {
> .name = "exynos-rotator",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> index 20608e9780ce..b5cbb864c0c8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
> @@ -539,15 +539,13 @@ static int scaler_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int scaler_remove(struct platform_device *pdev)
> +static void scaler_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> component_del(dev, &scaler_component_ops);
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
> -
> - return 0;
> }
>
> static int clk_disable_unprepare_wrapper(struct clk *clk)
> @@ -721,7 +719,7 @@ MODULE_DEVICE_TABLE(of, exynos_scaler_match);
>
> struct platform_driver scaler_driver = {
> .probe = scaler_probe,
> - .remove = scaler_remove,
> + .remove_new = scaler_remove,
> .driver = {
> .name = "exynos-scaler",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index b7c11bdce2c8..b03cc88f873b 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2067,7 +2067,7 @@ static int hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int hdmi_remove(struct platform_device *pdev)
> +static void hdmi_remove(struct platform_device *pdev)
> {
> struct hdmi_context *hdata = platform_get_drvdata(pdev);
>
> @@ -2090,8 +2090,6 @@ static int hdmi_remove(struct platform_device *pdev)
> put_device(&hdata->ddc_adpt->dev);
>
> mutex_destroy(&hdata->mutex);
> -
> - return 0;
> }
>
> static int __maybe_unused exynos_hdmi_suspend(struct device *dev)
> @@ -2123,7 +2121,7 @@ static const struct dev_pm_ops exynos_hdmi_pm_ops = {
>
> struct platform_driver hdmi_driver = {
> .probe = hdmi_probe,
> - .remove = hdmi_remove,
> + .remove_new = hdmi_remove,
> .driver = {
> .name = "exynos-hdmi",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 8d333db813b7..9aaf62c85cff 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1259,13 +1259,11 @@ static int mixer_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mixer_remove(struct platform_device *pdev)
> +static void mixer_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> component_del(&pdev->dev, &mixer_component_ops);
> -
> - return 0;
> }
>
> static int __maybe_unused exynos_mixer_suspend(struct device *dev)
> @@ -1339,5 +1337,5 @@ struct platform_driver mixer_driver = {
> .of_match_table = mixer_match_types,
> },
> .probe = mixer_probe,
> - .remove = mixer_remove,
> + .remove_new = mixer_remove,
> };
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
2023-05-15 7:32 ` Inki Dae
(?)
@ 2023-05-15 9:16 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:16 UTC (permalink / raw)
To: Inki Dae
Cc: linux-samsung-soc, kernel, Jingoo Han, Seung-Woo Kim,
Krzysztof Kozlowski, dri-devel, Kyungmin Park, Daniel Vetter,
Alim Akhtar, David Airlie, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > The .remove() callback for a platform driver returns an int which makes
> > many driver authors wrongly assume it's possible to do error handling by
> > returning an error code. However the value returned is (mostly) ignored
> > and this typically results in resource leaks. To improve here there is a
> > quest to make the remove callback return void. In the first step of this
> > quest all drivers are converted to .remove_new() which already returns
> > void.
> >
> > Trivially convert the exynos drm drivers from always returning zero in
> > the remove callback to the void returning variant.
>
> Could you please update exynos_drm_vidi.c also? Seems you missed.
This one cannot be trivially converted as vidi_remove() doensn't return
zero in all cases. I didn't grok the details about ctx->raw_edid and
don't know if skipping component_del() is right or not.
If you know the driver, feel free to address this.
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] 261+ messages in thread
* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-15 9:16 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:16 UTC (permalink / raw)
To: Inki Dae
Cc: linux-samsung-soc, Jingoo Han, Seung-Woo Kim, Kyungmin Park,
dri-devel, Krzysztof Kozlowski, kernel, Alim Akhtar,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]
On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > The .remove() callback for a platform driver returns an int which makes
> > many driver authors wrongly assume it's possible to do error handling by
> > returning an error code. However the value returned is (mostly) ignored
> > and this typically results in resource leaks. To improve here there is a
> > quest to make the remove callback return void. In the first step of this
> > quest all drivers are converted to .remove_new() which already returns
> > void.
> >
> > Trivially convert the exynos drm drivers from always returning zero in
> > the remove callback to the void returning variant.
>
> Could you please update exynos_drm_vidi.c also? Seems you missed.
This one cannot be trivially converted as vidi_remove() doensn't return
zero in all cases. I didn't grok the details about ctx->raw_edid and
don't know if skipping component_del() is right or not.
If you know the driver, feel free to address this.
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] 261+ messages in thread
* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-15 9:16 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:16 UTC (permalink / raw)
To: Inki Dae
Cc: linux-samsung-soc, kernel, Jingoo Han, Seung-Woo Kim,
Krzysztof Kozlowski, dri-devel, Kyungmin Park, Daniel Vetter,
Alim Akhtar, David Airlie, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1302 bytes --]
On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > The .remove() callback for a platform driver returns an int which makes
> > many driver authors wrongly assume it's possible to do error handling by
> > returning an error code. However the value returned is (mostly) ignored
> > and this typically results in resource leaks. To improve here there is a
> > quest to make the remove callback return void. In the first step of this
> > quest all drivers are converted to .remove_new() which already returns
> > void.
> >
> > Trivially convert the exynos drm drivers from always returning zero in
> > the remove callback to the void returning variant.
>
> Could you please update exynos_drm_vidi.c also? Seems you missed.
This one cannot be trivially converted as vidi_remove() doensn't return
zero in all cases. I didn't grok the details about ctx->raw_edid and
don't know if skipping component_del() is right or not.
If you know the driver, feel free to address this.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread
* RE: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
2023-05-15 9:16 ` Uwe Kleine-König
(?)
@ 2023-05-19 0:11 ` 대인기
-1 siblings, 0 replies; 261+ messages in thread
From: 대인기 @ 2023-05-19 0:11 UTC (permalink / raw)
To: 'Uwe Kleine-König', 'Inki Dae'
Cc: linux-samsung-soc, 'Jingoo Han', 'Seung-Woo Kim',
'Kyungmin Park', dri-devel, 'Krzysztof Kozlowski',
kernel, 'Alim Akhtar', linux-arm-kernel
Hi,
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Uwe
> Kleine-Konig
> Sent: Monday, May 15, 2023 6:16 PM
> To: Inki Dae <daeinki@gmail.com>
> Cc: linux-samsung-soc@vger.kernel.org; Jingoo Han <jingoohan1@gmail.com>;
> Seung-Woo Kim <sw0312.kim@samsung.com>; Kyungmin Park
> <kyungmin.park@samsung.com>; dri-devel@lists.freedesktop.org; Krzysztof
> Kozlowski <krzysztof.kozlowski@linaro.org>; kernel@pengutronix.de; Alim
> Akhtar <alim.akhtar@samsung.com>; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback
> returning void
>
> On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> > Hi,
> >
> > 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-
> koenig@pengutronix.de>님이 작성:
> > >
> > > The .remove() callback for a platform driver returns an int which makes
> > > many driver authors wrongly assume it's possible to do error handling by
> > > returning an error code. However the value returned is (mostly) ignored
> > > and this typically results in resource leaks. To improve here there is a
> > > quest to make the remove callback return void. In the first step of this
> > > quest all drivers are converted to .remove_new() which already returns
> > > void.
> > >
> > > Trivially convert the exynos drm drivers from always returning zero in
> > > the remove callback to the void returning variant.
> >
> > Could you please update exynos_drm_vidi.c also? Seems you missed.
>
> This one cannot be trivially converted as vidi_remove() doensn't return
> zero in all cases. I didn't grok the details about ctx->raw_edid and
> don't know if skipping component_del() is right or not.
>
> If you know the driver, feel free to address this.
I just posted one patch[1] which drops error return line from vidi_remove() because it's not an error case so it shouldn't return an error.
If you subscribed dri-devel then the patch must be in your mail box. On top of this, you could update it.
[1] [PATCH] drm/exynos: vidi: fix a wrong error return
Thanks,
Inki Dae
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions |
> https://protect2.fireeye.com/v1/url?k=fb0b309c-9a709a0b-fb0abbd3-
> 74fe4860001d-c8cb2d724d092dbd&q=1&e=7188ced8-eb65-487a-8ba9-
> 420177df6b75&u=https%3A%2F%2Fwww.pengutronix.de%2F |
^ permalink raw reply [flat|nested] 261+ messages in thread
* RE: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-19 0:11 ` 대인기
0 siblings, 0 replies; 261+ messages in thread
From: 대인기 @ 2023-05-19 0:11 UTC (permalink / raw)
To: 'Uwe Kleine-König', 'Inki Dae'
Cc: linux-samsung-soc, 'Alim Akhtar', 'Jingoo Han',
'Seung-Woo Kim', 'Krzysztof Kozlowski', dri-devel,
'Kyungmin Park', kernel, linux-arm-kernel
Hi,
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Uwe
> Kleine-Konig
> Sent: Monday, May 15, 2023 6:16 PM
> To: Inki Dae <daeinki@gmail.com>
> Cc: linux-samsung-soc@vger.kernel.org; Jingoo Han <jingoohan1@gmail.com>;
> Seung-Woo Kim <sw0312.kim@samsung.com>; Kyungmin Park
> <kyungmin.park@samsung.com>; dri-devel@lists.freedesktop.org; Krzysztof
> Kozlowski <krzysztof.kozlowski@linaro.org>; kernel@pengutronix.de; Alim
> Akhtar <alim.akhtar@samsung.com>; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback
> returning void
>
> On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> > Hi,
> >
> > 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-
> koenig@pengutronix.de>님이 작성:
> > >
> > > The .remove() callback for a platform driver returns an int which makes
> > > many driver authors wrongly assume it's possible to do error handling by
> > > returning an error code. However the value returned is (mostly) ignored
> > > and this typically results in resource leaks. To improve here there is a
> > > quest to make the remove callback return void. In the first step of this
> > > quest all drivers are converted to .remove_new() which already returns
> > > void.
> > >
> > > Trivially convert the exynos drm drivers from always returning zero in
> > > the remove callback to the void returning variant.
> >
> > Could you please update exynos_drm_vidi.c also? Seems you missed.
>
> This one cannot be trivially converted as vidi_remove() doensn't return
> zero in all cases. I didn't grok the details about ctx->raw_edid and
> don't know if skipping component_del() is right or not.
>
> If you know the driver, feel free to address this.
I just posted one patch[1] which drops error return line from vidi_remove() because it's not an error case so it shouldn't return an error.
If you subscribed dri-devel then the patch must be in your mail box. On top of this, you could update it.
[1] [PATCH] drm/exynos: vidi: fix a wrong error return
Thanks,
Inki Dae
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions |
> https://protect2.fireeye.com/v1/url?k=fb0b309c-9a709a0b-fb0abbd3-
> 74fe4860001d-c8cb2d724d092dbd&q=1&e=7188ced8-eb65-487a-8ba9-
> 420177df6b75&u=https%3A%2F%2Fwww.pengutronix.de%2F |
^ permalink raw reply [flat|nested] 261+ messages in thread
* RE: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-19 0:11 ` 대인기
0 siblings, 0 replies; 261+ messages in thread
From: 대인기 @ 2023-05-19 0:11 UTC (permalink / raw)
To: 'Uwe Kleine-König', 'Inki Dae'
Cc: linux-samsung-soc, 'Jingoo Han', 'Seung-Woo Kim',
'Kyungmin Park', dri-devel, 'Krzysztof Kozlowski',
kernel, 'Alim Akhtar', linux-arm-kernel
Hi,
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of Uwe
> Kleine-Konig
> Sent: Monday, May 15, 2023 6:16 PM
> To: Inki Dae <daeinki@gmail.com>
> Cc: linux-samsung-soc@vger.kernel.org; Jingoo Han <jingoohan1@gmail.com>;
> Seung-Woo Kim <sw0312.kim@samsung.com>; Kyungmin Park
> <kyungmin.park@samsung.com>; dri-devel@lists.freedesktop.org; Krzysztof
> Kozlowski <krzysztof.kozlowski@linaro.org>; kernel@pengutronix.de; Alim
> Akhtar <alim.akhtar@samsung.com>; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback
> returning void
>
> On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> > Hi,
> >
> > 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-
> koenig@pengutronix.de>님이 작성:
> > >
> > > The .remove() callback for a platform driver returns an int which makes
> > > many driver authors wrongly assume it's possible to do error handling by
> > > returning an error code. However the value returned is (mostly) ignored
> > > and this typically results in resource leaks. To improve here there is a
> > > quest to make the remove callback return void. In the first step of this
> > > quest all drivers are converted to .remove_new() which already returns
> > > void.
> > >
> > > Trivially convert the exynos drm drivers from always returning zero in
> > > the remove callback to the void returning variant.
> >
> > Could you please update exynos_drm_vidi.c also? Seems you missed.
>
> This one cannot be trivially converted as vidi_remove() doensn't return
> zero in all cases. I didn't grok the details about ctx->raw_edid and
> don't know if skipping component_del() is right or not.
>
> If you know the driver, feel free to address this.
I just posted one patch[1] which drops error return line from vidi_remove() because it's not an error case so it shouldn't return an error.
If you subscribed dri-devel then the patch must be in your mail box. On top of this, you could update it.
[1] [PATCH] drm/exynos: vidi: fix a wrong error return
Thanks,
Inki Dae
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions |
> https://protect2.fireeye.com/v1/url?k=fb0b309c-9a709a0b-fb0abbd3-
> 74fe4860001d-c8cb2d724d092dbd&q=1&e=7188ced8-eb65-487a-8ba9-
> 420177df6b75&u=https%3A%2F%2Fwww.pengutronix.de%2F |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
2023-05-19 0:11 ` 대인기
(?)
@ 2023-05-19 6:38 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-19 6:38 UTC (permalink / raw)
To: 대인기
Cc: 'Inki Dae', linux-samsung-soc, 'Alim Akhtar',
'Jingoo Han', 'Seung-Woo Kim',
'Krzysztof Kozlowski', dri-devel, 'Kyungmin Park',
kernel, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
Hello Inki Dae,
On Fri, May 19, 2023 at 09:11:58AM +0900, 대인기 wrote:
> > On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> > > 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-
> > koenig@pengutronix.de>님이 작성:
> > > Could you please update exynos_drm_vidi.c also? Seems you missed.
> >
> > This one cannot be trivially converted as vidi_remove() doensn't return
> > zero in all cases. I didn't grok the details about ctx->raw_edid and
> > don't know if skipping component_del() is right or not.
> >
> > If you know the driver, feel free to address this.
>
> I just posted one patch[1] which drops error return line from vidi_remove() because it's not an error case so it shouldn't return an error.
> If you subscribed dri-devel then the patch must be in your mail box. On top of this, you could update it.
I'm not subscribed, but I'll care to convert the driver once your patch
has landed in the mainline.
Thanks for the assist,
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] 261+ messages in thread
* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-19 6:38 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-19 6:38 UTC (permalink / raw)
To: 대인기
Cc: linux-samsung-soc, kernel, 'Jingoo Han',
'Seung-Woo Kim', 'Kyungmin Park', dri-devel,
'Krzysztof Kozlowski', 'Alim Akhtar',
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
Hello Inki Dae,
On Fri, May 19, 2023 at 09:11:58AM +0900, 대인기 wrote:
> > On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> > > 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-
> > koenig@pengutronix.de>님이 작성:
> > > Could you please update exynos_drm_vidi.c also? Seems you missed.
> >
> > This one cannot be trivially converted as vidi_remove() doensn't return
> > zero in all cases. I didn't grok the details about ctx->raw_edid and
> > don't know if skipping component_del() is right or not.
> >
> > If you know the driver, feel free to address this.
>
> I just posted one patch[1] which drops error return line from vidi_remove() because it's not an error case so it shouldn't return an error.
> If you subscribed dri-devel then the patch must be in your mail box. On top of this, you could update it.
I'm not subscribed, but I'll care to convert the driver once your patch
has landed in the mainline.
Thanks for the assist,
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] 261+ messages in thread
* Re: [PATCH 18/53] drm/exynos: Convert to platform remove callback returning void
@ 2023-05-19 6:38 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-19 6:38 UTC (permalink / raw)
To: 대인기
Cc: 'Inki Dae', linux-samsung-soc, 'Alim Akhtar',
'Jingoo Han', 'Seung-Woo Kim',
'Krzysztof Kozlowski', dri-devel, 'Kyungmin Park',
kernel, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]
Hello Inki Dae,
On Fri, May 19, 2023 at 09:11:58AM +0900, 대인기 wrote:
> > On Mon, May 15, 2023 at 04:32:00PM +0900, Inki Dae wrote:
> > > 2023년 5월 8일 (월) 오전 1:27, Uwe Kleine-König <u.kleine-
> > koenig@pengutronix.de>님이 작성:
> > > Could you please update exynos_drm_vidi.c also? Seems you missed.
> >
> > This one cannot be trivially converted as vidi_remove() doensn't return
> > zero in all cases. I didn't grok the details about ctx->raw_edid and
> > don't know if skipping component_del() is right or not.
> >
> > If you know the driver, feel free to address this.
>
> I just posted one patch[1] which drops error return line from vidi_remove() because it's not an error case so it shouldn't return an error.
> If you subscribed dri-devel then the patch must be in your mail box. On top of this, you could update it.
I'm not subscribed, but I'll care to convert the driver once your patch
has landed in the mainline.
Thanks for the assist,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 19/53] drm/fsl-dcu: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (21 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Stefan Agner, Alison Wang, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 8579c7629f5e..532c326b4ec9 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -346,7 +346,7 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
return ret;
}
-static int fsl_dcu_drm_remove(struct platform_device *pdev)
+static void fsl_dcu_drm_remove(struct platform_device *pdev)
{
struct fsl_dcu_drm_device *fsl_dev = platform_get_drvdata(pdev);
@@ -354,13 +354,11 @@ static int fsl_dcu_drm_remove(struct platform_device *pdev)
drm_dev_put(fsl_dev->drm);
clk_disable_unprepare(fsl_dev->clk);
clk_unregister(fsl_dev->pix_clk);
-
- return 0;
}
static struct platform_driver fsl_dcu_drm_platform_driver = {
.probe = fsl_dcu_drm_probe,
- .remove = fsl_dcu_drm_remove,
+ .remove_new = fsl_dcu_drm_remove,
.driver = {
.name = "fsl-dcu",
.pm = &fsl_dcu_drm_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 20/53] drm/hisilicon: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (22 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:41 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Xinliang Liu, Tian Tao, David Airlie, Daniel Vetter,
Ville Syrjälä, Jani Nikula, Sam Ravnborg,
Thomas Zimmermann, Danilo Krummrich, Laurent Pinchart,
Javier Martinez Canillas
Cc: dri-devel, Xinwei Kong, John Stultz, kernel, Yongqin Liu,
Sumit Semwal
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the hisilicon drm drivers from always returning zero
in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index d9978b79828c..566de4658719 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -874,14 +874,12 @@ static int dsi_probe(struct platform_device *pdev)
return 0;
}
-static int dsi_remove(struct platform_device *pdev)
+static void dsi_remove(struct platform_device *pdev)
{
struct dsi_data *data = platform_get_drvdata(pdev);
struct dw_dsi *dsi = &data->dsi;
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
static const struct of_device_id dsi_of_match[] = {
@@ -892,7 +890,7 @@ MODULE_DEVICE_TABLE(of, dsi_of_match);
static struct platform_driver dsi_driver = {
.probe = dsi_probe,
- .remove = dsi_remove,
+ .remove_new = dsi_remove,
.driver = {
.name = "dw-dsi",
.of_match_table = dsi_of_match,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 9c5d49bf40c9..bc2948500311 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -279,10 +279,9 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &kirin_drm_ops, match);
}
-static int kirin_drm_platform_remove(struct platform_device *pdev)
+static void kirin_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &kirin_drm_ops);
- return 0;
}
static const struct of_device_id kirin_drm_dt_ids[] = {
@@ -295,7 +294,7 @@ MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
static struct platform_driver kirin_drm_platform_driver = {
.probe = kirin_drm_platform_probe,
- .remove = kirin_drm_platform_remove,
+ .remove_new = kirin_drm_platform_remove,
.driver = {
.name = "kirin-drm",
.of_match_table = kirin_drm_dt_ids,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 20/53] drm/hisilicon: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 20/53] drm/hisilicon: " Uwe Kleine-König
@ 2023-05-08 2:41 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:41 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: kernel, Yongqin Liu, Thomas Zimmermann, Xinliang Liu,
Sam Ravnborg, Javier Martinez Canillas, dri-devel, John Stultz,
Jani Nikula, Xinwei Kong, Danilo Krummrich, Tian Tao,
Sumit Semwal
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:43PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the hisilicon drm drivers from always returning zero
> in the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> 2 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> index d9978b79828c..566de4658719 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> @@ -874,14 +874,12 @@ static int dsi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int dsi_remove(struct platform_device *pdev)
> +static void dsi_remove(struct platform_device *pdev)
> {
> struct dsi_data *data = platform_get_drvdata(pdev);
> struct dw_dsi *dsi = &data->dsi;
>
> mipi_dsi_host_unregister(&dsi->host);
> -
> - return 0;
> }
>
> static const struct of_device_id dsi_of_match[] = {
> @@ -892,7 +890,7 @@ MODULE_DEVICE_TABLE(of, dsi_of_match);
>
> static struct platform_driver dsi_driver = {
> .probe = dsi_probe,
> - .remove = dsi_remove,
> + .remove_new = dsi_remove,
> .driver = {
> .name = "dw-dsi",
> .of_match_table = dsi_of_match,
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 9c5d49bf40c9..bc2948500311 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -279,10 +279,9 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
> return component_master_add_with_match(dev, &kirin_drm_ops, match);
> }
>
> -static int kirin_drm_platform_remove(struct platform_device *pdev)
> +static void kirin_drm_platform_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &kirin_drm_ops);
> - return 0;
> }
>
> static const struct of_device_id kirin_drm_dt_ids[] = {
> @@ -295,7 +294,7 @@ MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
>
> static struct platform_driver kirin_drm_platform_driver = {
> .probe = kirin_drm_platform_probe,
> - .remove = kirin_drm_platform_remove,
> + .remove_new = kirin_drm_platform_remove,
> .driver = {
> .name = "kirin-drm",
> .of_match_table = kirin_drm_dt_ids,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 21/53] drm/imx/dcss: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Laurentiu Palcu, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: Lucas Stach, Fabio Estevam, NXP Linux Team, dri-devel,
linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-drv.c b/drivers/gpu/drm/imx/dcss/dcss-drv.c
index 4f2291610139..3400ec23cae5 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-drv.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-drv.c
@@ -79,7 +79,7 @@ static int dcss_drv_platform_probe(struct platform_device *pdev)
return err;
}
-static int dcss_drv_platform_remove(struct platform_device *pdev)
+static void dcss_drv_platform_remove(struct platform_device *pdev)
{
struct dcss_drv *mdrv = dev_get_drvdata(&pdev->dev);
@@ -87,8 +87,6 @@ static int dcss_drv_platform_remove(struct platform_device *pdev)
dcss_dev_destroy(mdrv->dcss);
kfree(mdrv);
-
- return 0;
}
static struct dcss_type_data dcss_types[] = {
@@ -112,7 +110,7 @@ MODULE_DEVICE_TABLE(of, dcss_of_match);
static struct platform_driver dcss_platform_driver = {
.probe = dcss_drv_platform_probe,
- .remove = dcss_drv_platform_remove,
+ .remove_new = dcss_drv_platform_remove,
.driver = {
.name = "imx-dcss",
.of_match_table = dcss_of_match,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 21/53] drm/imx/dcss: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Laurentiu Palcu, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: dri-devel, NXP Linux Team, kernel, linux-arm-kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-drv.c b/drivers/gpu/drm/imx/dcss/dcss-drv.c
index 4f2291610139..3400ec23cae5 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-drv.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-drv.c
@@ -79,7 +79,7 @@ static int dcss_drv_platform_probe(struct platform_device *pdev)
return err;
}
-static int dcss_drv_platform_remove(struct platform_device *pdev)
+static void dcss_drv_platform_remove(struct platform_device *pdev)
{
struct dcss_drv *mdrv = dev_get_drvdata(&pdev->dev);
@@ -87,8 +87,6 @@ static int dcss_drv_platform_remove(struct platform_device *pdev)
dcss_dev_destroy(mdrv->dcss);
kfree(mdrv);
-
- return 0;
}
static struct dcss_type_data dcss_types[] = {
@@ -112,7 +110,7 @@ MODULE_DEVICE_TABLE(of, dcss_of_match);
static struct platform_driver dcss_platform_driver = {
.probe = dcss_drv_platform_probe,
- .remove = dcss_drv_platform_remove,
+ .remove_new = dcss_drv_platform_remove,
.driver = {
.name = "imx-dcss",
.of_match_table = dcss_of_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread
* [PATCH 22/53] drm/imx/ipuv3: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Philipp Zabel, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: Fabio Estevam, NXP Linux Team, dri-devel, linux-arm-kernel,
kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the ipuv3 imx drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
6 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c b/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c
index a2277a0d6d06..0006ea52b83c 100644
--- a/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c
@@ -255,19 +255,17 @@ static int dw_hdmi_imx_probe(struct platform_device *pdev)
return ret;
}
-static int dw_hdmi_imx_remove(struct platform_device *pdev)
+static void dw_hdmi_imx_remove(struct platform_device *pdev)
{
struct imx_hdmi *hdmi = platform_get_drvdata(pdev);
component_del(&pdev->dev, &dw_hdmi_imx_ops);
dw_hdmi_remove(hdmi->hdmi);
-
- return 0;
}
static struct platform_driver dw_hdmi_imx_platform_driver = {
.probe = dw_hdmi_imx_probe,
- .remove = dw_hdmi_imx_remove,
+ .remove_new = dw_hdmi_imx_remove,
.driver = {
.name = "dwhdmi-imx",
.of_match_table = dw_hdmi_imx_dt_ids,
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index e060fa6cbcb9..b17a9dd42565 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -292,10 +292,9 @@ static int imx_drm_platform_probe(struct platform_device *pdev)
return ret;
}
-static int imx_drm_platform_remove(struct platform_device *pdev)
+static void imx_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &imx_drm_ops);
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -324,7 +323,7 @@ MODULE_DEVICE_TABLE(of, imx_drm_dt_ids);
static struct platform_driver imx_drm_pdrv = {
.probe = imx_drm_platform_probe,
- .remove = imx_drm_platform_remove,
+ .remove_new = imx_drm_platform_remove,
.driver = {
.name = "imx-drm",
.pm = &imx_drm_pm_ops,
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
index c45fc8f4744d..989eca32d325 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
@@ -737,7 +737,7 @@ static int imx_ldb_probe(struct platform_device *pdev)
return ret;
}
-static int imx_ldb_remove(struct platform_device *pdev)
+static void imx_ldb_remove(struct platform_device *pdev)
{
struct imx_ldb *imx_ldb = platform_get_drvdata(pdev);
int i;
@@ -750,12 +750,11 @@ static int imx_ldb_remove(struct platform_device *pdev)
}
component_del(&pdev->dev, &imx_ldb_ops);
- return 0;
}
static struct platform_driver imx_ldb_driver = {
.probe = imx_ldb_probe,
- .remove = imx_ldb_remove,
+ .remove_new = imx_ldb_remove,
.driver = {
.of_match_table = imx_ldb_dt_ids,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-tve.c b/drivers/gpu/drm/imx/ipuv3/imx-tve.c
index d6832f506322..b49bddb85535 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-tve.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-tve.c
@@ -645,10 +645,9 @@ static int imx_tve_probe(struct platform_device *pdev)
return component_add(dev, &imx_tve_ops);
}
-static int imx_tve_remove(struct platform_device *pdev)
+static void imx_tve_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &imx_tve_ops);
- return 0;
}
static const struct of_device_id imx_tve_dt_ids[] = {
@@ -659,7 +658,7 @@ MODULE_DEVICE_TABLE(of, imx_tve_dt_ids);
static struct platform_driver imx_tve_driver = {
.probe = imx_tve_probe,
- .remove = imx_tve_remove,
+ .remove_new = imx_tve_remove,
.driver = {
.of_match_table = imx_tve_dt_ids,
.name = "imx-tve",
diff --git a/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
index 5f26090b0c98..8819e40d5e6e 100644
--- a/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
@@ -441,10 +441,9 @@ static int ipu_drm_probe(struct platform_device *pdev)
return component_add(dev, &ipu_crtc_ops);
}
-static int ipu_drm_remove(struct platform_device *pdev)
+static void ipu_drm_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &ipu_crtc_ops);
- return 0;
}
struct platform_driver ipu_drm_driver = {
@@ -452,5 +451,5 @@ struct platform_driver ipu_drm_driver = {
.name = "imx-ipuv3-crtc",
},
.probe = ipu_drm_probe,
- .remove = ipu_drm_remove,
+ .remove_new = ipu_drm_remove,
};
diff --git a/drivers/gpu/drm/imx/ipuv3/parallel-display.c b/drivers/gpu/drm/imx/ipuv3/parallel-display.c
index 0fa0b590830b..70349739dd89 100644
--- a/drivers/gpu/drm/imx/ipuv3/parallel-display.c
+++ b/drivers/gpu/drm/imx/ipuv3/parallel-display.c
@@ -353,11 +353,9 @@ static int imx_pd_probe(struct platform_device *pdev)
return component_add(dev, &imx_pd_ops);
}
-static int imx_pd_remove(struct platform_device *pdev)
+static void imx_pd_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &imx_pd_ops);
-
- return 0;
}
static const struct of_device_id imx_pd_dt_ids[] = {
@@ -368,7 +366,7 @@ MODULE_DEVICE_TABLE(of, imx_pd_dt_ids);
static struct platform_driver imx_pd_driver = {
.probe = imx_pd_probe,
- .remove = imx_pd_remove,
+ .remove_new = imx_pd_remove,
.driver = {
.of_match_table = imx_pd_dt_ids,
.name = "imx-parallel-display",
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 22/53] drm/imx/ipuv3: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Philipp Zabel, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: linux-arm-kernel, kernel, NXP Linux Team, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the ipuv3 imx drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
6 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c b/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c
index a2277a0d6d06..0006ea52b83c 100644
--- a/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c
@@ -255,19 +255,17 @@ static int dw_hdmi_imx_probe(struct platform_device *pdev)
return ret;
}
-static int dw_hdmi_imx_remove(struct platform_device *pdev)
+static void dw_hdmi_imx_remove(struct platform_device *pdev)
{
struct imx_hdmi *hdmi = platform_get_drvdata(pdev);
component_del(&pdev->dev, &dw_hdmi_imx_ops);
dw_hdmi_remove(hdmi->hdmi);
-
- return 0;
}
static struct platform_driver dw_hdmi_imx_platform_driver = {
.probe = dw_hdmi_imx_probe,
- .remove = dw_hdmi_imx_remove,
+ .remove_new = dw_hdmi_imx_remove,
.driver = {
.name = "dwhdmi-imx",
.of_match_table = dw_hdmi_imx_dt_ids,
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
index e060fa6cbcb9..b17a9dd42565 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-drm-core.c
@@ -292,10 +292,9 @@ static int imx_drm_platform_probe(struct platform_device *pdev)
return ret;
}
-static int imx_drm_platform_remove(struct platform_device *pdev)
+static void imx_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &imx_drm_ops);
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -324,7 +323,7 @@ MODULE_DEVICE_TABLE(of, imx_drm_dt_ids);
static struct platform_driver imx_drm_pdrv = {
.probe = imx_drm_platform_probe,
- .remove = imx_drm_platform_remove,
+ .remove_new = imx_drm_platform_remove,
.driver = {
.name = "imx-drm",
.pm = &imx_drm_pm_ops,
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
index c45fc8f4744d..989eca32d325 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-ldb.c
@@ -737,7 +737,7 @@ static int imx_ldb_probe(struct platform_device *pdev)
return ret;
}
-static int imx_ldb_remove(struct platform_device *pdev)
+static void imx_ldb_remove(struct platform_device *pdev)
{
struct imx_ldb *imx_ldb = platform_get_drvdata(pdev);
int i;
@@ -750,12 +750,11 @@ static int imx_ldb_remove(struct platform_device *pdev)
}
component_del(&pdev->dev, &imx_ldb_ops);
- return 0;
}
static struct platform_driver imx_ldb_driver = {
.probe = imx_ldb_probe,
- .remove = imx_ldb_remove,
+ .remove_new = imx_ldb_remove,
.driver = {
.of_match_table = imx_ldb_dt_ids,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/imx/ipuv3/imx-tve.c b/drivers/gpu/drm/imx/ipuv3/imx-tve.c
index d6832f506322..b49bddb85535 100644
--- a/drivers/gpu/drm/imx/ipuv3/imx-tve.c
+++ b/drivers/gpu/drm/imx/ipuv3/imx-tve.c
@@ -645,10 +645,9 @@ static int imx_tve_probe(struct platform_device *pdev)
return component_add(dev, &imx_tve_ops);
}
-static int imx_tve_remove(struct platform_device *pdev)
+static void imx_tve_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &imx_tve_ops);
- return 0;
}
static const struct of_device_id imx_tve_dt_ids[] = {
@@ -659,7 +658,7 @@ MODULE_DEVICE_TABLE(of, imx_tve_dt_ids);
static struct platform_driver imx_tve_driver = {
.probe = imx_tve_probe,
- .remove = imx_tve_remove,
+ .remove_new = imx_tve_remove,
.driver = {
.of_match_table = imx_tve_dt_ids,
.name = "imx-tve",
diff --git a/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
index 5f26090b0c98..8819e40d5e6e 100644
--- a/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
@@ -441,10 +441,9 @@ static int ipu_drm_probe(struct platform_device *pdev)
return component_add(dev, &ipu_crtc_ops);
}
-static int ipu_drm_remove(struct platform_device *pdev)
+static void ipu_drm_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &ipu_crtc_ops);
- return 0;
}
struct platform_driver ipu_drm_driver = {
@@ -452,5 +451,5 @@ struct platform_driver ipu_drm_driver = {
.name = "imx-ipuv3-crtc",
},
.probe = ipu_drm_probe,
- .remove = ipu_drm_remove,
+ .remove_new = ipu_drm_remove,
};
diff --git a/drivers/gpu/drm/imx/ipuv3/parallel-display.c b/drivers/gpu/drm/imx/ipuv3/parallel-display.c
index 0fa0b590830b..70349739dd89 100644
--- a/drivers/gpu/drm/imx/ipuv3/parallel-display.c
+++ b/drivers/gpu/drm/imx/ipuv3/parallel-display.c
@@ -353,11 +353,9 @@ static int imx_pd_probe(struct platform_device *pdev)
return component_add(dev, &imx_pd_ops);
}
-static int imx_pd_remove(struct platform_device *pdev)
+static void imx_pd_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &imx_pd_ops);
-
- return 0;
}
static const struct of_device_id imx_pd_dt_ids[] = {
@@ -368,7 +366,7 @@ MODULE_DEVICE_TABLE(of, imx_pd_dt_ids);
static struct platform_driver imx_pd_driver = {
.probe = imx_pd_probe,
- .remove = imx_pd_remove,
+ .remove_new = imx_pd_remove,
.driver = {
.of_match_table = imx_pd_dt_ids,
.name = "imx-parallel-display",
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 22/53] drm/imx/ipuv3: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-08 7:10 ` Philipp Zabel
-1 siblings, 0 replies; 261+ messages in thread
From: Philipp Zabel @ 2023-05-08 7:10 UTC (permalink / raw)
To: Uwe Kleine-König, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: linux-arm-kernel, kernel, NXP Linux Team, dri-devel
On So, 2023-05-07 at 18:25 +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the ipuv3 imx drivers from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 23/53] drm/ingenic: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Paul Cercueil, David Airlie, Daniel Vetter; +Cc: linux-mips, dri-devel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the ingenic drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 5ec75e9ba499..4a22b7465080 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1449,7 +1449,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &ingenic_master_ops, match);
}
-static int ingenic_drm_remove(struct platform_device *pdev)
+static void ingenic_drm_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1457,8 +1457,6 @@ static int ingenic_drm_remove(struct platform_device *pdev)
ingenic_drm_unbind(dev);
else
component_master_del(dev, &ingenic_master_ops);
-
- return 0;
}
static int ingenic_drm_suspend(struct device *dev)
@@ -1611,7 +1609,7 @@ static struct platform_driver ingenic_drm_driver = {
.of_match_table = of_match_ptr(ingenic_drm_of_match),
},
.probe = ingenic_drm_probe,
- .remove = ingenic_drm_remove,
+ .remove_new = ingenic_drm_remove,
};
static int ingenic_drm_init(void)
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index 7a43505011a5..fc0d8512d217 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -922,10 +922,9 @@ static int ingenic_ipu_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &ingenic_ipu_ops);
}
-static int ingenic_ipu_remove(struct platform_device *pdev)
+static void ingenic_ipu_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &ingenic_ipu_ops);
- return 0;
}
static const u32 jz4725b_ipu_formats[] = {
@@ -992,7 +991,7 @@ static struct platform_driver ingenic_ipu_driver = {
.of_match_table = ingenic_ipu_of_match,
},
.probe = ingenic_ipu_probe,
- .remove = ingenic_ipu_remove,
+ .remove_new = ingenic_ipu_remove,
};
struct platform_driver *ingenic_ipu_driver_ptr = &ingenic_ipu_driver;
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 23/53] drm/ingenic: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Paul Cercueil, David Airlie, Daniel Vetter; +Cc: kernel, linux-mips, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the ingenic drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 5ec75e9ba499..4a22b7465080 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1449,7 +1449,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &ingenic_master_ops, match);
}
-static int ingenic_drm_remove(struct platform_device *pdev)
+static void ingenic_drm_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1457,8 +1457,6 @@ static int ingenic_drm_remove(struct platform_device *pdev)
ingenic_drm_unbind(dev);
else
component_master_del(dev, &ingenic_master_ops);
-
- return 0;
}
static int ingenic_drm_suspend(struct device *dev)
@@ -1611,7 +1609,7 @@ static struct platform_driver ingenic_drm_driver = {
.of_match_table = of_match_ptr(ingenic_drm_of_match),
},
.probe = ingenic_drm_probe,
- .remove = ingenic_drm_remove,
+ .remove_new = ingenic_drm_remove,
};
static int ingenic_drm_init(void)
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index 7a43505011a5..fc0d8512d217 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -922,10 +922,9 @@ static int ingenic_ipu_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &ingenic_ipu_ops);
}
-static int ingenic_ipu_remove(struct platform_device *pdev)
+static void ingenic_ipu_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &ingenic_ipu_ops);
- return 0;
}
static const u32 jz4725b_ipu_formats[] = {
@@ -992,7 +991,7 @@ static struct platform_driver ingenic_ipu_driver = {
.of_match_table = ingenic_ipu_of_match,
},
.probe = ingenic_ipu_probe,
- .remove = ingenic_ipu_remove,
+ .remove_new = ingenic_ipu_remove,
};
struct platform_driver *ingenic_ipu_driver_ptr = &ingenic_ipu_driver;
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 23/53] drm/ingenic: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 18:46 ` Paul Cercueil
-1 siblings, 0 replies; 261+ messages in thread
From: Paul Cercueil @ 2023-05-07 18:46 UTC (permalink / raw)
To: Uwe Kleine-König, David Airlie, Daniel Vetter
Cc: linux-mips, dri-devel, kernel
Hi,
Le dimanche 07 mai 2023 à 18:25 +0200, Uwe Kleine-König a écrit :
> The .remove() callback for a platform driver returns an int which
> makes
> many driver authors wrongly assume it's possible to do error handling
> by
> returning an error code. However the value returned is (mostly)
> ignored
> and this typically results in resource leaks. To improve here there
> is a
> quest to make the remove callback return void. In the first step of
> this
> quest all drivers are converted to .remove_new() which already
> returns
> void.
>
> Trivially convert the ingenic drm drivers from always returning zero
> in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Cheers,
-Paul
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> 2 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 5ec75e9ba499..4a22b7465080 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -1449,7 +1449,7 @@ static int ingenic_drm_probe(struct
> platform_device *pdev)
> return component_master_add_with_match(dev,
> &ingenic_master_ops, match);
> }
>
> -static int ingenic_drm_remove(struct platform_device *pdev)
> +static void ingenic_drm_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> @@ -1457,8 +1457,6 @@ static int ingenic_drm_remove(struct
> platform_device *pdev)
> ingenic_drm_unbind(dev);
> else
> component_master_del(dev, &ingenic_master_ops);
> -
> - return 0;
> }
>
> static int ingenic_drm_suspend(struct device *dev)
> @@ -1611,7 +1609,7 @@ static struct platform_driver
> ingenic_drm_driver = {
> .of_match_table = of_match_ptr(ingenic_drm_of_match),
> },
> .probe = ingenic_drm_probe,
> - .remove = ingenic_drm_remove,
> + .remove_new = ingenic_drm_remove,
> };
>
> static int ingenic_drm_init(void)
> diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> index 7a43505011a5..fc0d8512d217 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> @@ -922,10 +922,9 @@ static int ingenic_ipu_probe(struct
> platform_device *pdev)
> return component_add(&pdev->dev, &ingenic_ipu_ops);
> }
>
> -static int ingenic_ipu_remove(struct platform_device *pdev)
> +static void ingenic_ipu_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &ingenic_ipu_ops);
> - return 0;
> }
>
> static const u32 jz4725b_ipu_formats[] = {
> @@ -992,7 +991,7 @@ static struct platform_driver ingenic_ipu_driver
> = {
> .of_match_table = ingenic_ipu_of_match,
> },
> .probe = ingenic_ipu_probe,
> - .remove = ingenic_ipu_remove,
> + .remove_new = ingenic_ipu_remove,
> };
>
> struct platform_driver *ingenic_ipu_driver_ptr =
> &ingenic_ipu_driver;
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 23/53] drm/ingenic: Convert to platform remove callback returning void
@ 2023-05-07 18:46 ` Paul Cercueil
0 siblings, 0 replies; 261+ messages in thread
From: Paul Cercueil @ 2023-05-07 18:46 UTC (permalink / raw)
To: Uwe Kleine-König, David Airlie, Daniel Vetter
Cc: kernel, linux-mips, dri-devel
Hi,
Le dimanche 07 mai 2023 à 18:25 +0200, Uwe Kleine-König a écrit :
> The .remove() callback for a platform driver returns an int which
> makes
> many driver authors wrongly assume it's possible to do error handling
> by
> returning an error code. However the value returned is (mostly)
> ignored
> and this typically results in resource leaks. To improve here there
> is a
> quest to make the remove callback return void. In the first step of
> this
> quest all drivers are converted to .remove_new() which already
> returns
> void.
>
> Trivially convert the ingenic drm drivers from always returning zero
> in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Cheers,
-Paul
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> 2 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 5ec75e9ba499..4a22b7465080 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -1449,7 +1449,7 @@ static int ingenic_drm_probe(struct
> platform_device *pdev)
> return component_master_add_with_match(dev,
> &ingenic_master_ops, match);
> }
>
> -static int ingenic_drm_remove(struct platform_device *pdev)
> +static void ingenic_drm_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> @@ -1457,8 +1457,6 @@ static int ingenic_drm_remove(struct
> platform_device *pdev)
> ingenic_drm_unbind(dev);
> else
> component_master_del(dev, &ingenic_master_ops);
> -
> - return 0;
> }
>
> static int ingenic_drm_suspend(struct device *dev)
> @@ -1611,7 +1609,7 @@ static struct platform_driver
> ingenic_drm_driver = {
> .of_match_table = of_match_ptr(ingenic_drm_of_match),
> },
> .probe = ingenic_drm_probe,
> - .remove = ingenic_drm_remove,
> + .remove_new = ingenic_drm_remove,
> };
>
> static int ingenic_drm_init(void)
> diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> index 7a43505011a5..fc0d8512d217 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
> @@ -922,10 +922,9 @@ static int ingenic_ipu_probe(struct
> platform_device *pdev)
> return component_add(&pdev->dev, &ingenic_ipu_ops);
> }
>
> -static int ingenic_ipu_remove(struct platform_device *pdev)
> +static void ingenic_ipu_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &ingenic_ipu_ops);
> - return 0;
> }
>
> static const u32 jz4725b_ipu_formats[] = {
> @@ -992,7 +991,7 @@ static struct platform_driver ingenic_ipu_driver
> = {
> .of_match_table = ingenic_ipu_of_match,
> },
> .probe = ingenic_ipu_probe,
> - .remove = ingenic_ipu_remove,
> + .remove_new = ingenic_ipu_remove,
> };
>
> struct platform_driver *ingenic_ipu_driver_ptr =
> &ingenic_ipu_driver;
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 24/53] drm/kmb: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (26 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Anitha Chrisanthus, Edmund Dea, David Airlie, Daniel Vetter
Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_drv.c b/drivers/gpu/drm/kmb/kmb_drv.c
index d29c678f6c91..4b101b9277e1 100644
--- a/drivers/gpu/drm/kmb/kmb_drv.c
+++ b/drivers/gpu/drm/kmb/kmb_drv.c
@@ -448,7 +448,7 @@ static const struct drm_driver kmb_driver = {
.minor = DRIVER_MINOR,
};
-static int kmb_remove(struct platform_device *pdev)
+static void kmb_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct drm_device *drm = dev_get_drvdata(dev);
@@ -473,7 +473,6 @@ static int kmb_remove(struct platform_device *pdev)
/* Unregister DSI host */
kmb_dsi_host_unregister(kmb->kmb_dsi);
drm_atomic_helper_shutdown(drm);
- return 0;
}
static int kmb_probe(struct platform_device *pdev)
@@ -621,7 +620,7 @@ static SIMPLE_DEV_PM_OPS(kmb_pm_ops, kmb_pm_suspend, kmb_pm_resume);
static struct platform_driver kmb_platform_driver = {
.probe = kmb_probe,
- .remove = kmb_remove,
+ .remove_new = kmb_remove,
.driver = {
.name = "kmb-drm",
.pm = &kmb_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 25/53] drm/lima: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (27 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Qiang Yu, David Airlie, Daniel Vetter; +Cc: kernel, lima, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/lima/lima_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index 7b8d7178d09a..a272eace8f25 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -439,7 +439,7 @@ static int lima_pdev_probe(struct platform_device *pdev)
return err;
}
-static int lima_pdev_remove(struct platform_device *pdev)
+static void lima_pdev_remove(struct platform_device *pdev)
{
struct lima_device *ldev = platform_get_drvdata(pdev);
struct drm_device *ddev = ldev->ddev;
@@ -457,7 +457,6 @@ static int lima_pdev_remove(struct platform_device *pdev)
drm_dev_put(ddev);
lima_sched_slab_fini();
- return 0;
}
static const struct of_device_id dt_match[] = {
@@ -474,7 +473,7 @@ static const struct dev_pm_ops lima_pm_ops = {
static struct platform_driver lima_platform_driver = {
.probe = lima_pdev_probe,
- .remove = lima_pdev_remove,
+ .remove_new = lima_pdev_remove,
.driver = {
.name = "lima",
.pm = &lima_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 26/53] drm/logicvc: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (28 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Paul Kocialkowski, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c
index 2fb23697740a..b97bc254dbfa 100644
--- a/drivers/gpu/drm/logicvc/logicvc_drm.c
+++ b/drivers/gpu/drm/logicvc/logicvc_drm.c
@@ -466,7 +466,7 @@ static int logicvc_drm_probe(struct platform_device *pdev)
return ret;
}
-static int logicvc_drm_remove(struct platform_device *pdev)
+static void logicvc_drm_remove(struct platform_device *pdev)
{
struct logicvc_drm *logicvc = platform_get_drvdata(pdev);
struct device *dev = &pdev->dev;
@@ -480,8 +480,6 @@ static int logicvc_drm_remove(struct platform_device *pdev)
logicvc_clocks_unprepare(logicvc);
of_reserved_mem_device_release(dev);
-
- return 0;
}
static const struct of_device_id logicvc_drm_of_table[] = {
@@ -493,7 +491,7 @@ MODULE_DEVICE_TABLE(of, logicvc_drm_of_table);
static struct platform_driver logicvc_drm_platform_driver = {
.probe = logicvc_drm_probe,
- .remove = logicvc_drm_remove,
+ .remove_new = logicvc_drm_remove,
.driver = {
.name = "logicvc-drm",
.of_match_table = logicvc_drm_of_table,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 27/53] drm/mcde: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (29 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 6:13 ` Linus Walleij
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Linus Walleij, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the mcde drm driver from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 4aedb050d2a5..458672d0fb7a 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -448,7 +448,7 @@ static int mcde_probe(struct platform_device *pdev)
}
-static int mcde_remove(struct platform_device *pdev)
+static void mcde_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
struct mcde *mcde = to_mcde(drm);
@@ -457,8 +457,6 @@ static int mcde_remove(struct platform_device *pdev)
clk_disable_unprepare(mcde->mcde_clk);
regulator_disable(mcde->vana);
regulator_disable(mcde->epod);
-
- return 0;
}
static const struct of_device_id mcde_of_match[] = {
@@ -474,7 +472,7 @@ static struct platform_driver mcde_driver = {
.of_match_table = of_match_ptr(mcde_of_match),
},
.probe = mcde_probe,
- .remove = mcde_remove,
+ .remove_new = mcde_remove,
};
static struct platform_driver *const component_drivers[] = {
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 9f9ac8699310..db82b38600b2 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -1208,14 +1208,12 @@ static int mcde_dsi_probe(struct platform_device *pdev)
return component_add(dev, &mcde_dsi_component_ops);
}
-static int mcde_dsi_remove(struct platform_device *pdev)
+static void mcde_dsi_remove(struct platform_device *pdev)
{
struct mcde_dsi *d = platform_get_drvdata(pdev);
component_del(&pdev->dev, &mcde_dsi_component_ops);
mipi_dsi_host_unregister(&d->dsi_host);
-
- return 0;
}
static const struct of_device_id mcde_dsi_of_match[] = {
@@ -1231,5 +1229,5 @@ struct platform_driver mcde_dsi_driver = {
.of_match_table = of_match_ptr(mcde_dsi_of_match),
},
.probe = mcde_dsi_probe,
- .remove = mcde_dsi_remove,
+ .remove_new = mcde_dsi_remove,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 27/53] drm/mcde: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 27/53] drm/mcde: " Uwe Kleine-König
@ 2023-05-08 6:13 ` Linus Walleij
0 siblings, 0 replies; 261+ messages in thread
From: Linus Walleij @ 2023-05-08 6:13 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: kernel, dri-devel
On Sun, May 7, 2023 at 6:26 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the mcde drm driver from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 28/53] drm/mediatek: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: AngeloGioacchino Del Regno, dri-devel, linux-mediatek, kernel,
linux-arm-kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c
index b640bc0559e7..f47f417d8ba6 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -235,13 +235,12 @@ static int mtk_cec_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_cec_remove(struct platform_device *pdev)
+static void mtk_cec_remove(struct platform_device *pdev)
{
struct mtk_cec *cec = platform_get_drvdata(pdev);
mtk_cec_htplg_irq_disable(cec);
clk_disable_unprepare(cec->clk);
- return 0;
}
static const struct of_device_id mtk_cec_of_ids[] = {
@@ -252,7 +251,7 @@ MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
struct platform_driver mtk_cec_driver = {
.probe = mtk_cec_probe,
- .remove = mtk_cec_remove,
+ .remove_new = mtk_cec_remove,
.driver = {
.name = "mediatek-cec",
.of_match_table = mtk_cec_of_ids,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 28/53] drm/mediatek: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: linux-arm-kernel, linux-mediatek, kernel, dri-devel,
AngeloGioacchino Del Regno
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c
index b640bc0559e7..f47f417d8ba6 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -235,13 +235,12 @@ static int mtk_cec_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_cec_remove(struct platform_device *pdev)
+static void mtk_cec_remove(struct platform_device *pdev)
{
struct mtk_cec *cec = platform_get_drvdata(pdev);
mtk_cec_htplg_irq_disable(cec);
clk_disable_unprepare(cec->clk);
- return 0;
}
static const struct of_device_id mtk_cec_of_ids[] = {
@@ -252,7 +251,7 @@ MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
struct platform_driver mtk_cec_driver = {
.probe = mtk_cec_probe,
- .remove = mtk_cec_remove,
+ .remove_new = mtk_cec_remove,
.driver = {
.name = "mediatek-cec",
.of_match_table = mtk_cec_of_ids,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 28/53] drm/mediatek: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: AngeloGioacchino Del Regno, dri-devel, linux-mediatek, kernel,
linux-arm-kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c
index b640bc0559e7..f47f417d8ba6 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -235,13 +235,12 @@ static int mtk_cec_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_cec_remove(struct platform_device *pdev)
+static void mtk_cec_remove(struct platform_device *pdev)
{
struct mtk_cec *cec = platform_get_drvdata(pdev);
mtk_cec_htplg_irq_disable(cec);
clk_disable_unprepare(cec->clk);
- return 0;
}
static const struct of_device_id mtk_cec_of_ids[] = {
@@ -252,7 +251,7 @@ MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
struct platform_driver mtk_cec_driver = {
.probe = mtk_cec_probe,
- .remove = mtk_cec_remove,
+ .remove_new = mtk_cec_remove,
.driver = {
.name = "mediatek-cec",
.of_match_table = mtk_cec_of_ids,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 28/53] drm/mediatek: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-08 8:25 ` Matthias Brugger
-1 siblings, 0 replies; 261+ messages in thread
From: Matthias Brugger @ 2023-05-08 8:25 UTC (permalink / raw)
To: Uwe Kleine-König, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Daniel Vetter
Cc: AngeloGioacchino Del Regno, dri-devel, linux-mediatek, kernel,
linux-arm-kernel
On 07/05/2023 18:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c
> index b640bc0559e7..f47f417d8ba6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_cec.c
> +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> @@ -235,13 +235,12 @@ static int mtk_cec_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int mtk_cec_remove(struct platform_device *pdev)
> +static void mtk_cec_remove(struct platform_device *pdev)
> {
> struct mtk_cec *cec = platform_get_drvdata(pdev);
>
> mtk_cec_htplg_irq_disable(cec);
> clk_disable_unprepare(cec->clk);
> - return 0;
> }
>
> static const struct of_device_id mtk_cec_of_ids[] = {
> @@ -252,7 +251,7 @@ MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
>
> struct platform_driver mtk_cec_driver = {
> .probe = mtk_cec_probe,
> - .remove = mtk_cec_remove,
> + .remove_new = mtk_cec_remove,
> .driver = {
> .name = "mediatek-cec",
> .of_match_table = mtk_cec_of_ids,
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 28/53] drm/mediatek: Convert to platform remove callback returning void
@ 2023-05-08 8:25 ` Matthias Brugger
0 siblings, 0 replies; 261+ messages in thread
From: Matthias Brugger @ 2023-05-08 8:25 UTC (permalink / raw)
To: Uwe Kleine-König, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Daniel Vetter
Cc: linux-arm-kernel, linux-mediatek, kernel, dri-devel,
AngeloGioacchino Del Regno
On 07/05/2023 18:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c
> index b640bc0559e7..f47f417d8ba6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_cec.c
> +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> @@ -235,13 +235,12 @@ static int mtk_cec_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int mtk_cec_remove(struct platform_device *pdev)
> +static void mtk_cec_remove(struct platform_device *pdev)
> {
> struct mtk_cec *cec = platform_get_drvdata(pdev);
>
> mtk_cec_htplg_irq_disable(cec);
> clk_disable_unprepare(cec->clk);
> - return 0;
> }
>
> static const struct of_device_id mtk_cec_of_ids[] = {
> @@ -252,7 +251,7 @@ MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
>
> struct platform_driver mtk_cec_driver = {
> .probe = mtk_cec_probe,
> - .remove = mtk_cec_remove,
> + .remove_new = mtk_cec_remove,
> .driver = {
> .name = "mediatek-cec",
> .of_match_table = mtk_cec_of_ids,
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 29/53] drm/mediatek: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: AngeloGioacchino Del Regno, dri-devel, linux-mediatek, kernel,
linux-arm-kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the mediatek drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
14 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 434e8a9ce8ab..cbd9b4becc43 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -140,11 +140,9 @@ static int mtk_disp_aal_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_aal_remove(struct platform_device *pdev)
+static void mtk_disp_aal_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_aal_component_ops);
-
- return 0;
}
static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
@@ -161,7 +159,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
struct platform_driver mtk_disp_aal_driver = {
.probe = mtk_disp_aal_probe,
- .remove = mtk_disp_aal_remove,
+ .remove_new = mtk_disp_aal_remove,
.driver = {
.name = "mediatek-disp-aal",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 1773379b2439..fa6dbc4e9c35 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -195,11 +195,9 @@ static int mtk_disp_ccorr_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_ccorr_remove(struct platform_device *pdev)
+static void mtk_disp_ccorr_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_ccorr_component_ops);
-
- return 0;
}
static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
@@ -221,7 +219,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
struct platform_driver mtk_disp_ccorr_driver = {
.probe = mtk_disp_ccorr_probe,
- .remove = mtk_disp_ccorr_remove,
+ .remove_new = mtk_disp_ccorr_remove,
.driver = {
.name = "mediatek-disp-ccorr",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index cac9206079e7..78e44e6befd6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -132,11 +132,9 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_color_remove(struct platform_device *pdev)
+static void mtk_disp_color_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_color_component_ops);
-
- return 0;
}
static const struct mtk_disp_color_data mt2701_color_driver_data = {
@@ -164,7 +162,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_color_driver_dt_match);
struct platform_driver mtk_disp_color_driver = {
.probe = mtk_disp_color_probe,
- .remove = mtk_disp_color_remove,
+ .remove_new = mtk_disp_color_remove,
.driver = {
.name = "mediatek-disp-color",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index c844942603f7..c5237f4eb7fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -183,11 +183,9 @@ static int mtk_disp_gamma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_gamma_remove(struct platform_device *pdev)
+static void mtk_disp_gamma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_gamma_component_ops);
-
- return 0;
}
static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
@@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
struct platform_driver mtk_disp_gamma_driver = {
.probe = mtk_disp_gamma_probe,
- .remove = mtk_disp_gamma_remove,
+ .remove_new = mtk_disp_gamma_remove,
.driver = {
.name = "mediatek-disp-gamma",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
index 6428b6203ffe..fd14a59bc951 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -295,11 +295,9 @@ static int mtk_disp_merge_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_merge_remove(struct platform_device *pdev)
+static void mtk_disp_merge_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_merge_component_ops);
-
- return 0;
}
static const struct of_device_id mtk_disp_merge_driver_dt_match[] = {
@@ -311,7 +309,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_merge_driver_dt_match);
struct platform_driver mtk_disp_merge_driver = {
.probe = mtk_disp_merge_probe,
- .remove = mtk_disp_merge_remove,
+ .remove_new = mtk_disp_merge_remove,
.driver = {
.name = "mediatek-disp-merge",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 9d8c986700ee..f90ad9bce028 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -483,12 +483,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_ovl_remove(struct platform_device *pdev)
+static void mtk_disp_ovl_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
@@ -565,7 +563,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
struct platform_driver mtk_disp_ovl_driver = {
.probe = mtk_disp_ovl_probe,
- .remove = mtk_disp_ovl_remove,
+ .remove_new = mtk_disp_ovl_remove,
.driver = {
.name = "mediatek-disp-ovl",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index a5a0c3bac35d..49149d67bb0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -350,13 +350,11 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_rdma_remove(struct platform_device *pdev)
+static void mtk_disp_rdma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
@@ -390,7 +388,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
struct platform_driver mtk_disp_rdma_driver = {
.probe = mtk_disp_rdma_probe,
- .remove = mtk_disp_rdma_remove,
+ .remove_new = mtk_disp_rdma_remove,
.driver = {
.name = "mediatek-disp-rdma",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index 1f94fcc144d3..6352ee412045 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2575,7 +2575,7 @@ static int mtk_dp_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_dp_remove(struct platform_device *pdev)
+static void mtk_dp_remove(struct platform_device *pdev)
{
struct mtk_dp *mtk_dp = platform_get_drvdata(pdev);
@@ -2586,8 +2586,6 @@ static int mtk_dp_remove(struct platform_device *pdev)
platform_device_unregister(mtk_dp->phy_dev);
if (mtk_dp->audio_pdev)
platform_device_unregister(mtk_dp->audio_pdev);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -2646,7 +2644,7 @@ MODULE_DEVICE_TABLE(of, mtk_dp_of_match);
static struct platform_driver mtk_dp_driver = {
.probe = mtk_dp_probe,
- .remove = mtk_dp_remove,
+ .remove_new = mtk_dp_remove,
.driver = {
.name = "mediatek-drm-dp",
.of_match_table = mtk_dp_of_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 948a53f1f4b3..ed3cbb202b7a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -1102,14 +1102,12 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_dpi_remove(struct platform_device *pdev)
+static void mtk_dpi_remove(struct platform_device *pdev)
{
struct mtk_dpi *dpi = platform_get_drvdata(pdev);
component_del(&pdev->dev, &mtk_dpi_component_ops);
drm_bridge_remove(&dpi->bridge);
-
- return 0;
}
static const struct of_device_id mtk_dpi_of_ids[] = {
@@ -1140,7 +1138,7 @@ MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
struct platform_driver mtk_dpi_driver = {
.probe = mtk_dpi_probe,
- .remove = mtk_dpi_remove,
+ .remove_new = mtk_dpi_remove,
.driver = {
.name = "mediatek-dpi",
.of_match_table = mtk_dpi_of_ids,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a13b36ac03a1..b951ad494f7d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -826,7 +826,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_drm_remove(struct platform_device *pdev)
+static void mtk_drm_remove(struct platform_device *pdev)
{
struct mtk_drm_private *private = platform_get_drvdata(pdev);
int i;
@@ -836,8 +836,6 @@ static int mtk_drm_remove(struct platform_device *pdev)
of_node_put(private->mutex_node);
for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
of_node_put(private->comp_node[i]);
-
- return 0;
}
static int mtk_drm_sys_prepare(struct device *dev)
@@ -866,7 +864,7 @@ static const struct dev_pm_ops mtk_drm_pm_ops = {
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
- .remove = mtk_drm_remove,
+ .remove_new = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
.pm = &mtk_drm_pm_ops,
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 7d5250351193..d8bfc2cce54d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1178,14 +1178,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_dsi_remove(struct platform_device *pdev)
+static void mtk_dsi_remove(struct platform_device *pdev)
{
struct mtk_dsi *dsi = platform_get_drvdata(pdev);
mtk_output_dsi_disable(dsi);
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
@@ -1223,7 +1221,7 @@ MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
struct platform_driver mtk_dsi_driver = {
.probe = mtk_dsi_probe,
- .remove = mtk_dsi_remove,
+ .remove_new = mtk_dsi_remove,
.driver = {
.name = "mtk-dsi",
.of_match_table = mtk_dsi_of_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a8e0a13f516..86133bf16326 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1746,13 +1746,12 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_drm_hdmi_remove(struct platform_device *pdev)
+static void mtk_drm_hdmi_remove(struct platform_device *pdev)
{
struct mtk_hdmi *hdmi = platform_get_drvdata(pdev);
drm_bridge_remove(&hdmi->bridge);
mtk_hdmi_clk_disable_audio(hdmi);
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -1806,7 +1805,7 @@ MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
static struct platform_driver mtk_hdmi_driver = {
.probe = mtk_drm_hdmi_probe,
- .remove = mtk_drm_hdmi_remove,
+ .remove_new = mtk_drm_hdmi_remove,
.driver = {
.name = "mediatek-drm-hdmi",
.of_match_table = mtk_drm_hdmi_of_ids,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index 2fc9214ffa82..63d3d5ba31f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
@@ -324,14 +324,12 @@ static int mtk_hdmi_ddc_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_hdmi_ddc_remove(struct platform_device *pdev)
+static void mtk_hdmi_ddc_remove(struct platform_device *pdev)
{
struct mtk_hdmi_ddc *ddc = platform_get_drvdata(pdev);
i2c_del_adapter(&ddc->adap);
clk_disable_unprepare(ddc->clk);
-
- return 0;
}
static const struct of_device_id mtk_hdmi_ddc_match[] = {
@@ -342,7 +340,7 @@ MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
struct platform_driver mtk_hdmi_ddc_driver = {
.probe = mtk_hdmi_ddc_probe,
- .remove = mtk_hdmi_ddc_remove,
+ .remove_new = mtk_hdmi_ddc_remove,
.driver = {
.name = "mediatek-hdmi-ddc",
.of_match_table = mtk_hdmi_ddc_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index eecfa98ff52e..11bb6ca8cc8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -291,11 +291,10 @@ static int mtk_mdp_rdma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_mdp_rdma_remove(struct platform_device *pdev)
+static void mtk_mdp_rdma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_mdp_rdma_component_ops);
pm_runtime_disable(&pdev->dev);
- return 0;
}
static const struct of_device_id mtk_mdp_rdma_driver_dt_match[] = {
@@ -306,7 +305,7 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_rdma_driver_dt_match);
struct platform_driver mtk_mdp_rdma_driver = {
.probe = mtk_mdp_rdma_probe,
- .remove = mtk_mdp_rdma_remove,
+ .remove_new = mtk_mdp_rdma_remove,
.driver = {
.name = "mediatek-mdp-rdma",
.owner = THIS_MODULE,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 29/53] drm/mediatek: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: linux-arm-kernel, linux-mediatek, kernel, dri-devel,
AngeloGioacchino Del Regno
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the mediatek drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
14 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 434e8a9ce8ab..cbd9b4becc43 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -140,11 +140,9 @@ static int mtk_disp_aal_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_aal_remove(struct platform_device *pdev)
+static void mtk_disp_aal_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_aal_component_ops);
-
- return 0;
}
static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
@@ -161,7 +159,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
struct platform_driver mtk_disp_aal_driver = {
.probe = mtk_disp_aal_probe,
- .remove = mtk_disp_aal_remove,
+ .remove_new = mtk_disp_aal_remove,
.driver = {
.name = "mediatek-disp-aal",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 1773379b2439..fa6dbc4e9c35 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -195,11 +195,9 @@ static int mtk_disp_ccorr_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_ccorr_remove(struct platform_device *pdev)
+static void mtk_disp_ccorr_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_ccorr_component_ops);
-
- return 0;
}
static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
@@ -221,7 +219,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
struct platform_driver mtk_disp_ccorr_driver = {
.probe = mtk_disp_ccorr_probe,
- .remove = mtk_disp_ccorr_remove,
+ .remove_new = mtk_disp_ccorr_remove,
.driver = {
.name = "mediatek-disp-ccorr",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index cac9206079e7..78e44e6befd6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -132,11 +132,9 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_color_remove(struct platform_device *pdev)
+static void mtk_disp_color_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_color_component_ops);
-
- return 0;
}
static const struct mtk_disp_color_data mt2701_color_driver_data = {
@@ -164,7 +162,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_color_driver_dt_match);
struct platform_driver mtk_disp_color_driver = {
.probe = mtk_disp_color_probe,
- .remove = mtk_disp_color_remove,
+ .remove_new = mtk_disp_color_remove,
.driver = {
.name = "mediatek-disp-color",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index c844942603f7..c5237f4eb7fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -183,11 +183,9 @@ static int mtk_disp_gamma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_gamma_remove(struct platform_device *pdev)
+static void mtk_disp_gamma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_gamma_component_ops);
-
- return 0;
}
static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
@@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
struct platform_driver mtk_disp_gamma_driver = {
.probe = mtk_disp_gamma_probe,
- .remove = mtk_disp_gamma_remove,
+ .remove_new = mtk_disp_gamma_remove,
.driver = {
.name = "mediatek-disp-gamma",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
index 6428b6203ffe..fd14a59bc951 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -295,11 +295,9 @@ static int mtk_disp_merge_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_merge_remove(struct platform_device *pdev)
+static void mtk_disp_merge_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_merge_component_ops);
-
- return 0;
}
static const struct of_device_id mtk_disp_merge_driver_dt_match[] = {
@@ -311,7 +309,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_merge_driver_dt_match);
struct platform_driver mtk_disp_merge_driver = {
.probe = mtk_disp_merge_probe,
- .remove = mtk_disp_merge_remove,
+ .remove_new = mtk_disp_merge_remove,
.driver = {
.name = "mediatek-disp-merge",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 9d8c986700ee..f90ad9bce028 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -483,12 +483,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_ovl_remove(struct platform_device *pdev)
+static void mtk_disp_ovl_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
@@ -565,7 +563,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
struct platform_driver mtk_disp_ovl_driver = {
.probe = mtk_disp_ovl_probe,
- .remove = mtk_disp_ovl_remove,
+ .remove_new = mtk_disp_ovl_remove,
.driver = {
.name = "mediatek-disp-ovl",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index a5a0c3bac35d..49149d67bb0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -350,13 +350,11 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_rdma_remove(struct platform_device *pdev)
+static void mtk_disp_rdma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
@@ -390,7 +388,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
struct platform_driver mtk_disp_rdma_driver = {
.probe = mtk_disp_rdma_probe,
- .remove = mtk_disp_rdma_remove,
+ .remove_new = mtk_disp_rdma_remove,
.driver = {
.name = "mediatek-disp-rdma",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index 1f94fcc144d3..6352ee412045 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2575,7 +2575,7 @@ static int mtk_dp_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_dp_remove(struct platform_device *pdev)
+static void mtk_dp_remove(struct platform_device *pdev)
{
struct mtk_dp *mtk_dp = platform_get_drvdata(pdev);
@@ -2586,8 +2586,6 @@ static int mtk_dp_remove(struct platform_device *pdev)
platform_device_unregister(mtk_dp->phy_dev);
if (mtk_dp->audio_pdev)
platform_device_unregister(mtk_dp->audio_pdev);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -2646,7 +2644,7 @@ MODULE_DEVICE_TABLE(of, mtk_dp_of_match);
static struct platform_driver mtk_dp_driver = {
.probe = mtk_dp_probe,
- .remove = mtk_dp_remove,
+ .remove_new = mtk_dp_remove,
.driver = {
.name = "mediatek-drm-dp",
.of_match_table = mtk_dp_of_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 948a53f1f4b3..ed3cbb202b7a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -1102,14 +1102,12 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_dpi_remove(struct platform_device *pdev)
+static void mtk_dpi_remove(struct platform_device *pdev)
{
struct mtk_dpi *dpi = platform_get_drvdata(pdev);
component_del(&pdev->dev, &mtk_dpi_component_ops);
drm_bridge_remove(&dpi->bridge);
-
- return 0;
}
static const struct of_device_id mtk_dpi_of_ids[] = {
@@ -1140,7 +1138,7 @@ MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
struct platform_driver mtk_dpi_driver = {
.probe = mtk_dpi_probe,
- .remove = mtk_dpi_remove,
+ .remove_new = mtk_dpi_remove,
.driver = {
.name = "mediatek-dpi",
.of_match_table = mtk_dpi_of_ids,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a13b36ac03a1..b951ad494f7d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -826,7 +826,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_drm_remove(struct platform_device *pdev)
+static void mtk_drm_remove(struct platform_device *pdev)
{
struct mtk_drm_private *private = platform_get_drvdata(pdev);
int i;
@@ -836,8 +836,6 @@ static int mtk_drm_remove(struct platform_device *pdev)
of_node_put(private->mutex_node);
for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
of_node_put(private->comp_node[i]);
-
- return 0;
}
static int mtk_drm_sys_prepare(struct device *dev)
@@ -866,7 +864,7 @@ static const struct dev_pm_ops mtk_drm_pm_ops = {
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
- .remove = mtk_drm_remove,
+ .remove_new = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
.pm = &mtk_drm_pm_ops,
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 7d5250351193..d8bfc2cce54d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1178,14 +1178,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_dsi_remove(struct platform_device *pdev)
+static void mtk_dsi_remove(struct platform_device *pdev)
{
struct mtk_dsi *dsi = platform_get_drvdata(pdev);
mtk_output_dsi_disable(dsi);
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
@@ -1223,7 +1221,7 @@ MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
struct platform_driver mtk_dsi_driver = {
.probe = mtk_dsi_probe,
- .remove = mtk_dsi_remove,
+ .remove_new = mtk_dsi_remove,
.driver = {
.name = "mtk-dsi",
.of_match_table = mtk_dsi_of_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a8e0a13f516..86133bf16326 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1746,13 +1746,12 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_drm_hdmi_remove(struct platform_device *pdev)
+static void mtk_drm_hdmi_remove(struct platform_device *pdev)
{
struct mtk_hdmi *hdmi = platform_get_drvdata(pdev);
drm_bridge_remove(&hdmi->bridge);
mtk_hdmi_clk_disable_audio(hdmi);
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -1806,7 +1805,7 @@ MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
static struct platform_driver mtk_hdmi_driver = {
.probe = mtk_drm_hdmi_probe,
- .remove = mtk_drm_hdmi_remove,
+ .remove_new = mtk_drm_hdmi_remove,
.driver = {
.name = "mediatek-drm-hdmi",
.of_match_table = mtk_drm_hdmi_of_ids,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index 2fc9214ffa82..63d3d5ba31f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
@@ -324,14 +324,12 @@ static int mtk_hdmi_ddc_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_hdmi_ddc_remove(struct platform_device *pdev)
+static void mtk_hdmi_ddc_remove(struct platform_device *pdev)
{
struct mtk_hdmi_ddc *ddc = platform_get_drvdata(pdev);
i2c_del_adapter(&ddc->adap);
clk_disable_unprepare(ddc->clk);
-
- return 0;
}
static const struct of_device_id mtk_hdmi_ddc_match[] = {
@@ -342,7 +340,7 @@ MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
struct platform_driver mtk_hdmi_ddc_driver = {
.probe = mtk_hdmi_ddc_probe,
- .remove = mtk_hdmi_ddc_remove,
+ .remove_new = mtk_hdmi_ddc_remove,
.driver = {
.name = "mediatek-hdmi-ddc",
.of_match_table = mtk_hdmi_ddc_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index eecfa98ff52e..11bb6ca8cc8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -291,11 +291,10 @@ static int mtk_mdp_rdma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_mdp_rdma_remove(struct platform_device *pdev)
+static void mtk_mdp_rdma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_mdp_rdma_component_ops);
pm_runtime_disable(&pdev->dev);
- return 0;
}
static const struct of_device_id mtk_mdp_rdma_driver_dt_match[] = {
@@ -306,7 +305,7 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_rdma_driver_dt_match);
struct platform_driver mtk_mdp_rdma_driver = {
.probe = mtk_mdp_rdma_probe,
- .remove = mtk_mdp_rdma_remove,
+ .remove_new = mtk_mdp_rdma_remove,
.driver = {
.name = "mediatek-mdp-rdma",
.owner = THIS_MODULE,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 29/53] drm/mediatek: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Daniel Vetter,
Matthias Brugger
Cc: AngeloGioacchino Del Regno, dri-devel, linux-mediatek, kernel,
linux-arm-kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the mediatek drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
14 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 434e8a9ce8ab..cbd9b4becc43 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -140,11 +140,9 @@ static int mtk_disp_aal_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_aal_remove(struct platform_device *pdev)
+static void mtk_disp_aal_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_aal_component_ops);
-
- return 0;
}
static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
@@ -161,7 +159,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
struct platform_driver mtk_disp_aal_driver = {
.probe = mtk_disp_aal_probe,
- .remove = mtk_disp_aal_remove,
+ .remove_new = mtk_disp_aal_remove,
.driver = {
.name = "mediatek-disp-aal",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 1773379b2439..fa6dbc4e9c35 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -195,11 +195,9 @@ static int mtk_disp_ccorr_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_ccorr_remove(struct platform_device *pdev)
+static void mtk_disp_ccorr_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_ccorr_component_ops);
-
- return 0;
}
static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
@@ -221,7 +219,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
struct platform_driver mtk_disp_ccorr_driver = {
.probe = mtk_disp_ccorr_probe,
- .remove = mtk_disp_ccorr_remove,
+ .remove_new = mtk_disp_ccorr_remove,
.driver = {
.name = "mediatek-disp-ccorr",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index cac9206079e7..78e44e6befd6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -132,11 +132,9 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_color_remove(struct platform_device *pdev)
+static void mtk_disp_color_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_color_component_ops);
-
- return 0;
}
static const struct mtk_disp_color_data mt2701_color_driver_data = {
@@ -164,7 +162,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_color_driver_dt_match);
struct platform_driver mtk_disp_color_driver = {
.probe = mtk_disp_color_probe,
- .remove = mtk_disp_color_remove,
+ .remove_new = mtk_disp_color_remove,
.driver = {
.name = "mediatek-disp-color",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index c844942603f7..c5237f4eb7fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -183,11 +183,9 @@ static int mtk_disp_gamma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_gamma_remove(struct platform_device *pdev)
+static void mtk_disp_gamma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_gamma_component_ops);
-
- return 0;
}
static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
@@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
struct platform_driver mtk_disp_gamma_driver = {
.probe = mtk_disp_gamma_probe,
- .remove = mtk_disp_gamma_remove,
+ .remove_new = mtk_disp_gamma_remove,
.driver = {
.name = "mediatek-disp-gamma",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
index 6428b6203ffe..fd14a59bc951 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
@@ -295,11 +295,9 @@ static int mtk_disp_merge_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_merge_remove(struct platform_device *pdev)
+static void mtk_disp_merge_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_merge_component_ops);
-
- return 0;
}
static const struct of_device_id mtk_disp_merge_driver_dt_match[] = {
@@ -311,7 +309,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_merge_driver_dt_match);
struct platform_driver mtk_disp_merge_driver = {
.probe = mtk_disp_merge_probe,
- .remove = mtk_disp_merge_remove,
+ .remove_new = mtk_disp_merge_remove,
.driver = {
.name = "mediatek-disp-merge",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 9d8c986700ee..f90ad9bce028 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -483,12 +483,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_ovl_remove(struct platform_device *pdev)
+static void mtk_disp_ovl_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
@@ -565,7 +563,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
struct platform_driver mtk_disp_ovl_driver = {
.probe = mtk_disp_ovl_probe,
- .remove = mtk_disp_ovl_remove,
+ .remove_new = mtk_disp_ovl_remove,
.driver = {
.name = "mediatek-disp-ovl",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index a5a0c3bac35d..49149d67bb0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -350,13 +350,11 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_disp_rdma_remove(struct platform_device *pdev)
+static void mtk_disp_rdma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
@@ -390,7 +388,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
struct platform_driver mtk_disp_rdma_driver = {
.probe = mtk_disp_rdma_probe,
- .remove = mtk_disp_rdma_remove,
+ .remove_new = mtk_disp_rdma_remove,
.driver = {
.name = "mediatek-disp-rdma",
.owner = THIS_MODULE,
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index 1f94fcc144d3..6352ee412045 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2575,7 +2575,7 @@ static int mtk_dp_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_dp_remove(struct platform_device *pdev)
+static void mtk_dp_remove(struct platform_device *pdev)
{
struct mtk_dp *mtk_dp = platform_get_drvdata(pdev);
@@ -2586,8 +2586,6 @@ static int mtk_dp_remove(struct platform_device *pdev)
platform_device_unregister(mtk_dp->phy_dev);
if (mtk_dp->audio_pdev)
platform_device_unregister(mtk_dp->audio_pdev);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -2646,7 +2644,7 @@ MODULE_DEVICE_TABLE(of, mtk_dp_of_match);
static struct platform_driver mtk_dp_driver = {
.probe = mtk_dp_probe,
- .remove = mtk_dp_remove,
+ .remove_new = mtk_dp_remove,
.driver = {
.name = "mediatek-drm-dp",
.of_match_table = mtk_dp_of_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 948a53f1f4b3..ed3cbb202b7a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -1102,14 +1102,12 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return 0;
}
-static int mtk_dpi_remove(struct platform_device *pdev)
+static void mtk_dpi_remove(struct platform_device *pdev)
{
struct mtk_dpi *dpi = platform_get_drvdata(pdev);
component_del(&pdev->dev, &mtk_dpi_component_ops);
drm_bridge_remove(&dpi->bridge);
-
- return 0;
}
static const struct of_device_id mtk_dpi_of_ids[] = {
@@ -1140,7 +1138,7 @@ MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
struct platform_driver mtk_dpi_driver = {
.probe = mtk_dpi_probe,
- .remove = mtk_dpi_remove,
+ .remove_new = mtk_dpi_remove,
.driver = {
.name = "mediatek-dpi",
.of_match_table = mtk_dpi_of_ids,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a13b36ac03a1..b951ad494f7d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -826,7 +826,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_drm_remove(struct platform_device *pdev)
+static void mtk_drm_remove(struct platform_device *pdev)
{
struct mtk_drm_private *private = platform_get_drvdata(pdev);
int i;
@@ -836,8 +836,6 @@ static int mtk_drm_remove(struct platform_device *pdev)
of_node_put(private->mutex_node);
for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
of_node_put(private->comp_node[i]);
-
- return 0;
}
static int mtk_drm_sys_prepare(struct device *dev)
@@ -866,7 +864,7 @@ static const struct dev_pm_ops mtk_drm_pm_ops = {
static struct platform_driver mtk_drm_platform_driver = {
.probe = mtk_drm_probe,
- .remove = mtk_drm_remove,
+ .remove_new = mtk_drm_remove,
.driver = {
.name = "mediatek-drm",
.pm = &mtk_drm_pm_ops,
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 7d5250351193..d8bfc2cce54d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1178,14 +1178,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_dsi_remove(struct platform_device *pdev)
+static void mtk_dsi_remove(struct platform_device *pdev)
{
struct mtk_dsi *dsi = platform_get_drvdata(pdev);
mtk_output_dsi_disable(dsi);
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
@@ -1223,7 +1221,7 @@ MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
struct platform_driver mtk_dsi_driver = {
.probe = mtk_dsi_probe,
- .remove = mtk_dsi_remove,
+ .remove_new = mtk_dsi_remove,
.driver = {
.name = "mtk-dsi",
.of_match_table = mtk_dsi_of_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0a8e0a13f516..86133bf16326 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1746,13 +1746,12 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_drm_hdmi_remove(struct platform_device *pdev)
+static void mtk_drm_hdmi_remove(struct platform_device *pdev)
{
struct mtk_hdmi *hdmi = platform_get_drvdata(pdev);
drm_bridge_remove(&hdmi->bridge);
mtk_hdmi_clk_disable_audio(hdmi);
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -1806,7 +1805,7 @@ MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
static struct platform_driver mtk_hdmi_driver = {
.probe = mtk_drm_hdmi_probe,
- .remove = mtk_drm_hdmi_remove,
+ .remove_new = mtk_drm_hdmi_remove,
.driver = {
.name = "mediatek-drm-hdmi",
.of_match_table = mtk_drm_hdmi_of_ids,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index 2fc9214ffa82..63d3d5ba31f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
@@ -324,14 +324,12 @@ static int mtk_hdmi_ddc_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_hdmi_ddc_remove(struct platform_device *pdev)
+static void mtk_hdmi_ddc_remove(struct platform_device *pdev)
{
struct mtk_hdmi_ddc *ddc = platform_get_drvdata(pdev);
i2c_del_adapter(&ddc->adap);
clk_disable_unprepare(ddc->clk);
-
- return 0;
}
static const struct of_device_id mtk_hdmi_ddc_match[] = {
@@ -342,7 +340,7 @@ MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
struct platform_driver mtk_hdmi_ddc_driver = {
.probe = mtk_hdmi_ddc_probe,
- .remove = mtk_hdmi_ddc_remove,
+ .remove_new = mtk_hdmi_ddc_remove,
.driver = {
.name = "mediatek-hdmi-ddc",
.of_match_table = mtk_hdmi_ddc_match,
diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
index eecfa98ff52e..11bb6ca8cc8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
@@ -291,11 +291,10 @@ static int mtk_mdp_rdma_probe(struct platform_device *pdev)
return ret;
}
-static int mtk_mdp_rdma_remove(struct platform_device *pdev)
+static void mtk_mdp_rdma_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &mtk_mdp_rdma_component_ops);
pm_runtime_disable(&pdev->dev);
- return 0;
}
static const struct of_device_id mtk_mdp_rdma_driver_dt_match[] = {
@@ -306,7 +305,7 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_rdma_driver_dt_match);
struct platform_driver mtk_mdp_rdma_driver = {
.probe = mtk_mdp_rdma_probe,
- .remove = mtk_mdp_rdma_remove,
+ .remove_new = mtk_mdp_rdma_remove,
.driver = {
.name = "mediatek-mdp-rdma",
.owner = THIS_MODULE,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 29/53] drm/mediatek: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-08 8:26 ` Matthias Brugger
-1 siblings, 0 replies; 261+ messages in thread
From: Matthias Brugger @ 2023-05-08 8:26 UTC (permalink / raw)
To: Uwe Kleine-König, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Daniel Vetter
Cc: AngeloGioacchino Del Regno, dri-devel, linux-mediatek, kernel,
linux-arm-kernel
On 07/05/2023 18:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the mediatek drm drivers from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> 14 files changed, 28 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> index 434e8a9ce8ab..cbd9b4becc43 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -140,11 +140,9 @@ static int mtk_disp_aal_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_aal_remove(struct platform_device *pdev)
> +static void mtk_disp_aal_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_aal_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
> @@ -161,7 +159,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
>
> struct platform_driver mtk_disp_aal_driver = {
> .probe = mtk_disp_aal_probe,
> - .remove = mtk_disp_aal_remove,
> + .remove_new = mtk_disp_aal_remove,
> .driver = {
> .name = "mediatek-disp-aal",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> index 1773379b2439..fa6dbc4e9c35 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> @@ -195,11 +195,9 @@ static int mtk_disp_ccorr_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_ccorr_remove(struct platform_device *pdev)
> +static void mtk_disp_ccorr_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_ccorr_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
> @@ -221,7 +219,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
>
> struct platform_driver mtk_disp_ccorr_driver = {
> .probe = mtk_disp_ccorr_probe,
> - .remove = mtk_disp_ccorr_remove,
> + .remove_new = mtk_disp_ccorr_remove,
> .driver = {
> .name = "mediatek-disp-ccorr",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index cac9206079e7..78e44e6befd6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -132,11 +132,9 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_color_remove(struct platform_device *pdev)
> +static void mtk_disp_color_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_color_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_color_data mt2701_color_driver_data = {
> @@ -164,7 +162,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_color_driver_dt_match);
>
> struct platform_driver mtk_disp_color_driver = {
> .probe = mtk_disp_color_probe,
> - .remove = mtk_disp_color_remove,
> + .remove_new = mtk_disp_color_remove,
> .driver = {
> .name = "mediatek-disp-color",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> index c844942603f7..c5237f4eb7fe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -183,11 +183,9 @@ static int mtk_disp_gamma_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_gamma_remove(struct platform_device *pdev)
> +static void mtk_disp_gamma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_gamma_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
> @@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
>
> struct platform_driver mtk_disp_gamma_driver = {
> .probe = mtk_disp_gamma_probe,
> - .remove = mtk_disp_gamma_remove,
> + .remove_new = mtk_disp_gamma_remove,
> .driver = {
> .name = "mediatek-disp-gamma",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
> index 6428b6203ffe..fd14a59bc951 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
> @@ -295,11 +295,9 @@ static int mtk_disp_merge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_merge_remove(struct platform_device *pdev)
> +static void mtk_disp_merge_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_merge_component_ops);
> -
> - return 0;
> }
>
> static const struct of_device_id mtk_disp_merge_driver_dt_match[] = {
> @@ -311,7 +309,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_merge_driver_dt_match);
>
> struct platform_driver mtk_disp_merge_driver = {
> .probe = mtk_disp_merge_probe,
> - .remove = mtk_disp_merge_remove,
> + .remove_new = mtk_disp_merge_remove,
> .driver = {
> .name = "mediatek-disp-merge",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 9d8c986700ee..f90ad9bce028 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -483,12 +483,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_ovl_remove(struct platform_device *pdev)
> +static void mtk_disp_ovl_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> @@ -565,7 +563,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
>
> struct platform_driver mtk_disp_ovl_driver = {
> .probe = mtk_disp_ovl_probe,
> - .remove = mtk_disp_ovl_remove,
> + .remove_new = mtk_disp_ovl_remove,
> .driver = {
> .name = "mediatek-disp-ovl",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index a5a0c3bac35d..49149d67bb0e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -350,13 +350,11 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_rdma_remove(struct platform_device *pdev)
> +static void mtk_disp_rdma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> @@ -390,7 +388,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
>
> struct platform_driver mtk_disp_rdma_driver = {
> .probe = mtk_disp_rdma_probe,
> - .remove = mtk_disp_rdma_remove,
> + .remove_new = mtk_disp_rdma_remove,
> .driver = {
> .name = "mediatek-disp-rdma",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index 1f94fcc144d3..6352ee412045 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -2575,7 +2575,7 @@ static int mtk_dp_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int mtk_dp_remove(struct platform_device *pdev)
> +static void mtk_dp_remove(struct platform_device *pdev)
> {
> struct mtk_dp *mtk_dp = platform_get_drvdata(pdev);
>
> @@ -2586,8 +2586,6 @@ static int mtk_dp_remove(struct platform_device *pdev)
> platform_device_unregister(mtk_dp->phy_dev);
> if (mtk_dp->audio_pdev)
> platform_device_unregister(mtk_dp->audio_pdev);
> -
> - return 0;
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -2646,7 +2644,7 @@ MODULE_DEVICE_TABLE(of, mtk_dp_of_match);
>
> static struct platform_driver mtk_dp_driver = {
> .probe = mtk_dp_probe,
> - .remove = mtk_dp_remove,
> + .remove_new = mtk_dp_remove,
> .driver = {
> .name = "mediatek-drm-dp",
> .of_match_table = mtk_dp_of_match,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 948a53f1f4b3..ed3cbb202b7a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -1102,14 +1102,12 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int mtk_dpi_remove(struct platform_device *pdev)
> +static void mtk_dpi_remove(struct platform_device *pdev)
> {
> struct mtk_dpi *dpi = platform_get_drvdata(pdev);
>
> component_del(&pdev->dev, &mtk_dpi_component_ops);
> drm_bridge_remove(&dpi->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id mtk_dpi_of_ids[] = {
> @@ -1140,7 +1138,7 @@ MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
>
> struct platform_driver mtk_dpi_driver = {
> .probe = mtk_dpi_probe,
> - .remove = mtk_dpi_remove,
> + .remove_new = mtk_dpi_remove,
> .driver = {
> .name = "mediatek-dpi",
> .of_match_table = mtk_dpi_of_ids,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a13b36ac03a1..b951ad494f7d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -826,7 +826,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_drm_remove(struct platform_device *pdev)
> +static void mtk_drm_remove(struct platform_device *pdev)
> {
> struct mtk_drm_private *private = platform_get_drvdata(pdev);
> int i;
> @@ -836,8 +836,6 @@ static int mtk_drm_remove(struct platform_device *pdev)
> of_node_put(private->mutex_node);
> for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
> of_node_put(private->comp_node[i]);
> -
> - return 0;
> }
>
> static int mtk_drm_sys_prepare(struct device *dev)
> @@ -866,7 +864,7 @@ static const struct dev_pm_ops mtk_drm_pm_ops = {
>
> static struct platform_driver mtk_drm_platform_driver = {
> .probe = mtk_drm_probe,
> - .remove = mtk_drm_remove,
> + .remove_new = mtk_drm_remove,
> .driver = {
> .name = "mediatek-drm",
> .pm = &mtk_drm_pm_ops,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 7d5250351193..d8bfc2cce54d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1178,14 +1178,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_dsi_remove(struct platform_device *pdev)
> +static void mtk_dsi_remove(struct platform_device *pdev)
> {
> struct mtk_dsi *dsi = platform_get_drvdata(pdev);
>
> mtk_output_dsi_disable(dsi);
> mipi_dsi_host_unregister(&dsi->host);
> -
> - return 0;
> }
>
> static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
> @@ -1223,7 +1221,7 @@ MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
>
> struct platform_driver mtk_dsi_driver = {
> .probe = mtk_dsi_probe,
> - .remove = mtk_dsi_remove,
> + .remove_new = mtk_dsi_remove,
> .driver = {
> .name = "mtk-dsi",
> .of_match_table = mtk_dsi_of_match,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 0a8e0a13f516..86133bf16326 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1746,13 +1746,12 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_drm_hdmi_remove(struct platform_device *pdev)
> +static void mtk_drm_hdmi_remove(struct platform_device *pdev)
> {
> struct mtk_hdmi *hdmi = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&hdmi->bridge);
> mtk_hdmi_clk_disable_audio(hdmi);
> - return 0;
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -1806,7 +1805,7 @@ MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
>
> static struct platform_driver mtk_hdmi_driver = {
> .probe = mtk_drm_hdmi_probe,
> - .remove = mtk_drm_hdmi_remove,
> + .remove_new = mtk_drm_hdmi_remove,
> .driver = {
> .name = "mediatek-drm-hdmi",
> .of_match_table = mtk_drm_hdmi_of_ids,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> index 2fc9214ffa82..63d3d5ba31f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> @@ -324,14 +324,12 @@ static int mtk_hdmi_ddc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_hdmi_ddc_remove(struct platform_device *pdev)
> +static void mtk_hdmi_ddc_remove(struct platform_device *pdev)
> {
> struct mtk_hdmi_ddc *ddc = platform_get_drvdata(pdev);
>
> i2c_del_adapter(&ddc->adap);
> clk_disable_unprepare(ddc->clk);
> -
> - return 0;
> }
>
> static const struct of_device_id mtk_hdmi_ddc_match[] = {
> @@ -342,7 +340,7 @@ MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
>
> struct platform_driver mtk_hdmi_ddc_driver = {
> .probe = mtk_hdmi_ddc_probe,
> - .remove = mtk_hdmi_ddc_remove,
> + .remove_new = mtk_hdmi_ddc_remove,
> .driver = {
> .name = "mediatek-hdmi-ddc",
> .of_match_table = mtk_hdmi_ddc_match,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> index eecfa98ff52e..11bb6ca8cc8f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> @@ -291,11 +291,10 @@ static int mtk_mdp_rdma_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_mdp_rdma_remove(struct platform_device *pdev)
> +static void mtk_mdp_rdma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_mdp_rdma_component_ops);
> pm_runtime_disable(&pdev->dev);
> - return 0;
> }
>
> static const struct of_device_id mtk_mdp_rdma_driver_dt_match[] = {
> @@ -306,7 +305,7 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_rdma_driver_dt_match);
>
> struct platform_driver mtk_mdp_rdma_driver = {
> .probe = mtk_mdp_rdma_probe,
> - .remove = mtk_mdp_rdma_remove,
> + .remove_new = mtk_mdp_rdma_remove,
> .driver = {
> .name = "mediatek-mdp-rdma",
> .owner = THIS_MODULE,
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 29/53] drm/mediatek: Convert to platform remove callback returning void
@ 2023-05-08 8:26 ` Matthias Brugger
0 siblings, 0 replies; 261+ messages in thread
From: Matthias Brugger @ 2023-05-08 8:26 UTC (permalink / raw)
To: Uwe Kleine-König, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Daniel Vetter
Cc: linux-arm-kernel, linux-mediatek, kernel, dri-devel,
AngeloGioacchino Del Regno
On 07/05/2023 18:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the mediatek drm drivers from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> 14 files changed, 28 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> index 434e8a9ce8ab..cbd9b4becc43 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -140,11 +140,9 @@ static int mtk_disp_aal_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_aal_remove(struct platform_device *pdev)
> +static void mtk_disp_aal_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_aal_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
> @@ -161,7 +159,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
>
> struct platform_driver mtk_disp_aal_driver = {
> .probe = mtk_disp_aal_probe,
> - .remove = mtk_disp_aal_remove,
> + .remove_new = mtk_disp_aal_remove,
> .driver = {
> .name = "mediatek-disp-aal",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> index 1773379b2439..fa6dbc4e9c35 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
> @@ -195,11 +195,9 @@ static int mtk_disp_ccorr_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_ccorr_remove(struct platform_device *pdev)
> +static void mtk_disp_ccorr_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_ccorr_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_ccorr_data mt8183_ccorr_driver_data = {
> @@ -221,7 +219,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
>
> struct platform_driver mtk_disp_ccorr_driver = {
> .probe = mtk_disp_ccorr_probe,
> - .remove = mtk_disp_ccorr_remove,
> + .remove_new = mtk_disp_ccorr_remove,
> .driver = {
> .name = "mediatek-disp-ccorr",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index cac9206079e7..78e44e6befd6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -132,11 +132,9 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_color_remove(struct platform_device *pdev)
> +static void mtk_disp_color_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_color_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_color_data mt2701_color_driver_data = {
> @@ -164,7 +162,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_color_driver_dt_match);
>
> struct platform_driver mtk_disp_color_driver = {
> .probe = mtk_disp_color_probe,
> - .remove = mtk_disp_color_remove,
> + .remove_new = mtk_disp_color_remove,
> .driver = {
> .name = "mediatek-disp-color",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> index c844942603f7..c5237f4eb7fe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -183,11 +183,9 @@ static int mtk_disp_gamma_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_gamma_remove(struct platform_device *pdev)
> +static void mtk_disp_gamma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_gamma_component_ops);
> -
> - return 0;
> }
>
> static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
> @@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
>
> struct platform_driver mtk_disp_gamma_driver = {
> .probe = mtk_disp_gamma_probe,
> - .remove = mtk_disp_gamma_remove,
> + .remove_new = mtk_disp_gamma_remove,
> .driver = {
> .name = "mediatek-disp-gamma",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_merge.c b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
> index 6428b6203ffe..fd14a59bc951 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_merge.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_merge.c
> @@ -295,11 +295,9 @@ static int mtk_disp_merge_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_merge_remove(struct platform_device *pdev)
> +static void mtk_disp_merge_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_merge_component_ops);
> -
> - return 0;
> }
>
> static const struct of_device_id mtk_disp_merge_driver_dt_match[] = {
> @@ -311,7 +309,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_merge_driver_dt_match);
>
> struct platform_driver mtk_disp_merge_driver = {
> .probe = mtk_disp_merge_probe,
> - .remove = mtk_disp_merge_remove,
> + .remove_new = mtk_disp_merge_remove,
> .driver = {
> .name = "mediatek-disp-merge",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 9d8c986700ee..f90ad9bce028 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -483,12 +483,10 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_ovl_remove(struct platform_device *pdev)
> +static void mtk_disp_ovl_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> @@ -565,7 +563,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
>
> struct platform_driver mtk_disp_ovl_driver = {
> .probe = mtk_disp_ovl_probe,
> - .remove = mtk_disp_ovl_remove,
> + .remove_new = mtk_disp_ovl_remove,
> .driver = {
> .name = "mediatek-disp-ovl",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index a5a0c3bac35d..49149d67bb0e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -350,13 +350,11 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_disp_rdma_remove(struct platform_device *pdev)
> +static void mtk_disp_rdma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
> @@ -390,7 +388,7 @@ MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
>
> struct platform_driver mtk_disp_rdma_driver = {
> .probe = mtk_disp_rdma_probe,
> - .remove = mtk_disp_rdma_remove,
> + .remove_new = mtk_disp_rdma_remove,
> .driver = {
> .name = "mediatek-disp-rdma",
> .owner = THIS_MODULE,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index 1f94fcc144d3..6352ee412045 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -2575,7 +2575,7 @@ static int mtk_dp_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int mtk_dp_remove(struct platform_device *pdev)
> +static void mtk_dp_remove(struct platform_device *pdev)
> {
> struct mtk_dp *mtk_dp = platform_get_drvdata(pdev);
>
> @@ -2586,8 +2586,6 @@ static int mtk_dp_remove(struct platform_device *pdev)
> platform_device_unregister(mtk_dp->phy_dev);
> if (mtk_dp->audio_pdev)
> platform_device_unregister(mtk_dp->audio_pdev);
> -
> - return 0;
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -2646,7 +2644,7 @@ MODULE_DEVICE_TABLE(of, mtk_dp_of_match);
>
> static struct platform_driver mtk_dp_driver = {
> .probe = mtk_dp_probe,
> - .remove = mtk_dp_remove,
> + .remove_new = mtk_dp_remove,
> .driver = {
> .name = "mediatek-drm-dp",
> .of_match_table = mtk_dp_of_match,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 948a53f1f4b3..ed3cbb202b7a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -1102,14 +1102,12 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int mtk_dpi_remove(struct platform_device *pdev)
> +static void mtk_dpi_remove(struct platform_device *pdev)
> {
> struct mtk_dpi *dpi = platform_get_drvdata(pdev);
>
> component_del(&pdev->dev, &mtk_dpi_component_ops);
> drm_bridge_remove(&dpi->bridge);
> -
> - return 0;
> }
>
> static const struct of_device_id mtk_dpi_of_ids[] = {
> @@ -1140,7 +1138,7 @@ MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
>
> struct platform_driver mtk_dpi_driver = {
> .probe = mtk_dpi_probe,
> - .remove = mtk_dpi_remove,
> + .remove_new = mtk_dpi_remove,
> .driver = {
> .name = "mediatek-dpi",
> .of_match_table = mtk_dpi_of_ids,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a13b36ac03a1..b951ad494f7d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -826,7 +826,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_drm_remove(struct platform_device *pdev)
> +static void mtk_drm_remove(struct platform_device *pdev)
> {
> struct mtk_drm_private *private = platform_get_drvdata(pdev);
> int i;
> @@ -836,8 +836,6 @@ static int mtk_drm_remove(struct platform_device *pdev)
> of_node_put(private->mutex_node);
> for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
> of_node_put(private->comp_node[i]);
> -
> - return 0;
> }
>
> static int mtk_drm_sys_prepare(struct device *dev)
> @@ -866,7 +864,7 @@ static const struct dev_pm_ops mtk_drm_pm_ops = {
>
> static struct platform_driver mtk_drm_platform_driver = {
> .probe = mtk_drm_probe,
> - .remove = mtk_drm_remove,
> + .remove_new = mtk_drm_remove,
> .driver = {
> .name = "mediatek-drm",
> .pm = &mtk_drm_pm_ops,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 7d5250351193..d8bfc2cce54d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1178,14 +1178,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_dsi_remove(struct platform_device *pdev)
> +static void mtk_dsi_remove(struct platform_device *pdev)
> {
> struct mtk_dsi *dsi = platform_get_drvdata(pdev);
>
> mtk_output_dsi_disable(dsi);
> mipi_dsi_host_unregister(&dsi->host);
> -
> - return 0;
> }
>
> static const struct mtk_dsi_driver_data mt8173_dsi_driver_data = {
> @@ -1223,7 +1221,7 @@ MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
>
> struct platform_driver mtk_dsi_driver = {
> .probe = mtk_dsi_probe,
> - .remove = mtk_dsi_remove,
> + .remove_new = mtk_dsi_remove,
> .driver = {
> .name = "mtk-dsi",
> .of_match_table = mtk_dsi_of_match,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 0a8e0a13f516..86133bf16326 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1746,13 +1746,12 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_drm_hdmi_remove(struct platform_device *pdev)
> +static void mtk_drm_hdmi_remove(struct platform_device *pdev)
> {
> struct mtk_hdmi *hdmi = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&hdmi->bridge);
> mtk_hdmi_clk_disable_audio(hdmi);
> - return 0;
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -1806,7 +1805,7 @@ MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
>
> static struct platform_driver mtk_hdmi_driver = {
> .probe = mtk_drm_hdmi_probe,
> - .remove = mtk_drm_hdmi_remove,
> + .remove_new = mtk_drm_hdmi_remove,
> .driver = {
> .name = "mediatek-drm-hdmi",
> .of_match_table = mtk_drm_hdmi_of_ids,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> index 2fc9214ffa82..63d3d5ba31f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> @@ -324,14 +324,12 @@ static int mtk_hdmi_ddc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_hdmi_ddc_remove(struct platform_device *pdev)
> +static void mtk_hdmi_ddc_remove(struct platform_device *pdev)
> {
> struct mtk_hdmi_ddc *ddc = platform_get_drvdata(pdev);
>
> i2c_del_adapter(&ddc->adap);
> clk_disable_unprepare(ddc->clk);
> -
> - return 0;
> }
>
> static const struct of_device_id mtk_hdmi_ddc_match[] = {
> @@ -342,7 +340,7 @@ MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
>
> struct platform_driver mtk_hdmi_ddc_driver = {
> .probe = mtk_hdmi_ddc_probe,
> - .remove = mtk_hdmi_ddc_remove,
> + .remove_new = mtk_hdmi_ddc_remove,
> .driver = {
> .name = "mediatek-hdmi-ddc",
> .of_match_table = mtk_hdmi_ddc_match,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> index eecfa98ff52e..11bb6ca8cc8f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mdp_rdma.c
> @@ -291,11 +291,10 @@ static int mtk_mdp_rdma_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int mtk_mdp_rdma_remove(struct platform_device *pdev)
> +static void mtk_mdp_rdma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_mdp_rdma_component_ops);
> pm_runtime_disable(&pdev->dev);
> - return 0;
> }
>
> static const struct of_device_id mtk_mdp_rdma_driver_dt_match[] = {
> @@ -306,7 +305,7 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_rdma_driver_dt_match);
>
> struct platform_driver mtk_mdp_rdma_driver = {
> .probe = mtk_mdp_rdma_probe,
> - .remove = mtk_mdp_rdma_remove,
> + .remove_new = mtk_mdp_rdma_remove,
> .driver = {
> .name = "mediatek-mdp-rdma",
> .owner = THIS_MODULE,
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 30/53] drm/meson: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Neil Armstrong, David Airlie, Daniel Vetter, Kevin Hilman
Cc: Jerome Brunet, Martin Blumenstingl, dri-devel, linux-amlogic,
linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert meson drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 7caf937c3c90..edaaf9ce5b1a 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -500,11 +500,9 @@ static int meson_drv_probe(struct platform_device *pdev)
return 0;
};
-static int meson_drv_remove(struct platform_device *pdev)
+static void meson_drv_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &meson_drv_master_ops);
-
- return 0;
}
static struct meson_drm_match_data meson_drm_gxbb_data = {
@@ -544,7 +542,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
static struct platform_driver meson_drm_platform_driver = {
.probe = meson_drv_probe,
- .remove = meson_drv_remove,
+ .remove_new = meson_drv_remove,
.shutdown = meson_drv_shutdown,
.driver = {
.name = "meson-drm",
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 3d046878ce6c..411219d53b14 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -852,11 +852,9 @@ static int meson_dw_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &meson_dw_hdmi_ops);
}
-static int meson_dw_hdmi_remove(struct platform_device *pdev)
+static void meson_dw_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &meson_dw_hdmi_ops);
-
- return 0;
}
static const struct dev_pm_ops meson_dw_hdmi_pm_ops = {
@@ -879,7 +877,7 @@ MODULE_DEVICE_TABLE(of, meson_dw_hdmi_of_table);
static struct platform_driver meson_dw_hdmi_platform_driver = {
.probe = meson_dw_hdmi_probe,
- .remove = meson_dw_hdmi_remove,
+ .remove_new = meson_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
.of_match_table = meson_dw_hdmi_of_table,
--
2.39.2
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 30/53] drm/meson: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Neil Armstrong, David Airlie, Daniel Vetter, Kevin Hilman
Cc: Martin Blumenstingl, dri-devel, kernel, linux-amlogic,
linux-arm-kernel, Jerome Brunet
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert meson drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 7caf937c3c90..edaaf9ce5b1a 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -500,11 +500,9 @@ static int meson_drv_probe(struct platform_device *pdev)
return 0;
};
-static int meson_drv_remove(struct platform_device *pdev)
+static void meson_drv_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &meson_drv_master_ops);
-
- return 0;
}
static struct meson_drm_match_data meson_drm_gxbb_data = {
@@ -544,7 +542,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
static struct platform_driver meson_drm_platform_driver = {
.probe = meson_drv_probe,
- .remove = meson_drv_remove,
+ .remove_new = meson_drv_remove,
.shutdown = meson_drv_shutdown,
.driver = {
.name = "meson-drm",
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 3d046878ce6c..411219d53b14 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -852,11 +852,9 @@ static int meson_dw_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &meson_dw_hdmi_ops);
}
-static int meson_dw_hdmi_remove(struct platform_device *pdev)
+static void meson_dw_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &meson_dw_hdmi_ops);
-
- return 0;
}
static const struct dev_pm_ops meson_dw_hdmi_pm_ops = {
@@ -879,7 +877,7 @@ MODULE_DEVICE_TABLE(of, meson_dw_hdmi_of_table);
static struct platform_driver meson_dw_hdmi_platform_driver = {
.probe = meson_dw_hdmi_probe,
- .remove = meson_dw_hdmi_remove,
+ .remove_new = meson_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
.of_match_table = meson_dw_hdmi_of_table,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 30/53] drm/meson: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Neil Armstrong, David Airlie, Daniel Vetter, Kevin Hilman
Cc: Jerome Brunet, Martin Blumenstingl, dri-devel, linux-amlogic,
linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert meson drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/meson/meson_drv.c | 6 ++----
drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 7caf937c3c90..edaaf9ce5b1a 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -500,11 +500,9 @@ static int meson_drv_probe(struct platform_device *pdev)
return 0;
};
-static int meson_drv_remove(struct platform_device *pdev)
+static void meson_drv_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &meson_drv_master_ops);
-
- return 0;
}
static struct meson_drm_match_data meson_drm_gxbb_data = {
@@ -544,7 +542,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
static struct platform_driver meson_drm_platform_driver = {
.probe = meson_drv_probe,
- .remove = meson_drv_remove,
+ .remove_new = meson_drv_remove,
.shutdown = meson_drv_shutdown,
.driver = {
.name = "meson-drm",
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 3d046878ce6c..411219d53b14 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -852,11 +852,9 @@ static int meson_dw_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &meson_dw_hdmi_ops);
}
-static int meson_dw_hdmi_remove(struct platform_device *pdev)
+static void meson_dw_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &meson_dw_hdmi_ops);
-
- return 0;
}
static const struct dev_pm_ops meson_dw_hdmi_pm_ops = {
@@ -879,7 +877,7 @@ MODULE_DEVICE_TABLE(of, meson_dw_hdmi_of_table);
static struct platform_driver meson_dw_hdmi_platform_driver = {
.probe = meson_dw_hdmi_probe,
- .remove = meson_dw_hdmi_remove,
+ .remove_new = meson_dw_hdmi_remove,
.driver = {
.name = DRIVER_NAME,
.of_match_table = meson_dw_hdmi_of_table,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 30/53] drm/meson: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-08 19:39 ` Martin Blumenstingl
-1 siblings, 0 replies; 261+ messages in thread
From: Martin Blumenstingl @ 2023-05-08 19:39 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, David Airlie, Daniel Vetter, Kevin Hilman,
Jerome Brunet, dri-devel, linux-amlogic, linux-arm-kernel, kernel
On Sun, May 7, 2023 at 6:26 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert meson drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 30/53] drm/meson: Convert to platform remove callback returning void
@ 2023-05-08 19:39 ` Martin Blumenstingl
0 siblings, 0 replies; 261+ messages in thread
From: Martin Blumenstingl @ 2023-05-08 19:39 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Neil Armstrong, kernel, Kevin Hilman, dri-devel, linux-amlogic,
linux-arm-kernel, Jerome Brunet
On Sun, May 7, 2023 at 6:26 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert meson drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 31/53] drm/msm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, David Airlie,
Daniel Vetter, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Joel, Fernandes, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson
Cc: Sean Paul, linux-arm-msm, dri-devel, freedreno, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the msm drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
drivers/gpu/drm/msm/msm_drv.c | 6 ++----
drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
10 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c
index c5c4c93b3689..c6f443ac7904 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -603,10 +603,9 @@ static int adreno_probe(struct platform_device *pdev)
return 0;
}
-static int adreno_remove(struct platform_device *pdev)
+static void adreno_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &a3xx_ops);
- return 0;
}
static void adreno_shutdown(struct platform_device *pdev)
@@ -721,7 +720,7 @@ static const struct dev_pm_ops adreno_pm_ops = {
static struct platform_driver adreno_driver = {
.probe = adreno_probe,
- .remove = adreno_remove,
+ .remove_new = adreno_remove,
.shutdown = adreno_shutdown,
.driver = {
.name = "adreno",
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9b5a04..918c8c4f8e3d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1240,11 +1240,9 @@ static int dpu_dev_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, dpu_kms_init);
}
-static int dpu_dev_remove(struct platform_device *pdev)
+static void dpu_dev_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
-
- return 0;
}
static int __maybe_unused dpu_runtime_suspend(struct device *dev)
@@ -1317,7 +1315,7 @@ MODULE_DEVICE_TABLE(of, dpu_dt_match);
static struct platform_driver dpu_driver = {
.probe = dpu_dev_probe,
- .remove = dpu_dev_remove,
+ .remove_new = dpu_dev_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "msm_dpu",
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 9a1a0769575d..727d20ef9f02 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -566,11 +566,9 @@ static int mdp4_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, mdp4_kms_init);
}
-static int mdp4_remove(struct platform_device *pdev)
+static void mdp4_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
-
- return 0;
}
static const struct of_device_id mdp4_dt_match[] = {
@@ -581,7 +579,7 @@ MODULE_DEVICE_TABLE(of, mdp4_dt_match);
static struct platform_driver mdp4_platform_driver = {
.probe = mdp4_probe,
- .remove = mdp4_remove,
+ .remove_new = mdp4_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "mdp4",
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 29ae5c9613f3..51b313b4da51 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -942,11 +942,10 @@ static int mdp5_dev_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, mdp5_kms_init);
}
-static int mdp5_dev_remove(struct platform_device *pdev)
+static void mdp5_dev_remove(struct platform_device *pdev)
{
DBG("");
component_master_del(&pdev->dev, &msm_drm_ops);
- return 0;
}
static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
@@ -987,7 +986,7 @@ MODULE_DEVICE_TABLE(of, mdp5_dt_match);
static struct platform_driver mdp5_driver = {
.probe = mdp5_dev_probe,
- .remove = mdp5_dev_remove,
+ .remove_new = mdp5_dev_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "msm_mdp",
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index bde1a7ce442f..3fec97ede90e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1347,7 +1347,7 @@ static int dp_display_probe(struct platform_device *pdev)
return rc;
}
-static int dp_display_remove(struct platform_device *pdev)
+static void dp_display_remove(struct platform_device *pdev)
{
struct dp_display_private *dp = dev_get_dp_display_private(&pdev->dev);
@@ -1355,8 +1355,6 @@ static int dp_display_remove(struct platform_device *pdev)
component_del(&pdev->dev, &dp_display_comp_ops);
platform_set_drvdata(pdev, NULL);
-
- return 0;
}
static int dp_pm_resume(struct device *dev)
@@ -1471,7 +1469,7 @@ static const struct dev_pm_ops dp_pm_ops = {
static struct platform_driver dp_display_driver = {
.probe = dp_display_probe,
- .remove = dp_display_remove,
+ .remove_new = dp_display_remove,
.driver = {
.name = "msm-dp-display",
.of_match_table = dp_dt_match,
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 31fdee2052be..c5d65f0a5140 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -162,14 +162,12 @@ static int dsi_dev_probe(struct platform_device *pdev)
return 0;
}
-static int dsi_dev_remove(struct platform_device *pdev)
+static void dsi_dev_remove(struct platform_device *pdev)
{
struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
DBG("");
dsi_destroy(msm_dsi);
-
- return 0;
}
static const struct of_device_id dt_match[] = {
@@ -186,7 +184,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
static struct platform_driver dsi_driver = {
.probe = dsi_dev_probe,
- .remove = dsi_dev_remove,
+ .remove_new = dsi_dev_remove,
.driver = {
.name = "msm_dsi",
.of_match_table = dt_match,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 3132105a2a43..884d2e142307 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -549,15 +549,13 @@ static int msm_hdmi_dev_probe(struct platform_device *pdev)
return ret;
}
-static int msm_hdmi_dev_remove(struct platform_device *pdev)
+static void msm_hdmi_dev_remove(struct platform_device *pdev)
{
struct hdmi *hdmi = dev_get_drvdata(&pdev->dev);
component_del(&pdev->dev, &msm_hdmi_ops);
msm_hdmi_put_phy(hdmi);
-
- return 0;
}
static const struct of_device_id msm_hdmi_dt_match[] = {
@@ -572,7 +570,7 @@ static const struct of_device_id msm_hdmi_dt_match[] = {
static struct platform_driver msm_hdmi_driver = {
.probe = msm_hdmi_dev_probe,
- .remove = msm_hdmi_dev_remove,
+ .remove_new = msm_hdmi_dev_remove,
.driver = {
.name = "hdmi_msm",
.of_match_table = msm_hdmi_dt_match,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
index 9780107e1cc9..52f45d6684b6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
@@ -176,11 +176,9 @@ static int msm_hdmi_phy_probe(struct platform_device *pdev)
return 0;
}
-static int msm_hdmi_phy_remove(struct platform_device *pdev)
+static void msm_hdmi_phy_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id msm_hdmi_phy_dt_match[] = {
@@ -199,7 +197,7 @@ static const struct of_device_id msm_hdmi_phy_dt_match[] = {
static struct platform_driver msm_hdmi_phy_platform_driver = {
.probe = msm_hdmi_phy_probe,
- .remove = msm_hdmi_phy_remove,
+ .remove_new = msm_hdmi_phy_remove,
.driver = {
.name = "msm_hdmi_phy",
.of_match_table = msm_hdmi_phy_dt_match,
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index aca48c868c14..8b1d097a82e9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1265,11 +1265,9 @@ static int msm_pdev_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, NULL);
}
-static int msm_pdev_remove(struct platform_device *pdev)
+static void msm_pdev_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
-
- return 0;
}
void msm_drv_shutdown(struct platform_device *pdev)
@@ -1290,7 +1288,7 @@ void msm_drv_shutdown(struct platform_device *pdev)
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
- .remove = msm_pdev_remove,
+ .remove_new = msm_pdev_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "msm",
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 02646e4bb4cd..b8567b369063 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -508,15 +508,13 @@ static int mdss_probe(struct platform_device *pdev)
return 0;
}
-static int mdss_remove(struct platform_device *pdev)
+static void mdss_remove(struct platform_device *pdev)
{
struct msm_mdss *mdss = platform_get_drvdata(pdev);
of_platform_depopulate(&pdev->dev);
msm_mdss_destroy(mdss);
-
- return 0;
}
static const struct of_device_id mdss_dt_match[] = {
@@ -540,7 +538,7 @@ MODULE_DEVICE_TABLE(of, mdss_dt_match);
static struct platform_driver mdss_platform_driver = {
.probe = mdss_probe,
- .remove = mdss_remove,
+ .remove_new = mdss_remove,
.driver = {
.name = "msm-mdss",
.of_match_table = mdss_dt_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 31/53] drm/msm: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Dmitry Baryshkov, David Airlie,
Daniel Vetter, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Joel, Fernandes, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson
Cc: linux-arm-msm, freedreno, Sean Paul, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the msm drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
drivers/gpu/drm/msm/msm_drv.c | 6 ++----
drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
10 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c b/drivers/gpu/drm/msm/adreno/adreno_device.c
index c5c4c93b3689..c6f443ac7904 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -603,10 +603,9 @@ static int adreno_probe(struct platform_device *pdev)
return 0;
}
-static int adreno_remove(struct platform_device *pdev)
+static void adreno_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &a3xx_ops);
- return 0;
}
static void adreno_shutdown(struct platform_device *pdev)
@@ -721,7 +720,7 @@ static const struct dev_pm_ops adreno_pm_ops = {
static struct platform_driver adreno_driver = {
.probe = adreno_probe,
- .remove = adreno_remove,
+ .remove_new = adreno_remove,
.shutdown = adreno_shutdown,
.driver = {
.name = "adreno",
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9b5a04..918c8c4f8e3d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1240,11 +1240,9 @@ static int dpu_dev_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, dpu_kms_init);
}
-static int dpu_dev_remove(struct platform_device *pdev)
+static void dpu_dev_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
-
- return 0;
}
static int __maybe_unused dpu_runtime_suspend(struct device *dev)
@@ -1317,7 +1315,7 @@ MODULE_DEVICE_TABLE(of, dpu_dt_match);
static struct platform_driver dpu_driver = {
.probe = dpu_dev_probe,
- .remove = dpu_dev_remove,
+ .remove_new = dpu_dev_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "msm_dpu",
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 9a1a0769575d..727d20ef9f02 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -566,11 +566,9 @@ static int mdp4_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, mdp4_kms_init);
}
-static int mdp4_remove(struct platform_device *pdev)
+static void mdp4_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
-
- return 0;
}
static const struct of_device_id mdp4_dt_match[] = {
@@ -581,7 +579,7 @@ MODULE_DEVICE_TABLE(of, mdp4_dt_match);
static struct platform_driver mdp4_platform_driver = {
.probe = mdp4_probe,
- .remove = mdp4_remove,
+ .remove_new = mdp4_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "mdp4",
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 29ae5c9613f3..51b313b4da51 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -942,11 +942,10 @@ static int mdp5_dev_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, mdp5_kms_init);
}
-static int mdp5_dev_remove(struct platform_device *pdev)
+static void mdp5_dev_remove(struct platform_device *pdev)
{
DBG("");
component_master_del(&pdev->dev, &msm_drm_ops);
- return 0;
}
static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
@@ -987,7 +986,7 @@ MODULE_DEVICE_TABLE(of, mdp5_dt_match);
static struct platform_driver mdp5_driver = {
.probe = mdp5_dev_probe,
- .remove = mdp5_dev_remove,
+ .remove_new = mdp5_dev_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "msm_mdp",
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index bde1a7ce442f..3fec97ede90e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1347,7 +1347,7 @@ static int dp_display_probe(struct platform_device *pdev)
return rc;
}
-static int dp_display_remove(struct platform_device *pdev)
+static void dp_display_remove(struct platform_device *pdev)
{
struct dp_display_private *dp = dev_get_dp_display_private(&pdev->dev);
@@ -1355,8 +1355,6 @@ static int dp_display_remove(struct platform_device *pdev)
component_del(&pdev->dev, &dp_display_comp_ops);
platform_set_drvdata(pdev, NULL);
-
- return 0;
}
static int dp_pm_resume(struct device *dev)
@@ -1471,7 +1469,7 @@ static const struct dev_pm_ops dp_pm_ops = {
static struct platform_driver dp_display_driver = {
.probe = dp_display_probe,
- .remove = dp_display_remove,
+ .remove_new = dp_display_remove,
.driver = {
.name = "msm-dp-display",
.of_match_table = dp_dt_match,
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 31fdee2052be..c5d65f0a5140 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -162,14 +162,12 @@ static int dsi_dev_probe(struct platform_device *pdev)
return 0;
}
-static int dsi_dev_remove(struct platform_device *pdev)
+static void dsi_dev_remove(struct platform_device *pdev)
{
struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
DBG("");
dsi_destroy(msm_dsi);
-
- return 0;
}
static const struct of_device_id dt_match[] = {
@@ -186,7 +184,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
static struct platform_driver dsi_driver = {
.probe = dsi_dev_probe,
- .remove = dsi_dev_remove,
+ .remove_new = dsi_dev_remove,
.driver = {
.name = "msm_dsi",
.of_match_table = dt_match,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 3132105a2a43..884d2e142307 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -549,15 +549,13 @@ static int msm_hdmi_dev_probe(struct platform_device *pdev)
return ret;
}
-static int msm_hdmi_dev_remove(struct platform_device *pdev)
+static void msm_hdmi_dev_remove(struct platform_device *pdev)
{
struct hdmi *hdmi = dev_get_drvdata(&pdev->dev);
component_del(&pdev->dev, &msm_hdmi_ops);
msm_hdmi_put_phy(hdmi);
-
- return 0;
}
static const struct of_device_id msm_hdmi_dt_match[] = {
@@ -572,7 +570,7 @@ static const struct of_device_id msm_hdmi_dt_match[] = {
static struct platform_driver msm_hdmi_driver = {
.probe = msm_hdmi_dev_probe,
- .remove = msm_hdmi_dev_remove,
+ .remove_new = msm_hdmi_dev_remove,
.driver = {
.name = "hdmi_msm",
.of_match_table = msm_hdmi_dt_match,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
index 9780107e1cc9..52f45d6684b6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
@@ -176,11 +176,9 @@ static int msm_hdmi_phy_probe(struct platform_device *pdev)
return 0;
}
-static int msm_hdmi_phy_remove(struct platform_device *pdev)
+static void msm_hdmi_phy_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id msm_hdmi_phy_dt_match[] = {
@@ -199,7 +197,7 @@ static const struct of_device_id msm_hdmi_phy_dt_match[] = {
static struct platform_driver msm_hdmi_phy_platform_driver = {
.probe = msm_hdmi_phy_probe,
- .remove = msm_hdmi_phy_remove,
+ .remove_new = msm_hdmi_phy_remove,
.driver = {
.name = "msm_hdmi_phy",
.of_match_table = msm_hdmi_phy_dt_match,
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index aca48c868c14..8b1d097a82e9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1265,11 +1265,9 @@ static int msm_pdev_probe(struct platform_device *pdev)
return msm_drv_probe(&pdev->dev, NULL);
}
-static int msm_pdev_remove(struct platform_device *pdev)
+static void msm_pdev_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
-
- return 0;
}
void msm_drv_shutdown(struct platform_device *pdev)
@@ -1290,7 +1288,7 @@ void msm_drv_shutdown(struct platform_device *pdev)
static struct platform_driver msm_platform_driver = {
.probe = msm_pdev_probe,
- .remove = msm_pdev_remove,
+ .remove_new = msm_pdev_remove,
.shutdown = msm_drv_shutdown,
.driver = {
.name = "msm",
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 02646e4bb4cd..b8567b369063 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -508,15 +508,13 @@ static int mdss_probe(struct platform_device *pdev)
return 0;
}
-static int mdss_remove(struct platform_device *pdev)
+static void mdss_remove(struct platform_device *pdev)
{
struct msm_mdss *mdss = platform_get_drvdata(pdev);
of_platform_depopulate(&pdev->dev);
msm_mdss_destroy(mdss);
-
- return 0;
}
static const struct of_device_id mdss_dt_match[] = {
@@ -540,7 +538,7 @@ MODULE_DEVICE_TABLE(of, mdss_dt_match);
static struct platform_driver mdss_platform_driver = {
.probe = mdss_probe,
- .remove = mdss_remove,
+ .remove_new = mdss_remove,
.driver = {
.name = "msm-mdss",
.of_match_table = mdss_dt_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 31/53] drm/msm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-20 23:56 ` Dmitry Baryshkov
-1 siblings, 0 replies; 261+ messages in thread
From: Dmitry Baryshkov @ 2023-05-20 23:56 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Clark, Abhinav Kumar, David Airlie,
Daniel Vetter, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Joel, Fernandes, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson
Cc: Sean Paul, linux-arm-msm, dri-devel, freedreno, kernel
On 07/05/2023 19:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the msm drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> 10 files changed, 20 insertions(+), 38 deletions(-)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 31/53] drm/msm: Convert to platform remove callback returning void
@ 2023-05-20 23:56 ` Dmitry Baryshkov
0 siblings, 0 replies; 261+ messages in thread
From: Dmitry Baryshkov @ 2023-05-20 23:56 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Clark, Abhinav Kumar, David Airlie,
Daniel Vetter, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Joel, Fernandes, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson
Cc: linux-arm-msm, freedreno, Sean Paul, kernel, dri-devel
On 07/05/2023 19:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the msm drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> 10 files changed, 20 insertions(+), 38 deletions(-)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 32/53] drm/mxsfb: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: Fabio Estevam, NXP Linux Team, dri-devel, linux-arm-kernel,
kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the mxsfb driver from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index cc2ceb301b96..748b023cfe83 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -232,7 +232,7 @@ static int lcdif_probe(struct platform_device *pdev)
return ret;
}
-static int lcdif_remove(struct platform_device *pdev)
+static void lcdif_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
@@ -240,8 +240,6 @@ static int lcdif_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(drm);
lcdif_unload(drm);
drm_dev_put(drm);
-
- return 0;
}
static void lcdif_shutdown(struct platform_device *pdev)
@@ -309,7 +307,7 @@ static const struct dev_pm_ops lcdif_pm_ops = {
static struct platform_driver lcdif_platform_driver = {
.probe = lcdif_probe,
- .remove = lcdif_remove,
+ .remove_new = lcdif_remove,
.shutdown = lcdif_shutdown,
.driver = {
.name = "imx-lcdif",
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index b3ab86ad1b36..31f3696f82af 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -377,7 +377,7 @@ static int mxsfb_probe(struct platform_device *pdev)
return ret;
}
-static int mxsfb_remove(struct platform_device *pdev)
+static void mxsfb_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
@@ -385,8 +385,6 @@ static int mxsfb_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(drm);
mxsfb_unload(drm);
drm_dev_put(drm);
-
- return 0;
}
static void mxsfb_shutdown(struct platform_device *pdev)
@@ -418,7 +416,7 @@ static const struct dev_pm_ops mxsfb_pm_ops = {
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
- .remove = mxsfb_remove,
+ .remove_new = mxsfb_remove,
.shutdown = mxsfb_shutdown,
.driver = {
.name = "mxsfb",
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 32/53] drm/mxsfb: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, David Airlie, Daniel Vetter, Shawn Guo,
Sascha Hauer
Cc: linux-arm-kernel, kernel, NXP Linux Team, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the mxsfb driver from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
index cc2ceb301b96..748b023cfe83 100644
--- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
+++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
@@ -232,7 +232,7 @@ static int lcdif_probe(struct platform_device *pdev)
return ret;
}
-static int lcdif_remove(struct platform_device *pdev)
+static void lcdif_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
@@ -240,8 +240,6 @@ static int lcdif_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(drm);
lcdif_unload(drm);
drm_dev_put(drm);
-
- return 0;
}
static void lcdif_shutdown(struct platform_device *pdev)
@@ -309,7 +307,7 @@ static const struct dev_pm_ops lcdif_pm_ops = {
static struct platform_driver lcdif_platform_driver = {
.probe = lcdif_probe,
- .remove = lcdif_remove,
+ .remove_new = lcdif_remove,
.shutdown = lcdif_shutdown,
.driver = {
.name = "imx-lcdif",
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index b3ab86ad1b36..31f3696f82af 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -377,7 +377,7 @@ static int mxsfb_probe(struct platform_device *pdev)
return ret;
}
-static int mxsfb_remove(struct platform_device *pdev)
+static void mxsfb_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
@@ -385,8 +385,6 @@ static int mxsfb_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(drm);
mxsfb_unload(drm);
drm_dev_put(drm);
-
- return 0;
}
static void mxsfb_shutdown(struct platform_device *pdev)
@@ -418,7 +416,7 @@ static const struct dev_pm_ops mxsfb_pm_ops = {
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
- .remove = mxsfb_remove,
+ .remove_new = mxsfb_remove,
.shutdown = mxsfb_shutdown,
.driver = {
.name = "mxsfb",
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread
* [Nouveau] [PATCH 33/53] drm/nouveau: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:25 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude Paul, David Airlie, Daniel Vetter
Cc: nouveau, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c b/drivers/gpu/drm/nouveau/nouveau_platform.c
index 23cd43a7fd19..bf2dc7567ea4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_platform.c
+++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
@@ -43,11 +43,10 @@ static int nouveau_platform_probe(struct platform_device *pdev)
return 0;
}
-static int nouveau_platform_remove(struct platform_device *pdev)
+static void nouveau_platform_remove(struct platform_device *pdev)
{
struct drm_device *dev = platform_get_drvdata(pdev);
nouveau_drm_device_remove(dev);
- return 0;
}
#if IS_ENABLED(CONFIG_OF)
@@ -93,5 +92,5 @@ struct platform_driver nouveau_platform_driver = {
.of_match_table = of_match_ptr(nouveau_platform_match),
},
.probe = nouveau_platform_probe,
- .remove = nouveau_platform_remove,
+ .remove_new = nouveau_platform_remove,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 33/53] drm/nouveau: Convert to platform remove callback returning void
@ 2023-05-07 16:25 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude Paul, David Airlie, Daniel Vetter
Cc: nouveau, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c b/drivers/gpu/drm/nouveau/nouveau_platform.c
index 23cd43a7fd19..bf2dc7567ea4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_platform.c
+++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
@@ -43,11 +43,10 @@ static int nouveau_platform_probe(struct platform_device *pdev)
return 0;
}
-static int nouveau_platform_remove(struct platform_device *pdev)
+static void nouveau_platform_remove(struct platform_device *pdev)
{
struct drm_device *dev = platform_get_drvdata(pdev);
nouveau_drm_device_remove(dev);
- return 0;
}
#if IS_ENABLED(CONFIG_OF)
@@ -93,5 +92,5 @@ struct platform_driver nouveau_platform_driver = {
.of_match_table = of_match_ptr(nouveau_platform_match),
},
.probe = nouveau_platform_probe,
- .remove = nouveau_platform_remove,
+ .remove_new = nouveau_platform_remove,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread
* [PATCH 34/53] drm/omap: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (36 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:40 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Tomi Valkeinen, David Airlie, Daniel Vetter, Laurent Pinchart,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Jani Nikula,
Ville Syrjälä, Sam Ravnborg
Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the omap drm driver from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
8 files changed, 17 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c
index aacad5045e95..c26aab4939fa 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4858,10 +4858,9 @@ static int dispc_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &dispc_component_ops);
}
-static int dispc_remove(struct platform_device *pdev)
+static void dispc_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &dispc_component_ops);
- return 0;
}
static __maybe_unused int dispc_runtime_suspend(struct device *dev)
@@ -4913,7 +4912,7 @@ static const struct dev_pm_ops dispc_pm_ops = {
struct platform_driver omap_dispchw_driver = {
.probe = dispc_probe,
- .remove = dispc_remove,
+ .remove_new = dispc_remove,
.driver = {
.name = "omapdss_dispc",
.pm = &dispc_pm_ops,
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 4c1084eb0175..ea63c64d3a1a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5044,7 +5044,7 @@ static int dsi_probe(struct platform_device *pdev)
return r;
}
-static int dsi_remove(struct platform_device *pdev)
+static void dsi_remove(struct platform_device *pdev)
{
struct dsi_data *dsi = platform_get_drvdata(pdev);
@@ -5060,8 +5060,6 @@ static int dsi_remove(struct platform_device *pdev)
regulator_disable(dsi->vdds_dsi_reg);
dsi->vdds_dsi_enabled = false;
}
-
- return 0;
}
static __maybe_unused int dsi_runtime_suspend(struct device *dev)
@@ -5095,7 +5093,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
struct platform_driver omap_dsihw_driver = {
.probe = dsi_probe,
- .remove = dsi_remove,
+ .remove_new = dsi_remove,
.driver = {
.name = "omapdss_dsi",
.pm = &dsi_pm_ops,
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c b/drivers/gpu/drm/omapdrm/dss/dss.c
index c4febb861910..02955f976845 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1532,7 +1532,7 @@ static int dss_probe(struct platform_device *pdev)
return r;
}
-static int dss_remove(struct platform_device *pdev)
+static void dss_remove(struct platform_device *pdev)
{
struct dss_device *dss = platform_get_drvdata(pdev);
@@ -1557,8 +1557,6 @@ static int dss_remove(struct platform_device *pdev)
dss_put_clocks(dss);
kfree(dss);
-
- return 0;
}
static void dss_shutdown(struct platform_device *pdev)
@@ -1607,7 +1605,7 @@ static const struct dev_pm_ops dss_pm_ops = {
struct platform_driver omap_dsshw_driver = {
.probe = dss_probe,
- .remove = dss_remove,
+ .remove_new = dss_remove,
.shutdown = dss_shutdown,
.driver = {
.name = "omapdss_dss",
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index a8a75dc24751..a26b77d99d52 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -824,7 +824,7 @@ static int hdmi4_probe(struct platform_device *pdev)
return r;
}
-static int hdmi4_remove(struct platform_device *pdev)
+static void hdmi4_remove(struct platform_device *pdev)
{
struct omap_hdmi *hdmi = platform_get_drvdata(pdev);
@@ -835,7 +835,6 @@ static int hdmi4_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
kfree(hdmi);
- return 0;
}
static const struct of_device_id hdmi_of_match[] = {
@@ -845,7 +844,7 @@ static const struct of_device_id hdmi_of_match[] = {
struct platform_driver omapdss_hdmi4hw_driver = {
.probe = hdmi4_probe,
- .remove = hdmi4_remove,
+ .remove_new = hdmi4_remove,
.driver = {
.name = "omapdss_hdmi",
.of_match_table = hdmi_of_match,
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index 868712cd8a3a..e6611c683857 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -798,7 +798,7 @@ static int hdmi5_probe(struct platform_device *pdev)
return r;
}
-static int hdmi5_remove(struct platform_device *pdev)
+static void hdmi5_remove(struct platform_device *pdev)
{
struct omap_hdmi *hdmi = platform_get_drvdata(pdev);
@@ -809,7 +809,6 @@ static int hdmi5_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
kfree(hdmi);
- return 0;
}
static const struct of_device_id hdmi_of_match[] = {
@@ -820,7 +819,7 @@ static const struct of_device_id hdmi_of_match[] = {
struct platform_driver omapdss_hdmi5hw_driver = {
.probe = hdmi5_probe,
- .remove = hdmi5_remove,
+ .remove_new = hdmi5_remove,
.driver = {
.name = "omapdss_hdmi5",
.of_match_table = hdmi_of_match,
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c b/drivers/gpu/drm/omapdrm/dss/venc.c
index 4480b69ab5a7..f163d52a7c7d 100644
--- a/drivers/gpu/drm/omapdrm/dss/venc.c
+++ b/drivers/gpu/drm/omapdrm/dss/venc.c
@@ -865,7 +865,7 @@ static int venc_probe(struct platform_device *pdev)
return r;
}
-static int venc_remove(struct platform_device *pdev)
+static void venc_remove(struct platform_device *pdev)
{
struct venc_device *venc = platform_get_drvdata(pdev);
@@ -876,7 +876,6 @@ static int venc_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
kfree(venc);
- return 0;
}
static __maybe_unused int venc_runtime_suspend(struct device *dev)
@@ -913,7 +912,7 @@ static const struct of_device_id venc_of_match[] = {
struct platform_driver omap_venchw_driver = {
.probe = venc_probe,
- .remove = venc_remove,
+ .remove_new = venc_remove,
.driver = {
.name = "omapdss_venc",
.pm = &venc_pm_ops,
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 61a27dd7392e..9753c1e1f994 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -723,7 +723,7 @@ bool dmm_is_available(void)
return omap_dmm ? true : false;
}
-static int omap_dmm_remove(struct platform_device *dev)
+static void omap_dmm_remove(struct platform_device *dev)
{
struct tiler_block *block, *_block;
int i;
@@ -763,8 +763,6 @@ static int omap_dmm_remove(struct platform_device *dev)
kfree(omap_dmm);
omap_dmm = NULL;
}
-
- return 0;
}
static int omap_dmm_probe(struct platform_device *dev)
@@ -982,8 +980,7 @@ static int omap_dmm_probe(struct platform_device *dev)
return 0;
fail:
- if (omap_dmm_remove(dev))
- dev_err(&dev->dev, "cleanup failed\n");
+ omap_dmm_remove(dev);
return ret;
}
@@ -1213,7 +1210,7 @@ static const struct of_device_id dmm_of_match[] = {
struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
- .remove = omap_dmm_remove,
+ .remove_new = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
index 699ed814e021..fcab66fbcfbf 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -826,14 +826,12 @@ static int pdev_probe(struct platform_device *pdev)
return ret;
}
-static int pdev_remove(struct platform_device *pdev)
+static void pdev_remove(struct platform_device *pdev)
{
struct omap_drm_private *priv = platform_get_drvdata(pdev);
omapdrm_cleanup(priv);
kfree(priv);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -864,7 +862,7 @@ static struct platform_driver pdev = {
.pm = &omapdrm_pm_ops,
},
.probe = pdev_probe,
- .remove = pdev_remove,
+ .remove_new = pdev_remove,
};
static struct platform_driver * const drivers[] = {
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 34/53] drm/omap: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 34/53] drm/omap: " Uwe Kleine-König
@ 2023-05-08 2:40 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Tomi Valkeinen, Arnd Bergmann, Guo Zhengkui, Jani Nikula,
Liang He, Yuan Can, dri-devel, Sam Ravnborg, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:57PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the omap drm driver from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> 8 files changed, 17 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index aacad5045e95..c26aab4939fa 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -4858,10 +4858,9 @@ static int dispc_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &dispc_component_ops);
> }
>
> -static int dispc_remove(struct platform_device *pdev)
> +static void dispc_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &dispc_component_ops);
> - return 0;
> }
>
> static __maybe_unused int dispc_runtime_suspend(struct device *dev)
> @@ -4913,7 +4912,7 @@ static const struct dev_pm_ops dispc_pm_ops = {
>
> struct platform_driver omap_dispchw_driver = {
> .probe = dispc_probe,
> - .remove = dispc_remove,
> + .remove_new = dispc_remove,
> .driver = {
> .name = "omapdss_dispc",
> .pm = &dispc_pm_ops,
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 4c1084eb0175..ea63c64d3a1a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -5044,7 +5044,7 @@ static int dsi_probe(struct platform_device *pdev)
> return r;
> }
>
> -static int dsi_remove(struct platform_device *pdev)
> +static void dsi_remove(struct platform_device *pdev)
> {
> struct dsi_data *dsi = platform_get_drvdata(pdev);
>
> @@ -5060,8 +5060,6 @@ static int dsi_remove(struct platform_device *pdev)
> regulator_disable(dsi->vdds_dsi_reg);
> dsi->vdds_dsi_enabled = false;
> }
> -
> - return 0;
> }
>
> static __maybe_unused int dsi_runtime_suspend(struct device *dev)
> @@ -5095,7 +5093,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
>
> struct platform_driver omap_dsihw_driver = {
> .probe = dsi_probe,
> - .remove = dsi_remove,
> + .remove_new = dsi_remove,
> .driver = {
> .name = "omapdss_dsi",
> .pm = &dsi_pm_ops,
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c b/drivers/gpu/drm/omapdrm/dss/dss.c
> index c4febb861910..02955f976845 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> @@ -1532,7 +1532,7 @@ static int dss_probe(struct platform_device *pdev)
> return r;
> }
>
> -static int dss_remove(struct platform_device *pdev)
> +static void dss_remove(struct platform_device *pdev)
> {
> struct dss_device *dss = platform_get_drvdata(pdev);
>
> @@ -1557,8 +1557,6 @@ static int dss_remove(struct platform_device *pdev)
> dss_put_clocks(dss);
>
> kfree(dss);
> -
> - return 0;
> }
>
> static void dss_shutdown(struct platform_device *pdev)
> @@ -1607,7 +1605,7 @@ static const struct dev_pm_ops dss_pm_ops = {
>
> struct platform_driver omap_dsshw_driver = {
> .probe = dss_probe,
> - .remove = dss_remove,
> + .remove_new = dss_remove,
> .shutdown = dss_shutdown,
> .driver = {
> .name = "omapdss_dss",
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index a8a75dc24751..a26b77d99d52 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -824,7 +824,7 @@ static int hdmi4_probe(struct platform_device *pdev)
> return r;
> }
>
> -static int hdmi4_remove(struct platform_device *pdev)
> +static void hdmi4_remove(struct platform_device *pdev)
> {
> struct omap_hdmi *hdmi = platform_get_drvdata(pdev);
>
> @@ -835,7 +835,6 @@ static int hdmi4_remove(struct platform_device *pdev)
> pm_runtime_disable(&pdev->dev);
>
> kfree(hdmi);
> - return 0;
> }
>
> static const struct of_device_id hdmi_of_match[] = {
> @@ -845,7 +844,7 @@ static const struct of_device_id hdmi_of_match[] = {
>
> struct platform_driver omapdss_hdmi4hw_driver = {
> .probe = hdmi4_probe,
> - .remove = hdmi4_remove,
> + .remove_new = hdmi4_remove,
> .driver = {
> .name = "omapdss_hdmi",
> .of_match_table = hdmi_of_match,
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> index 868712cd8a3a..e6611c683857 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
> @@ -798,7 +798,7 @@ static int hdmi5_probe(struct platform_device *pdev)
> return r;
> }
>
> -static int hdmi5_remove(struct platform_device *pdev)
> +static void hdmi5_remove(struct platform_device *pdev)
> {
> struct omap_hdmi *hdmi = platform_get_drvdata(pdev);
>
> @@ -809,7 +809,6 @@ static int hdmi5_remove(struct platform_device *pdev)
> pm_runtime_disable(&pdev->dev);
>
> kfree(hdmi);
> - return 0;
> }
>
> static const struct of_device_id hdmi_of_match[] = {
> @@ -820,7 +819,7 @@ static const struct of_device_id hdmi_of_match[] = {
>
> struct platform_driver omapdss_hdmi5hw_driver = {
> .probe = hdmi5_probe,
> - .remove = hdmi5_remove,
> + .remove_new = hdmi5_remove,
> .driver = {
> .name = "omapdss_hdmi5",
> .of_match_table = hdmi_of_match,
> diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c b/drivers/gpu/drm/omapdrm/dss/venc.c
> index 4480b69ab5a7..f163d52a7c7d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/venc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/venc.c
> @@ -865,7 +865,7 @@ static int venc_probe(struct platform_device *pdev)
> return r;
> }
>
> -static int venc_remove(struct platform_device *pdev)
> +static void venc_remove(struct platform_device *pdev)
> {
> struct venc_device *venc = platform_get_drvdata(pdev);
>
> @@ -876,7 +876,6 @@ static int venc_remove(struct platform_device *pdev)
> pm_runtime_disable(&pdev->dev);
>
> kfree(venc);
> - return 0;
> }
>
> static __maybe_unused int venc_runtime_suspend(struct device *dev)
> @@ -913,7 +912,7 @@ static const struct of_device_id venc_of_match[] = {
>
> struct platform_driver omap_venchw_driver = {
> .probe = venc_probe,
> - .remove = venc_remove,
> + .remove_new = venc_remove,
> .driver = {
> .name = "omapdss_venc",
> .pm = &venc_pm_ops,
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 61a27dd7392e..9753c1e1f994 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -723,7 +723,7 @@ bool dmm_is_available(void)
> return omap_dmm ? true : false;
> }
>
> -static int omap_dmm_remove(struct platform_device *dev)
> +static void omap_dmm_remove(struct platform_device *dev)
> {
> struct tiler_block *block, *_block;
> int i;
> @@ -763,8 +763,6 @@ static int omap_dmm_remove(struct platform_device *dev)
> kfree(omap_dmm);
> omap_dmm = NULL;
> }
> -
> - return 0;
> }
>
> static int omap_dmm_probe(struct platform_device *dev)
> @@ -982,8 +980,7 @@ static int omap_dmm_probe(struct platform_device *dev)
> return 0;
>
> fail:
> - if (omap_dmm_remove(dev))
> - dev_err(&dev->dev, "cleanup failed\n");
> + omap_dmm_remove(dev);
> return ret;
> }
>
> @@ -1213,7 +1210,7 @@ static const struct of_device_id dmm_of_match[] = {
>
> struct platform_driver omap_dmm_driver = {
> .probe = omap_dmm_probe,
> - .remove = omap_dmm_remove,
> + .remove_new = omap_dmm_remove,
> .driver = {
> .owner = THIS_MODULE,
> .name = DMM_DRIVER_NAME,
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 699ed814e021..fcab66fbcfbf 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -826,14 +826,12 @@ static int pdev_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int pdev_remove(struct platform_device *pdev)
> +static void pdev_remove(struct platform_device *pdev)
> {
> struct omap_drm_private *priv = platform_get_drvdata(pdev);
>
> omapdrm_cleanup(priv);
> kfree(priv);
> -
> - return 0;
> }
>
> #ifdef CONFIG_PM_SLEEP
> @@ -864,7 +862,7 @@ static struct platform_driver pdev = {
> .pm = &omapdrm_pm_ops,
> },
> .probe = pdev_probe,
> - .remove = pdev_remove,
> + .remove_new = pdev_remove,
> };
>
> static struct platform_driver * const drivers[] = {
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 35/53] drm/panel: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (37 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-08 2:43 ` Laurent Pinchart
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Laurent Pinchart, Thierry Reding, David Airlie, Daniel Vetter
Cc: Sam Ravnborg, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the drm panel drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
drivers/gpu/drm/panel/panel-simple.c | 6 ++----
4 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c
index de8758c30e6e..b47c3a679be0 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -228,15 +228,13 @@ static int panel_lvds_probe(struct platform_device *pdev)
return 0;
}
-static int panel_lvds_remove(struct platform_device *pdev)
+static void panel_lvds_remove(struct platform_device *pdev)
{
struct panel_lvds *lvds = platform_get_drvdata(pdev);
drm_panel_remove(&lvds->panel);
drm_panel_disable(&lvds->panel);
-
- return 0;
}
static const struct of_device_id panel_lvds_of_table[] = {
@@ -248,7 +246,7 @@ MODULE_DEVICE_TABLE(of, panel_lvds_of_table);
static struct platform_driver panel_lvds_driver = {
.probe = panel_lvds_probe,
- .remove = panel_lvds_remove,
+ .remove_new = panel_lvds_remove,
.driver = {
.name = "panel-lvds",
.of_match_table = panel_lvds_of_table,
diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
index 76160e5d43bd..5c3d9f7fc358 100644
--- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
+++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
@@ -266,14 +266,12 @@ static int seiko_panel_probe(struct device *dev,
return 0;
}
-static int seiko_panel_remove(struct platform_device *pdev)
+static void seiko_panel_remove(struct platform_device *pdev)
{
struct seiko_panel *panel = platform_get_drvdata(pdev);
drm_panel_remove(&panel->base);
drm_panel_disable(&panel->base);
-
- return 0;
}
static void seiko_panel_shutdown(struct platform_device *pdev)
@@ -335,7 +333,7 @@ static struct platform_driver seiko_panel_platform_driver = {
.of_match_table = platform_of_match,
},
.probe = seiko_panel_platform_probe,
- .remove = seiko_panel_remove,
+ .remove_new = seiko_panel_remove,
.shutdown = seiko_panel_shutdown,
};
module_platform_driver(seiko_panel_platform_driver);
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
index a07d0f6c3e69..76bd9e810827 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
@@ -189,15 +189,13 @@ static int ls037v7dw01_probe(struct platform_device *pdev)
return 0;
}
-static int ls037v7dw01_remove(struct platform_device *pdev)
+static void ls037v7dw01_remove(struct platform_device *pdev)
{
struct ls037v7dw01_panel *lcd = platform_get_drvdata(pdev);
drm_panel_remove(&lcd->panel);
drm_panel_disable(&lcd->panel);
drm_panel_unprepare(&lcd->panel);
-
- return 0;
}
static const struct of_device_id ls037v7dw01_of_match[] = {
@@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, ls037v7dw01_of_match);
static struct platform_driver ls037v7dw01_driver = {
.probe = ls037v7dw01_probe,
- .remove = ls037v7dw01_remove,
+ .remove_new = ls037v7dw01_remove,
.driver = {
.name = "panel-sharp-ls037v7dw01",
.of_match_table = ls037v7dw01_of_match,
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 065f378bba9d..1274eb95cf86 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4335,11 +4335,9 @@ static int panel_simple_platform_probe(struct platform_device *pdev)
return panel_simple_probe(&pdev->dev, id->data);
}
-static int panel_simple_platform_remove(struct platform_device *pdev)
+static void panel_simple_platform_remove(struct platform_device *pdev)
{
panel_simple_remove(&pdev->dev);
-
- return 0;
}
static void panel_simple_platform_shutdown(struct platform_device *pdev)
@@ -4360,7 +4358,7 @@ static struct platform_driver panel_simple_platform_driver = {
.pm = &panel_simple_pm_ops,
},
.probe = panel_simple_platform_probe,
- .remove = panel_simple_platform_remove,
+ .remove_new = panel_simple_platform_remove,
.shutdown = panel_simple_platform_shutdown,
};
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 35/53] drm/panel: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 35/53] drm/panel: " Uwe Kleine-König
@ 2023-05-08 2:43 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:43 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: dri-devel, Thierry Reding, kernel, Sam Ravnborg
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:25:58PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the drm panel drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> 4 files changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c
> index de8758c30e6e..b47c3a679be0 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -228,15 +228,13 @@ static int panel_lvds_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int panel_lvds_remove(struct platform_device *pdev)
> +static void panel_lvds_remove(struct platform_device *pdev)
> {
> struct panel_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_panel_remove(&lvds->panel);
>
> drm_panel_disable(&lvds->panel);
> -
> - return 0;
> }
>
> static const struct of_device_id panel_lvds_of_table[] = {
> @@ -248,7 +246,7 @@ MODULE_DEVICE_TABLE(of, panel_lvds_of_table);
>
> static struct platform_driver panel_lvds_driver = {
> .probe = panel_lvds_probe,
> - .remove = panel_lvds_remove,
> + .remove_new = panel_lvds_remove,
> .driver = {
> .name = "panel-lvds",
> .of_match_table = panel_lvds_of_table,
> diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> index 76160e5d43bd..5c3d9f7fc358 100644
> --- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> +++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> @@ -266,14 +266,12 @@ static int seiko_panel_probe(struct device *dev,
> return 0;
> }
>
> -static int seiko_panel_remove(struct platform_device *pdev)
> +static void seiko_panel_remove(struct platform_device *pdev)
> {
> struct seiko_panel *panel = platform_get_drvdata(pdev);
>
> drm_panel_remove(&panel->base);
> drm_panel_disable(&panel->base);
> -
> - return 0;
> }
>
> static void seiko_panel_shutdown(struct platform_device *pdev)
> @@ -335,7 +333,7 @@ static struct platform_driver seiko_panel_platform_driver = {
> .of_match_table = platform_of_match,
> },
> .probe = seiko_panel_platform_probe,
> - .remove = seiko_panel_remove,
> + .remove_new = seiko_panel_remove,
> .shutdown = seiko_panel_shutdown,
> };
> module_platform_driver(seiko_panel_platform_driver);
> diff --git a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> index a07d0f6c3e69..76bd9e810827 100644
> --- a/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> +++ b/drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c
> @@ -189,15 +189,13 @@ static int ls037v7dw01_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int ls037v7dw01_remove(struct platform_device *pdev)
> +static void ls037v7dw01_remove(struct platform_device *pdev)
> {
> struct ls037v7dw01_panel *lcd = platform_get_drvdata(pdev);
>
> drm_panel_remove(&lcd->panel);
> drm_panel_disable(&lcd->panel);
> drm_panel_unprepare(&lcd->panel);
> -
> - return 0;
> }
>
> static const struct of_device_id ls037v7dw01_of_match[] = {
> @@ -209,7 +207,7 @@ MODULE_DEVICE_TABLE(of, ls037v7dw01_of_match);
>
> static struct platform_driver ls037v7dw01_driver = {
> .probe = ls037v7dw01_probe,
> - .remove = ls037v7dw01_remove,
> + .remove_new = ls037v7dw01_remove,
> .driver = {
> .name = "panel-sharp-ls037v7dw01",
> .of_match_table = ls037v7dw01_of_match,
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 065f378bba9d..1274eb95cf86 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -4335,11 +4335,9 @@ static int panel_simple_platform_probe(struct platform_device *pdev)
> return panel_simple_probe(&pdev->dev, id->data);
> }
>
> -static int panel_simple_platform_remove(struct platform_device *pdev)
> +static void panel_simple_platform_remove(struct platform_device *pdev)
> {
> panel_simple_remove(&pdev->dev);
> -
> - return 0;
> }
>
> static void panel_simple_platform_shutdown(struct platform_device *pdev)
> @@ -4360,7 +4358,7 @@ static struct platform_driver panel_simple_platform_driver = {
> .pm = &panel_simple_pm_ops,
> },
> .probe = panel_simple_platform_probe,
> - .remove = panel_simple_platform_remove,
> + .remove_new = panel_simple_platform_remove,
> .shutdown = panel_simple_platform_shutdown,
> };
>
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 36/53] drm/panfrost: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (38 preceding siblings ...)
(?)
@ 2023-05-07 16:25 ` Uwe Kleine-König
2023-05-10 16:05 ` Steven Price
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:25 UTC (permalink / raw)
To: Rob Herring, Tomeu Vizoso, David Airlie, Daniel Vetter
Cc: kernel, Alyssa Rosenzweig, dri-devel, Steven Price
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index abb0dadd8f63..adaacc8c39d7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -618,7 +618,7 @@ static int panfrost_probe(struct platform_device *pdev)
return err;
}
-static int panfrost_remove(struct platform_device *pdev)
+static void panfrost_remove(struct platform_device *pdev)
{
struct panfrost_device *pfdev = platform_get_drvdata(pdev);
struct drm_device *ddev = pfdev->ddev;
@@ -632,7 +632,6 @@ static int panfrost_remove(struct platform_device *pdev)
pm_runtime_set_suspended(pfdev->dev);
drm_dev_put(ddev);
- return 0;
}
/*
@@ -687,7 +686,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
static struct platform_driver panfrost_driver = {
.probe = panfrost_probe,
- .remove = panfrost_remove,
+ .remove_new = panfrost_remove,
.driver = {
.name = "panfrost",
.pm = pm_ptr(&panfrost_pm_ops),
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 36/53] drm/panfrost: Convert to platform remove callback returning void
2023-05-07 16:25 ` [PATCH 36/53] drm/panfrost: " Uwe Kleine-König
@ 2023-05-10 16:05 ` Steven Price
0 siblings, 0 replies; 261+ messages in thread
From: Steven Price @ 2023-05-10 16:05 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Tomeu Vizoso, David Airlie,
Daniel Vetter
Cc: kernel, Alyssa Rosenzweig, dri-devel
On 07/05/2023 17:25, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Steven Price <steven.price@arm.com>
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index abb0dadd8f63..adaacc8c39d7 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -618,7 +618,7 @@ static int panfrost_probe(struct platform_device *pdev)
> return err;
> }
>
> -static int panfrost_remove(struct platform_device *pdev)
> +static void panfrost_remove(struct platform_device *pdev)
> {
> struct panfrost_device *pfdev = platform_get_drvdata(pdev);
> struct drm_device *ddev = pfdev->ddev;
> @@ -632,7 +632,6 @@ static int panfrost_remove(struct platform_device *pdev)
> pm_runtime_set_suspended(pfdev->dev);
>
> drm_dev_put(ddev);
> - return 0;
> }
>
> /*
> @@ -687,7 +686,7 @@ MODULE_DEVICE_TABLE(of, dt_match);
>
> static struct platform_driver panfrost_driver = {
> .probe = panfrost_probe,
> - .remove = panfrost_remove,
> + .remove_new = panfrost_remove,
> .driver = {
> .name = "panfrost",
> .pm = pm_ptr(&panfrost_pm_ops),
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 37/53] drm/rcar-du: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, David Airlie, Daniel Vetter
Cc: dri-devel, linux-renesas-soc, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the rcar-du drm driver from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
6 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index e2a67dda4658..26a2f5ad8ee5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -187,11 +187,9 @@ static int rcar_cmm_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_cmm_remove(struct platform_device *pdev)
+static void rcar_cmm_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id rcar_cmm_of_table[] = {
@@ -203,7 +201,7 @@ MODULE_DEVICE_TABLE(of, rcar_cmm_of_table);
static struct platform_driver rcar_cmm_platform_driver = {
.probe = rcar_cmm_probe,
- .remove = rcar_cmm_remove,
+ .remove_new = rcar_cmm_remove,
.driver = {
.name = "rcar-cmm",
.of_match_table = rcar_cmm_of_table,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index b9a94c5260e9..4a6bf50b5c49 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -685,7 +685,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_du_pm_ops,
* Platform driver
*/
-static int rcar_du_remove(struct platform_device *pdev)
+static void rcar_du_remove(struct platform_device *pdev)
{
struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
struct drm_device *ddev = &rcdu->ddev;
@@ -694,8 +694,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(ddev);
drm_kms_helper_poll_fini(ddev);
-
- return 0;
}
static void rcar_du_shutdown(struct platform_device *pdev)
@@ -776,7 +774,7 @@ static int rcar_du_probe(struct platform_device *pdev)
static struct platform_driver rcar_du_platform_driver = {
.probe = rcar_du_probe,
- .remove = rcar_du_remove,
+ .remove_new = rcar_du_remove,
.shutdown = rcar_du_shutdown,
.driver = {
.name = "rcar-du",
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
index 18ed14911b98..119d69d20b23 100644
--- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -93,13 +93,11 @@ static int rcar_dw_hdmi_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_dw_hdmi_remove(struct platform_device *pdev)
+static void rcar_dw_hdmi_remove(struct platform_device *pdev)
{
struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
dw_hdmi_remove(hdmi);
-
- return 0;
}
static const struct of_device_id rcar_dw_hdmi_of_table[] = {
@@ -110,7 +108,7 @@ MODULE_DEVICE_TABLE(of, rcar_dw_hdmi_of_table);
static struct platform_driver rcar_dw_hdmi_platform_driver = {
.probe = rcar_dw_hdmi_probe,
- .remove = rcar_dw_hdmi_remove,
+ .remove_new = rcar_dw_hdmi_remove,
.driver = {
.name = "rcar-dw-hdmi",
.of_match_table = rcar_dw_hdmi_of_table,
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 260ea5d8624e..86d2ac204568 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -890,15 +890,13 @@ static int rcar_lvds_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_lvds_remove(struct platform_device *pdev)
+static void rcar_lvds_remove(struct platform_device *pdev)
{
struct rcar_lvds *lvds = platform_get_drvdata(pdev);
drm_bridge_remove(&lvds->bridge);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct rcar_lvds_device_info rcar_lvds_gen2_info = {
@@ -994,7 +992,7 @@ static const struct dev_pm_ops rcar_lvds_pm_ops = {
static struct platform_driver rcar_lvds_platform_driver = {
.probe = rcar_lvds_probe,
- .remove = rcar_lvds_remove,
+ .remove_new = rcar_lvds_remove,
.driver = {
.name = "rcar-lvds",
.pm = &rcar_lvds_pm_ops,
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index e10e4d4b89a2..305123a671c6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -1044,13 +1044,11 @@ static int rcar_mipi_dsi_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_mipi_dsi_remove(struct platform_device *pdev)
+static void rcar_mipi_dsi_remove(struct platform_device *pdev)
{
struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
static const struct rcar_mipi_dsi_device_info v3u_data = {
@@ -1093,7 +1091,7 @@ MODULE_DEVICE_TABLE(of, rcar_mipi_dsi_of_table);
static struct platform_driver rcar_mipi_dsi_platform_driver = {
.probe = rcar_mipi_dsi_probe,
- .remove = rcar_mipi_dsi_remove,
+ .remove_new = rcar_mipi_dsi_remove,
.driver = {
.name = "rcar-mipi-dsi",
.of_match_table = rcar_mipi_dsi_of_table,
diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
index aa95b85a2964..a97fc4c5d1c8 100644
--- a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
@@ -782,14 +782,12 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int rzg2l_mipi_dsi_remove(struct platform_device *pdev)
+static void rzg2l_mipi_dsi_remove(struct platform_device *pdev)
{
struct rzg2l_mipi_dsi *dsi = platform_get_drvdata(pdev);
mipi_dsi_host_unregister(&dsi->host);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
@@ -801,7 +799,7 @@ MODULE_DEVICE_TABLE(of, rzg2l_mipi_dsi_of_table);
static struct platform_driver rzg2l_mipi_dsi_platform_driver = {
.probe = rzg2l_mipi_dsi_probe,
- .remove = rzg2l_mipi_dsi_remove,
+ .remove_new = rzg2l_mipi_dsi_remove,
.driver = {
.name = "rzg2l-mipi-dsi",
.pm = &rzg2l_mipi_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 37/53] drm/rcar-du: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, David Airlie, Daniel Vetter
Cc: linux-renesas-soc, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the rcar-du drm driver from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
6 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c b/drivers/gpu/drm/rcar-du/rcar_cmm.c
index e2a67dda4658..26a2f5ad8ee5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
+++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
@@ -187,11 +187,9 @@ static int rcar_cmm_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_cmm_remove(struct platform_device *pdev)
+static void rcar_cmm_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id rcar_cmm_of_table[] = {
@@ -203,7 +201,7 @@ MODULE_DEVICE_TABLE(of, rcar_cmm_of_table);
static struct platform_driver rcar_cmm_platform_driver = {
.probe = rcar_cmm_probe,
- .remove = rcar_cmm_remove,
+ .remove_new = rcar_cmm_remove,
.driver = {
.name = "rcar-cmm",
.of_match_table = rcar_cmm_of_table,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index b9a94c5260e9..4a6bf50b5c49 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -685,7 +685,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_du_pm_ops,
* Platform driver
*/
-static int rcar_du_remove(struct platform_device *pdev)
+static void rcar_du_remove(struct platform_device *pdev)
{
struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
struct drm_device *ddev = &rcdu->ddev;
@@ -694,8 +694,6 @@ static int rcar_du_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(ddev);
drm_kms_helper_poll_fini(ddev);
-
- return 0;
}
static void rcar_du_shutdown(struct platform_device *pdev)
@@ -776,7 +774,7 @@ static int rcar_du_probe(struct platform_device *pdev)
static struct platform_driver rcar_du_platform_driver = {
.probe = rcar_du_probe,
- .remove = rcar_du_remove,
+ .remove_new = rcar_du_remove,
.shutdown = rcar_du_shutdown,
.driver = {
.name = "rcar-du",
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
index 18ed14911b98..119d69d20b23 100644
--- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -93,13 +93,11 @@ static int rcar_dw_hdmi_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_dw_hdmi_remove(struct platform_device *pdev)
+static void rcar_dw_hdmi_remove(struct platform_device *pdev)
{
struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
dw_hdmi_remove(hdmi);
-
- return 0;
}
static const struct of_device_id rcar_dw_hdmi_of_table[] = {
@@ -110,7 +108,7 @@ MODULE_DEVICE_TABLE(of, rcar_dw_hdmi_of_table);
static struct platform_driver rcar_dw_hdmi_platform_driver = {
.probe = rcar_dw_hdmi_probe,
- .remove = rcar_dw_hdmi_remove,
+ .remove_new = rcar_dw_hdmi_remove,
.driver = {
.name = "rcar-dw-hdmi",
.of_match_table = rcar_dw_hdmi_of_table,
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 260ea5d8624e..86d2ac204568 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -890,15 +890,13 @@ static int rcar_lvds_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_lvds_remove(struct platform_device *pdev)
+static void rcar_lvds_remove(struct platform_device *pdev)
{
struct rcar_lvds *lvds = platform_get_drvdata(pdev);
drm_bridge_remove(&lvds->bridge);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct rcar_lvds_device_info rcar_lvds_gen2_info = {
@@ -994,7 +992,7 @@ static const struct dev_pm_ops rcar_lvds_pm_ops = {
static struct platform_driver rcar_lvds_platform_driver = {
.probe = rcar_lvds_probe,
- .remove = rcar_lvds_remove,
+ .remove_new = rcar_lvds_remove,
.driver = {
.name = "rcar-lvds",
.pm = &rcar_lvds_pm_ops,
diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
index e10e4d4b89a2..305123a671c6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
@@ -1044,13 +1044,11 @@ static int rcar_mipi_dsi_probe(struct platform_device *pdev)
return 0;
}
-static int rcar_mipi_dsi_remove(struct platform_device *pdev)
+static void rcar_mipi_dsi_remove(struct platform_device *pdev)
{
struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
static const struct rcar_mipi_dsi_device_info v3u_data = {
@@ -1093,7 +1091,7 @@ MODULE_DEVICE_TABLE(of, rcar_mipi_dsi_of_table);
static struct platform_driver rcar_mipi_dsi_platform_driver = {
.probe = rcar_mipi_dsi_probe,
- .remove = rcar_mipi_dsi_remove,
+ .remove_new = rcar_mipi_dsi_remove,
.driver = {
.name = "rcar-mipi-dsi",
.of_match_table = rcar_mipi_dsi_of_table,
diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
index aa95b85a2964..a97fc4c5d1c8 100644
--- a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
+++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
@@ -782,14 +782,12 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int rzg2l_mipi_dsi_remove(struct platform_device *pdev)
+static void rzg2l_mipi_dsi_remove(struct platform_device *pdev)
{
struct rzg2l_mipi_dsi *dsi = platform_get_drvdata(pdev);
mipi_dsi_host_unregister(&dsi->host);
pm_runtime_disable(&pdev->dev);
-
- return 0;
}
static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
@@ -801,7 +799,7 @@ MODULE_DEVICE_TABLE(of, rzg2l_mipi_dsi_of_table);
static struct platform_driver rzg2l_mipi_dsi_platform_driver = {
.probe = rzg2l_mipi_dsi_probe,
- .remove = rzg2l_mipi_dsi_remove,
+ .remove_new = rzg2l_mipi_dsi_remove,
.driver = {
.name = "rzg2l-mipi-dsi",
.pm = &rzg2l_mipi_pm_ops,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 37/53] drm/rcar-du: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-08 2:42 ` Laurent Pinchart
-1 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:42 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Kieran Bingham, David Airlie, Daniel Vetter, dri-devel,
linux-renesas-soc, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:26:00PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the rcar-du drm driver from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> 6 files changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> index e2a67dda4658..26a2f5ad8ee5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> @@ -187,11 +187,9 @@ static int rcar_cmm_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_cmm_remove(struct platform_device *pdev)
> +static void rcar_cmm_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id rcar_cmm_of_table[] = {
> @@ -203,7 +201,7 @@ MODULE_DEVICE_TABLE(of, rcar_cmm_of_table);
>
> static struct platform_driver rcar_cmm_platform_driver = {
> .probe = rcar_cmm_probe,
> - .remove = rcar_cmm_remove,
> + .remove_new = rcar_cmm_remove,
> .driver = {
> .name = "rcar-cmm",
> .of_match_table = rcar_cmm_of_table,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index b9a94c5260e9..4a6bf50b5c49 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -685,7 +685,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_du_pm_ops,
> * Platform driver
> */
>
> -static int rcar_du_remove(struct platform_device *pdev)
> +static void rcar_du_remove(struct platform_device *pdev)
> {
> struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
> struct drm_device *ddev = &rcdu->ddev;
> @@ -694,8 +694,6 @@ static int rcar_du_remove(struct platform_device *pdev)
> drm_atomic_helper_shutdown(ddev);
>
> drm_kms_helper_poll_fini(ddev);
> -
> - return 0;
> }
>
> static void rcar_du_shutdown(struct platform_device *pdev)
> @@ -776,7 +774,7 @@ static int rcar_du_probe(struct platform_device *pdev)
>
> static struct platform_driver rcar_du_platform_driver = {
> .probe = rcar_du_probe,
> - .remove = rcar_du_remove,
> + .remove_new = rcar_du_remove,
> .shutdown = rcar_du_shutdown,
> .driver = {
> .name = "rcar-du",
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> index 18ed14911b98..119d69d20b23 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -93,13 +93,11 @@ static int rcar_dw_hdmi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_dw_hdmi_remove(struct platform_device *pdev)
> +static void rcar_dw_hdmi_remove(struct platform_device *pdev)
> {
> struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
>
> dw_hdmi_remove(hdmi);
> -
> - return 0;
> }
>
> static const struct of_device_id rcar_dw_hdmi_of_table[] = {
> @@ -110,7 +108,7 @@ MODULE_DEVICE_TABLE(of, rcar_dw_hdmi_of_table);
>
> static struct platform_driver rcar_dw_hdmi_platform_driver = {
> .probe = rcar_dw_hdmi_probe,
> - .remove = rcar_dw_hdmi_remove,
> + .remove_new = rcar_dw_hdmi_remove,
> .driver = {
> .name = "rcar-dw-hdmi",
> .of_match_table = rcar_dw_hdmi_of_table,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 260ea5d8624e..86d2ac204568 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -890,15 +890,13 @@ static int rcar_lvds_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_lvds_remove(struct platform_device *pdev)
> +static void rcar_lvds_remove(struct platform_device *pdev)
> {
> struct rcar_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&lvds->bridge);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct rcar_lvds_device_info rcar_lvds_gen2_info = {
> @@ -994,7 +992,7 @@ static const struct dev_pm_ops rcar_lvds_pm_ops = {
>
> static struct platform_driver rcar_lvds_platform_driver = {
> .probe = rcar_lvds_probe,
> - .remove = rcar_lvds_remove,
> + .remove_new = rcar_lvds_remove,
> .driver = {
> .name = "rcar-lvds",
> .pm = &rcar_lvds_pm_ops,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index e10e4d4b89a2..305123a671c6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -1044,13 +1044,11 @@ static int rcar_mipi_dsi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_mipi_dsi_remove(struct platform_device *pdev)
> +static void rcar_mipi_dsi_remove(struct platform_device *pdev)
> {
> struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
>
> mipi_dsi_host_unregister(&dsi->host);
> -
> - return 0;
> }
>
> static const struct rcar_mipi_dsi_device_info v3u_data = {
> @@ -1093,7 +1091,7 @@ MODULE_DEVICE_TABLE(of, rcar_mipi_dsi_of_table);
>
> static struct platform_driver rcar_mipi_dsi_platform_driver = {
> .probe = rcar_mipi_dsi_probe,
> - .remove = rcar_mipi_dsi_remove,
> + .remove_new = rcar_mipi_dsi_remove,
> .driver = {
> .name = "rcar-mipi-dsi",
> .of_match_table = rcar_mipi_dsi_of_table,
> diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> index aa95b85a2964..a97fc4c5d1c8 100644
> --- a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> @@ -782,14 +782,12 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int rzg2l_mipi_dsi_remove(struct platform_device *pdev)
> +static void rzg2l_mipi_dsi_remove(struct platform_device *pdev)
> {
> struct rzg2l_mipi_dsi *dsi = platform_get_drvdata(pdev);
>
> mipi_dsi_host_unregister(&dsi->host);
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
> @@ -801,7 +799,7 @@ MODULE_DEVICE_TABLE(of, rzg2l_mipi_dsi_of_table);
>
> static struct platform_driver rzg2l_mipi_dsi_platform_driver = {
> .probe = rzg2l_mipi_dsi_probe,
> - .remove = rzg2l_mipi_dsi_remove,
> + .remove_new = rzg2l_mipi_dsi_remove,
> .driver = {
> .name = "rzg2l-mipi-dsi",
> .pm = &rzg2l_mipi_pm_ops,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 37/53] drm/rcar-du: Convert to platform remove callback returning void
@ 2023-05-08 2:42 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:42 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: dri-devel, linux-renesas-soc, Kieran Bingham, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:26:00PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the rcar-du drm driver from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> 6 files changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> index e2a67dda4658..26a2f5ad8ee5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> @@ -187,11 +187,9 @@ static int rcar_cmm_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_cmm_remove(struct platform_device *pdev)
> +static void rcar_cmm_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id rcar_cmm_of_table[] = {
> @@ -203,7 +201,7 @@ MODULE_DEVICE_TABLE(of, rcar_cmm_of_table);
>
> static struct platform_driver rcar_cmm_platform_driver = {
> .probe = rcar_cmm_probe,
> - .remove = rcar_cmm_remove,
> + .remove_new = rcar_cmm_remove,
> .driver = {
> .name = "rcar-cmm",
> .of_match_table = rcar_cmm_of_table,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index b9a94c5260e9..4a6bf50b5c49 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -685,7 +685,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_du_pm_ops,
> * Platform driver
> */
>
> -static int rcar_du_remove(struct platform_device *pdev)
> +static void rcar_du_remove(struct platform_device *pdev)
> {
> struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
> struct drm_device *ddev = &rcdu->ddev;
> @@ -694,8 +694,6 @@ static int rcar_du_remove(struct platform_device *pdev)
> drm_atomic_helper_shutdown(ddev);
>
> drm_kms_helper_poll_fini(ddev);
> -
> - return 0;
> }
>
> static void rcar_du_shutdown(struct platform_device *pdev)
> @@ -776,7 +774,7 @@ static int rcar_du_probe(struct platform_device *pdev)
>
> static struct platform_driver rcar_du_platform_driver = {
> .probe = rcar_du_probe,
> - .remove = rcar_du_remove,
> + .remove_new = rcar_du_remove,
> .shutdown = rcar_du_shutdown,
> .driver = {
> .name = "rcar-du",
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> index 18ed14911b98..119d69d20b23 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -93,13 +93,11 @@ static int rcar_dw_hdmi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_dw_hdmi_remove(struct platform_device *pdev)
> +static void rcar_dw_hdmi_remove(struct platform_device *pdev)
> {
> struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
>
> dw_hdmi_remove(hdmi);
> -
> - return 0;
> }
>
> static const struct of_device_id rcar_dw_hdmi_of_table[] = {
> @@ -110,7 +108,7 @@ MODULE_DEVICE_TABLE(of, rcar_dw_hdmi_of_table);
>
> static struct platform_driver rcar_dw_hdmi_platform_driver = {
> .probe = rcar_dw_hdmi_probe,
> - .remove = rcar_dw_hdmi_remove,
> + .remove_new = rcar_dw_hdmi_remove,
> .driver = {
> .name = "rcar-dw-hdmi",
> .of_match_table = rcar_dw_hdmi_of_table,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 260ea5d8624e..86d2ac204568 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -890,15 +890,13 @@ static int rcar_lvds_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_lvds_remove(struct platform_device *pdev)
> +static void rcar_lvds_remove(struct platform_device *pdev)
> {
> struct rcar_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_bridge_remove(&lvds->bridge);
>
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct rcar_lvds_device_info rcar_lvds_gen2_info = {
> @@ -994,7 +992,7 @@ static const struct dev_pm_ops rcar_lvds_pm_ops = {
>
> static struct platform_driver rcar_lvds_platform_driver = {
> .probe = rcar_lvds_probe,
> - .remove = rcar_lvds_remove,
> + .remove_new = rcar_lvds_remove,
> .driver = {
> .name = "rcar-lvds",
> .pm = &rcar_lvds_pm_ops,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> index e10e4d4b89a2..305123a671c6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c
> @@ -1044,13 +1044,11 @@ static int rcar_mipi_dsi_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int rcar_mipi_dsi_remove(struct platform_device *pdev)
> +static void rcar_mipi_dsi_remove(struct platform_device *pdev)
> {
> struct rcar_mipi_dsi *dsi = platform_get_drvdata(pdev);
>
> mipi_dsi_host_unregister(&dsi->host);
> -
> - return 0;
> }
>
> static const struct rcar_mipi_dsi_device_info v3u_data = {
> @@ -1093,7 +1091,7 @@ MODULE_DEVICE_TABLE(of, rcar_mipi_dsi_of_table);
>
> static struct platform_driver rcar_mipi_dsi_platform_driver = {
> .probe = rcar_mipi_dsi_probe,
> - .remove = rcar_mipi_dsi_remove,
> + .remove_new = rcar_mipi_dsi_remove,
> .driver = {
> .name = "rcar-mipi-dsi",
> .of_match_table = rcar_mipi_dsi_of_table,
> diff --git a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> index aa95b85a2964..a97fc4c5d1c8 100644
> --- a/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> +++ b/drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c
> @@ -782,14 +782,12 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int rzg2l_mipi_dsi_remove(struct platform_device *pdev)
> +static void rzg2l_mipi_dsi_remove(struct platform_device *pdev)
> {
> struct rzg2l_mipi_dsi *dsi = platform_get_drvdata(pdev);
>
> mipi_dsi_host_unregister(&dsi->host);
> pm_runtime_disable(&pdev->dev);
> -
> - return 0;
> }
>
> static const struct of_device_id rzg2l_mipi_dsi_of_table[] = {
> @@ -801,7 +799,7 @@ MODULE_DEVICE_TABLE(of, rzg2l_mipi_dsi_of_table);
>
> static struct platform_driver rzg2l_mipi_dsi_platform_driver = {
> .probe = rzg2l_mipi_dsi_probe,
> - .remove = rzg2l_mipi_dsi_remove,
> + .remove_new = rzg2l_mipi_dsi_remove,
> .driver = {
> .name = "rzg2l-mipi-dsi",
> .pm = &rzg2l_mipi_pm_ops,
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 37/53] drm/rcar-du: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-08 13:14 ` Geert Uytterhoeven
-1 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-05-08 13:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Laurent Pinchart, Kieran Bingham, David Airlie, Daniel Vetter,
dri-devel, linux-renesas-soc, kernel
On Sun, May 7, 2023 at 6:31 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the rcar-du drm driver from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 37/53] drm/rcar-du: Convert to platform remove callback returning void
@ 2023-05-08 13:14 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-05-08 13:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: kernel, dri-devel, linux-renesas-soc, Kieran Bingham,
Laurent Pinchart
On Sun, May 7, 2023 at 6:31 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the rcar-du drm driver from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 38/53] drm/rockchip: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, David Airlie, Daniel Vetter
Cc: dri-devel, linux-arm-kernel, linux-rockchip, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert rockchip drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
10 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index ad2d3ae7e621..c497382fdb9b 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -419,14 +419,12 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return ret;
}
-static int rockchip_dp_remove(struct platform_device *pdev)
+static void rockchip_dp_remove(struct platform_device *pdev)
{
struct rockchip_dp_device *dp = platform_get_drvdata(pdev);
component_del(&pdev->dev, &rockchip_dp_component_ops);
analogix_dp_remove(dp->adp);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -481,7 +479,7 @@ MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
struct platform_driver rockchip_dp_driver = {
.probe = rockchip_dp_probe,
- .remove = rockchip_dp_remove,
+ .remove_new = rockchip_dp_remove,
.driver = {
.name = "rockchip-dp",
.pm = &rockchip_dp_pm_ops,
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8526dda91931..8a55950c208f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1223,15 +1223,13 @@ static int cdn_dp_probe(struct platform_device *pdev)
return component_add(dev, &cdn_dp_component_ops);
}
-static int cdn_dp_remove(struct platform_device *pdev)
+static void cdn_dp_remove(struct platform_device *pdev)
{
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(&pdev->dev, &cdn_dp_component_ops);
-
- return 0;
}
static void cdn_dp_shutdown(struct platform_device *pdev)
@@ -1248,7 +1246,7 @@ static const struct dev_pm_ops cdn_dp_pm_ops = {
struct platform_driver cdn_dp_driver = {
.probe = cdn_dp_probe,
- .remove = cdn_dp_remove,
+ .remove_new = cdn_dp_remove,
.shutdown = cdn_dp_shutdown,
.driver = {
.name = "cdn-dp",
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 7901c3babc8c..375572103fd9 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1468,13 +1468,11 @@ static int dw_mipi_dsi_rockchip_probe(struct platform_device *pdev)
return 0;
}
-static int dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
+static void dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
{
struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev);
dw_mipi_dsi_remove(dsi->dmd);
-
- return 0;
}
static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
@@ -1676,7 +1674,7 @@ MODULE_DEVICE_TABLE(of, dw_mipi_dsi_rockchip_dt_ids);
struct platform_driver dw_mipi_dsi_rockchip_driver = {
.probe = dw_mipi_dsi_rockchip_probe,
- .remove = dw_mipi_dsi_rockchip_remove,
+ .remove_new = dw_mipi_dsi_rockchip_remove,
.driver = {
.of_match_table = dw_mipi_dsi_rockchip_dt_ids,
.pm = &dw_mipi_dsi_rockchip_pm_ops,
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 2f4b8f64cbad..8c4011d4ca61 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -656,11 +656,9 @@ static int dw_hdmi_rockchip_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &dw_hdmi_rockchip_ops);
}
-static int dw_hdmi_rockchip_remove(struct platform_device *pdev)
+static void dw_hdmi_rockchip_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &dw_hdmi_rockchip_ops);
-
- return 0;
}
static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev)
@@ -678,7 +676,7 @@ static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
.probe = dw_hdmi_rockchip_probe,
- .remove = dw_hdmi_rockchip_remove,
+ .remove_new = dw_hdmi_rockchip_remove,
.driver = {
.name = "dwhdmi-rockchip",
.pm = &dw_hdmi_rockchip_pm,
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f51774866f41..6a63952a6c84 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -919,11 +919,9 @@ static int inno_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &inno_hdmi_ops);
}
-static int inno_hdmi_remove(struct platform_device *pdev)
+static void inno_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &inno_hdmi_ops);
-
- return 0;
}
static const struct of_device_id inno_hdmi_dt_ids[] = {
@@ -935,7 +933,7 @@ MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
struct platform_driver inno_hdmi_driver = {
.probe = inno_hdmi_probe,
- .remove = inno_hdmi_remove,
+ .remove_new = inno_hdmi_remove,
.driver = {
.name = "innohdmi-rockchip",
.of_match_table = inno_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 90145ad96984..5e6ac27ea155 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -858,11 +858,9 @@ static int rk3066_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &rk3066_hdmi_ops);
}
-static int rk3066_hdmi_remove(struct platform_device *pdev)
+static void rk3066_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &rk3066_hdmi_ops);
-
- return 0;
}
static const struct of_device_id rk3066_hdmi_dt_ids[] = {
@@ -873,7 +871,7 @@ MODULE_DEVICE_TABLE(of, rk3066_hdmi_dt_ids);
struct platform_driver rk3066_hdmi_driver = {
.probe = rk3066_hdmi_probe,
- .remove = rk3066_hdmi_remove,
+ .remove_new = rk3066_hdmi_remove,
.driver = {
.name = "rockchip-rk3066-hdmi",
.of_match_table = rk3066_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 6e0788d14c10..dedee7a0cd68 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,13 +450,11 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
return 0;
}
-static int rockchip_drm_platform_remove(struct platform_device *pdev)
+static void rockchip_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &rockchip_drm_ops);
rockchip_drm_match_remove(&pdev->dev);
-
- return 0;
}
static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
@@ -475,7 +473,7 @@ MODULE_DEVICE_TABLE(of, rockchip_drm_dt_ids);
static struct platform_driver rockchip_drm_platform_driver = {
.probe = rockchip_drm_platform_probe,
- .remove = rockchip_drm_platform_remove,
+ .remove_new = rockchip_drm_platform_remove,
.shutdown = rockchip_drm_platform_shutdown,
.driver = {
.name = "rockchip-drm",
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 68f6ebb33460..582859387792 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -739,19 +739,17 @@ static int rockchip_lvds_probe(struct platform_device *pdev)
return ret;
}
-static int rockchip_lvds_remove(struct platform_device *pdev)
+static void rockchip_lvds_remove(struct platform_device *pdev)
{
struct rockchip_lvds *lvds = platform_get_drvdata(pdev);
component_del(&pdev->dev, &rockchip_lvds_component_ops);
clk_unprepare(lvds->pclk);
-
- return 0;
}
struct platform_driver rockchip_lvds_driver = {
.probe = rockchip_lvds_probe,
- .remove = rockchip_lvds_remove,
+ .remove_new = rockchip_lvds_remove,
.driver = {
.name = "rockchip-lvds",
.of_match_table = of_match_ptr(rockchip_lvds_dt_ids),
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 9d30aa73b542..62b573f282a7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -264,16 +264,14 @@ static int vop2_probe(struct platform_device *pdev)
return component_add(dev, &vop2_component_ops);
}
-static int vop2_remove(struct platform_device *pdev)
+static void vop2_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vop2_component_ops);
-
- return 0;
}
struct platform_driver vop2_platform_driver = {
.probe = vop2_probe,
- .remove = vop2_remove,
+ .remove_new = vop2_remove,
.driver = {
.name = "rockchip-vop2",
.of_match_table = of_match_ptr(vop2_dt_match),
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 014f99e8928e..3e31e8e4e0fd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -1145,16 +1145,14 @@ static int vop_probe(struct platform_device *pdev)
return component_add(dev, &vop_component_ops);
}
-static int vop_remove(struct platform_device *pdev)
+static void vop_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vop_component_ops);
-
- return 0;
}
struct platform_driver vop_platform_driver = {
.probe = vop_probe,
- .remove = vop_remove,
+ .remove_new = vop_remove,
.driver = {
.name = "rockchip-vop",
.of_match_table = vop_driver_dt_match,
--
2.39.2
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 38/53] drm/rockchip: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, David Airlie, Daniel Vetter
Cc: kernel, linux-rockchip, linux-arm-kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert rockchip drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
10 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index ad2d3ae7e621..c497382fdb9b 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -419,14 +419,12 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return ret;
}
-static int rockchip_dp_remove(struct platform_device *pdev)
+static void rockchip_dp_remove(struct platform_device *pdev)
{
struct rockchip_dp_device *dp = platform_get_drvdata(pdev);
component_del(&pdev->dev, &rockchip_dp_component_ops);
analogix_dp_remove(dp->adp);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -481,7 +479,7 @@ MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
struct platform_driver rockchip_dp_driver = {
.probe = rockchip_dp_probe,
- .remove = rockchip_dp_remove,
+ .remove_new = rockchip_dp_remove,
.driver = {
.name = "rockchip-dp",
.pm = &rockchip_dp_pm_ops,
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8526dda91931..8a55950c208f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1223,15 +1223,13 @@ static int cdn_dp_probe(struct platform_device *pdev)
return component_add(dev, &cdn_dp_component_ops);
}
-static int cdn_dp_remove(struct platform_device *pdev)
+static void cdn_dp_remove(struct platform_device *pdev)
{
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(&pdev->dev, &cdn_dp_component_ops);
-
- return 0;
}
static void cdn_dp_shutdown(struct platform_device *pdev)
@@ -1248,7 +1246,7 @@ static const struct dev_pm_ops cdn_dp_pm_ops = {
struct platform_driver cdn_dp_driver = {
.probe = cdn_dp_probe,
- .remove = cdn_dp_remove,
+ .remove_new = cdn_dp_remove,
.shutdown = cdn_dp_shutdown,
.driver = {
.name = "cdn-dp",
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 7901c3babc8c..375572103fd9 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1468,13 +1468,11 @@ static int dw_mipi_dsi_rockchip_probe(struct platform_device *pdev)
return 0;
}
-static int dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
+static void dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
{
struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev);
dw_mipi_dsi_remove(dsi->dmd);
-
- return 0;
}
static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
@@ -1676,7 +1674,7 @@ MODULE_DEVICE_TABLE(of, dw_mipi_dsi_rockchip_dt_ids);
struct platform_driver dw_mipi_dsi_rockchip_driver = {
.probe = dw_mipi_dsi_rockchip_probe,
- .remove = dw_mipi_dsi_rockchip_remove,
+ .remove_new = dw_mipi_dsi_rockchip_remove,
.driver = {
.of_match_table = dw_mipi_dsi_rockchip_dt_ids,
.pm = &dw_mipi_dsi_rockchip_pm_ops,
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 2f4b8f64cbad..8c4011d4ca61 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -656,11 +656,9 @@ static int dw_hdmi_rockchip_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &dw_hdmi_rockchip_ops);
}
-static int dw_hdmi_rockchip_remove(struct platform_device *pdev)
+static void dw_hdmi_rockchip_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &dw_hdmi_rockchip_ops);
-
- return 0;
}
static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev)
@@ -678,7 +676,7 @@ static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
.probe = dw_hdmi_rockchip_probe,
- .remove = dw_hdmi_rockchip_remove,
+ .remove_new = dw_hdmi_rockchip_remove,
.driver = {
.name = "dwhdmi-rockchip",
.pm = &dw_hdmi_rockchip_pm,
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f51774866f41..6a63952a6c84 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -919,11 +919,9 @@ static int inno_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &inno_hdmi_ops);
}
-static int inno_hdmi_remove(struct platform_device *pdev)
+static void inno_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &inno_hdmi_ops);
-
- return 0;
}
static const struct of_device_id inno_hdmi_dt_ids[] = {
@@ -935,7 +933,7 @@ MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
struct platform_driver inno_hdmi_driver = {
.probe = inno_hdmi_probe,
- .remove = inno_hdmi_remove,
+ .remove_new = inno_hdmi_remove,
.driver = {
.name = "innohdmi-rockchip",
.of_match_table = inno_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 90145ad96984..5e6ac27ea155 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -858,11 +858,9 @@ static int rk3066_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &rk3066_hdmi_ops);
}
-static int rk3066_hdmi_remove(struct platform_device *pdev)
+static void rk3066_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &rk3066_hdmi_ops);
-
- return 0;
}
static const struct of_device_id rk3066_hdmi_dt_ids[] = {
@@ -873,7 +871,7 @@ MODULE_DEVICE_TABLE(of, rk3066_hdmi_dt_ids);
struct platform_driver rk3066_hdmi_driver = {
.probe = rk3066_hdmi_probe,
- .remove = rk3066_hdmi_remove,
+ .remove_new = rk3066_hdmi_remove,
.driver = {
.name = "rockchip-rk3066-hdmi",
.of_match_table = rk3066_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 6e0788d14c10..dedee7a0cd68 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,13 +450,11 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
return 0;
}
-static int rockchip_drm_platform_remove(struct platform_device *pdev)
+static void rockchip_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &rockchip_drm_ops);
rockchip_drm_match_remove(&pdev->dev);
-
- return 0;
}
static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
@@ -475,7 +473,7 @@ MODULE_DEVICE_TABLE(of, rockchip_drm_dt_ids);
static struct platform_driver rockchip_drm_platform_driver = {
.probe = rockchip_drm_platform_probe,
- .remove = rockchip_drm_platform_remove,
+ .remove_new = rockchip_drm_platform_remove,
.shutdown = rockchip_drm_platform_shutdown,
.driver = {
.name = "rockchip-drm",
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 68f6ebb33460..582859387792 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -739,19 +739,17 @@ static int rockchip_lvds_probe(struct platform_device *pdev)
return ret;
}
-static int rockchip_lvds_remove(struct platform_device *pdev)
+static void rockchip_lvds_remove(struct platform_device *pdev)
{
struct rockchip_lvds *lvds = platform_get_drvdata(pdev);
component_del(&pdev->dev, &rockchip_lvds_component_ops);
clk_unprepare(lvds->pclk);
-
- return 0;
}
struct platform_driver rockchip_lvds_driver = {
.probe = rockchip_lvds_probe,
- .remove = rockchip_lvds_remove,
+ .remove_new = rockchip_lvds_remove,
.driver = {
.name = "rockchip-lvds",
.of_match_table = of_match_ptr(rockchip_lvds_dt_ids),
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 9d30aa73b542..62b573f282a7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -264,16 +264,14 @@ static int vop2_probe(struct platform_device *pdev)
return component_add(dev, &vop2_component_ops);
}
-static int vop2_remove(struct platform_device *pdev)
+static void vop2_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vop2_component_ops);
-
- return 0;
}
struct platform_driver vop2_platform_driver = {
.probe = vop2_probe,
- .remove = vop2_remove,
+ .remove_new = vop2_remove,
.driver = {
.name = "rockchip-vop2",
.of_match_table = of_match_ptr(vop2_dt_match),
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 014f99e8928e..3e31e8e4e0fd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -1145,16 +1145,14 @@ static int vop_probe(struct platform_device *pdev)
return component_add(dev, &vop_component_ops);
}
-static int vop_remove(struct platform_device *pdev)
+static void vop_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vop_component_ops);
-
- return 0;
}
struct platform_driver vop_platform_driver = {
.probe = vop_probe,
- .remove = vop_remove,
+ .remove_new = vop_remove,
.driver = {
.name = "rockchip-vop",
.of_match_table = vop_driver_dt_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 38/53] drm/rockchip: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, David Airlie, Daniel Vetter
Cc: dri-devel, linux-arm-kernel, linux-rockchip, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert rockchip drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
10 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index ad2d3ae7e621..c497382fdb9b 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -419,14 +419,12 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return ret;
}
-static int rockchip_dp_remove(struct platform_device *pdev)
+static void rockchip_dp_remove(struct platform_device *pdev)
{
struct rockchip_dp_device *dp = platform_get_drvdata(pdev);
component_del(&pdev->dev, &rockchip_dp_component_ops);
analogix_dp_remove(dp->adp);
-
- return 0;
}
#ifdef CONFIG_PM_SLEEP
@@ -481,7 +479,7 @@ MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
struct platform_driver rockchip_dp_driver = {
.probe = rockchip_dp_probe,
- .remove = rockchip_dp_remove,
+ .remove_new = rockchip_dp_remove,
.driver = {
.name = "rockchip-dp",
.pm = &rockchip_dp_pm_ops,
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8526dda91931..8a55950c208f 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1223,15 +1223,13 @@ static int cdn_dp_probe(struct platform_device *pdev)
return component_add(dev, &cdn_dp_component_ops);
}
-static int cdn_dp_remove(struct platform_device *pdev)
+static void cdn_dp_remove(struct platform_device *pdev)
{
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(&pdev->dev, &cdn_dp_component_ops);
-
- return 0;
}
static void cdn_dp_shutdown(struct platform_device *pdev)
@@ -1248,7 +1246,7 @@ static const struct dev_pm_ops cdn_dp_pm_ops = {
struct platform_driver cdn_dp_driver = {
.probe = cdn_dp_probe,
- .remove = cdn_dp_remove,
+ .remove_new = cdn_dp_remove,
.shutdown = cdn_dp_shutdown,
.driver = {
.name = "cdn-dp",
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 7901c3babc8c..375572103fd9 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1468,13 +1468,11 @@ static int dw_mipi_dsi_rockchip_probe(struct platform_device *pdev)
return 0;
}
-static int dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
+static void dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
{
struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev);
dw_mipi_dsi_remove(dsi->dmd);
-
- return 0;
}
static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
@@ -1676,7 +1674,7 @@ MODULE_DEVICE_TABLE(of, dw_mipi_dsi_rockchip_dt_ids);
struct platform_driver dw_mipi_dsi_rockchip_driver = {
.probe = dw_mipi_dsi_rockchip_probe,
- .remove = dw_mipi_dsi_rockchip_remove,
+ .remove_new = dw_mipi_dsi_rockchip_remove,
.driver = {
.of_match_table = dw_mipi_dsi_rockchip_dt_ids,
.pm = &dw_mipi_dsi_rockchip_pm_ops,
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 2f4b8f64cbad..8c4011d4ca61 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -656,11 +656,9 @@ static int dw_hdmi_rockchip_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &dw_hdmi_rockchip_ops);
}
-static int dw_hdmi_rockchip_remove(struct platform_device *pdev)
+static void dw_hdmi_rockchip_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &dw_hdmi_rockchip_ops);
-
- return 0;
}
static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev)
@@ -678,7 +676,7 @@ static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
.probe = dw_hdmi_rockchip_probe,
- .remove = dw_hdmi_rockchip_remove,
+ .remove_new = dw_hdmi_rockchip_remove,
.driver = {
.name = "dwhdmi-rockchip",
.pm = &dw_hdmi_rockchip_pm,
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f51774866f41..6a63952a6c84 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -919,11 +919,9 @@ static int inno_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &inno_hdmi_ops);
}
-static int inno_hdmi_remove(struct platform_device *pdev)
+static void inno_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &inno_hdmi_ops);
-
- return 0;
}
static const struct of_device_id inno_hdmi_dt_ids[] = {
@@ -935,7 +933,7 @@ MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
struct platform_driver inno_hdmi_driver = {
.probe = inno_hdmi_probe,
- .remove = inno_hdmi_remove,
+ .remove_new = inno_hdmi_remove,
.driver = {
.name = "innohdmi-rockchip",
.of_match_table = inno_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 90145ad96984..5e6ac27ea155 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -858,11 +858,9 @@ static int rk3066_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &rk3066_hdmi_ops);
}
-static int rk3066_hdmi_remove(struct platform_device *pdev)
+static void rk3066_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &rk3066_hdmi_ops);
-
- return 0;
}
static const struct of_device_id rk3066_hdmi_dt_ids[] = {
@@ -873,7 +871,7 @@ MODULE_DEVICE_TABLE(of, rk3066_hdmi_dt_ids);
struct platform_driver rk3066_hdmi_driver = {
.probe = rk3066_hdmi_probe,
- .remove = rk3066_hdmi_remove,
+ .remove_new = rk3066_hdmi_remove,
.driver = {
.name = "rockchip-rk3066-hdmi",
.of_match_table = rk3066_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 6e0788d14c10..dedee7a0cd68 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -450,13 +450,11 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
return 0;
}
-static int rockchip_drm_platform_remove(struct platform_device *pdev)
+static void rockchip_drm_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &rockchip_drm_ops);
rockchip_drm_match_remove(&pdev->dev);
-
- return 0;
}
static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
@@ -475,7 +473,7 @@ MODULE_DEVICE_TABLE(of, rockchip_drm_dt_ids);
static struct platform_driver rockchip_drm_platform_driver = {
.probe = rockchip_drm_platform_probe,
- .remove = rockchip_drm_platform_remove,
+ .remove_new = rockchip_drm_platform_remove,
.shutdown = rockchip_drm_platform_shutdown,
.driver = {
.name = "rockchip-drm",
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 68f6ebb33460..582859387792 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -739,19 +739,17 @@ static int rockchip_lvds_probe(struct platform_device *pdev)
return ret;
}
-static int rockchip_lvds_remove(struct platform_device *pdev)
+static void rockchip_lvds_remove(struct platform_device *pdev)
{
struct rockchip_lvds *lvds = platform_get_drvdata(pdev);
component_del(&pdev->dev, &rockchip_lvds_component_ops);
clk_unprepare(lvds->pclk);
-
- return 0;
}
struct platform_driver rockchip_lvds_driver = {
.probe = rockchip_lvds_probe,
- .remove = rockchip_lvds_remove,
+ .remove_new = rockchip_lvds_remove,
.driver = {
.name = "rockchip-lvds",
.of_match_table = of_match_ptr(rockchip_lvds_dt_ids),
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index 9d30aa73b542..62b573f282a7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -264,16 +264,14 @@ static int vop2_probe(struct platform_device *pdev)
return component_add(dev, &vop2_component_ops);
}
-static int vop2_remove(struct platform_device *pdev)
+static void vop2_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vop2_component_ops);
-
- return 0;
}
struct platform_driver vop2_platform_driver = {
.probe = vop2_probe,
- .remove = vop2_remove,
+ .remove_new = vop2_remove,
.driver = {
.name = "rockchip-vop2",
.of_match_table = of_match_ptr(vop2_dt_match),
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 014f99e8928e..3e31e8e4e0fd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -1145,16 +1145,14 @@ static int vop_probe(struct platform_device *pdev)
return component_add(dev, &vop_component_ops);
}
-static int vop_remove(struct platform_device *pdev)
+static void vop_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vop_component_ops);
-
- return 0;
}
struct platform_driver vop_platform_driver = {
.probe = vop_probe,
- .remove = vop_remove,
+ .remove_new = vop_remove,
.driver = {
.name = "rockchip-vop",
.of_match_table = vop_driver_dt_match,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 38/53] drm/rockchip: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-08 8:24 ` Heiko Stübner
-1 siblings, 0 replies; 261+ messages in thread
From: Heiko Stübner @ 2023-05-08 8:24 UTC (permalink / raw)
To: Sandy Huang, David Airlie, Daniel Vetter, Uwe Kleine-König
Cc: dri-devel, linux-arm-kernel, linux-rockchip, kernel
Am Sonntag, 7. Mai 2023, 18:26:01 CEST schrieb Uwe Kleine-König:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert rockchip drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 38/53] drm/rockchip: Convert to platform remove callback returning void
@ 2023-05-08 8:24 ` Heiko Stübner
0 siblings, 0 replies; 261+ messages in thread
From: Heiko Stübner @ 2023-05-08 8:24 UTC (permalink / raw)
To: Sandy Huang, David Airlie, Daniel Vetter, Uwe Kleine-König
Cc: kernel, linux-rockchip, linux-arm-kernel, dri-devel
Am Sonntag, 7. Mai 2023, 18:26:01 CEST schrieb Uwe Kleine-König:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert rockchip drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 39/53] drm/shmobile: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, David Airlie, Daniel Vetter
Cc: dri-devel, linux-renesas-soc, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index faacfee24763..fa32115320ca 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -171,7 +171,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(shmob_drm_pm_ops,
* Platform driver
*/
-static int shmob_drm_remove(struct platform_device *pdev)
+static void shmob_drm_remove(struct platform_device *pdev)
{
struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
struct drm_device *ddev = sdev->ddev;
@@ -180,8 +180,6 @@ static int shmob_drm_remove(struct platform_device *pdev)
drm_kms_helper_poll_fini(ddev);
free_irq(sdev->irq, ddev);
drm_dev_put(ddev);
-
- return 0;
}
static int shmob_drm_probe(struct platform_device *pdev)
@@ -285,7 +283,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
static struct platform_driver shmob_drm_platform_driver = {
.probe = shmob_drm_probe,
- .remove = shmob_drm_remove,
+ .remove_new = shmob_drm_remove,
.driver = {
.name = "shmob-drm",
.pm = pm_sleep_ptr(&shmob_drm_pm_ops),
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 39/53] drm/shmobile: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, David Airlie, Daniel Vetter
Cc: linux-renesas-soc, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index faacfee24763..fa32115320ca 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -171,7 +171,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(shmob_drm_pm_ops,
* Platform driver
*/
-static int shmob_drm_remove(struct platform_device *pdev)
+static void shmob_drm_remove(struct platform_device *pdev)
{
struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
struct drm_device *ddev = sdev->ddev;
@@ -180,8 +180,6 @@ static int shmob_drm_remove(struct platform_device *pdev)
drm_kms_helper_poll_fini(ddev);
free_irq(sdev->irq, ddev);
drm_dev_put(ddev);
-
- return 0;
}
static int shmob_drm_probe(struct platform_device *pdev)
@@ -285,7 +283,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
static struct platform_driver shmob_drm_platform_driver = {
.probe = shmob_drm_probe,
- .remove = shmob_drm_remove,
+ .remove_new = shmob_drm_remove,
.driver = {
.name = "shmob-drm",
.pm = pm_sleep_ptr(&shmob_drm_pm_ops),
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 39/53] drm/shmobile: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-08 2:40 ` Laurent Pinchart
-1 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Kieran Bingham, David Airlie, Daniel Vetter, dri-devel,
linux-renesas-soc, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:26:02PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index faacfee24763..fa32115320ca 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -171,7 +171,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(shmob_drm_pm_ops,
> * Platform driver
> */
>
> -static int shmob_drm_remove(struct platform_device *pdev)
> +static void shmob_drm_remove(struct platform_device *pdev)
> {
> struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
> struct drm_device *ddev = sdev->ddev;
> @@ -180,8 +180,6 @@ static int shmob_drm_remove(struct platform_device *pdev)
> drm_kms_helper_poll_fini(ddev);
> free_irq(sdev->irq, ddev);
> drm_dev_put(ddev);
> -
> - return 0;
> }
>
> static int shmob_drm_probe(struct platform_device *pdev)
> @@ -285,7 +283,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
>
> static struct platform_driver shmob_drm_platform_driver = {
> .probe = shmob_drm_probe,
> - .remove = shmob_drm_remove,
> + .remove_new = shmob_drm_remove,
> .driver = {
> .name = "shmob-drm",
> .pm = pm_sleep_ptr(&shmob_drm_pm_ops),
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 39/53] drm/shmobile: Convert to platform remove callback returning void
@ 2023-05-08 2:40 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: dri-devel, linux-renesas-soc, Kieran Bingham, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:26:02PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index faacfee24763..fa32115320ca 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -171,7 +171,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(shmob_drm_pm_ops,
> * Platform driver
> */
>
> -static int shmob_drm_remove(struct platform_device *pdev)
> +static void shmob_drm_remove(struct platform_device *pdev)
> {
> struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
> struct drm_device *ddev = sdev->ddev;
> @@ -180,8 +180,6 @@ static int shmob_drm_remove(struct platform_device *pdev)
> drm_kms_helper_poll_fini(ddev);
> free_irq(sdev->irq, ddev);
> drm_dev_put(ddev);
> -
> - return 0;
> }
>
> static int shmob_drm_probe(struct platform_device *pdev)
> @@ -285,7 +283,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
>
> static struct platform_driver shmob_drm_platform_driver = {
> .probe = shmob_drm_probe,
> - .remove = shmob_drm_remove,
> + .remove_new = shmob_drm_remove,
> .driver = {
> .name = "shmob-drm",
> .pm = pm_sleep_ptr(&shmob_drm_pm_ops),
> --
> 2.39.2
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 39/53] drm/shmobile: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-08 13:13 ` Geert Uytterhoeven
-1 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-05-08 13:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Laurent Pinchart, Kieran Bingham, David Airlie, Daniel Vetter,
dri-devel, linux-renesas-soc, kernel
On Sun, May 7, 2023 at 6:31 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 39/53] drm/shmobile: Convert to platform remove callback returning void
@ 2023-05-08 13:13 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-05-08 13:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: kernel, dri-devel, linux-renesas-soc, Kieran Bingham,
Laurent Pinchart
On Sun, May 7, 2023 at 6:31 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 40/53] drm/sprd: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (42 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Orson Zhai, Baolin Wang,
Chunyan Zhang, Sam Ravnborg, Thomas Zimmermann, Danilo Krummrich,
Laurent Pinchart, Jani Nikula, Ville Syrjälä,
Deepak R Varma, Alex Deucher
Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the sprd drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c
index b96fc6837b0d..3b19b9788a29 100644
--- a/drivers/gpu/drm/sprd/sprd_dpu.c
+++ b/drivers/gpu/drm/sprd/sprd_dpu.c
@@ -861,16 +861,14 @@ static int sprd_dpu_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &dpu_component_ops);
}
-static int sprd_dpu_remove(struct platform_device *pdev)
+static void sprd_dpu_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &dpu_component_ops);
-
- return 0;
}
struct platform_driver sprd_dpu_driver = {
.probe = sprd_dpu_probe,
- .remove = sprd_dpu_remove,
+ .remove_new = sprd_dpu_remove,
.driver = {
.name = "sprd-dpu-drv",
.of_match_table = dpu_match_table,
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
index be60c0d546a3..cadf23f52ce5 100644
--- a/drivers/gpu/drm/sprd/sprd_drm.c
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -137,10 +137,9 @@ static int sprd_drm_probe(struct platform_device *pdev)
return drm_of_component_probe(&pdev->dev, component_compare_of, &drm_component_ops);
}
-static int sprd_drm_remove(struct platform_device *pdev)
+static void sprd_drm_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &drm_component_ops);
- return 0;
}
static void sprd_drm_shutdown(struct platform_device *pdev)
@@ -163,7 +162,7 @@ MODULE_DEVICE_TABLE(of, drm_match_table);
static struct platform_driver sprd_drm_driver = {
.probe = sprd_drm_probe,
- .remove = sprd_drm_remove,
+ .remove_new = sprd_drm_remove,
.shutdown = sprd_drm_shutdown,
.driver = {
.name = "sprd-drm-drv",
diff --git a/drivers/gpu/drm/sprd/sprd_dsi.c b/drivers/gpu/drm/sprd/sprd_dsi.c
index ab0e5cce7adb..d5b05379ceca 100644
--- a/drivers/gpu/drm/sprd/sprd_dsi.c
+++ b/drivers/gpu/drm/sprd/sprd_dsi.c
@@ -1053,18 +1053,16 @@ static int sprd_dsi_probe(struct platform_device *pdev)
return mipi_dsi_host_register(&dsi->host);
}
-static int sprd_dsi_remove(struct platform_device *pdev)
+static void sprd_dsi_remove(struct platform_device *pdev)
{
struct sprd_dsi *dsi = dev_get_drvdata(&pdev->dev);
mipi_dsi_host_unregister(&dsi->host);
-
- return 0;
}
struct platform_driver sprd_dsi_driver = {
.probe = sprd_dsi_probe,
- .remove = sprd_dsi_remove,
+ .remove_new = sprd_dsi_remove,
.driver = {
.name = "sprd-dsi-drv",
.of_match_table = dsi_match_table,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 41/53] drm/sti: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (43 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
2023-05-09 7:22 ` Alain Volmat
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Alain Volmat, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the sti drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
drivers/gpu/drm/sti/sti_drv.c | 6 ++----
drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
drivers/gpu/drm/sti/sti_hda.c | 5 ++---
drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
7 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_compositor.c b/drivers/gpu/drm/sti/sti_compositor.c
index 142a8e1b4436..33487a1fed8f 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -258,10 +258,9 @@ static int sti_compositor_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sti_compositor_ops);
}
-static int sti_compositor_remove(struct platform_device *pdev)
+static void sti_compositor_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sti_compositor_ops);
- return 0;
}
struct platform_driver sti_compositor_driver = {
@@ -270,7 +269,7 @@ struct platform_driver sti_compositor_driver = {
.of_match_table = compositor_of_match,
},
.probe = sti_compositor_probe,
- .remove = sti_compositor_remove,
+ .remove_new = sti_compositor_remove,
};
MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index ef6a4e63198f..451480041130 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -246,11 +246,9 @@ static int sti_platform_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &sti_ops, match);
}
-static int sti_platform_remove(struct platform_device *pdev)
+static void sti_platform_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &sti_ops);
-
- return 0;
}
static const struct of_device_id sti_dt_ids[] = {
@@ -261,7 +259,7 @@ MODULE_DEVICE_TABLE(of, sti_dt_ids);
static struct platform_driver sti_platform_driver = {
.probe = sti_platform_probe,
- .remove = sti_platform_remove,
+ .remove_new = sti_platform_remove,
.driver = {
.name = DRIVER_NAME,
.of_match_table = sti_dt_ids,
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 577c477b5f46..0dca0048dd25 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -567,10 +567,9 @@ static int sti_dvo_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sti_dvo_ops);
}
-static int sti_dvo_remove(struct platform_device *pdev)
+static void sti_dvo_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sti_dvo_ops);
- return 0;
}
static const struct of_device_id dvo_of_match[] = {
@@ -586,7 +585,7 @@ struct platform_driver sti_dvo_driver = {
.of_match_table = dvo_of_match,
},
.probe = sti_dvo_probe,
- .remove = sti_dvo_remove,
+ .remove_new = sti_dvo_remove,
};
MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 15097ac67931..6ee35612a14e 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -792,10 +792,9 @@ static int sti_hda_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sti_hda_ops);
}
-static int sti_hda_remove(struct platform_device *pdev)
+static void sti_hda_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sti_hda_ops);
- return 0;
}
static const struct of_device_id hda_of_match[] = {
@@ -812,7 +811,7 @@ struct platform_driver sti_hda_driver = {
.of_match_table = hda_of_match,
},
.probe = sti_hda_probe,
- .remove = sti_hda_remove,
+ .remove_new = sti_hda_remove,
};
MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 8539fe1fedc4..3d8ddceca845 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1471,7 +1471,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
return ret;
}
-static int sti_hdmi_remove(struct platform_device *pdev)
+static void sti_hdmi_remove(struct platform_device *pdev)
{
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);
@@ -1479,8 +1479,6 @@ static int sti_hdmi_remove(struct platform_device *pdev)
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(&pdev->dev, &sti_hdmi_ops);
-
- return 0;
}
struct platform_driver sti_hdmi_driver = {
@@ -1490,7 +1488,7 @@ struct platform_driver sti_hdmi_driver = {
.of_match_table = hdmi_of_match,
},
.probe = sti_hdmi_probe,
- .remove = sti_hdmi_remove,
+ .remove_new = sti_hdmi_remove,
};
MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 02b77279f6e4..0fb48ac044d8 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1400,10 +1400,9 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sti_hqvdp_ops);
}
-static int sti_hqvdp_remove(struct platform_device *pdev)
+static void sti_hqvdp_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sti_hqvdp_ops);
- return 0;
}
static const struct of_device_id hqvdp_of_match[] = {
@@ -1419,7 +1418,7 @@ struct platform_driver sti_hqvdp_driver = {
.of_match_table = hqvdp_of_match,
},
.probe = sti_hqvdp_probe,
- .remove = sti_hqvdp_remove,
+ .remove_new = sti_hqvdp_remove,
};
MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index 2499715a69b7..64615638b79a 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -872,10 +872,9 @@ static int sti_tvout_probe(struct platform_device *pdev)
return component_add(dev, &sti_tvout_ops);
}
-static int sti_tvout_remove(struct platform_device *pdev)
+static void sti_tvout_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sti_tvout_ops);
- return 0;
}
static const struct of_device_id tvout_of_match[] = {
@@ -891,7 +890,7 @@ struct platform_driver sti_tvout_driver = {
.of_match_table = tvout_of_match,
},
.probe = sti_tvout_probe,
- .remove = sti_tvout_remove,
+ .remove_new = sti_tvout_remove,
};
MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 41/53] drm/sti: Convert to platform remove callback returning void
2023-05-07 16:26 ` [PATCH 41/53] drm/sti: " Uwe Kleine-König
@ 2023-05-09 7:22 ` Alain Volmat
0 siblings, 0 replies; 261+ messages in thread
From: Alain Volmat @ 2023-05-09 7:22 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: kernel, dri-devel
Hi,
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Regards,
Alain
On Sun, May 07, 2023 at 06:26:04PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the sti drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> 7 files changed, 14 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_compositor.c b/drivers/gpu/drm/sti/sti_compositor.c
> index 142a8e1b4436..33487a1fed8f 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.c
> +++ b/drivers/gpu/drm/sti/sti_compositor.c
> @@ -258,10 +258,9 @@ static int sti_compositor_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &sti_compositor_ops);
> }
>
> -static int sti_compositor_remove(struct platform_device *pdev)
> +static void sti_compositor_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &sti_compositor_ops);
> - return 0;
> }
>
> struct platform_driver sti_compositor_driver = {
> @@ -270,7 +269,7 @@ struct platform_driver sti_compositor_driver = {
> .of_match_table = compositor_of_match,
> },
> .probe = sti_compositor_probe,
> - .remove = sti_compositor_remove,
> + .remove_new = sti_compositor_remove,
> };
>
> MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index ef6a4e63198f..451480041130 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -246,11 +246,9 @@ static int sti_platform_probe(struct platform_device *pdev)
> return component_master_add_with_match(dev, &sti_ops, match);
> }
>
> -static int sti_platform_remove(struct platform_device *pdev)
> +static void sti_platform_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &sti_ops);
> -
> - return 0;
> }
>
> static const struct of_device_id sti_dt_ids[] = {
> @@ -261,7 +259,7 @@ MODULE_DEVICE_TABLE(of, sti_dt_ids);
>
> static struct platform_driver sti_platform_driver = {
> .probe = sti_platform_probe,
> - .remove = sti_platform_remove,
> + .remove_new = sti_platform_remove,
> .driver = {
> .name = DRIVER_NAME,
> .of_match_table = sti_dt_ids,
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> index 577c477b5f46..0dca0048dd25 100644
> --- a/drivers/gpu/drm/sti/sti_dvo.c
> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> @@ -567,10 +567,9 @@ static int sti_dvo_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &sti_dvo_ops);
> }
>
> -static int sti_dvo_remove(struct platform_device *pdev)
> +static void sti_dvo_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &sti_dvo_ops);
> - return 0;
> }
>
> static const struct of_device_id dvo_of_match[] = {
> @@ -586,7 +585,7 @@ struct platform_driver sti_dvo_driver = {
> .of_match_table = dvo_of_match,
> },
> .probe = sti_dvo_probe,
> - .remove = sti_dvo_remove,
> + .remove_new = sti_dvo_remove,
> };
>
> MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index 15097ac67931..6ee35612a14e 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -792,10 +792,9 @@ static int sti_hda_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &sti_hda_ops);
> }
>
> -static int sti_hda_remove(struct platform_device *pdev)
> +static void sti_hda_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &sti_hda_ops);
> - return 0;
> }
>
> static const struct of_device_id hda_of_match[] = {
> @@ -812,7 +811,7 @@ struct platform_driver sti_hda_driver = {
> .of_match_table = hda_of_match,
> },
> .probe = sti_hda_probe,
> - .remove = sti_hda_remove,
> + .remove_new = sti_hda_remove,
> };
>
> MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 8539fe1fedc4..3d8ddceca845 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -1471,7 +1471,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int sti_hdmi_remove(struct platform_device *pdev)
> +static void sti_hdmi_remove(struct platform_device *pdev)
> {
> struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);
>
> @@ -1479,8 +1479,6 @@ static int sti_hdmi_remove(struct platform_device *pdev)
> if (hdmi->audio_pdev)
> platform_device_unregister(hdmi->audio_pdev);
> component_del(&pdev->dev, &sti_hdmi_ops);
> -
> - return 0;
> }
>
> struct platform_driver sti_hdmi_driver = {
> @@ -1490,7 +1488,7 @@ struct platform_driver sti_hdmi_driver = {
> .of_match_table = hdmi_of_match,
> },
> .probe = sti_hdmi_probe,
> - .remove = sti_hdmi_remove,
> + .remove_new = sti_hdmi_remove,
> };
>
> MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index 02b77279f6e4..0fb48ac044d8 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -1400,10 +1400,9 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &sti_hqvdp_ops);
> }
>
> -static int sti_hqvdp_remove(struct platform_device *pdev)
> +static void sti_hqvdp_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &sti_hqvdp_ops);
> - return 0;
> }
>
> static const struct of_device_id hqvdp_of_match[] = {
> @@ -1419,7 +1418,7 @@ struct platform_driver sti_hqvdp_driver = {
> .of_match_table = hqvdp_of_match,
> },
> .probe = sti_hqvdp_probe,
> - .remove = sti_hqvdp_remove,
> + .remove_new = sti_hqvdp_remove,
> };
>
> MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
> index 2499715a69b7..64615638b79a 100644
> --- a/drivers/gpu/drm/sti/sti_tvout.c
> +++ b/drivers/gpu/drm/sti/sti_tvout.c
> @@ -872,10 +872,9 @@ static int sti_tvout_probe(struct platform_device *pdev)
> return component_add(dev, &sti_tvout_ops);
> }
>
> -static int sti_tvout_remove(struct platform_device *pdev)
> +static void sti_tvout_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &sti_tvout_ops);
> - return 0;
> }
>
> static const struct of_device_id tvout_of_match[] = {
> @@ -891,7 +890,7 @@ struct platform_driver sti_tvout_driver = {
> .of_match_table = tvout_of_match,
> },
> .probe = sti_tvout_probe,
> - .remove = sti_tvout_remove,
> + .remove_new = sti_tvout_remove,
> };
>
> MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard@st.com>");
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 42/53] drm/stm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu, David Airlie,
Daniel Vetter, Maxime Coquelin, Alexandre Torgue
Cc: dri-devel, linux-stm32, linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the stm drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/stm/drv.c | 6 ++----
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 50410bd99dfe..be91b375a4d5 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -213,7 +213,7 @@ static int stm_drm_platform_probe(struct platform_device *pdev)
return ret;
}
-static int stm_drm_platform_remove(struct platform_device *pdev)
+static void stm_drm_platform_remove(struct platform_device *pdev)
{
struct drm_device *ddev = platform_get_drvdata(pdev);
@@ -222,8 +222,6 @@ static int stm_drm_platform_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
drv_unload(ddev);
drm_dev_put(ddev);
-
- return 0;
}
static const struct of_device_id drv_dt_ids[] = {
@@ -234,7 +232,7 @@ MODULE_DEVICE_TABLE(of, drv_dt_ids);
static struct platform_driver stm_drm_platform_driver = {
.probe = stm_drm_platform_probe,
- .remove = stm_drm_platform_remove,
+ .remove_new = stm_drm_platform_remove,
.driver = {
.name = "stm32-display",
.of_match_table = drv_dt_ids,
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 89897d5f5c72..a7c349404a7a 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -537,15 +537,13 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
return ret;
}
-static int dw_mipi_dsi_stm_remove(struct platform_device *pdev)
+static void dw_mipi_dsi_stm_remove(struct platform_device *pdev)
{
struct dw_mipi_dsi_stm *dsi = platform_get_drvdata(pdev);
dw_mipi_dsi_remove(dsi->dsi);
clk_disable_unprepare(dsi->pllref_clk);
regulator_disable(dsi->vdd_supply);
-
- return 0;
}
static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
@@ -590,7 +588,7 @@ static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
static struct platform_driver dw_mipi_dsi_stm_driver = {
.probe = dw_mipi_dsi_stm_probe,
- .remove = dw_mipi_dsi_stm_remove,
+ .remove_new = dw_mipi_dsi_stm_remove,
.driver = {
.of_match_table = dw_mipi_dsi_stm_dt_ids,
.name = "stm32-display-dsi",
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 42/53] drm/stm: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu, David Airlie,
Daniel Vetter, Maxime Coquelin, Alexandre Torgue
Cc: linux-arm-kernel, kernel, linux-stm32, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the stm drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/stm/drv.c | 6 ++----
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 50410bd99dfe..be91b375a4d5 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -213,7 +213,7 @@ static int stm_drm_platform_probe(struct platform_device *pdev)
return ret;
}
-static int stm_drm_platform_remove(struct platform_device *pdev)
+static void stm_drm_platform_remove(struct platform_device *pdev)
{
struct drm_device *ddev = platform_get_drvdata(pdev);
@@ -222,8 +222,6 @@ static int stm_drm_platform_remove(struct platform_device *pdev)
drm_dev_unregister(ddev);
drv_unload(ddev);
drm_dev_put(ddev);
-
- return 0;
}
static const struct of_device_id drv_dt_ids[] = {
@@ -234,7 +232,7 @@ MODULE_DEVICE_TABLE(of, drv_dt_ids);
static struct platform_driver stm_drm_platform_driver = {
.probe = stm_drm_platform_probe,
- .remove = stm_drm_platform_remove,
+ .remove_new = stm_drm_platform_remove,
.driver = {
.name = "stm32-display",
.of_match_table = drv_dt_ids,
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 89897d5f5c72..a7c349404a7a 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -537,15 +537,13 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
return ret;
}
-static int dw_mipi_dsi_stm_remove(struct platform_device *pdev)
+static void dw_mipi_dsi_stm_remove(struct platform_device *pdev)
{
struct dw_mipi_dsi_stm *dsi = platform_get_drvdata(pdev);
dw_mipi_dsi_remove(dsi->dsi);
clk_disable_unprepare(dsi->pllref_clk);
regulator_disable(dsi->vdd_supply);
-
- return 0;
}
static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
@@ -590,7 +588,7 @@ static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
static struct platform_driver dw_mipi_dsi_stm_driver = {
.probe = dw_mipi_dsi_stm_probe,
- .remove = dw_mipi_dsi_stm_remove,
+ .remove_new = dw_mipi_dsi_stm_remove,
.driver = {
.of_match_table = dw_mipi_dsi_stm_dt_ids,
.name = "stm32-display-dsi",
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 42/53] drm/stm: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-15 13:53 ` Raphael Gallais-Pou
-1 siblings, 0 replies; 261+ messages in thread
From: Raphael Gallais-Pou @ 2023-05-15 13:53 UTC (permalink / raw)
To: Uwe Kleine-König, Yannick Fertre, Philippe Cornu,
David Airlie, Daniel Vetter, Maxime Coquelin, Alexandre Torgue
Cc: dri-devel, linux-stm32, linux-arm-kernel, kernel
Hi Uwe,
On 5/7/23 18:26, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the stm drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Thanks for you patch
Raphaël G.-P.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 42/53] drm/stm: Convert to platform remove callback returning void
@ 2023-05-15 13:53 ` Raphael Gallais-Pou
0 siblings, 0 replies; 261+ messages in thread
From: Raphael Gallais-Pou @ 2023-05-15 13:53 UTC (permalink / raw)
To: Uwe Kleine-König, Yannick Fertre, Philippe Cornu,
David Airlie, Daniel Vetter, Maxime Coquelin, Alexandre Torgue
Cc: linux-arm-kernel, kernel, linux-stm32, dri-devel
Hi Uwe,
On 5/7/23 18:26, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the stm drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Raphaël Gallais-Pou <raphael.gallais-pou@foss.st.com>
Thanks for you patch
Raphaël G.-P.
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 43/53] drm/sun4i: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, David Airlie, Daniel Vetter,
Jernej Skrabec, Samuel Holland
Cc: dri-devel, linux-arm-kernel, linux-sunxi, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the sun4i drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
11 files changed, 22 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 38070fc261f3..b70950137bf1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -965,11 +965,9 @@ static int sun4i_backend_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_backend_ops);
}
-static int sun4i_backend_remove(struct platform_device *pdev)
+static void sun4i_backend_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_backend_ops);
-
- return 0;
}
static const struct sun4i_backend_quirks sun4i_backend_quirks = {
@@ -1028,7 +1026,7 @@ MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
static struct platform_driver sun4i_backend_platform_driver = {
.probe = sun4i_backend_probe,
- .remove = sun4i_backend_remove,
+ .remove_new = sun4i_backend_remove,
.driver = {
.name = "sun4i-backend",
.of_match_table = sun4i_backend_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index d6c741716167..1449b7ea66d3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -408,11 +408,9 @@ static int sun4i_drv_probe(struct platform_device *pdev)
return 0;
}
-static int sun4i_drv_remove(struct platform_device *pdev)
+static void sun4i_drv_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &sun4i_drv_master_ops);
-
- return 0;
}
static const struct of_device_id sun4i_drv_of_table[] = {
@@ -438,7 +436,7 @@ MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
static struct platform_driver sun4i_drv_platform_driver = {
.probe = sun4i_drv_probe,
- .remove = sun4i_drv_remove,
+ .remove_new = sun4i_drv_remove,
.driver = {
.name = "sun4i-drm",
.of_match_table = sun4i_drv_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 799ab7460ae5..3872c91a85c7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -634,11 +634,9 @@ static int sun4i_frontend_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_frontend_ops);
}
-static int sun4i_frontend_remove(struct platform_device *pdev)
+static void sun4i_frontend_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_frontend_ops);
-
- return 0;
}
static int sun4i_frontend_runtime_resume(struct device *dev)
@@ -719,7 +717,7 @@ MODULE_DEVICE_TABLE(of, sun4i_frontend_of_table);
static struct platform_driver sun4i_frontend_driver = {
.probe = sun4i_frontend_probe,
- .remove = sun4i_frontend_remove,
+ .remove_new = sun4i_frontend_remove,
.driver = {
.name = "sun4i-frontend",
.of_match_table = sun4i_frontend_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index c0df5e892fa7..c139e1262e03 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -693,11 +693,9 @@ static int sun4i_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_hdmi_ops);
}
-static int sun4i_hdmi_remove(struct platform_device *pdev)
+static void sun4i_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_hdmi_ops);
-
- return 0;
}
static const struct of_device_id sun4i_hdmi_of_table[] = {
@@ -710,7 +708,7 @@ MODULE_DEVICE_TABLE(of, sun4i_hdmi_of_table);
static struct platform_driver sun4i_hdmi_driver = {
.probe = sun4i_hdmi_probe,
- .remove = sun4i_hdmi_remove,
+ .remove_new = sun4i_hdmi_remove,
.driver = {
.name = "sun4i-hdmi",
.of_match_table = sun4i_hdmi_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 523a6d787921..f0a3752878fe 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1336,11 +1336,9 @@ static int sun4i_tcon_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_tcon_ops);
}
-static int sun4i_tcon_remove(struct platform_device *pdev)
+static void sun4i_tcon_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_tcon_ops);
-
- return 0;
}
/* platform specific TCON muxing callbacks */
@@ -1575,7 +1573,7 @@ EXPORT_SYMBOL(sun4i_tcon_of_table);
static struct platform_driver sun4i_tcon_platform_driver = {
.probe = sun4i_tcon_probe,
- .remove = sun4i_tcon_remove,
+ .remove_new = sun4i_tcon_remove,
.driver = {
.name = "sun4i-tcon",
.of_match_table = sun4i_tcon_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 9625a00a48ba..ec65d9d59de7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -546,11 +546,9 @@ static int sun4i_tv_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_tv_ops);
}
-static int sun4i_tv_remove(struct platform_device *pdev)
+static void sun4i_tv_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_tv_ops);
-
- return 0;
}
static const struct of_device_id sun4i_tv_of_table[] = {
@@ -561,7 +559,7 @@ MODULE_DEVICE_TABLE(of, sun4i_tv_of_table);
static struct platform_driver sun4i_tv_platform_driver = {
.probe = sun4i_tv_probe,
- .remove = sun4i_tv_remove,
+ .remove_new = sun4i_tv_remove,
.driver = {
.name = "sun4i-tve",
.of_match_table = sun4i_tv_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
index 4fbe9a6b5182..0d342f43fa93 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -95,11 +95,9 @@ static int sun6i_drc_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun6i_drc_ops);
}
-static int sun6i_drc_remove(struct platform_device *pdev)
+static void sun6i_drc_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun6i_drc_ops);
-
- return 0;
}
static const struct of_device_id sun6i_drc_of_table[] = {
@@ -114,7 +112,7 @@ MODULE_DEVICE_TABLE(of, sun6i_drc_of_table);
static struct platform_driver sun6i_drc_platform_driver = {
.probe = sun6i_drc_probe,
- .remove = sun6i_drc_remove,
+ .remove_new = sun6i_drc_remove,
.driver = {
.name = "sun6i-drc",
.of_match_table = sun6i_drc_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 760ff05eabf4..4abf4f102007 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1200,7 +1200,7 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int sun6i_dsi_remove(struct platform_device *pdev)
+static void sun6i_dsi_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
@@ -1211,8 +1211,6 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
clk_rate_exclusive_put(dsi->mod_clk);
regmap_mmio_detach_clk(dsi->regs);
-
- return 0;
}
static const struct sun6i_dsi_variant sun6i_a31_mipi_dsi_variant = {
@@ -1246,7 +1244,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
static struct platform_driver sun6i_dsi_platform_driver = {
.probe = sun6i_dsi_probe,
- .remove = sun6i_dsi_remove,
+ .remove_new = sun6i_dsi_remove,
.driver = {
.name = "sun6i-mipi-dsi",
.of_match_table = sun6i_dsi_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 7cab4213a680..26dd8f0dde99 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -235,11 +235,9 @@ static int sun8i_dw_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_dw_hdmi_ops);
}
-static int sun8i_dw_hdmi_remove(struct platform_device *pdev)
+static void sun8i_dw_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_dw_hdmi_ops);
-
- return 0;
}
static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
@@ -266,7 +264,7 @@ MODULE_DEVICE_TABLE(of, sun8i_dw_hdmi_dt_ids);
static struct platform_driver sun8i_dw_hdmi_pltfm_driver = {
.probe = sun8i_dw_hdmi_probe,
- .remove = sun8i_dw_hdmi_remove,
+ .remove_new = sun8i_dw_hdmi_remove,
.driver = {
.name = "sun8i-dw-hdmi",
.of_match_table = sun8i_dw_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index bafee05f6b24..e4a73ca08365 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -555,11 +555,9 @@ static int sun8i_mixer_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_mixer_ops);
}
-static int sun8i_mixer_remove(struct platform_device *pdev)
+static void sun8i_mixer_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_mixer_ops);
-
- return 0;
}
static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg = {
@@ -711,7 +709,7 @@ MODULE_DEVICE_TABLE(of, sun8i_mixer_of_table);
static struct platform_driver sun8i_mixer_platform_driver = {
.probe = sun8i_mixer_probe,
- .remove = sun8i_mixer_remove,
+ .remove_new = sun8i_mixer_remove,
.driver = {
.name = "sun8i-mixer",
.of_match_table = sun8i_mixer_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index da97682b6835..2e8dd7723e29 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -261,11 +261,9 @@ static int sun8i_tcon_top_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_tcon_top_ops);
}
-static int sun8i_tcon_top_remove(struct platform_device *pdev)
+static void sun8i_tcon_top_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_tcon_top_ops);
-
- return 0;
}
static const struct sun8i_tcon_top_quirks sun8i_r40_tcon_top_quirks = {
@@ -302,7 +300,7 @@ EXPORT_SYMBOL(sun8i_tcon_top_of_table);
static struct platform_driver sun8i_tcon_top_platform_driver = {
.probe = sun8i_tcon_top_probe,
- .remove = sun8i_tcon_top_remove,
+ .remove_new = sun8i_tcon_top_remove,
.driver = {
.name = "sun8i-tcon-top",
.of_match_table = sun8i_tcon_top_of_table,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 43/53] drm/sun4i: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, David Airlie, Daniel Vetter,
Jernej Skrabec, Samuel Holland
Cc: kernel, linux-arm-kernel, dri-devel, linux-sunxi
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the sun4i drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
11 files changed, 22 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 38070fc261f3..b70950137bf1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -965,11 +965,9 @@ static int sun4i_backend_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_backend_ops);
}
-static int sun4i_backend_remove(struct platform_device *pdev)
+static void sun4i_backend_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_backend_ops);
-
- return 0;
}
static const struct sun4i_backend_quirks sun4i_backend_quirks = {
@@ -1028,7 +1026,7 @@ MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
static struct platform_driver sun4i_backend_platform_driver = {
.probe = sun4i_backend_probe,
- .remove = sun4i_backend_remove,
+ .remove_new = sun4i_backend_remove,
.driver = {
.name = "sun4i-backend",
.of_match_table = sun4i_backend_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index d6c741716167..1449b7ea66d3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -408,11 +408,9 @@ static int sun4i_drv_probe(struct platform_device *pdev)
return 0;
}
-static int sun4i_drv_remove(struct platform_device *pdev)
+static void sun4i_drv_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &sun4i_drv_master_ops);
-
- return 0;
}
static const struct of_device_id sun4i_drv_of_table[] = {
@@ -438,7 +436,7 @@ MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
static struct platform_driver sun4i_drv_platform_driver = {
.probe = sun4i_drv_probe,
- .remove = sun4i_drv_remove,
+ .remove_new = sun4i_drv_remove,
.driver = {
.name = "sun4i-drm",
.of_match_table = sun4i_drv_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 799ab7460ae5..3872c91a85c7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -634,11 +634,9 @@ static int sun4i_frontend_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_frontend_ops);
}
-static int sun4i_frontend_remove(struct platform_device *pdev)
+static void sun4i_frontend_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_frontend_ops);
-
- return 0;
}
static int sun4i_frontend_runtime_resume(struct device *dev)
@@ -719,7 +717,7 @@ MODULE_DEVICE_TABLE(of, sun4i_frontend_of_table);
static struct platform_driver sun4i_frontend_driver = {
.probe = sun4i_frontend_probe,
- .remove = sun4i_frontend_remove,
+ .remove_new = sun4i_frontend_remove,
.driver = {
.name = "sun4i-frontend",
.of_match_table = sun4i_frontend_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index c0df5e892fa7..c139e1262e03 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -693,11 +693,9 @@ static int sun4i_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_hdmi_ops);
}
-static int sun4i_hdmi_remove(struct platform_device *pdev)
+static void sun4i_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_hdmi_ops);
-
- return 0;
}
static const struct of_device_id sun4i_hdmi_of_table[] = {
@@ -710,7 +708,7 @@ MODULE_DEVICE_TABLE(of, sun4i_hdmi_of_table);
static struct platform_driver sun4i_hdmi_driver = {
.probe = sun4i_hdmi_probe,
- .remove = sun4i_hdmi_remove,
+ .remove_new = sun4i_hdmi_remove,
.driver = {
.name = "sun4i-hdmi",
.of_match_table = sun4i_hdmi_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 523a6d787921..f0a3752878fe 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1336,11 +1336,9 @@ static int sun4i_tcon_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_tcon_ops);
}
-static int sun4i_tcon_remove(struct platform_device *pdev)
+static void sun4i_tcon_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_tcon_ops);
-
- return 0;
}
/* platform specific TCON muxing callbacks */
@@ -1575,7 +1573,7 @@ EXPORT_SYMBOL(sun4i_tcon_of_table);
static struct platform_driver sun4i_tcon_platform_driver = {
.probe = sun4i_tcon_probe,
- .remove = sun4i_tcon_remove,
+ .remove_new = sun4i_tcon_remove,
.driver = {
.name = "sun4i-tcon",
.of_match_table = sun4i_tcon_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 9625a00a48ba..ec65d9d59de7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -546,11 +546,9 @@ static int sun4i_tv_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_tv_ops);
}
-static int sun4i_tv_remove(struct platform_device *pdev)
+static void sun4i_tv_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_tv_ops);
-
- return 0;
}
static const struct of_device_id sun4i_tv_of_table[] = {
@@ -561,7 +559,7 @@ MODULE_DEVICE_TABLE(of, sun4i_tv_of_table);
static struct platform_driver sun4i_tv_platform_driver = {
.probe = sun4i_tv_probe,
- .remove = sun4i_tv_remove,
+ .remove_new = sun4i_tv_remove,
.driver = {
.name = "sun4i-tve",
.of_match_table = sun4i_tv_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
index 4fbe9a6b5182..0d342f43fa93 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -95,11 +95,9 @@ static int sun6i_drc_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun6i_drc_ops);
}
-static int sun6i_drc_remove(struct platform_device *pdev)
+static void sun6i_drc_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun6i_drc_ops);
-
- return 0;
}
static const struct of_device_id sun6i_drc_of_table[] = {
@@ -114,7 +112,7 @@ MODULE_DEVICE_TABLE(of, sun6i_drc_of_table);
static struct platform_driver sun6i_drc_platform_driver = {
.probe = sun6i_drc_probe,
- .remove = sun6i_drc_remove,
+ .remove_new = sun6i_drc_remove,
.driver = {
.name = "sun6i-drc",
.of_match_table = sun6i_drc_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 760ff05eabf4..4abf4f102007 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1200,7 +1200,7 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int sun6i_dsi_remove(struct platform_device *pdev)
+static void sun6i_dsi_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
@@ -1211,8 +1211,6 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
clk_rate_exclusive_put(dsi->mod_clk);
regmap_mmio_detach_clk(dsi->regs);
-
- return 0;
}
static const struct sun6i_dsi_variant sun6i_a31_mipi_dsi_variant = {
@@ -1246,7 +1244,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
static struct platform_driver sun6i_dsi_platform_driver = {
.probe = sun6i_dsi_probe,
- .remove = sun6i_dsi_remove,
+ .remove_new = sun6i_dsi_remove,
.driver = {
.name = "sun6i-mipi-dsi",
.of_match_table = sun6i_dsi_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 7cab4213a680..26dd8f0dde99 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -235,11 +235,9 @@ static int sun8i_dw_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_dw_hdmi_ops);
}
-static int sun8i_dw_hdmi_remove(struct platform_device *pdev)
+static void sun8i_dw_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_dw_hdmi_ops);
-
- return 0;
}
static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
@@ -266,7 +264,7 @@ MODULE_DEVICE_TABLE(of, sun8i_dw_hdmi_dt_ids);
static struct platform_driver sun8i_dw_hdmi_pltfm_driver = {
.probe = sun8i_dw_hdmi_probe,
- .remove = sun8i_dw_hdmi_remove,
+ .remove_new = sun8i_dw_hdmi_remove,
.driver = {
.name = "sun8i-dw-hdmi",
.of_match_table = sun8i_dw_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index bafee05f6b24..e4a73ca08365 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -555,11 +555,9 @@ static int sun8i_mixer_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_mixer_ops);
}
-static int sun8i_mixer_remove(struct platform_device *pdev)
+static void sun8i_mixer_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_mixer_ops);
-
- return 0;
}
static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg = {
@@ -711,7 +709,7 @@ MODULE_DEVICE_TABLE(of, sun8i_mixer_of_table);
static struct platform_driver sun8i_mixer_platform_driver = {
.probe = sun8i_mixer_probe,
- .remove = sun8i_mixer_remove,
+ .remove_new = sun8i_mixer_remove,
.driver = {
.name = "sun8i-mixer",
.of_match_table = sun8i_mixer_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index da97682b6835..2e8dd7723e29 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -261,11 +261,9 @@ static int sun8i_tcon_top_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_tcon_top_ops);
}
-static int sun8i_tcon_top_remove(struct platform_device *pdev)
+static void sun8i_tcon_top_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_tcon_top_ops);
-
- return 0;
}
static const struct sun8i_tcon_top_quirks sun8i_r40_tcon_top_quirks = {
@@ -302,7 +300,7 @@ EXPORT_SYMBOL(sun8i_tcon_top_of_table);
static struct platform_driver sun8i_tcon_top_platform_driver = {
.probe = sun8i_tcon_top_probe,
- .remove = sun8i_tcon_top_remove,
+ .remove_new = sun8i_tcon_top_remove,
.driver = {
.name = "sun8i-tcon-top",
.of_match_table = sun8i_tcon_top_of_table,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 43/53] drm/sun4i: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, David Airlie, Daniel Vetter,
Jernej Skrabec, Samuel Holland
Cc: dri-devel, linux-arm-kernel, linux-sunxi, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the sun4i drm drivers from always returning zero in
the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
11 files changed, 22 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 38070fc261f3..b70950137bf1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -965,11 +965,9 @@ static int sun4i_backend_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_backend_ops);
}
-static int sun4i_backend_remove(struct platform_device *pdev)
+static void sun4i_backend_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_backend_ops);
-
- return 0;
}
static const struct sun4i_backend_quirks sun4i_backend_quirks = {
@@ -1028,7 +1026,7 @@ MODULE_DEVICE_TABLE(of, sun4i_backend_of_table);
static struct platform_driver sun4i_backend_platform_driver = {
.probe = sun4i_backend_probe,
- .remove = sun4i_backend_remove,
+ .remove_new = sun4i_backend_remove,
.driver = {
.name = "sun4i-backend",
.of_match_table = sun4i_backend_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index d6c741716167..1449b7ea66d3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -408,11 +408,9 @@ static int sun4i_drv_probe(struct platform_device *pdev)
return 0;
}
-static int sun4i_drv_remove(struct platform_device *pdev)
+static void sun4i_drv_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &sun4i_drv_master_ops);
-
- return 0;
}
static const struct of_device_id sun4i_drv_of_table[] = {
@@ -438,7 +436,7 @@ MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
static struct platform_driver sun4i_drv_platform_driver = {
.probe = sun4i_drv_probe,
- .remove = sun4i_drv_remove,
+ .remove_new = sun4i_drv_remove,
.driver = {
.name = "sun4i-drm",
.of_match_table = sun4i_drv_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 799ab7460ae5..3872c91a85c7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -634,11 +634,9 @@ static int sun4i_frontend_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_frontend_ops);
}
-static int sun4i_frontend_remove(struct platform_device *pdev)
+static void sun4i_frontend_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_frontend_ops);
-
- return 0;
}
static int sun4i_frontend_runtime_resume(struct device *dev)
@@ -719,7 +717,7 @@ MODULE_DEVICE_TABLE(of, sun4i_frontend_of_table);
static struct platform_driver sun4i_frontend_driver = {
.probe = sun4i_frontend_probe,
- .remove = sun4i_frontend_remove,
+ .remove_new = sun4i_frontend_remove,
.driver = {
.name = "sun4i-frontend",
.of_match_table = sun4i_frontend_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index c0df5e892fa7..c139e1262e03 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -693,11 +693,9 @@ static int sun4i_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_hdmi_ops);
}
-static int sun4i_hdmi_remove(struct platform_device *pdev)
+static void sun4i_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_hdmi_ops);
-
- return 0;
}
static const struct of_device_id sun4i_hdmi_of_table[] = {
@@ -710,7 +708,7 @@ MODULE_DEVICE_TABLE(of, sun4i_hdmi_of_table);
static struct platform_driver sun4i_hdmi_driver = {
.probe = sun4i_hdmi_probe,
- .remove = sun4i_hdmi_remove,
+ .remove_new = sun4i_hdmi_remove,
.driver = {
.name = "sun4i-hdmi",
.of_match_table = sun4i_hdmi_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 523a6d787921..f0a3752878fe 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1336,11 +1336,9 @@ static int sun4i_tcon_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_tcon_ops);
}
-static int sun4i_tcon_remove(struct platform_device *pdev)
+static void sun4i_tcon_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_tcon_ops);
-
- return 0;
}
/* platform specific TCON muxing callbacks */
@@ -1575,7 +1573,7 @@ EXPORT_SYMBOL(sun4i_tcon_of_table);
static struct platform_driver sun4i_tcon_platform_driver = {
.probe = sun4i_tcon_probe,
- .remove = sun4i_tcon_remove,
+ .remove_new = sun4i_tcon_remove,
.driver = {
.name = "sun4i-tcon",
.of_match_table = sun4i_tcon_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 9625a00a48ba..ec65d9d59de7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -546,11 +546,9 @@ static int sun4i_tv_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun4i_tv_ops);
}
-static int sun4i_tv_remove(struct platform_device *pdev)
+static void sun4i_tv_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun4i_tv_ops);
-
- return 0;
}
static const struct of_device_id sun4i_tv_of_table[] = {
@@ -561,7 +559,7 @@ MODULE_DEVICE_TABLE(of, sun4i_tv_of_table);
static struct platform_driver sun4i_tv_platform_driver = {
.probe = sun4i_tv_probe,
- .remove = sun4i_tv_remove,
+ .remove_new = sun4i_tv_remove,
.driver = {
.name = "sun4i-tve",
.of_match_table = sun4i_tv_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
index 4fbe9a6b5182..0d342f43fa93 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -95,11 +95,9 @@ static int sun6i_drc_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun6i_drc_ops);
}
-static int sun6i_drc_remove(struct platform_device *pdev)
+static void sun6i_drc_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun6i_drc_ops);
-
- return 0;
}
static const struct of_device_id sun6i_drc_of_table[] = {
@@ -114,7 +112,7 @@ MODULE_DEVICE_TABLE(of, sun6i_drc_of_table);
static struct platform_driver sun6i_drc_platform_driver = {
.probe = sun6i_drc_probe,
- .remove = sun6i_drc_remove,
+ .remove_new = sun6i_drc_remove,
.driver = {
.name = "sun6i-drc",
.of_match_table = sun6i_drc_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 760ff05eabf4..4abf4f102007 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1200,7 +1200,7 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return ret;
}
-static int sun6i_dsi_remove(struct platform_device *pdev)
+static void sun6i_dsi_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct sun6i_dsi *dsi = dev_get_drvdata(dev);
@@ -1211,8 +1211,6 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
clk_rate_exclusive_put(dsi->mod_clk);
regmap_mmio_detach_clk(dsi->regs);
-
- return 0;
}
static const struct sun6i_dsi_variant sun6i_a31_mipi_dsi_variant = {
@@ -1246,7 +1244,7 @@ MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
static struct platform_driver sun6i_dsi_platform_driver = {
.probe = sun6i_dsi_probe,
- .remove = sun6i_dsi_remove,
+ .remove_new = sun6i_dsi_remove,
.driver = {
.name = "sun6i-mipi-dsi",
.of_match_table = sun6i_dsi_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 7cab4213a680..26dd8f0dde99 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -235,11 +235,9 @@ static int sun8i_dw_hdmi_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_dw_hdmi_ops);
}
-static int sun8i_dw_hdmi_remove(struct platform_device *pdev)
+static void sun8i_dw_hdmi_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_dw_hdmi_ops);
-
- return 0;
}
static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
@@ -266,7 +264,7 @@ MODULE_DEVICE_TABLE(of, sun8i_dw_hdmi_dt_ids);
static struct platform_driver sun8i_dw_hdmi_pltfm_driver = {
.probe = sun8i_dw_hdmi_probe,
- .remove = sun8i_dw_hdmi_remove,
+ .remove_new = sun8i_dw_hdmi_remove,
.driver = {
.name = "sun8i-dw-hdmi",
.of_match_table = sun8i_dw_hdmi_dt_ids,
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index bafee05f6b24..e4a73ca08365 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -555,11 +555,9 @@ static int sun8i_mixer_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_mixer_ops);
}
-static int sun8i_mixer_remove(struct platform_device *pdev)
+static void sun8i_mixer_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_mixer_ops);
-
- return 0;
}
static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg = {
@@ -711,7 +709,7 @@ MODULE_DEVICE_TABLE(of, sun8i_mixer_of_table);
static struct platform_driver sun8i_mixer_platform_driver = {
.probe = sun8i_mixer_probe,
- .remove = sun8i_mixer_remove,
+ .remove_new = sun8i_mixer_remove,
.driver = {
.name = "sun8i-mixer",
.of_match_table = sun8i_mixer_of_table,
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
index da97682b6835..2e8dd7723e29 100644
--- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -261,11 +261,9 @@ static int sun8i_tcon_top_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &sun8i_tcon_top_ops);
}
-static int sun8i_tcon_top_remove(struct platform_device *pdev)
+static void sun8i_tcon_top_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &sun8i_tcon_top_ops);
-
- return 0;
}
static const struct sun8i_tcon_top_quirks sun8i_r40_tcon_top_quirks = {
@@ -302,7 +300,7 @@ EXPORT_SYMBOL(sun8i_tcon_top_of_table);
static struct platform_driver sun8i_tcon_top_platform_driver = {
.probe = sun8i_tcon_top_probe,
- .remove = sun8i_tcon_top_remove,
+ .remove_new = sun8i_tcon_top_remove,
.driver = {
.name = "sun8i-tcon-top",
.of_match_table = sun8i_tcon_top_of_table,
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread
* [PATCH 44/53] drm/tegra: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Thierry Reding, David Airlie, Daniel Vetter, Jonathan Hunter
Cc: dri-devel, linux-tegra, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tegra/dpaux.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 3c84e73d5051..4d2677dcd831 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -579,7 +579,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
return 0;
}
-static int tegra_dpaux_remove(struct platform_device *pdev)
+static void tegra_dpaux_remove(struct platform_device *pdev)
{
struct tegra_dpaux *dpaux = platform_get_drvdata(pdev);
@@ -594,8 +594,6 @@ static int tegra_dpaux_remove(struct platform_device *pdev)
mutex_lock(&dpaux_lock);
list_del(&dpaux->list);
mutex_unlock(&dpaux_lock);
-
- return 0;
}
static int tegra_dpaux_suspend(struct device *dev)
@@ -695,7 +693,7 @@ struct platform_driver tegra_dpaux_driver = {
.pm = pm_ptr(&tegra_dpaux_pm_ops),
},
.probe = tegra_dpaux_probe,
- .remove = tegra_dpaux_remove,
+ .remove_new = tegra_dpaux_remove,
};
struct drm_dp_aux *drm_dp_aux_find_by_of_node(struct device_node *np)
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 44/53] drm/tegra: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Thierry Reding, David Airlie, Daniel Vetter, Jonathan Hunter
Cc: linux-tegra, kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tegra/dpaux.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 3c84e73d5051..4d2677dcd831 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -579,7 +579,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
return 0;
}
-static int tegra_dpaux_remove(struct platform_device *pdev)
+static void tegra_dpaux_remove(struct platform_device *pdev)
{
struct tegra_dpaux *dpaux = platform_get_drvdata(pdev);
@@ -594,8 +594,6 @@ static int tegra_dpaux_remove(struct platform_device *pdev)
mutex_lock(&dpaux_lock);
list_del(&dpaux->list);
mutex_unlock(&dpaux_lock);
-
- return 0;
}
static int tegra_dpaux_suspend(struct device *dev)
@@ -695,7 +693,7 @@ struct platform_driver tegra_dpaux_driver = {
.pm = pm_ptr(&tegra_dpaux_pm_ops),
},
.probe = tegra_dpaux_probe,
- .remove = tegra_dpaux_remove,
+ .remove_new = tegra_dpaux_remove,
};
struct drm_dp_aux *drm_dp_aux_find_by_of_node(struct device_node *np)
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread
* [PATCH 45/53] drm/tests: helpers: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (47 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
2023-05-08 22:10 ` Maíra Canal
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: David Airlie, Daniel Vetter, Maxime Ripard, Maíra Canal,
Javier Martinez Canillas, Noralf Trønnes
Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index e98b4150f556..049b98daedbb 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -19,14 +19,13 @@ static int fake_probe(struct platform_device *pdev)
return 0;
}
-static int fake_remove(struct platform_device *pdev)
+static void fake_remove(struct platform_device *pdev)
{
- return 0;
}
static struct platform_driver fake_platform_driver = {
.probe = fake_probe,
- .remove = fake_remove,
+ .remove_new = fake_remove,
.driver = {
.name = KUNIT_DEVICE_NAME,
},
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 45/53] drm/tests: helpers: Convert to platform remove callback returning void
2023-05-07 16:26 ` [PATCH 45/53] drm/tests: helpers: " Uwe Kleine-König
@ 2023-05-08 22:10 ` Maíra Canal
2023-05-09 5:51 ` Uwe Kleine-König
0 siblings, 1 reply; 261+ messages in thread
From: Maíra Canal @ 2023-05-08 22:10 UTC (permalink / raw)
To: Uwe Kleine-König, David Airlie, Daniel Vetter, Maxime Ripard,
Javier Martinez Canillas, Noralf Trønnes
Cc: kernel, dri-devel
Hi Uwe,
On 5/7/23 13:26, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c b/drivers/gpu/drm/tests/drm_kunit_helpers.c
> index e98b4150f556..049b98daedbb 100644
> --- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
> +++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
> @@ -19,14 +19,13 @@ static int fake_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int fake_remove(struct platform_device *pdev)
> +static void fake_remove(struct platform_device *pdev)
> {
> - return 0;
> }
This function was removed on commit 96c25b03145a. I'm not sure if
we should bring it back.
Best Regards,
- Maíra Canal
>
> static struct platform_driver fake_platform_driver = {
> .probe = fake_probe,
> - .remove = fake_remove,
> + .remove_new = fake_remove,
> .driver = {
> .name = KUNIT_DEVICE_NAME,
> },
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 45/53] drm/tests: helpers: Convert to platform remove callback returning void
2023-05-08 22:10 ` Maíra Canal
@ 2023-05-09 5:51 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-09 5:51 UTC (permalink / raw)
To: Maíra Canal
Cc: Javier Martinez Canillas, dri-devel, Noralf Trønnes,
Maxime Ripard, kernel
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On Mon, May 08, 2023 at 07:10:27PM -0300, Maíra Canal wrote:
> Hi Uwe,
>
> On 5/7/23 13:26, Uwe Kleine-König wrote:
> > The .remove() callback for a platform driver returns an int which makes
> > many driver authors wrongly assume it's possible to do error handling by
> > returning an error code. However the value returned is (mostly) ignored
> > and this typically results in resource leaks. To improve here there is a
> > quest to make the remove callback return void. In the first step of this
> > quest all drivers are converted to .remove_new() which already returns
> > void.
> >
> > Trivially convert this driver from always returning zero in the remove
> > callback to the void returning variant.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c b/drivers/gpu/drm/tests/drm_kunit_helpers.c
> > index e98b4150f556..049b98daedbb 100644
> > --- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
> > +++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
> > @@ -19,14 +19,13 @@ static int fake_probe(struct platform_device *pdev)
> > return 0;
> > }
> > -static int fake_remove(struct platform_device *pdev)
> > +static void fake_remove(struct platform_device *pdev)
> > {
> > - return 0;
> > }
>
> This function was removed on commit 96c25b03145a. I'm not sure if
> we should bring it back.
Indeed. I sent my patch series before v6.4-rc1 was published and so
based it on top of v6.3, which doesn't include 96c25b03145a. Please
don't bring back fake_remove(), just drop this patch instead.
Thanks
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] 261+ messages in thread
* [PATCH 46/53] drm/tidss: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (48 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
2023-05-09 8:11 ` Tomi Valkeinen
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Jyri Sarha, Tomi Valkeinen, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index 2dac8727d2f4..13177d58c8f9 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -197,7 +197,7 @@ static int tidss_probe(struct platform_device *pdev)
return ret;
}
-static int tidss_remove(struct platform_device *pdev)
+static void tidss_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct tidss_device *tidss = platform_get_drvdata(pdev);
@@ -221,8 +221,6 @@ static int tidss_remove(struct platform_device *pdev)
dispc_remove(tidss);
dev_dbg(dev, "%s done\n", __func__);
-
- return 0;
}
static void tidss_shutdown(struct platform_device *pdev)
@@ -241,7 +239,7 @@ MODULE_DEVICE_TABLE(of, tidss_of_table);
static struct platform_driver tidss_platform_driver = {
.probe = tidss_probe,
- .remove = tidss_remove,
+ .remove_new = tidss_remove,
.shutdown = tidss_shutdown,
.driver = {
.name = "tidss",
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 46/53] drm/tidss: Convert to platform remove callback returning void
2023-05-07 16:26 ` [PATCH 46/53] drm/tidss: " Uwe Kleine-König
@ 2023-05-09 8:11 ` Tomi Valkeinen
0 siblings, 0 replies; 261+ messages in thread
From: Tomi Valkeinen @ 2023-05-09 8:11 UTC (permalink / raw)
To: Uwe Kleine-König, Jyri Sarha, David Airlie, Daniel Vetter
Cc: kernel, dri-devel
On 07/05/2023 19:26, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
> index 2dac8727d2f4..13177d58c8f9 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> @@ -197,7 +197,7 @@ static int tidss_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int tidss_remove(struct platform_device *pdev)
> +static void tidss_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct tidss_device *tidss = platform_get_drvdata(pdev);
> @@ -221,8 +221,6 @@ static int tidss_remove(struct platform_device *pdev)
> dispc_remove(tidss);
>
> dev_dbg(dev, "%s done\n", __func__);
> -
> - return 0;
> }
>
> static void tidss_shutdown(struct platform_device *pdev)
> @@ -241,7 +239,7 @@ MODULE_DEVICE_TABLE(of, tidss_of_table);
>
> static struct platform_driver tidss_platform_driver = {
> .probe = tidss_probe,
> - .remove = tidss_remove,
> + .remove_new = tidss_remove,
> .shutdown = tidss_shutdown,
> .driver = {
> .name = "tidss",
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 47/53] drm/tilcdc: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (49 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Jyri Sarha, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel, Tomi Valkeinen
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 2729e16bc053..9aefd010acde 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -374,7 +374,7 @@ static int panel_probe(struct platform_device *pdev)
return ret;
}
-static int panel_remove(struct platform_device *pdev)
+static void panel_remove(struct platform_device *pdev)
{
struct tilcdc_module *mod = dev_get_platdata(&pdev->dev);
struct panel_module *panel_mod = to_panel_module(mod);
@@ -387,8 +387,6 @@ static int panel_remove(struct platform_device *pdev)
tilcdc_module_cleanup(mod);
kfree(panel_mod->info);
-
- return 0;
}
static const struct of_device_id panel_of_match[] = {
@@ -398,7 +396,7 @@ static const struct of_device_id panel_of_match[] = {
static struct platform_driver panel_driver = {
.probe = panel_probe,
- .remove = panel_remove,
+ .remove_new = panel_remove,
.driver = {
.name = "tilcdc-panel",
.of_match_table = panel_of_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 48/53] drm/tiny: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (50 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
2023-05-08 7:03 ` Thomas Zimmermann
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Alexey Brodkin, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index 611bbee15071..a1f998a85ce8 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -404,14 +404,12 @@ static int arcpgu_probe(struct platform_device *pdev)
return ret;
}
-static int arcpgu_remove(struct platform_device *pdev)
+static void arcpgu_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
drm_dev_unregister(drm);
arcpgu_unload(drm);
-
- return 0;
}
static const struct of_device_id arcpgu_of_table[] = {
@@ -423,7 +421,7 @@ MODULE_DEVICE_TABLE(of, arcpgu_of_table);
static struct platform_driver arcpgu_platform_driver = {
.probe = arcpgu_probe,
- .remove = arcpgu_remove,
+ .remove_new = arcpgu_remove,
.driver = {
.name = "arcpgu",
.of_match_table = arcpgu_of_table,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 48/53] drm/tiny: Convert to platform remove callback returning void
2023-05-07 16:26 ` [PATCH 48/53] drm/tiny: " Uwe Kleine-König
@ 2023-05-08 7:03 ` Thomas Zimmermann
2023-05-08 7:28 ` Uwe Kleine-König
0 siblings, 1 reply; 261+ messages in thread
From: Thomas Zimmermann @ 2023-05-08 7:03 UTC (permalink / raw)
To: Uwe Kleine-König, Alexey Brodkin, David Airlie,
Daniel Vetter
Cc: dri-devel, kernel
[-- Attachment #1.1: Type: text/plain, Size: 2203 bytes --]
Hi,
the subject line is a bit ugly. You may want to change the it to say
either 'drm/tiny/arcgpu' or just 'drm/arcgpu'. Same for the other
tiny/-related patches.
Best regards
Thomas
Am 07.05.23 um 18:26 schrieb Uwe Kleine-König:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
> index 611bbee15071..a1f998a85ce8 100644
> --- a/drivers/gpu/drm/tiny/arcpgu.c
> +++ b/drivers/gpu/drm/tiny/arcpgu.c
> @@ -404,14 +404,12 @@ static int arcpgu_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int arcpgu_remove(struct platform_device *pdev)
> +static void arcpgu_remove(struct platform_device *pdev)
> {
> struct drm_device *drm = platform_get_drvdata(pdev);
>
> drm_dev_unregister(drm);
> arcpgu_unload(drm);
> -
> - return 0;
> }
>
> static const struct of_device_id arcpgu_of_table[] = {
> @@ -423,7 +421,7 @@ MODULE_DEVICE_TABLE(of, arcpgu_of_table);
>
> static struct platform_driver arcpgu_platform_driver = {
> .probe = arcpgu_probe,
> - .remove = arcpgu_remove,
> + .remove_new = arcpgu_remove,
> .driver = {
> .name = "arcpgu",
> .of_match_table = arcpgu_of_table,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 48/53] drm/tiny: Convert to platform remove callback returning void
2023-05-08 7:03 ` Thomas Zimmermann
@ 2023-05-08 7:28 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-08 7:28 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: kernel, Alexey Brodkin, dri-devel
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Mon, May 08, 2023 at 09:03:30AM +0200, Thomas Zimmermann wrote:
> Hi,
>
> the subject line is a bit ugly. You may want to change the it to say either
> 'drm/tiny/arcgpu' or just 'drm/arcgpu'. Same for the other tiny/-related
> patches.
Oh, indeed non-optimal. There is this patch touching arcpgu and the next
touching ofdrm + simpledrm; both have the same commit log.
The obvious possibilities are: Squash them together and keep "drm/tiny"
as prefix, or split in three and use "drm/arcpgu", "drm/ofdrm" and
"drm/simpledrm" as prefix respectively (with or without "tiny/"). If I
don't hear back about this, I'll go for splitting and no "tiny/" (which
seems to be the more common one in the past).
Best regards and thanks for your feedback,
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] 261+ messages in thread
* [PATCH 49/53] drm/tiny: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (51 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, David Airlie,
Daniel Vetter
Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the tiny drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 6e349ca42485..e110f2e2c2a5 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -1373,13 +1373,11 @@ static int ofdrm_probe(struct platform_device *pdev)
return 0;
}
-static int ofdrm_remove(struct platform_device *pdev)
+static void ofdrm_remove(struct platform_device *pdev)
{
struct drm_device *dev = platform_get_drvdata(pdev);
drm_dev_unplug(dev);
-
- return 0;
}
static const struct of_device_id ofdrm_of_match_display[] = {
@@ -1394,7 +1392,7 @@ static struct platform_driver ofdrm_platform_driver = {
.of_match_table = ofdrm_of_match_display,
},
.probe = ofdrm_probe,
- .remove = ofdrm_remove,
+ .remove_new = ofdrm_remove,
};
module_platform_driver(ofdrm_platform_driver);
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 63881a3754f8..369c236a2fad 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -875,14 +875,12 @@ static int simpledrm_probe(struct platform_device *pdev)
return 0;
}
-static int simpledrm_remove(struct platform_device *pdev)
+static void simpledrm_remove(struct platform_device *pdev)
{
struct simpledrm_device *sdev = platform_get_drvdata(pdev);
struct drm_device *dev = &sdev->dev;
drm_dev_unplug(dev);
-
- return 0;
}
static const struct of_device_id simpledrm_of_match_table[] = {
@@ -897,7 +895,7 @@ static struct platform_driver simpledrm_platform_driver = {
.of_match_table = simpledrm_of_match_table,
},
.probe = simpledrm_probe,
- .remove = simpledrm_remove,
+ .remove_new = simpledrm_remove,
};
module_platform_driver(simpledrm_platform_driver);
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 50/53] drm/tve200: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (52 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
2023-05-08 6:14 ` Linus Walleij
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Linus Walleij, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c b/drivers/gpu/drm/tve200/tve200_drv.c
index 0d05c386d303..0d98939d7aed 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -238,7 +238,7 @@ static int tve200_probe(struct platform_device *pdev)
return ret;
}
-static int tve200_remove(struct platform_device *pdev)
+static void tve200_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
struct tve200_drm_dev_private *priv = drm->dev_private;
@@ -249,8 +249,6 @@ static int tve200_remove(struct platform_device *pdev)
drm_mode_config_cleanup(drm);
clk_disable_unprepare(priv->pclk);
drm_dev_put(drm);
-
- return 0;
}
static const struct of_device_id tve200_of_match[] = {
@@ -266,7 +264,7 @@ static struct platform_driver tve200_driver = {
.of_match_table = of_match_ptr(tve200_of_match),
},
.probe = tve200_probe,
- .remove = tve200_remove,
+ .remove_new = tve200_remove,
};
drm_module_platform_driver(tve200_driver);
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 50/53] drm/tve200: Convert to platform remove callback returning void
2023-05-07 16:26 ` [PATCH 50/53] drm/tve200: " Uwe Kleine-König
@ 2023-05-08 6:14 ` Linus Walleij
0 siblings, 0 replies; 261+ messages in thread
From: Linus Walleij @ 2023-05-08 6:14 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: kernel, dri-devel
On Sun, May 7, 2023 at 6:26 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 51/53] drm/v3d: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (53 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Emma Anholt, Melissa Wen, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 478f1f0f60de..71f9fdde24b4 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -295,7 +295,7 @@ static int v3d_platform_drm_probe(struct platform_device *pdev)
return ret;
}
-static int v3d_platform_drm_remove(struct platform_device *pdev)
+static void v3d_platform_drm_remove(struct platform_device *pdev)
{
struct drm_device *drm = platform_get_drvdata(pdev);
struct v3d_dev *v3d = to_v3d_dev(drm);
@@ -306,13 +306,11 @@ static int v3d_platform_drm_remove(struct platform_device *pdev)
dma_free_wc(v3d->drm.dev, 4096, v3d->mmu_scratch,
v3d->mmu_scratch_paddr);
-
- return 0;
}
static struct platform_driver v3d_platform_driver = {
.probe = v3d_platform_drm_probe,
- .remove = v3d_platform_drm_remove,
+ .remove_new = v3d_platform_drm_remove,
.driver = {
.name = "v3d",
.of_match_table = v3d_of_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 52/53] drm/vc4: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (54 preceding siblings ...)
(?)
@ 2023-05-07 16:26 ` Uwe Kleine-König
2023-05-09 14:32 ` Dave Stevenson
-1 siblings, 1 reply; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Emma Anholt, Maxime Ripard, David Airlie, Daniel Vetter; +Cc: kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert the vc4 drm drivers from always returning zero in the
remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
9 files changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index bef9d45ef1df..7610e841ef3c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -1450,15 +1450,14 @@ static int vc4_crtc_dev_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_crtc_ops);
}
-static int vc4_crtc_dev_remove(struct platform_device *pdev)
+static void vc4_crtc_dev_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_crtc_ops);
- return 0;
}
struct platform_driver vc4_crtc_driver = {
.probe = vc4_crtc_dev_probe,
- .remove = vc4_crtc_dev_remove,
+ .remove_new = vc4_crtc_dev_remove,
.driver = {
.name = "vc4_crtc",
.of_match_table = vc4_crtc_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index f518d6e59ed6..e67856ae9d75 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -391,15 +391,14 @@ static int vc4_dpi_dev_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_dpi_ops);
}
-static int vc4_dpi_dev_remove(struct platform_device *pdev)
+static void vc4_dpi_dev_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_dpi_ops);
- return 0;
}
struct platform_driver vc4_dpi_driver = {
.probe = vc4_dpi_dev_probe,
- .remove = vc4_dpi_dev_remove,
+ .remove_new = vc4_dpi_dev_remove,
.driver = {
.name = "vc4_dpi",
.of_match_table = vc4_dpi_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 0ccaee57fe9a..cee41e318bf9 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -439,11 +439,9 @@ static int vc4_platform_drm_probe(struct platform_device *pdev)
return component_master_add_with_match(dev, &vc4_drm_ops, match);
}
-static int vc4_platform_drm_remove(struct platform_device *pdev)
+static void vc4_platform_drm_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &vc4_drm_ops);
-
- return 0;
}
static const struct of_device_id vc4_of_match[] = {
@@ -456,7 +454,7 @@ MODULE_DEVICE_TABLE(of, vc4_of_match);
static struct platform_driver vc4_platform_driver = {
.probe = vc4_platform_drm_probe,
- .remove = vc4_platform_drm_remove,
+ .remove_new = vc4_platform_drm_remove,
.driver = {
.name = "vc4-drm",
.of_match_table = vc4_of_match,
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a5c075f802e4..839d7d682842 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1830,20 +1830,18 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev)
return 0;
}
-static int vc4_dsi_dev_remove(struct platform_device *pdev)
+static void vc4_dsi_dev_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct vc4_dsi *dsi = dev_get_drvdata(dev);
mipi_dsi_host_unregister(&dsi->dsi_host);
vc4_dsi_put(dsi);
-
- return 0;
}
struct platform_driver vc4_dsi_driver = {
.probe = vc4_dsi_dev_probe,
- .remove = vc4_dsi_dev_remove,
+ .remove_new = vc4_dsi_dev_remove,
.driver = {
.name = "vc4_dsi",
.of_match_table = vc4_dsi_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ea22c9bf223a..0c4aef532521 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -3561,10 +3561,9 @@ static int vc4_hdmi_dev_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_hdmi_ops);
}
-static int vc4_hdmi_dev_remove(struct platform_device *pdev)
+static void vc4_hdmi_dev_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_hdmi_ops);
- return 0;
}
static const struct vc4_hdmi_variant bcm2835_variant = {
@@ -3660,7 +3659,7 @@ static const struct dev_pm_ops vc4_hdmi_pm_ops = {
struct platform_driver vc4_hdmi_driver = {
.probe = vc4_hdmi_dev_probe,
- .remove = vc4_hdmi_dev_remove,
+ .remove_new = vc4_hdmi_dev_remove,
.driver = {
.name = "vc4_hdmi",
.of_match_table = vc4_hdmi_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 4da66ef96783..04af672caacb 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -1061,10 +1061,9 @@ static int vc4_hvs_dev_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_hvs_ops);
}
-static int vc4_hvs_dev_remove(struct platform_device *pdev)
+static void vc4_hvs_dev_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_hvs_ops);
- return 0;
}
static const struct of_device_id vc4_hvs_dt_match[] = {
@@ -1075,7 +1074,7 @@ static const struct of_device_id vc4_hvs_dt_match[] = {
struct platform_driver vc4_hvs_driver = {
.probe = vc4_hvs_dev_probe,
- .remove = vc4_hvs_dev_remove,
+ .remove_new = vc4_hvs_dev_remove,
.driver = {
.name = "vc4_hvs",
.of_match_table = vc4_hvs_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index ef5cab2a3aa9..8152c8325c13 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -577,10 +577,9 @@ static int vc4_txp_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_txp_ops);
}
-static int vc4_txp_remove(struct platform_device *pdev)
+static void vc4_txp_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_txp_ops);
- return 0;
}
static const struct of_device_id vc4_txp_dt_match[] = {
@@ -590,7 +589,7 @@ static const struct of_device_id vc4_txp_dt_match[] = {
struct platform_driver vc4_txp_driver = {
.probe = vc4_txp_probe,
- .remove = vc4_txp_remove,
+ .remove_new = vc4_txp_remove,
.driver = {
.name = "vc4_txp",
.of_match_table = vc4_txp_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index 29a664c8bf44..04ac7805e6d5 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -532,10 +532,9 @@ static int vc4_v3d_dev_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_v3d_ops);
}
-static int vc4_v3d_dev_remove(struct platform_device *pdev)
+static void vc4_v3d_dev_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_v3d_ops);
- return 0;
}
const struct of_device_id vc4_v3d_dt_match[] = {
@@ -547,7 +546,7 @@ const struct of_device_id vc4_v3d_dt_match[] = {
struct platform_driver vc4_v3d_driver = {
.probe = vc4_v3d_dev_probe,
- .remove = vc4_v3d_dev_remove,
+ .remove_new = vc4_v3d_dev_remove,
.driver = {
.name = "vc4_v3d",
.of_match_table = vc4_v3d_dt_match,
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index a3782d05cd66..0bbda1872881 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -818,15 +818,14 @@ static int vc4_vec_dev_probe(struct platform_device *pdev)
return component_add(&pdev->dev, &vc4_vec_ops);
}
-static int vc4_vec_dev_remove(struct platform_device *pdev)
+static void vc4_vec_dev_remove(struct platform_device *pdev)
{
component_del(&pdev->dev, &vc4_vec_ops);
- return 0;
}
struct platform_driver vc4_vec_driver = {
.probe = vc4_vec_dev_probe,
- .remove = vc4_vec_dev_remove,
+ .remove_new = vc4_vec_dev_remove,
.driver = {
.name = "vc4_vec",
.of_match_table = vc4_vec_dt_match,
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 52/53] drm/vc4: Convert to platform remove callback returning void
2023-05-07 16:26 ` [PATCH 52/53] drm/vc4: " Uwe Kleine-König
@ 2023-05-09 14:32 ` Dave Stevenson
0 siblings, 0 replies; 261+ messages in thread
From: Dave Stevenson @ 2023-05-09 14:32 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Emma Anholt, dri-devel, kernel
On Sun, 7 May 2023 at 17:27, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert the vc4 drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks for the patch - looks good.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> 9 files changed, 18 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index bef9d45ef1df..7610e841ef3c 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -1450,15 +1450,14 @@ static int vc4_crtc_dev_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_crtc_ops);
> }
>
> -static int vc4_crtc_dev_remove(struct platform_device *pdev)
> +static void vc4_crtc_dev_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_crtc_ops);
> - return 0;
> }
>
> struct platform_driver vc4_crtc_driver = {
> .probe = vc4_crtc_dev_probe,
> - .remove = vc4_crtc_dev_remove,
> + .remove_new = vc4_crtc_dev_remove,
> .driver = {
> .name = "vc4_crtc",
> .of_match_table = vc4_crtc_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index f518d6e59ed6..e67856ae9d75 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -391,15 +391,14 @@ static int vc4_dpi_dev_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_dpi_ops);
> }
>
> -static int vc4_dpi_dev_remove(struct platform_device *pdev)
> +static void vc4_dpi_dev_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_dpi_ops);
> - return 0;
> }
>
> struct platform_driver vc4_dpi_driver = {
> .probe = vc4_dpi_dev_probe,
> - .remove = vc4_dpi_dev_remove,
> + .remove_new = vc4_dpi_dev_remove,
> .driver = {
> .name = "vc4_dpi",
> .of_match_table = vc4_dpi_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 0ccaee57fe9a..cee41e318bf9 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -439,11 +439,9 @@ static int vc4_platform_drm_probe(struct platform_device *pdev)
> return component_master_add_with_match(dev, &vc4_drm_ops, match);
> }
>
> -static int vc4_platform_drm_remove(struct platform_device *pdev)
> +static void vc4_platform_drm_remove(struct platform_device *pdev)
> {
> component_master_del(&pdev->dev, &vc4_drm_ops);
> -
> - return 0;
> }
>
> static const struct of_device_id vc4_of_match[] = {
> @@ -456,7 +454,7 @@ MODULE_DEVICE_TABLE(of, vc4_of_match);
>
> static struct platform_driver vc4_platform_driver = {
> .probe = vc4_platform_drm_probe,
> - .remove = vc4_platform_drm_remove,
> + .remove_new = vc4_platform_drm_remove,
> .driver = {
> .name = "vc4-drm",
> .of_match_table = vc4_of_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index a5c075f802e4..839d7d682842 100644
> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> @@ -1830,20 +1830,18 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static int vc4_dsi_dev_remove(struct platform_device *pdev)
> +static void vc4_dsi_dev_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct vc4_dsi *dsi = dev_get_drvdata(dev);
>
> mipi_dsi_host_unregister(&dsi->dsi_host);
> vc4_dsi_put(dsi);
> -
> - return 0;
> }
>
> struct platform_driver vc4_dsi_driver = {
> .probe = vc4_dsi_dev_probe,
> - .remove = vc4_dsi_dev_remove,
> + .remove_new = vc4_dsi_dev_remove,
> .driver = {
> .name = "vc4_dsi",
> .of_match_table = vc4_dsi_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ea22c9bf223a..0c4aef532521 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -3561,10 +3561,9 @@ static int vc4_hdmi_dev_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_hdmi_ops);
> }
>
> -static int vc4_hdmi_dev_remove(struct platform_device *pdev)
> +static void vc4_hdmi_dev_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_hdmi_ops);
> - return 0;
> }
>
> static const struct vc4_hdmi_variant bcm2835_variant = {
> @@ -3660,7 +3659,7 @@ static const struct dev_pm_ops vc4_hdmi_pm_ops = {
>
> struct platform_driver vc4_hdmi_driver = {
> .probe = vc4_hdmi_dev_probe,
> - .remove = vc4_hdmi_dev_remove,
> + .remove_new = vc4_hdmi_dev_remove,
> .driver = {
> .name = "vc4_hdmi",
> .of_match_table = vc4_hdmi_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 4da66ef96783..04af672caacb 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -1061,10 +1061,9 @@ static int vc4_hvs_dev_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_hvs_ops);
> }
>
> -static int vc4_hvs_dev_remove(struct platform_device *pdev)
> +static void vc4_hvs_dev_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_hvs_ops);
> - return 0;
> }
>
> static const struct of_device_id vc4_hvs_dt_match[] = {
> @@ -1075,7 +1074,7 @@ static const struct of_device_id vc4_hvs_dt_match[] = {
>
> struct platform_driver vc4_hvs_driver = {
> .probe = vc4_hvs_dev_probe,
> - .remove = vc4_hvs_dev_remove,
> + .remove_new = vc4_hvs_dev_remove,
> .driver = {
> .name = "vc4_hvs",
> .of_match_table = vc4_hvs_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index ef5cab2a3aa9..8152c8325c13 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -577,10 +577,9 @@ static int vc4_txp_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_txp_ops);
> }
>
> -static int vc4_txp_remove(struct platform_device *pdev)
> +static void vc4_txp_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_txp_ops);
> - return 0;
> }
>
> static const struct of_device_id vc4_txp_dt_match[] = {
> @@ -590,7 +589,7 @@ static const struct of_device_id vc4_txp_dt_match[] = {
>
> struct platform_driver vc4_txp_driver = {
> .probe = vc4_txp_probe,
> - .remove = vc4_txp_remove,
> + .remove_new = vc4_txp_remove,
> .driver = {
> .name = "vc4_txp",
> .of_match_table = vc4_txp_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
> index 29a664c8bf44..04ac7805e6d5 100644
> --- a/drivers/gpu/drm/vc4/vc4_v3d.c
> +++ b/drivers/gpu/drm/vc4/vc4_v3d.c
> @@ -532,10 +532,9 @@ static int vc4_v3d_dev_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_v3d_ops);
> }
>
> -static int vc4_v3d_dev_remove(struct platform_device *pdev)
> +static void vc4_v3d_dev_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_v3d_ops);
> - return 0;
> }
>
> const struct of_device_id vc4_v3d_dt_match[] = {
> @@ -547,7 +546,7 @@ const struct of_device_id vc4_v3d_dt_match[] = {
>
> struct platform_driver vc4_v3d_driver = {
> .probe = vc4_v3d_dev_probe,
> - .remove = vc4_v3d_dev_remove,
> + .remove_new = vc4_v3d_dev_remove,
> .driver = {
> .name = "vc4_v3d",
> .of_match_table = vc4_v3d_dt_match,
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index a3782d05cd66..0bbda1872881 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -818,15 +818,14 @@ static int vc4_vec_dev_probe(struct platform_device *pdev)
> return component_add(&pdev->dev, &vc4_vec_ops);
> }
>
> -static int vc4_vec_dev_remove(struct platform_device *pdev)
> +static void vc4_vec_dev_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &vc4_vec_ops);
> - return 0;
> }
>
> struct platform_driver vc4_vec_driver = {
> .probe = vc4_vec_dev_probe,
> - .remove = vc4_vec_dev_remove,
> + .remove_new = vc4_vec_dev_remove,
> .driver = {
> .name = "vc4_vec",
> .of_match_table = vc4_vec_dt_match,
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 53/53] drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
@ 2023-05-07 16:26 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Hyun Kwon, Laurent Pinchart, David Airlie, Daniel Vetter,
Michal Simek
Cc: dri-devel, linux-arm-kernel, kernel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index bab862484d42..9d64a8d98372 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -280,7 +280,7 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
return ret;
}
-static int zynqmp_dpsub_remove(struct platform_device *pdev)
+static void zynqmp_dpsub_remove(struct platform_device *pdev)
{
struct zynqmp_dpsub *dpsub = platform_get_drvdata(pdev);
@@ -298,8 +298,6 @@ static int zynqmp_dpsub_remove(struct platform_device *pdev)
if (!dpsub->drm)
zynqmp_dpsub_release(dpsub);
-
- return 0;
}
static void zynqmp_dpsub_shutdown(struct platform_device *pdev)
@@ -320,7 +318,7 @@ MODULE_DEVICE_TABLE(of, zynqmp_dpsub_of_match);
static struct platform_driver zynqmp_dpsub_driver = {
.probe = zynqmp_dpsub_probe,
- .remove = zynqmp_dpsub_remove,
+ .remove_new = zynqmp_dpsub_remove,
.shutdown = zynqmp_dpsub_shutdown,
.driver = {
.name = "zynqmp-dpsub",
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 261+ messages in thread* [PATCH 53/53] drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning void
@ 2023-05-07 16:26 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-07 16:26 UTC (permalink / raw)
To: Hyun Kwon, Laurent Pinchart, David Airlie, Daniel Vetter,
Michal Simek
Cc: kernel, linux-arm-kernel, dri-devel
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index bab862484d42..9d64a8d98372 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -280,7 +280,7 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
return ret;
}
-static int zynqmp_dpsub_remove(struct platform_device *pdev)
+static void zynqmp_dpsub_remove(struct platform_device *pdev)
{
struct zynqmp_dpsub *dpsub = platform_get_drvdata(pdev);
@@ -298,8 +298,6 @@ static int zynqmp_dpsub_remove(struct platform_device *pdev)
if (!dpsub->drm)
zynqmp_dpsub_release(dpsub);
-
- return 0;
}
static void zynqmp_dpsub_shutdown(struct platform_device *pdev)
@@ -320,7 +318,7 @@ MODULE_DEVICE_TABLE(of, zynqmp_dpsub_of_match);
static struct platform_driver zynqmp_dpsub_driver = {
.probe = zynqmp_dpsub_probe,
- .remove = zynqmp_dpsub_remove,
+ .remove_new = zynqmp_dpsub_remove,
.shutdown = zynqmp_dpsub_shutdown,
.driver = {
.name = "zynqmp-dpsub",
--
2.39.2
^ permalink raw reply related [flat|nested] 261+ messages in thread* Re: [PATCH 53/53] drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning void
2023-05-07 16:26 ` Uwe Kleine-König
@ 2023-05-08 2:35 ` Laurent Pinchart
-1 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:35 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Hyun Kwon, David Airlie, Daniel Vetter, Michal Simek, dri-devel,
linux-arm-kernel, kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:26:16PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index bab862484d42..9d64a8d98372 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -280,7 +280,7 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int zynqmp_dpsub_remove(struct platform_device *pdev)
> +static void zynqmp_dpsub_remove(struct platform_device *pdev)
> {
> struct zynqmp_dpsub *dpsub = platform_get_drvdata(pdev);
>
> @@ -298,8 +298,6 @@ static int zynqmp_dpsub_remove(struct platform_device *pdev)
>
> if (!dpsub->drm)
> zynqmp_dpsub_release(dpsub);
> -
> - return 0;
> }
>
> static void zynqmp_dpsub_shutdown(struct platform_device *pdev)
> @@ -320,7 +318,7 @@ MODULE_DEVICE_TABLE(of, zynqmp_dpsub_of_match);
>
> static struct platform_driver zynqmp_dpsub_driver = {
> .probe = zynqmp_dpsub_probe,
> - .remove = zynqmp_dpsub_remove,
> + .remove_new = zynqmp_dpsub_remove,
> .shutdown = zynqmp_dpsub_shutdown,
> .driver = {
> .name = "zynqmp-dpsub",
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 53/53] drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning void
@ 2023-05-08 2:35 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-05-08 2:35 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: kernel, Hyun Kwon, Michal Simek, dri-devel, linux-arm-kernel
Hi Uwe,
Thank you for the patch.
On Sun, May 07, 2023 at 06:26:16PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index bab862484d42..9d64a8d98372 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -280,7 +280,7 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int zynqmp_dpsub_remove(struct platform_device *pdev)
> +static void zynqmp_dpsub_remove(struct platform_device *pdev)
> {
> struct zynqmp_dpsub *dpsub = platform_get_drvdata(pdev);
>
> @@ -298,8 +298,6 @@ static int zynqmp_dpsub_remove(struct platform_device *pdev)
>
> if (!dpsub->drm)
> zynqmp_dpsub_release(dpsub);
> -
> - return 0;
> }
>
> static void zynqmp_dpsub_shutdown(struct platform_device *pdev)
> @@ -320,7 +318,7 @@ MODULE_DEVICE_TABLE(of, zynqmp_dpsub_of_match);
>
> static struct platform_driver zynqmp_dpsub_driver = {
> .probe = zynqmp_dpsub_probe,
> - .remove = zynqmp_dpsub_remove,
> + .remove_new = zynqmp_dpsub_remove,
> .shutdown = zynqmp_dpsub_shutdown,
> .driver = {
> .name = "zynqmp-dpsub",
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (2 preceding siblings ...)
(?)
@ 2023-05-08 7:06 ` Thomas Zimmermann
-1 siblings, 0 replies; 261+ messages in thread
From: Thomas Zimmermann @ 2023-05-08 7:06 UTC (permalink / raw)
To: Uwe Kleine-König, James, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Danilo Krummrich, Laurent Pinchart,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Edmund Dea, Qiang Yu,
Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu, Matthias Brugger,
Kevin Hilman, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio, Johan Hovold,
Joel, Stephen Boyd, Marijn Suijten, Liu Shixin, Douglas Anderson,
Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Tomeu Vizoso, Kieran Bingham, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Deepak R Varma, Alex Deucher, Alain Volmat, Yannick Fertre,
Raphael Gallais-Pou, Philippe Cornu, Maxime Coquelin,
Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Jonathan Hunter, Maxime Ripard, Maíra Canal,
Noralf Trønnes, Jyri Sarha, Alexey Brodkin, Emma Anholt,
Melissa Wen, Hyun Kwon, Michal Simek
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Jonas Karlman, Fabio Estevam,
NXP Linux Team, Russell King, Christian Gmeiner, etnaviv,
Alim Akhtar, linux-samsung-soc, Xinwei Kong, Sumit Semwal,
Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
[-- Attachment #1.1.1: Type: text/plain, Size: 16005 bytes --]
Hi,
for the whole series:
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Please see my comment on the patches to tiny/.
Let me know if you want me to merge this patchset into drm-misc-next.
Best regards
Thomas
Am 07.05.23 um 18:25 schrieb Uwe Kleine-König:
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:06 ` Thomas Zimmermann
0 siblings, 0 replies; 261+ messages in thread
From: Thomas Zimmermann @ 2023-05-08 7:06 UTC (permalink / raw)
To: Uwe Kleine-König, James, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Danilo Krummrich, Laurent Pinchart,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Edmund Dea, Qiang Yu,
Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu, Matthias Brugger,
Kevin Hilman, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio, Johan Hovold,
Joel, Stephen Boyd, Marijn Suijten, Liu Shixin, Douglas Anderson,
Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Tomeu Vizoso, Kieran Bingham, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Deepak R Varma, Alex Deucher, Alain Volmat, Yannick Fertre,
Raphael Gallais-Pou, Philippe Cornu, Maxime Coquelin,
Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Jonathan Hunter, Maxime Ripard, Maíra Canal,
Noralf Trønnes, Jyri Sarha, Alexey Brodkin, Emma Anholt,
Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Alyssa Rosenzweig,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
[-- Attachment #1.1: Type: text/plain, Size: 16005 bytes --]
Hi,
for the whole series:
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Please see my comment on the patches to tiny/.
Let me know if you want me to merge this patchset into drm-misc-next.
Best regards
Thomas
Am 07.05.23 um 18:25 schrieb Uwe Kleine-König:
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:06 ` Thomas Zimmermann
0 siblings, 0 replies; 261+ messages in thread
From: Thomas Zimmermann @ 2023-05-08 7:06 UTC (permalink / raw)
To: Uwe Kleine-König, James, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Danilo Krummrich, Laurent Pinchart,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Edmund Dea, Qiang Yu,
Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu, Matthias Brugger,
Kevin Hilman, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio, Johan Hovold,
Joel, Stephen Boyd, Marijn Suijten, Liu Shixin, Douglas Anderson,
Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Tomeu Vizoso, Kieran Bingham, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Deepak R Varma, Alex Deucher, Alain Volmat, Yannick Fertre,
Raphael Gallais-Pou, Philippe Cornu, Maxime Coquelin,
Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Jonathan Hunter, Maxime Ripard, Maíra Canal,
Noralf Trønnes, Jyri Sarha, Alexey Brodkin, Emma Anholt,
Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
lima, Steven Price, linux-rockchip, Xinwei Kong,
Mali DP Maintainers, NXP Linux Team, Russell King, linux-sunxi,
Alyssa Rosenzweig, Jonas Karlman, Martin Blumenstingl,
linux-arm-msm, etnaviv, Christian Gmeiner, linux-mediatek,
linux-tegra, linux-amlogic, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-stm32,
linux-mips, linux-renesas-soc, kernel, Yongqin Liu, freedreno
[-- Attachment #1.1: Type: text/plain, Size: 16005 bytes --]
Hi,
for the whole series:
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Please see my comment on the patches to tiny/.
Let me know if you want me to merge this patchset into drm-misc-next.
Best regards
Thomas
Am 07.05.23 um 18:25 schrieb Uwe Kleine-König:
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:06 ` Thomas Zimmermann
0 siblings, 0 replies; 261+ messages in thread
From: Thomas Zimmermann @ 2023-05-08 7:06 UTC (permalink / raw)
To: Uwe Kleine-König, James, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Danilo Krummrich, Laurent Pinchart,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Edmund Dea, Qiang Yu,
Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu, Matthias Brugger,
Kevin Hilman, Rob Clark, Abhinav Kumar, Dmitry Baryshkov,
Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio, Johan Hovold,
Joel, Stephen Boyd, Marijn Suijten, Liu Shixin, Douglas Anderson,
Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Tomeu Vizoso, Kieran Bingham, Sandy Huang,
Heiko Stübner, Orson Zhai, Baolin Wang, Chunyan Zhang,
Deepak R Varma, Alex Deucher, Alain Volmat, Yannick Fertre,
Raphael Gallais-Pou, Philippe Cornu, Maxime Coquelin,
Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Jonathan Hunter, Maxime Ripard, Maíra Canal,
Noralf Trønnes, Jyri Sarha, Alexey Brodkin, Emma Anholt,
Melissa Wen, Hyun Kwon, Michal Simek
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Jonas Karlman, Fabio Estevam,
NXP Linux Team, Russell King, Christian Gmeiner, etnaviv,
Alim Akhtar, linux-samsung-soc, Xinwei Kong, Sumit Semwal,
Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
[-- Attachment #1.1: Type: text/plain, Size: 16005 bytes --]
Hi,
for the whole series:
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Please see my comment on the patches to tiny/.
Let me know if you want me to merge this patchset into drm-misc-next.
Best regards
Thomas
Am 07.05.23 um 18:25 schrieb Uwe Kleine-König:
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:06 ` Thomas Zimmermann
0 siblings, 0 replies; 261+ messages in thread
From: Thomas Zimmermann @ 2023-05-08 7:06 UTC (permalink / raw)
To: linux-aspeed
Hi,
for the whole series:
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Please see my comment on the patches to tiny/.
Let me know if you want me to merge this patchset into drm-misc-next.
Best regards
Thomas
Am 07.05.23 um 18:25 schrieb Uwe Kleine-K?nig:
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-K?nig (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230508/83f8e808/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-05-08 7:06 ` Thomas Zimmermann
` (2 preceding siblings ...)
(?)
@ 2023-05-08 7:50 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-08 7:50 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: James (Qian) Wang, Liviu Dudau, Mihail Atanassov, Brian Starkey,
David Airlie, Daniel Vetter, Russell King, Joel Stanley,
Sam Ravnborg, Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Andrzej Hajda, Neil Armstrong, Robert Foss,
Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo,
Sascha Hauer, Minghao Chi, Mark Brown, Kuninori Morimoto,
Lucas Stach, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Jingoo Han, Stefan Agner, Alison Wang,
Xinliang Liu, Tian Tao, Ville Syrjälä, Jani Nikula,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Joel Fernandes, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Kieran Bingham,
Sandy Huang, Heiko Stübner, Orson Zhai, Baolin Wang,
Chunyan Zhang, Deepak R Varma, Alex Deucher, Alain Volmat,
Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek, linux-aspeed,
nouveau, dri-devel, John Stultz, Alim Akhtar, Fabio Estevam,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
[-- Attachment #1.1: Type: text/plain, Size: 766 bytes --]
[A few addressed bounced and my script to find the recipents for a patch
series broke and invented some addresses. I fixed all the problem I'm
aware of in this mail.]
On Mon, May 08, 2023 at 09:06:27AM +0200, Thomas Zimmermann wrote:
> for the whole series:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Please see my comment on the patches to tiny/.
>
> Let me know if you want me to merge this patchset into drm-misc-next.
Thanks, I'd wait a bit for more acks/reviews to come in and then plan to
resend later, also addressing the feedback you sent.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:50 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-08 7:50 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Karol Herbst,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
James (Qian) Wang, Ben Skeggs, Russell King, Alain Volmat,
linux-mips, Liu Ying, linux-arm-msm, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Douglas Anderson, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Joel Fernandes,
Sam Ravnborg, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui, Konrad Dybcio,
Alison Wang, Abhinav Kumar, Mark Brown, Maxime Ripard,
Baolin Wang, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Sandy Huang, Paul Cercueil, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Martin Blumenstingl, Philippe Cornu, Melissa Wen, linux-mediatek,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
[A few addressed bounced and my script to find the recipents for a patch
series broke and invented some addresses. I fixed all the problem I'm
aware of in this mail.]
On Mon, May 08, 2023 at 09:06:27AM +0200, Thomas Zimmermann wrote:
> for the whole series:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Please see my comment on the patches to tiny/.
>
> Let me know if you want me to merge this patchset into drm-misc-next.
Thanks, I'd wait a bit for more acks/reviews to come in and then plan to
resend later, also addressing the feedback you sent.
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] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:50 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-08 7:50 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Inki Dae, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, linux-rockchip,
James (Qian) Wang, Ben Skeggs, Russell King, Alain Volmat,
linux-mips, Liu Ying, linux-arm-msm, Maxime Ripard, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Douglas Anderson, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Brian Starkey, Kuninori Morimoto, Yuan Can,
Stefan Agner, Michal Simek, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Joel Fernandes, Sam Ravnborg, Rob Herring,
Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32,
Emma Anholt, Liviu Dudau, Alexandre Torgue, Sandy Huang,
Paul Cercueil, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Rob Clark, Martin Blumenstingl,
Philippe Cornu, Daniel Vetter, Melissa Wen, linux-mediatek,
Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Philipp Zabel, Dmitry Baryshkov,
Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
[A few addressed bounced and my script to find the recipents for a patch
series broke and invented some addresses. I fixed all the problem I'm
aware of in this mail.]
On Mon, May 08, 2023 at 09:06:27AM +0200, Thomas Zimmermann wrote:
> for the whole series:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Please see my comment on the patches to tiny/.
>
> Let me know if you want me to merge this patchset into drm-misc-next.
Thanks, I'd wait a bit for more acks/reviews to come in and then plan to
resend later, also addressing the feedback you sent.
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] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:50 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-08 7:50 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: James (Qian) Wang, Liviu Dudau, Mihail Atanassov, Brian Starkey,
David Airlie, Daniel Vetter, Russell King, Joel Stanley,
Sam Ravnborg, Boris Brezillon, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Andrzej Hajda, Neil Armstrong, Robert Foss,
Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo,
Sascha Hauer, Minghao Chi, Mark Brown, Kuninori Morimoto,
Lucas Stach, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Jingoo Han, Stefan Agner, Alison Wang,
Xinliang Liu, Tian Tao, Ville Syrjälä, Jani Nikula,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Joel Fernandes, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Kieran Bingham,
Sandy Huang, Heiko Stübner, Orson Zhai, Baolin Wang,
Chunyan Zhang, Deepak R Varma, Alex Deucher, Alain Volmat,
Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek, linux-aspeed,
nouveau, dri-devel, John Stultz, Alim Akhtar, Fabio Estevam,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
[A few addressed bounced and my script to find the recipents for a patch
series broke and invented some addresses. I fixed all the problem I'm
aware of in this mail.]
On Mon, May 08, 2023 at 09:06:27AM +0200, Thomas Zimmermann wrote:
> for the whole series:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Please see my comment on the patches to tiny/.
>
> Let me know if you want me to merge this patchset into drm-misc-next.
Thanks, I'd wait a bit for more acks/reviews to come in and then plan to
resend later, also addressing the feedback you sent.
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] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-08 7:50 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-08 7:50 UTC (permalink / raw)
To: linux-aspeed
[A few addressed bounced and my script to find the recipents for a patch
series broke and invented some addresses. I fixed all the problem I'm
aware of in this mail.]
On Mon, May 08, 2023 at 09:06:27AM +0200, Thomas Zimmermann wrote:
> for the whole series:
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Please see my comment on the patches to tiny/.
>
> Let me know if you want me to merge this patchset into drm-misc-next.
Thanks, I'd wait a bit for more acks/reviews to come in and then plan to
resend later, also addressing the feedback you sent.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230508/2f4e2ea0/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 47/53] drm/tilcdc: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (57 preceding siblings ...)
(?)
@ 2023-05-08 14:16 ` jyri.sarha
-1 siblings, 0 replies; 261+ messages in thread
From: jyri.sarha @ 2023-05-08 14:16 UTC (permalink / raw)
To: Uwe Kleine-König, Jyri Sarha, David Airlie, Daniel Vetter
Cc: kernel, dri-devel, Tomi Valkeinen
May 7, 2023 at 7:26 PM, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de mailto:u.kleine-koenig@pengutronix.de?to=%22Uwe%20Kleine-K%C3%B6nig%22%20%3Cu.kleine-koenig%40pengutronix.de%3E > wrote:
>
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Jyri Sarha <jyri.sarha@iki.fi>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 2729e16bc053..9aefd010acde 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -374,7 +374,7 @@ static int panel_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int panel_remove(struct platform_device *pdev)
> +static void panel_remove(struct platform_device *pdev)
> {
> struct tilcdc_module *mod = dev_get_platdata(&pdev->dev);
> struct panel_module *panel_mod = to_panel_module(mod);
> @@ -387,8 +387,6 @@ static int panel_remove(struct platform_device *pdev)
>
> tilcdc_module_cleanup(mod);
> kfree(panel_mod->info);
> -
> - return 0;
> }
>
> static const struct of_device_id panel_of_match[] = {
> @@ -398,7 +396,7 @@ static const struct of_device_id panel_of_match[] = {
>
> static struct platform_driver panel_driver = {
> .probe = panel_probe,
> - .remove = panel_remove,
> + .remove_new = panel_remove,
> .driver = {
> .name = "tilcdc-panel",
> .of_match_table = panel_of_match,
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (2 preceding siblings ...)
(?)
@ 2023-05-15 7:50 ` Inki Dae
-1 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:50 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: James, Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Edmund Dea, Qiang Yu, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Kevin Hilman, Rob Clark,
Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda,
Konrad Dybcio, Johan Hovold, Joel, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Tomeu Vizoso,
Kieran Bingham, Sandy Huang, Heiko Stübner, Orson Zhai,
Baolin Wang, Chunyan Zhang, Deepak R Varma, Alex Deucher,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek,
Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Jonas Karlman, Fabio Estevam,
NXP Linux Team, Russell King, Christian Gmeiner, etnaviv,
Alim Akhtar, linux-samsung-soc, Xinwei Kong, Sumit Semwal,
Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Hi,
2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
>
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
First of all, I apologize for the delay in providing my review comments.
Not related to this patch but seems that the "remove_new" callback
naming implicitly implies that there is no need to return anything
since its return type is void. To help users understand the intended
behavior based on the callback name, how about considering a modified
naming convention like "remove_no_return" or something similar?
The relevant patch has already been merged as outlined below,
author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
16:09:14 +0100
committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
19:04:17 +0100
commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
platform: Provide a remove callback that returns no value
Maybe a trivial thing but how about renaming it? I think the postfix,
'new', is a very generic word. I think you could introduce another
patch for it if you think it's reasonable.
Thanks,
Inki Dae
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
> --
> 2.39.2
>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 7:50 ` Inki Dae
0 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:50 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, Joel, Robert Foss, Karol Herbst, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Akhil P Oommen, Danilo Krummrich, NXP Linux Team,
Miaoqian Lin, linux-rockchip, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Edmund Dea, Thierry Reding,
Yongqin Liu, Mihail Atanassov, Liang He, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, Martin Blumenstingl,
Ben Skeggs, Russell King, Alain Volmat, linux-mips, Liu Ying,
linux-arm-msm, linux-samsung-soc, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Tomeu Vizoso, Boris Brezillon, Douglas Anderson,
John Stultz, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Kuninori Morimoto, Yuan Can, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Alyssa Rosenzweig, Chun-Kuang Hu,
Arnd Bergmann, Guo Zhengkui, Konrad Dybcio, Alison Wang,
Abhinav Kumar, Mark Brown, Maxime Ripard, Baolin Wang, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Sandy Huang, Paul Cercueil, James,
Marek Vasut, linux-renesas-soc, Jayshri Pawar, Jonas Karlman,
Philippe Cornu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Dmitry Baryshkov, Jyri Sarha
Hi,
2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
>
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
First of all, I apologize for the delay in providing my review comments.
Not related to this patch but seems that the "remove_new" callback
naming implicitly implies that there is no need to return anything
since its return type is void. To help users understand the intended
behavior based on the callback name, how about considering a modified
naming convention like "remove_no_return" or something similar?
The relevant patch has already been merged as outlined below,
author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
16:09:14 +0100
committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
19:04:17 +0100
commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
platform: Provide a remove callback that returns no value
Maybe a trivial thing but how about renaming it? I think the postfix,
'new', is a very generic word. I think you could introduce another
patch for it if you think it's reasonable.
Thanks,
Inki Dae
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 7:50 ` Inki Dae
0 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:50 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, Joel, Robert Foss,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, linux-rockchip, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Edmund Dea,
Thierry Reding, Yongqin Liu, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Martin Blumenstingl, Ben Skeggs, Russell King,
Alain Volmat, linux-mips, Liu Ying, linux-arm-msm, Maxime Ripard,
linux-samsung-soc, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Tomeu Vizoso, Boris Brezillon, Douglas Anderson,
John Stultz, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Brian Starkey, Kuninori Morimoto, Yuan Can, Stefan Agner,
Michal Simek, linux-tegra, Laurent Pinchart, Andrzej Hajda,
Sam Ravnborg, Rob Herring, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Alyssa Rosenzweig, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Daniel Vetter, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Sandy Huang, Paul Cercueil, James, Marek Vasut,
linux-renesas-soc, Jayshri Pawar, Jonas Karlman, Rob Clark,
Philippe Cornu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Philipp Zabel, Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi,
2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
>
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
First of all, I apologize for the delay in providing my review comments.
Not related to this patch but seems that the "remove_new" callback
naming implicitly implies that there is no need to return anything
since its return type is void. To help users understand the intended
behavior based on the callback name, how about considering a modified
naming convention like "remove_no_return" or something similar?
The relevant patch has already been merged as outlined below,
author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
16:09:14 +0100
committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
19:04:17 +0100
commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
platform: Provide a remove callback that returns no value
Maybe a trivial thing but how about renaming it? I think the postfix,
'new', is a very generic word. I think you could introduce another
patch for it if you think it's reasonable.
Thanks,
Inki Dae
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 7:50 ` Inki Dae
0 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:50 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: James, Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Edmund Dea, Qiang Yu, Paul Kocialkowski, Linus Walleij,
Chun-Kuang Hu, Matthias Brugger, Kevin Hilman, Rob Clark,
Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda,
Konrad Dybcio, Johan Hovold, Joel, Stephen Boyd, Marijn Suijten,
Liu Shixin, Douglas Anderson, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Tomeu Vizoso,
Kieran Bingham, Sandy Huang, Heiko Stübner, Orson Zhai,
Baolin Wang, Chunyan Zhang, Deepak R Varma, Alex Deucher,
Alain Volmat, Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek,
Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Jonas Karlman, Fabio Estevam,
NXP Linux Team, Russell King, Christian Gmeiner, etnaviv,
Alim Akhtar, linux-samsung-soc, Xinwei Kong, Sumit Semwal,
Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Hi,
2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
>
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
First of all, I apologize for the delay in providing my review comments.
Not related to this patch but seems that the "remove_new" callback
naming implicitly implies that there is no need to return anything
since its return type is void. To help users understand the intended
behavior based on the callback name, how about considering a modified
naming convention like "remove_no_return" or something similar?
The relevant patch has already been merged as outlined below,
author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
16:09:14 +0100
committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
19:04:17 +0100
commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
platform: Provide a remove callback that returns no value
Maybe a trivial thing but how about renaming it? I think the postfix,
'new', is a very generic word. I think you could introduce another
patch for it if you think it's reasonable.
Thanks,
Inki Dae
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 7:50 ` Inki Dae
0 siblings, 0 replies; 261+ messages in thread
From: Inki Dae @ 2023-05-15 7:50 UTC (permalink / raw)
To: linux-aspeed
Hi,
2023? 5? 8? (?) ?? 1:32, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>?? ??:
>
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
First of all, I apologize for the delay in providing my review comments.
Not related to this patch but seems that the "remove_new" callback
naming implicitly implies that there is no need to return anything
since its return type is void. To help users understand the intended
behavior based on the callback name, how about considering a modified
naming convention like "remove_no_return" or something similar?
The relevant patch has already been merged as outlined below,
author Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> 2022-12-09
16:09:14 +0100
committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
19:04:17 +0100
commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
platform: Provide a remove callback that returns no value
Maybe a trivial thing but how about renaming it? I think the postfix,
'new', is a very generic word. I think you could introduce another
patch for it if you think it's reasonable.
Thanks,
Inki Dae
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-K?nig (53):
> drm/komeda: Convert to platform remove callback returning void
> drm/arm/hdlcd: Convert to platform remove callback returning void
> drm/arm/malidp: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
> drm/aspeed: Convert to platform remove callback returning void
> drm/atmel-hlcdc: Convert to platform remove callback returning void
> drm/bridge: cdns-dsi: Convert to platform remove callback returning
> void
> drm/bridge: display-connector: Convert to platform remove callback
> returning void
> drm/bridge: fsl-ldb: Convert to platform remove callback returning
> void
> drm/imx/imx8*: Convert to platform remove callback returning void
> drm/bridge: lvds-codec: Convert to platform remove callback returning
> void
> drm/bridge: nwl-dsi: Convert to platform remove callback returning
> void
> drm/bridge: simple-bridge: Convert to platform remove callback
> returning void
> drm/bridge: synopsys: Convert to platform remove callback returning
> void
> drm/bridge: thc63lvd1024: Convert to platform remove callback
> returning void
> drm/bridge: tfp410: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/exynos: Convert to platform remove callback returning void
> drm/fsl-dcu: Convert to platform remove callback returning void
> drm/hisilicon: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/lima: Convert to platform remove callback returning void
> drm/logicvc: Convert to platform remove callback returning void
> drm/mcde: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/meson: Convert to platform remove callback returning void
> drm/msm: Convert to platform remove callback returning void
> drm/mxsfb: Convert to platform remove callback returning void
> drm/nouveau: Convert to platform remove callback returning void
> drm/omap: Convert to platform remove callback returning void
> drm/panel: Convert to platform remove callback returning void
> drm/panfrost: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
> drm/rockchip: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/sti: Convert to platform remove callback returning void
> drm/stm: Convert to platform remove callback returning void
> drm/sun4i: Convert to platform remove callback returning void
> drm/tegra: Convert to platform remove callback returning void
> drm/tests: helpers: Convert to platform remove callback returning void
> drm/tidss: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tiny: Convert to platform remove callback returning void
> drm/tve200: Convert to platform remove callback returning void
> drm/v3d: Convert to platform remove callback returning void
> drm/vc4: Convert to platform remove callback returning void
> drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
> void
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> drivers/gpu/drm/armada/armada_crtc.c | 5 ++---
> drivers/gpu/drm/armada/armada_drv.c | 5 ++---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 6 ++----
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++----
> drivers/gpu/drm/bridge/display-connector.c | 6 ++----
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 6 ++----
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 6 ++----
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++----
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c | 6 ++----
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++----
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++----
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 ++---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_dp.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_drm_scaler.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++----
> drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++----
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 6 ++----
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 5 ++---
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c | 6 ++----
> drivers/gpu/drm/imx/ipuv3/imx-drm-core.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/imx-tve.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c | 5 ++---
> drivers/gpu/drm/imx/ipuv3/parallel-display.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++----
> drivers/gpu/drm/ingenic/ingenic-ipu.c | 5 ++---
> drivers/gpu/drm/kmb/kmb_drv.c | 5 ++---
> drivers/gpu/drm/lima/lima_drv.c | 5 ++---
> drivers/gpu/drm/logicvc/logicvc_drm.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_drv.c | 6 ++----
> drivers/gpu/drm/mcde/mcde_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_cec.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dp.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 ++---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 6 ++----
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 5 ++---
> drivers/gpu/drm/meson/meson_drv.c | 6 ++----
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/msm/adreno/adreno_device.c | 5 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 6 ++----
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 5 ++---
> drivers/gpu/drm/msm/dp/dp_display.c | 6 ++----
> drivers/gpu/drm/msm/dsi/dsi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi.c | 6 ++----
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 6 ++----
> drivers/gpu/drm/msm/msm_drv.c | 6 ++----
> drivers/gpu/drm/msm/msm_mdss.c | 6 ++----
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 6 ++----
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 ++----
> drivers/gpu/drm/nouveau/nouveau_platform.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/dss.c | 6 ++----
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/hdmi5.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/venc.c | 5 ++---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 +++------
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++----
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++----
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 6 ++----
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 6 ++----
> drivers/gpu/drm/panel/panel-simple.c | 6 ++----
> drivers/gpu/drm/panfrost/panfrost_drv.c | 5 ++---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++----
> drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 ++----
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 ++----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 6 ++----
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 ++----
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_dpu.c | 6 ++----
> drivers/gpu/drm/sprd/sprd_drm.c | 5 ++---
> drivers/gpu/drm/sprd/sprd_dsi.c | 6 ++----
> drivers/gpu/drm/sti/sti_compositor.c | 5 ++---
> drivers/gpu/drm/sti/sti_drv.c | 6 ++----
> drivers/gpu/drm/sti/sti_dvo.c | 5 ++---
> drivers/gpu/drm/sti/sti_hda.c | 5 ++---
> drivers/gpu/drm/sti/sti_hdmi.c | 6 ++----
> drivers/gpu/drm/sti/sti_hqvdp.c | 5 ++---
> drivers/gpu/drm/sti/sti_tvout.c | 5 ++---
> drivers/gpu/drm/stm/drv.c | 6 ++----
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_backend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_drv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++----
> drivers/gpu/drm/sun4i/sun4i_tv.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_drc.c | 6 ++----
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 6 ++----
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 ++----
> drivers/gpu/drm/tegra/dpaux.c | 6 ++----
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 5 ++---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 ++----
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 ++----
> drivers/gpu/drm/tiny/arcpgu.c | 6 ++----
> drivers/gpu/drm/tiny/ofdrm.c | 6 ++----
> drivers/gpu/drm/tiny/simpledrm.c | 6 ++----
> drivers/gpu/drm/tve200/tve200_drv.c | 6 ++----
> drivers/gpu/drm/v3d/v3d_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_crtc.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_dpi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_dsi.c | 6 ++----
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_hvs.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_txp.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_v3d.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_vec.c | 5 ++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++----
> 159 files changed, 319 insertions(+), 597 deletions(-)
>
>
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
> --
> 2.39.2
>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-05-15 7:50 ` Inki Dae
` (2 preceding siblings ...)
(?)
@ 2023-05-15 9:20 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:20 UTC (permalink / raw)
To: Inki Dae
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin, linux-rockchip,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, Yongqin Liu, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, Martin Blumenstingl, Ben Skeggs,
Russell King, Alain Volmat, linux-mips, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-samsung-soc, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Douglas Anderson, John Stultz,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin, Brian Starkey,
Kuninori Morimoto, Yuan Can, Stefan Agner, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Lyude Paul, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Christian Gmeiner,
Mark Brown, Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Sandy Huang, Paul Cercueil,
David Airlie, Marek Vasut, linux-renesas-soc, Jayshri Pawar,
Jonas Karlman, Rob Clark, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1.1: Type: text/plain, Size: 2089 bytes --]
On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
>
> First of all, I apologize for the delay in providing my review comments.
>
> Not related to this patch but seems that the "remove_new" callback
> naming implicitly implies that there is no need to return anything
> since its return type is void. To help users understand the intended
> behavior based on the callback name, how about considering a modified
> naming convention like "remove_no_return" or something similar?
>
> The relevant patch has already been merged as outlined below,
> author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
> 16:09:14 +0100
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
> 19:04:17 +0100
> commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
> tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
> parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
> download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
> platform: Provide a remove callback that returns no value
>
> Maybe a trivial thing but how about renaming it? I think the postfix,
> 'new', is a very generic word. I think you could introduce another
> patch for it if you think it's reasonable.
.remove_new is only a temporary name. Once all drivers are converted,
.remove is changed to return void and then all drivers are converted
back. While "remove_new" might not be a brilliant name choice, touching
all already converted drivers again just to improve the temporary
measures doesn't sound right.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 9:20 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:20 UTC (permalink / raw)
To: Inki Dae
Cc: Alexandre Belloni, Xinliang Liu, dri-devel, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Kuninori Morimoto,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, Yongqin Liu,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Martin Blumenstingl, linux-arm-msm,
Nicolas Ferre, Tian Tao, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Douglas Anderson,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin, Karol Herbst,
Yuan Can, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Chen-Yu Tsai, Jernej Skrabec,
Xinwei Kong, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Paul Cercueil, Tomi Valkeinen,
Deepak R Varma, Kieran Bingham, Ricardo Ribalda, John Stultz,
Shawn Guo, Bjorn Andersson, linux-stm32, Emma Anholt,
Konrad Dybcio, Alexandre Torgue, Sandy Huang, Liu Shixin,
Krzysztof Kozlowski, Marek Vasut, linux-renesas-soc,
Jayshri Pawar, Jonas Karlman, Russell King, Qiang Yu,
Thomas Zimmermann, Melissa Wen, linux-mediatek, Laurentiu Palcu,
linux-tegra, AngeloGioacchino Del Regno, Yannick Fertre,
linux-mips, Philippe Cornu, Dmitry Baryshkov, Liu Ying,
Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
>
> First of all, I apologize for the delay in providing my review comments.
>
> Not related to this patch but seems that the "remove_new" callback
> naming implicitly implies that there is no need to return anything
> since its return type is void. To help users understand the intended
> behavior based on the callback name, how about considering a modified
> naming convention like "remove_no_return" or something similar?
>
> The relevant patch has already been merged as outlined below,
> author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
> 16:09:14 +0100
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
> 19:04:17 +0100
> commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
> tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
> parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
> download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
> platform: Provide a remove callback that returns no value
>
> Maybe a trivial thing but how about renaming it? I think the postfix,
> 'new', is a very generic word. I think you could introduce another
> patch for it if you think it's reasonable.
.remove_new is only a temporary name. Once all drivers are converted,
.remove is changed to return void and then all drivers are converted
back. While "remove_new" might not be a brilliant name choice, touching
all already converted drivers again just to improve the temporary
measures doesn't sound right.
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] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 9:20 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:20 UTC (permalink / raw)
To: Inki Dae
Cc: Heiko Stübner, Alexandre Belloni, Xinliang Liu,
Linus Walleij, dri-devel, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Akhil P Oommen, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, Yongqin Liu,
Mihail Atanassov, Liang He, Ville Syrjälä, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat,
Martin Blumenstingl, linux-arm-msm, Nicolas Ferre, Maxime Ripard,
Tian Tao, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Douglas Anderson, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Brian Starkey, Yuan Can,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Kieran Bingham,
Ricardo Ribalda, John Stultz, Shawn Guo, Bjorn Andersson,
linux-stm32, Emma Anholt, Konrad Dybcio, Alexandre Torgue,
Sandy Huang, Liu Shixin, Krzysztof Kozlowski, Marek Vasut,
linux-renesas-soc, Jayshri Pawar, Jonas Karlman, Russell King,
Qiang Yu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, linux-tegra, AngeloGioacchino Del Regno,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Daniel Vetter, Dmitry Baryshkov, Liu Ying, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
>
> First of all, I apologize for the delay in providing my review comments.
>
> Not related to this patch but seems that the "remove_new" callback
> naming implicitly implies that there is no need to return anything
> since its return type is void. To help users understand the intended
> behavior based on the callback name, how about considering a modified
> naming convention like "remove_no_return" or something similar?
>
> The relevant patch has already been merged as outlined below,
> author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
> 16:09:14 +0100
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
> 19:04:17 +0100
> commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
> tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
> parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
> download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
> platform: Provide a remove callback that returns no value
>
> Maybe a trivial thing but how about renaming it? I think the postfix,
> 'new', is a very generic word. I think you could introduce another
> patch for it if you think it's reasonable.
.remove_new is only a temporary name. Once all drivers are converted,
.remove is changed to return void and then all drivers are converted
back. While "remove_new" might not be a brilliant name choice, touching
all already converted drivers again just to improve the temporary
measures doesn't sound right.
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] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 9:20 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:20 UTC (permalink / raw)
To: Inki Dae
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin, linux-rockchip,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, Yongqin Liu, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, Martin Blumenstingl, Ben Skeggs,
Russell King, Alain Volmat, linux-mips, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-samsung-soc, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Douglas Anderson, John Stultz,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin, Brian Starkey,
Kuninori Morimoto, Yuan Can, Stefan Agner, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Lyude Paul, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Christian Gmeiner,
Mark Brown, Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Sandy Huang, Paul Cercueil,
David Airlie, Marek Vasut, linux-renesas-soc, Jayshri Pawar,
Jonas Karlman, Rob Clark, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
>
> 2023년 5월 8일 (월) 오전 1:32, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>님이 작성:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
>
> First of all, I apologize for the delay in providing my review comments.
>
> Not related to this patch but seems that the "remove_new" callback
> naming implicitly implies that there is no need to return anything
> since its return type is void. To help users understand the intended
> behavior based on the callback name, how about considering a modified
> naming convention like "remove_no_return" or something similar?
>
> The relevant patch has already been merged as outlined below,
> author Uwe Kleine-König <u.kleine-koenig@pengutronix.de> 2022-12-09
> 16:09:14 +0100
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
> 19:04:17 +0100
> commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
> tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
> parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
> download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
> platform: Provide a remove callback that returns no value
>
> Maybe a trivial thing but how about renaming it? I think the postfix,
> 'new', is a very generic word. I think you could introduce another
> patch for it if you think it's reasonable.
.remove_new is only a temporary name. Once all drivers are converted,
.remove is changed to return void and then all drivers are converted
back. While "remove_new" might not be a brilliant name choice, touching
all already converted drivers again just to improve the temporary
measures doesn't sound right.
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] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-05-15 9:20 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-05-15 9:20 UTC (permalink / raw)
To: linux-aspeed
On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
>
> 2023? 5? 8? (?) ?? 1:32, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>?? ??:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
>
> First of all, I apologize for the delay in providing my review comments.
>
> Not related to this patch but seems that the "remove_new" callback
> naming implicitly implies that there is no need to return anything
> since its return type is void. To help users understand the intended
> behavior based on the callback name, how about considering a modified
> naming convention like "remove_no_return" or something similar?
>
> The relevant patch has already been merged as outlined below,
> author Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> 2022-12-09
> 16:09:14 +0100
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
> 19:04:17 +0100
> commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
> tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
> parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
> download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
> platform: Provide a remove callback that returns no value
>
> Maybe a trivial thing but how about renaming it? I think the postfix,
> 'new', is a very generic word. I think you could introduce another
> patch for it if you think it's reasonable.
.remove_new is only a temporary name. Once all drivers are converted,
.remove is changed to return void and then all drivers are converted
back. While "remove_new" might not be a brilliant name choice, touching
all already converted drivers again just to improve the temporary
measures doesn't sound right.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230515/37d41b2c/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-01 15:40 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-01 15:40 UTC (permalink / raw)
To: linux-aspeed
Hello,
On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
I wonder if someone would volunteer to add the whole series to
drm-misc-next?!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230601/da6cc783/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-01 15:40 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-01 15:40 UTC (permalink / raw)
To: Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Stephen Boyd, Marijn Suijten, Liu Shixin,
Douglas Anderson, Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson,
Marek Vasut, Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Kieran Bingham, Sandy Huang, Heiko Stübner,
Orson Zhai, Baolin Wang, Chunyan Zhang, Deepak R Varma,
Alex Deucher, Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Maxime Ripard,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Jonathan Hunter,
Maxime Ripard, Maíra Canal, Noralf Trønnes, Jyri Sarha,
Alexey Brodkin, Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, linux-mediatek,
linux-tegra, linux-amlogic, Sean Paul, linux-arm-kernel,
AngeloGioacchino Del Regno, Andrew Jeffery, linux-stm32,
linux-mips, linux-renesas-soc, kernel, Yongqin Liu, freedreno
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
Hello,
On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
I wonder if someone would volunteer to add the whole series to
drm-misc-next?!
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] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-01 15:40 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-01 15:40 UTC (permalink / raw)
To: Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Stephen Boyd, Marijn Suijten, Liu Shixin,
Douglas Anderson, Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson,
Marek Vasut, Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Kieran Bingham, Sandy Huang, Heiko Stübner,
Orson Zhai, Baolin Wang, Chunyan Zhang, Deepak R Varma,
Alex Deucher, Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Maxime Ripard,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Jonathan Hunter,
Maxime Ripard, Maíra Canal, Noralf Trønnes, Jyri Sarha,
Alexey Brodkin, Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
lima, Steven Price, linux-rockchip, Xinwei Kong,
Mali DP Maintainers, NXP Linux Team, Russell King, linux-sunxi,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
Christian Gmeiner, linux-mediatek, linux-tegra, linux-amlogic,
Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-stm32, linux-mips, linux-renesas-soc,
kernel, Yongqin Liu, freedreno
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
Hello,
On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
I wonder if someone would volunteer to add the whole series to
drm-misc-next?!
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] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-01 15:40 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-01 15:40 UTC (permalink / raw)
To: Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Stephen Boyd, Marijn Suijten, Liu Shixin,
Douglas Anderson, Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson,
Marek Vasut, Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Kieran Bingham, Sandy Huang, Heiko Stübner,
Orson Zhai, Baolin Wang, Chunyan Zhang, Deepak R Varma,
Alex Deucher, Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Maxime Ripard,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Jonathan Hunter,
Maxime Ripard, Maíra Canal, Noralf Trønnes, Jyri Sarha,
Alexey Brodkin, Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
lima, Steven Price, linux-rockchip, Xinwei Kong,
Mali DP Maintainers, NXP Linux Team, Russell King, linux-sunxi,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
Christian Gmeiner, linux-mediatek, linux-tegra, linux-amlogic,
Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-stm32, linux-mips, linux-renesas-soc,
kernel, Yongqin Liu, freedreno
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
Hello,
On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
I wonder if someone would volunteer to add the whole series to
drm-misc-next?!
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] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-06-01 15:40 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-08 16:08 ` Doug Anderson
-1 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:08 UTC (permalink / raw)
To: linux-aspeed
Hi,
On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
> > the driver core doesn't (and cannot) cope for errors during remove. The
> > only effect of a non-zero return value in .remove() is that the driver
> > core emits a warning. The device is removed anyhow and an early return
> > from .remove() usually yields a resource leak.
> >
> > By changing the remove callback to return void driver authors cannot
> > reasonably (but wrongly) assume any more that there happens some kind of
> > cleanup later.
>
> I wonder if someone would volunteer to add the whole series to
> drm-misc-next?!
It looks as if Neil applied quite a few of them already, so I looked
at what was left...
I'm a little hesitant to just apply the whole kit-and-caboodle to
drm-misc-next since there are specific DRM trees for a bunch of them
and it would be better if they landed there. ...so I went through all
the patches that still applied to drm-misc-next, then used
'scripts/get_maintainer.pl --scm' to check if they were maintained
through drm-misc. That still left quite a few patches. I've applied
those ones and pushed to drm-misc-next:
71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
callback returning void
1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
b957812839f8 drm/v3d: Convert to platform remove callback returning void
e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
0c259ab19146 drm/stm: Convert to platform remove callback returning void
9a865e45884a drm/sti: Convert to platform remove callback returning void
3c855610840e drm/rockchip: Convert to platform remove callback returning void
e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
cef3776d0b5a drm/panel: Convert to platform remove callback returning void
bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
38ca2d93d323 drm/meson: Convert to platform remove callback returning void
fd1457d84bae drm/mcde: Convert to platform remove callback returning void
41a56a18615c drm/logicvc: Convert to platform remove callback returning void
980ec6444372 drm/lima: Convert to platform remove callback returning void
82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
The following ones appeared to apply to the top of drm-misc-next, but
I didn't apply them since get_maintainer didn't say they were part of
drm-misc-next:
drm/tiny: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:08 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Karol Herbst,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Maxime Ripard, Baolin Wang, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, linux-mips, Paul Cercueil,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, linux-mediatek, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov,
Jyri Sarha
Hi,
On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
> > the driver core doesn't (and cannot) cope for errors during remove. The
> > only effect of a non-zero return value in .remove() is that the driver
> > core emits a warning. The device is removed anyhow and an early return
> > from .remove() usually yields a resource leak.
> >
> > By changing the remove callback to return void driver authors cannot
> > reasonably (but wrongly) assume any more that there happens some kind of
> > cleanup later.
>
> I wonder if someone would volunteer to add the whole series to
> drm-misc-next?!
It looks as if Neil applied quite a few of them already, so I looked
at what was left...
I'm a little hesitant to just apply the whole kit-and-caboodle to
drm-misc-next since there are specific DRM trees for a bunch of them
and it would be better if they landed there. ...so I went through all
the patches that still applied to drm-misc-next, then used
'scripts/get_maintainer.pl --scm' to check if they were maintained
through drm-misc. That still left quite a few patches. I've applied
those ones and pushed to drm-misc-next:
71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
callback returning void
1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
b957812839f8 drm/v3d: Convert to platform remove callback returning void
e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
0c259ab19146 drm/stm: Convert to platform remove callback returning void
9a865e45884a drm/sti: Convert to platform remove callback returning void
3c855610840e drm/rockchip: Convert to platform remove callback returning void
e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
cef3776d0b5a drm/panel: Convert to platform remove callback returning void
bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
38ca2d93d323 drm/meson: Convert to platform remove callback returning void
fd1457d84bae drm/mcde: Convert to platform remove callback returning void
41a56a18615c drm/logicvc: Convert to platform remove callback returning void
980ec6444372 drm/lima: Convert to platform remove callback returning void
82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
The following ones appeared to apply to the top of drm-misc-next, but
I didn't apply them since get_maintainer didn't say they were part of
drm-misc-next:
drm/tiny: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:08 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Inki Dae, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Brian Starkey, Kuninori Morimoto, Yuan Can,
Stefan Agner, Michal Simek, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Christian Gmeiner,
Mark Brown, Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, linux-mips, Paul Cercueil,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi,
On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
> > the driver core doesn't (and cannot) cope for errors during remove. The
> > only effect of a non-zero return value in .remove() is that the driver
> > core emits a warning. The device is removed anyhow and an early return
> > from .remove() usually yields a resource leak.
> >
> > By changing the remove callback to return void driver authors cannot
> > reasonably (but wrongly) assume any more that there happens some kind of
> > cleanup later.
>
> I wonder if someone would volunteer to add the whole series to
> drm-misc-next?!
It looks as if Neil applied quite a few of them already, so I looked
at what was left...
I'm a little hesitant to just apply the whole kit-and-caboodle to
drm-misc-next since there are specific DRM trees for a bunch of them
and it would be better if they landed there. ...so I went through all
the patches that still applied to drm-misc-next, then used
'scripts/get_maintainer.pl --scm' to check if they were maintained
through drm-misc. That still left quite a few patches. I've applied
those ones and pushed to drm-misc-next:
71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
callback returning void
1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
b957812839f8 drm/v3d: Convert to platform remove callback returning void
e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
0c259ab19146 drm/stm: Convert to platform remove callback returning void
9a865e45884a drm/sti: Convert to platform remove callback returning void
3c855610840e drm/rockchip: Convert to platform remove callback returning void
e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
cef3776d0b5a drm/panel: Convert to platform remove callback returning void
bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
38ca2d93d323 drm/meson: Convert to platform remove callback returning void
fd1457d84bae drm/mcde: Convert to platform remove callback returning void
41a56a18615c drm/logicvc: Convert to platform remove callback returning void
980ec6444372 drm/lima: Convert to platform remove callback returning void
82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
The following ones appeared to apply to the top of drm-misc-next, but
I didn't apply them since get_maintainer didn't say they were part of
drm-misc-next:
drm/tiny: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:08 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Liviu Dudau, Mihail Atanassov, Brian Starkey, David Airlie,
Daniel Vetter, Russell King, Joel Stanley, Sam Ravnborg,
Boris Brezillon, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Andrzej Hajda, Neil Armstrong, Robert Foss, Tomi Valkeinen,
Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo, Sascha Hauer,
Minghao Chi, Mark Brown, Kuninori Morimoto, Lucas Stach, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Jingoo Han,
Stefan Agner, Alison Wang, Xinliang Liu, Tian Tao,
Ville Syrjälä, Jani Nikula, Thomas Zimmermann,
Danilo Krummrich, Laurent Pinchart, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Stephen Boyd, Marijn Suijten, Liu Shixin,
Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Kieran Bingham, Sandy Huang, Heiko Stübner,
Orson Zhai, Baolin Wang, Chunyan Zhang, Deepak R Varma,
Alex Deucher, Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Maxime Ripard,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Jonathan Hunter,
Maxime Ripard, Maíra Canal, Noralf Trønnes, Jyri Sarha,
Alexey Brodkin, Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek,
linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
lima, Steven Price, linux-rockchip, Xinwei Kong,
Mali DP Maintainers, NXP Linux Team, Russell King, linux-sunxi,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
Christian Gmeiner, linux-mediatek, linux-tegra, linux-amlogic,
Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-stm32, linux-mips, linux-renesas-soc,
kernel, Yongqin Liu, freedreno
Hi,
On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
> > the driver core doesn't (and cannot) cope for errors during remove. The
> > only effect of a non-zero return value in .remove() is that the driver
> > core emits a warning. The device is removed anyhow and an early return
> > from .remove() usually yields a resource leak.
> >
> > By changing the remove callback to return void driver authors cannot
> > reasonably (but wrongly) assume any more that there happens some kind of
> > cleanup later.
>
> I wonder if someone would volunteer to add the whole series to
> drm-misc-next?!
It looks as if Neil applied quite a few of them already, so I looked
at what was left...
I'm a little hesitant to just apply the whole kit-and-caboodle to
drm-misc-next since there are specific DRM trees for a bunch of them
and it would be better if they landed there. ...so I went through all
the patches that still applied to drm-misc-next, then used
'scripts/get_maintainer.pl --scm' to check if they were maintained
through drm-misc. That still left quite a few patches. I've applied
those ones and pushed to drm-misc-next:
71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
callback returning void
1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
b957812839f8 drm/v3d: Convert to platform remove callback returning void
e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
0c259ab19146 drm/stm: Convert to platform remove callback returning void
9a865e45884a drm/sti: Convert to platform remove callback returning void
3c855610840e drm/rockchip: Convert to platform remove callback returning void
e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
cef3776d0b5a drm/panel: Convert to platform remove callback returning void
bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
38ca2d93d323 drm/meson: Convert to platform remove callback returning void
fd1457d84bae drm/mcde: Convert to platform remove callback returning void
41a56a18615c drm/logicvc: Convert to platform remove callback returning void
980ec6444372 drm/lima: Convert to platform remove callback returning void
82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
The following ones appeared to apply to the top of drm-misc-next, but
I didn't apply them since get_maintainer didn't say they were part of
drm-misc-next:
drm/tiny: Convert to platform remove callback returning void
drm/tilcdc: Convert to platform remove callback returning void
drm/sprd: Convert to platform remove callback returning void
drm/shmobile: Convert to platform remove callback returning void
drm/rcar-du: Convert to platform remove callback returning void
drm/omap: Convert to platform remove callback returning void
drm/nouveau: Convert to platform remove callback returning void
drm/mediatek: Convert to platform remove callback returning void
drm/kmb: Convert to platform remove callback returning void
drm/ingenic: Convert to platform remove callback returning void
drm/imx/ipuv3: Convert to platform remove callback returning void
drm/imx/dcss: Convert to platform remove callback returning void
drm/etnaviv: Convert to platform remove callback returning void
drm/armada: Convert to platform remove callback returning void
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-06-08 16:08 ` Doug Anderson
(?)
(?)
@ 2023-06-08 16:26 ` Laurent Pinchart
-1 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-06-08 16:26 UTC (permalink / raw)
To: linux-aspeed
Hi Doug,
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig wrote:
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> The following ones appeared to apply to the top of drm-misc-next, but
> I didn't apply them since get_maintainer didn't say they were part of
> drm-misc-next:
>
> drm/tiny: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
If you don't mind, could you take the rcar-du patch through drm-misc too
? I don't plan to send another pull request for v6.5.
> drm/omap: Convert to platform remove callback returning void
Tomi, should drm/omap moved to being maintained through drm-misc ?
> drm/nouveau: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:26 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-06-08 16:26 UTC (permalink / raw)
To: Doug Anderson
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Karol Herbst,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Andrzej Hajda, Sam Ravnborg, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Kieran Bingham, Ricardo Ribalda, Tian Tao,
Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Martin Blumenstingl, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, linux-mediatek, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
Hi Doug,
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> The following ones appeared to apply to the top of drm-misc-next, but
> I didn't apply them since get_maintainer didn't say they were part of
> drm-misc-next:
>
> drm/tiny: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
If you don't mind, could you take the rcar-du patch through drm-misc too
? I don't plan to send another pull request for v6.5.
> drm/omap: Convert to platform remove callback returning void
Tomi, should drm/omap moved to being maintained through drm-misc ?
> drm/nouveau: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:26 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-06-08 16:26 UTC (permalink / raw)
To: Doug Anderson
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, Uwe Kleine-König, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Inki Dae, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Alain Volmat, Liu Ying, linux-arm-msm, Maxime Ripard,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Brian Starkey, Kuninori Morimoto, Yuan Can, Stefan Agner,
Michal Simek, linux-tegra, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui, Konrad Dybcio,
Alison Wang, Abhinav Kumar, Christian Gmeiner, Mark Brown,
Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, linux-mips, Paul Cercueil,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi Doug,
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> The following ones appeared to apply to the top of drm-misc-next, but
> I didn't apply them since get_maintainer didn't say they were part of
> drm-misc-next:
>
> drm/tiny: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
If you don't mind, could you take the rcar-du patch through drm-misc too
? I don't plan to send another pull request for v6.5.
> drm/omap: Convert to platform remove callback returning void
Tomi, should drm/omap moved to being maintained through drm-misc ?
> drm/nouveau: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:26 ` Laurent Pinchart
0 siblings, 0 replies; 261+ messages in thread
From: Laurent Pinchart @ 2023-06-08 16:26 UTC (permalink / raw)
To: Doug Anderson
Cc: Uwe Kleine-König, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Thomas Zimmermann, Danilo Krummrich,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Qiang Yu, Paul Kocialkowski,
Linus Walleij, Chun-Kuang Hu, Matthias Brugger, Kevin Hilman,
Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen,
Ricardo Ribalda, Konrad Dybcio, Johan Hovold, Stephen Boyd,
Marijn Suijten, Liu Shixin, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Kieran Bingham,
Sandy Huang, Heiko Stübner, Orson Zhai, Baolin Wang,
Chunyan Zhang, Deepak R Varma, Alex Deucher, Alain Volmat,
Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek, linux-aspeed,
nouveau, dri-devel, John Stultz, Alim Akhtar, Fabio Estevam,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
Hi Doug,
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> The following ones appeared to apply to the top of drm-misc-next, but
> I didn't apply them since get_maintainer didn't say they were part of
> drm-misc-next:
>
> drm/tiny: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void
If you don't mind, could you take the rcar-du patch through drm-misc too
? I don't plan to send another pull request for v6.5.
> drm/omap: Convert to platform remove callback returning void
Tomi, should drm/omap moved to being maintained through drm-misc ?
> drm/nouveau: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-06-08 16:26 ` Laurent Pinchart
(?)
(?)
@ 2023-06-08 16:47 ` Doug Anderson
-1 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:47 UTC (permalink / raw)
To: linux-aspeed
Hi,
On Thu, Jun 8, 2023 at 9:26?AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> > The following ones appeared to apply to the top of drm-misc-next, but
> > I didn't apply them since get_maintainer didn't say they were part of
> > drm-misc-next:
> >
> > drm/tiny: Convert to platform remove callback returning void
> > drm/tilcdc: Convert to platform remove callback returning void
> > drm/sprd: Convert to platform remove callback returning void
> > drm/shmobile: Convert to platform remove callback returning void
> > drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
Done.
2510a2579324 drm/rcar-du: Convert to platform remove callback returning void
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:47 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:47 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Karol Herbst,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Andrzej Hajda, Sam Ravnborg, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Kieran Bingham, Ricardo Ribalda, Tian Tao,
Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Martin Blumenstingl, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, linux-mediatek, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
Hi,
On Thu, Jun 8, 2023 at 9:26 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> > The following ones appeared to apply to the top of drm-misc-next, but
> > I didn't apply them since get_maintainer didn't say they were part of
> > drm-misc-next:
> >
> > drm/tiny: Convert to platform remove callback returning void
> > drm/tilcdc: Convert to platform remove callback returning void
> > drm/sprd: Convert to platform remove callback returning void
> > drm/shmobile: Convert to platform remove callback returning void
> > drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
Done.
2510a2579324 drm/rcar-du: Convert to platform remove callback returning void
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:47 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:47 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, Uwe Kleine-König, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Inki Dae, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Alain Volmat, Liu Ying, linux-arm-msm, Maxime Ripard,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Brian Starkey, Kuninori Morimoto, Yuan Can, Stefan Agner,
Michal Simek, linux-tegra, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui, Konrad Dybcio,
Alison Wang, Abhinav Kumar, Christian Gmeiner, Mark Brown,
Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, linux-mips, Paul Cercueil,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi,
On Thu, Jun 8, 2023 at 9:26 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> > The following ones appeared to apply to the top of drm-misc-next, but
> > I didn't apply them since get_maintainer didn't say they were part of
> > drm-misc-next:
> >
> > drm/tiny: Convert to platform remove callback returning void
> > drm/tilcdc: Convert to platform remove callback returning void
> > drm/sprd: Convert to platform remove callback returning void
> > drm/shmobile: Convert to platform remove callback returning void
> > drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
Done.
2510a2579324 drm/rcar-du: Convert to platform remove callback returning void
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 16:47 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 16:47 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Uwe Kleine-König, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Tomi Valkeinen, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Thomas Zimmermann, Danilo Krummrich,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Qiang Yu, Paul Kocialkowski,
Linus Walleij, Chun-Kuang Hu, Matthias Brugger, Kevin Hilman,
Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen,
Ricardo Ribalda, Konrad Dybcio, Johan Hovold, Stephen Boyd,
Marijn Suijten, Liu Shixin, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Kieran Bingham,
Sandy Huang, Heiko Stübner, Orson Zhai, Baolin Wang,
Chunyan Zhang, Deepak R Varma, Alex Deucher, Alain Volmat,
Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek, linux-aspeed,
nouveau, dri-devel, John Stultz, Alim Akhtar, Fabio Estevam,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
Hi,
On Thu, Jun 8, 2023 at 9:26 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> > The following ones appeared to apply to the top of drm-misc-next, but
> > I didn't apply them since get_maintainer didn't say they were part of
> > drm-misc-next:
> >
> > drm/tiny: Convert to platform remove callback returning void
> > drm/tilcdc: Convert to platform remove callback returning void
> > drm/sprd: Convert to platform remove callback returning void
> > drm/shmobile: Convert to platform remove callback returning void
> > drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
Done.
2510a2579324 drm/rcar-du: Convert to platform remove callback returning void
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-06-08 16:26 ` Laurent Pinchart
(?)
(?)
@ 2023-06-08 17:19 ` Tomi Valkeinen
-1 siblings, 0 replies; 261+ messages in thread
From: Tomi Valkeinen @ 2023-06-08 17:19 UTC (permalink / raw)
To: linux-aspeed
On 08/06/2023 19:26, Laurent Pinchart wrote:
> Hi Doug,
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
>> On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig wrote:
>>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
>>>> this patch series adapts the platform drivers below drivers/gpu/drm
>>>> to use the .remove_new() callback. Compared to the traditional .remove()
>>>> callback .remove_new() returns no value. This is a good thing because
>>>> the driver core doesn't (and cannot) cope for errors during remove. The
>>>> only effect of a non-zero return value in .remove() is that the driver
>>>> core emits a warning. The device is removed anyhow and an early return
>>>> from .remove() usually yields a resource leak.
>>>>
>>>> By changing the remove callback to return void driver authors cannot
>>>> reasonably (but wrongly) assume any more that there happens some kind of
>>>> cleanup later.
>>>
>>> I wonder if someone would volunteer to add the whole series to
>>> drm-misc-next?!
>>
>> It looks as if Neil applied quite a few of them already, so I looked
>> at what was left...
>>
>> I'm a little hesitant to just apply the whole kit-and-caboodle to
>> drm-misc-next since there are specific DRM trees for a bunch of them
>> and it would be better if they landed there. ...so I went through all
>> the patches that still applied to drm-misc-next, then used
>> 'scripts/get_maintainer.pl --scm' to check if they were maintained
>> through drm-misc. That still left quite a few patches. I've applied
>> those ones and pushed to drm-misc-next:
>>
>> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
>> callback returning void
>> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
>> b957812839f8 drm/v3d: Convert to platform remove callback returning void
>> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
>> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
>> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
>> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
>> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
>> 9a865e45884a drm/sti: Convert to platform remove callback returning void
>> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
>> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
>> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
>> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
>> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
>> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
>> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
>> 980ec6444372 drm/lima: Convert to platform remove callback returning void
>> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
>> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
>> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
>> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
>> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
>> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
>> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>>
>> The following ones appeared to apply to the top of drm-misc-next, but
>> I didn't apply them since get_maintainer didn't say they were part of
>> drm-misc-next:
>>
>> drm/tiny: Convert to platform remove callback returning void
>> drm/tilcdc: Convert to platform remove callback returning void
>> drm/sprd: Convert to platform remove callback returning void
>> drm/shmobile: Convert to platform remove callback returning void
>> drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
>
>> drm/omap: Convert to platform remove callback returning void
>
> Tomi, should drm/omap moved to being maintained through drm-misc ?
Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc. But
I guess I need to add something to the MAINTAINERS to make this clear.
I'll look at it.
Tomi
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 17:19 ` Tomi Valkeinen
0 siblings, 0 replies; 261+ messages in thread
From: Tomi Valkeinen @ 2023-06-08 17:19 UTC (permalink / raw)
To: Laurent Pinchart, Doug Anderson
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Karol Herbst,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, nouveau, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Andrzej Hajda, Sam Ravnborg, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Kieran Bingham, Ricardo Ribalda, Tian Tao,
Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Martin Blumenstingl, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, linux-mediatek, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
On 08/06/2023 19:26, Laurent Pinchart wrote:
> Hi Doug,
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
>> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
>>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
>>>> this patch series adapts the platform drivers below drivers/gpu/drm
>>>> to use the .remove_new() callback. Compared to the traditional .remove()
>>>> callback .remove_new() returns no value. This is a good thing because
>>>> the driver core doesn't (and cannot) cope for errors during remove. The
>>>> only effect of a non-zero return value in .remove() is that the driver
>>>> core emits a warning. The device is removed anyhow and an early return
>>>> from .remove() usually yields a resource leak.
>>>>
>>>> By changing the remove callback to return void driver authors cannot
>>>> reasonably (but wrongly) assume any more that there happens some kind of
>>>> cleanup later.
>>>
>>> I wonder if someone would volunteer to add the whole series to
>>> drm-misc-next?!
>>
>> It looks as if Neil applied quite a few of them already, so I looked
>> at what was left...
>>
>> I'm a little hesitant to just apply the whole kit-and-caboodle to
>> drm-misc-next since there are specific DRM trees for a bunch of them
>> and it would be better if they landed there. ...so I went through all
>> the patches that still applied to drm-misc-next, then used
>> 'scripts/get_maintainer.pl --scm' to check if they were maintained
>> through drm-misc. That still left quite a few patches. I've applied
>> those ones and pushed to drm-misc-next:
>>
>> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
>> callback returning void
>> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
>> b957812839f8 drm/v3d: Convert to platform remove callback returning void
>> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
>> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
>> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
>> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
>> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
>> 9a865e45884a drm/sti: Convert to platform remove callback returning void
>> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
>> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
>> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
>> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
>> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
>> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
>> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
>> 980ec6444372 drm/lima: Convert to platform remove callback returning void
>> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
>> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
>> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
>> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
>> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
>> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
>> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>>
>> The following ones appeared to apply to the top of drm-misc-next, but
>> I didn't apply them since get_maintainer didn't say they were part of
>> drm-misc-next:
>>
>> drm/tiny: Convert to platform remove callback returning void
>> drm/tilcdc: Convert to platform remove callback returning void
>> drm/sprd: Convert to platform remove callback returning void
>> drm/shmobile: Convert to platform remove callback returning void
>> drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
>
>> drm/omap: Convert to platform remove callback returning void
>
> Tomi, should drm/omap moved to being maintained through drm-misc ?
Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc. But
I guess I need to add something to the MAINTAINERS to make this clear.
I'll look at it.
Tomi
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 17:19 ` Tomi Valkeinen
0 siblings, 0 replies; 261+ messages in thread
From: Tomi Valkeinen @ 2023-06-08 17:19 UTC (permalink / raw)
To: Laurent Pinchart, Doug Anderson
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, Uwe Kleine-König, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Inki Dae, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, nouveau,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Alain Volmat, Liu Ying, linux-arm-msm, Maxime Ripard,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Brian Starkey, Kuninori Morimoto, Yuan Can, Stefan Agner,
Michal Simek, linux-tegra, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, Orson Zhai, Chun-Kuang Hu,
Arnd Bergmann, Guo Zhengkui, Konrad Dybcio, Alison Wang,
Abhinav Kumar, Christian Gmeiner, Mark Brown, Maxime Ripard,
Baolin Wang, Daniel Vetter, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Kieran Bingham, Ricardo Ribalda, Tian Tao,
Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Rob Clark, Martin Blumenstingl, Philippe Cornu, Melissa Wen,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Philipp Zabel, Dmitry Baryshkov,
Jyri Sarha, Lucas Stach
On 08/06/2023 19:26, Laurent Pinchart wrote:
> Hi Doug,
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
>> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
>>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
>>>> this patch series adapts the platform drivers below drivers/gpu/drm
>>>> to use the .remove_new() callback. Compared to the traditional .remove()
>>>> callback .remove_new() returns no value. This is a good thing because
>>>> the driver core doesn't (and cannot) cope for errors during remove. The
>>>> only effect of a non-zero return value in .remove() is that the driver
>>>> core emits a warning. The device is removed anyhow and an early return
>>>> from .remove() usually yields a resource leak.
>>>>
>>>> By changing the remove callback to return void driver authors cannot
>>>> reasonably (but wrongly) assume any more that there happens some kind of
>>>> cleanup later.
>>>
>>> I wonder if someone would volunteer to add the whole series to
>>> drm-misc-next?!
>>
>> It looks as if Neil applied quite a few of them already, so I looked
>> at what was left...
>>
>> I'm a little hesitant to just apply the whole kit-and-caboodle to
>> drm-misc-next since there are specific DRM trees for a bunch of them
>> and it would be better if they landed there. ...so I went through all
>> the patches that still applied to drm-misc-next, then used
>> 'scripts/get_maintainer.pl --scm' to check if they were maintained
>> through drm-misc. That still left quite a few patches. I've applied
>> those ones and pushed to drm-misc-next:
>>
>> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
>> callback returning void
>> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
>> b957812839f8 drm/v3d: Convert to platform remove callback returning void
>> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
>> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
>> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
>> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
>> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
>> 9a865e45884a drm/sti: Convert to platform remove callback returning void
>> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
>> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
>> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
>> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
>> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
>> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
>> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
>> 980ec6444372 drm/lima: Convert to platform remove callback returning void
>> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
>> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
>> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
>> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
>> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
>> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
>> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>>
>> The following ones appeared to apply to the top of drm-misc-next, but
>> I didn't apply them since get_maintainer didn't say they were part of
>> drm-misc-next:
>>
>> drm/tiny: Convert to platform remove callback returning void
>> drm/tilcdc: Convert to platform remove callback returning void
>> drm/sprd: Convert to platform remove callback returning void
>> drm/shmobile: Convert to platform remove callback returning void
>> drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
>
>> drm/omap: Convert to platform remove callback returning void
>
> Tomi, should drm/omap moved to being maintained through drm-misc ?
Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc. But
I guess I need to add something to the MAINTAINERS to make this clear.
I'll look at it.
Tomi
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 17:19 ` Tomi Valkeinen
0 siblings, 0 replies; 261+ messages in thread
From: Tomi Valkeinen @ 2023-06-08 17:19 UTC (permalink / raw)
To: Laurent Pinchart, Doug Anderson
Cc: Uwe Kleine-König, Liviu Dudau, Mihail Atanassov,
Brian Starkey, David Airlie, Daniel Vetter, Russell King,
Joel Stanley, Sam Ravnborg, Boris Brezillon, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Andrzej Hajda, Neil Armstrong,
Robert Foss, Rahul T R, Jayshri Pawar, Liu Ying, Shawn Guo,
Sascha Hauer, Minghao Chi, Mark Brown, Kuninori Morimoto,
Lucas Stach, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Krzysztof Kozlowski, Jingoo Han, Stefan Agner, Alison Wang,
Xinliang Liu, Tian Tao, Ville Syrjälä, Jani Nikula,
Thomas Zimmermann, Danilo Krummrich, Javier Martinez Canillas,
Laurentiu Palcu, Philipp Zabel, Paul Cercueil, Anitha Chrisanthus,
Qiang Yu, Paul Kocialkowski, Linus Walleij, Chun-Kuang Hu,
Matthias Brugger, Kevin Hilman, Rob Clark, Abhinav Kumar,
Dmitry Baryshkov, Akhil P Oommen, Ricardo Ribalda, Konrad Dybcio,
Johan Hovold, Stephen Boyd, Marijn Suijten, Liu Shixin,
Miaoqian Lin, Kuogee Hsieh, Bjorn Andersson, Marek Vasut,
Ben Skeggs, Karol Herbst, Lyude Paul, Tomi Valkeinen,
Guo Zhengkui, Yuan Can, Arnd Bergmann, Liang He, Thierry Reding,
Rob Herring, Kieran Bingham, Sandy Huang, Heiko Stübner,
Orson Zhai, Baolin Wang, Chunyan Zhang, Deepak R Varma,
Alex Deucher, Alain Volmat, Yannick Fertre, Raphael Gallais-Pou,
Philippe Cornu, Maxime Coquelin, Alexandre Torgue, Maxime Ripard,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Jonathan Hunter,
Maxime Ripard, Maíra Canal, Noralf Trønnes, Jyri Sarha,
Alexey Brodkin, Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek,
linux-aspeed, nouveau, dri-devel, John Stultz, Alim Akhtar,
Fabio Estevam, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
lima, Steven Price, linux-rockchip, Xinwei Kong,
Mali DP Maintainers, NXP Linux Team, Russell King, linux-sunxi,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
Christian Gmeiner, linux-mediatek, linux-tegra, linux-amlogic,
Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-stm32, linux-mips, linux-renesas-soc,
kernel, Yongqin Liu, freedreno
On 08/06/2023 19:26, Laurent Pinchart wrote:
> Hi Doug,
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
>> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
>>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
>>>> this patch series adapts the platform drivers below drivers/gpu/drm
>>>> to use the .remove_new() callback. Compared to the traditional .remove()
>>>> callback .remove_new() returns no value. This is a good thing because
>>>> the driver core doesn't (and cannot) cope for errors during remove. The
>>>> only effect of a non-zero return value in .remove() is that the driver
>>>> core emits a warning. The device is removed anyhow and an early return
>>>> from .remove() usually yields a resource leak.
>>>>
>>>> By changing the remove callback to return void driver authors cannot
>>>> reasonably (but wrongly) assume any more that there happens some kind of
>>>> cleanup later.
>>>
>>> I wonder if someone would volunteer to add the whole series to
>>> drm-misc-next?!
>>
>> It looks as if Neil applied quite a few of them already, so I looked
>> at what was left...
>>
>> I'm a little hesitant to just apply the whole kit-and-caboodle to
>> drm-misc-next since there are specific DRM trees for a bunch of them
>> and it would be better if they landed there. ...so I went through all
>> the patches that still applied to drm-misc-next, then used
>> 'scripts/get_maintainer.pl --scm' to check if they were maintained
>> through drm-misc. That still left quite a few patches. I've applied
>> those ones and pushed to drm-misc-next:
>>
>> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
>> callback returning void
>> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
>> b957812839f8 drm/v3d: Convert to platform remove callback returning void
>> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
>> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
>> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
>> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
>> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
>> 9a865e45884a drm/sti: Convert to platform remove callback returning void
>> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
>> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
>> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
>> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
>> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
>> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
>> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
>> 980ec6444372 drm/lima: Convert to platform remove callback returning void
>> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
>> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
>> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
>> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
>> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
>> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
>> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>>
>> The following ones appeared to apply to the top of drm-misc-next, but
>> I didn't apply them since get_maintainer didn't say they were part of
>> drm-misc-next:
>>
>> drm/tiny: Convert to platform remove callback returning void
>> drm/tilcdc: Convert to platform remove callback returning void
>> drm/sprd: Convert to platform remove callback returning void
>> drm/shmobile: Convert to platform remove callback returning void
>> drm/rcar-du: Convert to platform remove callback returning void
>
> If you don't mind, could you take the rcar-du patch through drm-misc too
> ? I don't plan to send another pull request for v6.5.
>
>> drm/omap: Convert to platform remove callback returning void
>
> Tomi, should drm/omap moved to being maintained through drm-misc ?
Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc. But
I guess I need to add something to the MAINTAINERS to make this clear.
I'll look at it.
Tomi
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-06-08 17:19 ` Tomi Valkeinen
(?)
(?)
@ 2023-06-08 17:38 ` Doug Anderson
-1 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 17:38 UTC (permalink / raw)
To: linux-aspeed
Hi,
On Thu, Jun 8, 2023 at 10:19?AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
>
> On 08/06/2023 19:26, Laurent Pinchart wrote:
> > Hi Doug,
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> >> On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig wrote:
> >>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> >>>> this patch series adapts the platform drivers below drivers/gpu/drm
> >>>> to use the .remove_new() callback. Compared to the traditional .remove()
> >>>> callback .remove_new() returns no value. This is a good thing because
> >>>> the driver core doesn't (and cannot) cope for errors during remove. The
> >>>> only effect of a non-zero return value in .remove() is that the driver
> >>>> core emits a warning. The device is removed anyhow and an early return
> >>>> from .remove() usually yields a resource leak.
> >>>>
> >>>> By changing the remove callback to return void driver authors cannot
> >>>> reasonably (but wrongly) assume any more that there happens some kind of
> >>>> cleanup later.
> >>>
> >>> I wonder if someone would volunteer to add the whole series to
> >>> drm-misc-next?!
> >>
> >> It looks as if Neil applied quite a few of them already, so I looked
> >> at what was left...
> >>
> >> I'm a little hesitant to just apply the whole kit-and-caboodle to
> >> drm-misc-next since there are specific DRM trees for a bunch of them
> >> and it would be better if they landed there. ...so I went through all
> >> the patches that still applied to drm-misc-next, then used
> >> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> >> through drm-misc. That still left quite a few patches. I've applied
> >> those ones and pushed to drm-misc-next:
> >>
> >> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> >> callback returning void
> >> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> >> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> >> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> >> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> >> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> >> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> >> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> >> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> >> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> >> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> >> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> >> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> >> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> >> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> >> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> >> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> >> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> >> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> >> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> >> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> >> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> >> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> >> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >>
> >> The following ones appeared to apply to the top of drm-misc-next, but
> >> I didn't apply them since get_maintainer didn't say they were part of
> >> drm-misc-next:
> >>
> >> drm/tiny: Convert to platform remove callback returning void
> >> drm/tilcdc: Convert to platform remove callback returning void
> >> drm/sprd: Convert to platform remove callback returning void
> >> drm/shmobile: Convert to platform remove callback returning void
> >> drm/rcar-du: Convert to platform remove callback returning void
> >
> > If you don't mind, could you take the rcar-du patch through drm-misc too
> > ? I don't plan to send another pull request for v6.5.
> >
> >> drm/omap: Convert to platform remove callback returning void
> >
> > Tomi, should drm/omap moved to being maintained through drm-misc ?
>
> Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc.
tidss was already in my list of applied patches.
I've applied the other two and pushed:
c2807ecb5290 drm/omap: Convert to platform remove callback returning void
e52d1282f919 drm/tilcdc: Convert to platform remove callback returning void
> But
> I guess I need to add something to the MAINTAINERS to make this clear.
> I'll look at it.
The key I was looking for was:
T: git git://anongit.freedesktop.org/drm/drm-misc
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 17:38 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 17:38 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Xinliang Liu, dri-devel, Russell King, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Steven Price, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Karol Herbst,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, nouveau, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers,
Joel Stanley, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Maxime Ripard, Baolin Wang, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, linux-mips, Paul Cercueil,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, linux-mediatek, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov,
Jyri Sarha
Hi,
On Thu, Jun 8, 2023 at 10:19 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
>
> On 08/06/2023 19:26, Laurent Pinchart wrote:
> > Hi Doug,
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> >> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
> >>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> >>>> this patch series adapts the platform drivers below drivers/gpu/drm
> >>>> to use the .remove_new() callback. Compared to the traditional .remove()
> >>>> callback .remove_new() returns no value. This is a good thing because
> >>>> the driver core doesn't (and cannot) cope for errors during remove. The
> >>>> only effect of a non-zero return value in .remove() is that the driver
> >>>> core emits a warning. The device is removed anyhow and an early return
> >>>> from .remove() usually yields a resource leak.
> >>>>
> >>>> By changing the remove callback to return void driver authors cannot
> >>>> reasonably (but wrongly) assume any more that there happens some kind of
> >>>> cleanup later.
> >>>
> >>> I wonder if someone would volunteer to add the whole series to
> >>> drm-misc-next?!
> >>
> >> It looks as if Neil applied quite a few of them already, so I looked
> >> at what was left...
> >>
> >> I'm a little hesitant to just apply the whole kit-and-caboodle to
> >> drm-misc-next since there are specific DRM trees for a bunch of them
> >> and it would be better if they landed there. ...so I went through all
> >> the patches that still applied to drm-misc-next, then used
> >> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> >> through drm-misc. That still left quite a few patches. I've applied
> >> those ones and pushed to drm-misc-next:
> >>
> >> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> >> callback returning void
> >> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> >> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> >> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> >> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> >> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> >> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> >> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> >> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> >> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> >> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> >> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> >> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> >> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> >> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> >> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> >> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> >> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> >> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> >> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> >> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> >> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> >> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> >> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >>
> >> The following ones appeared to apply to the top of drm-misc-next, but
> >> I didn't apply them since get_maintainer didn't say they were part of
> >> drm-misc-next:
> >>
> >> drm/tiny: Convert to platform remove callback returning void
> >> drm/tilcdc: Convert to platform remove callback returning void
> >> drm/sprd: Convert to platform remove callback returning void
> >> drm/shmobile: Convert to platform remove callback returning void
> >> drm/rcar-du: Convert to platform remove callback returning void
> >
> > If you don't mind, could you take the rcar-du patch through drm-misc too
> > ? I don't plan to send another pull request for v6.5.
> >
> >> drm/omap: Convert to platform remove callback returning void
> >
> > Tomi, should drm/omap moved to being maintained through drm-misc ?
>
> Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc.
tidss was already in my list of applied patches.
I've applied the other two and pushed:
c2807ecb5290 drm/omap: Convert to platform remove callback returning void
e52d1282f919 drm/tilcdc: Convert to platform remove callback returning void
> But
> I guess I need to add something to the MAINTAINERS to make this clear.
> I'll look at it.
The key I was looking for was:
T: git git://anongit.freedesktop.org/drm/drm-misc
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 17:38 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 17:38 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
NXP Linux Team, Miaoqian Lin, Uwe Kleine-König, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Inki Dae, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, nouveau,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Alain Volmat, Liu Ying, linux-arm-msm, Maxime Ripard,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Brian Starkey, Kuninori Morimoto, Yuan Can, Stefan Agner,
Michal Simek, linux-tegra, Laurent Pinchart, Andrzej Hajda,
Sam Ravnborg, Rob Herring, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, Orson Zhai,
Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui, Konrad Dybcio,
Alison Wang, Abhinav Kumar, Christian Gmeiner, Mark Brown,
Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, linux-mips, Paul Cercueil,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi,
On Thu, Jun 8, 2023 at 10:19 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
>
> On 08/06/2023 19:26, Laurent Pinchart wrote:
> > Hi Doug,
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> >> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
> >>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> >>>> this patch series adapts the platform drivers below drivers/gpu/drm
> >>>> to use the .remove_new() callback. Compared to the traditional .remove()
> >>>> callback .remove_new() returns no value. This is a good thing because
> >>>> the driver core doesn't (and cannot) cope for errors during remove. The
> >>>> only effect of a non-zero return value in .remove() is that the driver
> >>>> core emits a warning. The device is removed anyhow and an early return
> >>>> from .remove() usually yields a resource leak.
> >>>>
> >>>> By changing the remove callback to return void driver authors cannot
> >>>> reasonably (but wrongly) assume any more that there happens some kind of
> >>>> cleanup later.
> >>>
> >>> I wonder if someone would volunteer to add the whole series to
> >>> drm-misc-next?!
> >>
> >> It looks as if Neil applied quite a few of them already, so I looked
> >> at what was left...
> >>
> >> I'm a little hesitant to just apply the whole kit-and-caboodle to
> >> drm-misc-next since there are specific DRM trees for a bunch of them
> >> and it would be better if they landed there. ...so I went through all
> >> the patches that still applied to drm-misc-next, then used
> >> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> >> through drm-misc. That still left quite a few patches. I've applied
> >> those ones and pushed to drm-misc-next:
> >>
> >> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> >> callback returning void
> >> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> >> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> >> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> >> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> >> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> >> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> >> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> >> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> >> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> >> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> >> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> >> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> >> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> >> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> >> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> >> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> >> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> >> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> >> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> >> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> >> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> >> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> >> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >>
> >> The following ones appeared to apply to the top of drm-misc-next, but
> >> I didn't apply them since get_maintainer didn't say they were part of
> >> drm-misc-next:
> >>
> >> drm/tiny: Convert to platform remove callback returning void
> >> drm/tilcdc: Convert to platform remove callback returning void
> >> drm/sprd: Convert to platform remove callback returning void
> >> drm/shmobile: Convert to platform remove callback returning void
> >> drm/rcar-du: Convert to platform remove callback returning void
> >
> > If you don't mind, could you take the rcar-du patch through drm-misc too
> > ? I don't plan to send another pull request for v6.5.
> >
> >> drm/omap: Convert to platform remove callback returning void
> >
> > Tomi, should drm/omap moved to being maintained through drm-misc ?
>
> Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc.
tidss was already in my list of applied patches.
I've applied the other two and pushed:
c2807ecb5290 drm/omap: Convert to platform remove callback returning void
e52d1282f919 drm/tilcdc: Convert to platform remove callback returning void
> But
> I guess I need to add something to the MAINTAINERS to make this clear.
> I'll look at it.
The key I was looking for was:
T: git git://anongit.freedesktop.org/drm/drm-misc
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-06-08 17:38 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-08 17:38 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, Uwe Kleine-König, Liviu Dudau,
Mihail Atanassov, Brian Starkey, David Airlie, Daniel Vetter,
Russell King, Joel Stanley, Sam Ravnborg, Boris Brezillon,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Andrzej Hajda,
Neil Armstrong, Robert Foss, Rahul T R, Jayshri Pawar, Liu Ying,
Shawn Guo, Sascha Hauer, Minghao Chi, Mark Brown,
Kuninori Morimoto, Lucas Stach, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Jingoo Han, Stefan Agner,
Alison Wang, Xinliang Liu, Tian Tao, Ville Syrjälä,
Jani Nikula, Thomas Zimmermann, Danilo Krummrich,
Javier Martinez Canillas, Laurentiu Palcu, Philipp Zabel,
Paul Cercueil, Anitha Chrisanthus, Qiang Yu, Paul Kocialkowski,
Linus Walleij, Chun-Kuang Hu, Matthias Brugger, Kevin Hilman,
Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Akhil P Oommen,
Ricardo Ribalda, Konrad Dybcio, Johan Hovold, Stephen Boyd,
Marijn Suijten, Liu Shixin, Miaoqian Lin, Kuogee Hsieh,
Bjorn Andersson, Marek Vasut, Ben Skeggs, Karol Herbst,
Lyude Paul, Tomi Valkeinen, Guo Zhengkui, Yuan Can, Arnd Bergmann,
Liang He, Thierry Reding, Rob Herring, Kieran Bingham,
Sandy Huang, Heiko Stübner, Orson Zhai, Baolin Wang,
Chunyan Zhang, Deepak R Varma, Alex Deucher, Alain Volmat,
Yannick Fertre, Raphael Gallais-Pou, Philippe Cornu,
Maxime Coquelin, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Jonathan Hunter, Maxime Ripard,
Maíra Canal, Noralf Trønnes, Jyri Sarha, Alexey Brodkin,
Emma Anholt, Melissa Wen, Hyun Kwon, Michal Simek, linux-aspeed,
nouveau, dri-devel, John Stultz, Alim Akhtar, Fabio Estevam,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
Hi,
On Thu, Jun 8, 2023 at 10:19 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
>
> On 08/06/2023 19:26, Laurent Pinchart wrote:
> > Hi Doug,
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> >> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König wrote:
> >>> On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> >>>> this patch series adapts the platform drivers below drivers/gpu/drm
> >>>> to use the .remove_new() callback. Compared to the traditional .remove()
> >>>> callback .remove_new() returns no value. This is a good thing because
> >>>> the driver core doesn't (and cannot) cope for errors during remove. The
> >>>> only effect of a non-zero return value in .remove() is that the driver
> >>>> core emits a warning. The device is removed anyhow and an early return
> >>>> from .remove() usually yields a resource leak.
> >>>>
> >>>> By changing the remove callback to return void driver authors cannot
> >>>> reasonably (but wrongly) assume any more that there happens some kind of
> >>>> cleanup later.
> >>>
> >>> I wonder if someone would volunteer to add the whole series to
> >>> drm-misc-next?!
> >>
> >> It looks as if Neil applied quite a few of them already, so I looked
> >> at what was left...
> >>
> >> I'm a little hesitant to just apply the whole kit-and-caboodle to
> >> drm-misc-next since there are specific DRM trees for a bunch of them
> >> and it would be better if they landed there. ...so I went through all
> >> the patches that still applied to drm-misc-next, then used
> >> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> >> through drm-misc. That still left quite a few patches. I've applied
> >> those ones and pushed to drm-misc-next:
> >>
> >> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> >> callback returning void
> >> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> >> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> >> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> >> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> >> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> >> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> >> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> >> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> >> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> >> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> >> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> >> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> >> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> >> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> >> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> >> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> >> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> >> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> >> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> >> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> >> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> >> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> >> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >>
> >> The following ones appeared to apply to the top of drm-misc-next, but
> >> I didn't apply them since get_maintainer didn't say they were part of
> >> drm-misc-next:
> >>
> >> drm/tiny: Convert to platform remove callback returning void
> >> drm/tilcdc: Convert to platform remove callback returning void
> >> drm/sprd: Convert to platform remove callback returning void
> >> drm/shmobile: Convert to platform remove callback returning void
> >> drm/rcar-du: Convert to platform remove callback returning void
> >
> > If you don't mind, could you take the rcar-du patch through drm-misc too
> > ? I don't plan to send another pull request for v6.5.
> >
> >> drm/omap: Convert to platform remove callback returning void
> >
> > Tomi, should drm/omap moved to being maintained through drm-misc ?
>
> Yes. tilcdc, tidss and omapdrm are all maintained through drm-misc.
tidss was already in my list of applied patches.
I've applied the other two and pushed:
c2807ecb5290 drm/omap: Convert to platform remove callback returning void
e52d1282f919 drm/tilcdc: Convert to platform remove callback returning void
> But
> I guess I need to add something to the MAINTAINERS to make this clear.
> I'll look at it.
The key I was looking for was:
T: git git://anongit.freedesktop.org/drm/drm-misc
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread
* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-08 16:08 ` Doug Anderson
(?)
(?)
@ 2023-06-17 16:12 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-17 16:12 UTC (permalink / raw)
To: linux-aspeed
[expanding recipents by the other affected persons]
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
Together with the patches that were applied later the topmost commit
from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
callback returning void"). This commit was part for the following next
tags:
$ git tag -l --contains c2807ecb5290
next-20230609
next-20230613
next-20230614
next-20230615
However in next-20230616 they are missing. In next-20230616
drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
also not included with a different commit id). The 37 patches dropped
are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
$ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
1 Christophe JAILLET
2 Jessica Zhang
5 Karol Wachowski
1 Laura Nao
27 Uwe Kleine-K?nig
1 Wang Jianzheng
I guess this was done by mistake because nobody told me about dropping
my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
again?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230617/412a4327/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 16:12 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-17 16:12 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Xinliang Liu, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Wang Jianzheng, Maxime Ripard, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Karol Herbst,
Alexandre Belloni, Michal Simek, Matthias Brugger,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Paul Cercueil, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Bjorn Andersson, linux-stm32, Emma Anholt,
Konrad Dybcio, Alexandre Torgue, Nicolas Ferre, Liu Shixin,
Krzysztof Kozlowski, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]
[expanding recipents by the other affected persons]
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
Together with the patches that were applied later the topmost commit
from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
callback returning void"). This commit was part for the following next
tags:
$ git tag -l --contains c2807ecb5290
next-20230609
next-20230613
next-20230614
next-20230615
However in next-20230616 they are missing. In next-20230616
drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
also not included with a different commit id). The 37 patches dropped
are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
$ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
1 Christophe JAILLET
2 Jessica Zhang
5 Karol Wachowski
1 Laura Nao
27 Uwe Kleine-König
1 Wang Jianzheng
I guess this was done by mistake because nobody told me about dropping
my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
again?
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] 261+ messages in thread* [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 16:12 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-17 16:12 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Heiko Stübner, Xinliang Liu, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Akhil P Oommen, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Wang Jianzheng, Maxime Ripard, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Alexandre Belloni,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Nicolas Ferre, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]
[expanding recipents by the other affected persons]
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
Together with the patches that were applied later the topmost commit
from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
callback returning void"). This commit was part for the following next
tags:
$ git tag -l --contains c2807ecb5290
next-20230609
next-20230613
next-20230614
next-20230615
However in next-20230616 they are missing. In next-20230616
drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
also not included with a different commit id). The 37 patches dropped
are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
$ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
1 Christophe JAILLET
2 Jessica Zhang
5 Karol Wachowski
1 Laura Nao
27 Uwe Kleine-König
1 Wang Jianzheng
I guess this was done by mistake because nobody told me about dropping
my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
again?
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] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 16:12 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-17 16:12 UTC (permalink / raw)
To: Doug Anderson
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Karol Herbst, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Akhil P Oommen, Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae, Sean Paul,
Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Brian Starkey, Kuninori Morimoto, Yuan Can,
Stefan Agner, Michal Simek, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Daniel Vetter, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, David Airlie,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Philipp Zabel, Dmitry Baryshkov, Jyri Sarha, Lucas Stach,
Christophe JAILLET, Jessica Zhang, Karol Wachowski, Laura Nao,
Wang Jianzheng, Raymond Tan, Stanislaw Gruszka
[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]
[expanding recipents by the other affected persons]
On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
>
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
>
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
>
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
Together with the patches that were applied later the topmost commit
from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
callback returning void"). This commit was part for the following next
tags:
$ git tag -l --contains c2807ecb5290
next-20230609
next-20230613
next-20230614
next-20230615
However in next-20230616 they are missing. In next-20230616
drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
also not included with a different commit id). The 37 patches dropped
are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
$ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
1 Christophe JAILLET
2 Jessica Zhang
5 Karol Wachowski
1 Laura Nao
27 Uwe Kleine-König
1 Wang Jianzheng
I guess this was done by mistake because nobody told me about dropping
my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
again?
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] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-17 16:12 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-17 16:51 ` Chen-Yu Tsai
-1 siblings, 0 replies; 261+ messages in thread
From: Chen-Yu Tsai @ 2023-06-17 16:51 UTC (permalink / raw)
To: linux-aspeed
On Sun, Jun 18, 2023 at 12:13?AM Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-K?nig
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
AFAIK drm-misc/for-linux-next cuts off at -rc6, at which point any patches
merged get queued up for -next-next. I think that's what happened to your
patches?
ChenYu
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 16:51 ` Chen-Yu Tsai
0 siblings, 0 replies; 261+ messages in thread
From: Chen-Yu Tsai @ 2023-06-17 16:51 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Xinliang Liu, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, Maxime Ripard, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Karol Herbst, Alexandre Belloni, Michal Simek,
Matthias Brugger, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Paul Cercueil, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Bjorn Andersson, linux-stm32, Emma Anholt,
Konrad Dybcio, Alexandre Torgue, Doug Anderson, Liu Shixin,
Krzysztof Kozlowski, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
On Sun, Jun 18, 2023 at 12:13 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-König
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
AFAIK drm-misc/for-linux-next cuts off at -rc6, at which point any patches
merged get queued up for -next-next. I think that's what happened to your
patches?
ChenYu
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 16:51 ` Chen-Yu Tsai
0 siblings, 0 replies; 261+ messages in thread
From: Chen-Yu Tsai @ 2023-06-17 16:51 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Xinliang Liu, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Akhil P Oommen, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Nicolas Ferre, Wang Jianzheng, Maxime Ripard,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Alexandre Belloni,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Jernej Skrabec,
Xinwei Kong, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
On Sun, Jun 18, 2023 at 12:13 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-König
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
AFAIK drm-misc/for-linux-next cuts off at -rc6, at which point any patches
merged get queued up for -next-next. I think that's what happened to your
patches?
ChenYu
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 16:51 ` Chen-Yu Tsai
0 siblings, 0 replies; 261+ messages in thread
From: Chen-Yu Tsai @ 2023-06-17 16:51 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Doug Anderson, Heiko Stübner, Xinliang Liu, Linus Walleij,
dri-devel, Russell King, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Karol Herbst, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Akhil P Oommen, Danilo Krummrich, NXP Linux Team,
Miaoqian Lin, linux-sunxi, Rahul T R, Raphael Gallais-Pou,
Jani Nikula, Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Brian Starkey, Kuninori Morimoto, Yuan Can,
Stefan Agner, Michal Simek, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Daniel Vetter, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, David Airlie,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Philipp Zabel, Dmitry Baryshkov, Jyri Sarha, Lucas Stach,
Christophe JAILLET, Jessica Zhang, Karol Wachowski, Laura Nao,
Wang Jianzheng, Raymond Tan, Stanislaw Gruszka
On Sun, Jun 18, 2023 at 12:13 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-König
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
AFAIK drm-misc/for-linux-next cuts off at -rc6, at which point any patches
merged get queued up for -next-next. I think that's what happened to your
patches?
ChenYu
^ permalink raw reply [flat|nested] 261+ messages in thread
* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-17 16:12 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-17 17:57 ` Doug Anderson
-1 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-17 17:57 UTC (permalink / raw)
To: linux-aspeed
Hi,
On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-K?nig
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
Actually, it was probably a mistake that these patches got merged to
linuxnext during the 4 days that you noticed. However, your patches
aren't dropped and are still present in drm-misc-next.
drm-misc has a bit of a unique model and it's documented fairly well here:
https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
The key is that committers can commit to drm-misc-next _at any time_
regardless of the merge window. The drm-misc merge strategy makes this
OK. Specifically, when it's late in the linux cycle then drm-misc-next
is supposed to stop merging to linuxnext. Then, shortly after the
merge window closes, patches will start flowing again.
So basically your patches are landed and should even keep the same git
hashes when they eventually make it to Linux. They just won't land for
another release cycle of Linux.
Hope that makes sense!
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 17:57 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-17 17:57 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Xinliang Liu, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Wang Jianzheng, Maxime Ripard, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Karol Herbst,
Alexandre Belloni, Michal Simek, Matthias Brugger,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Paul Cercueil, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Bjorn Andersson, linux-stm32, Emma Anholt,
Konrad Dybcio, Alexandre Torgue, Nicolas Ferre, Liu Shixin,
Krzysztof Kozlowski, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
Hi,
On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-König
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
Actually, it was probably a mistake that these patches got merged to
linuxnext during the 4 days that you noticed. However, your patches
aren't dropped and are still present in drm-misc-next.
drm-misc has a bit of a unique model and it's documented fairly well here:
https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
The key is that committers can commit to drm-misc-next _at any time_
regardless of the merge window. The drm-misc merge strategy makes this
OK. Specifically, when it's late in the linux cycle then drm-misc-next
is supposed to stop merging to linuxnext. Then, shortly after the
merge window closes, patches will start flowing again.
So basically your patches are landed and should even keep the same git
hashes when they eventually make it to Linux. They just won't land for
another release cycle of Linux.
Hope that makes sense!
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 17:57 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-17 17:57 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Xinliang Liu, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Akhil P Oommen, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Wang Jianzheng, Maxime Ripard, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Alexandre Belloni,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Nicolas Ferre, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
Hi,
On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-König
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
Actually, it was probably a mistake that these patches got merged to
linuxnext during the 4 days that you noticed. However, your patches
aren't dropped and are still present in drm-misc-next.
drm-misc has a bit of a unique model and it's documented fairly well here:
https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
The key is that committers can commit to drm-misc-next _at any time_
regardless of the merge window. The drm-misc merge strategy makes this
OK. Specifically, when it's late in the linux cycle then drm-misc-next
is supposed to stop merging to linuxnext. Then, shortly after the
merge window closes, patches will start flowing again.
So basically your patches are landed and should even keep the same git
hashes when they eventually make it to Linux. They just won't land for
another release cycle of Linux.
Hope that makes sense!
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-17 17:57 ` Doug Anderson
0 siblings, 0 replies; 261+ messages in thread
From: Doug Anderson @ 2023-06-17 17:57 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Heiko Stübner, Xinliang Liu, Linus Walleij, dri-devel,
Russell King, Alim Akhtar, Anitha Chrisanthus, Marijn Suijten,
Steven Price, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Karol Herbst, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Akhil P Oommen, Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae, Sean Paul,
Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Brian Starkey, Kuninori Morimoto, Yuan Can,
Stefan Agner, Michal Simek, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Daniel Vetter, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, David Airlie,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Rob Clark, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Philipp Zabel, Dmitry Baryshkov, Jyri Sarha, Lucas Stach,
Christophe JAILLET, Jessica Zhang, Karol Wachowski, Laura Nao,
Wang Jianzheng, Raymond Tan, Stanislaw Gruszka
Hi,
On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> [expanding recipents by the other affected persons]
>
> On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > callback .remove_new() returns no value. This is a good thing because
> > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > only effect of a non-zero return value in .remove() is that the driver
> > > > core emits a warning. The device is removed anyhow and an early return
> > > > from .remove() usually yields a resource leak.
> > > >
> > > > By changing the remove callback to return void driver authors cannot
> > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > cleanup later.
> > >
> > > I wonder if someone would volunteer to add the whole series to
> > > drm-misc-next?!
> >
> > It looks as if Neil applied quite a few of them already, so I looked
> > at what was left...
> >
> > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > drm-misc-next since there are specific DRM trees for a bunch of them
> > and it would be better if they landed there. ...so I went through all
> > the patches that still applied to drm-misc-next, then used
> > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > through drm-misc. That still left quite a few patches. I've applied
> > those ones and pushed to drm-misc-next:
> >
> > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > callback returning void
> > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
>
> Together with the patches that were applied later the topmost commit
> from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> callback returning void"). This commit was part for the following next
> tags:
>
> $ git tag -l --contains c2807ecb5290
> next-20230609
> next-20230613
> next-20230614
> next-20230615
>
> However in next-20230616 they are missing. In next-20230616
> drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> also not included with a different commit id). The 37 patches dropped
> are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
>
> $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> 1 Christophe JAILLET
> 2 Jessica Zhang
> 5 Karol Wachowski
> 1 Laura Nao
> 27 Uwe Kleine-König
> 1 Wang Jianzheng
>
>
> I guess this was done by mistake because nobody told me about dropping
> my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> again?
Actually, it was probably a mistake that these patches got merged to
linuxnext during the 4 days that you noticed. However, your patches
aren't dropped and are still present in drm-misc-next.
drm-misc has a bit of a unique model and it's documented fairly well here:
https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
The key is that committers can commit to drm-misc-next _at any time_
regardless of the merge window. The drm-misc merge strategy makes this
OK. Specifically, when it's late in the linux cycle then drm-misc-next
is supposed to stop merging to linuxnext. Then, shortly after the
merge window closes, patches will start flowing again.
So basically your patches are landed and should even keep the same git
hashes when they eventually make it to Linux. They just won't land for
another release cycle of Linux.
Hope that makes sense!
-Doug
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-17 17:57 ` Doug Anderson
(?)
(?)
@ 2023-06-18 12:39 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 12:39 UTC (permalink / raw)
To: linux-aspeed
Hello Doug,
On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > [expanding recipents by the other affected persons]
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > from .remove() usually yields a resource leak.
> > > > >
> > > > > By changing the remove callback to return void driver authors cannot
> > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > cleanup later.
> > > >
> > > > I wonder if someone would volunteer to add the whole series to
> > > > drm-misc-next?!
> > >
> > > It looks as if Neil applied quite a few of them already, so I looked
> > > at what was left...
> > >
> > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > and it would be better if they landed there. ...so I went through all
> > > the patches that still applied to drm-misc-next, then used
> > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > through drm-misc. That still left quite a few patches. I've applied
> > > those ones and pushed to drm-misc-next:
> > >
> > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > callback returning void
> > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >
> > Together with the patches that were applied later the topmost commit
> > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > callback returning void"). This commit was part for the following next
> > tags:
> >
> > $ git tag -l --contains c2807ecb5290
> > next-20230609
> > next-20230613
> > next-20230614
> > next-20230615
> >
> > However in next-20230616 they are missing. In next-20230616
> > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > also not included with a different commit id). The 37 patches dropped
> > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> >
> > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > 1 Christophe JAILLET
> > 2 Jessica Zhang
> > 5 Karol Wachowski
> > 1 Laura Nao
> > 27 Uwe Kleine-K?nig
> > 1 Wang Jianzheng
> >
> >
> > I guess this was done by mistake because nobody told me about dropping
> > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > again?
>
> Actually, it was probably a mistake that these patches got merged to
> linuxnext during the 4 days that you noticed. However, your patches
> aren't dropped and are still present in drm-misc-next.
>
> drm-misc has a bit of a unique model and it's documented fairly well here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
Is there a flaw then in this unique model (or its implementation) when
drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
expected, is it?
> The key is that committers can commit to drm-misc-next _at any time_
> regardless of the merge window. The drm-misc merge strategy makes this
> OK. Specifically, when it's late in the linux cycle then drm-misc-next
> is supposed to stop merging to linuxnext. Then, shortly after the
> merge window closes, patches will start flowing again.
>
> So basically your patches are landed and should even keep the same git
> hashes when they eventually make it to Linux. They just won't land for
> another release cycle of Linux.
OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
understand the whole model, the patches at least seem to be scheduled to
go in during the next merge window.
> Hope that makes sense!
I hope so, too :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/8e58e238/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 12:39 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 12:39 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Alexandre Belloni, Akhil P Oommen, dri-devel,
Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Karol Herbst, Samuel Holland,
Kevin Hilman, Maíra Canal, Michal Simek, Kuogee Hsieh,
Xinliang Liu, Danilo Krummrich, NXP Linux Team, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Alain Volmat, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Miaoqian Lin, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Jonathan Hunter,
linux-rockchip, Ben Skeggs, Russell King, Jessica Zhang, Liu Ying,
linux-arm-msm, Wang Jianzheng, Maxime Ripard, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin, linux-mediatek,
Kuninori Morimoto, Yuan Can, Javier Martinez Canillas,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Maxime Ripard, Baolin Wang, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32,
Emma Anholt, Liviu Dudau, Alexandre Torgue, linux-mips,
Paul Cercueil, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, Christophe JAILLET, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov,
Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 6727 bytes --]
Hello Doug,
On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > [expanding recipents by the other affected persons]
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > from .remove() usually yields a resource leak.
> > > > >
> > > > > By changing the remove callback to return void driver authors cannot
> > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > cleanup later.
> > > >
> > > > I wonder if someone would volunteer to add the whole series to
> > > > drm-misc-next?!
> > >
> > > It looks as if Neil applied quite a few of them already, so I looked
> > > at what was left...
> > >
> > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > and it would be better if they landed there. ...so I went through all
> > > the patches that still applied to drm-misc-next, then used
> > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > through drm-misc. That still left quite a few patches. I've applied
> > > those ones and pushed to drm-misc-next:
> > >
> > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > callback returning void
> > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >
> > Together with the patches that were applied later the topmost commit
> > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > callback returning void"). This commit was part for the following next
> > tags:
> >
> > $ git tag -l --contains c2807ecb5290
> > next-20230609
> > next-20230613
> > next-20230614
> > next-20230615
> >
> > However in next-20230616 they are missing. In next-20230616
> > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > also not included with a different commit id). The 37 patches dropped
> > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> >
> > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > 1 Christophe JAILLET
> > 2 Jessica Zhang
> > 5 Karol Wachowski
> > 1 Laura Nao
> > 27 Uwe Kleine-König
> > 1 Wang Jianzheng
> >
> >
> > I guess this was done by mistake because nobody told me about dropping
> > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > again?
>
> Actually, it was probably a mistake that these patches got merged to
> linuxnext during the 4 days that you noticed. However, your patches
> aren't dropped and are still present in drm-misc-next.
>
> drm-misc has a bit of a unique model and it's documented fairly well here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
Is there a flaw then in this unique model (or its implementation) when
drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
expected, is it?
> The key is that committers can commit to drm-misc-next _at any time_
> regardless of the merge window. The drm-misc merge strategy makes this
> OK. Specifically, when it's late in the linux cycle then drm-misc-next
> is supposed to stop merging to linuxnext. Then, shortly after the
> merge window closes, patches will start flowing again.
>
> So basically your patches are landed and should even keep the same git
> hashes when they eventually make it to Linux. They just won't land for
> another release cycle of Linux.
OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
understand the whole model, the patches at least seem to be scheduled to
go in during the next merge window.
> Hope that makes sense!
I hope so, too :-)
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] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 12:39 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 12:39 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Heiko Stübner, Alexandre Belloni,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Samuel Holland, Kevin Hilman, Maíra Canal, Michal Simek,
Kuogee Hsieh, Xinliang Liu, NXP Linux Team, linux-sunxi,
Rob Clark, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae, Alain Volmat,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Miaoqian Lin, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, linux-rockchip, Ben Skeggs,
Russell King, Jessica Zhang, Liu Ying, linux-arm-msm,
Wang Jianzheng, Maxime Ripard, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, linux-mediatek, Brian Starkey,
Kuninori Morimoto, Yuan Can, Stefan Agner,
Javier Martinez Canillas, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Christian Gmeiner,
Mark Brown, Maxime Ripard, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32,
Emma Anholt, Liviu Dudau, Alexandre Torgue, linux-mips,
Paul Cercueil, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Philippe Cornu, Melissa Wen,
Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 6727 bytes --]
Hello Doug,
On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > [expanding recipents by the other affected persons]
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > from .remove() usually yields a resource leak.
> > > > >
> > > > > By changing the remove callback to return void driver authors cannot
> > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > cleanup later.
> > > >
> > > > I wonder if someone would volunteer to add the whole series to
> > > > drm-misc-next?!
> > >
> > > It looks as if Neil applied quite a few of them already, so I looked
> > > at what was left...
> > >
> > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > and it would be better if they landed there. ...so I went through all
> > > the patches that still applied to drm-misc-next, then used
> > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > through drm-misc. That still left quite a few patches. I've applied
> > > those ones and pushed to drm-misc-next:
> > >
> > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > callback returning void
> > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >
> > Together with the patches that were applied later the topmost commit
> > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > callback returning void"). This commit was part for the following next
> > tags:
> >
> > $ git tag -l --contains c2807ecb5290
> > next-20230609
> > next-20230613
> > next-20230614
> > next-20230615
> >
> > However in next-20230616 they are missing. In next-20230616
> > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > also not included with a different commit id). The 37 patches dropped
> > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> >
> > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > 1 Christophe JAILLET
> > 2 Jessica Zhang
> > 5 Karol Wachowski
> > 1 Laura Nao
> > 27 Uwe Kleine-König
> > 1 Wang Jianzheng
> >
> >
> > I guess this was done by mistake because nobody told me about dropping
> > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > again?
>
> Actually, it was probably a mistake that these patches got merged to
> linuxnext during the 4 days that you noticed. However, your patches
> aren't dropped and are still present in drm-misc-next.
>
> drm-misc has a bit of a unique model and it's documented fairly well here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
Is there a flaw then in this unique model (or its implementation) when
drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
expected, is it?
> The key is that committers can commit to drm-misc-next _at any time_
> regardless of the merge window. The drm-misc merge strategy makes this
> OK. Specifically, when it's late in the linux cycle then drm-misc-next
> is supposed to stop merging to linuxnext. Then, shortly after the
> merge window closes, patches will start flowing again.
>
> So basically your patches are landed and should even keep the same git
> hashes when they eventually make it to Linux. They just won't land for
> another release cycle of Linux.
OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
understand the whole model, the patches at least seem to be scheduled to
go in during the next merge window.
> Hope that makes sense!
I hope so, too :-)
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] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 12:39 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 12:39 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Heiko Stübner, Xinliang Liu, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Jonathan Hunter, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Kuninori Morimoto, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Akhil P Oommen, Danilo Krummrich, NXP Linux Team,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Yuan Can, Inki Dae, Jessica Zhang,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Miaoqian Lin, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Steven Price, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Wang Jianzheng, Maxime Ripard, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Brian Starkey,
Karol Herbst, Alexandre Belloni, Stefan Agner, Michal Simek,
Matthias Brugger, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Philipp Zabel, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Nicolas Ferre, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, David Airlie, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
Stephen Boyd, AngeloGioacchino Del Regno, Yannick Fertre,
linux-mips, Rob Clark, Philippe Cornu, Daniel Vetter,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 6727 bytes --]
Hello Doug,
On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > [expanding recipents by the other affected persons]
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > from .remove() usually yields a resource leak.
> > > > >
> > > > > By changing the remove callback to return void driver authors cannot
> > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > cleanup later.
> > > >
> > > > I wonder if someone would volunteer to add the whole series to
> > > > drm-misc-next?!
> > >
> > > It looks as if Neil applied quite a few of them already, so I looked
> > > at what was left...
> > >
> > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > and it would be better if they landed there. ...so I went through all
> > > the patches that still applied to drm-misc-next, then used
> > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > through drm-misc. That still left quite a few patches. I've applied
> > > those ones and pushed to drm-misc-next:
> > >
> > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > callback returning void
> > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >
> > Together with the patches that were applied later the topmost commit
> > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > callback returning void"). This commit was part for the following next
> > tags:
> >
> > $ git tag -l --contains c2807ecb5290
> > next-20230609
> > next-20230613
> > next-20230614
> > next-20230615
> >
> > However in next-20230616 they are missing. In next-20230616
> > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > also not included with a different commit id). The 37 patches dropped
> > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> >
> > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > 1 Christophe JAILLET
> > 2 Jessica Zhang
> > 5 Karol Wachowski
> > 1 Laura Nao
> > 27 Uwe Kleine-König
> > 1 Wang Jianzheng
> >
> >
> > I guess this was done by mistake because nobody told me about dropping
> > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > again?
>
> Actually, it was probably a mistake that these patches got merged to
> linuxnext during the 4 days that you noticed. However, your patches
> aren't dropped and are still present in drm-misc-next.
>
> drm-misc has a bit of a unique model and it's documented fairly well here:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
Is there a flaw then in this unique model (or its implementation) when
drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
expected, is it?
> The key is that committers can commit to drm-misc-next _at any time_
> regardless of the merge window. The drm-misc merge strategy makes this
> OK. Specifically, when it's late in the linux cycle then drm-misc-next
> is supposed to stop merging to linuxnext. Then, shortly after the
> merge window closes, patches will start flowing again.
>
> So basically your patches are landed and should even keep the same git
> hashes when they eventually make it to Linux. They just won't land for
> another release cycle of Linux.
OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
understand the whole model, the patches at least seem to be scheduled to
go in during the next merge window.
> Hope that makes sense!
I hope so, too :-)
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] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-18 12:39 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-18 14:02 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 14:02 UTC (permalink / raw)
To: linux-aspeed
Hello again,
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
FTR, I checked historic next trees to find other trees where
for-linux-next were moved in a non-fast-forward manner[1]. I found:
$ git for-each-ref --format='%(refname)' refs/tags/next-* | while read n; do hn=$(git show $n:Next/SHA1s 2>/dev/null | awk '$1 == "drm-misc" { print $2 }'); if test -z "$hn"; then continue; fi; if test -n "$prevhn" && ! git merge-base --is-ancestor "$prevhn" "$hn"; then if git merge-base --is-ancestor "$hn" linus/master; then merged=x; else merged="-"; fi; echo "$n ($prevhn -> $hn) [$merged]"; fi; prevhn=$hn; done
refs/tags/next-20151231 (e8b4855b5dd3e285d0ec18ed15468025abc1be9a -> e112e593b215c394c0303dbf0534db0928e87967) [x]
refs/tags/next-20160212 (e24bfdd5052ca65e99fb835838da9d64b36ddc88 -> 382ab95d1af85381d8a5dff09b16a80c7e492534) [x]
refs/tags/next-20170613 (18e51064c42ca3945b94dd4652156b62457962bc -> 2d7b56378d32b0cf006f8944cbba4046df45dd25) [x]
refs/tags/next-20180406 (3ae7fb202d86b7847f237daa474f3946bdc3b0c6 -> 41613a1a7df27a0aa34bf77d51278bbe8e108a8f) [x]
refs/tags/next-20180517 (3131f209468d1514af378dd46eb34123d0af84ff -> 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4) [x]
refs/tags/next-20190320 (e552f0851070fe4975d610a99910be4e9bf5d7bd -> 29054230f3e11ea818eccfa7bb4e4b3e89544164) [x]
refs/tags/next-20190617 (9f9b25593ab4197318e3621201588ad8cd525c9b -> b1622cb3be4557fd086831ca7426eafe5f1acc2e) [x]
refs/tags/next-20190723 (7aaddd96d5febcf5b24357a326b3038d49a20532 -> d808097627e51d53cf9b1aa13239b5c4a6adaefb) [x]
refs/tags/next-20190829 (66c2dee4ae10a2d841c40b9dd9c7141eb23eee76 -> 578d2342ec702e5fb8a77983fabb3754ae3e9660) [x]
refs/tags/next-20191004 (d7d44b6fe40a98e960be92ea8617954c2596d140 -> 4092de1ba34eb376791809fb366bc15f8a9e0b7c) [x]
refs/tags/next-20191106 (8a537de0f3d8b655cb901c948ed863bf0b23277b -> cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d) [x]
refs/tags/next-20191216 (0a5239985a3bc084738851afdf3fceb7d5651b0c -> d4e6a62d3769ef09bfe116b261a61ef871dea4f9) [x]
refs/tags/next-20200123 (73896f60d4865657740c64821a7b18825a9bf96c -> db735fc4036bbe1fbe606819b5f0ff26cc76cdff) [x]
refs/tags/next-20200415 (152cce0006abf7e17dfb7dc94896b044bda4e588 -> 74aae1c42f4a7f69934762f9e9f90a3ec335fef2) [x]
refs/tags/next-20200521 (5bebaeadb30e8d1ed694bd9b63d4e424d333fe36 -> 0df3ff451287d71c620384eb7bb2cd3a8106412c) [x]
refs/tags/next-20200617 (291ddeb621e4a9f1ced8302a777fbd7fbda058c6 -> cfe28f909ddd6ca854568870a7a9b46454e52b6f) [x]
refs/tags/next-20200724 (9fadd6d1e2977bbd449d4fb99cde41ed6f71f668 -> 206739119508d5ab4b42ab480ff61a7e6cd72d7c) [x]
refs/tags/next-20200924 (ad44c03208e46b83e4ae3269e32c9e524aa71cf8 -> de194561359788871f7d8f5f7797557a2a166b4e) [x]
refs/tags/next-20201027 (2580a493a97da4a302cb66251b558bfc04c16e68 -> 70bb9193728627e84e02eb0960b0aa138ae2cef5) [x]
refs/tags/next-20201214 (c365d304d69ab2a38e1431323d17a216b7930e32 -> 05faf1559de52465f1e753e31883aa294e6179c1) [x]
refs/tags/next-20210211 (5ceeb328637a01e0e54e2618cff129c6a1c31dba -> e2183fb135a7f62d317aa1c61eb3d1919080edba) [x]
refs/tags/next-20210319 (5fd3de7a51855e086d9ce9d2d752489e9c15b850 -> 4cf1d8719aab0ad89690abb1d37ecf4552778420) [x]
refs/tags/next-20210409 (167b400217121338a2beb78e09e2c77bd95491f5 -> 9c0fed84d5750e1eea6c664e073ffa2534a17743) [x]
refs/tags/next-20210615 (a3a5f9d0fb15da90820254ba735491887cc12099 -> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2) [x]
refs/tags/next-20210714 (34bd46bcf3de72cbffcdc42d3fa67e543d1c869b -> 35d283658a6196b2057be562096610c6793e1219) [x]
refs/tags/next-20210715 (35d283658a6196b2057be562096610c6793e1219 -> 85fd4a8a84316166640102676a356755ddec80e0) [-]
refs/tags/next-20210726 (85fd4a8a84316166640102676a356755ddec80e0 -> 03b7c552d081b73ba814eefc257c704b4d096d93) [x]
refs/tags/next-20210727 (03b7c552d081b73ba814eefc257c704b4d096d93 -> 87360168759879d68550b0c052bbcc2a0339ff74) [-]
refs/tags/next-20210817 (87360168759879d68550b0c052bbcc2a0339ff74 -> 80cbd8808f85017b8aff4b223db68926b470be12) [x]
refs/tags/next-20211101 (2b3374306b315be02db0f67d3102a0d1e1357270 -> b3ec8cdf457e5e63d396fe1346cc788cf7c1b578) [x]
refs/tags/next-20211117 (bcae3af286f49bf4f6cda03f165fbe530f4a6bed -> a193f3b4e050e35c506a34d0870c838d8e0b0449) [x]
refs/tags/next-20211217 (43d5ac7d07023cd133b978de473b3400edad941f -> d6c75c295f67b26fad8ba2e72db80e0f744e9da9) [x]
refs/tags/next-20220317 (07f380da3ebd8d84fc866ccf83d93c667fcaaeaa -> f6d790e5a7fe42706756c7fa1686d08d230610fc) [x]
refs/tags/next-20220406 (67bae5f28c895f8737a1974c3f31cf12b9170b14 -> 21d139a95682c6ade89a2151e44012c9797c0309) [x]
refs/tags/next-20220513 (aebeb02dfccb61d6930112aede2db3db5b8e974e -> 6071c4c2a319da360b0bf2bc397d4fefad10b2c8) [x]
refs/tags/next-20220610 (5ee8c8f930ba7d20717c4fc2d9f1ce0e757d1155 -> efeeaefe9be56e8ae5e5b4e9ff6d2275ec977ec5) [x]
refs/tags/next-20220715 (887ddf3251928dc39bfc58c5c62083d38a633c14 -> c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2) [x]
refs/tags/next-20220818 (2939deac1fa220bc82b89235f146df1d9b52e876 -> 8ba9249396bef37cb68be9e8dee7847f1737db9d) [x]
refs/tags/next-20221007 (fdd0640b639070efb58226c96cea5861150e8dce -> 39dd0cc2e5bd0d5188dd69f27e18783cea7ff06a) [x]
refs/tags/next-20221122 (e3ddd2d25533d1cc6f9fea421e4a5f16b60b3434 -> 29583dfcd2dd72c766422bd05c16f06c6b1fb356) [x]
refs/tags/next-20230106 (03dec92c4f788c54a7c01b40a018f601eb8a6c52 -> 4c00ac500d0edd1a6730c4e8293834a694c1b304) [x]
refs/tags/next-20230201 (d023d6f741c85bb00d2ca43d338327fbc150c113 -> aebd8f0c6f8280ba35bc989f4a9ea47469d3589a) [x]
refs/tags/next-20230616 (c2807ecb529004ea6f2c2be823c495dc8491e205 -> cf683e8870bd4be0fd6b98639286700a35088660) [-]
so up to now it happend only three times (i.e. the lines with [-]) that
drm-misc/for-linux-next changed in a non-ff way and the commit wasn't
included later in the mainline (and for refs/tags/next-20230616 we
assume this will change to [x] during the next merge window)
So it seems to happen every few weeks ...
Best regards
Uwe
[1] My collection of historic next tags is incomplete, so there might be
more.
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/bf6174b7/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 14:02 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 14:02 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Michal Simek, Kuogee Hsieh, Xinliang Liu, Danilo Krummrich,
NXP Linux Team, linux-sunxi, Rahul T R, Raphael Gallais-Pou,
Jani Nikula, Sascha Hauer, etnaviv, Yuan Can, Jessica Zhang,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi,
Steven Price, linux-rockchip, Ben Skeggs, Russell King,
Alain Volmat, Liu Ying, linux-arm-msm, Wang Jianzheng,
Maxime Ripard, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, Christophe JAILLET, Karol Herbst, Miaoqian Lin,
Javier Martinez Canillas, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown,
Maxime Ripard, Baolin Wang, Paul Cercueil, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Bjorn Andersson, linux-stm32, Emma Anholt,
Konrad Dybcio, Alexandre Torgue, Nicolas Ferre, Liu Shixin,
Krzysztof Kozlowski, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 6794 bytes --]
Hello again,
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
FTR, I checked historic next trees to find other trees where
for-linux-next were moved in a non-fast-forward manner[1]. I found:
$ git for-each-ref --format='%(refname)' refs/tags/next-* | while read n; do hn=$(git show $n:Next/SHA1s 2>/dev/null | awk '$1 == "drm-misc" { print $2 }'); if test -z "$hn"; then continue; fi; if test -n "$prevhn" && ! git merge-base --is-ancestor "$prevhn" "$hn"; then if git merge-base --is-ancestor "$hn" linus/master; then merged=x; else merged="-"; fi; echo "$n ($prevhn -> $hn) [$merged]"; fi; prevhn=$hn; done
refs/tags/next-20151231 (e8b4855b5dd3e285d0ec18ed15468025abc1be9a -> e112e593b215c394c0303dbf0534db0928e87967) [x]
refs/tags/next-20160212 (e24bfdd5052ca65e99fb835838da9d64b36ddc88 -> 382ab95d1af85381d8a5dff09b16a80c7e492534) [x]
refs/tags/next-20170613 (18e51064c42ca3945b94dd4652156b62457962bc -> 2d7b56378d32b0cf006f8944cbba4046df45dd25) [x]
refs/tags/next-20180406 (3ae7fb202d86b7847f237daa474f3946bdc3b0c6 -> 41613a1a7df27a0aa34bf77d51278bbe8e108a8f) [x]
refs/tags/next-20180517 (3131f209468d1514af378dd46eb34123d0af84ff -> 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4) [x]
refs/tags/next-20190320 (e552f0851070fe4975d610a99910be4e9bf5d7bd -> 29054230f3e11ea818eccfa7bb4e4b3e89544164) [x]
refs/tags/next-20190617 (9f9b25593ab4197318e3621201588ad8cd525c9b -> b1622cb3be4557fd086831ca7426eafe5f1acc2e) [x]
refs/tags/next-20190723 (7aaddd96d5febcf5b24357a326b3038d49a20532 -> d808097627e51d53cf9b1aa13239b5c4a6adaefb) [x]
refs/tags/next-20190829 (66c2dee4ae10a2d841c40b9dd9c7141eb23eee76 -> 578d2342ec702e5fb8a77983fabb3754ae3e9660) [x]
refs/tags/next-20191004 (d7d44b6fe40a98e960be92ea8617954c2596d140 -> 4092de1ba34eb376791809fb366bc15f8a9e0b7c) [x]
refs/tags/next-20191106 (8a537de0f3d8b655cb901c948ed863bf0b23277b -> cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d) [x]
refs/tags/next-20191216 (0a5239985a3bc084738851afdf3fceb7d5651b0c -> d4e6a62d3769ef09bfe116b261a61ef871dea4f9) [x]
refs/tags/next-20200123 (73896f60d4865657740c64821a7b18825a9bf96c -> db735fc4036bbe1fbe606819b5f0ff26cc76cdff) [x]
refs/tags/next-20200415 (152cce0006abf7e17dfb7dc94896b044bda4e588 -> 74aae1c42f4a7f69934762f9e9f90a3ec335fef2) [x]
refs/tags/next-20200521 (5bebaeadb30e8d1ed694bd9b63d4e424d333fe36 -> 0df3ff451287d71c620384eb7bb2cd3a8106412c) [x]
refs/tags/next-20200617 (291ddeb621e4a9f1ced8302a777fbd7fbda058c6 -> cfe28f909ddd6ca854568870a7a9b46454e52b6f) [x]
refs/tags/next-20200724 (9fadd6d1e2977bbd449d4fb99cde41ed6f71f668 -> 206739119508d5ab4b42ab480ff61a7e6cd72d7c) [x]
refs/tags/next-20200924 (ad44c03208e46b83e4ae3269e32c9e524aa71cf8 -> de194561359788871f7d8f5f7797557a2a166b4e) [x]
refs/tags/next-20201027 (2580a493a97da4a302cb66251b558bfc04c16e68 -> 70bb9193728627e84e02eb0960b0aa138ae2cef5) [x]
refs/tags/next-20201214 (c365d304d69ab2a38e1431323d17a216b7930e32 -> 05faf1559de52465f1e753e31883aa294e6179c1) [x]
refs/tags/next-20210211 (5ceeb328637a01e0e54e2618cff129c6a1c31dba -> e2183fb135a7f62d317aa1c61eb3d1919080edba) [x]
refs/tags/next-20210319 (5fd3de7a51855e086d9ce9d2d752489e9c15b850 -> 4cf1d8719aab0ad89690abb1d37ecf4552778420) [x]
refs/tags/next-20210409 (167b400217121338a2beb78e09e2c77bd95491f5 -> 9c0fed84d5750e1eea6c664e073ffa2534a17743) [x]
refs/tags/next-20210615 (a3a5f9d0fb15da90820254ba735491887cc12099 -> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2) [x]
refs/tags/next-20210714 (34bd46bcf3de72cbffcdc42d3fa67e543d1c869b -> 35d283658a6196b2057be562096610c6793e1219) [x]
refs/tags/next-20210715 (35d283658a6196b2057be562096610c6793e1219 -> 85fd4a8a84316166640102676a356755ddec80e0) [-]
refs/tags/next-20210726 (85fd4a8a84316166640102676a356755ddec80e0 -> 03b7c552d081b73ba814eefc257c704b4d096d93) [x]
refs/tags/next-20210727 (03b7c552d081b73ba814eefc257c704b4d096d93 -> 87360168759879d68550b0c052bbcc2a0339ff74) [-]
refs/tags/next-20210817 (87360168759879d68550b0c052bbcc2a0339ff74 -> 80cbd8808f85017b8aff4b223db68926b470be12) [x]
refs/tags/next-20211101 (2b3374306b315be02db0f67d3102a0d1e1357270 -> b3ec8cdf457e5e63d396fe1346cc788cf7c1b578) [x]
refs/tags/next-20211117 (bcae3af286f49bf4f6cda03f165fbe530f4a6bed -> a193f3b4e050e35c506a34d0870c838d8e0b0449) [x]
refs/tags/next-20211217 (43d5ac7d07023cd133b978de473b3400edad941f -> d6c75c295f67b26fad8ba2e72db80e0f744e9da9) [x]
refs/tags/next-20220317 (07f380da3ebd8d84fc866ccf83d93c667fcaaeaa -> f6d790e5a7fe42706756c7fa1686d08d230610fc) [x]
refs/tags/next-20220406 (67bae5f28c895f8737a1974c3f31cf12b9170b14 -> 21d139a95682c6ade89a2151e44012c9797c0309) [x]
refs/tags/next-20220513 (aebeb02dfccb61d6930112aede2db3db5b8e974e -> 6071c4c2a319da360b0bf2bc397d4fefad10b2c8) [x]
refs/tags/next-20220610 (5ee8c8f930ba7d20717c4fc2d9f1ce0e757d1155 -> efeeaefe9be56e8ae5e5b4e9ff6d2275ec977ec5) [x]
refs/tags/next-20220715 (887ddf3251928dc39bfc58c5c62083d38a633c14 -> c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2) [x]
refs/tags/next-20220818 (2939deac1fa220bc82b89235f146df1d9b52e876 -> 8ba9249396bef37cb68be9e8dee7847f1737db9d) [x]
refs/tags/next-20221007 (fdd0640b639070efb58226c96cea5861150e8dce -> 39dd0cc2e5bd0d5188dd69f27e18783cea7ff06a) [x]
refs/tags/next-20221122 (e3ddd2d25533d1cc6f9fea421e4a5f16b60b3434 -> 29583dfcd2dd72c766422bd05c16f06c6b1fb356) [x]
refs/tags/next-20230106 (03dec92c4f788c54a7c01b40a018f601eb8a6c52 -> 4c00ac500d0edd1a6730c4e8293834a694c1b304) [x]
refs/tags/next-20230201 (d023d6f741c85bb00d2ca43d338327fbc150c113 -> aebd8f0c6f8280ba35bc989f4a9ea47469d3589a) [x]
refs/tags/next-20230616 (c2807ecb529004ea6f2c2be823c495dc8491e205 -> cf683e8870bd4be0fd6b98639286700a35088660) [-]
so up to now it happend only three times (i.e. the lines with [-]) that
drm-misc/for-linux-next changed in a non-ff way and the commit wasn't
included later in the mainline (and for refs/tags/next-20230616 we
assume this will change to [x] during the next merge window)
So it seems to happen every few weeks ...
Best regards
Uwe
[1] My collection of historic next tags is incomplete, so there might be
more.
--
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] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 14:02 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 14:02 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Michal Simek, Kuogee Hsieh, Xinliang Liu,
NXP Linux Team, linux-sunxi, Rahul T R, Raphael Gallais-Pou,
Jani Nikula, Sascha Hauer, etnaviv, Yuan Can, Inki Dae,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Wang Jianzheng, Maxime Ripard, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Miaoqian Lin, Stefan Agner,
Javier Martinez Canillas, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Nicolas Ferre, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 6794 bytes --]
Hello again,
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
FTR, I checked historic next trees to find other trees where
for-linux-next were moved in a non-fast-forward manner[1]. I found:
$ git for-each-ref --format='%(refname)' refs/tags/next-* | while read n; do hn=$(git show $n:Next/SHA1s 2>/dev/null | awk '$1 == "drm-misc" { print $2 }'); if test -z "$hn"; then continue; fi; if test -n "$prevhn" && ! git merge-base --is-ancestor "$prevhn" "$hn"; then if git merge-base --is-ancestor "$hn" linus/master; then merged=x; else merged="-"; fi; echo "$n ($prevhn -> $hn) [$merged]"; fi; prevhn=$hn; done
refs/tags/next-20151231 (e8b4855b5dd3e285d0ec18ed15468025abc1be9a -> e112e593b215c394c0303dbf0534db0928e87967) [x]
refs/tags/next-20160212 (e24bfdd5052ca65e99fb835838da9d64b36ddc88 -> 382ab95d1af85381d8a5dff09b16a80c7e492534) [x]
refs/tags/next-20170613 (18e51064c42ca3945b94dd4652156b62457962bc -> 2d7b56378d32b0cf006f8944cbba4046df45dd25) [x]
refs/tags/next-20180406 (3ae7fb202d86b7847f237daa474f3946bdc3b0c6 -> 41613a1a7df27a0aa34bf77d51278bbe8e108a8f) [x]
refs/tags/next-20180517 (3131f209468d1514af378dd46eb34123d0af84ff -> 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4) [x]
refs/tags/next-20190320 (e552f0851070fe4975d610a99910be4e9bf5d7bd -> 29054230f3e11ea818eccfa7bb4e4b3e89544164) [x]
refs/tags/next-20190617 (9f9b25593ab4197318e3621201588ad8cd525c9b -> b1622cb3be4557fd086831ca7426eafe5f1acc2e) [x]
refs/tags/next-20190723 (7aaddd96d5febcf5b24357a326b3038d49a20532 -> d808097627e51d53cf9b1aa13239b5c4a6adaefb) [x]
refs/tags/next-20190829 (66c2dee4ae10a2d841c40b9dd9c7141eb23eee76 -> 578d2342ec702e5fb8a77983fabb3754ae3e9660) [x]
refs/tags/next-20191004 (d7d44b6fe40a98e960be92ea8617954c2596d140 -> 4092de1ba34eb376791809fb366bc15f8a9e0b7c) [x]
refs/tags/next-20191106 (8a537de0f3d8b655cb901c948ed863bf0b23277b -> cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d) [x]
refs/tags/next-20191216 (0a5239985a3bc084738851afdf3fceb7d5651b0c -> d4e6a62d3769ef09bfe116b261a61ef871dea4f9) [x]
refs/tags/next-20200123 (73896f60d4865657740c64821a7b18825a9bf96c -> db735fc4036bbe1fbe606819b5f0ff26cc76cdff) [x]
refs/tags/next-20200415 (152cce0006abf7e17dfb7dc94896b044bda4e588 -> 74aae1c42f4a7f69934762f9e9f90a3ec335fef2) [x]
refs/tags/next-20200521 (5bebaeadb30e8d1ed694bd9b63d4e424d333fe36 -> 0df3ff451287d71c620384eb7bb2cd3a8106412c) [x]
refs/tags/next-20200617 (291ddeb621e4a9f1ced8302a777fbd7fbda058c6 -> cfe28f909ddd6ca854568870a7a9b46454e52b6f) [x]
refs/tags/next-20200724 (9fadd6d1e2977bbd449d4fb99cde41ed6f71f668 -> 206739119508d5ab4b42ab480ff61a7e6cd72d7c) [x]
refs/tags/next-20200924 (ad44c03208e46b83e4ae3269e32c9e524aa71cf8 -> de194561359788871f7d8f5f7797557a2a166b4e) [x]
refs/tags/next-20201027 (2580a493a97da4a302cb66251b558bfc04c16e68 -> 70bb9193728627e84e02eb0960b0aa138ae2cef5) [x]
refs/tags/next-20201214 (c365d304d69ab2a38e1431323d17a216b7930e32 -> 05faf1559de52465f1e753e31883aa294e6179c1) [x]
refs/tags/next-20210211 (5ceeb328637a01e0e54e2618cff129c6a1c31dba -> e2183fb135a7f62d317aa1c61eb3d1919080edba) [x]
refs/tags/next-20210319 (5fd3de7a51855e086d9ce9d2d752489e9c15b850 -> 4cf1d8719aab0ad89690abb1d37ecf4552778420) [x]
refs/tags/next-20210409 (167b400217121338a2beb78e09e2c77bd95491f5 -> 9c0fed84d5750e1eea6c664e073ffa2534a17743) [x]
refs/tags/next-20210615 (a3a5f9d0fb15da90820254ba735491887cc12099 -> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2) [x]
refs/tags/next-20210714 (34bd46bcf3de72cbffcdc42d3fa67e543d1c869b -> 35d283658a6196b2057be562096610c6793e1219) [x]
refs/tags/next-20210715 (35d283658a6196b2057be562096610c6793e1219 -> 85fd4a8a84316166640102676a356755ddec80e0) [-]
refs/tags/next-20210726 (85fd4a8a84316166640102676a356755ddec80e0 -> 03b7c552d081b73ba814eefc257c704b4d096d93) [x]
refs/tags/next-20210727 (03b7c552d081b73ba814eefc257c704b4d096d93 -> 87360168759879d68550b0c052bbcc2a0339ff74) [-]
refs/tags/next-20210817 (87360168759879d68550b0c052bbcc2a0339ff74 -> 80cbd8808f85017b8aff4b223db68926b470be12) [x]
refs/tags/next-20211101 (2b3374306b315be02db0f67d3102a0d1e1357270 -> b3ec8cdf457e5e63d396fe1346cc788cf7c1b578) [x]
refs/tags/next-20211117 (bcae3af286f49bf4f6cda03f165fbe530f4a6bed -> a193f3b4e050e35c506a34d0870c838d8e0b0449) [x]
refs/tags/next-20211217 (43d5ac7d07023cd133b978de473b3400edad941f -> d6c75c295f67b26fad8ba2e72db80e0f744e9da9) [x]
refs/tags/next-20220317 (07f380da3ebd8d84fc866ccf83d93c667fcaaeaa -> f6d790e5a7fe42706756c7fa1686d08d230610fc) [x]
refs/tags/next-20220406 (67bae5f28c895f8737a1974c3f31cf12b9170b14 -> 21d139a95682c6ade89a2151e44012c9797c0309) [x]
refs/tags/next-20220513 (aebeb02dfccb61d6930112aede2db3db5b8e974e -> 6071c4c2a319da360b0bf2bc397d4fefad10b2c8) [x]
refs/tags/next-20220610 (5ee8c8f930ba7d20717c4fc2d9f1ce0e757d1155 -> efeeaefe9be56e8ae5e5b4e9ff6d2275ec977ec5) [x]
refs/tags/next-20220715 (887ddf3251928dc39bfc58c5c62083d38a633c14 -> c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2) [x]
refs/tags/next-20220818 (2939deac1fa220bc82b89235f146df1d9b52e876 -> 8ba9249396bef37cb68be9e8dee7847f1737db9d) [x]
refs/tags/next-20221007 (fdd0640b639070efb58226c96cea5861150e8dce -> 39dd0cc2e5bd0d5188dd69f27e18783cea7ff06a) [x]
refs/tags/next-20221122 (e3ddd2d25533d1cc6f9fea421e4a5f16b60b3434 -> 29583dfcd2dd72c766422bd05c16f06c6b1fb356) [x]
refs/tags/next-20230106 (03dec92c4f788c54a7c01b40a018f601eb8a6c52 -> 4c00ac500d0edd1a6730c4e8293834a694c1b304) [x]
refs/tags/next-20230201 (d023d6f741c85bb00d2ca43d338327fbc150c113 -> aebd8f0c6f8280ba35bc989f4a9ea47469d3589a) [x]
refs/tags/next-20230616 (c2807ecb529004ea6f2c2be823c495dc8491e205 -> cf683e8870bd4be0fd6b98639286700a35088660) [-]
so up to now it happend only three times (i.e. the lines with [-]) that
drm-misc/for-linux-next changed in a non-ff way and the commit wasn't
included later in the mainline (and for refs/tags/next-20230616 we
assume this will change to [x] during the next merge window)
So it seems to happen every few weeks ...
Best regards
Uwe
[1] My collection of historic next tags is incomplete, so there might be
more.
--
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] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 14:02 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 14:02 UTC (permalink / raw)
To: Doug Anderson
Cc: Raymond Tan, Heiko Stübner, Alexandre Belloni,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Michal Simek, Kuogee Hsieh, Xinliang Liu, Danilo Krummrich,
NXP Linux Team, linux-sunxi, Rob Clark, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Inki Dae, Alain Volmat, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Miaoqian Lin, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, linux-rockchip, Ben Skeggs,
Russell King, Jessica Zhang, Liu Ying, linux-arm-msm,
Wang Jianzheng, Maxime Ripard, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, linux-mediatek, Brian Starkey,
Kuninori Morimoto, Yuan Can, Stefan Agner,
Javier Martinez Canillas, linux-tegra, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Chen-Yu Tsai,
Jernej Skrabec, Xinwei Kong, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Maxime Ripard, Baolin Wang,
Daniel Vetter, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Karol Wachowski, Kieran Bingham, Ricardo Ribalda, Tian Tao,
Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, linux-mips, Paul Cercueil, Laura Nao,
David Airlie, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 6794 bytes --]
Hello again,
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
FTR, I checked historic next trees to find other trees where
for-linux-next were moved in a non-fast-forward manner[1]. I found:
$ git for-each-ref --format='%(refname)' refs/tags/next-* | while read n; do hn=$(git show $n:Next/SHA1s 2>/dev/null | awk '$1 == "drm-misc" { print $2 }'); if test -z "$hn"; then continue; fi; if test -n "$prevhn" && ! git merge-base --is-ancestor "$prevhn" "$hn"; then if git merge-base --is-ancestor "$hn" linus/master; then merged=x; else merged="-"; fi; echo "$n ($prevhn -> $hn) [$merged]"; fi; prevhn=$hn; done
refs/tags/next-20151231 (e8b4855b5dd3e285d0ec18ed15468025abc1be9a -> e112e593b215c394c0303dbf0534db0928e87967) [x]
refs/tags/next-20160212 (e24bfdd5052ca65e99fb835838da9d64b36ddc88 -> 382ab95d1af85381d8a5dff09b16a80c7e492534) [x]
refs/tags/next-20170613 (18e51064c42ca3945b94dd4652156b62457962bc -> 2d7b56378d32b0cf006f8944cbba4046df45dd25) [x]
refs/tags/next-20180406 (3ae7fb202d86b7847f237daa474f3946bdc3b0c6 -> 41613a1a7df27a0aa34bf77d51278bbe8e108a8f) [x]
refs/tags/next-20180517 (3131f209468d1514af378dd46eb34123d0af84ff -> 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4) [x]
refs/tags/next-20190320 (e552f0851070fe4975d610a99910be4e9bf5d7bd -> 29054230f3e11ea818eccfa7bb4e4b3e89544164) [x]
refs/tags/next-20190617 (9f9b25593ab4197318e3621201588ad8cd525c9b -> b1622cb3be4557fd086831ca7426eafe5f1acc2e) [x]
refs/tags/next-20190723 (7aaddd96d5febcf5b24357a326b3038d49a20532 -> d808097627e51d53cf9b1aa13239b5c4a6adaefb) [x]
refs/tags/next-20190829 (66c2dee4ae10a2d841c40b9dd9c7141eb23eee76 -> 578d2342ec702e5fb8a77983fabb3754ae3e9660) [x]
refs/tags/next-20191004 (d7d44b6fe40a98e960be92ea8617954c2596d140 -> 4092de1ba34eb376791809fb366bc15f8a9e0b7c) [x]
refs/tags/next-20191106 (8a537de0f3d8b655cb901c948ed863bf0b23277b -> cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d) [x]
refs/tags/next-20191216 (0a5239985a3bc084738851afdf3fceb7d5651b0c -> d4e6a62d3769ef09bfe116b261a61ef871dea4f9) [x]
refs/tags/next-20200123 (73896f60d4865657740c64821a7b18825a9bf96c -> db735fc4036bbe1fbe606819b5f0ff26cc76cdff) [x]
refs/tags/next-20200415 (152cce0006abf7e17dfb7dc94896b044bda4e588 -> 74aae1c42f4a7f69934762f9e9f90a3ec335fef2) [x]
refs/tags/next-20200521 (5bebaeadb30e8d1ed694bd9b63d4e424d333fe36 -> 0df3ff451287d71c620384eb7bb2cd3a8106412c) [x]
refs/tags/next-20200617 (291ddeb621e4a9f1ced8302a777fbd7fbda058c6 -> cfe28f909ddd6ca854568870a7a9b46454e52b6f) [x]
refs/tags/next-20200724 (9fadd6d1e2977bbd449d4fb99cde41ed6f71f668 -> 206739119508d5ab4b42ab480ff61a7e6cd72d7c) [x]
refs/tags/next-20200924 (ad44c03208e46b83e4ae3269e32c9e524aa71cf8 -> de194561359788871f7d8f5f7797557a2a166b4e) [x]
refs/tags/next-20201027 (2580a493a97da4a302cb66251b558bfc04c16e68 -> 70bb9193728627e84e02eb0960b0aa138ae2cef5) [x]
refs/tags/next-20201214 (c365d304d69ab2a38e1431323d17a216b7930e32 -> 05faf1559de52465f1e753e31883aa294e6179c1) [x]
refs/tags/next-20210211 (5ceeb328637a01e0e54e2618cff129c6a1c31dba -> e2183fb135a7f62d317aa1c61eb3d1919080edba) [x]
refs/tags/next-20210319 (5fd3de7a51855e086d9ce9d2d752489e9c15b850 -> 4cf1d8719aab0ad89690abb1d37ecf4552778420) [x]
refs/tags/next-20210409 (167b400217121338a2beb78e09e2c77bd95491f5 -> 9c0fed84d5750e1eea6c664e073ffa2534a17743) [x]
refs/tags/next-20210615 (a3a5f9d0fb15da90820254ba735491887cc12099 -> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2) [x]
refs/tags/next-20210714 (34bd46bcf3de72cbffcdc42d3fa67e543d1c869b -> 35d283658a6196b2057be562096610c6793e1219) [x]
refs/tags/next-20210715 (35d283658a6196b2057be562096610c6793e1219 -> 85fd4a8a84316166640102676a356755ddec80e0) [-]
refs/tags/next-20210726 (85fd4a8a84316166640102676a356755ddec80e0 -> 03b7c552d081b73ba814eefc257c704b4d096d93) [x]
refs/tags/next-20210727 (03b7c552d081b73ba814eefc257c704b4d096d93 -> 87360168759879d68550b0c052bbcc2a0339ff74) [-]
refs/tags/next-20210817 (87360168759879d68550b0c052bbcc2a0339ff74 -> 80cbd8808f85017b8aff4b223db68926b470be12) [x]
refs/tags/next-20211101 (2b3374306b315be02db0f67d3102a0d1e1357270 -> b3ec8cdf457e5e63d396fe1346cc788cf7c1b578) [x]
refs/tags/next-20211117 (bcae3af286f49bf4f6cda03f165fbe530f4a6bed -> a193f3b4e050e35c506a34d0870c838d8e0b0449) [x]
refs/tags/next-20211217 (43d5ac7d07023cd133b978de473b3400edad941f -> d6c75c295f67b26fad8ba2e72db80e0f744e9da9) [x]
refs/tags/next-20220317 (07f380da3ebd8d84fc866ccf83d93c667fcaaeaa -> f6d790e5a7fe42706756c7fa1686d08d230610fc) [x]
refs/tags/next-20220406 (67bae5f28c895f8737a1974c3f31cf12b9170b14 -> 21d139a95682c6ade89a2151e44012c9797c0309) [x]
refs/tags/next-20220513 (aebeb02dfccb61d6930112aede2db3db5b8e974e -> 6071c4c2a319da360b0bf2bc397d4fefad10b2c8) [x]
refs/tags/next-20220610 (5ee8c8f930ba7d20717c4fc2d9f1ce0e757d1155 -> efeeaefe9be56e8ae5e5b4e9ff6d2275ec977ec5) [x]
refs/tags/next-20220715 (887ddf3251928dc39bfc58c5c62083d38a633c14 -> c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2) [x]
refs/tags/next-20220818 (2939deac1fa220bc82b89235f146df1d9b52e876 -> 8ba9249396bef37cb68be9e8dee7847f1737db9d) [x]
refs/tags/next-20221007 (fdd0640b639070efb58226c96cea5861150e8dce -> 39dd0cc2e5bd0d5188dd69f27e18783cea7ff06a) [x]
refs/tags/next-20221122 (e3ddd2d25533d1cc6f9fea421e4a5f16b60b3434 -> 29583dfcd2dd72c766422bd05c16f06c6b1fb356) [x]
refs/tags/next-20230106 (03dec92c4f788c54a7c01b40a018f601eb8a6c52 -> 4c00ac500d0edd1a6730c4e8293834a694c1b304) [x]
refs/tags/next-20230201 (d023d6f741c85bb00d2ca43d338327fbc150c113 -> aebd8f0c6f8280ba35bc989f4a9ea47469d3589a) [x]
refs/tags/next-20230616 (c2807ecb529004ea6f2c2be823c495dc8491e205 -> cf683e8870bd4be0fd6b98639286700a35088660) [-]
so up to now it happend only three times (i.e. the lines with [-]) that
drm-misc/for-linux-next changed in a non-ff way and the commit wasn't
included later in the mainline (and for refs/tags/next-20230616 we
assume this will change to [x] during the next merge window)
So it seems to happen every few weeks ...
Best regards
Uwe
[1] My collection of historic next tags is incomplete, so there might be
more.
--
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] 261+ messages in thread
* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-18 12:39 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-18 14:32 ` Maxime Ripard
-1 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-18 14:32 UTC (permalink / raw)
To: linux-aspeed
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> Hello Doug,
>
> On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > [expanding recipents by the other affected persons]
> > >
> > > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > > On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > > from .remove() usually yields a resource leak.
> > > > > >
> > > > > > By changing the remove callback to return void driver authors cannot
> > > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > > cleanup later.
> > > > >
> > > > > I wonder if someone would volunteer to add the whole series to
> > > > > drm-misc-next?!
> > > >
> > > > It looks as if Neil applied quite a few of them already, so I looked
> > > > at what was left...
> > > >
> > > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > > and it would be better if they landed there. ...so I went through all
> > > > the patches that still applied to drm-misc-next, then used
> > > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > > through drm-misc. That still left quite a few patches. I've applied
> > > > those ones and pushed to drm-misc-next:
> > > >
> > > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > > callback returning void
> > > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> > >
> > > Together with the patches that were applied later the topmost commit
> > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > callback returning void"). This commit was part for the following next
> > > tags:
> > >
> > > $ git tag -l --contains c2807ecb5290
> > > next-20230609
> > > next-20230613
> > > next-20230614
> > > next-20230615
> > >
> > > However in next-20230616 they are missing. In next-20230616
> > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > also not included with a different commit id). The 37 patches dropped
> > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > >
> > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > 1 Christophe JAILLET
> > > 2 Jessica Zhang
> > > 5 Karol Wachowski
> > > 1 Laura Nao
> > > 27 Uwe Kleine-K?nig
> > > 1 Wang Jianzheng
> > >
> > >
> > > I guess this was done by mistake because nobody told me about dropping
> > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > again?
> >
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
There's no expectation afaik. Any tree merged in linux-next can be
rebased, drop a patch, amend one, etc. without any concern.
It's also why linux-next is rebuilt entirely every day.
> > The key is that committers can commit to drm-misc-next _at any time_
> > regardless of the merge window. The drm-misc merge strategy makes this
> > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > is supposed to stop merging to linuxnext. Then, shortly after the
> > merge window closes, patches will start flowing again.
> >
> > So basically your patches are landed and should even keep the same git
> > hashes when they eventually make it to Linux. They just won't land for
> > another release cycle of Linux.
>
> OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> understand the whole model, the patches at least seem to be scheduled to
> go in during the next merge window.
It's not that complicated.
drm-misc-next is always open, and we start targeting release X + 2 when
X-rc6 is released.
This is due to Linus wanting all the commits sent as part of the PR in
linux-next for two weeks.
In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
is released, we remove drm-misc-next from the linux-next branch. All the
patches in drm-misc-next that were targetting X + 1 are in drm/next by
then, so it's not a concern.
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/0a6b8456/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 14:32 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-18 14:32 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Alexandre Belloni, Akhil P Oommen, dri-devel,
Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Karol Herbst, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Xinliang Liu, Danilo Krummrich, NXP Linux Team,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Alain Volmat, Sean Paul,
Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Miaoqian Lin, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi,
Jonathan Hunter, linux-rockchip, Ben Skeggs, Russell King,
Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Kuninori Morimoto, Yuan Can,
Michal Simek, linux-tegra, Laurent Pinchart, Andrzej Hajda,
Sam Ravnborg, Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui, Konrad Dybcio,
Alison Wang, Abhinav Kumar, Mark Brown, Baolin Wang, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32,
Emma Anholt, Liviu Dudau, Alexandre Torgue, Doug Anderson,
Paul Cercueil, Laura Nao, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Philippe Cornu, Thomas Zimmermann,
Melissa Wen, Christophe JAILLET, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov,
Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 7484 bytes --]
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> Hello Doug,
>
> On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > [expanding recipents by the other affected persons]
> > >
> > > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > > from .remove() usually yields a resource leak.
> > > > > >
> > > > > > By changing the remove callback to return void driver authors cannot
> > > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > > cleanup later.
> > > > >
> > > > > I wonder if someone would volunteer to add the whole series to
> > > > > drm-misc-next?!
> > > >
> > > > It looks as if Neil applied quite a few of them already, so I looked
> > > > at what was left...
> > > >
> > > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > > and it would be better if they landed there. ...so I went through all
> > > > the patches that still applied to drm-misc-next, then used
> > > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > > through drm-misc. That still left quite a few patches. I've applied
> > > > those ones and pushed to drm-misc-next:
> > > >
> > > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > > callback returning void
> > > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> > >
> > > Together with the patches that were applied later the topmost commit
> > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > callback returning void"). This commit was part for the following next
> > > tags:
> > >
> > > $ git tag -l --contains c2807ecb5290
> > > next-20230609
> > > next-20230613
> > > next-20230614
> > > next-20230615
> > >
> > > However in next-20230616 they are missing. In next-20230616
> > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > also not included with a different commit id). The 37 patches dropped
> > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > >
> > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > 1 Christophe JAILLET
> > > 2 Jessica Zhang
> > > 5 Karol Wachowski
> > > 1 Laura Nao
> > > 27 Uwe Kleine-König
> > > 1 Wang Jianzheng
> > >
> > >
> > > I guess this was done by mistake because nobody told me about dropping
> > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > again?
> >
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
There's no expectation afaik. Any tree merged in linux-next can be
rebased, drop a patch, amend one, etc. without any concern.
It's also why linux-next is rebuilt entirely every day.
> > The key is that committers can commit to drm-misc-next _at any time_
> > regardless of the merge window. The drm-misc merge strategy makes this
> > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > is supposed to stop merging to linuxnext. Then, shortly after the
> > merge window closes, patches will start flowing again.
> >
> > So basically your patches are landed and should even keep the same git
> > hashes when they eventually make it to Linux. They just won't land for
> > another release cycle of Linux.
>
> OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> understand the whole model, the patches at least seem to be scheduled to
> go in during the next merge window.
It's not that complicated.
drm-misc-next is always open, and we start targeting release X + 2 when
X-rc6 is released.
This is due to Linus wanting all the commits sent as part of the PR in
linux-next for two weeks.
In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
is released, we remove drm-misc-next from the linux-next branch. All the
patches in drm-misc-next that were targetting X + 1 are in drm/next by
then, so it's not a concern.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 14:32 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-18 14:32 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Alexandre Belloni,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
NXP Linux Team, linux-sunxi, Rob Clark, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Inki Dae, Alain Volmat, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Miaoqian Lin, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Daniel Vetter,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 7484 bytes --]
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> Hello Doug,
>
> On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > [expanding recipents by the other affected persons]
> > >
> > > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > > from .remove() usually yields a resource leak.
> > > > > >
> > > > > > By changing the remove callback to return void driver authors cannot
> > > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > > cleanup later.
> > > > >
> > > > > I wonder if someone would volunteer to add the whole series to
> > > > > drm-misc-next?!
> > > >
> > > > It looks as if Neil applied quite a few of them already, so I looked
> > > > at what was left...
> > > >
> > > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > > and it would be better if they landed there. ...so I went through all
> > > > the patches that still applied to drm-misc-next, then used
> > > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > > through drm-misc. That still left quite a few patches. I've applied
> > > > those ones and pushed to drm-misc-next:
> > > >
> > > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > > callback returning void
> > > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> > >
> > > Together with the patches that were applied later the topmost commit
> > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > callback returning void"). This commit was part for the following next
> > > tags:
> > >
> > > $ git tag -l --contains c2807ecb5290
> > > next-20230609
> > > next-20230613
> > > next-20230614
> > > next-20230615
> > >
> > > However in next-20230616 they are missing. In next-20230616
> > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > also not included with a different commit id). The 37 patches dropped
> > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > >
> > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > 1 Christophe JAILLET
> > > 2 Jessica Zhang
> > > 5 Karol Wachowski
> > > 1 Laura Nao
> > > 27 Uwe Kleine-König
> > > 1 Wang Jianzheng
> > >
> > >
> > > I guess this was done by mistake because nobody told me about dropping
> > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > again?
> >
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
There's no expectation afaik. Any tree merged in linux-next can be
rebased, drop a patch, amend one, etc. without any concern.
It's also why linux-next is rebuilt entirely every day.
> > The key is that committers can commit to drm-misc-next _at any time_
> > regardless of the merge window. The drm-misc merge strategy makes this
> > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > is supposed to stop merging to linuxnext. Then, shortly after the
> > merge window closes, patches will start flowing again.
> >
> > So basically your patches are landed and should even keep the same git
> > hashes when they eventually make it to Linux. They just won't land for
> > another release cycle of Linux.
>
> OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> understand the whole model, the patches at least seem to be scheduled to
> go in during the next merge window.
It's not that complicated.
drm-misc-next is always open, and we start targeting release X + 2 when
X-rc6 is released.
This is due to Linus wanting all the commits sent as part of the PR in
linux-next for two weeks.
In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
is released, we remove drm-misc-next from the linux-next branch. All the
patches in drm-misc-next that were targetting X + 1 are in drm/next by
then, so it's not a concern.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 14:32 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-18 14:32 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Doug Anderson, Raymond Tan, Heiko Stübner, Xinliang Liu,
Linus Walleij, dri-devel, Stanislaw Gruszka, Alim Akhtar,
Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter, Sumit Semwal,
Jerome Brunet, linux-samsung-soc, Robert Foss, Kuninori Morimoto,
Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Akhil P Oommen,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Brian Starkey,
Karol Herbst, Alexandre Belloni, Stefan Agner, Michal Simek,
Matthias Brugger, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Philipp Zabel, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Paul Cercueil,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Bjorn Andersson,
linux-stm32, Emma Anholt, Konrad Dybcio, Alexandre Torgue,
Nicolas Ferre, Liu Shixin, Krzysztof Kozlowski, Laura Nao,
David Airlie, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Fabio Estevam, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 7484 bytes --]
On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> Hello Doug,
>
> On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > [expanding recipents by the other affected persons]
> > >
> > > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > > On Thu, Jun 1, 2023 at 8:40 AM Uwe Kleine-König
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote:
> > > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > > from .remove() usually yields a resource leak.
> > > > > >
> > > > > > By changing the remove callback to return void driver authors cannot
> > > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > > cleanup later.
> > > > >
> > > > > I wonder if someone would volunteer to add the whole series to
> > > > > drm-misc-next?!
> > > >
> > > > It looks as if Neil applied quite a few of them already, so I looked
> > > > at what was left...
> > > >
> > > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > > and it would be better if they landed there. ...so I went through all
> > > > the patches that still applied to drm-misc-next, then used
> > > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > > through drm-misc. That still left quite a few patches. I've applied
> > > > those ones and pushed to drm-misc-next:
> > > >
> > > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > > callback returning void
> > > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> > >
> > > Together with the patches that were applied later the topmost commit
> > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > callback returning void"). This commit was part for the following next
> > > tags:
> > >
> > > $ git tag -l --contains c2807ecb5290
> > > next-20230609
> > > next-20230613
> > > next-20230614
> > > next-20230615
> > >
> > > However in next-20230616 they are missing. In next-20230616
> > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > also not included with a different commit id). The 37 patches dropped
> > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > >
> > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > 1 Christophe JAILLET
> > > 2 Jessica Zhang
> > > 5 Karol Wachowski
> > > 1 Laura Nao
> > > 27 Uwe Kleine-König
> > > 1 Wang Jianzheng
> > >
> > >
> > > I guess this was done by mistake because nobody told me about dropping
> > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > again?
> >
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> >
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> >
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
>
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?
There's no expectation afaik. Any tree merged in linux-next can be
rebased, drop a patch, amend one, etc. without any concern.
It's also why linux-next is rebuilt entirely every day.
> > The key is that committers can commit to drm-misc-next _at any time_
> > regardless of the merge window. The drm-misc merge strategy makes this
> > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > is supposed to stop merging to linuxnext. Then, shortly after the
> > merge window closes, patches will start flowing again.
> >
> > So basically your patches are landed and should even keep the same git
> > hashes when they eventually make it to Linux. They just won't land for
> > another release cycle of Linux.
>
> OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> understand the whole model, the patches at least seem to be scheduled to
> go in during the next merge window.
It's not that complicated.
drm-misc-next is always open, and we start targeting release X + 2 when
X-rc6 is released.
This is due to Linus wanting all the commits sent as part of the PR in
linux-next for two weeks.
In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
is released, we remove drm-misc-next from the linux-next branch. All the
patches in drm-misc-next that were targetting X + 1 are in drm/next by
then, so it's not a concern.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-18 14:32 ` Maxime Ripard
(?)
(?)
@ 2023-06-18 16:29 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 16:29 UTC (permalink / raw)
To: linux-aspeed
Hello Maxime,
On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > Together with the patches that were applied later the topmost commit
> > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > callback returning void"). This commit was part for the following next
> > > > tags:
> > > >
> > > > $ git tag -l --contains c2807ecb5290
> > > > next-20230609
> > > > next-20230613
> > > > next-20230614
> > > > next-20230615
> > > >
> > > > However in next-20230616 they are missing. In next-20230616
> > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > also not included with a different commit id). The 37 patches dropped
> > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > >
> > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > 1 Christophe JAILLET
> > > > 2 Jessica Zhang
> > > > 5 Karol Wachowski
> > > > 1 Laura Nao
> > > > 27 Uwe Kleine-K?nig
> > > > 1 Wang Jianzheng
> > > >
> > > >
> > > > I guess this was done by mistake because nobody told me about dropping
> > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > again?
> > >
> > > Actually, it was probably a mistake that these patches got merged to
> > > linuxnext during the 4 days that you noticed. However, your patches
> > > aren't dropped and are still present in drm-misc-next.
> > >
> > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > >
> > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> >
> > Is there a flaw then in this unique model (or its implementation) when
> > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > expected, is it?
>
> There's no expectation afaik. Any tree merged in linux-next can be
> rebased, drop a patch, amend one, etc. without any concern.
I agree that there are no rules broken for a tree that is included in
next and a maintainer is free to rewrite their tree independant of the
tree being included in next.
Still I think that shouldn't be used as an excuse. For me, if a
maintainer puts some patch into next that's a statement saying
(approximately) "I think this patch is fine and I intend to send it to
Linus during the next merge window.". So my expectation is that if a
patch is dropped again from next, there was a problem and it would be
fair if the maintainer tells the author/submitter about this problem and
that the patch was dropped.
So my concern is not about rule breaking, but about the strange signal
that is sent to contributors by including their work in next for some
time and then dropping it again without comment.
> It's also why linux-next is rebuilt entirely every day.
>
> > > The key is that committers can commit to drm-misc-next _at any time_
> > > regardless of the merge window. The drm-misc merge strategy makes this
> > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > merge window closes, patches will start flowing again.
> > >
> > > So basically your patches are landed and should even keep the same git
> > > hashes when they eventually make it to Linux. They just won't land for
> > > another release cycle of Linux.
> >
> > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > understand the whole model, the patches at least seem to be scheduled to
> > go in during the next merge window.
>
> It's not that complicated.
>
> drm-misc-next is always open, and we start targeting release X + 2 when
> X-rc6 is released.
>
> This is due to Linus wanting all the commits sent as part of the PR in
> linux-next for two weeks.
>
> In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> is released, we remove drm-misc-next from the linux-next branch. All the
> patches in drm-misc-next that were targetting X + 1 are in drm/next by
> then, so it's not a concern.
So if I were a maintainer of drm-misc, I'd want that no commit from
drm-misc-next migrates to next after -rc6.
Also note that the branch head in question (i.e. c2807ecb5290) was
included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
according to the rules you described c2807ecb5290 could have been
qualified to go into v6.5-rc1?!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/dcb798d2/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 16:29 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 16:29 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Karol Herbst,
Miaoqian Lin, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 5086 bytes --]
Hello Maxime,
On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > Together with the patches that were applied later the topmost commit
> > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > callback returning void"). This commit was part for the following next
> > > > tags:
> > > >
> > > > $ git tag -l --contains c2807ecb5290
> > > > next-20230609
> > > > next-20230613
> > > > next-20230614
> > > > next-20230615
> > > >
> > > > However in next-20230616 they are missing. In next-20230616
> > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > also not included with a different commit id). The 37 patches dropped
> > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > >
> > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > 1 Christophe JAILLET
> > > > 2 Jessica Zhang
> > > > 5 Karol Wachowski
> > > > 1 Laura Nao
> > > > 27 Uwe Kleine-König
> > > > 1 Wang Jianzheng
> > > >
> > > >
> > > > I guess this was done by mistake because nobody told me about dropping
> > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > again?
> > >
> > > Actually, it was probably a mistake that these patches got merged to
> > > linuxnext during the 4 days that you noticed. However, your patches
> > > aren't dropped and are still present in drm-misc-next.
> > >
> > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > >
> > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> >
> > Is there a flaw then in this unique model (or its implementation) when
> > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > expected, is it?
>
> There's no expectation afaik. Any tree merged in linux-next can be
> rebased, drop a patch, amend one, etc. without any concern.
I agree that there are no rules broken for a tree that is included in
next and a maintainer is free to rewrite their tree independant of the
tree being included in next.
Still I think that shouldn't be used as an excuse. For me, if a
maintainer puts some patch into next that's a statement saying
(approximately) "I think this patch is fine and I intend to send it to
Linus during the next merge window.". So my expectation is that if a
patch is dropped again from next, there was a problem and it would be
fair if the maintainer tells the author/submitter about this problem and
that the patch was dropped.
So my concern is not about rule breaking, but about the strange signal
that is sent to contributors by including their work in next for some
time and then dropping it again without comment.
> It's also why linux-next is rebuilt entirely every day.
>
> > > The key is that committers can commit to drm-misc-next _at any time_
> > > regardless of the merge window. The drm-misc merge strategy makes this
> > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > merge window closes, patches will start flowing again.
> > >
> > > So basically your patches are landed and should even keep the same git
> > > hashes when they eventually make it to Linux. They just won't land for
> > > another release cycle of Linux.
> >
> > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > understand the whole model, the patches at least seem to be scheduled to
> > go in during the next merge window.
>
> It's not that complicated.
>
> drm-misc-next is always open, and we start targeting release X + 2 when
> X-rc6 is released.
>
> This is due to Linus wanting all the commits sent as part of the PR in
> linux-next for two weeks.
>
> In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> is released, we remove drm-misc-next from the linux-next branch. All the
> patches in drm-misc-next that were targetting X + 1 are in drm/next by
> then, so it's not a concern.
So if I were a maintainer of drm-misc, I'd want that no commit from
drm-misc-next migrates to next after -rc6.
Also note that the branch head in question (i.e. c2807ecb5290) was
included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
according to the rules you described c2807ecb5290 could have been
qualified to go into v6.5-rc1?!
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] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 16:29 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 16:29 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Nicolas Ferre, Wang Jianzheng, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Miaoqian Lin, Stefan Agner,
Michal Simek, Matthias Brugger, Laurent Pinchart, Andrzej Hajda,
Sam Ravnborg, Rob Herring, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Paul Cercueil,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Bjorn Andersson,
linux-stm32, Emma Anholt, Konrad Dybcio, Alexandre Torgue,
Doug Anderson, Liu Shixin, Krzysztof Kozlowski, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Qiang Yu,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
linux-tegra, Stephen Boyd, AngeloGioacchino Del Regno,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Daniel Vetter, Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 5086 bytes --]
Hello Maxime,
On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > Together with the patches that were applied later the topmost commit
> > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > callback returning void"). This commit was part for the following next
> > > > tags:
> > > >
> > > > $ git tag -l --contains c2807ecb5290
> > > > next-20230609
> > > > next-20230613
> > > > next-20230614
> > > > next-20230615
> > > >
> > > > However in next-20230616 they are missing. In next-20230616
> > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > also not included with a different commit id). The 37 patches dropped
> > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > >
> > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > 1 Christophe JAILLET
> > > > 2 Jessica Zhang
> > > > 5 Karol Wachowski
> > > > 1 Laura Nao
> > > > 27 Uwe Kleine-König
> > > > 1 Wang Jianzheng
> > > >
> > > >
> > > > I guess this was done by mistake because nobody told me about dropping
> > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > again?
> > >
> > > Actually, it was probably a mistake that these patches got merged to
> > > linuxnext during the 4 days that you noticed. However, your patches
> > > aren't dropped and are still present in drm-misc-next.
> > >
> > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > >
> > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> >
> > Is there a flaw then in this unique model (or its implementation) when
> > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > expected, is it?
>
> There's no expectation afaik. Any tree merged in linux-next can be
> rebased, drop a patch, amend one, etc. without any concern.
I agree that there are no rules broken for a tree that is included in
next and a maintainer is free to rewrite their tree independant of the
tree being included in next.
Still I think that shouldn't be used as an excuse. For me, if a
maintainer puts some patch into next that's a statement saying
(approximately) "I think this patch is fine and I intend to send it to
Linus during the next merge window.". So my expectation is that if a
patch is dropped again from next, there was a problem and it would be
fair if the maintainer tells the author/submitter about this problem and
that the patch was dropped.
So my concern is not about rule breaking, but about the strange signal
that is sent to contributors by including their work in next for some
time and then dropping it again without comment.
> It's also why linux-next is rebuilt entirely every day.
>
> > > The key is that committers can commit to drm-misc-next _at any time_
> > > regardless of the merge window. The drm-misc merge strategy makes this
> > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > merge window closes, patches will start flowing again.
> > >
> > > So basically your patches are landed and should even keep the same git
> > > hashes when they eventually make it to Linux. They just won't land for
> > > another release cycle of Linux.
> >
> > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > understand the whole model, the patches at least seem to be scheduled to
> > go in during the next merge window.
>
> It's not that complicated.
>
> drm-misc-next is always open, and we start targeting release X + 2 when
> X-rc6 is released.
>
> This is due to Linus wanting all the commits sent as part of the PR in
> linux-next for two weeks.
>
> In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> is released, we remove drm-misc-next from the linux-next branch. All the
> patches in drm-misc-next that were targetting X + 1 are in drm/next by
> then, so it's not a concern.
So if I were a maintainer of drm-misc, I'd want that no commit from
drm-misc-next migrates to next after -rc6.
Also note that the branch head in question (i.e. c2807ecb5290) was
included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
according to the rules you described c2807ecb5290 could have been
qualified to go into v6.5-rc1?!
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] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-18 16:29 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-18 16:29 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Alexandre Belloni,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rob Clark,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Inki Dae, Alain Volmat, Sean Paul,
Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Miaoqian Lin, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
Ben Skeggs, Russell King, Jessica Zhang, linux-mips, Liu Ying,
linux-arm-msm, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, linux-mediatek, Brian Starkey,
Kuninori Morimoto, Yuan Can, Stefan Agner, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Lyude Paul, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Christian Gmeiner,
Mark Brown, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32,
Emma Anholt, Liviu Dudau, Alexandre Torgue, Doug Anderson,
Paul Cercueil, Laura Nao, David Airlie, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Russell King, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, Christophe JAILLET, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Philipp Zabel, Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 5086 bytes --]
Hello Maxime,
On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > Together with the patches that were applied later the topmost commit
> > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > callback returning void"). This commit was part for the following next
> > > > tags:
> > > >
> > > > $ git tag -l --contains c2807ecb5290
> > > > next-20230609
> > > > next-20230613
> > > > next-20230614
> > > > next-20230615
> > > >
> > > > However in next-20230616 they are missing. In next-20230616
> > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > also not included with a different commit id). The 37 patches dropped
> > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > >
> > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > 1 Christophe JAILLET
> > > > 2 Jessica Zhang
> > > > 5 Karol Wachowski
> > > > 1 Laura Nao
> > > > 27 Uwe Kleine-König
> > > > 1 Wang Jianzheng
> > > >
> > > >
> > > > I guess this was done by mistake because nobody told me about dropping
> > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > again?
> > >
> > > Actually, it was probably a mistake that these patches got merged to
> > > linuxnext during the 4 days that you noticed. However, your patches
> > > aren't dropped and are still present in drm-misc-next.
> > >
> > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > >
> > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> >
> > Is there a flaw then in this unique model (or its implementation) when
> > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > expected, is it?
>
> There's no expectation afaik. Any tree merged in linux-next can be
> rebased, drop a patch, amend one, etc. without any concern.
I agree that there are no rules broken for a tree that is included in
next and a maintainer is free to rewrite their tree independant of the
tree being included in next.
Still I think that shouldn't be used as an excuse. For me, if a
maintainer puts some patch into next that's a statement saying
(approximately) "I think this patch is fine and I intend to send it to
Linus during the next merge window.". So my expectation is that if a
patch is dropped again from next, there was a problem and it would be
fair if the maintainer tells the author/submitter about this problem and
that the patch was dropped.
So my concern is not about rule breaking, but about the strange signal
that is sent to contributors by including their work in next for some
time and then dropping it again without comment.
> It's also why linux-next is rebuilt entirely every day.
>
> > > The key is that committers can commit to drm-misc-next _at any time_
> > > regardless of the merge window. The drm-misc merge strategy makes this
> > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > merge window closes, patches will start flowing again.
> > >
> > > So basically your patches are landed and should even keep the same git
> > > hashes when they eventually make it to Linux. They just won't land for
> > > another release cycle of Linux.
> >
> > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > understand the whole model, the patches at least seem to be scheduled to
> > go in during the next merge window.
>
> It's not that complicated.
>
> drm-misc-next is always open, and we start targeting release X + 2 when
> X-rc6 is released.
>
> This is due to Linus wanting all the commits sent as part of the PR in
> linux-next for two weeks.
>
> In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> is released, we remove drm-misc-next from the linux-next branch. All the
> patches in drm-misc-next that were targetting X + 1 are in drm/next by
> then, so it's not a concern.
So if I were a maintainer of drm-misc, I'd want that no commit from
drm-misc-next migrates to next after -rc6.
Also note that the branch head in question (i.e. c2807ecb5290) was
included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
according to the rules you described c2807ecb5290 could have been
qualified to go into v6.5-rc1?!
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] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-18 16:29 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-19 9:45 ` Maxime Ripard
-1 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 9:45 UTC (permalink / raw)
To: linux-aspeed
On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> Hello Maxime,
>
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > Together with the patches that were applied later the topmost commit
> > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > callback returning void"). This commit was part for the following next
> > > > > tags:
> > > > >
> > > > > $ git tag -l --contains c2807ecb5290
> > > > > next-20230609
> > > > > next-20230613
> > > > > next-20230614
> > > > > next-20230615
> > > > >
> > > > > However in next-20230616 they are missing. In next-20230616
> > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > also not included with a different commit id). The 37 patches dropped
> > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > >
> > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > 1 Christophe JAILLET
> > > > > 2 Jessica Zhang
> > > > > 5 Karol Wachowski
> > > > > 1 Laura Nao
> > > > > 27 Uwe Kleine-K?nig
> > > > > 1 Wang Jianzheng
> > > > >
> > > > >
> > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > again?
> > > >
> > > > Actually, it was probably a mistake that these patches got merged to
> > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > aren't dropped and are still present in drm-misc-next.
> > > >
> > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > >
> > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > >
> > > Is there a flaw then in this unique model (or its implementation) when
> > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > expected, is it?
> >
> > There's no expectation afaik. Any tree merged in linux-next can be
> > rebased, drop a patch, amend one, etc. without any concern.
>
> I agree that there are no rules broken for a tree that is included in
> next and a maintainer is free to rewrite their tree independant of the
> tree being included in next.
>
> Still I think that shouldn't be used as an excuse.
As an excuse for what?
> For me, if a maintainer puts some patch into next that's a statement
> saying (approximately) "I think this patch is fine and I intend to
> send it to Linus during the next merge window.".
I mean, that's what we're saying and doing?
> So my expectation is that if a patch is dropped again from next, there
> was a problem and it would be fair if the maintainer tells the
> author/submitter about this problem and that the patch was dropped.
But it wasn't dropped, it's still very much to be sent to Linus during
the next merge window.
> So my concern is not about rule breaking, but about the strange signal
> that is sent to contributors by including their work in next for some
> time and then dropping it again without comment.
>
> > It's also why linux-next is rebuilt entirely every day.
> >
> > > > The key is that committers can commit to drm-misc-next _at any time_
> > > > regardless of the merge window. The drm-misc merge strategy makes this
> > > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > > merge window closes, patches will start flowing again.
> > > >
> > > > So basically your patches are landed and should even keep the same git
> > > > hashes when they eventually make it to Linux. They just won't land for
> > > > another release cycle of Linux.
> > >
> > > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > > understand the whole model, the patches at least seem to be scheduled to
> > > go in during the next merge window.
> >
> > It's not that complicated.
> >
> > drm-misc-next is always open, and we start targeting release X + 2 when
> > X-rc6 is released.
> >
> > This is due to Linus wanting all the commits sent as part of the PR in
> > linux-next for two weeks.
> >
> > In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> > is released, we remove drm-misc-next from the linux-next branch. All the
> > patches in drm-misc-next that were targetting X + 1 are in drm/next by
> > then, so it's not a concern.
>
> So if I were a maintainer of drm-misc, I'd want that no commit from
> drm-misc-next migrates to next after -rc6.
>
> Also note that the branch head in question (i.e. c2807ecb5290) was
> included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
> according to the rules you described c2807ecb5290 could have been
> qualified to go into v6.5-rc1?!
Yes, could have, but barely missed the last drm-misc-next PR we sent to
Dave that usually occurs on Thursday (8/6) so Dave can merge it on
Friday (9/6), the last working day before -rc6 was released.
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/63dca5ea/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 9:45 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 9:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Karol Herbst,
Miaoqian Lin, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 5567 bytes --]
On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > Together with the patches that were applied later the topmost commit
> > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > callback returning void"). This commit was part for the following next
> > > > > tags:
> > > > >
> > > > > $ git tag -l --contains c2807ecb5290
> > > > > next-20230609
> > > > > next-20230613
> > > > > next-20230614
> > > > > next-20230615
> > > > >
> > > > > However in next-20230616 they are missing. In next-20230616
> > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > also not included with a different commit id). The 37 patches dropped
> > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > >
> > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > 1 Christophe JAILLET
> > > > > 2 Jessica Zhang
> > > > > 5 Karol Wachowski
> > > > > 1 Laura Nao
> > > > > 27 Uwe Kleine-König
> > > > > 1 Wang Jianzheng
> > > > >
> > > > >
> > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > again?
> > > >
> > > > Actually, it was probably a mistake that these patches got merged to
> > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > aren't dropped and are still present in drm-misc-next.
> > > >
> > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > >
> > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > >
> > > Is there a flaw then in this unique model (or its implementation) when
> > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > expected, is it?
> >
> > There's no expectation afaik. Any tree merged in linux-next can be
> > rebased, drop a patch, amend one, etc. without any concern.
>
> I agree that there are no rules broken for a tree that is included in
> next and a maintainer is free to rewrite their tree independant of the
> tree being included in next.
>
> Still I think that shouldn't be used as an excuse.
As an excuse for what?
> For me, if a maintainer puts some patch into next that's a statement
> saying (approximately) "I think this patch is fine and I intend to
> send it to Linus during the next merge window.".
I mean, that's what we're saying and doing?
> So my expectation is that if a patch is dropped again from next, there
> was a problem and it would be fair if the maintainer tells the
> author/submitter about this problem and that the patch was dropped.
But it wasn't dropped, it's still very much to be sent to Linus during
the next merge window.
> So my concern is not about rule breaking, but about the strange signal
> that is sent to contributors by including their work in next for some
> time and then dropping it again without comment.
>
> > It's also why linux-next is rebuilt entirely every day.
> >
> > > > The key is that committers can commit to drm-misc-next _at any time_
> > > > regardless of the merge window. The drm-misc merge strategy makes this
> > > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > > merge window closes, patches will start flowing again.
> > > >
> > > > So basically your patches are landed and should even keep the same git
> > > > hashes when they eventually make it to Linux. They just won't land for
> > > > another release cycle of Linux.
> > >
> > > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > > understand the whole model, the patches at least seem to be scheduled to
> > > go in during the next merge window.
> >
> > It's not that complicated.
> >
> > drm-misc-next is always open, and we start targeting release X + 2 when
> > X-rc6 is released.
> >
> > This is due to Linus wanting all the commits sent as part of the PR in
> > linux-next for two weeks.
> >
> > In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> > is released, we remove drm-misc-next from the linux-next branch. All the
> > patches in drm-misc-next that were targetting X + 1 are in drm/next by
> > then, so it's not a concern.
>
> So if I were a maintainer of drm-misc, I'd want that no commit from
> drm-misc-next migrates to next after -rc6.
>
> Also note that the branch head in question (i.e. c2807ecb5290) was
> included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
> according to the rules you described c2807ecb5290 could have been
> qualified to go into v6.5-rc1?!
Yes, could have, but barely missed the last drm-misc-next PR we sent to
Dave that usually occurs on Thursday (8/6) so Dave can merge it on
Friday (9/6), the last working day before -rc6 was released.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 9:45 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 9:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Nicolas Ferre, Wang Jianzheng, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Miaoqian Lin, Stefan Agner,
Michal Simek, Matthias Brugger, Laurent Pinchart, Andrzej Hajda,
Sam Ravnborg, Rob Herring, Xinwei Kong, Jernej Skrabec,
Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley, nouveau,
Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Paul Cercueil,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Bjorn Andersson,
linux-stm32, Emma Anholt, Konrad Dybcio, Alexandre Torgue,
Doug Anderson, Liu Shixin, Krzysztof Kozlowski, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Qiang Yu,
Melissa Wen, linux-mediatek, Fabio Estevam, Laurentiu Palcu,
linux-tegra, Stephen Boyd, AngeloGioacchino Del Regno,
Yannick Fertre, linux-mips, Rob Clark, Philippe Cornu,
Daniel Vetter, Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 5567 bytes --]
On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > Together with the patches that were applied later the topmost commit
> > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > callback returning void"). This commit was part for the following next
> > > > > tags:
> > > > >
> > > > > $ git tag -l --contains c2807ecb5290
> > > > > next-20230609
> > > > > next-20230613
> > > > > next-20230614
> > > > > next-20230615
> > > > >
> > > > > However in next-20230616 they are missing. In next-20230616
> > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > also not included with a different commit id). The 37 patches dropped
> > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > >
> > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > 1 Christophe JAILLET
> > > > > 2 Jessica Zhang
> > > > > 5 Karol Wachowski
> > > > > 1 Laura Nao
> > > > > 27 Uwe Kleine-König
> > > > > 1 Wang Jianzheng
> > > > >
> > > > >
> > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > again?
> > > >
> > > > Actually, it was probably a mistake that these patches got merged to
> > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > aren't dropped and are still present in drm-misc-next.
> > > >
> > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > >
> > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > >
> > > Is there a flaw then in this unique model (or its implementation) when
> > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > expected, is it?
> >
> > There's no expectation afaik. Any tree merged in linux-next can be
> > rebased, drop a patch, amend one, etc. without any concern.
>
> I agree that there are no rules broken for a tree that is included in
> next and a maintainer is free to rewrite their tree independant of the
> tree being included in next.
>
> Still I think that shouldn't be used as an excuse.
As an excuse for what?
> For me, if a maintainer puts some patch into next that's a statement
> saying (approximately) "I think this patch is fine and I intend to
> send it to Linus during the next merge window.".
I mean, that's what we're saying and doing?
> So my expectation is that if a patch is dropped again from next, there
> was a problem and it would be fair if the maintainer tells the
> author/submitter about this problem and that the patch was dropped.
But it wasn't dropped, it's still very much to be sent to Linus during
the next merge window.
> So my concern is not about rule breaking, but about the strange signal
> that is sent to contributors by including their work in next for some
> time and then dropping it again without comment.
>
> > It's also why linux-next is rebuilt entirely every day.
> >
> > > > The key is that committers can commit to drm-misc-next _at any time_
> > > > regardless of the merge window. The drm-misc merge strategy makes this
> > > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > > merge window closes, patches will start flowing again.
> > > >
> > > > So basically your patches are landed and should even keep the same git
> > > > hashes when they eventually make it to Linux. They just won't land for
> > > > another release cycle of Linux.
> > >
> > > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > > understand the whole model, the patches at least seem to be scheduled to
> > > go in during the next merge window.
> >
> > It's not that complicated.
> >
> > drm-misc-next is always open, and we start targeting release X + 2 when
> > X-rc6 is released.
> >
> > This is due to Linus wanting all the commits sent as part of the PR in
> > linux-next for two weeks.
> >
> > In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> > is released, we remove drm-misc-next from the linux-next branch. All the
> > patches in drm-misc-next that were targetting X + 1 are in drm/next by
> > then, so it's not a concern.
>
> So if I were a maintainer of drm-misc, I'd want that no commit from
> drm-misc-next migrates to next after -rc6.
>
> Also note that the branch head in question (i.e. c2807ecb5290) was
> included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
> according to the rules you described c2807ecb5290 could have been
> qualified to go into v6.5-rc1?!
Yes, could have, but barely missed the last drm-misc-next PR we sent to
Dave that usually occurs on Thursday (8/6) so Dave can merge it on
Friday (9/6), the last working day before -rc6 was released.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 9:45 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 9:45 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Alexandre Belloni,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rob Clark,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Inki Dae, Alain Volmat, Sean Paul,
Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Miaoqian Lin, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Jonathan Hunter, linux-rockchip,
Ben Skeggs, Russell King, Jessica Zhang, linux-mips, Liu Ying,
linux-arm-msm, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, linux-mediatek, Brian Starkey,
Kuninori Morimoto, Yuan Can, Stefan Agner, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Chun-Kuang Hu, Lyude Paul, Arnd Bergmann, Guo Zhengkui,
Konrad Dybcio, Alison Wang, Abhinav Kumar, Christian Gmeiner,
Mark Brown, Baolin Wang, Daniel Vetter, Liu Shixin,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32,
Emma Anholt, Liviu Dudau, Alexandre Torgue, Doug Anderson,
Paul Cercueil, Laura Nao, David Airlie, Marek Vasut,
linux-renesas-soc, Yongqin Liu, Jayshri Pawar, Jonas Karlman,
Russell King, Martin Blumenstingl, Philippe Cornu,
Thomas Zimmermann, Melissa Wen, Christophe JAILLET, Fabio Estevam,
Laurentiu Palcu, Matthias Brugger, AngeloGioacchino Del Regno,
Bjorn Andersson, Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu,
Philipp Zabel, Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 5567 bytes --]
On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > Together with the patches that were applied later the topmost commit
> > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > callback returning void"). This commit was part for the following next
> > > > > tags:
> > > > >
> > > > > $ git tag -l --contains c2807ecb5290
> > > > > next-20230609
> > > > > next-20230613
> > > > > next-20230614
> > > > > next-20230615
> > > > >
> > > > > However in next-20230616 they are missing. In next-20230616
> > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > also not included with a different commit id). The 37 patches dropped
> > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > >
> > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > 1 Christophe JAILLET
> > > > > 2 Jessica Zhang
> > > > > 5 Karol Wachowski
> > > > > 1 Laura Nao
> > > > > 27 Uwe Kleine-König
> > > > > 1 Wang Jianzheng
> > > > >
> > > > >
> > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > again?
> > > >
> > > > Actually, it was probably a mistake that these patches got merged to
> > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > aren't dropped and are still present in drm-misc-next.
> > > >
> > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > >
> > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > >
> > > Is there a flaw then in this unique model (or its implementation) when
> > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > expected, is it?
> >
> > There's no expectation afaik. Any tree merged in linux-next can be
> > rebased, drop a patch, amend one, etc. without any concern.
>
> I agree that there are no rules broken for a tree that is included in
> next and a maintainer is free to rewrite their tree independant of the
> tree being included in next.
>
> Still I think that shouldn't be used as an excuse.
As an excuse for what?
> For me, if a maintainer puts some patch into next that's a statement
> saying (approximately) "I think this patch is fine and I intend to
> send it to Linus during the next merge window.".
I mean, that's what we're saying and doing?
> So my expectation is that if a patch is dropped again from next, there
> was a problem and it would be fair if the maintainer tells the
> author/submitter about this problem and that the patch was dropped.
But it wasn't dropped, it's still very much to be sent to Linus during
the next merge window.
> So my concern is not about rule breaking, but about the strange signal
> that is sent to contributors by including their work in next for some
> time and then dropping it again without comment.
>
> > It's also why linux-next is rebuilt entirely every day.
> >
> > > > The key is that committers can commit to drm-misc-next _at any time_
> > > > regardless of the merge window. The drm-misc merge strategy makes this
> > > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > > merge window closes, patches will start flowing again.
> > > >
> > > > So basically your patches are landed and should even keep the same git
> > > > hashes when they eventually make it to Linux. They just won't land for
> > > > another release cycle of Linux.
> > >
> > > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > > understand the whole model, the patches at least seem to be scheduled to
> > > go in during the next merge window.
> >
> > It's not that complicated.
> >
> > drm-misc-next is always open, and we start targeting release X + 2 when
> > X-rc6 is released.
> >
> > This is due to Linus wanting all the commits sent as part of the PR in
> > linux-next for two weeks.
> >
> > In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> > is released, we remove drm-misc-next from the linux-next branch. All the
> > patches in drm-misc-next that were targetting X + 1 are in drm/next by
> > then, so it's not a concern.
>
> So if I were a maintainer of drm-misc, I'd want that no commit from
> drm-misc-next migrates to next after -rc6.
>
> Also note that the branch head in question (i.e. c2807ecb5290) was
> included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
> according to the rules you described c2807ecb5290 could have been
> qualified to go into v6.5-rc1?!
Yes, could have, but barely missed the last drm-misc-next PR we sent to
Dave that usually occurs on Thursday (8/6) so Dave can merge it on
Friday (9/6), the last working day before -rc6 was released.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 9:45 ` Maxime Ripard
(?)
(?)
@ 2023-06-19 10:53 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 10:53 UTC (permalink / raw)
To: linux-aspeed
On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > Hello Maxime,
> >
> > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > Together with the patches that were applied later the topmost commit
> > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > callback returning void"). This commit was part for the following next
> > > > > > tags:
> > > > > >
> > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > next-20230609
> > > > > > next-20230613
> > > > > > next-20230614
> > > > > > next-20230615
> > > > > >
> > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > >
> > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > 1 Christophe JAILLET
> > > > > > 2 Jessica Zhang
> > > > > > 5 Karol Wachowski
> > > > > > 1 Laura Nao
> > > > > > 27 Uwe Kleine-K?nig
> > > > > > 1 Wang Jianzheng
> > > > > >
> > > > > >
> > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > again?
> > > > >
> > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > aren't dropped and are still present in drm-misc-next.
> > > > >
> > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > >
> > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > >
> > > > Is there a flaw then in this unique model (or its implementation) when
> > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > expected, is it?
> > >
> > > There's no expectation afaik. Any tree merged in linux-next can be
> > > rebased, drop a patch, amend one, etc. without any concern.
> >
> > I agree that there are no rules broken for a tree that is included in
> > next and a maintainer is free to rewrite their tree independant of the
> > tree being included in next.
> >
> > Still I think that shouldn't be used as an excuse.
>
> As an excuse for what?
Just because the rules for trees in next allow the merged branch to be
rewritten, shouldn't be used to justify rewriting the branch.
IMHO you still should ensure that only commits make it into any next
snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
intend to be included in X-rc1.
> > For me, if a maintainer puts some patch into next that's a statement
> > saying (approximately) "I think this patch is fine and I intend to
> > send it to Linus during the next merge window.".
>
> I mean, that's what we're saying and doing?
No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
was part of next-20230609). A few days later however the patches were
dropped.
The two options that would have made the experience smoother for me are:
a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
b) keep c2807ecb5290 in a branch that doesn't result it entering next
before v6.5-rc1.
> > So my expectation is that if a patch is dropped again from next, there
> > was a problem and it would be fair if the maintainer tells the
> > author/submitter about this problem and that the patch was dropped.
>
> But it wasn't dropped,
From my POV it was dropped from next as it was part of next between
next-20230609 and next-20230615 but not any more since next-20230616.
You talk about (not) being dropped from some branch in drm-misc, that's
irrelevant for the thing I'm complaining about.
> it's still very much to be sent to Linus during the next merge window.
"next merge window" as in the one leading to 6.5-rc1? Either we mean
different things when we say "next merge window", or there is a
misunderstanding I don't see yet.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/7f149314/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 10:53 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 10:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Alain Volmat, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Jonathan Hunter,
linux-rockchip, Ben Skeggs, Russell King, Jessica Zhang,
linux-mips, Liu Ying, linux-arm-msm, Wang Jianzheng,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
linux-mediatek, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Doug Anderson, Paul Cercueil,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]
On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > Hello Maxime,
> >
> > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > Together with the patches that were applied later the topmost commit
> > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > callback returning void"). This commit was part for the following next
> > > > > > tags:
> > > > > >
> > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > next-20230609
> > > > > > next-20230613
> > > > > > next-20230614
> > > > > > next-20230615
> > > > > >
> > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > >
> > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > 1 Christophe JAILLET
> > > > > > 2 Jessica Zhang
> > > > > > 5 Karol Wachowski
> > > > > > 1 Laura Nao
> > > > > > 27 Uwe Kleine-König
> > > > > > 1 Wang Jianzheng
> > > > > >
> > > > > >
> > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > again?
> > > > >
> > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > aren't dropped and are still present in drm-misc-next.
> > > > >
> > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > >
> > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > >
> > > > Is there a flaw then in this unique model (or its implementation) when
> > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > expected, is it?
> > >
> > > There's no expectation afaik. Any tree merged in linux-next can be
> > > rebased, drop a patch, amend one, etc. without any concern.
> >
> > I agree that there are no rules broken for a tree that is included in
> > next and a maintainer is free to rewrite their tree independant of the
> > tree being included in next.
> >
> > Still I think that shouldn't be used as an excuse.
>
> As an excuse for what?
Just because the rules for trees in next allow the merged branch to be
rewritten, shouldn't be used to justify rewriting the branch.
IMHO you still should ensure that only commits make it into any next
snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
intend to be included in X-rc1.
> > For me, if a maintainer puts some patch into next that's a statement
> > saying (approximately) "I think this patch is fine and I intend to
> > send it to Linus during the next merge window.".
>
> I mean, that's what we're saying and doing?
No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
was part of next-20230609). A few days later however the patches were
dropped.
The two options that would have made the experience smoother for me are:
a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
b) keep c2807ecb5290 in a branch that doesn't result it entering next
before v6.5-rc1.
> > So my expectation is that if a patch is dropped again from next, there
> > was a problem and it would be fair if the maintainer tells the
> > author/submitter about this problem and that the patch was dropped.
>
> But it wasn't dropped,
From my POV it was dropped from next as it was part of next between
next-20230609 and next-20230615 but not any more since next-20230616.
You talk about (not) being dropped from some branch in drm-misc, that's
irrelevant for the thing I'm complaining about.
> it's still very much to be sent to Linus during the next merge window.
"next merge window" as in the one leading to 6.5-rc1? Either we mean
different things when we say "next merge window", or there is a
misunderstanding I don't see yet.
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] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 10:53 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 10:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, Miaoqian Lin, linux-sunxi,
Rob Clark, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae, Alain Volmat,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, linux-rockchip, Ben Skeggs,
Russell King, Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Daniel Vetter,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]
On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > Hello Maxime,
> >
> > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > Together with the patches that were applied later the topmost commit
> > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > callback returning void"). This commit was part for the following next
> > > > > > tags:
> > > > > >
> > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > next-20230609
> > > > > > next-20230613
> > > > > > next-20230614
> > > > > > next-20230615
> > > > > >
> > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > >
> > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > 1 Christophe JAILLET
> > > > > > 2 Jessica Zhang
> > > > > > 5 Karol Wachowski
> > > > > > 1 Laura Nao
> > > > > > 27 Uwe Kleine-König
> > > > > > 1 Wang Jianzheng
> > > > > >
> > > > > >
> > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > again?
> > > > >
> > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > aren't dropped and are still present in drm-misc-next.
> > > > >
> > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > >
> > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > >
> > > > Is there a flaw then in this unique model (or its implementation) when
> > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > expected, is it?
> > >
> > > There's no expectation afaik. Any tree merged in linux-next can be
> > > rebased, drop a patch, amend one, etc. without any concern.
> >
> > I agree that there are no rules broken for a tree that is included in
> > next and a maintainer is free to rewrite their tree independant of the
> > tree being included in next.
> >
> > Still I think that shouldn't be used as an excuse.
>
> As an excuse for what?
Just because the rules for trees in next allow the merged branch to be
rewritten, shouldn't be used to justify rewriting the branch.
IMHO you still should ensure that only commits make it into any next
snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
intend to be included in X-rc1.
> > For me, if a maintainer puts some patch into next that's a statement
> > saying (approximately) "I think this patch is fine and I intend to
> > send it to Linus during the next merge window.".
>
> I mean, that's what we're saying and doing?
No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
was part of next-20230609). A few days later however the patches were
dropped.
The two options that would have made the experience smoother for me are:
a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
b) keep c2807ecb5290 in a branch that doesn't result it entering next
before v6.5-rc1.
> > So my expectation is that if a patch is dropped again from next, there
> > was a problem and it would be fair if the maintainer tells the
> > author/submitter about this problem and that the patch was dropped.
>
> But it wasn't dropped,
From my POV it was dropped from next as it was part of next between
next-20230609 and next-20230615 but not any more since next-20230616.
You talk about (not) being dropped from some branch in drm-misc, that's
irrelevant for the thing I'm complaining about.
> it's still very much to be sent to Linus during the next merge window.
"next merge window" as in the one leading to 6.5-rc1? Either we mean
different things when we say "next merge window", or there is a
misunderstanding I don't see yet.
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] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 10:53 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 10:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Jonathan Hunter, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Kuninori Morimoto, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Xinliang Liu, Danilo Krummrich, NXP Linux Team,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Yuan Can, Inki Dae, Jessica Zhang,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Steven Price, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Brian Starkey,
Karol Herbst, Miaoqian Lin, Stefan Agner, Michal Simek,
Matthias Brugger, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Philipp Zabel, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Paul Cercueil,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Bjorn Andersson,
linux-stm32, Emma Anholt, Konrad Dybcio, Alexandre Torgue,
Doug Anderson, Liu Shixin, Krzysztof Kozlowski, Laura Nao,
David Airlie, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Fabio Estevam, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]
On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > Hello Maxime,
> >
> > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > Together with the patches that were applied later the topmost commit
> > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > callback returning void"). This commit was part for the following next
> > > > > > tags:
> > > > > >
> > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > next-20230609
> > > > > > next-20230613
> > > > > > next-20230614
> > > > > > next-20230615
> > > > > >
> > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > >
> > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > 1 Christophe JAILLET
> > > > > > 2 Jessica Zhang
> > > > > > 5 Karol Wachowski
> > > > > > 1 Laura Nao
> > > > > > 27 Uwe Kleine-König
> > > > > > 1 Wang Jianzheng
> > > > > >
> > > > > >
> > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > again?
> > > > >
> > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > aren't dropped and are still present in drm-misc-next.
> > > > >
> > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > >
> > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > >
> > > > Is there a flaw then in this unique model (or its implementation) when
> > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > expected, is it?
> > >
> > > There's no expectation afaik. Any tree merged in linux-next can be
> > > rebased, drop a patch, amend one, etc. without any concern.
> >
> > I agree that there are no rules broken for a tree that is included in
> > next and a maintainer is free to rewrite their tree independant of the
> > tree being included in next.
> >
> > Still I think that shouldn't be used as an excuse.
>
> As an excuse for what?
Just because the rules for trees in next allow the merged branch to be
rewritten, shouldn't be used to justify rewriting the branch.
IMHO you still should ensure that only commits make it into any next
snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
intend to be included in X-rc1.
> > For me, if a maintainer puts some patch into next that's a statement
> > saying (approximately) "I think this patch is fine and I intend to
> > send it to Linus during the next merge window.".
>
> I mean, that's what we're saying and doing?
No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
was part of next-20230609). A few days later however the patches were
dropped.
The two options that would have made the experience smoother for me are:
a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
b) keep c2807ecb5290 in a branch that doesn't result it entering next
before v6.5-rc1.
> > So my expectation is that if a patch is dropped again from next, there
> > was a problem and it would be fair if the maintainer tells the
> > author/submitter about this problem and that the patch was dropped.
>
> But it wasn't dropped,
From my POV it was dropped from next as it was part of next between
next-20230609 and next-20230615 but not any more since next-20230616.
You talk about (not) being dropped from some branch in drm-misc, that's
irrelevant for the thing I'm complaining about.
> it's still very much to be sent to Linus during the next merge window.
"next merge window" as in the one leading to 6.5-rc1? Either we mean
different things when we say "next merge window", or there is a
misunderstanding I don't see yet.
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] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 10:53 ` Uwe Kleine-König
(?)
(?)
@ 2023-06-19 12:47 ` Maxime Ripard
-1 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 12:47 UTC (permalink / raw)
To: linux-aspeed
On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > Hello Maxime,
> > >
> > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > tags:
> > > > > > >
> > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > next-20230609
> > > > > > > next-20230613
> > > > > > > next-20230614
> > > > > > > next-20230615
> > > > > > >
> > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > >
> > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > 1 Christophe JAILLET
> > > > > > > 2 Jessica Zhang
> > > > > > > 5 Karol Wachowski
> > > > > > > 1 Laura Nao
> > > > > > > 27 Uwe Kleine-K?nig
> > > > > > > 1 Wang Jianzheng
> > > > > > >
> > > > > > >
> > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > again?
> > > > > >
> > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > >
> > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > >
> > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > >
> > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > expected, is it?
> > > >
> > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > rebased, drop a patch, amend one, etc. without any concern.
> > >
> > > I agree that there are no rules broken for a tree that is included in
> > > next and a maintainer is free to rewrite their tree independant of the
> > > tree being included in next.
> > >
> > > Still I think that shouldn't be used as an excuse.
> >
> > As an excuse for what?
>
> Just because the rules for trees in next allow the merged branch to be
> rewritten, shouldn't be used to justify rewriting the branch.
>
> IMHO you still should ensure that only commits make it into any next
> snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> intend to be included in X-rc1.
That's never been a next rule either. Rust support has been in next for
almost a year without being sent as a PR for example.
> > > For me, if a maintainer puts some patch into next that's a statement
> > > saying (approximately) "I think this patch is fine and I intend to
> > > send it to Linus during the next merge window.".
> >
> > I mean, that's what we're saying and doing?
>
> No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> was part of next-20230609). A few days later however the patches were
> dropped.
>
> The two options that would have made the experience smoother for me are:
>
> a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
That's not an option. You were simply too late for v6.5-rc1, unless you
expect us to get rid of timezones and work on week-ends. But surely you
don't.
> b) keep c2807ecb5290 in a branch that doesn't result it entering next
> before v6.5-rc1.
All the drm-misc committers use dim. If that's a concern for you, feel
free to send a patch addressing this to dim.
> > > So my expectation is that if a patch is dropped again from next, there
> > > was a problem and it would be fair if the maintainer tells the
> > > author/submitter about this problem and that the patch was dropped.
> >
> > But it wasn't dropped,
>
> From my POV it was dropped from next as it was part of next between
> next-20230609 and next-20230615 but not any more since next-20230616.
> You talk about (not) being dropped from some branch in drm-misc, that's
> irrelevant for the thing I'm complaining about.
You were never told that they were merged in linux-next, but in
drm-misc-next. If they did, it's mostly an unfortunate artifact.
We have a documentation that explains the process and how drm-misc-next
works. If that's still confusing somehow, feel free to amend it to make
it clearer.
> > it's still very much to be sent to Linus during the next merge window.
>
> "next merge window" as in the one leading to 6.5-rc1? Either we mean
> different things when we say "next merge window", or there is a
> misunderstanding I don't see yet.
Linus doesn't want to receive in a PR patches that haven't been in
linux-next for at least two weeks. In most cases that's rc6, which means
that by the time we send our last PR before rc6, the
next-merge-window-while-still-meeting-Linus-requirements is 6.6.
The rule applies to all trees, and it's why the soc tree also requires
its submaintainers to submit their PR before -rc6.
So yeah, sorry if it was confusing. At the end of the day, it's a
compromise, and I can't find a better one for everyone involved
(maintainers, contributors and committers alike) off the top of my head.
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/db60b3a5/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 12:47 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 12:47 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin, linux-sunxi,
Rahul T R, Raphael Gallais-Pou, Jani Nikula, Sascha Hauer,
etnaviv, Stephen Boyd, Alain Volmat, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Jonathan Hunter,
linux-rockchip, Ben Skeggs, Russell King, Jessica Zhang,
linux-mips, Liu Ying, linux-arm-msm, Wang Jianzheng,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
linux-mediatek, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Doug Anderson, Paul Cercueil,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 6302 bytes --]
On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > Hello Maxime,
> > >
> > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > tags:
> > > > > > >
> > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > next-20230609
> > > > > > > next-20230613
> > > > > > > next-20230614
> > > > > > > next-20230615
> > > > > > >
> > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > >
> > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > 1 Christophe JAILLET
> > > > > > > 2 Jessica Zhang
> > > > > > > 5 Karol Wachowski
> > > > > > > 1 Laura Nao
> > > > > > > 27 Uwe Kleine-König
> > > > > > > 1 Wang Jianzheng
> > > > > > >
> > > > > > >
> > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > again?
> > > > > >
> > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > >
> > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > >
> > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > >
> > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > expected, is it?
> > > >
> > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > rebased, drop a patch, amend one, etc. without any concern.
> > >
> > > I agree that there are no rules broken for a tree that is included in
> > > next and a maintainer is free to rewrite their tree independant of the
> > > tree being included in next.
> > >
> > > Still I think that shouldn't be used as an excuse.
> >
> > As an excuse for what?
>
> Just because the rules for trees in next allow the merged branch to be
> rewritten, shouldn't be used to justify rewriting the branch.
>
> IMHO you still should ensure that only commits make it into any next
> snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> intend to be included in X-rc1.
That's never been a next rule either. Rust support has been in next for
almost a year without being sent as a PR for example.
> > > For me, if a maintainer puts some patch into next that's a statement
> > > saying (approximately) "I think this patch is fine and I intend to
> > > send it to Linus during the next merge window.".
> >
> > I mean, that's what we're saying and doing?
>
> No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> was part of next-20230609). A few days later however the patches were
> dropped.
>
> The two options that would have made the experience smoother for me are:
>
> a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
That's not an option. You were simply too late for v6.5-rc1, unless you
expect us to get rid of timezones and work on week-ends. But surely you
don't.
> b) keep c2807ecb5290 in a branch that doesn't result it entering next
> before v6.5-rc1.
All the drm-misc committers use dim. If that's a concern for you, feel
free to send a patch addressing this to dim.
> > > So my expectation is that if a patch is dropped again from next, there
> > > was a problem and it would be fair if the maintainer tells the
> > > author/submitter about this problem and that the patch was dropped.
> >
> > But it wasn't dropped,
>
> From my POV it was dropped from next as it was part of next between
> next-20230609 and next-20230615 but not any more since next-20230616.
> You talk about (not) being dropped from some branch in drm-misc, that's
> irrelevant for the thing I'm complaining about.
You were never told that they were merged in linux-next, but in
drm-misc-next. If they did, it's mostly an unfortunate artifact.
We have a documentation that explains the process and how drm-misc-next
works. If that's still confusing somehow, feel free to amend it to make
it clearer.
> > it's still very much to be sent to Linus during the next merge window.
>
> "next merge window" as in the one leading to 6.5-rc1? Either we mean
> different things when we say "next merge window", or there is a
> misunderstanding I don't see yet.
Linus doesn't want to receive in a PR patches that haven't been in
linux-next for at least two weeks. In most cases that's rc6, which means
that by the time we send our last PR before rc6, the
next-merge-window-while-still-meeting-Linus-requirements is 6.6.
The rule applies to all trees, and it's why the soc tree also requires
its submaintainers to submit their PR before -rc6.
So yeah, sorry if it was confusing. At the end of the day, it's a
compromise, and I can't find a better one for everyone involved
(maintainers, contributors and committers alike) off the top of my head.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 12:47 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 12:47 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, Miaoqian Lin, linux-sunxi,
Rob Clark, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae, Alain Volmat,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, linux-rockchip, Ben Skeggs,
Russell King, Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Daniel Vetter,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 6302 bytes --]
On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > Hello Maxime,
> > >
> > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > tags:
> > > > > > >
> > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > next-20230609
> > > > > > > next-20230613
> > > > > > > next-20230614
> > > > > > > next-20230615
> > > > > > >
> > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > >
> > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > 1 Christophe JAILLET
> > > > > > > 2 Jessica Zhang
> > > > > > > 5 Karol Wachowski
> > > > > > > 1 Laura Nao
> > > > > > > 27 Uwe Kleine-König
> > > > > > > 1 Wang Jianzheng
> > > > > > >
> > > > > > >
> > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > again?
> > > > > >
> > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > >
> > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > >
> > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > >
> > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > expected, is it?
> > > >
> > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > rebased, drop a patch, amend one, etc. without any concern.
> > >
> > > I agree that there are no rules broken for a tree that is included in
> > > next and a maintainer is free to rewrite their tree independant of the
> > > tree being included in next.
> > >
> > > Still I think that shouldn't be used as an excuse.
> >
> > As an excuse for what?
>
> Just because the rules for trees in next allow the merged branch to be
> rewritten, shouldn't be used to justify rewriting the branch.
>
> IMHO you still should ensure that only commits make it into any next
> snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> intend to be included in X-rc1.
That's never been a next rule either. Rust support has been in next for
almost a year without being sent as a PR for example.
> > > For me, if a maintainer puts some patch into next that's a statement
> > > saying (approximately) "I think this patch is fine and I intend to
> > > send it to Linus during the next merge window.".
> >
> > I mean, that's what we're saying and doing?
>
> No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> was part of next-20230609). A few days later however the patches were
> dropped.
>
> The two options that would have made the experience smoother for me are:
>
> a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
That's not an option. You were simply too late for v6.5-rc1, unless you
expect us to get rid of timezones and work on week-ends. But surely you
don't.
> b) keep c2807ecb5290 in a branch that doesn't result it entering next
> before v6.5-rc1.
All the drm-misc committers use dim. If that's a concern for you, feel
free to send a patch addressing this to dim.
> > > So my expectation is that if a patch is dropped again from next, there
> > > was a problem and it would be fair if the maintainer tells the
> > > author/submitter about this problem and that the patch was dropped.
> >
> > But it wasn't dropped,
>
> From my POV it was dropped from next as it was part of next between
> next-20230609 and next-20230615 but not any more since next-20230616.
> You talk about (not) being dropped from some branch in drm-misc, that's
> irrelevant for the thing I'm complaining about.
You were never told that they were merged in linux-next, but in
drm-misc-next. If they did, it's mostly an unfortunate artifact.
We have a documentation that explains the process and how drm-misc-next
works. If that's still confusing somehow, feel free to amend it to make
it clearer.
> > it's still very much to be sent to Linus during the next merge window.
>
> "next merge window" as in the one leading to 6.5-rc1? Either we mean
> different things when we say "next merge window", or there is a
> misunderstanding I don't see yet.
Linus doesn't want to receive in a PR patches that haven't been in
linux-next for at least two weeks. In most cases that's rc6, which means
that by the time we send our last PR before rc6, the
next-merge-window-while-still-meeting-Linus-requirements is 6.6.
The rule applies to all trees, and it's why the soc tree also requires
its submaintainers to submit their PR before -rc6.
So yeah, sorry if it was confusing. At the end of the day, it's a
compromise, and I can't find a better one for everyone involved
(maintainers, contributors and committers alike) off the top of my head.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 12:47 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 12:47 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Jonathan Hunter, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Kuninori Morimoto, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Xinliang Liu, Danilo Krummrich, NXP Linux Team,
linux-sunxi, Rahul T R, Raphael Gallais-Pou, Jani Nikula,
Sascha Hauer, etnaviv, Yuan Can, Inki Dae, Jessica Zhang,
Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery, Jingoo Han,
Seung-Woo Kim, Noralf Trønnes, kernel, Alex Deucher,
freedreno, Claudiu Beznea, Alexandre Belloni, linux-aspeed,
Tomi Valkeinen, Thierry Reding, John Stultz, Mihail Atanassov,
Liang He, Ville Syrjälä, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Steven Price, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Brian Starkey,
Karol Herbst, Miaoqian Lin, Stefan Agner, Michal Simek,
Matthias Brugger, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Rob Herring, Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai,
Mali DP Maintainers, Joel Stanley, nouveau, Orson Zhai,
Philipp Zabel, Chun-Kuang Hu, Lyude Paul, Arnd Bergmann,
Guo Zhengkui, Liviu Dudau, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Paul Cercueil,
Tomi Valkeinen, Deepak R Varma, Karol Wachowski, Kieran Bingham,
Ricardo Ribalda, Tian Tao, Shawn Guo, Bjorn Andersson,
linux-stm32, Emma Anholt, Konrad Dybcio, Alexandre Torgue,
Doug Anderson, Liu Shixin, Krzysztof Kozlowski, Laura Nao,
David Airlie, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Fabio Estevam, Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 6302 bytes --]
On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > Hello Maxime,
> > >
> > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > tags:
> > > > > > >
> > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > next-20230609
> > > > > > > next-20230613
> > > > > > > next-20230614
> > > > > > > next-20230615
> > > > > > >
> > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > >
> > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > 1 Christophe JAILLET
> > > > > > > 2 Jessica Zhang
> > > > > > > 5 Karol Wachowski
> > > > > > > 1 Laura Nao
> > > > > > > 27 Uwe Kleine-König
> > > > > > > 1 Wang Jianzheng
> > > > > > >
> > > > > > >
> > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > again?
> > > > > >
> > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > >
> > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > >
> > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > >
> > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > expected, is it?
> > > >
> > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > rebased, drop a patch, amend one, etc. without any concern.
> > >
> > > I agree that there are no rules broken for a tree that is included in
> > > next and a maintainer is free to rewrite their tree independant of the
> > > tree being included in next.
> > >
> > > Still I think that shouldn't be used as an excuse.
> >
> > As an excuse for what?
>
> Just because the rules for trees in next allow the merged branch to be
> rewritten, shouldn't be used to justify rewriting the branch.
>
> IMHO you still should ensure that only commits make it into any next
> snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> intend to be included in X-rc1.
That's never been a next rule either. Rust support has been in next for
almost a year without being sent as a PR for example.
> > > For me, if a maintainer puts some patch into next that's a statement
> > > saying (approximately) "I think this patch is fine and I intend to
> > > send it to Linus during the next merge window.".
> >
> > I mean, that's what we're saying and doing?
>
> No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> was part of next-20230609). A few days later however the patches were
> dropped.
>
> The two options that would have made the experience smoother for me are:
>
> a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
That's not an option. You were simply too late for v6.5-rc1, unless you
expect us to get rid of timezones and work on week-ends. But surely you
don't.
> b) keep c2807ecb5290 in a branch that doesn't result it entering next
> before v6.5-rc1.
All the drm-misc committers use dim. If that's a concern for you, feel
free to send a patch addressing this to dim.
> > > So my expectation is that if a patch is dropped again from next, there
> > > was a problem and it would be fair if the maintainer tells the
> > > author/submitter about this problem and that the patch was dropped.
> >
> > But it wasn't dropped,
>
> From my POV it was dropped from next as it was part of next between
> next-20230609 and next-20230615 but not any more since next-20230616.
> You talk about (not) being dropped from some branch in drm-misc, that's
> irrelevant for the thing I'm complaining about.
You were never told that they were merged in linux-next, but in
drm-misc-next. If they did, it's mostly an unfortunate artifact.
We have a documentation that explains the process and how drm-misc-next
works. If that's still confusing somehow, feel free to amend it to make
it clearer.
> > it's still very much to be sent to Linus during the next merge window.
>
> "next merge window" as in the one leading to 6.5-rc1? Either we mean
> different things when we say "next merge window", or there is a
> misunderstanding I don't see yet.
Linus doesn't want to receive in a PR patches that haven't been in
linux-next for at least two weeks. In most cases that's rc6, which means
that by the time we send our last PR before rc6, the
next-merge-window-while-still-meeting-Linus-requirements is 6.6.
The rule applies to all trees, and it's why the soc tree also requires
its submaintainers to submit their PR before -rc6.
So yeah, sorry if it was confusing. At the end of the day, it's a
compromise, and I can't find a better one for everyone involved
(maintainers, contributors and committers alike) off the top of my head.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 12:47 ` Maxime Ripard
(?)
(?)
@ 2023-06-19 13:25 ` Geert Uytterhoeven
-1 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 13:25 UTC (permalink / raw)
To: linux-aspeed
Hi Maxime,
CC sfr
On Mon, Jun 19, 2023 at 2:51?PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > tags:
> > > > > > > >
> > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > next-20230609
> > > > > > > > next-20230613
> > > > > > > > next-20230614
> > > > > > > > next-20230615
> > > > > > > >
> > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > >
> > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > 1 Christophe JAILLET
> > > > > > > > 2 Jessica Zhang
> > > > > > > > 5 Karol Wachowski
> > > > > > > > 1 Laura Nao
> > > > > > > > 27 Uwe Kleine-K?nig
> > > > > > > > 1 Wang Jianzheng
> > > > > > > >
> > > > > > > >
> > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > again?
> > > > > > >
> > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > >
> > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > >
> > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > >
> > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > expected, is it?
> > > > >
> > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > >
> > > > I agree that there are no rules broken for a tree that is included in
> > > > next and a maintainer is free to rewrite their tree independant of the
> > > > tree being included in next.
> > > >
> > > > Still I think that shouldn't be used as an excuse.
> > >
> > > As an excuse for what?
> >
> > Just because the rules for trees in next allow the merged branch to be
> > rewritten, shouldn't be used to justify rewriting the branch.
> >
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
"The linux-next tree is, by design, a snapshot of what the mainline
is expected to look like after the next merge window closes."
The general rule for linux-next is that its contents are intended to end
up in the next kernel release, and that it should not contain commits
that are intended for the next-next release, cfr. what Stephen sends
out to new trees:
"You will need to ensure that the patches/commits in your tree/series have
been:
[...]
* destined for the current or next Linux merge window."
and what he requests regularly in his announces, e.g.:
"Please do not add any v6.4 related commits to your linux-next included
branches until after v6.3-rc1 has been released."
AFAIU, the exception to the rule is new, self-contained, and sometimes
controversial development, which may have to cook for a few more cycles,
if it ends up in a PR at all.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
I don't think anyone expects you to do that...
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
So you say this is an issue with the tooling? ;-)
If the tooling breaks the rules, perhaps the tooling should be fixed?
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next. If they did, it's mostly an unfortunate artifact.
>
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
Why that document may apply to drm-misc-next, everything that appears
in linux-next should follow the linux-next process
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L256
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
Unless there's a very good reason to deviate from that (e.g. a bug fix).
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
As I understand, the main issue Uwe is objecting to, is that his
patches ended up in linux-next first, only to be dropped again from
linux-next later, and that there was no communication about the
latter.
If you're not constantly working on a subsystem, it can be very hard
to keep track of the status of your own drive-by patches. When patches
get applied, appear in linux-next, and disappear from linux-next again
later, it's worse...
Thanks for your understanding!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 13:25 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 13:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Alain Volmat, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Stephen Rothwell, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Jonathan Hunter,
linux-rockchip, Ben Skeggs, Russell King, Jessica Zhang,
linux-mips, Liu Ying, linux-arm-msm, Wang Jianzheng,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
linux-mediatek, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Doug Anderson, Paul Cercueil,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
Hi Maxime,
CC sfr
On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > tags:
> > > > > > > >
> > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > next-20230609
> > > > > > > > next-20230613
> > > > > > > > next-20230614
> > > > > > > > next-20230615
> > > > > > > >
> > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > >
> > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > 1 Christophe JAILLET
> > > > > > > > 2 Jessica Zhang
> > > > > > > > 5 Karol Wachowski
> > > > > > > > 1 Laura Nao
> > > > > > > > 27 Uwe Kleine-König
> > > > > > > > 1 Wang Jianzheng
> > > > > > > >
> > > > > > > >
> > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > again?
> > > > > > >
> > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > >
> > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > >
> > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > >
> > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > expected, is it?
> > > > >
> > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > >
> > > > I agree that there are no rules broken for a tree that is included in
> > > > next and a maintainer is free to rewrite their tree independant of the
> > > > tree being included in next.
> > > >
> > > > Still I think that shouldn't be used as an excuse.
> > >
> > > As an excuse for what?
> >
> > Just because the rules for trees in next allow the merged branch to be
> > rewritten, shouldn't be used to justify rewriting the branch.
> >
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
"The linux-next tree is, by design, a snapshot of what the mainline
is expected to look like after the next merge window closes."
The general rule for linux-next is that its contents are intended to end
up in the next kernel release, and that it should not contain commits
that are intended for the next-next release, cfr. what Stephen sends
out to new trees:
"You will need to ensure that the patches/commits in your tree/series have
been:
[...]
* destined for the current or next Linux merge window."
and what he requests regularly in his announces, e.g.:
"Please do not add any v6.4 related commits to your linux-next included
branches until after v6.3-rc1 has been released."
AFAIU, the exception to the rule is new, self-contained, and sometimes
controversial development, which may have to cook for a few more cycles,
if it ends up in a PR at all.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
I don't think anyone expects you to do that...
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
So you say this is an issue with the tooling? ;-)
If the tooling breaks the rules, perhaps the tooling should be fixed?
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next. If they did, it's mostly an unfortunate artifact.
>
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
Why that document may apply to drm-misc-next, everything that appears
in linux-next should follow the linux-next process
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L256
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
Unless there's a very good reason to deviate from that (e.g. a bug fix).
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
As I understand, the main issue Uwe is objecting to, is that his
patches ended up in linux-next first, only to be dropped again from
linux-next later, and that there was no communication about the
latter.
If you're not constantly working on a subsystem, it can be very hard
to keep track of the status of your own drive-by patches. When patches
get applied, appear in linux-next, and disappear from linux-next again
later, it's worse...
Thanks for your understanding!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 13:25 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 13:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, Miaoqian Lin, Uwe Kleine-König,
linux-sunxi, Rob Clark, Rahul T R, Raphael Gallais-Pou,
Jani Nikula, Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae,
Alain Volmat, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä,
Stephen Rothwell, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Daniel Vetter,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi Maxime,
CC sfr
On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > tags:
> > > > > > > >
> > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > next-20230609
> > > > > > > > next-20230613
> > > > > > > > next-20230614
> > > > > > > > next-20230615
> > > > > > > >
> > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > >
> > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > 1 Christophe JAILLET
> > > > > > > > 2 Jessica Zhang
> > > > > > > > 5 Karol Wachowski
> > > > > > > > 1 Laura Nao
> > > > > > > > 27 Uwe Kleine-König
> > > > > > > > 1 Wang Jianzheng
> > > > > > > >
> > > > > > > >
> > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > again?
> > > > > > >
> > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > >
> > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > >
> > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > >
> > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > expected, is it?
> > > > >
> > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > >
> > > > I agree that there are no rules broken for a tree that is included in
> > > > next and a maintainer is free to rewrite their tree independant of the
> > > > tree being included in next.
> > > >
> > > > Still I think that shouldn't be used as an excuse.
> > >
> > > As an excuse for what?
> >
> > Just because the rules for trees in next allow the merged branch to be
> > rewritten, shouldn't be used to justify rewriting the branch.
> >
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
"The linux-next tree is, by design, a snapshot of what the mainline
is expected to look like after the next merge window closes."
The general rule for linux-next is that its contents are intended to end
up in the next kernel release, and that it should not contain commits
that are intended for the next-next release, cfr. what Stephen sends
out to new trees:
"You will need to ensure that the patches/commits in your tree/series have
been:
[...]
* destined for the current or next Linux merge window."
and what he requests regularly in his announces, e.g.:
"Please do not add any v6.4 related commits to your linux-next included
branches until after v6.3-rc1 has been released."
AFAIU, the exception to the rule is new, self-contained, and sometimes
controversial development, which may have to cook for a few more cycles,
if it ends up in a PR at all.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
I don't think anyone expects you to do that...
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
So you say this is an issue with the tooling? ;-)
If the tooling breaks the rules, perhaps the tooling should be fixed?
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next. If they did, it's mostly an unfortunate artifact.
>
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
Why that document may apply to drm-misc-next, everything that appears
in linux-next should follow the linux-next process
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L256
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
Unless there's a very good reason to deviate from that (e.g. a bug fix).
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
As I understand, the main issue Uwe is objecting to, is that his
patches ended up in linux-next first, only to be dropped again from
linux-next later, and that there was no communication about the
latter.
If you're not constantly working on a subsystem, it can be very hard
to keep track of the status of your own drive-by patches. When patches
get applied, appear in linux-next, and disappear from linux-next again
later, it's worse...
Thanks for your understanding!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 13:25 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 13:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Uwe Kleine-König, Raymond Tan, Heiko Stübner,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Nicolas Ferre, Wang Jianzheng, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Karol Herbst, Miaoqian Lin,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Lyude Paul,
Arnd Bergmann, Guo Zhengkui, Liviu Dudau, Alison Wang,
Abhinav Kumar, Christian Gmeiner, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, David Airlie, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
Stephen Boyd, AngeloGioacchino Del Regno, Yannick Fertre,
linux-mips, Rob Clark, Philippe Cornu, Daniel Vetter,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach, Stephen Rothwell
Hi Maxime,
CC sfr
On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > tags:
> > > > > > > >
> > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > next-20230609
> > > > > > > > next-20230613
> > > > > > > > next-20230614
> > > > > > > > next-20230615
> > > > > > > >
> > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > >
> > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > 1 Christophe JAILLET
> > > > > > > > 2 Jessica Zhang
> > > > > > > > 5 Karol Wachowski
> > > > > > > > 1 Laura Nao
> > > > > > > > 27 Uwe Kleine-König
> > > > > > > > 1 Wang Jianzheng
> > > > > > > >
> > > > > > > >
> > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > again?
> > > > > > >
> > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > >
> > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > >
> > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > >
> > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > expected, is it?
> > > > >
> > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > >
> > > > I agree that there are no rules broken for a tree that is included in
> > > > next and a maintainer is free to rewrite their tree independant of the
> > > > tree being included in next.
> > > >
> > > > Still I think that shouldn't be used as an excuse.
> > >
> > > As an excuse for what?
> >
> > Just because the rules for trees in next allow the merged branch to be
> > rewritten, shouldn't be used to justify rewriting the branch.
> >
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
"The linux-next tree is, by design, a snapshot of what the mainline
is expected to look like after the next merge window closes."
The general rule for linux-next is that its contents are intended to end
up in the next kernel release, and that it should not contain commits
that are intended for the next-next release, cfr. what Stephen sends
out to new trees:
"You will need to ensure that the patches/commits in your tree/series have
been:
[...]
* destined for the current or next Linux merge window."
and what he requests regularly in his announces, e.g.:
"Please do not add any v6.4 related commits to your linux-next included
branches until after v6.3-rc1 has been released."
AFAIU, the exception to the rule is new, self-contained, and sometimes
controversial development, which may have to cook for a few more cycles,
if it ends up in a PR at all.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
I don't think anyone expects you to do that...
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
So you say this is an issue with the tooling? ;-)
If the tooling breaks the rules, perhaps the tooling should be fixed?
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next. If they did, it's mostly an unfortunate artifact.
>
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
Why that document may apply to drm-misc-next, everything that appears
in linux-next should follow the linux-next process
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L256
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
Unless there's a very good reason to deviate from that (e.g. a bug fix).
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
As I understand, the main issue Uwe is objecting to, is that his
patches ended up in linux-next first, only to be dropped again from
linux-next later, and that there was no communication about the
latter.
If you're not constantly working on a subsystem, it can be very hard
to keep track of the status of your own drive-by patches. When patches
get applied, appear in linux-next, and disappear from linux-next again
later, it's worse...
Thanks for your understanding!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 13:25 ` Geert Uytterhoeven
(?)
(?)
@ 2023-06-19 14:02 ` Maxime Ripard
-1 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 14:02 UTC (permalink / raw)
To: linux-aspeed
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51?PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > tags:
> > > > > > > > >
> > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > next-20230609
> > > > > > > > > next-20230613
> > > > > > > > > next-20230614
> > > > > > > > > next-20230615
> > > > > > > > >
> > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > >
> > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > 2 Jessica Zhang
> > > > > > > > > 5 Karol Wachowski
> > > > > > > > > 1 Laura Nao
> > > > > > > > > 27 Uwe Kleine-K?nig
> > > > > > > > > 1 Wang Jianzheng
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > again?
> > > > > > > >
> > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > >
> > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > >
> > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > >
> > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > expected, is it?
> > > > > >
> > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > >
> > > > > I agree that there are no rules broken for a tree that is included in
> > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > tree being included in next.
> > > > >
> > > > > Still I think that shouldn't be used as an excuse.
> > > >
> > > > As an excuse for what?
> > >
> > > Just because the rules for trees in next allow the merged branch to be
> > > rewritten, shouldn't be used to justify rewriting the branch.
> > >
> > > IMHO you still should ensure that only commits make it into any next
> > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > intend to be included in X-rc1.
> >
> > That's never been a next rule either. Rust support has been in next for
> > almost a year without being sent as a PR for example.
>
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
>
> "The linux-next tree is, by design, a snapshot of what the mainline
> is expected to look like after the next merge window closes."
>
> The general rule for linux-next is that its contents are intended to end
> up in the next kernel release, and that it should not contain commits
> that are intended for the next-next release, cfr. what Stephen sends
> out to new trees:
>
> "You will need to ensure that the patches/commits in your tree/series have
> been:
> [...]
> * destined for the current or next Linux merge window."
>
> and what he requests regularly in his announces, e.g.:
>
> "Please do not add any v6.4 related commits to your linux-next included
> branches until after v6.3-rc1 has been released."
Which is why those patches aren't in next anymore.
> AFAIU, the exception to the rule is new, self-contained, and sometimes
> controversial development, which may have to cook for a few more cycles,
> if it ends up in a PR at all.
>
> > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > send it to Linus during the next merge window.".
> > > >
> > > > I mean, that's what we're saying and doing?
> > >
> > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > was part of next-20230609). A few days later however the patches were
> > > dropped.
> > >
> > > The two options that would have made the experience smoother for me are:
> > >
> > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> >
> > That's not an option. You were simply too late for v6.5-rc1, unless you
> > expect us to get rid of timezones and work on week-ends. But surely you
> > don't.
>
> I don't think anyone expects you to do that...
>
> > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > before v6.5-rc1.
> >
> > All the drm-misc committers use dim. If that's a concern for you, feel
> > free to send a patch addressing this to dim.
>
> So you say this is an issue with the tooling? ;-)
> If the tooling breaks the rules, perhaps the tooling should be fixed?
We've been using dim for more than 5 years. It doesn't seem to work too bad?
And it does feel like the goalposts are moving there: the discussion
started by "you shouldn't rebase a tree" and is now at "patches should
never be in a next branch if they can't reach the next merge window,
even though it's not apparent yet"
But yeah, I now that complaining about how much drm-misc sucks is fun
and all, but it's still not clear to me what a potential solution to
this would be?
Knowing that we can't rebase or close drm-misc-next, and that it should
be automated in dim somehow, what would that fix be?
> > So yeah, sorry if it was confusing. At the end of the day, it's a
> > compromise, and I can't find a better one for everyone involved
> > (maintainers, contributors and committers alike) off the top of my head.
>
> As I understand, the main issue Uwe is objecting to, is that his
> patches ended up in linux-next first, only to be dropped again from
> linux-next later, and that there was no communication about the
> latter.
>
> If you're not constantly working on a subsystem, it can be very hard
> to keep track of the status of your own drive-by patches. When patches
> get applied, appear in linux-next, and disappear from linux-next again
> later, it's worse...
Sure, I've worked with enough of these series to understand how it can
be annoying.
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/eccf050c/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 14:02 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 14:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Alain Volmat, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Stephen Rothwell, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Jonathan Hunter,
linux-rockchip, Ben Skeggs, Russell King, Jessica Zhang,
linux-mips, Liu Ying, linux-arm-msm, Wang Jianzheng,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
linux-mediatek, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Doug Anderson, Paul Cercueil,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 7820 bytes --]
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > tags:
> > > > > > > > >
> > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > next-20230609
> > > > > > > > > next-20230613
> > > > > > > > > next-20230614
> > > > > > > > > next-20230615
> > > > > > > > >
> > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > >
> > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > 2 Jessica Zhang
> > > > > > > > > 5 Karol Wachowski
> > > > > > > > > 1 Laura Nao
> > > > > > > > > 27 Uwe Kleine-König
> > > > > > > > > 1 Wang Jianzheng
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > again?
> > > > > > > >
> > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > >
> > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > >
> > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > >
> > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > expected, is it?
> > > > > >
> > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > >
> > > > > I agree that there are no rules broken for a tree that is included in
> > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > tree being included in next.
> > > > >
> > > > > Still I think that shouldn't be used as an excuse.
> > > >
> > > > As an excuse for what?
> > >
> > > Just because the rules for trees in next allow the merged branch to be
> > > rewritten, shouldn't be used to justify rewriting the branch.
> > >
> > > IMHO you still should ensure that only commits make it into any next
> > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > intend to be included in X-rc1.
> >
> > That's never been a next rule either. Rust support has been in next for
> > almost a year without being sent as a PR for example.
>
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
>
> "The linux-next tree is, by design, a snapshot of what the mainline
> is expected to look like after the next merge window closes."
>
> The general rule for linux-next is that its contents are intended to end
> up in the next kernel release, and that it should not contain commits
> that are intended for the next-next release, cfr. what Stephen sends
> out to new trees:
>
> "You will need to ensure that the patches/commits in your tree/series have
> been:
> [...]
> * destined for the current or next Linux merge window."
>
> and what he requests regularly in his announces, e.g.:
>
> "Please do not add any v6.4 related commits to your linux-next included
> branches until after v6.3-rc1 has been released."
Which is why those patches aren't in next anymore.
> AFAIU, the exception to the rule is new, self-contained, and sometimes
> controversial development, which may have to cook for a few more cycles,
> if it ends up in a PR at all.
>
> > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > send it to Linus during the next merge window.".
> > > >
> > > > I mean, that's what we're saying and doing?
> > >
> > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > was part of next-20230609). A few days later however the patches were
> > > dropped.
> > >
> > > The two options that would have made the experience smoother for me are:
> > >
> > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> >
> > That's not an option. You were simply too late for v6.5-rc1, unless you
> > expect us to get rid of timezones and work on week-ends. But surely you
> > don't.
>
> I don't think anyone expects you to do that...
>
> > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > before v6.5-rc1.
> >
> > All the drm-misc committers use dim. If that's a concern for you, feel
> > free to send a patch addressing this to dim.
>
> So you say this is an issue with the tooling? ;-)
> If the tooling breaks the rules, perhaps the tooling should be fixed?
We've been using dim for more than 5 years. It doesn't seem to work too bad?
And it does feel like the goalposts are moving there: the discussion
started by "you shouldn't rebase a tree" and is now at "patches should
never be in a next branch if they can't reach the next merge window,
even though it's not apparent yet"
But yeah, I now that complaining about how much drm-misc sucks is fun
and all, but it's still not clear to me what a potential solution to
this would be?
Knowing that we can't rebase or close drm-misc-next, and that it should
be automated in dim somehow, what would that fix be?
> > So yeah, sorry if it was confusing. At the end of the day, it's a
> > compromise, and I can't find a better one for everyone involved
> > (maintainers, contributors and committers alike) off the top of my head.
>
> As I understand, the main issue Uwe is objecting to, is that his
> patches ended up in linux-next first, only to be dropped again from
> linux-next later, and that there was no communication about the
> latter.
>
> If you're not constantly working on a subsystem, it can be very hard
> to keep track of the status of your own drive-by patches. When patches
> get applied, appear in linux-next, and disappear from linux-next again
> later, it's worse...
Sure, I've worked with enough of these series to understand how it can
be annoying.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 14:02 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 14:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, Miaoqian Lin, Uwe Kleine-König,
linux-sunxi, Rob Clark, Rahul T R, Raphael Gallais-Pou,
Jani Nikula, Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae,
Alain Volmat, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä,
Stephen Rothwell, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Daniel Vetter,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 7820 bytes --]
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > tags:
> > > > > > > > >
> > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > next-20230609
> > > > > > > > > next-20230613
> > > > > > > > > next-20230614
> > > > > > > > > next-20230615
> > > > > > > > >
> > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > >
> > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > 2 Jessica Zhang
> > > > > > > > > 5 Karol Wachowski
> > > > > > > > > 1 Laura Nao
> > > > > > > > > 27 Uwe Kleine-König
> > > > > > > > > 1 Wang Jianzheng
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > again?
> > > > > > > >
> > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > >
> > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > >
> > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > >
> > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > expected, is it?
> > > > > >
> > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > >
> > > > > I agree that there are no rules broken for a tree that is included in
> > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > tree being included in next.
> > > > >
> > > > > Still I think that shouldn't be used as an excuse.
> > > >
> > > > As an excuse for what?
> > >
> > > Just because the rules for trees in next allow the merged branch to be
> > > rewritten, shouldn't be used to justify rewriting the branch.
> > >
> > > IMHO you still should ensure that only commits make it into any next
> > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > intend to be included in X-rc1.
> >
> > That's never been a next rule either. Rust support has been in next for
> > almost a year without being sent as a PR for example.
>
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
>
> "The linux-next tree is, by design, a snapshot of what the mainline
> is expected to look like after the next merge window closes."
>
> The general rule for linux-next is that its contents are intended to end
> up in the next kernel release, and that it should not contain commits
> that are intended for the next-next release, cfr. what Stephen sends
> out to new trees:
>
> "You will need to ensure that the patches/commits in your tree/series have
> been:
> [...]
> * destined for the current or next Linux merge window."
>
> and what he requests regularly in his announces, e.g.:
>
> "Please do not add any v6.4 related commits to your linux-next included
> branches until after v6.3-rc1 has been released."
Which is why those patches aren't in next anymore.
> AFAIU, the exception to the rule is new, self-contained, and sometimes
> controversial development, which may have to cook for a few more cycles,
> if it ends up in a PR at all.
>
> > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > send it to Linus during the next merge window.".
> > > >
> > > > I mean, that's what we're saying and doing?
> > >
> > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > was part of next-20230609). A few days later however the patches were
> > > dropped.
> > >
> > > The two options that would have made the experience smoother for me are:
> > >
> > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> >
> > That's not an option. You were simply too late for v6.5-rc1, unless you
> > expect us to get rid of timezones and work on week-ends. But surely you
> > don't.
>
> I don't think anyone expects you to do that...
>
> > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > before v6.5-rc1.
> >
> > All the drm-misc committers use dim. If that's a concern for you, feel
> > free to send a patch addressing this to dim.
>
> So you say this is an issue with the tooling? ;-)
> If the tooling breaks the rules, perhaps the tooling should be fixed?
We've been using dim for more than 5 years. It doesn't seem to work too bad?
And it does feel like the goalposts are moving there: the discussion
started by "you shouldn't rebase a tree" and is now at "patches should
never be in a next branch if they can't reach the next merge window,
even though it's not apparent yet"
But yeah, I now that complaining about how much drm-misc sucks is fun
and all, but it's still not clear to me what a potential solution to
this would be?
Knowing that we can't rebase or close drm-misc-next, and that it should
be automated in dim somehow, what would that fix be?
> > So yeah, sorry if it was confusing. At the end of the day, it's a
> > compromise, and I can't find a better one for everyone involved
> > (maintainers, contributors and committers alike) off the top of my head.
>
> As I understand, the main issue Uwe is objecting to, is that his
> patches ended up in linux-next first, only to be dropped again from
> linux-next later, and that there was no communication about the
> latter.
>
> If you're not constantly working on a subsystem, it can be very hard
> to keep track of the status of your own drive-by patches. When patches
> get applied, appear in linux-next, and disappear from linux-next again
> later, it's worse...
Sure, I've worked with enough of these series to understand how it can
be annoying.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 14:02 ` Maxime Ripard
0 siblings, 0 replies; 261+ messages in thread
From: Maxime Ripard @ 2023-06-19 14:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Uwe Kleine-König, Raymond Tan, Heiko Stübner,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Nicolas Ferre, Wang Jianzheng, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Karol Herbst, Miaoqian Lin,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Lyude Paul,
Arnd Bergmann, Guo Zhengkui, Liviu Dudau, Alison Wang,
Abhinav Kumar, Christian Gmeiner, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, David Airlie, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
Stephen Boyd, AngeloGioacchino Del Regno, Yannick Fertre,
linux-mips, Rob Clark, Philippe Cornu, Daniel Vetter,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach, Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 7820 bytes --]
On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> CC sfr
>
> On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > tags:
> > > > > > > > >
> > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > next-20230609
> > > > > > > > > next-20230613
> > > > > > > > > next-20230614
> > > > > > > > > next-20230615
> > > > > > > > >
> > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > >
> > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > 2 Jessica Zhang
> > > > > > > > > 5 Karol Wachowski
> > > > > > > > > 1 Laura Nao
> > > > > > > > > 27 Uwe Kleine-König
> > > > > > > > > 1 Wang Jianzheng
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > again?
> > > > > > > >
> > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > >
> > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > >
> > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > >
> > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > expected, is it?
> > > > > >
> > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > >
> > > > > I agree that there are no rules broken for a tree that is included in
> > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > tree being included in next.
> > > > >
> > > > > Still I think that shouldn't be used as an excuse.
> > > >
> > > > As an excuse for what?
> > >
> > > Just because the rules for trees in next allow the merged branch to be
> > > rewritten, shouldn't be used to justify rewriting the branch.
> > >
> > > IMHO you still should ensure that only commits make it into any next
> > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > intend to be included in X-rc1.
> >
> > That's never been a next rule either. Rust support has been in next for
> > almost a year without being sent as a PR for example.
>
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
>
> "The linux-next tree is, by design, a snapshot of what the mainline
> is expected to look like after the next merge window closes."
>
> The general rule for linux-next is that its contents are intended to end
> up in the next kernel release, and that it should not contain commits
> that are intended for the next-next release, cfr. what Stephen sends
> out to new trees:
>
> "You will need to ensure that the patches/commits in your tree/series have
> been:
> [...]
> * destined for the current or next Linux merge window."
>
> and what he requests regularly in his announces, e.g.:
>
> "Please do not add any v6.4 related commits to your linux-next included
> branches until after v6.3-rc1 has been released."
Which is why those patches aren't in next anymore.
> AFAIU, the exception to the rule is new, self-contained, and sometimes
> controversial development, which may have to cook for a few more cycles,
> if it ends up in a PR at all.
>
> > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > send it to Linus during the next merge window.".
> > > >
> > > > I mean, that's what we're saying and doing?
> > >
> > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > was part of next-20230609). A few days later however the patches were
> > > dropped.
> > >
> > > The two options that would have made the experience smoother for me are:
> > >
> > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> >
> > That's not an option. You were simply too late for v6.5-rc1, unless you
> > expect us to get rid of timezones and work on week-ends. But surely you
> > don't.
>
> I don't think anyone expects you to do that...
>
> > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > before v6.5-rc1.
> >
> > All the drm-misc committers use dim. If that's a concern for you, feel
> > free to send a patch addressing this to dim.
>
> So you say this is an issue with the tooling? ;-)
> If the tooling breaks the rules, perhaps the tooling should be fixed?
We've been using dim for more than 5 years. It doesn't seem to work too bad?
And it does feel like the goalposts are moving there: the discussion
started by "you shouldn't rebase a tree" and is now at "patches should
never be in a next branch if they can't reach the next merge window,
even though it's not apparent yet"
But yeah, I now that complaining about how much drm-misc sucks is fun
and all, but it's still not clear to me what a potential solution to
this would be?
Knowing that we can't rebase or close drm-misc-next, and that it should
be automated in dim somehow, what would that fix be?
> > So yeah, sorry if it was confusing. At the end of the day, it's a
> > compromise, and I can't find a better one for everyone involved
> > (maintainers, contributors and committers alike) off the top of my head.
>
> As I understand, the main issue Uwe is objecting to, is that his
> patches ended up in linux-next first, only to be dropped again from
> linux-next later, and that there was no communication about the
> latter.
>
> If you're not constantly working on a subsystem, it can be very hard
> to keep track of the status of your own drive-by patches. When patches
> get applied, appear in linux-next, and disappear from linux-next again
> later, it's worse...
Sure, I've worked with enough of these series to understand how it can
be annoying.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 261+ messages in thread* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 14:02 ` Maxime Ripard
(?)
(?)
@ 2023-06-19 14:20 ` Geert Uytterhoeven
-1 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 14:20 UTC (permalink / raw)
To: linux-aspeed
Hi Maxime,
On Mon, Jun 19, 2023 at 4:02?PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51?PM Maxime Ripard <mripard@kernel.org> wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > > tags:
> > > > > > > > > >
> > > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > > next-20230609
> > > > > > > > > > next-20230613
> > > > > > > > > > next-20230614
> > > > > > > > > > next-20230615
> > > > > > > > > >
> > > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > > >
> > > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > > 2 Jessica Zhang
> > > > > > > > > > 5 Karol Wachowski
> > > > > > > > > > 1 Laura Nao
> > > > > > > > > > 27 Uwe Kleine-K?nig
> > > > > > > > > > 1 Wang Jianzheng
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > > again?
> > > > > > > > >
> > > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > > >
> > > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > > >
> > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > > >
> > > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > > expected, is it?
> > > > > > >
> > > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > > >
> > > > > > I agree that there are no rules broken for a tree that is included in
> > > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > > tree being included in next.
> > > > > >
> > > > > > Still I think that shouldn't be used as an excuse.
> > > > >
> > > > > As an excuse for what?
> > > >
> > > > Just because the rules for trees in next allow the merged branch to be
> > > > rewritten, shouldn't be used to justify rewriting the branch.
> > > >
> > > > IMHO you still should ensure that only commits make it into any next
> > > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > > intend to be included in X-rc1.
> > >
> > > That's never been a next rule either. Rust support has been in next for
> > > almost a year without being sent as a PR for example.
> >
> > https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
> >
> > "The linux-next tree is, by design, a snapshot of what the mainline
> > is expected to look like after the next merge window closes."
> >
> > The general rule for linux-next is that its contents are intended to end
> > up in the next kernel release, and that it should not contain commits
> > that are intended for the next-next release, cfr. what Stephen sends
> > out to new trees:
> >
> > "You will need to ensure that the patches/commits in your tree/series have
> > been:
> > [...]
> > * destined for the current or next Linux merge window."
> >
> > and what he requests regularly in his announces, e.g.:
> >
> > "Please do not add any v6.4 related commits to your linux-next included
> > branches until after v6.3-rc1 has been released."
>
> Which is why those patches aren't in next anymore.
So why were they in linux-next before?
Was this a genuine mistake (things happen), or is there process
or tooling to improve?
> > AFAIU, the exception to the rule is new, self-contained, and sometimes
> > controversial development, which may have to cook for a few more cycles,
> > if it ends up in a PR at all.
> >
> > > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > > send it to Linus during the next merge window.".
> > > > >
> > > > > I mean, that's what we're saying and doing?
> > > >
> > > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > > was part of next-20230609). A few days later however the patches were
> > > > dropped.
> > > >
> > > > The two options that would have made the experience smoother for me are:
> > > >
> > > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> > >
> > > That's not an option. You were simply too late for v6.5-rc1, unless you
> > > expect us to get rid of timezones and work on week-ends. But surely you
> > > don't.
> >
> > I don't think anyone expects you to do that...
> >
> > > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > > before v6.5-rc1.
> > >
> > > All the drm-misc committers use dim. If that's a concern for you, feel
> > > free to send a patch addressing this to dim.
> >
> > So you say this is an issue with the tooling? ;-)
> > If the tooling breaks the rules, perhaps the tooling should be fixed?
>
> We've been using dim for more than 5 years. It doesn't seem to work too bad?
I don't know anything about dim, so I cannot commit on that.
> And it does feel like the goalposts are moving there: the discussion
> started by "you shouldn't rebase a tree" and is now at "patches should
> never be in a next branch if they can't reach the next merge window,
> even though it's not apparent yet"
There is no such anti-rebasing rule for linux-next.
Some branches and some subsystems do have a non-rebasing rule,
but that's not applicable here, AFAIU.
Besides, won't you have to rebase the remaining commits from
drm-misc-next on top of v6.5-rc1 anyway later?
> But yeah, I now that complaining about how much drm-misc sucks is fun
> and all, but it's still not clear to me what a potential solution to
> this would be?
I'm so glad I'm not the one making personal attacks on drm-misc ;-)
> Knowing that we can't rebase or close drm-misc-next, and that it should
> be automated in dim somehow, what would that fix be?
Again, I don't know what dim does.
But I think the solution involves not merging anything in drm-next
if there is reason to believe it won't make the next merge window
(in this case: when it is applied to drm-misc-next after the cut-off point).
Personally, I use foo-for-vX.Y branches. Despite some of my
foo-for-v6.6 branches already having new commits, I just hold off
merging any of them in a for-next branch until after v6.5-rc1.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 14:20 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 14:20 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Steven Price,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Karol Herbst, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, Miaoqian Lin,
Uwe Kleine-König, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Alain Volmat, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Stephen Rothwell, lima,
Chunyan Zhang, Alexey Brodkin, Minghao Chi, Jonathan Hunter,
linux-rockchip, Ben Skeggs, Russell King, Jessica Zhang,
linux-mips, Liu Ying, linux-arm-msm, Wang Jianzheng,
linux-amlogic, linux-arm-kernel, Neil Armstrong, Boris Brezillon,
Sandy Huang, Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
linux-mediatek, Kuninori Morimoto, Yuan Can, Michal Simek,
linux-tegra, Laurent Pinchart, Andrzej Hajda, Sam Ravnborg,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Mark Brown, Baolin Wang, Liu Shixin, Tomi Valkeinen,
Deepak R Varma, Karol Wachowski, Kieran Bingham, Ricardo Ribalda,
Tian Tao, Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt,
Liviu Dudau, Alexandre Torgue, Doug Anderson, Paul Cercueil,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Laurentiu Palcu, Matthias Brugger,
AngeloGioacchino Del Regno, Bjorn Andersson, Nicolas Ferre,
Krzysztof Kozlowski, Qiang Yu, Dmitry Baryshkov, Jyri Sarha
Hi Maxime,
On Mon, Jun 19, 2023 at 4:02 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > > tags:
> > > > > > > > > >
> > > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > > next-20230609
> > > > > > > > > > next-20230613
> > > > > > > > > > next-20230614
> > > > > > > > > > next-20230615
> > > > > > > > > >
> > > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > > >
> > > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > > 2 Jessica Zhang
> > > > > > > > > > 5 Karol Wachowski
> > > > > > > > > > 1 Laura Nao
> > > > > > > > > > 27 Uwe Kleine-König
> > > > > > > > > > 1 Wang Jianzheng
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > > again?
> > > > > > > > >
> > > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > > >
> > > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > > >
> > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > > >
> > > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > > expected, is it?
> > > > > > >
> > > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > > >
> > > > > > I agree that there are no rules broken for a tree that is included in
> > > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > > tree being included in next.
> > > > > >
> > > > > > Still I think that shouldn't be used as an excuse.
> > > > >
> > > > > As an excuse for what?
> > > >
> > > > Just because the rules for trees in next allow the merged branch to be
> > > > rewritten, shouldn't be used to justify rewriting the branch.
> > > >
> > > > IMHO you still should ensure that only commits make it into any next
> > > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > > intend to be included in X-rc1.
> > >
> > > That's never been a next rule either. Rust support has been in next for
> > > almost a year without being sent as a PR for example.
> >
> > https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
> >
> > "The linux-next tree is, by design, a snapshot of what the mainline
> > is expected to look like after the next merge window closes."
> >
> > The general rule for linux-next is that its contents are intended to end
> > up in the next kernel release, and that it should not contain commits
> > that are intended for the next-next release, cfr. what Stephen sends
> > out to new trees:
> >
> > "You will need to ensure that the patches/commits in your tree/series have
> > been:
> > [...]
> > * destined for the current or next Linux merge window."
> >
> > and what he requests regularly in his announces, e.g.:
> >
> > "Please do not add any v6.4 related commits to your linux-next included
> > branches until after v6.3-rc1 has been released."
>
> Which is why those patches aren't in next anymore.
So why were they in linux-next before?
Was this a genuine mistake (things happen), or is there process
or tooling to improve?
> > AFAIU, the exception to the rule is new, self-contained, and sometimes
> > controversial development, which may have to cook for a few more cycles,
> > if it ends up in a PR at all.
> >
> > > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > > send it to Linus during the next merge window.".
> > > > >
> > > > > I mean, that's what we're saying and doing?
> > > >
> > > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > > was part of next-20230609). A few days later however the patches were
> > > > dropped.
> > > >
> > > > The two options that would have made the experience smoother for me are:
> > > >
> > > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> > >
> > > That's not an option. You were simply too late for v6.5-rc1, unless you
> > > expect us to get rid of timezones and work on week-ends. But surely you
> > > don't.
> >
> > I don't think anyone expects you to do that...
> >
> > > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > > before v6.5-rc1.
> > >
> > > All the drm-misc committers use dim. If that's a concern for you, feel
> > > free to send a patch addressing this to dim.
> >
> > So you say this is an issue with the tooling? ;-)
> > If the tooling breaks the rules, perhaps the tooling should be fixed?
>
> We've been using dim for more than 5 years. It doesn't seem to work too bad?
I don't know anything about dim, so I cannot commit on that.
> And it does feel like the goalposts are moving there: the discussion
> started by "you shouldn't rebase a tree" and is now at "patches should
> never be in a next branch if they can't reach the next merge window,
> even though it's not apparent yet"
There is no such anti-rebasing rule for linux-next.
Some branches and some subsystems do have a non-rebasing rule,
but that's not applicable here, AFAIU.
Besides, won't you have to rebase the remaining commits from
drm-misc-next on top of v6.5-rc1 anyway later?
> But yeah, I now that complaining about how much drm-misc sucks is fun
> and all, but it's still not clear to me what a potential solution to
> this would be?
I'm so glad I'm not the one making personal attacks on drm-misc ;-)
> Knowing that we can't rebase or close drm-misc-next, and that it should
> be automated in dim somehow, what would that fix be?
Again, I don't know what dim does.
But I think the solution involves not merging anything in drm-next
if there is reason to believe it won't make the next merge window
(in this case: when it is applied to drm-misc-next after the cut-off point).
Personally, I use foo-for-vX.Y branches. Despite some of my
foo-for-v6.6 branches already having new commits, I just hold off
merging any of them in a for-next branch until after v6.5-rc1.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 14:20 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 14:20 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, Miaoqian Lin, Uwe Kleine-König,
linux-sunxi, Rob Clark, Rahul T R, Raphael Gallais-Pou,
Jani Nikula, Sascha Hauer, etnaviv, Stephen Boyd, Inki Dae,
Alain Volmat, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Alexandre Belloni,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä,
Stephen Rothwell, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, linux-rockchip, Ben Skeggs, Russell King,
Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann,
Guo Zhengkui, Konrad Dybcio, Alison Wang, Abhinav Kumar,
Christian Gmeiner, Mark Brown, Baolin Wang, Daniel Vetter,
Liu Shixin, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
Marek Vasut, linux-renesas-soc, Yongqin Liu, Jayshri Pawar,
Jonas Karlman, Russell King, Martin Blumenstingl, Philippe Cornu,
Melissa Wen, Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach
Hi Maxime,
On Mon, Jun 19, 2023 at 4:02 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > > tags:
> > > > > > > > > >
> > > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > > next-20230609
> > > > > > > > > > next-20230613
> > > > > > > > > > next-20230614
> > > > > > > > > > next-20230615
> > > > > > > > > >
> > > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > > >
> > > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > > 2 Jessica Zhang
> > > > > > > > > > 5 Karol Wachowski
> > > > > > > > > > 1 Laura Nao
> > > > > > > > > > 27 Uwe Kleine-König
> > > > > > > > > > 1 Wang Jianzheng
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > > again?
> > > > > > > > >
> > > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > > >
> > > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > > >
> > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > > >
> > > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > > expected, is it?
> > > > > > >
> > > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > > >
> > > > > > I agree that there are no rules broken for a tree that is included in
> > > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > > tree being included in next.
> > > > > >
> > > > > > Still I think that shouldn't be used as an excuse.
> > > > >
> > > > > As an excuse for what?
> > > >
> > > > Just because the rules for trees in next allow the merged branch to be
> > > > rewritten, shouldn't be used to justify rewriting the branch.
> > > >
> > > > IMHO you still should ensure that only commits make it into any next
> > > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > > intend to be included in X-rc1.
> > >
> > > That's never been a next rule either. Rust support has been in next for
> > > almost a year without being sent as a PR for example.
> >
> > https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
> >
> > "The linux-next tree is, by design, a snapshot of what the mainline
> > is expected to look like after the next merge window closes."
> >
> > The general rule for linux-next is that its contents are intended to end
> > up in the next kernel release, and that it should not contain commits
> > that are intended for the next-next release, cfr. what Stephen sends
> > out to new trees:
> >
> > "You will need to ensure that the patches/commits in your tree/series have
> > been:
> > [...]
> > * destined for the current or next Linux merge window."
> >
> > and what he requests regularly in his announces, e.g.:
> >
> > "Please do not add any v6.4 related commits to your linux-next included
> > branches until after v6.3-rc1 has been released."
>
> Which is why those patches aren't in next anymore.
So why were they in linux-next before?
Was this a genuine mistake (things happen), or is there process
or tooling to improve?
> > AFAIU, the exception to the rule is new, self-contained, and sometimes
> > controversial development, which may have to cook for a few more cycles,
> > if it ends up in a PR at all.
> >
> > > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > > send it to Linus during the next merge window.".
> > > > >
> > > > > I mean, that's what we're saying and doing?
> > > >
> > > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > > was part of next-20230609). A few days later however the patches were
> > > > dropped.
> > > >
> > > > The two options that would have made the experience smoother for me are:
> > > >
> > > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> > >
> > > That's not an option. You were simply too late for v6.5-rc1, unless you
> > > expect us to get rid of timezones and work on week-ends. But surely you
> > > don't.
> >
> > I don't think anyone expects you to do that...
> >
> > > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > > before v6.5-rc1.
> > >
> > > All the drm-misc committers use dim. If that's a concern for you, feel
> > > free to send a patch addressing this to dim.
> >
> > So you say this is an issue with the tooling? ;-)
> > If the tooling breaks the rules, perhaps the tooling should be fixed?
>
> We've been using dim for more than 5 years. It doesn't seem to work too bad?
I don't know anything about dim, so I cannot commit on that.
> And it does feel like the goalposts are moving there: the discussion
> started by "you shouldn't rebase a tree" and is now at "patches should
> never be in a next branch if they can't reach the next merge window,
> even though it's not apparent yet"
There is no such anti-rebasing rule for linux-next.
Some branches and some subsystems do have a non-rebasing rule,
but that's not applicable here, AFAIU.
Besides, won't you have to rebase the remaining commits from
drm-misc-next on top of v6.5-rc1 anyway later?
> But yeah, I now that complaining about how much drm-misc sucks is fun
> and all, but it's still not clear to me what a potential solution to
> this would be?
I'm so glad I'm not the one making personal attacks on drm-misc ;-)
> Knowing that we can't rebase or close drm-misc-next, and that it should
> be automated in dim somehow, what would that fix be?
Again, I don't know what dim does.
But I think the solution involves not merging anything in drm-next
if there is reason to believe it won't make the next merge window
(in this case: when it is applied to drm-misc-next after the cut-off point).
Personally, I use foo-for-vX.Y branches. Despite some of my
foo-for-v6.6 branches already having new commits, I just hold off
merging any of them in a for-next branch until after v6.5-rc1.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 14:20 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 14:20 UTC (permalink / raw)
To: Maxime Ripard
Cc: Uwe Kleine-König, Raymond Tan, Heiko Stübner,
Akhil P Oommen, Linus Walleij, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea,
Alexandre Belloni, linux-aspeed, Tomi Valkeinen, Thierry Reding,
John Stultz, Mihail Atanassov, Liang He, Ville Syrjälä,
lima, Chunyan Zhang, Alexey Brodkin, Minghao Chi, Steven Price,
linux-rockchip, Ben Skeggs, Russell King, Alain Volmat, Liu Ying,
linux-arm-msm, Nicolas Ferre, Wang Jianzheng, linux-amlogic,
linux-arm-kernel, Neil Armstrong, Boris Brezillon, Sandy Huang,
Paul Kocialkowski, Kyungmin Park, Maxime Coquelin,
Christophe JAILLET, Brian Starkey, Karol Herbst, Miaoqian Lin,
Stefan Agner, Michal Simek, Matthias Brugger, Laurent Pinchart,
Andrzej Hajda, Sam Ravnborg, Rob Herring, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu, Lyude Paul,
Arnd Bergmann, Guo Zhengkui, Liviu Dudau, Alison Wang,
Abhinav Kumar, Christian Gmeiner, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, David Airlie, Marek Vasut, linux-renesas-soc,
Yongqin Liu, Jayshri Pawar, Jonas Karlman, Russell King,
Martin Blumenstingl, Qiang Yu, Thomas Zimmermann, Melissa Wen,
linux-mediatek, Fabio Estevam, Laurentiu Palcu, linux-tegra,
Stephen Boyd, AngeloGioacchino Del Regno, Yannick Fertre,
linux-mips, Rob Clark, Philippe Cornu, Daniel Vetter,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach, Stephen Rothwell
Hi Maxime,
On Mon, Jun 19, 2023 at 4:02 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-König wrote:
> > > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-König wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > > On Sat, Jun 17, 2023 at 9:15 AM Uwe Kleine-König
> > > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > > tags:
> > > > > > > > > >
> > > > > > > > > > $ git tag -l --contains c2807ecb5290
> > > > > > > > > > next-20230609
> > > > > > > > > > next-20230613
> > > > > > > > > > next-20230614
> > > > > > > > > > next-20230615
> > > > > > > > > >
> > > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > > >
> > > > > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > > 1 Christophe JAILLET
> > > > > > > > > > 2 Jessica Zhang
> > > > > > > > > > 5 Karol Wachowski
> > > > > > > > > > 1 Laura Nao
> > > > > > > > > > 27 Uwe Kleine-König
> > > > > > > > > > 1 Wang Jianzheng
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > > again?
> > > > > > > > >
> > > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > > >
> > > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > > >
> > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > > >
> > > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > > expected, is it?
> > > > > > >
> > > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > > >
> > > > > > I agree that there are no rules broken for a tree that is included in
> > > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > > tree being included in next.
> > > > > >
> > > > > > Still I think that shouldn't be used as an excuse.
> > > > >
> > > > > As an excuse for what?
> > > >
> > > > Just because the rules for trees in next allow the merged branch to be
> > > > rewritten, shouldn't be used to justify rewriting the branch.
> > > >
> > > > IMHO you still should ensure that only commits make it into any next
> > > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > > intend to be included in X-rc1.
> > >
> > > That's never been a next rule either. Rust support has been in next for
> > > almost a year without being sent as a PR for example.
> >
> > https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
> >
> > "The linux-next tree is, by design, a snapshot of what the mainline
> > is expected to look like after the next merge window closes."
> >
> > The general rule for linux-next is that its contents are intended to end
> > up in the next kernel release, and that it should not contain commits
> > that are intended for the next-next release, cfr. what Stephen sends
> > out to new trees:
> >
> > "You will need to ensure that the patches/commits in your tree/series have
> > been:
> > [...]
> > * destined for the current or next Linux merge window."
> >
> > and what he requests regularly in his announces, e.g.:
> >
> > "Please do not add any v6.4 related commits to your linux-next included
> > branches until after v6.3-rc1 has been released."
>
> Which is why those patches aren't in next anymore.
So why were they in linux-next before?
Was this a genuine mistake (things happen), or is there process
or tooling to improve?
> > AFAIU, the exception to the rule is new, self-contained, and sometimes
> > controversial development, which may have to cook for a few more cycles,
> > if it ends up in a PR at all.
> >
> > > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > > send it to Linus during the next merge window.".
> > > > >
> > > > > I mean, that's what we're saying and doing?
> > > >
> > > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > > was part of next-20230609). A few days later however the patches were
> > > > dropped.
> > > >
> > > > The two options that would have made the experience smoother for me are:
> > > >
> > > > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> > >
> > > That's not an option. You were simply too late for v6.5-rc1, unless you
> > > expect us to get rid of timezones and work on week-ends. But surely you
> > > don't.
> >
> > I don't think anyone expects you to do that...
> >
> > > > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > > before v6.5-rc1.
> > >
> > > All the drm-misc committers use dim. If that's a concern for you, feel
> > > free to send a patch addressing this to dim.
> >
> > So you say this is an issue with the tooling? ;-)
> > If the tooling breaks the rules, perhaps the tooling should be fixed?
>
> We've been using dim for more than 5 years. It doesn't seem to work too bad?
I don't know anything about dim, so I cannot commit on that.
> And it does feel like the goalposts are moving there: the discussion
> started by "you shouldn't rebase a tree" and is now at "patches should
> never be in a next branch if they can't reach the next merge window,
> even though it's not apparent yet"
There is no such anti-rebasing rule for linux-next.
Some branches and some subsystems do have a non-rebasing rule,
but that's not applicable here, AFAIU.
Besides, won't you have to rebase the remaining commits from
drm-misc-next on top of v6.5-rc1 anyway later?
> But yeah, I now that complaining about how much drm-misc sucks is fun
> and all, but it's still not clear to me what a potential solution to
> this would be?
I'm so glad I'm not the one making personal attacks on drm-misc ;-)
> Knowing that we can't rebase or close drm-misc-next, and that it should
> be automated in dim somehow, what would that fix be?
Again, I don't know what dim does.
But I think the solution involves not merging anything in drm-next
if there is reason to believe it won't make the next merge window
(in this case: when it is applied to drm-misc-next after the cut-off point).
Personally, I use foo-for-vX.Y branches. Despite some of my
foo-for-v6.6 branches already having new commits, I just hold off
merging any of them in a for-next branch until after v6.5-rc1.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread
* patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 12:47 ` Maxime Ripard
(?)
(?)
@ 2023-06-19 13:58 ` Uwe Kleine-König
-1 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 13:58 UTC (permalink / raw)
To: linux-aspeed
Hello Maxime,
On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
It seems not to be rigorously enforced, but it exists. See for example
https://lore.kernel.org/all/20230510092313.16693e4c at canb.auug.org.au/ .
@Stephen: you wrote there
You will need to ensure that the patches/commits in your
tree/series have been [...] destined for the current or next
Linux merge window.
This is a bit ambiguous because (AFAIK) during a merge window no patches
should be added that are supposed to go in during the next one, right?
Maybe adapt your template to read:
[...] destined to be included in the next -rc1 release.
which is more precise?
Even if others don't adhere to it, IMHO it's still an opportunity to
improve. Also there is a difference between a patch that is included in
next that doesn't make it in during the next merge window and a patch
that disappears from next. The latter (up to now) only happened to me
when there was a problem with the patch and the maintainer who first
thought the patch to be fine changed their opinion.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
We're mixing two things here. One is: "When will my patches be merged?".
I have no problem being patient here and b) is fine for me. The other is
"The patches first being included in next and then later not anymore
is a thing that just waits to be misinterpreted". This latter is the one
I care about here and that I think should be fixed for the future.
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
Not sure this is sensible given that I neither use nor know dim. Also I
think it should be the drm-misc maintainers who should care here given
that it's them who create this unfortunate situation again and again.
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next.
That's nitpicking and little helpful here. In your bubble where only or
mostly drm-misc matters it's ok to only look at drm-misc. But for a
contributor who sends patches for dozens of subsystems next is the more
useful place to look and each subsystem that is special is an obstacle.
> If they did, it's mostly an unfortunate artifact.
I see some progress in this discussion as you seem to agree this is
unfortunate. Actually that's all I intend to achieve.
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
>
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
>
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
Not knowing dim I think there is a simple(?) technical solution here: It
only has to make sure that after the pull request from drm-misc to drm
was sent, no new patches are added to the branch that is merged in next.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/4a8762bd/attachment-0001.sig>
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 13:58 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 13:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Akhil P Oommen, dri-devel, Stanislaw Gruszka,
Alim Akhtar, Anitha Chrisanthus, Marijn Suijten, Jonathan Hunter,
Sumit Semwal, Jerome Brunet, linux-samsung-soc, Robert Foss,
Kuninori Morimoto, Samuel Holland, Kevin Hilman, Maíra Canal,
Javier Martinez Canillas, Kuogee Hsieh, Xinliang Liu,
Danilo Krummrich, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon, Andrew Jeffery,
Jingoo Han, Seung-Woo Kim, Noralf Trønnes, kernel,
Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Stephen Rothwell, lima, Chunyan Zhang,
Alexey Brodkin, Minghao Chi, Steven Price, linux-rockchip,
Ben Skeggs, Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Karol Herbst,
Alexandre Belloni, Michal Simek, Matthias Brugger,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Xinwei Kong,
Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers, Joel Stanley,
nouveau, Orson Zhai, Chun-Kuang Hu, Arnd Bergmann, Guo Zhengkui,
Liviu Dudau, Alison Wang, Abhinav Kumar, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Thomas Zimmermann, Melissa Wen, linux-mediatek,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips,
Philippe Cornu, Dmitry Baryshkov, Jyri Sarha
[-- Attachment #1: Type: text/plain, Size: 5620 bytes --]
Hello Maxime,
On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
It seems not to be rigorously enforced, but it exists. See for example
https://lore.kernel.org/all/20230510092313.16693e4c@canb.auug.org.au/ .
@Stephen: you wrote there
You will need to ensure that the patches/commits in your
tree/series have been [...] destined for the current or next
Linux merge window.
This is a bit ambiguous because (AFAIK) during a merge window no patches
should be added that are supposed to go in during the next one, right?
Maybe adapt your template to read:
[...] destined to be included in the next -rc1 release.
which is more precise?
Even if others don't adhere to it, IMHO it's still an opportunity to
improve. Also there is a difference between a patch that is included in
next that doesn't make it in during the next merge window and a patch
that disappears from next. The latter (up to now) only happened to me
when there was a problem with the patch and the maintainer who first
thought the patch to be fine changed their opinion.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
We're mixing two things here. One is: "When will my patches be merged?".
I have no problem being patient here and b) is fine for me. The other is
"The patches first being included in next and then later not anymore
is a thing that just waits to be misinterpreted". This latter is the one
I care about here and that I think should be fixed for the future.
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
Not sure this is sensible given that I neither use nor know dim. Also I
think it should be the drm-misc maintainers who should care here given
that it's them who create this unfortunate situation again and again.
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next.
That's nitpicking and little helpful here. In your bubble where only or
mostly drm-misc matters it's ok to only look at drm-misc. But for a
contributor who sends patches for dozens of subsystems next is the more
useful place to look and each subsystem that is special is an obstacle.
> If they did, it's mostly an unfortunate artifact.
I see some progress in this discussion as you seem to agree this is
unfortunate. Actually that's all I intend to achieve.
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
>
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
>
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
Not knowing dim I think there is a simple(?) technical solution here: It
only has to make sure that after the pull request from drm-misc to drm
was sent, no new patches are added to the branch that is merged in next.
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] 261+ messages in thread
* Re: [Nouveau] patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 13:58 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 13:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Sumit Semwal, Jerome Brunet, linux-samsung-soc,
Robert Foss, Kuninori Morimoto, Samuel Holland, Kevin Hilman,
Maíra Canal, Javier Martinez Canillas, Kuogee Hsieh,
Xinliang Liu, NXP Linux Team, linux-sunxi, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv, Yuan Can,
Inki Dae, Jessica Zhang, Sean Paul, Johan Hovold, Hyun Kwon,
Andrew Jeffery, Jingoo Han, Seung-Woo Kim, Noralf Trønnes,
kernel, Alex Deucher, freedreno, Claudiu Beznea, Miaoqian Lin,
linux-aspeed, Tomi Valkeinen, Thierry Reding, John Stultz,
Mihail Atanassov, Liang He, Ville Syrjälä,
Stephen Rothwell, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Steven Price, linux-rockchip, Ben Skeggs,
Russell King, Alain Volmat, Liu Ying, linux-arm-msm,
Nicolas Ferre, Wang Jianzheng, linux-amlogic, linux-arm-kernel,
Neil Armstrong, Boris Brezillon, Sandy Huang, Paul Kocialkowski,
Kyungmin Park, Maxime Coquelin, Christophe JAILLET, Brian Starkey,
Alexandre Belloni, Stefan Agner, Michal Simek, Matthias Brugger,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Xinwei Kong, Jernej Skrabec, Chen-Yu Tsai, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Philipp Zabel, Chun-Kuang Hu,
Arnd Bergmann, Guo Zhengkui, Liviu Dudau, Alison Wang,
Abhinav Kumar, Christian Gmeiner, Mark Brown, Baolin Wang,
Paul Cercueil, Tomi Valkeinen, Deepak R Varma, Karol Wachowski,
Kieran Bingham, Ricardo Ribalda, Tian Tao, Shawn Guo,
Bjorn Andersson, linux-stm32, Emma Anholt, Konrad Dybcio,
Alexandre Torgue, Doug Anderson, Liu Shixin, Krzysztof Kozlowski,
Laura Nao, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Qiang Yu, Melissa Wen, linux-mediatek, Fabio Estevam,
Laurentiu Palcu, linux-tegra, Stephen Boyd,
AngeloGioacchino Del Regno, Yannick Fertre, linux-mips, Rob Clark,
Philippe Cornu, Daniel Vetter, Dmitry Baryshkov, Jyri Sarha,
Lucas Stach
[-- Attachment #1: Type: text/plain, Size: 5620 bytes --]
Hello Maxime,
On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
It seems not to be rigorously enforced, but it exists. See for example
https://lore.kernel.org/all/20230510092313.16693e4c@canb.auug.org.au/ .
@Stephen: you wrote there
You will need to ensure that the patches/commits in your
tree/series have been [...] destined for the current or next
Linux merge window.
This is a bit ambiguous because (AFAIK) during a merge window no patches
should be added that are supposed to go in during the next one, right?
Maybe adapt your template to read:
[...] destined to be included in the next -rc1 release.
which is more precise?
Even if others don't adhere to it, IMHO it's still an opportunity to
improve. Also there is a difference between a patch that is included in
next that doesn't make it in during the next merge window and a patch
that disappears from next. The latter (up to now) only happened to me
when there was a problem with the patch and the maintainer who first
thought the patch to be fine changed their opinion.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
We're mixing two things here. One is: "When will my patches be merged?".
I have no problem being patient here and b) is fine for me. The other is
"The patches first being included in next and then later not anymore
is a thing that just waits to be misinterpreted". This latter is the one
I care about here and that I think should be fixed for the future.
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
Not sure this is sensible given that I neither use nor know dim. Also I
think it should be the drm-misc maintainers who should care here given
that it's them who create this unfortunate situation again and again.
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next.
That's nitpicking and little helpful here. In your bubble where only or
mostly drm-misc matters it's ok to only look at drm-misc. But for a
contributor who sends patches for dozens of subsystems next is the more
useful place to look and each subsystem that is special is an obstacle.
> If they did, it's mostly an unfortunate artifact.
I see some progress in this discussion as you seem to agree this is
unfortunate. Actually that's all I intend to achieve.
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
>
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
>
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
Not knowing dim I think there is a simple(?) technical solution here: It
only has to make sure that after the pull request from drm-misc to drm
was sent, no new patches are added to the branch that is merged in next.
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] 261+ messages in thread
* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
@ 2023-06-19 13:58 ` Uwe Kleine-König
0 siblings, 0 replies; 261+ messages in thread
From: Uwe Kleine-König @ 2023-06-19 13:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Raymond Tan, Heiko Stübner, Akhil P Oommen, Linus Walleij,
dri-devel, Stanislaw Gruszka, Alim Akhtar, Anitha Chrisanthus,
Marijn Suijten, Steven Price, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, Robert Foss, Karol Herbst, Samuel Holland,
Kevin Hilman, Maíra Canal, Javier Martinez Canillas,
Kuogee Hsieh, Xinliang Liu, Danilo Krummrich, NXP Linux Team,
Miaoqian Lin, linux-sunxi, Rob Clark, Rahul T R,
Raphael Gallais-Pou, Jani Nikula, Sascha Hauer, etnaviv,
Stephen Boyd, Inki Dae, Alain Volmat, Sean Paul, Johan Hovold,
Hyun Kwon, Andrew Jeffery, Jingoo Han, Seung-Woo Kim,
Noralf Trønnes, kernel, Alex Deucher, freedreno,
Claudiu Beznea, Alexandre Belloni, linux-aspeed, Tomi Valkeinen,
Thierry Reding, John Stultz, Mihail Atanassov, Liang He,
Ville Syrjälä, lima, Chunyan Zhang, Alexey Brodkin,
Minghao Chi, Jonathan Hunter, linux-rockchip, Ben Skeggs,
Russell King, Jessica Zhang, linux-mips, Liu Ying, linux-arm-msm,
Wang Jianzheng, linux-amlogic, linux-arm-kernel, Neil Armstrong,
Boris Brezillon, Sandy Huang, Paul Kocialkowski, Kyungmin Park,
Maxime Coquelin, linux-mediatek, Brian Starkey, Kuninori Morimoto,
Yuan Can, Stefan Agner, Michal Simek, linux-tegra,
Laurent Pinchart, Andrzej Hajda, Sam Ravnborg, Rob Herring,
Chen-Yu Tsai, Jernej Skrabec, Xinwei Kong, Mali DP Maintainers,
Joel Stanley, nouveau, Orson Zhai, Chun-Kuang Hu, Lyude Paul,
Arnd Bergmann, Guo Zhengkui, Konrad Dybcio, Alison Wang,
Abhinav Kumar, Christian Gmeiner, Mark Brown, Baolin Wang,
Daniel Vetter, Liu Shixin, Tomi Valkeinen, Deepak R Varma,
Karol Wachowski, Kieran Bingham, Ricardo Ribalda, Tian Tao,
Shawn Guo, Yannick Fertre, linux-stm32, Emma Anholt, Liviu Dudau,
Alexandre Torgue, Doug Anderson, Paul Cercueil, Laura Nao,
David Airlie, Marek Vasut, linux-renesas-soc, Yongqin Liu,
Jayshri Pawar, Jonas Karlman, Russell King, Martin Blumenstingl,
Philippe Cornu, Thomas Zimmermann, Melissa Wen,
Christophe JAILLET, Fabio Estevam, Laurentiu Palcu,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Andersson,
Nicolas Ferre, Krzysztof Kozlowski, Qiang Yu, Philipp Zabel,
Dmitry Baryshkov, Jyri Sarha, Lucas Stach, Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 5620 bytes --]
Hello Maxime,
On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-König wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.
It seems not to be rigorously enforced, but it exists. See for example
https://lore.kernel.org/all/20230510092313.16693e4c@canb.auug.org.au/ .
@Stephen: you wrote there
You will need to ensure that the patches/commits in your
tree/series have been [...] destined for the current or next
Linux merge window.
This is a bit ambiguous because (AFAIK) during a merge window no patches
should be added that are supposed to go in during the next one, right?
Maybe adapt your template to read:
[...] destined to be included in the next -rc1 release.
which is more precise?
Even if others don't adhere to it, IMHO it's still an opportunity to
improve. Also there is a difference between a patch that is included in
next that doesn't make it in during the next merge window and a patch
that disappears from next. The latter (up to now) only happened to me
when there was a problem with the patch and the maintainer who first
thought the patch to be fine changed their opinion.
> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> > a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.
We're mixing two things here. One is: "When will my patches be merged?".
I have no problem being patient here and b) is fine for me. The other is
"The patches first being included in next and then later not anymore
is a thing that just waits to be misinterpreted". This latter is the one
I care about here and that I think should be fixed for the future.
> > b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.
Not sure this is sensible given that I neither use nor know dim. Also I
think it should be the drm-misc maintainers who should care here given
that it's them who create this unfortunate situation again and again.
> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next.
That's nitpicking and little helpful here. In your bubble where only or
mostly drm-misc matters it's ok to only look at drm-misc. But for a
contributor who sends patches for dozens of subsystems next is the more
useful place to look and each subsystem that is special is an obstacle.
> If they did, it's mostly an unfortunate artifact.
I see some progress in this discussion as you seem to agree this is
unfortunate. Actually that's all I intend to achieve.
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
>
> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
>
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.
Not knowing dim I think there is a simple(?) technical solution here: It
only has to make sure that after the pull request from drm-misc to drm
was sent, no new patches are added to the branch that is merged in next.
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] 261+ messages in thread
* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 13:58 ` Uwe Kleine-König
` (2 preceding siblings ...)
(?)
@ 2023-06-19 14:30 ` Jani Nikula
2023-06-19 14:52 ` Geert Uytterhoeven
-1 siblings, 1 reply; 261+ messages in thread
From: Jani Nikula @ 2023-06-19 14:30 UTC (permalink / raw)
To: Uwe Kleine-König, Maxime Ripard, Geert Uytterhoeven
Cc: Daniel Vetter, dri-devel
[Trimmed the recipients considerably; there's really no need to keep
spamming so many people about this.]
On Mon, 19 Jun 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> Not knowing dim I think there is a simple(?) technical solution here: It
> only has to make sure that after the pull request from drm-misc to drm
> was sent, no new patches are added to the branch that is merged in next.
The drm-misc-next and drm-intel-next branches are *always* open to
patches, regardless of the merge window. That's not going to change. We
never tell people "this is not the right time for your patches" due to
the merge window, like some subsystems do.
We have separate branches specifically for feeding to linux-next and
they serve no other purpose. The tooling tries to push the right thing
there, depending on the last pull request cutoff, so that linux-next
reflects what it's supposed to, but obviously the tooling doesn't have
the smarts to figure out when the last pull request is going to be
sent. (Really, humans don't always get that right either, because
predicting the future is kind of hard.)
Looks like you hit an issue, and although nobody else has complained
about this one over the 9 years we've been using dim, it royally
confused you. Sorry about that. There's always room for improvement in
the tooling, in the process, and in the human communication.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void
2023-06-19 14:30 ` Jani Nikula
@ 2023-06-19 14:52 ` Geert Uytterhoeven
0 siblings, 0 replies; 261+ messages in thread
From: Geert Uytterhoeven @ 2023-06-19 14:52 UTC (permalink / raw)
To: Jani Nikula
Cc: Daniel Vetter, Stephen Rothwell, dri-devel, Maxime Ripard,
Uwe Kleine-König
Hi Jani,
On Mon, Jun 19, 2023 at 4:30 PM Jani Nikula <jani.nikula@intel.com> wrote:
> [Trimmed the recipients considerably; there's really no need to keep
> spamming so many people about this.]
CC sfr
> On Mon, 19 Jun 2023, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> > Not knowing dim I think there is a simple(?) technical solution here: It
> > only has to make sure that after the pull request from drm-misc to drm
> > was sent, no new patches are added to the branch that is merged in next.
>
> The drm-misc-next and drm-intel-next branches are *always* open to
> patches, regardless of the merge window. That's not going to change. We
> never tell people "this is not the right time for your patches" due to
> the merge window, like some subsystems do.
Good (personally, I don't like it when a subsystem is not open to patches,
as it means that when I finally have time to work on patches myself, I
cannot submit them ;-)
> We have separate branches specifically for feeding to linux-next and
> they serve no other purpose. The tooling tries to push the right thing
> there, depending on the last pull request cutoff, so that linux-next
> reflects what it's supposed to, but obviously the tooling doesn't have
> the smarts to figure out when the last pull request is going to be
> sent. (Really, humans don't always get that right either, because
> predicting the future is kind of hard.)
OK. So all of this was a genuine mistake...
> Looks like you hit an issue, and although nobody else has complained
> about this one over the 9 years we've been using dim, it royally
> confused you. Sorry about that. There's always room for improvement in
> the tooling, in the process, and in the human communication.
Thanks for the explanation!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
2023-05-07 16:25 ` Uwe Kleine-König
` (4 preceding siblings ...)
(?)
@ 2023-09-09 14:37 ` Javier Martinez Canillas
-1 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Laurent Pinchart, Jonas Karlman,
Fabio Estevam, NXP Linux Team, Russell King, Christian Gmeiner,
etnaviv, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply [flat|nested] 261+ messages in thread* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-09-09 14:37 ` Javier Martinez Canillas
0 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Laurent Pinchart,
Alim Akhtar, Sumit Semwal, Jerome Brunet, linux-samsung-soc, lima,
Steven Price, linux-rockchip, Xinwei Kong, Mali DP Maintainers,
NXP Linux Team, Russell King, linux-sunxi, Alyssa Rosenzweig,
Jonas Karlman, Martin Blumenstingl, linux-arm-msm, etnaviv,
Christian Gmeiner, linux-mediatek, linux-tegra, linux-amlogic,
Sean Paul, linux-arm-kernel, AngeloGioacchino Del Regno,
Andrew Jeffery, linux-stm32, linux-mips, linux-renesas-soc,
kernel, Yongqin Liu, freedreno
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-09-09 14:37 ` Javier Martinez Canillas
0 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Laurent Pinchart, Jonas Karlman,
Fabio Estevam, NXP Linux Team, Russell King, Christian Gmeiner,
etnaviv, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [Nouveau] [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-09-09 14:37 ` Javier Martinez Canillas
0 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-aspeed, nouveau, dri-devel, John Stultz, Laurent Pinchart,
Alim Akhtar, Fabio Estevam, Sumit Semwal, Jerome Brunet,
linux-samsung-soc, lima, Steven Price, linux-rockchip,
Xinwei Kong, Mali DP Maintainers, NXP Linux Team, Russell King,
linux-sunxi, Alyssa Rosenzweig, Jonas Karlman,
Martin Blumenstingl, linux-arm-msm, etnaviv, Christian Gmeiner,
linux-mediatek, linux-tegra, linux-amlogic, Sean Paul,
linux-arm-kernel, AngeloGioacchino Del Regno, Andrew Jeffery,
linux-stm32, linux-mips, linux-renesas-soc, kernel, Yongqin Liu,
freedreno
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-09-09 14:37 ` Javier Martinez Canillas
0 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Laurent Pinchart, Jonas Karlman,
Fabio Estevam, NXP Linux Team, Russell King, Christian Gmeiner,
etnaviv, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 261+ messages in thread
* Re: [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-09-09 14:37 ` Javier Martinez Canillas
0 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mali DP Maintainers, dri-devel, kernel, Andrew Jeffery,
linux-aspeed, linux-arm-kernel, Laurent Pinchart, Jonas Karlman,
Fabio Estevam, NXP Linux Team, Russell King, Christian Gmeiner,
etnaviv, Alim Akhtar, linux-samsung-soc, Xinwei Kong,
Sumit Semwal, Yongqin Liu, John Stultz, linux-mips, lima,
AngeloGioacchino Del Regno, linux-mediatek, Jerome Brunet,
Martin Blumenstingl, linux-amlogic, Sean Paul, linux-arm-msm,
freedreno, nouveau, Steven Price, Alyssa Rosenzweig,
linux-renesas-soc, linux-rockchip, linux-stm32, linux-sunxi,
linux-tegra
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-König (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 261+ messages in thread
* [PATCH 00/53] drm: Convert to platform remove callback returning void
@ 2023-09-09 14:37 ` Javier Martinez Canillas
0 siblings, 0 replies; 261+ messages in thread
From: Javier Martinez Canillas @ 2023-09-09 14:37 UTC (permalink / raw)
To: linux-aspeed
Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> writes:
Hello Uwe,
> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-K?nig (53):
[...]
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
[...]
> drm/mediatek: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
[...]
> drm/msm: Convert to platform remove callback returning void
[...]
> drm/shmobile: Convert to platform remove callback returning void
Pushed these to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 261+ messages in thread