[cc += Mika, Sergey, Keith]
On Wed, Apr 10, 2019 at 02:07:48PM -0400, Spencer Lingard wrote:
> During command writes, pcie_poll_cmd() is invoked if
> Command Completed notifications are disabled. When polling,
> if Command Completed is set, the bit is reset and success is returned,
> but ctrl->cmd_busy is not set back to 0. The next command write
> then attempts to wait on a command that has already been completed,
> timing out after 2 seconds. This delay occurs more frequently at
> boot time, since pcie_init() disables notifications when powering
> down empty slots.
>
> Clear cmd_busy upon successful command completion during
> pcie_poll_cmd().
>
> Signed-off-by: Spencer Lingard <spencer@xxxxxxxxxxxx>
I suppose this can happen if a write to the Slot Control register is
performed while HPIE and/or CCIE is disabled, the two notifications
are subsequently enabled and another write to the Slot Control is
performed. That second write will then call wait_event_timeout()
because of the stale ctrl->cmd_busy == 1, but the Command Complete
notification has already happened and was cleared by pcie_poll_cmd(),
hence it times out.
Sounds reasonable, I'm a little suprised though that I've never seen
this myself. I guess we've been doing this wrong for years, so:
Cc: stable@xxxxxxxxxxxxxxx
Reviewed-by: Lukas Wunner <lukas@xxxxxxxxx>
Thanks,
Lukas
> ---
> drivers/pci/hotplug/pciehp_hpc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
> index 6a2365c..28c70cf 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -77,6 +77,7 @@ static int pcie_poll_cmd(struct controller *ctrl, int timeout)
> if (slot_status & PCI_EXP_SLTSTA_CC) {
> pcie_capability_write_word(pdev, PCI_EXP_SLTSTA,
> PCI_EXP_SLTSTA_CC);
> + ctrl->cmd_busy = 0;
> return 1;
> }
> if (timeout < 0)
> --
> 2.1.2
