On Sat, Apr 18, 2015 at 10:57:55PM +0100, Russell King - ARM Linux wrote:
But then we trundle down to:
+ ctx-teedev-desc-ops-get_version(ctx, vers.spec_version,
+ vers.uuid);
If we kref teedev so it is valid then calling a driver call back after
(or during) it's remove function
On Mon, Apr 27, 2015 at 09:24:35PM -0400, Doug Ledford wrote:
On Mon, 2015-04-27 at 17:53 -0700, Tom Talpey wrote:
Having some of it refer to things as IBOE and some as ROCE would be
similarly confusing, and switching existing IBOE usage to ROCE would
cause pain to people with out of tree
On Mon, May 11, 2015 at 08:27:00PM -0400, Doug Ledford wrote:
On Mon, 2015-05-11 at 19:49 -0400, ira.weiny wrote:
I have run with this series and the only issue I have found is not with this
patch set directly.
This patch:
IB/Verbs: Use management helper rdma_cap_ib_mad()
On Wed, May 13, 2015 at 03:24:32PM +0200, Michael Wang wrote:
This is the following patch for:
https://lkml.org/lkml/2015/5/5/417
which try to document the settled rdma_cap_XX().
Highlights:
There could be many missing/mistakes/misunderstanding, please don't
be hesitate to point out
On Tue, Apr 14, 2015 at 10:18:07AM -0400, ira.weiny wrote:
After more thought and reading other opinions, I must agree we should not
have cap_foo_dev.
I looked at it a bit, and I think Sean has also basically said, CM
does not support certain mixed port combinations. iWarp and IB simply
cannot
On Tue, Apr 14, 2015 at 01:43:11PM -0400, ira.weiny wrote:
A failure to init port 2 ends up ends up killing port 1 and releasing the
device associated resources.
Yes, that is the only reasonable thing that could happen.
init failure should only be possible under exceptional cases (OOM).
The
On Tue, Apr 14, 2015 at 06:02:47PM +, Hefty, Sean wrote:
Yes, that is the only reasonable thing that could happen.
init failure should only be possible under exceptional cases (OOM).
The only system response is to call ib_umad_add_one again - so of
course the first call had to
On Wed, Apr 15, 2015 at 09:17:14AM +0300, Erez Shitrit wrote:
+ /* parent interface */
+ if (!test_bit(IPOIB_FLAG_SUBINTERFACE, priv-flags))
+ return dev-ifindex;
+
+ /* child/vlan interface */
+ if (!priv-parent)
+ return -1;
Like was
On Thu, Apr 16, 2015 at 10:08:10AM +0200, Michael Wang wrote:
Use raw management helpers to reform cm related part in IB-core cma/ucm.
These checks focus on the device cm type rather than the port capability,
directly pass port 1 works currently, but can't support mixing cm type
device in
On Tue, Apr 14, 2015 at 11:13:03AM +0200, Michael Wang wrote:
I would be very happy to see a patch that adds cap_ib_smi to the
current tree and states 'This patch is tested to have no change on the
binary compilation results'
There are too much reform there (per-dev to per-port), I guess
On Wed, Apr 15, 2015 at 09:58:18AM +0200, Michael Wang wrote:
We can give client-add() callback a return value and make
ib_register_device() return -ENOMEM when it failed, just wondering
why we don't do this at first, any special reason?
No idea, but having ib_register_device fail and unwind
On Thu, Apr 16, 2015 at 04:55:10PM +, Hefty, Sean wrote:
After the discussion settled, I ended up thinking that implementing
explicit device checks, for use by CM, and the BUG_ON at register to
require all ports have the same value was the best option.
Sure, but why not update the
On Thu, Apr 16, 2015 at 01:38:07PM -0400, Hal Rosenstock wrote:
On 4/16/2015 11:58 AM, Jason Gunthorpe wrote:
It also looks like hardwired 1 won't work on switch ports, so it is no-go.
AFAIK enhanced switch port 0 is not supported by CM/RDMA CM in the
current code. There is no need for CM
On Thu, Apr 16, 2015 at 10:02:46AM -0700, Roland Dreier wrote:
On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
We can give client-add() callback a return value and make
ib_register_device() return -ENOMEM when it failed, just wondering
why we don't
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
+ rc = misc_register(teedev-miscdev);
[..]
+void tee_unregister(struct tee_device *teedev)
+{
[..]
+ misc_deregister(teedev-miscdev);
+}
[..]
+static
On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
+ rc = misc_register
On Tue, Apr 14, 2015 at 07:30:03PM +0300, Erez Shitrit wrote:
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 657b89b..11ea6e2 100644
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -846,7 +846,10 @@ static int
On Tue, Apr 07, 2015 at 02:30:22PM +0200, Michael Wang wrote:
- if (rdma_node_get_transport(device-node_type) != RDMA_TRANSPORT_IB)
- return;
-
if (device-node_type == RDMA_NODE_IB_SWITCH) {
start = 0;
end = 0;
@@ -3069,6 +3066,9 @@
On Tue, Apr 07, 2015 at 11:46:57AM -0400, Tom Talpey wrote:
On 4/7/2015 8:34 AM, Michael Wang wrote:
/**
+ * cap_read_multi_sge - Check if the port of device has the capability
+ * RDMA Read Multiple Scatter-Gather Entries.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number
On Tue, Apr 07, 2015 at 02:35:22PM +0200, Michael Wang wrote:
index f704254..4e61104 100644
+++ b/drivers/infiniband/core/sa_query.c
@@ -540,7 +540,7 @@ int ib_init_ah_from_path(struct ib_device *device, u8
port_num,
ah_attr-port_num = port_num;
ah_attr-static_rate = rec-rate;
On Wed, Apr 08, 2015 at 10:26:07AM +0300, Jarkko Sakkinen wrote:
On Wed, Apr 01, 2015 at 12:19:25PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 01, 2015 at 03:28:52PM +0300, Jarkko Sakkinen wrote:
Added PPI interface to the character device. PPI interface is also kept
in the pdev
On Wed, Apr 08, 2015 at 02:41:18PM +0200, Michael Wang wrote:
I think no one can have the access to all these hardware, so we can
only depends on those who accidentally have one to help the testing,
but it's still far from that stage..
I have seen other patches in this style use the compiler
On Wed, Apr 08, 2015 at 06:41:22PM +, Hefty, Sean wrote:
I too would like to see this as the end result, but I think it's
possible to stage the changes by having the static inline calls
being added convert to using these sort of attributes.
I agree as well, this patch set is already so
On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
To straighten all this out, lets break management out into the two
distinct types:
rdma_port_ib_fabric_mgmt() - fabric specific management tasks: MAD, SM,
multicast. The proper test for this with my bitmap above is a simple
On Wed, Apr 01, 2015 at 03:28:52PM +0300, Jarkko Sakkinen wrote:
Added PPI interface to the character device. PPI interface is also kept
in the pdev for backwards compatibility.
Could you look at just completely moving the PPI interface to the char
dev and then adding a symlink from the pdev?
On Thu, Apr 09, 2015 at 02:42:24PM +0200, Michael Wang wrote:
On 04/08/2015 10:10 PM, Jason Gunthorpe wrote:
[snip]
Some of the other checks in this file revolve around pkey, I'm not
sure what rocee does there? cap_pkey_supported ?
I'm not sure if this count in capability... how shall
On Thu, Apr 09, 2015 at 10:34:30AM -0400, Doug Ledford wrote:
These are exactly the tests I proposed Jason. I'm not sure I see your
point here. I guess my point is that although the scenario of all the
different items seems complex, it really does boil down to needing only
exactly what I
On Tue, Jun 02, 2015 at 04:04:22PM +0300, Jarkko Sakkinen wrote:
+/* A string buffer type for constructing TPM commands. This is based on the
+ * code in security/keys/trusted.h.
+ */
+
+#define TPM_BUF_SIZE 512
+
+struct tpm_buf {
+ u8 data[TPM_BUF_SIZE];
This should be u32 or u64 to
On Wed, Jun 03, 2015 at 03:23:31PM +0300, Jarkko Sakkinen wrote:
On Tue, Jun 02, 2015 at 12:13:15PM -0600, Jason Gunthorpe wrote:
On Tue, Jun 02, 2015 at 04:04:22PM +0300, Jarkko Sakkinen wrote:
+/* A string buffer type for constructing TPM commands. This is based on
the
+ * code
On Wed, Jun 03, 2015 at 07:43:34PM +0300, Jarkko Sakkinen wrote:
I realized basically the same what you said here when I refined the
patch (read this email after sending v2) :) I decided that align to 8
bytes.
Don't use the __attribute__((align)), use just a u64, the effect is
identical, and
++--
1 file changed, 2 insertions(+), 2 deletions(-)
Obviously there is a problem here with the double swap. But that
should be a nop on x86 hardware, I didn't think there was a BE arch
using ACPI??
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
Jason
--
To unsubscribe from
On Mon, Jun 22, 2015 at 01:30:39PM -0400, Tejun Heo wrote:
On Mon, Jun 22, 2015 at 08:24:50PM +0300, Jarkko Sakkinen wrote:
Added a new function sysfs_link_group_to_kobj() that adds a symlink
from attribute or group to a kobject. Exported kernfs_remove_by_name_ns
in order to provide a way
On Mon, Jun 22, 2015 at 02:01:54PM -0400, Tejun Heo wrote:
TPM is undergoing a migration of core attributes from the
platform_device to the core's struct device.
The only purpose of the symlink was to provide userspace
compatability with the old location.
Ah, yeah, that's painful.
On Mon, Aug 17, 2015 at 07:06:10PM -0500, Bjorn Helgaas wrote:
On Mon, Aug 17, 2015 at 5:50 PM, Jiang, Dave dave.ji...@intel.com wrote:
On Mon, 2015-08-17 at 17:30 -0500, Bjorn Helgaas wrote:
[+cc Mike, linux-rdma]
On Wed, Jul 29, 2015 at 04:18:54PM -0600, Keith Busch wrote:
From: Dave
ref counting and cdev.
Fixes: 313d21eeab92 (tpm: device class for tpm)
Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
---
drivers/char/tpm/tpm-chip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Peter, I've only compile tests this. Thanks
diff --git a/drivers/char/tpm
On Thu, Aug 13, 2015 at 03:20:49PM -0400, Jérôme Glisse wrote:
+#if IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING_HMM)
+#else /* CONFIG_INFINIBAND_ON_DEMAND_PAGING_HMM */
Yuk, what is wrong with
#if !IS_ENABLED(...)
?
-#ifdef CONFIG_INFINIBAND_ON_DEMAND_PAGING
+#if
On Thu, Jul 23, 2015 at 02:55:52PM -0700, Moritz Fischer wrote:
Hi Alan,
I saw that your socfpga driver doesn't support the partial reconfig
use case (not a big deal).
What I currently do for Zynq is if I'm doing a non-partial reconfig is
that I disable input
level shifters and assert
On Tue, Jul 21, 2015 at 11:14:59AM -0400, Jerome Glisse wrote:
This is a rebase error. But the #error is there for a purpose the HMM
would not work mid way so if anyone if bisecting up through that i would
rather error out at compilation.
Add the kconfig option last not first?
Also, can you
On Wed, Jul 22, 2015 at 03:32:32PM -0500, atull wrote:
I looked some more; I don't see a simple way of deferring probing until
after the filesystem is loaded (so that the image file would be
available), late_initcall is still not late enough.
That seems weird, are you saying you can't use
On Fri, Jul 17, 2015 at 10:51:10AM -0500, at...@opensource.altera.com wrote:
From: Alan Tull at...@opensource.altera.com
This patchset adds two chunks plus documentation:
* fpga manager core: exports ABI functions that write an image to a FPGA
* DT Overlay support: simple-fpga-bus to
On Fri, Jul 17, 2015 at 09:49:13PM +0200, Steffen Trumtrar wrote:
What you are describing here is a virtual bus, that is not existing on
at least the Socfpga, right?
I wouldn't get too hung up on bus or not bus, the HW these days
doesn't even use busses.
For AXI systems, which is all the ARM
On Mon, Jul 13, 2015 at 11:54:50PM +0200, Peter Hüwe wrote:
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.
Applied - thanks.
Will be included in the
On Tue, Oct 27, 2015 at 02:12:36PM -0400, ira.weiny wrote:
> On Tue, Oct 27, 2015 at 09:17:40PM +0530, Saurabh Sengar wrote:
> > replace GFP_KERNEL with GFP_ATOMIC, as code while holding a spinlock
> > should be atomic
> > GFP_KERNEL may sleep and can cause deadlock, where as GFP_ATOMIC may
> >
On Tue, Oct 27, 2015 at 06:56:50PM +, Wan, Kaike wrote:
> > I do wonder if it is a good idea to call ib_nl_send_msg with a spinlock held
> > though.. Would be nice to see that go away.
>
> We have to hold the lock to protect against a race condition that a
> quick response will try to free
On Fri, Nov 13, 2015 at 02:46:43PM +0100, Christoph Hellwig wrote:
> This adds an abstraction that allows ULP to simply pass a completion
> object and completion callback with each submitted WR and let the RDMA
> core handle the nitty gritty details of how to handle completion
> interrupts and
On Fri, Nov 13, 2015 at 11:57:56AM -0800, Bart Van Assche wrote:
> I think this is the conversation you are referring to: "About a shortcoming
> of the verbs API" (http://thread.gmane.org/gmane.linux.drivers.rdma/5028).
> That conversation occurred five years ago, which means that you have an
>
On Sun, Nov 08, 2015 at 09:51:07AM +0200, Jarkko Sakkinen wrote:
> + if (rc && rc != -ENOENT) {
> + tpm_chip_unregister(chip);
> + return rc;
> + }
> + }
This is still goofy looking, the list_add_tail_rcu should be the last
thing
On Fri, Nov 06, 2015 at 04:23:56PM -0800, Jeremiah Mahler wrote:
> On Fri, Oct 16, 2015 at 09:40:22PM +0300, Jarkko Sakkinen wrote:
> > 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
On Tue, Oct 13, 2015 at 11:11:21AM +0300, Jarkko Sakkinen wrote:
> * I updated tpm_buf to a be heap based structure. Now there's one full
> page of memory for variable sized messages. Also the stack is greatly
> reduced.
You may as well just use a skb then.
Jason
--
To unsubscribe from this
On Fri, Oct 02, 2015 at 11:38:17AM +0300, Jarkko Sakkinen wrote:
> Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
> trusted keys.
>
> This patch implements basic sealing and unsealing functionality for
> TPM 2.0:
We really need to stop using chip id's as a handle - the caller
On Wed, Jul 08, 2015 at 12:16:30PM +0200, Jens Wiklander wrote:
+static void tee_device_complete_unused(struct kref *kref)
+{
+ struct tee_device *teedev;
+
+ teedev = container_of(kref, struct tee_device, users);
+ /* When the mutex is released, no other tee_device_get() will
On Thu, Jul 09, 2015 at 02:49:08PM +0200, Jens Wiklander wrote:
Generally in a scheme like this we'd see open and release get/put the
underlying module handle to prevent driver removal while the char dev
is open. Otherwise module removal will hang here.
I'm perhaps misunderstanding you.
On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
+ cdev_init(teedev-cdev, tee_fops);
+ teedev-cdev.owner = teedesc-owner;
This also needs to set teedev-cdev.kobj.parent.
I'm guessing:
teedev-cdev.kobj.parent = teedev-dev.kobj;
TPM had the same
On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
The basic issue is that cdev_del doesn't seem to be synchronizing.
The use after free race is then something like:
struct tpm_chip {
struct device dev;
struct cdev cdev;
Oops, right there's your
On Fri, Sep 04, 2015 at 12:45:38PM -0400, Doug Ledford wrote:
> On 09/04/2015 12:35 PM, Nicholas Krause wrote:
> > This fixes error checking in the function ocrdma_dereg_mr to properly
> > check if the call to ocrdma_mbx_alloc fails as if so we must exit this
> > function immediately and return
On Mon, Sep 14, 2015 at 04:39:33PM +0530, Parav Pandit wrote:
> 1. How does the % of resource, is different than absolute number? With
> rest of the cgroups systems we define absolute number at most places
> to my knowledge.
There isn't really much choice if the abstraction is a bundle of all
On Mon, Sep 14, 2015 at 08:15:23PM +0300, Jarkko Sakkinen wrote:
> The command buffer address is necessarily not naturally aligned.
> The hardware drops the entire read on some platforms and fills the
> address with 1's. This patch fixes the issue by splitting the read
> into two 32 bit reads.
Is
On Tue, Sep 15, 2015 at 12:24:41AM +0530, Parav Pandit wrote:
> On Mon, Sep 14, 2015 at 10:58 PM, Jason Gunthorpe
> <jguntho...@obsidianresearch.com> wrote:
> > On Mon, Sep 14, 2015 at 04:39:33PM +0530, Parav Pandit wrote:
> >
> >> 1. How does the % of resource,
On Mon, Sep 14, 2015 at 05:36:07PM -0400, Joseph Salisbury wrote:
> I was hoping to get your feedback, since you are the patch author. Do
> you think gathering any additional data will help diagnose this
> issue,
Jarkko may have more to add, but from my perspective, this should have
been a
On Fri, Sep 11, 2015 at 07:22:56PM +, Hefty, Sean wrote:
> Trying to limit the number of QPs that an app can allocate,
> therefore, just limits how much of the address space an app can use.
> There's no clear link between QP limits and HW resource limits,
> unless you assume a very specific
On Tue, Sep 15, 2015 at 08:38:54AM +0530, Parav Pandit wrote:
> As you precisely described, about wild ratio,
> we are asking vendor driver (bottom most layer) to statically define
> what the resource pool is, without telling him which application are
> we going to run to use those pool.
>
On Tue, Sep 15, 2015 at 01:09:56PM +0300, Jarkko Sakkinen wrote:
> However, for MMIO address the hardware might abort the entire request
> when trying to do a 64-bit read, which causes the CPU to fill the result
> with 1's.
Okay, yes, for iomem you can't rely on packed.
packed actually can mess
ontrol_area {
> u32 int_enable;
> u32 int_sts;
> u32 cmd_size;
> - u64 cmd_pa;
> + u32 cmd_pa_low;
> + u32 cmd_pa_high;
> u32 rsp_size;
> u64 rsp_pa;
What about rsp_pa?
> } __packed;
As I mentioned, drop the __packed
On Thu, Sep 17, 2015 at 04:04:19PM -0400, Sasha Levin wrote:
> Allocating a workqueue might fail, which wasn't checked so far and would
> lead to NULL ptr derefs when an attempt to use it was made.
Indeed.
Yishai, please check this and check the other patches you've sent to
see if they have a
On Tue, Sep 29, 2015 at 08:07:10PM +0300, Jarkko Sakkinen wrote:
> -static struct pnp_device_id tpm_pnp_tbl[] = {
> +static struct acpi_device_id tpm_acpi_tbl[] = {
> {"PNP0C31", 0}, /* TPM */
> {"ATM1200", 0}, /* Atmel */
> {"IFX0102", 0}, /* Infineon */
On Mon, Dec 07, 2015 at 10:59:15AM +0100, Wilck, Martin wrote:
> > IS_ERR should address the oops though??
>
> No, see my answer to Jarkko in the other part of the thread.
I'm confused, is there an oops that still need to be fixed?
> As reported before, with "force=1", I get the error message:
On Tue, Dec 01, 2015 at 11:33:51PM +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 01, 2015 at 11:58:26AM -0700, Jason Gunthorpe wrote:
> I went through the patches and didn't see anything that would shock me
> enough not to apply the patches in the current if they also work when
On Wed, Dec 02, 2015 at 01:34:38PM +0100, Wilck, Martin wrote:
> On Di, 2015-12-01 at 11:58 -0700, Jason Gunthorpe wrote:
>
> > Martin, this should fix the double loading you noticed, please confirm.
> > There
> > is a possibility the force path needs a bit mo
include/acpi/actbl2.h is the proper place for these definitions
and the needed TPM2 ones have been there since
commit 413d4a6defe0 ("ACPICA: Update TPM2 ACPI table")
This also drops the le32_to_cpu for members of this table,
consistent with other ACPI stuff.
Signed-off-by: Jason
On Wed, Dec 02, 2015 at 11:27:27AM -0700, Jason Gunthorpe wrote:
> I'm guessing that if the driver probe order is tpm_crb,tpm_tis then
> things work because tpm_crb will claim the device first? Otherwise
> tpm_tis claims these things unconditionally? If the probe order is
> reversed t
On Tue, Dec 01, 2015 at 08:52:17PM +0100, Uwe Kleine-König wrote:
> The issue I saw is: There are three(?) ways the tpm could be bound. If
> one of the succeeds, the other two are expected to fail. But in this
> case an error message, that the tpm failed to be bound is at least
> misleading.
My
On Tue, Dec 01, 2015 at 11:33:51PM +0200, Jarkko Sakkinen wrote:
> I went through the patches and didn't see anything that would shock me
> enough not to apply the patches in the current if they also work when
> tested *but* are these release critical for Linux v4.4?
>
> I got a bit confused
On Sun, Dec 06, 2015 at 06:15:44AM +0200, Jarkko Sakkinen wrote:
> You can completely ignore this question. I saw Martins reply with a fix for
> "tpm_tis: Use devm_ioremap_resource" that you should squash into that
> change.
It isn't quite the right fix - but I've added something that should be
On Fri, Dec 04, 2015 at 10:10:15AM +0100, Wilck, Martin wrote:
> The following simple change fixes the ACPI probing after applying your
> latest series. The must have been another ACPI resource that you were
> erroneously using as mem resource.
Close, acpi_dev_resource_memory destroys it's
On Thu, Dec 03, 2015 at 09:30:30AM +0100, Wilck, Martin wrote:
> On Mi, 2015-12-02 at 12:11 -0700, Jason Gunthorpe wrote:
>
> > > What is the address tpm_tis should be using? I see two things, it
> > > either uses the x86 default address or it expects the ACPI to have a
&
On Thu, Dec 03, 2015 at 10:27:53AM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 02, 2015 at 12:19:00PM -0700, Jason Gunthorpe wrote:
> > include/acpi/actbl2.h is the proper place for these definitions
> > and the needed TPM2 ones have been there since
> > commit 413d4a6defe0
ing the base address. Maybe it is cca->cmd_pa ?
>From c9f7c0465008657f7fc7880496f68f4a1b3b4a26 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe <jguntho...@obsidianresearch.com>
Date: Thu, 3 Dec 2015 10:58:56 -0700
Subject: [PATCH 3/5] tpm_tis: Do not fall back to a hardcoded address for TPM
On Tue, Dec 01, 2015 at 08:17:43AM +0100, Uwe Kleine-König wrote:
> Hello Jason,
>
> On Mon, Nov 30, 2015 at 12:27:11PM -0700, Jason Gunthorpe wrote:
> > Instead of clearing the global interrupts flag when any device
> > does not have an interrupt just pass -1
On Tue, Dec 01, 2015 at 12:50:28PM +0100, Wilck, Martin wrote:
> The patch introduces one user-visible change, because now the ACPI and
> PnP drivers are registered even with "force=1". This causes my TPM to be
> show up twice in sysfs:
Registering all the drivers is deliberate, IMHO, force
On Tue, Dec 01, 2015 at 04:19:25PM +0100, Wilck, Martin wrote:
> > > > tpm_tis_init calls tpmm_chip_alloc which barfs when pdev (i.e. the
> > > > return value
> > > > of platform_device_register_simple above) isn't bound. It is not allowed
> > > > to assume that the device is bound after the
On Tue, Dec 01, 2015 at 10:35:08AM +0200, Jarkko Sakkinen wrote:
> In addition I want this fix as a single patch, not as two-patch set.
> The first patch might have made sense when the fix was being developed
> but now it's just really akward change.
No, you are not in tune with the kernel
On Tue, Dec 01, 2015 at 08:28:35AM +0100, Uwe Kleine-König wrote:
> On Mon, Nov 30, 2015 at 12:27:12PM -0700, Jason Gunthorpe wrote:
> > The TPM core has long assumed that every device has a driver attached,
> > however b8b2c7d845d5 ("base/platform: assert that dev
On Tue, Dec 01, 2015 at 10:26:17AM -0800, Peter Huewe wrote:
>
>
> Am 1. Dezember 2015 09:25:37 PST, schrieb Jason Gunthorpe
> <jguntho...@obsidianresearch.com>:
> >On Tue, Dec 01, 2015 at 04:19:25PM +0100, Wilck, Martin wrote:
> >> > > > tpm_tis_init c
not.
Jason Gunthorpe (3):
tpm_tis: Disable interrupt auto probing on a per-device basis
tpm_tis: Use devm_ioremap_resource
tpm_tis: Clean up the force=1 module parameter
drivers/char/tpm/tpm_tis.c | 203 +++--
1 file changed, 122 insertions(+), 81
Instead of clearing the global interrupts flag when any device
does not have an interrupt just pass -1 through tpm_info.irq.
The only thing that asks for autoprobing is the force=1 path.
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
---
drivers/char/tpm/tpm_tis.
tin" <martin.wi...@ts.fujitsu.com>
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
---
drivers/char/tpm/tpm_tis.c | 170 +++--
1 file changed, 104 insertions(+), 66 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/
resource from the device right
through to devm_ioremap_resource. This ensures all the proper resource
meta-data is carried down.
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
---
drivers/char/tpm/tpm_tis.c | 29 +
1 file changed, 17 insertions(
On Tue, Dec 01, 2015 at 07:54:59PM +0100, Peter Huewe wrote:
> Can you point to that discussion or was it offline?
Apparently it was brought up at the most recent kernel summit
http://www.spinics.net/lists/linux-rdma/msg29985.html
Jason
--
To unsubscribe from this list: send the line
On Tue, Dec 01, 2015 at 08:19:18PM +0100, Uwe Kleine-König wrote:
> I'd add a comment here about the possible values of irq and their
> interpretation. Something like:
Done
> It's definitly a nice improvement of this patch that the init functions
> don't change the module parameter any more. (I
On Tue, Dec 01, 2015 at 08:22:40PM +0100, Uwe Kleine-König wrote:
> here, which IMHO reads nicer and maybe is even more efficient (I don't
> know much about x86).
Sure
> > + if (resource_size(_info.res) == 0)
> > + return -ENODEV;
> > +
>
> Does this result in an error message from
On Tue, Dec 01, 2015 at 08:33:58PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Dec 01, 2015 at 11:58:29AM -0700, Jason Gunthorpe wrote:
> > The TPM core has long assumed that every device has a driver attached,
> > however commit b8b2c7d845d5 ("base/platform:
On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote:
> The hop_limit is only suggest that the package allowed to be
> routed, not have to, correct?
If the hop limit is >= 2 (?) then the GRH is mandatory. The
SM will return this information in the PathRecord if it determines a
GRH is
On Wed, Dec 16, 2015 at 11:26:39AM +0100, Michael Wang wrote:
>
> On 12/15/2015 06:30 PM, Jason Gunthorpe wrote:
> > On Tue, Dec 15, 2015 at 05:38:34PM +0100, Michael Wang wrote:
> >> The hop_limit is only suggest that the package allowed to be
> >>
ioread32 and readl are defined to read from PCI style memory, ie little
endian and return the result in host order. On platforms where a
swap is required ioread32/readl do the swap internally (eg see ppc).
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
Tested-by: Jarkko Sa
in tpm_tis to avoid double-loading
the driver
- Re-order the init sequence so that a forced platform device gets first crack
at
loading, and excludes the other mechanisms via the above
- Checkpatch clean
- Gotos renamed
Jason Gunthorpe (7):
tpm_crb: Use the common ACPI definition
To support the force mode in tpm_tis we need to use resource locking
in tpm_crb as well, via devm_ioremap_resource.
The light restructuring better aligns crb and tis and makes it easier
to see the that new changes make sense.
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.
resource from the device right
through to devm_ioremap_resource. This ensures all the proper resource
meta-data is carried down.
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
Tested-by: Wilck, Martin <martin.wi...@ts.fujitsu.com>
Tested-by: Jarkko Sakkinen &
Instead of clearing the global interrupts flag when any device
does not have an interrupt just pass -1 through tpm_info.irq.
The only thing that asks for autoprobing is the force=1 path.
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
Tested-by: Wilck, Martin <
t;tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM
2.0")
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
Tested-by: Wilck, Martin <martin.wi...@ts.fujitsu.com>
Tested-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>
---
dri
nsistently, and the definitions
in actbl2.h do not have endianness annotations, declaring that no swap
is required. Note that the TPM ACPI spec defines all of these
values to be little endian, both in crb2 and ppi.
Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com>
Tested-by: Wilck, M
401 - 500 of 4366 matches
Mail list logo
