> 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

Reply via email to