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 234DCC004D4 for ; Thu, 19 Jan 2023 16:54:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5648B85657; Thu, 19 Jan 2023 17:54:47 +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="FT07b0oH"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2A4008565F; Thu, 19 Jan 2023 17:54:45 +0100 (CET) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 2A8A085265 for ; Thu, 19 Jan 2023 17:54:42 +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-ej1-x62f.google.com with SMTP id mg12so7305978ejc.5 for ; Thu, 19 Jan 2023 08:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oFwO1teb56z4tJf3DjZl3V4M1NX11/lKlmIKiEGDjB4=; b=FT07b0oHy+h1ZKUI2aKPR182TnDaqgkLNkvIN/vOYDXGpd74H4bia3CVJp+cPTZ4qe oXfj01gRaqJDByaAHwS9Ytnd0nBhZ3QLqcOjE4mHtUMEYtGbCbaltnzrU7waG6w3U/38 AX/o8IN/4PFQDIUtWHU0JrHb+lx3E3jmYSHsU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=oFwO1teb56z4tJf3DjZl3V4M1NX11/lKlmIKiEGDjB4=; b=43bOzCxDZZa4Sy1Adht6VpEEG/3iI3ukqzMv91tutROl2jYoG1Xz/B6N8ocrVe4YM9 xNXtH/uhQN8RUQer6i1ZcUZOSS4/2KXs84vXDm75RPV7v0WJZJos+jrKNN1VLJY7IXqb zBqpX+7u/fTGLPla+UQJ0114IN7SSMMFL/Cz8tiDXL56usF9dinrsU/xLXGhs6cE/TRb TabS/JIpL2Q/WyKDCY1WM6sZ1EEYHgraf3SldrNVGSHD4KCZ3/G6989fY2ID3w7A/rrj 5yMs/Z/lPT0d17zL+T2stFzqJIOgsKVe8iYaQpTsQSXc6fOmQkaNfXNasp3ecqnh9qCg 7c4g== X-Gm-Message-State: AFqh2kpXG6hPvgq0AnygsBoTmJcqnJNW8jz9LHU94itQAq1ncSdIkEFJ tHg/WdeDlb/5TaYP7eVDQIfUc8APYUdqpR5uhQdmsQ== X-Google-Smtp-Source: AMrXdXvLRvCwXgB/z5VD/2QeWJwJgi70JFF+MZD9fcV8Pd9l3BIG1e+eOd+n3HZoa6gEZR9b95FZXYtUjFaPWEtTADw= X-Received: by 2002:a17:906:5214:b0:840:758a:9157 with SMTP id g20-20020a170906521400b00840758a9157mr807662ejm.434.1674147281370; Thu, 19 Jan 2023 08:54:41 -0800 (PST) MIME-Version: 1.0 References: <20221219111251.GA22370@e121910.cambridge.arm.com> <20230118124923.GB631605@bill-the-cat> <20230118135932.GC631605@bill-the-cat> <20230119163157.GA18384@e121910.cambridge.arm.com> <20230119164652.llh66rapyqqej63f@bogus> In-Reply-To: <20230119164652.llh66rapyqqej63f@bogus> From: Simon Glass Date: Thu, 19 Jan 2023 09:54:29 -0700 Message-ID: Subject: Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver To: Sudeep Holla Cc: Abdellatif El Khlifi , trini@konsulko.com, 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 Content-Type: text/plain; charset="UTF-8" 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 Sudeep, On Thu, 19 Jan 2023 at 09:46, Sudeep Holla wrote: > > Hi Abdellatif, > > On Thu, Jan 19, 2023 at 04:31:57PM +0000, Abdellatif El Khlifi wrote: > > > > Hi Simon, Tom, > > > > The FF-A transport is a SW bus and is not associated to any HW peripheral 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 and attributes. > > > > Please refer to the following paragraphs for more details: [2], [3], [4], [5] > > > > The core driver provided by this patchset implements the Setup and discovery interfaces > > in addition to direct messaging. > > > > The driver provides ffa_bus_discover() API that allows to discover 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 FF-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 existence of > FF-A support on a platform. If we are talking about individual partitions > (devices) in the device tree, then that is pure stupidity as it goes out > of since with the firmware the moment a partition is added or removed 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 design > 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 redundant, > 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.html#driver-lifecycle So there is nothing clever needed here at all and anything you do just adds confusion and bad precedent. Regards, Simon