>>> The spec says:
>>> The BMC must not return a given response once the corresponding
>>> Request-to-Response interval has passed. The BMC can ensure this
>>> by maintaining its own internal list of outstanding requests through
>>> the interface. The BMC could age and expire the entries in the list
>>> by expiring the entries at an interval that is somewhat shorter than
>>> the specified Request-to-Response interval....
>> This is clearly not handled in the driver.
>> For this purpose, we could maintain a request expiry list using the seq
>> field of the BT message. Update the list in the read and write operations
>> and arm a timer to garbage collect any left overs. As for the errno in
>> the write when a response had timeout'ed, may be ETIMEDOUT ?
> I think that would work, though I don't think you really need an
> error response in this case.
> I was thinking more just a timeout in the write function. Ideally
> the timeout would be calculated at receive time and then be
> passed in on every write, to preserve the request-to-response
> time for slow messages. I like the simplicity of the driver the
> way it is.
> The trouble is that there is no easy way to pass in a timeout
> in a write operation. You could pass in a structure where the
> first part is a 32-bit timeout, or something like that. Or
> maybe just a fixed timeout and assume every message is
> handled in a short enough time that it meets the spec
> requirement. But that doesn't handle slowness on the
> host side. You can send the message via an ioctl, which
> again isn't terribly ideal.
> It would be nice if there was a write function which was
> able to pass metadata, but AFAIK that's only available on
>> For configuration of the maximum response time, a sysfs file would do
>> I think.
>> Do you want that in v3 also ? I have some experimental patches for it,
>> that I can send as follow ups.
> I'm fine either way.
OK. So I will send a v3 with minimal changes, as openbmc has been using
this driver for a while now. We will discuss the response expiration on
the next patchset.
I have pushed the patches here :
Openipmi-developer mailing list