On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > 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@xxxxxxxxx>
> > > > > > > > Cc: José Roberto de Souza <jose.souza@xxxxxxxxx>
> > > > > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > > > > > Cc: stable@xxxxxxxxxxxxxxx #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@xxxxxxxxx>
> > > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@xxxxxxxxx>
> > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> > > > > > > > Tested-by: François Guerraz <kubrick@xxxxxxxx>
> > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> > > > > > > > Link:
> > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@xxxxxxxxx
> > > > > > > > (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. :(
>
> Then get the patch into Linus's tree!
> Nothing I can do until that happens, you know this...
-ENOTENOUGHCOFFEE sorry.
For some reason I thought this thread had started as the reject of your scripts.
This patch is already queued on our drm-intel-fixes and will probably land on
Linus tree next week. Than your scripts will just get it.
So, back to your original concern:
The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
exist until 5.3 merge window though.
My question now is regarding our fixes flow adding these future references.
Do you have any concern with that?
Sorry and Thanks,
Rodrigo.
>
> greg k-h
