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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 886A7C433F5 for ; Mon, 1 Nov 2021 15:19:22 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7C9D3610A0 for ; Mon, 1 Nov 2021 15:19:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7C9D3610A0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B9AAF83410; Mon, 1 Nov 2021 16:19:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="sejKm7ik"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5D8F18350D; Mon, 1 Nov 2021 16:19:17 +0100 (CET) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 879D583383 for ; Mon, 1 Nov 2021 16:19:13 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf35.google.com with SMTP id g25so10394285qvf.13 for ; Mon, 01 Nov 2021 08:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=av3qt3fRrqYCmbE4wrCfllMKSIj2OPg4JORtpvmCKIU=; b=sejKm7ikxwmdqkifmdaUezPvL0qXFfeRH/w3wt7lI6DzWcUvxcas7Mf/AVrS3Rkmsu mzA4fUoBhgPTXqybzvaVObJ+bvW/gVmBT+y2p0omzk91xWJ9IhKpl2IgmMEJA8rMvkw+ +a7fFjOzTIS3SEIR6mttEpRHkNsF5LLN7xdjU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=av3qt3fRrqYCmbE4wrCfllMKSIj2OPg4JORtpvmCKIU=; b=J3+wSTHIU1bEP/KlEQeq8XYWCekEMuhAW0n7ItPLMLCrMQ/5GuqJNBbHRXKizaL+N9 SEOTARI2Ouqa94X+/CR93vddpzVn7a2egj7SdDUb/2mVdre54MH/r+EWMMJFFujTIztN 7C/x2RHPWbPECdHVb+H3uJsdw4Yg8LG/j43GHnZYwyn3WSmjvizA3PnkWzE5pBsErWXQ /D7jLB5lMLhNDsa0y3lUC5TZOn6nny2/PptYrtcA4GafgiDtoynYlHZXhhJTcSt99OAT FJfs82rC6MCc4/K2aFyir/M9EY8X6cshr2nmjGogv4a0Z9DJ0vIJqM6rainIUfhJ0cyV /hvA== X-Gm-Message-State: AOAM530sLi71UKREq/dqHk7SD1a3v1vc7Fhvk7TVv+jJrU4qZuRiEsa0 ujUXnkrMY3KSOddsMfIiWjLLmg== X-Google-Smtp-Source: ABdhPJx/7sFmRP1VxRJ9s/PBl/H0ElZwwrTPXXpQvKn+2AnP5uz20y3FXkMmiLXUF8XklCG9QUoVhg== X-Received: by 2002:ad4:5f0d:: with SMTP id fo13mr13778002qvb.10.1635779952194; Mon, 01 Nov 2021 08:19:12 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-4914-04c9-a84a-a30a.res6.spectrum.com. [2603:6081:7b01:cbda:4914:4c9:a84a:a30a]) by smtp.gmail.com with ESMTPSA id m68sm10229581qkb.105.2021.11.01.08.19.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Nov 2021 08:19:11 -0700 (PDT) Date: Mon, 1 Nov 2021 11:19:09 -0400 From: Tom Rini To: Ilias Apalodimas Cc: Simon Glass , =?iso-8859-1?Q?Fran=E7ois?= Ozog , U-Boot Mailing List , Mark Kettenis , Heinrich Schuchardt , Sean Anderson , Marcel Ziswiler Subject: Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage Message-ID: <20211101151909.GH24579@bill-the-cat> References: <20211026002344.405160-3-sjg@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vr1sEM+RgL05fCrX" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --vr1sEM+RgL05fCrX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote: > Hi Simon, >=20 > [...] >=20 > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > separate tool and domain? You guys could really pull things together > > > > and reduce the fragmentation, if you took it on. > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > for code they have written. What gives? > > > > > > That's completely inaccurate. We've added selftests for *every* > > > single feature we've sent for EFI up to now. Functionality wise the > > > past 2 years we've added > > > - EFI variables > > > - EFI secure boot > > > - capsule updates > > > - initrd loading > > > - efi TCG protocol > > > - ESRT tables > > > - RNG protocol > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_boote= fi() > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableNam= e() > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > de489d82e3189 test: test the ESRT creation > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certifi= cates > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load = initramfs > > > > > > and I am pretty sure I am forgetting more on functionality and selfte= sts. > > > > > > So basically we've either contributed new selftests for *everything* > > > we've or fixed the existing ones. The only thing that's not merged is > > > the TCG selftests which are on upstream review. > >=20 > > Er, I didn't say or mean that no tests were written, just that there > > is too much push-back on it. Heinrich put a huge amount of effort into >=20 > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltest= s=20 > as part of our patchsets.=20 And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily. > > the tests and basically created a strong base for it. Congrats and > > huge kudos to him. As to Linaro, no offence intended, and it is great > > that all these tests have been added. Thank you for your efforts and > > it is very helpful. But I think you miss my point. Or perhaps you > > don't even agree with it? I sent an email about this on one patch just > > a day or two ago. >=20 > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. >=20 > So bottom line, we are contributing selftests as always, we just don't ag= ree=20 > with the way *you* want this specific TPM test, trying to force us into s= andbox. > So instead of respecting what we have (which btw is acceptable from u-boo= t's=20 > perspective and cleans up a lot of the TPM crud along the way), you went = ahead > making misleading statements on the selftests we contribute, in general. = What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encourag= ing ... and > very productive. >=20 > >=20 > > As to the leadership side (my bigger point), Linaro is leading us all > > down this fragmented path, with TF-A, FIP, more and more binaries and > > larger firmware diagrams. Or do you disagree with that too? > >=20 >=20 > Of course I disagree. People decided not to use SPL for their own reason= s. > I am certainly not qualified to answer why Arm choose to do that, but it = seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly vi= ew > things differently. FWIW it's *our* work mostly that made U-Boot SystemR= eady > compliant, which is something Arm pushes for [5]. Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work. --=20 Tom --vr1sEM+RgL05fCrX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmGABWYACgkQFHw5/5Y0 tyxTeAwAsITfOoXjGpRgIt5rlOP3qJXKQvgU+yRPcFnvSmSXjAiAFqowU6w11YKn bCNbQt/JY5Y+xgqJQi9I2SfHBtfXHDNwssN1DIW37mRxEZ7W2yiEc0OmLA9QbJ78 Fx15wNe2CEgajyFaTlbTNJlE8VAfe3aFuY1cnAbCUnrqfZuoYDh4Rkd+y5lo6sPz 8AlM8G1HjVw+1iaBu5EAu+LnFiaVRRE/zayU8juTNUZ9a+SxlnaCXctIXM79EMmG g2Ardok7NEKOVbEkl/9/kYbumjvJZYXkrD0GjRgfBzRJN4k5/+Thee/k0qwbaQyE DidfPneFlfev7kPYPdpHLs5aY6frQRuOkwPCNt+9ZfsMO/o4L3u+jMM/xfW7j+dL DUq5RWUK6k/HzmgttiOREPlPAzDpgTdQV5f6htsMAlf94dklXOHa3hQFYl1+LAqa pz5rgDd07d39mjeO2p78aF0QR6o7ZDenMCUIPjbl/2kpLeXRYnA7/yq79QhTRgig g3D6cTa+ =M9/+ -----END PGP SIGNATURE----- --vr1sEM+RgL05fCrX--