[PATCH 00/53] drm: Convert to platform remove callback returning void

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Uwe Kleine-König]

Hello,

this patch series adapts the platform drivers below drivers/gpu/drm
to use the .remove_new() callback. Compared to the traditional .remove()
callback .remove_new() returns no value. This is a good thing because
the driver core doesn't (and cannot) cope for errors during remove. The
only effect of a non-zero return value in .remove() is that the driver
core emits a warning. The device is removed anyhow and an early return
from .remove() usually yields a resource leak.

By changing the remove callback to return void driver authors cannot
reasonably (but wrongly) assume any more that there happens some kind of
cleanup later.

Best regards
Uwe

Uwe Kleine-K?nig (53):
  drm/komeda: Convert to platform remove callback returning void
  drm/arm/hdlcd: Convert to platform remove callback returning void
  drm/arm/malidp: Convert to platform remove callback returning void
  drm/armada: Convert to platform remove callback returning void
  drm/aspeed: Convert to platform remove callback returning void
  drm/atmel-hlcdc: Convert to platform remove callback returning void
  drm/bridge: cdns-dsi: Convert to platform remove callback returning
    void
  drm/bridge: display-connector: Convert to platform remove callback
    returning void
  drm/bridge: fsl-ldb: Convert to platform remove callback returning
    void
  drm/imx/imx8*: Convert to platform remove callback returning void
  drm/bridge: lvds-codec: Convert to platform remove callback returning
    void
  drm/bridge: nwl-dsi: Convert to platform remove callback returning
    void
  drm/bridge: simple-bridge: Convert to platform remove callback
    returning void
  drm/bridge: synopsys: Convert to platform remove callback returning
    void
  drm/bridge: thc63lvd1024: Convert to platform remove callback
    returning void
  drm/bridge: tfp410: Convert to platform remove callback returning void
  drm/etnaviv: Convert to platform remove callback returning void
  drm/exynos: Convert to platform remove callback returning void
  drm/fsl-dcu: Convert to platform remove callback returning void
  drm/hisilicon: Convert to platform remove callback returning void
  drm/imx/dcss: Convert to platform remove callback returning void
  drm/imx/ipuv3: Convert to platform remove callback returning void
  drm/ingenic: Convert to platform remove callback returning void
  drm/kmb: Convert to platform remove callback returning void
  drm/lima: Convert to platform remove callback returning void
  drm/logicvc: Convert to platform remove callback returning void
  drm/mcde: Convert to platform remove callback returning void
  drm/mediatek: Convert to platform remove callback returning void
  drm/mediatek: Convert to platform remove callback returning void
  drm/meson: Convert to platform remove callback returning void
  drm/msm: Convert to platform remove callback returning void
  drm/mxsfb: Convert to platform remove callback returning void
  drm/nouveau: Convert to platform remove callback returning void
  drm/omap: Convert to platform remove callback returning void
  drm/panel: Convert to platform remove callback returning void
  drm/panfrost: Convert to platform remove callback returning void
  drm/rcar-du: Convert to platform remove callback returning void
  drm/rockchip: Convert to platform remove callback returning void
  drm/shmobile: Convert to platform remove callback returning void
  drm/sprd: Convert to platform remove callback returning void
  drm/sti: Convert to platform remove callback returning void
  drm/stm: Convert to platform remove callback returning void
  drm/sun4i: Convert to platform remove callback returning void
  drm/tegra: Convert to platform remove callback returning void
  drm/tests: helpers: Convert to platform remove callback returning void
  drm/tidss: Convert to platform remove callback returning void
  drm/tilcdc: Convert to platform remove callback returning void
  drm/tiny: Convert to platform remove callback returning void
  drm/tiny: Convert to platform remove callback returning void
  drm/tve200: Convert to platform remove callback returning void
  drm/v3d: Convert to platform remove callback returning void
  drm/vc4: Convert to platform remove callback returning void
  drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
    void

 drivers/gpu/drm/arm/display/komeda/komeda_drv.c     | 5 ++---
 drivers/gpu/drm/arm/hdlcd_drv.c                     | 5 ++---
 drivers/gpu/drm/arm/malidp_drv.c                    | 5 ++---
 drivers/gpu/drm/armada/armada_crtc.c                | 5 ++---
 drivers/gpu/drm/armada/armada_drv.c                 | 5 ++---
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c             | 6 ++----
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c        | 6 ++----
 drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c      | 6 ++----
 drivers/gpu/drm/bridge/display-connector.c          | 6 ++----
 drivers/gpu/drm/bridge/fsl-ldb.c                    | 6 ++----
 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c         | 6 ++----
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c        | 6 ++----
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c     | 6 ++----
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c        | 6 ++----
 drivers/gpu/drm/bridge/lvds-codec.c                 | 6 ++----
 drivers/gpu/drm/bridge/nwl-dsi.c                    | 5 ++---
 drivers/gpu/drm/bridge/simple-bridge.c              | 6 ++----
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c       | 6 ++----
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c  | 6 ++----
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
 drivers/gpu/drm/bridge/thc63lvd1024.c               | 6 ++----
 drivers/gpu/drm/bridge/ti-tfp410.c                  | 6 ++----
 drivers/gpu/drm/etnaviv/etnaviv_drv.c               | 6 ++----
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c               | 5 ++---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c       | 6 ++----
 drivers/gpu/drm/exynos/exynos7_drm_decon.c          | 6 ++----
 drivers/gpu/drm/exynos/exynos_dp.c                  | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_drv.c             | 5 ++---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c             | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_fimc.c            | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_fimd.c            | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_g2d.c             | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_gsc.c             | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_mic.c             | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_rotator.c         | 6 ++----
 drivers/gpu/drm/exynos/exynos_drm_scaler.c          | 6 ++----
 drivers/gpu/drm/exynos/exynos_hdmi.c                | 6 ++----
 drivers/gpu/drm/exynos/exynos_mixer.c               | 6 ++----
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c           | 6 ++----
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c        | 6 ++----
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c     | 5 ++---
 drivers/gpu/drm/imx/dcss/dcss-drv.c                 | 6 ++----
 drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c             | 6 ++----
 drivers/gpu/drm/imx/ipuv3/imx-drm-core.c            | 5 ++---
 drivers/gpu/drm/imx/ipuv3/imx-ldb.c                 | 5 ++---
 drivers/gpu/drm/imx/ipuv3/imx-tve.c                 | 5 ++---
 drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c              | 5 ++---
 drivers/gpu/drm/imx/ipuv3/parallel-display.c        | 6 ++----
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c           | 6 ++----
 drivers/gpu/drm/ingenic/ingenic-ipu.c               | 5 ++---
 drivers/gpu/drm/kmb/kmb_drv.c                       | 5 ++---
 drivers/gpu/drm/lima/lima_drv.c                     | 5 ++---
 drivers/gpu/drm/logicvc/logicvc_drm.c               | 6 ++----
 drivers/gpu/drm/mcde/mcde_drv.c                     | 6 ++----
 drivers/gpu/drm/mcde/mcde_dsi.c                     | 6 ++----
 drivers/gpu/drm/mediatek/mtk_cec.c                  | 5 ++---
 drivers/gpu/drm/mediatek/mtk_disp_aal.c             | 6 ++----
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c           | 6 ++----
 drivers/gpu/drm/mediatek/mtk_disp_color.c           | 6 ++----
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c           | 6 ++----
 drivers/gpu/drm/mediatek/mtk_disp_merge.c           | 6 ++----
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c             | 6 ++----
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c            | 6 ++----
 drivers/gpu/drm/mediatek/mtk_dp.c                   | 6 ++----
 drivers/gpu/drm/mediatek/mtk_dpi.c                  | 6 ++----
 drivers/gpu/drm/mediatek/mtk_drm_drv.c              | 6 ++----
 drivers/gpu/drm/mediatek/mtk_dsi.c                  | 6 ++----
 drivers/gpu/drm/mediatek/mtk_hdmi.c                 | 5 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c             | 6 ++----
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c             | 5 ++---
 drivers/gpu/drm/meson/meson_drv.c                   | 6 ++----
 drivers/gpu/drm/meson/meson_dw_hdmi.c               | 6 ++----
 drivers/gpu/drm/msm/adreno/adreno_device.c          | 5 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c             | 6 ++----
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c            | 6 ++----
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c            | 5 ++---
 drivers/gpu/drm/msm/dp/dp_display.c                 | 6 ++----
 drivers/gpu/drm/msm/dsi/dsi.c                       | 6 ++----
 drivers/gpu/drm/msm/hdmi/hdmi.c                     | 6 ++----
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c                 | 6 ++----
 drivers/gpu/drm/msm/msm_drv.c                       | 6 ++----
 drivers/gpu/drm/msm/msm_mdss.c                      | 6 ++----
 drivers/gpu/drm/mxsfb/lcdif_drv.c                   | 6 ++----
 drivers/gpu/drm/mxsfb/mxsfb_drv.c                   | 6 ++----
 drivers/gpu/drm/nouveau/nouveau_platform.c          | 5 ++---
 drivers/gpu/drm/omapdrm/dss/dispc.c                 | 5 ++---
 drivers/gpu/drm/omapdrm/dss/dsi.c                   | 6 ++----
 drivers/gpu/drm/omapdrm/dss/dss.c                   | 6 ++----
 drivers/gpu/drm/omapdrm/dss/hdmi4.c                 | 5 ++---
 drivers/gpu/drm/omapdrm/dss/hdmi5.c                 | 5 ++---
 drivers/gpu/drm/omapdrm/dss/venc.c                  | 5 ++---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c            | 9 +++------
 drivers/gpu/drm/omapdrm/omap_drv.c                  | 6 ++----
 drivers/gpu/drm/panel/panel-lvds.c                  | 6 ++----
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c         | 6 ++----
 drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c     | 6 ++----
 drivers/gpu/drm/panel/panel-simple.c                | 6 ++----
 drivers/gpu/drm/panfrost/panfrost_drv.c             | 5 ++---
 drivers/gpu/drm/rcar-du/rcar_cmm.c                  | 6 ++----
 drivers/gpu/drm/rcar-du/rcar_du_drv.c               | 6 ++----
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c              | 6 ++----
 drivers/gpu/drm/rcar-du/rcar_lvds.c                 | 6 ++----
 drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c             | 6 ++----
 drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c            | 6 ++----
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c     | 6 ++----
 drivers/gpu/drm/rockchip/cdn-dp-core.c              | 6 ++----
 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c     | 6 ++----
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c         | 6 ++----
 drivers/gpu/drm/rockchip/inno_hdmi.c                | 6 ++----
 drivers/gpu/drm/rockchip/rk3066_hdmi.c              | 6 ++----
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c         | 6 ++----
 drivers/gpu/drm/rockchip/rockchip_lvds.c            | 6 ++----
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c        | 6 ++----
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c         | 6 ++----
 drivers/gpu/drm/shmobile/shmob_drm_drv.c            | 6 ++----
 drivers/gpu/drm/sprd/sprd_dpu.c                     | 6 ++----
 drivers/gpu/drm/sprd/sprd_drm.c                     | 5 ++---
 drivers/gpu/drm/sprd/sprd_dsi.c                     | 6 ++----
 drivers/gpu/drm/sti/sti_compositor.c                | 5 ++---
 drivers/gpu/drm/sti/sti_drv.c                       | 6 ++----
 drivers/gpu/drm/sti/sti_dvo.c                       | 5 ++---
 drivers/gpu/drm/sti/sti_hda.c                       | 5 ++---
 drivers/gpu/drm/sti/sti_hdmi.c                      | 6 ++----
 drivers/gpu/drm/sti/sti_hqvdp.c                     | 5 ++---
 drivers/gpu/drm/sti/sti_tvout.c                     | 5 ++---
 drivers/gpu/drm/stm/drv.c                           | 6 ++----
 drivers/gpu/drm/stm/dw_mipi_dsi-stm.c               | 6 ++----
 drivers/gpu/drm/sun4i/sun4i_backend.c               | 6 ++----
 drivers/gpu/drm/sun4i/sun4i_drv.c                   | 6 ++----
 drivers/gpu/drm/sun4i/sun4i_frontend.c              | 6 ++----
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c              | 6 ++----
 drivers/gpu/drm/sun4i/sun4i_tcon.c                  | 6 ++----
 drivers/gpu/drm/sun4i/sun4i_tv.c                    | 6 ++----
 drivers/gpu/drm/sun4i/sun6i_drc.c                   | 6 ++----
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c              | 6 ++----
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c               | 6 ++----
 drivers/gpu/drm/sun4i/sun8i_mixer.c                 | 6 ++----
 drivers/gpu/drm/sun4i/sun8i_tcon_top.c              | 6 ++----
 drivers/gpu/drm/tegra/dpaux.c                       | 6 ++----
 drivers/gpu/drm/tests/drm_kunit_helpers.c           | 5 ++---
 drivers/gpu/drm/tidss/tidss_drv.c                   | 6 ++----
 drivers/gpu/drm/tilcdc/tilcdc_panel.c               | 6 ++----
 drivers/gpu/drm/tiny/arcpgu.c                       | 6 ++----
 drivers/gpu/drm/tiny/ofdrm.c                        | 6 ++----
 drivers/gpu/drm/tiny/simpledrm.c                    | 6 ++----
 drivers/gpu/drm/tve200/tve200_drv.c                 | 6 ++----
 drivers/gpu/drm/v3d/v3d_drv.c                       | 6 ++----
 drivers/gpu/drm/vc4/vc4_crtc.c                      | 5 ++---
 drivers/gpu/drm/vc4/vc4_dpi.c                       | 5 ++---
 drivers/gpu/drm/vc4/vc4_drv.c                       | 6 ++----
 drivers/gpu/drm/vc4/vc4_dsi.c                       | 6 ++----
 drivers/gpu/drm/vc4/vc4_hdmi.c                      | 5 ++---
 drivers/gpu/drm/vc4/vc4_hvs.c                       | 5 ++---
 drivers/gpu/drm/vc4/vc4_txp.c                       | 5 ++---
 drivers/gpu/drm/vc4/vc4_v3d.c                       | 5 ++---
 drivers/gpu/drm/vc4/vc4_vec.c                       | 5 ++---
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c                 | 6 ++----
 159 files changed, 319 insertions(+), 597 deletions(-)


base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
-- 
2.39.2

[PATCH 05/53] drm/aspeed: Convert to platform remove callback returning void

[Uwe Kleine-König]

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index ecfb060d2557..d0089e7fbfae 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -351,20 +351,18 @@ static int aspeed_gfx_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int aspeed_gfx_remove(struct platform_device *pdev)
+static void aspeed_gfx_remove(struct platform_device *pdev)
 {
 	struct drm_device *drm = platform_get_drvdata(pdev);
 
 	sysfs_remove_group(&pdev->dev.kobj, &aspeed_sysfs_attr_group);
 	drm_dev_unregister(drm);
 	aspeed_gfx_unload(drm);
-
-	return 0;
 }
 
 static struct platform_driver aspeed_gfx_platform_driver = {
 	.probe		= aspeed_gfx_probe,
-	.remove		= aspeed_gfx_remove,
+	.remove_new	= aspeed_gfx_remove,
 	.driver = {
 		.name = "aspeed_gfx",
 		.of_match_table = aspeed_gfx_match,
-- 
2.39.2

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Thomas Zimmermann]

Hi,

for the whole series:

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>

Please see my comment on the patches to tiny/.

Let me know if you want me to merge this patchset into drm-misc-next.

Best regards
Thomas

Am 07.05.23 um 18:25 schrieb Uwe Kleine-K?nig:
> Hello,
> 
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
> 
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
> 
> Best regards
> Uwe
> 
> Uwe Kleine-K?nig (53):
>    drm/komeda: Convert to platform remove callback returning void
>    drm/arm/hdlcd: Convert to platform remove callback returning void
>    drm/arm/malidp: Convert to platform remove callback returning void
>    drm/armada: Convert to platform remove callback returning void
>    drm/aspeed: Convert to platform remove callback returning void
>    drm/atmel-hlcdc: Convert to platform remove callback returning void
>    drm/bridge: cdns-dsi: Convert to platform remove callback returning
>      void
>    drm/bridge: display-connector: Convert to platform remove callback
>      returning void
>    drm/bridge: fsl-ldb: Convert to platform remove callback returning
>      void
>    drm/imx/imx8*: Convert to platform remove callback returning void
>    drm/bridge: lvds-codec: Convert to platform remove callback returning
>      void
>    drm/bridge: nwl-dsi: Convert to platform remove callback returning
>      void
>    drm/bridge: simple-bridge: Convert to platform remove callback
>      returning void
>    drm/bridge: synopsys: Convert to platform remove callback returning
>      void
>    drm/bridge: thc63lvd1024: Convert to platform remove callback
>      returning void
>    drm/bridge: tfp410: Convert to platform remove callback returning void
>    drm/etnaviv: Convert to platform remove callback returning void
>    drm/exynos: Convert to platform remove callback returning void
>    drm/fsl-dcu: Convert to platform remove callback returning void
>    drm/hisilicon: Convert to platform remove callback returning void
>    drm/imx/dcss: Convert to platform remove callback returning void
>    drm/imx/ipuv3: Convert to platform remove callback returning void
>    drm/ingenic: Convert to platform remove callback returning void
>    drm/kmb: Convert to platform remove callback returning void
>    drm/lima: Convert to platform remove callback returning void
>    drm/logicvc: Convert to platform remove callback returning void
>    drm/mcde: Convert to platform remove callback returning void
>    drm/mediatek: Convert to platform remove callback returning void
>    drm/mediatek: Convert to platform remove callback returning void
>    drm/meson: Convert to platform remove callback returning void
>    drm/msm: Convert to platform remove callback returning void
>    drm/mxsfb: Convert to platform remove callback returning void
>    drm/nouveau: Convert to platform remove callback returning void
>    drm/omap: Convert to platform remove callback returning void
>    drm/panel: Convert to platform remove callback returning void
>    drm/panfrost: Convert to platform remove callback returning void
>    drm/rcar-du: Convert to platform remove callback returning void
>    drm/rockchip: Convert to platform remove callback returning void
>    drm/shmobile: Convert to platform remove callback returning void
>    drm/sprd: Convert to platform remove callback returning void
>    drm/sti: Convert to platform remove callback returning void
>    drm/stm: Convert to platform remove callback returning void
>    drm/sun4i: Convert to platform remove callback returning void
>    drm/tegra: Convert to platform remove callback returning void
>    drm/tests: helpers: Convert to platform remove callback returning void
>    drm/tidss: Convert to platform remove callback returning void
>    drm/tilcdc: Convert to platform remove callback returning void
>    drm/tiny: Convert to platform remove callback returning void
>    drm/tiny: Convert to platform remove callback returning void
>    drm/tve200: Convert to platform remove callback returning void
>    drm/v3d: Convert to platform remove callback returning void
>    drm/vc4: Convert to platform remove callback returning void
>    drm/xlnx/zynqmp_dpsub: Convert to platform remove callback returning
>      void
> 
>   drivers/gpu/drm/arm/display/komeda/komeda_drv.c     | 5 ++---
>   drivers/gpu/drm/arm/hdlcd_drv.c                     | 5 ++---
>   drivers/gpu/drm/arm/malidp_drv.c                    | 5 ++---
>   drivers/gpu/drm/armada/armada_crtc.c                | 5 ++---
>   drivers/gpu/drm/armada/armada_drv.c                 | 5 ++---
>   drivers/gpu/drm/aspeed/aspeed_gfx_drv.c             | 6 ++----
>   drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c        | 6 ++----
>   drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c      | 6 ++----
>   drivers/gpu/drm/bridge/display-connector.c          | 6 ++----
>   drivers/gpu/drm/bridge/fsl-ldb.c                    | 6 ++----
>   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c         | 6 ++----
>   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c        | 6 ++----
>   drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c | 6 ++----
>   drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c     | 6 ++----
>   drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c        | 6 ++----
>   drivers/gpu/drm/bridge/lvds-codec.c                 | 6 ++----
>   drivers/gpu/drm/bridge/nwl-dsi.c                    | 5 ++---
>   drivers/gpu/drm/bridge/simple-bridge.c              | 6 ++----
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c       | 6 ++----
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-gp-audio.c  | 6 ++----
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 6 ++----
>   drivers/gpu/drm/bridge/thc63lvd1024.c               | 6 ++----
>   drivers/gpu/drm/bridge/ti-tfp410.c                  | 6 ++----
>   drivers/gpu/drm/etnaviv/etnaviv_drv.c               | 6 ++----
>   drivers/gpu/drm/etnaviv/etnaviv_gpu.c               | 5 ++---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c       | 6 ++----
>   drivers/gpu/drm/exynos/exynos7_drm_decon.c          | 6 ++----
>   drivers/gpu/drm/exynos/exynos_dp.c                  | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_drv.c             | 5 ++---
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c             | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c            | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c            | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_g2d.c             | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c             | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_mic.c             | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_rotator.c         | 6 ++----
>   drivers/gpu/drm/exynos/exynos_drm_scaler.c          | 6 ++----
>   drivers/gpu/drm/exynos/exynos_hdmi.c                | 6 ++----
>   drivers/gpu/drm/exynos/exynos_mixer.c               | 6 ++----
>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c           | 6 ++----
>   drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c        | 6 ++----
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c     | 5 ++---
>   drivers/gpu/drm/imx/dcss/dcss-drv.c                 | 6 ++----
>   drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c             | 6 ++----
>   drivers/gpu/drm/imx/ipuv3/imx-drm-core.c            | 5 ++---
>   drivers/gpu/drm/imx/ipuv3/imx-ldb.c                 | 5 ++---
>   drivers/gpu/drm/imx/ipuv3/imx-tve.c                 | 5 ++---
>   drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c              | 5 ++---
>   drivers/gpu/drm/imx/ipuv3/parallel-display.c        | 6 ++----
>   drivers/gpu/drm/ingenic/ingenic-drm-drv.c           | 6 ++----
>   drivers/gpu/drm/ingenic/ingenic-ipu.c               | 5 ++---
>   drivers/gpu/drm/kmb/kmb_drv.c                       | 5 ++---
>   drivers/gpu/drm/lima/lima_drv.c                     | 5 ++---
>   drivers/gpu/drm/logicvc/logicvc_drm.c               | 6 ++----
>   drivers/gpu/drm/mcde/mcde_drv.c                     | 6 ++----
>   drivers/gpu/drm/mcde/mcde_dsi.c                     | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_cec.c                  | 5 ++---
>   drivers/gpu/drm/mediatek/mtk_disp_aal.c             | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_disp_ccorr.c           | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_disp_color.c           | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_disp_gamma.c           | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_disp_merge.c           | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_disp_ovl.c             | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_disp_rdma.c            | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_dp.c                   | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_dpi.c                  | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_drm_drv.c              | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_dsi.c                  | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_hdmi.c                 | 5 ++---
>   drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c             | 6 ++----
>   drivers/gpu/drm/mediatek/mtk_mdp_rdma.c             | 5 ++---
>   drivers/gpu/drm/meson/meson_drv.c                   | 6 ++----
>   drivers/gpu/drm/meson/meson_dw_hdmi.c               | 6 ++----
>   drivers/gpu/drm/msm/adreno/adreno_device.c          | 5 ++---
>   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c             | 6 ++----
>   drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c            | 6 ++----
>   drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c            | 5 ++---
>   drivers/gpu/drm/msm/dp/dp_display.c                 | 6 ++----
>   drivers/gpu/drm/msm/dsi/dsi.c                       | 6 ++----
>   drivers/gpu/drm/msm/hdmi/hdmi.c                     | 6 ++----
>   drivers/gpu/drm/msm/hdmi/hdmi_phy.c                 | 6 ++----
>   drivers/gpu/drm/msm/msm_drv.c                       | 6 ++----
>   drivers/gpu/drm/msm/msm_mdss.c                      | 6 ++----
>   drivers/gpu/drm/mxsfb/lcdif_drv.c                   | 6 ++----
>   drivers/gpu/drm/mxsfb/mxsfb_drv.c                   | 6 ++----
>   drivers/gpu/drm/nouveau/nouveau_platform.c          | 5 ++---
>   drivers/gpu/drm/omapdrm/dss/dispc.c                 | 5 ++---
>   drivers/gpu/drm/omapdrm/dss/dsi.c                   | 6 ++----
>   drivers/gpu/drm/omapdrm/dss/dss.c                   | 6 ++----
>   drivers/gpu/drm/omapdrm/dss/hdmi4.c                 | 5 ++---
>   drivers/gpu/drm/omapdrm/dss/hdmi5.c                 | 5 ++---
>   drivers/gpu/drm/omapdrm/dss/venc.c                  | 5 ++---
>   drivers/gpu/drm/omapdrm/omap_dmm_tiler.c            | 9 +++------
>   drivers/gpu/drm/omapdrm/omap_drv.c                  | 6 ++----
>   drivers/gpu/drm/panel/panel-lvds.c                  | 6 ++----
>   drivers/gpu/drm/panel/panel-seiko-43wvf1g.c         | 6 ++----
>   drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c     | 6 ++----
>   drivers/gpu/drm/panel/panel-simple.c                | 6 ++----
>   drivers/gpu/drm/panfrost/panfrost_drv.c             | 5 ++---
>   drivers/gpu/drm/rcar-du/rcar_cmm.c                  | 6 ++----
>   drivers/gpu/drm/rcar-du/rcar_du_drv.c               | 6 ++----
>   drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c              | 6 ++----
>   drivers/gpu/drm/rcar-du/rcar_lvds.c                 | 6 ++----
>   drivers/gpu/drm/rcar-du/rcar_mipi_dsi.c             | 6 ++----
>   drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.c            | 6 ++----
>   drivers/gpu/drm/rockchip/analogix_dp-rockchip.c     | 6 ++----
>   drivers/gpu/drm/rockchip/cdn-dp-core.c              | 6 ++----
>   drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c     | 6 ++----
>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c         | 6 ++----
>   drivers/gpu/drm/rockchip/inno_hdmi.c                | 6 ++----
>   drivers/gpu/drm/rockchip/rk3066_hdmi.c              | 6 ++----
>   drivers/gpu/drm/rockchip/rockchip_drm_drv.c         | 6 ++----
>   drivers/gpu/drm/rockchip/rockchip_lvds.c            | 6 ++----
>   drivers/gpu/drm/rockchip/rockchip_vop2_reg.c        | 6 ++----
>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c         | 6 ++----
>   drivers/gpu/drm/shmobile/shmob_drm_drv.c            | 6 ++----
>   drivers/gpu/drm/sprd/sprd_dpu.c                     | 6 ++----
>   drivers/gpu/drm/sprd/sprd_drm.c                     | 5 ++---
>   drivers/gpu/drm/sprd/sprd_dsi.c                     | 6 ++----
>   drivers/gpu/drm/sti/sti_compositor.c                | 5 ++---
>   drivers/gpu/drm/sti/sti_drv.c                       | 6 ++----
>   drivers/gpu/drm/sti/sti_dvo.c                       | 5 ++---
>   drivers/gpu/drm/sti/sti_hda.c                       | 5 ++---
>   drivers/gpu/drm/sti/sti_hdmi.c                      | 6 ++----
>   drivers/gpu/drm/sti/sti_hqvdp.c                     | 5 ++---
>   drivers/gpu/drm/sti/sti_tvout.c                     | 5 ++---
>   drivers/gpu/drm/stm/drv.c                           | 6 ++----
>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c               | 6 ++----
>   drivers/gpu/drm/sun4i/sun4i_backend.c               | 6 ++----
>   drivers/gpu/drm/sun4i/sun4i_drv.c                   | 6 ++----
>   drivers/gpu/drm/sun4i/sun4i_frontend.c              | 6 ++----
>   drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c              | 6 ++----
>   drivers/gpu/drm/sun4i/sun4i_tcon.c                  | 6 ++----
>   drivers/gpu/drm/sun4i/sun4i_tv.c                    | 6 ++----
>   drivers/gpu/drm/sun4i/sun6i_drc.c                   | 6 ++----
>   drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c              | 6 ++----
>   drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c               | 6 ++----
>   drivers/gpu/drm/sun4i/sun8i_mixer.c                 | 6 ++----
>   drivers/gpu/drm/sun4i/sun8i_tcon_top.c              | 6 ++----
>   drivers/gpu/drm/tegra/dpaux.c                       | 6 ++----
>   drivers/gpu/drm/tests/drm_kunit_helpers.c           | 5 ++---
>   drivers/gpu/drm/tidss/tidss_drv.c                   | 6 ++----
>   drivers/gpu/drm/tilcdc/tilcdc_panel.c               | 6 ++----
>   drivers/gpu/drm/tiny/arcpgu.c                       | 6 ++----
>   drivers/gpu/drm/tiny/ofdrm.c                        | 6 ++----
>   drivers/gpu/drm/tiny/simpledrm.c                    | 6 ++----
>   drivers/gpu/drm/tve200/tve200_drv.c                 | 6 ++----
>   drivers/gpu/drm/v3d/v3d_drv.c                       | 6 ++----
>   drivers/gpu/drm/vc4/vc4_crtc.c                      | 5 ++---
>   drivers/gpu/drm/vc4/vc4_dpi.c                       | 5 ++---
>   drivers/gpu/drm/vc4/vc4_drv.c                       | 6 ++----
>   drivers/gpu/drm/vc4/vc4_dsi.c                       | 6 ++----
>   drivers/gpu/drm/vc4/vc4_hdmi.c                      | 5 ++---
>   drivers/gpu/drm/vc4/vc4_hvs.c                       | 5 ++---
>   drivers/gpu/drm/vc4/vc4_txp.c                       | 5 ++---
>   drivers/gpu/drm/vc4/vc4_v3d.c                       | 5 ++---
>   drivers/gpu/drm/vc4/vc4_vec.c                       | 5 ++---
>   drivers/gpu/drm/xlnx/zynqmp_dpsub.c                 | 6 ++----
>   159 files changed, 319 insertions(+), 597 deletions(-)
> 
> 
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230508/83f8e808/attachment-0001.sig>

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Uwe Kleine-König]

[A few addressed bounced and my script to find the recipents for a patch
series broke and invented some addresses. I fixed all the problem I'm
aware of in this mail.]

On Mon, May 08, 2023 at 09:06:27AM +0200, Thomas Zimmermann wrote:
> for the whole series:
> 
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> 
> Please see my comment on the patches to tiny/.
> 
> Let me know if you want me to merge this patchset into drm-misc-next.

Thanks, I'd wait a bit for more acks/reviews to come in and then plan to
resend later, also addressing the feedback you sent.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230508/2f4e2ea0/attachment-0001.sig>

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Inki Dae]

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
>

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Uwe Kleine-König]

On Mon, May 15, 2023 at 04:50:57PM +0900, Inki Dae wrote:
> Hi,
> 
> 2023? 5? 8? (?) ?? 1:32, Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>?? ??:
> >
> > Hello,
> >
> > this patch series adapts the platform drivers below drivers/gpu/drm
> > to use the .remove_new() callback. Compared to the traditional .remove()
> > callback .remove_new() returns no value. This is a good thing because
> 
> First of all, I apologize for the delay in providing my review comments.
> 
> Not related to this patch but seems that the "remove_new" callback
> naming implicitly implies that there is no need to return anything
> since its return type is void. To help users understand the intended
> behavior based on the callback name, how about considering a modified
> naming convention like "remove_no_return" or something similar?
> 
> The relevant patch has already been merged as outlined below,
> author Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> 2022-12-09
> 16:09:14 +0100
> committer Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2023-01-17
> 19:04:17 +0100
> commit 5c5a7680e67ba6fbbb5f4d79fa41485450c1985c (patch)
> tree 0b6dbc003a6bb4a3f7fb084d31326bbfa3ba3f7c
> parent 7bbb89b420d9e290cb34864832de8fcdf2c140dc (diff)
> download linux-5c5a7680e67ba6fbbb5f4d79fa41485450c1985c.tar.gz
> platform: Provide a remove callback that returns no value
> 
> Maybe a trivial thing but how about renaming it? I think the postfix,
> 'new', is a very generic word. I think you could introduce another
> patch for it if you think it's reasonable.

.remove_new is only a temporary name. Once all drivers are converted,
.remove is changed to return void and then all drivers are converted
back. While "remove_new" might not be a brilliant name choice, touching
all already converted drivers again just to improve the temporary
measures doesn't sound right.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230515/37d41b2c/attachment-0001.sig>

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Uwe Kleine-König]

Hello,

On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
> 
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.

I wonder if someone would volunteer to add the whole series to
drm-misc-next?!

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230601/da6cc783/attachment-0001.sig>

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Doug Anderson]

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

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Laurent Pinchart]

Hi Doug,

On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig wrote:
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
> 
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
> 
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
> 
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> 
> The following ones appeared to apply to the top of drm-misc-next, but
> I didn't apply them since get_maintainer didn't say they were part of
> drm-misc-next:
> 
> drm/tiny: Convert to platform remove callback returning void
> drm/tilcdc: Convert to platform remove callback returning void
> drm/sprd: Convert to platform remove callback returning void
> drm/shmobile: Convert to platform remove callback returning void
> drm/rcar-du: Convert to platform remove callback returning void

If you don't mind, could you take the rcar-du patch through drm-misc too
? I don't plan to send another pull request for v6.5.

> drm/omap: Convert to platform remove callback returning void

Tomi, should drm/omap moved to being maintained through drm-misc ?

> drm/nouveau: Convert to platform remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void

-- 
Regards,

Laurent Pinchart

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Doug Anderson]

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

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Tomi Valkeinen]

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

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Doug Anderson]

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

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Uwe Kleine-König]

[expanding recipents by the other affected persons]

On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > Hello,
> >
> > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > callback .remove_new() returns no value. This is a good thing because
> > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > only effect of a non-zero return value in .remove() is that the driver
> > > core emits a warning. The device is removed anyhow and an early return
> > > from .remove() usually yields a resource leak.
> > >
> > > By changing the remove callback to return void driver authors cannot
> > > reasonably (but wrongly) assume any more that there happens some kind of
> > > cleanup later.
> >
> > I wonder if someone would volunteer to add the whole series to
> > drm-misc-next?!
> 
> It looks as if Neil applied quite a few of them already, so I looked
> at what was left...
> 
> I'm a little hesitant to just apply the whole kit-and-caboodle to
> drm-misc-next since there are specific DRM trees for a bunch of them
> and it would be better if they landed there. ...so I went through all
> the patches that still applied to drm-misc-next, then used
> 'scripts/get_maintainer.pl --scm' to check if they were maintained
> through drm-misc. That still left quite a few patches. I've applied
> those ones and pushed to drm-misc-next:
> 
> 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> callback returning void
> 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> b957812839f8 drm/v3d: Convert to platform remove callback returning void
> e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> 9a865e45884a drm/sti: Convert to platform remove callback returning void
> 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> 980ec6444372 drm/lima: Convert to platform remove callback returning void
> 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void

Together with the patches that were applied later the topmost commit
from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
callback returning void"). This commit was part for the following next
tags:

	$ git tag -l --contains c2807ecb5290
	next-20230609
	next-20230613
	next-20230614
	next-20230615

However in next-20230616 they are missing. In next-20230616
drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
also not included with a different commit id). The 37 patches dropped
are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:

	$ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
	     1  Christophe JAILLET
	     2  Jessica Zhang
	     5  Karol Wachowski
	     1  Laura Nao
	    27  Uwe Kleine-K?nig
	     1  Wang Jianzheng


I guess this was done by mistake because nobody told me about dropping
my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
again?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230617/412a4327/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Chen-Yu Tsai]

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

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Doug Anderson]

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

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Uwe Kleine-König]

Hello Doug,

On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > [expanding recipents by the other affected persons]
> >
> > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > from .remove() usually yields a resource leak.
> > > > >
> > > > > By changing the remove callback to return void driver authors cannot
> > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > cleanup later.
> > > >
> > > > I wonder if someone would volunteer to add the whole series to
> > > > drm-misc-next?!
> > >
> > > It looks as if Neil applied quite a few of them already, so I looked
> > > at what was left...
> > >
> > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > and it would be better if they landed there. ...so I went through all
> > > the patches that still applied to drm-misc-next, then used
> > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > through drm-misc. That still left quite a few patches. I've applied
> > > those ones and pushed to drm-misc-next:
> > >
> > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > callback returning void
> > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> >
> > Together with the patches that were applied later the topmost commit
> > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > callback returning void"). This commit was part for the following next
> > tags:
> >
> >         $ git tag -l --contains c2807ecb5290
> >         next-20230609
> >         next-20230613
> >         next-20230614
> >         next-20230615
> >
> > However in next-20230616 they are missing. In next-20230616
> > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > also not included with a different commit id). The 37 patches dropped
> > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> >
> >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> >              1  Christophe JAILLET
> >              2  Jessica Zhang
> >              5  Karol Wachowski
> >              1  Laura Nao
> >             27  Uwe Kleine-K?nig
> >              1  Wang Jianzheng
> >
> >
> > I guess this was done by mistake because nobody told me about dropping
> > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > again?
> 
> Actually, it was probably a mistake that these patches got merged to
> linuxnext during the 4 days that you noticed. However, your patches
> aren't dropped and are still present in drm-misc-next.
> 
> drm-misc has a bit of a unique model and it's documented fairly well here:
> 
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html

Is there a flaw then in this unique model (or its implementation) when
drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
expected, is it?

> The key is that committers can commit to drm-misc-next _at any time_
> regardless of the merge window. The drm-misc merge strategy makes this
> OK. Specifically, when it's late in the linux cycle then drm-misc-next
> is supposed to stop merging to linuxnext. Then, shortly after the
> merge window closes, patches will start flowing again.
> 
> So basically your patches are landed and should even keep the same git
> hashes when they eventually make it to Linux. They just won't land for
> another release cycle of Linux.

OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
understand the whole model, the patches at least seem to be scheduled to
go in during the next merge window.

> Hope that makes sense!

I hope so, too :-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/8e58e238/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Uwe Kleine-König]

Hello again,

On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> > 
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> > 
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> 
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?

FTR, I checked historic next trees to find other trees where
for-linux-next were moved in a non-fast-forward manner[1]. I found:

	$ git for-each-ref --format='%(refname)' refs/tags/next-* | while read n; do hn=$(git show $n:Next/SHA1s 2>/dev/null | awk '$1 == "drm-misc" { print $2 }'); if test -z "$hn"; then continue; fi; if test -n "$prevhn" && ! git merge-base --is-ancestor "$prevhn" "$hn"; then if git merge-base --is-ancestor "$hn" linus/master; then merged=x; else merged="-"; fi; echo "$n ($prevhn -> $hn) [$merged]"; fi; prevhn=$hn; done
	refs/tags/next-20151231 (e8b4855b5dd3e285d0ec18ed15468025abc1be9a -> e112e593b215c394c0303dbf0534db0928e87967) [x]
	refs/tags/next-20160212 (e24bfdd5052ca65e99fb835838da9d64b36ddc88 -> 382ab95d1af85381d8a5dff09b16a80c7e492534) [x]
	refs/tags/next-20170613 (18e51064c42ca3945b94dd4652156b62457962bc -> 2d7b56378d32b0cf006f8944cbba4046df45dd25) [x]
	refs/tags/next-20180406 (3ae7fb202d86b7847f237daa474f3946bdc3b0c6 -> 41613a1a7df27a0aa34bf77d51278bbe8e108a8f) [x]
	refs/tags/next-20180517 (3131f209468d1514af378dd46eb34123d0af84ff -> 2045b22461c07a88dc3d2bab3cbfc6dc0c602fd4) [x]
	refs/tags/next-20190320 (e552f0851070fe4975d610a99910be4e9bf5d7bd -> 29054230f3e11ea818eccfa7bb4e4b3e89544164) [x]
	refs/tags/next-20190617 (9f9b25593ab4197318e3621201588ad8cd525c9b -> b1622cb3be4557fd086831ca7426eafe5f1acc2e) [x]
	refs/tags/next-20190723 (7aaddd96d5febcf5b24357a326b3038d49a20532 -> d808097627e51d53cf9b1aa13239b5c4a6adaefb) [x]
	refs/tags/next-20190829 (66c2dee4ae10a2d841c40b9dd9c7141eb23eee76 -> 578d2342ec702e5fb8a77983fabb3754ae3e9660) [x]
	refs/tags/next-20191004 (d7d44b6fe40a98e960be92ea8617954c2596d140 -> 4092de1ba34eb376791809fb366bc15f8a9e0b7c) [x]
	refs/tags/next-20191106 (8a537de0f3d8b655cb901c948ed863bf0b23277b -> cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d) [x]
	refs/tags/next-20191216 (0a5239985a3bc084738851afdf3fceb7d5651b0c -> d4e6a62d3769ef09bfe116b261a61ef871dea4f9) [x]
	refs/tags/next-20200123 (73896f60d4865657740c64821a7b18825a9bf96c -> db735fc4036bbe1fbe606819b5f0ff26cc76cdff) [x]
	refs/tags/next-20200415 (152cce0006abf7e17dfb7dc94896b044bda4e588 -> 74aae1c42f4a7f69934762f9e9f90a3ec335fef2) [x]
	refs/tags/next-20200521 (5bebaeadb30e8d1ed694bd9b63d4e424d333fe36 -> 0df3ff451287d71c620384eb7bb2cd3a8106412c) [x]
	refs/tags/next-20200617 (291ddeb621e4a9f1ced8302a777fbd7fbda058c6 -> cfe28f909ddd6ca854568870a7a9b46454e52b6f) [x]
	refs/tags/next-20200724 (9fadd6d1e2977bbd449d4fb99cde41ed6f71f668 -> 206739119508d5ab4b42ab480ff61a7e6cd72d7c) [x]
	refs/tags/next-20200924 (ad44c03208e46b83e4ae3269e32c9e524aa71cf8 -> de194561359788871f7d8f5f7797557a2a166b4e) [x]
	refs/tags/next-20201027 (2580a493a97da4a302cb66251b558bfc04c16e68 -> 70bb9193728627e84e02eb0960b0aa138ae2cef5) [x]
	refs/tags/next-20201214 (c365d304d69ab2a38e1431323d17a216b7930e32 -> 05faf1559de52465f1e753e31883aa294e6179c1) [x]
	refs/tags/next-20210211 (5ceeb328637a01e0e54e2618cff129c6a1c31dba -> e2183fb135a7f62d317aa1c61eb3d1919080edba) [x]
	refs/tags/next-20210319 (5fd3de7a51855e086d9ce9d2d752489e9c15b850 -> 4cf1d8719aab0ad89690abb1d37ecf4552778420) [x]
	refs/tags/next-20210409 (167b400217121338a2beb78e09e2c77bd95491f5 -> 9c0fed84d5750e1eea6c664e073ffa2534a17743) [x]
	refs/tags/next-20210615 (a3a5f9d0fb15da90820254ba735491887cc12099 -> 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2) [x]
	refs/tags/next-20210714 (34bd46bcf3de72cbffcdc42d3fa67e543d1c869b -> 35d283658a6196b2057be562096610c6793e1219) [x]
	refs/tags/next-20210715 (35d283658a6196b2057be562096610c6793e1219 -> 85fd4a8a84316166640102676a356755ddec80e0) [-]
	refs/tags/next-20210726 (85fd4a8a84316166640102676a356755ddec80e0 -> 03b7c552d081b73ba814eefc257c704b4d096d93) [x]
	refs/tags/next-20210727 (03b7c552d081b73ba814eefc257c704b4d096d93 -> 87360168759879d68550b0c052bbcc2a0339ff74) [-]
	refs/tags/next-20210817 (87360168759879d68550b0c052bbcc2a0339ff74 -> 80cbd8808f85017b8aff4b223db68926b470be12) [x]
	refs/tags/next-20211101 (2b3374306b315be02db0f67d3102a0d1e1357270 -> b3ec8cdf457e5e63d396fe1346cc788cf7c1b578) [x]
	refs/tags/next-20211117 (bcae3af286f49bf4f6cda03f165fbe530f4a6bed -> a193f3b4e050e35c506a34d0870c838d8e0b0449) [x]
	refs/tags/next-20211217 (43d5ac7d07023cd133b978de473b3400edad941f -> d6c75c295f67b26fad8ba2e72db80e0f744e9da9) [x]
	refs/tags/next-20220317 (07f380da3ebd8d84fc866ccf83d93c667fcaaeaa -> f6d790e5a7fe42706756c7fa1686d08d230610fc) [x]
	refs/tags/next-20220406 (67bae5f28c895f8737a1974c3f31cf12b9170b14 -> 21d139a95682c6ade89a2151e44012c9797c0309) [x]
	refs/tags/next-20220513 (aebeb02dfccb61d6930112aede2db3db5b8e974e -> 6071c4c2a319da360b0bf2bc397d4fefad10b2c8) [x]
	refs/tags/next-20220610 (5ee8c8f930ba7d20717c4fc2d9f1ce0e757d1155 -> efeeaefe9be56e8ae5e5b4e9ff6d2275ec977ec5) [x]
	refs/tags/next-20220715 (887ddf3251928dc39bfc58c5c62083d38a633c14 -> c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2) [x]
	refs/tags/next-20220818 (2939deac1fa220bc82b89235f146df1d9b52e876 -> 8ba9249396bef37cb68be9e8dee7847f1737db9d) [x]
	refs/tags/next-20221007 (fdd0640b639070efb58226c96cea5861150e8dce -> 39dd0cc2e5bd0d5188dd69f27e18783cea7ff06a) [x]
	refs/tags/next-20221122 (e3ddd2d25533d1cc6f9fea421e4a5f16b60b3434 -> 29583dfcd2dd72c766422bd05c16f06c6b1fb356) [x]
	refs/tags/next-20230106 (03dec92c4f788c54a7c01b40a018f601eb8a6c52 -> 4c00ac500d0edd1a6730c4e8293834a694c1b304) [x]
	refs/tags/next-20230201 (d023d6f741c85bb00d2ca43d338327fbc150c113 -> aebd8f0c6f8280ba35bc989f4a9ea47469d3589a) [x]
	refs/tags/next-20230616 (c2807ecb529004ea6f2c2be823c495dc8491e205 -> cf683e8870bd4be0fd6b98639286700a35088660) [-]

so up to now it happend only three times (i.e. the lines with [-]) that
drm-misc/for-linux-next changed in a non-ff way and the commit wasn't
included later in the mainline (and for refs/tags/next-20230616 we
assume this will change to [x] during the next merge window)

So it seems to happen every few weeks ...

Best regards
Uwe

[1] My collection of historic next tags is incomplete, so there might be
more.

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/bf6174b7/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Maxime Ripard]

On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> Hello Doug,
> 
> On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > <u.kleine-koenig@pengutronix.de> wrote:
> > >
> > > [expanding recipents by the other affected persons]
> > >
> > > On Thu, Jun 08, 2023 at 09:08:15AM -0700, Doug Anderson wrote:
> > > > On Thu, Jun 1, 2023 at 8:40?AM Uwe Kleine-K?nig
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > this patch series adapts the platform drivers below drivers/gpu/drm
> > > > > > to use the .remove_new() callback. Compared to the traditional .remove()
> > > > > > callback .remove_new() returns no value. This is a good thing because
> > > > > > the driver core doesn't (and cannot) cope for errors during remove. The
> > > > > > only effect of a non-zero return value in .remove() is that the driver
> > > > > > core emits a warning. The device is removed anyhow and an early return
> > > > > > from .remove() usually yields a resource leak.
> > > > > >
> > > > > > By changing the remove callback to return void driver authors cannot
> > > > > > reasonably (but wrongly) assume any more that there happens some kind of
> > > > > > cleanup later.
> > > > >
> > > > > I wonder if someone would volunteer to add the whole series to
> > > > > drm-misc-next?!
> > > >
> > > > It looks as if Neil applied quite a few of them already, so I looked
> > > > at what was left...
> > > >
> > > > I'm a little hesitant to just apply the whole kit-and-caboodle to
> > > > drm-misc-next since there are specific DRM trees for a bunch of them
> > > > and it would be better if they landed there. ...so I went through all
> > > > the patches that still applied to drm-misc-next, then used
> > > > 'scripts/get_maintainer.pl --scm' to check if they were maintained
> > > > through drm-misc. That still left quite a few patches. I've applied
> > > > those ones and pushed to drm-misc-next:
> > > >
> > > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove
> > > > callback returning void
> > > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void
> > > > b957812839f8 drm/v3d: Convert to platform remove callback returning void
> > > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void
> > > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void
> > > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void
> > > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void
> > > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void
> > > > 9a865e45884a drm/sti: Convert to platform remove callback returning void
> > > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void
> > > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void
> > > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void
> > > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void
> > > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void
> > > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void
> > > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void
> > > > 980ec6444372 drm/lima: Convert to platform remove callback returning void
> > > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void
> > > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void
> > > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void
> > > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void
> > > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void
> > > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void
> > > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void
> > >
> > > Together with the patches that were applied later the topmost commit
> > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > callback returning void"). This commit was part for the following next
> > > tags:
> > >
> > >         $ git tag -l --contains c2807ecb5290
> > >         next-20230609
> > >         next-20230613
> > >         next-20230614
> > >         next-20230615
> > >
> > > However in next-20230616 they are missing. In next-20230616
> > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > also not included with a different commit id). The 37 patches dropped
> > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > >
> > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > >              1  Christophe JAILLET
> > >              2  Jessica Zhang
> > >              5  Karol Wachowski
> > >              1  Laura Nao
> > >             27  Uwe Kleine-K?nig
> > >              1  Wang Jianzheng
> > >
> > >
> > > I guess this was done by mistake because nobody told me about dropping
> > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > again?
> > 
> > Actually, it was probably a mistake that these patches got merged to
> > linuxnext during the 4 days that you noticed. However, your patches
> > aren't dropped and are still present in drm-misc-next.
> > 
> > drm-misc has a bit of a unique model and it's documented fairly well here:
> > 
> > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> 
> Is there a flaw then in this unique model (or its implementation) when
> drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> expected, is it?

There's no expectation afaik. Any tree merged in linux-next can be
rebased, drop a patch, amend one, etc. without any concern.

It's also why linux-next is rebuilt entirely every day.

> > The key is that committers can commit to drm-misc-next _at any time_
> > regardless of the merge window. The drm-misc merge strategy makes this
> > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > is supposed to stop merging to linuxnext. Then, shortly after the
> > merge window closes, patches will start flowing again.
> > 
> > So basically your patches are landed and should even keep the same git
> > hashes when they eventually make it to Linux. They just won't land for
> > another release cycle of Linux.
> 
> OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> understand the whole model, the patches at least seem to be scheduled to
> go in during the next merge window.

It's not that complicated.

drm-misc-next is always open, and we start targeting release X + 2 when
X-rc6 is released.

This is due to Linus wanting all the commits sent as part of the PR in
linux-next for two weeks.

In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
is released, we remove drm-misc-next from the linux-next branch. All the
patches in drm-misc-next that were targetting X + 1 are in drm/next by
then, so it's not a concern.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/0a6b8456/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Uwe Kleine-König]

Hello Maxime,

On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > Together with the patches that were applied later the topmost commit
> > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > callback returning void"). This commit was part for the following next
> > > > tags:
> > > >
> > > >         $ git tag -l --contains c2807ecb5290
> > > >         next-20230609
> > > >         next-20230613
> > > >         next-20230614
> > > >         next-20230615
> > > >
> > > > However in next-20230616 they are missing. In next-20230616
> > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > also not included with a different commit id). The 37 patches dropped
> > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > >
> > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > >              1  Christophe JAILLET
> > > >              2  Jessica Zhang
> > > >              5  Karol Wachowski
> > > >              1  Laura Nao
> > > >             27  Uwe Kleine-K?nig
> > > >              1  Wang Jianzheng
> > > >
> > > >
> > > > I guess this was done by mistake because nobody told me about dropping
> > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > again?
> > > 
> > > Actually, it was probably a mistake that these patches got merged to
> > > linuxnext during the 4 days that you noticed. However, your patches
> > > aren't dropped and are still present in drm-misc-next.
> > > 
> > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > 
> > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > 
> > Is there a flaw then in this unique model (or its implementation) when
> > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > expected, is it?
> 
> There's no expectation afaik. Any tree merged in linux-next can be
> rebased, drop a patch, amend one, etc. without any concern.

I agree that there are no rules broken for a tree that is included in
next and a maintainer is free to rewrite their tree independant of the
tree being included in next.

Still I think that shouldn't be used as an excuse. For me, if a
maintainer puts some patch into next that's a statement saying
(approximately) "I think this patch is fine and I intend to send it to
Linus during the next merge window.". So my expectation is that if a
patch is dropped again from next, there was a problem and it would be
fair if the maintainer tells the author/submitter about this problem and
that the patch was dropped.

So my concern is not about rule breaking, but about the strange signal
that is sent to contributors by including their work in next for some
time and then dropping it again without comment.

> It's also why linux-next is rebuilt entirely every day.
> 
> > > The key is that committers can commit to drm-misc-next _at any time_
> > > regardless of the merge window. The drm-misc merge strategy makes this
> > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > merge window closes, patches will start flowing again.
> > > 
> > > So basically your patches are landed and should even keep the same git
> > > hashes when they eventually make it to Linux. They just won't land for
> > > another release cycle of Linux.
> > 
> > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > understand the whole model, the patches at least seem to be scheduled to
> > go in during the next merge window.
> 
> It's not that complicated.
> 
> drm-misc-next is always open, and we start targeting release X + 2 when
> X-rc6 is released.
> 
> This is due to Linus wanting all the commits sent as part of the PR in
> linux-next for two weeks.
> 
> In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> is released, we remove drm-misc-next from the linux-next branch. All the
> patches in drm-misc-next that were targetting X + 1 are in drm/next by
> then, so it's not a concern.

So if I were a maintainer of drm-misc, I'd want that no commit from
drm-misc-next migrates to next after -rc6.

Also note that the branch head in question (i.e. c2807ecb5290) was
included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
according to the rules you described c2807ecb5290 could have been
qualified to go into v6.5-rc1?!

Best regards
Uwe


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230618/dcb798d2/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Maxime Ripard]

On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> Hello Maxime,
> 
> On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > Together with the patches that were applied later the topmost commit
> > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > callback returning void"). This commit was part for the following next
> > > > > tags:
> > > > >
> > > > >         $ git tag -l --contains c2807ecb5290
> > > > >         next-20230609
> > > > >         next-20230613
> > > > >         next-20230614
> > > > >         next-20230615
> > > > >
> > > > > However in next-20230616 they are missing. In next-20230616
> > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > also not included with a different commit id). The 37 patches dropped
> > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > >
> > > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > >              1  Christophe JAILLET
> > > > >              2  Jessica Zhang
> > > > >              5  Karol Wachowski
> > > > >              1  Laura Nao
> > > > >             27  Uwe Kleine-K?nig
> > > > >              1  Wang Jianzheng
> > > > >
> > > > >
> > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > again?
> > > > 
> > > > Actually, it was probably a mistake that these patches got merged to
> > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > aren't dropped and are still present in drm-misc-next.
> > > > 
> > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > 
> > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > 
> > > Is there a flaw then in this unique model (or its implementation) when
> > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > expected, is it?
> > 
> > There's no expectation afaik. Any tree merged in linux-next can be
> > rebased, drop a patch, amend one, etc. without any concern.
> 
> I agree that there are no rules broken for a tree that is included in
> next and a maintainer is free to rewrite their tree independant of the
> tree being included in next.
> 
> Still I think that shouldn't be used as an excuse.

As an excuse for what?

> For me, if a maintainer puts some patch into next that's a statement
> saying (approximately) "I think this patch is fine and I intend to
> send it to Linus during the next merge window.".

I mean, that's what we're saying and doing?

> So my expectation is that if a patch is dropped again from next, there
> was a problem and it would be fair if the maintainer tells the
> author/submitter about this problem and that the patch was dropped.

But it wasn't dropped, it's still very much to be sent to Linus during
the next merge window.

> So my concern is not about rule breaking, but about the strange signal
> that is sent to contributors by including their work in next for some
> time and then dropping it again without comment.
> 
> > It's also why linux-next is rebuilt entirely every day.
> > 
> > > > The key is that committers can commit to drm-misc-next _at any time_
> > > > regardless of the merge window. The drm-misc merge strategy makes this
> > > > OK. Specifically, when it's late in the linux cycle then drm-misc-next
> > > > is supposed to stop merging to linuxnext. Then, shortly after the
> > > > merge window closes, patches will start flowing again.
> > > > 
> > > > So basically your patches are landed and should even keep the same git
> > > > hashes when they eventually make it to Linux. They just won't land for
> > > > another release cycle of Linux.
> > > 
> > > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't
> > > understand the whole model, the patches at least seem to be scheduled to
> > > go in during the next merge window.
> > 
> > It's not that complicated.
> > 
> > drm-misc-next is always open, and we start targeting release X + 2 when
> > X-rc6 is released.
> > 
> > This is due to Linus wanting all the commits sent as part of the PR in
> > linux-next for two weeks.
> > 
> > In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6
> > is released, we remove drm-misc-next from the linux-next branch. All the
> > patches in drm-misc-next that were targetting X + 1 are in drm/next by
> > then, so it's not a concern.
> 
> So if I were a maintainer of drm-misc, I'd want that no commit from
> drm-misc-next migrates to next after -rc6.
> 
> Also note that the branch head in question (i.e. c2807ecb5290) was
> included in next-20230609, while v6.4-rc6 was tagged on Jun 11. So
> according to the rules you described c2807ecb5290 could have been
> qualified to go into v6.5-rc1?!

Yes, could have, but barely missed the last drm-misc-next PR we sent to
Dave that usually occurs on Thursday (8/6) so Dave can merge it on
Friday (9/6), the last working day before -rc6 was released.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/63dca5ea/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Uwe Kleine-König]

On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > Hello Maxime,
> > 
> > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > Together with the patches that were applied later the topmost commit
> > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > callback returning void"). This commit was part for the following next
> > > > > > tags:
> > > > > >
> > > > > >         $ git tag -l --contains c2807ecb5290
> > > > > >         next-20230609
> > > > > >         next-20230613
> > > > > >         next-20230614
> > > > > >         next-20230615
> > > > > >
> > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > >
> > > > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > >              1  Christophe JAILLET
> > > > > >              2  Jessica Zhang
> > > > > >              5  Karol Wachowski
> > > > > >              1  Laura Nao
> > > > > >             27  Uwe Kleine-K?nig
> > > > > >              1  Wang Jianzheng
> > > > > >
> > > > > >
> > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > again?
> > > > > 
> > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > aren't dropped and are still present in drm-misc-next.
> > > > > 
> > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > 
> > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > 
> > > > Is there a flaw then in this unique model (or its implementation) when
> > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > expected, is it?
> > > 
> > > There's no expectation afaik. Any tree merged in linux-next can be
> > > rebased, drop a patch, amend one, etc. without any concern.
> > 
> > I agree that there are no rules broken for a tree that is included in
> > next and a maintainer is free to rewrite their tree independant of the
> > tree being included in next.
> > 
> > Still I think that shouldn't be used as an excuse.
> 
> As an excuse for what?

Just because the rules for trees in next allow the merged branch to be
rewritten, shouldn't be used to justify rewriting the branch.

IMHO you still should ensure that only commits make it into any next
snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
intend to be included in X-rc1.

> > For me, if a maintainer puts some patch into next that's a statement
> > saying (approximately) "I think this patch is fine and I intend to
> > send it to Linus during the next merge window.".
> 
> I mean, that's what we're saying and doing?

No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
was part of next-20230609). A few days later however the patches were
dropped.

The two options that would have made the experience smoother for me are:

 a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
 b) keep c2807ecb5290 in a branch that doesn't result it entering next
    before v6.5-rc1.

> > So my expectation is that if a patch is dropped again from next, there
> > was a problem and it would be fair if the maintainer tells the
> > author/submitter about this problem and that the patch was dropped.
> 
> But it wasn't dropped,

From my POV it was dropped from next as it was part of next between
next-20230609 and next-20230615 but not any more since next-20230616.
You talk about (not) being dropped from some branch in drm-misc, that's
irrelevant for the thing I'm complaining about.

> it's still very much to be sent to Linus during the next merge window.

"next merge window" as in the one leading to 6.5-rc1? Either we mean
different things when we say "next merge window", or there is a
misunderstanding I don't see yet.

Best regards
Uwe




-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/7f149314/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Maxime Ripard]

On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > Hello Maxime,
> > > 
> > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > tags:
> > > > > > >
> > > > > > >         $ git tag -l --contains c2807ecb5290
> > > > > > >         next-20230609
> > > > > > >         next-20230613
> > > > > > >         next-20230614
> > > > > > >         next-20230615
> > > > > > >
> > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > >
> > > > > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > >              1  Christophe JAILLET
> > > > > > >              2  Jessica Zhang
> > > > > > >              5  Karol Wachowski
> > > > > > >              1  Laura Nao
> > > > > > >             27  Uwe Kleine-K?nig
> > > > > > >              1  Wang Jianzheng
> > > > > > >
> > > > > > >
> > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > again?
> > > > > > 
> > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > 
> > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > 
> > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > 
> > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > expected, is it?
> > > > 
> > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > rebased, drop a patch, amend one, etc. without any concern.
> > > 
> > > I agree that there are no rules broken for a tree that is included in
> > > next and a maintainer is free to rewrite their tree independant of the
> > > tree being included in next.
> > > 
> > > Still I think that shouldn't be used as an excuse.
> > 
> > As an excuse for what?
> 
> Just because the rules for trees in next allow the merged branch to be
> rewritten, shouldn't be used to justify rewriting the branch.
> 
> IMHO you still should ensure that only commits make it into any next
> snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> intend to be included in X-rc1.

That's never been a next rule either. Rust support has been in next for
almost a year without being sent as a PR for example.

> > > For me, if a maintainer puts some patch into next that's a statement
> > > saying (approximately) "I think this patch is fine and I intend to
> > > send it to Linus during the next merge window.".
> > 
> > I mean, that's what we're saying and doing?
> 
> No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> was part of next-20230609). A few days later however the patches were
> dropped.
>
> The two options that would have made the experience smoother for me are:
> 
>  a) keep c2807ecb5290 in next and send it for v6.5-rc1; or

That's not an option. You were simply too late for v6.5-rc1, unless you
expect us to get rid of timezones and work on week-ends. But surely you
don't.

>  b) keep c2807ecb5290 in a branch that doesn't result it entering next
>     before v6.5-rc1.

All the drm-misc committers use dim. If that's a concern for you, feel
free to send a patch addressing this to dim.

> > > So my expectation is that if a patch is dropped again from next, there
> > > was a problem and it would be fair if the maintainer tells the
> > > author/submitter about this problem and that the patch was dropped.
> > 
> > But it wasn't dropped,
> 
> From my POV it was dropped from next as it was part of next between
> next-20230609 and next-20230615 but not any more since next-20230616.
> You talk about (not) being dropped from some branch in drm-misc, that's
> irrelevant for the thing I'm complaining about.

You were never told that they were merged in linux-next, but in
drm-misc-next. If they did, it's mostly an unfortunate artifact.

We have a documentation that explains the process and how drm-misc-next
works. If that's still confusing somehow, feel free to amend it to make
it clearer.

> > it's still very much to be sent to Linus during the next merge window.
> 
> "next merge window" as in the one leading to 6.5-rc1? Either we mean
> different things when we say "next merge window", or there is a
> misunderstanding I don't see yet.

Linus doesn't want to receive in a PR patches that haven't been in
linux-next for at least two weeks. In most cases that's rc6, which means
that by the time we send our last PR before rc6, the
next-merge-window-while-still-meeting-Linus-requirements is 6.6.

The rule applies to all trees, and it's why the soc tree also requires
its submaintainers to submit their PR before -rc6.

So yeah, sorry if it was confusing. At the end of the day, it's a
compromise, and I can't find a better one for everyone involved
(maintainers, contributors and committers alike) off the top of my head.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/db60b3a5/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Geert Uytterhoeven]

Hi Maxime,

CC sfr

On Mon, Jun 19, 2023 at 2:51?PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > tags:
> > > > > > > >
> > > > > > > >         $ git tag -l --contains c2807ecb5290
> > > > > > > >         next-20230609
> > > > > > > >         next-20230613
> > > > > > > >         next-20230614
> > > > > > > >         next-20230615
> > > > > > > >
> > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > >
> > > > > > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > >              1  Christophe JAILLET
> > > > > > > >              2  Jessica Zhang
> > > > > > > >              5  Karol Wachowski
> > > > > > > >              1  Laura Nao
> > > > > > > >             27  Uwe Kleine-K?nig
> > > > > > > >              1  Wang Jianzheng
> > > > > > > >
> > > > > > > >
> > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > again?
> > > > > > >
> > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > >
> > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > >
> > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > >
> > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > expected, is it?
> > > > >
> > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > >
> > > > I agree that there are no rules broken for a tree that is included in
> > > > next and a maintainer is free to rewrite their tree independant of the
> > > > tree being included in next.
> > > >
> > > > Still I think that shouldn't be used as an excuse.
> > >
> > > As an excuse for what?
> >
> > Just because the rules for trees in next allow the merged branch to be
> > rewritten, shouldn't be used to justify rewriting the branch.
> >
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
>
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.

https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297

   "The linux-next tree is, by design, a snapshot of what the mainline
    is expected to look like after the next merge window closes."

The general rule for linux-next is that its contents are intended to end
up in the next kernel release, and that it should not contain commits
that are intended for the next-next release, cfr. what Stephen sends
out to new trees:

   "You will need to ensure that the patches/commits in your tree/series have
    been:
            [...]
         * destined for the current or next Linux merge window."

and what he requests regularly in his announces, e.g.:

   "Please do not add any v6.4 related commits to your linux-next included
    branches until after v6.3-rc1 has been released."

AFAIU, the exception to the rule is new, self-contained, and sometimes
controversial development, which may have to cook for a few more cycles,
if it ends up in a PR at all.

> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > >
> > > I mean, that's what we're saying and doing?
> >
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> >
> >  a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
>
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.

I don't think anyone expects you to do that...

> >  b) keep c2807ecb5290 in a branch that doesn't result it entering next
> >     before v6.5-rc1.
>
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.

So you say this is an issue with the tooling? ;-)
If the tooling breaks the rules, perhaps the tooling should be fixed?

> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > >
> > > But it wasn't dropped,
> >
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
>
> You were never told that they were merged in linux-next, but in
> drm-misc-next. If they did, it's mostly an unfortunate artifact.
>
> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.

Why that document may apply to drm-misc-next, everything that appears
in linux-next should follow the linux-next process
https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L256

> > > it's still very much to be sent to Linus during the next merge window.
> >
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
>
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
>
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.

Unless there's a very good reason to deviate from that (e.g. a bug fix).

> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.

As I understand, the main issue Uwe is objecting to, is that his
patches ended up in linux-next first, only to be dropped again from
linux-next later, and that there was no communication about the
latter.

If you're not constantly working on a subsystem, it can be very hard
to keep track of the status of your own drive-by patches. When patches
get applied, appear in linux-next, and disappear from linux-next again
later, it's worse...

Thanks for your understanding!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Maxime Ripard]

On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> CC sfr
> 
> On Mon, Jun 19, 2023 at 2:51?PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > tags:
> > > > > > > > >
> > > > > > > > >         $ git tag -l --contains c2807ecb5290
> > > > > > > > >         next-20230609
> > > > > > > > >         next-20230613
> > > > > > > > >         next-20230614
> > > > > > > > >         next-20230615
> > > > > > > > >
> > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > >
> > > > > > > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > >              1  Christophe JAILLET
> > > > > > > > >              2  Jessica Zhang
> > > > > > > > >              5  Karol Wachowski
> > > > > > > > >              1  Laura Nao
> > > > > > > > >             27  Uwe Kleine-K?nig
> > > > > > > > >              1  Wang Jianzheng
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > again?
> > > > > > > >
> > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > >
> > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > >
> > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > >
> > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > expected, is it?
> > > > > >
> > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > >
> > > > > I agree that there are no rules broken for a tree that is included in
> > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > tree being included in next.
> > > > >
> > > > > Still I think that shouldn't be used as an excuse.
> > > >
> > > > As an excuse for what?
> > >
> > > Just because the rules for trees in next allow the merged branch to be
> > > rewritten, shouldn't be used to justify rewriting the branch.
> > >
> > > IMHO you still should ensure that only commits make it into any next
> > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > intend to be included in X-rc1.
> >
> > That's never been a next rule either. Rust support has been in next for
> > almost a year without being sent as a PR for example.
> 
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
> 
>    "The linux-next tree is, by design, a snapshot of what the mainline
>     is expected to look like after the next merge window closes."
> 
> The general rule for linux-next is that its contents are intended to end
> up in the next kernel release, and that it should not contain commits
> that are intended for the next-next release, cfr. what Stephen sends
> out to new trees:
> 
>    "You will need to ensure that the patches/commits in your tree/series have
>     been:
>             [...]
>          * destined for the current or next Linux merge window."
> 
> and what he requests regularly in his announces, e.g.:
> 
>    "Please do not add any v6.4 related commits to your linux-next included
>     branches until after v6.3-rc1 has been released."

Which is why those patches aren't in next anymore.

> AFAIU, the exception to the rule is new, self-contained, and sometimes
> controversial development, which may have to cook for a few more cycles,
> if it ends up in a PR at all.
> 
> > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > send it to Linus during the next merge window.".
> > > >
> > > > I mean, that's what we're saying and doing?
> > >
> > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > was part of next-20230609). A few days later however the patches were
> > > dropped.
> > >
> > > The two options that would have made the experience smoother for me are:
> > >
> > >  a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> >
> > That's not an option. You were simply too late for v6.5-rc1, unless you
> > expect us to get rid of timezones and work on week-ends. But surely you
> > don't.
> 
> I don't think anyone expects you to do that...
> 
> > >  b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > >     before v6.5-rc1.
> >
> > All the drm-misc committers use dim. If that's a concern for you, feel
> > free to send a patch addressing this to dim.
> 
> So you say this is an issue with the tooling? ;-)
> If the tooling breaks the rules, perhaps the tooling should be fixed?

We've been using dim for more than 5 years. It doesn't seem to work too bad?

And it does feel like the goalposts are moving there: the discussion
started by "you shouldn't rebase a tree" and is now at "patches should
never be in a next branch if they can't reach the next merge window,
even though it's not apparent yet"

But yeah, I now that complaining about how much drm-misc sucks is fun
and all, but it's still not clear to me what a potential solution to
this would be?

Knowing that we can't rebase or close drm-misc-next, and that it should
be automated in dim somehow, what would that fix be?

> > So yeah, sorry if it was confusing. At the end of the day, it's a
> > compromise, and I can't find a better one for everyone involved
> > (maintainers, contributors and committers alike) off the top of my head.
> 
> As I understand, the main issue Uwe is objecting to, is that his
> patches ended up in linux-next first, only to be dropped again from
> linux-next later, and that there was no communication about the
> latter.
> 
> If you're not constantly working on a subsystem, it can be very hard
> to keep track of the status of your own drive-by patches. When patches
> get applied, appear in linux-next, and disappear from linux-next again
> later, it's worse...

Sure, I've worked with enough of these series to understand how it can
be annoying.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/eccf050c/attachment-0001.sig>

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Geert Uytterhoeven]

Hi Maxime,

On Mon, Jun 19, 2023 at 4:02?PM Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Jun 19, 2023 at 03:25:28PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 19, 2023 at 2:51?PM Maxime Ripard <mripard@kernel.org> wrote:
> > > On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > > > On Mon, Jun 19, 2023 at 11:45:37AM +0200, Maxime Ripard wrote:
> > > > > On Sun, Jun 18, 2023 at 06:29:50PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > On Sun, Jun 18, 2023 at 04:32:55PM +0200, Maxime Ripard wrote:
> > > > > > > On Sun, Jun 18, 2023 at 02:39:15PM +0200, Uwe Kleine-K?nig wrote:
> > > > > > > > On Sat, Jun 17, 2023 at 10:57:23AM -0700, Doug Anderson wrote:
> > > > > > > > > On Sat, Jun 17, 2023 at 9:15?AM Uwe Kleine-K?nig
> > > > > > > > > <u.kleine-koenig@pengutronix.de> wrote:
> > > > > > > > > > Together with the patches that were applied later the topmost commit
> > > > > > > > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove
> > > > > > > > > > callback returning void"). This commit was part for the following next
> > > > > > > > > > tags:
> > > > > > > > > >
> > > > > > > > > >         $ git tag -l --contains c2807ecb5290
> > > > > > > > > >         next-20230609
> > > > > > > > > >         next-20230613
> > > > > > > > > >         next-20230614
> > > > > > > > > >         next-20230615
> > > > > > > > > >
> > > > > > > > > > However in next-20230616 they are missing. In next-20230616
> > > > > > > > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660.
> > > > > > > > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are
> > > > > > > > > > also not included with a different commit id). The 37 patches dropped
> > > > > > > > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290:
> > > > > > > > > >
> > > > > > > > > >         $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290
> > > > > > > > > >              1  Christophe JAILLET
> > > > > > > > > >              2  Jessica Zhang
> > > > > > > > > >              5  Karol Wachowski
> > > > > > > > > >              1  Laura Nao
> > > > > > > > > >             27  Uwe Kleine-K?nig
> > > > > > > > > >              1  Wang Jianzheng
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I guess this was done by mistake because nobody told me about dropping
> > > > > > > > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next
> > > > > > > > > > again?
> > > > > > > > >
> > > > > > > > > Actually, it was probably a mistake that these patches got merged to
> > > > > > > > > linuxnext during the 4 days that you noticed. However, your patches
> > > > > > > > > aren't dropped and are still present in drm-misc-next.
> > > > > > > > >
> > > > > > > > > drm-misc has a bit of a unique model and it's documented fairly well here:
> > > > > > > > >
> > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html
> > > > > > > >
> > > > > > > > Is there a flaw then in this unique model (or its implementation) when
> > > > > > > > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't
> > > > > > > > expected, is it?
> > > > > > >
> > > > > > > There's no expectation afaik. Any tree merged in linux-next can be
> > > > > > > rebased, drop a patch, amend one, etc. without any concern.
> > > > > >
> > > > > > I agree that there are no rules broken for a tree that is included in
> > > > > > next and a maintainer is free to rewrite their tree independant of the
> > > > > > tree being included in next.
> > > > > >
> > > > > > Still I think that shouldn't be used as an excuse.
> > > > >
> > > > > As an excuse for what?
> > > >
> > > > Just because the rules for trees in next allow the merged branch to be
> > > > rewritten, shouldn't be used to justify rewriting the branch.
> > > >
> > > > IMHO you still should ensure that only commits make it into any next
> > > > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > > > intend to be included in X-rc1.
> > >
> > > That's never been a next rule either. Rust support has been in next for
> > > almost a year without being sent as a PR for example.
> >
> > https://elixir.bootlin.com/linux/latest/source/Documentation/process/2.Process.rst#L297
> >
> >    "The linux-next tree is, by design, a snapshot of what the mainline
> >     is expected to look like after the next merge window closes."
> >
> > The general rule for linux-next is that its contents are intended to end
> > up in the next kernel release, and that it should not contain commits
> > that are intended for the next-next release, cfr. what Stephen sends
> > out to new trees:
> >
> >    "You will need to ensure that the patches/commits in your tree/series have
> >     been:
> >             [...]
> >          * destined for the current or next Linux merge window."
> >
> > and what he requests regularly in his announces, e.g.:
> >
> >    "Please do not add any v6.4 related commits to your linux-next included
> >     branches until after v6.3-rc1 has been released."
>
> Which is why those patches aren't in next anymore.

So why were they in linux-next before?
Was this a genuine mistake (things happen), or is there process
or tooling to improve?

> > AFAIU, the exception to the rule is new, self-contained, and sometimes
> > controversial development, which may have to cook for a few more cycles,
> > if it ends up in a PR at all.
> >
> > > > > > For me, if a maintainer puts some patch into next that's a statement
> > > > > > saying (approximately) "I think this patch is fine and I intend to
> > > > > > send it to Linus during the next merge window.".
> > > > >
> > > > > I mean, that's what we're saying and doing?
> > > >
> > > > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > > > was part of next-20230609). A few days later however the patches were
> > > > dropped.
> > > >
> > > > The two options that would have made the experience smoother for me are:
> > > >
> > > >  a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> > >
> > > That's not an option. You were simply too late for v6.5-rc1, unless you
> > > expect us to get rid of timezones and work on week-ends. But surely you
> > > don't.
> >
> > I don't think anyone expects you to do that...
> >
> > > >  b) keep c2807ecb5290 in a branch that doesn't result it entering next
> > > >     before v6.5-rc1.
> > >
> > > All the drm-misc committers use dim. If that's a concern for you, feel
> > > free to send a patch addressing this to dim.
> >
> > So you say this is an issue with the tooling? ;-)
> > If the tooling breaks the rules, perhaps the tooling should be fixed?
>
> We've been using dim for more than 5 years. It doesn't seem to work too bad?

I don't know anything about dim, so I cannot commit on that.

> And it does feel like the goalposts are moving there: the discussion
> started by "you shouldn't rebase a tree" and is now at "patches should
> never be in a next branch if they can't reach the next merge window,
> even though it's not apparent yet"

There is no such anti-rebasing rule for linux-next.
Some branches and some subsystems do have a non-rebasing rule,
but that's not applicable here, AFAIU.

Besides, won't you have to rebase the remaining commits from
drm-misc-next on top of v6.5-rc1 anyway later?

> But yeah, I now that complaining about how much drm-misc sucks is fun
> and all, but it's still not clear to me what a potential solution to
> this would be?

I'm so glad I'm not the one making personal attacks on drm-misc ;-)

> Knowing that we can't rebase or close drm-misc-next, and that it should
> be automated in dim somehow, what would that fix be?

Again, I don't know what dim does.
But I think the solution involves not merging anything in drm-next
if there is reason to believe it won't make the next merge window
(in this case: when it is applied to drm-misc-next after the cut-off point).

Personally, I use foo-for-vX.Y branches.  Despite some of my
foo-for-v6.6 branches already having new commits, I just hold off
merging any of them in a for-next branch until after v6.5-rc1.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

patches dropped from drm-misc-next [Was: Re: [PATCH 00/53] drm: Convert to platform remove callback returning] void

[Uwe Kleine-König]

Hello Maxime,

On Mon, Jun 19, 2023 at 02:47:09PM +0200, Maxime Ripard wrote:
> On Mon, Jun 19, 2023 at 12:53:42PM +0200, Uwe Kleine-K?nig wrote:
> > IMHO you still should ensure that only commits make it into any next
> > snapshot via your tree before X-rc1 for some X (e.g. v6.5) that you
> > intend to be included in X-rc1.
> 
> That's never been a next rule either. Rust support has been in next for
> almost a year without being sent as a PR for example.

It seems not to be rigorously enforced, but it exists. See for example
https://lore.kernel.org/all/20230510092313.16693e4c at canb.auug.org.au/ .

@Stephen: you wrote there

	You will need to ensure that the patches/commits in your
	tree/series have been [...] destined for the current or next
	Linux merge window.

This is a bit ambiguous because (AFAIK) during a merge window no patches
should be added that are supposed to go in during the next one, right?
Maybe adapt your template to read:

	[...] destined to be included in the next -rc1 release.

which is more precise?

Even if others don't adhere to it, IMHO it's still an opportunity to
improve. Also there is a difference between a patch that is included in
next that doesn't make it in during the next merge window and a patch
that disappears from next. The latter (up to now) only happened to me
when there was a problem with the patch and the maintainer who first
thought the patch to be fine changed their opinion.

> > > > For me, if a maintainer puts some patch into next that's a statement
> > > > saying (approximately) "I think this patch is fine and I intend to
> > > > send it to Linus during the next merge window.".
> > > 
> > > I mean, that's what we're saying and doing?
> > 
> > No, on 2023-06-09 I assumed that my patches will go into v6.5-rc1 (as it
> > was part of next-20230609). A few days later however the patches were
> > dropped.
> >
> > The two options that would have made the experience smoother for me are:
> > 
> >  a) keep c2807ecb5290 in next and send it for v6.5-rc1; or
> 
> That's not an option. You were simply too late for v6.5-rc1, unless you
> expect us to get rid of timezones and work on week-ends. But surely you
> don't.

We're mixing two things here. One is: "When will my patches be merged?".
I have no problem being patient here and b) is fine for me. The other is
"The patches first being included in next and then later not anymore
is a thing that just waits to be misinterpreted". This latter is the one
I care about here and that I think should be fixed for the future.

> >  b) keep c2807ecb5290 in a branch that doesn't result it entering next
> >     before v6.5-rc1.
> 
> All the drm-misc committers use dim. If that's a concern for you, feel
> free to send a patch addressing this to dim.

Not sure this is sensible given that I neither use nor know dim. Also I
think it should be the drm-misc maintainers who should care here given
that it's them who create this unfortunate situation again and again.

> > > > So my expectation is that if a patch is dropped again from next, there
> > > > was a problem and it would be fair if the maintainer tells the
> > > > author/submitter about this problem and that the patch was dropped.
> > > 
> > > But it wasn't dropped,
> > 
> > From my POV it was dropped from next as it was part of next between
> > next-20230609 and next-20230615 but not any more since next-20230616.
> > You talk about (not) being dropped from some branch in drm-misc, that's
> > irrelevant for the thing I'm complaining about.
> 
> You were never told that they were merged in linux-next, but in
> drm-misc-next.

That's nitpicking and little helpful here. In your bubble where only or
mostly drm-misc matters it's ok to only look at drm-misc. But for a
contributor who sends patches for dozens of subsystems next is the more
useful place to look and each subsystem that is special is an obstacle.
 
> If they did, it's mostly an unfortunate artifact.

I see some progress in this discussion as you seem to agree this is
unfortunate. Actually that's all I intend to achieve.

> We have a documentation that explains the process and how drm-misc-next
> works. If that's still confusing somehow, feel free to amend it to make
> it clearer.
> 
> > > it's still very much to be sent to Linus during the next merge window.
> > 
> > "next merge window" as in the one leading to 6.5-rc1? Either we mean
> > different things when we say "next merge window", or there is a
> > misunderstanding I don't see yet.
> 
> Linus doesn't want to receive in a PR patches that haven't been in
> linux-next for at least two weeks. In most cases that's rc6, which means
> that by the time we send our last PR before rc6, the
> next-merge-window-while-still-meeting-Linus-requirements is 6.6.
> 
> The rule applies to all trees, and it's why the soc tree also requires
> its submaintainers to submit their PR before -rc6.
> 
> So yeah, sorry if it was confusing. At the end of the day, it's a
> compromise, and I can't find a better one for everyone involved
> (maintainers, contributors and committers alike) off the top of my head.

Not knowing dim I think there is a simple(?) technical solution here: It
only has to make sure that after the pull request from drm-misc to drm
was sent, no new patches are added to the branch that is merged in next.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230619/4a8762bd/attachment-0001.sig>

[PATCH 00/53] drm: Convert to platform remove callback returning void

[Javier Martinez Canillas]

Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> writes:

Hello Uwe,

> Hello,
>
> this patch series adapts the platform drivers below drivers/gpu/drm
> to use the .remove_new() callback. Compared to the traditional .remove()
> callback .remove_new() returns no value. This is a good thing because
> the driver core doesn't (and cannot) cope for errors during remove. The
> only effect of a non-zero return value in .remove() is that the driver
> core emits a warning. The device is removed anyhow and an early return
> from .remove() usually yields a resource leak.
>
> By changing the remove callback to return void driver authors cannot
> reasonably (but wrongly) assume any more that there happens some kind of
> cleanup later.
>
> Best regards
> Uwe
>
> Uwe Kleine-K?nig (53):

[...]

>   drm/imx/ipuv3: Convert to platform remove callback returning void
>   drm/ingenic: Convert to platform remove callback returning void

[...]

>   drm/mediatek: Convert to platform remove callback returning void
>   drm/mediatek: Convert to platform remove callback returning void

[...]

>   drm/msm: Convert to platform remove callback returning void

[...]

>   drm/shmobile: Convert to platform remove callback returning void

Pushed these to drm-misc (drm-misc-next). Thanks!

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat