> Hi,
>
> On 4/7/21 8:51 AM, Winkler, Tomas wrote:
> >>>
> >>> During PCH (platform/board) manufacturing process a global reset has
> >>> to be induced in order for configuration changes take the effect
> >>> upon following platform res
> >
> > During PCH (platform/board) manufacturing process a global reset has
> > to be induced in order for configuration changes take the effect upon
> > following platform reset.
> > This setting was commonly done by accessing PMC registers via /dev/mem
> > but due to security concern /dev/mem
> -Original Message-
> From: Enrico Weigelt, metux IT consult
> Sent: Friday, April 02, 2021 16:32
> To: Winkler, Tomas ; Rajneesh Bhardwaj
> ; Box, David E ; Hans
> de Goede ; Mark Gross
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org;
&g
> On 3/21/21 11:53 PM, Lukas Bulwahn wrote:
> > The command 'find drivers/watchdog | xargs ./scripts/kernel-doc -none'
> > reports a number of kernel-doc warnings in the watchdog subsystem.
> >
> > Address the kernel-doc warnings that were purely syntactic issues with
> > kernel-doc comments.
> >
> On Thu, Mar 4, 2021 at 8:54 PM Winkler, Tomas
> wrote:
> > > Winkler, Tomas writes:
> > > >> "Winkler, Tomas" writes:
> > > >>
> > > >> >> The user space API is achieved via a number of synchronous
&g
>
> Winkler, Tomas writes:
>
> >> "Winkler, Tomas" writes:
> >>
> >> >> The user space API is achieved via a number of synchronous IOCTLs.
> >> >>
> >> >> * RPMB_IOC_VER_CMD - sim
> "Winkler, Tomas" writes:
>
> >> The user space API is achieved via a number of synchronous IOCTLs.
> >>
> >> * RPMB_IOC_VER_CMD - simple versioning API
> >> * RPMB_IOC_CAP_CMD - query of underlying capabilities
> >&g
>
> The user space API is achieved via a number of synchronous IOCTLs.
>
> * RPMB_IOC_VER_CMD - simple versioning API
> * RPMB_IOC_CAP_CMD - query of underlying capabilities
> * RPMB_IOC_PKEY_CMD - one time programming of access key
> * RPMB_IOC_COUNTER_CMD - query the write counter
>
>
> Tomas,
>
> - Ursprüngliche Mail -
> >> As Richard was saying, we are really open to enhance MTD refcounting.
> >>
> >> However, the issue you are facing is, IMHO, not related to MTD but to
> MFD.
> >> There should be a way to avoid MFD to vanish by taking a reference of
> >> it
>
> On Sat, Feb 06, 2021 at 03:04:34PM +, Winkler, Tomas wrote:
> > > On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote:
> > > > From: Alexander Usyskin
> > > >
> > > > Expose the client dma mapping via mei client bus interfac
> On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote:
> > From: Alexander Usyskin
> >
> > Expose the client dma mapping via mei client bus interface.
> >
> > Signed-off-by: Alexander Usyskin
> > Signed-off-by: Tomas Winkler
> > ---
> > drivers/misc/mei/bus.c | 46
>
> On Sat, Feb 06, 2021 at 04:43:20PM +0200, Tomas Winkler wrote:
> > Using of snprintf is discouraged in sysfs.
> > For simple u8 it is safe to use sprintf.
> >
> > Signed-off-by: Tomas Winkler
> > ---
> > drivers/misc/mei/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Hi Tomas,
>
> "Winkler, Tomas" wrote on Thu, 28 Jan 2021
> 08:53:43 +:
>
> > > Tomas,
> > >
> > > - Ursprüngliche Mail -
> > > >> >> Can you please explain a little more what devices
> Tomas,
>
> - Ursprüngliche Mail -
> >> >> Can you please explain a little more what devices are involved?
> >> >> Does it implement _get_device() and _put_device()?
> >> > No this is not connected to those handlers of the underlying device
> >> > and those won't help.
> >> > I have a
>
> - Ursprüngliche Mail -
> >> > When underlying device is removed mtd core will crash in case user
> >> > space is still holding an open handle to a mtd device node.
> >> > A proper refcounting is needed so device is release only when a
> >> > partition has no active users. The current
> Subject: Re: [PATCH] mtd: use refcount to prevent corruption
>
> Tomas,
>
> - Ursprüngliche Mail -
> > Von: "Tomas Winkler"
> > An: "Miquel Raynal" , "richard"
> > , "Vignesh Raghavendra" , "linux-mtd"
> > , "linux-kernel"
> >
> > CC: "Tomas Winkler"
> > Gesendet: Mittwoch, 27.
>
> Tomas,
>
> On Thu, Jan 07, 2021 at 04:12:15PM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > On Thu, Jan 07, 2021 at 09:57:30PM +0200, Tomas Winkler wrote:
> > > From: Alexander Usyskin
> > >
> > > Send the stop command to the firmware on watchdog unregister to
> > > eleminate false event on
>
> On Tue, Aug 18, 2020 at 02:51:47PM +0300, Tomas Winkler wrote:
> > +#ifndef VIRTIO_ID_MEI
> > +#define VIRTIO_ID_MEI 0xFFFE /* virtio mei */ #endif
>
> Just noticed now that this driver landed upstream. Can I ask that you guys
> please register IDs with the virtio TC and not just pick a
> Sphinx 3.x doesn't allow expressions using :c:func markup:
>
> ./Documentation/driver-api/mei/mei.rst:41: WARNING: Unparseable
> C cross-reference: 'close(int fd)'
> Invalid C declaration: Expected end of definition. [error at 5]
> close(int fd)
> -^
>
> So,
> > Hi Tomas,
> >
> > On 7/30/20 02:02, Tomas Winkler wrote:
> > > wired_cmd_repeater_auth_stream_req_in has a variable length array at
> > > the end. we use struct_size() overflow macro to determine the size
> > > for the allocation and sending size.
> > >
> >
> > My comments here:
> >
> Hi Tomas,
>
> On 7/30/20 02:02, Tomas Winkler wrote:
> > wired_cmd_repeater_auth_stream_req_in has a variable length array at
> > the end. we use struct_size() overflow macro to determine the size for
> > the allocation and sending size.
> >
>
> My comments here:
>
> On Tue, 2020-07-28 at 22:14 +0000, Winkler, Tomas wrote:
> > > -Original Message-
> > > From: Gustavo A. R. Silva
> []
> > > I'm using this command:
> > >
> > > $ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallbac
>
> Tomas,
>
> Please, see some comments below...
>
> On 7/28/20 17:29, Winkler, Tomas wrote:
> >>>>>
> >>>>> Hi Tomas,
> >>>>>
> >>>>> On 7/28/20 16:41, Tomas Winkler wrote:
> >>>>&g
> > >>
> > >> Hi Tomas,
> > >>
> > >> On 7/28/20 16:41, Tomas Winkler wrote:
> > >>> Greg please revert, this commit it changes size of struct
> > >>> wired_cmd_repeater_auth_stream_req_in, this is not what firmware
> > >>> is expecting.
> > >>
> > >> Could you elaborate on what's the firmware
> -Original Message-
> From: Gustavo A. R. Silva
> Sent: Wednesday, July 29, 2020 01:15
> To: Winkler, Tomas ; Greg Kroah-Hartman
>
> Cc: Usyskin, Alexander ; linux-
> ker...@vger.kernel.org; Gustavo A . R . Silva
> Subject: Re: [char-misc-next] Revert "m
> -Original Message-
> From: Gustavo A. R. Silva
> Sent: Wednesday, July 29, 2020 00:57
> To: Winkler, Tomas ; Greg Kroah-Hartman
>
> Cc: Usyskin, Alexander ; linux-
> ker...@vger.kernel.org; Gustavo A . R . Silva
> Subject: Re: [char-misc-next] Revert "m
>
> On Tue, Jul 28, 2020 at 09:28:36PM +0300, Tomas Winkler wrote:
> > +/**
> > + * kind_show - display device kind
> > + *
> > + * @device: device pointer
> > + * @attr: attribute pointer
> > + * @buf: char out buffer
> > + *
> > + * Return: number of the bytes printed into buf or error
>
>
> -Original Message-
> From: Greg Kroah-Hartman
> Sent: Tuesday, July 28, 2020 18:54
> To: Winkler, Tomas
> Cc: Usyskin, Alexander ; linux-
> ker...@vger.kernel.org
> Subject: Re: [char-misc-next] mei: add device type
>
> On Tue, Jul 28, 2020 at 06:25:46PM
>
> Hi Tomas,
>
> Please, see my comments below...
>
> On 7/22/20 14:04, Winkler, Tomas wrote:
> >
> >>
> >> Hi all,
> >>
> >> Friendly ping: who can take this? :)
> >>
> >> Thanks
> >> --
> >> G
>
> Hi all,
>
> Friendly ping: who can take this? :)
>
> Thanks
> --
> Gustavo
>
> On 7/14/20 16:45, Gustavo A. R. Silva wrote:
> > One-element arrays are being deprecated[1]. Replace the one-element
> > arrays with a simple value type u8 reserved, once this is just a
> > placeholder for
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM as HTTPS
> traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^#
>
> On Tue, Jul 14, 2020 at 05:54:32PM +, Winkler, Tomas wrote:
> > >
> > > There is a regular need in the kernel to provide a way to declare
> > > having a dynamically sized set of trailing elements in a structure.
> > > Kernel code sh
>
> There is a regular need in the kernel to provide a way to declare having a
> dynamically sized set of trailing elements in a structure.
> Kernel code should always use “flexible array members”[1] for these cases
> or, as in this particular case, replace the one-element array with a simple
>
> boilerplate
>
> On Sat, 2020-06-06 at 23:20 +, Winkler, Tomas wrote:
> > >
> > > From: Bean Huo
> > >
> > > Add SPDX GPL-2.0 to UFS driver files that specified the GPL version
> > > 2 license,
> > > remove the full boil
>
> From: Bean Huo
>
> The static function ufshcd_setup_clocks() is just a wrapper around
> __ufshcd_setup_clocks(), remove it. Rename original function wrapped
> __ufshcd_setup_clocks() to new ufshcd_setup_clocks().
Not sure about this change, we have only one call with skip_ref_clock set
>
> From: Bean Huo
>
> Add SPDX GPL-2.0 to UFS driver files that specified the GPL version 2 license,
> remove the full boilerplate text.
>
> Signed-off-by: Bean Huo
LGTM.
Thanks
Tomas
> ---
> drivers/scsi/ufs/ufs.h | 27 +--
> drivers/scsi/ufs/ufshcd-pci.c
>
> From: Bean Huo
>
> Add SPDX GPL-2.0 to replace GPL v2 boilerplate, and remove wrapper
> function ufshcd_setup_clocks()
You don't do that in a single patch, please split.
>
> Signed-off-by: Bean Huo
> ---
> drivers/scsi/ufs/ufshcd-pltfrm.c | 26 +-
>
>
> >
> > > These device IDs can be found on Microsoft Surface devices.
> > >
> > > Signed-off-by: Dorian Stoll
> >
> > This need to be done differently because of the server platforms conflict.
> > I have patches for that I will post short, though we are not
> > officially supporting those
> These device IDs can be found on Microsoft Surface devices.
>
> Signed-off-by: Dorian Stoll
This need to be done differently because of the server platforms conflict.
I have patches for that I will post short, though we are not officially
supporting those devices under Linux,
It will be
> -Original Message-
> From: Gustavo A. R. Silva
> Sent: Thursday, May 07, 2020 21:54
> To: Winkler, Tomas
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH] treewide: Replace zero-length array with flexible-array
Ack.
>
> The current codebase make
> -Original Message-
> From: 亿一
> Sent: Wednesday, May 06, 2020 17:47
> To: Winkler, Tomas
> Cc: linux-kernel@vger.kernel.org
> Subject: [BUG]is there a refcount leak in function mei_me_cl_rm_by_uuid?
Unfortunately you are correct, but currently it is very har
> Add the necessary infrastructure to keep timestamp history of commands,
> events and other useful info for debugging complex issues. This helps in
> diagnosing events leading upto failure.
Why not use tracepoints, for that?
Thanks
Tomas
> Signed-off-by: Can Guo
> ---
>
> Dear Tomas,
>
>
> Testing Fedora 30 with Linux 5.2.11 on an old Dell OptiPlex 980, Linux
> log the message below.
>
> [ 15.964298] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could
> not read FW version
> [ 15.964301] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW
>
> Use kmemdup rather than duplicating its implementation
>
> Signed-off-by: YueHaibing
LGTM, ACK.
Tomas
> ---
> drivers/scsi/ufs/ufshcd.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
>
Oops, this should go to 5.3-rc6 possibly, not for next.
Thanks
>
> Add Tiger Lake Point device ID for TGP LP.
>
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/hw-me-regs.h | 2 ++
> drivers/misc/mei/pci-me.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git
>
> Hi all,
>
> On Thu, 20 Jun 2019 15:35:52 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the char-misc tree got a conflict in:
> >
> > drivers/misc/mei/debugfs.c
> >
> > between commit:
> >
> > 5666d896e838 ("mei: no need to check return value of debugfs_create
> >
>
> When calling debugfs functions, there is no need to ever check the return
> value. The function can work or not, but the code logic should never do
> something different based on this.
Maybe need to mention that API has changed in patch '
ff9fb72bc07705c00795ca48631f7fffe24d2c6b' in 5.0
> -Original Message-
> From: Suzuki K Poulose [mailto:suzuki.poul...@arm.com]
> Sent: Monday, June 03, 2019 18:50
> To: linux-kernel@vger.kernel.org
> Cc: gre...@linuxfoundation.org; raf...@kernel.org; suzuki.poul...@arm.com;
> Winkler, Tomas ; Arnd Bergmann
>
>
> On Tue, Apr 02, 2019 at 02:46:25AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Apr 01, 2019 at 12:06:07PM -0700, Kees Cook wrote:
> > > A "get random" may fail with a TPM error, but those codes were
> > > returned as-is to the caller, which assumed the result was the
> > > number of bytes that
>
> A "get random" may fail with a TPM error, but those codes were returned as-is
> to the caller, which assumed the result was the number of bytes that had been
> written to the target buffer, which could lead to a kernel heap memory
> exposure and over-read.
>
> This fixes tpm1_get_random() to
>
> On Sun, Mar 10, 2019 at 10:14:03AM +, Winkler, Tomas wrote:
> > > Please break this up into two (at the least) patches and resend as a
> > > series.
> >
> > Can you be please, more specific what split are you expecting.
>
> You are doing lot
> On Sun, Mar 10, 2019 at 12:03:23PM +0200, Tomas Winkler wrote:
> > Signed-off-by: Tomas Winkler
>
> I can not take patches without any changelog text.
Ok, my mistake.
>
> Especially a patch that does not actually do what your subject: line says it
> does.
Yep, I should be more verbose.
>
>
> On 2/12/19 5:29 PM, Greg KH wrote:
> > On Tue, Feb 12, 2019 at 02:02:52PM +0800, Chengguang Xu wrote:
> >> Actually, total amount of available minor number for a single major
> >> is MINORMARK + 1. So expand minor range when registering chrdev
> >> region.
> >>
> >> Signed-off-by: Chengguang
()
>
> On Tue, Feb 05, 2019 at 10:57:19PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Feb 05, 2019 at 02:56:02PM +0000, Winkler, Tomas wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Jarkko Sakkinen [mailto:jarkko.sakki.
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, February 05, 2019 16:36
> To: Winkler, Tomas
> Cc: linux-integr...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> security-mod...@vger.kernel.org; sta.
> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read will
>
> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read
>
> The current approach to read first 6 bytes from the response and then tail of
> the response, can cause the 2nd memcpy_fromio() to do an unaligned read
> (e.g. read 32-bit word from address aligned to a 16-bits), depending on how
> memcpy_fromio() is implemented. If this happens, the read
> -Original Message-
> From: Winkler, Tomas
> Sent: Thursday, January 31, 2019 21:47
> To: 'Linus Torvalds' ; Jarkko Sakkinen
>
> Cc: Jason Gunthorpe ; James Bottomley
> ; linux-integr...@vger.kernel.org;
> linux-security-mod...@vger.kernel.org; Linux
>
> On Thu, Jan 31, 2019 at 10:52 AM Linus Torvalds foundation.org> wrote:
> >
> > I think what I should do is to just make "memcpy_*io()" do the "align
> > naturally" thing.
> >
> > Let me cook up a patch for you to test.
>
> Does this work for you?
>
> I haven't tested it at all, but I
> > Hello Tomas,
> >
> > >
> > > Define new a type: uc_string_id for easier string handling and less
> > > casting. Reduce number or string copies in price of a dynamic
> > > allocation.
> > >
> > > Signed-off-by: Tomas Winkler
> > Tested-by: Avri Altman
> >
> > Just one nit - doesn't really
> -Original Message-
> From: Avri Altman [mailto:avri.alt...@wdc.com]
> Sent: Tuesday, December 11, 2018 18:18
> To: Winkler, Tomas ; James E . J . Bottomley
> ; Martin K . Petersen
> ; Vinayak Holikatti ;
> Hunter, Adrian
> Cc: Christoph Hellwig ; Vivek Gau
>
> On Mon, Nov 19, 2018 at 09:25:22PM +, Winkler, Tomas wrote:
> >
> >
> > >
> > > The error logging for tpm2_commit_space() is in a wrong place. This
> > > commit moves it inside that function.
> > >
> > > Cc: James
>
> On Mon, Nov 19, 2018 at 09:25:22PM +, Winkler, Tomas wrote:
> >
> >
> > >
> > > The error logging for tpm2_commit_space() is in a wrong place. This
> > > commit moves it inside that function.
> > >
> > > Cc: James
>
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo
> struct tpm_output_header.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 9 -
> drivers/char/tpm/tpm.h| 27
>
> Decleare struct tpm_header that replaces struct tpm_input_header and
Typo
> struct tpm_output_header.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 9 -
> drivers/char/tpm/tpm.h| 27
>
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
>
> Cc: James Bottomley
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 2 --
> drivers/char/tpm/tpm2-space.c| 9
>
> The error logging for tpm2_commit_space() is in a wrong place. This commit
> moves it inside that function.
>
> Cc: James Bottomley
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
> drivers/char/tpm/tpm-interface.c | 2 --
> drivers/char/tpm/tpm2-space.c| 9
>
> On Sun, Nov 18, 2018 at 10:52:46PM +, Winkler, Tomas wrote:
> > This is still NACK from my side
>
> Last time you spoke about tboot intervention but I don't see why as even
> sending a single command is not atomic in the true sense of the word i.e. if
> there
>
> On Sun, Nov 18, 2018 at 10:52:46PM +, Winkler, Tomas wrote:
> > This is still NACK from my side
>
> Last time you spoke about tboot intervention but I don't see why as even
> sending a single command is not atomic in the true sense of the word i.e. if
> there
>
> Call tpm_chip_start() and tpm_chip_stop() in
>
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
>
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
>
> Call tpm_chip_start() and tpm_chip_stop() in
>
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
>
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
>
> [was Detach TPM space code out of the tpm_transmit() flow but the scope
> expanded a bit.]
I believe you making this series artificially large we can merge the first 4
patches and leave the rest for further discussion.
Thanks
Tomas
>
> [was Detach TPM space code out of the tpm_transmit() flow but the scope
> expanded a bit.]
I believe you making this series artificially large we can merge the first 4
patches and leave the rest for further discussion.
Thanks
Tomas
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 13, 2018 13:12
> To: Winkler, Tomas
> Cc: linux-integr...@vger.kernel.org; linux-security-mod...@vger.kernel.org;
> James Bottomley ; Struk,
> Ta
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 13, 2018 13:12
> To: Winkler, Tomas
> Cc: linux-integr...@vger.kernel.org; linux-security-mod...@vger.kernel.org;
> James Bottomley ; Struk,
> Ta
>
> On Thu, Nov 08, 2018 at 06:38:59PM +, Winkler, Tomas wrote:
> > > Call tpm_chip_start() and tpm_chip_stop() in
> > >
> > > * tpm_try_get_ops() and tpm_put_ops()
> > > * tpm_chip_register()
> > > * tpm2_del_space()
> > >
>
>
> On Thu, Nov 08, 2018 at 06:38:59PM +, Winkler, Tomas wrote:
> > > Call tpm_chip_start() and tpm_chip_stop() in
> > >
> > > * tpm_try_get_ops() and tpm_put_ops()
> > > * tpm_chip_register()
> > > * tpm2_del_space()
> > >
>
> Call tpm_chip_start() and tpm_chip_stop() in
>
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
>
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
>
> Call tpm_chip_start() and tpm_chip_stop() in
>
> * tpm_try_get_ops() and tpm_put_ops()
> * tpm_chip_register()
> * tpm2_del_space()
>
> And remove these calls from tpm_transmit(). The core reason for this change
> is that in tpm_vtpm_proxy a locality change requires a virtual TPM command
>
>
> Move tpm_validate_command() to tpm2-space.c and make it part of the
> tpm2_prepare_space() flow. Make cc resolution as part of the TPM space
> functionality in order to detach it from rest of the tpm_transmit() flow.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
>
>
> Move tpm_validate_command() to tpm2-space.c and make it part of the
> tpm2_prepare_space() flow. Make cc resolution as part of the TPM space
> functionality in order to detach it from rest of the tpm_transmit() flow.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> ---
>
> Subject: [PATCH 0/8] Detach TPM space code out of the tpm_transmit() flow
You forgot to version your posts this should be V2 in the subject, right?
Thanks
Tomas
> Make the changes that are needed to detach TPM space code from
> tpm_transmit() flow so that we do no longer need nested
> Subject: [PATCH 0/8] Detach TPM space code out of the tpm_transmit() flow
You forgot to version your posts this should be V2 in the subject, right?
Thanks
Tomas
> Make the changes that are needed to detach TPM space code from
> tpm_transmit() flow so that we do no longer need nested
>
> On Tue, 23 Oct 2018, Winkler, Tomas wrote:
> > To the out label we jump after we are done with locality and cmd
> > read() before we jump to locality 'locality'. We will need to add
> > another variable to check If cmd_ready() was called or not in order to
> &g
>
> On Tue, 23 Oct 2018, Winkler, Tomas wrote:
> > To the out label we jump after we are done with locality and cmd
> > read() before we jump to locality 'locality'. We will need to add
> > another variable to check If cmd_ready() was called or not in order to
> &g
>
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > The TPM specs defines PCR index as a positive number, and there is no
> > reason to use a signed number. It is also a possible security issue as
> > currently no functions check for a negative index, which may become a
> > large number when
>
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > The TPM specs defines PCR index as a positive number, and there is no
> > reason to use a signed number. It is also a possible security issue as
> > currently no functions check for a negative index, which may become a
> > large number when
>
>
> On Sat, 20 Oct 2018, Winkler, Tomas wrote:
>
> >>
> >> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >>>> -Original Message-
> >>>> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >>>>
>
>
> On Sat, 20 Oct 2018, Winkler, Tomas wrote:
>
> >>
> >> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >>>> -Original Message-
> >>>> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >>>>
>
> On Mon, 22 Oct 2018, Winkler, Tomas wrote:
> >> This is the list of patches (assuming that I didn't miss anything)
> >> that still need tested-by tags:
> >
> > Those are just code movements, we are running them form months on our
> > systems.
&
>
> On Mon, 22 Oct 2018, Winkler, Tomas wrote:
> >> This is the list of patches (assuming that I didn't miss anything)
> >> that still need tested-by tags:
> >
> > Those are just code movements, we are running them form months on our
> > systems.
&
>
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > This patch series provides initial separation of tpm 1.x and tpm 2.x
> > commands, in foresight that the tpm 1.x chips will eventually phase
> > out and can be compiled out for modern systems.
> > A new file is added tpm1-cmd.c that contains tpm
>
> On Fri, 19 Oct 2018, Tomas Winkler wrote:
> > This patch series provides initial separation of tpm 1.x and tpm 2.x
> > commands, in foresight that the tpm 1.x chips will eventually phase
> > out and can be compiled out for modern systems.
> > A new file is added tpm1-cmd.c that contains tpm
>
> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >> -Original Message-
> >> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >> Sent: Thursday, October 18, 2018 03:15
> >> To: Winkler, Tomas
> >> Cc: Jarkko Sakkinen
>
> On Thu, 18 Oct 2018, Winkler, Tomas wrote:
> >> -Original Message-
> >> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> >> Sent: Thursday, October 18, 2018 03:15
> >> To: Winkler, Tomas
> >> Cc: Jarkko Sakkinen
On Fri, 2018-10-19 at 10:14 +0530, Nayna Jain wrote:
>
> On 10/17/2018 10:02 PM, Tomas Winkler wrote:
> > diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > index caa86b19c76d..f74f451baf6a 100644
> > --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > +++
On Fri, 2018-10-19 at 10:14 +0530, Nayna Jain wrote:
>
> On 10/17/2018 10:02 PM, Tomas Winkler wrote:
> > diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > index caa86b19c76d..f74f451baf6a 100644
> > --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > +++
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Thursday, October 18, 2018 03:15
> To: Winkler, Tomas
> Cc: Jarkko Sakkinen ; Jason Gunthorpe
> ; Nayna Jain ; Usyskin,
> Alexander ; Struk, Tadeusz
> ; linux-integr..
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Thursday, October 18, 2018 03:15
> To: Winkler, Tomas
> Cc: Jarkko Sakkinen ; Jason Gunthorpe
> ; Nayna Jain ; Usyskin,
> Alexander ; Struk, Tadeusz
> ; linux-integr..
1 - 100 of 858 matches
Mail list logo
