This is of course v2 of the series
Forgot to add it to git-send-email, sorry.
Shall I resend with v2 in subject?
Peter
This is of course v2 of the series
Forgot to add it to git-send-email, sorry.
Shall I resend with v2 in subject?
Peter
> > It saves about 20k in compiled size, so the savings from reduced
> > boilerplate are huge. (and I think it's more readable)
> >
> >> I would suggest to drop nct6775/nct6776 support to simplify the
> >> code when you do that. Maybe as separate commit, though.
> >
> > Hehe - I'm testing on a
> > It saves about 20k in compiled size, so the savings from reduced
> > boilerplate are huge. (and I think it's more readable)
> >
> >> I would suggest to drop nct6775/nct6776 support to simplify the
> >> code when you do that. Maybe as separate commit, though.
> >
> > Hehe - I'm testing on a
Hi
On Friday 03 March 2017 03:56:01 Guenter Roeck wrote:
> Hi Peter,
>
> On 03/02/2017 04:33 PM, Peter Hüwe wrote:
> > Hi,
> >
> > is anybody else working on the conversion of the w83627ehf to the new
> > hwmon_device_register_with_info interface?
>
&g
Hi
On Friday 03 March 2017 03:56:01 Guenter Roeck wrote:
> Hi Peter,
>
> On 03/02/2017 04:33 PM, Peter Hüwe wrote:
> > Hi,
> >
> > is anybody else working on the conversion of the w83627ehf to the new
> > hwmon_device_register_with_info interface?
>
&g
Hi Guenter,
I was wondering whether there was a particular reason why
hwmon_attr_show_string passes only an "empty" pointer(pointer) to the ops-
>read_string function rather than the buffer itself?
Wouldn't this mean that in ops->read_string I'd have to reserve some space for
the value on the
Hi Guenter,
I was wondering whether there was a particular reason why
hwmon_attr_show_string passes only an "empty" pointer(pointer) to the ops-
>read_string function rather than the buffer itself?
Wouldn't this mean that in ops->read_string I'd have to reserve some space for
the value on the
Hi,
is anybody else working on the conversion of the w83627ehf to the new
hwmon_device_register_with_info interface?
Otherwise I will probably update the driver to this interface within the next
days - but since it's a lot of work I wanted to check for duplication first.
Do you think it
Hi,
is anybody else working on the conversion of the w83627ehf to the new
hwmon_device_register_with_info interface?
Otherwise I will probably update the driver to this interface within the next
days - but since it's a lot of work I wanted to check for duplication first.
Do you think it
Am Freitag, 16. Oktober 2015, 20:40:25 schrieb Jarkko Sakkinen:
> This patch introduces struct tpm_buf that provides a string buffer for
> constructing TPM commands. This allows to construct variable sized TPM
> commands. For the buffer a page is allocated and mapped, which limits
> maximum size
Am Freitag, 16. Oktober 2015, 20:40:20 schrieb Jarkko Sakkinen:
> + pa = ((u64) le32_to_cpu(ioread32(>cca->cmd_pa_high)) << 32) +
> + (u64) le32_to_cpu(ioread32(>cca->cmd_pa_low));
The canonical form would be
> + pa = ((u64) le32_to_cpu(ioread32(>cca->cmd_pa_high)) <<
Am Freitag, 16. Oktober 2015, 20:40:22 schrieb Jarkko Sakkinen:
> Added a new function __compat_only_sysfs_link_group_to_kobj() that adds
> a symlink from attribute or group to a kobject. This needed for
> maintaining backwards compatibility with PPI attributes in the TPM
> driver.
>
>
Am Freitag, 16. Oktober 2015, 20:40:22 schrieb Jarkko Sakkinen:
> Added a new function __compat_only_sysfs_link_group_to_kobj() that adds
> a symlink from attribute or group to a kobject. This needed for
> maintaining backwards compatibility with PPI attributes in the TPM
> driver.
>
>
Am Freitag, 16. Oktober 2015, 20:40:20 schrieb Jarkko Sakkinen:
> + pa = ((u64) le32_to_cpu(ioread32(>cca->cmd_pa_high)) << 32) +
> + (u64) le32_to_cpu(ioread32(>cca->cmd_pa_low));
The canonical form would be
> + pa = ((u64) le32_to_cpu(ioread32(>cca->cmd_pa_high)) <<
Am Freitag, 16. Oktober 2015, 20:40:25 schrieb Jarkko Sakkinen:
> This patch introduces struct tpm_buf that provides a string buffer for
> constructing TPM commands. This allows to construct variable sized TPM
> commands. For the buffer a page is allocated and mapped, which limits
> maximum size
Am Montag, 24. August 2015, 21:07:32 schrieb Hon Ching(Vicky) Lo:
> Hi Peter,
>
>
> Did you the explanations in the following reply make sense to you?
> If you needed more clarifications, please advice. Thanks!
I trust your explanations - I just haven't gotten around to apply them.
Sorry about
Am Montag, 24. August 2015, 21:07:32 schrieb Hon Ching(Vicky) Lo:
Hi Peter,
Did you the explanations in the following reply make sense to you?
If you needed more clarifications, please advice. Thanks!
I trust your explanations - I just haven't gotten around to apply them.
Sorry about that
Hi Vicky,
Am Donnerstag, 16. Juli 2015, 19:54:15 schrieb Hon Ching(Vicky) Lo:
> Hi Peter,
>
> On Mon, 2015-07-13 at 23:08 +0200, Peter Hüwe wrote:
> > Hi Vicky,
> >
> > sorry for the late reply
> >
> > > This patch makes the code endian
Hi Vicky,
Am Donnerstag, 16. Juli 2015, 19:54:15 schrieb Hon Ching(Vicky) Lo:
Hi Peter,
On Mon, 2015-07-13 at 23:08 +0200, Peter Hüwe wrote:
Hi Vicky,
sorry for the late reply
This patch makes the code endianness independent. We defined a
macro do_endian_conversion to apply
Am Freitag, 10. Juli 2015, 07:32:28 schrieb Krzysztof Kozlowski:
> Hi,
>
>
> The i2c drivers also do not have to set 'owner' field because
> i2c_register_driver() will do it instead.
>
> 'owner' is removed from i2c drivers, which I was able to compile
> with allyesconfig (arm, arm64, i386,
Am Mittwoch, 24. Juni 2015, 16:14:55 schrieb Jarkko Sakkinen:
> At least some versions of AMI BIOS have corrupted contents in the TPM2
> ACPI table and namely the physical address of the control area is set to
> zero.
>
> This patch changes the driver to fail gracefully when we observe a zero
>
Hi Vicky,
sorry for the late reply
> This patch makes the code endianness independent. We defined a
> macro do_endian_conversion to apply endianness to raw integers
> in the event entries so that they will be displayed properly.
> tpm_binary_bios_measurements_show() is modified for the display.
Am Mittwoch, 24. Juni 2015, 16:14:55 schrieb Jarkko Sakkinen:
At least some versions of AMI BIOS have corrupted contents in the TPM2
ACPI table and namely the physical address of the control area is set to
zero.
This patch changes the driver to fail gracefully when we observe a zero
Hi Vicky,
sorry for the late reply
This patch makes the code endianness independent. We defined a
macro do_endian_conversion to apply endianness to raw integers
in the event entries so that they will be displayed properly.
tpm_binary_bios_measurements_show() is modified for the display.
Am Freitag, 10. Juli 2015, 07:32:28 schrieb Krzysztof Kozlowski:
Hi,
The i2c drivers also do not have to set 'owner' field because
i2c_register_driver() will do it instead.
'owner' is removed from i2c drivers, which I was able to compile
with allyesconfig (arm, arm64, i386, x86_64,
Hi Jarkko
> > > >Betreff: [PATCH] tpm, tpm_crb: migrate to struct acpi_table_tpm2 and
> > > >acpi_tpm2_control
> > > but are the names there still correct? Isn't this information outdated?
> > > The acpi spec refers to the MS spec which is not present anymore, and
> > > MS refers to the TCG --
Hey,
Am Freitag, 22. Mai 2015, 19:23:02 schrieb Hon Ching(Vicky) Lo:
> tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
> set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
> the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.
>
Hey,
Am Freitag, 22. Mai 2015, 19:23:02 schrieb Hon Ching(Vicky) Lo:
tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm-vdev-unit_address.
Hi Jarkko
Betreff: [PATCH] tpm, tpm_crb: migrate to struct acpi_table_tpm2 and
acpi_tpm2_control
but are the names there still correct? Isn't this information outdated?
The acpi spec refers to the MS spec which is not present anymore, and
MS refers to the TCG -- and in the PTP your
Hi,
Am Mittwoch, 3. Juni 2015, 18:39:14 schrieb Jarkko Sakkinen:
> This patch introduces struct tpm_buf that provides a string buffer for
> constructing TPM commands. This allows to construct variable sized TPM
> commands. This feature is needed for TPM 2.0 commands in order to allow
> policy
Hi,
Am Mittwoch, 3. Juni 2015, 18:39:14 schrieb Jarkko Sakkinen:
This patch introduces struct tpm_buf that provides a string buffer for
constructing TPM commands. This allows to construct variable sized TPM
commands. This feature is needed for TPM 2.0 commands in order to allow
policy
Am Dienstag, 5. Mai 2015, 18:32:19 schrieb Geert Uytterhoeven:
> The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
> not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
> functionality only, can still be compiled if GPIOLIB is not enabled.
>
> Relax the
Am Dienstag, 5. Mai 2015, 18:32:19 schrieb Geert Uytterhoeven:
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.
Relax the
Am Montag, 30. März 2015, 22:06:08 schrieb Fabian Frederick:
> KERN_ERR is implicitely declared in pr_err()
>
> Signed-off-by: Fabian Frederick
Good catch.
Acked-by: Peter Huewe
If nobody else pulls this one through his tree, I'll apply it probably for
4._2_ (so it might take a while)
Peter
Am Montag, 30. März 2015, 22:06:08 schrieb Fabian Frederick:
KERN_ERR is implicitely declared in pr_err()
Signed-off-by: Fabian Frederick f...@skynet.be
Good catch.
Acked-by: Peter Huewe peterhu...@gmx.de
If nobody else pulls this one through his tree, I'll apply it probably for
4._2_ (so it
Am Sonntag, 1. März 2015, 22:55:47 schrieb Jarkko Sakkinen:
> - tpm_dev_add_device(): cdev_add() must be done before uevent is
> propagated in order to avoid races.
> - tpm_chip_register(): tpm_dev_add_device() must be done as the
> last step before exposing device to the user space in order
Am Sonntag, 1. März 2015, 22:55:47 schrieb Jarkko Sakkinen:
- tpm_dev_add_device(): cdev_add() must be done before uevent is
propagated in order to avoid races.
- tpm_chip_register(): tpm_dev_add_device() must be done as the
last step before exposing device to the user space in order to
Am Mittwoch, 4. Februar 2015, 15:21:09 schrieb Jarkko Sakkinen:
> If during transmission system error was returned, the logic was to
> incorrectly deduce that chip is a TPM 1.x chip. This patch fixes this
> issue. Also, this patch changes probing so that message tag is used as the
> measure for
Am Mittwoch, 4. Februar 2015, 15:21:09 schrieb Jarkko Sakkinen:
If during transmission system error was returned, the logic was to
incorrectly deduce that chip is a TPM 1.x chip. This patch fixes this
issue. Also, this patch changes probing so that message tag is used as the
measure for TPM
Hi Bruno,
thanks for your patch!
The patch is fine,
but unfortunately not against the latest version of the tpm subsytem code.
You can find the latest version of the tpm subsystem at
https://github.com/PeterHuewe/linux-tpmdd
the for-james branch is usually the best choice here.
Hi Bruno,
thanks for your patch!
The patch is fine,
but unfortunately not against the latest version of the tpm subsytem code.
You can find the latest version of the tpm subsystem at
https://github.com/PeterHuewe/linux-tpmdd
the for-james branch is usually the best choice here.
Am Donnerstag, 4. Dezember 2014, 06:55:16 schrieb Jarkko Sakkinen:
> TPM 2.0 devices are separated by adding a field 'flags' to struct
> tpm_chip and defining a flag TPM_CHIP_FLAG_TPM2 for tagging them.
>
> This patch adds the following internal functions:
>
> - tpm2_get_random()
> -
Am Mittwoch, 3. Dezember 2014, 03:28:35 schrieb Stefan Berger:
> On 12/02/2014 05:31 PM, Jarkko Sakkinen wrote:
> > +
> > +/**
> > + * tpm2_startup() - send startup command to the TPM chip
> > + * @chip: TPM chip to use.
> > + * @startup_type startup type. The value is either
> > + *
Am Donnerstag, 4. Dezember 2014, 06:55:17 schrieb Jarkko Sakkinen:
> tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
> as defined in PC Client Platform TPM Profile (PTP) Specification.
>
> Only polling and single locality is supported as these are the limitations
> of the
Am Donnerstag, 4. Dezember 2014, 23:18:33 schrieb Peter Hüwe:
> Hi Jarkko,
>
> Am Donnerstag, 4. Dezember 2014, 06:55:18 schrieb Jarkko Sakkinen:
> > From: Will Arthur
> >
> > Detect TPM 2.0 by using the extended STS (STS3) register. For TPM 2.0,
> > in
Hi Jarkko,
Am Donnerstag, 4. Dezember 2014, 06:55:18 schrieb Jarkko Sakkinen:
> From: Will Arthur
>
> Detect TPM 2.0 by using the extended STS (STS3) register. For TPM 2.0,
> instead of calling tpm_get_timeouts(), assign duration and timeout
> values defined in the TPM 2.0 PTP specification.
>
Am Donnerstag, 4. Dezember 2014, 06:55:18 schrieb Jarkko Sakkinen:
> From: Will Arthur
>
> Detect TPM 2.0 by using the extended STS (STS3) register. For TPM 2.0,
> instead of calling tpm_get_timeouts(), assign duration and timeout
> values defined in the TPM 2.0 PTP specification.
>
>
Am Donnerstag, 4. Dezember 2014, 06:55:14 schrieb Jarkko Sakkinen:
> Rename chip->dev to chip->pdev to make it explicit that this not the
> character device but actually represents the platform device.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm-chip.c | 4 ++--
>
Am Donnerstag, 4. Dezember 2014, 06:55:13 schrieb Jarkko Sakkinen:
> Traversal of the ACPI device tree was not done right. PPI interface
> should be looked up only from the ACPI device that is the platform
> device for the TPM. This could cause problems with systems with
> two TPM chips such as
Am Donnerstag, 4. Dezember 2014, 06:55:17 schrieb Jarkko Sakkinen:
> tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
> as defined in PC Client Platform TPM Profile (PTP) Specification.
>
> Only polling and single locality is supported as these are the limitations
> of the
Am Donnerstag, 4. Dezember 2014, 06:55:17 schrieb Jarkko Sakkinen:
tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
as defined in PC Client Platform TPM Profile (PTP) Specification.
Only polling and single locality is supported as these are the limitations
of the
Am Donnerstag, 4. Dezember 2014, 06:55:13 schrieb Jarkko Sakkinen:
Traversal of the ACPI device tree was not done right. PPI interface
should be looked up only from the ACPI device that is the platform
device for the TPM. This could cause problems with systems with
two TPM chips such as 4th
Am Donnerstag, 4. Dezember 2014, 06:55:14 schrieb Jarkko Sakkinen:
Rename chip-dev to chip-pdev to make it explicit that this not the
character device but actually represents the platform device.
Signed-off-by: Jarkko Sakkinen jarkko.sakki...@linux.intel.com
---
drivers/char/tpm/tpm-chip.c
Am Donnerstag, 4. Dezember 2014, 06:55:18 schrieb Jarkko Sakkinen:
From: Will Arthur will.c.art...@intel.com
Detect TPM 2.0 by using the extended STS (STS3) register. For TPM 2.0,
instead of calling tpm_get_timeouts(), assign duration and timeout
values defined in the TPM 2.0 PTP
Hi Jarkko,
Am Donnerstag, 4. Dezember 2014, 06:55:18 schrieb Jarkko Sakkinen:
From: Will Arthur will.c.art...@intel.com
Detect TPM 2.0 by using the extended STS (STS3) register. For TPM 2.0,
instead of calling tpm_get_timeouts(), assign duration and timeout
values defined in the TPM 2.0 PTP
Am Donnerstag, 4. Dezember 2014, 23:18:33 schrieb Peter Hüwe:
Hi Jarkko,
Am Donnerstag, 4. Dezember 2014, 06:55:18 schrieb Jarkko Sakkinen:
From: Will Arthur will.c.art...@intel.com
Detect TPM 2.0 by using the extended STS (STS3) register. For TPM 2.0,
instead of calling
Am Donnerstag, 4. Dezember 2014, 06:55:17 schrieb Jarkko Sakkinen:
tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
as defined in PC Client Platform TPM Profile (PTP) Specification.
Only polling and single locality is supported as these are the limitations
of the
Am Mittwoch, 3. Dezember 2014, 03:28:35 schrieb Stefan Berger:
On 12/02/2014 05:31 PM, Jarkko Sakkinen wrote:
+
+/**
+ * tpm2_startup() - send startup command to the TPM chip
+ * @chip: TPM chip to use.
+ * @startup_type startup type. The value is either
+ *
Am Donnerstag, 4. Dezember 2014, 06:55:16 schrieb Jarkko Sakkinen:
TPM 2.0 devices are separated by adding a field 'flags' to struct
tpm_chip and defining a flag TPM_CHIP_FLAG_TPM2 for tagging them.
This patch adds the following internal functions:
- tpm2_get_random()
- tpm2_get_tpm_pt()
Am Mittwoch, 3. Dezember 2014, 00:24:43 schrieb Aaro Koskinen:
> Hi,
>
> On Wed, Dec 03, 2014 at 12:21:07AM +0100, Peter Hüwe wrote:
> > --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > @@ -605,10 +605,8 @@ static int i2c_nuvo
Am Mittwoch, 3. Dezember 2014, 00:16:19 schrieb Peter Hüwe:
> Am Dienstag, 2. Dezember 2014, 23:31:12 schrieb Jarkko Sakkinen:
> > This patch set enables TPM2 protocol and provides drivers for FIFO and
> > CRB interfaces. This patch set does not export any sysfs attributes for
>
Am Dienstag, 2. Dezember 2014, 23:31:12 schrieb Jarkko Sakkinen:
> This patch set enables TPM2 protocol and provides drivers for FIFO and
> CRB interfaces. This patch set does not export any sysfs attributes for
> TPM 2.0 because existing sysfs attributes have three non-trivial issues:
>
> - They
Am Dienstag, 2. Dezember 2014, 23:31:19 schrieb Jarkko Sakkinen:
> tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
> as defined in PC Client Platform TPM Profile (PTP) Specification.
>
> Only polling and single locality is supported as these are the limitations
> of the
Hi Jarkko,
Am Dienstag, 2. Dezember 2014, 23:31:12 schrieb Jarkko Sakkinen:
> This patch set enables TPM2 protocol and provides drivers for FIFO and
> CRB interfaces. This patch set does not export any sysfs attributes for
> TPM 2.0 because existing sysfs attributes have three non-trivial
Am Freitag, 19. September 2014, 09:14:39 schrieb Kiran Padwal:
> Currently these driver are missing a check on the return value of
> devm_kzalloc, which would cause a NULL pointer dereference in a OOM
> situation.
>
> This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c
>
>
Hi Anton,
is this patchset still needed after Vicky's patch
"[tpmdd-devel] Fix NULL return in tpm_ibmvtpm_get_desired_dma"
https://patchwork.ozlabs.org/patch/402315/
Ashley raised some concerns.
Since merge window is coming up, a fast reply is appreciated.
Thanks,
Peter
Am Freitag, 19.
Hi,
so shall I apply this patch? or not?
Thanks,
Peter
Am Dienstag, 2. Dezember 2014, 20:22:35 schrieb Ashley Lai:
> > @@ -63,9 +63,9 @@ static int ibmvtpm_send_crq(struct vio_dev *vdev, u64
> > w1, u64 w2) static struct ibmvtpm_dev *ibmvtpm_get_data(const struct
> > device *dev) {
> >
> >
Hi,
so shall I apply this patch? or not?
Thanks,
Peter
Am Dienstag, 2. Dezember 2014, 20:22:35 schrieb Ashley Lai:
@@ -63,9 +63,9 @@ static int ibmvtpm_send_crq(struct vio_dev *vdev, u64
w1, u64 w2) static struct ibmvtpm_dev *ibmvtpm_get_data(const struct
device *dev) {
struct
Hi Anton,
is this patchset still needed after Vicky's patch
[tpmdd-devel] Fix NULL return in tpm_ibmvtpm_get_desired_dma
https://patchwork.ozlabs.org/patch/402315/
Ashley raised some concerns.
Since merge window is coming up, a fast reply is appreciated.
Thanks,
Peter
Am Freitag, 19.
Am Freitag, 19. September 2014, 09:14:39 schrieb Kiran Padwal:
Currently these driver are missing a check on the return value of
devm_kzalloc, which would cause a NULL pointer dereference in a OOM
situation.
This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c
Hi Jarkko,
Am Dienstag, 2. Dezember 2014, 23:31:12 schrieb Jarkko Sakkinen:
This patch set enables TPM2 protocol and provides drivers for FIFO and
CRB interfaces. This patch set does not export any sysfs attributes for
TPM 2.0 because existing sysfs attributes have three non-trivial issues:
Am Dienstag, 2. Dezember 2014, 23:31:19 schrieb Jarkko Sakkinen:
tpm_crb is a driver for TPM 2.0 Command Response Buffer (CRB) Interface
as defined in PC Client Platform TPM Profile (PTP) Specification.
Only polling and single locality is supported as these are the limitations
of the
Am Dienstag, 2. Dezember 2014, 23:31:12 schrieb Jarkko Sakkinen:
This patch set enables TPM2 protocol and provides drivers for FIFO and
CRB interfaces. This patch set does not export any sysfs attributes for
TPM 2.0 because existing sysfs attributes have three non-trivial issues:
- They are
Am Mittwoch, 3. Dezember 2014, 00:16:19 schrieb Peter Hüwe:
Am Dienstag, 2. Dezember 2014, 23:31:12 schrieb Jarkko Sakkinen:
This patch set enables TPM2 protocol and provides drivers for FIFO and
CRB interfaces. This patch set does not export any sysfs attributes for
TPM 2.0 because
Am Mittwoch, 3. Dezember 2014, 00:24:43 schrieb Aaro Koskinen:
Hi,
On Wed, Dec 03, 2014 at 12:21:07AM +0100, Peter Hüwe wrote:
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -605,10 +605,8 @@ static int i2c_nuvoton_probe(struct i2c_client
*client
Hi Scot,
Am Montag, 29. September 2014, 19:24:57 schrieb Jason Gunthorpe:
> On Wed, Sep 24, 2014 at 10:41:10PM +, Scot Doyle wrote:
> > Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
> > not send IRQs while also having an ACPI TPM entry indicating that they
> > will
Applied to my tree:
https://github.com/PeterHuewe/linux-tpmdd for-james
Will be included in the next pull-request.
Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Applied to my tree:
https://github.com/PeterHuewe/linux-tpmdd for-james
Will be included in the next pull-request.
Thanks,
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Scot,
Am Montag, 29. September 2014, 19:24:57 schrieb Jason Gunthorpe:
On Wed, Sep 24, 2014 at 10:41:10PM +, Scot Doyle wrote:
Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
not send IRQs while also having an ACPI TPM entry indicating that they
will be
Hi,
as far as I remember everything marked with __exit or __exit_data will only be
used/called when unloading a module, and gets moved to the .exit.text or
.exit.data sections.
Why are these sections present in the vmlinux/vmlinux.bin/bzImage and not
dropped by the linker or at least objdump?
Hi,
as far as I remember everything marked with __exit or __exit_data will only be
used/called when unloading a module, and gets moved to the .exit.text or
.exit.data sections.
Why are these sections present in the vmlinux/vmlinux.bin/bzImage and not
dropped by the linker or at least objdump?
Am Mittwoch, 24. September 2014, 19:59:40 schrieb Jason Gunthorpe:
> On Wed, Sep 24, 2014 at 01:34:11PM -0400, Stefan Berger wrote:
> > On 09/24/2014 01:13 PM, Jason Gunthorpe wrote:
> > >On Wed, Sep 24, 2014 at 12:06:02PM +0300, Jarkko Sakkinen wrote:
> > >>+static ssize_t durations_show(struct
Am Mittwoch, 24. September 2014, 22:19:38 schrieb Jason Gunthorpe:
> On Wed, Sep 24, 2014 at 10:02:34PM +0300, Jarkko Sakkinen wrote:
> > > The pcrs file never conformed to the sysfs rules, if TPM2 is getting a
> > > whole new file set, I wouldn't mind seeing it not include the
> > >
Am Mittwoch, 24. September 2014, 21:43:23 schrieb Jarkko Sakkinen:
> On Wed, Sep 24, 2014 at 10:53:20AM -0600, Jason Gunthorpe wrote:
> > On Wed, Sep 24, 2014 at 12:05:53PM +0300, Jarkko Sakkinen wrote:
> > > +static struct tpm_input_header tpm2_pcrread_header = {
> >
> > Missing const - all of
Am Mittwoch, 24. September 2014, 19:13:38 schrieb Jason Gunthorpe:
> On Wed, Sep 24, 2014 at 12:06:02PM +0300, Jarkko Sakkinen wrote:
> > Added tpm2-sysfs.c that implements sysfs attributes for a TPM2
> > device.
>
> You need to document in Documentation every new sysfs that is added.
>
> The
Am Mittwoch, 24. September 2014, 19:13:38 schrieb Jason Gunthorpe:
On Wed, Sep 24, 2014 at 12:06:02PM +0300, Jarkko Sakkinen wrote:
Added tpm2-sysfs.c that implements sysfs attributes for a TPM2
device.
You need to document in Documentation every new sysfs that is added.
The existing
Am Mittwoch, 24. September 2014, 21:43:23 schrieb Jarkko Sakkinen:
On Wed, Sep 24, 2014 at 10:53:20AM -0600, Jason Gunthorpe wrote:
On Wed, Sep 24, 2014 at 12:05:53PM +0300, Jarkko Sakkinen wrote:
+static struct tpm_input_header tpm2_pcrread_header = {
Missing const - all of these
Am Mittwoch, 24. September 2014, 22:19:38 schrieb Jason Gunthorpe:
On Wed, Sep 24, 2014 at 10:02:34PM +0300, Jarkko Sakkinen wrote:
The pcrs file never conformed to the sysfs rules, if TPM2 is getting a
whole new file set, I wouldn't mind seeing it not include the
non-conformant ones.
Am Mittwoch, 24. September 2014, 19:59:40 schrieb Jason Gunthorpe:
On Wed, Sep 24, 2014 at 01:34:11PM -0400, Stefan Berger wrote:
On 09/24/2014 01:13 PM, Jason Gunthorpe wrote:
On Wed, Sep 24, 2014 at 12:06:02PM +0300, Jarkko Sakkinen wrote:
+static ssize_t durations_show(struct device
Am Montag, 22. September 2014, 19:13:38 schrieb Jason Gunthorpe:
>
> This does look much nicer, lets use this version.
>
> I think Peter were prefer a new clean patch that superceeds the
> original.
>
> > + if (!priv->irq_tested) {
>
> I think the sleep and check is still needed here, the
Am Montag, 22. September 2014, 19:13:38 schrieb Jason Gunthorpe:
This does look much nicer, lets use this version.
I think Peter were prefer a new clean patch that superceeds the
original.
+ if (!priv-irq_tested) {
I think the sleep and check is still needed here, the IRQ delivery
Hi
Am Samstag, 13. September 2014, 19:35:33 schrieb Jarkko Sakkinen:
> Replaced transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c
> with a single tpm_transmit_cmd() that can be used in both files.
>
> This patch is preliminary clean up work for the TPM2 support. This
> function is
Hi
Am Samstag, 13. September 2014, 19:35:33 schrieb Jarkko Sakkinen:
Replaced transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c
with a single tpm_transmit_cmd() that can be used in both files.
This patch is preliminary clean up work for the TPM2 support. This
function is needed
Am Freitag, 12. September 2014, 21:09:47 schrieb Peter Huewe:
> If adapter->dev.parent == NULL there is a NULL pointer dereference in
> acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.
>
> This is present since introduction of this code:
> 366047515c6e "i2c: rework kernel config
Am Freitag, 12. September 2014, 21:09:47 schrieb Peter Huewe:
If adapter-dev.parent == NULL there is a NULL pointer dereference in
acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler.
This is present since introduction of this code:
366047515c6e i2c: rework kernel config
Hi Scot,
Am Montag, 25. August 2014, 09:14:03 schrieb Scot Doyle:
> commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e
> wait: fix false timeouts when using wait_event_timeout()
>
> changed the semantics of wait_event_interruptible_timeout so that a
> condition check is performed after timeout
Hi Scot,
Am Montag, 25. August 2014, 09:14:03 schrieb Scot Doyle:
commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e
wait: fix false timeouts when using wait_event_timeout()
changed the semantics of wait_event_interruptible_timeout so that a
condition check is performed after timeout and 1
CC: Luigi, he works at Google and is responsible for the TPMs in
Chromebooks ;)
Thanks,
Peter
Am Freitag, 22. August 2014, 22:32:41 schrieb Jason Gunthorpe:
> On Fri, Aug 22, 2014 at 08:17:27PM +, Scot Doyle wrote:
> > On Fri, 22 Aug 2014, Jason Gunthorpe wrote:
> > > On Fri, Aug 22, 2014
CC: Luigi, he works at Google and is responsible for the TPMs in
Chromebooks ;)
Thanks,
Peter
Am Freitag, 22. August 2014, 22:32:41 schrieb Jason Gunthorpe:
On Fri, Aug 22, 2014 at 08:17:27PM +, Scot Doyle wrote:
On Fri, 22 Aug 2014, Jason Gunthorpe wrote:
On Fri, Aug 22, 2014 at
1 - 100 of 218 matches
Mail list logo