[Skiboot] [PATCH 1/7] phb4/capp: Update and re-factor phb4_set_capi_mode()
stewart at linux.ibm.com
Wed Sep 19 18:28:19 AEST 2018
Vaibhav Jain <vaibhav at linux.ibm.com> writes:
> Thanks for reviewing this patch Andrew.
> Andrew Donnellan <andrew.donnellan at au1.ibm.com> writes:
>>> + /* No one else fiddle with capp while we modify its state */
>>> - chip->capp_phb4_attached_mask |= 1 << p->index;
>>> - unlock(&capi_lock);
>> Is there any way to release the lock earlier, like we currently do here?
>> As is, we could be holding capi_lock for quite a while (some of the
>> timeouts in enable_capi_mode() are up to 5 seconds) and we only need to
>> hold capi_lock while we're touching the attached_mask, AIUI.
> Good point though we will need to hold the lock to prevent someone from
> calling phb4_set_capi_mode() with a conflicting value and stomping on
> us. I can probably replace lock with try_lock and return OPAL_BUSY in
> that case leaving the caller to take recovery steps.
Instead of using a mutex for this, what about using a flag variable?
If it really can take seconds, then it should be an async OPAL call
anyway so as not to hold a CPU spinning in OPAL doing nothing.
OPAL Architect, IBM.
More information about the Skiboot