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

On Thu, May 05, 2016 at 02:38:58PM -0600, Jason Gunthorpe wrote:

On Thu, May 05, 2016 at 03:32:32PM -0400, Doug Ledford wrote:

quoted

On 05/05/2016 03:20 PM, Jason Gunthorpe wrote:

quoted

On Thu, May 05, 2016 at 02:57:01PM -0400, Doug Ledford wrote:
 

quoted

and the eeprom is written with the new data.  If you need to do special
things, like Mellanox, in terms of recovering burned data like GIDs
or

The 'eeprom' and device firmware are very different things. hfi1 has
both, and uses request_firmware too.

I've never heard of a driver using ethtool eeprom to deal with nv
firmware like mlx has.

There's no reason it couldn't.  Since you can pass offset and length
parameters and write things in multiple chunks, you can actually set up
access to eeprom, nv ram, and firmware all through the one interface
simply by defining the start/stop points of each to be at specific, well
known locations for your device.

Well, sort of.

firmware write tends to be super-critical, doing it wrong can often
mean the card is bricked. eg some devices require good firmware to
start the PCI-E at all.

The firmware for hfi1 is already done with the kernel standard firmware
functions.

I think we will need Mellanox to weigh in on their firmware update but I
suspect that it is a critical operation which needs to be handled very
carefully.

This means the firmware write process needs to be bomb-proof and all
competent vendors provide a user space program that does all necesary
checks. Using the latest version of that program is always a good idea
:)

I would be strongly against moving that sort of complexity into the
kernel.

In turn this means users will never have a uniform user space
experience, like 'cat | ethtool' - because that will not include the
checks.

Further, the very worst thing we could do is create a situation where
a new kernel driver is required to do a firmware update (eg because we
decided to move the checks into the kernel), and worse, potentially
the new driver won't load on old firmware or old kernels. IIRC mlx had
some problems like this once.

From that view, I think, if it can be don entirely via resource0, then
that is what vendors should do, there is no value in a common API for
firmware nv writing.

ethtool eeprom exists as simple debugging/helper tool that should
really never be used by end users. It is reasonble to duplicate it for
eeprom like things, and AFAIK those uses cannot truely brick the
hardware.

The eeprom update for hfi1 should be a rare operation.  resource0 gives us
enough access to do this in the field but with very carefully crafted
instructions and/or tools.  This keeps the kernel simple yet gives us access
without requiring users to change their kernels.  The only exception would be a
lock to tell the driver and hardware we are accessing registers.

Perhaps this is as simple as calling open on a debugfs file then we
automatically know when the process has gone away?

All of this can be done with _very_ simple kernel code which really never has
to change while maintaining a very high degree of flexibility.

Ira

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html