From: "Pali Rohár" <pali@kernel.org>
To: Peter Chen <peter.chen@nxp.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Gregory CLEMENT <gregory.clement@bootlin.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Tomasz Maciej Nowak <tmn505@gmail.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720
Date: Thu, 24 Dec 2020 14:29:44 +0100 [thread overview]
Message-ID: <20201224132944.5odphwxtnzhvkeg7@pali> (raw)
In-Reply-To: <20201224132401.7inh5ae7aaqvooxe@pali>
On Thursday 24 December 2020 14:24:01 Pali Rohár wrote:
> On Thursday 24 December 2020 13:15:21 Peter Chen wrote:
> >
> > > > > + /* Old bindings miss the PHY handle */
> > > > > + phy = of_phy_get(dev->of_node, "usb3-phy");
> > > > > + if (IS_ERR(phy) && PTR_ERR(phy) == -EPROBE_DEFER)
> > > > > + return -EPROBE_DEFER;
> > > >
> > > > Doesn't need to judge IS_ERR(phy).
> > >
> > > Ok, I can remove it. I used same condition which is already in SATA and PCIe
> > > phy code.
> > >
> > > > > + else if (IS_ERR(phy))
> > > > > + goto phy_out;
> > > > > +
> > > > > + ret = phy_init(phy);
> > > > > + if (ret)
> > > > > + goto phy_put;
> > > > > +
> > > > > + ret = phy_set_mode(phy, PHY_MODE_USB_HOST_SS);
> > > > > + if (ret)
> > > > > + goto phy_exit;
> > > > > +
> > > > > + ret = phy_power_on(phy);
> > > > > + if (ret == -EOPNOTSUPP) {
> > > > > + /* Skip initializatin of XHCI PHY when it is unsupported by
> > > firmware */
> > > > > + dev_warn(dev, "PHY unsupported by firmware\n");
> > > > > + xhci->quirks |= XHCI_SKIP_PHY_INIT;
> > > > > + }
> > > > > + if (ret)
> > > > > + goto phy_exit;
> > > > > +
> > > > > + phy_power_off(phy);
> > > > > +phy_exit:
> > > > > + phy_exit(phy);
> > > > > +phy_put:
> > > > > + of_phy_put(phy);
> > > > > +phy_out:
> > > > > +
> > > >
> > > > You do power on and off again only want to know if PHY has already
> > > > powered at ATF, right?
> > >
> > > I need to know if power on/off procedure is supported by ATF. And if not
> > > (indicated by -EOPNOTSUPP) then I need to ensure that usb hdc code would not
> > > try to call phy_power_on() as it would cause failure as described in the commit
> > > message. You can look at those other two commits for PCIe and SATA. Same
> > > thing is needed for USB.
> >
> > If not supported by ATF, then where to power on and off PHY since no other place calls PHY APIs? Is it always on?
>
> Yes, in this case (when -EOPNOTSUPP is returned) SMC API is not
> supported by ATF, and PHY is always on.
To make it clear, core/hcd.c function usb_add_hcd() when
hcd->skip_phy_initialization is false is calling
usb_phy_roothub_power_on() which calls phy_power_on(). If this call
fails then error is propagated back to the usb_add_hcd() and this
function fails too.
But on boards with older ATF (which do not support PHY power on SMC API)
is phy_power_on() returning error -EOPNOTSUPP and therefore whole USB
3.0 initialization fails.
This patch is adding init hook to detect if ATF supports PHY power
on/off functions and in case it does not support it, code sets
XHCI_SKIP_PHY_INIT flag to instruct xhci-plat code to set
hcd->skip_phy_initialization flag to instruct core/hcd.c to skip calling
usb_phy_roothub_power_on() function as it is know that it would fail.
next prev parent reply other threads:[~2020-12-24 13:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-23 16:24 [PATCH] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720 Pali Rohár
2020-12-24 5:54 ` Peter Chen
2020-12-24 12:53 ` Pali Rohár
2020-12-24 13:15 ` Peter Chen
2020-12-24 13:24 ` Pali Rohár
2020-12-24 13:29 ` Pali Rohár [this message]
2020-12-25 0:16 ` Peter Chen
2020-12-28 12:11 ` Marek Behun
2020-12-28 13:22 ` Pali Rohár
2021-01-30 16:31 ` Tomasz Maciej Nowak
2021-01-30 16:35 ` Pali Rohár
2021-01-30 16:37 ` Tomasz Maciej Nowak
2021-02-01 15:08 ` [PATCH v2] " Pali Rohár
2021-02-02 1:53 ` Yoshihiro Shimoda
2021-02-02 18:41 ` Greg Kroah-Hartman
2021-02-03 9:46 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201224132944.5odphwxtnzhvkeg7@pali \
--to=pali@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=gregory.clement@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=miquel.raynal@bootlin.com \
--cc=peter.chen@nxp.com \
--cc=tmn505@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox