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 DAB4FC433F5 for ; Tue, 12 Oct 2021 15:00:40 +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 278AC61074 for ; Tue, 12 Oct 2021 15:00:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 278AC61074 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 4403E832E6; Tue, 12 Oct 2021 17:00:37 +0200 (CEST) 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="Gw5Z7hUK"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0FE9383477; Tue, 12 Oct 2021 17:00:35 +0200 (CEST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 07EED83246 for ; Tue, 12 Oct 2021 17:00:28 +0200 (CEST) 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-xf2e.google.com with SMTP id k19so7357707qvm.13 for ; Tue, 12 Oct 2021 08:00:27 -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=m3FScIeeHlHd13nR/+JGw9kDHr7cC6gv7kcCNhl1vDM=; b=Gw5Z7hUK1NnoxOtmavCzeF98KlXEj7Mz1cK9CsoiRlqcoTqB1Voft0/1KPLd1mq7iA 5banrscNuBo1GHb2mmv6o8q8JSOTrY55N8hJRae+DYFBt5sTBv94qUX9i9TK4+PqLlFm glfpg7bN5wPNvS/LYAMF7+0I+gS1lfQBP/5cs= 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=m3FScIeeHlHd13nR/+JGw9kDHr7cC6gv7kcCNhl1vDM=; b=kbO6b4Lh4YYhSS2puwPf4OY0sD4YcUY7Jw25kTxsmEEbfli002FenhA1hRlD/hIOeu NecUvLuXjtwwtxANPkq+B5CYns6uqr9SM9q9kIBqJbrS5rMB0/6XS4RmO79uAHGSLzjo jGmODLjpf9HpQuwwKwXMCKa4I8zRyKkrH2Fj31LbvMq1DgZtrLb2VyY0uv56AUaRvuUs hkKfrWeQ1r+PizcYO+ycn5UzPm31NEo8kTiz5JTx1Hj2aDRUwMPnID9MD2I98njMbAnc EeKaml71v95UmqEKrIf/Dz+XyP9LY2CvLzrSsmxclVPJwaIsneKN9AjGcKNBA7veqM3c N/TQ== X-Gm-Message-State: AOAM530A0Cb/COe+1Myktgouhy6HqmVdQtFA35J6vBlsz+c/JqZbxSZr QkBNZBkBSUrrPD3+5u8lg+30lg== X-Google-Smtp-Source: ABdhPJyUiulNUDgI6X4jnk/YOKey4VwWQnF53P6RngdGogQx9no0bDV306gpbylYX3EL7q6MVA2iZg== X-Received: by 2002:a0c:ec0e:: with SMTP id y14mr19470011qvo.11.1634050826407; Tue, 12 Oct 2021 08:00:26 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-2c86-b4b1-e1e0-936c.res6.spectrum.com. [2603:6081:7b01:cbda:2c86:b4b1:e1e0:936c]) by smtp.gmail.com with ESMTPSA id l7sm6508020qth.81.2021.10.12.08.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 08:00:25 -0700 (PDT) Date: Tue, 12 Oct 2021 11:00:23 -0400 From: Tom Rini To: Simon Glass Cc: AKASHI Takahiro , Heinrich Schuchardt , Alex Graf , Ilias Apalodimas , U-Boot Mailing List Subject: Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model Message-ID: <20211012150023.GY7964@bill-the-cat> References: <20211001050228.55183-1-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6mlNC2kKkos1Fi35" 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 --6mlNC2kKkos1Fi35 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > Hi Takahiro, >=20 > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > wrote: > > > > The purpose of this RPC is to reignite the discussion about how UEFI > > subystem would best be integrated into U-Boot device model. > > In the past, I poposed a couple of patch series, the latest one[1], > > while Heinrich revealed his idea[2], and the approach taken here is > > something between them, with a focus on block device handlings. > > > > # The code is a PoC and not well tested yet. > > > > Disks in UEFI world: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In general in UEFI world, accessing to any device is performed through > > a 'protocol' interface which are installed to (or associated with) the = device's > > UEFI handle (or an opaque pointer to UEFI object data). Protocols are > > implemented by either the UEFI system itself or UEFI drivers. > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk > > hereafter). Currently, every efi_disk may have one of two origins: > > a.U-Boot's block devices or related partitions > > (lib/efi_loader/efi_disk.c) > > b.UEFI objects which are implemented as a block device by UEFI drivers. > > (lib/efi_driver/efi_block_device.c) > > > > All the efi_diskss as (a) will be enumelated and created only once at U= EFI > > subsystem initialization (efi_disk_register()), which is triggered by > > first executing one of UEFI-related U-Boot commands, like "bootefi", > > "setenv -e" or "efidebug". > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->op= s) > > in the corresponding udevice(UCLASS_BLK). > > > > On the other hand, efi_disk as (b) will be created each time UEFI boot > > services' connect_controller() is executed in UEFI app which, as a (dev= ice) > > controller, gives the method to access the device's data, > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > >>> more details >>> > > Internally, connect_controller() search for UEFI driver that can support > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case, > > then calls the driver's 'bind' interface, which eventually installs > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for > > * creating additional partitions efi_disk's, and > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it. > > <<< <<< > > > > Issues: > > =3D=3D=3D=3D=3D=3D=3D > > 1. While an efi_disk represents a device equally for either a whole disk > > or a partition in UEFI world, the device model treats only a whole > > disk as a real block device or udevice(UCLASS_BLK). > > > > 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc > > in plat_data is supposed to be private and not to be accessed outside > > the device model. > > # This issue, though, exists for all the implmenetation of U-Boot > > # file systems as well. >=20 > Yes, this was a migration convenience and we should be able to unpick it = now. >=20 > However we still have SPL_BLK so need to consider whether we can drop tha= t. To be clear here, in that I can hand-wave my way to seeing a use case for lib/efi_loader/ under SPL, it would not be in a world where we also still would be supporting the non-DM infrastructure, and is also not a near-term goal. --=20 Tom --6mlNC2kKkos1Fi35 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFlowMACgkQFHw5/5Y0 tyzykAv/ao7uRH4iRi1taCruiluWFRPmD0knttF3rmD6a7245p9eKJY2JbGj3y5C Q1zXxFgPVJJCFT3K0fpxpesQ8YoQ317TX8bcxRKkfljCavO1LnhNJftfEp0BCZtG Wv/jOy3plJCOrqZVDXyl9sRCQy9UnnlFAn8oEF1TMf9NGOMwMrmUg0V6ztYPHOEQ rgqOJJISm0pRkXtaCH0jIn738z80vWmjlcReiHUcr35X5Whjzta44KktFilI2lvB qEBBOL2xyaYpAfjkifr1gEPG2knkOf+TOQzrCc8SdzPABxjnjvQGEA0wP04SUVRe zv4TKey4nMaCukxp2dhyl8wpiJK+wgxdTZJ8Xt/LM+LMYLwWT6Fw+G02cOpPFurR fybUSj+Q/H0dA9wTxT+w79ztOve02T6zMYOYIhZKXO2qa9gzCxwr8Uu9La2eCVRn wNz04NkWd+8jV0SheaxphZFxpDIURNyPhRaufwSZQfRnd0Kto+HY5ealn1OC8fzS vx5Pdotf =CjxH -----END PGP SIGNATURE----- --6mlNC2kKkos1Fi35--