Dear Simon Glass,
In message CAPnjgZ2QyRjfjbJTR9MHcsQUEV933oAWPjSTvv-kFrhLCFJRUg@mail.gmail.com you wrote:
OK, but I still don't quite get it. As I asked in the other thread, are you not interested in TPM functionality at all until we have a verified boot implementation, or are you happy to have things progress in stages? I'm will to work through this, and I have the time at present, but I believe that drivers for two common TPM chips are a useful addition to U-Boot regardless.
I'm sorry, but I disagree - the drivers may be useful indeed, but as long as there are no users in U-Boot they are just dead weight.
So far we have followed the rule not to add dead code - we always asked to add code (drivers) together with any "consumers", i. e. other code that provides useful features (at least to one board) that actually needs and uses such drivers.
With TPM we made an exception from this rule, based on the expectation that users would be added "soon". Then a full year passed, and nothing happened. Really _nothing_.
Now you suggest to "progress in stages"? You mean adding more and more code around, all of which will be unused, until one bright day in a non-foreseeable future some board might get added, that will then use this?
This is not exactly a proposal that triggers enthusiasm to me.
It's not obvious how to mainline this rather large feature except in pieces. For example, I think I can start on a feature to verify a kernel, but I do want to talk to the TPM as part of that.
Instead of working bottom up (which will necessarily result in an approach trying to add unused code) you could do it top down: start indeed with a feature to verify a kernel (oh! we already have that as psrt of the image verification - with simple CRC in the leggacy images, and will optionally all other kinds in FIT images). This "verification could initially be an empty function just returning a "true" value. No TPM is needed for that. Than work top down for there.
That's going to be a big series.... but in contrast, display, SATA and GPIO patches are ok, but TPM is not?
Ummm... are you telling me that contrast, display, SATA and GPIO patches all also add dead code that is not used anywhere? I have not looked closer there because I simply did not expoect this. But if so, the very same rules apply: we do not want to add dead code.
I'll see what I can do here, but in principle I feel that adding a driver should be OK, provided a board uses it, without necessarily the high-level code that uses it. After all, we don't necessarily expect to mainline all the scripts that drive the actual boot.
what exactly do you mean by "a board uses it, without necessarily the high-level code that uses it"? If "uses" for you means just conteining a function call reference so the code gets cimpiled and pulled in by the linker, then I have to tell you that this NOT my understanding of "usage".
For me, "using" some code means that it actually performs some _function_. As long as the code is not actually running on the system, it is not being used.
And especially not after the experience with the TPM code so far, where my patience has been exhausted after more than a year of nothing happening.
Well not nothing. Have been rather tied up getting a product out. I
Sorry, but for U-Boot it is completely irrelevant what happens with your out of tree code. The code in mainline has just been sitting there, unused as ever.
agree that things have been very quiet on verified boot - perhaps the original upstream author was exhausted after the effort of getting the driver into mainline and retired for a rest :-)
Well, this experience has sunk in. Exactly what I feared has happened: the code was added, and it has been dead ever since, for more than a full year.
It will be pretty difficult to talk me again into accepting unused code.
However most of the common/ series is code that we depend on and I think might be generally useful. I do admit that in striving for a very high level of polish we have attacked problems that perhaps would not matter for many systems, and thus more patches.
Mentioning that you depend on some specific code does not actually make me feel bad, if this is what you (subcounsciously) had in mind. Quote David Woodhouse: "If you're out of tree, you don't exist." ( http://article.gmane.org/gmane.linux.kernel.embedded/3534 )
All this discussion confirmed my resolution not to allow for dead code.
Best regards,
Wolfgang Denk