Cmt: [jammy xilinx-zynqmp 0/1] Fix backported kria device tree changes

[Portia Stephens]

On Wed, Feb 21, 2024 at 02:20:09PM +0100, Manuel Diewald wrote:
> On Wed, Feb 21, 2024 at 12:30:43PM +0100, Roxana Nicolescu wrote:
> > 
> > On 21/02/2024 09:29, Manuel Diewald wrote:
> > > On Wed, Feb 21, 2024 at 09:03:25AM +0100, Roxana Nicolescu wrote:
> > > > On 20/02/2024 05:30, Portia Stephens wrote:
> > > > > [ Impact ]
> > > > > 
> > > > > * Kria device tree's were backported from Xilinx's 6.1 tree in order to add
> > > > > support for the KD240 platform
> > > > > (https://bugs.launchpad.net/ubuntu/+source/linux-xilinx-zynqmp/+bug/2046280) .
> > > > > * Testing had previously been done a development branch with non-upstreamable
> > > > > patches. 3 issues were introduced to the KD240 image that was not present on
> > > > > the development branch.
> > > > > * Since all Xilinx device tree's are so interdependent all Kria and ZCU device
> > > > > trees were updated including certified platforms.
> > > > > 
> > > > > [ Test Plan ]
> > > > > 
> > > > > * QA will run certification testing on the KD240 platform
> > > > > * Normal certification testing will be run on all other certified platforms
> > > > > 
> > > > > [ Where problems could occur ]
> > > > > 
> > > > > * This impacts the device tree for certified Xilinx platforms which could break
> > > > > any of the device touched by the change.
> > > > > 
> > > > > [ Other Info ]
> > > > > 
> > > > > * Buglink: https://bugs.launchpad.net/ubuntu/+source/linux-xilinx-zynqmp/+bug/2054366
> > > > > 
> > > > > * Private launchpad bugs that contain the regressions failure:
> > > > > https://bugs.launchpad.net/limerick/+bug/2051228
> > > > > https://bugs.launchpad.net/limerick/+bug/2051224
> > > > > https://bugs.launchpad.net/limerick/+bug/2051201
> > > > > 
> > > > > Portia Stephens (1):
> > > > >     UBUNTU: SAUCE: zynqmp.dtsi fix incorrectly backported changes
> > > > > 
> > > > >    .../arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi |  2 +-
> > > > >    arch/arm64/boot/dts/xilinx/zynqmp.dtsi        | 42 +++++++++++--------
> > > > >    2 files changed, 25 insertions(+), 19 deletions(-)
> > > > > 
> > > > Hi,
> > > > 
> > > > Any reason the subject does not include SRU? It messes up my filters.
> > > > The mailing list receives other type of emails, not only patches, and this
> > > > is
> > > > what I use to filter patches.
> > > > https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
> > > > 
> > > > Roxana
> > > > 
> > > > -- 
> > > > kernel-team mailing list
> > > > kernel-team at lists.ubuntu.com
> > > > https://lists.ubuntu.com/mailman/listinfo/kernel-team
> > > I think the SRU tag is not mandatory since the kernel is not a stable
> > > kernel yet.

I'll add the SRU flag in the future, I am essentially treating it as a
SRU'd kernel anyways. Requiring 2 reviews, submitting the SRU
justification, etc. For context, it is still a development kernel
because we have one remaining enablement project we are working on now
and we (PM's, customer, me) were concerned about the impact of limtiing
ourselves to the SRU cycle on this enablment. Once that is wrapped up I will
move it out of development.

> > > 
> > Good point indeed. But I think at least PATCH should be used to show
> > it is a patch.
> > 
> > Roxana
> > 
> > -- 
> > kernel-team mailing list
> > kernel-team at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/kernel-team
> 
> I agree, if something like PATCH was mandatory, it would be possible to
> filter for things that require reviews trivially - which is nice to
> have.
> 
> -- 
>  Manuel
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team