[PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
This patch is trying to fix this bug on SLES11 SP2:
https://bugzilla.novell.com/show_bug.cgi?id=817035
On a large HP system with 64T memory and 60 logical cpus, when usb
driver inits the iLo Virtual USB Controller, there comes a warning
"Controller not stopped yet!". It is because the HP iLo virtual usb
device requires a longer delay.
Signed-off-by: Li, Zhen-Hua
---
drivers/usb/host/uhci-hcd.c |5 +
drivers/usb/host/uhci-hub.c | 12 +++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..af30517 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -355,6 +355,11 @@ __acquires(uhci->lock)
if (uhci->dead)
return;
}
+
+ /* HP's iLo Virtual USB Controller requires a longer delay. */
+ if (uhci->wait_for_hp)
+ wait_for_HP(uhci, USBSTS, USBSTS_HCH, 1000);
+
if (!(uhci_readw(uhci, USBSTS) & USBSTS_HCH))
dev_warn(uhci_dev(uhci), "Controller not stopped yet!\n");
diff --git a/drivers/usb/host/uhci-hub.c b/drivers/usb/host/uhci-hub.c
index f87bee6..c3f772c 100644
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -120,14 +120,15 @@ static void uhci_finish_suspend(struct uhci_hcd *uhci,
int port,
}
/* Wait for the UHCI controller in HP's iLO2 server management chip.
- * It can take up to 250 us to finish a reset and set the CSC bit.
+ * It can take up to max_wait us to finish the operation.
*/
-static void wait_for_HP(struct uhci_hcd *uhci, unsigned long port_addr)
+static void wait_for_HP(struct uhci_hcd *uhci, unsigned long port_addr,
+ u16 status, int max_wait)
{
int i;
- for (i = 10; i < 250; i += 10) {
- if (uhci_readw(uhci, port_addr) & USBPORTSC_CSC)
+ for (i = 10; i < max_wait; i += 10) {
+ if (uhci_readw(uhci, port_addr) & status)
return;
udelay(10);
}
@@ -151,7 +152,8 @@ static void uhci_check_ports(struct uhci_hcd *uhci)
/* HP's server management chip requires
* a longer delay. */
if (uhci->wait_for_hp)
- wait_for_HP(uhci, port_addr);
+ wait_for_HP(uhci, port_addr,
+ USBPORTSC_CSC, 250);
/* If the port was enabled before, turning
* reset on caused a port enable change.
--
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 1/1] driver,usb: Fix a warning in uhci-hcd driver
There is a function wait_for_HP() in uhci-hub.c. In this
patch, it is used in suspend_rh(), I think this can be a
solution. And I have tested this patch, it can fix the bug.
I think there is another patch needed. As Alan said in another
mail, in the UHCI_RH_RUNNING_NODEVS case, it should not be stopped
if the uhci device is HP iLo virtual usb.
Thanks
Zhen-Hua
On 04/26/2013 03:38 PM, Li, Zhen-Hua wrote:
This patch is trying to fix this bug on SLES11 SP2:
https://bugzilla.novell.com/show_bug.cgi?id=817035
On a large HP system with 64T memory and 60 logical cpus, when usb
driver inits the iLo Virtual USB Controller, there comes a warning
"Controller not stopped yet!". It is because the HP iLo virtual usb
device requires a longer delay.
Signed-off-by: Li, Zhen-Hua
---
drivers/usb/host/uhci-hcd.c |5 +
drivers/usb/host/uhci-hub.c | 12 +++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..af30517 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -355,6 +355,11 @@ __acquires(uhci->lock)
if (uhci->dead)
return;
}
+
+ /* HP's iLo Virtual USB Controller requires a longer delay. */
+ if (uhci->wait_for_hp)
+ wait_for_HP(uhci, USBSTS, USBSTS_HCH, 1000);
+
if (!(uhci_readw(uhci, USBSTS) & USBSTS_HCH))
dev_warn(uhci_dev(uhci), "Controller not stopped yet!\n");
diff --git a/drivers/usb/host/uhci-hub.c b/drivers/usb/host/uhci-hub.c
index f87bee6..c3f772c 100644
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -120,14 +120,15 @@ static void uhci_finish_suspend(struct uhci_hcd *uhci,
int port,
}
/* Wait for the UHCI controller in HP's iLO2 server management chip.
- * It can take up to 250 us to finish a reset and set the CSC bit.
+ * It can take up to max_wait us to finish the operation.
*/
-static void wait_for_HP(struct uhci_hcd *uhci, unsigned long port_addr)
+static void wait_for_HP(struct uhci_hcd *uhci, unsigned long port_addr,
+ u16 status, int max_wait)
{
int i;
- for (i = 10; i < 250; i += 10) {
- if (uhci_readw(uhci, port_addr) & USBPORTSC_CSC)
+ for (i = 10; i < max_wait; i += 10) {
+ if (uhci_readw(uhci, port_addr) & status)
return;
udelay(10);
}
@@ -151,7 +152,8 @@ static void uhci_check_ports(struct uhci_hcd *uhci)
/* HP's server management chip requires
* a longer delay. */
if (uhci->wait_for_hp)
- wait_for_HP(uhci, port_addr);
+ wait_for_HP(uhci, port_addr,
+ USBPORTSC_CSC, 250);
/* If the port was enabled before, turning
* reset on caused a port enable change.
--
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 1/1] driver,usb: Fix a warning in uhci-hcd driver
On 04/26/2013 03:50 PM, ZhenHua wrote:
I think there is another patch needed. As Alan said in another
mail, in the UHCI_RH_RUNNING_NODEVS case, it should not be stopped
if the uhci device is HP iLo virtual usb.
correct: it should not be auto stopped if the uhci device is HP iLo
virtual usb.
Thanks
Zhen-Hua
On 04/26/2013 03:38 PM, Li, Zhen-Hua wrote:
This patch is trying to fix this bug on SLES11 SP2:
https://bugzilla.novell.com/show_bug.cgi?id=817035
On a large HP system with 64T memory and 60 logical cpus, when usb
driver inits the iLo Virtual USB Controller, there comes a warning
"Controller not stopped yet!". It is because the HP iLo virtual usb
device requires a longer delay.
Signed-off-by: Li, Zhen-Hua
---
drivers/usb/host/uhci-hcd.c |5 +
drivers/usb/host/uhci-hub.c | 12 +++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 4a86b63..af30517 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -355,6 +355,11 @@ __acquires(uhci->lock)
if (uhci->dead)
return;
}
+
+/* HP's iLo Virtual USB Controller requires a longer delay. */
+if (uhci->wait_for_hp)
+wait_for_HP(uhci, USBSTS, USBSTS_HCH, 1000);
+
if (!(uhci_readw(uhci, USBSTS) & USBSTS_HCH))
dev_warn(uhci_dev(uhci), "Controller not stopped yet!\n");
diff --git a/drivers/usb/host/uhci-hub.c b/drivers/usb/host/uhci-hub.c
index f87bee6..c3f772c 100644
--- a/drivers/usb/host/uhci-hub.c
+++ b/drivers/usb/host/uhci-hub.c
@@ -120,14 +120,15 @@ static void uhci_finish_suspend(struct uhci_hcd
*uhci, int port,
}
/* Wait for the UHCI controller in HP's iLO2 server management chip.
- * It can take up to 250 us to finish a reset and set the CSC bit.
+ * It can take up to max_wait us to finish the operation.
*/
-static void wait_for_HP(struct uhci_hcd *uhci, unsigned long port_addr)
+static void wait_for_HP(struct uhci_hcd *uhci, unsigned long port_addr,
+u16 status, int max_wait)
{
int i;
-for (i = 10; i < 250; i += 10) {
-if (uhci_readw(uhci, port_addr) & USBPORTSC_CSC)
+for (i = 10; i < max_wait; i += 10) {
+if (uhci_readw(uhci, port_addr) & status)
return;
udelay(10);
}
@@ -151,7 +152,8 @@ static void uhci_check_ports(struct uhci_hcd *uhci)
/* HP's server management chip requires
* a longer delay. */
if (uhci->wait_for_hp)
-wait_for_HP(uhci, port_addr);
+wait_for_HP(uhci, port_addr,
+USBPORTSC_CSC, 250);
/* If the port was enabled before, turning
* reset on caused a port enable change.
--
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 net-next] net/usb: new driver for RTL8152
Add new driver for supporting Realtek RTL8152 Based USB 2.0 Ethernet Adapters
Signed-off-by: Hayes Wang
Cc: Realtek linux nic maintainers
---
drivers/net/usb/Kconfig | 11 +
drivers/net/usb/Makefile|1 +
drivers/net/usb/cdc_ether.c | 10 +
drivers/net/usb/r8152.c | 1751 +++
4 files changed, 1773 insertions(+)
create mode 100644 drivers/net/usb/r8152.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 7c769d8..287cc62 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -93,6 +93,17 @@ config USB_RTL8150
To compile this driver as a module, choose M here: the
module will be called rtl8150.
+config USB_RTL8152
+ tristate "Realtek RTL8152 Based USB 2.0 Ethernet Adapters"
+ select NET_CORE
+ select MII
+ help
+ This option adds support for Realtek RTL8152 based USB 2.0
+ 10/100 Ethernet adapters.
+
+ To compile this driver as a module, choose M here: the
+ module will be called r8152.
+
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
select NET_CORE
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 119b06c..9ab5c9d 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_USB_CATC) += catc.o
obj-$(CONFIG_USB_KAWETH) += kaweth.o
obj-$(CONFIG_USB_PEGASUS) += pegasus.o
obj-$(CONFIG_USB_RTL8150) += rtl8150.o
+obj-$(CONFIG_USB_RTL8152) += r8152.o
obj-$(CONFIG_USB_HSO) += hso.o
obj-$(CONFIG_USB_NET_AX8817X) += asix.o
asix-y := asix_devices.o asix_common.o ax88172a.o
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 4ff71d6..24fbec2 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -479,6 +479,7 @@ static const struct driver_info wwan_info = {
#define NOVATEL_VENDOR_ID 0x1410
#define ZTE_VENDOR_ID 0x19D2
#define DELL_VENDOR_ID 0x413C
+#define REALTEK_VENDOR_ID 0x0bda
static const struct usb_device_id products [] = {
/*
@@ -619,6 +620,15 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* Realtek RTL8152 Based USB 2.0 Ethernet Adapters */
+#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
+{
+ USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+#endif
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
new file mode 100644
index 000..8031c48
--- /dev/null
+++ b/drivers/net/usb/r8152.c
@@ -0,0 +1,1751 @@
+/*
+ * Copyright (c) 2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * 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.
+ *
+ * This product is covered by one or more of the following patents:
+ * US6,570,884, US6,115,776, and US6,327,625.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Version Information */
+#define DRIVER_VERSION "v1.0.0 (2013/04/25)"
+#define DRIVER_AUTHOR "Realtek linux nic maintainers "
+#define DRIVER_DESC "Realtek RTL8152 Based USB 2.0 Ethernet Adapters"
+#define MODULENAME "r8152"
+
+#define PATENTS"This product is covered by one or more of the
" \
+ "following patents:\n" \
+ "\t\tUS6,570,884, US6,115,776, and US6,327,625.\n"
+
+#define R8152_PHY_ID 32
+
+#define PLA_IDR0xc000
+#define PLA_RCR0xc010
+#define PLA_RMS0xc016
+#define PLA_RXFIFO_CTRL0 0xc0a0
+#define PLA_RXFIFO_CTRL1 0xc0a4
+#define PLA_RXFIFO_CTRL2 0xc0a8
+#define PLA_FMC0xc0b4
+#define PLA_CFG_WOL0xc0b6
+#define PLA_MAR0xcd00
+#define PAL_BDC_CR 0xd1a0
+#define PLA_LEDSEL 0xdd90
+#define PLA_LED_FEATURE0xdd92
+#define PLA_PHYAR 0xde00
+#define PLA_GPHY_INTR_IMR 0xe022
+#define PLA_EEE_CR 0xe040
+#define PLA_EEEP_CR0xe080
+#define PLA_MAC_PWR_CTRL 0xe0c0
+#define PLA_TCR0 0xe610
+#define PLA_TCR1 0xe612
+#define PLA_TXFIFO_CTRL0xe618
+#define PLA_RSTTELLY 0xe800
+#define PLA_CR 0xe813
+#define PLA_CRWECR 0xe81c
+#define PLA_CONFIG50xe822
+#define PLA_PHY_PWR0xe84c
+#define PLA_OOB_CTRL 0xe84f
+#define PLA_CPCR 0xe854
+#define PLA_MISC_0 0xe858
+#define PLA_MISC_1 0xe85a
+#define PLA_
Re: [PATCH V2] usb: storage: Convert US_DEBUGP to usb_stor_dbg
On Thu, 25 Apr 2013, Andrew Morton wrote:
> From: Andrew Morton
> Subject: drivers/usb/storage/realtek_cr.c: fix build
>
> Remove unused local `us', which broke the build. Also nuke an unneeded
> cast.
>
> Repairs 191648d03d20 ("usb: storage: Convert US_DEBUGP to usb_stor_dbg").
>
> Cc: Joe Perches
> Cc: David Rientjes
> Cc: Greg KH
> Signed-off-by: Andrew Morton
Acked-by: David Rientjes
Fixes it for me, thanks 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: [PATCH v4 00/11] usb: musb: add back support for host mode
On 10.04.2013 21:55, Daniel Mack wrote:
> Hi all,
>
> here are some patches to separate the HCD and gadget part of the musb
> driver so they can be deselected in Kconfig. They also make the driver
> keep track of the configured port mode that is set from DT, so the
> actual runtime configuration can be selected dynamically.
>
> One thing that is still broken is that once pm_suspend() was called on
> a musb device on a USB disconnect, the port won't wake up again when a
> device is plugged back in. I doubt this is related to my patches, but I
> might be wrong. If that effect rings a bell to anyone, please let me
> know.
Felipe, is there anything you want me to fix up in this version, or can
you queue it up for 3.11?
Thanks,
Daniel
> Changes from v3:
> * removed unnecessary indirection level via struct musb_hdc_link
> * fixed a typo in commit log of patch 10/11
> (all reported by Peter Korsgaard, thanks!)
>
> Changes from v2:
> * simplified Makefile rework
> * really remove musb_to_hcd
> * fixed some types
> (all reported by Peter Korsgaard, thanks!)
>
> Changes from v1:
> * fixed some typos in commit logs
> * factor out musb_host_resume_root_hub and
> musb_host_poke_root_hub()
> * split some changes into separate patches
> * some minor cosmetics fixed
>
> Daniel Mack (11):
> usb: gadget: drop unused USB_GADGET_MUSB_HDRC
> usb: musb: move function declarations to musb_{host,gadget}.h
> usb: musb: factor some host-specific functions
> usb: musb: gadget: remove hcd initialization
> usb: musb: move musb_start to musb_virthub.c
> usb: musb: factor out hcd initalization
> usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
> usb: musb: add musb_host_setup() and musb_host_cleanup()
> usb: musb: re-introduce musb->port_mode
> usb: musb: use musb->port_mode
> usb: musb: eliminate musb_to_hcd
>
> drivers/usb/gadget/Kconfig | 8 ---
> drivers/usb/musb/Kconfig| 29 +
> drivers/usb/musb/Makefile | 4 +-
> drivers/usb/musb/musb_core.c| 127
> +++-
> drivers/usb/musb/musb_core.h| 26 +++-
> drivers/usb/musb/musb_gadget.c | 10
> drivers/usb/musb/musb_gadget.h | 38 ++--
> drivers/usb/musb/musb_host.c| 82 +++---
> drivers/usb/musb/musb_host.h| 57 ++
> drivers/usb/musb/musb_virthub.c | 51 +++-
> drivers/usb/musb/omap2430.c | 2 +-
> 11 files changed, 286 insertions(+), 148 deletions(-)
>
--
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: musb: add back support for host mode
Hi, On Fri, Apr 26, 2013 at 11:26:49AM +0200, Daniel Mack wrote: > On 10.04.2013 21:55, Daniel Mack wrote: > > Hi all, > > > > here are some patches to separate the HCD and gadget part of the musb > > driver so they can be deselected in Kconfig. They also make the driver > > keep track of the configured port mode that is set from DT, so the > > actual runtime configuration can be selected dynamically. > > > > One thing that is still broken is that once pm_suspend() was called on > > a musb device on a USB disconnect, the port won't wake up again when a > > device is plugged back in. I doubt this is related to my patches, but I > > might be wrong. If that effect rings a bell to anyone, please let me > > know. > > Felipe, is there anything you want me to fix up in this version, or can > you queue it up for 3.11? we didn't even open v3.10 merge window yet... wait a few weeks, then I'll queue it -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 00/11] usb: musb: add back support for host mode
On 26.04.2013 11:33, Felipe Balbi wrote: > Hi, > > On Fri, Apr 26, 2013 at 11:26:49AM +0200, Daniel Mack wrote: >> On 10.04.2013 21:55, Daniel Mack wrote: >>> Hi all, >>> >>> here are some patches to separate the HCD and gadget part of the musb >>> driver so they can be deselected in Kconfig. They also make the driver >>> keep track of the configured port mode that is set from DT, so the >>> actual runtime configuration can be selected dynamically. >>> >>> One thing that is still broken is that once pm_suspend() was called on >>> a musb device on a USB disconnect, the port won't wake up again when a >>> device is plugged back in. I doubt this is related to my patches, but I >>> might be wrong. If that effect rings a bell to anyone, please let me >>> know. >> >> Felipe, is there anything you want me to fix up in this version, or can >> you queue it up for 3.11? > > we didn't even open v3.10 merge window yet... wait a few weeks, then > I'll queue it OK, great. Thanks for the update :) Daniel -- 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 0/3] isoc support for gadget zero and usbtest
Please send me the patch file. -- 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 1/3] usb: gadget: add isochronous support to gadget zero
Hello Paul Zimmerman, I am trying to test the USB 3.0 gadget driver for isochronous support. Can you please send me the .patch file for this patch as well as all related patchesrelated to this.If I am not wrong below are all the required patches and please send all of them to my mail ID and any other if i missed to mention [PATCH v3 0/3] isoc support for gadget zero and usbtest [PATCH v3 1/3] usb: gadget: add isochronous support to gadget zero [PATCH v3 2/3] usb: usbtest: two super speed fixes for usbtest [PATCH v3 3/3] usb: usbtest: add super speed isoc support to usbtest [PATCH v3 3/3] usb: usbtest: add super speed isoc support to usbtest Thanks, Raveendra -- 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 net-next] net/usb: new driver for RTL8152
On Friday 26 April 2013 16:45:48 Hayes Wang wrote:
> +static u16 r8152_mdio_read(struct r8152 *tp, u32 reg_addr)
> +{
> + u32 ocp_data;
> + int i;
> +
> + ocp_data = (reg_addr & 0x1f) << 16;
> + ocp_write_dword(tp, MCU_TYPE_PLA, PLA_PHYAR, ocp_data);
> +
> + for (i = 20; i > 0; i--) {
> + udelay(25);
> + ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_PHYAR);
> + if (ocp_data & PHYAR_FLAG)
> + break;
> + }
> + udelay(20);
> +
> + return (u16)(ocp_data & 0x);
> +}
Unfortunately this can fail, as it is physical IO and you throw away errors.
> +static int read_mii_word(struct net_device *netdev, int phy_id, int reg)
> +{
> + struct r8152 *tp = netdev_priv(netdev);
> +
> + if (phy_id != R8152_PHY_ID)
> + return -1;
> +
> + return r8152_mdio_read(tp, reg);
> +}
> +
> +static
> +void write_mii_word(struct net_device *netdev, int phy_id, int reg, int val)
> +{
> + struct r8152 *tp = netdev_priv(netdev);
> +
> + if (phy_id != R8152_PHY_ID)
> + return;
> +
> + r8152_mdio_write(tp, reg, val);
> +}
> +
> +static void ocp_reg_write(struct r8152 *tp, u16 addr, u16 data)
> +{
> + u16 ocp_base, ocp_index;
> +
> + ocp_base = addr & 0xf000;
> + if (ocp_base != tp->ocp_base) {
> + ocp_write_word(tp, MCU_TYPE_PLA, PLA_OCP_GPHY_BASE, ocp_base);
> + tp->ocp_base = ocp_base;
> + }
> +
> + ocp_index = (addr & 0x0fff) | 0xb000;
> + ocp_write_word(tp, MCU_TYPE_PLA, ocp_index, data);
> +}
> +
> +static inline void set_ethernet_addr(struct r8152 *tp)
> +{
> + struct net_device *dev = tp->netdev;
> + u8 node_id[8] = {0};
> +
> + if (pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id) < 0)
DMA coherency rules. No buffers on the stack.
> + netif_notice(tp, probe, dev, "inet addr fail\n");
> + else {
> + memcpy(dev->dev_addr, node_id, sizeof(node_id));
> + memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
> + }
> +}
> +static void _rtl8152_set_rx_mode(struct net_device *netdev)
> +{
> + struct r8152 *tp = netdev_priv(netdev);
> + u32 tmp, mc_filter[2]; /* Multicast hash filter */
> + u32 ocp_data;
> +
> + clear_bit(RTL8152_SET_RX_MODE, &tp->flags);
> + netif_stop_queue(netdev);
> + ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
> + ocp_data &= ~RCR_ACPT_ALL;
> + ocp_data |= RCR_AB | RCR_APM;
> +
> + if (netdev->flags & IFF_PROMISC) {
> + /* Unconditionally log net taps. */
> + netif_notice(tp, link, netdev, "Promiscuous mode enabled\n");
> + ocp_data |= RCR_AM | RCR_AAP;
> + mc_filter[1] = mc_filter[0] = 0x;
> + } else if ((netdev_mc_count(netdev) > multicast_filter_limit) ||
> +(netdev->flags & IFF_ALLMULTI)) {
> + /* Too many to filter perfectly -- accept all multicasts. */
> + ocp_data |= RCR_AM;
> + mc_filter[1] = mc_filter[0] = 0x;
> + } else {
> + struct netdev_hw_addr *ha;
> +
> + mc_filter[1] = mc_filter[0] = 0;
> + netdev_for_each_mc_addr(ha, netdev) {
> + int bit_nr = ether_crc(ETH_ALEN, ha->addr) >> 26;
> + mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
> + ocp_data |= RCR_AM;
> + }
> + }
> +
> + tmp = mc_filter[0];
> + mc_filter[0] = __cpu_to_le32(swab32(mc_filter[1]));
> + mc_filter[1] = __cpu_to_le32(swab32(tmp));
> +
> + pla_ocp_write(tp, PLA_MAR, BYTE_EN_DWORD, sizeof(mc_filter), mc_filter);
This looks like a violation of the DMA coherency rules.
You cannot use buffers on the stack.
> + ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
> + netif_wake_queue(netdev);
> +}
> +
> +static void rtl_work_func_t(struct work_struct *work)
> +{
> + struct r8152 *tp = container_of(work, struct r8152, schedule.work);
> +
> + if (!netif_running(tp->netdev))
> + goto out1;
> +
> + if (test_bit(RTL8152_UNPLUG, &tp->flags))
> + goto out1;
> +
> + set_carrier(tp);
> +
> + if (test_bit(RTL8152_SET_RX_MODE, &tp->flags))
> + _rtl8152_set_rx_mode(tp->netdev);
> +
> + schedule_delayed_work(&tp->schedule, HZ);
Why does this need to run permanently?
> +
> +out1:
> + return;
> +}
> +
> +static int rtl8152_open(struct net_device *netdev)
> +{
> + struct r8152 *tp = netdev_priv(netdev);
> + int res = 0;
> +
> + tp->speed = rtl8152_get_speed(tp);
> + if (tp->speed & LINK_STATUS) {
> + res = rtl8152_enable(tp);
> + netif_carrier_on(netdev);
And you leave it on in the error case?
> + } else {
> + netif_stop_queue(netdev);
> + netif_carrier_off(netdev);
> + }
> +
> + if (res) {
> + if (res == -ENODEV)
> + ne
Re: [PATCH] usb: chipidea: ci13xxx_imx: Use dev_dbg for pinctrl message
On Wed, Apr 24, 2013 at 02:19:19PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Currently we always get the following message during boot: > > imx_usb 8008.usb: pinctrl get/select failed, err=-19 > > ,which is not very useful during standard usage. > > Move it to dev_dbg. Is it a real problem when devm_pinctrl_get_select_default fails? What would be needed to make the call succeed? Best regards Uwe > > Signed-off-by: Fabio Estevam > --- > drivers/usb/chipidea/ci13xxx_imx.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/chipidea/ci13xxx_imx.c > b/drivers/usb/chipidea/ci13xxx_imx.c > index 8faec9d..9d6afab 100644 > --- a/drivers/usb/chipidea/ci13xxx_imx.c > +++ b/drivers/usb/chipidea/ci13xxx_imx.c > @@ -124,7 +124,7 @@ static int ci13xxx_imx_probe(struct platform_device *pdev) > > pinctrl = devm_pinctrl_get_select_default(&pdev->dev); > if (IS_ERR(pinctrl)) > - dev_warn(&pdev->dev, "pinctrl get/select failed, err=%ld\n", > + dev_dbg(&pdev->dev, "pinctrl get/select failed, err=%ld\n", > PTR_ERR(pinctrl)); > > data->clk = devm_clk_get(&pdev->dev, NULL); > -- > 1.7.9.5 > > -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: chipidea: ci13xxx_imx: Use dev_dbg for pinctrl message
Uwe Kleine-König writes: > On Wed, Apr 24, 2013 at 02:19:19PM -0300, Fabio Estevam wrote: >> From: Fabio Estevam >> >> Currently we always get the following message during boot: >> >> imx_usb 8008.usb: pinctrl get/select failed, err=-19 >> >> ,which is not very useful during standard usage. >> >> Move it to dev_dbg. > Is it a real problem when devm_pinctrl_get_select_default fails? What > would be needed to make the call succeed? In author's words, some controllers don't need it, so it's ok if it fails. Printing warning in that case is not a good idea, so I agree with Fabio. I'll apply it soon unless I hear from people involved with chipidea on imx. Next thing we need to agree on if this bit belongs to platform or core, which is not obvious, and the patch that introduced this code doesn't clarify why exactly this is needed. Cc'ing the chipidea crowd (hey, anyone wants to set up a mail alias? :)) in case they have something to say on the topic. Regards, -- Alex -- 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: chipidea: ci13xxx_imx: Use dev_dbg for pinctrl message
On Fri, Apr 26, 2013 at 03:36:42PM +0300, Alexander Shishkin wrote: > Uwe Kleine-König writes: > > > On Wed, Apr 24, 2013 at 02:19:19PM -0300, Fabio Estevam wrote: > >> From: Fabio Estevam > >> > >> Currently we always get the following message during boot: > >> > >> imx_usb 8008.usb: pinctrl get/select failed, err=-19 > >> > >> ,which is not very useful during standard usage. > >> > >> Move it to dev_dbg. > > Is it a real problem when devm_pinctrl_get_select_default fails? What > > would be needed to make the call succeed? > > In author's words, some controllers don't need it, so it's ok if it > fails. Printing warning in that case is not a good idea, so I agree with > Fabio. I'll apply it soon unless I hear from people involved with > chipidea on imx. Next thing we need to agree on if this bit belongs to > platform or core, which is not obvious, and the patch that introduced > this code doesn't clarify why exactly this is needed. I suggest to improve the commit log to include your explanation. I wonder that it fails on imx because I thought pinctrl is up and running there? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
3.9-rc7 suspend failure
Ccing Dave Jiang. Dave, can you please take a look at this resume from suspend failure? Tony bisected it to one of your patches. On Thu, Apr 25, 2013 at 11:43:00PM -0400, Tony Camuso wrote: > On 04/23/2013 05:14 PM, Sarah Sharp wrote: > >On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote: > >>It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8. > >>Neither the new patch nor the old patch helps. > > > >It might be unrelated to USB then. Let's see what the bisect shows. > > > > It does appear to be unrelated to usb. Now we need to determine why > this should cause problems with suspend/resume. > > - > # git bisect bad > 4dec23d7718e6f1f5e1773698d112025169e7d49 is the first bad commit > commit 4dec23d7718e6f1f5e1773698d112025169e7d49 > Author: Dave Jiang > Date: Thu Feb 7 14:38:32 2013 -0700 > > ioatdma: fix race between updating ioat->head and IOAT_COMPLETION_PENDING > There is a race that can hit during __cleanup() when the ioat->head > pointer is > incremented during descriptor submission. The __cleanup() can clear the > PENDING flag when it does not see any active descriptors. This causes new > submitted descriptors to be ignored because the COMPLETION_PENDING flag is > cleared. This was introduced when code was adapted from ioatdma v1 to > ioatdma > v2. For v2 and v3, IOAT_COMPLETION_PENDING flag will be abandoned and a > new > flag IOAT_CHAN_ACTIVE will be utilized. This flag will also be protected > under > the prep_lock when being modified in order to avoid the race. > Signed-off-by: Dave Jiang > Reviewed-by: Dan Williams > Signed-off-by: Vinod Koul > > :04 04 6a99537c215da68179b7431d165c4aa88c2f569d > b339a473063ad04cd985399e43e2e11c9a2a7026 Mdrivers > - > > > Here is a Call Trace when resuming from suspend with the above patch. > > - > [ 96.324588] ioatdma :40:04.0: ioat2_timer_event: Channel halted (1000) > [ 96.324659] [ cut here ] > [ 96.324661] kernel BUG at drivers/dma/ioat/dma_v2.c:317! > [ 96.324665] invalid opcode: [#1] SMP > [ 96.324709] Modules linked in: ipt_MASQUERADE nf_conntrack_netbios_ns > nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 > nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle > nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter > ebtables ip6table_filter ip6_tables kvm_intel snd_hda_codec_hdmi coretemp > snd_hda_codec_realtek kvm snd_hda_intel snd_hda_codec snd_hwdep snd_seq > snd_seq_device snd_pcm snd_page_alloc snd_timer snd hp_wmi crc32c_intel > sb_edac ioatdma sparse_keymap iTCO_wdt soundcore edac_core > ghash_clmulni_intel rfkill e1000e iTCO_vendor_support mei microcode i2c_i801 > lpc_ich pcspkr serio_raw dca mfd_core nouveau isci video mxm_wmi i2c_algo_bit > drm_kms_helper ttm libsas drm mpt2sas firewire_ohci firewire_core ata_generic > raid_class scsi_transport_sas i2c_core pata_acpi crc_itu_t wmi > [ 96.324718] CPU 0 > [ 96.324718] Pid: 0, comm: swapper/0 Not tainted 3.8.0-rc2+ #10 > Hewlett-Packard HP Z820 Workstation/158B > [ 96.324731] RIP: 0010:[] [] > ioat2_timer_event+0x1b6/0x2c0 [ioatdma] > [ 96.324733] RSP: 0018:8801a9c03df0 EFLAGS: 00010206 > [ 96.324734] RAX: 0023 RBX: 8801a6880228 RCX: > 00ae > [ 96.324735] RDX: RSI: 0086 RDI: > 0246 > [ 96.324737] RBP: 8801a9c03e20 R08: 81e4b4e0 R09: > 81e7faf0 > [ 96.324738] R10: ba64 R11: 0004 R12: > 1000 > [ 96.324740] R13: 0100 R14: a02752b0 R15: > 8801a6880228 > [ 96.324742] FS: () GS:8801a9c0() > knlGS: > [ 96.324744] CS: 0010 DS: ES: CR0: 80050033 > [ 96.324745] CR2: 7f8ce419 CR3: 01c0c000 CR4: > 000407f0 > [ 96.324747] DR0: DR1: DR2: > > [ 96.324748] DR3: DR6: 0ff0 DR7: > 0400 > [ 96.324751] Process swapper/0 (pid: 0, threadinfo 81c0, task > 81c14440) > [ 96.324751] Stack: > [ 96.324758] 00019e050740 00019e050740 81e8c500 > 8801a6880290 > [ 96.324763] 0100 a02752b0 8801a9c03e60 > 8106cb9a > [ 96.324768] 8103d3d4 81e8c500 8801a6880290 > a02752b0 > [ 96.324769] Call Trace: > [ 96.324774] > [ 96.324780] [] ? reshape_ring+0x330/0x330 [ioatdma] > [ 96.324788] [] call_timer_fn+0x3a/0x120 > [ 96.324794] [] ? native_apic_msr_eoi_write+0x14/0x20 > [ 96.324801] [] ? reshape_ring+0x330/
Re: 3.9-rc7 suspend failure
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote: It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8. That should say, "It hangs in resume-from-suspend...". -- 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 Fri, 26 Apr 2013, victor yeo wrote:
> Please see the attached kagen2_ep_queue(). As long as it is called, it
> will queue the request and read packets from hardware, in the same
> if-else branch for bulk out endpoint. The interrupt handler will NOT
> accept packet if request is NOT queued. If request is queued,
> interrupt handler will accept the packet.
This code is wrong. See what happens when a request for ep1-out is
submitted:
> /* ep1 OUT endpoint */
> else if (in == 0)
> {
> // read from EP1 OUT buffer
> if (num == 1)
> {
> unsigned int val;
> unsigned int val_arr[8];
> int i;
>
> // get byte count from hardware
> val = readl(dev->base_addr + 0x008);
> len = val & 0xFF;
Why do you expect there to be any data in the hardware FIFO at this
point? You said that the hardware will not accept any data if a
request is not queued. Well, before this point the request wasn't
queued, so there shouldn't be any data.
>
> // read from hardware fifo1 data
> for (i = 0; i < len/4; i++)
> {
> val_arr[i] = readl(dev->base_addr + 0x084);
> }
val_arr is declared as an array of 8 unsigned ints. That means its
total size is 32 bytes. What happens if len > 32? You will end up
overwriting part of the stack.
> list_add_tail(&ka_req->queue, &ka_ep->queue);
>
> ka_req->req.actual = len;
> memcpy(ka_req->req.buf, &val_arr[0], len);
>
> ka_req->req.complete(&ka_ep->ep, &ka_req->req);
You should not call req.complete until the request really is complete.
For example, what happens here if the host hasn't sent any packets yet?
Or what happens if req is waiting to receive 1024 bytes but the host
has sent only 512 bytes so far?
Also, all the data gets copied _twice_: once from the hardware FIFO
into val_arr, and then again from val_arr into req.buf. That's a waste
of time; the data should be copied directly from the FIFO into req.buf.
> list_del_init(&ka_req->queue);
>
> // clear hardware OUT1CS register
> val = readl(dev->base_addr + 0x008);
> val &= 0x00ff;
> writel(val, dev->base_addr + 0x008);
Does this really clear the register? It looks like the low-order 8
bits (which got read into "len" earlier) remain unchanged.
> }
> }
There probably are many other problems like these which need to be
fixed.
> Somehow, there is still timing problem in UDC driver and it is hard to
> pin down the root cause. It could be due to interaction of UDC driver
> queue() and gadget driver fsg_main_thread() main loop.
>
> 1) When writing to gen2 gadget, SCSI_READ_10 or or SCSI_REQUEST_SENSE
> commands are received by UDC driver, but gadget did not process the
> commands. (cannot get past get_next_command() in fsg_main_thread)
Then add printk statements inside get_next_command() so you can see
exactly where it's getting stuck.
> 2) Repeatedly (many many times), the same SCSI_READ_10 command is
> received by UDC driver, processed by gadget driver, and UDC driver
> sends out data and CSW to host. On usbmon trace, only one instance of
> the SCSI_READ_10 is observed.
This is probably because you are copying the same data from the FIFO to
req.buffer many times.
> 3) More severe case, if removing one printk statement in
> bulk_in_complete(), USB gadget device cannot be recognised by host.
I think there must still be many bugs remaining in the UDC driver.
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: 3.9-rc7 suspend failure
I have a feeling it's something else and the patch maybe have exposed it. A channel error occured and bit 12 is Completion Address Error. IOATDMA driver has no suspend/resume support. So what happens to the driver when a suspend and then resume happens? Is it possible that the DMA mapped completion address no longer exists after resume? What platform did this happen on? On 04/26/2013 09:27 AM, Sarah Sharp wrote: Ccing Dave Jiang. Dave, can you please take a look at this resume from suspend failure? Tony bisected it to one of your patches. On Thu, Apr 25, 2013 at 11:43:00PM -0400, Tony Camuso wrote: On 04/23/2013 05:14 PM, Sarah Sharp wrote: On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote: It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8. Neither the new patch nor the old patch helps. It might be unrelated to USB then. Let's see what the bisect shows. It does appear to be unrelated to usb. Now we need to determine why this should cause problems with suspend/resume. - # git bisect bad 4dec23d7718e6f1f5e1773698d112025169e7d49 is the first bad commit commit 4dec23d7718e6f1f5e1773698d112025169e7d49 Author: Dave Jiang Date: Thu Feb 7 14:38:32 2013 -0700 ioatdma: fix race between updating ioat->head and IOAT_COMPLETION_PENDING There is a race that can hit during __cleanup() when the ioat->head pointer is incremented during descriptor submission. The __cleanup() can clear the PENDING flag when it does not see any active descriptors. This causes new submitted descriptors to be ignored because the COMPLETION_PENDING flag is cleared. This was introduced when code was adapted from ioatdma v1 to ioatdma v2. For v2 and v3, IOAT_COMPLETION_PENDING flag will be abandoned and a new flag IOAT_CHAN_ACTIVE will be utilized. This flag will also be protected under the prep_lock when being modified in order to avoid the race. Signed-off-by: Dave Jiang Reviewed-by: Dan Williams Signed-off-by: Vinod Koul :04 04 6a99537c215da68179b7431d165c4aa88c2f569d b339a473063ad04cd985399e43e2e11c9a2a7026 M drivers - Here is a Call Trace when resuming from suspend with the above patch. - [ 96.324588] ioatdma :40:04.0: ioat2_timer_event: Channel halted (1000) [ 96.324659] [ cut here ] [ 96.324661] kernel BUG at drivers/dma/ioat/dma_v2.c:317! [ 96.324665] invalid opcode: [#1] SMP [ 96.324709] Modules linked in: ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables kvm_intel snd_hda_codec_hdmi coretemp snd_hda_codec_realtek kvm snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd hp_wmi crc32c_intel sb_edac ioatdma sparse_keymap iTCO_wdt soundcore edac_core ghash_clmulni_intel rfkill e1000e iTCO_vendor_support mei microcode i2c_i801 lpc_ich pcspkr serio_raw dca mfd_core nouveau isci video mxm_wmi i2c_algo_bit drm_kms_helper ttm libsas drm mpt2sas firewire_ohci firewire_core ata_generic raid_class scsi_transport_sas i2c_core pata_acpi crc_itu_t wmi [ 96.324718] CPU 0 [ 96.324718] Pid: 0, comm: swapper/0 Not tainted 3.8.0-rc2+ #10 Hewlett-Packard HP Z820 Workstation/158B [ 96.324731] RIP: 0010:[] [] ioat2_timer_event+0x1b6/0x2c0 [ioatdma] [ 96.324733] RSP: 0018:8801a9c03df0 EFLAGS: 00010206 [ 96.324734] RAX: 0023 RBX: 8801a6880228 RCX: 00ae [ 96.324735] RDX: RSI: 0086 RDI: 0246 [ 96.324737] RBP: 8801a9c03e20 R08: 81e4b4e0 R09: 81e7faf0 [ 96.324738] R10: ba64 R11: 0004 R12: 1000 [ 96.324740] R13: 0100 R14: a02752b0 R15: 8801a6880228 [ 96.324742] FS: () GS:8801a9c0() knlGS: [ 96.324744] CS: 0010 DS: ES: CR0: 80050033 [ 96.324745] CR2: 7f8ce419 CR3: 01c0c000 CR4: 000407f0 [ 96.324747] DR0: DR1: DR2: [ 96.324748] DR3: DR6: 0ff0 DR7: 0400 [ 96.324751] Process swapper/0 (pid: 0, threadinfo 81c0, task 81c14440) [ 96.324751] Stack: [ 96.324758] 00019e050740 00019e050740 81e8c500 8801a6880290 [ 96.324763] 0100 a02752b0 8801a9c03e60 8106cb9a [ 96.324768] 8103d3d4 81e8c500 8801a6880290 a02752b0 [ 96.324769]
Re: [PATCH 1/1] driver,usb: Fix a warning in uhci-hcd driver
On Fri, 26 Apr 2013, ZhenHua wrote: > There is a function wait_for_HP() in uhci-hub.c. In this > patch, it is used in suspend_rh(), I think this can be a > solution. And I have tested this patch, it can fix the bug. > > I think there is another patch needed. As Alan said in another > mail, in the UHCI_RH_RUNNING_NODEVS case, it should not be stopped > if the uhci device is HP iLo virtual usb. I believe that if you change the UHCI_RH_RUNNING_NODEVS case, you will find that this patch (calling wait_for_HP) isn't needed. In fact, the patch is so easy that I am including it below. Please test this (without either of your patches) to see if it works. Alan Stern Index: usb-3.9/drivers/usb/host/uhci-hub.c === --- usb-3.9.orig/drivers/usb/host/uhci-hub.c +++ usb-3.9/drivers/usb/host/uhci-hub.c @@ -225,7 +225,8 @@ static int uhci_hub_status_data(struct u /* auto-stop if nothing connected for 1 second */ if (any_ports_active(uhci)) uhci->rh_state = UHCI_RH_RUNNING; - else if (time_after_eq(jiffies, uhci->auto_stop_time)) + else if (time_after_eq(jiffies, uhci->auto_stop_time) && + !uhci->wait_for_hp) suspend_rh(uhci, UHCI_RH_AUTO_STOPPED); break; -- 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: 3.9-rc7 suspend failure
On 04/26/2013 12:47 PM, Dave Jiang wrote: I have a feeling it's something else and the patch maybe have exposed it. A channel error occured and bit 12 is Completion Address Error. IOATDMA driver has no suspend/resume support. So what happens to the driver when a suspend and then resume happens? Is it possible that the DMA mapped completion address no longer exists after resume? What platform did this happen on? Dave, Platform is HP Z820 with Two 8-core Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz and HT enabled. Output of lspci and lsmod available at these links. http://people.redhat.com/tcamuso/xhci-logs/lspci.txt http://people.redhat.com/tcamuso/xhci-logs/lsmod.txt -- 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: 3.9-rc7 suspend failure
On 04/26/2013 10:39 AM, Tony Camuso wrote: On 04/26/2013 12:47 PM, Dave Jiang wrote: I have a feeling it's something else and the patch maybe have exposed it. A channel error occured and bit 12 is Completion Address Error. IOATDMA driver has no suspend/resume support. So what happens to the driver when a suspend and then resume happens? Is it possible that the DMA mapped completion address no longer exists after resume? What platform did this happen on? Dave, Platform is HP Z820 with Two 8-core Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz and HT enabled. Output of lspci and lsmod available at these links. http://people.redhat.com/tcamuso/xhci-logs/lspci.txt http://people.redhat.com/tcamuso/xhci-logs/lsmod.txt Is this S3 state? -- Dave Jiang Application Engineer, Storage Divsion Intel Corp. dave.ji...@intel.com -- 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: 3.9-rc7 suspend failure
On 04/26/2013 01:46 PM, Dave Jiang wrote: On 04/26/2013 10:39 AM, Tony Camuso wrote: Platform is HP Z820 with Two 8-core Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz and HT enabled. Output of lspci and lsmod available at these links. http://people.redhat.com/tcamuso/xhci-logs/lspci.txt http://people.redhat.com/tcamuso/xhci-logs/lsmod.txt Is this S3 state? No, running at 1.2GHz # cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 -- 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: 3.9-rc7 suspend failure
On 04/26/2013 10:53 AM, Tony Camuso wrote: On 04/26/2013 01:46 PM, Dave Jiang wrote: On 04/26/2013 10:39 AM, Tony Camuso wrote: Platform is HP Z820 with Two 8-core Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz and HT enabled. Output of lspci and lsmod available at these links. http://people.redhat.com/tcamuso/xhci-logs/lspci.txt http://people.redhat.com/tcamuso/xhci-logs/lsmod.txt Is this S3 state? No, running at 1.2GHz No I mean are you transitioning to S3 (standby, sleep, or suspend to RAM) state via suspend and then resumed? # cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 -- Dave Jiang Application Engineer, Storage Divsion Intel Corp. dave.ji...@intel.com -- 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: 3.9-rc7 suspend failure
On 04/26/2013 01:53 PM, Dave Jiang wrote: No I mean are you transitioning to S3 (standby, sleep, or suspend to RAM) state via suspend and then resumed? Sorry, I misunderstood the question. The Call Trace occurs near the end of resuming from S3 after executing the following command. # rtcwake --mode=mem --second=60 -- 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: 3.9-rc7 suspend failure
On 04/26/2013 11:05 AM, Tony Camuso wrote: On 04/26/2013 01:53 PM, Dave Jiang wrote: No I mean are you transitioning to S3 (standby, sleep, or suspend to RAM) state via suspend and then resumed? Sorry, I misunderstood the question. The Call Trace occurs near the end of resuming from S3 after executing the following command. # rtcwake --mode=mem --second=60 So looking at Documentation/power/devices.txt, it says the device needs to be quiesced at suspend and re-initialized at resume. ioatdma has none of those support in driver right now. So in the current state I would say it does not support suspend/resume. And I have a feeling it may be in some sort of weird state upon resume. I'll put it on my queue of things to fix, but it probably won't be any time soon. Just curious what is the suspend/resume test for? Not typical usage model for a DP E5 system. AFAICT the race fix patch shouldn't have anything to do with the error you are encountering. It's completely unrelated -- Dave Jiang Application Engineer, Storage Divsion Intel Corp. dave.ji...@intel.com -- 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: 3.9-rc7 suspend failure
On 04/26/2013 11:09 AM, Dave Jiang wrote: On 04/26/2013 11:05 AM, Tony Camuso wrote: On 04/26/2013 01:53 PM, Dave Jiang wrote: No I mean are you transitioning to S3 (standby, sleep, or suspend to RAM) state via suspend and then resumed? Sorry, I misunderstood the question. The Call Trace occurs near the end of resuming from S3 after executing the following command. # rtcwake --mode=mem --second=60 So looking at Documentation/power/devices.txt, it says the device needs to be quiesced at suspend and re-initialized at resume. ioatdma has none of those support in driver right now. So in the current state I would say it does not support suspend/resume. And I have a feeling it may be in some sort of weird state upon resume. I'll put it on my queue of things to fix, but it probably won't be any time soon. Just curious what is the suspend/resume test for? Not typical usage model for a DP E5 system. AFAICT the race fix patch shouldn't have anything to do with the error you are encountering. It's completely unrelated A different question. Is the system utilizing IOATDMA at all at the point of suspend/resume? Any RAID5/6 volumes? Or NET_DMA is on? -- Dave Jiang Application Engineer, Storage Divsion Intel Corp. dave.ji...@intel.com -- 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: 3.9-rc7 suspend failure
On 04/26/2013 02:12 PM, Dave Jiang wrote: On 04/26/2013 11:09 AM, Dave Jiang wrote: A different question. Is the system utilizing IOATDMA at all at the point of suspend/resume? Any RAID5/6 volumes? Or NET_DMA is on? Dave, I just booted with ioatdma blacklisted in /etc/modprobe.d/blacklist.conf With ioatdma no longer loaded, I no longer see the problem with resuming from suspend. Does ioatdma have suspend/resume support? -- 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: 3.9-rc7 suspend failure
On 04/26/2013 11:44 AM, Tony Camuso wrote: On 04/26/2013 02:12 PM, Dave Jiang wrote: On 04/26/2013 11:09 AM, Dave Jiang wrote: A different question. Is the system utilizing IOATDMA at all at the point of suspend/resume? Any RAID5/6 volumes? Or NET_DMA is on? Dave, I just booted with ioatdma blacklisted in /etc/modprobe.d/blacklist.conf With ioatdma no longer loaded, I no longer see the problem with resuming from suspend. Does ioatdma have suspend/resume support? No ioatdma has no suspend/resume or any pm ops support. It'll be on my todo list. I suspect the DMA engine went into an unknown state with the suspend/resume. -- Dave Jiang Application Engineer, Storage Divsion Intel Corp. dave.ji...@intel.com -- 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 for-3.8-rc8] usb, chipidea: fix link error when USB_EHCI_HCD is a module
Fixes link error when USB_EHCI_HCD=m and USB_CHIPIDEA_HOST=y:
drivers/built-in.o: In function `ci_hdrc_host_init':
drivers/usb/chipidea/host.c:104: undefined reference to
`ehci_init_driver'
as a result of commit 09f6ffde2ece ("USB: EHCI: fix build error by making
ChipIdea host a normal EHCI driver").
Cc: sta...@vger.kernel.org [v3.7+]
Signed-off-by: David Rientjes
---
drivers/usb/chipidea/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -20,7 +20,7 @@ config USB_CHIPIDEA_UDC
config USB_CHIPIDEA_HOST
bool "ChipIdea host controller"
depends on USB=y || USB=USB_CHIPIDEA
- depends on USB_EHCI_HCD
+ depends on USB_EHCI_HCD=y
select USB_EHCI_ROOT_HUB_TT
help
Say Y here to enable host controller functionality of the
--
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 for-3.8-rc8] usb, chipidea: fix link error when USB_EHCI_HCD is a module
I think you mean "3.9" in your subject: right?
On Fri, Apr 26, 2013 at 01:25:01PM -0700, David Rientjes wrote:
> Fixes link error when USB_EHCI_HCD=m and USB_CHIPIDEA_HOST=y:
>
> drivers/built-in.o: In function `ci_hdrc_host_init':
> drivers/usb/chipidea/host.c:104: undefined reference to
> `ehci_init_driver'
>
> as a result of commit 09f6ffde2ece ("USB: EHCI: fix build error by making
> ChipIdea host a normal EHCI driver").
>
> Cc: sta...@vger.kernel.org [v3.7+]
> Signed-off-by: David Rientjes
> ---
> drivers/usb/chipidea/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
There have been a ton of chipidea changes recently in linux-next. This
really just looks like you got the configuration wrong, nothing that is
needed at this point in the release cycle, right?
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
Re: [patch for-3.8-rc8] usb, chipidea: fix link error when USB_EHCI_HCD is a module
On Fri, 26 Apr 2013, Greg Kroah-Hartman wrote:
> I think you mean "3.9" in your subject: right?
>
It's your subsystem, if you want to release a kernel with a known-broken
config, that's your call.
> On Fri, Apr 26, 2013 at 01:25:01PM -0700, David Rientjes wrote:
> > Fixes link error when USB_EHCI_HCD=m and USB_CHIPIDEA_HOST=y:
> >
> > drivers/built-in.o: In function `ci_hdrc_host_init':
> > drivers/usb/chipidea/host.c:104: undefined reference to
> > `ehci_init_driver'
> >
> > as a result of commit 09f6ffde2ece ("USB: EHCI: fix build error by making
> > ChipIdea host a normal EHCI driver").
> >
> > Cc: sta...@vger.kernel.org [v3.7+]
> > Signed-off-by: David Rientjes
> > ---
> > drivers/usb/chipidea/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> There have been a ton of chipidea changes recently in linux-next. This
> really just looks like you got the configuration wrong, nothing that is
> needed at this point in the release cycle, right?
>
This happens in both linux-next as well as Linus's tree, and has since
3.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 for-3.8-rc8] usb, chipidea: fix link error when USB_EHCI_HCD is a module
On Fri, Apr 26, 2013 at 02:50:56PM -0700, David Rientjes wrote:
> On Fri, 26 Apr 2013, Greg Kroah-Hartman wrote:
>
> > I think you mean "3.9" in your subject: right?
> >
>
> It's your subsystem, if you want to release a kernel with a known-broken
> config, that's your call.
As you point out, it's been "known broken" since 3.7, no rush now to fix
it, especially so late in the merge window. :)
> > On Fri, Apr 26, 2013 at 01:25:01PM -0700, David Rientjes wrote:
> > > Fixes link error when USB_EHCI_HCD=m and USB_CHIPIDEA_HOST=y:
> > >
> > > drivers/built-in.o: In function `ci_hdrc_host_init':
> > > drivers/usb/chipidea/host.c:104: undefined reference to
> > > `ehci_init_driver'
> > >
> > > as a result of commit 09f6ffde2ece ("USB: EHCI: fix build error by making
> > > ChipIdea host a normal EHCI driver").
> > >
> > > Cc: sta...@vger.kernel.org [v3.7+]
> > > Signed-off-by: David Rientjes
> > > ---
> > > drivers/usb/chipidea/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > There have been a ton of chipidea changes recently in linux-next. This
> > really just looks like you got the configuration wrong, nothing that is
> > needed at this point in the release cycle, right?
> >
>
> This happens in both linux-next as well as Linus's tree, and has since
> 3.7.
The chipidea maintainer has a big update all queued up in my trees for
3.10-rc1, if you could verify that linux-next fixes your problem, I
would appreciate it.
If not, please let us know.
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
Re: [patch for-3.8-rc8] usb, chipidea: fix link error when USB_EHCI_HCD is a module
On Fri, 26 Apr 2013, Greg Kroah-Hartman wrote: > > It's your subsystem, if you want to release a kernel with a known-broken > > config, that's your call. > > As you point out, it's been "known broken" since 3.7, no rush now to fix > it, especially so late in the merge window. :) > It's "known broken" as of today because I've made you aware of it and provided a patch to fix it. I annotated the changelog with sta...@vger.kernel.org since v3.7 since the problem goes back to that time because of the commit quoted in the changelog. The Kconfig allows for the broken config in 3.8-rc8, so I see no risk whatosever in fixing it to prevent specifically that broken combination. But again, it's your subsystem so if you'd like to drop this plainly obvious fix, that's completely your call. > The chipidea maintainer has a big update all queued up in my trees for > 3.10-rc1, if you could verify that linux-next fixes your problem, I > would appreciate it. > As stated, linux-next as of today has this problem. If you have a public git tree with patches that touch this area that are not pushed to linux-next, please send me the location and I'll try the combination stated in the changelog. (You could do that, as well, if you want.) -- 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 1/1] driver,usb: Fix a warning in uhci-hcd driver
On 04/27/2013 12:51 AM, Alan Stern wrote: On Fri, 26 Apr 2013, ZhenHua wrote: There is a function wait_for_HP() in uhci-hub.c. In this patch, it is used in suspend_rh(), I think this can be a solution. And I have tested this patch, it can fix the bug. I think there is another patch needed. As Alan said in another mail, in the UHCI_RH_RUNNING_NODEVS case, it should not be stopped if the uhci device is HP iLo virtual usb. I believe that if you change the UHCI_RH_RUNNING_NODEVS case, you will find that this patch (calling wait_for_HP) isn't needed. In fact, the patch is so easy that I am including it below. Please test this (without either of your patches) to see if it works. Alan Stern Index: usb-3.9/drivers/usb/host/uhci-hub.c === --- usb-3.9.orig/drivers/usb/host/uhci-hub.c +++ usb-3.9/drivers/usb/host/uhci-hub.c @@ -225,7 +225,8 @@ static int uhci_hub_status_data(struct u /* auto-stop if nothing connected for 1 second */ if (any_ports_active(uhci)) uhci->rh_state = UHCI_RH_RUNNING; - else if (time_after_eq(jiffies, uhci->auto_stop_time)) + else if (time_after_eq(jiffies, uhci->auto_stop_time) && + !uhci->wait_for_hp) suspend_rh(uhci, UHCI_RH_AUTO_STOPPED); break; I have tested the UHCI_RH_RUNNING_NODEVS case yeasterday, and it works. But the function suspend_rh is also called in other places, so I think it only fixes the warning when auto stop is called, but not fix the warning when uhci's bus_suspend is called, it will come out again. And if you add uhci->wait_for_hp check in the UHCI_RH_RUNNING_NODEVS case, all hp uhci devices will not auto stop, not only the virtual devices. I guess it may waste resource. Thanks Zhen-Hua -- 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: chipidea: ci13xxx_imx: Use dev_dbg for pinctrl message
On Fri, Apr 26, 2013 at 02:50:42PM +0200, Uwe Kleine-König wrote: > On Fri, Apr 26, 2013 at 03:36:42PM +0300, Alexander Shishkin wrote: > > Uwe Kleine-König writes: > > > > > On Wed, Apr 24, 2013 at 02:19:19PM -0300, Fabio Estevam wrote: > > >> From: Fabio Estevam > > >> > > >> Currently we always get the following message during boot: > > >> > > >> imx_usb 8008.usb: pinctrl get/select failed, err=-19 > > >> > > >> ,which is not very useful during standard usage. > > >> > > >> Move it to dev_dbg. > > > Is it a real problem when devm_pinctrl_get_select_default fails? What > > > would be needed to make the call succeed? > > > > In author's words, some controllers don't need it, so it's ok if it > > fails. Printing warning in that case is not a good idea, so I agree with > > Fabio. I'll apply it soon unless I hear from people involved with > > chipidea on imx. Next thing we need to agree on if this bit belongs to > > platform or core, which is not obvious, and the patch that introduced > > this code doesn't clarify why exactly this is needed. > I suggest to improve the commit log to include your explanation. I > wonder that it fails on imx because I thought pinctrl is up and running > there? > This pin is ID pin for OTG controller, some platforms use dedicated ID pin which doesn't need to config pinctrl.(mx53, etc), some platforms can choose ID pin from IOMUXC using pinctrl interface. I suggest that it uses of_match_table to differentiate platforms, and import new function ci_imx_init to cover it. It may not the only different things among i.mx SoC USB controllers. -- Best Regards, Peter Chen -- 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] linux-next:usb-stor:realtek_cr:Fix compile error
From: Wei WANG
To fix the compile error when CONFIG_PM_RUNTIME is not enabled,
move the declaration of us out of CONFIG_REALTEK_AUTOPM macro in rts51x_chip.
drivers/usb/storage/realtek_cr.c: In function 'realtek_cr_destructor':
drivers/usb/storage/realtek_cr.c:942:11: error: 'struct rts51x_chip' has no
member named 'us'
Signed-off-by: Wei WANG
---
drivers/usb/storage/realtek_cr.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/storage/realtek_cr.c b/drivers/usb/storage/realtek_cr.c
index 4797228..64c2b28 100644
--- a/drivers/usb/storage/realtek_cr.c
+++ b/drivers/usb/storage/realtek_cr.c
@@ -105,8 +105,9 @@ struct rts51x_chip {
int status_len;
u32 flag;
-#ifdef CONFIG_REALTEK_AUTOPM
struct us_data *us;
+
+#ifdef CONFIG_REALTEK_AUTOPM
struct timer_list rts51x_suspend_timer;
unsigned long timer_expires;
int pwr_state;
@@ -991,6 +992,7 @@ static int init_realtek_cr(struct us_data *us)
us->extra = chip;
us->extra_destructor = realtek_cr_destructor;
us->max_lun = chip->max_lun = rts51x_get_max_lun(us);
+ chip->us = us;
usb_stor_dbg(us, "chip->max_lun = %d\n", chip->max_lun);
@@ -1013,10 +1015,8 @@ static int init_realtek_cr(struct us_data *us)
SET_AUTO_DELINK(chip);
}
#ifdef CONFIG_REALTEK_AUTOPM
- if (ss_en) {
- chip->us = us;
+ if (ss_en)
realtek_cr_autosuspend_setup(us);
- }
#endif
usb_stor_dbg(us, "chip->flag = 0x%x\n", chip->flag);
--
1.7.11.3
--
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
