On Thu, Dec 01, 2022 at 02:14:42PM +0100, Noralf Trønnes wrote: > > > Den 01.12.2022 13.12, skrev Greg KH: > > On Thu, Dec 01, 2022 at 11:00:44AM +0100, Noralf Trønnes wrote: > >> > >> > >> Den 01.12.2022 06.55, skrev Greg KH: > >>> On Wed, Nov 30, 2022 at 08:26:48PM +0100, Noralf Trønnes via B4 Submission Endpoint wrote: > >>>> Hi, > >>>> > >>>> I have started to look at igt for testing and want to use CRC tests. To > >>>> implement support for this I need to move away from the simple kms > >>>> helper. > >>>> > >>>> When looking around for examples I came across Thomas' nice shadow > >>>> helper and thought, yes this is perfect for drm/gud. So I'll switch to > >>>> that before I move away from the simple kms helper. > >>>> > >>>> The async framebuffer flushing code path now uses a shadow buffer and > >>>> doesn't touch the framebuffer when it shouldn't. I have also taken the > >>>> opportunity to inline the synchronous flush code path and make this the > >>>> default flushing stategy. > >>>> > >>>> Noralf. > >>>> > >>>> Cc: Maxime Ripard <mripard@xxxxxxxxxx> > >>>> Cc: Thomas Zimmermann <tzimmermann@xxxxxxx> > >>>> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx > >>>> Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx> > >>>> > >>>> --- > >>>> Changes in v2: > >>>> - Drop patch (Thomas): > >>>> drm/gem: shadow_fb_access: Prepare imported buffers for CPU access > >>>> - Use src as variable name for iosys_map (Thomas) > >>>> - Prepare imported buffer for CPU access in the driver (Thomas) > >>>> - New patch: make sync flushing the default (Thomas) > >>>> - Link to v1: https://lore.kernel.org/r/20221122-gud-shadow-plane-v1-0-9de3afa3383e@xxxxxxxxxxx > >>> > >>> <formletter> > >>> > >>> This is not the correct way to submit patches for inclusion in the > >>> stable kernel tree. Please read: > >>> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > >>> for how to do this properly. > >>> > >>> </formletter> > >> > >> Care to elaborate? > >> Is it because stable got the whole patchset and not just the one fix > >> patch that cc'ed stable? > > > > That is what triggered this, yes. > > > >> This patchset was sent using the b4 tool and I can't control this > >> aspect. Everyone mentioned in the patches gets the whole set. > > > > Fair enough, but watch out, bots will report this as being a problem as > > they can't always read through all patches in a series to notice this... > > > > Konstantin, > > Can you add a rule in b4 to exclude stable@xxxxxxxxxxxxxxx > (stable@xxxxxxxxxx as well?) from getting the whole patchset? stable@xxxxxxxxxx is a pipe to /dev/null so that's not needed to be messed with. As for this needing special casing in b4, it's rare that you send out a patch series and only want 1 or 2 of them in stable, right? thanks, greg k-h
