Hi,
On Wed, 13 Apr 2022 at 10:46, Tom Rini trini@konsulko.com wrote:
On Wed, Apr 13, 2022 at 03:20:23PM +0100, Abdellatif El Khlifi wrote:
On Tue, Apr 12, 2022 at 08:28:42AM -0500, Rob Herring wrote:
On Tue, Apr 12, 2022 at 7:01 AM Tom Rini trini@konsulko.com wrote:
On Tue, Apr 12, 2022 at 12:43:15PM +0100, Abdellatif El Khlifi wrote:
On Thu, Apr 07, 2022 at 08:58:11AM -0400, Tom Rini wrote:
On Thu, Apr 07, 2022 at 01:54:24PM +0100, Abdellatif El Khlifi wrote: > On Wed, Apr 06, 2022 at 03:47:11PM -0400, Tom Rini wrote: > > On Tue, Mar 29, 2022 at 04:16:53PM +0100, abdellatif.elkhlifi@arm.com wrote: > > > From: Abdellatif El Khlifi abdellatif.elkhlifi@arm.com > > > > > > This patchset adds support for Arm FF-A (Arm Firmware Framework for Armv8-A v1.0). > > > > > > FF-A support is generic by design and can be used by any Arm platform. > > > > > > The features added are as follows: > > > > > > 1/ FF-A device driver > > > 2/ armffa command > > > 3/ FF-A Sandbox driver > > > 4/ FF-A Sandbox test cases > > > 5/ FF-A MM communication > > > > > > > > > The suggested design sees FF-A as a data bus allowing data exchange with the firmware > > > running under TrustZone HW (such as Optee). The same approach was followed in the > > > FF-A driver in Linux kernel (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...)) > > > > > > u-boot boards using FF-A can provide a device tree node in a <board>-u-boot.dtsi file. > > > Since the node can not be hosted in Linux device tree, we suggest using u-boot device tree. > > > > Why can't the node be in the upstream tree? It should be, so that it > > can be shared between all users. Especially since there's in-Linux > > users? > > > > -- > > Tom > > Linux already has an FF-A bus driver and doesn't use a device tree node for FF-A. > > The Linux driver registers FF-A as a bus: > > int arm_ffa_bus_init(void) > { > return bus_register(&ffa_bus_type); > } > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv... > > So, there is no user for the node in Linux. That's why we suggest hosting the node in the u-boot device tree (a u-boot.dtsi file)
OK, but you can still push it upstream as it's not required to have an in tree user.
During the review of Corstone-1000 patchset, Rui Silva had a discussion with the Linux device tree maintainer (Rob Herring). Rob is not in favour of an FFA node in the kernel device tree. This is why we are including the FFA node in u-boot device tree (u-boot.dtsi files).
Sigh. There is not a 'kernel device tree' and a 'u-boot device tree'. There is only 1. For SystemReadyIR compliance, that is a hard requirement.
I'm a bit confused now, can you please link to the kernel thread? Or Rob, can you chime in here please?
The FFA DT binding was rejected in favor of making FFA discoverable. The FFA spec was amended to address that. DT is only for what we failed to make discoverable. For hardware, we're stuck with it. We shouldn't repeat that for software interfaces.
Rob
Guys,
Since we can not add an FFA node in the device tree, we will make FFA a discoverable bus. So, we will manually create the udevice, binding it to the driver and probing it. Manually means directly calling device_bind and device_probe APIs.
Any thoughts about this approach ?
How is it both discoverable and doesn't have a device tree node, in the kernel?
Also, if it is discoverable, we can still use U-Boot to discover it and then pass the info to Linux in the DT.
I am seeing several series which don't have 'proper' DT bindings in Linux. First I heard it was for legacy reasons, but now I am hearing something different. For U-Boot, we really do need to have DT bindings for devices. All this ad-hoc creation of stuff makes things hard to discover, adds to code size and makes things like of-platdata impossible.
Furthermore, if the bindings affect U-Boot, then the U-Boot project should have a say in what is being done there, not just be downstream of all such changes.
Regards, Simon