All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Jisheng Zhang <jszhang@marvell.com>,
	mathias.nyman@linux.intel.com,
	Kishon Vijay Abraham I <kishon@ti.com>,
	thomas.petazzoni@free-electrons.com,
	gregory.clement@free-electrons.com,
	maxime.ripard@free-electrons.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	yendapally.reddy@broadcom.com
Subject: Re: [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support
Date: Wed, 27 Apr 2016 10:21:44 +0300	[thread overview]
Message-ID: <874mano6t3.fsf@intel.com> (raw)
In-Reply-To: <20160427144649.67304003@xhacker>

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]


Hi,

Jisheng Zhang <jszhang@marvell.com> writes:
>> > +static void xhci_plat_phy_exit(struct usb_hcd *hcd)
>> > +{
>> > +	if (hcd->phy) {
>> > +		phy_power_off(hcd->phy);
>> > +		phy_exit(hcd->phy);
>> > +	} else {
>> > +		usb_phy_shutdown(hcd->usb_phy);
>> > +	}
>> > +}
>> > +
>> >  static int xhci_plat_probe(struct platform_device *pdev)
>> >  {
>> >  	struct device_node	*node = pdev->dev.of_node;
>> > @@ -145,6 +177,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>> >  	struct usb_hcd		*hcd;
>> >  	struct clk              *clk;
>> >  	struct usb_phy		*usb_phy;
>> > +	struct phy		*phy;  
>> 
>> so, one phy driver using USB PHY layer and another using generic PHY
>> layer ? Why ? I think the first thing your series should do would be to
>
> It's different platforms. E.g
> platform A may write the phy driver under usb phy layer, while platform B
> may have generic phy driver.

right, but both APIs should be supported with *two* PHYs for the time being.

> The questions are: when adding phy support to xhci-plat, the generic phy
> has existed for a long time, what's the reason to use the deprecated usb
> phy APIs.

I don't know, ask the author :-) Maybe the PHY driver was already
available on the USB PHY layer ? What we should do is push that PHY
driver to be moved over to generic PHY layer, then we can get rid of USB
PHY layer from xhci-plat.

> And per my check, it's only MVEBU platforms use this support? I'm not sure
> if we could remove usbphy code from xhci-plat first then add generic phy then
> adding MVEBU xhci phy support bak with the new code. So Cc mvebu maintainers

First the PHY driver(s) depending on that should be converted over.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: felipe.balbi@linux.intel.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support
Date: Wed, 27 Apr 2016 10:21:44 +0300	[thread overview]
Message-ID: <874mano6t3.fsf@intel.com> (raw)
In-Reply-To: <20160427144649.67304003@xhacker>


Hi,

Jisheng Zhang <jszhang@marvell.com> writes:
>> > +static void xhci_plat_phy_exit(struct usb_hcd *hcd)
>> > +{
>> > +	if (hcd->phy) {
>> > +		phy_power_off(hcd->phy);
>> > +		phy_exit(hcd->phy);
>> > +	} else {
>> > +		usb_phy_shutdown(hcd->usb_phy);
>> > +	}
>> > +}
>> > +
>> >  static int xhci_plat_probe(struct platform_device *pdev)
>> >  {
>> >  	struct device_node	*node = pdev->dev.of_node;
>> > @@ -145,6 +177,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>> >  	struct usb_hcd		*hcd;
>> >  	struct clk              *clk;
>> >  	struct usb_phy		*usb_phy;
>> > +	struct phy		*phy;  
>> 
>> so, one phy driver using USB PHY layer and another using generic PHY
>> layer ? Why ? I think the first thing your series should do would be to
>
> It's different platforms. E.g
> platform A may write the phy driver under usb phy layer, while platform B
> may have generic phy driver.

right, but both APIs should be supported with *two* PHYs for the time being.

> The questions are: when adding phy support to xhci-plat, the generic phy
> has existed for a long time, what's the reason to use the deprecated usb
> phy APIs.

I don't know, ask the author :-) Maybe the PHY driver was already
available on the USB PHY layer ? What we should do is push that PHY
driver to be moved over to generic PHY layer, then we can get rid of USB
PHY layer from xhci-plat.

> And per my check, it's only MVEBU platforms use this support? I'm not sure
> if we could remove usbphy code from xhci-plat first then add generic phy then
> adding MVEBU xhci phy support bak with the new code. So Cc mvebu maintainers

First the PHY driver(s) depending on that should be converted over.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160427/554d3060/attachment.sig>

  reply	other threads:[~2016-04-27  7:24 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 12:57 [RESEND PATCH v2 0/7] usb: xhci-plat: support generic PHY and vbus regulator Jisheng Zhang
2016-04-26 12:57 ` Jisheng Zhang
2016-04-26 12:57 ` [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-27  5:25   ` Felipe Balbi
2016-04-27  5:25     ` Felipe Balbi
2016-04-27  5:46     ` Jisheng Zhang
2016-04-27  5:46       ` Jisheng Zhang
2016-04-26 12:57 ` [RESEND PATCH v2 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-27  5:29   ` Felipe Balbi
2016-04-27  5:29     ` Felipe Balbi
2016-04-27  5:59     ` Jisheng Zhang
2016-04-27  5:59       ` Jisheng Zhang
2016-04-27  6:19       ` Felipe Balbi
2016-04-27  6:19         ` Felipe Balbi
2016-04-26 12:57 ` [RESEND PATCH v2 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-27  5:30   ` Felipe Balbi
2016-04-27  5:30     ` Felipe Balbi
2016-04-26 12:57 ` [RESEND PATCH v2 4/7] usb: xhci: plat: sort the headers in alphabetic order Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-26 12:57 ` [RESEND PATCH v2 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-27  5:33   ` Felipe Balbi
2016-04-27  5:33     ` Felipe Balbi
2016-04-27  6:33     ` Jisheng Zhang
2016-04-27  6:33       ` Jisheng Zhang
2016-04-27  7:19       ` Felipe Balbi
2016-04-27  7:19         ` Felipe Balbi
2016-04-26 12:57 ` [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-27  5:35   ` Felipe Balbi
2016-04-27  5:35     ` Felipe Balbi
2016-04-27  6:46     ` Jisheng Zhang
2016-04-27  6:46       ` Jisheng Zhang
2016-04-27  7:21       ` Felipe Balbi [this message]
2016-04-27  7:21         ` Felipe Balbi
2016-04-27  7:57   ` Heikki Krogerus
2016-04-27  7:57     ` Heikki Krogerus
2016-04-27  9:34     ` Felipe Balbi
2016-04-27  9:34       ` Felipe Balbi
2016-04-26 12:57 ` [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control Jisheng Zhang
2016-04-26 12:57   ` Jisheng Zhang
2016-04-27  5:37   ` Felipe Balbi
2016-04-27  5:37     ` Felipe Balbi
2016-04-27  9:57     ` Mark Brown
2016-04-27  9:57       ` Mark Brown
2016-04-27 10:25       ` Jisheng Zhang
2016-04-27 10:25         ` Jisheng Zhang
2016-04-27 13:24         ` Mark Brown
2016-04-27 13:24           ` Mark Brown
2016-04-27 10:25       ` Felipe Balbi
2016-04-27 10:25         ` Felipe Balbi
2016-04-27 10:35         ` Mark Brown
2016-04-27 10:35           ` Mark Brown
2016-04-27 10:38           ` Felipe Balbi
2016-04-27 10:38             ` Felipe Balbi

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=874mano6t3.fsf@intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.clement@free-electrons.com \
    --cc=jszhang@marvell.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=yendapally.reddy@broadcom.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.