> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a mess
> --- 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
> Being a non native English speaker I am not fully sure, but "copyin
> corrupting" sounds like slang / street talking... proper English please
>
> > Commit e622f2f4ad21 ("IB: split struct ib_send_wr") introduced a
> > regression for HCAs whose user mode post sends go through
> > ib_uverbs_post_se
> On Mon, Nov 02, 2015 at 12:13:25PM -0500, Mike Marciniszyn wrote:
> > The current implementation gets a spin_lock, and at any scale with qib
> > and hfi1 post send, the lock contention grows exponentially with the
> > number of QPs.
> >
> > idr_find() is RCU compatibile, so read doesn't need the
> > drivers/staging/rdma/hfi1/qp.c
> >817 if (attr_mask & IB_QP_PATH_MIG_STATE) {
> >818 qp->s_mig_state = attr->path_mig_state;
> >819 if (mig) {
> >820 qp->remote_ah_attr = qp->alt_ah_attr;
> >821
> drivers/staging/rdma/hfi1/qp.c
>817 if (attr_mask & IB_QP_PATH_MIG_STATE) {
>818 qp->s_mig_state = attr->path_mig_state;
>819 if (mig) {
>820 qp->remote_ah_attr = qp->alt_ah_attr;
>821
> The patch d7b8ba5121e8: "staging/rdma/hfi1: pre-compute sc and sde for
> RC/UC QPs" from Nov 9, 2015, leads to the following static checker warning:
>
> drivers/staging/rdma/hfi1/verbs.c:1657 ah_to_sc()
> error: buffer overflow 'ibp->sl_to_sc' 32 <= 255
>
> drivers/staging/rdma/hfi1
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
> 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
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo in
>
> 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
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to major
> > + 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordom
> > 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
--
To unsubscribe from this list: send the line "u
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the
> > Subject: [PATCH] fix return value error
> >
>
> I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (-
> ENOMEM), ramfs (-ENOSPC), vfs (-ENOMEM).
>
> Not entirely consistent but this matches the majority.
>
> I agree -EPERM is pretty misleading.
>
> Acked-by: Mike Marciniszyn
> Subject: [PATCH] fix return value error
>
I checked returns in configfs (-ENOMEM), proc (-ENOENT), proc-sys (-ENOMEM),
ramfs (-ENOSPC), vfs (-ENOMEM).
Not entirely consistent but this matches the majority.
I agree -EPERM is pretty misleading.
Acked-by: Mike Marciniszyn
--
To unsubscribe fr
> > The lkey table is allocated with with a get_user_pages() with an
> Don't you mean __get_free_pages?
>
I was a nit in the original upstream commit.
I don’t think it is a big deal since the patch context clarifies.
Mike
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
��
> Subject: [PATCH] staging/rdma: Kconfig change STAGING_RDMA to be
> tristate.
>
> From: Ira Weiny
>
> STAGING_RDMA was failing to build when INFINIBAND was set to 'm' and
> STAGING_RDMA was set to 'y'.
>
> Making this a tristate properly inherits the 'm' from the INFINIBAND setting.
>
This p
Doug,
I think we need to apply http://www.spinics.net/lists/linux-rdma/msg27914.html
and https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg26989.html.
We just got http://marc.info/?l=linux-rdma&m=144311398317945&w=2. Whatever we
tried to do in the parent directory isn't working, and
> Subject: [PATCH] staging/rdma/hfi1: do not use u8 to store a 32-bit integer
>
Thanks for the patch!
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
> 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] 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
--
To unsubscri
> Subject: [PATCH] IB/hfi: Properly set permissions for user device files
>
> From: Ira Weiny
> Signed-off-by: Haralanov, Mitko
> Signed-off-by: Ira Weiny
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@
> 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
>
> Source code is
>
> if (count < 64 && count> 32768)
> return SDMA_DESCQ_CNT;
>
> Maybe better code
>
> if (count < 64 || count> 32768)
> return SDMA_DESCQ_CNT;
>
>
Correct and thanks!
I will prepare a patch.
Mike
--
To unsubscribe from this list: send the line "u
> Subject: [PATCH] IB/hfi1: fix pstateinfo from returning improperly
> byteswapped value
>
> From: Ira Weiny
>
> Byteswap link_width_downgrade_*_active values before sending on the
> wire. In addition properly define the Port State Info structure.
>
> Reviewed-by: Dennis Dalessandro
> Reviewe
> 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: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix
>
> Remove the 'CONFIG_' prefix of the Kconfig options PRESCAN_RXQ and
> SDMA_VERBOSITY in Kconfig. Such prefix in Kconfig requires a double
> 'CONFIG_CONFIG_' prefix in Make and CPP syntax.
>
Doug, can you pull this one in?
T
> 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-rdma@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-rdma@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
--
To unsubscribe from th
> Subject: [PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix
> Signed-off-by: Valentin Rothberg
> ---
Thanks for the patch!
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majord
> > From: Dennis Dalessandro
> >
> > inline in trace functions causes the following build error when
> > CONFIG_OPTIMIZE_INLINING is not defined in the kernel config:
> > error: function can never be inlined because it uses variable argument
> > lists
>
> There are all manner of tracing things in
> Subject: [PATCH v2] IB/hfi1: Remove inline from trace functions
>
v2 adjusts some of the comment text to clarify adding new traces.
An updated PSM library is available at:
https://www.openfabrics.org/downloads/infinipath-psm/infinipath-psm-3.3-6_gca75825_open.tar.gz
The update addresses the following issues:
- Adds support for 2^20 MPI ranks, up from 2^16
- Fixes issue with exhaustion of send tid dma descriptors
- Fixes perfo
> > {
> > @@ -599,25 +581,21 @@ static ssize_t show_tempsense(struct device
> > *device,
> > /* start of per-unit file structures and support code */ static
> > DEVICE_ATTR(hw_rev, S_IRUGO, show_rev, NULL); static
> > DEVICE_ATTR(board_id, S_IRUGO, show_hfi, NULL); -static
> > DEVICE_ATTR(versi
> Subject: [PATCH for-4.3 14/15] qib: Support ib_alloc_mr verb
>
> Signed-off-by: Sagi Grimberg
This did require repair of the to-be-rebased/for-4.3 branch to
"revert IB/core: Guarantee that a local_dma_lkey is available" and replace with
a corrected version.
Tested-by: Vinit Agnihotri
Acked-b
> Subject: Re: [PATCH] RDMA/amso1100: deprecate the amso1100 provider
>
> On 07/29/2015 10:44 AM, Steve Wise wrote:
> > The HW hasn't been sold since 2005, and the SW has definite bit rot.
> > Its time to remove it. So move it to staging for a few releases and
> > then remove it after that.
> >
>
>
> > If that wasn't done, the HW can't be changed, we are stuck with wonky
> > sysfs files.. Try and get it right next time
>
> And lspci as well as other tools will not be able to distinguish between
> different versions of the hardware.
Sorry if I misled.
We do fully support the PCI revisio
> > > > > +HFI1
> > > > > +
> > > > > + The hfi1 driver also creates these additional files:
> > > > > +
> > > > > + hw_rev - hardware revision
> > >=20
> > > I'm checking on this to see if it is indeed a duplicate.
> > >=20
> >
> > Our hardware architect has indicated there is not PCIe equivale
> > > +HFI1
> > > +
> > > + The hfi1 driver also creates these additional files:
> > > +
> > > + hw_rev - hardware revision
>
> I'm checking on this to see if it is indeed a duplicate.
>
Our hardware architect has indicated there is not PCIe equivalent for this case.
Mike
--
To unsubscribe f
> Subject: [PATCH for-4.3 14/15] qib: Support ib_alloc_mr verb
>
Doug,
Have you staged this anywhere?
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info
> > There is no PCIe equivalent.
> >
> > > > + serial - board serial number
> >
> > No PCIe equivalent.
> >
> > > > + boardversion - board version
>
> These all have PCI-E versions. Most should live in the config space VPD.
>
I'm not seeing VPD in our current cards.
I'm checking to make sur
> > +HFI1
> > +
> > + The hfi1 driver also creates these additional files:
> > +
> > + hw_rev - hardware revision
I'm checking on this to see if it is indeed a duplicate.
> > + board_id - manufacturing board id
There is no PCIe equivalent.
> > + version - driver version
This IS a duplic
> On 07/30/2015 04:01 PM, Marciniszyn, Mike wrote:
> >>
> >> I thought you were getting rid of this?
> >>
> >> Jason
> >
> > Doug wanted the v4 submitted as we currently have it.
>
> To be accurate, I said "If you want a chance at m
> The opcode is 0x80, which appears in the protocol part of the 8 bit opcode.
> That is what is specified in A3.10.2 of the 1.3 spec.
>
Correction A10.3.2.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More maj
> > > That is obvious and useless. Patches should have a meaningful
> > > description and justify the changes.
> > >
> >
> > The driver uses the CNP opcode for congestion control.
>
> And that requires a new transport protocol???
>
The opcode is 0x80, which appears in the protocol part of the 8
Hal,
I missed this email. Ira and I agree with the comments.
We will address this quickly with a follow up patch.
Sorry,
Mike
> -Original Message-
> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il]
> Sent: Wednesday, June 17, 2015 10:13 AM
> To: Marciniszyn, Mike
> That is obvious and useless. Patches should have a meaningful description
> and justify the changes.
>
The driver uses the CNP opcode for congestion control.
> Why do you add the CNP opcode and what in the world does it do? CNP is
> what? And why do the other enum values not work for you?
The
>
> I thought you were getting rid of this?
>
> Jason
Doug wanted the v4 submitted as we currently have it.
Doug?
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/m
> Bart Van Assche help us and resulting patch you can see below:
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
> b/drivers/infiniband/ulp/srp/ib_srp.c
> index c5af67a..470eb54 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -59,6 +59,7 @@
>
> This is the 3rd time in a row {(1) ipath (2) qib (3) OPA Gen1} for you guys to
> implement IB transports in SW @ your low-level drivers.
>
> So... enough is enough, please put it in a (say) libibtrans kernel module
> residing in the IB core and use it in this driver, to begin with.
>
I like th
> But personally, I hate seeing write() used to emulate ioctl() because 'ioctl
> is
> bad'. ie if you are 'writing' a struct that contains user pointers and you
> expect the kernel to read/write to user memory, then use ioctl. (and that is
> the 'badness' of ioctl, so pretending it is write doesn'
> Ummm.. Could we get some more descriptions as to what this code is for?
>
The next set with contain a great deal more background info in the cover letter.
> Do we have a new OmniPath protocol here as well or is it IB? Which
> standards are followed?
>
This will be covered in the additional i
> > This sysfs entries are used by PSM2 to form packets from user space.
>
> You didn't explain what's SC and what's SC-to-VL and why PSM2 can't talk to
> the SM to query that.
>
SC stands for Service Channel and is a Fabric wide concept.
These tables are used to as to perform the following map
>
> so what's the role of the char-device? why should a low-level driver which is
> part of the upstream RDMA stack contain a char-device?
>
> Or.
>
Contains additional char devices:
- PSM character device
- diagnostic character devices
The nature of the hardware requires both of these additio
> anything wrong with the umem services provided by the IB core that
> requires this implementation? what?
>
The current level of the API is mismatched with the PSM SDMA.
The ib_umem api:
- maps an SG list which isn't required by PSM since DMA mapping is done by the
low level SDMA
- the mapping
> netlink is a reasonable low speed format to use for this kind of
> serialization,
> either via the common mux or via your own char device.
>
A couple of follow-up netlink questions.
1. I assume you are talking about generic netlink vs. say the RDMA netlink.
The generic netlink handles dynam
> Subject: [PATCH V2 2/5] ipath,qib: Expose max_sge_rd correctly
>
> Applications must not assume that max_sge and max_sge_rd are the same,
> Hence expose max_sge_rd correctly as well.
>
> Signed-off-by: Steve Wise
Thanks!
Acked-by: Mike Marciniszyn
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay�
Doug,
We have been given the go ahead to start the deprecation process for thie ipath
driver.
What do I need to do to get that done?
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
> > + * hfi1_get_user_pages - lock user pages into memory
> > + * @start_page: the start page
> > + * @num_pages: the number of pages
> > + * @p: the output page structures
> > + *
> > + * This function takes a given start page (page aligned user virtual
> > + * address) and pins it and the followi
> Ummm... This looks eerily similar to qib_verbs_mcast.c. Sed job on the file?
> Is
> there any way to get a description as to what the differences are between qib
> and hfi?
>
We are working on what can be said on OPA and the hardware.
We chose to impact qib as little as possible with this dr
>
> > include/rdma/opa_port_info.h | 433
>
> This matches the current code structure, but is this the best location for
> this file?
Do you have a suggestion?
Mike
> > > Do you have a link to this comment? I'm missing a bunch of messages
> > > from
> > this thread and can't find anything from Al in the logs.
> >
>
> This commit appeared in qib and it did not appear on linux-rdma. I never saw
> it
> until it appeared.
>
> I emailed on list to Al in http:/
> > +/*
> > + * Generic trap/notice types
> > + */
> > +#define IB_NOTICE_TYPE_FATAL 0x80
> > +#define IB_NOTICE_TYPE_URGENT 0x81
> > +#define IB_NOTICE_TYPE_SECURITY0x82
> > +#define IB_NOTICE_TYPE_SM 0x83
> > +#define IB_NOTICE_TYPE_INFO0x84
>
Moved to ib_mad.h in v3.
>
> what's SC and what's SC-to-VL? aren't you using SM to do such mappings? if
> this
> and the below sysfs work-around/s for the maybe current lack of SM to
> configure the port? why do the upstream kernel has to carry ~hundreds of sysfs
> entries forever for such non-documented things?
>
This
> > Do you have a link to this comment? I'm missing a bunch of messages from
> this thread and can't find anything from Al in the logs.
>
This commit appeared in qib and it did not appear on linux-rdma. I never saw
it until it appeared.
I emailed on list to Al in http://marc.info/?l=linux-rdm
> Fix the issue by changing the type of wc_cookie to int. For the success case
> the
> ret left at zero to avoid a warning from the caller. For failure wc_cookie
> is used
> as the ret.
>
Just commit message change.
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+
Al,
In commit
commit 4961772560d2f19695c73ece943716033ad62ac2
Author: Al Viro
Date: Sat Apr 4 00:11:32 2015 -0400
infinibad: weird APIs switched to ->write_iter()
Things Not To Do When Writing A Driver, part 1001st:
have writev() and write() on the same file doing completely
> > 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
> parameter.
>
> Jason
Revise based on Jason's request and I will do some testing.
Mike
--
To unsubscr
> Subject: [patch] IB/ipath: remove some left over code
Thanks for the patch!
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
> Subject: [PATCH V2] IB/qib: add blank line after declaration
>
> Upstream checkpatch now requires this.
Just alters original summary.
Mike
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Rickard Strandqvist
> Sent: Saturday, December 20, 2014 11:19 AM
> To: infinipath; Roland Dreier
> Cc: Rickard Strandqvist; Hefty, Sean; Hal Rosenstock; linux-
> r...@vger.kernel.org; linux-ker...@vge
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Sunday, January 11, 2015 9:05 AM
> Subject: [PATCH] IB: qib: qib_iba7322: Remove unused function
>
Roland, can you change the summary to:
IB/qib: Remove unused function in qib_iba7322
Thanks for the patch!
An updated PSM library is available at:
https://www.openfabrics.org/downloads/infinipath-psm/infinipath-psm-3.3-2_g6f42cdb_open.tar.gz.
The update fixes a build issue with RHEL7
(http://bugs.openfabrics.org/bugzilla/show_bug.cgi?id=2475) and adds the knx
PSM code.
Mike
--
To unsubscribe from t
> Subject: [PATCH] qib: qib_qp: Replace rcu_assign_pointer() with
> RCU_INIT_POINTER()
>
Why not consolidate this with
http://marc.info/?l=linux-rdma&m=140836578119485&w=2 so there is just one patch?
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a m
> Subject: [PATCH] qib_keys: Replace rcu_assign_pointer() with
> RCU_INIT_POINTER()
>
I would prefer the summary be:
IB/qib: qib_remove_lkey() Replace rcu_assign_pointer() with
> RCU_INIT_POINTER()
Otherwise the patch looks ok and has been tested.
--
To unsubscribe from this list: send the line
> Subject: [PATCH] qib_qp: Replace rcu_assign_pointer() with
> RCU_INIT_POINTER()
>
I would prefer the summary line be:
IB/qib: remove_qp() use RCU_INIT_POINTER() instead of rcu_assign_pointer()
Otherwise I agree with the patch and I have tested it with large numbers of QPs.
Mike
--
To unsubscr
>
> No, it's not necessary. It turns out that the result cannot be greater than
> the
> requested maximum value.
>
> Julia
Ok.
No stable then.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo i
> Subject: [PATCH 9/10] IB/qib: use safer test on the result of
> find_first_zero_bit
>
> From: Julia Lawall
Thanks for the patch!
Roland, I'm marking this as stable since a memory corruption can occur in the
_set_bit().
Cc:
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send
> Subject: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in
> hw/qib/qib_keys.c
>
> Signed-off-by: Monam Agarwal
Thanks for the patch!
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kern
> Subject: [PATCH] drivers/infiniband: Use RCU_INIT_POINTER(x, NULL) in
> hw/qib/qib_qp.c
>
> Signed-off-by: Monam Agarwal
Thanks for the patch!
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel
> And struct ipath_dma_mapping_ops was converted to C99 initializer.
>
This is now mentioned in the ipath patch.
> It's just a matter of making patch "[PATCH 1/4] IB/core: Remove overload in
> ib_sg_dma*" the last one.
>
> BTW, You might want to provide a better explanation in the drivers functions
> remove patches (just duplicate the explanation).
Take a look at the latest series.
Mike
This patch just cc's ehca folks.
Sorry I forgot on first one.
Mike
> Subject: [PATCH v2] IB/ehca: remove ib_sg_dma_address() and ib_sg_dma_len()
> Subject: [PATCH infiniband] IB/qib: qib_user_sdma_rb_root can be static
>
> CC: CQ Tang
> CC: Roland Dreier
> Signed-off-by: Fengguang Wu
Thanks for the patch.
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to ma
> Subject: [PATCH for v3.14 5/5] IB/qib: fixup indentation in qib_ib_rcv()
>
> Signed-off-by: Yann Droneaud
Thanks for the patch!
Tested-by: Mike Marciniszyn
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord
> Subject: [PATCH for v3.14 4/5] IB/qib: add missing braces in
> do_qib_user_sdma_queue_create()
>
> Signed-off-by: Yann Droneaud
Thanks for the patch!
Tested-by: Mike Marciniszyn
Acked-by: Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body o
> Was this patch ever accepted upstream? I don't see this on git.kernel.org.
>
Roland is the RDMA/IB maintainer.
The timing is up to him.
Mike
> Subject: [patch] IB/qib: cleanup qib_register_observer()
>
> Returning directly is easier to read than do-nothing gotos. Remove the
> duplicative check on "olp" and pulled the code in one indent level.
>
> Signed-off-by: Dan Carpenter
Thanks for the patch!
Acked-by: Mike Marciniszyn
--
To
> Subject: [PATCH 2/2] qib: Use pci_enable_msix_range() instead of
> pci_enable_msix()
>
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers using these two
> interfaces need to be updated to use the new pci_enable_msi_range() and
1 - 100 of 155 matches
Mail list logo
