linux-kernel - Re: [PATCH 1/12 v2] switchtec: Remove immediate status check after submit a MRPC command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 27 Sep 2018 10:19:31 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Wesley.Sheng@...rochip.com, kurt.schwemmer@...rosemi.com,
        Kurt.Schwemmer@...rochip.com, bhelgaas@...gle.com
Cc:     linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        Kelvin.Cao@...rochip.com
Subject: Re: [PATCH 1/12 v2] switchtec: Remove immediate status check after
 submit a MRPC command

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@...rochip.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