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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id A6DEAECAAA1 for ; Mon, 12 Sep 2022 01:55:20 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8FD26845A9; Mon, 12 Sep 2022 03:55:17 +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="n5tKuUwF"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 35035845EF; Mon, 12 Sep 2022 03:55:16 +0200 (CEST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 41D2B84133 for ; Mon, 12 Sep 2022 03:55:13 +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-pj1-x102d.google.com with SMTP id q3so6584412pjg.3 for ; Sun, 11 Sep 2022 18:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date; bh=sU+v4DrTFZsV0q94eCe4vBGqc5hZR8sWqymKy6VZYco=; b=n5tKuUwFGSOk0I7uJZ3Ca5XdbJ1hlU1mexMqAZjAIc9YxRIw27wbo+8HzIRhKZzDx8 Qrfgb3V326C4pSnE/yDu/Xy7IWizcIVRDNRben1/QKA4bzniQQ25PNUZL5LdqSYqj6GQ eUl780AdqQ7UciS5gJZ2jPxneXQSMXp2OwNSOi0o2LtBIGCXq23SJ+zWommpl6z+IN4v YHG6hM/6s8mWXD4Ue91eOLawm6fTMPv/akXW2Ul1jrlBdXUSlFxiIoTprqDMEPnG8Cvv ejKU0Xf+8Z7ZA/TuFGeoO5w2NULKAU8KkTo4Jtcp4ZjmLKxCvduyZjhw+6fCh1QhtkfH U8Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=sU+v4DrTFZsV0q94eCe4vBGqc5hZR8sWqymKy6VZYco=; b=rneCK1IzaqM50Q63b8C38N5H7PJDgRBpjTO8YNeJO2Uj5GXnxWBScnfiV7+F6C6mDt +0M67YRByKX4Ej30x/nlPVzRgzppxwWwkqpXYyBNueiY4Ok2EKCd+jz5MqG44CINIRWp buDRj7gJrcKr8jhnIP8bS6HsDGoMxOIi9UJ7qLTRSnu/qjAB9VKFYmmAV0cwLV8QDbZq hVLPrBc57b4m6QtqnVDZ7XHOmOwf+W3iU6U3my5VKC5kKn7d0PEOx+5Hlqvcu3ZgxVh4 0BhnaY/1/xKmr1qWgeS/zsxWXniYs+s7KOu/9TZnSjsNSrTkwg8Wj0ivMcCsoCp9ENW2 9SyQ== X-Gm-Message-State: ACgBeo31CQbHw6SeFHiK2m8/YZq2bV2emGenOx02+FK5Ybs0aqKg+GHP IAcvOKKPoxr1I+tWVQEm58blsQ== X-Google-Smtp-Source: AA6agR4Yn1+2giqh7rRYVfkAmiVoQfSoY2CBk0brtfei1Dlsz8xa3hpqvm+Zcfpom4Kw2qgK157uzw== X-Received: by 2002:a17:90a:1c02:b0:1e0:df7:31f2 with SMTP id s2-20020a17090a1c0200b001e00df731f2mr20835560pjs.222.1662947711314; Sun, 11 Sep 2022 18:55:11 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:b2c6:1c12:86e9:3c0a]) by smtp.gmail.com with ESMTPSA id q2-20020a170902dac200b00176acd80f69sm4566922plx.102.2022.09.11.18.55.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Sep 2022 18:55:09 -0700 (PDT) Date: Mon, 12 Sep 2022 10:55:06 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: Ilias Apalodimas , Simon Glass , Etienne Carriere , u-boot@lists.denx.de Subject: Re: [PATCH v3 1/1] efi_driver: don't bind internal block devices Message-ID: <20220912015506.GA156558@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , Ilias Apalodimas , Simon Glass , Etienne Carriere , u-boot@lists.denx.de References: <20220909141118.21166-1-heinrich.schuchardt@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220909141118.21166-1-heinrich.schuchardt@canonical.com> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean On Fri, Sep 09, 2022 at 04:11:18PM +0200, Heinrich Schuchardt wrote: > UEFI block devices can either mirror U-Boot's internal devices or be > provided by an EFI application like iPXE. > > When ConnectController() is invoked for the EFI_BLOCK_IO_PROTOCOL > interface for such an application provided device we create a virtual > U-Boot block device of type "efi_blk". > > Currently we do not call ConnectController() when handles for U-Boot's > internal block devices are created. If an EFI application calls > ConnectController() for a handle relating to an internal block device, > we erroneously create an extra "efi_blk" block device. > > E.g. the UEFI shell has a command 'connect -r' which calls > ConnectController() for all handles with device path protocol. > > In the Supported() method of our EFI_DRIVER_BINDING_PROTOCOL return > EFI_UNSUPPORTED when dealing with an U-Boot internal device. Yes, but see the below. > Reported-by: Etienne Carriere > Fixes: commit 05ef48a2484b ("efi_driver: EFI block driver") > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Etienne Carriere > Tested-by: Etienne Carriere > Reviewed-by: Ilias Apalodimas > --- > v3: > return EFI_UNSUPPORTED > changes Fixes: line > > v2: > add code comment > --- > lib/efi_driver/efi_uclass.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c > index b01ce89c84..1d7a0f57e3 100644 > --- a/lib/efi_driver/efi_uclass.c > +++ b/lib/efi_driver/efi_uclass.c > @@ -71,6 +71,15 @@ static efi_status_t EFIAPI efi_uc_supported( > EFI_ENTRY("%p, %p, %ls", this, controller_handle, > efi_dp_str(remaining_device_path)); > > + /* > + * U-Boot internal devices install protocols interfaces without calling > + * ConnectController(). Hence we should not bind an extra driver. > + */ > + if (controller_handle->dev) { This check is not good enough to distinguish the two cases, ordinary block devices and EFI-app-based devices. Remember that "dev" field is also set by start() for the latter. (We expect EFI_ALREADY_STARTED in this case.) I think that you should look at dev's uclass (and/or blk_desc's if_type) for now. Logically, I believe, controller_handle's device path could be used to determine if the handle is to be managed by this driver. UEFI spec says, "Drivers will typically use the device path attached to ControllerHandle and/or the services from the bus I/O abstraction attached to ControllerHandle to determine if the driver supports ControllerHandle." -Takahiro Akashi > + ret = EFI_UNSUPPORTED; > + goto out; > + } > + > ret = EFI_CALL(systab.boottime->open_protocol( > controller_handle, bp->ops->protocol, > &interface, this->driver_binding_handle, > -- > 2.37.2 >