This patchs adds include guard to avoid double inclusion of the header.
Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com
---
include/linux/usb/otg_fsm.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/usb/otg_fsm.h b/include/linux/usb/otg_fsm.h
index
Subject: xhci message rate control needed
fedora kernel 3.9.10-100.fc17.x86_64
xhci_hcd :12:00.0: ERROR Transfer event TRB DMA ptr not part of
current TD
i got this message about every 200 MICROseconds after a warm boot.
unplugging the usb3 cables silenced it. plugging back in,
Sounds like a bug. Why num_trbs_in_deq_seg becomes high? How many urbs
are submitted during resume? Normally only isoc transfer triggers ring
expansion with multiple trbs per urb.
I've seen the number of free ring entries go down after a sequence
where all the active urb got cancelled.
Not
This adds remove_phy flag to the HCD structure. If the flag is
set and if hcd-phy is valid, the phy is shutdown and released
whenever usb_add_hcd fails or usb_hcd_remove is called.
This also adds generic external phy support that allows
the HCD driver to search for a USB phy, bound to the HCD,
This adds remove_phy flag to the HCD structure. If the flag is
set and if hcd-phy is valid, the phy is shutdown and released
whenever usb_add_hcd fails or usb_hcd_remove is called.
This can be used by the HCD drivers to auto-remove
the external USB phy when it is no longer needed.
Signed-off-by:
This adds external USB phy support to USB HCD driver that
allows to find and initialize external USB phy, bound to
the HCD, when the HCD is added.
The usb_add_hcd function returns -EPROBE_DEFER if the USB
phy, bound to the HCD, is not ready.
If no USB phy is bound, the HCD is initialized as usual.
[1.] 0ccd:0038 [Intel DH57JG] suspend/resume failure
[2.] When using the Cinergy Terratec T2 USB DVB device, my computer
fails to suspend fully and then cannot resume. The power light on the
Cinergy device and also on my computer remain on throughout. My
computer is a homebuilt machine based on
On Thu, Nov 07 2013, Andrzej Pietrasiewicz wrote:
If there are setup requests not directed to an endpont or an interface,
current config's setup() has been attempted so far.
This patch, in case the above fails, adds code which tries the setup() of
configuration's function if there is only one
On Thu, Nov 07 2013, Andrzej Pietrasiewicz wrote:
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This alternate patch calculates offsets into the kmalloc-ed
memory
On Wed, Oct 23, 2013 at 02:51:49PM +0200, Andrew Lunn wrote:
Add a driver which supports the following Moxa USB to serial converters:
* 2 ports : UPort 1250, UPort 1250I
* 4 ports : UPort 1410, UPort 1450, UPort 1450I
* 8 ports : UPort 1610-8, UPort 1650-8
* 16 ports :
+#ifdef CONFIG_USB_PHY
+ if (!hcd-phy) {
+ struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller,
0);
+
+ if (IS_ERR(phy)) {
+ retval = PTR_ERR(phy);
+ if (retval == -EPROBE_DEFER)
+
Call try_to_freeze() in sleep_thread() only when its safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these wont call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Signed-off-by: George Cherian george.cher...@ti.com
---
On 11/07/2013 02:37 PM, George Cherian wrote:
Call try_to_freeze() in sleep_thread() only when its safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these wont call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Thank you. This is was Alan asked
Yann E. MORIN yann.morin.1...@free.fr writes:
Dirk, All,
On 2013-11-06 15:43 +0100, Dirk Gouders spake thusly:
Yann E. MORIN yann.morin.1...@free.fr writes:
[--SNIP--]
It seems I'm missing something here.
[--SNIP--]
Yes, but obviously, I did not describe it very clearly. The steps to
If choices consist of choice_values that depend on symbols set to 'm',
those choice_values are not set to 'n' if the choice is changed from
'm' to 'y' (in which case only one active choice_value is allowed).
Those values are also written to the config file causing modules to be
built when they
On 11/7/2013 7:19 PM, Sebastian Andrzej Siewior wrote:
On 11/07/2013 02:37 PM, George Cherian wrote:
Call try_to_freeze() in sleep_thread() only when its safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these wont call try_to_freeze() by passing can_freeze
Call try_to_freeze() in sleep_thread() only when its safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these wont call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Calling try_to_freeze() with a lock hold was done since day one in
f_mass_storage
Hi Johan
Thanks for the review.
I have a few questions, points to raise.
+ /* Submit the vendor request */
+ buf[0] = data_bits;
+ buf[1] = parity;
+ buf[2] = stop_bits;
+ buf[3] = 0;
+
+ err = mxuport_send_ctrl_data_urb(serial, RQ_VENDOR_SET_LINE,
+
On 11/07/2013 05:06 PM, Peter Chen wrote:
+#ifdef CONFIG_USB_PHY
+ if (!hcd-phy) {
+ struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller,
0);
+
+ if (IS_ERR(phy)) {
+ retval = PTR_ERR(phy);
+ if (retval ==
On Thu, 7 Nov 2013, Alistair Popple wrote:
Thanks. Based on the discussion for the EHCI driver I would like to change
the
compatibility string to usb-ochi (instead of ibm,akebono-ohci). Are you
still happy for me to add the Acked-by with the alternate compatibility (and
of course the
On Thu, Nov 07, 2013 at 03:39:16PM +0100, Andrew Lunn wrote:
Hi Johan
Thanks for the review.
I have a few questions, points to raise.
+ /* Submit the vendor request */
+ buf[0] = data_bits;
+ buf[1] = parity;
+ buf[2] = stop_bits;
+ buf[3] = 0;
+
+ err =
On Thu, 7 Nov 2013, Dan Carpenter wrote:
There is a bug in ehci_msm_probe() where we do:
hcd-irq = platform_get_irq(pdev, 0);
if (hcd-irq 0) {
The problem is that hcd-irq is unsigned so the error handling doesn't
work. I have made it signed.
Signed-off-by: Dan Carpenter
On Thu, 7 Nov 2013, Valentine Barshak wrote:
This adds external USB phy support to USB HCD driver that
allows to find and initialize external USB phy, bound to
the HCD, when the HCD is added.
The usb_add_hcd function returns -EPROBE_DEFER if the USB
phy, bound to the HCD, is not ready.
If
On Thu, 7 Nov 2013, Valentine Barshak wrote:
This adds remove_phy flag to the HCD structure. If the flag is
set and if hcd-phy is valid, the phy is shutdown and released
whenever usb_add_hcd fails or usb_hcd_remove is called.
This can be used by the HCD drivers to auto-remove
the external
On Thu, 7 Nov 2013, George Cherian wrote:
Call try_to_freeze() in sleep_thread() only when its safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these wont call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Calling try_to_freeze() with a
Hi,
as the conversion to dynamic debugging has progressed well,
I would like to ask whether -DDEBUG can be removed from
the Makefile without replacement, or, failing that, shifted
down to the individual drivers. Dynamic debugging should be
off by default. I'd be happy to male a patch.
On Wed, 6 Nov 2013, Julius Werner wrote:
What if the device is in USB_STATE_SUSPENDED?
I'm not sure that is possible at that point in hub_events(), I don't
know of a way that could lead to this situation. I could still add the
check just to be sure if you want it, though.
I don't know
xhci_hcd :12:00.0: ERROR Transfer event TRB DMA ptr not part of
current TD
This seems to happen if the hardware rejects a TRB with status TRB_ERROR (5).
In this case the 'address' field is that of the broken TRB not that
of some dma buffer.
While the TRB_ERROR status shouldn't happen, the
On Thu, Nov 07, 2013 at 04:31:15PM +0100, Oliver Neukum wrote:
Hi,
as the conversion to dynamic debugging has progressed well,
I would like to ask whether -DDEBUG can be removed from
the Makefile without replacement, or, failing that, shifted
down to the individual drivers. Dynamic
On Wed, 6 Nov 2013, Michal Nazarewicz wrote:
On Tue, Nov 05 2013, Alan Stern wrote:
Maybe Michal can enlighten us.
Sorry for late response, this thread fell under my radar for some
reason.
So here's how it works:
epfile represents an end point file on the fuctionfs file system,
i.e.
On 11/07/2013 01:33:56 AM, David Laight wrote:
Subject: xhci message rate control needed
fedora kernel 3.9.10-100.fc17.x86_64
xhci_hcd :12:00.0: ERROR Transfer event TRB DMA ptr not part of
current TD
i got this message about every 200 MICROseconds after a warm boot.
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 480M).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending
On 11/05/2013 05:39 PM, Cliff Brake wrote:
On Tue, Nov 5, 2013 at 9:57 AM, Alan Stern st...@rowland.harvard.edu wrote:
You might be better off writing a special-purpose userspace driver,
using libusb, instead of relying on the HID driver. That would allow
you to handle your data more
On 11/07/2013 02:41 AM, Oliver Neukum wrote:
On Tue, 2013-11-05 at 21:16 +, Luke-Jr wrote:
I am trying to interface with the HEX devices sold by http://technobit.eu/
which appear as CDC-ACM devices, but give an I/O error whenever I try to open
them, with some rather unclear error
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
I am debugging a weird musb problem in which musb is in high-speed
device mode loaded with g_mass_storage. For some reason, musb received
10 bytes in SETUP packets during enumeration. Please see the following
log from musb.
after
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
I am debugging a weird musb problem in which musb is in high-speed
device mode loaded with g_mass_storage. For some reason, musb received
10 bytes in SETUP packets
Hi,
On Thu, Nov 07, 2013 at 12:10:41PM -0600, Bin Liu wrote:
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
I am debugging a weird musb problem in which musb is in high-speed
device mode loaded with
On Thu, Nov 7, 2013 at 12:19 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 12:10:41PM -0600, Bin Liu wrote:
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
I am debugging a weird musb
Hi,
can someone explain to me why OHCI compiles in that strange
manner?
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
I don't know either. But Sarah has said that ports can spontaneously
go into Compliance Mode for no apparent reason. If that can happen,
maybe it can happen while the port is in U3 and the device is
suspended. In such cases, though, you'd need to do a reset-resume
rather than a simple
This patch adds a check for USB_STATE_NOTATTACHED to the
hub_port_warm_reset_required() workaround for ports that end up in
Compliance Mode in hub_events() when trying to decide which reset
function to use. Trying to call usb_reset_device() with a NOTATTACHED
device will just fail and leave the
On Thu, 7 Nov 2013, Bin Liu wrote:
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
I am debugging a weird musb problem in which musb is in high-speed
device mode loaded with g_mass_storage. For some reason,
On Tue, Nov 05, 2013 at 06:02:34PM +0100, Colin Leitner wrote:
FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would
only report this limitation for CS6 to dmesg and fail to reflect this fact to
tcgetattr.
This patch reverts the unsupported CSIZE setting and reports
On Thu, 7 Nov 2013, Oliver Neukum wrote:
Hi,
can someone explain to me why OHCI compiles in that strange
manner?
Please be more specific: Which aspect of the strangeness are you
interested in? :-)
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the
On Thu, 2013-11-07 at 14:05 -0500, Alan Stern wrote:
On Thu, 7 Nov 2013, Oliver Neukum wrote:
Hi,
can someone explain to me why OHCI compiles in that strange
manner?
Please be more specific: Which aspect of the strangeness are you
interested in? :-)
The strangeness of compilation
On Thu, 7 Nov 2013, Oliver Neukum wrote:
On Thu, 2013-11-07 at 14:05 -0500, Alan Stern wrote:
On Thu, 7 Nov 2013, Oliver Neukum wrote:
Hi,
can someone explain to me why OHCI compiles in that strange
manner?
Please be more specific: Which aspect of the strangeness are you
On Tue, Nov 05, 2013 at 07:20:41AM -0300, Gustavo Zacarias wrote:
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to
Great, all looks good now. Thanks for fixing this. Did you check if
there are even more (USB) serial drivers with similar problems (i.e.
testing C_CSIZE(tty) in set_termios)?
I just casually scanned through and, at least CSIZE, seems to be
handled pretty well by the ones with lots of IDs. I'll
On Thu, Nov 7, 2013 at 1:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 7 Nov 2013, Bin Liu wrote:
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
I am debugging a weird musb problem in which musb
On Thu, Nov 07, 2013 at 08:26:58PM +0100, Colin Leitner wrote:
Great, all looks good now. Thanks for fixing this. Did you check if
there are even more (USB) serial drivers with similar problems (i.e.
testing C_CSIZE(tty) in set_termios)?
I just casually scanned through and, at least
hi,
On Thu, Nov 07, 2013 at 01:40:40PM -0600, Bin Liu wrote:
On Thu, Nov 7, 2013 at 1:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 7 Nov 2013, Bin Liu wrote:
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Nov 07, 2013 at 11:54:48AM
This patch removes an erroneous check of CSIZE, making it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner colin.leit...@gmail.com
---
drivers/usb/serial/mos7840.c | 32
drivers/usb/serial/spcp8x5.c | 30
On Thu, Nov 07, 2013 at 09:12:09PM +0100, Colin Leitner wrote:
This patch removes an erroneous check of CSIZE, making it impossible to set
CS5.
Could you fix the subject-typo (s/settting/setting/) and perhaps also
rephrase the above sentence to something like:
This patch removes an
On Thu, Nov 7, 2013 at 12:47 PM, Alan Ott a...@signal11.us wrote:
On 11/05/2013 05:39 PM, Cliff Brake wrote:
On Tue, Nov 5, 2013 at 9:57 AM, Alan Stern st...@rowland.harvard.edu
wrote:
You might be better off writing a special-purpose userspace driver, using
libusb, instead of relying on
On Thu, Nov 07, 2013 at 08:07:07PM +0100, Oliver Neukum wrote:
On Thu, 2013-11-07 at 14:05 -0500, Alan Stern wrote:
On Thu, 7 Nov 2013, Oliver Neukum wrote:
Hi,
can someone explain to me why OHCI compiles in that strange
manner?
Please be more specific: Which aspect of the
On Thu, 2013-11-07 at 13:00 -0800, Greg KH wrote:
On Thu, Nov 07, 2013 at 08:07:07PM +0100, Oliver Neukum wrote:
The strangeness of compilation by #include
That was David Brownell's style of coding at the time (you can see it
also in the gadget drivers, although most of that has been
Seeing this since todays USB merge.
WARNING: CPU: 0 PID: 226 at kernel/lockdep.c:2740
lockdep_trace_alloc+0xc5/0xd0()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
Modules linked in: usb_debug(+) kvm_intel kvm crct10dif_pclmul crc32c_intel
ghash_clmulni_intel microcode(+) pcspkr serio_raw
On Mon, Oct 21, 2013 at 10:24:47AM -0400, Alan Stern wrote:
On Sun, 20 Oct 2013, Sarah Sharp wrote:
So it means xHCI driver should clear wakeup flags for suspended ports
in this case, just like ehci driver does. Correct?
Yes, I agree.
Sarah, is this worth reporting to the
Quoting Nicolas Ferre (2013-10-18 01:18:04)
On 11/10/2013 09:37, Boris BREZILLON :
Hello,
This patch series is the 4th version of the new at91 clock implementation
(using common clk framework).
Mike, DT maintainers,
Can you have a look at this series converting the AT91 family to
On Thu, Nov 07, 2013 at 05:37:28PM -0500, Dave Jones wrote:
Seeing this since todays USB merge.
WARNING: CPU: 0 PID: 226 at kernel/lockdep.c:2740
lockdep_trace_alloc+0xc5/0xd0()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
Modules linked in: usb_debug(+) kvm_intel kvm crct10dif_pclmul
On Thu, Nov 07, 2013 at 05:20:49PM -, David Laight wrote:
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
480M).
Which version of the spec are you looking at? I'm looking at the
On Fri, Nov 08, 2013 at 01:09:03AM +0100, Johan Hovold wrote:
A recent change in usb-serial used the wrong memory-allocation flag in
write(), which results in a
[5.979005] BUG: sleeping function called from invalid context at
/home/johan/src/linux/linux-nu/mm/dmapool.c:310
On Mon, Oct 28, 2013 at 05:09:25PM -, David Laight wrote:
We are seeing complete lockups of the transmit side when using
the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu.
These errors are very intermittent - less than once a day, and
it isn't actually clear
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Friday, November 01, 2013 6:33 PM
To: Chen Peter-B29397
Cc: linux-usb@vger.kernel.org
Subject: re: usb: chipidea: host: add vbus regulator control
Hello Peter Chen,
This is a semi-automatic email
+#ifdef CONFIG_USB_PHY
+ if (!hcd-phy) {
+ struct usb_phy *phy = usb_get_phy_dev(hcd-self.controller,
0);
+
+ if (IS_ERR(phy)) {
+ retval = PTR_ERR(phy);
+ if (retval == -EPROBE_DEFER)
+ return
From: Fabio Estevam fabio.este...@freescale.com
Commit 40ed51a4b (usb: chipidea: host: add vbus regulator
control) introduced a smatch complaint because regulator_disable() is called
without checking whether ci-platdata-reg_vbus is not NULL.
Fix this by adding the check.
Reported-by: Dan
Call try_to_freeze() in sleep_thread() only when it's safe to sleep.
do_read() and do_write() calls sleep_thread with lock held.
Make sure these won't call try_to_freeze() by passing can_freeze flag
to sleep_thread.
Calling try_to_freeze() with a lock hold was done since day one in
f_mass_storage
Johan Hovold jhov...@gmail.com writes:
Bjørn, do you want any more info for the commit message (e.g. interface
layout)?
I believe it's nice to document the layout of complex composite devices
if known, but if not then I don't see any need to delay a patch like
this.
Bjørn
--
To unsubscribe
68 matches
Mail list logo
