RE: [PATCH 4/4] usb: host: xhci-rcar: avoid 60s wait by request_firmware() in system booting

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
To: Simon Horman <horms@verge.net.au>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"mathias.nyman@intel.com" <mathias.nyman@intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH 4/4] usb: host: xhci-rcar: avoid 60s wait by request_firmware() in system booting
Date: Mon, 2 Sep 2019 10:35:33 +0000	[thread overview]
Message-ID: <TYAPR01MB4544B88DD008C653007FF631D8BE0@TYAPR01MB4544.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20190831084304.wisliftdg5g26jbf@verge.net.au>

Hi Simon-san,

Thank you for your comment!

> From: Simon Horman, Sent: Saturday, August 31, 2019 5:43 PM
> 
> On Tue, Aug 27, 2019 at 07:02:07PM +0900, Yoshihiro Shimoda wrote:
> > If CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y and CONFIG_USB_XHCI_RCAR=y,
> > request_firmware() in xhci_rcar_download_firmware() waits for 60s to
> > sysfs fallback for the firmware like below.
> >
> > [    1.599701] xhci-hcd ee000000.usb: xHCI Host Controller
> > [    1.604948] xhci-hcd ee000000.usb: new USB bus registered, assigned bus number 3
> > [    1.612403] xhci-hcd ee000000.usb: Direct firmware load for r8a779x_usb3_v3.dlmem failed with error -2
> > [    1.621726] xhci-hcd ee000000.usb: Falling back to sysfs fallback for: r8a779x_usb3_v3.dlmem
> > [    1.707953] ata1: link resume succeeded after 1 retries
> > [    1.819379] ata1: SATA link down (SStatus 0 SControl 300)
> > [   62.436012] xhci-hcd ee000000.usb: can't setup: -11
> > [   62.440901] xhci-hcd ee000000.usb: USB bus 3 deregistered
> > [   62.446361] xhci-hcd: probe of ee000000.usb failed with error -11
> >
> > To avoid this 60s wait, this patch adds to check the system_state
> > condition and if the system is not running,
> > xhci_rcar_download_firmware() calls request_firmware_direct()
> > instead of request_firmware() as a workaround.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> 
> It seems to me that request_firmware() is working as expected.
> And that this patch introduces an alternate behaviour for xhci-rcar
> where it will fall back to the user-space helper in some cases but not
> others. This inconsistency isn't obviously correct to me. Perhaps
> xhci-rcar should always call request_firmware_direct() ?

If xhci-rcar always call request_firmware_direct() but end user
uses the user-space helper on the driver, it's a regression because
request_firmware_direct() always disables the user-space helper. So,
I'd like to avoid using request_firmware_direct(). JFYI, I checked
the git history and I found such a situation:
---
commit c0cc00f250e19c717fc9cdbdb7f55aaa569c7498
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Thu Aug 24 23:06:41 2017 +0200

    ath10k: activate user space firmware loading again
---

It seems we need more time to investigate how to fix (or avoid) this issue.
So, I'll resend v2 patch series without this patch.

Best regards,
Yoshihiro Shimoda