. Loose coupling works fine here.
Signed-off-by: Jarkko Sakkinen jarkko.sakki...@linux.intel.com
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
Thanks Jarkko!
Jason
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
Looks fine, if you have to spin this again you can incorporate the
nits.
+
+static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);
Not for this patch, but while this area of code is being looked at
this should probably be an IDR/IDA like
.
Signed-off-by: Jarkko Sakkinen jarkko.sakki...@linux.intel.com
Reviewed-by: Jason Gunthorpe jguntho...@obsidianresearch.com
I like this one the most of the three I've seen :)
Did you also look in tpm_acpi.c to see if it needs to use
acpi_dev_handle somehow too?
+ union acpi_object *obj
On Mon, Sep 08, 2014 at 04:59:31PM +0100, Liviu Dudau wrote:
I don't really understand how domains are used so it's hard to provide
a recommendation here. Do domains even belong in the DT?
ACPI calls them segments and the way Bjorn explained it to me at some moment
was
that it was an
On Mon, Sep 08, 2014 at 10:36:36AM -0600, Bjorn Helgaas wrote:
Presumably these devices have PCI BARs (since that's how dev-resource
got filled in), and we want to somehow ignore them, not assign
resources to them, and not allow drivers to use whatever is mapped by
the BARs. But clearing out
On Mon, Sep 08, 2014 at 01:39:40PM -0600, Bjorn Helgaas wrote:
Essentially for that case the mvebu HW is a repurposed end port core,
so when working as a root port it presents an end port config space
(not a root port bridge config space). The BAR in that config space is
not relevant, so
test it
properly, but it compiles and doesn't muck up the no irq specified
case at least.
+ if (test_irq) {
Should be
if (test_irq !priv-irq_tested)
We don't need to msleep if we got an irq already.
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
You should post
On Wed, Aug 27, 2014 at 04:31:56AM +, Scot Doyle wrote:
I think you'll have to directly test in the tis driver if the
interrupt is working.
The ordering in the TIS driver is wrong, interrupts should be turned
on before any TPM commands are issued. This is what other drivers are
On Wed, Aug 27, 2014 at 09:32:10PM +, Scot Doyle wrote:
If suspend/resume occur before falling back to polling mode (within 30
seconds after module load), then the machine freezes on resume because
the module is waiting on the interrupts.
Okay, this is just a specific case of the
On Thu, Aug 28, 2014 at 12:35:16AM +, Scot Doyle wrote:
To move it means we have to understand why you are getting timeouts:
[ 33.247720] tpm_tis 00:08: tpm_transmit: tpm_send: error -62
[ 33.247731] tpm_tis 00:08: [Hardware Error]: TPM command timed out
during continue self
On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
The compatible string is listed as optional property for PHYs. So, not
having one is an option, I guess. But, I'd also prefer to at least keep
the -c22 one, since I saw problems when I tried using -c45 (the Zed phy
should
On Fri, Aug 29, 2014 at 11:23:57AM -0700, Florian Fainelli wrote:
On 08/29/2014 10:31 AM, Jason Gunthorpe wrote:
On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
The compatible string is listed as optional property for PHYs. So, not
having one is an option, I guess
On Fri, Aug 29, 2014 at 11:59:32PM +, Scot Doyle wrote:
(current-pending.signal.sig[0] == 0x0100 == SIGKILL?) about 30
seconds after module load begins. wait_for_tpm_stat sees that the return
value from wait_event_interruptible_timeout is positive and returns 0.
tpm_tis_send thinks
On Fri, Sep 12, 2014 at 04:06:41PM +0300, Jarkko Sakkinen wrote:
It does not make sense to construct the PCR read command in
tpm_do_selftest() when there is already a function that does
the job.
This would seem to undo an older patch, I don't think things have
changed enough for that to make
On Tue, Oct 07, 2014 at 08:01:12PM +0300, Jarkko Sakkinen wrote:
Added tpm_chip_alloc() and tpm_chip_register() where tpm_chip_alloc()
reserves memory resources and tpm_chip_register() initializes the
device driver. This way it is possible to alter struct tpm_chip
attributes before passing it
On Tue, Oct 07, 2014 at 08:01:13PM +0300, Jarkko Sakkinen wrote:
+ chip = tpm_chip_alloc(dev, tpm_tis);
+ if (!chip)
return -ENODEV;
Needs to use ERR_PTR
+ rc = tpm_chip_register(chip);
+ if (rc)
+ return -ENODEV;
Wrong ordering, this needs to
On Tue, Oct 07, 2014 at 08:01:16PM +0300, Jarkko Sakkinen wrote:
+ rc = tpm_chip_register(chip);
+ if (rc)
+ return -ENODEV;
Again, wrong order, this needs to be last in the probe function
Jason
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Tue, Oct 07, 2014 at 01:54:41PM -0400, Stefan Berger wrote:
Why add the complexity of swapping of authenticated sessions and keys
into the kernel if you can handle this in userspace? You need a library
that is aware of the number of key slots and slots for sessions in the
TPM and swaps
On Tue, Oct 07, 2014 at 09:04:17PM +0300, Jarkko Sakkinen wrote:
Did you test compile all the drivers? One of my git commits on github
has some hackery to make that possible on x86.
Yeah, I compiled all the drivers:
$ grep CONFIG_TCG .config
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
On Wed, Oct 08, 2014 at 01:28:14AM +0300, Jarkko Sakkinen wrote:
@@ -714,15 +709,10 @@ static int tpm_tis_i2c_remove(struct i2c_client
*client)
struct tpm_chip *chip = tpm_dev.chip;
release_locality(chip, chip-vendor.locality, 1);
- /* close file handles */
-
On Tue, Sep 30, 2014 at 11:07:21PM +0300, Jarkko Sakkinen wrote:
On Fri, Sep 26, 2014 at 08:19:47PM +0300, Jarkko Sakkinen wrote:
On Wed, Sep 24, 2014 at 02:46:27PM -0600, Jason Gunthorpe wrote:
That would be 24*2 files only for pcrs...
Some subsystems do just that..
$ ls /sys
On Thu, Sep 11, 2014 at 12:50:00AM +, Scot Doyle wrote:
On Mon, 8 Sep 2014, Jason Gunthorpe wrote:
On Tue, Sep 02, 2014 at 08:22:58PM +, Scot Doyle wrote:
It's spending that time (now 3 seconds) in tpm_tis_send_data.
Due to request_locality?
The first command transmitted
On Mon, Sep 22, 2014 at 12:43:27PM -0500, Ashley Lai wrote:
Hi Anton,
Thanks for the patch. Is this oops easy to recreate? If so could
you give us the steps to reproduce?
This looks like it is probably related to the uninitialization mess in
the TPM core (resource held during module
On Mon, Sep 22, 2014 at 04:09:03PM -0600, Bjorn Helgaas wrote:
On Mon, Sep 22, 2014 at 3:33 PM, Tanmay Inamdar tinam...@apm.com wrote:
+static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
+{
+ int i;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
On Tue, Sep 09, 2014 at 08:26:19AM -0600, Bjorn Helgaas wrote:
So as long as the DT tells you the ECAM information for each host
bridge, that should be sufficient. The domain number is then just a
Linux convenience and is not tied to the platform as it is on ia64.
I think this is right for
On Tue, Sep 09, 2014 at 09:44:35PM +0200, Peter Hüwe wrote:
Hi Scot,
Am Montag, 25. August 2014, 09:14:03 schrieb Scot Doyle:
commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e
wait: fix false timeouts when using wait_event_timeout()
changed the semantics of
On Tue, Sep 09, 2014 at 01:31:46PM -0600, Bjorn Helgaas wrote:
On Mon, Sep 8, 2014 at 2:04 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
On Mon, Sep 08, 2014 at 01:39:40PM -0600, Bjorn Helgaas wrote:
Essentially for that case the mvebu HW is a repurposed end port core,
so
On Tue, Sep 09, 2014 at 09:44:56PM -0500, Rob Herring wrote:
On Tue, Sep 9, 2014 at 10:41 AM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
On Tue, Sep 09, 2014 at 08:26:19AM -0600, Bjorn Helgaas wrote:
So as long as the DT tells you the ECAM information for each host
bridge
On Sat, Aug 30, 2014 at 11:23:56PM +, Scot Doyle wrote:
On Sat, 30 Aug 2014, Jason Gunthorpe wrote:
On Fri, Aug 29, 2014 at 11:59:32PM +, Scot Doyle wrote:
I tried calling tpm_get_timeouts only during the interrupt test, but again
was timed out after 30 seconds. The interrupt
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
drivers/char/tpm/tpm_tis.c | 75
+-
1 file changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2c46734..cbef80e 100644
On Mon, Nov 10, 2014 at 02:49:48PM +0200, Jarkko Sakkinen wrote:
Rename chip-dev to chip-pdev to make it explicit that this not the
character device but actually represents the platform device.
I don't really have time to take a detailed look at this for a few
weeks, but I like this entire
On Mon, Nov 10, 2014 at 02:49:49PM +0200, Jarkko Sakkinen wrote:
+static void tpm_dev_release(struct device *dev)
+{
+}
+
These patches are so close to actually fixing many of the use-after-free
problems too :)
int tpm_dev_add_device(struct tpm_chip *chip)
{
int rc;
-
On Mon, Nov 10, 2014 at 02:49:54PM +0200, Jarkko Sakkinen wrote:
if (len le32_to_cpu(cca-cmd_size)) {
- dev_err(chip-dev,
+ dev_err(chip-dev,
Is this out of sequence in the patch series?
rc = tpm2_do_selftest(chip);
- if (rc) {
-
On Sat, Sep 20, 2014 at 07:30:14AM +1000, Anton Blanchard wrote:
There is no need to cast from a void pointer to another pointer.
Looks reasonable to me:
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
Signed-off-by: Anton Blanchard an...@samba.org
Index: b/drivers/char/tpm
bad, thank you:
Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
drivers/char/tpm/tpm_i2c_atmel.c |4
drivers/char/tpm/tpm_i2c_nuvoton.c |5 +
2 files changed, 9 insertions(+)
diff --git a/drivers/char
On Wed, Sep 24, 2014 at 12:05:51PM +0300, Jarkko Sakkinen wrote:
* Separated allocation and registeration into two functions:
* tpm_chip_alloc()
* tpm_chip_register()
Okay, this is a nice start!
I had intended tpm-interface.c to hold these 'chip' functions and the
other cmd related
On Wed, Sep 24, 2014 at 12:06:00PM +0300, Jarkko Sakkinen wrote:
- if (!(chip = tpm_register_hardware(dev, tpm_tis)))
+ chip = tpm_chip_alloc(dev, tpm_tis);
+ if (!chip)
return -ENODEV;
Please put this in a separate patch, don't co-mingle it with TPM2
support. If
On Wed, Sep 24, 2014 at 12:06:01PM +0300, Jarkko Sakkinen wrote:
+ offset = cca-rsp_pa - priv-cca_pa;
+ resp = (u8 *) ((unsigned long) cca + offset);
+ memcpy(buf, resp, 6);
+ expected = be32_to_cpu(*(__be32 *) (buf + 2));
be32_to_cpup?
+static void crb_release(void *data)
On Wed, Sep 24, 2014 at 12:06:02PM +0300, Jarkko Sakkinen wrote:
Added tpm2-sysfs.c that implements sysfs attributes for a TPM2
device.
You need to document in Documentation every new sysfs that is added.
The existing ones are not documented :(
+++ b/drivers/char/tpm/tpm-interface.c
@@
On Wed, Sep 24, 2014 at 12:05:53PM +0300, Jarkko Sakkinen wrote:
+static struct tpm_input_header tpm2_pcrread_header = {
Missing const - all of these static structures in tpm2-cmds.c are missing the
const, please fix them all.
+ .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
+ .length =
On Wed, Sep 24, 2014 at 01:34:11PM -0400, Stefan Berger wrote:
On 09/24/2014 01:13 PM, Jason Gunthorpe wrote:
On Wed, Sep 24, 2014 at 12:06:02PM +0300, Jarkko Sakkinen wrote:
+static ssize_t durations_show(struct device *dev, struct device_attribute
*attr,
+ char *buf
On Wed, Sep 24, 2014 at 10:43:23PM +0300, Jarkko Sakkinen wrote:
What do you think about the way trusted module builds messages? It's
easier to maintain and debug than the approach used in the tpm
subsystem.
Do you have a source reference?
In my userspace TPM work I use a code generator to
On Wed, Sep 24, 2014 at 10:02:34PM +0300, Jarkko Sakkinen wrote:
The pcrs file never conformed to the sysfs rules, if TPM2 is getting a
whole new file set, I wouldn't mind seeing it not include the
non-conformant ones. What do you think?
I think that it's better to put extra focus on
On Wed, Sep 24, 2014 at 10:35:42PM +0200, Peter Hüwe wrote:
Am Mittwoch, 24. September 2014, 22:19:38 schrieb Jason Gunthorpe:
On Wed, Sep 24, 2014 at 10:02:34PM +0300, Jarkko Sakkinen wrote:
The pcrs file never conformed to the sysfs rules, if TPM2 is getting a
whole new file set, I
On Wed, Sep 24, 2014 at 10:39:41PM +0200, Peter Hüwe wrote:
If it is more or less a no-op since we have set
chip-vendor.duration[TPM_SHORT] for other code to work, we can show
the values for TPM2.0.
It is not a no-op, Jarkko created a whole new file for the tpm2 sysfs
interface, so the two
On Sat, Nov 01, 2014 at 11:01:35AM +0200, Jarkko Sakkinen wrote:
Added own class for TPM devices that is used for TPM 2.0 and onwards.
For TPM1 old device structure is kept for backwards compatibility.
Each struct tpm_chip represents a character device that is associated
to the tpm device
On Mon, Nov 03, 2014 at 07:41:01AM +0200, Jarkko Sakkinen wrote:
I used the class 'tpm' only for TPM 2.x because I didn't want to
break the binary compatibility for TPM 1.x anyway. In ideal situtation
both would be character devices inside the class 'tpm' and there would
be sysfs attribute
On Tue, Nov 04, 2014 at 01:47:34PM +0200, Jarkko Sakkinen wrote:
I used the class 'tpm' only for TPM 2.x because I didn't want to
break the binary compatibility for TPM 1.x anyway. In ideal situtation
both would be character devices inside the class 'tpm' and there would
be sysfs
On Tue, Nov 04, 2014 at 10:38:43PM +0200, Jarkko Sakkinen wrote:
Then a patch: Drop misc_register entirely, no compat stuff. Explain
clearly the resulting sysfs changes, CC the various people who monitor
the sysfs API, act on any feedback. I'm hoping it is an OK change.
[ If it is not OK
On Wed, Nov 05, 2014 at 09:40:29AM +0200, Jarkko Sakkinen wrote:
I mean, if we have a patch that does:
struct tpm_chip {
struct device cdev; // the class device
struct device *pdev; // the 'platform' device chip is bound too
struct device *dev = pdev; // Temporary
On Sat, Dec 27, 2014 at 01:34:51AM -0500, nick wrote:
After reading the code and trying various ways to merge these
functions into tpm.h. I am wondering if the merge is really a good
idea as it seems to break a lot of code that is very hard to trace
and redo correctly without a lot of work.
On Thu, Jan 15, 2015 at 10:34:39AM -0600, atull wrote:
This is great! The way I had it working was using Pantelis' devicetree
configfs interface.
I figured you were very close to this already in your overlay work..
The DT fragment described the FPGA logic and included a filename
for
On Thu, Jan 15, 2015 at 08:45:02PM +, One Thousand Gnomes wrote:
- Hand over to a DT overlay (how does this work?) Lock transfers
from FD to kernel
That bit isn't stateful so I would actually have expected something in
the kernel ABI along the lines of
[unfutzd the cc a bit, sorry]
On Wed, Jan 21, 2015 at 04:19:17PM -0600, atull wrote:
If we consider a Zynq, for instance, there are a number of clock nets
that the CPU drives into the FPGA fabric. These nets are controlled by
the kernel CLK framework. So, before we program the FPGA
, at 22:45 , One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On Thu, 15 Jan 2015 11:47:26 -0700
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
It is a novel idea, my concern would be that embedding the FPGA in the
DT makes it permanent unswappable kernel memory
On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote:
and I think you effectively have the user usage covered here for such
things. It much like GPIO pins - we can describe them but we can also
declare they are not visible to the user.
A missing element in mainline is a kind of
On Sun, Feb 15, 2015 at 11:40:06PM +0100, Pavel Machek wrote:
So keeping that much memory pinned in the kernel when I can prove it
is uncessary for my system (either because there is no suspend/resume
possibility, or because I know the CPU can always access the
filesytem) is very
On Tue, Jan 27, 2015 at 06:57:22PM +0200, Jarkko Sakkinen wrote:
+ /* TPM 1.2 requires self-test on resume. */
+ if (!(chip-flags TPM_CHIP_FLAG_TPM2)) {
+ ret = tpm_do_selftest(chip);
+ if (ret 0)
+ return ret;
Just to note, the return value
On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote:
There are plenty of people today who treat the FPGA as an entirely
dynamic resource. It's not like flashing a controller, its near
immediate.
But this is a completely different use case. Remember, there are
*megabytes* of
On Tue, Jan 13, 2015 at 04:28:47PM +, One Thousand Gnomes wrote:
There is a lot of code overlap in things like loading the bitstreams,
there is also some overlap because you want to be able to assign FPGA
resources. For example if you have four FPGAs and you want to use one for
OS stuff
On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
the FPGA image. If someone wants there to be only one FPGA image on
the FGPA forever, they will probably not be using this framework; their
FPGA will probably be loaded before Linux boots up.
Nonsense, loading the FPGA through Linux is
On Mon, Mar 30, 2015 at 10:30:36AM +0200, Michael Wang wrote:
Thus I also agreed check inside mcast_event_handler() is unnecessary,
maybe we can change that logical to WARN_ON(!cap_mcast()) ?
Seems reasonable to me.
Jason
--
To unsubscribe from this list: send the line unsubscribe
On Mon, Mar 30, 2015 at 05:10:12PM +0200, Michael Wang wrote:
I found that actually we don't have to touch this one which
only used by HW driver currently.
I'm having a hard time understanding this, the code in question was in
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
Which is the NFS ULP, not
On Tue, Mar 31, 2015 at 08:51:13PM -0400, ira.weiny wrote:
Going forward we want to NAK stuff like this:
if (rdma_ib_mgmt() || rdma_opa_mgmt())
if (has_sa() || has_opa_foobar())
I'm confused.
Is the idea that you would NAK has_sa but be in favor of has_ib_sa?
It is the || I
On Mon, Mar 30, 2015 at 01:02:03PM -0400, Doug Ledford wrote:
If we use something like this, then the above is all you need. Then
every place in the code that checks for something like has_sa or cap_sa
can be replaced with rdma_ib_mgmt.
I don't want to see this slide back into some ill
On Mon, Mar 30, 2015 at 12:13:00PM -0400, Doug Ledford wrote:
On Fri, 2015-03-27 at 16:47 +0100, Michael Wang wrote:
Introduce helper has_iwarp() to help us check if an IB device
support IWARP protocol.
This is a needless redirection. Just stick with the original
On Fri, Mar 27, 2015 at 01:16:31PM -0400, ira.weiny wrote:
On Fri, Mar 27, 2015 at 10:13:19AM -0600, Jason Gunthorpe wrote:
On Fri, Mar 27, 2015 at 04:47:36PM +0100, Michael Wang wrote:
Introduce helper has_iwarp() to help us check if an IB device
support IWARP protocol.
Should
On Fri, Mar 27, 2015 at 01:05:08PM -0400, ira.weiny wrote:
But it seems redudent, since mcast_add_one will already not add a port that
is
not IB, so mcast_event_handler is not callable. Something to do with
rocee/ib switching?
I'm not sure about this either. This check seems to be
On Fri, Mar 27, 2015 at 06:31:26PM +0100, Yun Wang wrote:
Maybe we can temporarily reserve the old logical, and gradually solve
these problems?
It is best to make behavioral changes in small patches, yes.
I think it is best to address these sorts of problems before trying to
tackle the driver
On Fri, Mar 27, 2015 at 10:52:10AM +0100, Michael Wang wrote:
Basically I found there are three kind of check in current
implementation:
1. check transport type of device only
I'd like to use helper has_XX(device)
which means some port of the device has XX capability.
2. check
On Fri, Mar 27, 2015 at 05:15:42PM +0100, Michael Wang wrote:
I'm not sure if it's a good idea, but seems like the idea is use twice
check on different level to save some cycles?
That is what it looks like to me, right now. Which is why I'd drop
it. This isn't performance sensitive, make it
On Fri, Mar 27, 2015 at 04:46:57PM +0100, Michael Wang wrote:
Introduce helper has_mcast() and cap_mcast() to help us check if an
IB device or it's port support Multicast.
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Ira Weiny ira.we
On Fri, Mar 27, 2015 at 04:48:22PM +0100, Michael Wang wrote:
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 3341754..fcd7558 100644
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1655,7 +1655,7 @@ static void
On Fri, Mar 27, 2015 at 04:44:43PM +0100, Michael Wang wrote:
Introduce helper cap_smi() to help us check if the port of an
IB device support Subnet Management Interface.
This and most of the others should be qualified with 'cap_ib_smi'
since we already know we will need 'cap_opa_smi' someday
On Fri, Mar 27, 2015 at 04:47:36PM +0100, Michael Wang wrote:
Introduce helper has_iwarp() to help us check if an IB device
support IWARP protocol.
Should probably be !has_rdma_read_sges()
True if the device can handle more than one SGE entry on a RDMA READ
work request.
Jason
--
To
On Thu, Mar 26, 2015 at 05:58:20PM +0100, Michael Wang wrote:
The questions is just wondering how the transition method could be, but
if we have to do the changes for vendor, that sounds like a tough job...
I would see changing how the information is represented in the struct
as a follow on
On Tue, Jan 13, 2015 at 03:37:14PM -0600, atull wrote:
I do agree with this, and I think this is where this patch set goes so
wrong.
Just exposing all sorts of controls to userspace and having a way for
the kernel to load/unload a bitstream compleletely misses the point that
the two
On Mon, Apr 13, 2015 at 02:25:16PM +0200, Michael Wang wrote:
dev_list = kmalloc(sizeof *dev_list, GFP_KERNEL);
if (!dev_list)
@@ -1673,13 +1671,19 @@ static void ipoib_add_one(struct ib_device *device)
}
for (p = s; p = e; ++p) {
- if
On Mon, Apr 13, 2015 at 07:25:48PM +, Hefty, Sean wrote:
@@ -1037,17 +1033,13 @@ void rdma_destroy_id(struct rdma_cm_id *id)
mutex_unlock(id_priv-handler_mutex);
if (id_priv-cma_dev) {
- switch (rdma_node_get_transport(id_priv-id.device-
node_type)) {
-
On Mon, Apr 13, 2015 at 06:40:35PM +, Hefty, Sean wrote:
- if (rdma_node_get_transport(ib_device-node_type) !=
RDMA_TRANSPORT_IB)
- return;
+ int count = 0;
I'm ok with this as an intermediate patch but going forward if we are
going to
have calls like
static
On Mon, Apr 13, 2015 at 03:46:03PM -0400, ira.weiny wrote:
This doesn't quite look right, it should be 'goto error1'
Looks like you replied to the wrong patch. ?? I don't see error1 in
ipoib_add_one.
For the ib_cm module...
Right, sorry.
Yes I think it should go to error1.
On Mon, Apr 13, 2015 at 02:36:45PM +0200, Michael Wang wrote:
We have finished introducing the cap_XX(), and raw helper rdma_ib_or_iboe()
is no longer necessary, thus clean it up.
So, the net result is not looking too bad, but I'm confused about the
structure of this series.
Why introduce
compatibility
with the 1.x devices, a symlink is created to the platform device
directory.
Signed-off-by: Jarkko Sakkinen jarkko.sakki...@linux.intel.com
Reviewed-by: Jason Gunthorpe jason.guntho...@obsidianresearch.com
Jumping the gun a bit, there :)
But yes, the TPM bits still look OK to me
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now
On Wed, Apr 22, 2015 at 11:38:34AM +, Liran Liss wrote:
This is redundant. All IB ports have SMI, so if you know that you
are using an IB device, you know you have an SMI.
You should really go back and read the whole thread, this has already
been discussed.
The patch set was developed
On Tue, Apr 21, 2015 at 01:37:55PM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
This is probably OK, but I think you should also remove the qib_wc_pat
module
On Tue, Apr 21, 2015 at 02:50:35PM -0700, Luis R. Rodriguez wrote:
- if (qib_wc_pat) {
- resource_size_t vl15off;
- /*
- * We do not set WC on the VL15 buffers to avoid
- * a rare problem with unaligned writes from
- *
On Mon, Apr 20, 2015 at 10:41:38AM +0200, Michael Wang wrote:
Introduce helper cap_ipoib() to help us check if the port of an
IB device support IP over Infiniband.
I thought we were dropping this in favor of listing the actual
features the ULP required unconditionally? One of my messages had
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
Mike, do you think the time is right to just remove the iPath driver?
With PAT now being default the driver effectively won't work
with write-combining on modern kernels. Even if systems are old
they likely had PAT support,
On Wed, Apr 22, 2015 at 07:38:55PM +0300, Jarkko Sakkinen wrote:
+EXPORT_SYMBOL_GPL(kernfs_remove_by_name_ns);
??
I don't see this being called
My bad, it is clutter in the patch file. I'll remove it.
In fact this is needed because the driver uses kernfs_remove_by_name,
On Wed, Apr 22, 2015 at 10:59:52AM -0400, Doug Ledford wrote:
2)The name rdma_tech_* is lame.
rdma_transport_*(), adhering to the above (*) remark, is much better.
For example, both IB and ROCE *do* use the same transport.
I especially want to second this. I haven't really been happy
On Wed, Apr 22, 2015 at 10:49:44AM +0200, Michael Wang wrote:
On 04/22/2015 07:40 AM, Jason Gunthorpe wrote:
On Mon, Apr 20, 2015 at 10:41:38AM +0200, Michael Wang wrote:
Introduce helper cap_ipoib() to help us check if the port of an
IB device support IP over Infiniband.
I
On Wed, Apr 22, 2015 at 12:46:01AM +0200, Luis R. Rodriguez wrote:
are talking about annotating the qib driver as known to be broken without
PAT
and since the ipath driver needs considerable work to be ported to
use PAT (the
This only seems to be true for one of the chips that driver
On Fri, Apr 24, 2015 at 03:15:54PM +, Liran Liss wrote:
From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
+static inline int rdma_tech_iboe(struct ib_device *device, u8 port_num)
+{
+ return device-query_transport(device, port_num)
+ ==
On Fri, Apr 24, 2015 at 03:00:15PM +, Liran Liss wrote:
Currently, the only code in the kernel that has an SMI interface is IB.
When OPA is introduced, add the proper helper.
We already have tests checking for SMI is supported so QP0 can be
created, this is to support ROCEE
All I am
On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
To be precise, the split is that ipath powers the old HTX bus cards that
only work in AMD systems, qib is all PCI-e cards. I still have a few
HTX cards, but I no longer have any systems with HTX slots, so we
haven't even used this
On Mon, Apr 20, 2015 at 03:02:03PM +0200, Jens Wiklander wrote:
It appeared to me this driver was copying TPM's old architecture,
which is very much known to be broken.
The struct tee_device holds a shared memory pool from which shared
memory objects are allocated. These shared memory
On Mon, Apr 20, 2015 at 08:20:44AM +0200, Jens Wiklander wrote:
I'm not sure I understand what you mean. This function is a building
block for the TEE driver to supply whatever interface is needed for user
space. For a Global Platform like TEE it will typically have support for
On Mon, Apr 20, 2015 at 04:54:32PM +0200, Greg Kroah-Hartman wrote:
On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
I still suspect the expected way to write a new mid layer is to create
your own struct device and not rely on misc_device,
Yes, that is the way. You can
On Mon, Apr 20, 2015 at 10:51:58AM -0500, Tom Tucker wrote:
On 4/20/15 10:16 AM, Michael Wang wrote:
On 04/20/2015 04:00 PM, Steve Wise wrote:
On 4/20/2015 3:40 AM, Michael Wang wrote:
[snip]
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 6805e3e..e4999f6 100644
+++
301 - 400 of 4366 matches
Mail list logo
