search for: backmerge

On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. > > Reference id -> 1c8f422059ae ("mm: change return type to >

On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. > > Reference id -> 1c8f422059ae ("mm: change return type to >

...drm: add missing declaration to drm_blend.h - good > > > > Before the git highway splits, all is well. The lane with commits > > works fine at both ends, but e98c58e55f68 is busted. Merge arfifact? > > Hmmm... that tree does not appear to have gotten a v4.12 backmerge at > any point. The last backmerge from Linus as far as I can tell was > v4.11-rc7. Could be an interaction with some out-of-tree change. FWIW, checking out the fingered commit then.. git log --oneline 52d9d38c183b..e98c58e55f68|grep nouveau and reverting the lot helped not at all. Checkin...

On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > > too much trouble, a bisect would be pretty useful. > > Bisection seemingly went fine, but the result is odd. > > e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the

...- good > 9cf8f5802f39 drm: add missing declaration to drm_blend.h - good > > Before the git highway splits, all is well. The lane with commits > works fine at both ends, but e98c58e55f68 is busted. Merge arfifact? Hmmm... that tree does not appear to have gotten a v4.12 backmerge at any point. The last backmerge from Linus as far as I can tell was v4.11-rc7. Could be an interaction with some out-of-tree change.

...dd missing declaration to drm_blend.h - good >>> >>> Before the git highway splits, all is well. The lane with commits >>> works fine at both ends, but e98c58e55f68 is busted. Merge arfifact? >> Hmmm... that tree does not appear to have gotten a v4.12 backmerge at >> any point. The last backmerge from Linus as far as I can tell was >> v4.11-rc7. Could be an interaction with some out-of-tree change. > FWIW, checking out the fingered commit then.. > > git log --oneline 52d9d38c183b..e98c58e55f68|grep nouveau and reverting > the lot h...

On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > too much trouble, a bisect would be pretty useful. Bisection seemingly went fine, but the result is odd. e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit -Mike

...ying this series. > > > > I've understood this to be Linus's prefered workflow. > > > > So, please send the next iteration of this against either > > plainv5.2-rc5 or v5.2-rc5 merged with hmm.git and I'll sort it out. > > Just make sure that when you backmerge v5.2-rc5 you have a clear > reason in the merge commit message about why you needed to do it. > While needless rebasing is top of the pet peeve list, second place, as > I found out, is mystery merges without explanations. Yes, I always describe the merge commits. Linus also particular abo...

...drm: add missing declaration to drm_blend.h - good > > > > Before the git highway splits, all is well. The lane with commits > > works fine at both ends, but e98c58e55f68 is busted. Merge arfifact? > > Hmmm... that tree does not appear to have gotten a v4.12 backmerge at > any point. The last backmerge from Linus as far as I can tell was > v4.11-rc7. Could be an interaction with some out-of-tree change. Ok, a network outage gave me time to go hunting.  Indeed it is a bad interaction with the tree DRM merged into.  All DRM did was to slip a WARN_ON_ONCE()...

...ge v5.2-rc5 to the tree before applying this series. > > I've understood this to be Linus's prefered workflow. > > So, please send the next iteration of this against either > plainv5.2-rc5 or v5.2-rc5 merged with hmm.git and I'll sort it out. Just make sure that when you backmerge v5.2-rc5 you have a clear reason in the merge commit message about why you needed to do it. While needless rebasing is top of the pet peeve list, second place, as I found out, is mystery merges without explanations.

On Wed, Jun 19, 2019 at 03:19:23PM -0300, Jason Gunthorpe wrote: > > Just make sure that when you backmerge v5.2-rc5 you have a clear > > reason in the merge commit message about why you needed to do it. > > While needless rebasing is top of the pet peeve list, second place, as > > I found out, is mystery merges without explanations. > > Yes, I always describe the merge commits....

...MAINTAINERS, many of the drivers are maintained in the same drm-misc repo, and it makes no difference to split those. In general it's, well, trivial to split up patches like this per driver or repo, but not splitting it up generates extra busywork in managing conflicts until some common merge/backmerge happens. We just want to apply the patch and forget about it, instead of dealing with a trivial whitespace cleanup many times over. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center

...ances > > are converted, vm_fault_t will become a distinct type. > > > > Reference id -> 1c8f422059ae ("mm: change return type to > > vm_fault_t") > > Hmm, that commit isn't yet in drm-misc-next. > Will drm-misc-next merge with 4.17-rcX soon? For backmerge requests you need to cc/ping the drm-misc maintainers. Adding them. I think the hold-up also was that Dave was on vacations still. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

Hi, > > So my expectation that a backmerge happens anyway after -rc1/2 is in > > line with reality, it is just to be delayed this time. I'll stay > > tuned ;) > > Is this patch already merged in drm-misc-next tree ? Pushed now. cheers, Gerd

On Thu, Aug 1, 2019 at 9:04 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Hi, > > > and removes a large amount of framebuffer code from these drivers. For > > bochs, a problem was reported where the driver could not display the console > > because it was pinned in system memory. [1] The patch set fixes this bug > > by converting bochs to use the shadow

....org > Cc: xen-devel at lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other drive...

....org > Cc: xen-devel at lists.xen.org > --- > Merging this is going to be a bit a mess due to all the ongoing drmP.h > cleanups. I think the following should work: > - Apply Sam's prep patches for removing drmP.h from > drm_modeset_helper.h > - Get the i915 drmP.h cleanup backmerged into drm-misc-next > - Apply this patch. > - Apply Sam's patch to remove drmP.h from drm_modeset_helper.h > - All through drm-misc-next, which has some potential for trivial > conflicts around #includes with other drivers unfortunately. > > I hope there's no other drive...

On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote: > On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote: > > > Git tree: > > > > > > git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2 > > > > > > Gitweb: > > > > > >

On Mon, Oct 7, 2019 at 7:39 AM Jani Nikula <jani.nikula at linux.intel.com> wrote: > > On Fri, 04 Oct 2019, Krzysztof Kozlowski <krzk at kernel.org> wrote: > > drivers/gpu/drm/i915/Kconfig | 12 +- > > drivers/gpu/drm/i915/Kconfig.debug | 144 +++++++++++------------ > > Please split these out to a separate patch. Can't speak for others,

On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote: > > Git tree: > > > > git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2 > > > > Gitweb: > > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-devmem-cleanup.2 > > Attached is my incremental fixups on top of this series, with those >