From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB765C43331 for ; Thu, 26 Mar 2020 11:26:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A9E2F2073E for ; Thu, 26 Mar 2020 11:26:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727688AbgCZL0q (ORCPT ); Thu, 26 Mar 2020 07:26:46 -0400 Received: from mga17.intel.com ([192.55.52.151]:9890 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727560AbgCZL0p (ORCPT ); Thu, 26 Mar 2020 07:26:45 -0400 IronPort-SDR: 7C3kS7zrNh/hCiyB5w5F/vcVoP3DMrSSq8fyYNuvI9iHo74M3QmHNK7swOyYGwif/eaSqcJMzp UaWQXW4ZHqKQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 04:26:44 -0700 IronPort-SDR: j+CX21XIILRChtNrHQMbIj0SlMiqShprtb0zcBZPdehxP4557gVhBxKOezUEUVceIPa8QALX4P mphdgBgGDe2A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,308,1580803200"; d="scan'208";a="240931447" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.170]) ([10.237.72.170]) by orsmga008.jf.intel.com with ESMTP; 26 Mar 2020 04:26:41 -0700 Subject: Re: [PATCH v8 3/5] usb: xhci: Add support for Renesas controller with memory To: Vinod Koul , Mathias Nyman , Greg Kroah-Hartman Cc: linux-arm-msm@vger.kernel.org, Bjorn Andersson , Yoshihiro Shimoda , Christian Lamparter , John Stultz , Alan Stern , =?UTF-8?Q?Andreas_B=c3=b6hler?= , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200323170601.419809-1-vkoul@kernel.org> <20200323170601.419809-4-vkoul@kernel.org> From: Mathias Nyman Openpgp: preference=signencrypt Autocrypt: addr=mathias.nyman@linux.intel.com; prefer-encrypt=mutual; keydata= mQINBFMB0ccBEADd+nZnZrFDsIjQtclVz6OsqFOQ6k0nQdveiDNeBuwyFYykkBpaGekoHZ6f lH4ogPZzQ+pzoJEMlRGXc881BIggKMCMH86fYJGfZKWdfpg9O6mqSxyEuvBHKe9eZCBKPvoC L2iwygtO8TcXXSCynvXSeZrOwqAlwnxWNRm4J2ikDck5S5R+Qie0ZLJIfaId1hELofWfuhy+ tOK0plFR0HgVVp8O7zWYT2ewNcgAzQrRbzidA3LNRfkL7jrzyAxDapuejuK8TMrFQT/wW53e uegnXcRJaibJD84RUJt+mJrn5BvZ0MYfyDSc1yHVO+aZcpNr+71yZBQVgVEI/AuEQ0+p9wpt O9Wt4zO2KT/R5lq2lSz1MYMJrtfFRKkqC6PsDSB4lGSgl91XbibK5poxrIouVO2g9Jabg04T MIPpVUlPme3mkYHLZUsboemRQp5/pxV4HTFR0xNBCmsidBICHOYAepCzNmfLhfo1EW2Uf+t4 L8IowAaoURKdgcR2ydUXjhACVEA/Ldtp3ftF4hTQ46Qhba/p4MUFtDAQ5yeA5vQVuspiwsqB BoL/298+V119JzM998d70Z1clqTc8fiGMXyVnFv92QKShDKyXpiisQn2rrJVWeXEIVoldh6+ J8M3vTwzetnvIKpoQdSFJ2qxOdQ8iYRtz36WYl7hhT3/hwkHuQARAQABtCdNYXRoaWFzIE55 bWFuIDxtYXRoaWFzLm55bWFuQGdtYWlsLmNvbT6JAjsEEwECACUCGwMGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheABQJTAeo1AhkBAAoJEFiDn/uYk8VJOdIP/jhA+RpIZ7rdUHFIYkHEKzHw tkwrJczGA5TyLgQaI8YTCTPSvdNHU9Rj19mkjhUO/9MKvwfoT2RFYqhkrtk0K92STDaBNXTL JIi4IHBqjXOyJ/dPADU0xiRVtCHWkBgjEgR7Wihr7McSdVpgupsaXhbZjXXgtR/N7PE0Wltz hAL2GAnMuIeJyXhIdIMLb+uyoydPCzKdH6znfu6Ox76XfGWBCqLBbvqPXvk4oH03jcdt+8UG 2nfSeti/To9ANRZIlSKGjddCGMa3xzjtTx9ryf1Xr0MnY5PeyNLexpgHp93sc1BKxKKtYaT0 lR6p0QEKeaZ70623oB7Sa2Ts4IytqUVxkQKRkJVWeQiPJ/dZYTK5uo15GaVwufuF8VTwnMkC 4l5X+NUYNAH1U1bpRtlT40aoLEUhWKAyVdowxW4yGCP3nL5E69tZQQgsag+OnxBa6f88j63u wxmOJGNXcwCerkCb+wUPwJzChSifFYmuV5l89LKHgSbv0WHSN9OLkuhJO+I9fsCNvro1Y7dT U/yq4aSVzjaqPT3yrnQkzVDxrYT54FLWO1ssFKAOlcfeWzqrT9QNcHIzHMQYf5c03Kyq3yMI Xi91hkw2uc/GuA2CZ8dUD3BZhUT1dm0igE9NViE1M7F5lHQONEr7MOCg1hcrkngY62V6vh0f RcDeV0ISwlZWuQINBFMB0ccBEACXKmWvojkaG+kh/yipMmqZTrCozsLeGitxJzo5hq9ev31N 2XpPGx4AGhpccbco63SygpVN2bOd0W62fJJoxGohtf/g0uVtRSuK43OTstoBPqyY/35+VnAV oA5cnfvtdx5kQPIL6LRcxmYKgN4/3+A7ejIxbOrjWFmbWCC+SgX6mzHHBrV0OMki8R+NnrNa NkUmMmosi7jBSKdoi9VqDqgQTJF/GftvmaZHqgmVJDWNrCv7UiorhesfIWPt1O/AIk9luxlE dHwkx5zkWa9CGYvV6LfP9BznendEoO3qYZ9IcUlW727Le80Q1oh69QnHoI8pODDBBTJvEq1h bOWcPm/DsNmDD8Rwr/msRmRyIoxjasFi5WkM/K/pzujICKeUcNGNsDsEDJC5TCmRO/TlvCvm 0X+vdfEJRZV6Z+QFBflK1asUz9QHFre5csG8MyVZkwTR9yUiKi3KiqQdaEu+LuDD2CGF5t68 xEl66Y6mwfyiISkkm3ETA4E8rVZP1rZQBBm83c5kJEDvs0A4zrhKIPTcI1smK+TWbyVyrZ/a mGYDrZzpF2N8DfuNSqOQkLHIOL3vuOyx3HPzS05lY3p+IIVmnPOEdZhMsNDIGmVorFyRWa4K uYjBP/W3E5p9e6TvDSDzqhLoY1RHfAIadM3I8kEx5wqco67VIgbIHHB9DbRcxQARAQABiQIf BBgBAgAJBQJTAdHHAhsMAAoJEFiDn/uYk8VJb7AQAK56tgX8V1Wa6RmZDmZ8dmBC7W8nsMRz PcKWiDSMIvTJT5bygMy1lf7gbHXm7fqezRtSfXAXr/OJqSA8LB2LWfThLyuuCvrdNsQNrI+3 D+hjHJjhW/4185y3EdmwwHcelixPg0X9EF+lHCltV/w29Pv3PiGDkoKxJrnOpnU6jrwiBebz eAYBfpSEvrCm4CR4hf+T6MdCs64UzZnNt0nxL8mLCCAGmq1iks9M4bZk+LG36QjCKGh8PDXz 9OsnJmCggptClgjTa7pO6040OW76pcVrP2rZrkjo/Ld/gvSc7yMO/m9sIYxLIsR2NDxMNpmE q/H7WO+2bRG0vMmsndxpEYS4WnuhKutoTA/goBEhtHu1fg5KC+WYXp9wZyTfeNPrL0L8F3N1 BCEYefp2JSZ/a355X6r2ROGSRgIIeYjAiSMgGAZMPEVsdvKsYw6BH17hDRzltNyIj5S0dIhb Gjynb3sXforM/GVbr4mnuxTdLXQYlj2EJ4O4f0tkLlADT7podzKSlSuZsLi2D+ohKxtP3U/r 42i8PBnX2oAV0UIkYk7Oel/3hr0+BP666SnTls9RJuoXc7R5XQVsomqXID6GmjwFQR5Wh/RE IJtkiDAsk37cfZ9d1kZ2gCQryTV9lmflSOB6AFZkOLuEVSC5qW8M/s6IGDfYXN12YJaZPptJ fiD/ Message-ID: <6ea778a7-6d58-6dae-bd65-3a63a945fb97@linux.intel.com> Date: Thu, 26 Mar 2020 13:29:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200323170601.419809-4-vkoul@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Vinod On 23.3.2020 19.05, Vinod Koul wrote: > Some rensas controller like uPD720201 and uPD720202 need firmware to be > loaded. Add these devices in table and invoke renesas firmware loader > functions to check and load the firmware into device memory when > required. > > Signed-off-by: Vinod Koul > --- > drivers/usb/host/xhci-pci-renesas.c | 1 + > drivers/usb/host/xhci-pci.c | 29 ++++++++++++++++++++++++++++- > drivers/usb/host/xhci-pci.h | 3 +++ > 3 files changed, 32 insertions(+), 1 deletion(-) > It's unfortunate if firmware loading couldn't be initiated in a PCI fixup hook for this Renesas controller. What was the reason it failed? Nicolas Saenz Julienne just submitted a solution like that for Raspberry Pi 4 where firmware loading is initiated in pci-quirks.c quirk_usb_early_handoff() https://lore.kernel.org/lkml/20200324182812.20420-1-nsaenzjulienne@suse.de Is he doing something different than what was done for the Renesas controller? > diff --git a/drivers/usb/host/xhci-pci-renesas.c b/drivers/usb/host/xhci-pci-renesas.c > index c588277ac9b8..d413d53df94b 100644 > --- a/drivers/usb/host/xhci-pci-renesas.c > +++ b/drivers/usb/host/xhci-pci-renesas.c > @@ -336,6 +336,7 @@ static void renesas_fw_callback(const struct firmware *fw, > goto cleanup; > } > > + xhci_pci_probe(pdev, ctx->id); > return; I haven't looked into this but instead of calling xhci_pci_probe() here in the async fw loading callback could we just return -EPROBE_DEFER until firmware is loaded when xhci_pci_probe() is originally called? > > cleanup: > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > index a19752178216..7e63658542ac 100644 > --- a/drivers/usb/host/xhci-pci.c > +++ b/drivers/usb/host/xhci-pci.c > @@ -15,6 +15,7 @@ > > #include "xhci.h" > #include "xhci-trace.h" > +#include "xhci-pci.h" > > #define SSIC_PORT_NUM 2 > #define SSIC_PORT_CFG2 0x880c > @@ -312,11 +313,25 @@ static int xhci_pci_setup(struct usb_hcd *hcd) > * We need to register our own PCI probe function (instead of the USB core's > * function) in order to create a second roothub under xHCI. > */ > -static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) > +int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) > { > int retval; > struct xhci_hcd *xhci; > struct usb_hcd *hcd; > + char *renesas_fw; > + > + renesas_fw = (char *)id->driver_data; driver_data is useful for other things than just renesas firmware loading. Heikki suggested a long time ago to use it for passing the quirk flags as well, which makes sense. We probably need a structure, something like struct xhci_driver_data = { u64 quirks; const char *firmware; }; > + if (renesas_fw) { > + retval = renesas_xhci_pci_probe(dev, id); > + switch (retval) { > + case 0: /* fw check success, continue */ > + break; > + case 1: /* fw will be loaded by async load */ > + return 0; > + default: /* error */ > + return retval; > + } > + } > If returning -EPROBE_DEFER until firmware is loaded is an option then we would prevent probe from returning success while the renesas controller is still loading firmware. So we would end up with something like this: (we can add a quirk flag for renesas firmware loading) int xhci_pci_probe(..) { ... struct xhci_driver_data *data = id->driver_data; if (data && data->quirks & XHCI_RENESAS_FW_QUIRK) { if (!xhci_renesas_fw_ready(...)) return -EPROBE_DEFER } } xhci_renesas_fw_ready() would need to initiate firmware loading unless firmware is already running or loading. Would that work for you? -Mathias