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 4EDBEC433EF for ; Mon, 4 Oct 2021 18:07:47 +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 7454061153 for ; Mon, 4 Oct 2021 18:07:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7454061153 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 2A14A831B2; Mon, 4 Oct 2021 20:07: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=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="UUI7SY5R"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E3D8F83176; Mon, 4 Oct 2021 20:07:41 +0200 (CEST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 6F2B3801B2 for ; Mon, 4 Oct 2021 20:07:38 +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=ilias.apalodimas@linaro.org Received: by mail-wr1-x429.google.com with SMTP id s15so4086762wrv.11 for ; Mon, 04 Oct 2021 11:07:38 -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:references:mime-version :content-disposition:in-reply-to; bh=ERjpZogccrNFi9sS24gNvi1wDIIU3tw6kJbL4gmI/C8=; b=UUI7SY5RMpxIs3P5Xit86yN2+zL5/uCwpsgmRcFB/bPe0fExng9o8FOrxo5TVQONjt wgC8cSDtIZ4YfcybLqWAFW7C+oE6xFdPRMxSGpI1uS5qv43Hu1dN48q2EyNZd2ILFaas xrfHkbLfsJWcrdIkvdACDtJOZZSDh2szYey4mQnJkMzBZEz7PhNBlUBXVg6kPwyM/Y3G Wc17U2tpi/en7QITXC6nDuWyXVAvbweEYOY4EN3wYF4+eZD0/egVuSifdyZpYFRMfCvs qcKtQNtq5ZrNH/jt4nWGuviHdB/qjCOZ4OEGqrqdeq5ZG1mAFAVyetKMn85ABtq5RJ9K WyTw== 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=ERjpZogccrNFi9sS24gNvi1wDIIU3tw6kJbL4gmI/C8=; b=Cc/9xpNXmrT40QpkTC/UBfUCE4dUybFHOcdsU23oFHbKHS8kx4Tp9jiAAf/aKeM+tL dheLz7Hvjx2OhhGp3rPRB3Ey5cw5WDfPNhTstVPG6ROLdixX0t3bCKnnueobn2SRzK/D MwT/+wEJx5PEr+jFS9CQsFOaG7SbPOtll8qs0xkdcXH/6ZALSveBrvJ3HhVnZfFw3k7q R7NNvuSYUB06vGWJmS380AfROtSWUH1P91dEzQKO2JCSqXPBE59yGSArBmquJSHHB/IH LAJ/p8IfcLDc0zmaErR3OJMHFcR2r0wM3VxrFPZmV9x901yAetlRtDhz2+aLuRbbSTS/ UtJA== X-Gm-Message-State: AOAM5335gwNsdWFcVxURVzePGZWpYnv+eI+voPw+ZCd7BAHDk08SC+Fj 7CmGrO6FE0AmTS2XUu9EDVIJmw== X-Google-Smtp-Source: ABdhPJySzZMsQ/pohBNiggO7SAlPH2iUVRzpFFZU7GET8D0wfUFNdGcv/KAQ4Pjl9gENcC5T7tfrfQ== X-Received: by 2002:adf:fb50:: with SMTP id c16mr16112751wrs.120.1633370857938; Mon, 04 Oct 2021 11:07:37 -0700 (PDT) Received: from enceladus (ppp-94-66-220-209.home.otenet.gr. [94.66.220.209]) by smtp.gmail.com with ESMTPSA id 143sm5260967wma.37.2021.10.04.11.07.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 11:07:37 -0700 (PDT) Date: Mon, 4 Oct 2021 21:07:35 +0300 From: Ilias Apalodimas To: Heinrich Schuchardt Cc: AKASHI Takahiro , 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: 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: <88cc8ea2-648e-c86b-37e3-bcdb73c3f482@gmx.de> 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 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 > > > > 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. > > > > 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