AMD drm patch workflow is broken for stable trees

AMD drm patch workflow is broken for stable trees

[Greg KH]

Hi all,

As some of you have noticed, there's a TON of failure messages being
sent out for AMD gpu driver commits that are tagged for stable
backports.  In short, you all are doing something really wrong with how
you are tagging these.

Please fix it up to NOT have duplicates in multiple branches that end up
in Linus's tree at different times.  Or if you MUST do that, then give
us a chance to figure out that it IS a duplicate.  As-is, it's not
working at all, and I think I need to just drop all patches for this
driver that are tagged for stable going forward and rely on you all to
provide a proper set of backported fixes when you say they are needed.

Again, what you are doing today is NOT ok and is broken.  Please fix.

greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Felix Kuehling]

On 2024-08-12 11:00, Greg KH wrote:
> Hi all,
>
> As some of you have noticed, there's a TON of failure messages being
> sent out for AMD gpu driver commits that are tagged for stable
> backports.  In short, you all are doing something really wrong with how
> you are tagging these.
Hi Greg,

I got notifications about one KFD patch failing to apply on six branches 
(6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you 
already applied this patch on two branches back in May. The emails had a 
suspicious looking date in the header (Sep 17, 2001). I wonder if there 
was some date glitch that caused a whole bunch of patches to be re-sent 
to stable somehow:

    ------------------ original commit in Linus's tree
    ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon
    Sep 17 00:00:00 2001 From: Alex Deucher
    <alexander.deucher@amd.com>Date: Sun, 14 Apr 2024 13:06:39 -0400
    Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page
    with large pages ...

On 6.1 and 6.6, the patch was already applied by you in May:

    $ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages"
    commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
    Author:     Alex Deucher <alexander.deucher@amd.com>
    AuthorDate: Sun Apr 14 13:06:39 2024 -0400
    Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    CommitDate: Fri May 17 12:02:34 2024 +0200

         drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
    ...

On 6.10 it was already upstream.

On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those 
and send the fixed patches out for you.

Regards,
   Felix


>
> Please fix it up to NOT have duplicates in multiple branches that end up
> in Linus's tree at different times.  Or if you MUST do that, then give
> us a chance to figure out that it IS a duplicate.  As-is, it's not
> working at all, and I think I need to just drop all patches for this
> driver that are tagged for stable going forward and rely on you all to
> provide a proper set of backported fixes when you say they are needed.
>
> Again, what you are doing today is NOT ok and is broken.  Please fix.
>
> greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Alex Deucher]

On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
>
> On 2024-08-12 11:00, Greg KH wrote:
> > Hi all,
> >
> > As some of you have noticed, there's a TON of failure messages being
> > sent out for AMD gpu driver commits that are tagged for stable
> > backports.  In short, you all are doing something really wrong with how
> > you are tagging these.
> Hi Greg,
>
> I got notifications about one KFD patch failing to apply on six branches
> (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> already applied this patch on two branches back in May. The emails had a
> suspicious looking date in the header (Sep 17, 2001). I wonder if there
> was some date glitch that caused a whole bunch of patches to be re-sent
> to stable somehow:

I think the crux of the problem is that sometimes patches go into
-next with stable tags and they end getting taken into -fixes as well
so after the merge window they end up getting picked up for stable
again.  Going forward, if they land in -next, I'll cherry-pick -x the
changes into -fixes so there is better traceability.

Alex

>
>     ------------------ original commit in Linus's tree
>     ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon
>     Sep 17 00:00:00 2001 From: Alex Deucher
>     <alexander.deucher@amd.com>Date: Sun, 14 Apr 2024 13:06:39 -0400
>     Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page
>     with large pages ...
>
> On 6.1 and 6.6, the patch was already applied by you in May:
>
>     $ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages"
>     commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
>     Author:     Alex Deucher <alexander.deucher@amd.com>
>     AuthorDate: Sun Apr 14 13:06:39 2024 -0400
>     Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     CommitDate: Fri May 17 12:02:34 2024 +0200
>
>          drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
>     ...
>
> On 6.10 it was already upstream.
>
> On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those
> and send the fixed patches out for you.
>
> Regards,
>    Felix
>
>
> >
> > Please fix it up to NOT have duplicates in multiple branches that end up
> > in Linus's tree at different times.  Or if you MUST do that, then give
> > us a chance to figure out that it IS a duplicate.  As-is, it's not
> > working at all, and I think I need to just drop all patches for this
> > driver that are tagged for stable going forward and rely on you all to
> > provide a proper set of backported fixes when you say they are needed.
> >
> > Again, what you are doing today is NOT ok and is broken.  Please fix.
> >
> > greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Greg KH]

On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> >
> > On 2024-08-12 11:00, Greg KH wrote:
> > > Hi all,
> > >
> > > As some of you have noticed, there's a TON of failure messages being
> > > sent out for AMD gpu driver commits that are tagged for stable
> > > backports.  In short, you all are doing something really wrong with how
> > > you are tagging these.
> > Hi Greg,
> >
> > I got notifications about one KFD patch failing to apply on six branches
> > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> > already applied this patch on two branches back in May. The emails had a
> > suspicious looking date in the header (Sep 17, 2001). I wonder if there
> > was some date glitch that caused a whole bunch of patches to be re-sent
> > to stable somehow:
> 
> I think the crux of the problem is that sometimes patches go into
> -next with stable tags and they end getting taken into -fixes as well
> so after the merge window they end up getting picked up for stable
> again.  Going forward, if they land in -next, I'll cherry-pick -x the
> changes into -fixes so there is better traceability.

Please do so, and also work to not have duplicate commits like this in
different branches.  Git can handle merges quite well, please use it.

If this shows up again in the next -rc1 merge window without any
changes, I'll have to just blackhole all amd drm patches going forward
until you all tell me you have fixed your development process.

thanks,

greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Greg KH]

On Wed, Aug 14, 2024 at 04:39:29PM -0400, Felix Kuehling wrote:
> On 2024-08-12 11:00, Greg KH wrote:
> > Hi all,
> > 
> > As some of you have noticed, there's a TON of failure messages being
> > sent out for AMD gpu driver commits that are tagged for stable
> > backports.  In short, you all are doing something really wrong with how
> > you are tagging these.
> Hi Greg,
> 
> I got notifications about one KFD patch failing to apply on six branches
> (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you already
> applied this patch on two branches back in May. The emails had a suspicious
> looking date in the header (Sep 17, 2001). I wonder if there was some date
> glitch that caused a whole bunch of patches to be re-sent to stable somehow:
> 
>    ------------------ original commit in Linus's tree
>    ------------------ From 24e82654e98e96cece5d8b919c522054456eeec6 Mon
>    Sep 17 00:00:00 2001 From: Alex Deucher
>    <alexander.deucher@amd.com>Date: Sun, 14 Apr 2024 13:06:39 -0400

That's the real date, ignore the 2001 thing, that's from git.


>    Subject: [PATCH] drm/amdkfd: don't allow mapping the MMIO HDP page
>    with large pages ...
> 
> On 6.1 and 6.6, the patch was already applied by you in May:
> 
>    $ git log --pretty=fuller stable/linux-6.6.y --grep "drm/amdkfd: don't allow mapping the MMIO HDP page with large pages"
>    commit 4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
>    Author:     Alex Deucher <alexander.deucher@amd.com>
>    AuthorDate: Sun Apr 14 13:06:39 2024 -0400
>    Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>    CommitDate: Fri May 17 12:02:34 2024 +0200
> 
>         drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
>    ...
> 
> On 6.10 it was already upstream.

Then why did we have it in the tree again with different commit ids?
That's the issue here, and the major confusion as there is no way for us
to determine if this is a commit that has been in the tree already or if
it's just a normal failure.

> On 5.4-5.15 it doesn't apply because of conflicts. I can resolve those and
> send the fixed patches out for you.

If it is needed in those branches, please do so.

thanks,

greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Alex Deucher]

On Thu, Aug 15, 2024 at 1:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> > On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> > >
> > > On 2024-08-12 11:00, Greg KH wrote:
> > > > Hi all,
> > > >
> > > > As some of you have noticed, there's a TON of failure messages being
> > > > sent out for AMD gpu driver commits that are tagged for stable
> > > > backports.  In short, you all are doing something really wrong with how
> > > > you are tagging these.
> > > Hi Greg,
> > >
> > > I got notifications about one KFD patch failing to apply on six branches
> > > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> > > already applied this patch on two branches back in May. The emails had a
> > > suspicious looking date in the header (Sep 17, 2001). I wonder if there
> > > was some date glitch that caused a whole bunch of patches to be re-sent
> > > to stable somehow:
> >
> > I think the crux of the problem is that sometimes patches go into
> > -next with stable tags and they end getting taken into -fixes as well
> > so after the merge window they end up getting picked up for stable
> > again.  Going forward, if they land in -next, I'll cherry-pick -x the
> > changes into -fixes so there is better traceability.
>
> Please do so, and also work to not have duplicate commits like this in
> different branches.  Git can handle merges quite well, please use it.
>
> If this shows up again in the next -rc1 merge window without any
> changes, I'll have to just blackhole all amd drm patches going forward
> until you all tell me you have fixed your development process.

Just a heads up, you will see some of these when the 6.12 merge window
due to what is currently in -next and the fixes that went into 6.11,
but going forward we have updated our process and it should be better.

Thanks,

Alex

>
> thanks,
>
> greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Greg KH]

On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
> On Thu, Aug 15, 2024 at 1:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> > > On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> > > >
> > > > On 2024-08-12 11:00, Greg KH wrote:
> > > > > Hi all,
> > > > >
> > > > > As some of you have noticed, there's a TON of failure messages being
> > > > > sent out for AMD gpu driver commits that are tagged for stable
> > > > > backports.  In short, you all are doing something really wrong with how
> > > > > you are tagging these.
> > > > Hi Greg,
> > > >
> > > > I got notifications about one KFD patch failing to apply on six branches
> > > > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> > > > already applied this patch on two branches back in May. The emails had a
> > > > suspicious looking date in the header (Sep 17, 2001). I wonder if there
> > > > was some date glitch that caused a whole bunch of patches to be re-sent
> > > > to stable somehow:
> > >
> > > I think the crux of the problem is that sometimes patches go into
> > > -next with stable tags and they end getting taken into -fixes as well
> > > so after the merge window they end up getting picked up for stable
> > > again.  Going forward, if they land in -next, I'll cherry-pick -x the
> > > changes into -fixes so there is better traceability.
> >
> > Please do so, and also work to not have duplicate commits like this in
> > different branches.  Git can handle merges quite well, please use it.
> >
> > If this shows up again in the next -rc1 merge window without any
> > changes, I'll have to just blackhole all amd drm patches going forward
> > until you all tell me you have fixed your development process.
> 
> Just a heads up, you will see some of these when the 6.12 merge window
> due to what is currently in -next and the fixes that went into 6.11,
> but going forward we have updated our process and it should be better.

Can you give me a list of the git ids that I should be ignoring for
6.12-rc1?  Otherwise again, it's a huge waste of time on my side trying
to sift through them and figure out if the rejection is real or not...

thanks,

greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Alex Deucher]

On Sat, Aug 24, 2024 at 1:23 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
> > On Thu, Aug 15, 2024 at 1:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> > > > On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> > > > >
> > > > > On 2024-08-12 11:00, Greg KH wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > As some of you have noticed, there's a TON of failure messages being
> > > > > > sent out for AMD gpu driver commits that are tagged for stable
> > > > > > backports.  In short, you all are doing something really wrong with how
> > > > > > you are tagging these.
> > > > > Hi Greg,
> > > > >
> > > > > I got notifications about one KFD patch failing to apply on six branches
> > > > > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> > > > > already applied this patch on two branches back in May. The emails had a
> > > > > suspicious looking date in the header (Sep 17, 2001). I wonder if there
> > > > > was some date glitch that caused a whole bunch of patches to be re-sent
> > > > > to stable somehow:
> > > >
> > > > I think the crux of the problem is that sometimes patches go into
> > > > -next with stable tags and they end getting taken into -fixes as well
> > > > so after the merge window they end up getting picked up for stable
> > > > again.  Going forward, if they land in -next, I'll cherry-pick -x the
> > > > changes into -fixes so there is better traceability.
> > >
> > > Please do so, and also work to not have duplicate commits like this in
> > > different branches.  Git can handle merges quite well, please use it.
> > >
> > > If this shows up again in the next -rc1 merge window without any
> > > changes, I'll have to just blackhole all amd drm patches going forward
> > > until you all tell me you have fixed your development process.
> >
> > Just a heads up, you will see some of these when the 6.12 merge window
> > due to what is currently in -next and the fixes that went into 6.11,
> > but going forward we have updated our process and it should be better.
>
> Can you give me a list of the git ids that I should be ignoring for
> 6.12-rc1?  Otherwise again, it's a huge waste of time on my side trying
> to sift through them and figure out if the rejection is real or not...

8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2
ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference
332315885d3c drm/amd/display: Remove ASSERT if significance is zero in
math_ceil2
295d91cbc700 drm/amd/display: Check for NULL pointer
6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings
93381e6b6180 drm/amdgpu: fix a possible null pointer dereference
7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Thanks.

Alex

>
> thanks,
>
> greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Greg KH]

On Tue, Aug 27, 2024 at 10:18:27AM -0400, Alex Deucher wrote:
> On Sat, Aug 24, 2024 at 1:23 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
> > > On Thu, Aug 15, 2024 at 1:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> > > > > On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> > > > > >
> > > > > > On 2024-08-12 11:00, Greg KH wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > As some of you have noticed, there's a TON of failure messages being
> > > > > > > sent out for AMD gpu driver commits that are tagged for stable
> > > > > > > backports.  In short, you all are doing something really wrong with how
> > > > > > > you are tagging these.
> > > > > > Hi Greg,
> > > > > >
> > > > > > I got notifications about one KFD patch failing to apply on six branches
> > > > > > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> > > > > > already applied this patch on two branches back in May. The emails had a
> > > > > > suspicious looking date in the header (Sep 17, 2001). I wonder if there
> > > > > > was some date glitch that caused a whole bunch of patches to be re-sent
> > > > > > to stable somehow:
> > > > >
> > > > > I think the crux of the problem is that sometimes patches go into
> > > > > -next with stable tags and they end getting taken into -fixes as well
> > > > > so after the merge window they end up getting picked up for stable
> > > > > again.  Going forward, if they land in -next, I'll cherry-pick -x the
> > > > > changes into -fixes so there is better traceability.
> > > >
> > > > Please do so, and also work to not have duplicate commits like this in
> > > > different branches.  Git can handle merges quite well, please use it.
> > > >
> > > > If this shows up again in the next -rc1 merge window without any
> > > > changes, I'll have to just blackhole all amd drm patches going forward
> > > > until you all tell me you have fixed your development process.
> > >
> > > Just a heads up, you will see some of these when the 6.12 merge window
> > > due to what is currently in -next and the fixes that went into 6.11,
> > > but going forward we have updated our process and it should be better.
> >
> > Can you give me a list of the git ids that I should be ignoring for
> > 6.12-rc1?  Otherwise again, it's a huge waste of time on my side trying
> > to sift through them and figure out if the rejection is real or not...
> 
> 8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
> fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2
> ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference
> 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in
> math_ceil2
> 295d91cbc700 drm/amd/display: Check for NULL pointer
> 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings
> 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference
> 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Please resend this after -rc1 is out, so we don't have to hunt for it
again.

thanks,

greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Alex Deucher]

Resending now that rc1 is out.  These should be ignored for stable.

8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2
ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference
332315885d3c drm/amd/display: Remove ASSERT if significance is zero in
math_ceil2
295d91cbc700 drm/amd/display: Check for NULL pointer
6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings
93381e6b6180 drm/amdgpu: fix a possible null pointer dereference
7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes


Alex

On Wed, Sep 4, 2024 at 1:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Aug 27, 2024 at 10:18:27AM -0400, Alex Deucher wrote:
> > On Sat, Aug 24, 2024 at 1:23 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
> > > > On Thu, Aug 15, 2024 at 1:11 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> > > > > > On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling <felix.kuehling@amd.com> wrote:
> > > > > > >
> > > > > > > On 2024-08-12 11:00, Greg KH wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > As some of you have noticed, there's a TON of failure messages being
> > > > > > > > sent out for AMD gpu driver commits that are tagged for stable
> > > > > > > > backports.  In short, you all are doing something really wrong with how
> > > > > > > > you are tagging these.
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > I got notifications about one KFD patch failing to apply on six branches
> > > > > > > (6.10, 6.6, 6.1, 5.15, 5.10 and 5.4). The funny thing is, that you
> > > > > > > already applied this patch on two branches back in May. The emails had a
> > > > > > > suspicious looking date in the header (Sep 17, 2001). I wonder if there
> > > > > > > was some date glitch that caused a whole bunch of patches to be re-sent
> > > > > > > to stable somehow:
> > > > > >
> > > > > > I think the crux of the problem is that sometimes patches go into
> > > > > > -next with stable tags and they end getting taken into -fixes as well
> > > > > > so after the merge window they end up getting picked up for stable
> > > > > > again.  Going forward, if they land in -next, I'll cherry-pick -x the
> > > > > > changes into -fixes so there is better traceability.
> > > > >
> > > > > Please do so, and also work to not have duplicate commits like this in
> > > > > different branches.  Git can handle merges quite well, please use it.
> > > > >
> > > > > If this shows up again in the next -rc1 merge window without any
> > > > > changes, I'll have to just blackhole all amd drm patches going forward
> > > > > until you all tell me you have fixed your development process.
> > > >
> > > > Just a heads up, you will see some of these when the 6.12 merge window
> > > > due to what is currently in -next and the fixes that went into 6.11,
> > > > but going forward we have updated our process and it should be better.
> > >
> > > Can you give me a list of the git ids that I should be ignoring for
> > > 6.12-rc1?  Otherwise again, it's a huge waste of time on my side trying
> > > to sift through them and figure out if the rejection is real or not...
> >
> > 8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
> > fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2
> > ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference
> > 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in
> > math_ceil2
> > 295d91cbc700 drm/amd/display: Check for NULL pointer
> > 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings
> > 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference
> > 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
>
> Please resend this after -rc1 is out, so we don't have to hunt for it
> again.
>
> thanks,
>
> greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Greg KH]

On Mon, Sep 30, 2024 at 10:10:25AM -0400, Alex Deucher wrote:
> Resending now that rc1 is out.  These should be ignored for stable.
> 
> 8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
> fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2
> ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference
> 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in
> math_ceil2
> 295d91cbc700 drm/amd/display: Check for NULL pointer
> 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings
> 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference
> 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes

Thanks, that helped a lot.

However the following two commits did not apply, is that because they
are already in the tree or do they need someone to properly backport them?

c2ed7002c061 ("drm/amd/display: Use SDR white level to calculate matrix coefficients")
b74571a83fd3 ("drm/amd/display: Use full update for swizzle mode change")

thanks,

greg k-h

Re: AMD drm patch workflow is broken for stable trees

[Alex Deucher]

On Tue, Oct 1, 2024 at 6:04 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Sep 30, 2024 at 10:10:25AM -0400, Alex Deucher wrote:
> > Resending now that rc1 is out.  These should be ignored for stable.
> >
> > 8151a6c13111 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
> > fbfb5f034225 drm/amdgpu: fix contiguous handling for IB parsing v2
> > ec0d7abbb0d4 drm/amd/display: Fix Potential Null Dereference
> > 332315885d3c drm/amd/display: Remove ASSERT if significance is zero in
> > math_ceil2
> > 295d91cbc700 drm/amd/display: Check for NULL pointer
> > 6472de66c0aa drm/amd/amdgpu: Fix uninitialized variable warnings
> > 93381e6b6180 drm/amdgpu: fix a possible null pointer dereference
> > 7a38efeee6b5 drm/radeon: fix null pointer dereference in radeon_add_common_modes
>
> Thanks, that helped a lot.
>
> However the following two commits did not apply, is that because they
> are already in the tree or do they need someone to properly backport them?
>
> c2ed7002c061 ("drm/amd/display: Use SDR white level to calculate matrix coefficients")
> b74571a83fd3 ("drm/amd/display: Use full update for swizzle mode change")

Looks like they will need backports.

Alex

>
> thanks,
>
> greg k-h