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 4AD62C00A5A for ; Thu, 19 Jan 2023 17:24:28 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C601B85677; Thu, 19 Jan 2023 18:24:25 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="NqXwHDP3"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 06E9D85668; Thu, 19 Jan 2023 18:24:24 +0100 (CET) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 A886B85677 for ; Thu, 19 Jan 2023 18:24:20 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82e.google.com with SMTP id z9so2094528qtv.5 for ; Thu, 19 Jan 2023 09:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=A29lEIOQg5Vm5K/87jpNe06QX8iGiGVM3+RO7lQSQKk=; b=NqXwHDP3+aPcAR3slBBCvLFtN/j6cFKZpNc2M2xTNLTm+g4ykJfecuWu3ydi8dzYco BPot9Ewa46fVdAZ30JW9EDwD6bzGgLbAeb23lu6a+Bd145iuUgqHTEpf/LuCw5rMzYWD hn1TS28KzbST/DJ+TPcn6qO9ocSiB60UNCgAI= 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:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=A29lEIOQg5Vm5K/87jpNe06QX8iGiGVM3+RO7lQSQKk=; b=KUtvKd/ZiR4a7jJY6WNrLG55ZMbl1GovzXY9QvrWgNlSoY/fR9kZ59uR1pNyUdV4qs AcfMawrkXUXO9AeyjOVBGerCrvWusJP+ZGp2PQDEdhC+PgHdx7LvPOFHnqDbxHZcpsNr kRiwBA48LMqFDDv6FGwjt55yxuRVr0/BOjE+FxvFbbG6BYWGknYXd4FcUrJU6mbZLnZB +9eTj9tE+f15sc2iT7mnQR6KtFQ9GU0S9bIDlC3l3EohrWom0WfGgSar8x4VebONR8Wb sXpe/OEE3mS1Xp0T/kdLdKTykLMd6mZ2WuiGUqsMkY7PuIoNCrmWxsEDp7VvyJH3yI3q DAiQ== X-Gm-Message-State: AFqh2kotlT3FLr5o6m1Sn+Uo+ISjV/vdB3+OEwhw+izrLC2m4+yid0lI ZW0VdhstUUSwheRfqj0/5z5G2Q== X-Google-Smtp-Source: AMrXdXtt/63CpAx1U8Lm2/UzQYEv7E3e6kiggbG4K+SChSoPfkoq+YuRg1aeMIFWcGqDsHOMEYfddg== X-Received: by 2002:ac8:66da:0:b0:3a7:e9a2:4f4a with SMTP id m26-20020ac866da000000b003a7e9a24f4amr17214307qtp.8.1674149059379; Thu, 19 Jan 2023 09:24:19 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-99bd-1ec8-6b02-61e8.res6.spectrum.com. [2603:6081:7b00:6400:99bd:1ec8:6b02:61e8]) by smtp.gmail.com with ESMTPSA id y5-20020ac85245000000b003b5bc7a4512sm6835122qtn.26.2023.01.19.09.24.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Jan 2023 09:24:19 -0800 (PST) Date: Thu, 19 Jan 2023 12:24:17 -0500 From: Tom Rini To: Simon Glass Cc: Sudeep Holla , Abdellatif El Khlifi , achin.gupta@arm.com, xueliang.zhong@arm.com, Drew.Reed@arm.com, robh@kernel.org, jens.wiklander@linaro.org, ilias.apalodimas@linaro.org, u-boot@lists.denx.de Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver Message-ID: <20230119172417.GI631605@bill-the-cat> References: <20230118124923.GB631605@bill-the-cat> <20230118135932.GC631605@bill-the-cat> <20230119163157.GA18384@e121910.cambridge.arm.com> <20230119164652.llh66rapyqqej63f@bogus> <20230119165744.GG631605@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="evOcBaiMpN7OEvsd" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --evOcBaiMpN7OEvsd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2023 at 10:21:07AM -0700, Simon Glass wrote: > Hi Tom, >=20 > On Thu, 19 Jan 2023 at 09:57, Tom Rini wrote: > > > > On Thu, Jan 19, 2023 at 09:54:29AM -0700, Simon Glass wrote: > > > Hi Sudeep, > > > > > > On Thu, 19 Jan 2023 at 09:46, Sudeep Holla wro= te: > > > > > > > > Hi Abdellatif, > > > > > > > > On Thu, Jan 19, 2023 at 04:31:57PM +0000, Abdellatif El Khlifi wrot= e: > > > > > > > > > > Hi Simon, Tom, > > > > > > > > > > The FF-A transport is a SW bus and is not associated to any HW pe= ripheral or > > > > > undiscoverable base address. > > > > > > > > > > There is only 1 way of discovering the FF-A bus and it's through = the FF-A SW > > > > > interfaces. The FF-A spec [1] describes this in details. > > > > > > > > > > Discovering means gathering information about the FF-A framework = such as: > > > > > the FF-A version, supported features, secure partitions number an= d attributes. > > > > > > > > > > Please refer to the following paragraphs for more details: [2], [= 3], [4], [5] > > > > > > > > > > The core driver provided by this patchset implements the Setup an= d discovery interfaces > > > > > in addition to direct messaging. > > > > > > > > > > The driver provides ffa_bus_discover() API that allows to discove= r the FF-A bus > > > > > as described by the spec and in the FF-A driver readme [6]. > > > > > > > > > > We expect and highly recommend FF-A users to always discover the = FF-A bus using ffa_bus_discover() API. > > > > > > > > > > > > > Thanks for the details. But IIRC this discussion is not about the F= F-A bus > > > > and device(partitions) discovery, but the support for FF-A itself. = The > > > > discussion is about where to have a device node to represent the ex= istence of > > > > FF-A support on a platform. If we are talking about individual part= itions > > > > (devices) in the device tree, then that is pure stupidity as it goe= s out > > > > of since with the firmware the moment a partition is added or remov= ed in > > > > the firmware. > > > > > > > > IIUC, the whole discussion was around whether to use FFA_VERSION as= the > > > > discovery mechanism for existence of FF-A support on a platform or = you > > > > have a device node to specify the same. > > > > > > No, with respect, that is not quite the situation here. > > > > > > > > > > > Just to be clear, even if it is decided to add a device node, the > > > > FFA_VERSION must be used to detect the presence of FF-A support and > > > > return error otherwise. DT node presence is just to satisfy the des= ign > > > > and must be treated as no auto-confirmation for the presence of FF-A > > > > support. We are just arguing the device node presence is just redun= dant, > > > > but as mentioned before it is up to U-Boot community to make a call= on > > > > what is best. > > > > > > U-Boot driver model design already supports this. You can have a > > > device that binds (from DT) but will not probe because it is not > > > present / wrong version. Perhaps this was missed in the conversion to > > > Linux: > > > > > > https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.h= tml#driver-lifecycle > > > > > > So there is nothing clever needed here at all and anything you do just > > > adds confusion and bad precedent. > > > > But it's also true that at run-time, within U-Boot, we can modify the > > device tree we have, with live tree yes? So, the whole series in > > question here can be done without modifying the base DT and getting in > > to the further discussions that doing so entails. The assertion is that > > the software discoverable bus here is sufficient to not need DT, so, OK, > > lets go. >=20 > One of the reasons that I find this all so frustrating is that it is > circular logic: >=20 > 1. Device-tree bindings are controlled by Linux; U-Boot cannot upstream b= indings > 2. We can only have upstreamed bindings in any device tree >=20 > We have invented a whole u-boot.dtsi feature in U-Boot to hold > modifications from Linux. Board vendors have been suffering with this > for years. >=20 > It is not fair and it really needs to stop. I am doing what I can to > upstream some basic U-Boot bindings and I hope that will work and can > lead to a healthier relationship here. Yes, but this is a problem outside of that scope. The argument here is that one does not need a device tree node to work. So lets see just how clean and nice the code can be without what you and I have been insisting would lead to the cleanest result. --=20 Tom --evOcBaiMpN7OEvsd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmPJfMEACgkQFHw5/5Y0 tyzuggv/WjJoHY4nANLD4lI0qGGgkStRT+qXQO4hmUindU2dcS0nE7Gwwn4hfGmw WbSkvvFWR4ITbt5AbA7o/lKxEclBTEb6swbH7lZLxGix2ORacLAiQTnkQQQZnC4y 5DBHzx8uakTRohxpMBNY4dZRsswyHzC99R7jVHmvOm3bhucGxM5HpQzzYuNLDgXH y8CzKScnl5oL0gph23UkfwANNi7FlTwqO2jPTOVYQVBmyyVGrrfNNkGfjbyJqMiI UoGeGOafOE5l0pC0t9uG3pR9Ip6Zlws4Ebgmm7oeukCTnyDgVOJagfyuvMIUDXpr q0HQCZHfL8reVgTpSXaeMQMMxBqLFJtJIcObre2d/jKtRm2osmrcKa92gpIRO8qS 5IsuqsLLMUzotfk3CcnTrB5I+cOjp3nEfMTqfJF+QLAmY7q5l0fbCWgdaqeW7cX2 Rdbb7NE3TFQRkPFXRRhN8mJ00MkeVpDL4vFkxPSYQoViSTQWkAgGSwQkIvW+WcV+ tU6zzk9d =pxYu -----END PGP SIGNATURE----- --evOcBaiMpN7OEvsd--