Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
To:     Wesley.Sheng@microchip.com, kurt.schwemmer@microsemi.com,
        Kurt.Schwemmer@microchip.com, bhelgaas@google.com
Cc:     linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
        Kelvin.Cao@microchip.com
References: <DM2PR11MB0105CD1B3A264290413ED1CA95140@DM2PR11MB0105.namprd11.prod.outlook.com>
From:   Logan Gunthorpe <logang@deltatee.com>
Message-ID: <f640f7a1-946f-c1b2-56aa-a4ee0bad67b4@deltatee.com>
Date:   Thu, 27 Sep 2018 10:19:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <DM2PR11MB0105CD1B3A264290413ED1CA95140@DM2PR11MB0105.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-CA
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH 1/12 v2] switchtec: Remove immediate status check after
 submit a MRPC command
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Wesley, I'm going to suggest you send patches to me before sending them
to the community until you have a better handle of the tools and
process. The subject suggests you have 11 other patches in this series
so you've mishandled the tools.

On 2018-09-26 11:57 p.m., Wesley.Sheng@microchip.com wrote:
> After submit a Firmware Download (Download sub-command) MRPC
> command, Switchtec firmware refuses to response any management 
> EP's BAR access until current flash programming finished.
> During this time, a READ TLP to the gas area in the BAR of the
> management EP will complete with significant delay like more than 
> 10ms.
> It's a Switchtec firmware limitation that READ requests cannot get
> prompt service during firmware download.
> The delayed completion of READ TLP would be a problem on some system
>  which is sensitive to READ timeout.
> Current driver check status immediately after submit a MRPC command,
> which triggers READ TLP to the gas area in the BAR of the management EP.
> Also, other processes or functions, like NTB, would also trigger READ TLP by
> accessing the GAS.
> To avoid this, the immediate check of status is removed in this patch, and
> driver delays the status check to the occurrence of MSIx or MRPC timeout.
> In the meantime, user must not initiate any gas access during a firmware
> download.
> Also, any process that issues MRPC command will be affected by the delay
> in this patch.
> However, this is only a software workaround to the READ issue in firmware
> download. A complete fix of this should happen in firmware.
> 
> Note: For NTB function, the memory window access is handled by Switchtec
> hardware. So it's not affected by this firmware limitation. But the other GAS
> access which is handled by Switchtec firmware is are affected by this firmware
> limitation.

The commit message is poorly formatted/wrapped and with all due respect,
I think the grammar needs a lot of work.

> ---
>  drivers/pci/switch/switchtec.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index 4591f15..b759228 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -142,10 +142,6 @@ static void mrpc_cmd_submit(struct switchtec_dev *stdev)
>  		    stuser->data, stuser->data_len);
>  	iowrite32(stuser->cmd, &stdev->mmio_mrpc->cmd);
>  
> -	stuser->status = ioread32(&stdev->mmio_mrpc->status);
> -	if (stuser->status != SWITCHTEC_MRPC_STATUS_INPROGRESS)
> -		mrpc_complete_cmd(stdev);
> -
>  	schedule_delayed_work(&stdev->mrpc_timeout,
>  			      msecs_to_jiffies(500));
>  }

The change itself looks good.

Logan