adding notion of "hints" to FruDevice

James Feist james.feist at linux.intel.com
Fri Aug 16 06:28:03 AEST 2019


On 8/10/19 7:53 AM, Patrick Venture wrote:
> James;
> 
> One difficulty we've run into is the 16-bit address detection can be
> flaky.  It's not known yet whether there's some underlying i2c issue
> on the board or with the i2c driver that could be leading to the
> flakiness, but to get around it I've been forced to add hints to
> FruDevice locally.  Effectively, it's a lookup that says, if this is
> the bus and address, it's 16-bit.  Sort of a way to say, if something
> is in the PE slot (which we know the buses for) then we know it's
> 16-bit.  It's just an idea of been playing with to get a couple things
> working, and I was curious if the notion had larger appeal?
> 
> the production-ized idea would be, optional hint json configuration
> that does a priority search:
> devices
> addresses
> buses
> 
> So it'd search if there was a device match, then search for an address
> match, then a bus match, otherwise fall back without a hint to the
> dynamic attempt.
> 
> It's certainly not a perfect solution.  It requires the system
> programmer to enforce that certain cards are only placed in certain
> slots -- but it is _optional_...

Any reason to not just try one, if it fails, try the other type of 
scanning? I think that's what the intent of the detection was. To scan 
the header, if it's a valid header, continue, else try the other scan 
mode. We could put a configuration option in the cmakelists too if we 
wanted to allow trying 8 bit or 16 bit first.

-James


> 
> Patrick
> 


More information about the openbmc mailing list