Hi, On Wed, 13 Apr 2022 at 10:46, Tom Rini <tr...@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 <tr...@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.elkhl...@arm.com wrote: > > > > > > > > > From: Abdellatif El Khlifi <abdellatif.elkhl...@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/drivers/firmware/arm_ffa/bus.c?h=v5.15#n211)) > > > > > > > > > > > > > > > > > > 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/drivers/firmware/arm_ffa/bus.c?h=v5.15#n211 > > > > > > > > > > > > > > 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