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 X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88150C433EF for ; Thu, 9 Sep 2021 10:35:41 +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 BC1A66115B for ; Thu, 9 Sep 2021 10:35:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BC1A66115B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de 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 4317682DF0; Thu, 9 Sep 2021 12:35:38 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de 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; secure) header.d=gmx.net header.i=@gmx.net header.b="A5uiUUiG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1FA378311F; Thu, 9 Sep 2021 12:35:36 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id AAF168200B for ; Thu, 9 Sep 2021 12:35:32 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631183728; bh=N+rwEqfsJuwYkSpvgFKZY7ZMtcQzeTzfTijYy5g0SR4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=A5uiUUiG1mGqFYNkPT3GWYH8HOOzB1gy/Eo8ONik/8fQPaoUospjixgH3OjgoIKDr cFtv4FbhSATdZFQdNiWmKvMOISJnYJOmPN/RQUJ6S3Dn08lNiC0vusqraxUBYqvkDz Ee9zg9BIjUhgTQnUq+M2ekK9x2XT8mJp4B4duES4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.55] ([88.152.144.157]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MnJlc-1mpbvg1AdI-00jKjd; Thu, 09 Sep 2021 12:35:28 +0200 Subject: Re: [PATCH 13/35] efi: Add a media/block driver for EFI block devices To: Simon Glass Cc: Ilias Apalodimas , Bin Meng , Tom Rini , Christian Melki , Alexander Graf , U-Boot Mailing List References: <20210908133405.696481-1-sjg@chromium.org> <20210908073355.13.I9b48fe5f6b8c61348f16a1b5df114282240238c0@changeid> <21126ea8-9842-49fd-c01d-6408b5a28218@gmx.de> From: Heinrich Schuchardt Message-ID: Date: Thu, 9 Sep 2021 12:35:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:u9lkEQF07+kfBxLnmo7MKumG7p4TtPBQiado2iDBWmSL17p/7dx uauROxXyaEUJirtSpgzn0pP/4xV8NT7S1wUo7QC/3/jGemxBc2K4VHE074nFXTcjes+ozeh dF+315G8O3EY233VZ3FOndZ5cKWxlFefpO9BadgSby6X5mWRU+SFr/tzvVqrc2MUljTEnnP o+W0qVrlTU/r8Op/+xeyw== X-UI-Out-Filterresults: notjunk:1;V03:K0:cOMHFhifzhE=:sFs35jeSkI/esAubb2oag1 o0KwQHUm8xaADFK0YgJvhn/169JtYh3wwF53ebUJNX69jdxfwUbVOCM5anzjeNveD2/flERmy ruV5RzENByIURszEsz5s6xU0T/Rk0B9vDWtwlUDu2/bZM4R5m1lsuOlkMvIQ8ulYk5OI+GO5j 4nuf3308JTYw1rsrEUWhdLjBxtwv/9u7WlxbtQyxUoOsqI3eejkQd5g77RJyFlrqznko/BDmQ V3sSJLxz7RK4Lsz3BEtP0Dzh3cNkuN38/FHVnnOhrlLiwKMGbY+6CSnc1TbQ3C6zhHMLwoWI2 fBIO+4XIZSmbHMkjBm7tnuno07qBEftzYKYsm/Jm96ZP1e4dTBWfa8uV5ZDB/xTSUI3iKnxX0 2PgG2o5lXVnLaVhwNlJd6MHyIjrFBSCVkp9x6HtelZ2brV6YY7XY1gWVh68KXnYVuAdclErdB akyXdhuzf312q9YcikdroctOEX6hFfvlMrAqwLaBdK+k2S/uyzM6BOjlKbM48z78LZyTENX3z oP5fBpjvcWEV6Vjm0EH4LNQDQwOKf7BeFXYDJDnI9+kEmWK9c2B7nKnNPNV7zj1zrqWSmRhxz NV6pwzwi6zkB4zKHvXwoP2Vl52H756ddFgJsJX1A4Hv1iIVFiT4bP+giAhz5R5xiq2bEj1V87 /ZoIPkhHlxg5fJJI7mdQPsqmvjbQ0VbWKM2GAQa71hP1a9gcThO71Aghj/vGeomAldoOipfrG yShuejNavu1FJL7E2esPawBhPRQvocZLjJ+4u5rFLWctnmsvcoCdCUVE4FyXaxCBEpZNkkGBD SwLYrU3fJWVboEQSho/Vmx9OI+HtrXp7+q3N/M6WNmbeE8ThFIeZf/kiko/5YTPvvEBXuFUm9 xllG3mlu4/DWeXMbtqkHytV1eYIUOyM3fXFLN422yHAhv2XcWhD6+JTlP6l4q6Wk8bWfULDjT +Mb0dpPHxCBCWIXlWG/01Z5pHOiK8Tijnfjz02uKg2Gqt+UfH3TBpLC0KostUHrF83SCwla87 iC9tw/RqREVwR8D974U9P1ZnLz/lwx+2Qab8ucAcFjzKu473ayt8PrhsSucGE3MmTBmqBIzQt NzYTzxQ6GrluQk= 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 9/9/21 10:57 AM, Simon Glass wrote: > Hi Heinrich, > > On Wed, 8 Sept 2021 at 12:04, Heinrich Schuchardt w= rote: >> >> >> >> On 9/8/21 3:33 PM, Simon Glass wrote: >>> Add a block driver which handles read/write for EFI block devices. Thi= s >>> driver actually already exists ('efi_block') but is not really suitabl= e >>> for use as a real U-Boot driver: >>> >>> - The operations do not provide a udevice >> >> efi_bl_bind() creates a udevice by calling blk_create_device() when an >> EFI application calls ConnectController() for a handle with an >> EFI_BLOCK_IO_PROTOCOL. >> >> Please, explain in some detail what you think is wrong with the existin= g >> code. > > See below: > >> >>> - The code is designed for running as part of EFI loader, so uses >>> EFI_PRINT() and EFI_CALL(). >>> - It creates block devices for all the partitions too, which is not >>> somthing we want to support in this way No, it creates a block device for the handle that was passed to ConnectController(). The handles for the partitions are created by U-Boot and these are not backed by separate block devices. >>> - The bind method probes the device, which is not permitted >>> - It uses 'EFI' as its parent device All devices that the UEFI sub-system uses must be probed. >>> >>> The new driver is more 'normal', just requiring its platform data be s= et >>> up in advance. No clue what you mean by "in advance". It is a software like iPXE that produces a handle at runtime and then calls ConnectController(). When that call is done we must create a block device which is in status probed, create handles for the partitions and install protocol interfaces on these partitions. Best regards Heinrich >>> >>> Signed-off-by: Simon Glass >> >> Please, separate this series in two. One for U-Boot on EFI and one for >> U-Boot's UEFI implementation. > > Again I'm not sure what you mean here. Please point to something you > don't want in this series, which is focussed on the app. > >> >> Best regardss >> >> Heinrich >> >>> --- >>> >>> drivers/block/Kconfig | 10 ++++ >>> drivers/block/Makefile | 1 + >>> drivers/block/efi_blk.c | 115 +++++++++++++++++++++++++++++++++++++= +++ >>> include/efi.h | 11 ++++ >>> 4 files changed, 137 insertions(+) >>> create mode 100644 drivers/block/efi_blk.c >>> > > Regards, > Simon >