IB/hfi1: checking for NULL instead of IS_ERR

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would oops on failure.

Signed-off-by Dan Carpenter <[email protected]>

Quoted 4 lines · Dan Carpenter

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would oops on failure.

Signed-off-by Dan Carpenter <[email protected]>

Thanks, applied.

Quoted 4 lines · Dan Carpenter

Quoted 3 lines

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would oops on failure.

Quoted 3 lines

Quoted 1 line

Signed-off-by Dan Carpenter <[email protected]>

Thanks, applied.

Applied to what? Should I just ignore these types of patches and not take them in my tree and you will send them on later on? I don't remember what we agreed to do, sorry.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html

Quoted 10 lines · Doug Ledford

Quoted 7 lines · Dan Carpenter

Quoted 4 lines

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would oops on failure.

Signed-off-by Dan Carpenter <[email protected]>

Thanks, applied.

Quoted 3 lines

Applied to what? Should I just ignore these types of patches and not take them in my tree and you will send them on later on? I don't remember what we agreed to do, sorry.

My recollection was that Doug was going to handle the staging/rdma sub-tree because of the large churn he expected between the rdma subsystem and those drivers.

Therefore, I have been submitting my patches against staging/rdma/hfi directly to Doug and Linux-rdma.

Quoted 4 lines · Doug Ledford

Quoted 3 lines · Dan Carpenter

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would oops on failure.

Quoted 3 lines

Quoted 1 line

Signed-off-by Dan Carpenter <[email protected]>

Thanks, applied.

Applied to what? Should I just ignore these types of patches and not take them in my tree and you will send them on later on? I don't remember what we agreed to do, sorry.

Quoted 5 lines · Greg Kroah-Hartman

Quoted 4 lines · Doug Ledford

Quoted 3 lines · Dan Carpenter

__get_txreq() returns an ERR_PTR() but this checks for NULL so it would oops on failure.

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

Signed-off-by Dan Carpenter <[email protected]>

Thanks, applied.

Applied to what? Should I just ignore these types of patches and not take them in my tree and you will send them on later on? I don't remember what we agreed to do, sorry.

My understanding was that I would handle everything in the staging/rdma area. To that end, I tried to make it explicit so that people would know that via the following things:

From MAINTAINERS:

INFINIBAND SUBSYSTEM

M:      Doug Ledford <[email protected]>
M:      Sean Hefty <[email protected]>
M:      Hal Rosenstock <[email protected]>
L:      [email protected]
W:      http://www.openfabrics.org/
Q:      http://patchwork.kernel.org/project/linux-rdma/list/
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
S:      Supported
F:      Documentation/infiniband/
F:      drivers/infiniband/
F:      drivers/staging/rdma/
F:      include/uapi/linux/if_infiniband.h
F:      include/uapi/rdma/
F:      include/rdma/

And from drivers/staging/rdma/Kconfig:

menuconfig STAGING_RDMA
bool "RDMA staging drivers"
depends on INFINIBAND
depends on PCI || BROKEN
depends on HAS_IOMEM
depends on NET
depends on INET
default n
---help---
This option allows you to select a number of RDMA drivers that fall into one of two categories: deprecated drivers being held here before finally being removed or new drivers that still need some work before being moved to the normal RDMA driver area.

If you wish to work on these drivers, to help improve them, or to report problems you have with them, please use the [email protected] mailing list.

If in doubt, say N here.

I was hoping those two items would be sufficient to keep people from flooding devel@ and yourself personally with fixups for these items and instead they would send them through linux-rdma@.

But, that's already not happening, as is obvious by my inbox.

So, how about you forward on what you have so far to me, and I'll keep these. Otherwise you will end up with nasty merge issues very quickly as people will continue to send stuff to me.

Quoted 1 line · Greg Kroah-Hartman

But, that's already not happening, as is obvious by my inbox.

Yeah, I see that.

Quoted 3 lines

So, how about you forward on what you have so far to me, and I'll keep these. Otherwise you will end up with nasty merge issues very quickly as people will continue to send stuff to me.

As you wish. I pulled in a number of patches related to hfi1, but I've already sent the pull request to Linus and they made it as of 4.1-rc2. So, just start from there and you will have all the patches I've taken.

Doug Ledford will be handling all the patches related to drivers/staging/rdma/. Patches for those files are not to be sent to Greg and devel mailing list.

Signed-off-by Sudip Mukherjee <[email protected]>

---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

MAINTAINERS +0 -0

index cf1a98d..95b9ecb 100644