Re: [PATCH] tpm, tpm_tis: fix TPM 2.0 probing

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

.exit.text section in vmlinux ?

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?

Re: Conversion of w83627ehf to hwmon_device_register_with_info ?

> > 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

Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

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

Re: Conversion of w83627ehf to hwmon_device_register_with_info ?

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

Conversion of w83627ehf to hwmon_device_register_with_info ?

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

Question about hwmon_attr_show_string

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

Re: [PATCH 03/10] sysfs: added __compat_only_sysfs_link_entry_to_kobj()

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. > >

Re: [PATCH 01/10] tpm, tpm_crb: fix unaligned read of the command buffer address

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)) <<

Re: [PATCH 06/10] tpm: introduce tpm_buf

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

Re: [tpmdd-devel] [PATCH 3/4] tpm: Convert tpm_tis driver to use dev_pm_ops from legacy pm_ops

Hi, thanks for your patch > static struct pnp_device_id tpm_pnp_tbl[] = { > {"PNP0C31", 0}, /* TPM */ > {"ATM1200", 0}, /* Atmel */ > @@ -835,9 +834,12 @@ static struct pnp_driver tis_pnp_driver = { > .name = "tpm_tis", > .id_table = tpm_pnp_tbl, >

Re: [tpmdd-devel] [PATCH 3/4] tpm: Convert tpm_tis driver to use dev_pm_ops from legacy pm_ops

Hi Shuah, thanks for your reply. > >> +#ifdef CONFIG_PM_SLEEP > >> + .driver = { > >> + .pm = _tis_pm, > >> + }, > >> +#endif > >> > >> }; > > > > I don't think the #if CONFIG_PM_SLEEP is required here. In this case, the SIMPLE_DEV_PM_OPS macro handles the case internally - i.e.

Re: [PATCH 01/13] tpm: ibmvtpm: Use %zd formatting for size_t format arguments

Am Montag, 23. September 2013, 20:14:31 schrieb Jason Gunthorpe: > This suppresses compile warnings on 32 bit builds. > > Signed-off-by: Jason Gunthorpe Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Staged here https://github.com/PeterHuewe/linux-tpmdd for-james -- To unsubscribe

Re: [tpmdd-devel] [PATCH 07/13] tpm: Remove tpm_show_caps_1_2

Hi Jason, Am Mittwoch, 2. Oktober 2013, 00:21:13 schrieb Jason Gunthorpe: > On Wed, Oct 02, 2013 at 12:09:22AM +0200, Peter H?we wrote: > >Since the tpm_spi_stm_st33, tpm_i2c_nuvoton and tpm_i2c_atmel drivers > >are not yet merged and were heavily improved by you anyway, please > >

Re: [PATCH 08/13] tpm: Pull everything related to /dev/tpmX into tpm-dev.c

Am Montag, 23. September 2013, 20:14:38 schrieb Jason Gunthorpe: > CLASS-dev.c is a common idiom for Linux subsystems > > This pulls all the code related to the miscdev into tpm-dev.c and makes it > static. The identical file_operation structs in the drivers are purged and > the tpm common code

Re: [PATCH 08/13] tpm: Pull everything related to /dev/tpmX into tpm-dev.c

Am Mittwoch, 2. Oktober 2013, 00:57:33 schrieb Jason Gunthorpe: > > When compiling the tpm drivers as modules I get > > ERROR: "tpm_sysfs_del_device" [drivers/char/tpm/tpm.ko] undefined! > > ERROR: "tpm_dev_add_device" [drivers/char/tpm/tpm.ko] undefined! > > ERROR: "tpm_dev_del_device"

TPM.ko module rename (was tpm: Pull everything related to /dev/tpmX into tpm-dev.c)

Am Donnerstag, 3. Oktober 2013, 07:05:04 schrieb Jason Gunthorpe: > On Wed, Oct 02, 2013 at 01:14:18AM +0200, Peter H?we wrote: > > > I botched the makefile changes for the new .c files. > > > > > > I believe it should be like this: > > > > > > obj-$(CONFIG_TCG_TPM) += tpm-core.o > > >

Re: [tpmdd-devel] [PATCH 09/13] tpm: Pull everything related to sysfs into tpm-sysfs.c

Am Freitag, 4. Oktober 2013, 21:17:36 schrieb Stefan Berger: > On 10/04/2013 01:08 PM, Jason Gunthorpe wrote: > > On Mon, Sep 30, 2013 at 05:09:51PM -0500, Joel Schopp wrote: > >>> So far, nobody I have talked to has offered any strong opinions on > >>> what locality should be used or how it

<    1   2   3