This patchs adds include guard to avoid double inclusion of the header.
Signed-off-by: Anton Tikhomirov
---
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 12ece58..55de52e 100644
--- a/includ
> 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
> 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 l
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,
whe
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 In
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 o
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 bu
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 port
>
> +#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
---
drivers/usb/gadget/f_mass_storage.c | 23 +++
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 as
"Yann E. MORIN" writes:
> Dirk, All,
>
> On 2013-11-06 15:43 +0100, Dirk Gouders spake thusly:
>> "Yann E. MORIN" writes:
> [--SNIP--]
>> > It seems I'm missing something here.
> [--SNIP--]
>> Yes, but obviously, I did not describe it very clearly. The steps to
>> reproduce the problem are:
>>
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 shou
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 fla
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 bu
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
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;
> > > +
>
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: Da
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.
>
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 extern
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
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.
Reg
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 kno
> 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 deb
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 syst
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 wa
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 (while
On 11/05/2013 05:39 PM, Cliff Brake wrote:
On Tue, Nov 5, 2013 at 9:57 AM, Alan Stern 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 efficiently, and with interrupts en
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 descripti
Hi,
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.
[ 447.100858] musb-hdrc musb-hdrc.0: usbintr (1) epintr(0)
[ 447.250
On 11/06/2013 08:04 AM, Stanislaw Wadas wrote:
In reference to the message sent by Andrzej Pietrasiewicz
(about libusbg (formerly libgadget)) I would like to propose
some changes to libusbg.
Creating directories is now performed after successful memory
allocation and gadget function creation. Ha
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.
>
>
On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi 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 durin
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 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_
On Thu, Nov 7, 2013 at 12:19 PM, Felipe Balbi 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 wrote:
>> > Hi,
>> >
>> > On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
>> >> I am debugging a weird musb problem in
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 http://vger.kernel.org/majordomo-i
> 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 por
On Thu, 7 Nov 2013, Bin Liu wrote:
> On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi 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 repor
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
th
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
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 s
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
> 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'
On Thu, Nov 7, 2013 at 1:02 PM, Alan Stern wrote:
> On Thu, 7 Nov 2013, Bin Liu wrote:
>
>> On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi 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
>>
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 leas
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 wrote:
> > On Thu, 7 Nov 2013, Bin Liu wrote:
> >
> >> On Thu, Nov 7, 2013 at 12:01 PM, Felipe Balbi wrote:
> >> > Hi,
> >> >
> >> > On Thu, Nov 07, 2013 at 11:54:48AM -0600, Bin Liu wrote:
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
---
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 e
On Thu, Nov 7, 2013 at 12:47 PM, Alan Ott wrote:
> On 11/05/2013 05:39 PM, Cliff Brake wrote:
>>
>> On Tue, Nov 5, 2013 at 9:57 AM, Alan Stern
>> wrote:
>>>
>>> You might be better off writing a special-purpose userspace driver, using
>>> libusb, instead of relying on the HID driver. That would a
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:
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
CPU:
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 wo
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
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_pclm
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
up
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:3
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 actuall
> -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-automat
> >>
> >> +#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)
> >> +
From: Fabio Estevam
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 Carpenter
Signed-off-by: Fabio
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 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 from this list: s
70 matches
Mail list logo
