Hi Peng, On Mi, 2020-10-14 at 01:23 +0000, Peng Fan wrote: [...] > > > > > 3. either 8MM, 8MN, or 8MP, the power domain design is different, > > > > > I am not > > > > sure if it is the good to add hundreds line of code in GPCv2 each > > > > time > > > > > a new SOC is added. > > > > > > > > I don't buy into this argument. We have lots of drivers in the Linux > > > > kernel that require some changes for new SoC generations, that's > > > > what Linux drivers are for. The complexity of the hardware doesn't > > > > disappear just because you push some of the driver bits into TF-A, > > > > you just handle the complexity at a different palce and IMHO that > > > > the wrong place. The power domains have complex interactions with > > > > other drivers in the Linux system, so debugging and deplyong fixes > > > > is much easier when the power domain handling is fully done by a kernel > > driver. > > > Actually, due to the security requirement from other system solution > > > provider, for example, Microsoft Azure Sphere, it has strict > > > requirement for power domain to be controlled by secure subsystem(either > > TF-A, TEE or dedicated secure domain controller). > > > Same requirement for reset control, and system critical clock control. > > > > Yes, I'm aware of those requirements, but to satisfy those you need a full > > implementation of all those parts in the secure subsystem. Doing it just for the > > power domains adds complexity for no gain, as you still won't be able to meet > > all the requirements and frankly I don't think this is a realistic goal to achieve > > with the current i.MX8M family of SoCs. > > At least we are moving to that direction. To me it seems like the current way (custom TF-A interface and implementation) is one step in the right direction, but two steps backwards in terms of complexity. > > Meeting those requirements needs a fully system approach where the secure > > subsystem parts are made sufficiently independent from the non- secure > > parts on a hardware level, which I don't see on the i.MX8M SoC and hardware > > design guide. > > CSU could restrict the access permission. While this is true, my argument is much broader and not only focused on on-SoC peripherals. For example some of the power domains need different voltages for specific performance states, which means you need to communicate with a external PMIC or other voltage regulator, which in turn means you need to set aside the necessary i2c bus and/or GPIO banks required for this communication at system design time, so it isn't shared between TF-A and the rich OS. I don't see this in any of the i.MX8M designs. > > > For NXP i.MX8M family, it is ok to implement in linux kernel, just a > > > tradeoff to find out a place to hide the complexity ^_^. > > > > > > BTW, for virtualization support, it is better to put the power domain > > > in a central place to simplify the VM implementation. > > > > Same as above. If you can make all the relevant bits (clock, reset, > > power-domain, regulator) available via a virtualization friendly API, then I > > would see a point in adding complexity for this abstraction. As long as this > > added abstraction only solves a very tiny bit of the overall picture, I just don't > > see the point in the added complexity and (from a Linux PoV) obfuscation. > > Could we use SCMI for power domain, system critical clocks, smc watchdog > and etc? If you could demonstrate a working solution with all those pieces hidden behind a standard SCMI interface, this would make for a much more compelling story supporting the secure subsystem argument. > Or we support two approaches, one is let Linux control everything, the other > is using SCMI. > > Thoughts? I wouldn't be opposed to such a solution. If you can put all this behind a standard SCMI interface, I guess we wouldn't need two different SoC specific drivers for the same purpose, so we could easily have a Linux full-control solution (i.e. this patchset) coexist with a SCMI based implementation, possibly with just a slightly different base SoC DT with all the power domains, clocks and other system level control stuff behind SCMI. What I'm strongly opposed to is having a custom TF-A interface and all the added complexity for little to no gain in actual system security. Regards, Lucas
