On Fri, Nov 4, 2016 at 3:33 PM, Nathan Zimmer wrote:
> On Thu, Nov 03, 2016 at 06:25:46PM -0600, Peter Hurley wrote:
>> On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer wrote:
>> > On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote:
>> >> On Mon, Oct 31, 2016
7;ve
> seen patches flying around fixing such issues. Unfortunately I
> cannot reliably reproduce this and booting a production machine
> with lockdep would be problematic.
Too bad because lockdep would definitively tell you what process is
holding the ldsem for this tty.
If you paste *all the tasks*, I can try to see if I recognize the task
stack that is holding the ldsem.
Regards,
Peter Hurley
On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer wrote:
> On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote:
>> On Mon, Oct 31, 2016 at 2:27 PM, Sean Young wrote:
>> > On Sun, Oct 30, 2016 at 10:33:02AM -0500, Nathan wrote:
>> >> I think this should
;t use IRQs; iow, maybe the serial
port w/ driver never actually worked.
2. Can you post dmesg for the SLES 11 setup? That would show if there
were probe errors even on that.
An alternative that should be equivalent to your previous setup is to
build w/ CONFIG_SERIAL_8250_PNP=n
Seems like your ACPI BIOS is buggy, but also that something else is using IRQ 3?
Regards,
Peter Hurley
I'm here so let's make time to discuss this.
Regards,
Peter Hurley
ata specified in a string, for example taken from command line or
>> compiled by ACPI SPCR table handler.
>>
>> Signed-off-by: Aleksey Makarov
>> Reviewed-by: Peter Hurley
>> ---
>> drivers/tty/serial/amba-pl011.c | 56
>> +
error:
>
> [5.541751] ttyS0 - failed to request DMA
>
> Reverting the commit ec5a11a91eec removes the error.
The error is that your dmaengine driver doesn't support the functionality
required by the 8250 driver.
Regards,
Peter Hurley
> I saw that you started the
ome kind of naming scheme that preserves
both the command line parameters (uart,uart8250,pl011,etc.) and uniquely
identifies which uart driver is the earlycon.
The current scheme could be fixed easily enough (by just using a single digit).
Or using a separator, ie. uart/0, pl011/0, etc.
Re
page = get_zeroed_page(GFP_KERNEL);
> - if (!page)
> + if (!page) {
if (!uart_console(uport))
Otherwise, you'll be powering off the console.
Just out of curiosity, did you actually hit this error?
Regards,
Peter Hurley
> + u
eally)
> and noticed that the most recent builds were against GCC 4.6.3.
Someone's been making them.
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
arm64
alpha
arm = gnueabi
parisc = hppa
parisc64 = hppa64
mips
mips64
powerpc
powerpc64
sparc
sparc64
s390
...
Regards,
Peter Hurley
; for documentation, as it's probably not going to cost anything in
> practice. It would be better to avoid adding any special macros for this
> which may just add more complexity.
See, I don't understand this line of reasoning at all.
I read this as "it's ok to be non-optimal here where were spinning CPU
time but not ok to be non-optimal generally elsewhere where it's
way less important like at init time".
And by the way, it's not just "here" but _everywhere_.
What about reading ->on_cpu locklessly?
Sure it's a bool, but doesn't the "we need to document lockless access"
argument equally apply here?
Regards,
Peter Hurley
Hi Paul,
You can disregard this as I think we're talking about
the same things with the other email thread.
Regards,
Peter Hurley
On 05/17/2016 12:46 PM, Peter Hurley wrote:
> On 05/16/2016 10:22 AM, Paul E. McKenney wrote:
>> On Mon, May 16, 2016 at 07:17:42AM -0700, Pete
On 05/16/2016 10:22 AM, Paul E. McKenney wrote:
> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote:
>> On 05/16/2016 05:17 AM, Paul E. McKenney wrote:
>>> On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote:
>>>> On Fri, May 13, 2016 at 10:58:
On 05/16/2016 10:50 AM, Peter Zijlstra wrote:
> On Mon, May 16, 2016 at 07:17:42AM -0700, Peter Hurley wrote:
>
>>>> Correct; which is why we should always use {READ,WRITE}_ONCE() for
>>>> anything that is used locklessly.
>>>
>>> Completely
interrupt-issue/20160513-162046 HEAD
>> 0354112aa9821bec8d278ad06b3d543724f5291d builds fine.
>> It only hurts bisectibility.
>>
>> All errors (new ones prefixed by >>):
>
> Peter, what happened to your DMA series in the linux-next? Did I miss
> any discu
On 05/17/2016 08:57 AM, Peter Hurley wrote:
> On 05/16/2016 04:36 PM, Peter Hurley wrote:
>> > Hi Mikulas,
>> >
>> > On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
>>> >> Hi
>>> >>
>>> >> In the kernel 4.6 I get cras
On 05/12/2016 03:56 PM, Waiman Long wrote:
> This patch moves the owner loading and checking code entirely inside of
> rwsem_spin_on_owner() to simplify the logic of rwsem_optimistic_spin()
> loop.
Thanks for this.
Reviewed-by: Peter Hurley
Although there's no particular harm in the current code, this at
least spells out this condition is normal (ie., when a failed reader
wakes itself while waking the other waiting readers).
Reviewed-by: Peter Hurley
eck. If another reader is present, the code
> will still break out and exit even if the writer is gone. This patch
> changes it to check the same "< RWSEM_WAITING_BIAS" condition to
> reduce the chance of false positive.
Nice.
Reviewed-by: Peter Hurley
On 05/16/2016 04:36 PM, Peter Hurley wrote:
> Hi Mikulas,
>
> On 05/16/2016 01:12 PM, Mikulas Patocka wrote:
>> Hi
>>
>> In the kernel 4.6 I get crashes in the tty layer. I can reproduce the
>> crash by logging into the machine with ssh and typing before the pr
[ +to Scot Doyle ]
Scot, please take a look at this soft lockup.
Regards,
Peter Hurley
Hi Ming,
On 05/17/2016 02:12 AM, Ming Lei wrote:
> Hi,
>
> On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
> wrote:
>> Hi,
>> I'm observing a soft lockup issue w/ the ASP
that the crashes are caused by the patch
> 892d1fa7eaaed9d3c04954cb140c34ebc3393932 ("tty: Destroy ldisc instance on
> hangup").
Can you try the test patch below?
Regards,
Peter Hurley
> Kernel Fault: Code=15 regs=7d9e0720 (Addr=2260)
> CPU: 0 PID: 3319 Comm:
if we have not opened any
> other serial drivers, because SERIAL_CORE would not be selected.
I don't understand what this means.
Regards,
Peter Hurley
> Signed-off-by: Zhen Lei
> ---
> drivers/tty/serial/8250/Kconfig | 9 +++--
> drivers/tty/serial/8250/Makefile | 1 -
&
On 05/16/2016 05:17 AM, Paul E. McKenney wrote:
> On Mon, May 16, 2016 at 01:09:48PM +0200, Peter Zijlstra wrote:
>> On Fri, May 13, 2016 at 10:58:05AM -0700, Peter Hurley wrote:
>>>> Note that barrier() and READ_ONCE() have overlapping but not identical
>>>> resu
On 05/13/2016 08:07 AM, Peter Zijlstra wrote:
> On Wed, May 11, 2016 at 03:04:20PM -0700, Peter Hurley wrote:
>>> + return !rwsem_is_reader_owned(READ_ONCE(sem->owner));
>>
>> It doesn't make sense to force reload sem->owner here; if sem->owner
>> is
On 05/12/2016 01:15 PM, Waiman Long wrote:
> On 05/11/2016 06:04 PM, Peter Hurley wrote:
[...]
>>
>>> @@ -328,8 +329,6 @@ done:
>>> static noinline
>>> bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct
>
>* When there's no owner, we might have preempted between the
>* owner acquiring the lock and setting the owner field. If
>* we're an RT task that will live-lock because we won't let
> - * the owner complete.
several full barriers which will force reloading from sem->count.
I think the patch is ok if you want it just for consistency anyway,
but please change $subject and changelog.
Regards,
Peter Hurley
> Signed-off-by: Davidlohr Bueso
> ---
> kernel/locking/rwsem-xadd.c | 2 +-
&g
d I've been running them cherry-picked on
my private tty-next testing tree since.
When Greg picks up -rc6 (not sure he was going to do that pre-merge window?),
I'd also like to push the devpts_mutex locking down into fs/devpts/inode.c,
but I'd be willing to do that later, if it's going to get in the way.
Regards,
Peter Hurley
On 05/05/2016 03:08 AM, One Thousand Gnomes wrote:
> On Wed, 4 May 2016 16:07:44 -0700
> Peter Hurley wrote:
>
>> Hi Julio,
>>
>> On 05/04/2016 04:00 PM, Julio Guerra wrote:
>>> Hi,
>>>
>>> When a tty (here a slave pty) is set in noncanonical
es.
>>
>
> This does not appear in my man...
>
> Anyway, how do you explain the random behavior then?
A long standing bug in this read mode allows the asynchronous input
processing thread to race with the read() thread and become confused
about how much data remains.
I fixed this in 4.6; when I run your test on 4.6, it consistently
returns the full user buffer.
Regards,
Peter Hurley
os(3) man page:
* MIN > 0; TIME == 0: read(2) blocks until the lesser of MIN bytes or
the number of bytes requested are avail‐
able, and returns the lesser of these two values.
Regards,
Peter Hurley
> I isolated it in the following example (with VMIN = 5, received = 4, u
access, part 3")
This should be fixed on most recent tty-testing and tty-next branches.
Please re-test on last tty-testing branch including commit
7da4b8b7378790dd1e4af1bb7522863127fa1438
("serial: core: Fix port mutex assert if lockdep disabled")
Regards,
Peter Hurley
> on test
On 04/29/2016 05:03 PM, Doug Anderson wrote:
> Hi,
>
> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley
> wrote:
>
> On 04/29/2016 04:01 PM, Doug Anderson wrote:
> > * serial allows numbering devices by alias.
>
> Which is in fact a total nightmare.
>
cult; eg., by performing minimal scan
serially and more expensive portion of the probe async.
Regards,
Peter Hurley
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Correct pin initialization on (H)SCIF:
> - RTS must be deasserted (it's active low),
> - SCK must be an input, as it may be used as the optional external
> clock input.
>
> Initial pin configuration must always be done:
> - Regardless o
pins.
Reviewed-by: Peter Hurley
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Improve documentation for the (H)SCIF Serial Port Register:
> - Make it clear the RTS and CTS lines are active-low,
> - Document the bits related to the serial port's clock pin.
Reviewed-by: Peter Hurley
On 04/29/2016 05:58 AM, Geert Uytterhoeven wrote:
> Replace open-coded variants of sci_getreg() by function calls, and drop
> intermediate variables where appropriate.
Reviewed-by: Peter Hurley
lines are
> not available. Invalid configurations specifying both GPIO RTS/CTS and
> dedicated RTS/CTS are rejected.
Reviewed-by: Peter Hurley
't look at the CTS
> hardware line state at all.
>
> FWIW, this fixes the transmit path when hardware-assisted flow control
> is enabled, and userspace enables CRTSCTS.
> The receive path is still broken, as RTS is never asserted.
Reviewed-by: Peter Hurley
2. early_serial_setup()
Same as above, but must be before console_init()
3. Don't enumerate PNP0501 ACPI devices
These are going to be probed dynamically
4. Add ACPI/PNP custom device
Fixing the port type isn't supported now but could be
5. Modify the SERIAL_PORT_DFNS
Fixing the port type isn't supported now either but could be
Regards,
Peter Hurley
On 04/28/2016 12:28 PM, Richard Guy Briggs wrote:
> On 16/04/27, Peter Hurley wrote:
>> On 04/27/2016 06:31 PM, Richard Guy Briggs wrote:
>>> On 16/04/22, Peter Hurley wrote:
>>>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>>>> The
On 04/27/2016 06:31 PM, Richard Guy Briggs wrote:
> On 16/04/22, Peter Hurley wrote:
>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>> The tty field was missing from AUDIT_LOGIN events.
>>>
>>> Refactor code to create a new function audit_get_tty(),
On 04/27/2016 10:24 AM, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 12:20:02 Paul Moore wrote:
>>> diff --git a/include/linux/tty.h b/include/linux/tty.h
>>> index 3b09f235db66..17b247c94440 100644
>>> --- a/include/linux/tty.h
>>> +++ b/include/linux/tty.h
>>> @@ -371,6 +371,7 @@ extern void
On 04/26/2016 03:34 PM, Paul Moore wrote:
> On Fri, Apr 22, 2016 at 1:16 PM, Peter Hurley
> wrote:
>> On 04/21/2016 11:14 AM, Richard Guy Briggs wrote:
>>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>>> index b40ed5d..32cdafb 100644
>>>
On 04/26/2016 04:15 AM, Roman Pen wrote:
> The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
> with the following backtrace:
>
> [ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120
> seconds.
> [ 601.347574] Tainted: G O4.4.5-1-storag
On 04/26/2016 10:45 AM, Tejun Heo wrote:
> As long as what's happening is clearly documented, I think either is
> fine. I'm gonna go with Roman's mb patch for -stable fix but think
> it'd be nice to have a separate patch to consolidate the paths which
> clear PENDING and make them use xchg. If yo
Hi Tejun,
On 04/26/2016 08:15 AM, Tejun Heo wrote:
> Hello, Peter.
>
> On Mon, Apr 25, 2016 at 06:22:01PM -0700, Peter Hurley wrote:
>> This is the same bug I wrote about 2 yrs ago (but with the wrong fix).
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1402.2/04697
as several benefits over the naked barrier:
1. set_work_pool_and_clear_pending() has the same requirements as
clear_work_data(); note that both require write barrier before and
full barrier after.
2. xchg() et al imply full barrier before and full barrier after.
3. The naked barriers could be removed, while improving efficiency.
On x86, mov + mfence => xchg
4. Maybe fixes other hidden bugs.
For example, I'm wondering if reordering with set_work_pwq/list_add_tail
would be a problem; ie., what if work is visible on the worklist _before_
data is initialized by set_work_pwq()?
Regards,
Peter Hurley
On 04/22/2016 08:10 AM, Geert Uytterhoeven wrote:
> The OUT1 and OUT2 pins present on some legacy UARTs are basically GPIOs.
> It doesn't make much sense to emulate GPIOs using other GPIOs, hence
> drop support for that.
Thanks Geert.
Reviewed-by: Peter Hurley
o dereference the
sighand_struct (ie tsk->sighand).
2. The existing usage is always tsk==current
3. If the idea is to make this invulnerable to tsk being gone, then
the usage is unsafe anyway.
So ultimately (but not necessarily for this patch) I'd prefer that either
a. audit use existing t
On 04/19/2016 05:24 PM, Peter Hurley wrote:
> On 04/19/2016 04:35 PM, Linus Torvalds wrote:
>> On Tue, Apr 19, 2016 at 3:06 PM, Eric W. Biederman
>> wrote:
>>>
>>> I have work inspired by this rolled into my code. I will post shortly
>>> after a lit
s instance from
teardown when the only open filp is /dev/tty.
What I want to do instead (but not for -stable) is bump the inode
reference at controlling tty association instead (either first
qualifying open or ioctl(TIOCSCTTY)). That way it would always be
the slave inode. This method is non-trivial though because it makes
disassociation more complicated.
Regards,
Peter Hurley
check? __tty_hangup() can set hung_up_tty_fops()
> right after tty_hung_up_p() returns F.
__tty_hangup() will not have had visibility to this filp after
tty_release().
> Don't we need something like below? Otherwise afaics tty_open() can
> actually succeed (and clear TTY_HUPPED)
a, flags, len);
>
> with a rule that you never mix fast and tty buffers, and with an atomic
> swap of port->fast_rx between tty_buffer queueing logic, discard and
> ldisc->fast_rx pointers done when the ldisc is set or changes.
Yes, that's one possible alternative. The drawback is that makes
testing more difficult, but maybe the tradeoff would be worth it.
Regards,
Peter Hurley
> There are very few cases where n_tty is the one that needs the optimized
> path: uucp died a long time ago 8)
>
> Alan
>
On 04/12/2016 11:42 AM, Peter Hurley wrote:
> On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
>> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
>
On 04/13/2016 04:11 AM, Sekhar Nori wrote:
> On Wednesday 13 April 2016 05:30 AM, Peter Hurley wrote:
>
>>>> - generates spurious uart interrupt for every rx dma transaction
>>>> (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT)
>>>&g
4
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1993,8 +1993,9 @@ static void audit_log_set_loginuid(kuid_t koldloginuid,
> kuid_t kloginuid,
> return;
> audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
> audit_log_task_context(ab);
> - audit_log_format(ab, " old-auid=%u auid=%u old-ses=%u ses=%u res=%d",
> - oldloginuid, loginuid, oldsessionid, sessionid, !rc);
tty = get_current_tty();
> + audit_log_format(ab, " old-auid=%u auid=%u tty=%s old-ses=%u ses=%u
> res=%d",
> + oldloginuid, loginuid, audit_get_tty(current),
..., tty_name(tty),
> + oldsessionid, sessionid, !rc);
tty_kref_put(tty);
Regards,
Peter Hurley
> audit_log_end(ab);
> }
>
>
Hi Prasad,
Thanks for the report.
On 04/12/2016 08:22 AM, Sodagudi Prasad wrote:
>
> Hi All,
>
> It looks like there is race between flush_to_ldisc() and release_one_tty().
Not necessarily.
Driver could have destroyed the port prematurely. Or the driver could have
rescheduled the input kwork
On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
>>>> On 04/11/2016 01:18 AM, John Ogness wrote:
>
[ +to Heikki, Andy ]
On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
[ elided parts not relevant to shared 8
On 04/12/2016 10:03 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 10:10 PM, Peter Hurley wrote:
>> On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
>>> On 04/11/2016 07:53 PM, Peter Hurley wrote:
>>>> On 04/11/2016 01:18 AM, John Ogness wrote:
>
On 04/11/2016 11:31 AM, Sebastian Andrzej Siewior wrote:
> On 04/11/2016 07:53 PM, Peter Hurley wrote:
>> On 04/11/2016 01:18 AM, John Ogness wrote:
>>> On 2016-04-05, Peter Hurley wrote:
>>>> On 03/31/2016 01:41 AM, John Ogness wrote:
>>>>> I
On 04/11/2016 01:18 AM, John Ogness wrote:
> On 2016-04-05, Peter Hurley wrote:
>> On 03/31/2016 01:41 AM, John Ogness wrote:
>>> It has been observed that the TX-DMA can stall
>>
>> Does this happen on any other OMAP part besides am335x?
>> I looked back over
On 04/11/2016 02:01 AM, Cyrill Gorcunov wrote:
> On Sun, Apr 10, 2016 at 10:43:28PM -0700, Peter Hurley wrote:
>> Hi Cyrill,
>>
>> On 04/07/2016 05:53 AM, Cyrill Gorcunov wrote:
>>> Currently when we checkpoint PTY connections we ignore data queued inside
>>
uot;; note
that series also has two other patch dependencies which are detailed
in the cover letter.
Regards,
Peter Hurley
> The flags
> will be overwritten with old value after it updates in uart_suspend_port().
> CPU A CPU B
> in uart_s
> Drop a FIFO size limitation to allow autoflow control be enabled on such
> UARTs.
>
> While here, comment out UART_CAP_AFE for PORT_AR7 since it wasn't working and
> it will be not a good idea to use it in conjunction with trigger level of 1
> byte.
Reviewed-by: Peter Hurley
end up
> in plain copying of buffer data.
>
> Strictly speaking, we could try handle it inside CRIU itself, as
> Peter Hurley proposed (switch terminal to raw mode, read data,
> and return original termios back) but in this case we may hit
> the scenario when we read data and fail
On 04/10/2016 01:24 AM, Jiri Slaby wrote:
> On 04/10/2016, 05:36 AM, Peter Hurley wrote:
>> noctty was removed as a parameter by commit 216513411937586
>
> It is actually 11e1d4aa4da.
Right; not sure where that number came from.
>
>> ("tty: Consoli
TTY_NUMBER() has been unused since v2.5.71; removed by
"[PATCH] callout removal: callout is gone".
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 320dc4d..3cdd63b 100644
---
noctty was removed as a parameter by commit 216513411937586
("tty: Consolidate noctty check in tty_open()").
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 3cdd63b..50979be 10
and new, substitute bit definitions
for the former ASYNC_* flags.
Signed-off-by: Peter Hurley
---
include/linux/tty.h| 16 +++-
include/uapi/linux/tty_flags.h | 9 -
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/include/linux/tty.h b/include
ASYNC*_SHARE_IRQ is no longer used; remove.
Signed-off-by: Peter Hurley
---
drivers/tty/mxser.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 7e8c27b..98d2bd1 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2392,7 +2392,6
state transitions are protected by the
tty lock (which mutually excludes parallel open/close/hangup),
and no user tests the active state while holding the port lock.
Signed-off-by: Peter Hurley
---
drivers/isdn/i4l/isdn_tty.c | 20 +---
drivers/tty/amiserial.c | 2
Replace ASYNC_CHECK_CD bit in the tty_port::flags field with
TTY_PORT_CHECK_CD bit in the tty_port::iflags field. Introduce helpers
tty_port_set_check_carrier() and tty_port_check_carrier() to abstract
the atomic bit ops.
Signed-off-by: Peter Hurley
---
drivers/char/pcmcia/synclink_cs.c | 8
Purposefully break out-of-tree driver compiles using kernel
ASYNC_* bits which have been superceded by TTY_PORT* flags and
their respective helper functions.
Signed-off-by: Peter Hurley
---
include/uapi/linux/tty_flags.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux
Replace TTY_THROTTLED bit tests with tty_throttled()"
Regards,
Peter Hurley (8):
tty: Define ASYNC_ replacement bits
tty: Replace ASYNC_CTS_FLOW bit and update atomically
tty: Replace ASYNC_NORMAL_ACTIVE bit and update atomically
tty: Replace ASYNC_CHECK_CD and update atomically
tty: R
unnecessary as the state transitions are already mutually exclusive;
the tty lock prevents concurrent open/close/hangup.
Signed-off-by: Peter Hurley
---
drivers/char/pcmcia/synclink_cs.c | 12 +-
drivers/ipack/devices/ipoctal.c| 5 ++---
drivers/isdn/i4l/isdn_tty.c| 10
Replace ASYNC_SUSPENDED bit in the tty_port::flags field with
TTY_PORT_SUSPENDED bit in the tty_port::iflags field. Introduce helpers
tty_port_set_suspended() and tty_port_suspended() to abstract
atomic bit ops.
Signed-off-by: Peter Hurley
---
drivers/s390/char/con3215.c | 12
Replace ASYNC_CTS_FLOW bit in the tty_port::flags field with
TTY_PORT_CTS_FLOW bit in the tty_port::iflags field. Add
tty_port_set_cts_flow() helper to abstract the atomic bit ops.
Signed-off-by: Peter Hurley
---
drivers/char/pcmcia/synclink_cs.c | 5 +
drivers/tty/amiserial.c
Abstract TTY_THROTTLED bit tests with tty_throttled().
Signed-off-by: Peter Hurley
---
drivers/char/pcmcia/synclink_cs.c | 2 +-
drivers/mmc/card/sdio_uart.c | 2 +-
drivers/net/usb/hso.c | 2 +-
drivers/staging/fwserial/fwserial.c| 2 +-
drivers/staging
Abstract TTY_IO_ERROR status test treewide with tty_io_error().
NB: tty->flags uses atomic bit ops; replace non-atomic bit test
with test_bit().
Signed-off-by: Peter Hurley
---
v3: redo of an earlier patch titled "tty: Use test_bit() with tty->flags"
v2: rebase
arch/ia64/hp
On 04/08/2016 01:07 AM, Andy Shevchenko wrote:
> On Fri, Apr 8, 2016 at 2:54 AM, Peter Hurley wrote:
>> On 04/07/2016 01:37 PM, Andy Shevchenko wrote:
>>> If we get an exeption interrupt. i.e. UART_IIR_RLSI, stop any ongoing RX DMA
>>> transfer otherwise it mi
On 04/08/2016 01:17 AM, Andy Shevchenko wrote:
> On Fri, Apr 8, 2016 at 4:42 AM, Peter Hurley wrote:
>> On 04/07/2016 01:37 PM, Andy Shevchenko wrote:
>>> Intes SoCs, such as Braswell, have DesignWare UART. Split out to separate
>>> module which also will be
On 04/07/2016 01:37 PM, Andy Shevchenko wrote:
> Intes SoCs, such as Braswell, have DesignWare UART. Split out to separate
> module which also will be used for Intel Quark later.
What's the rationale?
And this really isn't a split; this patch introduces a number of significant
changes from the pc
On 04/07/2016 01:37 PM, Andy Shevchenko wrote:
> Some UARTs, e.g. one is used in Intel Quark, have a different address base for
> DMA operations. Introduce an additional field in struct uart_8250_dma to cover
> those cases.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/tty/serial/8250/8250.
On 04/07/2016 01:37 PM, Andy Shevchenko wrote:
> Convert dmaengine_terminate_all() calls to synchronous and asynchronous
> versions where appropriate.
Reviewed-by: Peter Hurley
On 04/07/2016 01:37 PM, Andy Shevchenko wrote:
> If we get an exeption interrupt. i.e. UART_IIR_RLSI, stop any ongoing RX DMA
> transfer otherwise it might generates more spurious interrupts and make port
> unavailable anymore.
Then how to know which rx byte the error is for if dma continues anywa
st and rely on UART_CAP_AFE to enable
AFE. Please remove comment from "In the case where ..."
Also, I think the PORT_A7 port type should have UART_CAP_AFE commented out,
especially since/if the trigger level is 1 byte.
Regards,
Peter Hurley
> up->mcr &= ~UART_MCR_AFE;
> if (termios->c_cflag & CRTSCTS)
> up->mcr |= UART_MCR_AFE;
>
a fact ia64 servers didn't,
so the assertion that SPCR + 16550 + MMIO automatically means 32-bit data width
seems unlikely.
In fact, I suspect the opposite is true; that before these arm64 designs,
SPCR + 16550 + MMIO automatically meant 8-bit data width, which is why it's
unspecified in
tition is still /dev/mmcblk0p2.
Note though that this particular bootscript can load add'l bootscripts
from the boot partition; in this particular case, the eMMC root
partition is set as a fixed UUID in the bootscript from the
boot partition.
Regards,
Peter Hurley
termios(), then resume dma which would
keep everything nice and linear.
Or even just drop DMA for the am335x and only use the normal 8250_dma
support for newer OMAP designs.
Regards,
Peter Hurley
> Commit message and forward port by John Ogness.
>
> Tested-by: John Ogness
> Signed-off-b
ty, n_tty: Simplify input processing on final close
>
> 3) 1a48632ffed61352a7810ce089dc5a8bcd505a60
> pty: Fix input race when closing
Reviewed-by: Peter Hurley
until ACPI/DT decision is made.
>
> Parse the ACPI SPCR table, setup earlycon if required,
> enable specified console.
>
> Thanks to Peter Hurley for explaining how this should work.
>
> [1]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
able handler.
Reviewed-by: Peter Hurley
ision is made.
>
> Rename the exported function to avoid clashing with the function from
> arch/microblaze/kernel/prom.c
Reviewed-by: Peter Hurley
On 04/04/2016 12:49 PM, Linus Torvalds wrote:
> On Mon, Apr 4, 2016 at 12:29 PM, Peter Hurley
> wrote:
>>
>> Yeah, a straight revert of 520bd7a8b415 resumes normal service:
>
> Ok, so we have that as an option.
>
>> Should I send a proper revert?
>
> L
Hi Dmitry,
On 04/04/2016 01:56 AM, Dmitry Vyukov wrote:
> Hello,
>
> The following program causes a memory leak:
Thanks for the report. This is the same problem fixed in 4.5
There was a merge snafu; Greg has the patch in his queue that
fixes this for 4.6
Regards,
Peter Hurley
>
On 04/04/2016 11:59 AM, Linus Torvalds wrote:
> On Mon, Apr 4, 2016 at 4:29 AM, Ulf Hansson wrote:
>>
>> The commit that's likely to cause the regression is:
>> 520bd7a8b415 ("mmc: core: Optimize boot time by detecting cards
>> simultaneously").
>
> Peter, mind testing if you can revert that and
1 - 100 of 2441 matches
Mail list logo
