Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote: > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote: > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins > > wrote: > > > > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote: > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > > > > > However, the reply is incorrect. Kselftest in-kernel tests (which > > > > > > is the context here) can be configured as built in instead of as > > > > > > a module, and built in a UML kernel. The UML kernel can boot, > > > > > > running the in-kernel tests before UML attempts to invoke the > > > > > > init process. > > > > > > > > > > Um, Citation needed? > > > > > > > > > > I don't see any evidence for this in the kselftest documentation, nor > > > > > do I see any evidence of this in the kselftest Makefiles. > > > > > > > > > > There exists test modules in the kernel that run before the init > > > > > scripts run --- but that's not strictly speaking part of kselftests, > > > > > and do not have any kind of infrastructure. As noted, the > > > > > kselftests_harness header file fundamentally assumes that you are > > > > > running test code in userspace. > > > > > > > > Yeah I really like the "no userspace required at all" design of kunit, > > > > while still collecting results in a well-defined way (unless the current > > > > self-test that just run when you load the module, with maybe some > > > > kselftest ad-hoc wrapper around to collect the results). > > > > > > > > What I want to do long-term is to run these kernel unit tests as part of > > > > the build-testing, most likely in gitlab (sooner or later, for drm.git > > > > > > Totally! This is part of the reason I have been insisting on a minimum > > > of UML compatibility for all unit tests. If you can suffiently constrain > > > the environment that is required for tests to run in, it makes it much > > > easier not only for a human to run your tests, but it also makes it a > > > lot easier for an automated service to be able to run your tests. > > > > > > I actually have a prototype presubmit already working on my > > > "stable/non-upstream" branch. You can checkout what presubmit results > > > look like here[1][2]. > > > > ug gerrit :-) > > Yeah, yeah, I know, but it is a lot easier for me to get a project set > up here using Gerrit, when we already use that for a lot of other > projects. > > Also, Gerrit has gotten a lot better over the last two years or so. Two > years ago, I wouldn't touch it with a ten foot pole. It's not so bad > anymore, at least if you are used to using a web UI to review code. I was somewhat joking, I'm just not used to gerrit ... And seems to indeed be a lot more polished than last time I looked at it seriously. > > > > only ofc). So that people get their pull requests (and patch series, we > > > > have some ideas to tie this into patchwork) automatically tested for > > > > this > > > > > > Might that be Snowpatch[3]? I talked to Russell, the creator of Snowpatch, > > > and he seemed pretty open to collaboration. > > > > > > Before I heard about Snowpatch, I had an intern write a translation > > > layer that made Prow (the presubmit service that I used in the prototype > > > above) work with LKML[4]. > > > > There's about 3-4 forks/clones of patchwork. snowpatch is one, we have > > a different one on freedesktop.org. It's a bit a mess :-/ > > Oh, I didn't realize that. I found your patchwork instance here[5], but > do you have a place where I can see the changes you have added to > support presubmit? Ok here's a few links. Aside from the usual patch view we've also added a series view: https://patchwork.freedesktop.org/project/intel-gfx/series/?ordering=-last_updated This ties the patches + cover letter together, and it even (tries to at least) track revisions. Here's an example which is currently at revision 9: https://patchwork.freedesktop.org/series/57232/ Below the patch list for each revision we also have the test result list. If you click on the grey bar it'll expand with the summary from CI, the "See full logs" is link to the full results from our CI. This is driven with some REST api from our jenkins. Patchwork also sends out mails for these results. Source is on gitlab: https://gitlab.freedesktop.org/patchwork-fdo > > > I am not married to either approach, but I think between the two of > > > them, most of the initial legwork has been done to make presubmit on > > > LKML a reality. > > > > We do have presubmit CI working already with our freedesktop.org > > patchwork. The missing glue is just tying that into gitlab CI somehow > > (since we want to unify build testing more and make it easier for > > contributors to adjust things). > > I checked out a couple of your projects on your patchwork instance: AMD > X.Org drivers, DRI devel, and Wayland. I saw the tab you added for > test
Re: [PATCH v3 1/2] ftpm: firmware TPM running in TEE
On Mon, Apr 15, 2019 at 11:56:35AM -0400, Sasha Levin wrote:
> This patch adds support for a software-only implementation of a TPM
> running in TEE.
>
> There is extensive documentation of the design here:
> https://www.microsoft.com/en-us/research/publication/ftpm-software-implementation-tpm-chip/
> .
>
> As well as reference code for the firmware available here:
> https://github.com/Microsoft/ms-tpm-20-ref/tree/master/Samples/ARM32-FirmwareTPM
The commit message should include at least a brief description what TEE
is.
>
> Signed-off-by: Thirupathaiah Annapureddy
> Signed-off-by: Sasha Levin
> ---
> drivers/char/tpm/Kconfig| 5 +
> drivers/char/tpm/Makefile | 1 +
> drivers/char/tpm/tpm_ftpm_tee.c | 366
> drivers/char/tpm/tpm_ftpm_tee.h | 47
> 4 files changed, 419 insertions(+)
> create mode 100644 drivers/char/tpm/tpm_ftpm_tee.c
> create mode 100644 drivers/char/tpm/tpm_ftpm_tee.h
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index 536e55d3919f..5638726641eb 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -164,6 +164,11 @@ config TCG_VTPM_PROXY
> /dev/vtpmX and a server-side file descriptor on which the vTPM
> can receive commands.
>
> +config TCG_FTPM_TEE
> + tristate "TEE based fTPM Interface"
> + depends on TEE
> + ---help---
> + This driver proxies for fTPM running in TEE
>
> source "drivers/char/tpm/st33zp24/Kconfig"
> endif # TCG_TPM
> diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
> index a01c4cab902a..c354cdff9c62 100644
> --- a/drivers/char/tpm/Makefile
> +++ b/drivers/char/tpm/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/
> obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o
> obj-$(CONFIG_TCG_CRB) += tpm_crb.o
> obj-$(CONFIG_TCG_VTPM_PROXY) += tpm_vtpm_proxy.o
> +obj-$(CONFIG_TCG_FTPM_TEE) += tpm_ftpm_tee.o
> diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
> new file mode 100644
> index ..f33cdfeb5376
> --- /dev/null
> +++ b/drivers/char/tpm/tpm_ftpm_tee.c
> @@ -0,0 +1,366 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Microsoft Corporation
> + */
There should be at least some description what kind of implementation
this is and something about TEE.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "tpm.h"
> +#include "tpm_ftpm_tee.h"
> +
> +#define DRIVER_NAME "ftpm-tee"
> +
> +/* TA_FTPM_UUID: BC50D971-D4C9-42C4-82CB-343FB7F37896 */
> +static const uuid_t ftpm_ta_uuid =
> + UUID_INIT(0xBC50D971, 0xD4C9, 0x42C4,
> + 0x82, 0xCB, 0x34, 0x3F, 0xB7, 0xF3, 0x78, 0x96);
Just wondering why prefixes are here in different order in the comment
and code.
> +
> +/*
> + * Note: ftpm_tee_tpm_op_recv and ftpm_tee_tpm_op_send are called from the
> + * same routine tpm_try_transmit in tpm-interface.c. These calls are
> protected
> + * by chip->tpm_mutex => There is no need for protecting any data shared
> + * between these routines ex: struct ftpm_tee_private
> + */
This documentation block should be removed. It could be in all drivers
and thus this documentation belongs outside of specific HW drivers.
> +
> +/**
> + * ftpm_tee_tpm_op_recv retrieve fTPM response.
> + * @param: chip, the tpm_chip description as specified in
> driver/char/tpm/tpm.h.
> + * @param: buf, the buffer to store data.
> + * @param: count, the number of bytes to read.
> + * @return: In case of success the number of bytes received.
> + * In other case, a < 0 value describing the issue.
> + */
This should be modified to follow kdoc [1]. It is inconsistent with the
other kdoc comments we have. Now it is all wrong and contains redundant
information. It should be something like
/**
* ftpm_tee_tpm_op_recv() - retrieve a response from fTPM
* @chip: TPM chip associated with the fTPM
* @buf:buffer for the received data
* @count: number of bytes to read
*
* Copy the response from fTPM's internal buffer to the buffer provided
* by the caller.
*
* Return:
* 0 on success,
* -errno on error
*/
> +static int ftpm_tee_tpm_op_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> +{
> + struct ftpm_tee_private *pvt_data = dev_get_drvdata(chip->dev.parent);
> + size_t len;
> +
> + len = pvt_data->resp_len;
> + if (count < len) {
> + dev_err(&chip->dev,
> + "%s:Invalid size in recv: count=%zd, resp_len=%zd\n",
> + __func__, count, len);
> + return -EIO;
> + }
> +
> + memcpy(buf, pvt_data->resp_buf, len);
> + pvt_data->resp_len = 0;
> +
> + return len;
> +}
> +
> +/**
> + * ftpm_tee_tpm_op_send send TPM commands through the TEE shared memory.
> + *
> + * @param: chip, the tpm_chip description as specified in
> driver/char/tpm/tpm.h
> + * @param: buf, the buffer t
Re: [PATCH v3 2/2] ftpm: add documentation for ftpm driver
On Mon, Apr 15, 2019 at 11:56:36AM -0400, Sasha Levin wrote: > This patch adds basic documentation to describe the new fTPM driver. > > Signed-off-by: Sasha Levin > Signed-off-by: Sasha Levin (Microsoft) > --- > Documentation/security/tpm/index.rst| 1 + > Documentation/security/tpm/tpm_ftpm_tee.rst | 31 + > 2 files changed, 32 insertions(+) > create mode 100644 Documentation/security/tpm/tpm_ftpm_tee.rst > > diff --git a/Documentation/security/tpm/index.rst > b/Documentation/security/tpm/index.rst > index af77a7bbb070..15783668644f 100644 > --- a/Documentation/security/tpm/index.rst > +++ b/Documentation/security/tpm/index.rst > @@ -4,4 +4,5 @@ Trusted Platform Module documentation > > .. toctree:: > > + tpm_ftpm_tee > tpm_vtpm_proxy > diff --git a/Documentation/security/tpm/tpm_ftpm_tee.rst > b/Documentation/security/tpm/tpm_ftpm_tee.rst > new file mode 100644 > index ..29c2f8b5ed10 > --- /dev/null > +++ b/Documentation/security/tpm/tpm_ftpm_tee.rst > @@ -0,0 +1,31 @@ > += > +Firmware TPM Driver > += > + > +| Authors: > +| Thirupathaiah Annapureddy > +| Sasha Levin > + > +This document describes the firmware Trusted Platform Module (fTPM) > +device driver. > + > +Introduction > + > + > +This driver is a shim for a firmware implemented in ARM's TrustZone > +environment. The driver allows programs to interact with the TPM in the same > +way the would interact with a hardware TPM. > + > +Design > +== > + > +The driver acts as a thin layer that passes commands to and from a TPM > +implemented in firmware. The driver itself doesn't contain much logic and is > +used more like a dumb pipe between firmware and kernel/userspace. > + > +The firmware itself is based on the following paper: > +https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf > + > +When the driver is loaded it will expose ``/dev/tpmX`` character devices to > +userspace which will enable userspace to communicate with the firmware tpm > +through this device. > -- > 2.19.1 > Actually this would a better place at least with some words to describe what is TEE. I'm, for example, confused whether there is only single TEE in existence always used with TZ or is this some MS specific TEE. Otherwise, looks legit. /Jarkko
Re: [PATCH v3 15/18] Documentation: kunit: add documentation for KUnit
On Tue, 14 May 2019 16:19:02 -0700 Brendan Higgins wrote: > Hmmm...probably premature to bring this up, but Documentation/dev-tools/ > is kind of thrown together. Wait a minute, man... *I* created that directory, are you impugning my work? :) But yes, "kind of thrown together" is a good description of much of Documentation/. A number of people have been working for years to make that better, with some success, but there is a long way to go yet. The dev-tools directory is an improvement over having that stuff scattered all over the place — at least it's actually thrown together — but it's not the end point. > It would be nice to provide a coherent overview, maybe provide some > basic grouping as well. > > It would be nice if there was kind of a gentle introduction to the > tools, which ones you should be looking at, when, why, etc. Total agreement. All we need is somebody to write it! :) Thanks, jon
[TRIVIA] Re: [PATCH] docs: Move kref.txt to core-api/kref.rst
On Fri, 10 May 2019 16:45:45 -0400 "Tobin C. Harding" wrote: > I read once that they used 72 characters on punch cards at times because > the other 8 characters got mangled for some reason. Those of use who worked in Fortran understand these things... columns 73-80 were ignored by the compiler. The normal use was to put line numbers in there to help recovery when you dropped your card deck on the floor and had to unshuffle things. A diagonal line drawn across the top of deck helped a lot, but it was good to have verification for the marginal cases. Kids today just don't have any culture at all...:) jon
[PATCH v4 0/2] kheaders fixes for -rc
Linus, Greg, Masahiro, Here are some simple fixes for the kheaders feature.
Please consider these patches for an rc release. They are based on Linus's
master branch. The only difference between the last series [1] and this one is
I squashed 1/3 and 3/3 and rebased. Thanks!
[1] https://patchwork.kernel.org/cover/10939557/
Joel Fernandes (Google) (2):
kheaders: Move from proc to sysfs
kheaders: Do not regenerate archive if config is not changed
init/Kconfig| 17 +
kernel/Makefile | 4 +--
kernel/{gen_ikh_data.sh => gen_kheaders.sh} | 17 ++---
kernel/kheaders.c | 40 +
4 files changed, 38 insertions(+), 40 deletions(-)
rename kernel/{gen_ikh_data.sh => gen_kheaders.sh} (82%)
--
2.21.0.1020.gf2820cf01a-goog
[PATCH v4 2/2] kheaders: Do not regenerate archive if config is not changed
Linus reported an issue that doing an allmodconfig was causing the kheaders archive to be regenerated even though the config is the same. This patch fixes the issue by ignoring the config-related header files for "knowing when to regenerate based on timestamps". Instead, if the CONFIG_X_Y option really changes, then we there are the include/config/X/Y.h which will already tells us "if a config really changed". So we don't really need these files for regeneration detection anyway, and ignoring them fixes Linus's issue. Reported-by: Linus Torvalds Signed-off-by: Joel Fernandes (Google) --- kernel/gen_kheaders.sh | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh index 581b83534587..9a34e1d9bd7f 100755 --- a/kernel/gen_kheaders.sh +++ b/kernel/gen_kheaders.sh @@ -31,9 +31,8 @@ arch/$SRCARCH/include/ # This block is useful for debugging the incremental builds. # Uncomment it for debugging. -# iter=1 -# if [ ! -f /tmp/iter ]; then echo 1 > /tmp/iter; -# else;iter=$(($(cat /tmp/iter) + 1)); fi +# if [ ! -f /tmp/iter ]; then iter=1; echo 1 > /tmp/iter; +# else iter=$(($(cat /tmp/iter) + 1)); echo $iter > /tmp/iter; fi # find $src_file_list -type f | xargs ls -lR > /tmp/src-ls-$iter # find $obj_file_list -type f | xargs ls -lR > /tmp/obj-ls-$iter @@ -43,10 +42,18 @@ arch/$SRCARCH/include/ pushd $kroot > /dev/null src_files_md5="$(find $src_file_list -type f | grep -v "include/generated/compile.h" | + grep -v "include/generated/autoconf.h" | + grep -v "include/config/auto.conf" | + grep -v "include/config/auto.conf.cmd" | + grep -v "include/config/tristate.conf" | xargs ls -lR | md5sum | cut -d ' ' -f1)" popd > /dev/null obj_files_md5="$(find $obj_file_list -type f | grep -v "include/generated/compile.h" | + grep -v "include/generated/autoconf.h" | + grep -v "include/config/auto.conf" | + grep -v "include/config/auto.conf.cmd" | + grep -v "include/config/tristate.conf" | xargs ls -lR | md5sum | cut -d ' ' -f1)" if [ -f $tarfile ]; then tarfile_md5="$(md5sum $tarfile | cut -d ' ' -f1)"; fi @@ -82,7 +89,7 @@ find $cpio_dir -type f -print0 | tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null -echo "$src_files_md5" > kernel/kheaders.md5 +echo "$src_files_md5" > kernel/kheaders.md5 echo "$obj_files_md5" >> kernel/kheaders.md5 echo "$(md5sum $tarfile | cut -d ' ' -f1)" >> kernel/kheaders.md5 -- 2.21.0.1020.gf2820cf01a-goog
[PATCH v4 1/2] kheaders: Move from proc to sysfs
The kheaders archive consisting of the kernel headers used for compiling
bpf programs is in /proc. However there is concern that moving it here
will make it permanent. Let us move it to /sys/kernel as discussed [1].
[1] https://lore.kernel.org/patchwork/patch/1067310/#1265969
Suggested-by: Steven Rostedt
Signed-off-by: Joel Fernandes (Google)
---
This patch applies on top of the previous patch that was applied to the
driver tree:
https://lore.kernel.org/patchwork/patch/1067310/
v2->v3: Fixed sysfs file mode nit (Greg).
v1->v2: Fixed some kconfig nits (Masami).
init/Kconfig| 17 +
kernel/Makefile | 4 +--
kernel/{gen_ikh_data.sh => gen_kheaders.sh} | 2 +-
kernel/kheaders.c | 40 +
4 files changed, 27 insertions(+), 36 deletions(-)
rename kernel/{gen_ikh_data.sh => gen_kheaders.sh} (98%)
diff --git a/init/Kconfig b/init/Kconfig
index 8b9ffe236e4f..16a7540d60c8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -579,15 +579,14 @@ config IKCONFIG_PROC
This option enables access to the kernel configuration file
through /proc/config.gz.
-config IKHEADERS_PROC
- tristate "Enable kernel header artifacts through /proc/kheaders.tar.xz"
- depends on PROC_FS
- help
- This option enables access to the kernel header and other artifacts
that
- are generated during the build process. These can be used to build
eBPF
- tracing programs, or similar programs. If you build the headers as a
- module, a module called kheaders.ko is built which can be loaded
on-demand
- to get access to the headers.
+config IKHEADERS
+ tristate "Enable kernel headers through /sys/kernel/kheaders.tar.xz"
+ depends on SYSFS
+ help
+ This option enables access to the in-kernel headers that are
generated during
+ the build process. These can be used to build eBPF tracing programs,
+ or similar programs. If you build the headers as a module, a module
called
+ kheaders.ko is built which can be loaded on-demand to get access to
headers.
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
diff --git a/kernel/Makefile b/kernel/Makefile
index 33824f0385b3..a8d923b5481b 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -71,7 +71,7 @@ obj-$(CONFIG_UTS_NS) += utsname.o
obj-$(CONFIG_USER_NS) += user_namespace.o
obj-$(CONFIG_PID_NS) += pid_namespace.o
obj-$(CONFIG_IKCONFIG) += configs.o
-obj-$(CONFIG_IKHEADERS_PROC) += kheaders.o
+obj-$(CONFIG_IKHEADERS) += kheaders.o
obj-$(CONFIG_SMP) += stop_machine.o
obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
@@ -127,7 +127,7 @@ $(obj)/config_data.gz: $(KCONFIG_CONFIG) FORCE
$(obj)/kheaders.o: $(obj)/kheaders_data.tar.xz
quiet_cmd_genikh = CHK $(obj)/kheaders_data.tar.xz
-cmd_genikh = $(CONFIG_SHELL) $(srctree)/kernel/gen_ikh_data.sh $@
+cmd_genikh = $(CONFIG_SHELL) $(srctree)/kernel/gen_kheaders.sh $@
$(obj)/kheaders_data.tar.xz: FORCE
$(call cmd,genikh)
diff --git a/kernel/gen_ikh_data.sh b/kernel/gen_kheaders.sh
similarity index 98%
rename from kernel/gen_ikh_data.sh
rename to kernel/gen_kheaders.sh
index 591a94f7b387..581b83534587 100755
--- a/kernel/gen_ikh_data.sh
+++ b/kernel/gen_kheaders.sh
@@ -2,7 +2,7 @@
# SPDX-License-Identifier: GPL-2.0
# This script generates an archive consisting of kernel headers
-# for CONFIG_IKHEADERS_PROC.
+# for CONFIG_IKHEADERS.
set -e
spath="$(dirname "$(readlink -f "$0")")"
kroot="$spath/.."
diff --git a/kernel/kheaders.c b/kernel/kheaders.c
index 70ae6052920d..8f69772af77b 100644
--- a/kernel/kheaders.c
+++ b/kernel/kheaders.c
@@ -8,9 +8,8 @@
#include
#include
-#include
+#include
#include
-#include
/*
* Define kernel_headers_data and kernel_headers_data_end, within which the
@@ -31,39 +30,32 @@ extern char kernel_headers_data;
extern char kernel_headers_data_end;
static ssize_t
-ikheaders_read_current(struct file *file, char __user *buf,
- size_t len, loff_t *offset)
+ikheaders_read(struct file *file, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t len)
{
- return simple_read_from_buffer(buf, len, offset,
- &kernel_headers_data,
- &kernel_headers_data_end -
- &kernel_headers_data);
+ memcpy(buf, &kernel_headers_data + off, len);
+ return len;
}
-static const struct file_operations ikheaders_file_ops = {
- .read = ikheaders_read_current,
- .llseek = default_llseek,
+static struct bin_attribute kheaders_attr __ro_after_init = {
+ .attr = {
+ .name = "kheaders.tar.xz",
+ .mode = 0444,
+ },
+ .read = &ikheaders_read,
RE: [PATCH v3 0/2] ftpm: a firmware based TPM driver
> -Original Message- > From: Sumit Garg > Sent: Tuesday, May 14, 2019 7:02 PM > To: Sasha Levin > Cc: Jarkko Sakkinen ; peterhu...@gmx.de; > j...@ziepe.ca; cor...@lwn.net; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-doc@vger.kernel.org; linux- > integr...@vger.kernel.org; Microsoft Linux Kernel List ker...@microsoft.com>; Thirupathaiah Annapureddy ; > Bryan Kelly (CSI) > Subject: Re: [PATCH v3 0/2] ftpm: a firmware based TPM driver > > On Wed, 15 May 2019 at 01:00, Sasha Levin wrote: > > > > On Wed, May 08, 2019 at 03:44:36PM +0300, Jarkko Sakkinen wrote: > > >On Tue, May 07, 2019 at 01:40:20PM -0400, Sasha Levin wrote: > > >> On Mon, Apr 15, 2019 at 11:56:34AM -0400, Sasha Levin wrote: > > >> > From: "Sasha Levin (Microsoft)" > > >> > > > >> > Changes since v2: > > >> > > > >> > - Drop the devicetree bindings patch (we don't add any new ones). > > >> > - More code cleanups based on Jason Gunthorpe's review. > > >> > > > >> > Sasha Levin (2): > > >> > ftpm: firmware TPM running in TEE > > >> > ftpm: add documentation for ftpm driver > > >> > > >> Ping? Does anyone have any objections to this? > > > > > >Sorry I've been on vacation week before last week and last week > > >I was extremely busy because I had been on vacation. This in > > >my TODO list. Will look into it tomorrow in detail. > > > > > >Apologies for the delay with this! > > > > Hi Jarkko, > > > > If there aren't any big objections to this, can we get it merged in? > > We'll be happy to address any comments that come up. > > I guess you have missed or ignored this comment [1]. Please address it. > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org% > 2Flkml%2F2019%2F5%2F8%2F11&data=01%7C01%7Cthiruan%40microsoft.com%7Cf2a > 80c7b94434329eaee08d6d8d962b1%7C72f988bf86f141af91ab2d7cd011db47%7C1&sd > ata=hyJRc23NwEFLDuaIMkbSCGetd%2BObQWiAg%2BJtMMR6z9U%3D&reserved=0 > > -Sumit Thanks for reviewing and adding comments. We tried to use TEE bus framework you suggested for fTPM enumeration. We were not able to pass the TCG Logs collected by the boot loaders. Currently there are 3 ways to pass TCG Logs based on the code in drivers/char/tpm/eventlog: 1. ACPI Table 2. EFI Table 3. OF Device node properties Our ARM system is booting using U-boot and Device Tree. So ACPI/EFI table mechanism to pass TCG2 logs won't be applicable. We needed to use OF device node properties to pass TCG2 Logs. TEE bus enumeration framework does not work for our use case due to the above. Is it possible to add flexibility in TEE bus enumeration framework to support platform specific properties through OF nodes or ACPI? > > > > > -- > > Thanks, > > Sasha
