Dear Simon,
In message CAPnjgZ0vRbsFWpGqsZPy=TjgJp9r80VnVv2Pcem5werL8bRwmw@mail.gmail.com you wrote:
I think you may have missed the pending patches which make use of this. it is important functionality for the Chromebooks (secure boot).
No, I have not missed these. But all the patch does is set CONFIG_GENERIC_LPC_TPM - there is still not a single user defining CONFIG_CMD_TPM, so what does this help? We still have tons of dead code around. Dump it!
So we need a board that defines the command also? I did not realise that was a requirement - certainly I can add that command to the boards also.
No, you misunderstand. You stick at the surface, at the formal part of it. Indeed enabling this option for a board would be an improvement - at least then we could be sure that the code compiles. But that does not actually make it _used_. Similar to you enabling of CONFIG_GENERIC_LPC_TPM - the code that needs appears to be just more unused code itself so this is not actual _use_ in the sense of providing a functionality needed for the operation of the device.
Upstreaming the code is a step-by-step process. The TPM is an important component of secure boot, and things have to progress in some sort of fashion. I do understand the dead code argument, but we can't submit high-level code without the drivers it uses (and there are many).
Well, we had this very same discussion when the TPM code was originally added, and I let myself talk into accepting it, based on the argument that code that needs it is available and will be mainlined "really soon now". More than a year has passed, and _nothing_ happened. Now I see the next wave of patches adding dead code in the same are, and I have to admit that this does not make me enthusiastic.
I think your approach is wrong. You should try and get a minimal version (obviously with very restricted functionality) of your "high-level code" into mainline, and all needed drivers in the same patch series (which makes clear why this should be a minimal configuration). Then add drivers and functionality step by step. Adding a driver here and a driver there one by one with the slight chance that there might - in some unforeseeable future - a board submitted that actually uses these all is nothing I'm going to accept.
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.
Finally, I also have license concerns about the newly submitted code. Statements like "code is governed by a BSD-style license" (in drivers/tpm/tis_i2c.c) are obviusly not acceptabl at all - there are several BSD-style licenses - am I to chose myself any of these, or what???
I have the impression that you are trying to use the end of the merge window to get a whole a bunch of very green code into mainline, ignoring quite a number of rules well known to you.
Best regards,
Wolfgang Denk