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