On Tue, 2012-11-27 at 19:01 +0100, Sebastian Andrzej Siewior wrote:
> Since commit 89c8d91e31f2 ("tty: localise the lock") I see a dead lock
> in one of my dummy_hcd + g_nokia test cases. The first run one was usually
> okay, the second often resulted in a splat by lockdep and the third was
> usual
LUNTARY=y && CONFIG_HZ=250
The -lowlatency kernel is CONFIG_PREEMPT=y && CONFIG_HZ=1000
That is the only difference.
Regards,
Peter Hurley
--
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
cy kernel is a packaged Ubuntu alternate kernel configured as
CONFIG_PREEMPT=y + CONFIG_HZ=1000.
The stock Ubuntu kernel is CONFIG_PREEMPT_VOLUNTARY=y + CONFIG_HZ=250.
Regards,
Peter Hurley
--
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
anyway?
I'll open a bugzilla if a bunch more info is necessary.
Regards,
Peter Hurley
--
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
On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote:
> On Tue, 5 Feb 2013, Peter Hurley wrote:
>
> > With -next-20130204:
> >
> > [ 33.855570] irq 18: nobody cared (try booting with the "irqpoll" option)
> > [ 33.855580] Pid: 0, comm: swappe
On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote:
> On Tue, 5 Feb 2013, Peter Hurley wrote:
>
> > With -next-20130204:
> >
> > [ 33.855570] irq 18: nobody cared (try booting with the "irqpoll" option)
> > [ 33.855580] Pid: 0, comm: swappe
On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote:
> On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote:
> > On Tue, 5 Feb 2013, Peter Hurley wrote:
> >
> > > With -next-20130204:
> > >
> > > [ 33.855570] irq 18: nobody cared (tr
On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote:
> On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote:
> > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley
> > wrote:
> >> On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote:
> >>> On Tue, 2013-02
kill_traffic(port);
cancel_work_sync(&port->work);
if (device_is_registered(&port->dev))
> device_del(&port->dev);
}
}
[...]
}
Ummm, w
On Wed, 2013-02-13 at 18:27 +0100, Johan Hovold wrote:
> Move HUPCL handling to port shutdown so that DTR/RTS is dropped also on
> hang up.
>
> Currently a hung up port will return immediately from
> tty_port_close_start leaving DTR/RTS unchanged.
> ---
> drivers/tty/tty_port.c | 22 -
On Wed, 2013-02-13 at 14:32 -0500, Peter Hurley wrote:
> On Wed, 2013-02-13 at 18:27 +0100, Johan Hovold wrote:
> > Move HUPCL handling to port shutdown so that DTR/RTS is dropped also on
> > hang up.
> >
> > Currently a hung up port will return immediately from
>
On Wed, 2013-02-13 at 18:27 +0100, Johan Hovold wrote:
> Move port drain-delay handling to a separate function.
> ---
> drivers/tty/tty_port.c | 29 ++---
> 1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
>
On Wed, 2013-02-20 at 17:02 +0100, Johan Hovold wrote:
> These patches against tty-next fix a few issues with tty-port hangup and
> close.
>
> The first and third patch are essentially clean ups.
>
> The second patch makes sure DTR is dropped also on hangup and that DTR
> is only dropped for init
On Fri, 2013-02-22 at 12:35 -0500, Alan Stern wrote:
> On Fri, 22 Feb 2013, Johan Hovold wrote:
>
> > > > So we end up with an unregistered device still possibly referenced by
> > > > tty instead, and I suspect we can't do much else than deal with any
> > > > post-disconnect callbacks. [ These sho
On Wed, 2013-02-20 at 17:02 +0100, Johan Hovold wrote:
> Move HUPCL handling to port shutdown so that DTR is dropped also on hang
> up (tty_port_close is a noop for hung-up ports).
>
> Also do not try to drop DTR for uninitialised ports where it has never
> been raised (e.g. after a failed open).
The tty port ops shutdown() routine is not called for console ports;
remove extra check.
Signed-off-by: Peter Hurley
---
drivers/usb/serial/usb-serial.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb
On Tue, 2013-02-26 at 12:14 +0100, Johan Hovold wrote:
> These patches against tty-next fix a few issues with tty-port hangup and
> close.
>
> The first and third patch are essentially clean ups.
>
> The second patch makes sure DTR is dropped also on hangup and that DTR
> is only dropped for init
On Tue, 2013-03-05 at 17:02 +0100, Jiri Slaby wrote:
> On 02/28/2013 09:57 PM, Peter Hurley wrote:
> > Hi Jiri,
> >
> > Just wanted to make sure you saw this series.
>
> Hi, thanks for letting me know. Johan, care to CC Alan Cox and me (or at
> least LKML) when you
On Tue, 2013-03-05 at 22:56 +0100, Jiri Slaby wrote:
> On 03/05/2013 06:06 PM, Peter Hurley wrote:
> >>> @@ -225,15 +232,13 @@ void tty_port_hangup(struct tty_port *port)
> >> spin_lock_irqsave(&port->lock, flags);
> >> p
On Tue, 2013-03-05 at 23:10 +0100, Jiri Slaby wrote:
> On 03/05/2013 11:02 PM, Peter Hurley wrote:
> > On Tue, 2013-03-05 at 22:56 +0100, Jiri Slaby wrote:
> >> On 03/05/2013 06:06 PM, Peter Hurley wrote:
> >>>>> @@ -225,15 +232,13 @@ void t
[now this discussion has turned to usb gadget
+cc Felipe Balbi, linux-usb, -cc Dave Jones, Ilya Zykov]
On Tue, 2013-03-05 at 23:39 +0100, Jiri Slaby wrote:
> On 03/05/2013 11:20 PM, Peter Hurley wrote:
> > [--cc Alan Cox]
> >
> > On Tue, 2013-03-05 at 21:50 +0100, Sebastian
the changed order is actually preferred as it
> allows the waiting process to return based on ASYNC_INITIALIZED. This is
> also the order used by serial_core. Note however that the current
> serial_core TIOCMIWAIT is broken in that it doesn't return on hangups at
> all.
>
> Perhap
On Thu, 2013-03-07 at 10:43 +0100, Johan Hovold wrote:
> On Wed, Mar 06, 2013 at 02:14:56PM -0500, Peter Hurley wrote:
> > On Wed, 2013-03-06 at 17:52 +0100, Johan Hovold wrote:
> > > Yes, I did. First, the order should not matter for blocked opens as they
> > > will exi
[ +linux-usb, linux-pci]
This is the 2nd report today for unhandled interrupts with usb hcd.
On Fri, 2013-03-08 at 08:37 +0100, Thomas Meyer wrote:
> [1.883369] input: C-Media Electronics Inc. USB Multimedia Audio Device as
> /devices/pci:00/:00:1d.7/usb2/2-1/2-1.2/2-1.2:1.3/input/in
[ +linux-pci, +linux-acpi, +Rafael Wysocki, +Bjorn Helgaas ]
On Sat, 2013-03-09 at 09:53 +0100, Thomas Meyer wrote:
> Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
> > On Fri, 8 Mar 2013, Peter Hurley wrote:
> >
> > > [ +linux-usb ]
> > >
> &
ct file *filp,
./drivers/tty/synclink.c:static int block_til_ready(struct tty_struct *tty,
struct file * filp,
./net/irda/ircomm/ircomm_tty.c:static int ircomm_tty_block_til_ready(struct
ircomm_tty_cb *self,
Please be sure to Cc: David Miller on changes to
net/irda.
Regards,
Peter Hurl
- use cflag-macros throughout
Other than the comments for patch 3/6, this series looks good. Thanks
again for your work on this.
Please cc: me on the USB serial core changes as well, if you don't mind.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe
> > 100% objective measure.
>
> So I will try a bisect, but it'll take some time so that I could claim it
> to be trustworthy.
>
> Therefore in case anyone has any idea in parallel, I am all ears.
When I had this happen on -next, it was PCI + ACPI-related and I had t
On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
> On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
> > On Thu, 14 Mar 2013, Jiri Kosina wrote:
> >
> > > > > I don't think I have seen this message on rc1+ (8343bce, to be
> > > > > precise),
> > > > > but I have definitely se
On Thu, 2013-03-14 at 18:22 +0100, Rafael J. Wysocki wrote:
> On Thursday, March 14, 2013 01:06:04 PM Peter Hurley wrote:
> > On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
> > > > On Thu,
;
> Note that the order currently does not matter as the tty-layer can make
> callbacks also after the device has been unregistered. This is
> handled in usb-serial core using the disconnected flag, which is
> already set when usb-serial bus device remove is called.
>
> Cc: Peter
On Fri, 2013-03-15 at 10:24 +0100, Johan Hovold wrote:
> On Wed, Mar 13, 2013 at 03:43:43PM -0400, Peter Hurley wrote:
> > On Thu, 2013-03-07 at 15:55 +0100, Johan Hovold wrote:
> > > Make sure to check ASYNC_INITIALISED before raising DTR when waking up
> >
On Fri, 2013-03-15 at 12:30 +0100, Johan Hovold wrote:
> On Fri, Mar 15, 2013 at 07:03:08AM -0400, Peter Hurley wrote:
> > On Fri, 2013-03-15 at 10:24 +0100, Johan Hovold wrote:
> > > On Wed, Mar 13, 2013 at 03:43:43PM -0400, Peter Hurley wrote:
> > > > On Thu, 20
On Thu, 2013-03-14 at 19:30 +0100, Johan Hovold wrote:
> On Thu, Mar 14, 2013 at 01:39:39PM -0400, Peter Hurley wrote:
> > On Thu, 2013-03-14 at 16:23 +0100, Johan Hovold wrote:
> > > Make sure to unregister the tty-device before calling subdriver
> > > port_remove.
&
ng this construct
into the glue layer.
Thanks again,
Peter Hurley
--
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
then a (re)enumeration is performed.
related bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649
I thought I saw someone reporting this problem recently on LKML;
where is the Reported-by so that Sarah can follow-up with the
reporter directly, if desired?
Regards,
Peter Hurley
[1
On 07/18/2013 06:09 PM, Sarah Sharp wrote:
On Thu, Jul 18, 2013 at 04:28:01PM -0400, Peter Hurley wrote:
[ +cc Sarah Sharp, linux-usb ]
On 07/18/2013 09:21 AM, Nestor Lopez Casado wrote:
This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
This patch re-adds the workaround
On 07/22/2013 07:44 AM, Jiri Kosina wrote:
On Fri, 19 Jul 2013, Peter Hurley wrote:
As far as getting printk output from a custom kernel, I think that may
be beyond the reporter's capability. Perhaps one of the Ubuntu devs
triaging this bug could provide a test kernel for the OP with
On 08/12/2013 05:54 PM, Peter Wu wrote:
On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
Before we revert to using the workaround, I'd like to suggest that
this new "hidden" problem may be an interaction with the xhci_hcd host
controller driver only.
Looking at the rela
On 08/13/2013 11:42 AM, Peter Wu wrote:
On Tuesday 13 August 2013 08:13:17 Peter Hurley wrote:
On 08/12/2013 05:54 PM, Peter Wu wrote:
On Thursday 18 July 2013 16:28:01 Peter Hurley wrote:
Before we revert to using the workaround, I'd like to suggest that
this new "hidden" pr
s per call when the port
fifo is empty, which makes chars_in_buffer about 100 times slower on my
test system.)
A better solution for stable would be to set port->drain_delay. It
won't help tcdrain() but at least the port won't shutdown on live
outbound data.
Regards,
Peter Hurl
On 10/30/2014 08:08 AM, Johan Hovold wrote:
> Hi Peter,
>
> Forgot to reply to this one.
>
> On Wed, Oct 22, 2014 at 07:40:20AM -0400, Peter Hurley wrote:
>> On 10/19/2014 01:12 PM, Johan Hovold wrote:
>>> [ +CC: Jiri, Alan, linux-serial ]
>>>
>>>
if (tty->termios.c_cflag & CLOCAL)
> + stop_tty(tty);
> + else
> + tty_hangup(tty);
It seems you missed my earlier email: what happens if you leave
out the stop_tty() call here?
I ask because the tty is still
gister the ldsem lock class
from the tty_ldisc_ref() means that no tty has yet been opened [see 1].
So how did the call to tty_port_tty_get() in pl2303_update_line_status()
return a tty?
If you can easily reproduce this, I can supply you with a debug patch
to find out what's going on.
Regards
On 01/03/2015 11:26 AM, Johan Hovold wrote:
> On Wed, Dec 31, 2014 at 09:07:59PM -0500, Peter Hurley wrote:
>> Hi Johan,
>>
>> On 11/18/2014 11:18 AM, Johan Hovold wrote:
>>> I get this missing-lockdep-annotation warning which I haven't seen
>>> befo
On 02/22/2014 10:14 AM, Alan Stern wrote:
On Sat, 22 Feb 2014, Tejun Heo wrote:
Hello,
If this is actually safe, let's do it from the get-go.
Thanks!
--- 8< ---
PREPARE_[DELAYED_]WORK() are being phased out. They have few users
and a nasty surprise in terms of reentrancy guarantee as
exactly how the throttle
mechanism works, and the tty buffer API is specifically designed to
allow drivers to manage flow via that interface as well (especially
for high-throughput drivers).
The n_tty throttle/unthrottle is a very indirect method for restricting
flow, and at extremely high bit rates may not be appropriate. (It's
mostly a historical vestige from pre-tty buffer days).
Regards,
Peter Hurley
--
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
s but just not
to the extent you're experiencing.
For example, I made changes to the conditions required to restart the
input worker; I may have omitted some necessary condition which you've
triggered.
> On 21/07/15 18:45, Peter Hurley wrote:
>> 1. Instrument acm_read_bulk_callback
On 07/22/2015 04:40 AM, Oliver Neukum wrote:
> On Tue, 2015-07-21 at 12:45 -0400, Peter Hurley wrote:
>> Let me know if you need help instrumenting the tty buffers/throttling
>> to help figure out what the actual problem is.
>>
>> Regarding the patch itself, I have no op
Hi Sven,
On 07/21/2015 08:47 PM, Sven Brauch wrote:
> On 22/07/15 01:34, Peter Hurley wrote:
>> I'd like to see that data, if you can, which will help me understand
>> at least the timing.
> Sure, please see below for the code which produced the output
> and the actual
generic driver.
read() is limited to 4096 bytes by the driver.
What linux version are you using?
Regards,
Peter Hurley
--
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
and the line speed is too fast for no flow control.
Regards,
Peter Hurley
>>> Please don't use the "generic" driver, it's slow and not the best to
>>> use
>
> Could you tell me is generic driver is suitable for my application ( My usb
> device sendi
On 07/22/2015 11:01 AM, Oliver Neukum wrote:
> On Wed, 2015-07-22 at 10:30 -0400, Peter Hurley wrote:
>> 3. Pre-allocate space _before_ the data arrives (with
>> tty_buffer_request_room());
>>this is applicable to subsystems which know how much data can be
>> in-f
going to work @ 4Mbaud line rate.
If you're stuck using software flow control, start with a 115kbaud line rate
and see if that fixes your data loss problem.
Regards,
Peter Hurley
> On Wed, Aug 5, 2015 at 12:59 AM, Peter Hurley
> wrote:
>> On 08/03/2015 10:47 PM, arun k wrote:
&
n with issue.
Yes. Also, can you test this on a newer kernel like 3.18?
Regards,
Peter Hurley
> On Wed, Aug 5, 2015 at 11:24 AM, Peter Hurley <mailto:pe...@hurleysoftware.com>> wrote:
>
> On 08/04/2015 10:00 PM, arun k wrote:
> > I enabled software flow con
On 07/22/2015 06:53 PM, Sven Brauch wrote:
> Hi,
>
> On 23/07/15 00:12, Peter Hurley wrote:
>> The premature unthrottle actually leads to the data loss but the throttling
>> with a mere 2K left is _way too late_.
> Ok, yes, I think so too.
>
>> 10ms is a _r
nd.
To answer your original question, yes, the write() is behaving as expected.
If you open a tty without O_NONBLOCK, then both read() and write() to that
tty will _block_ until the operation is successful or the tty is hung up.
Your comparison with how ttyS* ports behave when a cable is not con
ion is the problem?
What h/w platform is this?
You mentioned earlier you're running 3.4.35. That's really old; current 3.4
is .108. Where did you get this kernel?
Regards,
Peter Hurley
PS - Please stop top-posting. See how I had to reiterate your linux version...
>>> I think the
d, caller);
> - WARN_ON_ONCE(!spin_is_locked(&devinfo->lock));
> + lockdep_assert_held(&devinfo->lock);
This change isn't equivalent.
lockdep_assert_held() will continue to emit warnings; ie., there is no
"once" functionality. Same for the other changes below.
Reg
he first open() and
cleanup() when the tty is being released. usb serial does this with
usb_serial_port_get_by_minor() from serial_install() and usb_serial_put() in
serial_cleanup() and usb_serial_disconnect().
2. a flag (like usb serial's '->disconnected') to prevent continued p
; should be more like tty_port_cleanup(),
as it doesn't actually deallocate the port (because tty_port could be an
embedded structure in a larger 'port' which is the most common usage).
I've been struggling to understand how this patch could even cause the
wait_event() to complete
On 10/10/2014 12:05 AM, Andre Wolokita wrote:
>
>
> On 10/10/14 00:47, Peter Hurley wrote:
>> Hi Andre,
>>
>> On 10/08/2014 11:54 PM, Andre Wolokita wrote:
>>> On 09/10/14 14:38, Greg KH wrote:
>>>> On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre
[ +Jan Dumon, netdev ]
Forwarding oops report to maintainer.
On 10/10/2014 10:02 AM, Christian Melki wrote:
> I'm using a ppc 8347 with a normal 3.16.1 kernel.
> The software opens the driver tty in question and then sets it as stdin,
> stdout for chat-program and pppd.
> When I yank the modem w
On 10/10/2014 09:44 PM, Nathan Lynch wrote:
> On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
>>
>> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
>> it seems that this has been known about for some time.)
>
> Looking at http://gcc.gnu.org/PR58854 it seems that all
On 10/11/2014 10:51 AM, Otavio Salvador wrote:
> Hello Russell,
>
> On Sat, Oct 11, 2014 at 11:16 AM, Russell King - ARM Linux
> wrote:
>> On Sat, Oct 11, 2014 at 11:54:32AM +0800, Peter Chen wrote:
>>> On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote:
On 10/10/2014 11:25 AM, Rus
t; is dealing with the stack.
>>
>> I think the only viable solution here is that:
>>
>> 1. We blacklist the bad compiler versions outright in the kernel.
>
> Yes, please do this, it's what we have done for other buggy compiler
> versions, no need to do some
Commit 90419cfcb5d9c889b10dc51363c56a4d394d670e,
"USB: kobil_sct: fix control requests without data stage", removed
the bogus data buffer arguments, but still allocate transfer
buffers which are not used.
Cc: Johan Hovold
Signed-off-by: Peter Hurley
---
drivers/usb/serial/kobil_
On 10/16/2014 01:59 PM, Peter Hurley wrote:
> Commit 90419cfcb5d9c889b10dc51363c56a4d394d670e,
> "USB: kobil_sct: fix control requests without data stage", removed
> the bogus data buffer arguments, but still allocate transfer
> buffers which are not used.
>
> Cc: J
On 10/22/2014 04:20 AM, Johan Hovold wrote:
> On Thu, Oct 16, 2014 at 01:59:22PM -0400, Peter Hurley wrote:
>> Commit 90419cfcb5d9c889b10dc51363c56a4d394d670e,
>> "USB: kobil_sct: fix control requests without data stage", removed
>
> checkpatch.pl complains on you
On 10/19/2014 01:12 PM, Johan Hovold wrote:
> [ +CC: Jiri, Alan, linux-serial ]
>
> On Thu, Oct 16, 2014 at 02:09:29PM -0400, Peter Hurley wrote:
>> On 10/16/2014 01:59 PM, Peter Hurley wrote:
>>> Commit 90419cfcb5d9c889b10dc51363c56a4d394d670e,
>>> "USB: k
On 10/22/2014 08:07 AM, Joe Perches wrote:
> On Wed, 2014-10-22 at 06:26 -0400, Peter Hurley wrote:
>> On 10/22/2014 04:20 AM, Johan Hovold wrote:
>>> On Thu, Oct 16, 2014 at 01:59:22PM -0400, Peter Hurley wrote:
>>>> Commit 90419cfcb5d9c889b10dc51363c56a4d394d6
ty);
>> +else
>> + tty_hangup(tty);
>
> this I'll defer to Greg who also maintains tty.
I'm curious what happens without stop_tty().
The tty is restartable from userspace with
tcflow(fd, TCOOFF);
tcflow(fd, TCOON);
Regards,
Peter Hurley
--
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
itions.
But you don't want to do it for every tty open, only for opens
requiring port initialization, which is what the tty_port->activate()
method is for (ie., acm_port_activate()).
Note that the ftdi_sio driver is a usb serial port driver; ftdi_open()
is called from serial_port_activa
that they
> do not honour ((IGNBRK || (!BRKINT && !PARMRK)) && (IGNPAR || !INPCK)).
These settings are a constant source of bugs in serial drivers.
We really need to abstract the way these settings are processed;
even the 8250 driver is getting this wrong.
Regards,
Peter Hurley
--
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
On 08/05/2015 01:36 PM, Peter Hurley wrote:
> On 07/22/2015 06:53 PM, Sven Brauch wrote:
>> On 23/07/15 00:12, Peter Hurley wrote:
>>> The premature unthrottle actually leads to the data loss but the throttling
>>> with a mere 2K left is _way too late_.
>> Ok, yes,
On 10/21/2015 06:12 AM, Oliver Neukum wrote:
> On Tue, 2015-10-20 at 14:16 -0400, Peter Hurley wrote:
>> ECHO is on by default and the cdc-acm driver does not implement the
>> put_char() and flush_chars() tty driver methods, which made the
>> problem
>> _way worse_, sinc
On 10/21/2015 08:09 AM, Peter Hurley wrote:
> Be aware that while the N_TTY line discipline ensures that put_char()
> and write() usage will not be interleaved without flush_chars(), other
> line disciplines might not, so at least be sure that driver won't
> crash if that happen
run a few more tests before we look at your patch
> again? It really has issues, but it does help and nothing else
> does. If necessary I will merge an improved version of your patch.
I would much rather rework URB flow + unthrottle, as I previously
outlined in the original thread instead of
On 10/28/2015 08:33 AM, Oliver Neukum wrote:
> Peter, do you think I ought to upstream the support for put_char() ?
Yes, but I owe you a test jig to validate it first. I'll do my best
to get that to you today.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line &quo
On 10/28/2015 11:53 AM, Sven Brauch wrote:
> On 28/10/15 13:23, Peter Hurley wrote:
>> Sven, please test Oliver's patch on that tree.
> I will do as soon as I get around to it, I hope on the weekend.
Ok.
I'll get you the kworker scheduler latency profiling howto so
we can
echoke -extproc
If there's anything else which would be helpful for you to have tested,
please let me know.
Just the kernel .config of the host please.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to
On 11/02/2015 06:32 AM, Oliver Neukum wrote:
> It looks like the throttling code isn't perfect yet
Yeah, that's still a todo (ie., fixing the premature unthrottle).
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body
e intermediate buffer, preferably lockless since there is only
one producer and one consumer.
Some other review comments below; please ignore anything other reviewers
have already noted.
Regards,
Peter Hurley
> Signed-off-by: Baolin Wang
> ---
> drivers/usb/gadget/Kconfig
On 11/19/2015 01:48 AM, Baolin Wang wrote:
>>
>>> +{
>>> + struct gscons_info *info = gserial_cons.data;
>>> + int port_num = gserial_cons.index;
>>> + struct usb_request *req;
>>> + struct gs_port *port;
>>> + struct usb_ep *ep;
>>> +
>>> + if (port_num >= MAX_U_SERIAL_PORT
On 11/18/2015 09:35 PM, Baolin Wang wrote:
> On 18 November 2015 at 23:32, Peter Hurley wrote:
>> Hi Baolin,
>>
>> On 11/16/2015 02:05 AM, Baolin Wang wrote:
>>> It dose not work when we want to use the usb-to-serial port based
>>> on one usb gadget as a co
y_wait_until_sent_from_close (e.g. via
> tty_port_close_start).
Reviewed-by: Peter Hurley
--
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
On 03/04/2015 04:39 AM, Johan Hovold wrote:
> Remove incorrect and redundant wait_until_sent operation, which waits
> for the driver buffer rather than any hardware buffers to drain,
> something which is already taken care of by the tty layer (and
> chars_in_buffer).
Reviewed-by:
implementation is not affected
> by this bug due to a lucky chance (comparison to an unsigned maximum
> timeout), and neither is the cyclades one that had an explicit check for
> negative timeouts, but all other tty drivers appear to be affected.
Reviewed-by: Peter Hurley
--
To unsubscrib
88 matches
Mail list logo
