Hi, > Am 23.04.2020 um 22:36 schrieb Maxime Ripard <maxime@xxxxxxxxxx>: >> My goal is to keep the bindings as minimalistic as possible. And reset >> lines and power domains are (at least for those we have in the works) >> not needed to make working systems. >> >> Therefore, for clocks I also would start with a minimalistic approach >> for a single optional GPU core clock and leave out reset and power >> completely. > > Like I said above, the DT is considered an ABI and you'll have to > maintain backward compatibility (ie, newer kernel running with older > DT). Generally I fully agree to this rule (although I have experienced that exceptions happen more often than I like). But here, we don't have any older DT which define something about SGX. We introduce SGX for the first time with bindings and DT in parallel. So they are in sync. Therefore, newer kernels with SGX support and older DT simply will skip SGX and not load any drivers. So we can't break older DT and older DT can't break SGX. What we introduce is a DT code that is well hung and tested (originating in vendor kernels). It is cast in a bindings.yaml where not everyone is happy with for reasons outside the originally proposed DT. For new SoC not yet supported, I don't see a need to touch the existing ones. This is because I only propose to *add* properties to the bindings for devices that have not been supported with SGX before and are not sufficiently covered by what exists. So backward compatibility is a non-problem. > Therefore, you won't be able to require a new clock, reset or > power-domain later on for example. > > I guess the question I'm really asking is: since you don't really know > how the hardware is integrated at the moment, Like I explained, we do not need to know and model all details about the hardware integration. The register set of an SoC does not always provide bits to control all signals we may see in a block diagram or think they must exist. We have a set of SoC where it is demonstrated to work without need for more detailed knowledge about specific hardware integration. So we know everything of importance for this initial set of SoC to make it work. > why should we have that > discussion *now*. It's really not suprising that you don't know yet, so > I'm not sure why we need to rush in the bindings. Because: * there are people who want to have upstream SGX support for an initial set of SoC *now* * the discussion already lasts ca. 6 months since I posted v1, that should be enough and is not a rush * it is not required to know more details to make a working system * we will not gain more information by waiting for another year or two * problems are not solved by postponing them * there are DTS for some initial SoC, tested to work * it is no longer possible to submit DT without bindings.yaml (or is it?) * we just need to define a bindings.yaml for them, not invent something completely new * we can start with a minimal bindings.yaml for the analysed SoC and *extend* it in the future if really needed * we can discuss changes & extensions for the bindings when they are really proposed * having this patch series upstream is a prerequisite for introducing the sgx kernel driver to staging In other words: your suggestion to postpone everything will keep finished work sitting in front of the door and rotting and blocking unfinished work... And to be honest, we have postponed SGX support already for too long time and could be much farther with more and broader community cooperation. So we should not block ourselves. So if you can contribute new information or proposals to specifically improve the proposed bindings.yaml, you are very welcome. But please do it *now*. BR and thanks, Nikolaus
