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 3A0B2C54EBD for ; Fri, 13 Jan 2023 18:02:23 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8210385509; Fri, 13 Jan 2023 19:01:06 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="czhwrMDO"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 91994852F3; Fri, 13 Jan 2023 19:00:47 +0100 (CET) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 37CD5852E9 for ; Fri, 13 Jan 2023 19:00:43 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ed1-x533.google.com with SMTP id c17so32172390edj.13 for ; Fri, 13 Jan 2023 10:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ATMRBbcPRj3klRaidK+qslIhct8LhyRakqudY5aN5GE=; b=czhwrMDOnA/7G9pNnXTpHPZ6JiQ+tlBCDw5Yjj9PaxBDjFzeiurFJ38lcWZ58rWN16 NmCgYn8fF4EzPZOYMYvTXC14pBmLBUItG6aqhB7PPrraQs5PE3SeNInp1eqvmX8vTsTS HapvF8IQOhb0qrMLR+w2RcsXP0Go8S09Q1o5E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ATMRBbcPRj3klRaidK+qslIhct8LhyRakqudY5aN5GE=; b=y6rOE7hQ6kVgIoP1gtw9z1dcUsVVR/QnUYAtT+VLBTqVeYW2zZljc8duXEUmr5m3Uj RRw+ShWu3RdMnW+mZKUbGxfQF+8nGHvP1LzBfWD72WFO2X7gJRtZSxWOsLbRoKjxL9u/ 2xcaMhHOY2lQjtFh3S/cMom6Nf0yzO2qWQywstgv5KOV0KQvRiIq5OYYbLBAor0aMJzw KyX1hPGu+1+gKo/jnmPBmkzcU8AUc/esUUeNSx3erDyoo33nb5ZmH1ZYGEzG1audeU+h A9CT5j//nc9L+xtmm2jVCtcNFJT7kW3ITdnDb/V71xUu8FS+m6uXrwLAdnlO4disWEYl DxeQ== X-Gm-Message-State: AFqh2kp8442uU7MDw0vCgks/+fx7+9vCmwbHAbrWgxNYS6WVUbEvOyjV MkAa7uPkBq9BdxVd9CxjSIp2PTyMK13IBX5VNMV9HSLDZYs/hA== X-Google-Smtp-Source: AMrXdXvXLAFsXaQ/bUgYePP5XPdDBoftfdtc8G/4KMwBYAikexkZ/VR81ROcDUXsliammfNxV6OWbj658lpSUUDA/MY= X-Received: by 2002:a05:6402:4c6:b0:478:f729:3008 with SMTP id n6-20020a05640204c600b00478f7293008mr7895032edw.281.1673632842519; Fri, 13 Jan 2023 10:00:42 -0800 (PST) MIME-Version: 1.0 References: <20221124132115.GA393@e121910.cambridge.arm.com> <20221219111251.GA22370@e121910.cambridge.arm.com> <20230113104415.GA22133@e121910.cambridge.arm.com> In-Reply-To: <20230113104415.GA22133@e121910.cambridge.arm.com> From: Simon Glass Date: Fri, 13 Jan 2023 11:00:28 -0700 Message-ID: Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver To: Abdellatif El Khlifi Cc: u-boot@lists.denx.de, nd@arm.com, robh@kernel.org 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Abdellatif, On Fri, 13 Jan 2023 at 03:44, Abdellatif El Khlifi wrote: > > On Thu, Jan 12, 2023 at 04:43:32PM -0700, Simon Glass wrote: > > Hi Rob, > > > > On Wed, 11 Jan 2023 at 19:10, Rob Herring wrote: > > > > > > On Mon, Dec 19, 2022 at 1:21 PM Simon Glass wrote: > > > > > > > > Hi Abdellatif, > > > > > > > > On Mon, 19 Dec 2022 at 04:12, Abdellatif El Khlifi > > > > wrote: > > > > > > > > > > On Mon, Dec 05, 2022 at 09:49:30AM -0600, Rob Herring wrote: > > > > > > On Sun, Dec 4, 2022 at 1:22 PM Simon Glass w= rote: > > > > > > > > > > > > > > Hi Rob, > > > > > > > > > > > > > > On Tue, 29 Nov 2022 at 05:22, Rob Herring w= rote: > > > > > > > > > > > > > > > > On Fri, Nov 25, 2022 at 3:18 PM Simon Glass wrote: > > > > > > > > > > > > > > > > > > Hi Abdellatif, > > > > > > > > > > > > > > > > > > On Thu, 24 Nov 2022 at 06:21, Abdellatif El Khlifi wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Nov 22, 2022 at 07:09:16PM -0700, Simon Glass w= rote: > > > > > > > > > > > should be called 'priov' and should beHi Abdellatif, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [..] > > > > > > > > > > > > > > > > > > > > > +/** > > > > > > > > > > > > + * ffa_device_get - create, bind and probe the arm= _ffa device > > > > > > > > > > > > + * @pdev: the address of a device pointer (to be f= illed when the arm_ffa bus device is created > > > > > > > > > > > > + * successfully) > > > > > > > > > > > > + * > > > > > > > > > > > > + * This function makes sure the arm_ffa device is > > > > > > > > > > > > + * created, bound to this driver, probed and ready= to use. > > > > > > > > > > > > + * Arm FF-A transport is implemented through a sin= gle U-Boot > > > > > > > > > > > > + * device managing the FF-A bus (arm_ffa). > > > > > > > > > > > > + * > > > > > > > > > > > > + * Return: > > > > > > > > > > > > + * > > > > > > > > > > > > + * 0 on success. Otherwise, failure > > > > > > > > > > > > + */ > > > > > > > > > > > > +int ffa_device_get(struct udevice **pdev) > > > > > > > > > > > > +{ > > > > > > > > > > > > + int ret; > > > > > > > > > > > > + struct udevice *dev =3D NULL; > > > > > > > > > > > > + > > > > > > > > > > > > + ret =3D device_bind(dm_root(), DM_DRIVER_GE= T(arm_ffa), FFA_DRV_NAME, NULL, ofnode_null(), > > > > > > > > > > > > + &dev); > > > > > > > > > > > > > > > > > > > > > > Please add a DT binding. Even if only temporary, we n= eed something for this. > > > > > > > > > > > > > > > > > > > > Thanks for the feedback. I'm happy to address all the c= omments. > > > > > > > > > > > > > > > > > > > > Regarding DT binding and FF-A discovery. We agreed with= Linaro and Rob Herring > > > > > > > > > > about the following: > > > > > > > > > > > > > > > > > > > > - DT is only for what we failed to make discoverable. F= or hardware, we're stuck > > > > > > > > > > with it. We shouldn't repeat that for software interf= aces. This approach is > > > > > > > > > > already applied in the FF-A kernel driver which comes= with no DT support and > > > > > > > > > > discovers the bus with bus_register() API [1]. > > > > > > > > > > > > > > > > > > This may be the UEFI view, but it is not how U-Boot works= . This is not something we are 'stuck' with. It is how we define what is pr= esent on a device. This is how the PCI bus works in U-Boot. It is best prac= tice in U-Boot to use the device tree to make this things visible and confi= gurable. Unlike with Linux there is no other way to provide configuration n= eeded by these devices. > > > > > > > > > > > > > > > > Where do you get UEFI out of this? > > > > > > > > > > > > > > I assume it was UEFI as there was no discussion about this in= U-Boot. > > > > > > > Which firmware project was consulted about this? > > > > > > > > > > > > > > > > > > > > > > > It is the discoverability of hardware that is fixed (and we= are stuck > > > > > > > > with). We can't change hardware. The disoverability may be = PCI > > > > > > > > VID/PID, USB device descriptors, or nothing. We only use DT= when those > > > > > > > > are not sufficient. For a software interface, there is no r= eason to > > > > > > > > make them non-discoverable as the interface can be fixed (a= t least for > > > > > > > > new things like FF-A). > > > > > > > > > > > > > > Here I am talking about the controller itself, the top-level = node in > > > > > > > the device tree. For PCI this is a device tree node and it sh= ould be > > > > > > > the same here. So I am not saying that the devices on the bus= need to > > > > > > > be in the device tree (that can be optional, but may be usefu= l in some > > > > > > > situations where it is status and known). > > > > > > > > > > > > Sure, the PCI host bridges are not discoverable, have a bunch o= f > > > > > > resources, and do need to be in DT. The downstream devices only= do if > > > > > > they have extra resources such as when a device is soldered dow= n on a > > > > > > board rather than a standard slot. > > > > > > > > > > > > > We need something like: > > > > > > > > > > > > > > ff-a { > > > > > > > compatible =3D "something"; > > > > > > > }; > > > > > > > > > > > > > > I don't know what mechanism is actually used to communicate w= ith it, > > > > > > > but that will be enough to get the top-level driver started. > > > > > > > > > > > > There's discovery of FF-A itself and then discovery of FF-A fea= tures > > > > > > (e.g. partitions). Both of those are discoverable without DT. T= he > > > > > > first is done by checking the SMCCC version, then checking for = FF-A > > > > > > presence and features. Putting this into DT is redundant. Worse= , what > > > > > > if they disagree? > > > > > > > > > > Hi Simon, > > > > > > > > > > Do you agree with Rob, Ilias and myself that it makes more sense > > > > > FF-A bus is discovered without a DT node and following the same a= pproach as > > > > > Linux ? (FF-A bus doesn't have a HW controller and is a purely SW= bus, > > > > > no configuration/description needed at DT level). > > > > > > > > > > Your suggestions are always welcome. > > > > > > > > I'm sorry I don't agree with that. It does need a compatible string= , > > > > like PCI has. You can just add it in U-Boot if Linux won't accept t= he > > > > binding. > > > > > > It's not like PCI as the host side of PCI has non-discoverable resour= ces. > > > > OK I see. It is certainly an edge case. > > > > > > > > This all could have been designed better, but hindsight is 20/20 and > > > things evolved step by step. There are a bunch of firmware services > > > that are all behind SMCCC. The first (upstream) was PSCI. IIRC, SMCCC > > > was invented a bit after that, but generalized PSCI for other > > > services. Since then more have been added. More services get added on= e > > > by one and yes we added bindings for them. Because what's one more... > > > But that really needs to stop. We're stuck with h/w that's not > > > discoverable, there's zero reason to do that with s/w interfaces. If > > > we could redo everything, we'd have a node for SMCCC and that's it > > > unless there's h/w resources provided to the rest of DT. But we can't= , > > > so SMCCC is discovered by the presence of PSCI. > > > > I understand the background here, but if we don't take a stand on > > this, this sort of thing will continue. Just because something works > > in Linux does not mean that the binding (or lack of it) is good. > > > > The reasons to do this are: > > - avoids needing to manually call device_bind() > > - avoids extra plumbing in U-Boot > > - provides visibility into what is in the system, by looking at the > > DT, like documentation > > - DT is how devices are bound in U-Boot > > > > You can see the problem if you look at ffa_device_get(). It is called > > from ffa_bus_discover() which is a new addition into the board_init > > list. We are trying to remove this list and certainly don't want new > > things added!! > > Hi Simon, > > As stated in the v8 patchset cover letter [1] and readme [2], the FF-A bu= s is discoverable on demand at runtime. > > Clients (such as EFI) can discover the FF-A bus using ffa_bus_discover() = API which triggers the > discovery process. > > We no longer use the board_init list to discover the FF-A bus. That's because you have moved it to the command - everything that wants to use this has to call ffa_bus_discover()...! > > Please refer to the v8 patchset for the review. It still needs a DT node and the binding needs to happen with driver model. Please put that in. See also how the sandbox emulation is done for I2C, SPI, USB, PCI and every other bus, with something in the DT. We have dm_scan_other() which can pick up other buses but that is just one function and we don't support multiple versions of it. We could add that I suppose, but as I say, where does it end? You can create a u-boot-ffa.dtsi file with the appropriate node and include that in any board or SoC that uses this feature. Sandbox can have its emulation node also. You will know that everything is good when you can boot U-Boot, type 'dm tree' and see your device in there without running any other commands. Regards, Simon > > Cheers > > [1]: https://lore.kernel.org/all/20221122131751.22747-1-abdellatif.elkhli= fi@arm.com/ > [2]: https://lore.kernel.org/all/20221122131751.22747-4-abdellatif.elkhli= fi@arm.com/#Z31doc:arch:arm64.ffa.rst > > > > > We don't need to change this in the Linux implementation, just add a > > top-level DT node for U-Boot. I don't understand why that is such a > > big problem? > > > > Regards, > > Simon