Re: Linux USB file storage gadget with new UDC
Hi, > Yes, i see the bad characters in the log file. I apologize for that, > my eyes was in pain after looking thru the log files and did not > notice that when i attached the log file. > > The good news is i can get gadget to work with Lenovo x100e on Ubuntu > and Windows. The change is adding more delay after writing to endpoint > one IN FIFO register, for the case of writing more than the endpoint > buffer size. However, the gadget only work on high-speed mode. If i > disable ehci_hcd driver in Ubuntu (force it to be full speed), the > same problem of SCSI_READ_10 command asking 4096 bytes and gadget > returning the data, and gadget reset, still happens. I can bring up the gadget in full speed mode now, so the SCSI_READ_10 command problem is fixed. It is caused by an error interfacing to hardware. Now there is another problem with SCSI_MODE_SELECT_6 command, when in full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte, and somehow the gadget is reset. Is it because gadget is not able to handle the amount of data? Please see the attached gadget log. Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command is 24 byte. Thanks, victor g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop USB_RECIP_DEVICE fa is 0x3 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor exit C ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: full-speed config #1 EP1 OUT IRQ 0x28 ept0 in queue len 0x0, buffer 0xc128f800 g_file_storage gadget: in handle_exception loop [start_transfer] 800 0 ept1 out queue len 0x40, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 64 31 EP1 OUT IRQ 0x28 [kagen2_ep_queue] 43425355 87a68008 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 80 a6 87 18 00 00 00 00 00 06 15 0010: 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: MODE SELECT(6); Dc=6, Do=24; Hc=6, Ho=24 attention condition [start_transfer] 43425355 87a68008 ept1 out queue len 0x40, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 24 64 24 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 48 64 24 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 72 64 24 [kagen2_ep_queue] 800 0 g_file_storage gadget: bulk-out, length 72: : 00 00 00 08 00 00 00 00 00 00 02 00 08 0a 00 00 0010: ff ff 00 00 ff ff ff ff 00 00 00 00 00 00 00 5f 0020: c1 9f 75 00 58 1d 00 00 00 00 00 00 02 00 00 00 0030: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 80 00 29 5f 22 e8 c2 4e g_file_storage gadget: bulk_out_complete --> 0, 72/24 g_file_storage gadget: before calling send_status g_file_storage gadget: sending command-failure status g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 08 80 a6 87 18 00 00 00 01 [start_transfer] 53425355 87a68008 exit C ept1 in queue len 0xd, buffer 0xc135 0: 0x53425355 4: 0x87a68008 8: 0x18 bulk_in_complete --> 0, 13/13 handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: in fsg->running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18
Re: [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
* Kevin Hilman [130619 10:30]: > Hi Roger, > > Roger Quadros writes: > > > In order to support wake up from suspend use the pinctrl > > framework to put the USB host pins in IDLE state during suspend. > > > > CC: Samuel Ortiz > > Signed-off-by: Roger Quadros > > You should use helpers for this now in the pinctrl core: > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html Also see the thread "[PATCH] pinctrl: document the pinctrl PM states" as we're still discussing how to deal with the various dynamic pinctrl needs in a generic way. Meanwile, just make sure the other patches work and don't break anything without this patch to remove the dependency. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: dwc3: use extcon fwrk to receive connect/disconnect
Hi,
On Monday 17 June 2013 09:39 AM, Chanwoo Choi wrote:
On 06/14/2013 10:10 PM, Kishon Vijay Abraham I wrote:
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
---
This patch depends on
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git commit:f7ae906
It should also be applied on top of
usb: dwc3: omap: improve error handling of dwc3_omap_probe patch which is
merged in Felipe's tree.
So I'm not sure on whose tree this patch should go in.
Changes from v3:
* did #include of of_extcon.h after Chanwoo resent the patch separating
extcon-class.c from of_extcon.c
Changes from v2:
* updated the Documentation with dwc3 dt binding information.
* used of_extcon_get_extcon_dev to get extcon device from device tree data.
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some users
of palmas-usb wont need regulator.
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
drivers/usb/dwc3/dwc3-omap.c | 119
include/linux/usb/dwc3-omap.h | 30 -
3 files changed, 105 insertions(+), 49 deletions(-)
delete mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..f1c15f3 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE
It should be set to "1" for HW mode and "2" for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address
space
+Optional Properties:
+ - extcon : phandle for the extcon device omap dwc3 uses to detect
+ connect/disconnect events.
+ - vbus-supply : phandle to the regulator device tree node if needed.
+
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f8f76e6..14c1f1b 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,13 +43,15 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
#include
+#include
+#include
+#include
#include
@@ -124,9 +126,21 @@ struct dwc3_omap {
u32 utmi_otg_status;
u32 dma_status:1;
+
+ struct extcon_specific_cable_nb extcon_vbus_dev;
+ struct extcon_specific_cable_nb extcon_id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+
+ struct regulator*vbus_reg;
};
-static struct dwc3_omap*_omap;
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_VBUS_OFF,
+ OMAP_DWC3_VBUS_VALID,
+};
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
@@ -138,18 +152,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
-int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
+ enum omap_dwc3_vbus_id_status status)
{
- u32 val;
- struct dwc3_omap*omap = _omap;
-
- if (!omap)
- return -EPROBE_DEFER;
+ int ret;
+ u32 val;
switch (status) {
case OMAP_DWC3_ID_GROUND:
dev_dbg(omap->dev, "ID GND\n");
+ if (omap->vbus_reg) {
+ ret = regulator_enable(omap->vbus_reg);
+ if (ret) {
+ dev_dbg(omap->dev, "regulator enable failed\n");
+ return;
+ }
+ }
val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
val &= ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
| USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
@@ -172,6 +191,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
case OMAP_DWC3_ID_FLOAT:
+ if (omap->vbus_reg)
+ regulator_disable(omap->vbus_reg);
+
case OMAP_DWC3_VBUS_OFF:
dev_dbg(omap->dev, "VBUS Disconnect\n");
@@ -185,12 +207,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
default:
- dev_dbg(omap->dev, "ID float\n");
+ dev_dbg(omap->dev, "invalid state\n");
}
-
- return 0;
}
-EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
{
@@ -282,6 +301,32 @@ static void dwc3_omap_disable_irqs(struct dwc3_omap *omap)
stati
ATENÇÃO
ATENÇÃO; Sua caixa de correio excedeu o limite de 5 GB de armazenamento, que é como definido pelo administrador, você está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa de correio, envie os seguintes dados abaixo: nome: Usuário: senha: Confirme a Senha: Endereço de E-mail: Telefone: Se você não conseguir revalidar sua caixa de correio, a caixa de correio será desativado! obrigado Administrador do Sistema -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 00/11] USB: OHCI:Properly handle ohci_suspend()routine in bus glue
Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. V2: -Incase ohci_suspend() fails, return right away without executing further. V3: -New patch 1/11 added, for generic ohci-hcd suspend code. V4: -Properly aligned "do_wakeup" and "ret" variables. Manjunath Goudar (11): USB: OHCI: Properly handle OHCI controller suspend USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c | 10 -- drivers/usb/host/ohci-da8xx.c| 15 +++ drivers/usb/host/ohci-ep93xx.c |9 - drivers/usb/host/ohci-exynos.c | 20 +--- drivers/usb/host/ohci-hcd.c |9 - drivers/usb/host/ohci-omap.c | 13 ++--- drivers/usb/host/ohci-platform.c |9 - drivers/usb/host/ohci-pxa27x.c |8 +++- drivers/usb/host/ohci-s3c2410.c | 19 --- drivers/usb/host/ohci-sm501.c| 11 +-- drivers/usb/host/ohci-spear.c| 12 +--- 11 files changed, 87 insertions(+), 48 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 01/11] USB: OHCI: Properly handle OHCI controller suspend
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. This does proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V3: New patch.
V4: No change.
---
drivers/usb/host/ohci-hcd.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index b69a49e..f3dcaa2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1034,6 +1034,7 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
unsigned long flags;
+ int rc = 0;
/* Disable irq emission and mark HW unaccessible. Use
* the spinlock to properly synchronize with possible pending
@@ -1046,7 +1047,13 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
spin_unlock_irqrestore (&ohci->lock, flags);
- return 0;
+ synchronize_irq(hcd->irq);
+
+ if (do_wakeup && HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ return rc;
}
EXPORT_SYMBOL_GPL(ohci_suspend);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 02/11] USB: OHCI: Properly handle ohci-at91 suspend
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Acked-by: Alan Stern
Cc: Arnd Bergmann
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
- No change.
---
drivers/usb/host/ohci-at91.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..e34baa6 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,14 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
- if (device_may_wakeup(&pdev->dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
+ if (do_wakeup)
enable_irq_wake(hcd->irq);
/*
@@ -637,7 +643,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 06/11] USB: OHCI: Properly handle ohci-exynos suspend
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-rid of unwanted code from ohci_hcd_s3c2410_drv_suspend() which already
ohci_suspend() does it.
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and rc variable alignment is removed.
---
drivers/usb/host/ohci-exynos.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index ae6068d..17de3dd 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -203,24 +203,15 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(&ohci->lock, flags);
- if (ohci->rh_state != OHCI_RH_SUSPENDED &&
- ohci->rh_state != OHCI_RH_HALTED) {
- rc = -EINVAL;
- goto fail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
+ spin_lock_irqsave(&ohci->lock, flags);
if (exynos_ohci->otg)
exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
@@ -228,7 +219,6 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci->clk);
-fail:
spin_unlock_irqrestore(&ohci->lock, flags);
return rc;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and ret variable alignment is removed.
---
drivers/usb/host/ohci-ep93xx.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..f0aaa48 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,20 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
ep93xx_stop_hc(&pdev->dev);
- return 0;
+
+ return ret;
}
static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 03/11] USB: OHCI: Properly handle ohci-s3c2410 suspend
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-rid of unwanted code from ohci_hcd_s3c2410_drv_suspend()
which already ohci_suspend() does it.
V4:
-The do_wakeup variable alignment is removed.
---
drivers/usb/host/ohci-s3c2410.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index 8018bb1..4ccf156 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -428,26 +428,15 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device
*dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(&ohci->lock, flags);
- if (ohci->rh_state != OHCI_RH_SUSPENDED) {
- rc = -EINVAL;
- goto bail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
s3c2410_stop_hc(pdev);
-bail:
- spin_unlock_irqrestore(&ohci->lock, flags);
return rc;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 07/11] USB: OHCI: Properly handle ohci-omap suspend
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and ret variable alignment is removed.
---
drivers/usb/host/ohci-omap.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 10ba58d..baefc46 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -432,16 +432,23 @@ static int ohci_hcd_omap_drv_remove(struct
platform_device *dev)
#ifdef CONFIG_PM
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t
message)
{
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(dev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
omap_ohci_clock_power(0);
- return 0;
+ return ret;
}
static int ohci_omap_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 04/11] USB: OHCI: Properly handle ohci-da8xx suspend
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
-pdev->dev.power.power_state stuff has been removed.
V4:
-Properly aligned "do_wakeup" and "ret" variable.
---
drivers/usb/host/ohci-da8xx.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..44893cf 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,26 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
ohci_da8xx_clock(0);
hcd->state = HC_STATE_SUSPENDED;
- dev->dev.power.power_state = PMSG_SUSPEND;
- return 0;
+
+ return ret;
}
static int ohci_da8xx_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 11/11] USB: OHCI: Properly handle ohci-spear suspend
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and ret variable alignment is removed.
---
drivers/usb/host/ohci-spear.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..41148f8 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,26 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
clk_disable_unprepare(sohci_p->clk);
- return 0;
+ return ret;
}
static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 10/11] USB: OHCI: Properly handle ohci-sm501 suspend
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and ret variable alignment is removed.
---
drivers/usb/host/ohci-sm501.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..2a5de5f 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,21 @@ static int ohci_hcd_sm501_drv_remove(struct
platform_device *pdev)
static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
{
struct device *dev = &pdev->dev;
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
if (time_before(jiffies, ohci->next_statechange))
msleep(5);
ohci->next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
sm501_unit_power(dev->parent, SM501_GATE_USB_HOST, 0);
- return 0;
+ return ret;
}
static int ohci_sm501_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 09/11] USB: OHCI: Properly handle ohci-pxa27x suspend
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and ret variable alignment is removed.
---
drivers/usb/host/ohci-pxa27x.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..5fb91f1 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,19 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
if (time_before(jiffies, ohci->ohci.next_statechange))
msleep(5);
ohci->ohci.next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
pxa27x_stop_hc(ohci, dev);
- return 0;
+ return ret;
}
static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 08/11] USB: OHCI: Properly handle ohci-platform suspend
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
V4:
-The do_wakeup and ret variable alignment is removed.
---
drivers/usb/host/ohci-platform.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index bc30475..b4a8784 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -139,14 +139,21 @@ static int ohci_platform_remove(struct platform_device
*dev)
static int ohci_platform_suspend(struct device *dev)
{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev->platform_data;
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
if (pdata->power_suspend)
pdata->power_suspend(pdev);
- return 0;
+ return ret;
}
static int ohci_platform_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi, >> Yes, i see the bad characters in the log file. I apologize for that, >> my eyes was in pain after looking thru the log files and did not >> notice that when i attached the log file. >> >> The good news is i can get gadget to work with Lenovo x100e on Ubuntu >> and Windows. The change is adding more delay after writing to endpoint >> one IN FIFO register, for the case of writing more than the endpoint >> buffer size. However, the gadget only work on high-speed mode. If i >> disable ehci_hcd driver in Ubuntu (force it to be full speed), the >> same problem of SCSI_READ_10 command asking 4096 bytes and gadget >> returning the data, and gadget reset, still happens. > > I can bring up the gadget in full speed mode now, so the SCSI_READ_10 > command problem is fixed. It is caused by an error interfacing to > hardware. > > Now there is another problem with SCSI_MODE_SELECT_6 command, when in > full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte, > and somehow the gadget is reset. Is it because gadget is not able to > handle the amount of data? Please see the attached gadget log. > Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command > is 24 byte. The problem is in UDC driver. i made the change, it is ok now. Thanks, victor -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 04/11] USB: OHCI: Properly handle ohci-da8xx suspend
Hello.
On 20-06-2013 13:36, Manjunath Goudar wrote:
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V2:
-Incase ohci_suspend() fails, return right away without
executing further.
V3:
-Aligned variable "do_wakeup" and "ret".
-pdev->dev.power.power_state stuff has been removed.
V4:
-Properly aligned "do_wakeup" and "ret" variable.
---
drivers/usb/host/ohci-da8xx.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..44893cf 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,26 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
Could you align this line more, so that it starts under the
character after ( in the previous line.
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(&pdev->dev);
+ int ret;
I wouldn't call this "properly aligned". It need one more tab.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
On 06/19/2013 09:42 PM, Kevin Hilman wrote:
> Roger Quadros writes:
>
>> Add the Idle state pins for USB host and enable WAKEUP on
>> DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
>> sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
>>
>> CC: Benoît Cousson
>> Signed-off-by: Roger Quadros
>
> This one doesn't apply...
>
>> ---
>> arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
>> 1 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
>> b/arch/arm/boot/dts/omap3-beagle-xm.dts
>> index d3808ed..f1d56c2 100644
>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>> @@ -89,12 +89,7 @@
>> };
>>
>> &omap3_pmx_core {
>> -pinctrl-names = "default";
>> -pinctrl-0 = <
>> -&hsusbb2_pins
>> ->;
>> -
>> -hsusbb2_pins: pinmux_hsusbb2_pins {
>
> This omap3_pmx_core section doesn't exist upstream in the xM DTS file
> (but does in omap3-beagle.dts.)
>
> Is there a dependency patch missing?
>
Sorry for not mentioning it earlier. This is based on Benoit's tree [1]
and you need these patches
http://thread.gmane.org/gmane.linux.drivers.devicetree/38383
[1]
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
/for_3.11/dts
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
On 06/20/2013 02:55 PM, Roger Quadros wrote:
> On 06/19/2013 09:42 PM, Kevin Hilman wrote:
>> Roger Quadros writes:
>>
>>> Add the Idle state pins for USB host and enable WAKEUP on
>>> DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
>>> sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
>>>
>>> CC: Benoît Cousson
>>> Signed-off-by: Roger Quadros
>>
>> This one doesn't apply...
>>
>>> ---
>>> arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
>>> 1 files changed, 23 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> index d3808ed..f1d56c2 100644
>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> @@ -89,12 +89,7 @@
>>> };
>>>
>>> &omap3_pmx_core {
>>> - pinctrl-names = "default";
>>> - pinctrl-0 = <
>>> - &hsusbb2_pins
>>> - >;
>>> -
>>> - hsusbb2_pins: pinmux_hsusbb2_pins {
>>
>> This omap3_pmx_core section doesn't exist upstream in the xM DTS file
>> (but does in omap3-beagle.dts.)
>>
>> Is there a dependency patch missing?
>>
>
> Sorry for not mentioning it earlier. This is based on Benoit's tree [1]
> and you need these patches
>
> http://thread.gmane.org/gmane.linux.drivers.devicetree/38383
Just noticed that this no longer applies today. I'll send a revision soon.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init()
Hi,
On Wed, Jun 19, 2013 at 05:05:48PM +0300, Roger Quadros wrote:
> We no longer need to be initialized in any particular order
> so move driver initialization to the standard place i.e. module_init()
>
> CC: Samuel Ortiz
> Signed-off-by: Roger Quadros
> ---
> drivers/mfd/omap-usb-host.c | 10 +-
> drivers/mfd/omap-usb-tll.c |8 +---
> 2 files changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 759fae3..6601a49 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
> {
> return platform_driver_probe(&usbhs_omap_driver, usbhs_omap_probe);
> }
> -
> -/*
> - * init before ehci and ohci drivers;
> - * The usbhs core driver should be initialized much before
> - * the omap ehci and ohci probe functions are called.
> - * This usbhs core driver should be initialized after
> - * usb tll driver
> - */
> -fs_initcall_sync(omap_usbhs_drvinit);
> +module_init(omap_usbhs_drvinit);
>
> static void __exit omap_usbhs_drvexit(void)
> {
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index e59ac4c..fb7c73e 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
> {
> return platform_driver_register(&usbtll_omap_driver);
> }
> -
> -/*
> - * init before usbhs core driver;
> - * The usbtll driver should be initialized before
> - * the usbhs core driver probe function is called.
> - */
> -fs_initcall(omap_usbtll_drvinit);
> +module_init(omap_usbtll_drvinit);
since you're doing that, could just move to module_platform_driver.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
Hi,
On Wed, Jun 19, 2013 at 05:05:51PM +0300, Roger Quadros wrote:
> Runtime suspend the controller during bus suspend and resume it
> during bus resume. This will ensure that the USB Host power domain
> enters lower power state and does not prevent the SoC from
> endering deeper sleep states.
>
> Remote wakeup will come up as an interrupt while the controller
> is suspended, so tackle it carefully using a workqueue.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/usb/host/ehci-omap.c | 82
> ++
> 1 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
> index 16d7150..91f14f1 100644
> --- a/drivers/usb/host/ehci-omap.c
> +++ b/drivers/usb/host/ehci-omap.c
> @@ -44,6 +44,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "ehci.h"
>
> @@ -69,6 +71,7 @@ static const char hcd_name[] = "ehci-omap";
> struct omap_hcd {
> struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
> int nports;
> + struct work_struct work;
> };
>
> static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
> @@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
> return __raw_readl(base + reg);
> }
>
> +static void omap_ehci_work(struct work_struct *work)
> +{
> + struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
> + struct ehci_hcd *ehci = container_of((void *) omap,
> + struct ehci_hcd, priv);
> + struct usb_hcd *hcd = ehci_to_hcd(ehci);
> + struct device *dev = hcd->self.controller;
> +
> + pm_runtime_get_sync(dev);
> + enable_irq(hcd->irq);
> + /*
> + * enable_irq() should preempt us with a pending IRQ
> + * so we can be sure that IRQ handler completes before
> + * we call pm_runtime_put_sync()
> + */
> + pm_runtime_put_sync(dev);
> +}
> +
> +static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
> +{
> + struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
> + struct device *dev = hcd->self.controller;
> + irqreturn_t ret;
> +
> + if (pm_runtime_suspended(dev)) {
> + schedule_work(&omap->work);
> + disable_irq_nosync(hcd->irq);
> + ret = IRQ_HANDLED;
looks like this could be done as:
if (pm_runtime_suspended(dev)) {
pm_runtime_get(dev);
omap->flags |= OMAP_EHCI_IRQ_PENDING;
disable_irq_nosync(hcd->irq);
ret = IRQ_HANDLED;
}
then on your ->runtime_resume():
runtime_resume(dev)
{
...
if (omap->flags & OMAP_EHCI_IRQ_PENDING) {
process_pending_irqs(omap);
omap->flags &= ~OMAP_EHCI_IRQ_PENDING;
}
return 0;
}
or something similar
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget: fotg210-udc: Use module_platform_driver_probe macro
Hi, On Thu, Jun 20, 2013 at 01:53:13PM +, Yuan-Hsin Chen wrote: > Because fotg210-udc is configured as a non-hotpluggable device, > that makes sense to use module_platform_driver_probe() instead of > module_platform_driver(). This also fixes the section mismatch issue. > > Signed-off-by: Yuan-Hsin Chen I would rather see you remove __init annotation from your probe() function. The reason being that it will users to bind/unbind the driver through sysfs, which is pretty good for testing, at least. -- balbi signature.asc Description: Digital signature
Re: [PATCH V2] USB: initialize or shutdown PHY when add or remove host controller
Hi, On Thu, Jun 20, 2013 at 08:53:05AM +0800, Chao Xie wrote: > >> @@ -2674,6 +2693,9 @@ void usb_remove_hcd(struct usb_hcd *hcd) > >> free_irq(hcd->irq, hcd); > >> } > >> > >> + if (hcd->phy) > >> + usb_phy_shutdown(hcd->phy); > >> + > >> usb_put_dev(hcd->self.root_hub); > >> usb_deregister_bus(&hcd->self); > >> hcd_buffer_destroy(hcd); > >> > > > > I still think that we shouldn't do this because it adds more confusion and > > is not > > still a generic enough solution. > > > > 1) It is better for the piece of code that does usb_phy_get() to do > > usb_phy_init/shutdown, > > else there will be lot of confusion. (Felipe pointed this out earlier). > > > > 2) There is no standard way of getting phy for different controllers. It is > > mostly platform > > dependent and it is best to leave this to the controller drivers. (Pointed > > out by Alan). > > > > 3) Controllers can have multiple PHYs. e.g. ehci-omap has one PHY per port > > and it supports > > 3 ports. This is also platform specific and difficult to handle generically. > > > > 4) Controllers can have specific timing requirements as to when the PHY is > > initialized relative > > to the controller being initialized. I've pointed OMAP specific stuff in > > the earlier patch. > > > > Considering all these points, I think we should leave things as they are. > > It isn't that hard > > for controllers to manage phy_init() and phy_shutdown(), and there is not > > much code space saved > > when compared to the complexity it creates if we move them to HCD layer. > > > In fact, the PHY setting and handling is related to platform or SOC, > and for different SOC they can > have same EHCI HCD but they PHY handling can be different. > Omap'a case is the example, and i think some other vendors may have > silimar cases. > From above point, It is better to leave the PHY initialization and > shutdown to be done by each echi-xxx driver. > > So Alan and Felipe > What are your ideas about it? If we have so many exceptions, then sure. But eventually, the common case should be added generically with a flag so that non-generic cases (like OMAP) can request to handle the PHY by themselves. Alan ? -- balbi signature.asc Description: Digital signature
[PATCH 1/1] net: add dm9620 net usb driver
DM9620 is an USB2.0 network adapter rather than DM9601 USB1.1. This
driver processed the RX data 4 bytes header, TX data 2 bytes header,
make the control bit exactly right in PHY write function, and optional
IFF_ALLMUTLI bit for RX control.
Tested good for many platforms, include X86 desktop and ARM embedded.
Signed-off-by: Joseph CHANG
---
drivers/net/usb/Kconfig | 13 +
drivers/net/usb/Makefile |1 +
drivers/net/usb/dm9620.c | 796 ++
3 files changed, 810 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/usb/dm9620.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 287cc62..e9c9e2a 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -272,6 +272,19 @@ config USB_NET_DM9601
This option adds support for Davicom DM9601 based USB 1.1
10/100 Ethernet adapters.
+config USB_NET_DM9620
+ tristate "Davicom DM9620/21 based USB 2.0 10/100 ethernet devices"
+ depends on USB_USBNET
+ select CRC32
+ help
+ This option adds support for Davicom DM9620 based USB 2.0
+ 10/100 Ethernet adapters.
+
+ This driver creates an interface named "ethX", where X depends on
+ what other networking devices you have in use.
+
+ To compile this driver as a module, choose M here.
+
config USB_NET_SMSC75XX
tristate "SMSC LAN75XX based USB 2.0 gigabit ethernet devices"
depends on USB_USBNET
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 9ab5c9d..7d95e5c 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o
obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
+obj-$(CONFIG_USB_NET_DM9620) += dm9620.o
obj-$(CONFIG_USB_NET_SMSC75XX) += smsc75xx.o
obj-$(CONFIG_USB_NET_SMSC95XX) += smsc95xx.o
obj-$(CONFIG_USB_NET_GL620A) += gl620a.o
diff --git a/drivers/net/usb/dm9620.c b/drivers/net/usb/dm9620.c
new file mode 100644
index 000..aa4226b
--- /dev/null
+++ b/drivers/net/usb/dm9620.c
@@ -0,0 +1,796 @@
+/*
+ * Davicom DM9620 USB 2.0 10/100Mbps ethernet devices
+ *
+ * Peter Korsgaard
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/* #define DEBUG */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* control requests */
+#define DM_READ_REGS 0x00
+#define DM_WRITE_REGS 0x01
+#define DM_READ_MEMS 0x02
+#define DM_WRITE_REG 0x03
+#define DM_WRITE_MEMS 0x05
+#define DM_WRITE_MEM 0x07
+
+/* registers */
+#define DM_NET_CTRL0x00
+#define DM_RX_CTRL 0x05
+#define DM_FCR 0x0a
+#define DM_SHARED_CTRL 0x0b
+#define DM_SHARED_ADDR 0x0c
+#define DM_SHARED_DATA 0x0d/* low + high */
+#define DM_SHARED_DL 0x0d
+#define DM_SHARED_DH 0x0e
+#define DM_WAKEUP_CTRL 0x0f
+#define DM_PHY_ADDR0x10/* 6 bytes */
+#define DM_MCAST_ADDR 0x16/* 8 bytes */
+#define DM_GPR_CTRL0x1e
+#define DM_GPR_DATA0x1f
+#define DM_PID 0x2a
+#define DM_CHIP_ID 0x2c
+#define DM_XPHY_CTRL 0x2e/* reserved */
+#define DM_TX_CRC_CTRL 0x31
+#define DM_RX_CRC_CTRL 0x32
+#define DM_AZR 0x3f/* reserved */
+#define DM_USB_CTRL0xf4
+#define DM_MODE_CTRL 0x91/* only on dm9620 */
+#define DM_CHIP_ID_EX 0x5C
+
+#define MD96XX_EEPROM_MAGIC0x9620
+#define DM_MAX_MCAST 64
+#define DM_MCAST_SIZE 8
+#define DM_EEPROM_LEN 256
+#define DM_TX_OVERHEAD 2 /* 2 byte header */
+#define DM_RX_OVERHEAD 8 /* 4 byte header + 4 byte crc tail */
+#define DM_TIMEOUT 1000
+
+#define DM_NCR_RST (1<<0)
+#define DM_NCR_WAKEEN (1<<6)
+
+#define DM_FCR_TXPEN (1<<5)
+#define DM_FCR_BKPM(1<<3)
+#define DM_FCR_FLCE(1<<0)
+
+#define DMSC_WEP (1<<4)
+#define DMSC_ERPRW (1<<1)
+#define DMSC_ERRE (1<<0)
+
+#define DM_LINKEN (1<<5)
+#define DM_MAGICEN (1<<3)
+
+#define DM_TX_UDPCSE (1<<2)
+#define DM_TX_TCPCSE (1<<1)
+#define DM_TX_IPCSE(1<<0)
+#define DM_RX_RCSEN(1<<1)
+#define DM_MODE_DM_TXRX(0<<4)
+#define DM_MODE_CDC_TRX(1<<4)
+#define DM_MODE_DM_DESC(0<<5)
+#define DM_MODE_CDC_DES(1<<5)
+
+#define DM_USB_EP3ACK (1<<5)
+
+#define DM_MODE9601(0<<7)
+#define DM_MODE9620(1<<7)
+#define DM9620_PHY_ID 1 /* Stone add For kernel read phy register */
+
+#define VID_DAVICOM0x0a46
+
+#define PID_DM9620 0x9620
+#define PID_DM9621 0x9621
+#define PID_DM9622 0x9622
+#define PID_DM9620A0x0269
+#define PID_DM9621A0x1269
+
+static int dm_read(struct usbnet *dev, u8 reg, u16 length, void *data)
+{
+ int err;
+ err = usbnet_read_cmd(dev, DM_READ_REG
Re: [RFC PATCH 1/6] mfd: omap-usb-host: move initialization to module_init()
On 06/20/2013 03:07 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jun 19, 2013 at 05:05:48PM +0300, Roger Quadros wrote:
>> We no longer need to be initialized in any particular order
>> so move driver initialization to the standard place i.e. module_init()
>>
>> CC: Samuel Ortiz
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/mfd/omap-usb-host.c | 10 +-
>> drivers/mfd/omap-usb-tll.c |8 +---
>> 2 files changed, 2 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 759fae3..6601a49 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -908,15 +908,7 @@ static int __init omap_usbhs_drvinit(void)
>> {
>> return platform_driver_probe(&usbhs_omap_driver, usbhs_omap_probe);
>> }
>> -
>> -/*
>> - * init before ehci and ohci drivers;
>> - * The usbhs core driver should be initialized much before
>> - * the omap ehci and ohci probe functions are called.
>> - * This usbhs core driver should be initialized after
>> - * usb tll driver
>> - */
>> -fs_initcall_sync(omap_usbhs_drvinit);
>> +module_init(omap_usbhs_drvinit);
>>
>> static void __exit omap_usbhs_drvexit(void)
>> {
>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
>> index e59ac4c..fb7c73e 100644
>> --- a/drivers/mfd/omap-usb-tll.c
>> +++ b/drivers/mfd/omap-usb-tll.c
>> @@ -482,13 +482,7 @@ static int __init omap_usbtll_drvinit(void)
>> {
>> return platform_driver_register(&usbtll_omap_driver);
>> }
>> -
>> -/*
>> - * init before usbhs core driver;
>> - * The usbtll driver should be initialized before
>> - * the usbhs core driver probe function is called.
>> - */
>> -fs_initcall(omap_usbtll_drvinit);
>> +module_init(omap_usbtll_drvinit);
>
> since you're doing that, could just move to module_platform_driver.
>
sounds good.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/6] mfd: omap-usb-host: Put pins in IDLE state on suspend
On 06/19/2013 08:23 PM, Kevin Hilman wrote: > Hi Roger, > > Roger Quadros writes: > >> In order to support wake up from suspend use the pinctrl >> framework to put the USB host pins in IDLE state during suspend. >> >> CC: Samuel Ortiz >> Signed-off-by: Roger Quadros > > You should use helpers for this now in the pinctrl core: > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/173514.html > Right. thanks. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 06/19/2013 08:39 PM, Kevin Hilman wrote: > Hi Roger, > > Roger Quadros writes: > >> Runtime suspend the controller during bus suspend and resume it >> during bus resume. This will ensure that the USB Host power domain >> enters lower power state and does not prevent the SoC from >> endering deeper sleep states. >> >> Remote wakeup will come up as an interrupt while the controller >> is suspended, so tackle it carefully using a workqueue. > > I don't think you need a special workqueue here. The workqueue of the PM > core (pm_wq) will be used if you just use an asynchronous 'get' in the > ISR. Then, the driver's own runtime PM callbacks can be used instead of > an additional workqueue. > > Another thing to worry about here when using runtime PM to implement > suspend/resume is that runtime PM can be disabled from userspace (e.g. > echo disabled > /sys/devices/.../power/control.) If that's the case, > all the pm_runtime_suspended() checks will always fail becuase that > call also checks if runtime PM is disabled. You'll likely want to use > the pm_runtime_status_suspended() check instead, which checks only the > status, and doesn't matter if runtime PM is currently disabled. > > Because of the corner issues here, please test system suspend/resume > when runtime PM has been disabled. > Good points. Thanks. I'll need to think about it some more. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On 06/20/2013 03:11 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jun 19, 2013 at 05:05:51PM +0300, Roger Quadros wrote:
>> Runtime suspend the controller during bus suspend and resume it
>> during bus resume. This will ensure that the USB Host power domain
>> enters lower power state and does not prevent the SoC from
>> endering deeper sleep states.
>>
>> Remote wakeup will come up as an interrupt while the controller
>> is suspended, so tackle it carefully using a workqueue.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/usb/host/ehci-omap.c | 82
>> ++
>> 1 files changed, 82 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
>> index 16d7150..91f14f1 100644
>> --- a/drivers/usb/host/ehci-omap.c
>> +++ b/drivers/usb/host/ehci-omap.c
>> @@ -44,6 +44,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include "ehci.h"
>>
>> @@ -69,6 +71,7 @@ static const char hcd_name[] = "ehci-omap";
>> struct omap_hcd {
>> struct usb_phy *phy[OMAP3_HS_USB_PORTS]; /* one PHY for each port */
>> int nports;
>> +struct work_struct work;
>> };
>>
>> static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
>> @@ -81,6 +84,76 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
>> return __raw_readl(base + reg);
>> }
>>
>> +static void omap_ehci_work(struct work_struct *work)
>> +{
>> +struct omap_hcd *omap = container_of(work, struct omap_hcd, work);
>> +struct ehci_hcd *ehci = container_of((void *) omap,
>> +struct ehci_hcd, priv);
>> +struct usb_hcd *hcd = ehci_to_hcd(ehci);
>> +struct device *dev = hcd->self.controller;
>> +
>> +pm_runtime_get_sync(dev);
>> +enable_irq(hcd->irq);
>> +/*
>> + * enable_irq() should preempt us with a pending IRQ
>> + * so we can be sure that IRQ handler completes before
>> + * we call pm_runtime_put_sync()
>> + */
>> +pm_runtime_put_sync(dev);
>> +}
>> +
>> +static irqreturn_t omap_ehci_irq(struct usb_hcd *hcd)
>> +{
>> +struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
>> +struct device *dev = hcd->self.controller;
>> +irqreturn_t ret;
>> +
>> +if (pm_runtime_suspended(dev)) {
>> +schedule_work(&omap->work);
>> +disable_irq_nosync(hcd->irq);
>> +ret = IRQ_HANDLED;
>
> looks like this could be done as:
>
> if (pm_runtime_suspended(dev)) {
> pm_runtime_get(dev);
> omap->flags |= OMAP_EHCI_IRQ_PENDING;
> disable_irq_nosync(hcd->irq);
> ret = IRQ_HANDLED;
> }
>
> then on your ->runtime_resume():
>
> runtime_resume(dev)
> {
> ...
>
> if (omap->flags & OMAP_EHCI_IRQ_PENDING) {
> process_pending_irqs(omap);
OK, thanks.
But I'm not sure if the generic ehci_irq handler is able to
run in a process context. Maybe if we replace spin_lock(&ehci->lock);
with spin_lock_irqsave() there, it will work.
Alan is this a doable option?
> omap->flags &= ~OMAP_EHCI_IRQ_PENDING;
> }
>
> return 0;
> }
>
> or something similar
>
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] Suspend USB Host controller on bus suspend
On 06/19/2013 06:23 PM, Alan Stern wrote: > On Wed, 19 Jun 2013, Roger Quadros wrote: > >> Hi, >> >> This series attempts to suspend the OMAP EHCI host controller on USB >> Bus suspend. > > Why do you want to suspend the host controller during bus suspend? > They are two different operations and should be carried out at two > different times. The controller should be suspended during controller > suspend, not during bus suspend. > Good point. I didn't think it that way. I think it should work. >> As the omap-ehci controller driver needs to do some additional work to put >> itself into suspend/resume and make sure it is resumed to process an >> interrupt, >> we need to be able to override irq, bus_suspend, and bus_resume handlers. >> This >> provision is done in patch 3. > > Do you still need to override these things if you do the controller > suspend at the right time? > At least not for bus_suspend and bus_resume. We will still need to override the irq handler though. But, if we can take care of this generically in the ehci_irq handler (i.e. make sure controller is not suspended while accessing it) then we don't need such override for irq. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] ARM: OMAP3: Enable Hardware Save and Restore for USB Host
On 06/19/2013 08:30 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 06/19/2013 06:05 PM, Roger Quadros wrote:
>
>> To ensure hardware context is restored while resuming from
>> OFF mode we need to enable the Hardware SAR bit for the
>> USB Host power domain.
>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
>> 1 files changed, 1 insertions(+), 7 deletions(-)
>
>> diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> b/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> index f0e14e9..9554d2b 100644
>> --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> @@ -289,13 +289,7 @@ static struct powerdomain usbhost_pwrdm = {
>> .prcm_offs = OMAP3430ES2_USBHOST_MOD,
>> .pwrsts = PWRSTS_OFF_RET_ON,
>> .pwrsts_logic_ret = PWRSTS_RET,
>> -/*
>> - * REVISIT: Enabling usb host save and restore mechanism seems to
>> - * leave the usb host domain permanently in ACTIVE mode after
>> - * changing the usb host power domain state from OFF to active once.
>> - * Disabling for now.
>> - */
>> -/*.flags = PWRDM_HAS_HDWR_SAR,*/ /* for USBHOST ctrlr only */
>> +.flags = PWRDM_HAS_HDWR_SAR, /* for USBHOST ctrlr only */
>
>Looks like you're not indenting = right, in accordance to the other
> fields...
Will fix. Thanks.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
On 06/20/2013 03:02 PM, Roger Quadros wrote:
> On 06/20/2013 02:55 PM, Roger Quadros wrote:
>> On 06/19/2013 09:42 PM, Kevin Hilman wrote:
>>> Roger Quadros writes:
>>>
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson
Signed-off-by: Roger Quadros
>>>
>>> This one doesn't apply...
>>>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index d3808ed..f1d56c2 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -89,12 +89,7 @@
};
&omap3_pmx_core {
- pinctrl-names = "default";
- pinctrl-0 = <
- &hsusbb2_pins
- >;
-
- hsusbb2_pins: pinmux_hsusbb2_pins {
>>>
>>> This omap3_pmx_core section doesn't exist upstream in the xM DTS file
>>> (but does in omap3-beagle.dts.)
>>>
>>> Is there a dependency patch missing?
>>>
>>
>> Sorry for not mentioning it earlier. This is based on Benoit's tree [1]
>> and you need these patches
>>
>> http://thread.gmane.org/gmane.linux.drivers.devicetree/38383
>
> Just noticed that this no longer applies today. I'll send a revision soon.
>
OK. In case you are eager to test, please use the series [1] on l-o on top of
Benoit's
for_3.11/_dts branch and then the $subject series with the updated patch 5
below [2].
[1] - [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
[2] - Updated Patch 5
>From b712a1fb936f65fa05f21fcd2c62fff5628d0628 Mon Sep 17 00:00:00 2001
From: Roger Quadros
Date: Wed, 19 Jun 2013 11:14:35 +0300
Subject: [PATCH] ARM: dts: omap3beagle-xm: Add idle state pins for USB host
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 371b1e2..91d19fa 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -113,11 +113,6 @@
};
&omap3_pmx_core {
- pinctrl-names = "default";
- pinctrl-0 = <
- &hsusbb2_pins
- >;
-
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = <
0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
@@ -125,7 +120,7 @@
>;
};
- hsusbb2_pins: pinmux_hsusbb2_pins {
+ hsusb2_pins: pinmux_hsusb2_pins {
pinctrl-single,pins = <
0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
@@ -141,6 +136,25 @@
0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
>;
};
+
+ /* WAKEUP enabled on DIR, DAT0-3 */
+ hsusb2_idle_pins: pinmux_hsusb2_idle_pins {
+ pinctrl-single,pins = <
+ 0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+ 0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+ 0x5c4 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d12.hsusb2_dir */
+ 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3)
/* etk_d13.hsusb2_nxt */
+ 0x5c8 (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d14.hsusb2_data0 */
+ 0x5cA (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* etk_d15.hsusb2_data1 */
+ 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+ 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+ 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+ 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+ 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+ 0x1ae (PIN_INPUT_PULLDOWN | WAKEUP_EN | MUX_MODE3)
/* mcspi2_cs1.hsusb2_data3 */
+ >;
+ interrupts = <77>; /* route padconf wakeup to EHCI IRQ */
+ };
};
&i2c1 {
@@ -223,6 +237,9 @@
};
&usbhshost {
+
[RFC] usb: musb: do not change dev's dma_mask
Commit 8d2421e ("usb: musb: kill global and static for multi instance")
removed the global dma_mask copy and replaced by parent's DMA mask. The
problem here is that if the parent does not have a dma_mask then
musb_remove() goes kaboom.
Instead trying to fix this I was thinking we do we need to erase
dma_mask in the first place?
Cc: Ajay Kumar Gupta
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_core.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 9b774e7..80ffd7e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1843,10 +1843,6 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
if (use_dma && dev->dma_mask)
musb->dma_controller = dma_controller_create(musb, musb->mregs);
- /* ideally this would be abstracted in platform setup */
- if (!musb->dma_controller)
- dev->dma_mask = NULL;
-
/* be sure interrupts are disabled before connecting ISR */
musb_platform_disable(musb);
musb_generic_disable(musb);
@@ -1993,9 +1989,6 @@ static int musb_remove(struct platform_device *pdev)
musb_free(musb);
device_init_wakeup(dev, 0);
-#ifndef CONFIG_MUSB_PIO_ONLY
- dma_set_mask(dev, *dev->parent->dma_mask);
-#endif
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Announcing libusbx-1.0.16-rc1
Hi All, I'm very happy to announce libusbx-1.0.16-rc1, highlights: * As Nathan Hjelm already announced in his "libusb and libusbx merging" mail, Nathan has taken over libusb maintenance and this release is a combined effort between the libusb and libusbx projects! * Hotplug support for Darwin and Linux * Superspeed endpoint companion and BOS descriptor support * We finally have a libusb_strerror API You can find 1.0.16-rc1 docs including all the new API-s here: http://people.fedoraproject.org/~jwrdegoede/libusb-reference/ You can download the 1.0.16-rc1 tarbal here: http://downloads.sourceforge.net/libusbx/libusbx-1.0.16-rc1.tar.bz2 Please give it a thorough testing, and report any issues you find. For those interested the full ChangeLog is below. Regards, Hans 2013-06-20: v1.0.16-rc1 * Add hotplug support for Darwin and Linux (#9) * Add superspeed endpoint companion descriptor support (#15) * Add BOS descriptor support (#15) * Make descriptor parsing code more robust * New libusb_get_port_numbers API, this is libusb_get_port_path without the unnecessary context parameter, libusb_get_port_path is now deprecated * New libusb_strerror API (#14) * New libusb_set_auto_detach_kernel_driver API (#17) * Android: use Android logging when building on Android (#101) * Darwin: make libusb_reset reenumerate device on descriptors change (#89) * Darwin: add support for the LIBUSB_TRANSFER_ADD_ZERO_PACKET flag (#91) * Darwin: add a device cache (#112, #114) * Examples: Add sam3u_benchmark isochronous example by Harald Welte (#109) * Many other bug fixes and improvements The (#xx) numbers are libusbx issue numbers, see ie: https://github.com/libusbx/libusbx/issues/9 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 1/1] Intel xhci: refactor EHCI/xHCI port switching
Make the Linux xHCI driver automatically try to switchover the EHCI ports to
xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI host.
This means we will no longer have to add Intel xHCI hosts to a quirks list when
the PCI device IDs change. Simply continuing to add new Intel xHCI PCI device
IDs to the quirks list is not sustainable.
During suspend ports may be swicthed back to EHCI by BIOS and not properly
restored to xHCI at resume. Previously both EHCI and xHCI resume functions
switched ports back to XHCI, but it's enough to do it in xHCI only
because the hub driver doesn't start running again until after both hosts are
resumed.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/ehci-pci.c | 42 -
drivers/usb/host/pci-quirks.c | 42 +++-
drivers/usb/host/pci-quirks.h |3 +-
drivers/usb/host/xhci-pci.c | 14 +++-
4 files changed, 21 insertions(+), 80 deletions(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 595d210..6bd299e 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -315,53 +315,11 @@ done:
* Also they depend on separate root hub suspend/resume.
*/
-static bool usb_is_intel_switchable_ehci(struct pci_dev *pdev)
-{
- return pdev->class == PCI_CLASS_SERIAL_USB_EHCI &&
- pdev->vendor == PCI_VENDOR_ID_INTEL &&
- (pdev->device == 0x1E26 ||
-pdev->device == 0x8C2D ||
-pdev->device == 0x8C26 ||
-pdev->device == 0x9C26);
-}
-
-static void ehci_enable_xhci_companion(void)
-{
- struct pci_dev *companion = NULL;
-
- /* The xHCI and EHCI controllers are not on the same PCI slot */
- for_each_pci_dev(companion) {
- if (!usb_is_intel_switchable_xhci(companion))
- continue;
- usb_enable_xhci_ports(companion);
- return;
- }
-}
-
static int ehci_pci_resume(struct usb_hcd *hcd, bool hibernated)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
- /* The BIOS on systems with the Intel Panther Point chipset may or may
-* not support xHCI natively. That means that during system resume, it
-* may switch the ports back to EHCI so that users can use their
-* keyboard to select a kernel from GRUB after resume from hibernate.
-*
-* The BIOS is supposed to remember whether the OS had xHCI ports
-* enabled before resume, and switch the ports back to xHCI when the
-* BIOS/OS semaphore is written, but we all know we can't trust BIOS
-* writers.
-*
-* Unconditionally switch the ports back to xHCI after a system resume.
-* We can't tell whether the EHCI or xHCI controller will be resumed
-* first, so we have to do the port switchover in both drivers. Writing
-* a '1' to the port switchover registers should have no effect if the
-* port was already switched over.
-*/
- if (usb_is_intel_switchable_ehci(pdev))
- ehci_enable_xhci_companion();
-
if (ehci_resume(hcd, hibernated) != 0)
(void) ehci_pci_reinit(ehci, pdev);
return 0;
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index b9848e4..90f927f 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -735,32 +735,6 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
return -ETIMEDOUT;
}
-#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI0x8C31
-#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31
-
-bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
-{
- return pdev->class == PCI_CLASS_SERIAL_USB_XHCI &&
- pdev->vendor == PCI_VENDOR_ID_INTEL &&
- pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI;
-}
-
-/* The Intel Lynx Point chipset also has switchable ports. */
-bool usb_is_intel_lpt_switchable_xhci(struct pci_dev *pdev)
-{
- return pdev->class == PCI_CLASS_SERIAL_USB_XHCI &&
- pdev->vendor == PCI_VENDOR_ID_INTEL &&
- (pdev->device == PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI ||
-pdev->device == PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI);
-}
-
-bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
-{
- return usb_is_intel_ppt_switchable_xhci(pdev) ||
- usb_is_intel_lpt_switchable_xhci(pdev);
-}
-EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
-
/*
* Intel's Panther Point chipset has two host controllers (EHCI and xHCI) that
* share some number of ports. These ports can be switched between either
@@ -779,7 +753,7 @@ EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
* terminations before switching the USB 2.0 wires over, so that USB 3.0
* devices connect at SuperSp
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Thu, 20 Jun 2013, Ming Lei wrote: > >> Looks not always synchronous, control transfer is synchronous, and > >> interrupt transfer is still asynchronous. No drivers(hub, usbfs) depend > >> on that, and IMO, treating root hub same as hub will simplify HCD core, > >> and finally we can remove all the above lock releasing & acquiring if > >> all HCDs set HCD_BH. > >> > >> Also there is very less roothub transfers and always letting tasklet > >> handle URB giveback of roothub won't have performance problem, so > >> how about keeping the above tests? > > > > If you want to use the tasklets for root-hub URBs, okay. There's no > > reason to check the HCD_BH flag, though, because HCDs have only minimal > > involvement in root-hub URBs. In particular, HCD's don't call > > usb_hcd_giveback_urb() for them. > > Looks both root hub's control and interrupt transfer call > usb_hcd_giveback_urb() > to complete URBs, don't they? They do. But those calls come from within usbcore, not from within the HCD. Which means it doesn't matter whether the HCD_BH flag is set. When working with URBs sent to a root hub, it many ways it's as though usbcore acts as its own HCD. It takes care of all the locking and giving back the URBs. > > So you can use the tasklets for _all_ root-hub URBs. Then the tests > > above aren't necessary, and neither are the spinlock operations. > > Yes, that is what I am going to do. Okay. By the way, did you consider the race that Oliver pointed out? When an HCD is removed, all the outstanding URBs for all devices on its bus get cancelled. The core waits until the urb_list for each endpoint is empty. In the past this was good enough. But now it looks like we will also need to wait until the tasklet lists are empty and the tasklets aren't running before they get killed. Your __exit_giveback_urb_bh() routine doesn't seem to do that. (Probably it's sufficient to wait until the tasklet lists are empty. I assume tasklet_kill() won't stop a tasklet that's currently running.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Thu, Jun 20, 2013 at 10:59 PM, Alan Stern wrote: > > By the way, did you consider the race that Oliver pointed out? When an > HCD is removed, all the outstanding URBs for all devices on its bus get > cancelled. The core waits until the urb_list for each endpoint is > empty. This should be enough since during remove path usbcore will wait for all URBs' completion which is only triggered by tasklet, so once all URBs are finished, the tasklet list has been empty already. > > In the past this was good enough. But now it looks like we will also > need to wait until the tasklet lists are empty and the tasklets aren't > running before they get killed. Your __exit_giveback_urb_bh() routine > doesn't seem to do that. > > (Probably it's sufficient to wait until the tasklet lists are empty. I > assume tasklet_kill() won't stop a tasklet that's currently running.) >From the implementation of tasklet_kill(), it will wait for the completion of the tasklet. Actually the tasklet_kill() should not be necessary, I think. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Thu, 20 Jun 2013, Ming Lei wrote: > On Thu, Jun 20, 2013 at 10:59 PM, Alan Stern > wrote: > > > > By the way, did you consider the race that Oliver pointed out? When an > > HCD is removed, all the outstanding URBs for all devices on its bus get > > cancelled. The core waits until the urb_list for each endpoint is > > empty. > > This should be enough since during remove path usbcore will wait for all > URBs' completion which is only triggered by tasklet, so once all URBs are > finished, the tasklet list has been empty already. No, usbcore only waits until the urb_list for each endpoint is empty. It doesn't keep track of the individual URB completions. Look at usb_hcd_flush_endpoint() and you'll see. > > (Probably it's sufficient to wait until the tasklet lists are empty. I > > assume tasklet_kill() won't stop a tasklet that's currently running.) > > From the implementation of tasklet_kill(), it will wait for the completion > of the tasklet. > > Actually the tasklet_kill() should not be necessary, I think. You're probably right. But we should wait until the tasklet's list is empty; we don't want to deallocate an hcd structure until all the URBs are taken off. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 5/6] USB: OHCI: make ohci-at91 a separate driver
On Thu, 20 Jun 2013, Manjunath Goudar wrote:
> > > @@ -686,7 +631,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device
> > *pdev, pm_message_t mesg)
> > >* REVISIT: some boards will be able to turn VBUS off...
> > >*/
> > > if (at91_suspend_entering_slow_clock()) {
> > > - ohci_usb_reset (ohci);
> > > + ohci_restart(ohci);
> >
> > Why did you change this? Did we discuss it earlier?
> >
>
> We are not discussed regarding this,I think we need to call
> use ohci_resume() instead of ohci_restart().
Why? Don't you think the current code has a good reason for calling
ohci_usb_reset()?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about USB interface probe order and synchronization
On Thu, Jun 20, 2013 at 12:05:21PM -0500, Thomas Pugliese wrote: > > > On Wed, 19 Jun 2013, Greg KH wrote: > > > On Wed, Jun 19, 2013 at 03:33:51PM -0500, Thomas Pugliese wrote: > > > Hi, > > > I am attempting to debug a problem where the hwa_hc module occasionally > > > fails to start correctly when an HWA device is plugged in. An HWA device > > > consists of two USB interfaces each with its own driver: the radio > > > control > > > interface (hwa_rc.ko), and the host controller interface (hwa_hc.ko). > > > Both of these modules depend on a common subcomponent (uwb.ko) but they > > > do > > > not depend directly on each other as far as depmod is concerned. > > > > Why don't we just build them both together, as they aren't ever used > > separately, right? Would that solve your issue? > > > > thanks, > > > > greg k-h > > > > I'm not exactly sure what the implications of combining the modules are so > I don't know if that would fix it or not. > > It is true that an HWA will always have an associated radio controller > interface but the inverse is not always true. A UWB radio controller can > be paired with any number of different protocol interfaces that run on top > of UWB. I think HWA_RC is a bit of a misnomer for the radio control > module. It should really be something like uwb_usb_rc since it is > basically a USB interface to the UWB bandwidth reservation functionality. > > The best approach is probably to further decouple the HC and RC interfaces > instead of tying them closer together. They are meant to be independent > and there are only a few areas where the HC driver uses the RC handle. > That functionality could be moved to userspace since the HWA already needs > input from userspace to start the WUSB channel. Instead of the HWA_HC > querying the RC directly for its channel characteristics, userspace could > query the RC and send that info to the HC device. Doing that will > probably break the ABI though. Is that allowed? It sounds like that is much more work than needed, and yes, it would break anyone's systems that actually are using this hardware (which is probably pretty rare...) So I wouldn't recommend doing that, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Thu, 20 Jun 2013, victor yeo wrote: > The problem is in UDC driver. i made the change, it is ok now. Good. I noticed that the usb_ep_set_wedge routine still isn't working right. You might try to fix that. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] Suspend USB Host controller on bus suspend
On Thu, 20 Jun 2013, Roger Quadros wrote: > >> As the omap-ehci controller driver needs to do some additional work to put > >> itself into suspend/resume and make sure it is resumed to process an > >> interrupt, > >> we need to be able to override irq, bus_suspend, and bus_resume handlers. > >> This > >> provision is done in patch 3. > > > > Do you still need to override these things if you do the controller > > suspend at the right time? > > > > At least not for bus_suspend and bus_resume. We will still need to override > the irq > handler though. But, if we can take care of this generically in the ehci_irq > handler (i.e. make > sure controller is not suspended while accessing it) then we don't need such > override > for irq. I don't think you need to override anything. The high-level interrupt handler usb_hcd_irq() will avoid calling ehci_irq() when the HCD_HW_ACCESSIBLE flag isn't set. All you will need to do in ehci-omap.c is call synchronize_irq() after ehci_suspend() returns and before turning off the clocks. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] USB: initialize or shutdown PHY when add or remove host controller
On Thu, 20 Jun 2013, Felipe Balbi wrote: > > In fact, the PHY setting and handling is related to platform or SOC, > > and for different SOC they can > > have same EHCI HCD but they PHY handling can be different. > > Omap'a case is the example, and i think some other vendors may have > > silimar cases. > > From above point, It is better to leave the PHY initialization and > > shutdown to be done by each echi-xxx driver. > > > > So Alan and Felipe > > What are your ideas about it? > > If we have so many exceptions, then sure. But eventually, the common > case should be added generically with a flag so that non-generic cases > (like OMAP) can request to handle the PHY by themselves. > > Alan ? I don't have very strong feelings about this; Felipe has much more experience with these things. However, when the common case is added into the core, the simplest way to indicate that the HCD wants to handle the PHY(s) by itself will be to leave hcd->phy set to NULL or an ERR_PTR value. One important thing that hasn't been pointed out yet: When we move these calls into the core, the same patch must also remove those calls from the glue drivers that currently do set hcd->phy. And it must make sure that the glue drivers which handle the PHY by themselves do not set hcd->phy. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about USB interface probe order and synchronization
On Wed, 19 Jun 2013, Greg KH wrote: > On Wed, Jun 19, 2013 at 03:33:51PM -0500, Thomas Pugliese wrote: > > Hi, > > I am attempting to debug a problem where the hwa_hc module occasionally > > fails to start correctly when an HWA device is plugged in. An HWA device > > consists of two USB interfaces each with its own driver: the radio control > > interface (hwa_rc.ko), and the host controller interface (hwa_hc.ko). > > Both of these modules depend on a common subcomponent (uwb.ko) but they do > > not depend directly on each other as far as depmod is concerned. > > Why don't we just build them both together, as they aren't ever used > separately, right? Would that solve your issue? > > thanks, > > greg k-h > I'm not exactly sure what the implications of combining the modules are so I don't know if that would fix it or not. It is true that an HWA will always have an associated radio controller interface but the inverse is not always true. A UWB radio controller can be paired with any number of different protocol interfaces that run on top of UWB. I think HWA_RC is a bit of a misnomer for the radio control module. It should really be something like uwb_usb_rc since it is basically a USB interface to the UWB bandwidth reservation functionality. The best approach is probably to further decouple the HC and RC interfaces instead of tying them closer together. They are meant to be independent and there are only a few areas where the HC driver uses the RC handle. That functionality could be moved to userspace since the HWA already needs input from userspace to start the WUSB channel. Instead of the HWA_HC querying the RC directly for its channel characteristics, userspace could query the RC and send that info to the HC device. Doing that will probably break the ABI though. Is that allowed? Thanks, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] USB: ehci-omap: Suspend the controller during bus suspend
On Thu, 20 Jun 2013, Roger Quadros wrote:
> > runtime_resume(dev)
> > {
> > ...
> >
> > if (omap->flags & OMAP_EHCI_IRQ_PENDING) {
> > process_pending_irqs(omap);
>
> OK, thanks.
>
> But I'm not sure if the generic ehci_irq handler is able to
> run in a process context. Maybe if we replace spin_lock(&ehci->lock);
> with spin_lock_irqsave() there, it will work.
>
> Alan is this a doable option?
ehci_irq() will work okay in process context, provided the caller
disables interrupts.
But maybe none of this will be needed after Roger redesigns the
controller suspend to work at the right time. Or if it is, we could
adopt a simpler alternative: the controller's resume routine could
always call usb_hcd_resume_root_hub(). After all, about the only
reason for doing a runtime resume of the controller is because the root
hub needs to do something.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/1] Intel xhci: refactor EHCI/xHCI port switching
On Thu, 20 Jun 2013, Mathias Nyman wrote:
> Make the Linux xHCI driver automatically try to switchover the EHCI ports to
> xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI
> host.
>
> This means we will no longer have to add Intel xHCI hosts to a quirks list
> when
> the PCI device IDs change. Simply continuing to add new Intel xHCI PCI device
> IDs to the quirks list is not sustainable.
>
> During suspend ports may be swicthed back to EHCI by BIOS and not properly
> restored to xHCI at resume. Previously both EHCI and xHCI resume functions
> switched ports back to XHCI, but it's enough to do it in xHCI only
> because the hub driver doesn't start running again until after both hosts are
> resumed.
>
> Signed-off-by: Mathias Nyman
Looks good, and it removes a lot more code than it adds, which is
always beneficial.
> index 595d210..6bd299e 100644
> --- a/drivers/usb/host/ehci-pci.c
> +++ b/drivers/usb/host/ehci-pci.c
> @@ -315,53 +315,11 @@ done:
> * Also they depend on separate root hub suspend/resume.
> */
>
> -static bool usb_is_intel_switchable_ehci(struct pci_dev *pdev)
> @@ -921,8 +895,16 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
> writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
>
> hc_init:
> - if (usb_is_intel_switchable_xhci(pdev))
> - usb_enable_xhci_ports(pdev);
> + if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> + struct pci_dev *companion = NULL;
> + for_each_pci_dev(companion) {
> + if (companion->class == PCI_CLASS_SERIAL_USB_EHCI &&
> + companion->vendor == PCI_VENDOR_ID_INTEL) {
> + usb_enable_intel_xhci_ports(pdev);
> + break;
> + }
> + }
> + }
Maybe this loop isn't needed. Would it be okay to call
usb_enable_intel_xhci_ports() even if there are no EHCI controllers?
For that matter, what happens if there aren't any "companion" EHCI
controllers for the xHCI controller in question, but there are separate
EHCI controllers on an add-on PCI card?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about USB interface probe order and synchronization
On Thu, 20 Jun 2013, Greg KH wrote: > > I'm not exactly sure what the implications of combining the modules are so > > I don't know if that would fix it or not. > > > > It is true that an HWA will always have an associated radio controller > > interface but the inverse is not always true. A UWB radio controller can > > be paired with any number of different protocol interfaces that run on top > > of UWB. I think HWA_RC is a bit of a misnomer for the radio control > > module. It should really be something like uwb_usb_rc since it is > > basically a USB interface to the UWB bandwidth reservation functionality. > > > > The best approach is probably to further decouple the HC and RC interfaces > > instead of tying them closer together. They are meant to be independent > > and there are only a few areas where the HC driver uses the RC handle. > > That functionality could be moved to userspace since the HWA already needs > > input from userspace to start the WUSB channel. Instead of the HWA_HC > > querying the RC directly for its channel characteristics, userspace could > > query the RC and send that info to the HC device. Doing that will > > probably break the ABI though. Is that allowed? > > It sounds like that is much more work than needed, and yes, it would > break anyone's systems that actually are using this hardware (which is > probably pretty rare...) So I wouldn't recommend doing that, sorry. Would it be okay for the HWA_RC to delay querying the RC until userspace tells it to start up the WUSB channel? If the RC interface isn't available at that time, the start-up could simply fail. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about USB interface probe order and synchronization
On Thu, 20 Jun 2013, Alan Stern wrote: > On Thu, 20 Jun 2013, Greg KH wrote: > > > > I'm not exactly sure what the implications of combining the modules are > > > so > > > I don't know if that would fix it or not. > > > > > > It is true that an HWA will always have an associated radio controller > > > interface but the inverse is not always true. A UWB radio controller can > > > be paired with any number of different protocol interfaces that run on > > > top > > > of UWB. I think HWA_RC is a bit of a misnomer for the radio control > > > module. It should really be something like uwb_usb_rc since it is > > > basically a USB interface to the UWB bandwidth reservation functionality. > > > > > > The best approach is probably to further decouple the HC and RC > > > interfaces > > > instead of tying them closer together. They are meant to be independent > > > and there are only a few areas where the HC driver uses the RC handle. > > > That functionality could be moved to userspace since the HWA already > > > needs > > > input from userspace to start the WUSB channel. Instead of the HWA_HC > > > querying the RC directly for its channel characteristics, userspace could > > > query the RC and send that info to the HC device. Doing that will > > > probably break the ABI though. Is that allowed? > > > > It sounds like that is much more work than needed, and yes, it would > > break anyone's systems that actually are using this hardware (which is > > probably pretty rare...) So I wouldn't recommend doing that, sorry. > > Would it be okay for the HWA_RC to delay querying the RC until > userspace tells it to start up the WUSB channel? If the RC interface > isn't available at that time, the start-up could simply fail. > > Alan Stern > > I think that should work. It seems like the best option available. I'll take a crack at it. Thanks, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] option: remove Novatel/Verizon USB-1000 (handled by qc_serial/qmi_wwan)
The USB-1000 is a Gobi1K device in USB dongle form, requires firmware
download via gobi_loader, and has the Gobi1K descriptor layout. It
also supports QMI like any other Gobi1K device, but option grabs
all the USB interfaces and prevents qmi_wwan and qc_serial from
handling the device.
Signed-off-by: Dan Williams
---
drivers/usb/serial/option.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 7343728..7df7c67 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -159,7 +159,6 @@ static void option_instat_callback(struct urb *urb);
#define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_FULLSPEED0x9000
#define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED0x9001
#define NOVATELWIRELESS_PRODUCT_E362 0x9010
-#define NOVATELWIRELESS_PRODUCT_G1 0xA001
#define NOVATELWIRELESS_PRODUCT_G1_M 0xA002
#define NOVATELWIRELESS_PRODUCT_G2 0xA010
#define NOVATELWIRELESS_PRODUCT_MC551 0xB001
@@ -741,7 +740,6 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC547)
},
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
NOVATELWIRELESS_PRODUCT_EVDO_EMBEDDED_HIGHSPEED) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED) },
- { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1_M) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },
/* Novatel Ovation MC551 a.k.a. Verizon USB551L */
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 00/11] USB: OHCI:Properly handle ohci_suspend()routine in bus glue
On Thu, 20 Jun 2013, Manjunath Goudar wrote: > Suspend scenario in case of ohci bus glue was not properly handled as > it was not suspending generic part of ohci controller. Calling > explicitly the ohci_suspend()routine will ensure proper handling > of suspend scenario. > > V2: > -Incase ohci_suspend() fails, return right away without executing further. > > V3: > -New patch 1/11 added, for generic ohci-hcd suspend code. > > V4: > -Properly aligned "do_wakeup" and "ret" variables. This whole series looks good now. For all of the patches: Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] option: remove Novatel/Verizon USB-1000 (handled by qc_serial/qmi_wwan)
On Thu, 2013-06-20 at 13:27 -0500, Dan Williams wrote:
> The USB-1000 is a Gobi1K device in USB dongle form, requires firmware
> download via gobi_loader, and has the Gobi1K descriptor layout. It
> also supports QMI like any other Gobi1K device, but option grabs
> all the USB interfaces and prevents qmi_wwan and qc_serial from
> handling the device.
>
> Signed-off-by: Dan Williams
Ignore this patch please; there are a number of other Novatel devices
that should get removed (having looked at the USB1000 Windows .INF
files), I'll send an updated patch.
Dan
> ---
> drivers/usb/serial/option.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 7343728..7df7c67 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -159,7 +159,6 @@ static void option_instat_callback(struct urb *urb);
> #define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_FULLSPEED 0x9000
> #define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED 0x9001
> #define NOVATELWIRELESS_PRODUCT_E362 0x9010
> -#define NOVATELWIRELESS_PRODUCT_G1 0xA001
> #define NOVATELWIRELESS_PRODUCT_G1_M 0xA002
> #define NOVATELWIRELESS_PRODUCT_G2 0xA010
> #define NOVATELWIRELESS_PRODUCT_MC5510xB001
> @@ -741,7 +740,6 @@ static const struct usb_device_id option_ids[] = {
> { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC547)
> },
> { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
> NOVATELWIRELESS_PRODUCT_EVDO_EMBEDDED_HIGHSPEED) },
> { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
> NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED) },
> - { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1) },
> { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1_M) },
> { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },
> /* Novatel Ovation MC551 a.k.a. Verizon USB551L */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] option: remove Novatel/Verizon USB-1000 (handled by qc_serial/qmi_wwan)
On Thu, Jun 20, 2013 at 03:16:42PM -0500, Dan Williams wrote: > On Thu, 2013-06-20 at 13:27 -0500, Dan Williams wrote: > > The USB-1000 is a Gobi1K device in USB dongle form, requires firmware > > download via gobi_loader, and has the Gobi1K descriptor layout. It > > also supports QMI like any other Gobi1K device, but option grabs > > all the USB interfaces and prevents qmi_wwan and qc_serial from > > handling the device. > > > > Signed-off-by: Dan Williams > > Ignore this patch please; there are a number of other Novatel devices > that should get removed (having looked at the USB1000 Windows .INF > files), I'll send an updated patch. Ok, now dropped. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] option,qcserial: move Novatel Gobi1K IDs to qcserial
These devices are all Gobi1K devices (according to the Windows INF
files) and should be handled by qcserial instead of option. Their
network port is handled by qmi_wwan.
Signed-off-by: Dan Williams
---
drivers/usb/serial/option.c | 4
drivers/usb/serial/qcserial.c | 8 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 7343728..941685a 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -159,8 +159,6 @@ static void option_instat_callback(struct urb *urb);
#define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_FULLSPEED0x9000
#define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED0x9001
#define NOVATELWIRELESS_PRODUCT_E362 0x9010
-#define NOVATELWIRELESS_PRODUCT_G1 0xA001
-#define NOVATELWIRELESS_PRODUCT_G1_M 0xA002
#define NOVATELWIRELESS_PRODUCT_G2 0xA010
#define NOVATELWIRELESS_PRODUCT_MC551 0xB001
@@ -741,8 +739,6 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC547)
},
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
NOVATELWIRELESS_PRODUCT_EVDO_EMBEDDED_HIGHSPEED) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED) },
- { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1) },
- { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G1_M) },
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },
/* Novatel Ovation MC551 a.k.a. Verizon USB551L */
{ USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID,
NOVATELWIRELESS_PRODUCT_MC551, 0xff, 0xff, 0xff) },
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 59b32b7..efd7aa9 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -35,7 +35,13 @@ static const struct usb_device_id id_table[] = {
{DEVICE_G1K(0x04da, 0x250c)}, /* Panasonic Gobi QDL device */
{DEVICE_G1K(0x413c, 0x8172)}, /* Dell Gobi Modem device */
{DEVICE_G1K(0x413c, 0x8171)}, /* Dell Gobi QDL device */
- {DEVICE_G1K(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
+ {DEVICE_G1K(0x1410, 0xa001)}, /* Novatel/Verizon USB-1000 */
+ {DEVICE_G1K(0x1410, 0xa002)}, /* Novatel Gobi Modem device */
+ {DEVICE_G1K(0x1410, 0xa003)}, /* Novatel Gobi Modem device */
+ {DEVICE_G1K(0x1410, 0xa004)}, /* Novatel Gobi Modem device */
+ {DEVICE_G1K(0x1410, 0xa005)}, /* Novatel Gobi Modem device */
+ {DEVICE_G1K(0x1410, 0xa006)}, /* Novatel Gobi Modem device */
+ {DEVICE_G1K(0x1410, 0xa007)}, /* Novatel Gobi Modem device */
{DEVICE_G1K(0x1410, 0xa008)}, /* Novatel Gobi QDL device */
{DEVICE_G1K(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
{DEVICE_G1K(0x0b05, 0x1774)}, /* Asus Gobi QDL device */
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] USB: initialize or shutdown PHY when add or remove host controller
On Fri, Jun 21, 2013 at 1:25 AM, Alan Stern wrote: > On Thu, 20 Jun 2013, Felipe Balbi wrote: > >> > In fact, the PHY setting and handling is related to platform or SOC, >> > and for different SOC they can >> > have same EHCI HCD but they PHY handling can be different. >> > Omap'a case is the example, and i think some other vendors may have >> > silimar cases. >> > From above point, It is better to leave the PHY initialization and >> > shutdown to be done by each echi-xxx driver. >> > >> > So Alan and Felipe >> > What are your ideas about it? >> >> If we have so many exceptions, then sure. But eventually, the common >> case should be added generically with a flag so that non-generic cases >> (like OMAP) can request to handle the PHY by themselves. >> >> Alan ? > > I don't have very strong feelings about this; Felipe has much more > experience with these things. > > However, when the common case is added into the core, the simplest way > to indicate that the HCD wants to handle the PHY(s) by itself will be > to leave hcd->phy set to NULL or an ERR_PTR value. > > One important thing that hasn't been pointed out yet: When we move > these calls into the core, the same patch must also remove those calls > from the glue drivers that currently do set hcd->phy. And it must make > sure that the glue drivers which handle the PHY by themselves do not > set hcd->phy. > >From device point of view, EHCI is a standlone component. It has the standard sepcification, so each SOC vendor has EHCI HCD need to follow the standards. Then we have common EHCI HCD driver. The PHY is outside of EHCI component, each SOC vendor may have different PHY implementation. Then we have PHY driver. The EHCI glue driver ehci-xxx works like a SOC depended driver. It is its duty to handle the' relationship between the EHCI HCD driver and PHY driver. It is same as clk, irq requested by ehci-xxx driver. So i think add a flag and use usb_get_phy() is not very good. It is bette to make ehci-xxx to do the phy getting and EHCI HCD initialize it and shut down as the patch did, or let ehci-xxx to handle the PHY as Roger said. Based on the generic work is not too much, and does not look so meaningful. I suggest that let to echi-xxx do it. > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Fri, Jun 21, 2013 at 12:52 AM, Alan Stern wrote: > On Thu, 20 Jun 2013, Ming Lei wrote: > >> On Thu, Jun 20, 2013 at 10:59 PM, Alan Stern >> wrote: >> > >> > By the way, did you consider the race that Oliver pointed out? When an >> > HCD is removed, all the outstanding URBs for all devices on its bus get >> > cancelled. The core waits until the urb_list for each endpoint is >> > empty. >> >> This should be enough since during remove path usbcore will wait for all >> URBs' completion which is only triggered by tasklet, so once all URBs are >> finished, the tasklet list has been empty already. > > No, usbcore only waits until the urb_list for each endpoint is empty. > It doesn't keep track of the individual URB completions. Look at > usb_hcd_flush_endpoint() and you'll see. But, if URBs still aren't completed after usb_disconnect(), it should be bug of usbcore or driver, shouldn't it? > >> > (Probably it's sufficient to wait until the tasklet lists are empty. I >> > assume tasklet_kill() won't stop a tasklet that's currently running.) >> >> From the implementation of tasklet_kill(), it will wait for the completion >> of the tasklet. >> >> Actually the tasklet_kill() should not be necessary, I think. > > You're probably right. But we should wait until the tasklet's list is > empty; we don't want to deallocate an hcd structure until all the URBs > are taken off. I will keep the tasklet_kill() for safe reason. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] USB: initialize or shutdown PHY when add or remove host controller
correct for irq. irq number is get by gludriver, while irq is requested by EHCO HCD. On Fri, Jun 21, 2013 at 9:07 AM, Chao Xie wrote: > On Fri, Jun 21, 2013 at 1:25 AM, Alan Stern wrote: >> On Thu, 20 Jun 2013, Felipe Balbi wrote: >> >>> > In fact, the PHY setting and handling is related to platform or SOC, >>> > and for different SOC they can >>> > have same EHCI HCD but they PHY handling can be different. >>> > Omap'a case is the example, and i think some other vendors may have >>> > silimar cases. >>> > From above point, It is better to leave the PHY initialization and >>> > shutdown to be done by each echi-xxx driver. >>> > >>> > So Alan and Felipe >>> > What are your ideas about it? >>> >>> If we have so many exceptions, then sure. But eventually, the common >>> case should be added generically with a flag so that non-generic cases >>> (like OMAP) can request to handle the PHY by themselves. >>> >>> Alan ? >> >> I don't have very strong feelings about this; Felipe has much more >> experience with these things. >> >> However, when the common case is added into the core, the simplest way >> to indicate that the HCD wants to handle the PHY(s) by itself will be >> to leave hcd->phy set to NULL or an ERR_PTR value. >> >> One important thing that hasn't been pointed out yet: When we move >> these calls into the core, the same patch must also remove those calls >> from the glue drivers that currently do set hcd->phy. And it must make >> sure that the glue drivers which handle the PHY by themselves do not >> set hcd->phy. >> > > From device point of view, EHCI is a standlone component. It has the > standard sepcification, so each > SOC vendor has EHCI HCD need to follow the standards. Then we have > common EHCI HCD driver. > The PHY is outside of EHCI component, each SOC vendor may have > different PHY implementation. Then > we have PHY driver. > The EHCI glue driver ehci-xxx works like a SOC depended driver. It is > its duty to handle the' > relationship between the EHCI HCD driver and PHY driver. > It is same as clk, irq requested by ehci-xxx driver. > > So i think add a flag and use usb_get_phy() is not very good. > It is bette to make ehci-xxx to do the phy getting and EHCI HCD > initialize it and shut down as the patch did, or let ehci-xxx to > handle the PHY as Roger said. > > Based on the generic work is not too much, and does not look so > meaningful. I suggest that let to echi-xxx > do it. > >> Alan Stern >> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Fri, Jun 21, 2013 at 9:12 AM, Ming Lei wrote: > On Fri, Jun 21, 2013 at 12:52 AM, Alan Stern > wrote: >> On Thu, 20 Jun 2013, Ming Lei wrote: >> >>> On Thu, Jun 20, 2013 at 10:59 PM, Alan Stern >>> wrote: >>> > >>> > By the way, did you consider the race that Oliver pointed out? When an >>> > HCD is removed, all the outstanding URBs for all devices on its bus get >>> > cancelled. The core waits until the urb_list for each endpoint is >>> > empty. >>> >>> This should be enough since during remove path usbcore will wait for all >>> URBs' completion which is only triggered by tasklet, so once all URBs are >>> finished, the tasklet list has been empty already. >> >> No, usbcore only waits until the urb_list for each endpoint is empty. >> It doesn't keep track of the individual URB completions. Look at >> usb_hcd_flush_endpoint() and you'll see. > > But, if URBs still aren't completed after usb_disconnect(), it should be > bug of usbcore or driver, shouldn't it? Thought about the problem further, there should be one problem: - we can't let URBs survive from deleting the interface, otherwise the module in which the completion handler lives might have been removed - so tasklet_kill() should be added into usb_hcd_synchronize_unlinks() to make sure the above point, although it is a bit tricky since tasklet_kill() flushes global list, but it does work. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v1 1/6] USB: HCD: support giveback of URB in tasklet context
On Fri, Jun 21, 2013 at 12:46 PM, Ming Lei wrote: > On Fri, Jun 21, 2013 at 9:12 AM, Ming Lei wrote: >> On Fri, Jun 21, 2013 at 12:52 AM, Alan Stern >> wrote: >>> On Thu, 20 Jun 2013, Ming Lei wrote: >>> On Thu, Jun 20, 2013 at 10:59 PM, Alan Stern wrote: > > By the way, did you consider the race that Oliver pointed out? When an > HCD is removed, all the outstanding URBs for all devices on its bus get > cancelled. The core waits until the urb_list for each endpoint is > empty. This should be enough since during remove path usbcore will wait for all URBs' completion which is only triggered by tasklet, so once all URBs are finished, the tasklet list has been empty already. >>> >>> No, usbcore only waits until the urb_list for each endpoint is empty. >>> It doesn't keep track of the individual URB completions. Look at >>> usb_hcd_flush_endpoint() and you'll see. >> >> But, if URBs still aren't completed after usb_disconnect(), it should be >> bug of usbcore or driver, shouldn't it? > > Thought about the problem further, there should be one problem: > > - we can't let URBs survive from deleting the interface, otherwise > the module in which the completion handler lives might have been > removed > > - so tasklet_kill() should be added into usb_hcd_synchronize_unlinks() > to make sure the above point, although it is a bit tricky since tasklet_kill() > flushes global list, but it does work. Maybe usb_suspend_both() need to call usb_hcd_synchronize_unlinks(dev), both the two cases(disconnect, suspend) suppose drivers don't kill their URBs in remove() and suspend(). Even we can implement one function which only flushes URBs for one device to optimize the cases. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: fotg210-udc: Use module_platform_driver_probe macro
Hi, On Thu, Jun 20, 2013 at 8:16 PM, Felipe Balbi wrote: > > Hi, > > On Thu, Jun 20, 2013 at 01:53:13PM +, Yuan-Hsin Chen wrote: > > Because fotg210-udc is configured as a non-hotpluggable device, > > that makes sense to use module_platform_driver_probe() instead of > > module_platform_driver(). This also fixes the section mismatch issue. > > > > Signed-off-by: Yuan-Hsin Chen > > I would rather see you remove __init annotation from your probe() > function. The reason being that it will users to bind/unbind the driver > through sysfs, which is pretty good for testing, at least. I see and will send a patch later. Thanks. Yuan-Hsin > > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
