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
UNTARY=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
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 >=
On 11/18/2015 09:35 PM, Baolin Wang wrote:
> On 18 November 2015 at 23:32, Peter Hurley <pe...@hurleysoftware.com> 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
>
ermediate 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 <baolin.w...@linaro.org>
> ---
> dr
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 of a mess
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 majord...@vger.kerne
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 "uns
> 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 introducing another
buffering layer.
Regards,
Pe
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 find out w
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 happens.
S
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 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,
; 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 generic USB driver ignores baud rate. Like Greg suggested,
you need to
use the proper driver for your hardware.
I did't find
writing the data out without knowing that nothing is listening.
I don't see a bug here.
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
Hurley
On Wed, Aug 5, 2015 at 11:24 AM, Peter Hurley pe...@hurleysoftware.com
mailto:pe...@hurleysoftware.com wrote:
On 08/04/2015 10:00 PM, arun k wrote:
I enabled software flow control like below
tty.c_iflag |= (IXON | IXOFF | IXANY);
Ok, but does the sending
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 _really_ long time for a cpu not to attend
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-flight
at any one time
properly.
I tried this method but in my case I found data loss. By changing any buffer
size modification in driver side , can we fix this issue ?
The data loss is probably occurring because you have all flow control disabled
and the line speed is too fast for no flow control.
Regards,
Peter
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 pe...@hurleysoftware.com
wrote:
On 08/03/2015 10:47 PM, arun k wrote:
Thank you
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
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 output. Let me know if you need
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 opinion on the suitability of
simply
-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
,
failure to progress, etc.) which is affecting other users 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
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: Peter Hurley pe
(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 pe...@hurleysoftware.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb
tty_port_close_start).
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
before when booting with a usb-serial console on 3.18-rc5. It's
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,
Peter Hurley
[ 10.575225] usbserial: USB Serial support
(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 restartable from userspace after you
stop_tty() here. So if your goal is to prevent write() from
happening, this won't work.
Regards,
Peter Hurley
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 ]
On Thu, Oct 16, 2014 at 02:09:29PM -0400, Peter Hurley wrote
in 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
()).
Note that the ftdi_sio driver is a usb serial port driver; ftdi_open()
is called from serial_port_activate(), which is the activate() method
for all usb serial drivers.
Regards,
Peter Hurley
---
drivers/usb/class/cdc-acm.c | 21 -
1 file changed, 12 insertions(+), 9
)
+stop_tty(tty);
+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
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 your commit-reference style so you know
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: kobil_sct: fix control requests without data stage
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 90419cfcb5d9c889b10dc51363c56a4d394d670e,
USB: kobil_sct: fix control requests
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 jhov...@gmail.com
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
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: Johan Hovold jhov...@gmail.com
Signed
have to write it myself?
I did on Friday (arm: Blacklist gcc 4.8.[012] ...) but Russell said he
was doing it himself.
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
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
li...@arm.linux.org.uk 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
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 Wolokita wrote:
On 09/10/14 13:56, Greg KH wrote:
On Thu, Oct
[ +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
the port-openclose flag.
FWIW, the tty_unregister_device() does not need to be after gserial_free_port()
because existing ttys maintain a device reference count which prevents the
underlying tty device from being released.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe
is that
the deallocation in tty_port_destroy() somehow causes the process with
the open tty to crash but I don't see how.
Regards,
Peter Hurley
PS - My earlier email was greylisted so that's why I appeared to reply
well after your answer :)
X-Greylist: delayed 4693 seconds by postgrey-1.27 at vger.kernel.org
(!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.
Regards,
Peter Hurley
WARN_ON_ONCE(cmdinfo-state COMMAND_ABORTED
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
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 those
.
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]
https://bugs.launchpad.net/ubuntu/+source
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
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 Hurley
--
To unsubscribe from this list: send the line unsubscribe
just meant that current and future contributors may not have as much
comprehension of the tty layer and the subtleties of tty lifetimes
(which has obviously been a recurrent problem).
As you point out, the problem is fixed by consolidating this construct
into the glue layer.
Thanks again,
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
from blocked open in tty_port_block_til_ready
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, 2013-03-07 at 15:55 +0100, Johan Hovold wrote
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.
This way remove will reverse
I had this happen on -next, it was PCI + ACPI-related and I had to
bisect it. But for me the problem was quite noticable and showed up
right at login prompt.
Regards,
Peter Hurley
PS - I already confirmed that the commit that fixes that is in 3.9-rc1
--
To unsubscribe from this list: send
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 seen sluggish system
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, 14 Mar 2013, Jiri Kosina wrote
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 Hurley pe...@hurleysoftware.com
Reported
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 linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ +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 ]
On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr
[ +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
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 exit their wait loops based
this to a patch of its own, and send a fix
for serial_core TIOCMIWAIT as well.
uart_wait_modem_status() is what I was referring to and should be fixed.
Patches always welcome.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord
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're changing the TTY core next time
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);
port-count = 0;
port-flags = ~ASYNC_NORMAL_ACTIVE
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 tty_port_hangup(struct tty_port *port)
spin_lock_irqsave
[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 Andrzej Siewior wrote
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
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 pe...@hurleysoftware.com
---
drivers/usb/serial/usb-serial.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/usb-serial.c b
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 should be few,
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
);
}
}
[...]
}
Ummm, wasn't that where the port private data pointer was?
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 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
tty_port_close_start leaving DTR/RTS
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
index
On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote:
On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote:
On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com
wrote:
On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote:
On Tue, 2013-02-05 at 15:26
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: swapper/4 Not tainted 3.8.0-next-20130204-xeon
#20130204
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: swapper/4 Not tainted 3.8.0-next-20130204-xeon
#20130204
correct way to clear usb3.0 device's remote wakeup feature.
I didn't see any changes in the drivers/hid/hid-logitech-dj.c or usbhid
but maybe it's doing something wrong anyway?
I'll open a bugzilla if a bunch more info is necessary.
Regards,
Peter Hurley
--
To unsubscribe from this list: send
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
usually a
83 matches
Mail list logo
