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 0DE45C0015E for ; Fri, 14 Jul 2023 00:42:05 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0EBA986C16; Fri, 14 Jul 2023 02:42:03 +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="aHsvpl6t"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5A6C086C1D; Fri, 14 Jul 2023 02:42:01 +0200 (CEST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 95CE986C03 for ; Fri, 14 Jul 2023 02:41:57 +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-pg1-x536.google.com with SMTP id 41be03b00d2f7-55badd6d6feso231611a12.1 for ; Thu, 13 Jul 2023 17:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689295316; x=1689900116; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=J8ERuJMK//c1wcN037/fjzGYPP2/Kr/eYqoRRcrZg1o=; b=aHsvpl6t7RSYz+cnz46PHtV8AKnmeWZHLvgxPHxrt+fUEshX9g84Zo/z1LapHnuTRx Kr14TIxaaWM56Cka0JESmcpS6m/Imj+fqK0gI15v0gpUvHkdtZQnbXG4FdyBVSKgJ0Xt hmv0fk7edm+1ZSWCGPl3gEAe97p0cSusTZVS7kj2TQBaeqrjYIPAz6y1Gh+YJ9dySuwU nrLP+aseFVnzeaIBltkyiwlmsgL4iz9zVaBsoLmX2TrBkSYm04RQXBneO2Owg80uw2xO jRJ+ig7EwDTi0MIfmEN7den0BmzVCjm0XS6VMg34Kml3vjwveePtc50cQFCkuuzWKs2j 3HOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689295316; x=1689900116; 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:message-id:reply-to; bh=J8ERuJMK//c1wcN037/fjzGYPP2/Kr/eYqoRRcrZg1o=; b=YXU7me09UHEjKTK1kCDJBs8ShEacrNBE5KulKRC7vHbaERIAEY/w/2TxczVIhqi4YT IM9x+IcTzQZIHyb9UqBGWX01deS9XFm68+rLbg36IceVy0F74CJTAn48tSZCNC1tDXn3 p1kglA+cSc0NVkwjjvk3EsGh1Qe7X0EueBNc8Sqvzc+OAKJfIYFbaYsYYsO/2qvcMLdL fgMVWUJ06eGS+ZzUdheghSXZ2dUc4KwH2EfmxECFUWfQ5Msnp2c1bLbon8YQuSyNtSRe fQpfBBm02YrN3kj/NWQvgIq5eX7GdFfI7D1Auwei5c3N7v80GbCiLDMiXG1hUGtFZR45 kKmA== X-Gm-Message-State: ABy/qLbo/f0Blp3K/ro/AORSGZHtkwLn0PKFkkeBzNe+n5bp/dJl6H3q imh5sMm6bADDvKRRalFxSIOkbw== X-Google-Smtp-Source: APBJJlEmBVZqc9vvNwn9n1vSY0fN121C9Sx5WST+EKeNzDFXLq2UPPFc/XjEtlkadjoAAPSi2FlJuQ== X-Received: by 2002:a17:902:da92:b0:1b8:9fc4:2733 with SMTP id j18-20020a170902da9200b001b89fc42733mr4027427plx.3.1689295315676; Thu, 13 Jul 2023 17:41:55 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:67e0:38af:3c10:1480]) by smtp.gmail.com with ESMTPSA id t8-20020a1709028c8800b001b8a3a0c928sm6433465plo.181.2023.07.13.17.41.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jul 2023 17:41:55 -0700 (PDT) Date: Fri, 14 Jul 2023 09:41:52 +0900 From: AKASHI Takahiro To: Simon Glass Cc: trini@konsulko.com, etienne.carriere@st.com, u-boot@lists.denx.de Subject: Re: [PATCH 07/10] test: dm: add SCMI base protocol test Message-ID: Mail-Followup-To: AKASHI Takahiro , Simon Glass , trini@konsulko.com, etienne.carriere@st.com, u-boot@lists.denx.de References: <20230628004841.21774-8-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.8 at phobos.denx.de X-Virus-Status: Clean Hi Simon, On Tue, Jul 11, 2023 at 12:41:58PM -0600, Simon Glass wrote: > Hi Takahiro, > > On Mon, 10 Jul 2023 at 19:02, AKASHI Takahiro > wrote: > > > > Hi Simon, > > > > On Mon, Jul 10, 2023 at 01:45:58PM -0600, Simon Glass wrote: > > > Hi, > > > > > > On Sun, 9 Jul 2023 at 20:04, AKASHI Takahiro wrote: > > > > > > > > On Fri, Jul 07, 2023 at 11:35:49AM -0600, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On Tue, 4 Jul 2023 at 03:35, AKASHI Takahiro wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Mon, Jul 03, 2023 at 02:30:57PM +0100, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, 3 Jul 2023 at 01:57, AKASHI Takahiro wrote: > > > > > > > > > > > > > > > > On Thu, Jun 29, 2023 at 08:09:58PM +0100, Simon Glass wrote: > > > > > > > > > Hi AKASHI, > > > > > > > > > > > > > > > > > > On Wed, 28 Jun 2023 at 01:49, AKASHI Takahiro > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Added is a new unit test for SCMI base protocol, which will exercise all > > > > > > > > > > the commands provided by the protocol, except SCMI_BASE_NOTIFY_ERRORS. > > > > > > > > > > $ ut dm scmi_base > > > > > > > > > > It is assumed that test.dtb is used as sandbox's device tree. > > > > > > > > > > > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > > > > > > --- > > > > > > > > > > test/dm/scmi.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > 1 file changed, 112 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/test/dm/scmi.c b/test/dm/scmi.c > > > > > > > > > > index 881be3171b7c..563017bb63e0 100644 > > > > > > > > > > --- a/test/dm/scmi.c > > > > > > > > > > +++ b/test/dm/scmi.c > > > > > > > > > > @@ -16,6 +16,9 @@ > > > > > > > > > > #include > > > > > > > > > > #include > > > > > > > > > > #include > > > > > > > > > > +#include > > > > > > > > > > +#include > > > > > > > > > > +#include > > > > > > > > > > #include > > > > > > > > > > #include > > > > > > > > > > #include > > > > > > > > > > @@ -95,6 +98,115 @@ static int dm_test_scmi_sandbox_agent(struct unit_test_state *uts) > > > > > > > > > > } > > > > > > > > > > DM_TEST(dm_test_scmi_sandbox_agent, UT_TESTF_SCAN_FDT); > > > > > > > > > > > > > > > > > > > > +static int dm_test_scmi_base(struct unit_test_state *uts) > > > > > > > > > > +{ > > > > > > > > > > + struct udevice *agent_dev, *base; > > > > > > > > > > + struct scmi_agent_priv *priv; > > > > > > > > > > + const struct scmi_base_ops *ops; > > > > > > > > > > + u32 version, num_agents, num_protocols, impl_version; > > > > > > > > > > + u32 attributes, agent_id; > > > > > > > > > > + char vendor[SCMI_BASE_NAME_LENGTH_MAX], > > > > > > > > > > + agent_name[SCMI_BASE_NAME_LENGTH_MAX]; > > > > > > > > > > + u8 *protocols; > > > > > > > > > > + int ret; > > > > > > > > > > + > > > > > > > > > > + /* preparation */ > > > > > > > > > > + ut_assertok(uclass_get_device_by_name(UCLASS_SCMI_AGENT, "scmi", > > > > > > > > > > + &agent_dev)); > > > > > > > > > > + ut_assertnonnull(agent_dev); > > > > > > > > > > + ut_assertnonnull(priv = dev_get_uclass_plat(agent_dev)); > > > > > > > > > > + ut_assertnonnull(base = scmi_get_protocol(agent_dev, > > > > > > > > > > + SCMI_PROTOCOL_ID_BASE)); > > > > > > > > > > + ut_assertnonnull(ops = dev_get_driver_ops(base)); > > > > > > > > > > + > > > > > > > > > > + /* version */ > > > > > > > > > > + ret = (*ops->protocol_version)(base, &version); > > > > > > > > > > > > > > > > > > Can you add uclass helpers to call each of the methods? That is how it > > > > > > > > > is commonly done. You should not be calling ops->xxx directly here. > > > > > > > > > > > > > > > > Yes, I will add inline functions instead. > > > > > > > > > > > > > > I don't mean inline...see all the other uclasses which define a > > > > > > > > > > > > Okay, I will *real* functions. > > > > > > > > > > > > > function which is implemented in the uclass. It is confusing when one > > > > > > > uclass does something different. People might copy this style and then > > > > > > > the code base diverges. Did you not notice this when looking around > > > > > > > the source tree? > > > > > > > > > > > > But one concern came up in my mind. > > > > > > Contrary to ordinary "device controllers", there exists only a single > > > > > > implementation of driver for each of "udevice"'s associated with SCMI > > > > > > protocols including the base protocol. > > > > > > > > > > > > So if I follow your suggestion, the code (base.c) might look like: > > > > > > === > > > > > > static int __scmi_base_discover_vendor(struct udevice *dev, u8 *vendor) > > > > > > { > > > > > > ... > > > > > > } > > > > > > > > > > > > struct scmi_base_ops scmi_base_ops = { > > > > > > > > > > > > .base_discover_vendor = __scmi_base_discover_vendor, > > > > > > > > > > > > } > > > > > > > > > > > > int scmi_base_discover_vendor(struct udevice *dev, u8 *vendor) > > > > > > { > > > > > > struct scmi_base_ops *ops; > > > > > > > > > > > > ops = scmi_base_dev_ops(dev); > > > > > > > > > > > > return ops->base_discover_vendor(dev, vendor); > > > > > > } > > > > > > === > > > > > > > > > > > > We will have to have similar definitions for every operation in ops. > > > > > > It looks quite weird to me as there are always pairs of functions, > > > > > > like __scmi_base_discover_vendor() and scmi_base_discover_vendor(). > > > > > > > > > > Yes I understand that you only have one driver at present. Is there > > > > > not a sandbox driver? > > > > > > > > No. > > > > Please remember that SCMI protocol drivers on U-Boot are nothing but > > > > stubs that makes a call to SCMI servers, supporting common communication > > > > channel interfaces for different transports (either OP-TEE, SMCCC or mailbox). > > > > > > > > Sandbox driver, if is properly named, is also implemented as a sort of > > > > transport layer, where a invocation is replaced with a function call which > > > > mimicks one of specific commands in SCMI protocol on behalf of a real SCMI server. > > > > > > > > In this sense, there will exist only a single driver under the current > > > > form of framework forever. > > > > > > OK, so driver model is used for the transport but not the top-level > > > driver? I see. > > > > I'm not sure if you fully understand. > > Yes, transports, or interchangeably named as a channel, are modeled > > as U-Boot devices as you see in drivers/firmware/scmi/*_agent.c > > (Their names, *_agent, are misleading in my opinion as their functionality > > is purely a transport method to SCMI server. An agent means, in SCMI jargon, > > a user or client of SCMI server.) > > > > On top of that, each SCMI protocol, the base protocol in my patch set, > > is also modeled as a U-Boot device. > > You can see another example, say, in drivers/firmware/clk/clk_scmi.c. > > > > Since there is no corresponding uclass for the base protocol, I create > > a new one (UCLASS_SCMI_BASE) even though it may not be seen an concrete > > device object. > > It doesn't need to be 'concrete', whatever that means. A uclass is a > model of hardware or something else. We have lots of drivers that > don't deal with a hardware device. Yes, I know. > > > > > > > > > > > > > > > > > > > > > > > We can avoid this redundant code easily by eliminating "ops" abstraction. > > > > > > But as far as I remember, you insist that every driver that complies > > > > > > to U-Boot driver model should have a "ops". > > > > > > > > > > > > What do you make of this? > > > > > > > > > > Well there are some exceptions, but yes that is the idea. Operations > > > > > should be in a 'ops' struct and documented and implemented in a > > > > > consistent way. > > > > > > > > Is it your choice that I should keep "ops" structure in this specific > > > > implementation? > > > > > > I can't actually find this patch on patchwork. > > > > Indeed (why?), but you have already seen it. > > https://lists.denx.de/pipermail/u-boot/2023-June/521288.html > > I mean patchwork. Yes, I know. But even a bunch of patches listed in patchwork are left "new" state forever. > > > > > But yes, you do need a function for each ops call. They should be used > > > in the tests, which should not directly call functions using > > > ops->xxx() > > > > Even though there is no practical benefit to do so. Right? > > I don't have a useful answer to that question. If you want to > contribute to U-Boot, please follow its conventions. It is just > frustrating for people doing code review, with limited time. I simply wanted to double-check the rule since you mention, in another thread, that there are some exceptions. > While xxx may be unique in U-Boot, I very much doubt it always is, so > using 'ops' is not helping people looking through the code, nor is it > obvious what is happening without looking up 'ops'. The helper > functions should be used in all cases. > > The thing is, this convention has been in place since the start of > driver model, so I wonder how you have missed it? Well, probably I was confused with many uses of function pointers for boot and runtime services in UEFI code. That said, after rethinking, I decided to remove udevice-related code from my patch here, i.e. there will be no U-Boot device for the base protocol as it is a protocol not a concrete device. Its sole purpose is to get *meta* information about SCMI server and the services, then manipulate them. The analogy is that HTTP or FTP is a protocol over an ethernet device to access a remote application (server), but is not a device object in any sense. > Please also fix the other uclasses, as I see for example that > devm_scmi_process_msg() calls ops->process_msg() when it should have > an exported function in that file. I'm not sure that this is the case. devm_scmi_process_mesg() is just a wrapper, as the name suggests, to ops->process_msg() like other uclass driver operations, say blk_read/blk_write(). The only difference, if any, "ops" doesn't derive from the device itself, but it parent (or grand^* parent). If you really want, I will fix it (but in a separate patch). -Takahiro Akashi > Every uclass should have its > operations in a struct, clearly documented, as well as helper > functions to call each operation. > > Regards, > Simon