All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Michael Kelley <mhklinux@outlook.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
Subject: Re: [PATCH 1/1] fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs
Date: Sun, 9 Mar 2025 15:20:04 +0100	[thread overview]
Message-ID: <fc8f7246-2e05-4433-85d8-65dbed723826@gmx.de> (raw)
In-Reply-To: <SN6PR02MB4157594508B80319444C6C24D4D72@SN6PR02MB4157.namprd02.prod.outlook.com>

On 3/9/25 05:10, Michael Kelley wrote:
> From: Helge Deller <deller@gmx.de> Sent: Saturday, March 8, 2025 6:59 PM
>>
>> On 2/19/25 00:01, mhkelley58@gmail.com wrote:
>>> From: Michael Kelley <mhklinux@outlook.com>
>>>
> [snip]
>
>>>
>>> Reported-by: Thomas Tai <thomas.tai@oracle.com>
>>> Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info")
>>> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
>>> ---
>>> The "Fixes" tag uses commit c25a19afb81c because that's where the problem
>>> was re-exposed, and how far back a stable backport is needed. But I've
>>> taken a completely different, and hopefully better, approach in the
>>> solution that isn't related to the code changes in c25a19afb81c.
>>>
>>>    drivers/video/fbdev/hyperv_fb.c | 20 +++++++++++++-------
>>>    1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> applied to fbdev tree.
>>
>
> Thank you!
>
> Related, I noticed the patch "fbdev: hyperv_fb: iounmap() the correct
> memory when removing a device" is also in the fbdev for-next branch.
> Wei Liu previously applied this patch to the hyperv-fixes tree (see [1])
> and it's already in linux-next. Won't having it also in fbdev produce a
> merge conflict?
> [1] https://lore.kernel.org/linux-hyperv/Z6wHDw8BssJyQHiM@liuwe-devbox-debian-v2/

Thanks Michael!
I now dropped that patch from the fbdev tree to avoid collisions.

Btw, I'm fine if we agree that all hyperv-fbdev fixes & patches go through
hyperv or other trees. Just let me know.

Helge

  reply	other threads:[~2025-03-09 14:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 23:01 [PATCH 1/1] fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs mhkelley58
2025-03-09  2:58 ` Helge Deller
2025-03-09  4:10   ` Michael Kelley
2025-03-09 14:20     ` Helge Deller [this message]
2025-03-09 23:52       ` Wei Liu
2025-03-09 23:54 ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc8f7246-2e05-4433-85d8-65dbed723826@gmx.de \
    --to=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhklinux@outlook.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.