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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id BC3CFC433F5 for ; Wed, 9 Mar 2022 14:26:08 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CB88383935; Wed, 9 Mar 2022 15:26:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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="jewj4sA7"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5366C8023A; Wed, 9 Mar 2022 15:26:03 +0100 (CET) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 78F358393E for ; Wed, 9 Mar 2022 15:25:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x830.google.com with SMTP id c4so1990577qtx.1 for ; Wed, 09 Mar 2022 06:25:55 -0800 (PST) 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=Cum/yCWBAgfBv7msNp41CeVa08rj1AZa73ANMSDvA2g=; b=jewj4sA7KNsfPfdFMO0PrH1epT3dF0G517vNx4mV8F6nptPWFqgnUsQ6Bavha3usQV xaaP/7W53ASnQhwFzklsSNPA1v2U3lpGVZiW/4SZFKBFxSuUWJqpye6fnBREJuqUYmOh jWdxCMbbuOzu7cwSjjPTcb/dUK0EyHB/djrM0= 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=Cum/yCWBAgfBv7msNp41CeVa08rj1AZa73ANMSDvA2g=; b=a8bkDfYeYvrsQ/tLzyYzaitreddnSRUDoTkVGMUX+bOJnwl30pndrq7VqKa/bUT7Q9 1OiGhu8JrRJYwWZtZzyRz/LkiAE+daa4rgAFUe+ZdHOAal3Vmdo9TONRoUXyRRUJxfgV z9VsLoyhkemLldAiW/7wpC+aoTcnAtGi+wMhE5pZ3ZTnSy8V0w/74tP7jpbjn2Z0FLJd Kaqc6UiboS6X9Jg7PgUKXJ9oTmuHFSzVQmdUD4wGZn26QnICCWgABX1FD+dVSyWJVpvL Ea0GVr5s4mGo8PlfahG6mxyFvsVzEDUwj0Y9m3pVgLpaOXpt+hxwIpJfrJG1YUIQvzkP W6ng== X-Gm-Message-State: AOAM532Jg27IA+Wsq+LSkN4K3h/QOI4uelsmxxo0mUASG3gXZ9Epzt63 z1RGj1Mbqjy/kCf3Qwj/ZKC8Fw== X-Google-Smtp-Source: ABdhPJzdWDF963VB4MeV9LGSIm0V5VYA2CgejO3nUvZN8yt+UOlFxXDbQfkfyhhI3eSOP11/l83cLg== X-Received: by 2002:ac8:5c14:0:b0:2de:2b69:dae7 with SMTP id i20-20020ac85c14000000b002de2b69dae7mr17408147qti.185.1646835954231; Wed, 09 Mar 2022 06:25:54 -0800 (PST) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id j188-20020a3755c5000000b0067d1c76a09fsm1009351qkb.74.2022.03.09.06.25.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 06:25:53 -0800 (PST) Date: Wed, 9 Mar 2022 09:25:50 -0500 From: Tom Rini To: Simon Glass , Soeren Moch Cc: AKASHI Takahiro , Masami Hiramatsu , U-Boot Mailing List , Lukasz Majewski , Peng Fan , Bin Meng , Jaehoon Chung , Stefan Roese , Ilias Apalodimas , Heinrich Schuchardt Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model Message-ID: <20220309142550.GS5020@bill-the-cat> References: <20220308113657.221101-1-takahiro.akashi@linaro.org> <82d88a69-159a-257d-2fcb-b6226bff6fe4@gmx.de> <6465499b-8c7b-daea-1729-628ed9252eea@web.de> <20220309001314.GQ5020@bill-the-cat> <20220309030035.GR5020@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MbsZhpoBPAblP5dJ" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean --MbsZhpoBPAblP5dJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 08, 2022 at 08:10:38PM -0700, Simon Glass wrote: > Hi Tom, >=20 > On Tue, 8 Mar 2022 at 20:00, Tom Rini wrote: > > > > On Tue, Mar 08, 2022 at 07:32:59PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 8 Mar 2022 at 17:13, Tom Rini wrote: > > > > > > > > On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote: > > > > > Hi Soeren, > > > > > > > > > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 08.03.22 17:56, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote: > > > > > > >> > > > > > > >> On 3/8/22 12:36, AKASHI Takahiro wrote: > > > > > > >>> With this patch set[1] applied, UEFI subsystem maintains a = list of its > > > > > > >>> disk objects dynamically at runtime based on block device's= probing. > > > > > > >>> (See "issues" below.) > > > > > > >>> > > > > > > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > > > > >> > > > > > > >> This series together with Simon's series breaks multiple boa= rds due to > > > > > > >> size constraints: > > > > > > >> > > > > > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipeli= nes/11197 > > > > > > >> > > > > > > >> Please, investigate how to work around this issue. > > > > > > > > > > > > > > tbs2910 - perhaps we should just drop this board? It doesn't = use > > > > > > > DM_SERIAL and still uses OF_EMBED > > > > > > > > > > > > Are we again at the same point? You are breaking working boards= with > > > > > > (for these boards) useless additions, and all you come up with = is > > > > > > "remove this board". Of course without adding the board maintai= ner. > > > > > > > > > > I'm just expressing reasonable frustration that this board uses > > > > > OF_EMBED and does not use DM_SERIAL, after all of this time. Why > > > > > should the rest of the U-Boot developers care more about this boa= rd > > > > > than the maintainer? > > > > > > > > Please keep in mind Simon that we've had zero releases with the > > > > DM_SERIAL migration warning being posted, v2022.04 will be the first > > > > one. > > > > > > Yes, understood :-) For OF_EMBED though...? > > > > No deadline and 50 boards. >=20 > Er, there has been a build message about that since the beginning, so > people ignored it. Do we really need to make the build fail for these > sorts of things? Perhaps so, but it is a sad situation. Yes, in hind-sight, "don't do that" wasn't the right path. It would be a good idea to start a different thread and see what / how the platforms can be migrated away. > > > It was actually quite hard to add a migration message until we added > > > the CONFIG_SERIAL base thing and that was a pain to do. > > > > > > For those of us who take on larger refactors etc., we end up spending > > > a lot of our time on these few platforms. I'm not picking on tbs2910in > > > in particular. > > > > Well, the flip side of the problem here is that there's a number of > > platforms with real constraints to them and it keeps being "can we drop > > this yet?" without CC'ing the board maintainer on the series that once > > again pushes a given platform to the limit. I would expect no size > > growth to tbs2910 for the topic of this series since it disables > > EFI_LOADER entirely, so why is it a problem? >=20 > The partition changes are going to add some size anyway, I expect. I > have not actually analysed it though. Perhaps we can just disable a > filesystem? I was a bit too absolutist there, sorry. Yes, a few hundreds of bytes here-and-there is probably a non issue. But it shouldn't be kilobytes. It really shouldn't push things over the line. And on the tbs2910 side, Soeren, can you look at enabling LTO for this platform? That would likely buy a good bit of space savings. That might well be needed to do further DM migrations/etc. --=20 Tom --MbsZhpoBPAblP5dJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmIouOsACgkQFHw5/5Y0 tyzAdwv/dPH29crJpTZxllWyNaSt719e53LNKoc5PGGaur7RYKrjv1EDbiCZ7Mfo NeDyzDRvlahtvuhk9y26BLEamhCKOsasqQ2muiSmlxgOYeepvjZQi/dtX3IETlFR A2R1EKjr+IK31RvTHHnRhrYVrGF7wMyt/+ERPbgWoQ5T10vIQvDrYWHZ7+pEdhoT e9pZnfsAOzvnXT6mKj4WC7IYQ/OU5ClN8PACyXjz6Yl0Hp/pVpsAf3T22/y0x7x6 xdsbFHD8r5DT/tBDbzok6dNzkfBsjTyYej0YrSUc+uhDwRsSjrI+HylTnTVaHe9H 4Mq1zI6NgAJVxx+oDmOwSFoWv7/+/45DEqfWyXYzcdB0kDvYCVsf4hMdqjtNYCA7 PEL9Btq1SumfOjjKR7Db0v4a/hrd4crqHGGi22/yQcgwyHQHJKUtn+U5QLEWDRNE 7jWgPsswsGvLVHjxBCBPjU+GC/u4o8HeMpF6aXCfrnrsAXloD8/MT8iCeSN2RFq0 Eno30ELp =IV8n -----END PGP SIGNATURE----- --MbsZhpoBPAblP5dJ--