Skip to content
  • Daniel Henrique Barboza's avatar
    382907b1
    spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical() · 382907b1
    Daniel Henrique Barboza authored
    
    
    drc_isolate_logical() is used to move the DRC from the "Configured" to
    the "Available" state, erroring out if the DRC is in the unexpected
    "Unisolate" state and doing nothing (with RTAS_OUT_SUCCESS) if the DRC
    is already in "Available" or in "Unusable" state.
    
    When moving from "Configured" to "Available", the DRC is moved to the
    LOGICAL_AVAILABLE state, a drc->unplug_requested check is done and, if
    true, spapr_drc_detach() is called.
    
    What spapr_drc_detach() does then is:
    
    - set drc->unplug_requested to true. In fact, this is the only place
    where unplug_request is set to true;
    - does nothing else if drc->state != drck->empty_state. If the DRC
    state is equal to drck->empty_state, spapr_drc_release() is
    called. For logical DRCs, drck->empty_state = LOGICAL_UNUSABLE.
    
    In short, calling spapr_drc_detach() in drc_isolate_logical() does
    nothing. It'll set unplug_request to true again ('again' since it was
    already true - otherwise the function wouldn't be called), and will
    return without calling spapr_drc_release() because the DRC is not in
    LOGICAL_UNUSABLE, since drc_isolate_logical() just moved it to
    LOGICAL_AVAILABLE. The only place where the logical DRC is released is
    when called from drc_set_unusable(), when it is moved to the
    "Unusable" state.  As it should, according to PAPR.
    
    Even though calling spapr_drc_detach() in drc_isolate_logical() is
    benign, removing it will avoid further thought about the matter. So
    let's go ahead and do that.
    
    As a note, this logic was introduced in commit bbf5c878. Since
    then, the DRC handling code was refactored and enhanced, and PAPR
    itself went through some changes in the DRC area as well. It is
    expected that some assumptions we had back then are now deprecated.
    
    Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
    Message-Id: <20210211225246.17315-2-danielhb413@gmail.com>
    Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
    Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
    382907b1
    spapr_drc.c: do not call spapr_drc_detach() in drc_isolate_logical()
    Daniel Henrique Barboza authored
    
    
    drc_isolate_logical() is used to move the DRC from the "Configured" to
    the "Available" state, erroring out if the DRC is in the unexpected
    "Unisolate" state and doing nothing (with RTAS_OUT_SUCCESS) if the DRC
    is already in "Available" or in "Unusable" state.
    
    When moving from "Configured" to "Available", the DRC is moved to the
    LOGICAL_AVAILABLE state, a drc->unplug_requested check is done and, if
    true, spapr_drc_detach() is called.
    
    What spapr_drc_detach() does then is:
    
    - set drc->unplug_requested to true. In fact, this is the only place
    where unplug_request is set to true;
    - does nothing else if drc->state != drck->empty_state. If the DRC
    state is equal to drck->empty_state, spapr_drc_release() is
    called. For logical DRCs, drck->empty_state = LOGICAL_UNUSABLE.
    
    In short, calling spapr_drc_detach() in drc_isolate_logical() does
    nothing. It'll set unplug_request to true again ('again' since it was
    already true - otherwise the function wouldn't be called), and will
    return without calling spapr_drc_release() because the DRC is not in
    LOGICAL_UNUSABLE, since drc_isolate_logical() just moved it to
    LOGICAL_AVAILABLE. The only place where the logical DRC is released is
    when called from drc_set_unusable(), when it is moved to the
    "Unusable" state.  As it should, according to PAPR.
    
    Even though calling spapr_drc_detach() in drc_isolate_logical() is
    benign, removing it will avoid further thought about the matter. So
    let's go ahead and do that.
    
    As a note, this logic was introduced in commit bbf5c878. Since
    then, the DRC handling code was refactored and enhanced, and PAPR
    itself went through some changes in the DRC area as well. It is
    expected that some assumptions we had back then are now deprecated.
    
    Signed-off-by: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
    Message-Id: <20210211225246.17315-2-danielhb413@gmail.com>
    Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
    Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
Loading