Re: [RFC] Proposal to address hfi1 UI and EPROM devices

Jason Gunthorpe
2016-05-03T17:31:30Z

On Mon, May 02, 2016 at 03:55:02PM -0400, Dennis Dalessandro wrote:
> 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.

Yah, the places I've seen regmap used don't seem to match this use
case.

> 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.

You should probably use resource0 as much as possible - that minimizes
the kernel code required.

> 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.

.. and use debugfs just for that little bit of shared locking you need
to make resource0 work out.

Minimizing the kernel impact for debugging code is generally desirable.

> 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

I would be fine with this if you moved the eeprom handling to user
space and used resource0.

Less fine if the code remains in the kernel but just moves to debugfs.

Jason