From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id F05EBC433EF for ; Tue, 7 Dec 2021 09:49:25 +0000 (UTC) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by mx.groups.io with SMTP id smtpd.web12.65004.1638870564289760153 for ; Tue, 07 Dec 2021 01:49:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=OoPHS20K; spf=pass (domain: linaro.org, ip: 209.85.208.47, mailfrom: nicolas.dechesne@linaro.org) Received: by mail-ed1-f47.google.com with SMTP id r11so54318885edd.9 for ; Tue, 07 Dec 2021 01:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2nge3mvVmF5wQdSLwa2wh4ptFna1KGjj3SQz5xBJ1a8=; b=OoPHS20KtIM/pEW/baU0n/bYjpEFscwa3mMoNJlSyg8fs/itYVWNvPGhKsFKXb3kLc N048aYhbyjv0P1LSvPNMnrzzT7ed55l3NHlb2VQUe5sNjaZkiXVbXZgbRFNO7ECT2zYr uOj+1LTqXaWkDvMmKU6LriOg57TaXjnemeAuA1awfBgf/W6d5wav/QXcMrb+Wqax91by GNYDokeZa5RkZ1tOVfz5fazSY18PGGlges3ol5T5rT1WOF44ocmGFpQAic4KaG/kbN8g RT0UZU/krGc5clX9XNzHeLpUGFgdjdDNQRUoAT4gFZzZ/PWDhUDJhluyIQVOUGKMOuUT a2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2nge3mvVmF5wQdSLwa2wh4ptFna1KGjj3SQz5xBJ1a8=; b=RKwoancsbHWkOaU1yxYR5kM5MX/Y38YerwaJrMRqf0WOH7OJQjGdjhVpJFslFomfFQ l6w+KL9xMyaG5cYWLg8HKj8cWk4UQDz2cn3CAGa/ydUI6wzTREhv9x2YdgbQS/WKF1F7 ZbRBRtvgPX6SX8MMKmYvaCUoVbY5zX9I9vf+tJuplUitNt5B4q1AK0plDpOhdvj6rASX OHuITSrRbLNEO4HzQsI/a9bfL5xKNz7YzSol7ib/BJQmPrQnjZPfQACo6HVwy9AdUfB0 cDaLx5krDjg+2JC69r63uvdllgsTNJGa5iYKYO1PiqTkFUJm3CP4wlewgw+Dj+IIWmfT tEWg== X-Gm-Message-State: AOAM530/aPtn8AZ8tNyhEjZtrrnICdT4GSyjB7iIff9JJ+oferL7SDKp Ia0aNe79lBAvvg5DWZZ8DerNcspYf5lEV250Ys6otA== X-Google-Smtp-Source: ABdhPJxXvjrQxhEWExSx8y0hynjgXaVCX4fM8kL6uK366ZTRvMSkAoA9B1UaxTPRUgsX4u0dahPEkYO3MpHQbdy6SZs= X-Received: by 2002:a17:907:6d07:: with SMTP id sa7mr53161727ejc.339.1638870562438; Tue, 07 Dec 2021 01:49:22 -0800 (PST) MIME-Version: 1.0 References: <20211201203407.218692-1-bhupesh.sharma@linaro.org> In-Reply-To: From: Nicolas Dechesne Date: Tue, 7 Dec 2021 10:49:11 +0100 Message-ID: Subject: Re: [OE-core] [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel. To: Richard Purdie Cc: Bruce Ashfield , Bhupesh Sharma , Patches and discussions about the oe-core layer , bhupesh.linux@gmail.com Content-Type: multipart/alternative; boundary="000000000000b5176205d28b49e6" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 07 Dec 2021 09:49:25 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/159284 --000000000000b5176205d28b49e6 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 1, 2021 at 10:39 PM Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfield wrote: > > On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma > wrote: > > > > > > This is a backport request for dunfell, while picking up only the > > > skeletal support for allowing mandatory dtschema handling for > > > device trees built through the kernel, introduced from kernel > > > version 5.16 onwards. > > > > The problem with adding this support to dunfell, is obvious in the > > number of patches involved. We've also said/known that at some point > > that we won't be able to support all new kernel versions with the LTS > > release. This may be the start of drawing that line. > > > > Also, we've had to do some license tweaks in master just today for one > > of the added packages (idna), so that would be needed as well. > > > > The validation isn't absolutely critical, I'd suggest that just the > > wrappers and pkg-config fixes would be a smaller footprint to allow > > the kernel to build, without the new package/feature additions to the > > dunfell release. The new packages (and full validation) could still > > possibly be done through a secondary or mixin layer. > > > > I'm not sure which way to go on this, but I thought I'd offer those > > points for discussion. > > I think this needs to be done in a mixin layer for dunfell. > ok.. what about honister? would you consider a backport of these patches for this more recent release? > > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#159062): > https://lists.openembedded.org/g/openembedded-core/message/159062 > Mute This Topic: https://lists.openembedded.org/mt/87439224/1279857 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > nicolas.dechesne@linaro.org] > -=-=-=-=-=-=-=-=-=-=-=- > > --000000000000b5176205d28b49e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 1, 2021 at 10:39 PM Richa= rd Purdie <richard= .purdie@linuxfoundation.org> wrote:
On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfiel= d wrote:
> On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma <bhupesh.sharma@linaro.org>= ; wrote:
> >
> > This is a backport request for dunfell, while picking up only the=
> > skeletal support for allowing mandatory dtschema handling for
> > device trees built through the kernel, introduced from kernel
> > version 5.16 onwards.
>
> The problem with adding this support to dunfell, is obvious in the
> number of patches involved.=C2=A0 We've also said/known that at so= me point
> that we won't be able to support all new kernel versions with the = LTS
> release. This may be the start of drawing that line.
>
> Also, we've had to do some license tweaks in master just today for= one
> of the added packages (idna), so that would be needed as well.
>
> The validation isn't absolutely critical, I'd suggest that jus= t the
> wrappers and pkg-config fixes would be a smaller footprint to allow > the kernel to build, without the new package/feature additions to the<= br> > dunfell release. The new packages (and full validation) could still > possibly be done through a secondary or mixin layer.
>
> I'm not sure which way to go on this, but I thought I'd offer = those
> points for discussion.

I think this needs to be done in a mixin layer for dunfell.

ok.. what about honister? would you consider a backpor= t of these patches for this more recent release?
=C2=A0

Cheers,

Richard


-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Links: You receive all messages sent to this group.
View/Reply Online (#159062): https:= //lists.openembedded.org/g/openembedded-core/message/159062
Mute This Topic: https://lists.openembedded.org/mt= /87439224/1279857
Group Owner: openembedded-core+owner@lists.openembedded.org<= br> Unsubscribe: https://lists.openembedded.org/= g/openembedded-core/unsub [nicolas.dechesne@linaro.org]
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-

--000000000000b5176205d28b49e6--