Le 24/10/17 à 15:51, Jarkko Sakkinen a écrit :
On Mon, Oct 23, 2017 at 06:45:15AM -0700, Jerry Snitselaar wrote:
On Mon Oct 23 17, Jarkko Sakkinen wrote:
On Sat, Oct 21, 2017 at 10:53:55AM +0200, Laurent Bigonville wrote:
Le 14/10/17 à 10:13, Jerry Snitselaar a écrit :
On Wed Sep 06 17, Jar
Device number (the character device index) is not a stable identifier
for a TPM chip. That is the reason why every call site passes
TPM_ANY_NUM to tpm_chip_find_get().
This commit changes the API in a way that instead a struct tpm_chip
instance is given and NULL means the default chip. In addition
Hi Jarkko,
On 24 October 2017 at 23:52, Jarkko Sakkinen
wrote:
> On Tue, Oct 24, 2017 at 10:05:20PM +0530, PrasannaKumar Muralidharan wrote:
>> > 1. Every user in the kernel is using TPM_ANY_NUM, which means there are
>> >no other users.
>>
>> Completely agree that there is no in kernel users
Hi Jarkko,
On 25 October 2017 at 17:25, Jarkko Sakkinen
wrote:
> Device number (the character device index) is not a stable identifier
> for a TPM chip. That is the reason why every call site passes
> TPM_ANY_NUM to tpm_chip_find_get().
>
> This commit changes the API in a way that instead a stru
On Wed, Oct 25, 2017 at 01:55:04PM +0200, Jarkko Sakkinen wrote:
> Device number (the character device index) is not a stable identifier
> for a TPM chip. That is the reason why every call site passes
> TPM_ANY_NUM to tpm_chip_find_get().
>
> This commit changes the API in a way that instead a str
On Wed, Oct 25, 2017 at 08:21:16PM +0530, PrasannaKumar Muralidharan wrote:
> >> > 2. Moving struct tpm_rng to the TPM client is architecturally
> >> >uacceptable.
> >>
> >> As there was no response to the patch there is no way to know whether
> >> it is acceptable or not.
> >
> > I like the id
On Wed, Oct 25, 2017 at 08:40:26PM +0530, PrasannaKumar Muralidharan wrote:
> > -struct tpm_chip *tpm_chip_find_get(int chip_num)
> > +struct tpm_chip *tpm_chip_find_get(struct tpm_chip *chip)
> > {
> > - struct tpm_chip *chip, *res = NULL;
> > + struct tpm_chip *res = NULL;
> > +
> struct tpm_chip *tpm_chip_find_get(u64 id)
> {
> struct tpm_chup *chip;
> struct tpm_chip *res = NULL;
> int chip_num = 0;
> int chip_prev;
>
> mutex_lock(&idr_lock);
>
> do {
> chip_prev = chip_num;
>
> chip = idr_get_next(&dev_n
On Wed, Oct 25, 2017 at 01:46:33PM -0600, Jason Gunthorpe wrote:
> > struct tpm_chip *tpm_chip_find_get(u64 id)
> > {
> > struct tpm_chup *chip;
> > struct tpm_chip *res = NULL;
> > int chip_num = 0;
> > int chip_prev;
> >
> > mutex_lock(&idr_lock);
> >
> > do {
> >
On Wed, Oct 25, 2017 at 10:07:46PM +0200, Jarkko Sakkinen wrote:
> The id has a nice feature that it is unique for one boot cycle you can
> even try to get a chip that has been deleted. It has the most stable
> properties in the long run.
It isn't unique, we can re-use ids them via idr_alloc(). W
10 matches
Mail list logo
