> Subject: [PATCH] staging: rdma: use setup_timer() api
>
> From: Hari Prasath Gujulan Elango
>
Doug,
We are going to add this to the rdmavt/hfi1/qib work, with the appropriate
authorship credit. Otherwise, there will certainly be conflicts.
Hari,
Note that ehca is going away.
In additio
> Subject: [PATCH RESEND] staging: rdma: hfi1: diag: constify hfi1_filter_array
> structure
>
> The hfi1_filter_array structure is never modified, so declare it as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Thanks for the patch and for resubmitting.
Acked-by:
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Julia Lawall
> Subject: [PATCH] staging: rdma: hfi1: diag: constify hfi1_filter_array
> structure
>
> The hfi1_filter_array structure is never modified, so declare it as const.
>
> Done with the help of Coccinell
Greg,
We have other patch series close to being submitted.
Some depend on the inflight patches you are behind on, some on each other.
What is the best way of handling this to insure no conflicts?
Mike
___
devel mailing list
de...@linuxdriverproject.or
> --- a/drivers/staging/rdma/hfi1/chip.c
> +++ b/drivers/staging/rdma/hfi1/chip.c
> @@ -10128,8 +10128,7 @@ static void init_qos(struct hfi1_devdata *dd,
> u32 first_ctxt)
> goto bail;
> if (num_vls * qpns_per_vl > dd->chip_rcv_contexts)
> goto bail;
> - rsmmap
> @@ -10129,6 +10129,9 @@ static void init_qos(struct hfi1_devdata *dd,
> u32 first_ctxt)
> if (num_vls * qpns_per_vl > dd->chip_rcv_contexts)
> goto bail;
> rsmmap = kcalloc(NUM_MAP_REGS, sizeof(u64), GFP_KERNEL);
> + if (!rsmmap)
> + goto bail;
> +
I che
> > Add aeth name syndrome decode
>
> Again, why?
>
This fix is to enhance debugging.
The IBTA RC ACK contains an ACK extended transport header.
Part of that header is the syndrome field that qualifies the RC ACK as an ACK,
NAK, or RNR NAK.
Without the patch here is the syndrome decode:
aeth
> >
> > Is the inprocess branch available?
>
> I do not understand what you mean here :(
Does it fail to apply to staging-next or staging-testing or something else?
Mike
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverpr
> That sounds like a horrid hack, and this implies that a slower machine will
> still have this problem...
Greg,
I'm NAK'ing this patch for two reasons:
1. Code underneath the CONFIG option is only used during rework
2. It is a hack as you have noted
We are going to take this up internally to ge
>
> To that end, I've opened my 4.4-rc branch and deleted the three deprecated
> drivers from staging and moved hfi1 to the rdma tree. I've sent an email to
> Linus to see if he's ok taking those changes, and if so, I'll get them
> submitted
> and then open up my for-4.5 branch early to be able
> > Are you saying dev_dbg() is a better choice?
>
> Yes, why would a user ever want to see that above line? What can they do
> with it?
Will do.
Mike
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/
> > The longest quiet timeout is now 6s. Extend the driver wait.
>
> To what? And why? What does this fix?
>
The driver wasn't following the our internal specification: 6 seconds.
The patch corrects that issue.
Mike
___
devel mailing list
de...@li
> > drivers/staging/rdma/hfi1/sdma.c | 12 ++--
> > 1 files changed, 10 insertions(+), 2 deletions(-)
>
> Doesn't apply to my tree :(
Ok.
Is the inprocess branch available?
Mike
___
devel mailing list
de...@linuxdriverproject.org
http://dri
> > + dd_dev_info(dd, "%s: program XMT margin, CcePcieCtrl 0x%llx\n",
> > + fname, pcie_ctrl);
>
> Why spam the log with this all the time? Shouldn't this be a debug line
> instead?
The current implementation is layered on dev_info().
Are you saying dev_dbg() is a better choice?
> > From: Dean Luick
> >
> > Correctly reduce the number of VLs when limited by the number of SDMA
> > engines.
>
> why? What does this "solve"?
The hardware has multiple egress mechanisms, SDMA and pio, and multiples of
those.
These mechanisms are chosen using the VL (8)
The fix corrects a
> > Clean up comments
>
> In what way?
>
The patch deleted numbering and terms internal to intel.
The information on the actual bugs is not deleted.
Mike
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mail
> > Add CNP opcode decode
>
> Why?
Prior to this patch the trace appeared like:
-0 [001] d.h. 94062.578932: input_ibhdr: [:05:00.0] vl 0 lver 0
sl 0 lnh 2,LRH_BTH dlid 0003 len 6 slid 0001 op 0x80,0x80 se 0 m 0 pad 0 tver 0
pkey 0x8001 f 0 b 0 qpn 0x001234 a 0 psn 0x
Note the "o
> Cc: Sunny Kumar
> Subject: [PATCH v2 1/1] staging: rdma: hfi1 : Prefer using the BIT macro
>
> This patch replaces bit shifting on 1 with the BIT(x) macro
>
> Signed-off-by: Sunny Kumar
> ---
Thanks for the patch!
Acked-by: Mike Marciniszyn
___
de
> Subject: [PATCH 1/1] staging: rdma: hfi1 : Prefer using the BIT macro
>
> This patch replaces bit shifting on 1 with the BIT(x) macro
>
> Signed-off-by: Sunny Kumar
> ---
Nak.
The patch leaves the shift in.
Mike
___
devel mailing list
de...@linuxd
> Subject: [PATCH] IB/hfi1: class_name_user() should be static
>
> Fixes the following sparse warning:
> drivers/staging/rdma/hfi1/device.c:127:12:
> warning: symbol 'class_name_user' was not declared. Should it be static?
>
> Signed-off-by: Geliang Tang
> ---
Thanks for the patch!
Acked-b
> Subject: [PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer
>
Thanks for the patch!
Acked-by: Mike Marciniszyn
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-dev
> Subject: [PATCH] IB/hfi1: use kvfree() in sdma.c
>
> Use kvfree() instead of open-coding it.
>
> Signed-off-by: Geliang Tang
> ---
> drivers/staging/rdma/hfi1/sdma.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Thanks for the patch.
Acked-by: Mike Marciniszyn
___
> Subject: [patch] IB/hfi1: fix copy_to/from_user() error handling
>
> copy_to/from_user() returns the number of bytes which we were not able to
> copy. It doesn't return an error code.
>
> Also a couple places had a printk() on error and I removed that because
> people can take advantage of it
> Subject: [PATCH 11/39] hfi1: drop null test before destroy functions
>
> Remove unneeded NULL test.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@ expression x; @@
> -if (x != NULL)
> \(kmem_cache_destroy\|mempool_destroy\|dma_pool_de
> Subject: [PATCH] drivers:staging:hfi1: Fix coding style issues
>
> From: Sergey Lysanov
>
> This patch fixes the following issues reported by checkpatch.pl:
> - code indent should use tabs where possible
>
> Signed-off-by: Sergey Lysanov
> ---
Doug,
Can you stage this with your github serie
> Subject: Re: [PATCH] MAINTAINERS: Add maintainer section for hfi1
>
> On Tue, Aug 18, 2015 at 04:04:15PM +, Marciniszyn, Mike wrote:
> > > > +HFI1 DRIVER
> > > > +M: Mike Marciniszyn
> > > > +L: linux-r...@vger.kernel.org
> >
> Subject: Re: [PATCH] Kconfig: add temporary PCI dependency
>
> On Tue, Aug 18, 2015 at 10:15:42AM -0400, Mike Marciniszyn wrote:
> > The move from infiniband to staging requires a temporary PCI
> > dependency to fix 0-day build issues. The
> > drivers/infiniband/hw/Kconfig gratuitously added it
> > +HFI1 DRIVER
> > +M: Mike Marciniszyn
> > +L: linux-r...@vger.kernel.org
> > +L: de...@driverdev.osuosl.org
> > +S: Supported
> > +F: drivers/staging/hfi1
>
> Why do this for a driver that is being deleted?
>
You are thinking of ipath. This is a new driver.
Mike
_
> A: these and other similar errors:
>
> In file included from ../drivers/staging/hfi1/chip.c:61:0:
> ../drivers/staging/hfi1/chip.c: In function â__hfi1_trace_LINKVERBâ:
> ../drivers/staging/hfi1/trace.h:1357:20: error: function
> â__hfi1_trace_LINKVERBâ can never be inlined because it u
Greg,
We are in the process of submitting an RDMA driver for the Intel OPA
architecture.
The current massive patch set is submitted to add the driver to the infiniband
tree.
I'm wondering if the staging area is a better spot to land the driver at first?
That way everyone can see it being rew
30 matches
Mail list logo
