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 93D6EC38147 for ; Wed, 18 Jan 2023 13:59:41 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4E2EF8481F; Wed, 18 Jan 2023 14:59:39 +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="tkrX23Zl"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4470E8526E; Wed, 18 Jan 2023 14:59:38 +0100 (CET) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 B3D6284231 for ; Wed, 18 Jan 2023 14:59:35 +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-x82f.google.com with SMTP id d16so16910159qtw.8 for ; Wed, 18 Jan 2023 05:59:35 -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=YpGZ6pY+Ndee1bOAtzJP0dclopEKxR5dn0lm6TWRHSo=; b=tkrX23Zl9yUwn2hmBnoxv72cqboBaFEgpN89LUfwXdx4jFGmUvvdflVy0cU+6i0FOi jdDBLaACKG5kT+k5tG7oLYl8yqkkRUMsEfkVERlKzT/CBuEsXx+FOheCPF/30X78YgqM a3CkLTWmcsw/zLr69bpU4LVb3nAAkpKFiHRNQ= 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=YpGZ6pY+Ndee1bOAtzJP0dclopEKxR5dn0lm6TWRHSo=; b=Jm7P9MvMtQksjAF7kf4Zf7tknannXcYPiRyIX/WltmEo7v2BPVuYV1AOaiujH2R6+e wdMWGKC6FxNEhlGNLaAbQw2Fyz+pBE3ZkY/hgGqb8en7CIMK5gIPkUzRPzB/CEbxF5KC 208QtVrgzQUzp6jQmYWEc7f/DSygDEpU4oLFM4dYaA6F+pkHUh3VPraW37e+71petXNh KcmIOuMB0SslFYIhv5Cull2Ak/C9cxicVIuymFEdCJNcukaCsMvgpAS9h4JAyJ1UYMad V9cI+48ZKmKnb7aT13Qx0MIeI5soh4Ah7MO1nytHhpedoncfPoGoYgVyoySTmnbtpA5z bJ3g== X-Gm-Message-State: AFqh2koWJqV3og6clJ6C2wOkln5W45hwKC2JmNTqQKxBx/V9t2YDBrBm WdWuk0QlPtkW7T+7tmbYP1yeQg== X-Google-Smtp-Source: AMrXdXs7wc4heJWCJOOkrh7BPrgUoFQEJp6Uo+CYBB5V/tv7YNzJJlbAPQE17K09C0JMXBQdieDiLA== X-Received: by 2002:ac8:4504:0:b0:3b6:2f11:25a4 with SMTP id q4-20020ac84504000000b003b62f1125a4mr9683168qtn.16.1674050374425; Wed, 18 Jan 2023 05:59:34 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-400d-a7ad-2782-8e67.res6.spectrum.com. [2603:6081:7b00:6400:400d:a7ad:2782:8e67]) by smtp.gmail.com with ESMTPSA id m5-20020ac86885000000b0039cba52974fsm17455895qtq.94.2023.01.18.05.59.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 05:59:34 -0800 (PST) Date: Wed, 18 Jan 2023 08:59:32 -0500 From: Tom Rini To: Sudeep Holla Cc: Rob Herring , Simon Glass , Abdellatif El Khlifi , ilias.apalodimas@linaro.org, jens.wiklander@linaro.org, achin.gupta@arm.com, xueliang.zhong@arm.com, u-boot@lists.denx.de Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver Message-ID: <20230118135932.GC631605@bill-the-cat> References: <20221219111251.GA22370@e121910.cambridge.arm.com> <20230118124923.GB631605@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L6iaP+gRLNZHKoI4" 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 --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 18, 2023 at 01:46:54PM +0000, Sudeep Holla wrote: > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini wrote: >=20 > > > > I guess the problem comes down to, can we have one discovery method that > > everyone shares, or do we have to let everyone invent a new discovery > > method every time? >=20 >=20 > No one needs to invent any discovery method every time if the firmware > specification > provides one and as Rob mentioned many times in the thread, all new firmw= are > specification must provide one and we are trying to make sure that is > the case with all new > specs from Arm. >=20 >=20 > > FF-A, Op-tee, U-Boot, coreboot, barebox (and > > everyone else I'm unintentionally forgetting) could just discover these > > things via device tree. >=20 >=20 > I leave that to the individual projects to decide and agree but > fundamentally if > the specification provides a way to discover, not sure why we are even > discussing > an alternative method here. >=20 >=20 > > Or, we could all write our own code to perform > > the discovery. >=20 >=20 > For what reason ? I can understand if there is no discovery mechanism but > that's not the > case in $subject. >=20 >=20 > > And when RISC-V comes along with similar functionality, > > we could probe their device tree and see they've implemented the same > > concept, but a little differently, but still have the discovery portion > > be in the device tree. To which it sounds like your answer is "not in > > the device tree". > > >=20 > I see U-boot seem to have made a decision to create DT node for each and > everything > that needs to be added to DM which seems bit unfortunate but I don't > understand the > history/motive/background for it but I respect the decision if it is > already made. >=20 > These firmware interfaces are standard on all Arm platforms and can be > discovered > based on PSCI/SMCCC. Not using the same and use DT node needs unnecessary > addition of DT nodes for all the f/w i/f on all the platforms that need t= he > support when > one can be just discovered. >=20 > Sorry for the sudden appearance on this thread, I was avoiding getting in= to > this but thought > I will at least express my opinion and also the way the firmware > specifications from Arm is > expected to be evolved from now on. With that I will leave it to you and > other U-boot > maintainers and the community in general to decide the right course in th= is > case. To be clear, if the position is that "this is what everyone else will use, really" then yes, we'll follow this in U-Boot. --=20 Tom --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmPH+0EACgkQFHw5/5Y0 tyzC6Qv/ZSQkCmqfbTFZ6NN8jFQCvW93JczEA2z7yJGsNL87h7AgcwzwOyM0Ux7G Fns//dmNkR98xZYqkao9MSZEo9dKX8pPSdXNejUY0X/Ozgeql6ziysy2Z9UdSDIr o3TOMsC1BMFp3UyTQINPZVrJ7cedJG/lRzwyUel6Va+lC8rNWZFxuxIYr3r6cdli 3GMQQMsSN+Ofg7D7wIeVU5s9ZhhcRriAg67GpCsJHvvMT7mwQaSSGqAfc0hTcHKT wOC10wDQpCAZFQ/kb+JnZF3Jn3CmzkmFLCAbsPi6UvqyNXjuBhpOZ7+K0lKSM/sU AJCFXFqAvVtq9MfjWlZQU60OOBOZmhoaX7Zqf6TgWPlQHZqdsTtLt9lLCueZd0rB xLb+szRHkKe3hrKOuF6Dp2Ac96KXni1pFU5oTA+kEye3+KD+HalvU4uURSpqQ/Ev Xudw5xtSmSDeEQsDcoogZT7HXHnNUKanVDdJ/3O+nvRXqYLJVWm3dHJWyM+nxxAo U8O64icS =/CjI -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4--