RE: [PATCH 3/9] usb/gadget: change sysfs parent device for USB Ethernet
On Wednesday, April 17, 2013 6:46 PM Alan Stern wrote: > On Wed, 17 Apr 2013, Andrzej Pietrasiewicz wrote: > > > The procedure of setting a gadget up with configfs is like this: > > > > 1) create the gadget directory > > 2) create functions directories corresponding to functions to be used > > by the gadget > > 3) create configurations directories > > ... > > > 4) create symbolic links in configurations' directories, pointing to > > appropriate functions' directories > > 5) In the gadget directory echo > UDC > > > > Now, what you suggest is that a net device is registered only at step > > 5) above. But changing a device address is possible only _after_ the > > device is registered. Which is in contradiction with the assumptions > above. > > It doesn't have to be. You don't actually have to change the address when > the attribute is written. In fact, since the network link doesn't exist > at this point, there _is_ no address to change. > > > And in practice you would have a directory structure like this: > > > > . > > . > > . > > ./functions > > ./functions/ncm.usb0 > > ./functions/ncm.usb0/ifname > > ./functions/ncm.usb0/qmult > > ./functions/ncm.usb0/host_addr > > ./functions/ncm.usb0/dev_addr > > . > > . > > . > > > > Where ifname, qmult and host_addr can be written to before the gadget > > is bound, but writing to dev_addr in such a situation would result in > > ENODEV. > > If you still want to persist with this approach, you can do it in a way > that doesn't require the network interface to be registered before the > gadget is bound. > > Simply store the strings written to host_addr and dev_addr. Don't try to > do anything with them -- in particular, don't try to change the addresses > associated with a nonexistent network interface. Then later on, when the > gadget is bound and you have registered the network interface, set the > address values that were saved earlier. (Of course, when you do this > you'll be racing with udev and NetworkManager, which will try to set their > own values for the network addresses. That's the price you pay for > following this peculiar approach.) > By host_addr and dev_addr I meant link layer addresses (MAC addresses), not IP addresses. Exactly these names have been used for module parameters so far and I thought it would be understood. Andrzej -- 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: Summary, was Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from hibernate
On Thu, Apr 18, 2013 at 8:18 AM, Sarah Sharp wrote: > All right, I've finally come back to this long thread. To sum up: > > xHCI hosts that have the effected TI redriver may lose device connect > events when in D3hot or D3cold, if the port goes into Compliance Mode. > > Effected xHCI hosts may lose device connect events (or wake events, if > those happen after the failed connect event) while the system is > suspended or hibernated, and there's nothing software can do about it. > > The current timer code to poll port status registers for compliance mode > fails in two ways: > > 1. When hibernate occurs, the frozen image stored in memory still has > the compliance mode polling timer running. On resume from hibernate, > re-starting that timer in xhci_resume causes list corruption, leading to > an NMI and system lock up. > > 2. If effected xHCI hosts are allowed to go into D3cold, power is > removed, and we cannot read the port status registers to see if a port > is in compliance mode, since they will be all F's. > > To solve #1, I prefer Tony's patch that stops and restarts the > compliance timer on resume from hibernate: > > http://marc.info/?l=linux-usb&m=136148109502971&w=2 > > However, looking at it again, there's an issue if the xHCI restore > registers operation fails on resume from suspend, when (temp & STS_SRE) > is true. xhci_init will get called, which will re-init the compliance > timer. We'll move to the done label, and hibernate will be false, and > we'll attempt to re-init the compliance timer again, which will again > cause list corruption, NMIs, and a lockup. I'll send a refresh patch > that fixes this shortly. > > To solve #2, there are two possible solutions. > > The first option is to disable runtime PM for effected xHCI hosts > entirely, with a call to pm_runtime_get_noresume in the xHCI PCI probe > function, and a call to pm_runtime_put_noidle in the release function. > However, that seems a bit harsh to completely disable xHCI PCI host > suspend, and cause user systems to have increased power consumption. > > The second option is to disable D3cold only. I think this is the better > option, but it's not clear how best to do this. > > It seems like the xHCI PCI probe function needs to set d3cold_allowed to > false in the parent PCI structure. However, I think that userspace can > overwrite that value and re-enable D3cold through the d3cold_allowed > sysfs file. We don't want that to happen in this case. > > Ying, is there a way to permanently disable D3cold, so that userspace > can't re-enable it? Yes. You can set pci_dev->no_d3cold = true in runtime_suspend callback of device driver. Then the device will never be put into D3COLD state. Best Regards, Huang Ying -- 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: Driver for PL-2303 HX not working
On Wed, Apr 17, 2013 at 07:43:11PM +0200, Karsten Malcher wrote: > Am 17.04.2013 15:13, schrieb Johan Hovold: > > Can you minimise your test setup using a custom program which only opens > > the device, initialises it, writes the four characters (e.g. "test") > > and reads them back (over you hardwired loop) before closing the device > > again? > > I have used a little perl program that opens the port and send "Test" > to the looped back device. > The length of the log looks good. Great. Now I can see what's going on. The only problem (?) is that everything seems to be working. The write succeeds and the four bytes are read back as they should by the driver. The first thing that comes to mind that could prevent you from reading the received data would be if the tty device is configured for canonical input processing. Have you made sure this is not the case? Can you read the data back if you add a newline to your test string (e.g. "test\n")? > > Make sure to verify it using a working device first. > > I use this script with a ch341 adapter and it works. Hmmm. Did you remember to initialise the device (e.g. set the termios flags)? Johan -- 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, >> >> g_file_storage gadget: SCSI command: Unknown xa1; Dc=12, Du=0; Hc=12, >> >> Hi=512 >> >> g_file_storage gadget: bulk-in, length 0: >> >> [start_transfer] 43425355 12 >> >> ept1 in queue len 0x0, buffer 0xc12ac000 >> >> g_file_storage gadget: bulk-in set halt >> >> I think here is the problem: the bulk-in of length 0. This zero >> length packet is never sent out nor received by the host. What is this >> zero length packet? > > A data packet has three parts: > > a Packet ID (PID) byte, which is either DATA0 or DATA1 for > bulk transfers; > > some variable number N of data bytes; > > two Cyclic Redundancy Check (CRC) bytes. > > A zero-length data packet is one in which N = 0. Such packets contain > exactly three bytes: a PID and two CRC bytes. See Sections 8.3 and > 8.4.4 of the USB-2.0 specification. I modified the UDC driver to send out zero length data packet. Now the linux host is able to see the USB gadget as a mass storage device and read from USB gadget. However, writing to USB gadget fails. The SCSI_WRITE_10 command often receives (-104). The usbmon trace showing this failure is attached. Is the bulk-out endpoint unable to receive command and data continuously, due to error in UDC driver? Also, as in UDC driver log, sometimes the same SCSI_READ_10 command is received repeatedly. It is strange behavior. Thanks, victor g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 330: 0x53425355 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 5124: 0x2020544f g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 5120: 0x53425355 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00 00 80 00 0a 28 0010: 00 00 00 20 00 00 00 01 00 00 00 00 f8 9e 33 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=10, Hi=512 g_file_storage gadget-lun0: file read 512 @ 4194304 -> 512 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0a 01 00 00 00 00 00 00 00 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0a 01 00 00 00 02 00
Re: Driver for PL-2303 HX not working
Am 17.04.2013 15:13, schrieb Johan Hovold: Can you try to reproduce this on a later kernel (e.g. 3.8) which uses dynamic debugging? I have compiled a 3.8.5 kernel now on Debian testing (wheezy). The result is the same as in 3.2.0 ! I could receive only some of the first bytes after opening the port afterwards everything is lost without errors. How can i enable the debugging in kernel 3.8.5? root@PC# modprobe usbserial debug=1 ERROR: could not insert 'usbserial': Invalid argument root@PC# modprobe pl2303 debug=1 ERROR: could not insert 'pl2303': Invalid argument Cheers Karsten -- 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: Driver for PL-2303 HX not working
On Thu, Apr 18, 2013 at 12:36:17PM +0200, Karsten Malcher wrote: > Am 17.04.2013 15:13, schrieb Johan Hovold: > > Can you try to reproduce this on a later kernel (e.g. 3.8) which uses > > dynamic debugging? > > I have compiled a 3.8.5 kernel now on Debian testing (wheezy). > The result is the same as in 3.2.0 ! > I could receive only some of the first bytes after opening the port > afterwards everything is lost without errors. Can you generate a log where bytes are actually lost? Nothing seemed to get lost in the previous log you posted. > How can i enable the debugging in kernel 3.8.5? Make sure debugfs is mounted: mount -t debugfs none /sys/kernel/debug and then enable debugging: echo "module usbserial +p" >/sys/kernel/debug/dynamic_debug/control echo "module pl2303 +p" >/sys/kernel/debug/dynamic_debug/control Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management
On Tuesday 02 April 2013 06:10 PM, Vivek Gautam wrote:
Hi,
On Tue, Apr 2, 2013 at 5:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Apr 02, 2013 at 04:04:01PM +0530, Vivek Gautam wrote:
On Mon, Apr 01, 2013 at 07:24:00PM +0530, Vivek Gautam wrote:
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam
---
include/linux/usb/phy.h | 141 +++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return "UNKNOWN PHY TYPE";
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x->dev) {
+ dev_err(x->dev, "no PHY or attached device available\n");
+ return;
+ }
wrong indentation, also, I'm not sure we should allow calls with NULL
pointers. Perhaps a WARN() so we get API offenders early enough ?
True, bad coding style :-(
We should be handling dev_err with a NULL pointer.
Will just keep here:
if (WARN_ON(!x->dev))
return ;
right, but I guess:
if (WARN(!x || !x->dev, "Invalid parameters\n"))
return -EINVAL;
would be better ??
btw, shouldn't it be IS_ERR(x)?
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Gadget Zero fixes
Dear All, The first patch contains a trivial fix of a name which doesn't fit its purpose. The second patch fixes a bug which prevents the usb_f_ss_lb.ko from unloading when it is not actually used. Andrzej Pietrasiewicz (2): usb/gadget: f_sourcesink.c: correct a copy-paste misnomer usb/gadget: zero: put function instances on unbind drivers/usb/gadget/f_sourcesink.c |4 ++-- drivers/usb/gadget/zero.c |2 ++ 2 files changed, 4 insertions(+), 2 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] usb/gadget: f_sourcesink.c: correct a copy-paste misnomer
acm was the first function to be converted and it seems that its
code served as a base for converting f_sourcesink to the new function
interface. source_sink has nothing to do with acm, though.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_sourcesink.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_sourcesink.c
b/drivers/usb/gadget/f_sourcesink.c
index 41adf3e..a889585 100644
--- a/drivers/usb/gadget/f_sourcesink.c
+++ b/drivers/usb/gadget/f_sourcesink.c
@@ -898,7 +898,7 @@ static struct usb_function *source_sink_alloc_func(
return &ss->function;
}
-static void acm_free_instance(struct usb_function_instance *fi)
+static void source_sink_free_instance(struct usb_function_instance *fi)
{
struct f_ss_opts *ss_opts;
@@ -913,7 +913,7 @@ static struct usb_function_instance
*source_sink_alloc_inst(void)
ss_opts = kzalloc(sizeof(*ss_opts), GFP_KERNEL);
if (!ss_opts)
return ERR_PTR(-ENOMEM);
- ss_opts->func_inst.free_func_inst = acm_free_instance;
+ ss_opts->func_inst.free_func_inst = source_sink_free_instance;
return &ss_opts->func_inst;
}
DECLARE_USB_FUNCTION(SourceSink, source_sink_alloc_inst,
--
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/gadget: zero: put function instances on unbind
If function instances are not put on gadget's unbind, their implementation module's refcount is nonzero and it is impossible to unload it. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park --- drivers/usb/gadget/zero.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/zero.c b/drivers/usb/gadget/zero.c index 685fa68..2cd6262 100644 --- a/drivers/usb/gadget/zero.c +++ b/drivers/usb/gadget/zero.c @@ -368,8 +368,10 @@ static int zero_unbind(struct usb_composite_dev *cdev) del_timer_sync(&autoresume_timer); if (!IS_ERR_OR_NULL(func_ss)) usb_put_function(func_ss); + usb_put_function_instance(func_inst_ss); if (!IS_ERR_OR_NULL(func_lb)) usb_put_function(func_lb); + usb_put_function_instance(func_inst_lb); return 0; } -- 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
Olicard 145
Hello! Sorry, but i'm not sure i'm writing in the right place. I own an usb GSM modem named Olivetti Olicard 145, and with my kernel version (3.7.10-gentoo) it doesn't work just pluggin it in, but loading the usbserial generic module and passing by hand product and vendor id. Taking a look on the kernel sourced I noticed that an Olicard 100 is present in usb/serial/option.c, so I added a couple of lines in the file to try my 145 with the same module, I rebuild the modules plugged the card in, the modules loaded without doing anything and it just works. I send the patch file, I hope this can help. Filippo. option.c_patch Description: Binary data
[PATCH] usb: otg: remove exported function from __init section
The symbol usb_bind_phy is exported and annotated __init.
It looks like section mismatch. Fix by removing
the __init annotation of usb_bind_phy.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov
---
drivers/usb/otg/otg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 2bd03d2..77346cf 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -414,7 +414,7 @@ EXPORT_SYMBOL(usb_remove_phy);
*
* To be used by platform specific initialization code.
*/
-int __init usb_bind_phy(const char *dev_name, u8 index,
+int usb_bind_phy(const char *dev_name, u8 index,
const char *phy_dev_name)
{
struct usb_phy_bind *phy_bind;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Olicard 145
On Thursday 18 April 2013 15:05:39 Filippo Turato wrote: > Hello! > Sorry, but i'm not sure i'm writing in the right place. > I own an usb GSM modem named Olivetti Olicard 145, and with my kernel > version (3.7.10-gentoo) it doesn't work just pluggin it in, but > loading the usbserial generic module and passing by hand product and > vendor id. > Taking a look on the kernel sourced I noticed that an Olicard 100 is > present in usb/serial/option.c, so I added a couple of lines in the > file to try my 145 with the same module, I rebuild the modules plugged > the card in, the modules loaded without doing anything and it just > works. > I send the patch file, I hope this can help. Hi, thank you for making a patch. Could you send the patch as a git patch? In any case a "Signed-off-by:" line from you is needed. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
On Wed, Apr 17, 2013 at 01:35:09AM +0400, Sergei Shtylyov wrote: > Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'. > Enable USB storage driver and SCSI disk driver that it needs as well... > > Signed-off-by: Sergei Shtylyov I realise that this is not going to be useful until the rest of the series has been merged. But regardless I have pre-emptively queued it up for v3.11 in the defconfig-bockw branch. > > --- > arch/arm/configs/bockw_defconfig | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > Index: renesas/arch/arm/configs/bockw_defconfig > === > --- renesas.orig/arch/arm/configs/bockw_defconfig > +++ renesas/arch/arm/configs/bockw_defconfig > @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y > # CONFIG_STANDALONE is not set > # CONFIG_PREVENT_FIRMWARE_BUILD is not set > # CONFIG_FW_LOADER is not set > +CONFIG_SCSI=y > +CONFIG_BLK_DEV_SD=y > CONFIG_NETDEVICES=y > # CONFIG_NET_CADENCE is not set > # CONFIG_NET_VENDOR_BROADCOM is not set > @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6 > CONFIG_SERIAL_SH_SCI_CONSOLE=y > # CONFIG_HW_RANDOM is not set > # CONFIG_HWMON is not set > -# CONFIG_USB_SUPPORT is not set > +CONFIG_USB=y > +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > +CONFIG_USB_EHCI_HCD=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_HCD_PLATFORM=y > +CONFIG_USB_EHCI_HCD_PLATFORM=y > +CONFIG_USB_STORAGE=y > +CONFIG_USB_RCAR_PHY=y > CONFIG_UIO=y > CONFIG_UIO_PDRV_GENIRQ=y > # CONFIG_IOMMU_SUPPORT is not set > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: storage: Add usb_stor_dbg, reduce object size
On Wed, 17 Apr 2013, Joe Perches wrote:
> On Wed, 2013-04-17 at 14:47 -0400, Alan Stern wrote:
> > On Wed, 17 Apr 2013, Joe Perches wrote:
> []
> > > +int usb_stor_dbg(const struct us_data *us, const char *fmt, ...)
> > > +{
> > > + struct va_format vaf;
> > > + va_list args;
> > > + int r;
> > > +
> > > + va_start(args, fmt);
> > > +
> > > + if (us && us->pusb_dev) {
> > > + r = dev_vprintk_emit(7, &us->pusb_dev->dev, fmt, args);
> >
> > Isn't there a symbolic constant you can use instead of "7"?
>
> Nope.
> lib/dynamic_debug:__dynamic_dev_dbg() does the same thing.
This clearly is an omission in the logging API.
Kay, why doesn't the kernel have symbolic constants for the various
logging facilities and levels?
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 3/9] usb/gadget: change sysfs parent device for USB Ethernet
On Thu, 18 Apr 2013, Andrzej Pietrasiewicz wrote: > On Wednesday, April 17, 2013 6:46 PM Alan Stern wrote: > > On Wed, 17 Apr 2013, Andrzej Pietrasiewicz wrote: > > > > > The procedure of setting a gadget up with configfs is like this: > > > > > > 1) create the gadget directory > > > 2) create functions directories corresponding to functions to be used > > > by the gadget > > > 3) create configurations directories > > > > ... > > > > > 4) create symbolic links in configurations' directories, pointing to > > > appropriate functions' directories > > > 5) In the gadget directory echo > UDC > > > > > > Now, what you suggest is that a net device is registered only at step > > > 5) above. But changing a device address is possible only _after_ the > > > device is registered. Which is in contradiction with the assumptions > > above. > > > > It doesn't have to be. You don't actually have to change the address when > > the attribute is written. In fact, since the network link doesn't exist > > at this point, there _is_ no address to change. > > > > > And in practice you would have a directory structure like this: > > > > > > . > > > . > > > . > > > ./functions > > > ./functions/ncm.usb0 > > > ./functions/ncm.usb0/ifname > > > ./functions/ncm.usb0/qmult > > > ./functions/ncm.usb0/host_addr > > > ./functions/ncm.usb0/dev_addr > > > . > > > . > > > . > > > > > > Where ifname, qmult and host_addr can be written to before the gadget > > > is bound, but writing to dev_addr in such a situation would result in > > > ENODEV. > > > > If you still want to persist with this approach, you can do it in a way > > that doesn't require the network interface to be registered before the > > gadget is bound. > > > > Simply store the strings written to host_addr and dev_addr. Don't try to > > do anything with them -- in particular, don't try to change the addresses > > associated with a nonexistent network interface. Then later on, when the > > gadget is bound and you have registered the network interface, set the > > address values that were saved earlier. (Of course, when you do this > > you'll be racing with udev and NetworkManager, which will try to set their > > own values for the network addresses. That's the price you pay for > > following this peculiar approach.) > > > > By host_addr and dev_addr I meant link layer addresses (MAC addresses), not > IP addresses. Exactly these names have been used for module parameters so > far > and I thought it would be understood. Everything I wrote above still stands, except the part about racing with udev and NetworkManager. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Thu, 18 Apr 2013, victor yeo wrote: > I modified the UDC driver to send out zero length data packet. Now the > linux host is able to see the USB gadget as a mass storage device and > read from USB gadget. However, writing to USB gadget fails. The > SCSI_WRITE_10 command often receives (-104). The usbmon trace showing > this failure is attached. Is the bulk-out endpoint unable to receive > command and data continuously, due to error in UDC driver? It looks like the data gets received okay. I can't tell what's going wrong because you did not post the gadget log showing the WRITE commands. > Also, as in UDC driver log, sometimes the same SCSI_READ_10 command is > received repeatedly. It is strange behavior. This could be the same probably I told you about earlier: The UDC driver calls bulk_out_complete() even though no packets were received. 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: [Projekt-wlan] Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with Freescale P1020
Hi,
thanks for the quick reply.
Please review the patch http://patchwork.ozlabs.org/patch/237201/
I applied it, but it does not make any difference on my platform.
Regards,
M. Braun
Am 17.04.2013 12:53, schrieb Liu Shengzhou-B36685:
Hi Braun,
It seems the duplicated tdi_reset caused the PHY_CLK_VALID bit
unstable,
introduced by patch "EHCI: centralize controller initialization".
I submitted a patch to fix it.
Please review the patch http://patchwork.ozlabs.org/patch/237201/
Regards,
Shengzhou
-Original Message-
From: Michael Braun [mailto:michael-...@fami-braun.de]
Sent: Wednesday, April 17, 2013 6:08 PM
To: Liu Shengzhou-B36685
Cc: Alan Stern; projekt-w...@fem.tu-ilmenau.de; Greg Kroah-Hartman;
linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: Regression in 3735ba8db8e6ea22ad3ff524328926d8d780a884 with
Freescale P1020
Hi,
I'm running OpenWRT Kernel 3.8.3 (which already has
f66dea709cd9309b2ee9f715697818001fb518de and
5ed338778f917a035f0f0a52327fc4f72e36f7a1 applied) on a P1020WLAN
(QorlQ,
PPC) device.
Before updating the kernel from 3.3.0, USB host support was working
fine.
Now I get "fsl-ehci: USB PHY clock invalid" messages in dmesg and the
lsusb output is empty, so USB host support is not working. When I
apply
the following patch, USB host support starts working again, so I
guess
3735ba8db8e6ea22ad3ff524328926d8d780a884 is the cause.
Do you have an idea how to fix it more appropriately?
Thanks,
M. Braun
--- a/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:52.924403077
+0200
+++ b/drivers/usb/host/ehci-fsl.c 2013-04-15 21:13:57.572410838
+0200
@@ -273,7 +273,6 @@ static int ehci_fsl_setup_phy(struct usb
if (!spin_event_timeout(in_be32(non_ehci +
FSL_SOC_USB_CTRL) &
PHY_CLK_VALID,
FSL_USB_PHY_CLK_TIMEOUT,
0)) {
printk(KERN_WARNING "fsl-ehci: USB PHY clock
invalid\n");
- return -EINVAL;
}
}
--
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/7] USB: serial: more patches for 3.10
These patches fix a regression in io_ti and removes the ti_usb_3410_5052 custom closing-wait implementation and some other redundant code. All patches have been compile-only tested. Johan Johan Hovold (7): USB: io_ti: fix TIOCGSERIAL USB: io_ti: remove redundant wait_until_sent USB: ti_usb_3410_5052: move write-fifo flushing to close USB: ti_usb_3410_5052: remove lsr from port data USB: ti_usb_3410_5052: query hardware-buffer status in chars_in_buffer USB: ti_usb_3410_5052: remove redundant drain from break_ctl USB: ti_usb_3410_5052: kill custom closing_wait drivers/usb/serial/io_ti.c| 4 +- drivers/usb/serial/ti_usb_3410_5052.c | 94 +++ 2 files changed, 31 insertions(+), 67 deletions(-) -- 1.8.1.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 4/7] USB: ti_usb_3410_5052: remove lsr from port data
The line status register is only polled so let's not keep a possibly
outdated value in the port data.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index a49d2a7..3ed8eca 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -67,7 +67,6 @@
struct ti_port {
int tp_is_open;
__u8tp_msr;
- __u8tp_lsr;
__u8tp_shadow_mcr;
__u8tp_uart_mode; /* 232 or 485 modes */
unsigned inttp_uart_base_addr;
@@ -121,7 +120,7 @@ static void ti_recv(struct usb_serial_port *port, unsigned
char *data,
int length);
static void ti_send(struct ti_port *tport);
static int ti_set_mcr(struct ti_port *tport, unsigned int mcr);
-static int ti_get_lsr(struct ti_port *tport);
+static int ti_get_lsr(struct ti_port *tport, u8 *lsr);
static int ti_get_serial_info(struct ti_port *tport,
struct serial_struct __user *ret_arg);
static int ti_set_serial_info(struct tty_struct *tty, struct ti_port *tport,
@@ -1251,7 +1250,7 @@ static int ti_set_mcr(struct ti_port *tport, unsigned int
mcr)
}
-static int ti_get_lsr(struct ti_port *tport)
+static int ti_get_lsr(struct ti_port *tport, u8 *lsr)
{
int size, status;
struct ti_device *tdev = tport->tp_tdev;
@@ -1277,7 +1276,7 @@ static int ti_get_lsr(struct ti_port *tport)
dev_dbg(&port->dev, "%s - lsr 0x%02X\n", __func__, data->bLSR);
- tport->tp_lsr = data->bLSR;
+ *lsr = data->bLSR;
free_data:
kfree(data);
@@ -1370,6 +1369,7 @@ static void ti_drain(struct ti_port *tport, unsigned long
timeout)
struct ti_device *tdev = tport->tp_tdev;
struct usb_serial_port *port = tport->tp_port;
wait_queue_t wait;
+ u8 lsr;
spin_lock_irq(&tport->tp_lock);
@@ -1396,11 +1396,11 @@ static void ti_drain(struct ti_port *tport, unsigned
long timeout)
/* wait for data to drain from the device */
/* wait for empty tx register, plus 20 ms */
timeout += jiffies;
- tport->tp_lsr &= ~TI_LSR_TX_EMPTY;
+ lsr = 0;
while ((long)(jiffies - timeout) < 0 && !signal_pending(current)
- && !(tport->tp_lsr&TI_LSR_TX_EMPTY) && !tdev->td_urb_error
+ && !(lsr & TI_LSR_TX_EMPTY) && !tdev->td_urb_error
&& !port->serial->disconnected) {
- if (ti_get_lsr(tport))
+ if (ti_get_lsr(tport, &lsr))
break;
mutex_unlock(&port->serial->disc_mutex);
msleep_interruptible(20);
--
1.8.1.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 6/7] USB: ti_usb_3410_5052: remove redundant drain from break_ctl
Remove redundant drain, which has already been handled by the tty-layer, from break_ctl. Signed-off-by: Johan Hovold --- drivers/usb/serial/ti_usb_3410_5052.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/serial/ti_usb_3410_5052.c b/drivers/usb/serial/ti_usb_3410_5052.c index 062b6d8..6a40823 100644 --- a/drivers/usb/serial/ti_usb_3410_5052.c +++ b/drivers/usb/serial/ti_usb_3410_5052.c @@ -976,8 +976,6 @@ static void ti_break(struct tty_struct *tty, int break_state) if (tport == NULL) return; - ti_drain(tport, (tport->tp_closing_wait*HZ)/100); - status = ti_write_byte(port, tport->tp_tdev, tport->tp_uart_base_addr + TI_UART_OFFSET_LCR, TI_LCR_BREAK, break_state == -1 ? TI_LCR_BREAK : 0); -- 1.8.1.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 5/7] USB: ti_usb_3410_5052: query hardware-buffer status in chars_in_buffer
Query hardware-buffer status in chars_in_buffer should the write fifo be
empty.
This is needed to make the tty layer wait for hardware buffers to drain
on close.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 3ed8eca..062b6d8 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -687,6 +687,8 @@ static int ti_chars_in_buffer(struct tty_struct *tty)
struct ti_port *tport = usb_get_serial_port_data(port);
int chars = 0;
unsigned long flags;
+ int ret;
+ u8 lsr;
if (tport == NULL)
return 0;
@@ -695,6 +697,12 @@ static int ti_chars_in_buffer(struct tty_struct *tty)
chars = kfifo_len(&tport->write_fifo);
spin_unlock_irqrestore(&tport->tp_lock, flags);
+ if (!chars) {
+ ret = ti_get_lsr(tport, &lsr);
+ if (!ret && !(lsr & TI_LSR_TX_EMPTY))
+ chars = 1;
+ }
+
dev_dbg(&port->dev, "%s - returns %d\n", __func__, chars);
return chars;
}
--
1.8.1.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/7] USB: io_ti: remove redundant wait_until_sent
Remove redundant wait_until_sent, which has already been handled by the tty-layer, from break_ctl. Signed-off-by: Johan Hovold --- drivers/usb/serial/io_ti.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c index ab979a2..158bf4b 100644 --- a/drivers/usb/serial/io_ti.c +++ b/drivers/usb/serial/io_ti.c @@ -2400,8 +2400,6 @@ static void edge_break(struct tty_struct *tty, int break_state) int status; int bv = 0; /* Off */ - tty_wait_until_sent(tty, 0); - if (break_state == -1) bv = 1; /* On */ status = ti_do_config(edge_port, UMPC_SET_CLR_BREAK, bv); -- 1.8.1.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/7] USB: io_ti: fix TIOCGSERIAL
Fix regression introduced by commit f40d78155 ("USB: io_ti: kill custom
closing_wait implementation") which made TIOCGSERIAL return the wrong
value for closing_wait.
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/io_ti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index f2a1601..ab979a2 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2357,7 +2357,7 @@ static int get_serial_info(struct edgeport_port
*edge_port,
cwait = edge_port->port->port.closing_wait;
if (cwait != ASYNC_CLOSING_WAIT_NONE)
- cwait = jiffies_to_msecs(closing_wait) / 10;
+ cwait = jiffies_to_msecs(cwait) / 10;
memset(&tmp, 0, sizeof(tmp));
--
1.8.1.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 3/7] USB: ti_usb_3410_5052: move write-fifo flushing to close
Move write-fifo flushing from ti_drain to close where it belongs.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 0726859..a49d2a7 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -128,7 +128,7 @@ static int ti_set_serial_info(struct tty_struct *tty,
struct ti_port *tport,
struct serial_struct __user *new_arg);
static void ti_handle_new_msr(struct ti_port *tport, __u8 msr);
-static void ti_drain(struct ti_port *tport, unsigned long timeout, int flush);
+static void ti_drain(struct ti_port *tport, unsigned long timeout);
static void ti_stop_read(struct ti_port *tport, struct tty_struct *tty);
static int ti_restart_read(struct ti_port *tport, struct tty_struct *tty);
@@ -601,6 +601,7 @@ static void ti_close(struct usb_serial_port *port)
int port_number;
int status;
int do_unlock;
+ unsigned long flags;
tdev = usb_get_serial_data(port->serial);
tport = usb_get_serial_port_data(port);
@@ -609,11 +610,14 @@ static void ti_close(struct usb_serial_port *port)
tport->tp_is_open = 0;
- ti_drain(tport, (tport->tp_closing_wait*HZ)/100, 1);
+ ti_drain(tport, (tport->tp_closing_wait*HZ)/100);
usb_kill_urb(port->read_urb);
usb_kill_urb(port->write_urb);
tport->tp_write_urb_in_use = 0;
+ spin_lock_irqsave(&tport->tp_lock, flags);
+ kfifo_reset_out(&tport->write_fifo);
+ spin_unlock_irqrestore(&tport->tp_lock, flags);
port_number = port->number - port->serial->minor;
@@ -965,7 +969,7 @@ static void ti_break(struct tty_struct *tty, int
break_state)
if (tport == NULL)
return;
- ti_drain(tport, (tport->tp_closing_wait*HZ)/100, 0);
+ ti_drain(tport, (tport->tp_closing_wait*HZ)/100);
status = ti_write_byte(port, tport->tp_tdev,
tport->tp_uart_base_addr + TI_UART_OFFSET_LCR,
@@ -1361,7 +1365,7 @@ static void ti_handle_new_msr(struct ti_port *tport, __u8
msr)
}
-static void ti_drain(struct ti_port *tport, unsigned long timeout, int flush)
+static void ti_drain(struct ti_port *tport, unsigned long timeout)
{
struct ti_device *tdev = tport->tp_tdev;
struct usb_serial_port *port = tport->tp_port;
@@ -1386,11 +1390,6 @@ static void ti_drain(struct ti_port *tport, unsigned
long timeout, int flush)
}
set_current_state(TASK_RUNNING);
remove_wait_queue(&tport->tp_write_wait, &wait);
-
- /* flush any remaining data in the buffer */
- if (flush)
- kfifo_reset_out(&tport->write_fifo);
-
spin_unlock_irq(&tport->tp_lock);
mutex_lock(&port->serial->disc_mutex);
--
1.8.1.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 7/7] USB: ti_usb_3410_5052: kill custom closing_wait
Kill custom closing_wait implementation and let the tty-layer handle it
instead.
Note that the port drain-delay is set to three characters to keep the
20ms delay after wait_until_sent at low baudrates (1200 baud) during close.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ti_usb_3410_5052.c | 69 ---
1 file changed, 15 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 6a40823..4b52132 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -71,7 +71,6 @@ struct ti_port {
__u8tp_uart_mode; /* 232 or 485 modes */
unsigned inttp_uart_base_addr;
int tp_flags;
- int tp_closing_wait;/* in .01 secs */
wait_queue_head_t tp_write_wait;
struct ti_device*tp_tdev;
struct usb_serial_port *tp_port;
@@ -127,8 +126,6 @@ static int ti_set_serial_info(struct tty_struct *tty,
struct ti_port *tport,
struct serial_struct __user *new_arg);
static void ti_handle_new_msr(struct ti_port *tport, __u8 msr);
-static void ti_drain(struct ti_port *tport, unsigned long timeout);
-
static void ti_stop_read(struct ti_port *tport, struct tty_struct *tty);
static int ti_restart_read(struct ti_port *tport, struct tty_struct *tty);
@@ -428,7 +425,7 @@ static int ti_port_probe(struct usb_serial_port *port)
tport->tp_uart_base_addr = TI_UART1_BASE_ADDR;
else
tport->tp_uart_base_addr = TI_UART2_BASE_ADDR;
- tport->tp_closing_wait = closing_wait;
+ port->port.closing_wait = msecs_to_jiffies(10 * closing_wait);
init_waitqueue_head(&tport->tp_write_wait);
if (kfifo_alloc(&tport->write_fifo, TI_WRITE_BUF_SIZE, GFP_KERNEL)) {
kfree(tport);
@@ -581,6 +578,8 @@ static int ti_open(struct tty_struct *tty, struct
usb_serial_port *port)
tport->tp_is_open = 1;
++tdev->td_open_port_count;
+ port->port.drain_delay = 3;
+
goto release_lock;
unlink_int_urb:
@@ -609,8 +608,6 @@ static void ti_close(struct usb_serial_port *port)
tport->tp_is_open = 0;
- ti_drain(tport, (tport->tp_closing_wait*HZ)/100);
-
usb_kill_urb(port->read_urb);
usb_kill_urb(port->write_urb);
tport->tp_write_urb_in_use = 0;
@@ -1295,10 +1292,15 @@ static int ti_get_serial_info(struct ti_port *tport,
{
struct usb_serial_port *port = tport->tp_port;
struct serial_struct ret_serial;
+ unsigned cwait;
if (!ret_arg)
return -EFAULT;
+ cwait = port->port.closing_wait;
+ if (cwait != ASYNC_CLOSING_WAIT_NONE)
+ cwait = jiffies_to_msecs(cwait) / 10;
+
memset(&ret_serial, 0, sizeof(ret_serial));
ret_serial.type = PORT_16550A;
@@ -1307,7 +1309,7 @@ static int ti_get_serial_info(struct ti_port *tport,
ret_serial.flags = tport->tp_flags;
ret_serial.xmit_fifo_size = TI_WRITE_BUF_SIZE;
ret_serial.baud_base = tport->tp_tdev->td_is_3410 ? 921600 : 460800;
- ret_serial.closing_wait = tport->tp_closing_wait;
+ ret_serial.closing_wait = cwait;
if (copy_to_user(ret_arg, &ret_serial, sizeof(*ret_arg)))
return -EFAULT;
@@ -1320,12 +1322,17 @@ static int ti_set_serial_info(struct tty_struct *tty,
struct ti_port *tport,
struct serial_struct __user *new_arg)
{
struct serial_struct new_serial;
+ unsigned cwait;
if (copy_from_user(&new_serial, new_arg, sizeof(new_serial)))
return -EFAULT;
+ cwait = new_serial.closing_wait;
+ if (cwait != ASYNC_CLOSING_WAIT_NONE)
+ cwait = msecs_to_jiffies(10 * new_serial.closing_wait);
+
tport->tp_flags = new_serial.flags & TI_SET_SERIAL_FLAGS;
- tport->tp_closing_wait = new_serial.closing_wait;
+ tport->tp_port->port.closing_wait = cwait;
return 0;
}
@@ -1370,52 +1377,6 @@ static void ti_handle_new_msr(struct ti_port *tport,
__u8 msr)
}
-static void ti_drain(struct ti_port *tport, unsigned long timeout)
-{
- struct ti_device *tdev = tport->tp_tdev;
- struct usb_serial_port *port = tport->tp_port;
- wait_queue_t wait;
- u8 lsr;
-
- spin_lock_irq(&tport->tp_lock);
-
- /* wait for data to drain from the buffer */
- tdev->td_urb_error = 0;
- init_waitqueue_entry(&wait, current);
- add_wait_queue(&tport->tp_write_wait, &wait);
- for (;;) {
- set_current_state(TASK_INTERRUPTIBLE);
- if (kfifo_len(&tport->write_fifo) == 0
- || timeout == 0 || signal_pending(current)
- || tdev->td_urb_error
- || port->serial->disconnected) /* disconnect */
- break;
- spin_unlock_irq(&tport->tp_lock);
-
Re: [PATCH 1/7] USB: io_ti: fix TIOCGSERIAL
On Thu, Apr 18, 2013 at 05:33:17PM +0200, Johan Hovold wrote:
> Fix regression introduced by commit f40d78155 ("USB: io_ti: kill custom
> closing_wait implementation") which made TIOCGSERIAL return the wrong
> value for closing_wait.
>
> Cc: stable
Oops, managed to use the old address there. Can you fix it up, Greg?
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] USB: OHCI: add a name for the platform-private field
This patch adds an ohci->priv field for private use by OHCI
platform drivers.
Until now none of the platform drivers has used this private space,
but that's about to change in the next patch of this series.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Greg KH
Cc: Alan Stern
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index 2c5065e..6d94ac9 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -421,6 +421,9 @@ struct ohci_hcd {
struct dentry *debug_periodic;
struct dentry *debug_registers;
#endif
+ /* platform-specific data -- must come last */
+ unsigned long priv[0] __aligned(sizeof(s64));
+
};
#ifdef CONFIG_PCI
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] USB: OHCI: make ohci-exynos a separate driver
Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before EXYNOS can
be booted with a multi-platform kernel. We currently expect those
to get merged for 3.11.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Jingoo Han
Cc: Kukjin Kim
Cc: Greg KH
Cc: Alan Stern
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig |2 +-
drivers/usb/host/Makefile|1 +
drivers/usb/host/ohci-exynos.c | 140 +++---
drivers/usb/host/ohci-hcd.c |5 --
drivers/usb/host/ohci-platform.c |2 +-
5 files changed, 72 insertions(+), 78 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index bbf1907..42ce228 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -445,7 +445,7 @@ config USB_OHCI_SH
If you use the PCI OHCI controller, this option is not necessary.
config USB_OHCI_EXYNOS
- boolean "OHCI support for Samsung EXYNOS SoC Series"
+ tristate "OHCI support for Samsung EXYNOS SoC Series"
depends on USB_OHCI_HCD && ARCH_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index a20a8d9..f148671 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
obj-$(CONFIG_USB_OHCI_PCI) += ohci-pci.o
+obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index e3b7e85..59d6e23 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -12,25 +12,39 @@
*/
#include
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
+#include
#include
#include
+#include
#include
+#include "ohci.h"
+
+#define DRIVER_DESC "OHCI exynos driver"
+
+static const char hcd_name[] = "ohci-exynos";
+static struct hc_driver __read_mostly exynos_ohci_hc_driver;
+
+#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
+
struct exynos_ohci_hcd {
- struct device *dev;
- struct usb_hcd *hcd;
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
struct exynos4_ohci_platdata *pdata;
};
-static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_enable(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+ struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
if (exynos_ohci->phy)
usb_phy_init(exynos_ohci->phy);
@@ -38,9 +52,9 @@ static void exynos_ohci_phy_enable(struct exynos_ohci_hcd
*exynos_ohci)
exynos_ohci->pdata->phy_init(pdev, USB_PHY_TYPE_HOST);
}
-static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_disable(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(exynos_ohci->dev);
+ struct exynos_ohci_hcd *exynos_ohci = platform_get_drvdata(pdev);
if (exynos_ohci->phy)
usb_phy_shutdown(exynos_ohci->phy);
@@ -60,7 +74,7 @@ static int ohci_exynos_start(struct usb_hcd *hcd)
ohci_dbg(ohci, "ohci_exynos_start, ohci:%p", ohci);
- ret = ohci_run(ohci);
+ ret = ohci_run(hcd);
if (ret < 0) {
dev_err(hcd->self.controller, "can't start %s\n",
hcd->self.bus_name);
@@ -71,34 +85,6 @@ static int ohci_exynos_start(struct usb_hcd *hcd)
return 0;
}
-static const struct hc_driver exynos_ohci_hc_driver = {
- .description= hcd_name,
- .product_desc = "EXYNOS OHCI Host Controller",
- .hcd_priv_size = sizeof(struct ohci_hcd),
-
- .irq= ohci_irq,
- .flags = HCD_MEMORY|HCD_USB11,
-
- .reset = ohci_exynos_reset,
- .start = ohci_exynos_start,
- .stop = ohci_stop,
- .shutdown = ohci_shutdown,
-
- .get_frame_number = ohci_get_frame,
-
- .urb_enqueue= ohci_urb_enqueue,
- .urb_dequeue= ohci_urb_dequeue,
- .endpoint_disable = ohci_endpoint_disable,
-
- .hub_status_data= ohci_hub_status_data,
- .hub_control= ohci_hub_control,
-#ifdef CONFIG_PM
- .bus_suspend= ohci_bus_suspend,
- .bus_resume = ohci_bus_resume,
-#endif
- .start
Re: [PATCH] usb: storage: Add usb_stor_dbg, reduce object size
On Thu, 2013-04-18 at 10:57 -0400, Alan Stern wrote:
> On Wed, 17 Apr 2013, Joe Perches wrote:
>
> > On Wed, 2013-04-17 at 14:47 -0400, Alan Stern wrote:
> > > On Wed, 17 Apr 2013, Joe Perches wrote:
> > []
> > > > +int usb_stor_dbg(const struct us_data *us, const char *fmt, ...)
> > > > +{
> > > > + struct va_format vaf;
> > > > + va_list args;
> > > > + int r;
> > > > +
> > > > + va_start(args, fmt);
> > > > +
> > > > + if (us && us->pusb_dev) {
> > > > + r = dev_vprintk_emit(7, &us->pusb_dev->dev, fmt, args);
> > >
> > > Isn't there a symbolic constant you can use instead of "7"?
> >
> > Nope.
> > lib/dynamic_debug:__dynamic_dev_dbg() does the same thing.
>
> This clearly is an omission in the logging API.
>
> Kay, why doesn't the kernel have symbolic constants for the various
> logging facilities and levels?
Because they're so _very_ rarely used in decimal form.
printk.c, drivers/base/core.c, and net/core/dev.c
sensibly use - '0', and I think dynamic_debug is the
only other current user.
I suppose a new inline could be created something like
static inline int printk_get_level_decimal(const char *level)
{
if (printk_get_level(level)) {
switch (level[1]) {
case '0' ... '7':
return level[1] - '0';
}
}
return -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: BUG: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Wed, 17 Apr 2013, Joe Rayhawk wrote: > Small buffer/period sizes on usb audio playback though UHCI works fine on > v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7. > > I've bisected the behavior down to > > c44b225077bb1fb25ed5cd5c4f226897b91bedd4 > 'UHCI: implement new semantics for URB_ISO_ASAP' > > Tested on two UHCI hosts and three usb-audio devices, all from different > vendors. Can you provide a usbmon trace showing the problems? And maybe also a similar trace made under a 3.7 kernel, where the problem doesn't occur? 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: [RFT] xhci - correct comp_mode_recovery_timer on return from hibernate
On 04/17/2013 08:27 PM, Sarah Sharp wrote: [Sarah reworked this patch to cover the case where the xHCI restore register operation fails, and (temp & STS_SRE) is true (and we re-init the host, including re-init for the compliance mode), but hibernate is false. The original patch would have caused list corruption in this case.] Sarah, This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7. I can attach the S3_Suspend_message.log, if you like, but here are the last few lines. # tail /var/tmp/S3_Suspend_message.log Bridge firewalling registered device virbr0-nic entered promiscuous mode device virbr0-nic left promiscuous mode virbr0: port 1(virbr0-nic) entered disabled state Ebtables v2.0 registered SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts usb 2-1.1: USB disconnect, device number 3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] USB: OHCI: prepare to make ohci-hcd a library module
On Tue, 16 Apr 2013 manjunath.gou...@linaro.org wrote: > From: Manjunath Goudar > > This patch prepares ohci-hcd for being split up into a core > library and separate platform driver modules. A generic > ohci_hc_driver structure is created, containing all the "standard" > values, and a new mechanism is added whereby a driver module can > specify a set of overrides to those values. In addition the > ohci_init(),ohci_restart(),ohci_hcd_init(),ohci_run() ohci_stop(), > ohci_suspend() and ohci_resume() routines need to be EXPORTed > for use by the drivers. This is a good start, but it goes too far by exporting routines that ought to be private. ohci_hcd_init, ohci_run, and ohci_stop should not be called by bus glue modules: ohci_hcd_init doesn't need to be called by glue modules at all, since ohci_init already calls it. Glue modules should not override ohci_hc_driver.start. Stuff like the code at the start of ohci_pci_start can be moved to the end of the module's reset routine. Likewise, glue modules should not need to call ohci_stop. If ohci_run fails, it should call ohci_stop itself. Lastly, I agree with Arnd that sb800_prefetch should be moved to the pci-quirks.c file. 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
add device to a proper driver
Hi, I'm using this phone as modem (it works great) and after modprobe (and checked with dmesg) I was told to tell linux-usb@vger.kernel.org to add my device to a proper driver. So here's my dmesg: usb 1-1: new full-speed USB device number 4 using ohci_hcd usb 1-1: New USB device found, idVendor=1bbb, idProduct=011f usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: USB MMC Storage usb 1-1: Manufacturer: TCT Holding Ltd. usb 1-1: SerialNumber: 0002 Initializing USB Mass Storage driver... scsi1 : usb-storage 1-1:1.0 usbcore: registered new interface driver usb-storage USB Mass Storage support registered. scsi 1:0:0:0: CD-ROMVirtual CD-ROM 2.31 PQ: 0 ANSI: 2 scsi 1:0:0:0: Attached scsi generic sg1 type 5 sr0: scsi3-mmc drive: 0x/0x caddy cdrom: Uniform CD-ROM driver Revision: 3.20 sr 1:0:0:0: Attached scsi CD-ROM sr0 sr0: CDROM (ioctl) error, command: Xpwrite, Read disk info 51 00 00 00 00 00 00 00 02 00 sr: Sense Key : Hardware Error [current] sr: Add. Sense: No additional sense information usb 1-1: USB disconnect, device number 4 usb 1-1: new full-speed USB device number 5 using ohci_hcd usb 1-1: New USB device found, idVendor=1bbb, idProduct=0106 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: Product: EVDO Modem usb 1-1: Manufacturer: TCT Holding Ltd. usbcore: registered new interface driver usbserial usbcore: registered new interface driver usbserial_generic usbserial: USB Serial support registered for generic usbserial_generic 1-1:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes. usbserial_generic 1-1:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver. usbserial_generic 1-1:1.0: generic converter detected usb 1-1: generic converter now attached to ttyUSB0 usbserial_generic 1-1:1.1: The "generic" usb-serial driver is only for testing and one-off prototypes. usbserial_generic 1-1:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver. usbserial_generic 1-1:1.1: generic converter detected usb 1-1: generic converter now attached to ttyUSB1 usbserial_generic 1-1:1.2: The "generic" usb-serial driver is only for testing and one-off prototypes. usbserial_generic 1-1:1.2: Tell linux-usb@vger.kernel.org to add your device to a proper driver. usbserial_generic 1-1:1.2: generic converter detected usb 1-1: generic converter now attached to ttyUSB2 usbserial_generic 1-1:1.3: The "generic" usb-serial driver is only for testing and one-off prototypes. usbserial_generic 1-1:1.3: Tell linux-usb@vger.kernel.org to add your device to a proper driver. usbserial_generic 1-1:1.3: generic converter detected usb 1-1: generic converter now attached to ttyUSB3 faramir@faramir-1215b ~ $ -- 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: [RFT] xhci - correct comp_mode_recovery_timer on return from hibernate
On Thu, Apr 18, 2013 at 02:45:40PM -0400, Tony Camuso wrote: > On 04/17/2013 08:27 PM, Sarah Sharp wrote: > > > >[Sarah reworked this patch to cover the case where the xHCI restore > >register operation fails, and (temp & STS_SRE) is true (and we re-init > >the host, including re-init for the compliance mode), but hibernate is > >false. The original patch would have caused list corruption in this > >case.] > > > > Sarah, > > This patch works with RHEL6.4+ kernel, but hangs with 3.9-rc7. > > I can attach the S3_Suspend_message.log, if you like, but here are the > last few lines. Is it hanging on suspend or on resume? Does S3 work on 3.9-rc7 with your original patch (without the new comp_timer_running variable)? Does S3 work on the effected system with vanilla 3.9-rc7? > # tail /var/tmp/S3_Suspend_message.log > Bridge firewalling registered > device virbr0-nic entered promiscuous mode > device virbr0-nic left promiscuous mode > virbr0: port 1(virbr0-nic) entered disabled state > Ebtables v2.0 registered > SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs > SELinux: initialized (dev proc, type proc), uses genfs_contexts > SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs > SELinux: initialized (dev proc, type proc), uses genfs_contexts > usb 2-1.1: USB disconnect, device number 3 The full log with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING would be helpful. 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
[PATCH usb-next] usb: storage: Fix link error
Fix allmodconfig link error introduced by commit 75b9130e8a
("usb: storage: Add usb_stor_dbg, reduce object size")
Export the symbol usb_stor_dbg.
Add export.h
Signed-off-by: Joe Perches
---
drivers/usb/storage/debug.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/storage/debug.c b/drivers/usb/storage/debug.c
index b428129..29fe08f 100644
--- a/drivers/usb/storage/debug.c
+++ b/drivers/usb/storage/debug.c
@@ -43,6 +43,7 @@
*/
#include
+#include
#include
#include
#include
@@ -193,3 +194,4 @@ int usb_stor_dbg(const char *fmt, ...)
return r;
}
+EXPORT_SYMBOL_GPL(usb_stor_dbg);
--
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: USB audio discontinuities with 'UHCI: implement new semantics for URB_ISO_ASAP'
On Thu, Apr 18, 2013 at 12:42:00PM -0400, Alan Stern wrote:
> On Wed, 17 Apr 2013, Joe Rayhawk wrote:
> > Small buffer/period sizes on usb audio playback though UHCI works fine on
> > v3.7 but causes audio discontinuities/delays on v3.8 and v3.9-rc7.
>
> Can you provide a usbmon trace showing the problems? And maybe also a
> similar trace made under a 3.7 kernel, where the problem doesn't occur?
root@richardiv:~# uname -a; cat /sys/kernel/debug/usb/usbmon/6u & perl -e
'print pack "H*", "00FF" x 2048' | aplay --period-size=48 -r 44100 -f S16_LE
-c2 -D hw:1,0; kill %1
Linux richardiv 3.7-trunk-amd64 #1 SMP Debian 3.7.1-1~experimental.1 x86_64
GNU/Linux
[1] 4407
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
880155fd2780 288949785 S Co:6:007:0 s 01 0b 0001 0001 0
880155fd2780 288951516 C Co:6:007:0 0 0
88015593f3c0 288951743 S Co:6:007:0 s 22 01 0100 0001 0003 3 = 44ac00
88015593f3c0 288952512 C Co:6:007:0 0 3 >
88015593f3c0 288952551 S Ci:6:007:0 s a2 81 0100 0001 0003 3 <
88015593f3c0 288953511 C Ci:6:007:0 0 3 = 44ac00
8801549cc780 288953559 S Zo:6:007:1 -115:1:0 1 -18:0:176 176 =
8801549cca80 288953569 S Zo:6:007:1 -115:1:0 1 -18:0:176 176 =
8801549cc780 288964489 C Zo:6:007:1 0:1:217621:0 1 0:0:176 176 >
8801549cc780 288964505 S Zo:6:007:1 -115:1:217621 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288965508 C Zo:6:007:1 0:1:217622:0 1 0:0:176 176 >
8801549cca80 288965527 S Zo:6:007:1 -115:1:217622 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288966486 C Zo:6:007:1 0:1:217623:0 1 0:0:176 176 >
8801549cc780 288966503 S Zo:6:007:1 -115:1:217623 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288967488 C Zo:6:007:1 0:1:217624:0 1 0:0:176 176 >
8801549cca80 288967507 S Zo:6:007:1 -115:1:217624 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288968508 C Zo:6:007:1 0:1:217625:0 1 0:0:176 176 >
8801549cc780 288968523 S Zo:6:007:1 -115:1:217625 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288969485 C Zo:6:007:1 0:1:217626:0 1 0:0:176 176 >
8801549cca80 288969499 S Zo:6:007:1 -115:1:217626 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288970507 C Zo:6:007:1 0:1:217627:0 1 0:0:176 176 >
8801549cc780 288970520 S Zo:6:007:1 -115:1:217627 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288971487 C Zo:6:007:1 0:1:217628:0 1 0:0:176 176 >
8801549cca80 288971505 S Zo:6:007:1 -115:1:217628 1 -18:0:180 180 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288972491 C Zo:6:007:1 0:1:217629:0 1 0:0:176 176 >
8801549cc780 288972504 S Zo:6:007:1 -115:1:217629 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288973485 C Zo:6:007:1 0:1:217630:0 1 0:0:180 180 >
8801549cca80 288973499 S Zo:6:007:1 -115:1:217630 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288974490 C Zo:6:007:1 0:1:217631:0 1 0:0:176 176 >
8801549cc780 288974505 S Zo:6:007:1 -115:1:217631 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288975485 C Zo:6:007:1 0:1:217632:0 1 0:0:176 176 >
8801549cca80 288975502 S Zo:6:007:1 -115:1:217632 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288976491 C Zo:6:007:1 0:1:217633:0 1 0:0:176 176 >
8801549cc780 288976501 S Zo:6:007:1 -115:1:217633 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288977485 C Zo:6:007:1 0:1:217634:0 1 0:0:176 176 >
8801549cca80 288977503 S Zo:6:007:1 -115:1:217634 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288978491 C Zo:6:007:1 0:1:217635:0 1 0:0:176 176 >
8801549cc780 288978506 S Zo:6:007:1 -115:1:217635 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cca80 288979481 C Zo:6:007:1 0:1:217636:0 1 0:0:176 176 >
8801549cca80 288979489 S Zo:6:007:1 -115:1:217636 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff
8801549cc780 288980484 C Zo:6:007:1 0:1:217637:0 1 0:0:176 176 >
8801549cc780 288980493 S Zo:6:007:1 -115:1:217637 1 -18:0:176 176 =
00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00ff 00ff00
Re: [RFC PATCH v2 1/4] retu-mfd: support also Tahvo
Hi Aaro, On Tue, Apr 09, 2013 at 10:51:25PM +0300, Aaro Koskinen wrote: > Tahvo is a multi-function device on Nokia 770, implementing USB > transceiver and charge/battery control. > > It's so close to Retu that a single driver can support both. > > Signed-off-by: Aaro Koskinen > Cc: Samuel Ortiz > --- > drivers/mfd/Kconfig |6 ++-- > drivers/mfd/retu-mfd.c | 85 > -- > include/linux/mfd/retu.h |8 - > 3 files changed, 85 insertions(+), 14 deletions(-) Simple and good enough, I applied this one. 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: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
Hello. On 04/18/2013 06:05 PM, Simon Horman wrote: Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'. Enable USB storage driver and SCSI disk driver that it needs as well... Signed-off-by: Sergei Shtylyov I realise that this is not going to be useful until the rest of the series has been merged. But regardless I have pre-emptively queued it up for v3.11 in the defconfig-bockw branch. --- arch/arm/configs/bockw_defconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) Index: renesas/arch/arm/configs/bockw_defconfig === --- renesas.orig/arch/arm/configs/bockw_defconfig +++ renesas/arch/arm/configs/bockw_defconfig @@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y # CONFIG_NET_CADENCE is not set # CONFIG_NET_VENDOR_BROADCOM is not set @@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6 CONFIG_SERIAL_SH_SCI_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set -# CONFIG_USB_SUPPORT is not set +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PLATFORM=y +CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_STORAGE=y +CONFIG_USB_RCAR_PHY=y Unfortunately, you've made a mistake in this last line of the patch: you've truncated it to just "CONFIG_USB_RCAR". :-( Will you correct it? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net,stable 3/3] net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround)
We normally trust and use the CDC functional descriptors provided by a
number of devices. But some of these will erroneously list the address
reserved for the device end of the link. Attempting to use this on
both the device and host side will naturally not work.
Work around this bug by ignoring the functional descriptor and assign a
random address instead in this case.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index cff0bbd..2a3579f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -53,6 +53,9 @@ struct qmi_wwan_state {
struct usb_interface *data;
};
+/* default ethernet address used by the modem */
+static const u8 default_modem_addr[ETH_ALEN] = {0x02, 0x50, 0xf3};
+
/* Make up an ethernet header if the packet doesn't have one.
*
* A firmware bug common among several devices cause them to send raw
@@ -317,6 +320,12 @@ next_desc:
usb_driver_release_interface(driver, info->data);
}
+ /* Never use the same address on both ends of the link, even
+* if the buggy firmware told us to.
+*/
+ if (!compare_ether_addr(dev->net->dev_addr, default_modem_addr))
+ eth_hw_addr_random(dev->net);
+
/* make MAC addr easily distinguishable from an IP header */
if (possibly_iphdr(dev->net->dev_addr)) {
dev->net->dev_addr[0] |= 0x02; /* set local assignment bit */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net,stable 2/3] net: qmi_wwan: fixup destination address (firmware bug workaround)
Received packets are sometimes addressed to 00:a0:c6:00:00:00
instead of the address the device firmware should have learned
from the host:
321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request
id=0x4025, seq=64/16384, ttl=64
82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00 .g.g..E.
0010 00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a .T..@.@.W.M.U..z
0020 ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00 b.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .. !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply
id=0x4025, seq=64/16384, ttl=55
00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00 ...P..E.
0010 00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10 .T.V..7..v.z..M.
0020 55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00 U...j.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .. !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
The bogus address is always the same, and matches the address
suggested by many devices as a default address. It is likely a
hardcoded firmware default.
The circumstances where this bug has been observed indicates that
the trigger is related to timing or some other factor the host
cannot control. Repeating the exact same configuration sequence
that caused it to trigger once, will not necessarily cause it to
trigger the next time. Reproducing the bug is therefore difficult.
This opens up a possibility that the bug is more common than we can
confirm, because affected devices often will work properly again
after a reset. A procedure most users are likely to try out before
reporting a bug.
Unconditionally rewriting the destination address if the first digit
of the received packet is 0, is considered an acceptable compromise
since we already have to inspect this digit. The simplification will
cause unnecessary rewrites if the real address starts with 0, but this
is still better than adding additional tests for this particular case.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d8a50c7..cff0bbd 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -68,6 +68,10 @@ struct qmi_wwan_state {
* This means that this function will reliably add the appropriate
* header iff necessary, provided our hardware address does not start
* with 4 or 6.
+ *
+ * Another common firmware bug results in all packets being addressed
+ * to 00:a0:c6:00:00:00 despite the host address being different.
+ * This function will also fixup such packets.
*/
static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
@@ -84,6 +88,12 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
case 0x60:
proto = htons(ETH_P_IPV6);
break;
+ case 0x00:
+ if (is_multicast_ether_addr(skb->data))
+ return 1;
+ /* possibly bogus destination - rewrite just in case */
+ skb_reset_mac_header(skb);
+ goto fix_dest;
default:
/* pass along other packets without modifications */
return 1;
@@ -94,6 +104,7 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
skb_reset_mac_header(skb);
eth_hdr(skb)->h_proto = proto;
memset(eth_hdr(skb)->h_source, 0, ETH_ALEN);
+fix_dest:
memcpy(eth_hdr(skb)->h_dest, dev->net->dev_addr, ETH_ALEN);
return 1;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net,stable 0/3] qmi_wwan: working around 3 serious firmware bugs
This series adds workarounds for 3 different firmware bugs, each preventing the affected devices from working at all. I therefore humbly request that these fixes go to stable-3.8 (if still maintained) and 3.9 (either via net if still possible, or via stable if not). All 3 workarounds are applied to all devices supported by the driver. Adding quirks for specific devices was considered as an alternative, but was rejected because we have too little information about the exact distribution of the buggy firmwares. All we know is that the same bug shows up in devices from at least 3 different, and presumably independent, vendors. The workarounds have instead been designed to automatically apply when necessary, and to have as little impact as possible on unaffected devices. The series has been tested on a number of devices both with and without these bugs. The series should apply cleanly to net/master, net-next/master and stable/linux-3.8.y Thanks, Bjørn Bjørn Mork (3): net: qmi_wwan: fixup missing ethernet header (firmware bug workaround) net: qmi_wwan: fixup destination address (firmware bug workaround) net: qmi_wwan: prevent duplicate mac address on link (firmware bug workaround) drivers/net/usb/qmi_wwan.c | 104 1 file changed, 104 insertions(+) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net,stable 1/3] net: qmi_wwan: fixup missing ethernet header (firmware bug workaround)
A number of LTE devices from different vendors all suffer from the
same firmware bug: Most of the packets received from the device while
it is attached to a LTE network will not have an ethernet header. The
devices work as expected when attached to 2G or 3G networks, sending
an ethernet header with all packets.
This driver is not aware of which network the modem attached to, and
even if it were there are still some packet types which are always
received with the header intact.
All devices supported by this driver have severely limited
networking capabilities:
- can only transmit IPv4, IPv6 and possibly ARP
- can only support a single host hardware address at any time
- will only do point-to-point communcation with the host
Because of this, we are able to reliably identify any bogus raw IP
packets by simply looking at the 4 IP version bits. All we need to
do is to avoid 4 or 6 in the first digit of the mac address. This
workaround ensures this, and fix up the received packets as necessary.
Given the distribution of the bug, it is believed that the source is
the chipset vendor. The devices which are verified to be affected are:
Huawei E392u-12 (Qualcomm MDM9200)
Pantech UML290 (Qualcomm MDM9600)
Novatel USB551L (Qualcomm MDM9600)
Novatel E362(Qualcomm MDM9600)
It is believed that the bug depend on firmware revision, which means
that possibly all devices based on the above mentioned chipset may be
affected if we consider all available firmware revisions.
The information about affected devices and versions is likely
incomplete. As the additional overhead for packets not needing this
fixup is very small, it is considered acceptable to apply the
workaround to all devices handled by this driver.
Reported-by: Dan Williams
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 84
1 file changed, 84 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 968d5d5..d8a50c7 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -52,6 +53,82 @@ struct qmi_wwan_state {
struct usb_interface *data;
};
+/* Make up an ethernet header if the packet doesn't have one.
+ *
+ * A firmware bug common among several devices cause them to send raw
+ * IP packets under some circumstances. There is no way for the
+ * driver/host to know when this will happen. And even when the bug
+ * hits, some packets will still arrive with an intact header.
+ *
+ * The supported devices are only capably of sending IPv4, IPv6 and
+ * ARP packets on a point-to-point link. Any packet with an ethernet
+ * header will have either our address or a broadcast/multicast
+ * address as destination. ARP packets will always have a header.
+ *
+ * This means that this function will reliably add the appropriate
+ * header iff necessary, provided our hardware address does not start
+ * with 4 or 6.
+ */
+static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ __be16 proto;
+
+ /* usbnet rx_complete guarantees that skb->len is at least
+* hard_header_len, so we can inspect the dest address without
+* checking skb->len
+*/
+ switch (skb->data[0] & 0xf0) {
+ case 0x40:
+ proto = htons(ETH_P_IP);
+ break;
+ case 0x60:
+ proto = htons(ETH_P_IPV6);
+ break;
+ default:
+ /* pass along other packets without modifications */
+ return 1;
+ }
+ if (skb_headroom(skb) < ETH_HLEN)
+ return 0;
+ skb_push(skb, ETH_HLEN);
+ skb_reset_mac_header(skb);
+ eth_hdr(skb)->h_proto = proto;
+ memset(eth_hdr(skb)->h_source, 0, ETH_ALEN);
+ memcpy(eth_hdr(skb)->h_dest, dev->net->dev_addr, ETH_ALEN);
+ return 1;
+}
+
+/* very simplistic detection of IPv4 or IPv6 headers */
+static bool possibly_iphdr(const char *data)
+{
+ return (data[0] & 0xd0) == 0x40;
+}
+
+/* disallow addresses which may be confused with IP headers */
+static int qmi_wwan_mac_addr(struct net_device *dev, void *p)
+{
+ int ret;
+ struct sockaddr *addr = p;
+
+ ret = eth_prepare_mac_addr_change(dev, p);
+ if (ret < 0)
+ return ret;
+ if (possibly_iphdr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+ eth_commit_mac_addr_change(dev, p);
+ return 0;
+}
+
+static const struct net_device_ops qmi_wwan_netdev_ops = {
+ .ndo_open = usbnet_open,
+ .ndo_stop = usbnet_stop,
+ .ndo_start_xmit = usbnet_start_xmit,
+ .ndo_tx_timeout = usbnet_tx_timeout,
+ .ndo_change_mtu = usbnet_change_mtu,
+ .ndo_set_mac_address= qmi_wwan_mac_addr,
+ .ndo_validate_addr = eth_validate_addr,
+};
+
/* using a counter to mer
Re: [PATCH v2 0/9] Reorganize R8A7779/Marzen USB code
Hi Sergei > > >>> I'm going to post R8A7778/BOCK-W series following this one, and > > >>> all the > > >>> patches in 1st series should additionally be tested on BOCK-W. Well, I > > >>> probably can hold up posting version 3 until I have the second > > >>> series verified. > > >>> BTW, about R8A7778/BOCK-W, R-Car M1A user manual talks about a > > >>> ferrite > > >>> bead in 49.4.1 (3) Setting USB-PHY. Do you know for sure if it's > > >>> used or not > > >>> on BOCK-W board? PHY initialization seems to work with either > > >>> settings... > > >> I can ask it to HW team if you want me. > > > > Yes, ask them please. > > Now, I'm asking it to HW team > Please wait According to HW team, this setting is for some kind of USB compliance test (?). So, in general, we can use "No ferrite bead". Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH usb-next] usb: storage: Fix link error
On Thu, Apr 18, 2013 at 02:17:14PM -0700, Joe Perches wrote:
> Fix allmodconfig link error introduced by commit 75b9130e8a
> ("usb: storage: Add usb_stor_dbg, reduce object size")
>
> Export the symbol usb_stor_dbg.
> Add export.h
>
> Signed-off-by: Joe Perches
> ---
> drivers/usb/storage/debug.c | 2 ++
> 1 file changed, 2 insertions(+)
You forgot the "Reported-by:" line :(
I'll go add it now, thanks for the quick fix-up patch.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] ARM: shmobile: BOCK-W: enable USB in defconfig
On Fri, Apr 19, 2013 at 02:50:05AM +0400, Sergei Shtylyov wrote: > Hello. > > On 04/18/2013 06:05 PM, Simon Horman wrote: > > > > >>Enable USB platform EHCI/OHCI and common PHY drivers in 'bockw_defconfig'. > >>Enable USB storage driver and SCSI disk driver that it needs as well... > >> > >>Signed-off-by: Sergei Shtylyov > >I realise that this is not going to be useful until the rest > >of the series has been merged. But regardless I have pre-emptively > >queued it up for v3.11 in the defconfig-bockw branch. > >>--- > >> arch/arm/configs/bockw_defconfig | 11 ++- > >> 1 file changed, 10 insertions(+), 1 deletion(-) > >> > >>Index: renesas/arch/arm/configs/bockw_defconfig > >>=== > >>--- renesas.orig/arch/arm/configs/bockw_defconfig > >>+++ renesas/arch/arm/configs/bockw_defconfig > >>@@ -48,6 +48,8 @@ CONFIG_DEVTMPFS_MOUNT=y > >> # CONFIG_STANDALONE is not set > >> # CONFIG_PREVENT_FIRMWARE_BUILD is not set > >> # CONFIG_FW_LOADER is not set > >>+CONFIG_SCSI=y > >>+CONFIG_BLK_DEV_SD=y > >> CONFIG_NETDEVICES=y > >> # CONFIG_NET_CADENCE is not set > >> # CONFIG_NET_VENDOR_BROADCOM is not set > >>@@ -71,7 +73,14 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=6 > >> CONFIG_SERIAL_SH_SCI_CONSOLE=y > >> # CONFIG_HW_RANDOM is not set > >> # CONFIG_HWMON is not set > >>-# CONFIG_USB_SUPPORT is not set > >>+CONFIG_USB=y > >>+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > >>+CONFIG_USB_EHCI_HCD=y > >>+CONFIG_USB_OHCI_HCD=y > >>+CONFIG_USB_OHCI_HCD_PLATFORM=y > >>+CONFIG_USB_EHCI_HCD_PLATFORM=y > >>+CONFIG_USB_STORAGE=y > >>+CONFIG_USB_RCAR_PHY=y > >> > >Unfortunately, you've made a mistake in this last line of the patch: > you've truncated it to just "CONFIG_USB_RCAR". :-( >Will you correct it? Sorry about that, I will fix it. -- 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] usbatm: fix potential NULL pointer dereference
From: Wei Yongjun
The dereference to 'instance' in the debug code should be moved
below the NULL test.
Signed-off-by: Wei Yongjun
---
drivers/usb/atm/usbatm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index 35f10bf..d3527dd 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -672,9 +672,6 @@ static int usbatm_atm_send(struct atm_vcc *vcc, struct
sk_buff *skb)
struct usbatm_control *ctrl = UDSL_SKB(skb);
int err;
- vdbg(&instance->usb_intf->dev, "%s called (skb 0x%p, len %u)", __func__,
-skb, skb->len);
-
/* racy disconnection check - fine */
if (!instance || instance->disconnected) {
#ifdef DEBUG
@@ -684,6 +681,9 @@ static int usbatm_atm_send(struct atm_vcc *vcc, struct
sk_buff *skb)
goto fail;
}
+ vdbg(&instance->usb_intf->dev, "%s called (skb 0x%p, len %u)", __func__,
+skb, skb->len);
+
if (vcc->qos.aal != ATM_AAL5) {
atm_rldbg(instance, "%s: unsupported ATM type %d!\n", __func__,
vcc->qos.aal);
err = -EINVAL;
--
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, >> I modified the UDC driver to send out zero length data packet. Now the >> linux host is able to see the USB gadget as a mass storage device and >> read from USB gadget. However, writing to USB gadget fails. The >> SCSI_WRITE_10 command often receives (-104). The usbmon trace showing >> this failure is attached. Is the bulk-out endpoint unable to receive >> command and data continuously, due to error in UDC driver? > > It looks like the data gets received okay. I can't tell what's going > wrong because you did not post the gadget log showing the WRITE > commands. When writing to USB gadget from Linux host, the SCSI_WRITE_10 command is sent out from the Linux host, but the USB gadget receives zero length packet. And after a long wait of 30 seconds, the Linux host resets the connection (-104). The usbmon trace and the UDC driver log are attached. g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 I think UDC driver receives the zero length packet on bulk out endpoint. Thanks, victor # dmesg [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000<7>g_file_storage gadget: bulk_out_complete --> 0, 0/31 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete --> 0, 0/31 [start_transfer] 43425355 c5 ept1 out queue len 0x200, buffer 0xc133c000 g_file_storage gadget: bulk-out, length 0: usbmon_write_gadget2.log Description: Binary data
