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 ABD1DEB64DC for ; Tue, 4 Jul 2023 02:35:43 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4AE998469F; Tue, 4 Jul 2023 04:35:41 +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="zrNR+LIG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2E621846B5; Tue, 4 Jul 2023 04:35:39 +0200 (CEST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 1C10982A2C for ; Tue, 4 Jul 2023 04:35:36 +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-x102a.google.com with SMTP id 98e67ed59e1d1-263e62842c1so14165a91.0 for ; Mon, 03 Jul 2023 19:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1688438134; x=1691030134; 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=4sZEN3rAO4z5WIgRAp+7use+oKdSL0k59ItdftdarDk=; b=zrNR+LIGf2YJIcqMacsVoWzGOqfYS9pb7YaKiJfGqDDh7Wi6cTtsagriOyQxAGgFZv /C98qWPXY1aBX4U/NT4DojdaX8LohYP7relQzOEoLXGjaUXx81h4SL7kUENJsB6puilm 8j8hlKjRK6ux+cj0uPWjdelXajEbHm2SJmtGLzjKQoDB6JpSV+2vxaIPMAwH/GZVGLOA s6SlzrkYGKRx/8DVwOAlV4rCKNJKAkgosZ5ARMgFLWo1553zX6EyfgPbzeaORPJwyZ+q sz13lbbcK7+eYt1GXnDRPdFoO+COqjKzi/3pJtcoV1TvL//6g0rnqvIpIuFrVzCr4ZA+ sb+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688438134; x=1691030134; 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=4sZEN3rAO4z5WIgRAp+7use+oKdSL0k59ItdftdarDk=; b=O6SfiAF7eckpWMslDgC0wGY+0pt4puJMOD1BYwufsX7tv8qSOLIu7xTb6ThzxKvjEe qyRrg4RSJTeduJk94ckWzLZZOcvMB2VHIphuqACW2OAPOF8UXzQ1tyRmBgia2cmfTodJ 2xDfgzgSeWywDD32wE+h6y3DRgro0+GgtXYld8J0uXEQpqQsr8sbgpYviAIY1KTF+adb 3TcqKEpqc3SQhbKeWcfS+KzZWVDGrfZu15f76VPJkGwXyUWdZFW5PMFNIkCORmCOscPP uqHgCgS70C8Lu4jWapfcxNAogNsL6evIVLTA1tMFXIk90LEvs86x7Vdfzu3RU8HY8Oam rmHw== X-Gm-Message-State: ABy/qLZ4n5UGM6+TKiMlNzaw8HDhYs4gt/zFmv7rV1fZnW0/is+nuVd6 QILR8CHiGwrYIGZ/Fp3Y09syXzJYRLzHJdBIIoQ= X-Google-Smtp-Source: APBJJlHma+aWSUiQ0FHC1mL5Em73MRtcjya64ayx3x39ybvjd3ZJi7ujRRk5E1WfRktrAKfDPEj0kA== X-Received: by 2002:a17:90a:6a87:b0:263:5c30:2cf8 with SMTP id u7-20020a17090a6a8700b002635c302cf8mr13733120pjj.0.1688438134351; Mon, 03 Jul 2023 19:35:34 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:7b09:80d7:6bb8:cb8]) by smtp.gmail.com with ESMTPSA id m17-20020a17090ade1100b00263987a50fcsm4879843pjv.22.2023.07.03.19.35.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jul 2023 19:35:33 -0700 (PDT) Date: Tue, 4 Jul 2023 11:35:31 +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-1-takahiro.akashi@linaro.org> <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 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(). 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? Thanks -Takahiro Akashi > Regards, > Simon