* [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 13:57 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 13:57 UTC (permalink / raw
To: gregkh, linux-usb
Cc: Peter.Chen, stern, swarren, thierry.reding, balbi, linux-tegra,
linux-omap, linux-sh, magnus.damm
Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
This is in preparation to adding the generic PHY support.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
drivers/usb/chipidea/host.c | 2 +-
drivers/usb/core/hcd.c | 20 ++++++++++----------
drivers/usb/core/hub.c | 9 +++++----
drivers/usb/host/ehci-fsl.c | 16 ++++++++--------
drivers/usb/host/ehci-hub.c | 2 +-
drivers/usb/host/ehci-msm.c | 4 ++--
drivers/usb/host/ehci-tegra.c | 16 ++++++++--------
drivers/usb/host/ohci-omap.c | 20 ++++++++++----------
include/linux/usb/hcd.h | 6 +++---
9 files changed, 48 insertions(+), 47 deletions(-)
Index: usb/drivers/usb/chipidea/host.c
===================================================================
--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd->has_tt = 1;
hcd->power_budget = ci->platdata->power_budget;
- hcd->phy = ci->transceiver;
+ hcd->transceiver = ci->transceiver;
ehci = hcd_to_ehci(hcd);
ehci->caps = ci->hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
===================================================================
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2605,7 +2605,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->transceiver) {
struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
if (IS_ERR(phy)) {
@@ -2618,7 +2618,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd->phy = phy;
+ hcd->transceiver = phy;
hcd->remove_phy = 1;
}
}
@@ -2764,10 +2764,10 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_remove_phy:
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->transceiver) {
+ usb_phy_shutdown(hcd->transceiver);
+ usb_put_phy(hcd->transceiver);
+ hcd->transceiver = NULL;
}
return retval;
}
@@ -2841,10 +2841,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_dev(hcd->self.root_hub);
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->transceiver) {
+ usb_phy_shutdown(hcd->transceiver);
+ usb_put_phy(hcd->transceiver);
+ hcd->transceiver = NULL;
}
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
Index: usb/drivers/usb/core/hub.c
===================================================================
--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4250,8 +4250,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
- if (hcd->phy && !hdev->parent)
- usb_phy_notify_connect(hcd->phy, udev->speed);
+ if (hcd->transceiver && !hdev->parent)
+ usb_phy_notify_connect(hcd->transceiver, udev->speed);
/*
* Some superspeed devices have finished the link training process
@@ -4459,9 +4459,10 @@ static void hub_port_connect_change(stru
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd->phy && !hdev->parent &&
+ if (hcd->transceiver && !hdev->parent &&
!(portstatus & USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd->phy, udev->speed);
+ usb_phy_notify_disconnect(hcd->transceiver,
+ udev->speed);
usb_disconnect(&hub->ports[port1 - 1]->child);
}
clear_bit(port1, hub->change_bits);
Index: usb/drivers/usb/host/ehci-fsl.c
===================================================================
--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata->operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- hcd->phy = usb_get_phy(USB_PHY_TYPE_USB2);
+ hcd->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
dev_dbg(&pdev->dev, "hcd=0x%p ehci=0x%p, phy=0x%p\n",
- hcd, ehci, hcd->phy);
+ hcd, ehci, hcd->transceiver);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- retval = otg_set_host(hcd->phy->otg,
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ retval = otg_set_host(hcd->transceiver->otg,
&ehci_to_hcd(ehci)->self);
if (retval) {
- usb_put_phy(hcd->phy);
+ usb_put_phy(hcd->transceiver);
goto err2;
}
} else {
@@ -181,9 +181,9 @@ static void usb_hcd_fsl_remove(struct us
{
struct fsl_usb2_platform_data *pdata = dev_get_platdata(&pdev->dev);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- otg_set_host(hcd->phy->otg, NULL);
- usb_put_phy(hcd->phy);
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ otg_set_host(hcd->transceiver->otg, NULL);
+ usb_put_phy(hcd->transceiver);
}
usb_remove_hcd(hcd);
Index: usb/drivers/usb/host/ehci-hub.c
===================================================================
--- usb.orig/drivers/usb/host/ehci-hub.c
+++ usb/drivers/usb/host/ehci-hub.c
@@ -931,7 +931,7 @@ static int ehci_hub_control (
#ifdef CONFIG_USB_OTG
if ((hcd->self.otg_port == (wIndex + 1))
&& hcd->self.b_hnp_enable) {
- otg_start_hnp(hcd->phy->otg);
+ otg_start_hnp(hcd->transceiver->otg);
break;
}
#endif
Index: usb/drivers/usb/host/ehci-msm.c
===================================================================
--- usb.orig/drivers/usb/host/ehci-msm.c
+++ usb/drivers/usb/host/ehci-msm.c
@@ -125,7 +125,7 @@ static int ehci_msm_probe(struct platfor
goto put_hcd;
}
- hcd->phy = phy;
+ hcd->transceiver = phy;
device_init_wakeup(&pdev->dev, 1);
/*
* OTG device parent of HCD takes care of putting
@@ -152,7 +152,7 @@ static int ehci_msm_remove(struct platfo
pm_runtime_disable(&pdev->dev);
pm_runtime_set_suspended(&pdev->dev);
- otg_set_host(hcd->phy->otg, NULL);
+ otg_set_host(hcd->transceiver->otg, NULL);
/* FIXME: need to call usb_remove_hcd() here? */
Index: usb/drivers/usb/host/ehci-tegra.c
===================================================================
--- usb.orig/drivers/usb/host/ehci-tegra.c
+++ usb/drivers/usb/host/ehci-tegra.c
@@ -154,7 +154,7 @@ static int tegra_ehci_hub_control(
if (tegra->port_resuming && !(temp & PORT_SUSPEND)) {
/* Resume completed, re-enable disconnect detection */
tegra->port_resuming = 0;
- tegra_usb_phy_postresume(hcd->phy);
+ tegra_usb_phy_postresume(hcd->transceiver);
}
}
@@ -207,7 +207,7 @@ static int tegra_ehci_hub_control(
goto done;
/* Disable disconnect detection during port resume */
- tegra_usb_phy_preresume(hcd->phy);
+ tegra_usb_phy_preresume(hcd->transceiver);
ehci->reset_done[wIndex-1] = jiffies + msecs_to_jiffies(25);
@@ -402,7 +402,7 @@ static int tegra_ehci_probe(struct platf
err = PTR_ERR(u_phy);
goto cleanup_clk_en;
}
- hcd->phy = u_phy;
+ hcd->transceiver = u_phy;
tegra->needs_double_reset = of_property_read_bool(pdev->dev.of_node,
"nvidia,needs-double-reset");
@@ -424,7 +424,7 @@ static int tegra_ehci_probe(struct platf
ehci->caps = hcd->regs + 0x100;
ehci->has_hostpc = soc_config->has_hostpc;
- err = usb_phy_init(hcd->phy);
+ err = usb_phy_init(hcd->transceiver);
if (err) {
dev_err(&pdev->dev, "Failed to initialize phy\n");
goto cleanup_clk_en;
@@ -439,7 +439,7 @@ static int tegra_ehci_probe(struct platf
}
u_phy->otg->host = hcd_to_bus(hcd);
- err = usb_phy_set_suspend(hcd->phy, 0);
+ err = usb_phy_set_suspend(hcd->transceiver, 0);
if (err) {
dev_err(&pdev->dev, "Failed to power on the phy\n");
goto cleanup_phy;
@@ -466,7 +466,7 @@ static int tegra_ehci_probe(struct platf
cleanup_otg_set_host:
otg_set_host(u_phy->otg, NULL);
cleanup_phy:
- usb_phy_shutdown(hcd->phy);
+ usb_phy_shutdown(hcd->transceiver);
cleanup_clk_en:
clk_disable_unprepare(tegra->clk);
cleanup_hcd_create:
@@ -480,9 +480,9 @@ static int tegra_ehci_remove(struct plat
struct tegra_ehci_hcd *tegra =
(struct tegra_ehci_hcd *)hcd_to_ehci(hcd)->priv;
- otg_set_host(hcd->phy->otg, NULL);
+ otg_set_host(hcd->transceiver->otg, NULL);
- usb_phy_shutdown(hcd->phy);
+ usb_phy_shutdown(hcd->transceiver);
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
Index: usb/drivers/usb/host/ohci-omap.c
===================================================================
--- usb.orig/drivers/usb/host/ohci-omap.c
+++ usb/drivers/usb/host/ohci-omap.c
@@ -180,10 +180,10 @@ static void start_hnp(struct ohci_hcd *o
unsigned long flags;
u32 l;
- otg_start_hnp(hcd->phy->otg);
+ otg_start_hnp(hcd->transceiver->otg);
local_irq_save(flags);
- hcd->phy->state = OTG_STATE_A_SUSPEND;
+ hcd->transceiver->state = OTG_STATE_A_SUSPEND;
writel (RH_PS_PSS, &ohci->regs->roothub.portstatus [port]);
l = omap_readl(OTG_CTRL);
l &= ~OTG_A_BUSREQ;
@@ -220,14 +220,14 @@ static int ohci_omap_reset(struct usb_hc
#ifdef CONFIG_USB_OTG
if (need_transceiver) {
- hcd->phy = usb_get_phy(USB_PHY_TYPE_USB2);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- int status = otg_set_host(hcd->phy->otg,
+ hcd->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ int status = otg_set_host(hcd->transceiver->otg,
&ohci_to_hcd(ohci)->self);
dev_dbg(hcd->self.controller, "init %s phy, status %d\n",
- hcd->phy->label, status);
+ hcd->transceiver->label, status);
if (status) {
- usb_put_phy(hcd->phy);
+ usb_put_phy(hcd->transceiver);
return status;
}
} else {
@@ -399,9 +399,9 @@ usb_hcd_omap_remove (struct usb_hcd *hcd
dev_dbg(hcd->self.controller, "stopping USB Controller\n");
usb_remove_hcd(hcd);
omap_ohci_clock_power(0);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- (void) otg_set_host(hcd->phy->otg, 0);
- usb_put_phy(hcd->phy);
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ (void) otg_set_host(hcd->transceiver->otg, 0);
+ usb_put_phy(hcd->transceiver);
}
if (machine_is_omap_osk())
gpio_free(9);
Index: usb/include/linux/usb/hcd.h
===================================================================
--- usb.orig/include/linux/usb/hcd.h
+++ usb/include/linux/usb/hcd.h
@@ -103,10 +103,10 @@ struct usb_hcd {
const struct hc_driver *driver; /* hw-specific hooks */
/*
- * OTG and some Host controllers need software interaction with phys;
- * other external phys should be software-transparent
+ * OTG and some host controllers need software interaction with PHYs;
+ * other external PHYs should be software-transparent
*/
- struct usb_phy *phy;
+ struct usb_phy *transceiver;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 13:57 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 13:57 UTC (permalink / raw
To: gregkh, linux-usb
Cc: Peter.Chen, stern, swarren, thierry.reding, balbi, linux-tegra,
linux-omap, linux-sh, magnus.damm
Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
This is in preparation to adding the generic PHY support.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
drivers/usb/chipidea/host.c | 2 +-
drivers/usb/core/hcd.c | 20 ++++++++++----------
drivers/usb/core/hub.c | 9 +++++----
drivers/usb/host/ehci-fsl.c | 16 ++++++++--------
drivers/usb/host/ehci-hub.c | 2 +-
drivers/usb/host/ehci-msm.c | 4 ++--
drivers/usb/host/ehci-tegra.c | 16 ++++++++--------
drivers/usb/host/ohci-omap.c | 20 ++++++++++----------
include/linux/usb/hcd.h | 6 +++---
9 files changed, 48 insertions(+), 47 deletions(-)
Index: usb/drivers/usb/chipidea/host.c
=================================--- usb.orig/drivers/usb/chipidea/host.c
+++ usb/drivers/usb/chipidea/host.c
@@ -59,7 +59,7 @@ static int host_start(struct ci_hdrc *ci
hcd->has_tt = 1;
hcd->power_budget = ci->platdata->power_budget;
- hcd->phy = ci->transceiver;
+ hcd->transceiver = ci->transceiver;
ehci = hcd_to_ehci(hcd);
ehci->caps = ci->hw_bank.cap;
Index: usb/drivers/usb/core/hcd.c
=================================--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -2605,7 +2605,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
- if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->phy) {
+ if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->transceiver) {
struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
if (IS_ERR(phy)) {
@@ -2618,7 +2618,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_put_phy(phy);
return retval;
}
- hcd->phy = phy;
+ hcd->transceiver = phy;
hcd->remove_phy = 1;
}
}
@@ -2764,10 +2764,10 @@ err_allocate_root_hub:
err_register_bus:
hcd_buffer_destroy(hcd);
err_remove_phy:
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->transceiver) {
+ usb_phy_shutdown(hcd->transceiver);
+ usb_put_phy(hcd->transceiver);
+ hcd->transceiver = NULL;
}
return retval;
}
@@ -2841,10 +2841,10 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_put_dev(hcd->self.root_hub);
usb_deregister_bus(&hcd->self);
hcd_buffer_destroy(hcd);
- if (hcd->remove_phy && hcd->phy) {
- usb_phy_shutdown(hcd->phy);
- usb_put_phy(hcd->phy);
- hcd->phy = NULL;
+ if (hcd->remove_phy && hcd->transceiver) {
+ usb_phy_shutdown(hcd->transceiver);
+ usb_put_phy(hcd->transceiver);
+ hcd->transceiver = NULL;
}
}
EXPORT_SYMBOL_GPL(usb_remove_hcd);
Index: usb/drivers/usb/core/hub.c
=================================--- usb.orig/drivers/usb/core/hub.c
+++ usb/drivers/usb/core/hub.c
@@ -4250,8 +4250,8 @@ hub_port_init (struct usb_hub *hub, stru
if (retval)
goto fail;
- if (hcd->phy && !hdev->parent)
- usb_phy_notify_connect(hcd->phy, udev->speed);
+ if (hcd->transceiver && !hdev->parent)
+ usb_phy_notify_connect(hcd->transceiver, udev->speed);
/*
* Some superspeed devices have finished the link training process
@@ -4459,9 +4459,10 @@ static void hub_port_connect_change(stru
/* Disconnect any existing devices under this port */
if (udev) {
- if (hcd->phy && !hdev->parent &&
+ if (hcd->transceiver && !hdev->parent &&
!(portstatus & USB_PORT_STAT_CONNECTION))
- usb_phy_notify_disconnect(hcd->phy, udev->speed);
+ usb_phy_notify_disconnect(hcd->transceiver,
+ udev->speed);
usb_disconnect(&hub->ports[port1 - 1]->child);
}
clear_bit(port1, hub->change_bits);
Index: usb/drivers/usb/host/ehci-fsl.c
=================================--- usb.orig/drivers/usb/host/ehci-fsl.c
+++ usb/drivers/usb/host/ehci-fsl.c
@@ -136,15 +136,15 @@ static int usb_hcd_fsl_probe(const struc
if (pdata->operating_mode = FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- hcd->phy = usb_get_phy(USB_PHY_TYPE_USB2);
+ hcd->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
dev_dbg(&pdev->dev, "hcd=0x%p ehci=0x%p, phy=0x%p\n",
- hcd, ehci, hcd->phy);
+ hcd, ehci, hcd->transceiver);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- retval = otg_set_host(hcd->phy->otg,
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ retval = otg_set_host(hcd->transceiver->otg,
&ehci_to_hcd(ehci)->self);
if (retval) {
- usb_put_phy(hcd->phy);
+ usb_put_phy(hcd->transceiver);
goto err2;
}
} else {
@@ -181,9 +181,9 @@ static void usb_hcd_fsl_remove(struct us
{
struct fsl_usb2_platform_data *pdata = dev_get_platdata(&pdev->dev);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- otg_set_host(hcd->phy->otg, NULL);
- usb_put_phy(hcd->phy);
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ otg_set_host(hcd->transceiver->otg, NULL);
+ usb_put_phy(hcd->transceiver);
}
usb_remove_hcd(hcd);
Index: usb/drivers/usb/host/ehci-hub.c
=================================--- usb.orig/drivers/usb/host/ehci-hub.c
+++ usb/drivers/usb/host/ehci-hub.c
@@ -931,7 +931,7 @@ static int ehci_hub_control (
#ifdef CONFIG_USB_OTG
if ((hcd->self.otg_port = (wIndex + 1))
&& hcd->self.b_hnp_enable) {
- otg_start_hnp(hcd->phy->otg);
+ otg_start_hnp(hcd->transceiver->otg);
break;
}
#endif
Index: usb/drivers/usb/host/ehci-msm.c
=================================--- usb.orig/drivers/usb/host/ehci-msm.c
+++ usb/drivers/usb/host/ehci-msm.c
@@ -125,7 +125,7 @@ static int ehci_msm_probe(struct platfor
goto put_hcd;
}
- hcd->phy = phy;
+ hcd->transceiver = phy;
device_init_wakeup(&pdev->dev, 1);
/*
* OTG device parent of HCD takes care of putting
@@ -152,7 +152,7 @@ static int ehci_msm_remove(struct platfo
pm_runtime_disable(&pdev->dev);
pm_runtime_set_suspended(&pdev->dev);
- otg_set_host(hcd->phy->otg, NULL);
+ otg_set_host(hcd->transceiver->otg, NULL);
/* FIXME: need to call usb_remove_hcd() here? */
Index: usb/drivers/usb/host/ehci-tegra.c
=================================--- usb.orig/drivers/usb/host/ehci-tegra.c
+++ usb/drivers/usb/host/ehci-tegra.c
@@ -154,7 +154,7 @@ static int tegra_ehci_hub_control(
if (tegra->port_resuming && !(temp & PORT_SUSPEND)) {
/* Resume completed, re-enable disconnect detection */
tegra->port_resuming = 0;
- tegra_usb_phy_postresume(hcd->phy);
+ tegra_usb_phy_postresume(hcd->transceiver);
}
}
@@ -207,7 +207,7 @@ static int tegra_ehci_hub_control(
goto done;
/* Disable disconnect detection during port resume */
- tegra_usb_phy_preresume(hcd->phy);
+ tegra_usb_phy_preresume(hcd->transceiver);
ehci->reset_done[wIndex-1] = jiffies + msecs_to_jiffies(25);
@@ -402,7 +402,7 @@ static int tegra_ehci_probe(struct platf
err = PTR_ERR(u_phy);
goto cleanup_clk_en;
}
- hcd->phy = u_phy;
+ hcd->transceiver = u_phy;
tegra->needs_double_reset = of_property_read_bool(pdev->dev.of_node,
"nvidia,needs-double-reset");
@@ -424,7 +424,7 @@ static int tegra_ehci_probe(struct platf
ehci->caps = hcd->regs + 0x100;
ehci->has_hostpc = soc_config->has_hostpc;
- err = usb_phy_init(hcd->phy);
+ err = usb_phy_init(hcd->transceiver);
if (err) {
dev_err(&pdev->dev, "Failed to initialize phy\n");
goto cleanup_clk_en;
@@ -439,7 +439,7 @@ static int tegra_ehci_probe(struct platf
}
u_phy->otg->host = hcd_to_bus(hcd);
- err = usb_phy_set_suspend(hcd->phy, 0);
+ err = usb_phy_set_suspend(hcd->transceiver, 0);
if (err) {
dev_err(&pdev->dev, "Failed to power on the phy\n");
goto cleanup_phy;
@@ -466,7 +466,7 @@ static int tegra_ehci_probe(struct platf
cleanup_otg_set_host:
otg_set_host(u_phy->otg, NULL);
cleanup_phy:
- usb_phy_shutdown(hcd->phy);
+ usb_phy_shutdown(hcd->transceiver);
cleanup_clk_en:
clk_disable_unprepare(tegra->clk);
cleanup_hcd_create:
@@ -480,9 +480,9 @@ static int tegra_ehci_remove(struct plat
struct tegra_ehci_hcd *tegra (struct tegra_ehci_hcd *)hcd_to_ehci(hcd)->priv;
- otg_set_host(hcd->phy->otg, NULL);
+ otg_set_host(hcd->transceiver->otg, NULL);
- usb_phy_shutdown(hcd->phy);
+ usb_phy_shutdown(hcd->transceiver);
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
Index: usb/drivers/usb/host/ohci-omap.c
=================================--- usb.orig/drivers/usb/host/ohci-omap.c
+++ usb/drivers/usb/host/ohci-omap.c
@@ -180,10 +180,10 @@ static void start_hnp(struct ohci_hcd *o
unsigned long flags;
u32 l;
- otg_start_hnp(hcd->phy->otg);
+ otg_start_hnp(hcd->transceiver->otg);
local_irq_save(flags);
- hcd->phy->state = OTG_STATE_A_SUSPEND;
+ hcd->transceiver->state = OTG_STATE_A_SUSPEND;
writel (RH_PS_PSS, &ohci->regs->roothub.portstatus [port]);
l = omap_readl(OTG_CTRL);
l &= ~OTG_A_BUSREQ;
@@ -220,14 +220,14 @@ static int ohci_omap_reset(struct usb_hc
#ifdef CONFIG_USB_OTG
if (need_transceiver) {
- hcd->phy = usb_get_phy(USB_PHY_TYPE_USB2);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- int status = otg_set_host(hcd->phy->otg,
+ hcd->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ int status = otg_set_host(hcd->transceiver->otg,
&ohci_to_hcd(ohci)->self);
dev_dbg(hcd->self.controller, "init %s phy, status %d\n",
- hcd->phy->label, status);
+ hcd->transceiver->label, status);
if (status) {
- usb_put_phy(hcd->phy);
+ usb_put_phy(hcd->transceiver);
return status;
}
} else {
@@ -399,9 +399,9 @@ usb_hcd_omap_remove (struct usb_hcd *hcd
dev_dbg(hcd->self.controller, "stopping USB Controller\n");
usb_remove_hcd(hcd);
omap_ohci_clock_power(0);
- if (!IS_ERR_OR_NULL(hcd->phy)) {
- (void) otg_set_host(hcd->phy->otg, 0);
- usb_put_phy(hcd->phy);
+ if (!IS_ERR_OR_NULL(hcd->transceiver)) {
+ (void) otg_set_host(hcd->transceiver->otg, 0);
+ usb_put_phy(hcd->transceiver);
}
if (machine_is_omap_osk())
gpio_free(9);
Index: usb/include/linux/usb/hcd.h
=================================--- usb.orig/include/linux/usb/hcd.h
+++ usb/include/linux/usb/hcd.h
@@ -103,10 +103,10 @@ struct usb_hcd {
const struct hc_driver *driver; /* hw-specific hooks */
/*
- * OTG and some Host controllers need software interaction with phys;
- * other external phys should be software-transparent
+ * OTG and some host controllers need software interaction with PHYs;
+ * other external PHYs should be software-transparent
*/
- struct usb_phy *phy;
+ struct usb_phy *transceiver;
/* Flags that need to be manipulated atomically because they can
* change while the host controller is running. Always use
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 13:57 ` Sergei Shtylyov
@ 2014-04-09 15:31 ` Stephen Warren
-1 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 15:31 UTC (permalink / raw
To: Sergei Shtylyov, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 07:57 AM, Sergei Shtylyov wrote:
> Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
> This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY support? To be honest, this rename
feels like churn, especially since the APIs and DT bindings all still
include the work phy so now everything will be inconsistent.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 15:31 ` Stephen Warren
0 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 15:31 UTC (permalink / raw
To: Sergei Shtylyov, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 07:57 AM, Sergei Shtylyov wrote:
> Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
> This is in preparation to adding the generic PHY support.
Surely if the correct term is transceiver, we should be adding generic
transceiver support not generic PHY support? To be honest, this rename
feels like churn, especially since the APIs and DT bindings all still
include the work phy so now everything will be inconsistent.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 15:31 ` Stephen Warren
@ 2014-04-09 16:27 ` Sergei Shtylyov
-1 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 16:27 UTC (permalink / raw
To: Stephen Warren, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
Hello.
On 04/09/2014 07:31 PM, Stephen Warren wrote:
>> Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
>> This is in preparation to adding the generic PHY support.
> Surely if the correct term is transceiver, we should be adding generic
> transceiver support not generic PHY support? To be honest, this rename
> feels like churn, especially since the APIs and DT bindings all still
> include the work phy so now everything will be inconsistent.
How about 'usb_phy'?
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 16:27 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 16:27 UTC (permalink / raw
To: Stephen Warren, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
Hello.
On 04/09/2014 07:31 PM, Stephen Warren wrote:
>> Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'.
>> This is in preparation to adding the generic PHY support.
> Surely if the correct term is transceiver, we should be adding generic
> transceiver support not generic PHY support? To be honest, this rename
> feels like churn, especially since the APIs and DT bindings all still
> include the work phy so now everything will be inconsistent.
How about 'usb_phy'?
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 16:27 ` Sergei Shtylyov
@ 2014-04-09 16:48 ` Stephen Warren
-1 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 16:48 UTC (permalink / raw
To: Sergei Shtylyov, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 10:27 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 04/09/2014 07:31 PM, Stephen Warren wrote:
>
>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>> 'transceiver'.
>>> This is in preparation to adding the generic PHY support.
>
>> Surely if the correct term is transceiver, we should be adding generic
>> transceiver support not generic PHY support? To be honest, this rename
>> feels like churn, especially since the APIs and DT bindings all still
>> include the work phy so now everything will be inconsistent.
>
> How about 'usb_phy'?
That certainly would make things more consistent, but I wonder why
"usb_phy" is better than "phy" when the code/struct in question is
something USB-specific; the "usb_" prefix seems implicit to me due to
context.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 16:48 ` Stephen Warren
0 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 16:48 UTC (permalink / raw
To: Sergei Shtylyov, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 10:27 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 04/09/2014 07:31 PM, Stephen Warren wrote:
>
>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>> 'transceiver'.
>>> This is in preparation to adding the generic PHY support.
>
>> Surely if the correct term is transceiver, we should be adding generic
>> transceiver support not generic PHY support? To be honest, this rename
>> feels like churn, especially since the APIs and DT bindings all still
>> include the work phy so now everything will be inconsistent.
>
> How about 'usb_phy'?
That certainly would make things more consistent, but I wonder why
"usb_phy" is better than "phy" when the code/struct in question is
something USB-specific; the "usb_" prefix seems implicit to me due to
context.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
[not found] ` <534579D5.10306-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
@ 2014-04-09 16:53 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 16:53 UTC (permalink / raw
To: Stephen Warren, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: Peter.Chen-KZfg59tc24xl57MIdRCFDg,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w
On 04/09/2014 08:48 PM, Stephen Warren wrote:
>>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>>> 'transceiver'.
>>>> This is in preparation to adding the generic PHY support.
>>> Surely if the correct term is transceiver, we should be adding generic
>>> transceiver support not generic PHY support? To be honest, this rename
>>> feels like churn, especially since the APIs and DT bindings all still
>>> include the work phy so now everything will be inconsistent.
>> How about 'usb_phy'?
> That certainly would make things more consistent, but I wonder why
> "usb_phy" is better than "phy" when the code/struct in question is
> something USB-specific; the "usb_" prefix seems implicit to me due to
> context.
I tend to agree. However, I need to name the new field of stype 'struct
phy *' somehow... perhaps something like 'gen_phy' for it would do?
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 16:53 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 16:53 UTC (permalink / raw
To: Stephen Warren, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: Peter.Chen-KZfg59tc24xl57MIdRCFDg,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w
On 04/09/2014 08:48 PM, Stephen Warren wrote:
>>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>>> 'transceiver'.
>>>> This is in preparation to adding the generic PHY support.
>>> Surely if the correct term is transceiver, we should be adding generic
>>> transceiver support not generic PHY support? To be honest, this rename
>>> feels like churn, especially since the APIs and DT bindings all still
>>> include the work phy so now everything will be inconsistent.
>> How about 'usb_phy'?
> That certainly would make things more consistent, but I wonder why
> "usb_phy" is better than "phy" when the code/struct in question is
> something USB-specific; the "usb_" prefix seems implicit to me due to
> context.
I tend to agree. However, I need to name the new field of stype 'struct
phy *' somehow... perhaps something like 'gen_phy' for it would do?
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 16:53 ` Sergei Shtylyov
@ 2014-04-09 17:37 ` Stephen Warren
-1 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 17:37 UTC (permalink / raw
To: Sergei Shtylyov, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 10:53 AM, Sergei Shtylyov wrote:
> On 04/09/2014 08:48 PM, Stephen Warren wrote:
>
>>>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>>>> 'transceiver'.
>>>>> This is in preparation to adding the generic PHY support.
>
>>>> Surely if the correct term is transceiver, we should be adding generic
>>>> transceiver support not generic PHY support? To be honest, this rename
>>>> feels like churn, especially since the APIs and DT bindings all still
>>>> include the work phy so now everything will be inconsistent.
>
>>> How about 'usb_phy'?
>
>> That certainly would make things more consistent, but I wonder why
>> "usb_phy" is better than "phy" when the code/struct in question is
>> something USB-specific; the "usb_" prefix seems implicit to me due to
>> context.
>
> I tend to agree. However, I need to name the new field of stype
> 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do?
Ok, the existing field is being replaced by something? I didn't get that
from the patch description; I thought the new name in this patch was
going to be it. In that case, a temporary name of usb_phy for the
existing field, or adding the new field as gen_phy sound reasonable.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 17:37 ` Stephen Warren
0 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 17:37 UTC (permalink / raw
To: Sergei Shtylyov, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 10:53 AM, Sergei Shtylyov wrote:
> On 04/09/2014 08:48 PM, Stephen Warren wrote:
>
>>>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>>>> 'transceiver'.
>>>>> This is in preparation to adding the generic PHY support.
>
>>>> Surely if the correct term is transceiver, we should be adding generic
>>>> transceiver support not generic PHY support? To be honest, this rename
>>>> feels like churn, especially since the APIs and DT bindings all still
>>>> include the work phy so now everything will be inconsistent.
>
>>> How about 'usb_phy'?
>
>> That certainly would make things more consistent, but I wonder why
>> "usb_phy" is better than "phy" when the code/struct in question is
>> something USB-specific; the "usb_" prefix seems implicit to me due to
>> context.
>
> I tend to agree. However, I need to name the new field of stype
> 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do?
Ok, the existing field is being replaced by something? I didn't get that
from the patch description; I thought the new name in this patch was
going to be it. In that case, a temporary name of usb_phy for the
existing field, or adding the new field as gen_phy sound reasonable.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 17:37 ` Stephen Warren
@ 2014-04-09 17:52 ` Sergei Shtylyov
-1 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 17:52 UTC (permalink / raw
To: Stephen Warren, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 09:37 PM, Stephen Warren wrote:
>>>>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>>>>> 'transceiver'.
>>>>>> This is in preparation to adding the generic PHY support.
>>>>> Surely if the correct term is transceiver, we should be adding generic
>>>>> transceiver support not generic PHY support? To be honest, this rename
>>>>> feels like churn, especially since the APIs and DT bindings all still
>>>>> include the work phy so now everything will be inconsistent.
>>>> How about 'usb_phy'?
>>> That certainly would make things more consistent, but I wonder why
>>> "usb_phy" is better than "phy" when the code/struct in question is
>>> something USB-specific; the "usb_" prefix seems implicit to me due to
>>> context.
>> I tend to agree. However, I need to name the new field of stype
>> 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do?
> Ok, the existing field is being replaced by something? I didn't get that
No, not replaced. I'm adding the support for generic PHY to the existing
USB PHY support. I thought that was clear from the changelog.
> from the patch description; I thought the new name in this patch was
> going to be it. In that case, a temporary name of usb_phy for the
> existing field, or adding the new field as gen_phy sound reasonable.
OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 17:52 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 17:52 UTC (permalink / raw
To: Stephen Warren, gregkh, linux-usb
Cc: Peter.Chen, stern, thierry.reding, balbi, linux-tegra, linux-omap,
linux-sh, magnus.damm
On 04/09/2014 09:37 PM, Stephen Warren wrote:
>>>>>> Return to the 'phy' field of 'struct usb_hcd' its historic name
>>>>>> 'transceiver'.
>>>>>> This is in preparation to adding the generic PHY support.
>>>>> Surely if the correct term is transceiver, we should be adding generic
>>>>> transceiver support not generic PHY support? To be honest, this rename
>>>>> feels like churn, especially since the APIs and DT bindings all still
>>>>> include the work phy so now everything will be inconsistent.
>>>> How about 'usb_phy'?
>>> That certainly would make things more consistent, but I wonder why
>>> "usb_phy" is better than "phy" when the code/struct in question is
>>> something USB-specific; the "usb_" prefix seems implicit to me due to
>>> context.
>> I tend to agree. However, I need to name the new field of stype
>> 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do?
> Ok, the existing field is being replaced by something? I didn't get that
No, not replaced. I'm adding the support for generic PHY to the existing
USB PHY support. I thought that was clear from the changelog.
> from the patch description; I thought the new name in this patch was
> going to be it. In that case, a temporary name of usb_phy for the
> existing field, or adding the new field as gen_phy sound reasonable.
OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 17:52 ` Sergei Shtylyov
@ 2014-04-09 17:56 ` Alan Stern
-1 siblings, 0 replies; 32+ messages in thread
From: Alan Stern @ 2014-04-09 17:56 UTC (permalink / raw
To: Sergei Shtylyov
Cc: Stephen Warren, gregkh, linux-usb, Peter.Chen, thierry.reding,
balbi, linux-tegra, linux-omap, linux-sh, magnus.damm
On Wed, 9 Apr 2014, Sergei Shtylyov wrote:
> > Ok, the existing field is being replaced by something? I didn't get that
>
> No, not replaced. I'm adding the support for generic PHY to the existing
> USB PHY support. I thought that was clear from the changelog.
>
> > from the patch description; I thought the new name in this patch was
> > going to be it. In that case, a temporary name of usb_phy for the
> > existing field, or adding the new field as gen_phy sound reasonable.
>
> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
What is the reason for all of this? That is, can you explain the
difference between USB PHY support and general PHY support, and why we
need both?
Alan Stern
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 17:56 ` Alan Stern
0 siblings, 0 replies; 32+ messages in thread
From: Alan Stern @ 2014-04-09 17:56 UTC (permalink / raw
To: Sergei Shtylyov
Cc: Stephen Warren, gregkh, linux-usb, Peter.Chen, thierry.reding,
balbi, linux-tegra, linux-omap, linux-sh, magnus.damm
On Wed, 9 Apr 2014, Sergei Shtylyov wrote:
> > Ok, the existing field is being replaced by something? I didn't get that
>
> No, not replaced. I'm adding the support for generic PHY to the existing
> USB PHY support. I thought that was clear from the changelog.
>
> > from the patch description; I thought the new name in this patch was
> > going to be it. In that case, a temporary name of usb_phy for the
> > existing field, or adding the new field as gen_phy sound reasonable.
>
> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
What is the reason for all of this? That is, can you explain the
difference between USB PHY support and general PHY support, and why we
need both?
Alan Stern
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 17:56 ` Alan Stern
@ 2014-04-09 18:16 ` Sergei Shtylyov
-1 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 18:16 UTC (permalink / raw
To: Alan Stern
Cc: Stephen Warren, gregkh, linux-usb, Peter.Chen, thierry.reding,
balbi, linux-tegra, linux-omap, linux-sh, magnus.damm
Hello.
On 04/09/2014 09:56 PM, Alan Stern wrote:
>>> Ok, the existing field is being replaced by something? I didn't get that
>> No, not replaced. I'm adding the support for generic PHY to the existing
>> USB PHY support. I thought that was clear from the changelog.
>>> from the patch description; I thought the new name in this patch was
>>> going to be it. In that case, a temporary name of usb_phy for the
>>> existing field, or adding the new field as gen_phy sound reasonable.
>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
> What is the reason for all of this? That is, can you explain the
> difference between USB PHY support and general PHY support, and why we
> need both?
The generic PHY framework (drivers/phy/phy-core.c) supports multifunction
"complex" PHYs (some functions of which may be related to USB). My case is a
Renesas R-Car generation 2 PHY that can switch two USB ports between different
USB controllers (one PCI and one non-PCI on each port); I just haven't CCed
linux-usb on my driver submission. Though there's already drivers/phy/usb/
driver for that hardware, it failed to meet the expectations (dynamic setting
of the port multiplexing depending on what USB host/gadget drivers are
loaded), so I had to write a new driver. I guess I don't need to describe
drivers/phy/usb/ framework in detail, do I? It only provides for
single-function "simple" USB PHYs...
> Alan Stern
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 18:16 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 18:16 UTC (permalink / raw
To: Alan Stern
Cc: Stephen Warren, gregkh, linux-usb, Peter.Chen, thierry.reding,
balbi, linux-tegra, linux-omap, linux-sh, magnus.damm
Hello.
On 04/09/2014 09:56 PM, Alan Stern wrote:
>>> Ok, the existing field is being replaced by something? I didn't get that
>> No, not replaced. I'm adding the support for generic PHY to the existing
>> USB PHY support. I thought that was clear from the changelog.
>>> from the patch description; I thought the new name in this patch was
>>> going to be it. In that case, a temporary name of usb_phy for the
>>> existing field, or adding the new field as gen_phy sound reasonable.
>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
> What is the reason for all of this? That is, can you explain the
> difference between USB PHY support and general PHY support, and why we
> need both?
The generic PHY framework (drivers/phy/phy-core.c) supports multifunction
"complex" PHYs (some functions of which may be related to USB). My case is a
Renesas R-Car generation 2 PHY that can switch two USB ports between different
USB controllers (one PCI and one non-PCI on each port); I just haven't CCed
linux-usb on my driver submission. Though there's already drivers/phy/usb/
driver for that hardware, it failed to meet the expectations (dynamic setting
of the port multiplexing depending on what USB host/gadget drivers are
loaded), so I had to write a new driver. I guess I don't need to describe
drivers/phy/usb/ framework in detail, do I? It only provides for
single-function "simple" USB PHYs...
> Alan Stern
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
[not found] ` <53458E95.4080505-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
@ 2014-04-09 19:01 ` Stephen Warren
0 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 19:01 UTC (permalink / raw
To: Sergei Shtylyov, Alan Stern
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
Peter.Chen-KZfg59tc24xl57MIdRCFDg,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w
On 04/09/2014 12:16 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 04/09/2014 09:56 PM, Alan Stern wrote:
>
>>>> Ok, the existing field is being replaced by something? I didn't get
>>>> that
>
>>> No, not replaced. I'm adding the support for generic PHY to the
>>> existing
>>> USB PHY support. I thought that was clear from the changelog.
>
>>>> from the patch description; I thought the new name in this patch was
>>>> going to be it. In that case, a temporary name of usb_phy for the
>>>> existing field, or adding the new field as gen_phy sound reasonable.
>
>>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch
>>> #1.
>
>> What is the reason for all of this? That is, can you explain the
>> difference between USB PHY support and general PHY support, and why we
>> need both?
>
> The generic PHY framework (drivers/phy/phy-core.c) supports
> multifunction "complex" PHYs (some functions of which may be related to
> USB). My case is a Renesas R-Car generation 2 PHY that can switch two
> USB ports between different USB controllers (one PCI and one non-PCI on
> each port); I just haven't CCed linux-usb on my driver submission.
> Though there's already drivers/phy/usb/ driver for that hardware, it
> failed to meet the expectations (dynamic setting of the port
> multiplexing depending on what USB host/gadget drivers are loaded), so I
> had to write a new driver. I guess I don't need to describe
> drivers/phy/usb/ framework in detail, do I? It only provides for
> single-function "simple" USB PHYs...
Naively, it sounds like the complex PHY driver should also be a pinctrl
driver, since it sounds like the main feature it has beyond a simple PHY
is the ability to do pin muxing.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 19:01 ` Stephen Warren
0 siblings, 0 replies; 32+ messages in thread
From: Stephen Warren @ 2014-04-09 19:01 UTC (permalink / raw
To: Sergei Shtylyov, Alan Stern
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
Peter.Chen-KZfg59tc24xl57MIdRCFDg,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w
On 04/09/2014 12:16 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 04/09/2014 09:56 PM, Alan Stern wrote:
>
>>>> Ok, the existing field is being replaced by something? I didn't get
>>>> that
>
>>> No, not replaced. I'm adding the support for generic PHY to the
>>> existing
>>> USB PHY support. I thought that was clear from the changelog.
>
>>>> from the patch description; I thought the new name in this patch was
>>>> going to be it. In that case, a temporary name of usb_phy for the
>>>> existing field, or adding the new field as gen_phy sound reasonable.
>
>>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch
>>> #1.
>
>> What is the reason for all of this? That is, can you explain the
>> difference between USB PHY support and general PHY support, and why we
>> need both?
>
> The generic PHY framework (drivers/phy/phy-core.c) supports
> multifunction "complex" PHYs (some functions of which may be related to
> USB). My case is a Renesas R-Car generation 2 PHY that can switch two
> USB ports between different USB controllers (one PCI and one non-PCI on
> each port); I just haven't CCed linux-usb on my driver submission.
> Though there's already drivers/phy/usb/ driver for that hardware, it
> failed to meet the expectations (dynamic setting of the port
> multiplexing depending on what USB host/gadget drivers are loaded), so I
> had to write a new driver. I guess I don't need to describe
> drivers/phy/usb/ framework in detail, do I? It only provides for
> single-function "simple" USB PHYs...
Naively, it sounds like the complex PHY driver should also be a pinctrl
driver, since it sounds like the main feature it has beyond a simple PHY
is the ability to do pin muxing.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
[not found] ` <534598EF.3010102-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
@ 2014-04-09 19:06 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 19:06 UTC (permalink / raw
To: Stephen Warren, Alan Stern
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
Peter.Chen-KZfg59tc24xl57MIdRCFDg,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w
On 04/09/2014 11:01 PM, Stephen Warren wrote:
>>>>> Ok, the existing field is being replaced by something? I didn't get
>>>>> that
>>>> No, not replaced. I'm adding the support for generic PHY to the
>>>> existing
>>>> USB PHY support. I thought that was clear from the changelog.
>>>>> from the patch description; I thought the new name in this patch was
>>>>> going to be it. In that case, a temporary name of usb_phy for the
>>>>> existing field, or adding the new field as gen_phy sound reasonable.
>>>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch
>>>> #1.
>>> What is the reason for all of this? That is, can you explain the
>>> difference between USB PHY support and general PHY support, and why we
>>> need both?
>> The generic PHY framework (drivers/phy/phy-core.c) supports
>> multifunction "complex" PHYs (some functions of which may be related to
>> USB). My case is a Renesas R-Car generation 2 PHY that can switch two
>> USB ports between different USB controllers (one PCI and one non-PCI on
>> each port); I just haven't CCed linux-usb on my driver submission.
>> Though there's already drivers/phy/usb/ driver for that hardware, it
>> failed to meet the expectations (dynamic setting of the port
>> multiplexing depending on what USB host/gadget drivers are loaded), so I
>> had to write a new driver. I guess I don't need to describe
>> drivers/phy/usb/ framework in detail, do I? It only provides for
>> single-function "simple" USB PHYs...
> Naively, it sounds like the complex PHY driver should also be a pinctrl
> driver, since it sounds like the main feature it has beyond a simple PHY
> is the ability to do pin muxing.
It doesn't do any pin muxing. It switches SoC internal USB signals between
USB controllers. The pins remain the same.
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-09 19:06 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-09 19:06 UTC (permalink / raw
To: Stephen Warren, Alan Stern
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
Peter.Chen-KZfg59tc24xl57MIdRCFDg,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w
On 04/09/2014 11:01 PM, Stephen Warren wrote:
>>>>> Ok, the existing field is being replaced by something? I didn't get
>>>>> that
>>>> No, not replaced. I'm adding the support for generic PHY to the
>>>> existing
>>>> USB PHY support. I thought that was clear from the changelog.
>>>>> from the patch description; I thought the new name in this patch was
>>>>> going to be it. In that case, a temporary name of usb_phy for the
>>>>> existing field, or adding the new field as gen_phy sound reasonable.
>>>> OK, I'll respin the patch #2 with 'gen_phy' and remove the patch
>>>> #1.
>>> What is the reason for all of this? That is, can you explain the
>>> difference between USB PHY support and general PHY support, and why we
>>> need both?
>> The generic PHY framework (drivers/phy/phy-core.c) supports
>> multifunction "complex" PHYs (some functions of which may be related to
>> USB). My case is a Renesas R-Car generation 2 PHY that can switch two
>> USB ports between different USB controllers (one PCI and one non-PCI on
>> each port); I just haven't CCed linux-usb on my driver submission.
>> Though there's already drivers/phy/usb/ driver for that hardware, it
>> failed to meet the expectations (dynamic setting of the port
>> multiplexing depending on what USB host/gadget drivers are loaded), so I
>> had to write a new driver. I guess I don't need to describe
>> drivers/phy/usb/ framework in detail, do I? It only provides for
>> single-function "simple" USB PHYs...
> Naively, it sounds like the complex PHY driver should also be a pinctrl
> driver, since it sounds like the main feature it has beyond a simple PHY
> is the ability to do pin muxing.
It doesn't do any pin muxing. It switches SoC internal USB signals between
USB controllers. The pins remain the same.
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-09 19:06 ` Sergei Shtylyov
(?)
@ 2014-04-10 9:20 ` David Laight
2014-04-10 10:49 ` Sergei Shtylyov
-1 siblings, 1 reply; 32+ messages in thread
From: David Laight @ 2014-04-10 9:20 UTC (permalink / raw
To: 'Sergei Shtylyov', Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
From: Sergei Shtylyov
> It doesn't do any pin muxing. It switches SoC internal USB signals between
> USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?
That also doesn't sound like you are changing the PHY.
I'd have thought that would happen if you had a single controller
that select between multiply PHY.
David
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-10 9:20 ` David Laight
@ 2014-04-10 10:49 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-10 10:49 UTC (permalink / raw
To: David Laight, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
On 10-04-2014 13:20, David Laight wrote:
>> It doesn't do any pin muxing. It switches SoC internal USB signals between
>> USB controllers. The pins remain the same.
> Doesn't something like that already happen for the companion USB1
> controllers for USB2 ports?
Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
> That also doesn't sound like you are changing the PHY.
I am changing one of the PHY registers that controls USB port (Renesas
calls it channel) multiplexing.
> I'd have thought that would happen if you had a single controller
> that select between multiply PHY.
No, it's not the case.
> David
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-10 10:49 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-10 10:49 UTC (permalink / raw
To: David Laight, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
On 10-04-2014 13:20, David Laight wrote:
>> It doesn't do any pin muxing. It switches SoC internal USB signals between
>> USB controllers. The pins remain the same.
> Doesn't something like that already happen for the companion USB1
> controllers for USB2 ports?
Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
> That also doesn't sound like you are changing the PHY.
I am changing one of the PHY registers that controls USB port (Renesas
calls it channel) multiplexing.
> I'd have thought that would happen if you had a single controller
> that select between multiply PHY.
No, it's not the case.
> David
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-10 10:49 ` Sergei Shtylyov
@ 2014-04-10 11:01 ` Ben Dooks
-1 siblings, 0 replies; 32+ messages in thread
From: Ben Dooks @ 2014-04-10 11:01 UTC (permalink / raw
To: Sergei Shtylyov, David Laight, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
On 10/04/14 11:49, Sergei Shtylyov wrote:
> On 10-04-2014 13:20, David Laight wrote:
>
>>> It doesn't do any pin muxing. It switches SoC internal USB
>>> signals between
>>> USB controllers. The pins remain the same.
>
>> Doesn't something like that already happen for the companion USB1
>> controllers for USB2 ports?
>
> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
>
>> That also doesn't sound like you are changing the PHY.
>
> I am changing one of the PHY registers that controls USB port
> (Renesas calls it channel) multiplexing.
>
>> I'd have thought that would happen if you had a single controller
>> that select between multiply PHY.
>
> No, it's not the case.
There is an interesting case, the USB3 shares a PHY with a SATA
and the PCIE and SATA also share a PHY on the R8A7790.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-10 11:01 ` Ben Dooks
0 siblings, 0 replies; 32+ messages in thread
From: Ben Dooks @ 2014-04-10 11:01 UTC (permalink / raw
To: Sergei Shtylyov, David Laight, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
On 10/04/14 11:49, Sergei Shtylyov wrote:
> On 10-04-2014 13:20, David Laight wrote:
>
>>> It doesn't do any pin muxing. It switches SoC internal USB
>>> signals between
>>> USB controllers. The pins remain the same.
>
>> Doesn't something like that already happen for the companion USB1
>> controllers for USB2 ports?
>
> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
>
>> That also doesn't sound like you are changing the PHY.
>
> I am changing one of the PHY registers that controls USB port
> (Renesas calls it channel) multiplexing.
>
>> I'd have thought that would happen if you had a single controller
>> that select between multiply PHY.
>
> No, it's not the case.
There is an interesting case, the USB3 shares a PHY with a SATA
and the PCIE and SATA also share a PHY on the R8A7790.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 32+ messages in thread
* RE: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-10 11:01 ` Ben Dooks
(?)
@ 2014-04-10 11:14 ` David Laight
2014-04-10 11:20 ` Ben Dooks
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
-1 siblings, 2 replies; 32+ messages in thread
From: David Laight @ 2014-04-10 11:14 UTC (permalink / raw
To: 'Ben Dooks', Sergei Shtylyov, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
From: Ben Dooks
> On 10/04/14 11:49, Sergei Shtylyov wrote:
> > On 10-04-2014 13:20, David Laight wrote:
> >
> >>> It doesn't do any pin muxing. It switches SoC internal USB
> >>> signals between
> >>> USB controllers. The pins remain the same.
> >
> >> Doesn't something like that already happen for the companion USB1
> >> controllers for USB2 ports?
> >
> > Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
Yes.
Why do you care which USB controller is driving the pins?
> >> That also doesn't sound like you are changing the PHY.
> >
> > I am changing one of the PHY registers that controls USB port
> > (Renesas calls it channel) multiplexing.
> >
> >> I'd have thought that would happen if you had a single controller
> >> that select between multiply PHY.
> >
> > No, it's not the case.
I realised that wasn't what you were doing, but at first it did seem
to be what you were doing.
> There is an interesting case, the USB3 shares a PHY with a SATA
> and the PCIE and SATA also share a PHY on the R8A7790.
Some of those look like pcb design decisions - so there is no dynamic
changing, just config time plumbing.
OTOH we are carrying PCIe using two SATA cables (the second carries the
clock) so I suspect some SoC system pcbs may be able to support SATA
or PCIe on the same connector).
David
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
2014-04-10 11:14 ` David Laight
@ 2014-04-10 11:20 ` Ben Dooks
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
1 sibling, 0 replies; 32+ messages in thread
From: Ben Dooks @ 2014-04-10 11:20 UTC (permalink / raw
To: David Laight, Sergei Shtylyov, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
On 10/04/14 12:14, David Laight wrote:
> From: Ben Dooks
>> On 10/04/14 11:49, Sergei Shtylyov wrote:
>>> On 10-04-2014 13:20, David Laight wrote:
>>>
>>>>> It doesn't do any pin muxing. It switches SoC internal USB
>>>>> signals between
>>>>> USB controllers. The pins remain the same.
>>>
>>>> Doesn't something like that already happen for the companion USB1
>>>> controllers for USB2 ports?
>>>
>>> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
>
> Yes.
>
> Why do you care which USB controller is driving the pins?
>
>>>> That also doesn't sound like you are changing the PHY.
>>>
>>> I am changing one of the PHY registers that controls USB port
>>> (Renesas calls it channel) multiplexing.
>>>
>>>> I'd have thought that would happen if you had a single controller
>>>> that select between multiply PHY.
>>>
>>> No, it's not the case.
>
> I realised that wasn't what you were doing, but at first it did seem
> to be what you were doing.
>
>> There is an interesting case, the USB3 shares a PHY with a SATA
>> and the PCIE and SATA also share a PHY on the R8A7790.
>
> Some of those look like pcb design decisions - so there is no dynamic
> changing, just config time plumbing.
> OTOH we are carrying PCIe using two SATA cables (the second carries the
> clock) so I suspect some SoC system pcbs may be able to support SATA
> or PCIe on the same connector).
Yes, which means we will probably want to support the case where
the USB3 is routed out of the PCIe lanes.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-10 11:20 ` Ben Dooks
0 siblings, 0 replies; 32+ messages in thread
From: Ben Dooks @ 2014-04-10 11:20 UTC (permalink / raw
To: David Laight, Sergei Shtylyov, Stephen Warren, Alan Stern
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
Peter.Chen@freescale.com, thierry.reding@gmail.com, balbi@ti.com,
linux-tegra@vger.kernel.org, linux-omap@vger.kernel.org,
linux-sh@vger.kernel.org, magnus.damm@gmail.com
On 10/04/14 12:14, David Laight wrote:
> From: Ben Dooks
>> On 10/04/14 11:49, Sergei Shtylyov wrote:
>>> On 10-04-2014 13:20, David Laight wrote:
>>>
>>>>> It doesn't do any pin muxing. It switches SoC internal USB
>>>>> signals between
>>>>> USB controllers. The pins remain the same.
>>>
>>>> Doesn't something like that already happen for the companion USB1
>>>> controllers for USB2 ports?
>>>
>>> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
>
> Yes.
>
> Why do you care which USB controller is driving the pins?
>
>>>> That also doesn't sound like you are changing the PHY.
>>>
>>> I am changing one of the PHY registers that controls USB port
>>> (Renesas calls it channel) multiplexing.
>>>
>>>> I'd have thought that would happen if you had a single controller
>>>> that select between multiply PHY.
>>>
>>> No, it's not the case.
>
> I realised that wasn't what you were doing, but at first it did seem
> to be what you were doing.
>
>> There is an interesting case, the USB3 shares a PHY with a SATA
>> and the PCIE and SATA also share a PHY on the R8A7790.
>
> Some of those look like pcb design decisions - so there is no dynamic
> changing, just config time plumbing.
> OTOH we are carrying PCIe using two SATA cables (the second carries the
> clock) so I suspect some SoC system pcbs may be able to support SATA
> or PCIe on the same connector).
Yes, which means we will probably want to support the case where
the USB3 is routed out of the PCIe lanes.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
@ 2014-04-10 12:40 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-10 12:40 UTC (permalink / raw
To: David Laight, 'Ben Dooks', Stephen Warren, Alan Stern
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
balbi-l0cyMroinI0@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
On 10-04-2014 15:14, David Laight wrote:
>>>>> It doesn't do any pin muxing. It switches SoC internal USB
>>>>> signals between
>>>>> USB controllers. The pins remain the same.
>>>> Doesn't something like that already happen for the companion USB1
>>>> controllers for USB2 ports?
>>> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
> Yes.
> Why do you care which USB controller is driving the pins?
Because the controllers the driver switches between are not companions.
The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device
controller in this case) controllers on port 0 and between PCI EHCI/OHCI and
non-PCI xHCI controller on port 2.
>>>> That also doesn't sound like you are changing the PHY.
>>> I am changing one of the PHY registers that controls USB port
>>> (Renesas calls it channel) multiplexing.
>>>> I'd have thought that would happen if you had a single controller
>>>> that select between multiply PHY.
>>> No, it's not the case.
> I realised that wasn't what you were doing, but at first it did seem
> to be what you were doing.
The PHY really does belong to the USBHS controller but that multiplexing
register inside it controls routing of the ports 0 and 2; USBHS itself is on
port 0.
>> There is an interesting case, the USB3 shares a PHY with a SATA
>> and the PCIE and SATA also share a PHY on the R8A7790.
> Some of those look like pcb design decisions - so there is no dynamic
> changing, just config time plumbing.
No, there are also host/device mode DIP switches on the boards which
control port 0 signals (and the port 0 connector is micro-AB, so both a host
and device can be connected). The second board also has OTG chip on port 0
thru which USB ID pin can be read from the micro-AB connector.
> David
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
@ 2014-04-10 12:40 ` Sergei Shtylyov
0 siblings, 0 replies; 32+ messages in thread
From: Sergei Shtylyov @ 2014-04-10 12:40 UTC (permalink / raw
To: David Laight, 'Ben Dooks', Stephen Warren, Alan Stern
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
balbi-l0cyMroinI0@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
On 10-04-2014 15:14, David Laight wrote:
>>>>> It doesn't do any pin muxing. It switches SoC internal USB
>>>>> signals between
>>>>> USB controllers. The pins remain the same.
>>>> Doesn't something like that already happen for the companion USB1
>>>> controllers for USB2 ports?
>>> Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2?
> Yes.
> Why do you care which USB controller is driving the pins?
Because the controllers the driver switches between are not companions.
The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device
controller in this case) controllers on port 0 and between PCI EHCI/OHCI and
non-PCI xHCI controller on port 2.
>>>> That also doesn't sound like you are changing the PHY.
>>> I am changing one of the PHY registers that controls USB port
>>> (Renesas calls it channel) multiplexing.
>>>> I'd have thought that would happen if you had a single controller
>>>> that select between multiply PHY.
>>> No, it's not the case.
> I realised that wasn't what you were doing, but at first it did seem
> to be what you were doing.
The PHY really does belong to the USBHS controller but that multiplexing
register inside it controls routing of the ports 0 and 2; USBHS itself is on
port 0.
>> There is an interesting case, the USB3 shares a PHY with a SATA
>> and the PCIE and SATA also share a PHY on the R8A7790.
> Some of those look like pcb design decisions - so there is no dynamic
> changing, just config time plumbing.
No, there are also host/device mode DIP switches on the boards which
control port 0 signals (and the port 0 connector is micro-AB, so both a host
and device can be connected). The second board also has OTG chip on port 0
thru which USB ID pin can be read from the micro-AB connector.
> David
WBR, Sergei
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2014-04-10 12:40 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-09 13:57 [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver' Sergei Shtylyov
2014-04-09 13:57 ` Sergei Shtylyov
2014-04-09 15:31 ` Stephen Warren
2014-04-09 15:31 ` Stephen Warren
2014-04-09 16:27 ` Sergei Shtylyov
2014-04-09 16:27 ` Sergei Shtylyov
2014-04-09 16:48 ` Stephen Warren
2014-04-09 16:48 ` Stephen Warren
[not found] ` <534579D5.10306-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-04-09 16:53 ` Sergei Shtylyov
2014-04-09 16:53 ` Sergei Shtylyov
2014-04-09 17:37 ` Stephen Warren
2014-04-09 17:37 ` Stephen Warren
2014-04-09 17:52 ` Sergei Shtylyov
2014-04-09 17:52 ` Sergei Shtylyov
2014-04-09 17:56 ` Alan Stern
2014-04-09 17:56 ` Alan Stern
2014-04-09 18:16 ` Sergei Shtylyov
2014-04-09 18:16 ` Sergei Shtylyov
[not found] ` <53458E95.4080505-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2014-04-09 19:01 ` Stephen Warren
2014-04-09 19:01 ` Stephen Warren
[not found] ` <534598EF.3010102-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-04-09 19:06 ` Sergei Shtylyov
2014-04-09 19:06 ` Sergei Shtylyov
2014-04-10 9:20 ` David Laight
2014-04-10 10:49 ` Sergei Shtylyov
2014-04-10 10:49 ` Sergei Shtylyov
2014-04-10 11:01 ` Ben Dooks
2014-04-10 11:01 ` Ben Dooks
2014-04-10 11:14 ` David Laight
2014-04-10 11:20 ` Ben Dooks
2014-04-10 11:20 ` Ben Dooks
[not found] ` <063D6719AE5E284EB5DD2968C1650D6D0F6F44A4-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2014-04-10 12:40 ` Sergei Shtylyov
2014-04-10 12:40 ` Sergei Shtylyov
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.