On 2/22/2019 10:36 AM, Jason Gunthorpe wrote:
> On Sun, Feb 17, 2019 at 06:09:09PM +0100, Håkon Bugge wrote:
>> During certain workloads, the default CM response timeout is too
>> short, leading to excessive retries. Hence, make it configurable
>> through sysctl. While at it, also make number of
On 1/29/2019 7:26 AM, Joel Nider wrote:
> As discussed at LPC'18, there is a need to be able to register a memory
> region (MR) on behalf of another process. One example is the case of
> post-copy container migration, in which CRIU is responsible for setting
> up the migration, but the contents o
On 1/23/2019 3:44 PM, Jason Gunthorpe wrote:
> On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote:
>> The kmalloc is called with | __GFP_NOFAIL so there is no point in
>> checking the return value - it either returns valid storage or it would
>> hang/terminate there. But it is n
On 1/23/2019 12:30 PM, Jason Gunthorpe wrote:
> On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote:
>> The kmalloc is called with | __GFP_NOFAIL so there is no point in
>> checking the return value - it either returns valid storage or it would
>> hang/terminate there. But it is
On 1/23/2019 12:30 PM, Jason Gunthorpe wrote:
> On Sun, Jan 20, 2019 at 02:27:13AM +0100, Nicholas Mc Guire wrote:
>> The kmalloc is called with | __GFP_NOFAIL so there is no point in
>> checking the return value - it either returns valid storage or it would
>> hang/terminate there. But it is
Hey Greg,
On 1/22/2019 9:17 AM, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Steve Wise
> Cc:
nt(&rdev->lldi.pdev->dev,
> wq->memsize, &wq->dma_addr,
> GFP_KERNEL);
> if (!wq->queue)
> goto err_free_rqtpool;
>
> - memset(wq->queue, 0, wq->memsize);
> dma_unmap_addr_set(wq, mapping, wq->dma_addr);
>
> wq->bar2_va = c4iw_bar2_addrs(rdev, wq->qid, CXGB4_BAR2_QTYPE_EGRESS,
>
Acked-by: Steve Wise
->dma_addr);
> wq->doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr;
> if (!kernel_domain)
>
Acked-by: Steve Wise
->dma_addr);
> wq->doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr;
> if (!kernel_domain)
>
Acked-by: Steve Wise
utx_cmd = (T3_UTX_MEM_WRITE << 28) | (addr + i * 3);
> utx_cmd <<= 32;
> - utx_cmd |= (utx_len << 28) | ((utx_len << 2) + 1);
> + utx_cmd |= ((u64)utx_len << 28) | ((utx_len << 2) + 1);
> *wqe = cpu_to_be64(utx_cmd);
> wqe++;
> copy_data = (u8 *) data + i * 96;
>
Acked-by: Steve Wise
n Wang
> Subject: Re: [PATCH] iw_cxgb4: fix a missing-check bug
>
> On Sat, Oct 20, 2018 at 6:41 PM Steve Wise
> wrote:
> >
> > Hey Wenwen,
> >
> > > Subject: [PATCH] iw_cxgb4: fix a missing-check bug
> > >
> > > In c4iw_flush_hw_cq, the n
Hey Wenwen,
> Subject: [PATCH] iw_cxgb4: fix a missing-check bug
>
> In c4iw_flush_hw_cq, the next CQE is acquired through t4_next_hw_cqe(). In
> t4_next_hw_cqe(), the CQE, i.e., 'cq->queue[cq->cidx]', is checked to see
> whether it is valid through t4_valid_cqe(). If it is valid, the address of
t; corresponding values from that type so Clang is satisfied without
> changing the meaning of the code.
>
> T4_BAR2_QTYPE_EGRESS = CXGB4_BAR2_QTYPE_EGRESS = 0
> T4_BAR2_QTYPE_INGRESS = CXGB4_BAR2_QTYPE_INGRESS = 1
>
> Reported-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
Looks correct, Thanks.
Acked-by: Steve Wise
iniband/hw/cxgb4/qp.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
Acked-by: Steve Wise
ker...@vger.kernel.org>; Steve Wise
> Subject: Re: linux-next: build failure after merge of the block tree
>
> On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote:
> > >> inline_page_count = num_pages(port->inline_data_size);
> > >>
Hey Stephen:
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell
> Date: Thu, 26 Jul 2018 14:32:15 +1000
> Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/nvme/host/rdma.c | 2 +-
> drive
On 5/30/2018 5:25 PM, Jason Gunthorpe wrote:
> On Wed, May 30, 2018 at 05:10:35PM -0500, Steve Wise wrote:
>>
>> On 5/30/2018 5:04 PM, Jason Gunthorpe wrote:
>>> On Wed, May 30, 2018 at 11:58:18PM +0200, Arnd Bergmann wrote:
>>>> The newly added fill_re
On 5/30/2018 5:04 PM, Jason Gunthorpe wrote:
> On Wed, May 30, 2018 at 11:58:18PM +0200, Arnd Bergmann wrote:
>> The newly added fill_res_ep_entry function fails to link if
>> CONFIG_INFINIBAND_ADDR_TRANS is not set:
>>
>> drivers/infiniband/hw/cxgb4/restrack.o: In function `fill_res_ep_entry':
On 5/14/2018 1:09 PM, Steve Wise wrote:
>
> On 5/14/2018 1:03 PM, Jason Gunthorpe wrote:
>> On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the rdma tree, today's linux-next build (x86_64
>>>
On 5/14/2018 1:03 PM, Jason Gunthorpe wrote:
> On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the rdma tree, today's linux-next build (x86_64
>> allmodconfig) produced this warning:
>>
>> drivers/infiniband/hw/cxgb4/restrack.c: In function 'fill_r
/cxgb4: use skb_put_zero()/__skb_put_zero
>
> Use the recently introduced helper to replace the pattern of
> skb_put_zero/__skb_put() && memset().
>
> Signed-off-by: YueHaibing
Looks ok.
Reviewed-by: Steve Wise
On 3/22/2018 9:52 AM, Sinan Kaya wrote:
> On 3/22/2018 9:40 AM, Steve Wise wrote:
>> I think all these iw_cxgb4 changes should be reverted until we really have a
>> plan for multi-platform that works.
> I know you are looking to have support for PowerPC.
>
> Isn'
>
> On 2018-03-22 08:24, ok...@codeaurora.org wrote:
> > On 2018-03-22 02:44, kbuild test robot wrote:
> >> Hi Sinan,
> >>
> >> Thank you for the patch! Yet something to improve:
> >>
> >> [auto build test ERROR on linus/master]
> >> [also build test ERROR on v4.16-rc6 next-20180321]
> >> [if your
gt; src++;
> > > dst++;
> > > count--;
> >
> > This is another case where writes can be re-ordered.. IIRC dst is WC
> > BAR memory, so the NIC should tolerate re-ordering, but Steve will
> > have to ack this.
> >
>
> Yes, this is WC BAR memory. The goal is that pio_copy() will enable
write-
> combining this into a single 64B pci-e transaction.
>
I'd like to see the PPC issue resolved...but
Acked-by: Steve Wise
> On Mon, Mar 19, 2018 at 10:47:46PM -0400, Sinan Kaya wrote:
> > Code includes wmb() followed by writel(). writel() already has a barrier
on
> > some architectures like arm64.
> >
> > This ends up CPU observing two barriers back to back before executing
> the
> > register write.
> >
> > Since code
IDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> +wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb();
> }
>
>
Yes, this is what chelsio recommended to me.
Reviewed-by: Steve Wise
>
> On 3/16/2018 5:05 PM, Steve Wise wrote:
> >> Code includes wmb() followed by writel(). writel() already has a barrier
> > on
> >> some architectures like arm64.
> >>
> >> This ends up CPU observing two barriers back to back before executing
>
> On Fri, Mar 16, 2018 at 04:05:10PM -0500, Steve Wise wrote:
> > > Code includes wmb() followed by writel(). writel() already has a
barrier
> > on
> > > some architectures like arm64.
> > >
> > > This ends up CPU observing two barriers back to
> Code includes wmb() followed by writel(). writel() already has a barrier
on
> some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code already has an explicit barrier call, changing writel() to
> writel_relaxed
>
> cxio_dbg.c is uncompiled since commit 2b540355cd2f ("RDMA/cxgb3:
> cleanups")
> 10 years after, we could remove it.
>
> Signed-off-by: Corentin Labbe
Acked-by: Steve Wise
gt; > drivers/infiniband/hw/cxgb4/qp.c | 6 +++---
> > drivers/infiniband/hw/cxgb4/t4.h | 4 ++--
> > 4 files changed, 22 insertions(+), 26 deletions(-)
>
> Steve? This changes the format of the debugfs files, so please ack it
> if it is Ok..
>
red. Should it be static?
>
> Signed-off-by: Colin Ian King
Looks correct. This fixes a recent commit.
Reviewed-by: Steve Wise
Fixes: 1c8f1da5d851 ("iw_cxgb4: Fix possible circular dependency locking
warning")
Thanks,
Steve.
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Also removes an unused timer.
>
> Cc: Steve Wise
> Cc: Doug Ledford
> Cc:
>
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Also removes an unused timer and
> drops a redundant initialization.
>
>
ue stored to 'sqp' during its
> initialization is never read"
>
> Fixes: a58e58fafdff ("RDMA/cxgb3: Wrap the software send queue pointer as
> needed on flush")
> Signed-off-by: Colin Ian King
Acked-by: Steve Wise
> I have put the patch v3 in the following location:
> https://github.com/longlimsft/linux-next/tree/patch_v3
>
> I will be sending it out soon. Please give it a try.
>
Hey Long, how do I request a CIFS RDMA mount from the Linux client? Is
there a mount.cifs option? If so, where can I get the
> >
> > Hey Long,
> >
> > What testing have you done with this on the various rdma transports? Does
> > it work over IB, RoCE, and iWARP providers?
>
> Hi Steve,
>
> Currently all the tests have been done over Infiniband. We haven't tested on
RoCE
> or iWARP, but planned to do it in the followin
>
> From: Long Li
>
> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport
protocol
> for transferring upper layer (SMB2) payload over RDMA via Infiniband, RoCE or
> iWARP. The prococol is published in [MS-SMBD] (https://msdn.microsoft.com/en-
> us/library/hh536346.aspx).
>
Mustafa Ismail
Looks good.
Reviewed-by: Steve Wise
> Initialize the port_num for iWARP in rdma_init_qp_attr.
>
> Signed-off-by: Mustafa Ismail
Looks fine.
Reviewed-by: Steve Wise
Acked-by: Steve Wise
>
> > + p2pmem_debugfs_root = debugfs_create_dir("p2pmem", NULL);
> > + if (!p2pmem_debugfs_root)
> > + pr_info("could not create debugfs entry, continuing\n");
> > +
>
> Why continue? I think it'd be better to just fail it.
>
Because not having debugfs support isn't fatal to usin
>
>
> > +static void setup_memwin_p2pmem(struct adapter *adap)
> > +{
> > + unsigned int mem_base = t4_read_reg(adap,
> CIM_EXTMEM2_BASE_ADDR_A);
> > + unsigned int mem_size = t4_read_reg(adap,
> CIM_EXTMEM2_ADDR_SIZE_A);
> > +
> > + if (!use_p2pmem)
> > + return;
>
> This is wei
| 22 +--
> 10 files changed, 368 insertions(+), 362 deletions(-)
Looks good (and thanks).
Reviewed-by: Steve Wise
4 +-
> drivers/infiniband/hw/cxgb4/qp.c | 5 +-
> drivers/infiniband/hw/cxgb4/resource.c | 18 +++-
> drivers/infiniband/hw/cxgb4/t4.h | 2 +-
> 10 files changed, 97 insertions(+), 129 deletions(-)
>
Looks good (and thanks).
Reviewed-by: Steve Wise
> +#endif
Is the ifdef/undef needed? I see other modules just define pr_fmt() regardless.
Otherwise, looks good (and thanks).
Reviewed-by: Steve Wise
| 2 +-
> drivers/infiniband/hw/cxgb3/iwch_provider.c | 101 +++---
> drivers/infiniband/hw/cxgb3/iwch_provider.h | 9 +-
> drivers/infiniband/hw/cxgb3/iwch_qp.c | 60
> 13 files changed, 329 insertions(+), 330 deletions(-)
>
Looks good (and thanks).
Reviewed-by: Steve Wise
Acked-by: Steve Wise
>
> Use CXGB3_... instead of CXBG3_...
>
> Signed-off-by: Nicolas Iooss
Acked-by: Steve Wise
Acked-by: Steve Wise
used in the file in which it is declared
> and don't need a declaration, but can be made static.
> so this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie
> Reviewed-by: Yuval Shaia
> Reviewed-by: Leon Romanovsky
Ignore my comment on v2...
Acked-by: Steve Wise
> Subject: [PATCH v2] fix:infiniband:hw:cxgb4:qp:mark symbols static where
possible
>
Is "fix:infiniband:hw:cxgb4:qp:" some standard way patches are being submitted
these days? Usually it would be the module name, something like:
iw_cxgb4: make _free_qp() static
Steve
AIM has been set to ensure forward progress under
> memory pressure.
>
> Signed-off-by: Bhaktipriya Shridhar
Looks fine.
Reviewed-by: Steve Wise
WQ_MEM_RECLAIM has been set to ensure forward progress under
> memory pressure.
>
> Signed-off-by: Bhaktipriya Shridhar
Looks fine.
Reviewed-by: Steve Wise
n set to ensure forward progress under
> memory pressure.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Steve Wise
M has been set to ensure forward progress under
> memory pressure.
>
> Signed-off-by: Bhaktipriya Shridhar
Acked-by: Steve Wise
>
> On Tue, Aug 02, 2016 at 09:12:54AM -0500, Steve Wise wrote:
> > Acked-by: Steve Wise
> >
>
> I have to ask, why did you ack all these? There's several things wrong with
> this patch series, but even the point of the patch is mistaken. It makes
> readabl
Acked-by: Steve Wise
Acked-by: Steve Wise
Acked-by: Steve Wise
Acked-by: Steve Wise
Acked-by: Steve Wise
Acked-by: Steve Wise
> >
> > Updating to 1.6.0 of makedumpfile didn't help. :(
> >
>
> Does anyone else have suggestions on how to debug this? From my original
> post, the dump kernel just reboots and I'm not sure why. Where can I add
> printks to gather more info on why the dump kernel gives on on the dump?
Seems
> > >> Also what's the content of your /etc/kdump.conf file?
> > >>
> > >
> > > #raw /dev/sda5
> > > #ext4 /dev/sda3
> > > #ext4 LABEL=/boot
> > > #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
> > > #net my.server.com:/export/tmp
> > > #net u...@my.server.com
> > > path /var/crash
> > > #ext4 /de
> >> Also what's the content of your /etc/kdump.conf file?
> >>
> >
> > #raw /dev/sda5
> > #ext4 /dev/sda3
> > #ext4 LABEL=/boot
> > #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
> > #net my.server.com:/export/tmp
> > #net u...@my.server.com
> > path /var/crash
> > #ext4 /dev/nvme0n1
> > core_col
> -Original Message-
> From: nborisov [mailto:n.borisov.l...@gmail.com]
> Sent: Friday, June 24, 2016 10:07 AM
> To: Steve Wise; linux-kernel@vger.kernel.org
> Subject: Re: vmcore not getting created on linux-4.7
>
>
>
> On 24.06.2016 17:45, Steve Wise wro
I've been trying to get crash dumps working on linux-4.7 and haven't succeeded.
The kdump kernel boots up and appears to be chugging along and then just reboots
and never creates the vmcore, and fails to create the vmcore-dmesg.txt, though
I've never seen that working on my nodes. Below is the tai
>
> Hey Sean,
>
> Am I correct here? IE: Is it ok for the rdma application to rdma_reject() and
> rmda_destroy_id() the CONNECT_REQUEST cm_id _inside_ its event handler as
> long
> as it returns 0?
>
> Thanks,
>
> Steve.
Looking at rdma_destroy_id(), I think it is invalid to call it from the
>
> The above nvmet cm event handler, nvmet_rdma_cm_handler(), calls
> nvmet_rdma_queue_connect() for CONNECT_REQUEST events, which calls
> nvmet_rdma_alloc_queue (), which, if it encounters a failure (like creating
> the qp), calls nvmet_rdma_cm_reject () which calls rdma_reject(). The
> non-zer
> Either
> > > nvmet should reject and destroy the cm_id, or it should do neither and
> > > return non-zero to the RDMA_CM to reject/destroy.
> >
> > Can you just send a patch?
>
> Yes, I'll send it out in a separate email.
Before I do, what do you think of this (untested)?
diff --git a/drivers/
> On Thu, Jun 09, 2016 at 06:03:51PM -0500, Steve Wise wrote:
> > The above nvmet cm event handler, nvmet_rdma_cm_handler(), calls
> > nvmet_rdma_queue_connect() for CONNECT_REQUEST events, which calls
> > nvmet_rdma_alloc_queue (), which, if it encounters a failure (lik
> > +
> > +static int nvmet_rdma_cm_handler(struct rdma_cm_id *cm_id,
> > + struct rdma_cm_event *event)
> > +{
> > + struct nvmet_rdma_queue *queue = NULL;
> > + int ret = 0;
> > +
> > + if (cm_id->qp)
> > + queue = cm_id->qp->qp_context;
> > +
> > + pr_debug("%s (%d)
> > +
> > +static struct nvmet_rdma_queue *
> > +nvmet_rdma_alloc_queue(struct nvmet_rdma_device *ndev,
> > + struct rdma_cm_id *cm_id,
> > + struct rdma_cm_event *event)
> > +{
> > + struct nvmet_rdma_queue *queue;
> > + int ret;
> > +
> > + queue = kzalloc(sizeof(*que
ested-by: Steve Wise
>
> Fixes: b955150ea784 ('RDMA/cxgb3: When a user QP is marked in error, also mark
> the CQs in error')
> Signed-off-by: Honggang Li
Nice catch. Your fix looks correct.
Reviewed-by: Steve Wise
i_resource_start(rdev->lldi.pdev, 2),
>
> This changes the format string to use %pR instead, which pretty-prints
> the resource, avoids the warning and is shorter.
>
> Signed-off-by: Arnd Bergmann
> ---
> This is an old warning I see rarely on ARM randconfig builds.
Acked-by: Steve Wise
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Sagi Grimberg
> Sent: Monday, November 23, 2015 4:36 AM
> To: Steve Wise; 'Christoph Hellwig'; linux-r...@vger.kernel.org
> Cc: ba
> -Original Message-
> From: Sagi Grimberg [mailto:sa...@dev.mellanox.co.il]
> Sent: Monday, November 23, 2015 4:29 AM
> To: Steve Wise; 'Christoph Hellwig'; linux-r...@vger.kernel.org
> Cc: bart.vanass...@sandisk.com; ax...@fb.com; linux-s...@vger.ke
On 11/18/2015 8:06 AM, Christoph Hellwig wrote:
On Wed, Nov 18, 2015 at 01:32:19PM +0200, Sagi Grimberg wrote:
Christoph,
Given the discussion around this patch I think it would
be a good idea remove it from the patchset since it's not
mandatory for the CQ abstraction. I think that we should
ta
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org
> [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Sagi Grimberg
> Sent: Monday, November 16, 2015 12:38 PM
> To: Steve Wise; 'Christoph Hellwig'; linux-r...@vger.kernel.org
> Cc: ba
> -Original Message-
> From: Steve Wise [mailto:sw...@opengridcomputing.com]
> Sent: Monday, November 16, 2015 10:38 AM
> To: Sagi Grimberg; Christoph Hellwig; linux-r...@vger.kernel.org
> Cc: bart.vanass...@sandisk.com; ax...@fb.com; linux-s...@vger.kernel.org;
On 11/15/2015 3:34 AM, Sagi Grimberg wrote:
+
+struct ib_stop_cqe {
+struct ib_cqecqe;
+struct completion done;
+};
+
+static void ib_stop_done(struct ib_cq *cq, struct ib_wc *wc)
+{
+struct ib_stop_cqe *stop =
+container_of(wc->wr_cqe, struct ib_stop_cqe, cqe);
+
+c
On 11/13/2015 7:46 AM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/core/cq.c | 46
include/rdma/ib_verbs.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/infiniband/core/cq.c b/drivers/in
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Sunday, August 30, 2015 3:12 PM
> To: sw...@chelsio.com
> Cc: dledf...@redhat.com; sean.he...@intel.com; hal.rosenst...@gmail.com;
> linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATC
Acked-by: Steve Wise
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Wednesday, August 26, 2015 7:22 PM
> To: sw...@chelsio.com
> Cc: dledf...@redhat.com; sean.he...@intel.com; hal.rosenst...@gmail.com;
> linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PA
Is this change really worth the effort?
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Thursday, July 16, 2015 1:34 PM
> To: sw...@chelsio.com
> Cc: dledf...@redhat.com; sean.he...@intel.com; hal.rosenst...@gmail.com;
> linux-r...@vger.kernel.org; linux
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Wednesday, July 15, 2015 9:38 PM
> To: sw...@chelsio.com
> Cc: dledf...@redhat.com; sean.he...@intel.com; hal.rosenst...@gmail.com;
> linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PAT
On 4/20/2015 3:40 AM, Michael Wang wrote:
Introduce helper cap_iw_cm() to help us check if the port of an
IB device support IWARP Communication Manager.
Cc: Hal Rosenstock
Cc: Steve Wise
Cc: Tom Talpey
Cc: Jason Gunthorpe
Cc: Doug Ledford
Cc: Ira Weiny
Cc: Sean Hefty
Signed-off-by
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Thursday, April 16, 2015 11:43 AM
> To: Michael Wang
> Cc: Roland Dreier; Sean Hefty; Hal Rosenstock; linux-r...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Tom Tucker; S
: Hal Rosenstock; Tom Tucker; Steve Wise; Hoang-Nam Nguyen; Christoph
> Raisch; Mike Marciniszyn; Eli Cohen; Faisal Latif; Upinder
> Malhi; Trond Myklebust; J. Bruce Fields; David S. Miller; Ira Weiny; PJ
> Waskiewicz; Tatyana Nikolova; Or Gerlitz; Jack Morgenstein; Haggai
> Eran; Ily
.kernel.org;
> net...@vger.kernel.org; Hal Rosenstock; Tom Tucker; Steve Wise; Hoang-Nam
> Nguyen; Christoph Raisch; Mike Marciniszyn; Eli Cohen;
> Faisal Latif; Upinder Malhi; Trond Myklebust; J. Bruce Fields; David S.
> Miller; Ira Weiny; PJ Waskiewicz; Tatyana Nikolova; Or
Gerlitz; Jack
&g
>
> > diff --git a/drivers/infiniband/core/sysfs.c
> > b/drivers/infiniband/core/sysfs.c
> > index cbd0383..aa53e40 100644
> > --- a/drivers/infiniband/core/sysfs.c
> > +++ b/drivers/infiniband/core/sysfs.c
> > @@ -248,14 +248,10 @@ static ssize_t phys_state_show(struct ib_port *p,
> > struct port
Acked-by: Steve Wise
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Steve Wise
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org
> [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Rasmus Villemoes
> Sent: Thursday, February 05, 2015 5:33 PM
> To: Steve Wise; Roland Dreier; Sean Hefty; Hal Rosenstock
> Cc
Acked-by: Steve Wise
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Steve Wise
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org]
> On Behalf Of Rickard Strandqvist
> Sent: Sunday, August 17, 2014 5:40 PM
> To: Steve Wise; Roland Dreier
> Cc: Rickard Strandqvist; Sean Hefty; Hal R
On 7/29/2014 5:50 PM, David Miller wrote:
From: Himangi Saraogi
Date: Mon, 28 Jul 2014 20:59:38 +0530
Delete successive assignments to the same location.
A simplified version of Coccinelle semantic match that finds this problem is as
follows:
//
@@
expression i;
@@
*i = ...;
i = ...;
//
1 - 100 of 337 matches
Mail list logo
