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 B0D5EC433F5 for ; Tue, 5 Oct 2021 02:27:53 +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 069E7613A1 for ; Tue, 5 Oct 2021 02:27:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 069E7613A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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 3ABD4805F9; Tue, 5 Oct 2021 04:27:50 +0200 (CEST) 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="ca5MNGUh"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 46B4780641; Tue, 5 Oct 2021 04:27:48 +0200 (CEST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 946298033A for ; Tue, 5 Oct 2021 04:27:44 +0200 (CEST) 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-pf1-x42f.google.com with SMTP id c29so5694271pfp.2 for ; Mon, 04 Oct 2021 19:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=qnoAAHqVtsuuw32S4574DdqB4HUc0JqOfyJpKfssr/k=; b=ca5MNGUhIs5LXxl3SeVn1RssMs1CyJJwAnh6saBLbwYLm5rBxQUpRvKQp/FMTiwAEx 80wqTZHhocivRn5Eup5dlfdLO6qRM/E1Gh5GNFgn4DM7CYSKOcjNG9UCLs7tnED6VORK 5Nbo/6rdD6Q/u2xFpjq24iPWVCnutSXO9zpuw60NoCACfvkiC7NKtQSUO4iJiSChnVFo K4IcZ4wzFERbSAfk0mQzFhwc1lxJtLFns1OAflw5vCIjWVrxJOvGZkEyV5iAklFlHjIH 6j1gKEFZaMledHuO9vpd9Nw6tu4D36wjXQdLBmPY7rBC2A2QCpj5+WwAXGZJUj9G0ik+ yP6Q== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=qnoAAHqVtsuuw32S4574DdqB4HUc0JqOfyJpKfssr/k=; b=Fa9hL2PiXuhR4QHN4GjSJ0t76rWZKP7/w7PpVwEcgj17OPH/6WN1g1hSexRUUs+nha GqS8eq1TebOrZ7tqq/F5Y7AUD2N3wDCw3JzjJQraKOV9UlxJi8L4tT/r/Sz2VviJlC1z f/J9jd5QjK+nDtsJLcgKvHZf9DpuxznwNXb85ro6Qr3STiw7fwDBPITCS5JZuKsHL68b S811ZnNgzjZaiNt0YKFAir2SjNSrVaXRTTL/0GUGYba1OVqrbnfblsqMA/AeWOnnH9On 9iQMVRQunvyndKXH6x0zcO+2RDmja5ceB3XRAzCSSSAb2tYylcjSPlbEHGBJBkRhhwOk 76hg== X-Gm-Message-State: AOAM5332BBlknPg/gR7740MFvSZFYcczgJPbRVbVmWRmEnEm7aaVb0zA tM5jM6DAFtjj9tCMXX9wF22KLw== X-Google-Smtp-Source: ABdhPJxwc597WSjfPJYuWKRdlVrVsoaAyPAgCwPa5igGStkd39mXmI5C8QKDWFpk2YoPxtgFqsRp5A== X-Received: by 2002:aa7:84d8:0:b0:44c:12c4:7d83 with SMTP id x24-20020aa784d8000000b0044c12c47d83mr22516189pfn.61.1633400862781; Mon, 04 Oct 2021 19:27:42 -0700 (PDT) Received: from laputa (122-100-26-39m5.mineo.jp. [122.100.26.39]) by smtp.gmail.com with ESMTPSA id z9sm5398050pgz.94.2021.10.04.19.27.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 19:27:42 -0700 (PDT) Date: Tue, 5 Oct 2021 11:27:37 +0900 From: AKASHI Takahiro To: Ilias Apalodimas Cc: Heinrich Schuchardt , u-boot@lists.denx.de, agraf@csgraf.de, sjg@chromium.org Subject: Re: [resent RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model Message-ID: <20211005022737.GE39521@laputa> Mail-Followup-To: AKASHI Takahiro , Ilias Apalodimas , Heinrich Schuchardt , u-boot@lists.denx.de, agraf@csgraf.de, sjg@chromium.org References: <20211004034430.41355-1-takahiro.akashi@linaro.org> <88cc8ea2-648e-c86b-37e3-bcdb73c3f482@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Mon, Oct 04, 2021 at 09:07:35PM +0300, Ilias Apalodimas wrote: > On Mon, Oct 04, 2021 at 04:47:53PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > [...] > > > > 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.) > > I think it makes more sense the way it's currently defined. I don;t see a > point in hiding partitions within UCLASS_BLK Yeah. But even with my UCLASS_PARTITION, it provides block-level io's through blk_read/blk_write() APIs. So someone may wonder why two different type of udevices have the same interfaces :) > > > > > > 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 "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 by adding > > > - a UEFI handle pointer in "struct udevice" > > > - a udevice pointer in UEFI handle (in fact, in "struct efi_disk_obj") > > > > An EFI application can create handles with any combination of protocols, > > e.g. a handle with both the block IO protocol and the simple network > > protocol. This means that a udevice cannot be assigned to a handle > > created by an EFI application. > > > > When the EFI application calls ConnectController() for the handle, > > U-Boot can create child controllers. If U-Boot creates a udevice for > > such a child controller, it has to store the udevice pointer. > > lib/efi_driver/efi_block_device.c uses a private data section but you it > > could be preferable to use a field in struct efi_obj. > > > > I agree with Heinrich here. Basically U-Boot has to be in charge of that. > Once ConnectController has been called U-Boot should create an 1:1 mapping > between udevice <-> handle and shouldn't be allowed to change that. Again, are you sure you're talking about the implementation of efi_disk for U-Boot's block device (the path(1) in my previous reply to Heinrich)? -Takahiro Akashi > > > > > > 3-2. use device model's post_probe/pre_remove hook to synchronize the lifetime > > > of efi_disk objects in UEFI world with the device model. > > > > > > 4. I have no answer to issue(4) and (5) yet. > > > > 4) A udevice shall only exist for the child controller handle created by > > U-Boot and not for the controller handle created by an EFI application. > > > > 5) The stop() method of the driver binding protocol has to take care of > > destroying the child controllers and the associated udevices. > > > > Best regards > > > > Heinrich > > Thanks > /Ilias