linux-dev/drivers/staging/rdma/hfi1, branch master

IB/hfi1: Move driver out of staging

2016-05-26T15:35:14Z

The TODO list for the hfi1 driver was completed during 4.6. In addition other objections raised (which are far beyond what was in the TODO list) have been addressed as well. It is now time to remove the driver from staging and into the drivers/infiniband sub-tree. Reviewed-by: Jubin John Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Do not free hfi1 cdev parent structure early

2016-05-26T15:35:13Z

The deletion of a cdev is not a fence for holding off references to the structure. The driver attempts to delete the cdev and then proceeds to free the parent structure, the hfi1_devdata, or dd. This can potentially lead to a kernel panic in situations where a user has an FD for the cdev open, and the pci device gets removed. If the user then closes the FD there will be a NULL dereference when trying to do put on the cdev's kobject. Fix this by pointing the cdev's kobject.parent at a new kobject embedded in its parent structure. Also take a reference when the device is opened and put it back when it is closed. Reviewed-by: Mitko Haralanov Signed-off-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Add trace message in user IOCTL handling

2016-05-26T15:35:13Z

Add a trace message to HFI1s user IOCTL handling. This allows debugging of which IOCTLs are being handled by the driver. Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Remove write(), use ioctl() for user cmds

2016-05-26T15:35:13Z

Remove the write() handler for user space commands now that ioctl handling is available. User apps will need to change to use ioctl from this point forward. Reviewed-by: Mitko Haralanov Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Add ioctl() interface for user commands

2016-05-26T15:35:06Z

IOCTL is more suited to what user space commands need to do than the write() interface. Add IOCTL definitions for all existing write commands and the handling for those. The write() interface will be removed in a follow on patch. Reviewed-by: Mitko Haralanov Reviewed-by: Mike Marciniszyn Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Remove unused user command

2016-05-26T15:23:18Z

The HFI1_CMD_SDMA_STATUS_UPD command was never implemented it has no reason to live in the driver. Remove it. Reviewed-by: Christoph Hellwig Reviewed-by: Mitko Haralanov Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Remove snoop/diag interface

2016-05-26T15:23:18Z

The snoop/diag interface is better served by an implementation which is more general and usable by other drivers perhaps. Go ahead and remove the code now and get rid of the char dev. We can put the feature back when we have a more agreeable solution. Reviewed-by: Dean Luick Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Remove EPROM functionality from data device

2016-05-26T15:23:18Z

Remove EPROM handling from the cdev which is used for user application data traffic. Reviewed-by: Dean Luick Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Remove UI char device

2016-05-26T15:23:18Z

Remove UI char device which exposes direct access to registers for user space. This was put in to aid in debugging the hardware. We are looking into alternatives means of providing the same functionality. This removes another char device from HFI1's footprint. Reviewed-by: Dean Luick Reviewed-by: Mitko Haralanov Reviewed-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford

IB/hfi1: Remove multiple device cdev

2016-05-26T15:23:17Z

hfi1 current exports a cdev that can be used to target all of the hfi's in the system. However there is a problem with this approach in that the devices could be on different subnets. This is a problem that user space can figure out and explicitly tell the driver on which device to create a context. Remove the multi-purpose cdev leaving a dedicated cdev for each port. Also remove the striping capability that is dependent upon the user choosing the multi-purpose cdev. It is now up to user space to determine how to stripe contexts. Reviewed-by: Dean Luick Reviewed-by: Mitko Haralanov Reviewed-by: Mike Marciniszyn Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford