Re: [RFC 0/2] target refcounting infrastructure fixes for usb
Hi, On 01/03/2014 01:45 AM, Sarah Sharp wrote: On Sat, Dec 21, 2013 at 03:51:25PM -0500, Alan Stern wrote: On Fri, 20 Dec 2013, Sarah Sharp wrote: On Thu, Dec 19, 2013 at 11:48:47AM -0800, James Bottomley wrote: It should apply incrementally on top of the previous two. If it actually works, I'll fold it into the first patch. Well, it doesn't oops anymore, but it does generate a pile of warnings: This was a simple oversight. scsi_target_reap() was called at the start of __scsi_remove_device(), but it should be called at the end. The patch below, applied on top of James's three patches, will fix the warnings. Alan Stern P.S.: The comment isn't entirely correct any more... Ok, Alan's additional patch fixed the warnings I was seeing on UAS device unplug. James, can you Cc me on the finished patch when you send it in? Hans, I don't want to send the UAS patches off to Greg until James' patches get into mainline. I believe Greg's usb-next tree is frozen at this point, so they'll have to wait until 3.15. Ugh, I must say I'm rather unhappy about this, waiting till 3.14 to give time to shake things out was fine. But since the start of the 3.13 cycle, there have been no issues found in the xhci / uas code. Yes it triggered an existing problem in another subsys, but the code itself has been issue free all this time. If Greg's tree is indeed already frozen I would rather have us asking an exception for this. Alternatively we could add all of it to 3.14 except for the patch removing the BROKEN marking from uas. Or at least all the non uas bits, which are useful to have by themselves. James, what is the status of getting the fix for the refcount issue into mainline ? Regards, Hans -- 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] usb: gadget: printer: using gadget_is_otg to check otg support at runtime
We need to use gadget_is_otg to check if the gadget is really
otg support at runtime, other composite gadget drivers have already
followed this method.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/printer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index bf7a56b..69b76ef 100644
--- a/drivers/usb/gadget/printer.c
+++ b/drivers/usb/gadget/printer.c
@@ -1157,7 +1157,7 @@ static int __init printer_bind_config(struct
usb_configuration *c)
usb_gadget_set_selfpowered(gadget);
- if (gadget-is_otg) {
+ if (gadget_is_otg(gadget)) {
otg_descriptor.bmAttributes |= USB_OTG_HNP;
printer_cfg_driver.descriptors = otg_desc;
printer_cfg_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
--
1.7.8
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2 6/6] r8152: support RTL8153
hayeswang hayesw...@realtek.com writes:
Bjørn Mork [mailto:bj...@mork.no]
Sent: Thursday, January 02, 2014 10:25 PM
To: Hayeswang
Cc: oli...@neukum.org; net...@vger.kernel.org; nic_swsd;
linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
Subject: Re: [PATCH net-next v2 6/6] r8152: support RTL8153
[...]
+#if defined(CONFIG_USB_RTL8152) ||
defined(CONFIG_USB_RTL8152_MODULE)
+/* Samsung USB Ethernet Adapters */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
0xa101, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+#endif
We don't play the if-other-driver-is-enabled for any other of the
blacklisted devices, including other devices supported by the RTL8152
driver. Why do we need it here?
The USB nic have two configurations. One is the config 2 which is the ECM
mode and uses the driver of cdc_ether. The other is the config 1 which use
the driver of r8152.
Sorry, but then this makes even less sense. The active USB
configuration is user selectable and you should make any of them work if
possible. Why can't the drivers figure out this at runtime?
When the dangle is plugged, I find the configuration
is 2 and the ECM driver would be loaded.
The USB core will normally select cfg #1, but prefers classful
configurations over vendor-specific ones. It will loop through all
possible configurations looking at the first interface of each of them,
and then select the first one with a class different from 0xff.
So what you write above indicates that the first interface of cfg #1 is
vendor specific. But this doesn't seem to match the r815x driver, so I
don't quite understand the layout here.
In any case, if your device provides two _different_ functions in
different configurations, but using the exact class, subclass and
protocol, then I'd call that device buggy. If at least one of these are
different, then it shouldn't be a problem making the respective drivers
match these functions.
By this way, you could select
which mode you want to run. Some people would select ECM mode for
performance, and the other would select r8152 for power saving.
Build time driver selection is useless. All distros will enable all
drivers. End users don't build kernels. That ended sometime around the
release of Linux 2.2
Bjørn
--
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 04/16] USB: pl2303: switch to generic TIOCMIWAIT implementation
On Thursday 02 January 2014, Johan Hovold wrote: Switch to the generic TIOCMIWAIT implementation which does not suffer from the races involved when using the deprecated sleep_on functions. Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Johan Hovold jhov...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC 15/30] usbserial: stop using interruptible_sleep_on
On Thursday 02 January 2014, Johan Hovold wrote: I'd prefer to just fix the race once and for all. These four drivers have been on my todo list since I converted the other usb-serial drivers about a year ago. In fact, I posted a fix for f81232 last week, and I've had a fix for pl2303 brewing as part of larger series for quite some time. I'll post a conversion series to linux-usb shortly and make sure to keep you CC:ed on the sleep_on-killing patches. Ah, excellent! Much better to see the job done properly than me adding more hacks on top. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/16] USB: cypress_m8: switch to generic TIOCMIWAIT implementation
On Thursday 02 January 2014, Johan Hovold wrote: Switch to the generic TIOCMIWAIT implementation which does not suffer from the races involved when using the deprecated sleep_on functions. Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Johan Hovold jhov...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] USB: ch341: switch to generic TIOCMIWAIT implementation
On Thursday 02 January 2014, Johan Hovold wrote: Switch to the generic TIOCMIWAIT implementation which does not suffer from the races involved when using the deprecated sleep_on functions. Cc: Arnd Bergmann a...@arndb.de Signed-off-by: Johan Hovold jhov...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] target refcounting infrastructure fixes for usb
On Fri, 2014-01-03 at 09:56 +0100, Hans de Goede wrote: James, what is the status of getting the fix for the refcount issue into mainline ? The plan is what I wrote in the patch intro: Since it's a major change to the infrastructure, we'll incubate upstream first before backporting to stable. That means with the merge window and delayed stable backport to make sure it's sound. James -- 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: gadgetfs USB2.0 Chapter 9 Tests: Test after Addressed State fails
Thank you Roshan for the patch and thank you Michal for the discussion! Appearently I am not as familiar with USB as you guys are. But what I understood from the discussion is, that if I apply the patch from Roshan to f_fs.c and composite.c, the CV Test should not fail? Thanks! On Tue, Dec 24, 2013 at 5:14 PM, Michal Nazarewicz min...@mina86.com wrote: This is a bug in user space. FUNCTIONFS_DISABLE event means the host has chosen a configuration with given function disabled. User-space should clean up it's state, as any pending requests of any kind are now invalid. It should not close all of the ep files. On Tue, Dec 24 2013, roshan.jhal...@broadcom.com wrote: Then, I would say this bug exists in both Android 4.2 and Android 4.4 version. But we are facing issue in Android 4.4 because kernel uses FunctionFs instead of f_adb.c. That may be the case. Do you think this should be ONLY fixed in user space or we can avoid all ep releases in kernel? I think this should be fixed in user space since kernel space behaves as it always has and as advertised[1]. Changing the behaviour would change the ABI and risk situations that when a user space daemon crashes, gadget's USB configuration becomes dysfunctional for the host. Perhaps it would make sense in some cases for the FunctionFS to hang on even when all files are closed, but I don't think the issue you've described justifies such a change, since it's easily fixed in user space (a quick hack is to simply dup() ep0 and never close it). [1] See Documentation/usb/functionfs.txt: When all files are closed the function disables itself. Perhaps the documentation should be made clearer here though. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo-- -- 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 2/2] dual scan thread bug fix
On Thu, 2 Jan 2014, James Bottomley wrote:
In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it. In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.
Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.
I'm still concerned about one thing. The previous patch does this in
scsi_alloc_target():
found:
- found_target-reap_ref++;
+ if (!kref_get_unless_zero(found_target-reap_ref))
+ /*
+ * release routine already fired. Target is dead, but
+ * STARGET_DEL may not yet be set (set in the release
+ * routine), so set here as well, just in case
+ */
+ found_target-state = STARGET_DEL;
spin_unlock_irqrestore(shost-host_lock, flags);
As a result, the two comments in this patch aren't right:
@@ -384,9 +385,15 @@ static void scsi_target_reap_ref_release(struct kref
*kref)
struct scsi_target *starget
= container_of(kref, struct scsi_target, reap_ref);
- transport_remove_device(starget-dev);
- device_del(starget-dev);
- starget-state = STARGET_DEL;
+ /*
+ * if we get here and the target is still in the CREATED state that
+ * means it was allocated but never made visible (because a scan
+ * turned up no LUNs), so don't call device_del() on it.
+ */
+ if (starget-state == STARGET_RUNNING) {
+ transport_remove_device(starget-dev);
+ device_del(starget-dev);
+ }
Here the state could already be STARGET_DEL, even though the target is
still visible.
Also, it's a little odd that the comment talks about CREATED but the
code really checks for RUNNING. They should be consistent.
@@ -506,11 +513,13 @@ static struct scsi_target *scsi_alloc_target(struct
device *parent,
*/
void scsi_target_reap(struct scsi_target *starget)
{
+ /*
+ * serious problem if this triggers: STARGET_DEL is only set in the
+ * kref release routine, so we're doing another final put on an
+ * already released kref
+ */
BUG_ON(starget-state == STARGET_DEL);
Here the code is okay but the comment is wrong: STARGET_DEL is set in
_two_ places (but neither of them runs until reap_ref has reached 0).
Would it be better in scsi_alloc_target() to behave as though the state
were STARGET_DEL without actually setting it?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmotm 2014-01-02-14-35 uploaded (musb)
On 01/02/14 14:36, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2014-01-02-14-35 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. on x86_64: when CONFIG_USB is not enabled: drivers/built-in.o: In function `musb_init': musb_core.c:(.init.text+0x45fc): undefined reference to `usb_disabled' Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.13.0-rc6-mm1 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_KERNEL_LZ4=y CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SYSVIPC is not set # CONFIG_FHANDLE is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_CONTEXT_TRACKING=y CONFIG_RCU_USER_QS=y # CONFIG_CONTEXT_TRACKING_FORCE is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y CONFIG_RCU_FAST_NO_HZ=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_ARCH_USES_NUMA_PROT_NONE=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_NUMA_BALANCING=y # CONFIG_CGROUPS is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set CONFIG_UIDGID_STRICT_TYPE_CHECKS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set CONFIG_BUG=y # CONFIG_PCSPKR_PLATFORM is not set # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y CONFIG_SHMEM=y # CONFIG_AIO is not set # CONFIG_EMBEDDED is not set
Re: [PATCH v1] xhci: Switch Intel Lynx Point ports to EHCI on shutdown
On 01/03/2014 01:03 AM, Sarah Sharp wrote: ISTR that the other folks on Cc (Meng, Niklas, Giorgos, and Art) all had systems that broke when commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 was introduced. For those systems, what vendor was the system, and what BIOS was it running? Information from dmidecode: BIOS Information Vendor: American Megatrends Inc. System Information Manufacturer: To Be Filled By O.E.M. Product Name: To Be Filled By O.E.M. Version: To Be Filled By O.E.M. Base Board Information Manufacturer: ASRock Product Name: B85 Pro4 -- 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.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me
know.
--
From: David Laight david.lai...@aculab.com
commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link
TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for
example,
the USB3 ethernet ax88179_178a card will stop sending...
Unfortunately this patch causes a regression when copying large files to my
outboard USB3 drive. (Nothing at all to do with networking.)
Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
dmesg output from this statement shortly before your drive fails:
if (num_trbs = TRBS_PER_SEGMENT) {
xhci_err(xhci, Too many fragments %d, max %d\n,
num_trbs, TRBS_PER_SEGMENT - 1);
return -ENOMEM;
}
Well, the answers depend on whether the usb3 drive uses logical volumes or not
(lvm2), which I can't explain. What I've described so far is with lvm2.
When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect -- the
console prints two or three lines stating that the ext4 journal has quit and
the drive is remounted ro. That particular drive stays wedged until the next
reboot, but no other ill effects to the system.
Odd. In 3.12 xHCI has dynamic debugging, and turning on CONFIG_USB_DEBUG
should turn on debugging by default, so it's confusing that you didn't
see any messages.
Can I see your .config from /boot/? Also, did you try capturing dmesg
with `tail -f /var/log/kern.log` or just dmesg? Perhaps you need to run
`sudo dmesg -n 7`?
OTOH, when I put a disk with just an ordinary ext4 partition in the usb3 dock,
(no logical volumes) the copy failure becomes catastrophic, with kernel panic
messages, leaving the system unresponsive and needing a hard reset to recover.
I also tried your other suggestion:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48..1a6a43d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4714,7 +4714,7 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
int retval;
/* Accept arbitrarily long scatter-gather lists */
- hcd-self.sg_tablesize = ~0;
+ hcd-self.sg_tablesize = 31;
/* support to build packet from discontinuous buffers */
hcd-self.no_sg_constraint = 1;
Sadly it didn't fix the problem. Did I get the patch right?
Yes, you did. So perhaps the patch triggers a different bug. I can't
tell until I see xHCI debugging output.
Thanks for your help, and I'm happy to try more ideas, as always.
Thanks for your patience. :)
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
Re: mmotm 2014-01-02-14-35 uploaded (musb)
On Fri, Jan 03, 2014 at 09:57:50AM -0800, Randy Dunlap wrote:
On 01/02/14 14:36, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2014-01-02-14-35 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
on x86_64:
when CONFIG_USB is not enabled:
drivers/built-in.o: In function `musb_init':
musb_core.c:(.init.text+0x45fc): undefined reference to `usb_disabled'
already have a patch for that. Waiting for Greg to merge ;-)
commit 89f836a8c56bfea6585a09f7afff7094968a4fd0
Author: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Date: Thu Dec 26 09:24:52 2013 -0300
usb: musb: Remove usb_disable() check in module_init()
Removing the check to usb_disable() before registering the platform
driver allows to build this driver when !USB USB_GADGET, to be
used in gadget-only mode.
Also, use module_platform_driver() to register the platform driver.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0e7f4a0..5942f00 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2325,19 +2325,4 @@ static struct platform_driver musb_driver = {
.shutdown = musb_shutdown,
};
-/*-*/
-
-static int __init musb_init(void)
-{
- if (usb_disabled())
- return 0;
-
- return platform_driver_register(musb_driver);
-}
-module_init(musb_init);
-
-static void __exit musb_cleanup(void)
-{
- platform_driver_unregister(musb_driver);
-}
-module_exit(musb_cleanup);
+module_platform_driver(musb_driver);
--
balbi
signature.asc
Description: Digital signature
Re: xHCI driver Bug report (Babble reported at enumeration for cam that works in Windows)
On Fri, Jan 03, 2014 at 12:48:26AM +, Marius Silaghi wrote:
Thanks
Running 3.12.4
During the holiday I managed to solve my problem with the following small
patch (could it be added to the mainstream kernel such that it would be
solved when we upgrade to the future kernels?):
Hi Marius,
Please try the patch I pointed you to instead of your patch. Dan's
patch may have the same impact yours does, and I need to know whether
his patch helps, since that's what's currently queued for the upcoming
3.14 kernel.
Sarah Sharp
Signed-off-by: Marius C Silaghi msila...@fit.edu
---
--- linux/drivers/usb/core/hub.c.orig 2013-12-23 22:09:50.545093470 -0500
+++ linux/drivers/usb/core/hub.c2013-12-23 22:29:40.521043702 -0500
@@ -4197,7 +4197,19 @@ hub_port_init (struct usb_hub *hub, stru
break;
}
- retval = usb_get_device_descriptor(udev, 8);
+ /* Try first the old 8-byte query (since it may be expected
+* by some devices), but then give at least a chance to the
+* new form (retrieving the whole descriptor)!
+* Querying the content of the whole structure is required
+* for older USB2 video cameras which do not support partial
+* descriptor queries, like the STC-XXXUSB family.
+* Windows also supports them.
+*/
+ if (USE_NEW_SCHEME(retry_counter))
+ retval = usb_get_device_descriptor(udev, 8);
+ else
+ retval = usb_get_device_descriptor(udev,
+ sizeof(struct usb_device_descriptor));
if (retval 8) {
if (retval != -ENODEV)
dev_err(udev-dev,--
From: Sarah Sharp [sarah.a.sh...@linux.intel.com]
Sent: Thursday, January 02, 2014 19:24
To: Marius Silaghi
Cc: linux-usb-ow...@vger.kernel.org
Subject: Re: xHCI driver Bug report (Babble reported at enumeration for cam
that works in Windows)
On Sat, Dec 21, 2013 at 04:40:21PM +, Marius Silaghi wrote:
Hi Marius,
There is a bug in xHCI. The camera STC-MC33USB that is recognized on the
same computerport with Windows fails to be enumerated with Babble (-75).
I recompiled the kernel with DEBUG on for XHCI and DEBUG_USB.
I attach the following files:
- dmesg_cam_connect (cat /proc/kmsg output during plugging the USB
connector)
- dmesg_cam_disconnect_and_poll (cat /proc/kmsg during a normal xhci ring
poll and then a camera usb unplugging)
-lsusb_ehci_Sentech (lsusb -v on a system with ahci where the camera is
recognized)
-lsusb_ehci_nothing (lsusb -v on the same system with ahci with nothing
plugged in)
-lsusb_xhci_Sentech (lsusb -v on the system with xhci where the camera is
recognized)
-lsusb_xhci_nothing (lsusb -v on the same system with xhci with nothing
plugged in)
Thanks for the bug report. Which kernel version are you running?
I think this issue might be fixed in a patch that's queued for the 3.14
kernel. Can you apply the following patch to 3.13-rc6 and see if it
helps?
http://marc.info/?l=linux-usbm=138672064109890w=2
If you need directions on how to compile a custom kernel, please see
http://kernelnewbies.org/KernelBuild
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
Re: Similar Elan Touchscreen reset behaviour
On Fri, 3 Jan 2014, Eric Decker wrote: On Fri, Jan 3, 2014 at 7:46 AM, Alan Stern st...@rowland.harvard.eduwrote: On Thu, 2 Jan 2014, Sarah Sharp wrote: On Sun, Dec 29, 2013 at 06:28:20AM -0800, Eric Decker wrote: When I boot using a live USB (the kernel in this case is vmlinuz-3.11.0.12-generic), I see a couple of messages and then the kernel finishes (that is it doesn't hang). *Although the number of reattaches seems suspect.* By reattaches, do you mean that the ELAN touchscreen disconnects from the USB bus and then reconnects? I see messages saying that the device is disconnected. It doesn't say why so I don't know if the the ELAN h/w is doing it or not. That was a what question, not why. _What_ do you mean by reattaches? _What_ device is mentioned in those messages? If you get different behavior at different times using the same software, then most likely it's an intermittent hardware problem. So I took my current installed kernel Linux zot 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux And rebooted like 4 times in a row. The behaviour is the same. Okay. I thought you said before that it had trouble finishing the boot process and that later on it was behaving itself. The infinite loop happened with different s/w. It was a grub environment booting a casper image of some type. The boot environment should not matter. I don't know what casper is. I've looked at the log from the reboots mentioned above and they all look the same. I think something is tickling the ELAN h/w in someway. I've been keeping an eye on the logs and haven't seen any misbehaviour on the part of the touch screen. Its not acting like it is an intermittent. It is acting like a complex bug of somekind. One that we don't have enough visibility on. I'm happy to try and find out what is going on but I am not far enough up the learning curve to know what to look at. I've done embedded and h/w/s/w kinds of things for a long time (4th s/w engineer at cisco) so know my way around just not on this stuff. So if you point me in the right direction, that would be a big help. I've enclosed both a summary that I've pulled out from the syslog of the reboots as well as the syslog You can try running usbmon (see the instructions in Documentation/usb/usbmon.txt) to see what happens during one of those disconnect/reconnect cycles. 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
XHCI (possible) bug
Hi Sarah, I'm running v3.12.1 on my desktop pc and today I got into rather weird state when I was testing an old OMAP3 platform (as device) connected trough xHCI. Even after disconnecting the device, I still see it as if it was still present on the bus. All I was doing was connecting and disconnecting the device while a tool I'm writing (to cold-boot old OMAP3 platforms) was searching for that device in the bus so it could transfer data. After quite a few iterations, I noticed that the device was not vanishing from the bus anymore. Does that ring any bell ? Perhaps it has been fixed already and I just need to upgrade my desktop pc kernel :-) I can try to reproduce with full dmesg, if you need, but it'll take me a few days to get back to this since I got some other stuff to finish up. cheers ps: xHCI is still working just fine, I can still enumerate my USB3 SD Card reader, can transfer data to my USB3 external HDD and, if I ignore the stale OMAP3 device, I can still talk to my board. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] Chipidea Fix for 3.13-rc2
On Fri, Dec 27, 2013 at 01:37:48PM +0800, Peter Chen wrote: On Thu, Dec 05, 2013 at 03:20:48PM +0800, Peter Chen wrote: Hi Greg, This patchset includes chipidea fixes for 3.13-rc2, the mainly fixes include add correct imx28 write register method, fixing un-initialized variable, etc. Chris Ruehl (2): usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag usb: chipidea: put hw_phymode_configure before ci_usb_phy_init Fabio Estevam (1): usb: chipidea: host: Only disable the vbus regulator if it is not NULL Peter Chen (4): usb: chipidea: fix nobody cared IRQ when booting with host role usb: ehci: add freescale imx28 special write register method usb: chipidea: add freescale imx28 special write register method usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28 Hi Greg, usb: chipidea: host: Only disable the vbus regulator if it is not NULL usb: chipidea: fix nobody cared IRQ when booting with host role The above 2 patches are already at your usb-linus three. I will take 2 Chris's patches to 3.14, the below three imx28 special write patches are needed for 3.13 if the time is admitted. Thanks. It's too late for 3.13, sorry, please resend them for 3.14. 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 patches for v3.14 merge window
On Thu, Dec 26, 2013 at 04:36:59PM -0600, Felipe Balbi wrote: Hi Greg, Here's my overly extensive pull request for v3.14 merge window. Lots of work has happened for next merge window. All patches have been tested with all ARM defconfigs, i386_defconfig, kvm_guest.config, x86_64_defconfig, plus quite a few randconfigs. All latest 0-DAY reports have been fixed already a few days back. I have test-merged this on top of your usb-next and no conflicts showed up. Please, consider merging. Happy New Year The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.14 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/26] USB: serial: patches for v3.14
On Sun, Dec 29, 2013 at 07:22:52PM +0100, Johan Hovold wrote: Hi Greg, Here are a few patches for v3.14 (if it's not to late) including a new driver by Andrew Lunn (and Moxa) for MOXA UPort devices, some subsystem wide cleanups, and some pl2303 driver improvements. The pl2303 patches fix one low-priority bug (still marked for stable) and add some device-type abstractions that will also make it possible to refine the type detection in a clean way. The baud rate for pl2303 devices can either be set directly for a discrete number of values, or by using divisors. I chose to restore the old way of relying on the direct encoding of baudrates whenever possible. It should be straight-forward to add support for further baud rates using divisors (e.g. if the table lookup fails) if anyone's interested. Thanks for cleaning up the pl2303 baud rate mess. All now applied, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] USB: chipidea: correct spelling mistakes in comment
On Wed, Jan 01, 2014 at 10:02:34AM +0530, Rahul Bedarkar wrote: Changes are as follows: Changes for what, this patch? 1. Reverted drivers/usb/chipidea/ci_hdrc_pci.c as zeroes and zeros either are acceptable What do you mean, you don't touch this file in this patch. totally confused... 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 v1] USB: chipidea: correct spelling mistakes in comment
On 01/03/14 12:37, Greg KH wrote: On Wed, Jan 01, 2014 at 10:02:34AM +0530, Rahul Bedarkar wrote: Changes are as follows: Changes for what, this patch? 1. Reverted drivers/usb/chipidea/ci_hdrc_pci.c as zeroes and zeros either are acceptable What do you mean, you don't touch this file in this patch. totally confused... The original patch changed zeroes to zeros and I commented that either spelling is acceptable, so that change was reverted in the updated patch. -- ~Randy -- 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 v1] USB: core: correct spelling mistakes in comments and warning
On Wed, Jan 01, 2014 at 09:59:30AM +0530, Rahul Bedarkar wrote: Changed warning string to port %d not suspended yet That's not the description for this whole patch :( sorry, please fix this up and resend. 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: mmotm 2014-01-02-14-35 uploaded (musb)
On 01/03/14 12:02, Felipe Balbi wrote: On Fri, Jan 03, 2014 at 09:57:50AM -0800, Randy Dunlap wrote: On 01/02/14 14:36, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2014-01-02-14-35 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. on x86_64: when CONFIG_USB is not enabled: drivers/built-in.o: In function `musb_init': musb_core.c:(.init.text+0x45fc): undefined reference to `usb_disabled' already have a patch for that. Waiting for Greg to merge ;-) Thanks. commit 89f836a8c56bfea6585a09f7afff7094968a4fd0 Author: Ezequiel Garcia ezequiel.gar...@free-electrons.com Date: Thu Dec 26 09:24:52 2013 -0300 usb: musb: Remove usb_disable() check in module_init() Removing the check to usb_disable() before registering the platform driver allows to build this driver when !USB USB_GADGET, to be used in gadget-only mode. Also, use module_platform_driver() to register the platform driver. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Signed-off-by: Felipe Balbi ba...@ti.com -- ~Randy -- 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.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On 01/03/2014 11:54 AM, Sarah Sharp wrote:
On Fri, Jan 03, 2014 at 07:40:33AM -0800, walt wrote:
On 01/02/2014 11:15 AM, Sarah Sharp wrote:
On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
On 12/18/2013 01:11 PM, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me
know.
--
From: David Laight david.lai...@aculab.com
commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e upstream.
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link
TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for
example,
the USB3 ethernet ax88179_178a card will stop sending...
Unfortunately this patch causes a regression when copying large files to my
outboard USB3 drive. (Nothing at all to do with networking.)
Do you have CONFIG_USB_DEBUG turned on for 3.13? If so, you should see
dmesg output from this statement shortly before your drive fails:
if (num_trbs = TRBS_PER_SEGMENT) {
xhci_err(xhci, Too many fragments %d, max %d\n,
num_trbs, TRBS_PER_SEGMENT - 1);
return -ENOMEM;
}
Well, the answers depend on whether the usb3 drive uses logical volumes or
not
(lvm2), which I can't explain. What I've described so far is with lvm2.
When using lvm2 on the usb3 drive, turning on USB_DEBUG has *no* effect
I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm not
going to publish it here :(
Once I finally ran the kernel with debugging actually compiled in, dmesg
contains
xhci debugging messages. Wow :)
It's a big file so I zipped and attached it, which I hope is acceptable in lkml.
BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said before
doesn't fix the problem. The cp stopped around 7GB just as before.
Sorry for the noise...
xhci.dmesg.gz
Description: application/gzip
Re: [RFC 0/2] target refcounting infrastructure fixes for usb
On Fri, Jan 03, 2014 at 09:56:45AM +0100, Hans de Goede wrote: Hi, On 01/03/2014 01:45 AM, Sarah Sharp wrote: Ok, Alan's additional patch fixed the warnings I was seeing on UAS device unplug. James, can you Cc me on the finished patch when you send it in? Hans, I don't want to send the UAS patches off to Greg until James' patches get into mainline. I believe Greg's usb-next tree is frozen at this point, so they'll have to wait until 3.15. Ugh, I must say I'm rather unhappy about this, waiting till 3.14 to give time to shake things out was fine. But since the start of the 3.13 cycle, there have been no issues found in the xhci / uas code. I completely understand why you're unhappy. I agree that the pull request you sent me on Nov 18th is fine (aside from not being a GPG signed git tag). [1] I also agree that the UAS and xHCI driver changes have been stable during my testing, other than triggering the SCSI oops on UAS disconnect. Yes it triggered an existing problem in another subsys, but the code itself has been issue free all this time. If Greg's tree is indeed already frozen I would rather have us asking an exception for this. Detach yourself emotionally from your code and look at this request from a maintainer's perspective. You're asking me to push 69 patches to Greg after -rc6 is out, for a driver that's been marked broken for several kernel releases (uas). The patches enable a feature that's been basically untested across all xHCI host controllers (streams), and they add new userspace API for usbfs to expose streams. In the meantime, there's a big push to get code into linux-next at least a week or two before the merge window opens. I sent my last pull request on Dec 20th, and Felipe closed his USB gadget tree on Dec 26th. I had hoped to get the SCSI issue settled so I could send in the UAS patches on the 20th, but that didn't happen. My tree is closed. These fixes should get merged (and will!), but I will not ask Greg for an exception to get these patches into 3.14. Alternatively we could add all of it to 3.14 except for the patch removing the BROKEN marking from uas. Or at least all the non uas bits, which are useful to have by themselves. I think the best way to proceed with this is for me to queue all the xHCI patches in that pull request for usb-next once 3.14-rc1 is out, and then you send a separate pull request to Greg. You're going to need to be able to send him pull requests with a signed git tag in the future anyway. James, what is the status of getting the fix for the refcount issue into mainline ? (Greg, James will be queuing the SCSI fix for the 3.14 merge window.) Sarah Sharp [1] http://marc.info/?l=linux-usbm=138478555324055w=2 -- 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 0/2] target refcounting infrastructure fixes for usb
Hi, On 01/03/2014 11:00 PM, Sarah Sharp wrote: On Fri, Jan 03, 2014 at 09:56:45AM +0100, Hans de Goede wrote: Hi, On 01/03/2014 01:45 AM, Sarah Sharp wrote: Ok, Alan's additional patch fixed the warnings I was seeing on UAS device unplug. James, can you Cc me on the finished patch when you send it in? Hans, I don't want to send the UAS patches off to Greg until James' patches get into mainline. I believe Greg's usb-next tree is frozen at this point, so they'll have to wait until 3.15. Ugh, I must say I'm rather unhappy about this, waiting till 3.14 to give time to shake things out was fine. But since the start of the 3.13 cycle, there have been no issues found in the xhci / uas code. I completely understand why you're unhappy. I agree that the pull request you sent me on Nov 18th is fine (aside from not being a GPG signed git tag). [1] I also agree that the UAS and xHCI driver changes have been stable during my testing, other than triggering the SCSI oops on UAS disconnect. Yes it triggered an existing problem in another subsys, but the code itself has been issue free all this time. If Greg's tree is indeed already frozen I would rather have us asking an exception for this. Detach yourself emotionally from your code and look at this request from a maintainer's perspective. You're asking me to push 69 patches to Greg after -rc6 is out, for a driver that's been marked broken for several kernel releases (uas). The patches enable a feature that's been basically untested across all xHCI host controllers (streams), and they add new userspace API for usbfs to expose streams. Yes 69 patches which have been ready since November 18. Your argument is that they were not in linux-next before now, my unhappiness comes from that they could have been in linux-next for some time now already. In the meantime, there's a big push to get code into linux-next at least a week or two before the merge window opens. I sent my last pull request on Dec 20th, and Felipe closed his USB gadget tree on Dec 26th. I had hoped to get the SCSI issue settled so I could send in the UAS patches on the 20th, but that didn't happen. My tree is closed. These fixes should get merged (and will!), but I will not ask Greg for an exception to get these patches into 3.14. Alternatively we could add all of it to 3.14 except for the patch removing the BROKEN marking from uas. Or at least all the non uas bits, which are useful to have by themselves. I think the best way to proceed with this is for me to queue all the xHCI patches in that pull request for usb-next once 3.14-rc1 is out, and then you send a separate pull request to Greg. You're going to need to be able to send him pull requests with a signed git tag in the future anyway. Since you have all the patches in your tree now anyways I believe it would be best if you just send a pull-req for all of them. I see little value in me sending a separate pull-req for the uas patches. As discussed before I'm fine with picking up uas maintenance from then on. Regards, Hans -- 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.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote: I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm not going to publish it here :( Once I finally ran the kernel with debugging actually compiled in, dmesg contains xhci debugging messages. Wow :) It's a big file so I zipped and attached it, which I hope is acceptable in lkml. Yep, that's fine. Sticking it in pastebin (or up on your server) is also fine, if it gets really big. BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said before doesn't fix the problem. The cp stopped around 7GB just as before. Sorry for the noise... No worries! :) With the dmesg, I can finally see what happened: [ 188.703059] xhci_hcd :03:00.0: Cancel URB 8800b7d2e0c0, dev 1, ep 0x2, starting at offset 0xbb7b9000 [ 188.703072] xhci_hcd :03:00.0: // Ding dong! [ 193.711022] xhci_hcd :03:00.0: xHCI host not responding to stop endpoint command. [ 193.711029] xhci_hcd :03:00.0: Assuming host is dying, halting host. [ 193.711046] xhci_hcd :03:00.0: // Halt the HC [ 193.711060] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 0 [ 193.711066] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 2 [ 193.711078] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 3 [ 193.711096] xhci_hcd :03:00.0: Calling usb_hc_died() [ 193.711103] xhci_hcd :03:00.0: HC died; cleaning up [ 193.76] xhci_hcd :03:00.0: xHCI host controller is dead. It seems that the xHCI driver tried to stop the endpoint ring in order to cancel a SCSI transfer, and the driver never got a response for that. The offset is rather suspicious (0xbb7b9000), and it probably means the driver attempted to cancel a transfer that had been moved to the beginning of the ring segment, with no-op TRBs before the link TRB. I suspect David's patch triggers a bug in the command cancellation code. There's also the unlikely possibility that the no-op TRBs did indeed cause the host to hang. Either way, I'll have to look into it. I'll let you know when I have some diagnostic patches ready. 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: Skip U1/U2 LPM disable if device is disconnected.
Occasionally when a USB 3.0 device is disconnected, the roothub port
goes into the SS.Inactive state, rather than reporting a disconnect. A
warm reset is the only way to get out of this state. khubd notices the
link state in hub_port_events(), and since a udev is active on that
port, it calls into usb_reset_and_verify_device().
USB 3.0 Link PM is disabled before the device is reset, in order to
balance out the LPM ref counts. That code will also issue two control
transfers to disable the U1 and U2 timeouts. On some USB host
controllers (at least the Intel ones, possibly others), issuing a
control transfer to a disconnected port causes the transfer to timeout,
rather than immediately returning with a transfer error. Each control
transfer takes five seconds to timeout and be canceled.
[ 89.551350] hub 2-0:1.0: state 7 ports 4 chg evt 0004
[ 89.551642] hub 2-0:1.0: warm reset port 2
[ 94.549887] usb 2-2: Disable of device-initiated U1 failed.
[ 99.548027] usb 2-2: Disable of device-initiated U2 failed.
The end result is that USB device disconnect is delayed by ten seconds,
and khubd won't be able to service other ports until the disconnect is
handled. Work around this by checking the status of the device's port,
and not sending the U1/U2 disable control transfers if the device is
disconnected.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Tested-by: Girish Nandibasappa girishx.nandibasa...@intel.com
Tested-by: Hemanth Venkatesh Murthy hemanthx.venkatesh.mur...@intel.com
---
drivers/usb/core/hub.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 92e052db27ac..5eea4a5475a4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2521,6 +2521,22 @@ static bool hub_port_warm_reset_required(struct usb_hub
*hub, u16 portstatus)
USB_SS_PORT_LS_COMP_MOD)) ;
}
+static bool hub_is_device_disconnected(struct usb_device *udev)
+{
+ u16 portstatus;
+ u16 portchange;
+ int ret;
+ struct usb_hub *hub;
+
+ hub = usb_hub_to_struct_hub(udev-parent);
+ ret = hub_port_status(hub, udev-portnum, portstatus, portchange);
+ if (ret 0)
+ return true;
+ if ((portstatus USB_PORT_STAT_CONNECTION))
+ return false;
+ return true;
+}
+
static int hub_port_wait_reset(struct usb_hub *hub, int port1,
struct usb_device *udev, unsigned int delay, bool warm)
{
@@ -3513,6 +3529,13 @@ static int usb_set_device_initiated_lpm(struct
usb_device *udev,
usb3_lpm_names[state]);
return 0;
}
+ if (hub_is_device_disconnected(udev)) {
+ dev_dbg(udev-dev, %s: Can't %s %s state
+ for disconnected device.\n,
+ __func__, enable ? enable : disable,
+ usb3_lpm_names[state]);
+ return 0;
+ }
if (enable) {
/*
--
1.8.3.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: [PATCH] usb: Skip U1/U2 LPM disable if device is disconnected.
On Fri, Jan 03, 2014 at 04:22:45PM -0800, Sarah Sharp wrote: Occasionally when a USB 3.0 device is disconnected, the roothub port goes into the SS.Inactive state, rather than reporting a disconnect. Is that a hardware bug? Or just something inherent in how the spec says things can work? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] usb: musb: add support for JZ4740 usb device controller
On Thu, Dec 19, 2013 at 9:42 PM, Apelete Seketeli apel...@seketeli.net wrote:
Add support for Ingenic JZ4740 USB Device Controller through a
specific musb glue layer.
JZ4740 UDC not being OTG compatible and missing some hardware
registers, this musb glue layer is written from scratch to be used in
gadget mode only and take silicon design specifics into account.
Signed-off-by: Apelete Seketeli apel...@seketeli.net
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
drivers/usb/musb/Kconfig |8 +-
drivers/usb/musb/Makefile |1 +
drivers/usb/musb/jz4740.c | 201
+
3 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/musb/jz4740.c
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 57dfc0c..14d7e72 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -93,6 +93,12 @@ config USB_MUSB_BLACKFIN
config USB_MUSB_UX500
tristate Ux500 platforms
+config USB_MUSB_JZ4740
+ tristate JZ4740
+ depends on MACH_JZ4740 || COMPILE_TEST
+ depends on USB_MUSB_GADGET
+ depends on USB_OTG_BLACKLIST_HUB
+
endchoice
config USB_MUSB_AM335X_CHILD
@@ -100,7 +106,7 @@ config USB_MUSB_AM335X_CHILD
choice
prompt 'MUSB DMA mode'
- default MUSB_PIO_ONLY if ARCH_MULTIPLATFORM
+ default MUSB_PIO_ONLY if ARCH_MULTIPLATFORM || USB_MUSB_JZ4740
Just out of curiosity, why can't we use DMA?
default USB_UX500_DMA if USB_MUSB_UX500
default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
default USB_TI_CPPI_DMA if USB_MUSB_DAVINCI
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index c5ea5c6..ba49501 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_USB_MUSB_DAVINCI)+=
davinci.o
obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
+obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
new file mode 100644
index 000..5f30537
--- /dev/null
+++ b/drivers/usb/musb/jz4740.c
@@ -0,0 +1,201 @@
+/*
+ * Ingenic JZ4740 glue layer
+ *
+ * Copyright (C) 2013, Apelete Seketeli apel...@seketeli.net
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+
+#include musb_core.h
+
+struct jz4740_glue {
+ struct device *dev;
+ struct platform_device *musb;
+ struct clk *clk;
+};
+
+static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci)
+{
+ unsigned long flags;
+ irqreturn_t retval = IRQ_NONE;
+ struct musb *musb = __hci;
+
+ spin_lock_irqsave(musb-lock, flags);
+
+ musb-int_usb = musb_readb(musb-mregs, MUSB_INTRUSB);
+ musb-int_tx = musb_readw(musb-mregs, MUSB_INTRTX);
+ musb-int_rx = musb_readw(musb-mregs, MUSB_INTRRX);
+
+ /*
+* The controller is gadget only, the state of the host mode IRQ bits
is
+* undefined. Mask them to make sure that the musb driver core will
+* never see them set
+*/
+ musb-int_usb = MUSB_INTR_SUSPEND | MUSB_INTR_RESUME |
+ MUSB_INTR_RESET | MUSB_INTR_SOF;
+
+ if (musb-int_usb || musb-int_tx || musb-int_rx)
+ retval = musb_interrupt(musb);
+
+ spin_unlock_irqrestore(musb-lock, flags);
+
+ return retval;
+}
+
+static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = {
+{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, },
+{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, },
+{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, },
+};
+
+static struct musb_hdrc_config jz4740_musb_config = {
+ /* Silicon does not implement USB OTG. */
+ .multipoint = 0,
+ /* Max EPs scanned, driver will decide which EP can be used. */
+ .num_eps= 4,
+ /* RAMbits needed to configure EPs from table */
+ .ram_bits = 9,
+ .fifo_cfg = jz4740_musb_fifo_cfg,
+ .fifo_cfg_size = ARRAY_SIZE(jz4740_musb_fifo_cfg),
+};
+
+static struct
Re: [PATCH net-next] r8152: fix the wrong return value
From: Hayes Wang hayesw...@realtek.com Date: Fri, 3 Jan 2014 11:21:56 +0800 The return value should be the boolean value, not the error code. Signed-off-by: Hayes Wang hayesw...@realtek.com Spotted-by: Dan Carpenter dan.carpen...@oracle.com Applied, but I agree with others that it's more canonical to have the function return either an error code, or zero for success, rather than a boolean. -- 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 2/2] dual scan thread bug fix
On Fri, 2014-01-03 at 10:58 -0500, Alan Stern wrote:
On Thu, 2 Jan 2014, James Bottomley wrote:
In the highly unusual case where two threads are running concurrently
through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it. In this
case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.
Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.
I'm still concerned about one thing. The previous patch does this in
scsi_alloc_target():
found:
- found_target-reap_ref++;
+ if (!kref_get_unless_zero(found_target-reap_ref))
+ /*
+* release routine already fired. Target is dead, but
+* STARGET_DEL may not yet be set (set in the release
+* routine), so set here as well, just in case
+*/
+ found_target-state = STARGET_DEL;
spin_unlock_irqrestore(shost-host_lock, flags);
As a result, the two comments in this patch aren't right:
@@ -384,9 +385,15 @@ static void scsi_target_reap_ref_release(struct kref
*kref)
struct scsi_target *starget
= container_of(kref, struct scsi_target, reap_ref);
- transport_remove_device(starget-dev);
- device_del(starget-dev);
- starget-state = STARGET_DEL;
+ /*
+* if we get here and the target is still in the CREATED state that
+* means it was allocated but never made visible (because a scan
+* turned up no LUNs), so don't call device_del() on it.
+*/
+ if (starget-state == STARGET_RUNNING) {
+ transport_remove_device(starget-dev);
+ device_del(starget-dev);
+ }
Here the state could already be STARGET_DEL, even though the target is
still visible.
Well, I agree with the theory. In practise, there are only a few
machine instructions between the kref going to zero and us reaching that
point, because kref_release will jump into this routine next, so the
condition would be very hard to see. However, I suppose it's easy to
close by checking for != STARGET_CREATED and there's no reason not to do
that, so I'll change it.
Also, it's a little odd that the comment talks about CREATED but the
code really checks for RUNNING. They should be consistent.
!= STARGET_CREATED should solve this.
@@ -506,11 +513,13 @@ static struct scsi_target *scsi_alloc_target(struct
device *parent,
*/
void scsi_target_reap(struct scsi_target *starget)
{
+ /*
+* serious problem if this triggers: STARGET_DEL is only set in the
+* kref release routine, so we're doing another final put on an
+* already released kref
+*/
BUG_ON(starget-state == STARGET_DEL);
Here the code is okay but the comment is wrong: STARGET_DEL is set in
_two_ places (but neither of them runs until reap_ref has reached 0).
Would it be better in scsi_alloc_target() to behave as though the state
were STARGET_DEL without actually setting it?
Yes, I'll update the comment to it only goes to DEL after the kref goes
to zero.
How does the attached diff look?
James
---
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 82cf902..2f7de33 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -390,7 +390,7 @@ static void scsi_target_reap_ref_release(struct kref *kref)
* means it was allocated but never made visible (because a scan
* turned up no LUNs), so don't call device_del() on it.
*/
- if (starget-state == STARGET_RUNNING) {
+ if (starget-state != STARGET_CREATED) {
transport_remove_device(starget-dev);
device_del(starget-dev);
}
@@ -514,9 +514,9 @@ static struct scsi_target *scsi_alloc_target(struct device
*parent,
void scsi_target_reap(struct scsi_target *starget)
{
/*
-* serious problem if this triggers: STARGET_DEL is only set in the
-* kref release routine, so we're doing another final put on an
-* already released kref
+* serious problem if this triggers: STARGET_DEL is only set in the if
+* the reap_ref drops to zero, so we're trying to do another final put
+* on an already released kref
*/
BUG_ON(starget-state == STARGET_DEL);
scsi_target_reap_ref_put(starget);
--
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: wusbcore: correct spelling mistakes in comments and error string
Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
drivers/usb/wusbcore/cbaf.c | 2 +-
drivers/usb/wusbcore/crypto.c | 2 +-
drivers/usb/wusbcore/devconnect.c | 4 ++--
drivers/usb/wusbcore/security.c | 2 +-
drivers/usb/wusbcore/wa-hc.h | 10 +-
drivers/usb/wusbcore/wa-rpipe.c | 2 +-
drivers/usb/wusbcore/wusbhc.c | 2 +-
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/wusbcore/cbaf.c b/drivers/usb/wusbcore/cbaf.c
index f06ed82..66a6e6f 100644
--- a/drivers/usb/wusbcore/cbaf.c
+++ b/drivers/usb/wusbcore/cbaf.c
@@ -184,7 +184,7 @@ static int cbaf_check(struct cbaf *cbaf)
assoc_request = itr;
if (top - itr sizeof(*assoc_request)) {
- dev_err(dev, Not enough data to decode associaton
+ dev_err(dev, Not enough data to decode association
request (%zu vs %zu bytes needed)\n,
top - itr, sizeof(*assoc_request));
break;
diff --git a/drivers/usb/wusbcore/crypto.c b/drivers/usb/wusbcore/crypto.c
index 7e4bf95..9a95b2d 100644
--- a/drivers/usb/wusbcore/crypto.c
+++ b/drivers/usb/wusbcore/crypto.c
@@ -87,7 +87,7 @@ struct aes_ccm_block {
* B1 contains l(a), the MAC header, the encryption offset and padding.
*
* If EO is nonzero, additional blocks are built from payload bytes
- * until EO is exahusted (FIXME: padding to 16 bytes, I guess). The
+ * until EO is exhausted (FIXME: padding to 16 bytes, I guess). The
* padding is not xmitted.
*/
diff --git a/drivers/usb/wusbcore/devconnect.c
b/drivers/usb/wusbcore/devconnect.c
index f14e792..3b959e8 100644
--- a/drivers/usb/wusbcore/devconnect.c
+++ b/drivers/usb/wusbcore/devconnect.c
@@ -265,9 +265,9 @@ static void wusbhc_devconnect_acked_work(struct work_struct
*work)
* Addresses: because WUSB hosts have no downstream hubs, we can do a
*1:1 mapping between 'port number' and device
*address. This simplifies many things, as during this
- *initial connect phase the USB stack has no knoledge of
+ *initial connect phase the USB stack has no knowledge of
*the device and hasn't assigned an address yet--we know
- *USB's choose_address() will use the same euristics we
+ *USB's choose_address() will use the same heuristics we
*use here, so we can assume which address will be assigned.
*
*USB stack always assigns address 1 to the root hub, so
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index 4c40d0d..f0f29ff 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -56,7 +56,7 @@ void wusbhc_sec_destroy(struct wusbhc *wusbhc)
* @wusb_dev: the device whose PTK the TKID is for
*(or NULL for a TKID for a GTK)
*
- * The generated TKID consist of two parts: the device's authenicated
+ * The generated TKID consist of two parts: the device's authenticated
* address (or 0 or a GTK); and an incrementing number. This ensures
* that TKIDs cannot be shared between devices and by the time the
* incrementing number wraps around the older TKIDs will no longer be
diff --git a/drivers/usb/wusbcore/wa-hc.h b/drivers/usb/wusbcore/wa-hc.h
index e614f02..50cb033 100644
--- a/drivers/usb/wusbcore/wa-hc.h
+++ b/drivers/usb/wusbcore/wa-hc.h
@@ -36,7 +36,7 @@
*
* hcdglue with the USB API Host Controller Interface API.
*
- * nepNotification EndPoint managent: collect notifications
+ * nepNotification EndPoint management: collect notifications
* and queue them with the workqueue daemon.
*
* Handle notifications as coming from the NEP. Sends them
@@ -144,7 +144,7 @@ enum wa_quirks {
*
* @wa_descr Can be accessed without locking because it is in
*the same area where the device descriptors were
- *read, so it is guaranteed to exist umodified while
+ *read, so it is guaranteed to exist unmodified while
*the device exists.
*
*Endianess has been converted to CPU's.
@@ -167,8 +167,8 @@ enum wa_quirks {
* submitted from an atomic context).
*
* FIXME: this needs to be layered up: a wusbhc layer (for sharing
- *comonalities with WHCI), a wa layer (for sharing
- *comonalities with DWA-RC).
+ *commonalities with WHCI), a wa layer (for sharing
+ *commonalities with DWA-RC).
*/
struct wahc {
struct usb_device *usb_dev;
@@ -345,7 +345,7 @@ extern void wa_handle_notif_xfer(struct wahc *, struct
wa_notif_hdr *);
*it...no RC specific function is called...unless I miss
*something.
*
- * FIXME: has to go away in favour of an 'struct' hcd based sollution
+ * FIXME: has to go away in favour of an 'struct' hcd based solution
*/
static inline
[PATCH] USB: wusbcore: fix up minor coding style issues in cbaf.c
Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
drivers/usb/wusbcore/cbaf.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/wusbcore/cbaf.c b/drivers/usb/wusbcore/cbaf.c
index 66a6e6f..b423fe6 100644
--- a/drivers/usb/wusbcore/cbaf.c
+++ b/drivers/usb/wusbcore/cbaf.c
@@ -235,7 +235,7 @@ static int cbaf_check(struct cbaf *cbaf)
static const struct wusb_cbaf_host_info cbaf_host_info_defaults = {
.AssociationTypeId_hdr= WUSB_AR_AssociationTypeId,
- .AssociationTypeId= cpu_to_le16(AR_TYPE_WUSB),
+ .AssociationTypeId= cpu_to_le16(AR_TYPE_WUSB),
.AssociationSubTypeId_hdr = WUSB_AR_AssociationSubTypeId,
.AssociationSubTypeId = cpu_to_le16(AR_TYPE_WUSB_RETRIEVE_HOST_INFO),
.CHID_hdr = WUSB_AR_CHID,
@@ -260,7 +260,8 @@ static int cbaf_send_host_info(struct cbaf *cbaf)
hi-HostFriendlyName_hdr.len = cpu_to_le16(name_len);
hi_size = sizeof(*hi) + name_len;
- return usb_control_msg(cbaf-usb_dev, usb_sndctrlpipe(cbaf-usb_dev, 0),
+ return usb_control_msg(cbaf-usb_dev,
+ usb_sndctrlpipe(cbaf-usb_dev, 0),
CBAF_REQ_SET_ASSOCIATION_RESPONSE,
USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
0x0101,
@@ -290,7 +291,8 @@ static int cbaf_cdid_get(struct cbaf *cbaf)
0x0200, cbaf-usb_iface-cur_altsetting-desc.bInterfaceNumber,
di, cbaf-buffer_size, 1000 /* FIXME: arbitrary */);
if (result 0) {
- dev_err(dev, Cannot request device information: %d\n, result);
+ dev_err(dev, Cannot request device information: %d\n,
+ result);
return result;
}
@@ -491,11 +493,11 @@ static DEVICE_ATTR(wusb_device_name, 0600,
cbaf_wusb_device_name_show, NULL);
static const struct wusb_cbaf_cc_data cbaf_cc_data_defaults = {
.AssociationTypeId_hdr= WUSB_AR_AssociationTypeId,
- .AssociationTypeId= cpu_to_le16(AR_TYPE_WUSB),
+ .AssociationTypeId= cpu_to_le16(AR_TYPE_WUSB),
.AssociationSubTypeId_hdr = WUSB_AR_AssociationSubTypeId,
.AssociationSubTypeId = cpu_to_le16(AR_TYPE_WUSB_ASSOCIATE),
.Length_hdr = WUSB_AR_Length,
- .Length = cpu_to_le32(sizeof(struct
wusb_cbaf_cc_data)),
+ .Length = cpu_to_le32(sizeof(struct wusb_cbaf_cc_data)),
.ConnectionContext_hdr= WUSB_AR_ConnectionContext,
.BandGroups_hdr = WUSB_AR_BandGroups,
};
--
1.8.1.2
--
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: wusbcore: correct spelling mistakes in comments and error string
On 01/03/14 21:47, Rahul Bedarkar wrote:
Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
drivers/usb/wusbcore/cbaf.c | 2 +-
drivers/usb/wusbcore/crypto.c | 2 +-
drivers/usb/wusbcore/devconnect.c | 4 ++--
drivers/usb/wusbcore/security.c | 2 +-
drivers/usb/wusbcore/wa-hc.h | 10 +-
drivers/usb/wusbcore/wa-rpipe.c | 2 +-
drivers/usb/wusbcore/wusbhc.c | 2 +-
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index 4c40d0d..f0f29ff 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -56,7 +56,7 @@ void wusbhc_sec_destroy(struct wusbhc *wusbhc)
* @wusb_dev: the device whose PTK the TKID is for
*(or NULL for a TKID for a GTK)
*
- * The generated TKID consist of two parts: the device's authenicated
+ * The generated TKID consist of two parts: the device's authenticated
consists
* address (or 0 or a GTK); and an incrementing number. This ensures
* that TKIDs cannot be shared between devices and by the time the
* incrementing number wraps around the older TKIDs will no longer be
diff --git a/drivers/usb/wusbcore/wa-hc.h b/drivers/usb/wusbcore/wa-hc.h
index e614f02..50cb033 100644
--- a/drivers/usb/wusbcore/wa-hc.h
+++ b/drivers/usb/wusbcore/wa-hc.h
@@ -345,7 +345,7 @@ extern void wa_handle_notif_xfer(struct wahc *, struct
wa_notif_hdr *);
*it...no RC specific function is called...unless I miss
*something.
*
- * FIXME: has to go away in favour of an 'struct' hcd based sollution
+ * FIXME: has to go away in favour of an 'struct' hcd based solution
of a
*/
static inline struct wahc *wa_get(struct wahc *wa)
{
diff --git a/drivers/usb/wusbcore/wusbhc.c b/drivers/usb/wusbcore/wusbhc.c
index 742c607..e6b0fad92 100644
--- a/drivers/usb/wusbcore/wusbhc.c
+++ b/drivers/usb/wusbcore/wusbhc.c
@@ -419,7 +419,7 @@ EXPORT_SYMBOL_GPL(wusb_cluster_id_put);
* - After a successful transfer, update the trust timeout timestamp
*for the WUSB device.
*
- * - [WUSB] sections 4.13 and 7.5.1 specifies the stop retrasmittion
+ * - [WUSB] sections 4.13 and 7.5.1 specifies the stop retransmission
specify
*condition for the WCONNECTACK_IE is that the host has observed
*the associated device responding to a control transfer.
*/
--
~Randy
--
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: core: correct spelling mistakes in comments and warning
Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
drivers/usb/core/buffer.c | 2 +-
drivers/usb/core/devio.c| 2 +-
drivers/usb/core/hcd.c | 2 +-
drivers/usb/core/hub.c | 7 ---
drivers/usb/core/hub.h | 2 +-
drivers/usb/core/message.c | 4 ++--
drivers/usb/core/sysfs.c| 2 +-
drivers/usb/core/urb.c | 4 ++--
drivers/usb/core/usb-acpi.c | 2 +-
9 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 2355974..684ef70 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -2,7 +2,7 @@
* DMA memory management for framework level HCD code (hc_driver)
*
* This implementation plugs in through generic usb_bus level methods,
- * and should work with all USB controllers, regardles of bus type.
+ * and should work with all USB controllers, regardless of bus type.
*/
#include linux/module.h
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 967152a..90e18f6 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -118,7 +118,7 @@ module_param(usbfs_memory_mb, uint, 0644);
MODULE_PARM_DESC(usbfs_memory_mb,
maximum MB allowed for usbfs buffers (0 = no limit));
-/* Hard limit, necessary to avoid aithmetic overflow */
+/* Hard limit, necessary to avoid arithmetic overflow */
#define USBFS_XFER_MAX (UINT_MAX / 2 - 100)
static atomic_t usbfs_memory_usage;/* Total memory currently allocated */
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 6bffb8c..674d2df 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1297,7 +1297,7 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* DMA framework is dma_declare_coherent_memory()
*
* - So we use that, even though the primary requirement
- * is that the memory be local (hence addressible
+ * is that the memory be local (hence addressable
* by that device), not coherent.
*
*/
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bd9dc35..da2bf46 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2526,7 +2526,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
static int hub_port_reset(struct usb_hub *hub, int port1,
struct usb_device *udev, unsigned int delay, bool warm);
-/* Is a USB 3.0 port in the Inactive or Complinance Mode state?
+/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
* Port worm reset is required to recover
*/
static bool hub_port_warm_reset_required(struct usb_hub *hub, u16 portstatus)
@@ -3334,7 +3334,8 @@ static int hub_suspend(struct usb_interface *intf,
pm_message_t msg)
udev = hub-ports[port1 - 1]-child;
if (udev udev-can_submit) {
- dev_warn(intf-dev, port %d nyet suspended\n, port1);
+ dev_warn(intf-dev, port %d not suspended yet\n,
+ port1);
if (PMSG_IS_AUTO(msg))
return -EBUSY;
}
@@ -4900,7 +4901,7 @@ static void hub_events(void)
static int hub_thread(void *__unused)
{
- /* khubd needs to be freezable to avoid intefering with USB-PERSIST
+ /* khubd needs to be freezable to avoid interfering with USB-PERSIST
* port handover. Otherwise it might see that a full-speed device
* was gone before the EHCI controller had handed its port over to
* the companion full-speed controller.
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 4e4790d..df629a3 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,7 +78,7 @@ struct usb_hub {
/**
* struct usb port - kernel's representation of a usb port
- * @child: usb device attatched to the port
+ * @child: usb device attached to the port
* @dev: generic device interface
* @port_owner: port's owner
* @connect_type: port's connect type
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index bb31597..854a419 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -218,7 +218,7 @@ EXPORT_SYMBOL_GPL(usb_interrupt_msg);
*
* Return:
* If successful, 0. Otherwise a negative error number. The number of actual
- * bytes transferred will be stored in the @actual_length paramater.
+ * bytes transferred will be stored in the @actual_length parameter.
*
*/
int usb_bulk_msg(struct usb_device *usb_dev, unsigned int pipe,
@@ -518,7 +518,7 @@ void usb_sg_wait(struct usb_sg_request *io)
io-urbs[i]-dev = io-dev;
retval = usb_submit_urb(io-urbs[i], GFP_ATOMIC);
- /* after we submit, let completions or cancelations fire;
+ /* after we submit, let completions or cancellations fire;
* we handshake using io-status.
*/
spin_unlock_irq(io-lock);
diff --git
CP2102 mystery - ttyUSB0 vs usbfs
Members of this list may recall a question I asked regarding the CP2102 serial adapter a couple of weeks ago. For the curious, my original message is attached to this one. At the time, I was rather frustrated at the go away and figure it out for yourself response, but, in the end, I'm glad I then did exactly that. The answer turns out to be that current Linux support for this particular set of serial adapters, i.e. the cp210x driver, is rather inadequate. For my particular problem, the driver initializes the adapter by configuring its flow control to keep DTR and RTS low, and then using a manual operation to force both of them high. The difference between our code then, and Linux's code, is that we were forcing DTR and RTS high before configuring the flow control settings the same way the driver does, which caused the adapter to honour the instruction to keep both lines low. The fact is, as I see it, that the cp210x driver is doing things incorrectly. What it should do is not use those manual operations at all, and configure the adapter's flow control settings to keep both DTR and RTS high. That's the proper way to persistently maintain their desired state without any risk of them honouring the initially configured and incorrect instruction to keep them low. That's what our code now does, and it works very well. In addition, the test for setting termios's CRTSCTS bit is only half right, and there's no support at all for other forms of flow control (like input and/or output XON-XOFF) even though the user gets no error at all if he requests any of them. So, in the end, I'm sorry I showed so much frustration at this list's response, am glad that I did my own research, and, even though I like Linux a great deal, am still glad we have our own code which, on all platforms, will work correctly in a portable way. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ ---BeginMessage--- I'm using kernel 3.11.4-101.fc18.x86_64 on a 64-bit Fedora 19 system. I'd very much appreciate a bit of help from someone who understands the CP2102 serial adapter support. When I access it through /dev/ttyUSB0, it works fine. When, however, I access it through usbfs, it doesn't seem to be working. When I study the usbmon output for both methods, they look to be effectively the same. I've attached the two usbmon traces to this message (as usbmon-ttyUSB0 and usbmon-usbfs). The first output packet to endpoint 1 (FF,FF,11,00,00,00) probes the device. When ttyUSB0 is being used, there's an immediate response of the single byte 0X10. This is correct. When usbfs is being used, the probe is resent several times, with no response, and then the code gives up. All of the control setup for the CP2102 completes without any errors. The usbfs code even includes a set of queries to ensure that the serial configuration is correct - it is. The correct settings are: 9600 baud, 1 stop bit, 8 data bits, no parity, no flow control. In case it matters, urb-signr is set (to SIGRTMIN). We rely in receipt of this signal to know that the URB is ready to be reaped. This is working very well for many devices. Is there a possibility, though, that the kernel support for the CP2102 doesn't work this way? I'd sure appreciate any help on this issue as I've been staring at it for a couple of weeks now and haven't been able to spot the problem. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ 8801138a0540 3905511537 S Co:5:065:0 s 41 00 0001 0 8801138a0540 3905511739 C Co:5:065:0 0 0 8801138a0540 3905511804 S Ci:5:065:0 s c1 1d 0004 4 8801138a0540 3905513729 C Ci:5:065:0 0 4 = 00c20100 8801138a0540 3905513780 S Ci:5:065:0 s c1 04 0002 2 8801138a0540 3905515728 C Ci:5:065:0 0 2 = 0008 8801138a0540 3905515780 S Ci:5:065:0 s c1 14 0010 16 8801138a0540 3905517728 C Ci:5:065:0 0 16 = 8801138a0540 3905517788 S Co:5:065:0 s 41 1e 0004 4 = 00c20100 8801138a0540 3905519728 C Co:5:065:0 0 4 8801f1357b40 3905519788 S Bi:5:065:1 -115 256 8801f1357480 3905519806 S Bi:5:065:1 -115 256 8801138a0540 3905519814 S Co:5:065:0 s 41 07 0303 0 8801138a0540 3905521728 C Co:5:065:0 0 0 8801138a0540 3905521922 S Co:5:065:0 s 41 1e 0004 4 = 8025 8801138a0540 3905523729 C Co:5:065:0 0 4 8801f1357f00 3905523925 S Bo:5:065:1 -115 6 = 1100 8801f1357f00 3905524727 C Bo:5:065:1 0 6 8801f1357b40 3905533742 C Bi:5:065:1 0 1 = 10 8801f1357b40 3905533769 S Bi:5:065:1 -115 256 8801f1357f00 3905534088 S Bo:5:065:1 -115 8
[PATCH v2] USB: wusbcore: correct spelling mistakes in comments and error string
Signed-off-by: Rahul Bedarkar rahulbedarka...@gmail.com
---
drivers/usb/wusbcore/cbaf.c | 2 +-
drivers/usb/wusbcore/crypto.c | 2 +-
drivers/usb/wusbcore/devconnect.c | 4 ++--
drivers/usb/wusbcore/security.c | 2 +-
drivers/usb/wusbcore/wa-hc.h | 10 +-
drivers/usb/wusbcore/wa-rpipe.c | 2 +-
drivers/usb/wusbcore/wusbhc.c | 2 +-
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/wusbcore/cbaf.c b/drivers/usb/wusbcore/cbaf.c
index f06ed82..66a6e6f 100644
--- a/drivers/usb/wusbcore/cbaf.c
+++ b/drivers/usb/wusbcore/cbaf.c
@@ -184,7 +184,7 @@ static int cbaf_check(struct cbaf *cbaf)
assoc_request = itr;
if (top - itr sizeof(*assoc_request)) {
- dev_err(dev, Not enough data to decode associaton
+ dev_err(dev, Not enough data to decode association
request (%zu vs %zu bytes needed)\n,
top - itr, sizeof(*assoc_request));
break;
diff --git a/drivers/usb/wusbcore/crypto.c b/drivers/usb/wusbcore/crypto.c
index 7e4bf95..9a95b2d 100644
--- a/drivers/usb/wusbcore/crypto.c
+++ b/drivers/usb/wusbcore/crypto.c
@@ -87,7 +87,7 @@ struct aes_ccm_block {
* B1 contains l(a), the MAC header, the encryption offset and padding.
*
* If EO is nonzero, additional blocks are built from payload bytes
- * until EO is exahusted (FIXME: padding to 16 bytes, I guess). The
+ * until EO is exhausted (FIXME: padding to 16 bytes, I guess). The
* padding is not xmitted.
*/
diff --git a/drivers/usb/wusbcore/devconnect.c
b/drivers/usb/wusbcore/devconnect.c
index f14e792..3b959e8 100644
--- a/drivers/usb/wusbcore/devconnect.c
+++ b/drivers/usb/wusbcore/devconnect.c
@@ -265,9 +265,9 @@ static void wusbhc_devconnect_acked_work(struct work_struct
*work)
* Addresses: because WUSB hosts have no downstream hubs, we can do a
*1:1 mapping between 'port number' and device
*address. This simplifies many things, as during this
- *initial connect phase the USB stack has no knoledge of
+ *initial connect phase the USB stack has no knowledge of
*the device and hasn't assigned an address yet--we know
- *USB's choose_address() will use the same euristics we
+ *USB's choose_address() will use the same heuristics we
*use here, so we can assume which address will be assigned.
*
*USB stack always assigns address 1 to the root hub, so
diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index 4c40d0d..371d94a 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -56,7 +56,7 @@ void wusbhc_sec_destroy(struct wusbhc *wusbhc)
* @wusb_dev: the device whose PTK the TKID is for
*(or NULL for a TKID for a GTK)
*
- * The generated TKID consist of two parts: the device's authenicated
+ * The generated TKID consists of two parts: the device's authenticated
* address (or 0 or a GTK); and an incrementing number. This ensures
* that TKIDs cannot be shared between devices and by the time the
* incrementing number wraps around the older TKIDs will no longer be
diff --git a/drivers/usb/wusbcore/wa-hc.h b/drivers/usb/wusbcore/wa-hc.h
index e614f02..2556e8e 100644
--- a/drivers/usb/wusbcore/wa-hc.h
+++ b/drivers/usb/wusbcore/wa-hc.h
@@ -36,7 +36,7 @@
*
* hcdglue with the USB API Host Controller Interface API.
*
- * nepNotification EndPoint managent: collect notifications
+ * nepNotification EndPoint management: collect notifications
* and queue them with the workqueue daemon.
*
* Handle notifications as coming from the NEP. Sends them
@@ -144,7 +144,7 @@ enum wa_quirks {
*
* @wa_descr Can be accessed without locking because it is in
*the same area where the device descriptors were
- *read, so it is guaranteed to exist umodified while
+ *read, so it is guaranteed to exist unmodified while
*the device exists.
*
*Endianess has been converted to CPU's.
@@ -167,8 +167,8 @@ enum wa_quirks {
* submitted from an atomic context).
*
* FIXME: this needs to be layered up: a wusbhc layer (for sharing
- *comonalities with WHCI), a wa layer (for sharing
- *comonalities with DWA-RC).
+ *commonalities with WHCI), a wa layer (for sharing
+ *commonalities with DWA-RC).
*/
struct wahc {
struct usb_device *usb_dev;
@@ -345,7 +345,7 @@ extern void wa_handle_notif_xfer(struct wahc *, struct
wa_notif_hdr *);
*it...no RC specific function is called...unless I miss
*something.
*
- * FIXME: has to go away in favour of an 'struct' hcd based sollution
+ * FIXME: has to go away in favour of a 'struct' hcd based solution
*/
static inline
