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=-16.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 C6D91C433F5 for ; Thu, 9 Sep 2021 19:58:51 +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 319A461100 for ; Thu, 9 Sep 2021 19:58:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 319A461100 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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 E39C483510; Thu, 9 Sep 2021 21:58:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="JGxvIE3s"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E16C483516; Thu, 9 Sep 2021 21:58:46 +0200 (CEST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 7EE04834ED for ; Thu, 9 Sep 2021 21:58:43 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wm1-x336.google.com with SMTP id u19-20020a7bc053000000b002f8d045b2caso2255114wmc.1 for ; Thu, 09 Sep 2021 12:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iW4YixVKsz7Zy9soW0ycoR+onaQBVEnHbQiblmVoAMo=; b=JGxvIE3soaipBOp74/4KDr5H3s24THPWeQ+UzZGGuupADGSfPGP+N5WfxughPqhqhN /6TBgnlK3i6hGI1Rpg+/EMOIHTJ4qEsajBvPADFEgSXX8yZ7PWXLm1jmpg5Imszfkm/C NPnjb2w3+l5Owzjj7rizr771135N0OwyOJPk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iW4YixVKsz7Zy9soW0ycoR+onaQBVEnHbQiblmVoAMo=; b=xWbgKYz6lTl55HB80kCQ4MSdI/knh1qGyHYUj965Au0DItyrJR7gwtZmwxpgOMkAB4 dCVp0LlCbrbMcxKzqytbrSyQ3VkoN9qgn+EpVOj4TCpXLEXL+iO5Iyj3xzeoTy8l1tqj 9jFR+KLmXz/YjOn86RZ6rsOfMxbDvBHEVizL8+YjvbRTLRFa6nGDRy/B3xxtTxqEsGAR gdvA6ve5aBHVdrZ2IRNk3zxB9jpxyCuPkj8xZx390S3phJTM3Ke8uTmTX+VRbXz13qO2 pHILIHzHlmvUsCxmR6W5MTX9hxhwCSx+u5dgmI3XhATdhfPDoZ0wcdeFSTjmaeKQMDD1 U0Dg== X-Gm-Message-State: AOAM532TM4Qe1Ch2wP5jhGgyjNs9oT35C3tZS/s2CdtSRdHDuPfKR061 2gtB0KfVMe9yyupvDoPIah6RLzzBBEyIBZurSD4KeQ== X-Google-Smtp-Source: ABdhPJz07O4zjwj+2OajyBoD6HwJt1ZpvsJ6MB/3v3gamIy4jGl5UMrN5toKp81BKBifAOf/7Vtb/kf1DqSjD3t1reU= X-Received: by 2002:a7b:cb04:: with SMTP id u4mr4856433wmj.18.1631217522626; Thu, 09 Sep 2021 12:58:42 -0700 (PDT) MIME-Version: 1.0 References: <20210908133405.696481-1-sjg@chromium.org> <20210908073355.13.I9b48fe5f6b8c61348f16a1b5df114282240238c0@changeid> <21126ea8-9842-49fd-c01d-6408b5a28218@gmx.de> In-Reply-To: From: Simon Glass Date: Thu, 9 Sep 2021 13:58:31 -0600 Message-ID: Subject: Re: [PATCH 13/35] efi: Add a media/block driver for EFI block devices To: Heinrich Schuchardt Cc: Ilias Apalodimas , Bin Meng , Tom Rini , Christian Melki , Alexander Graf , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" 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 Hi Heinrich, On Thu, 9 Sept 2021 at 04:40, Heinrich Schuchardt wrote: > > > > On 9/9/21 10:57 AM, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 8 Sept 2021 at 12:04, Heinrich Schuchardt wrote: > >> > >> > >> > >> On 9/8/21 3:33 PM, Simon Glass wrote: > >>> Add a block driver which handles read/write for EFI block devices. This > >>> driver actually already exists ('efi_block') but is not really suitable > >>> 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 existing > >> 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. OK, that is hard to discover so thank you for explaining it. The other items stand, in any case. > > Best regards > > Heinrich > > >>> - 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., It is fine to probe a device but this must not be done in the bind() method. Hopefully the reason for this is obvious? > > >>> > >>> The new driver is more 'normal', just requiring its platform data be set > >>> 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. In advance of using the device. Basically we can pass the platform data into the device_bind() call, so it has it right from the start. Please understand that, while the existing EFI uclass is wonky, for the reasons I have clearly explained in this patch, my intent in explaining this is to motivate adding a new uclass. I am not trying to change the existing uclass. It is just one of many wonky things in the original EFI implementation that predates your efforts. - Simon > > 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 > >