| Message ID | 20230507162616.1368908-1-u.kleine-koenig@pengutronix.de |
|---|---|
| Headers | show |
| Series | drm: Convert to platform remove callback returning void | expand |
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 >
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
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
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
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
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
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
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
[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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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!
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