> Thanks, I'll get the mthca patch upstream. I think the following is > also required -- any review is appreciated.
I hadn't realized the newer Mellanox driver had some of its code in drivers/net. Yesterday, I had looked at its drivers/infiniband portion and saw that your proposed change to hw/mlx4/main.c looked good. I agree with the changes you've made. However, I had a new concern about both the mthca and mlx4 changes so far: Are we sure using the phys_addr_t type is the correct thing to do? I know it is for the PowerPC platform. When I checked my Linux tree for phys_addr_t it was only present for PowerPC and Intel architectures. So, I was worried that it might not be appropriate for other architectures. But I now see that the newer trees do define phys_addr_t for all platforms (defined in linux/types.h). And, resource_size_t is now defined using phys_addr_t. That is the type returned from pci_resource_start(), which is where we normally acquire the value to pass to ioremap(). This all happened at 2.6.28, so I'm a victim of running such an old level (I'm still at 2.6.26). I think therefore that all is well with this change. By the way, the only reason I'm using mthca is because my hardware has a 4-lane slot. If I had 8-lanes, I would be trying to use mlx4. -- 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.html