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 CC9BBC433EF for ; Tue, 19 Jul 2022 23:56:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C81C383FAD; Wed, 20 Jul 2022 01:56: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="S49S4PtH"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AB7DA83FEA; Wed, 20 Jul 2022 01:56:49 +0200 (CEST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 73C4F83E92 for ; Wed, 20 Jul 2022 01:56:46 +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-x42b.google.com with SMTP id 17so4722983pfy.0 for ; Tue, 19 Jul 2022 16:56:46 -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; bh=dtLhHWh4X6mrbjUiJi+FRihXbW+BNQGldmTO8wes45w=; b=S49S4PtH6xbGZHrKBEXGhmCAzDXRjjLoTufY9mJWDgI+5jTR2NypY1scodgWa/phEq CaoEo4Hv0TtwUsCBl4D3JY8pUKO84lKK1EjjXP3HEV+PXgJyVKybCY8GogzMTZjbYa86 KEoTYfPxhlLLxrTqB26eJHQELHUoQk7egE57qIG7Js/6zR6ClNjQpWcblURJVQrKtjVr IRNbDgHmkimvkRDsTsGB+7dNclR/HP1ZR8A6rDjJB/IheBgV99naL7uxG6791xRGNJnx FjPuJHxt9SwiKVdxr84B3aZ3Vv2JqK0k+5rG+lVyQKI8qGPRyMjo0BpCc8ItkUZmCP0D lKEw== 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; bh=dtLhHWh4X6mrbjUiJi+FRihXbW+BNQGldmTO8wes45w=; b=a5IHF0ZcMpAdiScIQN4Fyi1lvrxy0uXGol46Hcgf+RyMVthZ/inV7+BnY54sn/eLZR hfqfHQNLeF2YCe+4Xp0PQkpZgnBBq8yRM7E462D2E9pBEGxh1VgKtacGZrHq7UJq4AFm jdOnxFHKZQzW0zXFG+r16+ijZvaqcIPM6VRs6M6CRb3xii3XBbkbHqNVh2Tkm4oYoMSX SnCNbPaiM93TDgIgL/+JxSZVHJz81mBNKA4PoRwtIoY6F2TIo5EG34rP9GzM5KTKX4tG 8B9I49FXSIOG6WFe7XzWY5MA0kyj81uW9Kl5Y74b1opOcHZmtYwKCPdcQTfgvo3kAIpD J+aA== X-Gm-Message-State: AJIora//nlyGp87BPZrRBtHmMueA/fRdRaPxgfmezx5RLqBr3TE8WSeu z2N77WkrXouy4btPPL/2CdHD5w== X-Google-Smtp-Source: AGRyM1tR86xE1nOc/qxBr/TYinMsC0Yh0F/V8CGMfrxYRkBQEbAAq8958jrxRH3JiKHIBQjDAaZOtQ== X-Received: by 2002:a63:1c0f:0:b0:41a:3b20:5f8c with SMTP id c15-20020a631c0f000000b0041a3b205f8cmr8028063pgc.44.1658275004346; Tue, 19 Jul 2022 16:56:44 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:f416:6ef9:e0c6:d3cb]) by smtp.gmail.com with ESMTPSA id b68-20020a62cf47000000b0052ab92772a0sm12370824pfg.98.2022.07.19.16.56.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 16:56:43 -0700 (PDT) Date: Wed, 20 Jul 2022 08:56:39 +0900 From: Takahiro Akashi To: Heinrich Schuchardt Cc: Masahisa Kojima , Ilias Apalodimas , Simon Glass , Mark Kettenis , u-boot@lists.denx.de Subject: Re: [RESEND v9 1/9] efi_loader: move udevice pointer into struct efi_object Message-ID: <20220719235639.GA36287@laputa> Mail-Followup-To: Takahiro Akashi , Heinrich Schuchardt , Masahisa Kojima , Ilias Apalodimas , Simon Glass , Mark Kettenis , u-boot@lists.denx.de References: <20220715144749.30564-1-masahisa.kojima@linaro.org> <20220715144749.30564-2-masahisa.kojima@linaro.org> <0a2d9892-7bc7-a4e4-6052-325edcc7ace6@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a2d9892-7bc7-a4e4-6052-325edcc7ace6@gmx.de> 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 Sun, Jul 17, 2022 at 10:09:42AM +0200, Heinrich Schuchardt wrote: > On 7/15/22 16:47, Masahisa Kojima wrote: > > This is a preparation patch to provide the unified method > > to access udevice pointer associated with the block io device. > > The EFI handles of both EFI block io driver implemented in > > lib/efi_loader/efi_disk.c and EFI block io driver implemented > > as EFI payload can posess the udevice pointer in the struct efi_object. > > > > We can use this udevice pointer to get the U-Boot friendly > > block device name(e.g. mmc 0:1, nvme 0:1) through efi_handle_t. > > > > Signed-off-by: Masahisa Kojima > > --- > > Newly created in v9 > > > > include/efi_loader.h | 8 ++++++++ > > lib/efi_loader/efi_disk.c | 20 +++++++++++++------- > > 2 files changed, 21 insertions(+), 7 deletions(-) > > > > diff --git a/include/efi_loader.h b/include/efi_loader.h > > index 3a63a1f75f..bba5ffd482 100644 > > --- a/include/efi_loader.h > > +++ b/include/efi_loader.h > > @@ -226,6 +226,12 @@ const char *__efi_nesting_dec(void); > > #define EFI_CACHELINE_SIZE 128 > > #endif > > > > +/** > > + * efi_handle_to_udev - accessor to the DM device associated to the EFI handle > > + * @handle: pointer to the EFI handle > > + */ > > +#define efi_handle_to_udev(handle) (((struct efi_object *)handle)->dev) > > This conversion will hide errors if handle is not of type efi_handle_t. > We should avoid the conversion and see build time errors instead. > Please, remove the macro. I don't think we should remove the macro itself, but only the type casting. I think it is a good practice to hide an implementation how the relationship between udev and efi_object is maintained *behind* accessor macros. > For every handle of type efi_handle_t you can access the field > handle->dev directly. > > For struct efi_disk_obj we can use disk->header.dev. This is a good example for hiding the implementation from the rest of code. > > + > > /* Key identifying current memory map */ > > extern efi_uintn_t efi_memory_map_key; > > > > @@ -375,6 +381,7 @@ enum efi_object_type { > > * @protocols: linked list with the protocol interfaces installed on this > > * handle > > * @type: image type if the handle relates to an image > > + * @dev: pointer to the DM device which is associated with this EFI handle > > * > > * UEFI offers a flexible and expandable object model. The objects in the UEFI > > * API are devices, drivers, and loaded images. struct efi_object is our storage > > @@ -392,6 +399,7 @@ struct efi_object { > > /* The list of protocols */ > > struct list_head protocols; > > enum efi_object_type type; > > + struct udevice *dev; > > }; > > > > enum efi_image_auth_status { > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c > > index 1d700b2a6b..a8e8521e3e 100644 > > --- a/lib/efi_loader/efi_disk.c > > +++ b/lib/efi_loader/efi_disk.c > > @@ -46,7 +46,6 @@ struct efi_disk_obj { > > struct efi_device_path *dp; > > unsigned int part; > > struct efi_simple_file_system_protocol *volume; > > - struct udevice *dev; /* TODO: move it to efi_object */ > > ok > > > }; > > > > /** > > @@ -124,16 +123,16 @@ static efi_status_t efi_disk_rw_blocks(struct efi_block_io *this, > > return EFI_BAD_BUFFER_SIZE; > > > > if (CONFIG_IS_ENABLED(PARTITIONS) && > > - device_get_uclass_id(diskobj->dev) == UCLASS_PARTITION) { > > + device_get_uclass_id(efi_handle_to_udev(diskobj)) == UCLASS_PARTITION) { > > device_get_uclass_id(diskobj->header.hdev)) == UCLASS_PARTITION) { > > > if (direction == EFI_DISK_READ) > > - n = dev_read(diskobj->dev, lba, blocks, buffer); > > + n = dev_read(efi_handle_to_udev(diskobj), lba, blocks, buffer); > > dev_read(diskobj->header.hdev) > > > else > > - n = dev_write(diskobj->dev, lba, blocks, buffer); > > + n = dev_write(efi_handle_to_udev(diskobj), lba, blocks, buffer); > > dev_write(diskobj->header.hdev) > > > } else { > > /* dev is a block device (UCLASS_BLK) */ > > struct blk_desc *desc; > > > > - desc = dev_get_uclass_plat(diskobj->dev); > > + desc = dev_get_uclass_plat(efi_handle_to_udev(diskobj)); > > dev_get_uclass(diskobj->header.hdev) > > > > if (direction == EFI_DISK_READ) > > n = blk_dread(desc, lba, blocks, buffer); > > else > > @@ -552,7 +551,7 @@ static int efi_disk_create_raw(struct udevice *dev) > > > > return -1; > > } > > - disk->dev = dev; > > + efi_handle_to_udev(disk) = dev; > > if (dev_tag_set_ptr(dev, DM_TAG_EFI, &disk->header)) { > > efi_free_pool(disk->dp); > > efi_delete_handle(&disk->header); > > @@ -609,7 +608,7 @@ static int efi_disk_create_part(struct udevice *dev) > > log_err("Adding partition for %s failed\n", dev->name); > > return -1; > > } > > - disk->dev = dev; > > + efi_handle_to_udev(disk) = dev; > > disk->header.dev = dev; It's my preference, but I would suggest another accessor: efi_set_udev(handle, dev); to hide an implementation. -Takahiro Akashi > > > if (dev_tag_set_ptr(dev, DM_TAG_EFI, &disk->header)) { > > efi_free_pool(disk->dp); > > efi_delete_handle(&disk->header); > > @@ -656,6 +655,13 @@ static int efi_disk_probe(void *ctx, struct event *event) > > ret = efi_disk_create_raw(dev); > > if (ret) > > return -1; > > + } else { > > + efi_handle_t handle; > > + > > + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&handle)) > > + return -1; > > + > > + efi_handle_to_udev(handle) = dev; > > handle->dev = dev; > > Best regards > > Heinrich > > > } > > > > device_foreach_child(child, dev) { >