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 0EF96C433EF for ; Wed, 9 Feb 2022 09:04:07 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 564CB83D2F; Wed, 9 Feb 2022 10:04:05 +0100 (CET) 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="h2MC3p9U"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1CA8583D45; Wed, 9 Feb 2022 10:04:03 +0100 (CET) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 034DB83D1B for ; Wed, 9 Feb 2022 10:03:59 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sughosh.ganu@linaro.org Received: by mail-io1-xd30.google.com with SMTP id d188so2247635iof.7 for ; Wed, 09 Feb 2022 01:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JQTSezgHtX/UZlfLF5rxoNOCHwAQRPQX3Vm0ygIFT9o=; b=h2MC3p9UjQBjm4VKZXK8/dt/jhACUR29vlPclzbFUBG6PuewITEDETAA2MTVXa/iXP Zm4Wzg+TPbjaFuqJH0IUnOPwSrgB70RtDGXxGrz68cyoR+ZRLBmnS2PSSanXA6MoiAYj EiJ6r5J3rOedV5u8rwvtVU48rcImerlOxKhaM17i/cPdaVC/Sg69jaG+vtJpm0h0w0ei cHypVjIl+xKNk4q5Yk4WU9WNyausczzvtt5sjGOxomZtGKcQHm++qJDyQCDOfU3RAmi3 cJAHVuWrzqWXvQbhbJjEWWob76nqwaLaelpRmLKWzhzsrIODU3ZG0xGGytAE5w7AMV2U dhgQ== 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:content-transfer-encoding; bh=JQTSezgHtX/UZlfLF5rxoNOCHwAQRPQX3Vm0ygIFT9o=; b=rKgQobaWcMxhx8giHAFMJADJ2G9An4lm3kXdPpoBT4V+GfBFL/tIqMLHzIxBwdRJ/k eoVcQMa+1lb2Xo0A0gyUQCbyympdnkKkvs6Fb0kM1caO9+VferNZZEZoVH48YZo5PbA/ UB5nTq9qr+11OZDpPol2b2L7OxvQPu8p19DQEI/zFur0gssPwDm1iXSToKuJa0Td/C2G JG3qNlLGbkDUDGAPnDEzNI1XocJBAG/A+ccXp0kKH80CbNw1O+OnnVwkvjBYxGkLE4lB 7c9umb8t8a/hfHGEaDHZQd5rl3K7jJms4OVHVIYg5kICrKJBymNj48Ind+LZ53c9j4uw +x1w== X-Gm-Message-State: AOAM533U1fYg5PpzaRq8tbls/dMTNkGHXAOXnLtwbFD7Od96tO5gjcmf bJSqxeLoB7SIH7G/68Zt25lklpM5NC0Ny4DqDNEEWQ== X-Google-Smtp-Source: ABdhPJy2S3Qh9FwZPdk8I/Rp/DCIV/CzIG2QUf/8amA+jdOmvM7dQ7MHjXo0L09HBEf2ahFoRVQPjUtgYy/ZuiYUcQ4= X-Received: by 2002:a05:6638:408a:: with SMTP id m10mr633169jam.16.1644397437431; Wed, 09 Feb 2022 01:03:57 -0800 (PST) MIME-Version: 1.0 References: <20220207182001.31270-1-sughosh.ganu@linaro.org> <20220207182001.31270-3-sughosh.ganu@linaro.org> In-Reply-To: From: Sughosh Ganu Date: Wed, 9 Feb 2022 14:33:46 +0530 Message-ID: Subject: Re: [PATCH v4 02/11] FWU: Add FWU metadata access driver for GPT partitioned block devices To: Masami Hiramatsu Cc: u-boot@lists.denx.de, Heinrich Schuchardt , Patrick Delaunay , Patrice Chotard , Alexander Graf , AKASHI Takahiro , Simon Glass , Bin Meng , Ilias Apalodimas , Jose Marinho , Grant Likely , Tom Rini , Etienne Carriere Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.5 at phobos.denx.de X-Virus-Status: Clean hi Masami, On Wed, 9 Feb 2022 at 10:26, Masami Hiramatsu wrote: > > Hi Sughosh, > > While porting mdata-sf driver, I'm confusing on the devicetree > usage. > > 2022=E5=B9=B42=E6=9C=888=E6=97=A5(=E7=81=AB) 3:21 Sughosh Ganu : > > > +int fwu_get_mdata_device(struct udevice **mdata_dev) > > +{ > > + u32 phandle; > > + int ret, size; > > + struct udevice *dev, *child; > > + ofnode fwu_mdata_node; > > + const fdt32_t *phandle_p =3D NULL; > > + > > + fwu_mdata_node =3D ofnode_path("/fwu-mdata"); > > + if (!ofnode_valid(fwu_mdata_node)) { > > + log_err("fwu-node not found\n"); > > + return -ENOENT; > > + } > > So this seems to get the udevice from path, but I think fwu-mdata node > has "u-boot,fwu-mdata" compatible property, in that case probe function > already gets the node. Why would you search it again by path? Okay. Is there some other api that I can use which is faster than the approach currently taken? If so, do let me know. > > > + > > + phandle_p =3D ofnode_get_property(fwu_mdata_node, "fwu-mdata-st= ore", > > + &size); > > + if (!phandle_p) { > > + log_err("fwu-mdata-store property not found\n"); > > + return -ENOENT; > > + } > > + > > + phandle =3D fdt32_to_cpu(*phandle_p); > > + > > + ret =3D device_get_global_by_ofnode(ofnode_get_by_phandle(phand= le), > > + &dev); > > + if (ret) > > + return ret; > > + > > + ret =3D -ENODEV; > > + for (device_find_first_child(dev, &child); child; > > + device_find_next_child(&child)) { > > + if (device_get_uclass_id(child) =3D=3D UCLASS_BLK) { > > + *mdata_dev =3D child; > > I thought that the blk device node directly passed by the > "fwu-mdata-store" property. Would we need to search it from > children nodes? What the device tree is pointing to is the device like the mmc, which is described through a device tree node. The block device is the child of this device, which is not described in the device tree. The driver finally needs the block device. > > BTW, if we can use the devicetree, can we define the number of banks > and the number of images can be described too? It is much easier to handle if these values are defined through Kconfig symbols. That way, this gets directly included in the config file, and can be used directly in the fwu_mdata.h metadata structure. > Of course as I said in the other thread, I would like to put the > dfu_alt_info like information in the devicetree too. > (But it maybe different from this discussion) Just curious, why do you need to define a variable like dfu_alt_info in a device tree. If this has already been described earlier, you can point me to that discussion. Trying to understand what benefit does having the variables defined in a device tree brings. Thanks. -sughosh > > Thank you, > > > > + ret =3D 0; > > + } > > + } > > + > > + return ret; > > +} > > + > > +static int fwu_mdata_gpt_blk_probe(struct udevice *dev) > > +{ > > + int ret; > > + struct udevice *mdata_dev =3D NULL; > > + > > + ret =3D fwu_get_mdata_device(&mdata_dev); > > + if (ret) > > + return ret; > > + > > + dev_set_priv(dev, mdata_dev); > > + > > + return 0; > > +} > > + > > +static const struct fwu_mdata_ops fwu_gpt_blk_ops =3D { > > + .get_image_alt_num =3D fwu_gpt_get_image_alt_num, > > + .mdata_check =3D fwu_gpt_mdata_check, > > + .get_mdata =3D fwu_gpt_get_mdata, > > + .update_mdata =3D fwu_gpt_update_mdata, > > +}; > > + > > +static const struct udevice_id fwu_mdata_ids[] =3D { > > + { .compatible =3D "u-boot,fwu-mdata" }, > > > + { } > > +}; > > + > > +U_BOOT_DRIVER(fwu_mdata_gpt_blk) =3D { > > + .name =3D "fwu-mdata-gpt-blk", > > + .id =3D UCLASS_FWU_MDATA, > > + .of_match =3D fwu_mdata_ids, > > + .ops =3D &fwu_gpt_blk_ops, > > + .probe =3D fwu_mdata_gpt_blk_probe, > > +}; > > diff --git a/include/fwu.h b/include/fwu.h > > index 5a99c579fc..2c7db2dff9 100644 > > --- a/include/fwu.h > > +++ b/include/fwu.h > > @@ -43,6 +43,8 @@ int fwu_get_active_index(u32 *active_idx); > > int fwu_update_active_index(u32 active_idx); > > int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank, > > int *alt_num); > > +int fwu_get_mdata_device(struct udevice **mdata_dev); > > +int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part); > > int fwu_mdata_check(void); > > int fwu_revert_boot_index(void); > > int fwu_accept_image(efi_guid_t *img_type_id, u32 bank); > > -- > > 2.17.1 > > > > > -- > Masami Hiramatsu