Intel NUC and fTPM issue on 4.9.2

Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

[-- Attachment #1.1: Type: text/plain, Size: 691 bytes --]

Hello guys,
I am trying to get the fTPM on an Intel NUC working bit I get this error

[    3.191376] tpm_crb MSFT0101:00: can't request region for resource [mem
0xfed40080-0xfed40fff]

[    3.200378] tpm_crb: probe of MSFT0101:00 failed with error -16

and, of course, the TPM device is not registered in dev/sysfs

In my understanding this is a regression as it has been already fixed in
the past and merged in 4.7 or 4.8.
I also verified my source and tpm_crb.c contains this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=422eac3f7deae34dbaffd08e03e27f37a5394a56

Is that a known issue? If so, are there workaround/patches?

Thanks in advance,
 Davide.

[-- Attachment #1.2: Type: text/html, Size: 1606 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jason Gunthorpe]

On Thu, Feb 16, 2017 at 11:15:41AM +0000, Davide Guerri wrote:
>    Hello guys,
>    I am trying to get the fTPM on an Intel NUC working bit I get this
>    error
> 
>    [ 3.191376] tpm_crb MSFT0101:00: can't request region for resource
>    [mem 0xfed40080-0xfed40fff]

What does /proc/iomem say?

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

[-- Attachment #1.1: Type: text/plain, Size: 677 bytes --]

Hey thanks for the prompt reply.

I think you are interested in this:

  fed40000-fed4087f : MSFT0101:00


Thanks!

On 16 February 2017 at 18:01, Jason Gunthorpe <
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:

> On Thu, Feb 16, 2017 at 11:15:41AM +0000, Davide Guerri wrote:
> >    Hello guys,
> >    I am trying to get the fTPM on an Intel NUC working bit I get this
> >    error
> >
> >    [ 3.191376] tpm_crb MSFT0101:00: can't request region for resource
> >    [mem 0xfed40080-0xfed40fff]
>
> What does /proc/iomem say?
>
> Jason
>



-- 


[image: Davide Guerri on about.me]

Davide Guerri
about.me/davide_guerri
  <http://about.me/davide_guerri>

[-- Attachment #1.2: Type: text/html, Size: 3013 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jason Gunthorpe]

On Thu, Feb 16, 2017 at 06:10:43PM +0000, Davide Guerri wrote:
>    Hey thanks for the prompt reply.
>    I think you are interested in this:
>       fed40000-fed4087f : MSFT0101:00

Are there more lines below that?

Can you apply this patch and report what the results are?

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index a7c870af916c3d..acc54a03d6025d 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
 		.flags	= IORESOURCE_MEM,
 	};
 
+	printk("map request is is %pr\n",&new_res);
+
 	/* Detect a 64 bit address on a 32 bit system */
 	if (start != new_res.start)
 		return (void __iomem *) ERR_PTR(-EINVAL);
@@ -267,6 +269,8 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 		return -EINVAL;
 	}
 
+	printk("ACPI resource is %pr\n",&io_res);
+
 	priv->iobase = devm_ioremap_resource(dev, &io_res);
 	if (IS_ERR(priv->iobase))
 		return PTR_ERR(priv->iobase);

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

[-- Attachment #1.1: Type: text/plain, Size: 1957 bytes --]

No lines including the requested range:

fed10000-fed17fff : pnp 00:06

fed18000-fed18fff : pnp 00:06

fed19000-fed19fff : pnp 00:06

fed20000-fed3ffff : pnp 00:06

fed40000-fed4087f : MSFT0101:00

fed45000-fed8ffff : pnp 00:06

fed90000-fed93fff : pnp 00:06

fee00000-fee00fff : Local APIC

This is the NUC I am using, if that can be useful.

root@vhsv1:~# cat /sys/class/dmi/id/board_name
/sys/class/dmi/id/board_version

NUC6i7KYB

H90766-404

I am compiling the module right as we speak, I will get back to you soon.

On 16 February 2017 at 18:19, Jason Gunthorpe <
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:

> On Thu, Feb 16, 2017 at 06:10:43PM +0000, Davide Guerri wrote:
> >    Hey thanks for the prompt reply.
> >    I think you are interested in this:
> >       fed40000-fed4087f : MSFT0101:00
>
> Are there more lines below that?
>
> Can you apply this patch and report what the results are?
>
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index a7c870af916c3d..acc54a03d6025d 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev,
> struct crb_priv *priv,
>                 .flags  = IORESOURCE_MEM,
>         };
>
> +       printk("map request is is %pr\n",&new_res);
> +
>         /* Detect a 64 bit address on a 32 bit system */
>         if (start != new_res.start)
>                 return (void __iomem *) ERR_PTR(-EINVAL);
> @@ -267,6 +269,8 @@ static int crb_map_io(struct acpi_device *device,
> struct crb_priv *priv,
>                 return -EINVAL;
>         }
>
> +       printk("ACPI resource is %pr\n",&io_res);
> +
>         priv->iobase = devm_ioremap_resource(dev, &io_res);
>         if (IS_ERR(priv->iobase))
>                 return PTR_ERR(priv->iobase);
>



-- 


[image: Davide Guerri on about.me]

Davide Guerri
about.me/davide_guerri
  <http://about.me/davide_guerri>

[-- Attachment #1.2: Type: text/html, Size: 5993 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

[-- Attachment #1.1: Type: text/plain, Size: 2599 bytes --]

[20417.678975] map request is is [mem 0xfed40040-0xfed4006f flags 0x200]

[20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]

[20417.678996] tpm_crb MSFT0101:00: can't request region for resource [mem
0xfed40080-0xfed40fff]

[20417.688797] tpm_crb: probe of MSFT0101:00 failed with error -16



On 16 February 2017 at 18:26, Davide Guerri <davide.guerri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> No lines including the requested range:
>
> fed10000-fed17fff : pnp 00:06
>
> fed18000-fed18fff : pnp 00:06
>
> fed19000-fed19fff : pnp 00:06
>
> fed20000-fed3ffff : pnp 00:06
>
> fed40000-fed4087f : MSFT0101:00
>
> fed45000-fed8ffff : pnp 00:06
>
> fed90000-fed93fff : pnp 00:06
>
> fee00000-fee00fff : Local APIC
>
> This is the NUC I am using, if that can be useful.
>
> root@vhsv1:~# cat /sys/class/dmi/id/board_name /sys/class/dmi/id/board_
> version
>
> NUC6i7KYB
>
> H90766-404
>
> I am compiling the module right as we speak, I will get back to you soon.
>
> On 16 February 2017 at 18:19, Jason Gunthorpe <
> jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
>
>> On Thu, Feb 16, 2017 at 06:10:43PM +0000, Davide Guerri wrote:
>> >    Hey thanks for the prompt reply.
>> >    I think you are interested in this:
>> >       fed40000-fed4087f : MSFT0101:00
>>
>> Are there more lines below that?
>>
>> Can you apply this patch and report what the results are?
>>
>> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
>> index a7c870af916c3d..acc54a03d6025d 100644
>> --- a/drivers/char/tpm/tpm_crb.c
>> +++ b/drivers/char/tpm/tpm_crb.c
>> @@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev,
>> struct crb_priv *priv,
>>                 .flags  = IORESOURCE_MEM,
>>         };
>>
>> +       printk("map request is is %pr\n",&new_res);
>> +
>>         /* Detect a 64 bit address on a 32 bit system */
>>         if (start != new_res.start)
>>                 return (void __iomem *) ERR_PTR(-EINVAL);
>> @@ -267,6 +269,8 @@ static int crb_map_io(struct acpi_device *device,
>> struct crb_priv *priv,
>>                 return -EINVAL;
>>         }
>>
>> +       printk("ACPI resource is %pr\n",&io_res);
>> +
>>         priv->iobase = devm_ioremap_resource(dev, &io_res);
>>         if (IS_ERR(priv->iobase))
>>                 return PTR_ERR(priv->iobase);
>>
>
>
>
> --
>
>
> [image: Davide Guerri on about.me]
>
> Davide Guerri
> about.me/davide_guerri
>   <http://about.me/davide_guerri>
>



-- 


[image: Davide Guerri on about.me]

Davide Guerri
about.me/davide_guerri
  <http://about.me/davide_guerri>

[-- Attachment #1.2: Type: text/html, Size: 9082 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

[-- Attachment #1.1: Type: text/plain, Size: 3351 bytes --]

Sorry I missed 1 line:

[20417.678952] ACPI resource is [mem 0xfed40000-0xfed4087f flags 0x200]

[20417.678975] map request is is [mem 0xfed40040-0xfed4006f flags 0x200]

[20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]

[20417.678996] tpm_crb MSFT0101:00: can't request region for resource [mem
0xfed40080-0xfed40fff]

[20417.688797] tpm_crb: probe of MSFT0101:00 failed with error -16


On 16 February 2017 at 18:39, Davide Guerri <davide.guerri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> [20417.678975] map request is is [mem 0xfed40040-0xfed4006f flags 0x200]
>
> [20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]
>
> [20417.678996] tpm_crb MSFT0101:00: can't request region for resource [mem
> 0xfed40080-0xfed40fff]
>
> [20417.688797] tpm_crb: probe of MSFT0101:00 failed with error -16
>
>
>
> On 16 February 2017 at 18:26, Davide Guerri <davide.guerri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>
>> No lines including the requested range:
>>
>> fed10000-fed17fff : pnp 00:06
>>
>> fed18000-fed18fff : pnp 00:06
>>
>> fed19000-fed19fff : pnp 00:06
>>
>> fed20000-fed3ffff : pnp 00:06
>>
>> fed40000-fed4087f : MSFT0101:00
>>
>> fed45000-fed8ffff : pnp 00:06
>>
>> fed90000-fed93fff : pnp 00:06
>>
>> fee00000-fee00fff : Local APIC
>>
>> This is the NUC I am using, if that can be useful.
>>
>> root@vhsv1:~# cat /sys/class/dmi/id/board_name
>> /sys/class/dmi/id/board_version
>>
>> NUC6i7KYB
>>
>> H90766-404
>>
>> I am compiling the module right as we speak, I will get back to you soon.
>>
>> On 16 February 2017 at 18:19, Jason Gunthorpe <
>> jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
>>
>>> On Thu, Feb 16, 2017 at 06:10:43PM +0000, Davide Guerri wrote:
>>> >    Hey thanks for the prompt reply.
>>> >    I think you are interested in this:
>>> >       fed40000-fed4087f : MSFT0101:00
>>>
>>> Are there more lines below that?
>>>
>>> Can you apply this patch and report what the results are?
>>>
>>> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
>>> index a7c870af916c3d..acc54a03d6025d 100644
>>> --- a/drivers/char/tpm/tpm_crb.c
>>> +++ b/drivers/char/tpm/tpm_crb.c
>>> @@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev,
>>> struct crb_priv *priv,
>>>                 .flags  = IORESOURCE_MEM,
>>>         };
>>>
>>> +       printk("map request is is %pr\n",&new_res);
>>> +
>>>         /* Detect a 64 bit address on a 32 bit system */
>>>         if (start != new_res.start)
>>>                 return (void __iomem *) ERR_PTR(-EINVAL);
>>> @@ -267,6 +269,8 @@ static int crb_map_io(struct acpi_device *device,
>>> struct crb_priv *priv,
>>>                 return -EINVAL;
>>>         }
>>>
>>> +       printk("ACPI resource is %pr\n",&io_res);
>>> +
>>>         priv->iobase = devm_ioremap_resource(dev, &io_res);
>>>         if (IS_ERR(priv->iobase))
>>>                 return PTR_ERR(priv->iobase);
>>>
>>
>>
>>
>> --
>>
>>
>> [image: Davide Guerri on about.me]
>>
>> Davide Guerri
>> about.me/davide_guerri
>>   <http://about.me/davide_guerri>
>>
>
>
>
> --
>
>
> [image: Davide Guerri on about.me]
>
> Davide Guerri
> about.me/davide_guerri
>   <http://about.me/davide_guerri>
>



-- 


[image: Davide Guerri on about.me]

Davide Guerri
about.me/davide_guerri
  <http://about.me/davide_guerri>

[-- Attachment #1.2: Type: text/html, Size: 12431 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jason Gunthorpe]

On Thu, Feb 16, 2017 at 06:40:02PM +0000, Davide Guerri wrote:
>    Sorry I missed 1 line:
> 
>    [20417.678952] ACPI resource is [mem 0xfed40000-0xfed4087f flags 0x200]

The BIOS is broken.. That range declared in the ACPI is too small

Or the cmd_size is too big:

>    [20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]

I have no idea which.

If we trust the ACPI table then the cmd_size is 2047 bytes

If we trust the register then it is 3967..

Try this?

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index a7c870af916c3d..2d16cc4aa0f43b 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
 		.flags	= IORESOURCE_MEM,
 	};
 
+	printk("map request is is %pr\n",&new_res);
+
 	/* Detect a 64 bit address on a 32 bit system */
 	if (start != new_res.start)
 		return (void __iomem *) ERR_PTR(-EINVAL);
@@ -243,6 +245,26 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
 	return priv->iobase + (new_res.start - io_res->start);
 }
 
+/*
+ * Work around broken BIOSs that return inconsistent values from the ACPI
+ * region vs the registers. Trust the ACPI region.
+ */
+static u64 crb_clamp_cmd_size(struct device *dev, struct resource *io_res,
+			      u64 start, u64 size)
+{
+	if (io_res->start > start || io_res->end < start)
+		return size;
+
+	if (start + size - 1 <= io_res->end)
+		return size;
+
+	dev_err(dev,
+		FW_BUG "ACPI region does not cover the entire command/response buffer. %pr vs %llx %llx\n",
+		io_res, start, size);
+
+	return io_res->end - start + 1;
+}
+
 static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 		      struct acpi_table_tpm2 *buf)
 {
@@ -267,6 +289,8 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 		return -EINVAL;
 	}
 
+	printk("ACPI resource is %pr\n",&io_res);
+
 	priv->iobase = devm_ioremap_resource(dev, &io_res);
 	if (IS_ERR(priv->iobase))
 		return PTR_ERR(priv->iobase);
@@ -278,14 +302,16 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 
 	cmd_pa = ((u64) ioread32(&priv->cca->cmd_pa_high) << 32) |
 		  (u64) ioread32(&priv->cca->cmd_pa_low);
-	cmd_size = ioread32(&priv->cca->cmd_size);
+	cmd_size = crb_clamp_cmd_size(dev, &io_res, cmd_pa,
+				      ioread32(&priv->cca->cmd_size));
 	priv->cmd = crb_map_res(dev, priv, &io_res, cmd_pa, cmd_size);
 	if (IS_ERR(priv->cmd))
 		return PTR_ERR(priv->cmd);
 
 	memcpy_fromio(&rsp_pa, &priv->cca->rsp_pa, 8);
 	rsp_pa = le64_to_cpu(rsp_pa);
-	rsp_size = ioread32(&priv->cca->rsp_size);
+	rsp_size = crb_clamp_cmd_size(dev, &io_res, rsp_pa,
+				      ioread32(&priv->cca->rsp_size));
 
 	if (cmd_pa != rsp_pa) {
 		priv->rsp = crb_map_res(dev, priv, &io_res, rsp_pa, rsp_size);

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

Yes.
I tried to crop the 2 sizes manually and it worked.
I tested a couple of user space commands and it seems to be working.

Later I will try with your patch.

Thanks!



Sent from my iPhone
> On 16 Feb 2017, at 19:03, Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> 
>> On Thu, Feb 16, 2017 at 06:40:02PM +0000, Davide Guerri wrote:
>>   Sorry I missed 1 line:
>> 
>>   [20417.678952] ACPI resource is [mem 0xfed40000-0xfed4087f flags 0x200]
> 
> The BIOS is broken.. That range declared in the ACPI is too small
> 
> Or the cmd_size is too big:
> 
>>   [20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]
> 
> I have no idea which.
> 
> If we trust the ACPI table then the cmd_size is 2047 bytes
> 
> If we trust the register then it is 3967..
> 
> Try this?
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index a7c870af916c3d..2d16cc4aa0f43b 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
>        .flags    = IORESOURCE_MEM,
>    };
> 
> +    printk("map request is is %pr\n",&new_res);
> +
>    /* Detect a 64 bit address on a 32 bit system */
>    if (start != new_res.start)
>        return (void __iomem *) ERR_PTR(-EINVAL);
> @@ -243,6 +245,26 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
>    return priv->iobase + (new_res.start - io_res->start);
> }
> 
> +/*
> + * Work around broken BIOSs that return inconsistent values from the ACPI
> + * region vs the registers. Trust the ACPI region.
> + */
> +static u64 crb_clamp_cmd_size(struct device *dev, struct resource *io_res,
> +                  u64 start, u64 size)
> +{
> +    if (io_res->start > start || io_res->end < start)
> +        return size;
> +
> +    if (start + size - 1 <= io_res->end)
> +        return size;
> +
> +    dev_err(dev,
> +        FW_BUG "ACPI region does not cover the entire command/response buffer. %pr vs %llx %llx\n",
> +        io_res, start, size);
> +
> +    return io_res->end - start + 1;
> +}
> +
> static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
>              struct acpi_table_tpm2 *buf)
> {
> @@ -267,6 +289,8 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
>        return -EINVAL;
>    }
> 
> +    printk("ACPI resource is %pr\n",&io_res);
> +
>    priv->iobase = devm_ioremap_resource(dev, &io_res);
>    if (IS_ERR(priv->iobase))
>        return PTR_ERR(priv->iobase);
> @@ -278,14 +302,16 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
> 
>    cmd_pa = ((u64) ioread32(&priv->cca->cmd_pa_high) << 32) |
>          (u64) ioread32(&priv->cca->cmd_pa_low);
> -    cmd_size = ioread32(&priv->cca->cmd_size);
> +    cmd_size = crb_clamp_cmd_size(dev, &io_res, cmd_pa,
> +                      ioread32(&priv->cca->cmd_size));
>    priv->cmd = crb_map_res(dev, priv, &io_res, cmd_pa, cmd_size);
>    if (IS_ERR(priv->cmd))
>        return PTR_ERR(priv->cmd);
> 
>    memcpy_fromio(&rsp_pa, &priv->cca->rsp_pa, 8);
>    rsp_pa = le64_to_cpu(rsp_pa);
> -    rsp_size = ioread32(&priv->cca->rsp_size);
> +    rsp_size = crb_clamp_cmd_size(dev, &io_res, rsp_pa,
> +                      ioread32(&priv->cca->rsp_size));
> 
>    if (cmd_pa != rsp_pa) {
>        priv->rsp = crb_map_res(dev, priv, &io_res, rsp_pa, rsp_size);

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Jarkko Sakkinen]

On Thu, Feb 16, 2017 at 12:03:29PM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 16, 2017 at 06:40:02PM +0000, Davide Guerri wrote:
> >    Sorry I missed 1 line:
> > 
> >    [20417.678952] ACPI resource is [mem 0xfed40000-0xfed4087f flags 0x200]
> 
> The BIOS is broken.. That range declared in the ACPI is too small

The range declare in ACPI is too small. It should be one full page.

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Winkler, Tomas]

[-- Attachment #1.1: Type: text/plain, Size: 3877 bytes --]

This is a BIOS issue + kernel ACPI platform driver refusing to handle overlapping memory space. The issue here is that the ACPI platform driver is not created, however this should not prevent  the tpm_crb driver from working as it registers directly the ACPI device. For now you can suppress the message by adding the device in forbidden_id_list in drivers/acpi/acpi_platform.c

I’m already testing a fixed BIOS, not sure whether and when it will be available for your particular device.

Thanks
Tomas

From: Davide Guerri [mailto:davide.guerri@gmail.com]
Sent: Thursday, February 16, 2017 20:40
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: tpmdd-devel@lists.sourceforge.net
Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2

Sorry I missed 1 line:


[20417.678952] ACPI resource is [mem 0xfed40000-0xfed4087f flags 0x200]

[20417.678975] map request is is [mem 0xfed40040-0xfed4006f flags 0x200]

[20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]

[20417.678996] tpm_crb MSFT0101:00: can't request region for resource [mem 0xfed40080-0xfed40fff]

[20417.688797] tpm_crb: probe of MSFT0101:00 failed with error -16


On 16 February 2017 at 18:39, Davide Guerri <davide.guerri@gmail.com<mailto:davide.guerri@gmail.com>> wrote:

[20417.678975] map request is is [mem 0xfed40040-0xfed4006f flags 0x200]

[20417.678990] map request is is [mem 0xfed40080-0xfed40fff flags 0x200]

[20417.678996] tpm_crb MSFT0101:00: can't request region for resource [mem 0xfed40080-0xfed40fff]

[20417.688797] tpm_crb: probe of MSFT0101:00 failed with error -16



On 16 February 2017 at 18:26, Davide Guerri <davide.guerri@gmail.com<mailto:davide.guerri@gmail.com>> wrote:
No lines including the requested range:


fed10000-fed17fff : pnp 00:06

fed18000-fed18fff : pnp 00:06

fed19000-fed19fff : pnp 00:06

fed20000-fed3ffff : pnp 00:06

fed40000-fed4087f : MSFT0101:00

fed45000-fed8ffff : pnp 00:06

fed90000-fed93fff : pnp 00:06

fee00000-fee00fff : Local APIC

This is the NUC I am using, if that can be useful.


root@vhsv1:~# cat /sys/class/dmi/id/board_name /sys/class/dmi/id/board_version

NUC6i7KYB

H90766-404

I am compiling the module right as we speak, I will get back to you soon.

On 16 February 2017 at 18:19, Jason Gunthorpe <jgunthorpe@obsidianresearch.com<mailto:jgunthorpe@obsidianresearch.com>> wrote:
On Thu, Feb 16, 2017 at 06:10:43PM +0000, Davide Guerri wrote:
>    Hey thanks for the prompt reply.
>    I think you are interested in this:
>       fed40000-fed4087f : MSFT0101:00

Are there more lines below that?

Can you apply this patch and report what the results are?

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index a7c870af916c3d..acc54a03d6025d 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -233,6 +233,8 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
                .flags  = IORESOURCE_MEM,
        };

+       printk("map request is is %pr\n",&new_res);
+
        /* Detect a 64 bit address on a 32 bit system */
        if (start != new_res.start)
                return (void __iomem *) ERR_PTR(-EINVAL);
@@ -267,6 +269,8 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
                return -EINVAL;
        }

+       printk("ACPI resource is %pr\n",&io_res);
+
        priv->iobase = devm_ioremap_resource(dev, &io_res);
        if (IS_ERR(priv->iobase))
                return PTR_ERR(priv->iobase);



--


[Davide Guerri on about.me]



Davide Guerri
about.me/davide_guerri






--


[Davide Guerri on about.me]



Davide Guerri
about.me/davide_guerri






--


[Davide Guerri on about.me]



Davide Guerri
about.me/davide_guerri





[-- Attachment #1.2: Type: text/html, Size: 17438 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jason Gunthorpe]

On Thu, Feb 16, 2017 at 10:36:40PM +0000, Winkler, Tomas wrote:
>    This is a BIOS issue + kernel ACPI platform driver refusing to handle
>    overlapping memory space. The issue here is that the ACPI platform
>    driver is not created, however this should not prevent  the tpm_crb
>    driver from working as it registers directly the ACPI device. For now
>    you can suppress the message by adding the device in forbidden_id_list
>    in drivers/acpi/acpi_platform.c
> 
>
>    I'm already testing a fixed BIOS, not sure whether and when it will be
>    available for your particular device.

Do you think we should go ahead with the patch I sent? Or should we
tell users they need a BIOS update?

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Sakkinen, Jarkko]

On Fri, 2017-02-17 at 09:43 -0700, Jason Gunthorpe wrote:
> On Thu, Feb 16, 2017 at 10:36:40PM +0000, Winkler, Tomas wrote:
> >    This is a BIOS issue + kernel ACPI platform driver refusing to
> > handle
> >    overlapping memory space. The issue here is that the ACPI
> > platform
> >    driver is not created, however this should not prevent  the
> > tpm_crb
> >    driver from working as it registers directly the ACPI device.
> > For now
> >    you can suppress the message by adding the device in
> > forbidden_id_list
> >    in drivers/acpi/acpi_platform.c
> > 
> > 
> >    I'm already testing a fixed BIOS, not sure whether and when it
> > will be
> >    available for your particular device.
> 
> Do you think we should go ahead with the patch I sent? Or should we
> tell users they need a BIOS update?
> 
> Jason

I would rather review a patch with proper commit message than just pick
from an email thread in all cases with a proper explanation what the
patch does and why it is the right way to fix the issue.

I got an email privately and identified it as the very same issue. It
was in a NUC and the author said that he had updated the BIOS to the
latest version. That supports the view of doing some kind of workaround
to the driver, perhaps the way you did it.

/Jarkko
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jason Gunthorpe]

> I would rather review a patch with proper commit message than just pick
> from an email thread in all cases with a proper explanation what the
> patch does and why it is the right way to fix the issue.

Of course, but I am waiting for Davide to say the approach even works
..

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

[-- Attachment #1.1: Type: text/plain, Size: 656 bytes --]

Hey,
sorry fro the delayed reply.

Jason's patch works. I had no doubt it would, because I tried a qnd patch with manually cropped sizes. 
I have cleaned it up a little bit, removing printks.

Thanks again!

D. 



> On 17 Feb 2017, at 7:01 pm, Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> 
>> I would rather review a patch with proper commit message than just pick
>> from an email thread in all cases with a proper explanation what the
>> patch does and why it is the right way to fix the issue.
> 
> Of course, but I am waiting for Davide to say the approach even works
> ..
> 
> Jason


[-- Attachment #1.2.1: Type: text/html, Size: 1463 bytes --]

[-- Attachment #1.2.2: NUC-fw-fix.patch --]
[-- Type: application/octet-stream, Size: 1770 bytes --]

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index a7c870a..7f5e871 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -243,6 +243,26 @@ static void __iomem *crb_map_res(struct device *dev, struct crb_priv *priv,
 	return priv->iobase + (new_res.start - io_res->start);
 }

+/*
+ * Work around broken BIOSs that return inconsistent values from the ACPI
+ * region vs the registers. Trust the ACPI region.
+ */
+static u64 crb_clamp_cmd_size(struct device *dev, struct resource *io_res,
+			      u64 start, u64 size)
+{
+	if (io_res->start > start || io_res->end < start)
+		return size;
+
+	if (start + size - 1 <= io_res->end)
+		return size;
+
+	dev_err(dev,
+		FW_BUG "ACPI region does not cover the entire command/response buffer. %pr vs %llx %llx\n",
+		io_res, start, size);
+
+	return io_res->end - start + 1;
+}
+
 static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 		      struct acpi_table_tpm2 *buf)
 {
@@ -278,14 +298,16 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,

 	cmd_pa = ((u64) ioread32(&priv->cca->cmd_pa_high) << 32) |
 		  (u64) ioread32(&priv->cca->cmd_pa_low);
-	cmd_size = ioread32(&priv->cca->cmd_size);
+	cmd_size = crb_clamp_cmd_size(dev, &io_res, cmd_pa,
+				      ioread32(&priv->cca->cmd_size));
 	priv->cmd = crb_map_res(dev, priv, &io_res, cmd_pa, cmd_size);
 	if (IS_ERR(priv->cmd))
 		return PTR_ERR(priv->cmd);

 	memcpy_fromio(&rsp_pa, &priv->cca->rsp_pa, 8);
 	rsp_pa = le64_to_cpu(rsp_pa);
-	rsp_size = ioread32(&priv->cca->rsp_size);
+	rsp_size = crb_clamp_cmd_size(dev, &io_res, rsp_pa,
+				      ioread32(&priv->cca->rsp_size));

 	if (cmd_pa != rsp_pa) {
 		priv->rsp = crb_map_res(dev, priv, &io_res, rsp_pa, rsp_size);

[-- Attachment #1.2.3: Type: text/html, Size: 1047 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Winkler, Tomas]

[-- Attachment #1.1: Type: text/plain, Size: 1556 bytes --]

I need few days to get into BIOS to understand how we got to here at the first place,
Can you please send me the dmidecode of the NUC (even privately) so I can understand what exactly issue we have. The fixed BIOS I'm testing now is for the Kaby Lake platform.
Davide if would fill a bug for that via intel support page so we can follow up on that.

Thanks
Tomas

From: Davide Guerri [mailto:davide.guerri-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Friday, February 17, 2017 23:15
To: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Sakkinen, Jarkko <jarkko.sakkinen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; Winkler, Tomas <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2

Hey,
sorry fro the delayed reply.

Jason's patch works. I had no doubt it would, because I tried a qnd patch with manually cropped sizes.
I have cleaned it up a little bit, removing printks.

Thanks again!

D.


On 17 Feb 2017, at 7:01 pm, Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMNAWLNoT+7d/@public.gmane.orgm<mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>> wrote:

I would rather review a patch with proper commit message than just pick
from an email thread in all cases with a proper explanation what the
patch does and why it is the right way to fix the issue.

Of course, but I am waiting for Davide to say the approach even works
..

Jason


[-- Attachment #1.2: Type: text/html, Size: 6040 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jarkko Sakkinen]

On Sun, Feb 19, 2017 at 10:28:08PM +0000, Winkler, Tomas wrote:
>    I need few days to get into BIOS to understand how we got to here at the
>    first place,
> 
>    Can you please send me the dmidecode of the NUC (even privately) so I can
>    understand what exactly issue we have. The fixed BIOS I’m testing now is
>    for the Kaby Lake platform.
> 
>    Davide if would fill a bug for that via intel support page so we can
>    follow up on that.
> 
>     
> 
>    Thanks
> 
>    Tomas

I don't want to be impolite but can you please stop constantly sending
HTML messages to the list and top-posting. This has now happend multiple
times. Thank you.

/Jarkko

> 
>     
> 
>    From: Davide Guerri [mailto:davide.guerri@gmail.com]
>    Sent: Friday, February 17, 2017 23:15
>    To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>    Cc: Sakkinen, Jarkko <jarkko.sakkinen@intel.com>; Winkler, Tomas
>    <tomas.winkler@intel.com>; tpmdd-devel@lists.sourceforge.net
>    Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2
> 
>     
> 
>    Hey,
> 
>    sorry fro the delayed reply.
> 
>     
> 
>    Jason's patch works. I had no doubt it would, because I tried a qnd patch
>    with manually cropped sizes. 
> 
>    I have cleaned it up a little bit, removing printks.
> 
>     
> 
>    Thanks again!
> 
>     
> 
>    D. 
> 
>     
> 
>     
> 
>      On 17 Feb 2017, at 7:01 pm, Jason Gunthorpe
>      <jgunthorpe@obsidianresearch.com> wrote:
> 
>       
> 
>        I would rather review a patch with proper commit message than just
>        pick
>        from an email thread in all cases with a proper explanation what the
>        patch does and why it is the right way to fix the issue.
> 
>      Of course, but I am waiting for Davide to say the approach even works
>      ..
> 
>      Jason
> 
>     

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot

> _______________________________________________
> tpmdd-devel mailing list
> tpmdd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: Intel NUC and fTPM issue on 4.9.2

[Jarkko Sakkinen]

On Fri, Feb 17, 2017 at 12:01:25PM -0700, Jason Gunthorpe wrote:
> > I would rather review a patch with proper commit message than just pick
> > from an email thread in all cases with a proper explanation what the
> > patch does and why it is the right way to fix the issue.
> 
> Of course, but I am waiting for Davide to say the approach even works
> ..
> 
> Jason

I'm not sure what would be a good function name but maybe something
that would state that this is not status quo but workaround for a
bug. Since I do not have any better suggestion keep the current
name if nothing comes up.

Probably a dev_err message would make sense here to state in klog
that something is wrong in the BIOS.

Since there are multiple people complaining about the issue I will
take this workaround even if the BIOS is fixed.

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[tpmdd-devel] Intel NUC and fTPM issue on 4.9.2

[Winkler, Tomas]

> -----Original Message-----
> From: Jarkko Sakkinen [mailto:jarkko.sakkinen at linux.intel.com]
> Sent: Monday, February 20, 2017 12:48
> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Cc: Sakkinen, Jarkko <jarkko.sakkinen@intel.com>; tpmdd-
> devel at lists.sourceforge.net; davide.guerri at gmail.com
> Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2
> 
> On Fri, Feb 17, 2017 at 12:01:25PM -0700, Jason Gunthorpe wrote:
> > > I would rather review a patch with proper commit message than just
> > > pick from an email thread in all cases with a proper explanation
> > > what the patch does and why it is the right way to fix the issue.
> >
> > Of course, but I am waiting for Davide to say the approach even works
> > ..
> >
> > Jason
> 
> I'm not sure what would be a good function name but maybe something that
> would state that this is not status quo but workaround for a bug. Since I do not
> have any better suggestion keep the current name if nothing comes up.
> 
> Probably a dev_err message would make sense here to state in klog that
> something is wrong in the BIOS.
> 
> Since there are multiple people complaining about the issue I will take this
> workaround even if the BIOS is fixed.
> 
> /Jarkko


There is finally a BIOS fix 
https://downloadcenter.intel.com/download/26698/NUCs-BIOS-Update-KYSKLi70-86A- 
0045 and newer

Thanks
Tomas

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2

[Winkler, Tomas]

> -----Original Message-----
> From: Jarkko Sakkinen [mailto:jarkko.sakkinen@linux.intel.com]
> Sent: Monday, February 20, 2017 12:48
> To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Cc: Sakkinen, Jarkko <jarkko.sakkinen@intel.com>; tpmdd-
> devel@lists.sourceforge.net; davide.guerri@gmail.com
> Subject: Re: [tpmdd-devel] Intel NUC and fTPM issue on 4.9.2
> 
> On Fri, Feb 17, 2017 at 12:01:25PM -0700, Jason Gunthorpe wrote:
> > > I would rather review a patch with proper commit message than just
> > > pick from an email thread in all cases with a proper explanation
> > > what the patch does and why it is the right way to fix the issue.
> >
> > Of course, but I am waiting for Davide to say the approach even works
> > ..
> >
> > Jason
> 
> I'm not sure what would be a good function name but maybe something that
> would state that this is not status quo but workaround for a bug. Since I do not
> have any better suggestion keep the current name if nothing comes up.
> 
> Probably a dev_err message would make sense here to state in klog that
> something is wrong in the BIOS.
> 
> Since there are multiple people complaining about the issue I will take this
> workaround even if the BIOS is fixed.
> 
> /Jarkko


There is finally a BIOS fix 
https://downloadcenter.intel.com/download/26698/NUCs-BIOS-Update-KYSKLi70-86A- 
0045 and newer

Thanks
Tomas

Re: Intel NUC and fTPM issue on 4.9.2

[Jarkko Sakkinen]

On Thu, Feb 16, 2017 at 06:26:29PM +0000, Davide Guerri wrote:
>    No lines including the requested range:
> 
>    fed10000-fed17fff : pnp 00:06
> 
>    fed18000-fed18fff : pnp 00:06
> 
>    fed19000-fed19fff : pnp 00:06
> 
>    fed20000-fed3ffff : pnp 00:06
> 
>    fed40000-fed4087f : MSFT0101:00

It really looks like that the BIOS is reporting wrong value.
Have you tried to update it?

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Davide Guerri]

> On 16 Feb 2017, at 8:27 pm, Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> 
> On Thu, Feb 16, 2017 at 06:26:29PM +0000, Davide Guerri wrote:
>>   No lines including the requested range:
>> 
>>   fed10000-fed17fff : pnp 00:06
>> 
>>   fed18000-fed18fff : pnp 00:06
>> 
>>   fed19000-fed19fff : pnp 00:06
>> 
>>   fed20000-fed3ffff : pnp 00:06
>> 
>>   fed40000-fed4087f : MSFT0101:00
> 
> It really looks like that the BIOS is reporting wrong value.
> Have you tried to update it?
> 
> /Jarkko

Hi Jarkko,
I apologise for having used an HTML user agent, I hadn't one configured for this account and I just used the google UI.

So, I can try upgrading it. But I wonder whether acpi_enforce_resources=lax would work around the issue.
I am trying that later and I will let you know.

Thanks,
 Davide.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Intel NUC and fTPM issue on 4.9.2

[Jarkko Sakkinen]

On Thu, Feb 16, 2017 at 11:15:41AM +0000, Davide Guerri wrote:
>    Hello guys,
>    I am trying to get the fTPM on an Intel NUC working bit I get this error
> 
>    [    3.191376] tpm_crb MSFT0101:00: can't request region for resource
>    [mem 0xfed40080-0xfed40fff]
> 
>    [    3.200378] tpm_crb: probe of MSFT0101:00 failed with error -16
> 
>    and, of course, the TPM device is not registered in dev/sysfs
>    In my understanding this is a regression as it has been already fixed in
>    the past and merged in 4.7 or 4.8.
>    I also verified my source and tpm_crb.c contains this
>    patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=422eac3f7deae34dbaffd08e03e27f37a5394a56
>    Is that a known issue? If so, are there workaround/patches?
>    Thanks in advance,
>     Davide.

Could you please use plain text email, '>' quoting and reply inline?
Your emails are almost impossible to read with plain text email client
like the one that I use (links dump looks terrible).

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot