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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > Hello, > > > > > > > > > > On Sun, May 07, 2023 at 06:25:23PM +0200, Uwe Kleine-König wrote: > > > > > > this patch series adapts the platform drivers below drivers/gpu/drm > > > > > > to use the .remove_new() callback. Compared to the traditional .remove() > > > > > > callback .remove_new() returns no value. This is a good thing because > > > > > > the driver core doesn't (and cannot) cope for errors during remove. The > > > > > > only effect of a non-zero return value in .remove() is that the driver > > > > > > core emits a warning. The device is removed anyhow and an early return > > > > > > from .remove() usually yields a resource leak. > > > > > > > > > > > > By changing the remove callback to return void driver authors cannot > > > > > > reasonably (but wrongly) assume any more that there happens some kind of > > > > > > cleanup later. > > > > > > > > > > I wonder if someone would volunteer to add the whole series to > > > > > drm-misc-next?! > > > > > > > > It looks as if Neil applied quite a few of them already, so I looked > > > > at what was left... > > > > > > > > I'm a little hesitant to just apply the whole kit-and-caboodle to > > > > drm-misc-next since there are specific DRM trees for a bunch of them > > > > and it would be better if they landed there. ...so I went through all > > > > the patches that still applied to drm-misc-next, then used > > > > 'scripts/get_maintainer.pl --scm' to check if they were maintained > > > > through drm-misc. That still left quite a few patches. I've applied > > > > those ones and pushed to drm-misc-next: > > > > > > > > 71722685cd17 drm/xlnx/zynqmp_dpsub: Convert to platform remove > > > > callback returning void > > > > 1ed54a19f3b3 drm/vc4: Convert to platform remove callback returning void > > > > b957812839f8 drm/v3d: Convert to platform remove callback returning void > > > > e2fd3192e267 drm/tve200: Convert to platform remove callback returning void > > > > 84e6da7ad553 drm/tiny: Convert to platform remove callback returning void > > > > 34cdd1f691ad drm/tidss: Convert to platform remove callback returning void > > > > d665e3c9d37a drm/sun4i: Convert to platform remove callback returning void > > > > 0c259ab19146 drm/stm: Convert to platform remove callback returning void > > > > 9a865e45884a drm/sti: Convert to platform remove callback returning void > > > > 3c855610840e drm/rockchip: Convert to platform remove callback returning void > > > > e41977a83b71 drm/panfrost: Convert to platform remove callback returning void > > > > cef3776d0b5a drm/panel: Convert to platform remove callback returning void > > > > bd296a594e87 drm/mxsfb: Convert to platform remove callback returning void > > > > 38ca2d93d323 drm/meson: Convert to platform remove callback returning void > > > > fd1457d84bae drm/mcde: Convert to platform remove callback returning void > > > > 41a56a18615c drm/logicvc: Convert to platform remove callback returning void > > > > 980ec6444372 drm/lima: Convert to platform remove callback returning void > > > > 82a2c0cc1a22 drm/hisilicon: Convert to platform remove callback returning void > > > > c3b28b29ac0a drm/fsl-dcu: Convert to platform remove callback returning void > > > > a118fc6e71f9 drm/atmel-hlcdc: Convert to platform remove callback returning void > > > > 9a32dd324c46 drm/aspeed: Convert to platform remove callback returning void > > > > 2c7d291c498c drm/arm/malidp: Convert to platform remove callback returning void > > > > a920028df679 drm/arm/hdlcd: Convert to platform remove callback returning void > > > > 1bf3d76a7d15 drm/komeda: Convert to platform remove callback returning void > > > > > > Together with the patches that were applied later the topmost commit > > > from this series is c2807ecb5290 ("drm/omap: Convert to platform remove > > > callback returning void"). This commit was part for the following next > > > tags: > > > > > > $ git tag -l --contains c2807ecb5290 > > > next-20230609 > > > next-20230613 > > > next-20230614 > > > next-20230615 > > > > > > However in next-20230616 they are missing. In next-20230616 > > > drm-misc/for-linux-next was cf683e8870bd4be0fd6b98639286700a35088660. > > > Compared to c2807ecb5290 this adds 1149 patches but drops 37 (that are > > > also not included with a different commit id). The 37 patches dropped > > > are 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290: > > > > > > $ git shortlog -s 13cdd12a9f934158f4ec817cf048fcb4384aa9dc..c2807ecb5290 > > > 1 Christophe JAILLET > > > 2 Jessica Zhang > > > 5 Karol Wachowski > > > 1 Laura Nao > > > 27 Uwe Kleine-König > > > 1 Wang Jianzheng > > > > > > > > > I guess this was done by mistake because nobody told me about dropping > > > my/these patches? Can c2807ecb5290 please be merged into drm-misc-next > > > again? > > > > Actually, it was probably a mistake that these patches got merged to > > linuxnext during the 4 days that you noticed. However, your patches > > aren't dropped and are still present in drm-misc-next. > > > > drm-misc has a bit of a unique model and it's documented fairly well here: > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > Is there a flaw then in this unique model (or its implementation) when > drm-misc/for-linux-next moves in a non-fast-forward manner? This isn't > expected, is it? There's no expectation afaik. Any tree merged in linux-next can be rebased, drop a patch, amend one, etc. without any concern. It's also why linux-next is rebuilt entirely every day. > > The key is that committers can commit to drm-misc-next _at any time_ > > regardless of the merge window. The drm-misc merge strategy makes this > > OK. Specifically, when it's late in the linux cycle then drm-misc-next > > is supposed to stop merging to linuxnext. Then, shortly after the > > merge window closes, patches will start flowing again. > > > > So basically your patches are landed and should even keep the same git > > hashes when they eventually make it to Linux. They just won't land for > > another release cycle of Linux. > > OK, c2807ecb5290 is still included in drm-misc-next. So while I don't > understand the whole model, the patches at least seem to be scheduled to > go in during the next merge window. It's not that complicated. drm-misc-next is always open, and we start targeting release X + 2 when X-rc6 is released. This is due to Linus wanting all the commits sent as part of the PR in linux-next for two weeks. In order to converge towards (X + 1)-rc1 in linux-next, as soon as X-rc6 is released, we remove drm-misc-next from the linux-next branch. All the patches in drm-misc-next that were targetting X + 1 are in drm/next by then, so it's not a concern. Maxime
Attachment:
signature.asc
Description: PGP signature