All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Seunghun Han <kkamagui@gmail.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	"open list:TPM DEVICE DRIVER" <linux-integrity@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Vanya Lazeev <ivan.lazeev@gmail.com>
Subject: Re: [PATCH v2 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
Date: Fri, 13 Sep 2019 14:12:34 +0100	[thread overview]
Message-ID: <20190913131234.GA7412@linux.intel.com> (raw)
In-Reply-To: <CAHjaAcRf3fcJMp6AwVRTrVaABZVzSkhBwRcpKZogAS4SSDK3zg@mail.gmail.com>

On Wed, Sep 11, 2019 at 12:28:18AM +0900, Seunghun Han wrote:
> > Matthew pointed out that having a hook in NVS driver is better solution
> > because it is nil functionality if the TPM driver is loaded. We need
> > functions to:
> >
> > 1. Request a region from the NVS driver (when tpm_crb loads)
> > 2. Release a region back to the NVS Driver (when tpm_crb unloads).
> >
> > My proposal would unnecessarily duplicate code and also leave a
> > side-effect when TPM is not used in the first place.
> >
> > I see this as the overally best solution. If you can come up with a
> > patch for the NVS side and changes to CRB drivers to utilize the new
> > hooks, then combined with Vanya's changes we have a sustainable solution
> > for AMD fTPM.
> 
> It's a great solution. I will update this patch on your advice and
> send it to you soon.
> 
> By the way, I have a question about your advice.
> If we handle the NVS region with NVS driver, calling devm_ioremap()
> function is fine like crb_ioremap_resource() function in this patch?

No, you should reclaim the resource that conflicts and return it back
when tpm_crb is unregistered (e.g. rmmod tpm_crb).

I would try something like enumerating iomem resources with
walk_iomem_res_desc(). I would advice to peek at arch/x86/kernel/crash.c
for an example how to use this for NVS regions
(IORES_DESC_ACPI_NV_STORAGE).

E.g. you could use a callback for it along the lines of:

static int crb_find_iomem_res_cb(struct resource *res, void *io_res_ptr)
{
	struct resource *io_res = io_res_ptr;

	if (res->start == io_res->start && res->end == io_res->end) {
		/*
		 * Backup all resource data so that it can be inserted
		 * later on with the flags it had etc.
		 */
		*io_res = *res;
		return 1;
	}

	return 0;
}

Then you could __release_region() to unallocate the source. When tpm_crb
is removed you can then allocate and insert a resource with data
matching it had.


/Jarkko

  reply	other threads:[~2019-09-13 13:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09  9:09 [PATCH v2 0/2] Enhance support for the AMD's fTPM Seunghun Han
2019-09-09  9:09 ` [PATCH v2 1/2] tpm: tpm_crb: enhance command and response buffer size calculation code Seunghun Han
2019-09-10 12:34   ` Jarkko Sakkinen
2019-09-10 15:12     ` Seunghun Han
2019-09-09  9:09 ` [PATCH v2 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM Seunghun Han
2019-09-10 14:42   ` Jarkko Sakkinen
2019-09-10 15:06     ` Jarkko Sakkinen
2019-09-10 15:28       ` Seunghun Han
2019-09-13 13:12         ` Jarkko Sakkinen [this message]
2019-09-16  8:18           ` Seunghun Han
2019-09-16  8:42             ` Seunghun Han

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190913131234.GA7412@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=ivan.lazeev@gmail.com \
    --cc=kkamagui@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=peterhuewe@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.