linux-kernel - Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <165052322868.6597.3051928698772494571@jlahtine-mobl.ger.corp.intel.com>
Date:   Thu, 21 Apr 2022 09:40:28 +0300
From:   Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>
To:     "Wang, Zhi A" <zhi.a.wang@...el.com>,
        Jason Gunthorpe <jgg@...dia.com>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Christoph Hellwig <hch@....de>,
        "Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

+ Tvrtko

Quoting Jason Gunthorpe (2022-04-13 17:45:48)
> On Wed, Apr 13, 2022 at 02:26:23PM +0000, Wang, Zhi A wrote:
> > On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> > > 
> > >> It seems Jani's makefile clean patch has already included this one, I can
> > >> just simply drop this one so that Christoph won't need to re-send everything.
> > >>
> > >> For the branch to move on, I am merging the patches and will re-generate the
> > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> > >> gvt branches.
> > >>
> > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> > >> gvt-staging branch until my pull request landed in drm-intel-next.
> > >>
> > >> Also our QA will test gvt-staging-branch before the pull request. I suppose
> > >> it will take one or two days.
> > > 
> > > When you are wrangling the branches it would be great if Christoph's
> > > series and it's minimal dependencies could be on a single branch that
> > > could reasonably be pulled to the VFIO tree too, thanks
> > > 
> > > Jason
> > > 
> > 
> > Hi Jason:
> > 
> > I am thinking about the process of merging process. Here are the dependence:
> > 
> > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> > go through drm.
> > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. 
> > 
> > 2) Christoph's patches depends on my patches, but part of them are for VFIO.
> > 
> > a. If they are fully going through VFIO repo, they might have to wait my
> > patches to get landed first.
> > 
> > b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> > through VFIO, the rest part still needs to wait.
> > 
> > What would be a better process?
> 
> You should organize everything onto one simple branch based on a rc to
> make this all work.
> 
> Make your #1 patch as a single patch PR based on rc to drm-intel so it
> gets to the right tree
> 
> Make your MMIO series as PR on the branch above that first PR and merge to
> the gvt tree
> 
> Make Christoph's series as a PR on the branch above the second PR's
> MMIO series and merge to the gvt tree
> 
> Merge the gvt toward DRM in the normal way - ie the main merge path for
> this should be through DRM.
> 
> Then ask Alex to merge the 3rd PR as well.
> 
> I don't see any intel-next stuff in linux-next yet so hopefully it is
> early enough to get #1 OK.
> 
> Jason