Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月13日 04:28, Frank Schäfer wrote: Am 12.12.2012 09:23, schrieb Lan Tianyu: On 2012年12月12日 05:59, Frank Schäfer wrote: Am 11.12.2012 17:48, schrieb Alan Stern: [snip] We really need to know which component is bad: the host controller or the device. It happens with all USB 1.1 devices I have (several mice and a HP Deskjet 960c printer). The same devices do not cause other machines to wake up, so I assume it's the host controller. Good information. Attaching device makes hc work abnormally during entering into s3 since without device it can work, right? Right. The system successfully enters S3 (machine switches off = fan stops, light off etc.) but it resumes immediately. No errors in the log, it looks like this: snip ... [24685.640361] PM: Syncing filesystems ... done. [24686.022132] PM: Preparing system for mem sleep [24686.110208] Freezing user space processes ... (elapsed 0.01 seconds) done. [24686.123851] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [24686.134818] PM: Entering mem sleep [24686.134840] Suspending console(s) (use no_console_suspend to debug) [24686.135751] sd 1:0:0:0: [sda] Synchronizing SCSI cache [24686.136509] sd 1:0:0:0: [sda] Stopping disk [24686.150741] i8042 kbd 00:0b: wake-up capability enabled by ACPI [24686.150833] i8042 aux 00:0a: wake-up capability disabled by ACPI [24686.150926] parport_pc 00:09: disabled [24686.151029] serial 00:08: disabled [24686.151056] serial 00:08: wake-up capability disabled by ACPI [24686.151219] ACPI handle has no context! [24686.151299] [drm] nouveau :00:0d.0: Disabling display... [24686.151302] [drm] nouveau :00:0d.0: Disabling fbcon... [24686.151311] [drm] nouveau :00:0d.0: Unpinning framebuffer(s)... [24686.151341] [drm] nouveau :00:0d.0: Evicting buffers... [24686.255063] usb 1-5: reset high-speed USB device number 3 using ehci_hcd [24686.346351] [drm] nouveau :00:0d.0: Idling channels... [24686.346668] [drm] nouveau :00:0d.0: Suspending GPU objects... [24686.447591] [drm] nouveau :00:0d.0: And we're gone! [24687.547695] PM: suspend of devices complete after 1412.642 msecs [24687.547853] PM: late suspend of devices complete after 0.153 msecs [24687.548029] forcedeth :00:07.0: wake-up capability enabled by ACPI [24687.559652] ehci_hcd :00:02.1: wake-up capability enabled by ACPI [24687.570602] ohci_hcd :00:02.0: wake-up capability enabled by ACPI [24687.581671] PM: noirq suspend of devices complete after 33.815 msecs [24687.581735] ACPI: Preparing to enter system sleep state S3 [24687.582536] PM: Saving platform NVS memory [24687.582591] Disabling non-boot CPUs ... [24687.583984] smpboot: CPU 1 is now offline [24687.584703] Extended CMOS year: 2000 [24687.584703] ACPI: Low-level resume complete [24687.584703] PM: Restoring platform NVS memory [24687.584703] Extended CMOS year: 2000 [24687.586196] Enabling non-boot CPUs ... [24687.589496] smpboot: Booting Node 0 Processor 1 APIC 0x1 [24687.583795] Initializing CPU#1 [24687.583795] process: Switch to broadcast mode on CPU1 [24687.601153] CPU1 is up [24687.601538] ACPI: Waking up from system sleep state S3 [24687.613683] ohci_hcd :00:02.0: wake-up capability disabled by ACPI [24687.624693] ehci_hcd :00:02.1: wake-up capability disabled by ACPI [24687.624746] pci :00:00.0: Found enabled HT MSI Mapping [24687.635726] pci :00:00.0: Found enabled HT MSI Mapping [24687.657735] pci :00:00.0: Found enabled HT MSI Mapping [24687.668730] pci :00:00.0: Found enabled HT MSI Mapping [24687.679730] pci :00:00.0: Found enabled HT MSI Mapping [24687.679803] pci :00:00.0: Found enabled HT MSI Mapping [24687.679878] pci :00:00.0: Found enabled HT MSI Mapping [24687.679956] pci :00:00.0: Found enabled HT MSI Mapping [24687.773804] PM: noirq resume of devices complete after 171.507 msecs [24687.773907] PM: early resume of devices complete after 0.056 msecs [24687.773980] ohci_hcd :00:02.0: setting latency timer to 64 [24687.774001] ehci_hcd :00:02.1: setting latency timer to 64 [24687.774023] pci :00:04.0: setting latency timer to 64 ... snip When I disconnect all USB 1.1 devices, suspend works fine. I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Oh. That means the device doesn't support wakeup function. Non-wakeupable devices also will cause the issue. Now Confirm this is hcd problem. I write a quirk patch. Can you test? I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. diff --git a/drivers/usb/core/hcd.c
Re: Tegra3 ehci_suspend and ehci_resume
On 12/12/2012 07:34 PM, Alan Stern wrote: Okay. Then how about this: Unplug both the power connector and the slave connector. After the N7 goes into deep sleep, plug the power connector back in but leave the slave unplugged. Then a few seconds later, plug in the slave. This always fails (-71 / SET_ADDRESS). The issues can then only be solved, by unplugging the OTG adapter. In other words, by switching to peripheral mode (and back). Also try doing the same thing, but don't wait for the N7 to go into deep sleep. If this works but the other test doesn't, then clearly the slave is working correctly and the problem lies in the host controller. This works well most of the time. Some issues in a few cases, not sure why. (It is possible to debug over WiFi. But doing so would prevent LP0.) Timur -- 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 v6] usb_8dev: Add support for USB2CAN interface from 8 devices
On 12/11/2012 06:57 PM, Bernd Krumboeck wrote:
Add device driver for USB2CAN interface from 8 devices
(http://www.8devices.com).
changes since v5:
* unlock mutex on error
changes since v4:
* removed FSF address
* renamed struct usb_8dev
* removed unused variable free_slots
* replaced some _to_cpu functions with pointer equivalent
* fix return value for usb_8dev_set_mode
* handle can errors with separate function
* fix overrun error handling
* rewrite error handling for usb_8dev_start_xmit
* fix urb submit in usb_8dev_start
* various small fixes
Signed-off-by: Bernd Krumboeck krumbo...@universalnet.at
Looks quite good, some nitpicks inline.
Marc
---
drivers/net/can/usb/Kconfig|6 +
drivers/net/can/usb/Makefile |1 +
drivers/net/can/usb/usb_8dev.c | 1096
3 files changed, 1103 insertions(+)
create mode 100644 drivers/net/can/usb/usb_8dev.c
diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
index a4e4bee..2162233 100644
--- a/drivers/net/can/usb/Kconfig
+++ b/drivers/net/can/usb/Kconfig
@@ -48,4 +48,10 @@ config CAN_PEAK_USB
This driver supports the PCAN-USB and PCAN-USB Pro adapters
from PEAK-System Technik (http://www.peak-system.com).
+config CAN_8DEV_USB
+ tristate 8 devices USB2CAN interface
+ ---help---
+ This driver supports the USB2CAN interface
+ from 8 devices (http://www.8devices.com).
+
endmenu
diff --git a/drivers/net/can/usb/Makefile b/drivers/net/can/usb/Makefile
index 80a2ee4..becef46 100644
--- a/drivers/net/can/usb/Makefile
+++ b/drivers/net/can/usb/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_CAN_EMS_USB) += ems_usb.o
obj-$(CONFIG_CAN_ESD_USB2) += esd_usb2.o
obj-$(CONFIG_CAN_KVASER_USB) += kvaser_usb.o
obj-$(CONFIG_CAN_PEAK_USB) += peak_usb/
+obj-$(CONFIG_CAN_8DEV_USB) += usb_8dev.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/usb/usb_8dev.c b/drivers/net/can/usb/usb_8dev.c
new file mode 100644
index 000..2b0d848
--- /dev/null
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -0,0 +1,1096 @@
+/*
+ * CAN driver for 8 devices USB2CAN converter
+ *
+ * Copyright (C) 2012 Bernd Krumboeck (krumbo...@universalnet.at)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.
+ *
+ * This driver is inspired by the 3.2.0 version of
drivers/net/can/usb/ems_usb.c
+ * and drivers/net/can/usb/esd_usb2.c
+ *
+ * Many thanks to Gerhard Bertelsmann (i...@gerhard-bertelsmann.de)
+ * for testing and fixing this driver. Also many thanks to 8 devices,
+ * who were very cooperative and answered my questions.
+ */
+
+#include linux/init.h
+#include linux/signal.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/usb.h
+
+#include linux/can.h
+#include linux/can/dev.h
+#include linux/can/error.h
+
+/* driver constants */
+#define MAX_RX_URBS 10
+#define MAX_TX_URBS 10
+#define RX_BUFFER_SIZE 64
+
+/* vendor and product id */
+#define USB_8DEV_VENDOR_ID 0x0483
+#define USB_8DEV_PRODUCT_ID 0x1234
+
+/* endpoints */
+enum usb_8dev_endpoint {
+ USB_8DEV_ENDP_DATA_RX = 1,
+ USB_8DEV_ENDP_DATA_TX,
+ USB_8DEV_ENDP_CMD_RX,
+ USB_8DEV_ENDP_CMD_TX
+};
+
+/* bittiming constants */
+#define USB_8DEV_ABP_CLOCK 3200
+#define USB_8DEV_BAUD_MANUAL 0x09
+#define USB_8DEV_TSEG1_MIN 1
+#define USB_8DEV_TSEG1_MAX 16
+#define USB_8DEV_TSEG2_MIN 1
+#define USB_8DEV_TSEG2_MAX 8
+#define USB_8DEV_SJW_MAX 4
+#define USB_8DEV_BRP_MIN 1
+#define USB_8DEV_BRP_MAX 1024
+#define USB_8DEV_BRP_INC 1
+
+/* setup flags */
+#define USB_8DEV_SILENT 0x01
+#define USB_8DEV_LOOPBACK0x02
+#define USB_8DEV_DISABLE_AUTO_RESTRANS 0x04
+#define USB_8DEV_STATUS_FRAME0x08
+
+/* commands */
+enum usb_8dev_cmd {
+ USB_8DEV_RESET = 1,
+ USB_8DEV_OPEN,
+ USB_8DEV_CLOSE,
+ USB_8DEV_SET_SPEED,
+ USB_8DEV_SET_MASK_FILTER,
+ USB_8DEV_GET_STATUS,
+ USB_8DEV_GET_STATISTICS,
+ USB_8DEV_GET_SERIAL,
+ USB_8DEV_GET_SOFTW_VER,
+ USB_8DEV_GET_HARDW_VER,
+ USB_8DEV_RESET_TIMESTAMP,
+ USB_8DEV_GET_SOFTW_HARDW_VER
+};
+
+#define
Re: [PATCH] usb: gadget: fix switch off blocked in u_serial
Hi, On Wed, Dec 12, 2012 at 10:13:27PM +0100, Linus Walleij wrote: On Tue, Nov 27, 2012 at 3:11 PM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Nov 21, 2012 at 3:33 PM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij linus.wall...@stericsson.com wrote: From: Haipeng YU haipeng...@stericsson.com When a device is switched off by software, gserial_cleanup will be called, and switch off will be blocked in this function because wake_up_interruptible() in gs_close() can not wake_up the wait_event() in gserial_cleanup(), it should be changed to wake_up() to match the wait_event(). Signed-off-by: Haipeng YU haipeng...@stericsson.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- drivers/usb/gadget/u_serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c index f173952..2d074ba 100644 --- a/drivers/usb/gadget/u_serial.c +++ b/drivers/usb/gadget/u_serial.c @@ -887,7 +887,7 @@ static void gs_close(struct tty_struct *tty, struct file *file) pr_debug(gs_close: ttyGS%d (%p,%p) done!\n, port-port_num, tty, file); - wake_up_interruptible(port-port.close_wait); + wake_up(port-port.close_wait); exit: spin_unlock_irq(port-port_lock); } Ping on this, we're trying to figure out if we're doing the right thing here so help... Ping again. This is stopping our systems from shutting down so would really appreciate some advice if this is the way to go. Ping on this again, Felipe do you want us to repost? Soon one month in review... don't worry, they're all in my pending queue. Greg's pull request hasn't yet been merged upstream. One it is, you will start to receive my automated emails. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 00/23] OMAP USB Host cleanup
Hi Samuel Felipe, How can we proceed with this patchset? You can use the below pull request. The following changes since commit 47f46768d3a3866bff7164649dab499bf5d8ed81: Merge branch 'next/soc' into for-next (2012-12-07 16:35:14 -0800) are available in the git repository at: g...@github.com:rogerq/linux.git arm-for-next-usbhost6 It is known to fix the following warnings on arm-soc/for-next [1.608428] WARNING: at drivers/clk/clk.c:512 __clk_enable+0x94/0xa0() [0.608428] Modules linked in: [0.608459] [c001b254] (unwind_backtrace+0x0/0xf0) from [c003fdd4] (warn_slowpath_common+0x4c/0x64) [0.608459] [c003fdd4] (warn_slowpath_common+0x4c/0x64) from [c003fe08] (warn_slowpath_null+0x1c/0x24) [0.608489] [c003fe08] (warn_slowpath_null+0x1c/0x24) from [c03f05d8] (__clk_enable+0x94/0xa0) [0.608489] [c03f05d8] (__clk_enable+0x94/0xa0) from [c03f0604] (clk_enable+0x20/0x3c) [0.608520] [c03f0604] (clk_enable+0x20/0x3c) from [c031f480] (usbhs_runtime_resume+0x68/0xa4) [0.608520] [c031f480] (usbhs_runtime_resume+0x68/0xa4) from [c030c9a0] (pm_generic_runtime_resume+0x2c/0x38) [0.608551] [c030c9a0] (pm_generic_runtime_resume+0x2c/0x38) from [c0310134] (__rpm_callback+0x2c/0x60) [0.608581] [c0310134] (__rpm_callback+0x2c/0x60) from [c0311060] (rpm_resume+0x39c/0x60c) [0.608581] [c0311060] (rpm_resume+0x39c/0x60c) from [c0311538] (__pm_runtime_resume+0x48/0x60) [0.608612] [c0311538] (__pm_runtime_resume+0x48/0x60) from [c04b8260] (usbhs_omap_probe+0x3a8/0x858) [0.608612] [c04b8260] (usbhs_omap_probe+0x3a8/0x858) from [c0309c70] (platform_drv_probe+0x18/0x1c) [0.608642] [c0309c70] (platform_drv_probe+0x18/0x1c) from [c03089f4] (driver_probe_device+0x74/0x218) [0.608642] [c03089f4] (driver_probe_device+0x74/0x218) from [c0308c2c] (__driver_attach+0x94/0x98) [0.608673] [c0308c2c] (__driver_attach+0x94/0x98) from [c0307188] (bus_for_each_dev+0x4c/0x80) [0.608673] [c0307188] (bus_for_each_dev+0x4c/0x80) from [c0308224] (bus_add_driver+0x174/0x240) [0.608703] [c0308224] (bus_add_driver+0x174/0x240) from [c03090f8] (driver_register+0x78/0x14c) [0.608703] [c03090f8] (driver_register+0x78/0x14c) from [c0309e5c] (platform_driver_probe+0x18/0x9c) [0.608734] [c0309e5c] (platform_driver_probe+0x18/0x9c) from [c0008774] (do_one_initcall+0xfc/0x168) [0.608734] [c0008774] (do_one_initcall+0xfc/0x168) from [c04b2014] (kernel_init+0x120/0x2cc) [0.608764] [c04b2014] (kernel_init+0x120/0x2cc) from [c00137f0] (ret_from_fork+0x14/0x24) [0.608764] ---[ end trace f627315b3f056ecc ]--- [0.608795] [ cut here ] [0.608795] WARNING: at drivers/clk/clk.c:471 clk_disable+0x20/0x34() [0.608825] Modules linked in: [0.608825] [c001b254] (unwind_backtrace+0x0/0xf0) from [c003fdd4] (warn_slowpath_common+0x4c/0x64) [0.608856] [c003fdd4] (warn_slowpath_common+0x4c/0x64) from [c003fe08] (warn_slowpath_null+0x1c/0x24) [0.608856] [c003fe08] (warn_slowpath_null+0x1c/0x24) from [c03f0530] (clk_disable+0x20/0x34) [0.608886] [c03f0530] (clk_disable+0x20/0x34) from [c031f500] (usbhs_runtime_suspend+0x44/0xa4) [0.608917] [c031f500] (usbhs_runtime_suspend+0x44/0xa4) from [c030c968] (pm_generic_runtime_suspend+0x2c/0x38) [0.608917] [c030c968] (pm_generic_runtime_suspend+0x2c/0x38) from [c002b120] (_od_runtime_suspend+0xc/0x24) [0.608947] [c002b120] (_od_runtime_suspend+0xc/0x24) from [c0310134] (__rpm_callback+0x2c/0x60) [0.608947] [c0310134] (__rpm_callback+0x2c/0x60) from [c03104a4] (rpm_suspend+0xf4/0x59c) [0.608978] [c03104a4] (rpm_suspend+0xf4/0x59c) from [c03118f8] (__pm_runtime_suspend+0x5c/0x80) [0.609008] [c03118f8] (__pm_runtime_suspend+0x5c/0x80) from [c030cde0] (pm_generic_runtime_idle+0x44/0x50) [0.609008] [c030cde0] (pm_generic_runtime_idle+0x44/0x50) from [c0310134] (__rpm_callback+0x2c/0x60) [0.609039] [c0310134] (__rpm_callback+0x2c/0x60) from [c0310aa8] (rpm_idle+0xf0/0x21c) [0.609039] [c0310aa8] (rpm_idle+0xf0/0x21c) from [c0310ca0] (__pm_runtime_idle+0x5c/0x80) [0.609069] [c0310ca0] (__pm_runtime_idle+0x5c/0x80) from [c04b83c0] (usbhs_omap_probe+0x508/0x858) [0.609069] [c04b83c0] (usbhs_omap_probe+0x508/0x858) from [c0309c70] (platform_drv_probe+0x18/0x1c) [0.609100] [c0309c70] (platform_drv_probe+0x18/0x1c) from [c03089f4] (driver_probe_device+0x74/0x218) [0.609100] [c03089f4] (driver_probe_device+0x74/0x218) from [c0308c2c] (__driver_attach+0x94/0x98) [0.609130] [c0308c2c] (__driver_attach+0x94/0x98) from [c0307188] (bus_for_each_dev+0x4c/0x80) [0.609130] [c0307188] (bus_for_each_dev+0x4c/0x80) from [c0308224] (bus_add_driver+0x174/0x240) [0.609161] [c0308224] (bus_add_driver+0x174/0x240) from [c03090f8] (driver_register+0x78/0x14c) [0.609161] [c03090f8] (driver_register+0x78/0x14c) from [c0309e5c] (platform_driver_probe+0x18/0x9c) [0.609191] [c0309e5c] (platform_driver_probe+0x18/0x9c) from [c0008774]
Re: [PATCH v4 00/23] OMAP USB Host cleanup
Hi, On Thu, Dec 13, 2012 at 12:44:22PM +0200, Roger Quadros wrote: Hi Samuel Felipe, How can we proceed with this patchset? You can use the below pull request. there are patches under arch/arm/ which need Tony's Acked-by, if we get those, then sure, go ahead ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On Wed, Dec 05, 2012 at 04:13:46PM +0200, Roger Quadros wrote:
On 12/05/2012 03:42 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..e5257dc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
-/* for OMAP3 , the clk set paretn fails */
+/* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap-utmi_clk[0],
omap-xclk60mhsp1_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp1_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp1_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[0])) {
ret = clk_set_parent(omap-utmi_clk[0],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp2_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp2_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ret);
Hm, you sometimes put a space before colon in the error message and
sometimes not. Inconsistent. :-)
That was because it fit in 80 characters without the space. I'm not sure
what is more important, fitting in 80 or consistency in the print
message. Maybe i should have removed the spaces everywhere so that it is
consistent as well. :)
I'd say it's the consistency :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On 5 December 2012 19:43, Roger Quadros rog...@ti.com wrote:
On 12/05/2012 03:42 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..e5257dc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata-port_mode[0])) {
-/* for OMAP3 , the clk set paretn fails */
+/* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap-utmi_clk[0],
omap-xclk60mhsp1_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp1_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp1_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[0])) {
ret = clk_set_parent(omap-utmi_clk[0],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp2_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp2_ck set parent failed : %d\n,
+ret);
} else if (is_ehci_tll_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-init_60m_fclk);
if (ret != 0)
-dev_err(dev, init_60m_fclk set parent
-failed error:%d\n, ret);
+dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ret);
Hm, you sometimes put a space before colon in the error message and
sometimes not. Inconsistent. :-)
That was because it fit in 80 characters without the space. I'm not sure
what is more important, fitting in 80 or consistency in the print
message. Maybe i should have removed the spaces everywhere so that it is
consistent as well. :)
prints are one thing where breaking the 80 column rule is acceptable.
Otherwise it fails grep'ing
--
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] usb: dwc3: gadget: don't redefine 'ret'
we have an extra 'ret' variable shadowing a previous
definition. Remove it.
Signed-off-by: Felipe Balbi ba...@ti.com
---
alredy in my branch, will be sent for v3.9 merge window.
drivers/usb/dwc3/gadget.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c9e729a..6c8e461 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1082,8 +1082,6 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
*
*/
if (dep-flags DWC3_EP_PENDING_REQUEST) {
- int ret;
-
/*
* If xfernotready is already elapsed and it is a case
* of isoc transfer, then issue END TRANSFER, so that
--
1.8.1.rc1.5.g7e0651a
--
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] usb: gadget zero: avoid unnecessary reinit of data in f_sourcesink
In the IN case, since the USB request is allocated only when the source/sink function is started and never freed, the USB ept buffer needs to be inited only at the beginning. This change results into a more performant g_zero module, especially when 'pattern=1' is selected. Signed-off-by: Armando Visconti armando.visco...@st.com --- drivers/usb/gadget/f_sourcesink.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/f_sourcesink.c b/drivers/usb/gadget/f_sourcesink.c index 3c126fd..534cf8c 100644 --- a/drivers/usb/gadget/f_sourcesink.c +++ b/drivers/usb/gadget/f_sourcesink.c @@ -536,8 +536,7 @@ static void source_sink_complete(struct usb_ep *ep, struct usb_request *req) check_read_data(ss, req); if (pattern != 2) memset(req-buf, 0x55, req-length); - } else - reinit_write_data(ep, req); + } break; /* this endpoint is normally active while we're configured */ -- 1.7.4.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 0/2] usb: exynos: Fix compatible strings used for device
Using chip specific compatible string as it should be. So fixing this for ehci-s5p, ohci-exynos and dwc3-exynos which till now used a generic 'exynos' in their compatible strings. This goes as per the discussion happened in the thread for [PATCH v2] ARM: Exynos5250: Enabling dwc3-exynos driver available at: http://www.spinics.net/lists/linux-usb/msg74145.html Vivek Gautam (2): usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device usb: dwc3-exynos: Fix compatible strings for the device drivers/usb/dwc3/dwc3-exynos.c |2 +- drivers/usb/host/ehci-s5p.c|2 +- drivers/usb/host/ohci-exynos.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device
Using specific chip in compatible strings. Newer SOCs can claim
device by using older string in the compatible list.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/ehci-s5p.c|2 +-
drivers/usb/host/ohci-exynos.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..f18e6ac 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -266,7 +266,7 @@ static const struct dev_pm_ops s5p_ehci_pm_ops = {
#ifdef CONFIG_OF
static const struct of_device_id exynos_ehci_match[] = {
- { .compatible = samsung,exynos-ehci },
+ { .compatible = samsung,exynos4210-ehci },
{},
};
MODULE_DEVICE_TABLE(of, exynos_ehci_match);
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index aa3b884..77f2017 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -267,7 +267,7 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
#ifdef CONFIG_OF
static const struct of_device_id exynos_ohci_match[] = {
- { .compatible = samsung,exynos-ohci },
+ { .compatible = samsung,exynos4210-ohci },
{},
};
MODULE_DEVICE_TABLE(of, exynos_ohci_match);
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: dwc3-exynos: Fix compatible strings for the device
Using specific chip in compatible strings. Newer SOCs can claim
device by using older string in the compatible list.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index aae5328..9dce99a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -188,7 +188,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id exynos_dwc3_match[] = {
- { .compatible = samsung,exynos-dwc3 },
+ { .compatible = samsung,exynos5250-dwc3 },
{},
};
MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tegra3 ehci_suspend and ehci_resume
On Thu, 13 Dec 2012, Timur wrote: On 12/12/2012 07:34 PM, Alan Stern wrote: Okay. Then how about this: Unplug both the power connector and the slave connector. After the N7 goes into deep sleep, plug the power connector back in but leave the slave unplugged. Then a few seconds later, plug in the slave. This always fails (-71 / SET_ADDRESS). The issues can then only be solved, by unplugging the OTG adapter. In other words, by switching to peripheral mode (and back). Also try doing the same thing, but don't wait for the N7 to go into deep sleep. If this works but the other test doesn't, then clearly the slave is working correctly and the problem lies in the host controller. This works well most of the time. Some issues in a few cases, not sure why. (It is possible to debug over WiFi. But doing so would prevent LP0.) So it seems clear that the problem is the deep sleep implementation in ehci-tegra. That implementation is very non-standard in the 3.7 kernel. To fix it will require assistance from the people responsible for the ehci-tegra driver. I can be of only limited help because I don't have any Tegra hardware and I don't know how it's supposed to work. 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
[GIT PULL] USB fixes for v3.8-rc2
Hi Greg, Here's my first set of fixes for this -rc cycle. Let me know if you want any changes to this pull request. I'm basing it off of Linus' current master as there are no tags yet. If you want to wait until -rc1 is tagged, I can easily rebase. cheers The following changes since commit 6be35c700f742e911ecedd07fcc43d4439922334: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2012-12-12 18:07:07 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.8-rc2 for you to fetch changes up to 2ac788f705e5118dd45204e7a5bc8d5bb6873835: usb: musb: core: print new line in the driver banner again (2012-12-13 12:05:07 +0200) usb: fixes for v3.8-rc2 Here is the first set of fixes for v3.8-rc cycle. There is a build fix for musb's dsps glue layer caused by some header cleanup on the OMAP tree. Marvel's USB drivers got a fix up for clk API usage switching over to clk_prepare() calls. u_serial has a bug fix for a missing wake_up() which would make gs_cleanup() wait forever for gs_close() to finish. A minor bug fix on dwc3's debugfs interface which would make us read wrong addresses when dumping all registers. dummy_hcd learned how to enumerate g_multi. s3c-hsotg now understands that we shouldn't kfree() memory allocated with devm_*. Other than that, there are a bunch of other minor fixes on renesas_usbhs, tcm_usb_gadget and amd5536udc. All patches have been pending on mailing for many weeks and shouldn't cause any problems. Afzal Mohammed (1): usb: musb: dsps: header movement build error fix Anatolij Gustschin (1): USB: fix fsl_otg config dependency Chao Xie (3): usb: gadget: mv_udc: fix the clk APIs usb: host: ehci-mv: fix clk APIs usb: otg: mv_otg: fix the clk APIs Haipeng YU (1): usb: gadget: u_serial: fix switch off blocked Jack Pham (1): usb: dwc3: debugfs: fix regdump offset Kuninori Morimoto (3): usb: renesas_usbhs: gadget: remove usbhsg_uep_init() usb: renesas_usbhs: gadget: usbhsg_ep_disable() care pipe settings usb: renesas_usbhs: mod_host: fixup usbhsh_ureq_free() timing Sebastian Andrzej Siewior (1): usb: gadget: dummy: fix enumeration with g_multi Sergei Shtylyov (1): usb: musb: core: print new line in the driver banner again Tushar Behera (1): usb: gadget: s3c-hsotg: Fix invalid free of devm_ allocated data Wei Yongjun (1): usb: gadget: tcm_usb_gadge: fix to return error or 0 in tcm_usbg_drop_nexus() Xi Wang (1): usb: gadget: amd5536udc: avoid NULL pointer dereference in udc_pci_probe() drivers/usb/dwc3/debugfs.c | 2 +- drivers/usb/gadget/amd5536udc.c| 4 ++-- drivers/usb/gadget/dummy_hcd.c | 9 + drivers/usb/gadget/mv_udc_core.c | 4 ++-- drivers/usb/gadget/s3c-hsotg.c | 5 ++--- drivers/usb/gadget/tcm_usb_gadget.c| 3 ++- drivers/usb/gadget/u_serial.c | 2 +- drivers/usb/host/ehci-mv.c | 4 ++-- drivers/usb/musb/musb_core.c | 5 + drivers/usb/musb/musb_dsps.c | 5 + drivers/usb/otg/Kconfig| 2 +- drivers/usb/otg/mv_otg.c | 4 ++-- drivers/usb/renesas_usbhs/mod_gadget.c | 22 +- drivers/usb/renesas_usbhs/mod_host.c | 3 ++- 14 files changed, 37 insertions(+), 37 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: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 13.12.2012 09:45, schrieb Lan Tianyu: [snip] I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Oh. That means the device doesn't support wakeup function. Non-wakeupable devices also will cause the issue. Now Confirm this is hcd problem. I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). Regards, Frank -- 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: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012, Frank Schäfer wrote: I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). It would be great if we could get in touch with an engineer at ASUS or nVidia who knows the cause of this problem and how to work around it. Tianyu, do you think this would be possible? 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 0/2] usb: exynos: Fix compatible strings used for device
CC: LKML On Thu, Dec 13, 2012 at 8:22 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Using chip specific compatible string as it should be. So fixing this for ehci-s5p, ohci-exynos and dwc3-exynos which till now used a generic 'exynos' in their compatible strings. This goes as per the discussion happened in the thread for [PATCH v2] ARM: Exynos5250: Enabling dwc3-exynos driver available at: http://www.spinics.net/lists/linux-usb/msg74145.html Vivek Gautam (2): usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device usb: dwc3-exynos: Fix compatible strings for the device drivers/usb/dwc3/dwc3-exynos.c |2 +- drivers/usb/host/ehci-s5p.c|2 +- drivers/usb/host/ohci-exynos.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks Regards Vivek -- 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/2] usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device
On Thu, Dec 13, 2012 at 8:22 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
Using specific chip in compatible strings. Newer SOCs can claim
device by using older string in the compatible list.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/ehci-s5p.c|2 +-
drivers/usb/host/ohci-exynos.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..f18e6ac 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -266,7 +266,7 @@ static const struct dev_pm_ops s5p_ehci_pm_ops = {
#ifdef CONFIG_OF
static const struct of_device_id exynos_ehci_match[] = {
- { .compatible = samsung,exynos-ehci },
+ { .compatible = samsung,exynos4210-ehci },
{},
};
MODULE_DEVICE_TABLE(of, exynos_ehci_match);
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index aa3b884..77f2017 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -267,7 +267,7 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
#ifdef CONFIG_OF
static const struct of_device_id exynos_ohci_match[] = {
- { .compatible = samsung,exynos-ohci },
+ { .compatible = samsung,exynos4210-ohci },
{},
};
MODULE_DEVICE_TABLE(of, exynos_ohci_match);
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks Regards
Vivek
--
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 0/2] Enable ehci and ohci devices for exynos5250
Changes from v2: - Changed the compatible string to chip specific(samsung,exynos4210), since ehci-s5p and ohci-exynos are being used from exynso4210 onwards. - Based on changes for drivers available at: http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg23218.html Changes from v1: - Changed the device node names from 'ehci' and 'ohci' to 'usb@1211' and 'usb@1212' as per discussion for the change 'http://www.spinics.net/lists/linux-usb/msg73993.html' - Rebased on for-next branch of linux-samsung. Vivek Gautam (2): ARM: Exynos5250: Enabling ehci-s5p driver ARM: Exynos5250: Enabling ohci-exynos driver .../devicetree/bindings/usb/exynos-usb.txt | 40 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++ arch/arm/boot/dts/exynos5250.dtsi | 12 ++ arch/arm/mach-exynos/include/mach/map.h|2 + arch/arm/mach-exynos/mach-exynos5-dt.c |4 ++ 5 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/usb/exynos-usb.txt | 25
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
arch/arm/boot/dts/exynos5250.dtsi |6
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
5 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
new file mode 100644
index 000..e8bbb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -0,0 +1,25 @@
+Samsung Exynos SoC USB controller
+
+The USB devices interface with USB controllers on Exynos SOCs.
+The device node has following properties.
+
+EHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ehci for USB 2.0
+ EHCI controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Optional properties:
+ - samsung,vbus-gpio: if present, specifies the GPIO that
+ needs to be pulled up for the bus to be powered.
+
+Example:
+
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 711b55f..f990086 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -218,4 +218,8 @@
i2s_2: i2s@12D7 {
status = disabled;
};
+
+ usb@1211 {
+ samsung,vbus-gpio = gpx2 6 1 3 3;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 581e57a..584bb9a 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -299,6 +299,12 @@
rx-dma-channel = pdma0 11; /* preliminary */
};
+ usb@1211 {
+ compatible = samsung,exynos4210-ehci;
+ reg = 0x1211 0x100;
+ interrupts = 0 71 0;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index cbb2852..b2c662f 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -201,6 +201,7 @@
#define EXYNOS4_PA_EHCI0x1258
#define EXYNOS4_PA_OHCI0x1259
#define EXYNOS4_PA_HSPHY 0x125B
+#define EXYNOS5_PA_EHCI0x1211
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART0x1380
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 462e5ac..b3b9af1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -110,6 +110,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
samsung-i2s.1, NULL),
OF_DEV_AUXDATA(samsung,samsung-i2s, 0x12D7,
samsung-i2s.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-ehci, EXYNOS5_PA_EHCI,
+ s5p-ehci, NULL),
{},
};
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] ARM: Exynos5250: Enabling ohci-exynos driver
Adding OHCI device tree node for Exynos5250 along with
the device base address.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
.../devicetree/bindings/usb/exynos-usb.txt | 15 +++
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index e8bbb47..f66fcdd 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -23,3 +23,18 @@ Example:
interrupts = 0 71 0;
samsung,vbus-gpio = gpx2 6 1 3 3;
};
+
+OHCI
+Required properties:
+ - compatible: should be samsung,exynos4210-ohci for USB 2.0
+ OHCI companion controller in host mode.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+ usb@1212 {
+ compatible = samsung,exynos4210-ohci;
+ reg = 0x1212 0x100;
+ interrupts = 0 71 0;
+ };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 584bb9a..75510d1 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -305,6 +305,12 @@
interrupts = 0 71 0;
};
+ usb@1212 {
+ compatible = samsung,exynos4210-ohci;
+ reg = 0x1212 0x100;
+ interrupts = 0 71 0;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index b2c662f..4bf6fd9 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -202,6 +202,7 @@
#define EXYNOS4_PA_OHCI0x1259
#define EXYNOS4_PA_HSPHY 0x125B
#define EXYNOS5_PA_EHCI0x1211
+#define EXYNOS5_PA_OHCI0x1212
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART0x1380
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index b3b9af1..07aa586 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -112,6 +112,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
samsung-i2s.2, NULL),
OF_DEV_AUXDATA(samsung,exynos4210-ehci, EXYNOS5_PA_EHCI,
s5p-ehci, NULL),
+ OF_DEV_AUXDATA(samsung,exynos4210-ohci, EXYNOS5_PA_OHCI,
+ exynos-ohci, NULL),
{},
};
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: Exynos5250: Enabling dwc3-exynos driver
Adding DWC3 device tree node for Exynos5250 along with the
device address and clock support needed for the controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v2:
- Changed the compatible string to chip specific(samsung,exynos5250),
since dwc3-exynos is being used from exynso5250 onwards.
- Based on changes for USB 2.0:
https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-December/024413.html
Changes from v1:
- Changed the device node name from 'dwc3' to 'usb@1200'.
- Added the documentation for device tree bindings for dwc3 controller.
.../devicetree/bindings/usb/exynos-usb.txt | 14 +++
arch/arm/boot/dts/exynos5250.dtsi |6 +
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/clock-exynos5.c | 24
arch/arm/mach-exynos/include/mach/map.h|1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
6 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index f66fcdd..d660410 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,3 +38,17 @@ Example:
reg = 0x1212 0x100;
interrupts = 0 71 0;
};
+
+DWC3
+Required properties:
+ - compatible: should be samsung,exynos5250-dwc3 for USB 3.0 DWC3 controller.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Example:
+ usb@1200 {
+ compatible = samsung,exynos5250-dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 75510d1..001a31b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -299,6 +299,12 @@
rx-dma-channel = pdma0 11; /* preliminary */
};
+ usb@1200 {
+ compatible = samsung,exynos5250-dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 91d5b6f..09f9587 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -426,6 +426,7 @@ config MACH_EXYNOS5_DT
depends on ARCH_EXYNOS5
select ARM_AMBA
select USE_OF
+ select USB_ARCH_HAS_XHCI
help
Machine support for Samsung EXYNOS5 machine with device tree enabled.
Select this if a fdt blob is available for the EXYNOS5 SoC based
board.
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 5c63bc7..f2214a0 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -768,6 +768,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_fsys_ctrl ,
.ctrlbit= (1 18),
}, {
+ .name = usbdrd30,
+ .parent = exynos5_clk_aclk_200.clk,
+ .enable = exynos5_clk_ip_fsys_ctrl,
+ .ctrlbit= (1 19),
+ }, {
.name = usbotg,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 7),
@@ -1121,6 +1126,16 @@ static struct clksrc_sources exynos5_clkset_group = {
.nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
};
+struct clk *exynos5_clkset_usbdrd30_list[] = {
+ [0] = exynos5_clk_mout_mpll.clk,
+ [1] = exynos5_clk_mout_cpll.clk,
+};
+
+struct clksrc_sources exynos5_clkset_usbdrd30 = {
+ .sources= exynos5_clkset_usbdrd30_list,
+ .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
+};
+
/* Possible clock sources for aclk_266_gscl_sub Mux */
static struct clk *clk_src_gscl_266_list[] = {
[0] = clk_ext_xtal_mux,
@@ -1415,6 +1430,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.parent = exynos5_clk_mout_cpll.clk,
},
.reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3 },
+ }, {
+ .clk= {
+ .name = sclk_usbdrd30,
+ .enable = exynos5_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 28),
+ },
+ .sources = exynos5_clkset_usbdrd30,
+ .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 28, .size = 1
},
+ .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 24, .size =
4 },
Re: Fwd: Safely remove option shows with Micro SD Card connected to Linux through an Android phone
On Wed, Dec 12, 2012 at 9:11 PM, Alan Stern st...@rowland.harvard.edu wrote: That's the error code returned by the USB stack when a request is cancelled synchronously. But it is intended for internal kernel use only; it should not appear at the userspace level. Without knowing the details of what the program did, it's hard to tell how that code got there. I am not much aware of the nautilus code. May be people who work on Nautilus will be able to provide this information. Can any nautilus contributor or one who has idea of nautilus code explain this? Having safe to remove and eject are great and fine tuning them will be very useful for users. -- 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: Safely remove option shows with Micro SD Card connected to Linux through an Android phone
On Wed, Dec 12, 2012 at 9:11 PM, Alan Stern st...@rowland.harvard.edu wrote: That's the error code returned by the USB stack when a request is cancelled synchronously. But it is intended for internal kernel use only; it should not appear at the userspace level. Without knowing the details of what the program did, it's hard to tell how that code got there. Makes sense. Seeing the reason having this is really helpful I think. A good information :). Forgot to copy all so sending this reply again. Thanks, PrasannaKumar -- 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: Safely remove option shows with Micro SD Card connected to Linux through an Android phone
On Thu, 13 Dec 2012, prasannatsmkumar wrote: On Wed, Dec 12, 2012 at 2:07 AM, Alan Stern st...@rowland.harvard.edu wrote: STOP UNIT means spin down the disk or eject the disc. Since your phone doesn't have a disk drive or an optical disc, no wonder this step failed. Yes of course it does not have a optical disc or disk drive. But I thought if there is no such thing nautilus should not try to spin down. Linux kernel has nothing to do with this problem though. Right. Bear in mind that nautilus may not have any way of finding out whether the device has removable media, other than requesting for the media to be ejected. But if it doesn't know then failure of the request shouldn't be reported as an error. No, neither option cuts power. The main difference is that safely remove disables the USB connection, so that if the device has an okay to unplug now light, the light will turn on. I have seen lights going off in my pen drive, so naturally as an user I assumed that nautilus request the kernel to cut down the power and kernel did that. After choosing Safely Remove option my device node (/dev/sdb or whatever) still exists? No, it is gone. At least, I think so -- I'm not sure exactly what nautilus does when you select Safely Remove. The kernel's USB stack has a remove interface that is meant for this sort of thing; I've been assuming that this is what nautilus uses. 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: Fwd: Safely remove option shows with Micro SD Card connected to Linux through an Android phone
On Thu, Dec 13, 2012 at 11:40 PM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 13 Dec 2012, prasannatsmkumar wrote: On Wed, Dec 12, 2012 at 2:07 AM, Alan Stern st...@rowland.harvard.edu wrote: STOP UNIT means spin down the disk or eject the disc. Since your phone doesn't have a disk drive or an optical disc, no wonder this step failed. Yes of course it does not have a optical disc or disk drive. But I thought if there is no such thing nautilus should not try to spin down. Linux kernel has nothing to do with this problem though. Right. Bear in mind that nautilus may not have any way of finding out whether the device has removable media, other than requesting for the media to be ejected. But if it doesn't know then failure of the request shouldn't be reported as an error. Is kernel not exposing this information? The other OS shows Eject for the android device and for other pen drive I get a safely remove option - stated this assuming the options in nautilus and the other OS mean the same. Thanks, PrasannaKumar -- 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 v7] usb_8dev: Add support for USB2CAN interface from 8 devices
Add device driver for USB2CAN interface from 8 devices
(http://www.8devices.com).
changes since v6:
* changed some variable types to big endian equivalent
* small cleanups
changes since v5:
* unlock mutex on error
changes since v4:
* removed FSF address
* renamed struct usb_8dev
* removed unused variable free_slots
* replaced some _to_cpu functions with pointer equivalent
* fix return value for usb_8dev_set_mode
* handle can errors with separate function
* fix overrun error handling
* rewrite error handling for usb_8dev_start_xmit
* fix urb submit in usb_8dev_start
* various small fixes
Signed-off-by: Bernd Krumboeck krumbo...@universalnet.at
---
drivers/net/can/usb/Kconfig|6 +
drivers/net/can/usb/Makefile |1 +
drivers/net/can/usb/usb_8dev.c | 1094
3 files changed, 1101 insertions(+)
create mode 100644 drivers/net/can/usb/usb_8dev.c
diff --git a/drivers/net/can/usb/Kconfig b/drivers/net/can/usb/Kconfig
index a4e4bee..2162233 100644
--- a/drivers/net/can/usb/Kconfig
+++ b/drivers/net/can/usb/Kconfig
@@ -48,4 +48,10 @@ config CAN_PEAK_USB
This driver supports the PCAN-USB and PCAN-USB Pro adapters
from PEAK-System Technik (http://www.peak-system.com).
+config CAN_8DEV_USB
+ tristate 8 devices USB2CAN interface
+ ---help---
+ This driver supports the USB2CAN interface
+ from 8 devices (http://www.8devices.com).
+
endmenu
diff --git a/drivers/net/can/usb/Makefile b/drivers/net/can/usb/Makefile
index 80a2ee4..becef46 100644
--- a/drivers/net/can/usb/Makefile
+++ b/drivers/net/can/usb/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_CAN_EMS_USB) += ems_usb.o
obj-$(CONFIG_CAN_ESD_USB2) += esd_usb2.o
obj-$(CONFIG_CAN_KVASER_USB) += kvaser_usb.o
obj-$(CONFIG_CAN_PEAK_USB) += peak_usb/
+obj-$(CONFIG_CAN_8DEV_USB) += usb_8dev.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/usb/usb_8dev.c b/drivers/net/can/usb/usb_8dev.c
new file mode 100644
index 000..d9c681b
--- /dev/null
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -0,0 +1,1094 @@
+/*
+ * CAN driver for 8 devices USB2CAN converter
+ *
+ * Copyright (C) 2012 Bernd Krumboeck (krumbo...@universalnet.at)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.
+ *
+ * This driver is inspired by the 3.2.0 version of
drivers/net/can/usb/ems_usb.c
+ * and drivers/net/can/usb/esd_usb2.c
+ *
+ * Many thanks to Gerhard Bertelsmann (i...@gerhard-bertelsmann.de)
+ * for testing and fixing this driver. Also many thanks to 8 devices,
+ * who were very cooperative and answered my questions.
+ */
+
+#include linux/init.h
+#include linux/signal.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/usb.h
+
+#include linux/can.h
+#include linux/can/dev.h
+#include linux/can/error.h
+
+/* driver constants */
+#define MAX_RX_URBS10
+#define MAX_TX_URBS10
+#define RX_BUFFER_SIZE 64
+
+/* vendor and product id */
+#define USB_8DEV_VENDOR_ID 0x0483
+#define USB_8DEV_PRODUCT_ID0x1234
+
+/* endpoints */
+enum usb_8dev_endpoint {
+ USB_8DEV_ENDP_DATA_RX = 1,
+ USB_8DEV_ENDP_DATA_TX,
+ USB_8DEV_ENDP_CMD_RX,
+ USB_8DEV_ENDP_CMD_TX
+};
+
+/* bittiming constants */
+#define USB_8DEV_ABP_CLOCK 3200
+#define USB_8DEV_BAUD_MANUAL 0x09
+#define USB_8DEV_TSEG1_MIN 1
+#define USB_8DEV_TSEG1_MAX 16
+#define USB_8DEV_TSEG2_MIN 1
+#define USB_8DEV_TSEG2_MAX 8
+#define USB_8DEV_SJW_MAX 4
+#define USB_8DEV_BRP_MIN 1
+#define USB_8DEV_BRP_MAX 1024
+#define USB_8DEV_BRP_INC 1
+
+/* setup flags */
+#define USB_8DEV_SILENT0x01
+#define USB_8DEV_LOOPBACK 0x02
+#define USB_8DEV_DISABLE_AUTO_RESTRANS 0x04
+#define USB_8DEV_STATUS_FRAME 0x08
+
+/* commands */
+enum usb_8dev_cmd {
+ USB_8DEV_RESET = 1,
+ USB_8DEV_OPEN,
+ USB_8DEV_CLOSE,
+ USB_8DEV_SET_SPEED,
+ USB_8DEV_SET_MASK_FILTER,
+ USB_8DEV_GET_STATUS,
+ USB_8DEV_GET_STATISTICS,
+ USB_8DEV_GET_SERIAL,
+ USB_8DEV_GET_SOFTW_VER,
+ USB_8DEV_GET_HARDW_VER,
+ USB_8DEV_RESET_TIMESTAMP,
+ USB_8DEV_GET_SOFTW_HARDW_VER
+};
+
+#define USB_8DEV_CMD_START 0x11
+#define USB_8DEV_CMD_END 0x22
+
+#define
Re: [GIT PULL] USB fixes for v3.8-rc2
On Thu, Dec 13, 2012 at 04:58:36PM +0200, Felipe Balbi wrote: Hi Greg, Here's my first set of fixes for this -rc cycle. Let me know if you want any changes to this pull request. I'm basing it off of Linus' current master as there are no tags yet. If you want to wait until -rc1 is tagged, I can easily rebase. cheers The following changes since commit 6be35c700f742e911ecedd07fcc43d4439922334: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2012-12-12 18:07:07 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.8-rc2 Nice, I'll do this after 3.8-rc1 is out, no problem with it being based on the tree you did it for, I can handle any merge issues myself. 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: [GIT PULL] USB fixes for v3.8-rc2
On Thu, Dec 13, 2012 at 10:50:39AM -0800, Greg KH wrote: On Thu, Dec 13, 2012 at 04:58:36PM +0200, Felipe Balbi wrote: Hi Greg, Here's my first set of fixes for this -rc cycle. Let me know if you want any changes to this pull request. I'm basing it off of Linus' current master as there are no tags yet. If you want to wait until -rc1 is tagged, I can easily rebase. cheers The following changes since commit 6be35c700f742e911ecedd07fcc43d4439922334: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2012-12-12 18:07:07 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.8-rc2 Nice, I'll do this after 3.8-rc1 is out, no problem with it being based on the tree you did it for, I can handle any merge issues myself. ok cool, if you need help with any merge conflicts just let me know ;-) -- balbi signature.asc Description: Digital signature
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012 07:35:55 -0800, Frank Schäfer fschaefer@googlemail.com wrote: I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). These are 4 machines I found reported. I don't know what is the exact PCI ID needed, so I compiled links and information. MACHINE 1: DELL XPS 1340 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=43081 The bug doesn't have system information, but a search on the Internet [1][2] suggest that it's an MCP79 chipset, integrated by Dell itself. [1] http://ubuntuforums.org/showthread.php?t=1927427 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/969755 The lspci for [2] is at: https://launchpadlibrarian.net/99189829/Lspci.txt MACHINE 2 and 3: ASUS P4S8X and P4S8X-MX mainboards Bug: https://bugzilla.kernel.org/show_bug.cgi?id=47991 lspci: https://bugzilla.kernel.org/attachment.cgi?id=81331 Both are mostly unrelated to nVidia, except for the graphics card in one of them. Both have SiS-based chipsets. Enough device information in bug report. MACHINE 4: ASUS 1201N Bug: https://bugs.launchpad.net/linux/+bug/952080 lspci: https://launchpadlibrarian.net/96828581/Lspci.txt Also an nVidia MCP79-based device. All device info in bug report. -- Octavio. -- 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: Unreliable USB3 with NEC uPD720200 and Delock Cardreader
On Wed, Dec 12, 2012 at 10:32:05AM +0800, Huang Ying wrote: Please try the patch attached. With it, USB host controller can be waken up with USB card reader plugging in on my test machine. This patch works for me. When I enable runtime PM for both the root port and the host controller, and I see the xHCI host go into PCI runtime suspend, but there's no longer a message about the power state changing to D3cold. USB device connects while the PCI host is suspended work now, as well as remote wakeup. Tested-by: Sarah Sharp sarah.a.sh...@linux.intel.com Please mark this for stable. Thanks, Sarah Sharp -- 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
Edgeport/416 io_edgeport problem.
Hello, I'm having a problem with a Digi Inside Out Networks Edgeport/416 device. According to the kernel.org file (see exerpt below) this particular model is not listed in the supported products. Is this info still valid? The device is connected to a 32 bit CentOS 6.3 machine running with kernel 2.6.32-279.14.1.el6.i686. When I connect the Edgeport/416, the messages which show up in /var/log/messages don't show any errors (see below). The 16 /dev/ttyUSB character devices are created in /dev. I can see the Edgeport/416 in /proc/bus/devices and in /sys/bus/usb/drivers/io_edgeport. But when I try to access any one of the 16 ports, I always get a timeout followed by a no such device error. If I do this... sudo strace cat /dev/ttyUSB14 ...it always fail with this line : open(/dev/ttyUSB14, O_RDONLY|O_LARGEFILE) = -1 ENODEV (No such device) I tried to contact Digi, but their answer is a bit dull : this driver is supported by the Linux community, we recommend contacting the Linux-USB group to see if they might be familiar with this behavior and a possible patch. Otherwise, a bug report should be filed with them. I'm not quite sure where to go from there? Any help would be very appreciated. Many thanks, David P.S. Below is the output when I connect the unit to the CentOS machine and the contents of the http://www.kernel.org/doc/Documentation/usb/usb-serial.txt file. Dec 12 14:42:40 solo kernel: usb 1-2: new full speed USB device number 2 using ohci_hcd Dec 12 14:42:40 solo kernel: usb 1-2: New USB device found, idVendor=0451, idProduct=2077 Dec 12 14:42:40 solo kernel: usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 Dec 12 14:42:40 solo kernel: usb 1-2: Product: General Purpose USB Hub Dec 12 14:42:40 solo kernel: usb 1-2: configuration #1 chosen from 1 choice Dec 12 14:42:40 solo kernel: hub 1-2:1.0: USB hub found Dec 12 14:42:40 solo kernel: hub 1-2:1.0: 7 ports detected Dec 12 14:42:40 solo kernel: usb 1-2.5: new full speed USB device number 3 using ohci_hcd Dec 12 14:42:40 solo kernel: usb 1-2.5: New USB device found, idVendor=1608, idProduct=0012 Dec 12 14:42:40 solo kernel: usb 1-2.5: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Dec 12 14:42:40 solo kernel: usb 1-2.5: Product: Edgeport/416 Dec 12 14:42:40 solo kernel: usb 1-2.5: Manufacturer: Inside Out Networks Dec 12 14:42:40 solo kernel: usb 1-2.5: SerialNumber: V70430350-0 Dec 12 14:42:40 solo kernel: usb 1-2.5: configuration #1 chosen from 1 choice Dec 12 14:42:40 solo kernel: usbcore: registered new interface driver usbserial Dec 12 14:42:40 solo kernel: USB Serial support registered for generic Dec 12 14:42:40 solo kernel: usb 1-2.6: new full speed USB device number 4 using ohci_hcd Dec 12 14:42:41 solo kernel: usb 1-2.6: New USB device found, idVendor=1608, idProduct=0012 Dec 12 14:42:41 solo kernel: usb 1-2.6: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Dec 12 14:42:41 solo kernel: usb 1-2.6: Product: Edgeport/416 Dec 12 14:42:41 solo kernel: usb 1-2.6: Manufacturer: Inside Out Networks Dec 12 14:42:41 solo kernel: usb 1-2.6: SerialNumber: V70430350-1 Dec 12 14:42:41 solo kernel: usb 1-2.6: configuration #1 chosen from 1 choice Dec 12 14:42:41 solo kernel: usbcore: registered new interface driver usbserial_generic Dec 12 14:42:41 solo kernel: usbserial: USB Serial Driver core Dec 12 14:42:41 solo kernel: USB Serial support registered for Edgeport 2 port adapter Dec 12 14:42:41 solo kernel: USB Serial support registered for Edgeport 4 port adapter Dec 12 14:42:41 solo kernel: USB Serial support registered for Edgeport 8 port adapter Dec 12 14:42:41 solo kernel: USB Serial support registered for EPiC device Dec 12 14:42:41 solo kernel: io_edgeport 1-2.5:1.0: Edgeport 8 port adapter converter detected Dec 12 14:42:41 solo kernel: usb 1-2.5: Inside Out Networks Edgeport/416 detected Dec 12 14:42:41 solo kernel: usb 1-2.5: firmware: requesting edgeport/down.fw Dec 12 14:42:42 solo kernel: usb 1-2.5: firmware: requesting edgeport/boot.fw Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB0 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB1 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB2 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB3 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB4 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB5 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB6 Dec 12 14:42:42 solo kernel: usb 1-2.5: Edgeport 8 port adapter converter now attached to ttyUSB7 Dec 12 14:42:42 solo kernel: io_edgeport 1-2.6:1.0: Edgeport 8 port adapter converter detected Dec 12 14:42:42 solo kernel: usb 1-2.6: Inside Out Networks Edgeport/416 detected Dec 12 14:42:42
Re: [PATCH v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Hi Samuel,
* Roger Quadros rog...@ti.com [121210 02:23]:
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h
for omaps by -rc1 before more drivers start using it again.
That is assuming nobody else is planning on merging this series for
v3.8 presumably. Want to ack this one?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-host.c |4
drivers/mfd/omap-usb-host.c|2 +-
include/linux/platform_data/usb-omap.h |3 +++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..2e44e8a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -508,6 +508,10 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
+
+ if (omap_rev() = OMAP3430_REV_ES2_1)
+ usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index cebfe0a..fe7906b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -384,7 +384,7 @@ static void omap_usbhs_init(struct device *dev)
reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
- if (cpu_is_omap3430() (omap_rev() = OMAP3430_REV_ES2_1)) {
+ if (pdata-single_ulpi_bypass) {
dev_dbg(dev, OMAP3 ES version = ES2.1\n);
if (is_ehci_phy_mode(pdata-port_mode[0]) ||
is_ehci_phy_mode(pdata-port_mode[1]) ||
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..ef65b67 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -59,6 +59,9 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
+
+ /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
+ unsignedsingle_ulpi_bypass:1;
};
/*-*/
--
1.7.4.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 v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Hi Tony, On Thu, Dec 13, 2012 at 01:49:49PM -0800, Tony Lindgren wrote: Hi Samuel, * Roger Quadros rog...@ti.com [121210 02:23]: Instead of using cpu_is_omap..() macros in the device driver we rely on information provided in the platform data. The only information we need is whether the USB Host module has a single ULPI bypass control bit for all ports or individual bypass control bits for each port. OMAP3 REV2.1 and earlier have the former. I'd like to apply this patch as a fix so I can finally nuke plat/cpu.h for omaps by -rc1 before more drivers start using it again. That is assuming nobody else is planning on merging this series for v3.8 presumably. This should go into 3.9, yes. Want to ack this one? Looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.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: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月13日 23:47, Alan Stern wrote: On Thu, 13 Dec 2012, Frank Schäfer wrote: I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? I also wonder if this could be an BIOS / ACPI issue. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). It would be great if we could get in touch with an engineer at ASUS or nVidia who knows the cause of this problem and how to work around it. Tianyu, do you think this would be possible? Hi Alan: I think this is very hard because these board is old and nVidia doesn't produce chipset now. Otherwise, I have no such channel to communicate with ASUS or nVidia engineer. :( Alan Stern -- 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
Re: Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 2012年12月13日 23:35, Frank Schäfer wrote: Am 13.12.2012 09:45, schrieb Lan Tianyu: [snip] I am curious about whether disabling usb device's wakeup rather than usb hc's would make suspend work. Can you do a test? Go to /sys/bus/usb/devices/ and enter the usb 1,1 device directory(normally it will be something like1-1.1.) run echo disabled power/wakeup. Are you sure the file is called 'wakeup' for the devices ? I have no such file in the power directory... Oh. That means the device doesn't support wakeup function. Non-wakeupable devices also will cause the issue. Now Confirm this is hcd problem. I write a quirk patch. Can you test? Yes, that makes it work ! I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy hcd id via lspci -nnvvv? Thanks. I have the MCP61 (rev. A2) with id 10de:03f1. Further NVIDIA OHCI HCD IDs can be found at http://openbenchmarking.org/linux/PCI/0c03. But I'm not sure that we should blacklist them all. Maybe this bug has been fixed in newer chipset revisions / generations ? Where did you get the ID for the MCP79 from ? Is it confirmed that this device still suffers from the same bug ? Yeah. From other reporter. I also wonder if this could be an BIOS / ACPI issue. Just from my opinion, this cause's by OHCI/UHCI. Because if there is no attached device, suspend can work. This shows BIOS/ACPI work correctly. So far, all boards I've seen were form ASUSTeK (Octavio: A8N-VM, me: M2N-VM DH, and I remember having seen the same bug on another M2N board with MCP55 a while ago). Regards, Frank -- 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 1/1]linux-usb: optimize to match rules in USB storage for Huawei dongles.
From: fangxiaozhi huana...@huawei.com
1. Add a new macro define for USB storage match rule.
2. Optimize the match rules with new macro for Huawei USB storage devices,
to avoid to load USB storage driver for the modem interface
with Huawei devices.
3. Add to support new switch command for new Huawei USB dongles.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c2012-12-13
20:53:40.0 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
{
int result;
@@ -104,3 +104,55 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
+
+/* Find the supported Huawei USB dongles */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ idProduct = us-pusb_dev-descriptor.idProduct;
+ if (idesc idesc-bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001)
+ || (idProduct == 0x1003)
+ || (idProduct == 0x1004)
+ || (idProduct = 0x1401 idProduct 0x1501)
+ || (idProduct 0x1504 idProduct = 0x1600)
+ || (idProduct = 0x1c02 idProduct = 0x2202)) {
+ return 1;
+ }
+ }
+ return 0;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ struct bulk_cb_wrap bcbw = {0};
+ bcbw.Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw.Tag = 0;
+ bcbw.DataTransferLength = cpu_to_le32(0);
+ bcbw.Flags = bcbw.Lun = 0;
+ bcbw.Length = sizeof(rewind_cmd);
+ memcpy(bcbw.CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe, bcbw,
+ US_BULK_CS_WRAP_LEN, act_len);
+ US_DEBUGP(transfer actual length=%d, result=%d\n, act_len, result);
+ return result;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+ if (usb_stor_huawei_dongles_pid(us)) {
+ if (us-pusb_dev-descriptor.idProduct = 0x1446)
+ result = usb_stor_huawei_scsi_init(us);
+ else
+ result = usb_stor_huawei_feature_init(us);
+ }
+ return result;
+}
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h
linux-3.7/drivers/usb/storage/initializers.h
--- linux-3.7_bak/drivers/usb/storage/initializers.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.h2012-12-12
11:43:58.0 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
diff -uprN linux-3.7_bak/drivers/usb/storage/unusual_devs.h
linux-3.7/drivers/usb/storage/unusual_devs.h
--- linux-3.7_bak/drivers/usb/storage/unusual_devs.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/unusual_devs.h2012-12-13
20:51:23.0 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100, 0x
/* Reported by fangxiaozhi huana...@huawei.com
* This brings the HUAWEI data card devices into multi-port mode
*/
-UNUSUAL_DEV( 0x12d1, 0x1001, 0x, 0x,
+UNUSUAL_VENDOR_INTF(0x12d1, 0x08, 0x06, 0x50,
HUAWEI MOBILE,
Mass Storage,
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
- 0),
-UNUSUAL_DEV( 0x12d1, 0x1003, 0x, 0x,
- HUAWEI MOBILE,
- Mass Storage,
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
- 0),
-UNUSUAL_DEV( 0x12d1, 0x1004, 0x, 0x,
- HUAWEI MOBILE,
- Mass Storage,
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
- 0),
-UNUSUAL_DEV( 0x12d1, 0x1401, 0x, 0x,
-
RE: Linux USB file storage gadget with new UDC
Hi, Alan Stern st...@rowland.harvard.edu writes: If you read the confidentiality notice, you'll see that it merely says that the contents of the email _may_ be confidential. Also, it warns people who _aren't_ the intended addressees -- but if the message was sent to a public email list then obviously there are no such people. So I don't see any problem. Then I guess you missed this unconditional part?: be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. This means that victor is deliberately violating his company policy by continuing to send emails to a public list, which is the direct action causing disclosure, copying and distribution of the e-mail. You can of course not blame list admins or subscribers here. I still do not see how a patch with such restrictions can be useful to anyone. But I am not the one to decide that... This is wrong, partly because you are quoting out of context and partly because of a grammatical error in the original notice. Here's the text with the context retained: If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. It is clear, from the lack of capitalization of the word be and the fact that the preceding text is only a sentence fragment, that the period following the close- parenthesis was meant to be a comma. Therefore this prohibition applies only to people who are not meant to be reading an open mailing list -- and there are no such people. This means that victor did not violate any policies. Thanks for the analysis. I have talked to the IT guy regarding the confidentiality note. Unfortunately, he cannot understand the spirit of open source and refuses to drop it. victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux USB file storage gadget with new UDC
Hi, # ls /dev/mmc* /dev/mmc0 /dev/mmc2 /dev/mmcblk0p1 /dev/mmc1 /dev/mmcblk0/dev/mmcblk0p2 # mount /dev/mmcblk0 /mnt # ls /mnt/ initramfs.gz # umount /mnt umounting 1 umounting 0 # insmod kagen2_udc.ko # insmod g_file_storage.ko file=/dev/mmcblk0 insmod: can't insert 'g_file_storage.ko': No such device are you registering your udc with the udc class ?? Are you initilizing udc-gadget.dev ? Look at other udc drivers to check if you're udc-missing something. For example look at drivers/usb/dwc3/gadget.c::dwc3_gadget_init() to see how I register the gadget device and how I add the gadget to the list of UDCs. Also look at drivers/usb/dwc3/gadget.c::dwc3_gadget_start() to see how that should be implemented. -- balbi I look at drivers/usb/dwc3/gadget.c and compare to my UDC code. The difference is my UDC probe function is declared in platform driver, and the platform probe function is not called. How could the file storage gadget know it needs to call my UDC code? Is it done by the platform_add_devices(struct platform_device **pdevs, int ndev) which is to add UDC driver to the linux system? Here is my probe function. Somehow, It is not called after insmod. if it's not called it's because you don't have a matching platform_device. For a driver's probe() to be called you need a platform_device with the same name. -- balbi Thanks. The driver's probe() can be called. Now when insmod g_file_storage.ko, it says the file-backed storage gadget failed to start. I have defined the udc_start() function in usb_gadget_ops structure and added the udc_start() function. What else do I need to add? Here is the message at console: # insmod kagen2_udc.ko # insmod g_file_storage.ko file=/dev/mmcblk0 gadget: controller 'kagen2_usb' not recognized gadget: No serial-number string provided! gadget: File-backed Storage Gadget, version: 1 September 2010 gadget: NOTE: This driver is deprecated. Consider using g_mass_storage instead. gadget: Number of LUNs=1 g_file_storage gadget-lun0: ro=0, nofua=0, file: /dev/mmcblk0 g_file_storage kagen2_usb: failed to start File-backed Storage Gadget: -22 insmod: can't insert 'g_file_storage.ko': invalid parameter thanks, victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- 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: Safely remove option shows with Micro SD Card connected to Linux through an Android phone
On Fri, Dec 14, 2012 at 12:49 AM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 13 Dec 2012, prasannatsmkumar wrote: On Thu, Dec 13, 2012 at 11:40 PM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 13 Dec 2012, prasannatsmkumar wrote: On Wed, Dec 12, 2012 at 2:07 AM, Alan Stern st...@rowland.harvard.edu wrote: STOP UNIT means spin down the disk or eject the disc. Since your phone doesn't have a disk drive or an optical disc, no wonder this step failed. Yes of course it does not have a optical disc or disk drive. But I thought if there is no such thing nautilus should not try to spin down. Linux kernel has nothing to do with this problem though. Right. Bear in mind that nautilus may not have any way of finding out whether the device has removable media, other than requesting for the media to be ejected. But if it doesn't know then failure of the request shouldn't be reported as an error. Is kernel not exposing this information? What I wrote earlier was wrong, sorry. No problem :). No, the kernel does not export it. But user programs can get the information directly from the device in exactly the same way that the kernel does, by issuing an INQUIRY command. I will try to file a bug in nautilus project. As I am not in the nautilus mailing list my mails are not getting delivered. The other OS shows Eject for the android device and for other pen drive I get a safely remove option - stated this assuming the options in nautilus and the other OS mean the same. Alan Stern Thanks, PrasannaKumar -- 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/2] usb: tegra: modifying port reset based on instance number
Tegra USB host driver is using port instance number, to handle some of the hardware issues on SOC e.g. reset PORT0 twice etc. As instance number based handling looks ugly, added a new property to USB DT node for this purpose. Modified host driver to make use of the information passed through DT to reset the port second time. Venu Byravarasu (2): arm: tegra: Add new DT property to USB node. usb: host: tegra: Resetting PORT0 based on information received via DT. .../bindings/usb/nvidia,tegra20-ehci.txt |2 ++ arch/arm/boot/dts/tegra20.dtsi |1 + drivers/usb/host/ehci-tegra.c |6 +- 3 files changed, 8 insertions(+), 1 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
[PATCH 1/2] arm: tegra: Add new DT property to USB node.
As Tegra USB host driver is using instance number for resetting
PORT0 twice, adding a new DT property for handling this.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
.../bindings/usb/nvidia,tegra20-ehci.txt |2 ++
arch/arm/boot/dts/tegra20.dtsi |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index e9b005d..443a2b4 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -27,3 +27,5 @@ Optional properties:
registers are accessed through the APB_MISC base address instead of
the USB controller. Since this is a legacy issue it probably does not
warrant a compatible string of its own.
+ - nvidia,needs-double-reset : boolean is to be set for some of the Tegra2
+USB ports, which need reset twice due to hardware issues.
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index b8effa1..3ebbd0c 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -364,6 +364,7 @@
phy_type = utmi;
nvidia,has-legacy-mode;
status = disabled;
+ nvidia,needs-double-reset;
};
usb@c5004000 {
--
1.7.0.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 2/2] usb: host: tegra: Resetting PORT0 based on information received via DT.
Tegra USB host driver is using port instance number,
to handle some of the hardware issues on SOC e.g. reset PORT0
twice etc. As instance number based handling looks ugly,
making use of information passed through DT for achieving this.
Signed-off-by: Venu Byravarasu vbyravar...@nvidia.com
---
drivers/usb/host/ehci-tegra.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index acf1755..55a9cde 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -43,6 +43,7 @@ struct tegra_ehci_hcd {
struct usb_phy *transceiver;
int host_resumed;
int port_resuming;
+ bool needs_double_reset;
enum tegra_usb_phy_port_speed port_speed;
};
@@ -184,7 +185,7 @@ static int tegra_ehci_hub_control(
}
/* For USB1 port we need to issue Port Reset twice internally */
- if (tegra-phy-instance == 0
+ if (tegra-needs_double_reset
(typeReq == SetPortFeature wValue == USB_PORT_FEAT_RESET)) {
spin_unlock_irqrestore(ehci-lock, flags);
return tegra_ehci_internal_port_reset(ehci, status_reg);
@@ -666,6 +667,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
clk_prepare_enable(tegra-emc_clk);
clk_set_rate(tegra-emc_clk, 4);
+ tegra-needs_double_reset = of_property_read_bool(pdev-dev.of_node,
+ nvidia,needs-double-reset);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(pdev-dev, Failed to get I/O memory\n);
--
1.7.0.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: Linux USB file storage gadget with new UDC
Hi, If you read the confidentiality notice, you'll see that it merely says that the contents of the email _may_ be confidential. Also, it warns people who _aren't_ the intended addressees -- but if the message was sent to a public email list then obviously there are no such people. So I don't see any problem. Then I guess you missed this unconditional part?: be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. This means that victor is deliberately violating his company policy by continuing to send emails to a public list, which is the direct action causing disclosure, copying and distribution of the e-mail. You can of course not blame list admins or subscribers here. I still do not see how a patch with such restrictions can be useful to anyone. But I am not the one to decide that... This is wrong, partly because you are quoting out of context and partly because of a grammatical error in the original notice. Here's the text with the context retained: If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. It is clear, from the lack of capitalization of the word be and the fact that the preceding text is only a sentence fragment, that the period following the close- parenthesis was meant to be a comma. Therefore this prohibition applies only to people who are not meant to be reading an open mailing list -- and there are no such people. This means that victor did not violate any policies. Thanks for the analysis. I have talked to the IT guy regarding the confidentiality note. Unfortunately, he cannot understand the spirit of open source and refuses to drop it. Then I for one, and probably others, will not be able to apply any patches you send me with that attached to the bottom of it, sorry. That's the rules I have to work from based on my legal council. Some Linux mailing lists will also just bounce your email, not allowing it through, but it looks like this list will accept it. Ok, I will use gmail to send the patch when it is ready. victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- 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
