From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Ricard Date: Thu, 13 Aug 2015 22:32:59 +0200 Subject: [U-Boot] [PATCH 08/25] tpm: tpm_tis_i2c: Drop struct tpm_vendor_specific In-Reply-To: References: <1439304497-10081-1-git-send-email-sjg@chromium.org> <1439304497-10081-9-git-send-email-sjg@chromium.org> <55CA6D72.80902@gmail.com> Message-ID: <55CCFEFB.4050509@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On 13/08/2015 03:30, Simon Glass wrote: > Hi Christophe, > > On 11 August 2015 at 15:47, christophe.ricard > wrote: >> Hi Simon, >> >> Locality concept are valid almost on any chip assuming if no locality are >> supported the default one is locality 0. >> I would leave this change open for discussion. >> >> However, as per patch 06 & 07, i would keep req_complete_mask, >> req_complete_val, req_canceled, timeout_a, timeout_b, timeout_c, timeout_d >> in tpm_vendor_specific structure as this is chip specific. >> >> I really think tpm_vendor_specific is usefull for managing different kind of >> TPM "the same way"/following standards. > That code belongs in the uclass I think. If there really are generic > settings that are needed for all TPMs then it should sit there. We > don't want to have an additional layer of stuff that doesn't relate to > driver model. After reviewing your previous comments, i think we can drop this tpm_vendor_specific structure to simplify the code a bit. However, the work we are doing may stick only to TPM1.2. I think it will be fine as we have only drivers for those kind of TPMs. I believe a new uclass may be necessary when going to provide support TPM 2.0. In short, may be we can anticipate that and make it explicit in the uclass name ? (UCLASS_TPM12 ?) [...] Best Regards Christophe