From patchwork Fri Dec 10 06:49:27 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 522723 Delivered-To: patch@linaro.org Received: by 2002:a05:6e04:2287:0:0:0:0 with SMTP id bl7csp2168374imb; Thu, 9 Dec 2021 22:50:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2VKcC/MJkR0RSeBUzm8XMGI0aUUSy0cfOhr4pe6Jv3uaGbR5W0l50fg+uJ1d2k+IcAD92 X-Received: by 2002:a17:906:c109:: with SMTP id do9mr22556295ejc.111.1639119024354; Thu, 09 Dec 2021 22:50:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1639119024; cv=none; d=google.com; s=arc-20160816; b=mHRDJhmuNM9rIxa8SxS32HfBOHor+0vt1N1Gqk8Sx7ZBBnvk3ZWMPCX+4HzNUpPVG+ FPqhjg2WEBGlDd5jNDFh36hWRLj+VT25w/AbIjK06KkG+M9WX804+AN7EZ4GwQKEGK2u sDgHbA4hfgtaYF2AB7eYeu5zbSc9yAgFc5B8bwushhxnsniGb1v6cMtuzzTMmDFDPdvl w1NMbefKs70C8LtJbGeSaDE/SHTV+PK0jZGg+AYh4s9J8GQEjVmfUaBsg1buEqH2pLtC askcqwYqZG8zly2w9fbs0Jt/4jTGB4qrBHQVdnol7tiuoBoLUHyX79YLjRfxLSpJra8o P0fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:dkim-signature; bh=ztYNV07sl6mlD9FA/G2zbyW1ci+CN+oQsDmFc755vuU=; b=X8rpADPeI34lk4Bjt5XVnDubUXdhKoTLrzsLTkV+3MTxIURK6mldc82A9KBhfu1JN3 894YeJnxCJBRJP7C/kJPCW6FrhBuLMaqVHg8J3uV5KvpWqkYA/rktqlJtwGdWi8d8hv3 Gt9fodLHqvMmQC/DvRYVB36/p+F+HYcmIARGmr4PZRgG6EITpGZ+QRD2NhqoRgX+MKUp 9k+nvOyhb8O0NTYVHQ7ujplmjyqKeDe09o0BUvbNsgesRYh+IZa/lHT/qAjC015/gD0g nE312J5I8bzI6Su1L60ADPXlP+G142uL2tF9uHBxOH+fuh7Vpcq6Fh6QLmDozgqsdQbC tjSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="vJBQ/NN4"; spf=pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) smtp.mailfrom=u-boot-bounces@lists.denx.de; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from phobos.denx.de (phobos.denx.de. [2a01:238:438b:c500:173d:9f52:ddab:ee01]) by mx.google.com with ESMTPS id f12si3788964edd.178.2021.12.09.22.50.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 22:50:24 -0800 (PST) Received-SPF: pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="vJBQ/NN4"; spf=pass (google.com: domain of u-boot-bounces@lists.denx.de designates 2a01:238:438b:c500:173d:9f52:ddab:ee01 as permitted sender) smtp.mailfrom=u-boot-bounces@lists.denx.de; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AD3238203C; Fri, 10 Dec 2021 07:50:20 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="vJBQ/NN4"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CB16B82054; Fri, 10 Dec 2021 07:50:18 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 8234A80257 for ; Fri, 10 Dec 2021 07:50:13 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pl1-x632.google.com with SMTP id z6so5648593plk.6 for ; Thu, 09 Dec 2021 22:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ztYNV07sl6mlD9FA/G2zbyW1ci+CN+oQsDmFc755vuU=; b=vJBQ/NN4Oci4eXN/+0a0uY+/yX4/46hixjrhW5bdKIsRJB2c+mglCTpxi9rkiaIuHS 2QAKXmGXGN9K4yCfp4HTEaINRnKI/lU8iAi+RMqtBRzguZK1gOMEJFJiXUjc8cNNMcSF 3OVvGTLstYxBGjJ8yc7VVH2lqBD2lgSt6NBbHAfWWgB5a9Rl5zEvBSbD8B6iZQxvIbPM rFfzIFZD3AHC/TwK3D7HXGitq+C5LUsp0Ay8tyEA6VFoh83QQelAwbpAJMYswn2Bl78r OeK2jkWfR3809ap6/P2Io5cYXLvxmidX0CEQyQTi11LkQOgXnv0izXTVFivnh3HbnQ9/ kUUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ztYNV07sl6mlD9FA/G2zbyW1ci+CN+oQsDmFc755vuU=; b=OxEeJdkRVSdmAWE/ANmkcKK4YzwcRvsYnX5pLhsAFEWhL+WmdOl/0u38mFDnvHqnFA ysb1j+x3UiC5i26Cf6JvgZRtBKl1vlf33at1FHK+X19b7baAB3DRgMIt9wXek5UQ1QNM rmSGX0m0hsrCgDXI+I3cuLXpcOYhOQo7CJnaGYRGqsjkp/DK+tK5JgNYNu92t5tQ614Q k5Nh9lgqIba0O1F91vXd/FX1PQ8OaDaCugjdgwOLOGjXfor1LtGw5aBFpRb6rsyar2u9 ogTBgHBA1sElwVNYUqEpAnsyO6psfhPYbVeipk8XroLFhGlRrobDkMDyTgofM2WFrE1Y xu4Q== X-Gm-Message-State: AOAM533RllHXC1dSBv/98xLvD53a2KQgs2aVhpkMhL76DOh+rJnP6lPm a8J3buUpLQ/f83bObTpUnUhkuw== X-Received: by 2002:a17:90a:c287:: with SMTP id f7mr22109139pjt.114.1639119011722; Thu, 09 Dec 2021 22:50:11 -0800 (PST) Received: from localhost.localdomain ([2400:4050:c3e1:100:75dd:4e0e:4542:936e]) by smtp.gmail.com with ESMTPSA id nn4sm1639035pjb.38.2021.12.09.22.50.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 22:50:11 -0800 (PST) From: AKASHI Takahiro To: xypron.glpk@gmx.de, agraf@csgraf.de, sjg@chromium.org, ilias.apalodimas@linaro.org Cc: masami.hiramatsu@linaro.org, u-boot@lists.denx.de, AKASHI Takahiro Subject: [RFC v2 00/20] efi_loader: more tightly integrate UEFI disks to driver model Date: Fri, 10 Dec 2021 15:49:27 +0900 Message-Id: <20211210064947.73361-1-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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 # This is a kind of snapshot of my current work. # I submit this to show my progress on this effort, and then # I haven't addressed all the issues in this version. # See the change history below. The purpose of this RPC is to reignite the discussion about how UEFI subystem would best be integrated into U-Boot driver 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: ==================== 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 UEFI 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(->ops) 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 (device) 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: ======= 1. While an efi_disk represents a device equally for either a whole disk or a partition in UEFI world, the driver 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 driver model. # This issue, though, exists for all the implmenetation of U-Boot # file systems as well. For efi_disk(a), 3. A block device can be enumelated dynamically by 'scanning' a device bus in U-Boot, but UEFI subsystem is not able to update efi_disks accordingly. For examples, => scsi rescan; efidebug devices => usb start; efidebug devices ... (A) (A) doesn't show any usb devices detected. => scsi rescan; efidebug boot add -b 0 TEST scsi 0:1 ... => scsi rescan ... (B) => bootefi bootmgr ... (C) (C) may de-reference a bogus blk_desc pointer which has been freed by (B). (Please note that "scsi rescan" removes all udevices/blk_desc and then re-create them even if nothing is changed on a bus.) For efi_disk(b), 4. A "controller (handle)", combined with efi_block driver, has no corresponding udevice as a parent of efi_disks in DM tree, unlike, say, a scsi controller, even though it provides methods for block io operations. 5. There is no way supported to remove efi_disk's even after disconnect_controller() is called. My approach in this RFC: ======================== Due to functional differences in semantics, it would be difficult to identify "udevice" structure as a handle in UEFI world. Instead, we will have to somehow maintain a relationship between a udevice and a handle. 1-1. add a dedicated uclass, UCLASS_PARTITION, for partitions Currently, the uclass for paritions is not a UCLASS_BLK. It can be possible to define partitions as UCLASS_BLK (with IF_TYPE_PARTION?), but I'm afraid that it may introduce some chaos since udevice(UCLASS_BLK) is tightly coupled with 'struct blk_desc' data which is still used as a "structure to a whole disk" in a lot of interfaces. (I hope that you understand what it means.) In DM tree, a UCLASS_PARTITON instance has a UCLASS_BLK parent: For instance, UCLASS_SCSI --- UCLASS_BLK --- UCLASS_PARTITION (IF_TYPE_SCSI) | +- struct blk_desc +- struct disk_part +- scsi_blk_ops +- blk_part_ops 1-2. create partition udevices in the context of device_probe() part_init() is already called in blk_post_probe(). See the commit d0851c893706 ("blk: Call part_init() in the post_probe() method"). Why not enumelate partitions as well in there. 2. add new block access interfaces, which takes a *udevice* as a target device, in U-Boot and use those functions to implement efi_disk operations (i.e. EFI_BLOCK_IO_PROTOCOL). 3-1. maintain a bi-directional link between a udevice and an efi_disk by adding - a UEFI handle pointer as a tag for a udevice - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj") 3-2. synchronize the lifetime of efi_disk objects in UEFI world with the driver model using - event notification associated with device's probe/remove. 4. I have no answer to issue(4) and (5) yet. Patchs: ======= For easy understandings, patches may be categorized into seperate groups of changes. Patch#1-#10: DM: add device_probe() for later use of events Patch#11-#12: DM: add new features (tag and event notification) Patch#13-#16: UEFI: dynamically create/remove efi_disk's for a raw disk and its partitions For removal case, we may need more consideration since removing handles unconditionally may end up breaking integrity of handles (as some may still be held and referenced to by a UEFI app). Patch#17-#18: UEFI: use udevice read/write interfaces Patch#19-#20: UEFI: fix-up efi_driver, aligning with changes in DM integration [1] https://lists.denx.de/pipermail/u-boot/2019-February/357923.html [2] https://lists.denx.de/pipermail/u-boot/2021-June/452297.html Change history: =============== RFCv2 (Dec 10, 2021) * rebased on 2022-rc3 * re-order and merge some related commits into ones * call device_probe() in MMC (not bind, but) probe hook (patch#5) * fix a wrong name of variable (patch#7) * add patch#9 * invoke device_probe() for virtio devices (patch#10) * add DM event notitication (from Simon) (patch#11) * add DM tag support (patch#12) * move UCLASS_PARTITION driver under disk/ (patch#13) * create partition's dp using its parent's. This change is necessary in particular for 'efi_blk' efi_disk (patch#13) * modify the code so that we will use new features like tags and event notification (patch#13,15,16,20) * rename new functions from blk_read/write() to dev_read/write() (patch#17,18) * isolate changes in efi_driver from the rest (in efi_loader) (patch#19) * drop the previous patch#22 ("efi_selftest: block device: adjust dp for a test") due to the fix in patch#13 RFC (Nov 16, 2021) * initial RFC AKASHI Takahiro (19): part: call part_init() in blk_get_device_by_str() only for MMC blk: add a helper function, blk_probe_or_unbind() scsi: call device_probe() after scanning usb: storage: call device_probe() after scanning mmc: call device_probe() after scanning nvme: call device_probe() after scanning sata: call device_probe() after scanning block: ide: call device_probe() after scanning dm: fix an 'undefined' error in some macros virtio: call device_probe() in scanning dm: add tag support dm: disk: add UCLASS_PARTITION dm: blk: add a device-probe hook for scanning disk partitions efi_loader: disk: a helper function to create efi_disk objects from udevice efi_loader: disk: a helper function to delete efi_disk objects dm: disk: add read/write interfaces with udevice efi_loader: disk: use udevice instead of blk_desc efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI) devices efi_driver: align with efi_disk-dm integration Simon Glass (1): dm: add event notification cmd/virtio.c | 21 +- common/Kconfig | 11 + common/Makefile | 2 + common/board_f.c | 2 + common/event.c | 103 ++++++++++ common/log.c | 1 + common/usb_storage.c | 4 + disk/Makefile | 3 + disk/disk-uclass.c | 249 ++++++++++++++++++++++ disk/part.c | 3 +- drivers/ata/dwc_ahsata.c | 5 + drivers/ata/fsl_sata.c | 11 + drivers/ata/sata_mv.c | 5 + drivers/ata/sata_sil.c | 12 ++ drivers/block/blk-uclass.c | 17 ++ drivers/block/ide.c | 4 + drivers/core/Makefile | 2 +- drivers/core/device-remove.c | 9 + drivers/core/device.c | 9 + drivers/core/tag.c | 162 +++++++++++++++ drivers/mmc/mmc-uclass.c | 13 ++ drivers/nvme/nvme.c | 4 + drivers/scsi/scsi.c | 5 + include/asm-generic/global_data.h | 3 + include/blk.h | 12 ++ include/dm/device-internal.h | 10 + include/dm/device.h | 8 +- include/dm/tag.h | 76 +++++++ include/dm/uclass-id.h | 1 + include/efi_loader.h | 4 +- include/event.h | 105 ++++++++++ include/event_internal.h | 34 +++ include/log.h | 2 + include/part.h | 18 ++ lib/efi_driver/efi_block_device.c | 34 +-- lib/efi_loader/Kconfig | 2 + lib/efi_loader/efi_disk.c | 329 ++++++++++++++++++++++-------- lib/efi_loader/efi_setup.c | 11 +- test/common/Makefile | 1 + test/common/event.c | 87 ++++++++ test/test-main.c | 5 + 41 files changed, 1274 insertions(+), 125 deletions(-) create mode 100644 common/event.c create mode 100644 disk/disk-uclass.c create mode 100644 drivers/core/tag.c create mode 100644 include/dm/tag.h create mode 100644 include/event.h create mode 100644 include/event_internal.h create mode 100644 test/common/event.c