Re: [V7 PATCH 02/16] usb: gadget: mv_udc: use PHY driver for udc
Hi,
On Monday 18 February 2013 11:40 AM, Chao Xie wrote:
Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of enabling device tree for udc driver.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/gadget/mv_udc.h |2 +-
drivers/usb/gadget/mv_udc_core.c | 37 +++--
2 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index 9073436..f339df4 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -180,7 +180,6 @@ struct mv_udc {
struct mv_cap_regs __iomem *cap_regs;
struct mv_op_regs __iomem *op_regs;
- void __iomem*phy_regs;
unsigned intmax_eps;
struct mv_dqh *ep_dqh;
size_t ep_dqh_size;
@@ -217,6 +216,7 @@ struct mv_udc {
struct work_struct vbus_work;
struct workqueue_struct *qwork;
+ struct usb_phy *phy;
struct usb_phy *transceiver;
struct mv_usb_platform_data *pdata;
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c8cf959..d3ce1aa 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -35,6 +35,7 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/platform_data/mv_usb.h
+#include linux/usb/mv_usb2.h
#include asm/unaligned.h
#include mv_udc.h
@@ -1121,15 +1122,14 @@ static int mv_udc_enable_internal(struct mv_udc *udc)
dev_dbg(udc-dev-dev, enable udc\n);
udc_clock_enable(udc);
- if (udc-pdata-phy_init) {
- retval = udc-pdata-phy_init(udc-phy_regs);
- if (retval) {
- dev_err(udc-dev-dev,
- init phy error %d\n, retval);
- udc_clock_disable(udc);
- return retval;
- }
+ retval = usb_phy_init(udc-phy);
+ if (retval) {
+ dev_err(udc-dev-dev,
+ init phy error %d\n, retval);
+ udc_clock_disable(udc);
+ return retval;
}
+
udc-active = 1;
return 0;
@@ -1147,8 +1147,7 @@ static void mv_udc_disable_internal(struct mv_udc *udc)
{
if (udc-active) {
dev_dbg(udc-dev-dev, disable udc\n);
- if (udc-pdata-phy_deinit)
- udc-pdata-phy_deinit(udc-phy_regs);
+ usb_phy_shutdown(udc-phy);
udc_clock_disable(udc);
udc-active = 0;
}
@@ -2175,8 +2174,8 @@ static int mv_udc_probe(struct platform_device *pdev)
#ifdef CONFIG_USB_OTG_UTILS
if (pdata-mode == MV_USB_MODE_OTG) {
- udc-transceiver = devm_usb_get_phy(pdev-dev,
- USB_PHY_TYPE_USB2);
+ udc-transceiver = devm_usb_get_phy_dev(pdev-dev,
+ MV_USB2_OTG_PHY_INDEX);
if (IS_ERR_OR_NULL(udc-transceiver)) {
udc-transceiver = NULL;
return -ENODEV;
@@ -2194,7 +2193,7 @@ static int mv_udc_probe(struct platform_device *pdev)
}
}
- r = platform_get_resource_byname(udc-dev, IORESOURCE_MEM, capregs);
+ r = platform_get_resource(udc-dev, IORESOURCE_MEM, 0);
if (r == NULL) {
dev_err(pdev-dev, no I/O memory resource defined\n);
return -ENODEV;
@@ -2207,18 +2206,12 @@ static int mv_udc_probe(struct platform_device *pdev)
return -EBUSY;
}
- r = platform_get_resource_byname(udc-dev, IORESOURCE_MEM, phyregs);
- if (r == NULL) {
- dev_err(pdev-dev, no phy I/O memory resource defined\n);
+ udc-phy = devm_usb_get_phy_dev(pdev-dev, MV_USB2_PHY_INDEX);
+ if (IS_ERR_OR_NULL(udc-phy)) {
+ udc-phy = NULL;
Ideally you shouldn't do this. Consider the case where
devm_usb_get_phy_dev returns -EPROBE_DEFER. In that case you should
return -EPROBE_DEFER from probe instead of manually writing the return
value to -ENODEV.
This comment is applicable for the remaining patches that uses
devm_usb_get_phy_dev.
Thanks
Kishon
--
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: [V2 2/8] USB: EHCI: make ehci-atmel a separate driver
On 02/15/2013 06:24 PM, Manjunath Goudar wrote:
Separate the Atmel host controller driver from ehci-hcd host code
into its own driver module.
In V2:
Resolved below compiler error.
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function
'ehci_shutdown'
Signed-off-by: Manjunath Goudarmanjunath.gou...@linaro.org
Cc: Alan Sternst...@rowland.harvard.edu
Cc: Greg KHg...@kroah.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
Cc: Andrew Victorli...@maxim.org.za
Cc: Nicolas Ferrenicolas.fe...@atmel.com
Cc: Jean-Christophe Plagniol-Villardplagn...@jcrosoft.com
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
drivers/usb/host/Kconfig |8 +
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-atmel.c | 76 ++---
drivers/usb/host/ehci-hcd.c | 10 ++
drivers/usb/host/ehci.h |2 +-
5 files changed, 53 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 15e8032..1ef37d7 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -170,6 +170,14 @@ config USB_EHCI_HCD_SPEAR
Enables support for the on-chip EHCI controller on
ST SPEAr chips.
+config USB_EHCI_HCD_AT91
+tristate Support for Atmel on-chip EHCI USB controller
+depends on USB_EHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index c8fcde9..b301243 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_USB_EHCI_HCD_PLATFORM) += ehci-platform.o
obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o
obj-$(CONFIG_USB_OXU210HP_HCD)+= oxu210hp-hcd.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 27639487..3cd0dd4 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -15,6 +15,19 @@
#includelinux/platform_device.h
#includelinux/of.h
#includelinux/of_platform.h
+#includelinux/kernel.h
+#includelinux/module.h
+#includelinux/usb.h
+#includelinux/usb/hcd.h
+#includelinux/io.h
+#includelinux/dma-mapping.h
+
+#include ehci.h
+
+#define DRIVER_DESC EHCI atmel driver
+
+static const char hcd_name[] = ehci-atmel;
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
static struct clk *iclk, *fclk;
@@ -60,41 +73,6 @@ static int ehci_atmel_setup(struct usb_hcd *hcd)
return ehci_setup(hcd);
}
-static const struct hc_driver ehci_atmel_hc_driver = {
- .description= hcd_name,
- .product_desc = Atmel EHCI UHP HS,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /* generic hardware linkage */
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /* basic lifecycle operations */
- .reset = ehci_atmel_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /* managing i/o requests and associated device resources */
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
-
- /* scheduling support */
- .get_frame_number = ehci_get_frame,
-
- /* root hub support */
- .hub_status_data= ehci_hub_status_data,
- .hub_control= ehci_hub_control,
- .bus_suspend= ehci_bus_suspend,
- .bus_resume = ehci_bus_resume,
- .relinquish_port= ehci_relinquish_port,
- .port_handed_over = ehci_port_handed_over,
-
- .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
-
static u64 at91_ehci_dma_mask = DMA_BIT_MASK(32);
static int ehci_atmel_drv_probe(struct platform_device *pdev)
@@ -210,7 +188,33 @@ static struct platform_driver ehci_atmel_driver = {
.remove = ehci_atmel_drv_remove,
.shutdown = usb_hcd_platform_shutdown,
.driver = {
- .name = atmel-ehci,
+ .name = hcd_name,
This change will cause atmel ehci won't work with the none device tree
kernel.
it can be fixed with replace
[PATCH] pci: do not try to assign irq 255
The PCI config space reseves a byte for the interrupt line, so irq 255 actually refers to 'not set'. However, the 'irq' field for struct pci_dev is an integer, so the original meaning is lost, causing the system to assign an interrupt '255', which fails. So we should _not_ assign an interrupt value here, and allow upper layers to fixup things. This patch make PCI devices with MSI interrupts only (like the xhci device on certain HP laptops) work properly. Cc: Frederik Himpe fhi...@vub.ac.be Cc: Oliver Neukum oneu...@suse.de Cc: David Haerdeman da...@hardeman.nu Cc: linux-usb@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Hannes Reinecke h...@suse.de diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 6186f03..a2db887f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -923,7 +923,8 @@ static void pci_read_irq(struct pci_dev *dev) dev-pin = irq; if (irq) pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq); - dev-irq = irq; + if (irq 255) + dev-irq = irq; } void set_pcie_port_type(struct pci_dev *pdev) -- 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: [V2 2/8] USB: EHCI: make ehci-atmel a separate driver
On Monday 18 February 2013, Bo Shen wrote: - .name = atmel-ehci, + .name = hcd_name, This change will cause atmel ehci won't work with the none device tree kernel. it can be fixed with replace other places using atmel-ehci with hcd_name, that means replace atmel-ehci with ehci-atmel at other places. Ah, that is right. Thanks for pointing it out! Manjunath, please revert this change and ensure you are not changing the contents of the 'platform_driver-name' field in any of the drivers. Arnd -- 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: Fwd: PROBLEM: Permanent kernel panic in USB hub driver - 3.5.0-22
Hi, However, I think the root cause is the same as in previous cores, so it is still would be worth to analyze them. Here is a new picture of the panic: https://dl.dropbox.com/u/8276110/3.7.4%20panic.jpg Do you have the UAS driver compiled in? I see some functions that could only be called after the UAS driver allocates a streams context (i.e. xhci_stream_id_to_ring). It doesn't seem to be related to the Set Address timeout crash that was your previous issue. The crash could be a uas driver bug, please pick up fixes from http://www.kraxel.org/cgit/linux/log/?h=uas (greg's usb-next tree will do too). That will not make the uas driver work due to the radix tree bug, but the uas driver's error handling should be solid enougth that xhci driver bugs don't make uas crash the box. cheers, Gerd -- 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] usb/core: add current frame_number sysfs attr to hcd
On Mon, Feb 18, 2013 at 03:34:07PM +0100, Stefan Tauner wrote: This allows user space to retrieve the current frame number on a USB as returned by usb_get_current_frame_number(...) via sysfs. Signed-off-by: Stefan Tauner stefan.tau...@student.tuwien.ac.at --- That's sadly not necessarily the raw value seen on the bus because the individual driver functions called by usb_get_current_frame_number(...) seem to limit the possible range to the schedule horizon of isochronous packets. IMHO the function name is a misnomer and I would like to hear your opinion on this, a possible new name for it and a better way to retrieve the real/raw value. The rationale for this patch can be found in the thread with the subject Correlating SOF with host system time from last december (201212042020.qb4kkt0n008...@mail2.student.tuwien.ac.at). My whole use case/idea was kinda frowned upon then, but there was little discussion about how it should/could be implemented in the kernel code in case one really wants to try it. For those of us with bad memories, care to expand on why you want this in the changelog body of the patch so that the world will remember it as well? Adding the sysfs attribute was the easiest way for me to communicate this to user space, but at least for my use case a non-polling approach would have been better. Any suggestions on how this could be done by a newbie like me are very welcome. Whenever you add/modify/remove a sysfs attribute, you also need to document it in Documentation/ABI/. Care to do that and resend this patch? thanks, 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 v3] xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP controller,
but it introduced a bug where resume from hibernate would add the
comp_mode_recovery_timer to the timer queue while it was already
active when saved to disk on hibernate. This caused list_add corruption
leading to a crash when resuming from hibernate.
The original patch erroneously assumed that the timer would be deleted
by a call to xhci_suspend() or xhci_stop(), but neither of these calls
is made during the hibernate sequence. When returning from hibernate,
the timer was still active, and the attempt to list_add the same timer
corrupted the list.
We can avoid this problem when resuming from hibernate by first deleting
the timer and then initializing it and adding it to the timer list.
Removed extraneous parenthesis from conditional statements of the
original commit.
Signed-off-by: Tony Camuso tcam...@redhat.com
Acked-by: Don Zickus dzic...@redhat.com
---
drivers/usb/host/xhci.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f1f01a8..267a7b1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -732,7 +732,7 @@ void xhci_stop(struct usb_hcd *hcd)
/* Deleting Compliance Mode Recovery Timer */
if ((xhci-quirks XHCI_COMP_MODE_QUIRK)
- (!(xhci_all_ports_seen_u0(xhci
+ !(xhci_all_ports_seen_u0(xhci)))
del_timer_sync(xhci-comp_mode_recovery_timer);
if (xhci-quirks XHCI_AMD_PLL_FIX)
@@ -927,7 +927,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
* is about to be suspended.
*/
if ((xhci-quirks XHCI_COMP_MODE_QUIRK)
- (!(xhci_all_ports_seen_u0(xhci {
+ !(xhci_all_ports_seen_u0(xhci))) {
del_timer_sync(xhci-comp_mode_recovery_timer);
xhci_dbg(xhci, Compliance Mode Recovery Timer Deleted!\n);
}
@@ -988,6 +988,13 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
/* If restore operation fails, re-initialize the HC during resume */
if ((temp STS_SRE) || hibernated) {
+
+ if ((xhci-quirks XHCI_COMP_MODE_QUIRK)
+ !(xhci_all_ports_seen_u0(xhci))) {
+ del_timer_sync(xhci-comp_mode_recovery_timer);
+ xhci_dbg(xhci, Compliance Mode Recovery Timer
deleted!\n);
+ }
+
/* Let the USB core know _both_ roothubs lost power. */
usb_root_hub_lost_power(xhci-main_hcd-self.root_hub);
usb_root_hub_lost_power(xhci-shared_hcd-self.root_hub);
@@ -1071,7 +1078,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
* to suffer the Compliance Mode issue again. It doesn't matter if
* ports have entered previously to U0 before system's suspension.
*/
- if (xhci-quirks XHCI_COMP_MODE_QUIRK)
+ if ((xhci-quirks XHCI_COMP_MODE_QUIRK) !hibernated)
compliance_mode_recovery_timer_init(xhci);
/* Re-enable port polling. */
--
1.7.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
Re: [PATCH v3] xhci - correct comp_mode_recovery_timer on return from hibernate
The difference between v2 and v3 of this patch was mostly cosmetic.
(!(xhci_all_ports_seen_u0(xhci))
... was changed to...
!(xhci_all_ports_seen_u0(xhci))
And ...
Compliance Mode Recovery Timer Deleted!\n
... was changed to ...
Compliance Mode Recovery Timer deleted!\n
On 02/18/2013 12:52 PM, Tony Camuso wrote:
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP controller,
but it introduced a bug where resume from hibernate would add the
comp_mode_recovery_timer to the timer queue while it was already
active when saved to disk on hibernate. This caused list_add corruption
leading to a crash when resuming from hibernate.
The original patch erroneously assumed that the timer would be deleted
by a call to xhci_suspend() or xhci_stop(), but neither of these calls
is made during the hibernate sequence. When returning from hibernate,
the timer was still active, and the attempt to list_add the same timer
corrupted the list.
We can avoid this problem when resuming from hibernate by first deleting
the timer and then initializing it and adding it to the timer list.
Removed extraneous parenthesis from conditional statements of the
original commit.
Signed-off-by: Tony Camuso tcam...@redhat.com
Acked-by: Don Zickus dzic...@redhat.com
---
drivers/usb/host/xhci.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f1f01a8..267a7b1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -732,7 +732,7 @@ void xhci_stop(struct usb_hcd *hcd)
/* Deleting Compliance Mode Recovery Timer */
if ((xhci-quirks XHCI_COMP_MODE_QUIRK)
- (!(xhci_all_ports_seen_u0(xhci
+ !(xhci_all_ports_seen_u0(xhci)))
del_timer_sync(xhci-comp_mode_recovery_timer);
if (xhci-quirks XHCI_AMD_PLL_FIX)
@@ -927,7 +927,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
* is about to be suspended.
*/
if ((xhci-quirks XHCI_COMP_MODE_QUIRK)
- (!(xhci_all_ports_seen_u0(xhci {
+ !(xhci_all_ports_seen_u0(xhci))) {
del_timer_sync(xhci-comp_mode_recovery_timer);
xhci_dbg(xhci, Compliance Mode Recovery Timer Deleted!\n);
}
@@ -988,6 +988,13 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
/* If restore operation fails, re-initialize the HC during resume */
if ((temp STS_SRE) || hibernated) {
+
+ if ((xhci-quirks XHCI_COMP_MODE_QUIRK)
+ !(xhci_all_ports_seen_u0(xhci))) {
+ del_timer_sync(xhci-comp_mode_recovery_timer);
+ xhci_dbg(xhci, Compliance Mode Recovery Timer
deleted!\n);
+ }
+
/* Let the USB core know _both_ roothubs lost power. */
usb_root_hub_lost_power(xhci-main_hcd-self.root_hub);
usb_root_hub_lost_power(xhci-shared_hcd-self.root_hub);
@@ -1071,7 +1078,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
* to suffer the Compliance Mode issue again. It doesn't matter if
* ports have entered previously to U0 before system's suspension.
*/
- if (xhci-quirks XHCI_COMP_MODE_QUIRK)
+ if ((xhci-quirks XHCI_COMP_MODE_QUIRK) !hibernated)
compliance_mode_recovery_timer_init(xhci);
/* Re-enable port polling. */
--
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 0/3] Introduce driver for IMS PCU devices
IMS, an In Flight Entertainment System provider, has a number of seat displays Linux. To interact with the user IMS uses a passenger Control Unit (PCU), which communicates with Rave Display Unit via a USB interface. Originally large part of the PCU handling was done from userspace and so it presents itself as two distinct USB devices: one is a standard HID mouse and another is a CDC-ACM modem-like device. The latter one was used by IMS userspace software to get the status of all PCU buttons and perform other operations. However the fact that with the custom userspace handling the device resides outside of the standard input framework hinders use of the device elsewhere in the stack and this patch series attempts to fix this issue by creating a proper input driver for the device. If the device was purely input device it would also be possible to use cdc-acm + userspace solution and loop the input events back into the kernel via uinput, however the device also allows control its key backlight, which exported as a standard LED device, and this functionality is not available through uinput (nor should it be). Firmware update is also implemented via the standard request_firmware mechanism. The patch series consists of 3 parts: - a patch adding new keycodes needed for PCU; - the driver itself; - a patch to cdc-acm driver to ignore PCU devices when ims-pcu driver is enabled. Thanks. -- Dmitry -- 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 2/3] Input: add IMS Passenger Control Unit driver
The PCU is a device installed in the armrest of a plane seat and
is connected to IMS Rave Entertainment System. It has a set of control
buttons (Volume Up/Down, Attendant, Lights, etc) on one side and
gamepad-like controls on the other side.
Originally the device was handled from userspace and because of that
it presents itself on USB bus as a CDC-ACM modem device that however
can not make calls. However the custom handling is not as convenient
as using standard input subsystem facilities. If it was pure input
device it would be possible to continue using userspace solution
(moving it over to uinput), but the device also has backlighted keys
which can not be supported via uinput.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/input/misc/Kconfig | 10 +
drivers/input/misc/Makefile |1 +
drivers/input/misc/ims-pcu.c | 1907 ++
3 files changed, 1918 insertions(+)
create mode 100644 drivers/input/misc/ims-pcu.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 798ba29..9d32716 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -606,6 +606,16 @@ config INPUT_ADXL34X_SPI
To compile this driver as a module, choose M here: the
module will be called adxl34x-spi.
+config INPUT_IMS_PCU
+ tristate IMS Passenger Control Unit driver
+ depends on USB
+ depends on LEDS_CLASS
+ help
+ Say Y here if you have system with IMS Rave Passenger Control Unit.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ims_pcu.
+
config INPUT_CMA3000
tristate VTI CMA3000 Tri-axis accelerometer
help
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index ae5d9fd..33085784 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
obj-$(CONFIG_INPUT_GPIO_BEEPER)+= gpio-beeper.o
obj-$(CONFIG_INPUT_GPIO_TILT_POLLED) += gpio_tilt_polled.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
+obj-$(CONFIG_INPUT_IMS_PCU)+= ims-pcu.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
new file mode 100644
index 000..10bd73c
--- /dev/null
+++ b/drivers/input/misc/ims-pcu.c
@@ -0,0 +1,1907 @@
+/*
+ * Driver for IMS Passenger Control Unit Devices
+ *
+ * Copyright (C) 2013 The IMS Company
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#include linux/completion.h
+#include linux/device.h
+#include linux/firmware.h
+#include linux/ihex.h
+#include linux/input.h
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/usb/input.h
+#include linux/usb/cdc.h
+#include asm/unaligned.h
+
+#define IMS_PCU_KEYMAP_LEN 32
+
+struct ims_pcu_buttons {
+ struct input_dev *input;
+ char name[32];
+ char phys[32];
+ unsigned short keymap[IMS_PCU_KEYMAP_LEN];
+};
+
+struct ims_pcu_gamepad {
+ struct input_dev *input;
+ char name[32];
+ char phys[32];
+};
+
+struct ims_pcu_backlight {
+ struct led_classdev cdev;
+ struct work_struct work;
+ enum led_brightness desired_brightness;
+ char name[32];
+};
+
+#define IMS_PCU_PART_NUMBER_LEN15
+#define IMS_PCU_SERIAL_NUMBER_LEN 8
+#define IMS_PCU_DOM_LEN8
+#define IMS_PCU_FW_VERSION_LEN (9 + 1)
+#define IMS_PCU_BL_VERSION_LEN (9 + 1)
+#define IMS_PCU_BL_RESET_REASON_LEN(2 + 1)
+
+#define IMS_PCU_BUF_SIZE 128
+
+struct ims_pcu {
+ struct usb_device *udev;
+ struct device *dev; /* control interface's device, used for logging */
+
+ unsigned int device_no;
+
+ bool bootloader_mode;
+
+ char part_number[IMS_PCU_PART_NUMBER_LEN];
+ char serial_number[IMS_PCU_SERIAL_NUMBER_LEN];
+ char date_of_manufacturing[IMS_PCU_DOM_LEN];
+ char fw_version[IMS_PCU_FW_VERSION_LEN];
+ char bl_version[IMS_PCU_BL_VERSION_LEN];
+ char reset_reason[IMS_PCU_BL_RESET_REASON_LEN];
+ int update_firmware_status;
+
+ struct usb_interface *ctrl_intf;
+
+ struct usb_endpoint_descriptor *ep_ctrl;
+ struct urb *urb_ctrl;
+ u8 *urb_ctrl_buf;
+ dma_addr_t ctrl_dma;
+ size_t max_ctrl_size;
+
+ struct usb_interface *data_intf;
+
+ struct usb_endpoint_descriptor *ep_in;
+ struct urb *urb_in;
+ u8 *urb_in_buf;
+ dma_addr_t read_dma;
+ size_t max_in_size;
+
+ struct
[PATCH 3/3] USB: cdc-acm - blacklist IMS PCU device
The IMS PCU (Passenger Control Unit) device used custom protocol over serial
line, so it is presenting itself as CDC ACM device.
Now that we have proper in-kernel driver for it we need to black-list the
device in cdc-acm driver.
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
drivers/usb/class/cdc-acm.c | 13 +
drivers/usb/class/cdc-acm.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 2d92cce..3c8473d 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -987,6 +987,10 @@ static int acm_probe(struct usb_interface *intf,
/* normal quirks */
quirks = (unsigned long)id-driver_info;
+
+ if (quirks == IGNORE_DEVICE)
+ return -ENODEV;
+
num_rx_buf = (quirks == SINGLE_RX_URB) ? 1 : ACM_NR;
/* handle quirks deadly to normal probing*/
@@ -1691,6 +1695,15 @@ static const struct usb_device_id acm_ids[] = {
.driver_info = NO_DATA_INTERFACE,
},
+#if IS_ENABLED(CONFIG_INPUT_IMS_PCU)
+ { USB_DEVICE(0x04d8, 0x0082), /* Application mode */
+ .driver_info = IGNORE_DEVICE,
+ },
+ { USB_DEVICE(0x04d8, 0x0083), /* Bootloader mode */
+ .driver_info = IGNORE_DEVICE,
+ },
+#endif
+
/* control interfaces without any protocol set */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
USB_CDC_PROTO_NONE) },
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index 35ef887..0f76e4a 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -128,3 +128,4 @@ struct acm {
#define NO_CAP_LINE4
#define NOT_A_MODEM8
#define NO_DATA_INTERFACE 16
+#define IGNORE_DEVICE 32
--
1.7.11.7
--
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 3/3] USB: cdc-acm - blacklist IMS PCU device
On Mon, Feb 18, 2013 at 11:05:57AM -0800, Dmitry Torokhov wrote: The IMS PCU (Passenger Control Unit) device used custom protocol over serial line, so it is presenting itself as CDC ACM device. Now that we have proper in-kernel driver for it we need to black-list the device in cdc-acm driver. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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] usb/core: add current frame_number sysfs attr to hcd
On Mon, 18 Feb 2013, Stefan Tauner wrote: This allows user space to retrieve the current frame number on a USB as returned by usb_get_current_frame_number(...) via sysfs. Signed-off-by: Stefan Tauner stefan.tau...@student.tuwien.ac.at --- That's sadly not necessarily the raw value seen on the bus because the individual driver functions called by usb_get_current_frame_number(...) seem to limit the possible range to the schedule horizon of isochronous packets. IMHO the function name is a misnomer and I would like to hear your opinion on this, a possible new name for it and a better way to retrieve the real/raw value. A problem, as you point out, is that the individual host controller drivers are somewhat careless about how they implement this. For example, the value reported by ehci-hcd increments 125 us before the value seen on the bus (in addition to being limited to the schedule horizon for no good reason). 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: Linux 3.8 broken for MacBookAir5,1
On Sun, 10 Feb 2013, Otavio Salvador wrote: On Sun, Feb 10, 2013 at 12:47 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 10 Feb 2013, Otavio Salvador wrote: I do have EHCI and PCI enabled so it should be working. Any clue about why it breaks it? Perhaps your system is not loading the new ehci-pci kernel module. Yes; it should be the cause as building it built-in makes it work. However it is a regression from my point of view. Those are the controllers I have in my system: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) I thought the ehci-pci module would be load for every ehci PCI; What do you think? The kernel can't guarantee anything about what driver modules are loaded. That's up to userspace. In particular, the initramfs image must be set up properly (if that is where these modules are loaded from). 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: Linux 3.8 broken for MacBookAir5,1
On Mon, Feb 18, 2013 at 7:09 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 10 Feb 2013, Otavio Salvador wrote: On Sun, Feb 10, 2013 at 12:47 PM, Alan Stern st...@rowland.harvard.edu wrote: On Sun, 10 Feb 2013, Otavio Salvador wrote: I do have EHCI and PCI enabled so it should be working. Any clue about why it breaks it? Perhaps your system is not loading the new ehci-pci kernel module. Yes; it should be the cause as building it built-in makes it work. However it is a regression from my point of view. Those are the controllers I have in my system: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) I thought the ehci-pci module would be load for every ehci PCI; What do you think? The kernel can't guarantee anything about what driver modules are loaded. That's up to userspace. In particular, the initramfs image must be set up properly (if that is where these modules are loaded from). But why kernel cannot load it if we have a PCI subsystem? Or do you think my initrd did not put the module on the initramfs image? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- 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: -drop_endpoint being called for disabled endpoints
On Fri, 15 Feb 2013, Felipe Balbi wrote: Hi all, I keep seeing the following messages when transferring data to any USB3 mass storage I have (tried 3 different ones already): [618002.014556] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 88012976cd40 [618002.014562] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 88012976cd80 It looks like usbcore is calling -drop_endpoint() for endpoints which are already disabled. I wonder if that's something legal to do or if we want to protect calls to -drop_endpoint() with if (ep-enabled) check. There was a thread on this topic a couple of weeks ago: http://marc.info/?t=13587409252r=1w=2 Device resets cause the hardware to disable the endpoint rings, but apparently xhci-hcd doesn't take this into account. Hence it ends up trying to drop endpoints which are already disabled, causing those error messages. I'll add a WARN_ONCE() later just to check who's to blame here, but it's a pretty annoying message to see all the time. :-) How about something like below ? No, I think this needs to be fixed in xhci-hcd. 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 2/2] USB: EHCI: make ehci-orion a separate driver
On Fri, 15 Feb 2013, Arnd Bergmann wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like
drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the
previous definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined
but not used [-Wunused-variable]
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o
+obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o
Both of these two new lines should be formatted like the other lines in
this file (i.e., with tabs at the corresponding places), and they
should come before the OXU210HP_HCD entry so that they are next to the
other EHCI-related lines.
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -17,6 +17,13 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_irq.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/io.h
+#include linux/dma-mapping.h
Is this line really needed?
@@ -34,6 +41,17 @@
#define USB_PHY_IVREF_CTRL 0x440
#define USB_PHY_TST_GRP_CTRL 0x450
+#define DRIVER_DESC EHCI orion driver
+
+static const char hcd_name[] = ehci-orion;
+
+static struct hc_driver __read_mostly ehci_orion_hc_driver;
+
+static const struct ehci_driver_overrides orion_overrides __initdata = {
+ .reset = ehci_setup,
+};
This is not necessary; ehci_setup is the default value anyway. This
structure can be omitted.
@@ -323,8 +296,6 @@ static int __exit ehci_orion_drv_remove(struct
platform_device *pdev)
return 0;
}
-MODULE_ALIAS(platform:orion-ehci);
-
static const struct of_device_id ehci_orion_dt_ids[] = {
{ .compatible = marvell,orion-ehci, },
{},
@@ -336,8 +307,31 @@ static struct platform_driver ehci_orion_driver = {
.remove = __exit_p(ehci_orion_drv_remove),
.shutdown = usb_hcd_platform_shutdown,
.driver = {
- .name = orion-ehci,
+ .name = hcd_name,
Is this really what you want -- changing the driver name from
orion-ehci to ehci-orion? Is that liable to cause trouble?
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS(platform:ehci-orion);
And is this really what you want -- changing the alias from
platform:orion-ehci to platform:ehci-orion?
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: Linux 3.8 broken for MacBookAir5,1
On Mon, 18 Feb 2013, Otavio Salvador wrote: I thought the ehci-pci module would be load for every ehci PCI; What do you think? The kernel can't guarantee anything about what driver modules are loaded. That's up to userspace. In particular, the initramfs image must be set up properly (if that is where these modules are loaded from). But why kernel cannot load it if we have a PCI subsystem? Or do you think my initrd did not put the module on the initramfs image? That's exactly what I think. See this message and the corresponding thread: http://marc.info/?l=linux-usbm=136074995914335w=2 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: Linux 3.8 broken for MacBookAir5,1
On Mon, Feb 18, 2013 at 7:38 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 18 Feb 2013, Otavio Salvador wrote: I thought the ehci-pci module would be load for every ehci PCI; What do you think? The kernel can't guarantee anything about what driver modules are loaded. That's up to userspace. In particular, the initramfs image must be set up properly (if that is where these modules are loaded from). But why kernel cannot load it if we have a PCI subsystem? Or do you think my initrd did not put the module on the initramfs image? That's exactly what I think. See this message and the corresponding thread: http://marc.info/?l=linux-usbm=136074995914335w=2 Thanks Alan, this was the problem. Regards, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- 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] usb/core: add current frame_number sysfs attr to hcd
On Mon, 18 Feb 2013 07:20:56 -0800 Greg KH gre...@linuxfoundation.org wrote: On Mon, Feb 18, 2013 at 03:34:07PM +0100, Stefan Tauner wrote: This allows user space to retrieve the current frame number on a USB as returned by usb_get_current_frame_number(...) via sysfs. Signed-off-by: Stefan Tauner stefan.tau...@student.tuwien.ac.at --- That's sadly not necessarily the raw value seen on the bus because the individual driver functions called by usb_get_current_frame_number(...) seem to limit the possible range to the schedule horizon of isochronous packets. IMHO the function name is a misnomer and I would like to hear your opinion on this, a possible new name for it and a better way to retrieve the real/raw value. The rationale for this patch can be found in the thread with the subject Correlating SOF with host system time from last december (201212042020.qb4kkt0n008...@mail2.student.tuwien.ac.at). My whole use case/idea was kinda frowned upon then, but there was little discussion about how it should/could be implemented in the kernel code in case one really wants to try it. For those of us with bad memories, care to expand on why you want this in the changelog body of the patch so that the world will remember it as well? Well, I am not entirely sure if even I want this in (as is) yet, because it is just a part of a complete solution for my problem and I can't imagine a reason why user space would want to know this odd value as is. So I can not give a committable rationale yet, but I can sum up what I am trying to do eventually: I try to map SOF counters to CLOCK_REALTIME timestamps in user space. Later I want to use that to establish a global time base on microcontrollers connected via USB without the hassle of running NTP or PTP over USB. In user space I am waiting for changes in the frame_counter sysfs file by reading it and comparing its contents to values previously read in a busy loop, which is of course not very elegant but it works - apart from the fact that the returned values are not the raw values (and as Alan noted, might also be off a bit)... :) Therefore I am currently playing around with a usb_hcd_get_real_frame_number() which uses a ehci_get_real_frame() function hacked into ehci-hcd.c which returns the actual SOF counter without the artificial horizon limit, but this is of course not committable. I wonder though why the limitation is there in the first place. Most users of usb_get_current_frame_number() seem rather unhappy with the limitation (e.g. drivers/media/usb/uvc/uvc_video.c) or don't care because they cap the returned value to the (locally defined(!)) minimum of the schedule horizon (0xFF everywhere AFAICS). Only very few use it directly to determine a possible scheduling (e.g. drivers/isdn/hisax/st5481_d.c which looks rather dubious to my naive eyes BTW). So from the user's perspective I don't see a reason why the artificially limited reply should be returned instead of the complete value. I have not checked if the raw value is available on all HCDs, but I assume it is. Wouldn't it make sense to change usb_hcd_get_frame_number() to return the raw value and add another one that returns the actual limit of the schedule horizon e.g. periodic_size in the case of EHCI(?) for those users that want to scheduler packets? If not, I would really like to see the documentation of usb_get_current_frame_number() be changed to make it more clear that it is not the raw SOF value and *why*. I have not figured out what *exactly* it is yet/how the iso scheduling works... grasping the kernel - even a subsystem - is quite an effort :) If/when I do I will send a documentation patch. If you think refactoring get_frame_number should be done I would be glad to work on it. A few pointers to what the result should look like and any obvious pitfalls would be appreciated in that case. Whenever you add/modify/remove a sysfs attribute, you also need to document it in Documentation/ABI/. Care to do that and resend this patch? Sure, if you think it makes sense to add the code as is, I can do that any time. Thanks for the amazingly fast reply BTW. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- 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] pci: do not try to assign irq 255
On Mon, Feb 18, 2013 at 11:09:53AM +0100, Hannes Reinecke wrote: The PCI config space reseves a byte for the interrupt line, so irq 255 actually refers to 'not set'. However, the 'irq' field for struct pci_dev is an integer, so the original meaning is lost, causing the system to assign an interrupt '255', which fails. So we should _not_ assign an interrupt value here, and allow upper layers to fixup things. This patch make PCI devices with MSI interrupts only (like the xhci device on certain HP laptops) work properly. Just tested and it works for me. Thank you. Tested-by: David Härdeman da...@hardeman.nu Cc: Frederik Himpe fhi...@vub.ac.be Cc: Oliver Neukum oneu...@suse.de Cc: David Haerdeman da...@hardeman.nu Cc: linux-usb@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Hannes Reinecke h...@suse.de diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 6186f03..a2db887f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -923,7 +923,8 @@ static void pci_read_irq(struct pci_dev *dev) dev-pin = irq; if (irq) pci_read_config_byte(dev, PCI_INTERRUPT_LINE, irq); - dev-irq = irq; + if (irq 255) + dev-irq = irq; } void set_pcie_port_type(struct pci_dev *pdev) -- David Härdeman -- 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] usb/core: add current frame_number sysfs attr to hcd
On Tue, 19 Feb 2013, Stefan Tauner wrote: Well, I am not entirely sure if even I want this in (as is) yet, because it is just a part of a complete solution for my problem and I can't imagine a reason why user space would want to know this odd value as is. So I can not give a committable rationale yet, but I can sum up what I am trying to do eventually: I try to map SOF counters to CLOCK_REALTIME timestamps in user space. Later I want to use that to establish a global time base on microcontrollers connected via USB without the hassle of running NTP or PTP over USB. In user space I am waiting for changes in the frame_counter sysfs file by reading it and comparing its contents to values previously read in a busy loop, which is of course not very elegant but it works - apart from the fact that the returned values are not the raw values (and as Alan noted, might also be off a bit)... :) Therefore I am currently playing around with a usb_hcd_get_real_frame_number() which uses a ehci_get_real_frame() function hacked into ehci-hcd.c which returns the actual SOF counter without the artificial horizon limit, but this is of course not committable. I wonder though why the limitation is there in the first place. Most users of usb_get_current_frame_number() seem rather unhappy with the limitation (e.g. drivers/media/usb/uvc/uvc_video.c) or don't care because they cap the returned value to the (locally defined(!)) minimum of the schedule horizon (0xFF everywhere AFAICS). Only very few use it directly to determine a possible scheduling (e.g. drivers/isdn/hisax/st5481_d.c which looks rather dubious to my naive eyes BTW). I wasn't aware that anyone was trying to use this API. In my opinion doing so is probably a mistake. In the future, all scheduling of periodic transfers will be done by the host controller driver; the upper-layer drivers won't have any choice in the matter. Hence they shouldn't care about the current frame number. (Note that drivers can still determine in which frames individual isochronous packets were sent. That information is available from urb-start_frame.) So from the user's perspective I don't see a reason why the artificially limited reply should be returned instead of the complete value. I have This was probably the result of some early design decisions which have not turned out well. not checked if the raw value is available on all HCDs, but I assume it is. Wouldn't it make sense to change usb_hcd_get_frame_number() to return the raw value and add another one that returns the actual limit of the schedule horizon e.g. periodic_size in the case of EHCI(?) for those users that want to scheduler packets? Users should never want to schedule packets. If not, I would really like to see the documentation of usb_get_current_frame_number() be changed to make it more clear that it is not the raw SOF value and *why*. I have not figured out what *exactly* it is yet/how the iso scheduling works... grasping the kernel - even a subsystem - is quite an effort :) If/when I do I will send a documentation patch. It's going to get more complicated -- in one sense, that is: more complicated for the controller driver, but less complicated for everybody else. As far as I'm concerned, the usb_get_current_frame_number() API can be removed (unless somebody suggests a good use for it). If you think refactoring get_frame_number should be done I would be glad to work on it. A few pointers to what the result should look like and any obvious pitfalls would be appreciated in that case. Using frame boundaries for time synchronization at the user level is possibly a defensible reason for exporting frame numbers. But there are better ways to accomplish this goal. For example, there could be an API that returns both a realtime value and a microframe number as of the next time a completion interrupt occurs. 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
qcaux: add Franklin U600
4 ports; AT/PPP is standard CDC-ACM. The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.
Signed-off-by: Dan Williams d...@redhat.com
---
diff --git a/drivers/usb/serial/qcaux.c b/drivers/usb/serial/qcaux.c
index 9b1b96f..31f81c3 100644
--- a/drivers/usb/serial/qcaux.c
+++ b/drivers/usb/serial/qcaux.c
@@ -69,6 +69,7 @@ static struct usb_device_id id_table[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff)
}, /* NMEA */
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfe, 0xff)
}, /* WMC */
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xff, 0xff)
}, /* DIAG */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1fac, 0x0151, 0xff, 0xff, 0xff) },
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
--
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: Not enough resource for old configuration after USB bus reset
Hi all, I checkout the usb-next branch (on 2/18) and following the https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel. After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/Linux. I try the same operation to produce the issue, and it also fails. Thanks, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Friday, February 08, 2013 12:57 AM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 于 2013/2/7 16:59, Soar Hung 写道: Hi Tianyu, I can produce the issue on the Ubuntu 12.10 (linux 3.5), too. However, could you tell me more detail about what to do or give me some hint for google? Do you mean replacing the usb related source with source from 'usb next', rebuild the kernel, and test again? I think you can git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git and git checkout usb-next. Compile kernel and test it. Best regards, Soar -Original Message- From: Lan Tianyu [mailto:lantianyu1...@gmail.com] Sent: Thursday, February 07, 2013 4:18 PM To: Soar Hung Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org Subject: Re: Not enough resource for old configuration after USB bus reset 2013/2/4 Soar Hung soarh...@realtek.com: Hi Alan, Sarah, Thank you for your kindly help. Can I do something to provide some help? You found the issue on the 3.0.30+ kernel. Can you test it on the usb-next branch of usb tree? Sarah has fixed a lot of bugs since v3.0. Best regards, Soar -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Friday, February 01, 2013 11:36 PM To: Soar Hung Cc: Sarah Sharp; linux-usb@vger.kernel.org Subject: RE: Not enough resource for old configuration after USB bus reset On Fri, 1 Feb 2013, [big5] x R wrote: Hi, According to xHCI spec Rev1 page 125, Endpoint context state diagram. When reset device, the endpoint state transit to disabled state. Do I make some mistake? I'll try to figure out the endopint state transitions during the reset flow, and update information later. Thanks for the direction. Ah, now I understand the problem. The device reset automatically disables the endpoints, so when usb_reset_and_verify_device calls usb_hcd_alloc_bandwidth, and that routine tries to drop the endpoints, it fails because the endpoints are already disabled. Sarah is going to to have to figure out the right way to fix this. She's the maintainer for xhci-hcd. Alan Stern -- Best regards Tianyu Lan --Please consider the environment before printing this e-mail. -- Best regards Tianyu Lan -- 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 v2] qmi_wwan, cdc-ether: add ADU960S
It advertises a standard CDC-ETHER interface, which actually should be
driven by qmi_wwan.
Signed-off-by: Dan Williams d...@redhat.com
---
index 3f3d12d..57136dc 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -615,6 +615,13 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* AnyDATA ADU960S - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 19d9035..efb5c7c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -409,6 +409,13 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info= (unsigned long)qmi_wwan_info,
},
+ { /* ADU960S */
+ USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info= (unsigned long)qmi_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x0408, 0xea42, 4)},/* Yota / Megafon M100-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
Re: [PATCH v2] qmi_wwan, cdc-ether: add ADU960S
From: Dan Williams d...@redhat.com Date: Mon, 18 Feb 2013 21:25:09 -0600 It advertises a standard CDC-ETHER interface, which actually should be driven by qmi_wwan. Signed-off-by: Dan Williams d...@redhat.com Applied. -- 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 v2 2/5] usb: phy: omap-usb2: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/phy/omap-usb2.c | 49 ++
include/linux/usb/omap_usb.h |3 +++
2 files changed, 52 insertions(+)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..924ae59 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -119,9 +119,48 @@ static int omap_usb2_suspend(struct usb_phy *x, int
suspend)
return 0;
}
+static int omap_usb_suspend(struct phy_descriptor *desc)
+{
+ struct omap_usb *phy = desc_to_omapusb(desc);
+
+ if (!phy-is_suspended) {
+ omap_control_usb_phy_power(phy-control_dev, 0);
+ pm_runtime_put_sync(phy-dev);
+ phy-is_suspended = 1;
+ }
+
+ return 0;
+}
+
+static int omap_usb_resume(struct phy_descriptor *desc)
+{
+ u32 ret;
+ struct omap_usb *phy = desc_to_omapusb(desc);
+
+ if (phy-is_suspended) {
+ ret = pm_runtime_get_sync(phy-dev);
+ if (ret 0) {
+ dev_err(phy-dev, get_sync failed with err %d\n,
+ ret);
+ return ret;
+ }
+ omap_control_usb_phy_power(phy-control_dev, 1);
+ phy-is_suspended = 0;
+ }
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= omap_usb_suspend,
+ .resume = omap_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
+ struct phy *generic_phy;
struct usb_otg *otg;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +183,16 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
+ phy-desc.ops = ops;
+ phy-desc.label = omap-usb2;
+ phy-desc.of_node = pdev-dev.of_node;
+
+ generic_phy = devm_phy_create(phy-dev, phy-desc);
+ if (IS_ERR(generic_phy)) {
+ dev_dbg(pdev-dev, Failed to create PHY\n);
+ return PTR_ERR(generic_phy);
+ }
+
phy-control_dev = omap_get_control_dev();
if (IS_ERR(phy-control_dev)) {
dev_dbg(pdev-dev, Failed to get control device\n);
diff --git a/include/linux/usb/omap_usb.h b/include/linux/usb/omap_usb.h
index 6ae2936..4c6878e 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/usb/omap_usb.h
@@ -20,6 +20,7 @@
#define __DRIVERS_OMAP_USB2_H
#include linux/io.h
+#include linux/phy/phy.h
#include linux/usb/otg.h
struct usb_dpll_params {
@@ -32,6 +33,7 @@ struct usb_dpll_params {
struct omap_usb {
struct usb_phy phy;
+ struct phy_descriptor desc;
struct phy_companion*comparator;
void __iomem*pll_ctrl_base;
struct device *dev;
@@ -43,6 +45,7 @@ struct omap_usb {
};
#definephy_to_omapusb(x) container_of((x), struct omap_usb, phy)
+#definedesc_to_omapusb(x) container_of((x), struct omap_usb, desc)
#if defined(CONFIG_OMAP_USB2) || defined(CONFIG_OMAP_USB2_MODULE)
extern int omap_usb2_set_comparator(struct phy_companion *comparator);
--
1.7.10.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
[PATCH v2 3/5] usb: otg: twl4030: use the new generic PHY framework
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..b79c319 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
#include linux/io.h
#include linux/delay.h
#include linux/usb/otg.h
+#include linux/phy/phy.h
#include linux/usb/musb-omap.h
#include linux/usb/ulpi.h
#include linux/i2c/twl.h
@@ -145,6 +146,7 @@
struct twl4030_usb {
struct usb_phy phy;
+ struct phy_descriptor desc;
struct device *dev;
/* TWL4030 internal USB regulator supplies */
@@ -167,6 +169,7 @@ struct twl4030_usb {
/* internal define on top of container_of */
#define phy_to_twl(x) container_of((x), struct twl4030_usb, phy)
+#define desc_to_twl(x) container_of((x), struct twl4030_usb, desc)
/*-*/
@@ -575,10 +578,38 @@ static int twl4030_set_host(struct usb_otg *otg, struct
usb_bus *host)
return 0;
}
+static int twl4030_usb_suspend(struct phy_descriptor *desc)
+{
+ struct twl4030_usb *twl = desc_to_twl(desc);
+
+ twl4030_phy_suspend(twl, 1);
+
+ return 0;
+}
+
+static int twl4030_usb_resume(struct phy_descriptor *desc)
+{
+ struct twl4030_usb *twl = desc_to_twl(desc);
+
+ if (!twl-asleep)
+ return -EBUSY;
+ __twl4030_phy_resume(twl);
+ twl-asleep = 0;
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .suspend= twl4030_usb_suspend,
+ .resume = twl4030_usb_resume,
+ .owner = THIS_MODULE,
+};
+
static int twl4030_usb_probe(struct platform_device *pdev)
{
struct twl4030_usb_data *pdata = pdev-dev.platform_data;
struct twl4030_usb *twl;
+ struct phy *phy;
int status, err;
struct usb_otg *otg;
struct device_node *np = pdev-dev.of_node;
@@ -617,6 +648,16 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg-set_host = twl4030_set_host;
otg-set_peripheral = twl4030_set_peripheral;
+ twl-desc.ops = ops;
+ twl-desc.label = twl4030;
+ twl-desc.of_node = pdev-dev.of_node;
+
+ phy = devm_phy_create(twl-dev, twl-desc);
+ if (IS_ERR(phy)) {
+ dev_dbg(pdev-dev, Failed to create PHY\n);
+ return PTR_ERR(phy);
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
--
1.7.10.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
[PATCH v2 0/5] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Changes from v1: * Added Documentation for the PHY framework * Added few more APIs mostly w.r.t devres * Modified omap-usb2 and twl4030 to make use of the new framework Did USB enumeration testing in panda and beagle. Kishon Vijay Abraham I (5): drivers: phy: add generic PHY framework usb: phy: omap-usb2: use the new generic PHY framework usb: otg: twl4030: use the new generic PHY framework ARM: OMAP: USB: Add phy binding information usb: musb: omap2430: use the new generic PHY framework Documentation/ABI/testing/sysfs-class-phy| 15 + Documentation/phy.txt| 113 ++ MAINTAINERS |7 + arch/arm/mach-omap2/board-2430sdp.c |2 + arch/arm/mach-omap2/board-3430sdp.c |2 + arch/arm/mach-omap2/board-4430sdp.c |2 + arch/arm/mach-omap2/board-cm-t35.c |2 + arch/arm/mach-omap2/board-devkit8000.c |2 + arch/arm/mach-omap2/board-igep0020.c |2 + arch/arm/mach-omap2/board-ldp.c |2 + arch/arm/mach-omap2/board-omap3beagle.c |2 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3logic.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |2 + arch/arm/mach-omap2/board-omap3touchbook.c |2 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c|2 + arch/arm/mach-omap2/board-rm680.c|2 + arch/arm/mach-omap2/board-zoom-peripherals.c |2 + drivers/Kconfig |2 + drivers/Makefile |2 + drivers/phy/Kconfig | 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 519 ++ drivers/usb/musb/musb_core.h |2 + drivers/usb/musb/omap2430.c | 22 +- drivers/usb/otg/twl4030-usb.c| 41 ++ drivers/usb/phy/omap-usb2.c | 49 +++ include/linux/phy/phy.h | 198 ++ include/linux/usb/omap_usb.h |3 + 31 files changed, 1019 insertions(+), 6 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-phy create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 1.7.10.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
[PATCH v2 5/5] usb: musb: omap2430: use the new generic PHY framework
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb-xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 22 --
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include linux/usb.h
#include linux/usb/otg.h
#include linux/usb/musb.h
+#include linux/phy/phy.h
struct musb;
struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1762354..99378af 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,14 +345,24 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev-parent-of_node)
+ if (dev-parent-of_node) {
+ musb-phy = devm_of_phy_get(dev-parent, usb-phy, 0);
+
+ /* We can't totally remove musb-xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
- else
+ } else {
musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-phy = devm_phy_get(dev, 0);
+ }
- if (IS_ERR_OR_NULL(musb-xceiv)) {
- pr_err(HS USB OTG: no transceiver configured\n);
+ if (IS_ERR_OR_NULL(musb-xceiv) || IS_ERR_OR_NULL(musb-phy)) {
+ dev_err(dev, no transceiver configured\n);
return -EPROBE_DEFER;
}
@@ -608,7 +618,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
omap2430_low_level_exit(musb);
- usb_phy_set_suspend(musb-xceiv, 1);
+ phy_suspend(musb-phy);
}
return 0;
@@ -624,7 +634,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb-mregs, OTG_INTERFSEL,
musb-context.otg_interfsel);
- usb_phy_set_suspend(musb-xceiv, 0);
+ phy_resume(musb-phy);
}
return 0;
--
1.7.10.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 2/2] USB: EHCI: make ehci-orion a separate driver
On Mon, Feb 18, 2013 at 05:34:35PM -0500, Alan Stern wrote:
On Fri, 15 Feb 2013, Arnd Bergmann wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
With the multiplatform changes in arm-soc tree, it becomes
possible to enable the mvebu platform (which uses
ehci-orion) at the same time as other platforms that require
a conflicting EHCI bus glue. At the moment, this results
in a warning like
drivers/usb/host/ehci-hcd.c:1297:0: warning: PLATFORM_DRIVER redefined
[enabled by default]
drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the
previous definition
drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined
but not used [-Wunused-variable]
and an ehci driver that only works on one of them.
With the infrastructure added by Alan Stern in patch 3e0232039
USB: EHCI: prepare to make ehci-hcd a library module, we can
avoid this problem by turning a bus glue into a separate
module, as we do here for the orion bus glue.
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
obj-$(CONFIG_USB_EHCI_HCD_VT8500)+= ehci-vt8500.o
+obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o
Both of these two new lines should be formatted like the other lines in
this file (i.e., with tabs at the corresponding places), and they
should come before the OXU210HP_HCD entry so that they are next to the
other EHCI-related lines.
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -17,6 +17,13 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_irq.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/io.h
+#include linux/dma-mapping.h
Is this line really needed?
@@ -34,6 +41,17 @@
#define USB_PHY_IVREF_CTRL 0x440
#define USB_PHY_TST_GRP_CTRL 0x450
+#define DRIVER_DESC EHCI orion driver
+
+static const char hcd_name[] = ehci-orion;
+
+static struct hc_driver __read_mostly ehci_orion_hc_driver;
+
+static const struct ehci_driver_overrides orion_overrides __initdata = {
+ .reset = ehci_setup,
+};
This is not necessary; ehci_setup is the default value anyway. This
structure can be omitted.
@@ -323,8 +296,6 @@ static int __exit ehci_orion_drv_remove(struct
platform_device *pdev)
return 0;
}
-MODULE_ALIAS(platform:orion-ehci);
-
static const struct of_device_id ehci_orion_dt_ids[] = {
{ .compatible = marvell,orion-ehci, },
{},
@@ -336,8 +307,31 @@ static struct platform_driver ehci_orion_driver = {
.remove = __exit_p(ehci_orion_drv_remove),
.shutdown = usb_hcd_platform_shutdown,
.driver = {
- .name = orion-ehci,
+ .name = hcd_name,
Is this really what you want -- changing the driver name from
orion-ehci to ehci-orion? Is that liable to cause trouble?
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_ALIAS(platform:ehci-orion);
And is this really what you want -- changing the alias from
platform:orion-ehci to platform:ehci-orion?
Hi Manjunath
I can confirm that this breaks non DT based kirkwood systems. The
driver does not get loaded.
Sorry for not testing and finding this case earlier, i just tested a
DT based system.
GregKH: Please can you drop this patch from usb-next. It breaks more
than it fixes.
Andrew
--
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: [regression][v3.8rc6-v3.8rc7] ehci-pci fails with error -110 on read/[64,all]
Correction, this regression/commit (55bcdce) was introduced between
rc6 and rc7. Sorry about that.
2013/2/18 Ronald ronald...@gmail.com:
CC'ing the author of the patch.
2013/2/18 Ronald ronald...@gmail.com:
This e-mail is a follow-up as requested in this bug[1]. I will repost
everything so far in this e-mail. Please CC me as I'm not subscribed
to your list.
Current head gives this when I plug a 'Mass Storage Device' into a 2.0
hub:
[ 842.760400] hub 1-0:1.0: unable to enumerate USB device on port 3
[ 843.080058] usb 1-3: new high-speed USB device number 48 using ehci-pci
[ 858.230072] usb 1-3: device descriptor read/64, error -110
[ 873.490070] usb 1-3: device descriptor read/64, error -110
Reverting the following commit makes it work again:
commit 55bcdce8a8228223ec4d17d8ded8134ed265d2c5
Author: Alan Stern st...@rowland.harvard.edu
Date: Fri Jan 25 16:52:45 2013 -0500
USB: EHCI: remove ASS/PSS polling timeout
This patch (as1647) attempts to work around a problem that seems to
affect some nVidia EHCI controllers. They sometimes take a very long
time to turn off their async or periodic schedules. I don't know if
this is a result of other problems, but in any case it seems wise not
to depend on schedule enables or disables taking effect in any
specific length of time.
The patch removes the existing 20-ms timeout for enabling and
disabling the schedules. The driver will now continue to poll the
schedule state at 1-ms intervals until the controller finally decides
to obey the most recent command issued by the driver. Just in case
this hides a problem, a debugging message will be logged if the
controller takes longer than 20 polls.
I don't know if this will actually fix anything, but it can't hurt.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Tested-by: Piergiorgio Sartor piergiorgio.sar...@nexgo.de
CC: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c
index 20dbdcb..f904071 100644
--- a/drivers/usb/host/ehci-timer.c
+++ b/drivers/usb/host/ehci-timer.c
@@ -113,14 +113,15 @@ static void ehci_poll_ASS(struct ehci_hcd *ehci)
if (want != actual) {
- /* Poll again later, but give up after about 20 ms */
- if (ehci-ASS_poll_count++ 20) {
- ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS,
true);
- return;
- }
- ehci_dbg(ehci, Waited too long for the async schedule
status(%x/%x), giving up\n,
- want, actual);
+ /* Poll again later */
+ ehci_enable_event(ehci, EHCI_HRTIMER_POLL_ASS, true);
+ ++ehci-ASS_poll_count;
+ return;
}
+
+ if (ehci-PSS_poll_count 20)
+ ehci_dbg(ehci, PSS poll count reached %d\n,
+ ehci-PSS_poll_count);
ehci-PSS_poll_count = 0;
/* The status is up-to-date; restart or stop the schedule as
needed */
Please note, that I'm using the 'irqpoll' cmdline to improve system
stability. What I forgot to mention in the bug was the chipset:
00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82)
(prog-if 20 [EHCI])
Subsystem: Micro-Star International Co., Ltd. KT4AV motherboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 32, Cache Line Size: 32 bytes
Interrupt: pin D routed to IRQ 21
Region 0: Memory at dffeff00 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci-pci
Yes, it's 10 years old, and no I'm not scrooge. We are waiting a while
for computer prices to plummet mkay?
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=54031
Would like to add that while searching the mailing lists I stumbled on
this:
http://marc.info/?l=linux-usbm=136045531311402w=4
It's an entirely seperate USB issue in this cycle. The person is doing
git bisect to find the regression. I did another approach as
recompiling the full kernel on a 1,25GHz isn't even remotely funny
anymore.
On top of HEAD I started reverting groups of USB EHCI patches one by
one. I'm just mentioning it since I'm not sure if this procedure is
accepted here.
Did some more testing this morning. It seems like it's a race
condition, which somewhat confirms that this patch is involved. Just
had an occurance where the kernel with this
Re: -drop_endpoint being called for disabled endpoints
Hi, On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan Stern wrote: On Fri, 15 Feb 2013, Felipe Balbi wrote: Hi all, I keep seeing the following messages when transferring data to any USB3 mass storage I have (tried 3 different ones already): [618002.014556] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 88012976cd40 [618002.014562] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 88012976cd80 It looks like usbcore is calling -drop_endpoint() for endpoints which are already disabled. I wonder if that's something legal to do or if we want to protect calls to -drop_endpoint() with if (ep-enabled) check. There was a thread on this topic a couple of weeks ago: http://marc.info/?t=13587409252r=1w=2 Device resets cause the hardware to disable the endpoint rings, but apparently xhci-hcd doesn't take this into account. Hence it ends up trying to drop endpoints which are already disabled, causing those error messages. I'll add a WARN_ONCE() later just to check who's to blame here, but it's a pretty annoying message to see all the time. :-) How about something like below ? No, I think this needs to be fixed in xhci-hcd. fair enough, though I think the issue is two-fold: a) on reset xhci-hcd should set ep-enabled to zero b) patch I sent should still be applied no ? -- balbi signature.asc Description: Digital signature
