The hfi1 driver has a "UI" device associated with it. This is currently a
char dev. It is used for debugging/diagnostics. Basically it provides direct
user level access to HW registers. We have been exploring options to remove
this char dev, yet retain the same functionality.
One approach we have considered is using the regmap interface. This has a
number of problems. It is primarily a read only interface. The write
capability is not even available as a compile time option. A code change is
needed to make use of it. There are other issues as well such as being 32bit
when we need 64bit. So this seems like the wrong option.
Another approach is using the driver's resource0 file. We can mmap() the BAR
and access the registers. The main drawback we have with that is we have
some hardware requirements that the driver needs to arbitrate access to
certain registers. This means some form of kernel/user space shared locking.
We are currently not aware of anything that the kernel provides to achieve
this. However, we are still looking and would appreciate any pointers.
The third approach would be to take our existing UI implementation and plop
it down in debugfs as a binary file. We can control our locking just as we
do today, in the driver. This gets rid of the character device, and it's not
even available unless the admin decides to mount debugfs.
We also should be able to use any of these schemes to handle our eprom
reading/writing. Adding eprom to IPoIB as Doug suggested is a fine plan, but
we technically don't need to do it right now when we could make do with the
"UI" functionality and hide the details in user space. In the future there
may well be value in having an eprom capability in the rdma sub-system, but
for now we believe we can avoid extending the kernel in this regard.
-Denny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
