Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Souza, Jose" <jose.souza@intel.com>,
	"sashal@kernel.org" <sashal@kernel.org>,
	Jani Nikula <jani.nikula@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Subject: Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section
Date: Tue, 30 Jul 2019 09:22:07 -0700	[thread overview]
Message-ID: <20190730162207.GA18653@intel.com> (raw)
In-Reply-To: <20190730152724.GB31590@kroah.com>

On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > Hi Greg,
> > 
> > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > element
> > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > define
> > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > PSR1
> > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > with bdb
> > > > > > version >= 226 will also be wrong.
> > > > > > 
> > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > Cc: stable@vger.kernel.org
> > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Link: 
> > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > > (cherry picked from commit
> > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > 
> > > > > There is no such commit in Linus's kernel tree :(
> > > 
> > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > 
> > > This line is automatically added by "dim" tool when
> > > cherry-picking queued stuff for our drm-intel fixes branches.
> > 
> > What do you need her from us to accept this patch?
> 
> Um, you have read the stable kernel rules, right?
>     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>
> That's what I need for it to go into a stable kernel release.

Yes, I have read it. Maybe what I don't understand is just the fact that we will
let customers facing issues for 6 weeks or more while the original patch
doesn't land on Linus tree. :(

> 
> thanks,
> 
> greg k-h