* Re: [tty:tty-next 10/16] fs/compat_ioctl.c:869:1: error: 'TIOCSRS485' undeclared here (not in a function)
From: Jaeden Amero @ 2012-09-24 15:39 UTC (permalink / raw)
To: fengguang.wu
Cc: linux-next, sfr, gregkh, alan, kernel-janitors, linux-serial,
Jaeden Amero
In-Reply-To: <20120922005021.GM5959@localhost>
On Sat, 22 Sep 2012 08:50:21 +0800, Fengguang Wu wrote:
> FYI, kernel build failed on
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> tty-next
> head: ac57e7f38ea6fe7358cd0b7a2f2d21aef5ab70cd
> commit: 84c3b84860440a9e3a3666c14112f41311b8f623 [10/16]
> compat_ioctl: Add RS-485 IOCTLs to the list
> config: mips-fuloong2e_defconfig
>
> All related error/warning messages:
>
> fs/compat_ioctl.c:869:1: error: 'TIOCSRS485' undeclared here (not in
> a function)
> fs/compat_ioctl.c:870:1: error: 'TIOCGRS485' undeclared here (not in
> a function)
I could fix this by defining these IOCTLs for all architectures that
don't have them yet, but I'm unsure of what values to give them or why
MIPS isn't using 'include/asm-generic/ioctls.h'.
Perhaps it is better to leave adding those IOCTLs up to those who add
the first RS-485 capable driver for that platform and to wrap the use
of these defines in compat_ioctl.c with #ifdefs, as I've done in this
patch. What do you think is best?
Cheers,
Jaeden Amero
Jaeden Amero (1):
compat_ioctl: Avoid using undefined RS-485 IOCTLs
fs/compat_ioctl.c | 4 ++++
1 file changed, 4 insertions(+)
--
1.7.12
^ permalink raw reply
* Re: [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate
From: Alan Cox @ 2012-09-24 13:21 UTC (permalink / raw)
To: Christophe Leroy
Cc: Vitaly Bordug, Marcelo Tosatti, linux-kernel, linux-serial,
linuxppc-dev
In-Reply-To: <201209240639.q8O6di6f029596@localhost.localdomain>
On Mon, 24 Sep 2012 08:39:44 +0200
Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> MAXIDL is the timeout after which a receive buffer is closed when not
> full if no more characters are received. We calculate it from the
> baudrate so that the duration is always the same at standard rates:
> about 4ms. At 9600 bauds it gives a timeout of 4 characters, which is
> the timeout on the 8250 UART.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Looks good tome - series Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 0/2] winbond-cir: Fix initialization
From: Alan Cox @ 2012-09-24 13:18 UTC (permalink / raw)
To: Sean Young
Cc: Greg Kroah-Hartman, linux-serial, David Härdeman,
Mauro Carvalho Chehab
In-Reply-To: <20120924095301.GA9201@pequod.mess.org>
> >
> > [1] http://www.spinics.net/lists/linux-serial/msg06757.html
> >
> > v3:
> > - Removed IrDA entries
> > - Renamed PORT_IR to PORT_8250_CIR
> > - commit message rewording
>
> It's been more than two weeks. Do you have any review comments? It
> would be great to have this in 3.7.
Agreed - I'd been trying to see if there was a nicer way to split the
PnP and non PnP stuff cleanly but no inspiration has appeared
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* [PATCH] RFC: sched: Prevent wakeup to enter critical section needlessly
From: Ivo Sieben @ 2012-09-24 13:06 UTC (permalink / raw)
To: linux-kernel, Ingo Molnar, Peter Zijlstra, linux-serial, RT,
Alan Cox, Greg KH
Cc: Ivo Sieben
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
---
Request for comments:
- Does this make any sense?
- I assume that I can safely use the list_empty_careful() function here, but is
that correct?
Background to this patch:
Testing on a PREEMPT_RT system with TTY serial communication. Each time the TTY
line discipline is dereferenced the Idle handling wait queue is woken up (see
function put_ldisc in /drivers/tty/tty_ldisc.c)
However line discipline idle handling is not used very often so the wait queue
is empty most of the time. But still the wake_up() function enters the critical
section guarded by spin locks. This causes additional scheduling overhead when
a lower priority thread has control of that same lock.
kernel/sched/core.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 649c9f8..6436eb8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3631,9 +3631,19 @@ void __wake_up(wait_queue_head_t *q, unsigned int mode,
{
unsigned long flags;
- spin_lock_irqsave(&q->lock, flags);
- __wake_up_common(q, mode, nr_exclusive, 0, key);
- spin_unlock_irqrestore(&q->lock, flags);
+ /*
+ * We can check for list emptiness outside the lock by using the
+ * "careful" check that verifies both the next and prev pointers, so
+ * that there cannot be any half-pending updates in progress.
+ *
+ * This prevents the wake up to enter the critical section needlessly
+ * when the task list is empty.
+ */
+ if (!list_empty_careful(&q->task_list)) {
+ spin_lock_irqsave(&q->lock, flags);
+ __wake_up_common(q, mode, nr_exclusive, 0, key);
+ spin_unlock_irqrestore(&q->lock, flags);
+ }
}
EXPORT_SYMBOL(__wake_up);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v8 0/11] KGDB/KDB FIQ (NMI) debugger
From: Jason Wessel @ 2012-09-24 10:46 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Andrew Morton, Russell King, Greg Kroah-Hartman, Alan Cox,
Arve Hjønnevåg, Colin Cross, Brian Swetland,
John Stultz, Thomas Gleixner, linux-kernel, linux-arm-kernel,
linaro-kernel, patches, kernel-team, kgdb-bugreport, linux-serial
In-Reply-To: <505B1CC7.9000005@windriver.com>
On 09/20/2012 08:40 AM, Jason Wessel wrote:
> On 09/19/2012 06:40 PM, Anton Vorontsov wrote:
>> Hi all,
>>
>> In v8, addressed Jason's comments:
>>
>> - Changed kgdb_enable_nmi() weak function to kgdb_arch callbck;
>> - We no longer register disable_nmi command if arch does not register
>> KGDB NMI handling (i.e. not filling kgdb_arch.enable_nmi callback);
>> - The same is for ttyNMI: if architecure does not provide us with
>> enable_nmi call, we don't need the tty device. Of course, there is no
>> way to tell wether a specific serial device can be used for NMI
>> debugging, as it is not serial-device specific, but specific to
>> whether IRQ can be rerouted to an NMI (for most our cases, pretty
>> much every IRQ can be rerouted, e.g. a hot-pluggable serial device on
>> a PCI bus).
>> - Rebased on the latest and greatest tty-next, just in case.
>
> I have the kgdb regression builder running right now (it will be done in about 1 hour), and so far it picked up one new warning.
>
> drivers/tty/serial/kgdb_nmi.c: In function 'kgdb_nmi_poll_one_knock':
> drivers/tty/serial/kgdb_nmi.c:161: warning: field width should have type 'int', but argument 4 has type 'size_t'
>
Hi Anton,
You can add my ack to the series, for what you have in: "git://git.infradead.org/users/cbou/linux-nmi-kdb.git master", and then drop a pull request to Greg for the next merge window. Thank you for your hard work through all the revisions of this code and this slick new feature.
Acked-by: Jason Wessel <jason.wessel@windriver.com>
Cheers,
Jason.
^ permalink raw reply
* Re: [PATCH v3 0/2] winbond-cir: Fix initialization
From: Sean Young @ 2012-09-24 9:53 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial
Cc: David Härdeman, Mauro Carvalho Chehab
In-Reply-To: <cover.1347029782.git.sean@mess.org>
Hi Alan,
On Fri, Sep 07, 2012 at 07:06:22PM +0100, Sean Young wrote:
> The serial driver will detect the winbond cir device as a serial port,
> since it looks exactly like a serial port unless you know what it is
> from the PNP ID.
>
> v2:
> Alan Cox pointed out[1] that the pnp serial probe should be done before
> the legacy probe and we should keep track of any IR ports during the
> pnp scan. This is an implementation of that idea.
>
> [1] http://www.spinics.net/lists/linux-serial/msg06757.html
>
> v3:
> - Removed IrDA entries
> - Renamed PORT_IR to PORT_8250_CIR
> - commit message rewording
It's been more than two weeks. Do you have any review comments? It
would be great to have this in 3.7.
Thanks
Sean
> Diffed against tty-next.
>
> Sean Young (2):
> 8250_pnp: do pnp probe before legacy probe
> 8250: blacklist Winbond CIR port
>
> drivers/tty/serial/8250/8250.c | 47 ++++++++++++++++++++++++-----------
> drivers/tty/serial/8250/8250.h | 9 +++++++
> drivers/tty/serial/8250/8250_pnp.c | 31 +++++++++++++----------
> drivers/tty/serial/8250/Kconfig | 16 ++++++------
> drivers/tty/serial/8250/Makefile | 5 ++-
> include/linux/serial_core.h | 3 +-
> 6 files changed, 72 insertions(+), 39 deletions(-)
>
> --
> 1.7.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tty: prevent unnecessary work queue lock checking on flip buffer copy
From: Ivo Sieben @ 2012-09-24 9:33 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg KH, linux-serial, RT
In-Reply-To: <20120920173305.15ea580a@bob.linux.org.uk>
Hi,
2012/9/20 Alan Cox <alan@linux.intel.com>:
>
> This seems reasonable, but given its also relevant for upstream it
> would be nice to get it without the ifdef in upstream.
>
> The corner case is when the tty->low_latency flag is flipped but the
> drivers should handle that gracefully and if not we should fix them so
> you can get your 100uS.
>
> Alan
Actually this patch is related to my previous patch "tty: cleanup
duplicate functions in tty_buffer". Some drivers call the
tty_schedule_flip() function instead of tty_flip_buffer_push(). In
that case the work queue is always used, regardless the
tty->low_latency flag. That's why tried to get rid of the
tty_schedule_flip() function.
But from the first review remarks on the "tty: cleanup duplicate
functions in tty_buffer" patch, that patch seems to be invalid. So in
that case this patch is invalid also.
Regards,
Ivo Sieben
^ permalink raw reply
* [PATCH] tty: Use raw spin lock to protect RX flip buffer
From: Ivo Sieben @ 2012-09-24 9:24 UTC (permalink / raw)
To: Thomas Gleixner, Steven Rostedt, Alan Cox, Greg KH, linux-serial,
RT
Cc: Ivo Sieben
The "normal" spin lock that guards the RX flip buffer is replaced by a raw
spin lock.
On a PREEMP_RT system this prevents unwanted scheduling overhead when data is
read at the same time as data is being received: while RX IRQ threaded handling
is busy a TTY read call is performed from a RT priority > threaded IRQ priority.
The read call tries to take the flip buffer spin lock (held by the threaded IRQ)
which blocks and causes a context switch to/from the threaded IRQ handler until
the spin lock is unlocked.
On a 240 MHz AT91SAM9261 processor setup this fixes about 100us of scheduling
overhead on the TTY read call.
Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
---
Repost
@Thomas Gleixner & Steven Rostedt:
Alan Cox has responded to this patch: "I've no real opinion on the spin/raw_spin
choices as it's basically an RT question not a tty one so if the rt folks are
happy with it so am I." Do you agree?
drivers/tty/tty_buffer.c | 44 ++++++++++++++++++++++----------------------
include/linux/kbd_kern.h | 4 ++--
include/linux/tty.h | 2 +-
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index b8e90b8..fd4c242 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -135,20 +135,20 @@ static void __tty_buffer_flush(struct tty_struct *tty)
void tty_buffer_flush(struct tty_struct *tty)
{
unsigned long flags;
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
/* If the data is being pushed to the tty layer then we can't
process it here. Instead set a flag and the flush_to_ldisc
path will process the flush request before it exits */
if (test_bit(TTY_FLUSHING, &tty->flags)) {
set_bit(TTY_FLUSHPENDING, &tty->flags);
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
wait_event(tty->read_wait,
test_bit(TTY_FLUSHPENDING, &tty->flags) == 0);
return;
} else
__tty_buffer_flush(tty);
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
}
/**
@@ -238,9 +238,9 @@ int tty_buffer_request_room(struct tty_struct *tty, size_t size)
unsigned long flags;
int length;
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
length = __tty_buffer_request_room(tty, size);
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
return length;
}
EXPORT_SYMBOL_GPL(tty_buffer_request_room);
@@ -268,18 +268,18 @@ int tty_insert_flip_string_fixed_flag(struct tty_struct *tty,
unsigned long flags;
struct tty_buffer *tb;
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
space = __tty_buffer_request_room(tty, goal);
tb = tty->buf.tail;
/* If there is no space then tb may be NULL */
if (unlikely(space == 0)) {
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
break;
}
memcpy(tb->char_buf_ptr + tb->used, chars, space);
memset(tb->flag_buf_ptr + tb->used, flag, space);
tb->used += space;
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
copied += space;
chars += space;
/* There is a small chance that we need to split the data over
@@ -313,18 +313,18 @@ int tty_insert_flip_string_flags(struct tty_struct *tty,
unsigned long __flags;
struct tty_buffer *tb;
- spin_lock_irqsave(&tty->buf.lock, __flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, __flags);
space = __tty_buffer_request_room(tty, goal);
tb = tty->buf.tail;
/* If there is no space then tb may be NULL */
if (unlikely(space == 0)) {
- spin_unlock_irqrestore(&tty->buf.lock, __flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, __flags);
break;
}
memcpy(tb->char_buf_ptr + tb->used, chars, space);
memcpy(tb->flag_buf_ptr + tb->used, flags, space);
tb->used += space;
- spin_unlock_irqrestore(&tty->buf.lock, __flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, __flags);
copied += space;
chars += space;
flags += space;
@@ -357,7 +357,7 @@ int tty_prepare_flip_string(struct tty_struct *tty, unsigned char **chars,
unsigned long flags;
struct tty_buffer *tb;
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
space = __tty_buffer_request_room(tty, size);
tb = tty->buf.tail;
@@ -366,7 +366,7 @@ int tty_prepare_flip_string(struct tty_struct *tty, unsigned char **chars,
memset(tb->flag_buf_ptr + tb->used, TTY_NORMAL, space);
tb->used += space;
}
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
return space;
}
EXPORT_SYMBOL_GPL(tty_prepare_flip_string);
@@ -394,7 +394,7 @@ int tty_prepare_flip_string_flags(struct tty_struct *tty,
unsigned long __flags;
struct tty_buffer *tb;
- spin_lock_irqsave(&tty->buf.lock, __flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, __flags);
space = __tty_buffer_request_room(tty, size);
tb = tty->buf.tail;
@@ -403,7 +403,7 @@ int tty_prepare_flip_string_flags(struct tty_struct *tty,
*flags = tb->flag_buf_ptr + tb->used;
tb->used += space;
}
- spin_unlock_irqrestore(&tty->buf.lock, __flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, __flags);
return space;
}
EXPORT_SYMBOL_GPL(tty_prepare_flip_string_flags);
@@ -433,7 +433,7 @@ static void flush_to_ldisc(struct work_struct *work)
if (disc == NULL) /* !TTY_LDISC */
return;
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
if (!test_and_set_bit(TTY_FLUSHING, &tty->flags)) {
struct tty_buffer *head;
@@ -462,10 +462,10 @@ static void flush_to_ldisc(struct work_struct *work)
char_buf = head->char_buf_ptr + head->read;
flag_buf = head->flag_buf_ptr + head->read;
head->read += count;
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
disc->ops->receive_buf(tty, char_buf,
flag_buf, count);
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
}
clear_bit(TTY_FLUSHING, &tty->flags);
}
@@ -477,7 +477,7 @@ static void flush_to_ldisc(struct work_struct *work)
clear_bit(TTY_FLUSHPENDING, &tty->flags);
wake_up(&tty->read_wait);
}
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
tty_ldisc_deref(disc);
}
@@ -519,10 +519,10 @@ void tty_flush_to_ldisc(struct tty_struct *tty)
void tty_flip_buffer_push(struct tty_struct *tty)
{
unsigned long flags;
- spin_lock_irqsave(&tty->buf.lock, flags);
+ raw_spin_lock_irqsave(&tty->buf.lock, flags);
if (tty->buf.tail != NULL)
tty->buf.tail->commit = tty->buf.tail->used;
- spin_unlock_irqrestore(&tty->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&tty->buf.lock, flags);
if (tty->low_latency)
flush_to_ldisc(&tty->buf.work);
@@ -543,7 +543,7 @@ EXPORT_SYMBOL(tty_flip_buffer_push);
void tty_buffer_init(struct tty_struct *tty)
{
- spin_lock_init(&tty->buf.lock);
+ raw_spin_lock_init(&tty->buf.lock);
tty->buf.head = NULL;
tty->buf.tail = NULL;
tty->buf.free = NULL;
diff --git a/include/linux/kbd_kern.h b/include/linux/kbd_kern.h
index daf4a3a..507af24 100644
--- a/include/linux/kbd_kern.h
+++ b/include/linux/kbd_kern.h
@@ -150,10 +150,10 @@ extern unsigned int keymap_count;
static inline void con_schedule_flip(struct tty_struct *t)
{
unsigned long flags;
- spin_lock_irqsave(&t->buf.lock, flags);
+ raw_spin_lock_irqsave(&t->buf.lock, flags);
if (t->buf.tail != NULL)
t->buf.tail->commit = t->buf.tail->used;
- spin_unlock_irqrestore(&t->buf.lock, flags);
+ raw_spin_unlock_irqrestore(&t->buf.lock, flags);
schedule_work(&t->buf.work);
}
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 9f47ab5..e728ecc 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -86,7 +86,7 @@ struct tty_buffer {
struct tty_bufhead {
struct work_struct work;
- spinlock_t lock;
+ raw_spinlock_t lock;
struct tty_buffer *head; /* Queue head */
struct tty_buffer *tail; /* Active buffer */
struct tty_buffer *free; /* Free queue head */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] tty: cleanup duplicate functions in tty_buffer
From: Alan Cox @ 2012-09-24 9:25 UTC (permalink / raw)
To: Ivo Sieben
Cc: Alan Cox, Greg KH, linux-serial, RT, Jiri Slaby, Heiko Carstens
In-Reply-To: <CAMSQXEHkjWubwNXiCd_bBnUdzQ2M+sa8HPs2KCzwcOOp2dSsBw@mail.gmail.com>
> I agree that when the tty->low_latency flag is set on these machines,
> the drivers that were modified by my patch will behave differently:
> they will call the flush_to_ldisc() function directly instead of using
> the work queue. So that indeed introduces different functionality.
flush_to_ldisc calls into the tty core code which sleeps. The rule is
that you may not call flush_to_ldisc except from a workqueue context.
If you break that rule then various bad things will occur (eg rx ->
flush_to_ldisc -> n_tty -> flow control -> tx -> deadlock) in a lot of
drivers.
> But what I don't understand is how this would cause the machine to
> crash? Even when the flush_to_ldisc() function is called from hard IRQ
> context this would cause no problems: the flush_to_ldisc() function
> uses IRQ save spin locks instead of mutexes to protect it's critical
> section. Right?
>
> Furthermore the majority of TTY drivers currently already use the
> tty_flip_buffer_push() function.
Several of them are ones that shouldn't.
Alan
^ permalink raw reply
* Re: [PATCH] tty: cleanup duplicate functions in tty_buffer
From: Jiri Slaby @ 2012-09-24 8:15 UTC (permalink / raw)
To: Ivo Sieben; +Cc: Alan Cox, Greg KH, linux-serial, RT, Heiko Carstens
In-Reply-To: <CAMSQXEHkjWubwNXiCd_bBnUdzQ2M+sa8HPs2KCzwcOOp2dSsBw@mail.gmail.com>
On 09/24/2012 10:02 AM, Ivo Sieben wrote:
> Hi,
>
> 2012/9/20 Alan Cox <alan@linux.intel.com>:
>>
>> So now when the user sets tty->low_latency on these devices the machine
>> crashes ?
>>
>> This is the wrong direction - in fact we have a pile we need to move
>> the other way !
>>
>> If they resolve to the same thing in hard RT patches fine, that's a
>> different question.
>
> Sorry, Allan you are probably right, but I don't get it...
>
> I agree that when the tty->low_latency flag is set on these machines,
> the drivers that were modified by my patch will behave differently:
> they will call the flush_to_ldisc() function directly instead of using
> the work queue. So that indeed introduces different functionality.
>
> But what I don't understand is how this would cause the machine to
> crash? Even when the flush_to_ldisc() function is called from hard IRQ
> context this would cause no problems: the flush_to_ldisc() function
> uses IRQ save spin locks instead of mutexes to protect it's critical
> section. Right?
Yes, but there are deadlocks caused when low_latency is set. Simply
because flush_to_ldisc calls tty->ops->flush_chars from ldisc's
receive_buf. And some drivers take a lock there. But they already hold
the lock from the site where they call tty_schedule_flip from.
> Furthermore the majority of TTY drivers currently already use the
> tty_flip_buffer_push() function.
Yes, but not all call tty_flip_buffer_push correctly. If you set
low_latency for them, they explode.
regards,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] tty: cleanup duplicate functions in tty_buffer
From: Ivo Sieben @ 2012-09-24 8:02 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg KH, linux-serial, RT, Jiri Slaby, Heiko Carstens
In-Reply-To: <20120920171717.04ee9098@bob.linux.org.uk>
Hi,
2012/9/20 Alan Cox <alan@linux.intel.com>:
>
> So now when the user sets tty->low_latency on these devices the machine
> crashes ?
>
> This is the wrong direction - in fact we have a pile we need to move
> the other way !
>
> If they resolve to the same thing in hard RT patches fine, that's a
> different question.
Sorry, Allan you are probably right, but I don't get it...
I agree that when the tty->low_latency flag is set on these machines,
the drivers that were modified by my patch will behave differently:
they will call the flush_to_ldisc() function directly instead of using
the work queue. So that indeed introduces different functionality.
But what I don't understand is how this would cause the machine to
crash? Even when the flush_to_ldisc() function is called from hard IRQ
context this would cause no problems: the flush_to_ldisc() function
uses IRQ save spin locks instead of mutexes to protect it's critical
section. Right?
Furthermore the majority of TTY drivers currently already use the
tty_flip_buffer_push() function.
Regards,
Ivo Sieben
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate
From: Christophe Leroy @ 2012-09-24 6:39 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linux-kernel, linux-serial, linuxppc-dev
MAXIDL is the timeout after which a receive buffer is closed when not full if
no more characters are received. We calculate it from the baudrate so that the
duration is always the same at standard rates: about 4ms. At 9600 bauds it gives
a timeout of 4 characters, which is the timeout on the 8250 UART.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -501,6 +501,7 @@
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
smc_t __iomem *smcp = pinfo->smcp;
scc_t __iomem *sccp = pinfo->sccp;
+ int maxidl;
pr_debug("CPM uart[%d]:set_termios\n", port->line);
@@ -511,6 +512,17 @@
else
pinfo->rx_fifosize = RX_BUF_SIZE;
+ /* MAXIDL is the timeout after which a receive buffer is closed
+ * when not full if no more characters are received.
+ * We calculate it from the baudrate so that the duration is
+ * always the same at standard rates: about 4ms.
+ */
+ maxidl = baud / 2400;
+ if (maxidl < 1)
+ maxidl = 1;
+ if (maxidl > 0x10)
+ maxidl = 0x10;
+
/* Character length programmed into the mode register is the
* sum of: 1 start bit, number of data bits, 0 or 1 parity bit,
* 1 or 2 stop bits, minus 1.
@@ -611,6 +623,7 @@
* SMC/SCC receiver is disabled.
*/
out_be16(&pinfo->smcup->smc_mrblr, pinfo->rx_fifosize);
+ out_be16(&pinfo->smcup->smc_maxidl, maxidl);
/* Set the mode register. We want to keep a copy of the
* enables, because we want to put them back if they were
@@ -623,6 +636,7 @@
SMCMR_SM_UART | prev_mode);
} else {
out_be16(&pinfo->sccup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
+ out_be16(&pinfo->sccup->scc_maxidl, maxidl);
out_be16(&sccp->scc_psmr, (sbits << 12) | scval);
}
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART maxidl should not depend on fifo size
From: Christophe Leroy @ 2012-09-24 6:20 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linux-kernel, linux-serial, linuxppc-dev
maxidl register was set to fifo size. There is no reason to set this
register to same value as fifo size. Setting it now to 0x10 by default
as in the UCC UART driver.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -799,7 +799,7 @@
cpm_set_scc_fcr(sup);
out_be16(&sup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
- out_be16(&sup->scc_maxidl, pinfo->rx_fifosize);
+ out_be16(&sup->scc_maxidl, 0x10);
out_be16(&sup->scc_brkcr, 1);
out_be16(&sup->scc_parec, 0);
out_be16(&sup->scc_frmec, 0);
@@ -873,7 +873,7 @@
/* Using idle character time requires some additional tuning. */
out_be16(&up->smc_mrblr, pinfo->rx_fifosize);
- out_be16(&up->smc_maxidl, pinfo->rx_fifosize);
+ out_be16(&up->smc_maxidl, 0x10);
out_be16(&up->smc_brklen, 0);
out_be16(&up->smc_brkec, 0);
out_be16(&up->smc_brkcr, 1);
^ permalink raw reply
* [PATCH] Powerpc 8xx CPM_UART too many interrupts
From: Christophe Leroy @ 2012-09-24 6:19 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linux-kernel, linux-serial, linuxppc-dev
Setting the fifo to only 1 byte generates one interrupt every 1ms at 9600 bauds.
This is too much. This patch reduces the threshold to speeds below 2400 bauds
like in the 8250 UART driver.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -71,7 +71,7 @@
/**************************************************************/
-#define HW_BUF_SPD_THRESHOLD 9600
+#define HW_BUF_SPD_THRESHOLD 2400
/*
* Check, if transmit buffers are processed
@@ -505,7 +505,7 @@
pr_debug("CPM uart[%d]:set_termios\n", port->line);
baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
- if (baud <= HW_BUF_SPD_THRESHOLD ||
+ if (baud < HW_BUF_SPD_THRESHOLD ||
(pinfo->port.state && pinfo->port.state->port.tty->low_latency))
pinfo->rx_fifosize = 1;
else
^ permalink raw reply
* [PATCH v2] Powerpc 8xx CPM_UART desynchronisation
From: Christophe Leroy @ 2012-09-24 6:17 UTC (permalink / raw)
To: Alan Cox, Vitaly Bordug, Marcelo Tosatti
Cc: linux-kernel, linux-serial, linuxppc-dev
This patch fixes a desynchronisation problem with CPM UART driver on
Powerpc MPC8xx. The problem happens if data is received before the device
is open by the user application.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
--- linux-3.5-vanilla/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-07-21 22:58:29.000000000 +0200
+++ linux-3.5/drivers/tty/serial/cpm_uart/cpm_uart_core.c 2012-08-09 17:38:37.000000000 +0200
@@ -417,6 +417,7 @@
clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR);
clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX);
}
+ cpm_uart_initbd(pinfo);
cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
}
/* Install interrupt handler. */
^ permalink raw reply
* Re: [RFC 2/3] ARM: move udc_pxa2xx.h to linux/platform_data
From: Krzysztof Halasa @ 2012-09-22 11:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Eric Miao, Greg Kroah-Hartman, linux-usb, Haojian Zhuang,
Felipe Balbi, linux-serial, Imre Kaloz, linux-arm-kernel
In-Reply-To: <20120921094855.GC15609@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> > --- a/arch/arm/mach-ixp4xx/include/mach/udc.h
>> > +++ b/arch/arm/mach-ixp4xx/include/mach/udc.h
>> > @@ -2,7 +2,7 @@
>> > * arch/arm/mach-ixp4xx/include/mach/udc.h
>> > *
>> > */
>> > -#include <asm/mach/udc_pxa2xx.h>
>> > +#include <linux/platform_data_pxa2xx_udc.h>
>>
>> Guess a typo here, "/" instead of "_"? Otherwise looks good to me
>
> Yea, fixed.
The ixp4xx part looks good to me too.
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
--
Krzysztof Hałasa
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] serial: samsung: Add poll_get_char & poll_put_char
From: Doug Anderson @ 2012-09-22 6:22 UTC (permalink / raw)
To: linux-samsung-soc
Cc: linux-serial, linux-kernel, Julien Pichon, Alan Cox,
Greg Kroah-Hartman, kgene.kim, GNUtoo, heiko, ben-linux,
Doug Anderson
In-Reply-To: <20120212182201.GA17975@debian>
From: Julien Pichon <pichon.jln@gmail.com>
The following patch allows users to use KGDB over serial console on
board based on Samsung SOC. It has been tested on a board using
exynos5.
Signed-off-by: Julien Pichon <pichon.jln@gmail.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
(dianders changed poll to return NO_POLL_CHAR, which appears to
fix 'help' in kgdb; also updated commit message)
---
This is pulled from an email on <linux-samsung-soc@vger.kernel.org>
from Feb 18, 2012. It's never landed anywhere. I've made a small modification
that make it so that kgdb's "help" doesn't crash.
See: http://comments.gmane.org/gmane.linux.kernel.samsung-soc/9477
drivers/tty/serial/samsung.c | 47 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 8eef114..7f04717 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -876,11 +876,24 @@ s3c24xx_serial_verify_port(struct uart_port *port, struct serial_struct *ser)
static struct console s3c24xx_serial_console;
+static int __init s3c24xx_serial_console_init(void)
+{
+ register_console(&s3c24xx_serial_console);
+ return 0;
+}
+console_initcall(s3c24xx_serial_console_init);
+
#define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console
#else
#define S3C24XX_SERIAL_CONSOLE NULL
#endif
+#ifdef CONFIG_CONSOLE_POLL
+static int s3c24xx_serial_get_poll_char(struct uart_port *port);
+static void s3c24xx_serial_put_poll_char(struct uart_port *port,
+ unsigned char c);
+#endif
+
static struct uart_ops s3c24xx_serial_ops = {
.pm = s3c24xx_serial_pm,
.tx_empty = s3c24xx_serial_tx_empty,
@@ -899,6 +912,10 @@ static struct uart_ops s3c24xx_serial_ops = {
.request_port = s3c24xx_serial_request_port,
.config_port = s3c24xx_serial_config_port,
.verify_port = s3c24xx_serial_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = s3c24xx_serial_get_poll_char,
+ .poll_put_char = s3c24xx_serial_put_poll_char,
+#endif
};
static struct uart_driver s3c24xx_uart_drv = {
@@ -1316,6 +1333,36 @@ s3c24xx_serial_console_txrdy(struct uart_port *port, unsigned int ufcon)
return (utrstat & S3C2410_UTRSTAT_TXE) ? 1 : 0;
}
+#ifdef CONFIG_CONSOLE_POLL
+/*
+ * Console polling routines for writing and reading from the uart while
+ * in an interrupt or debug context.
+ */
+
+static int s3c24xx_serial_get_poll_char(struct uart_port *port)
+{
+ struct s3c24xx_uart_port *ourport = to_ourport(port);
+ unsigned int ufstat;
+
+ ufstat = rd_regl(port, S3C2410_UFSTAT);
+ if (s3c24xx_serial_rx_fifocnt(ourport, ufstat) == 0)
+ return NO_POLL_CHAR;
+
+ return rd_regb(port, S3C2410_URXH);
+}
+
+static void s3c24xx_serial_put_poll_char(struct uart_port *port,
+ unsigned char c)
+{
+ unsigned int ufcon = rd_regl(cons_uart, S3C2410_UFCON);
+
+ while (!s3c24xx_serial_console_txrdy(port, ufcon))
+ cpu_relax();
+ wr_regb(cons_uart, S3C2410_UTXH, c);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
static void
s3c24xx_serial_console_putchar(struct uart_port *port, int ch)
{
--
1.7.7.3
^ permalink raw reply related
* [tty:tty-next 10/16] fs/compat_ioctl.c:869:1: error: 'TIOCSRS485' undeclared here (not in a function)
From: Fengguang Wu @ 2012-09-22 0:50 UTC (permalink / raw)
To: Jaeden Amero; +Cc: kernel-janitors, Greg Kroah-Hartman, Alan Cox, linux-serial
Hi Jaeden,
FYI, kernel build failed on
tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
head: ac57e7f38ea6fe7358cd0b7a2f2d21aef5ab70cd
commit: 84c3b84860440a9e3a3666c14112f41311b8f623 [10/16] compat_ioctl: Add RS-485 IOCTLs to the list
config: mips-fuloong2e_defconfig
All related error/warning messages:
fs/compat_ioctl.c:869:1: error: 'TIOCSRS485' undeclared here (not in a function)
fs/compat_ioctl.c:870:1: error: 'TIOCGRS485' undeclared here (not in a function)
vim +869 fs/compat_ioctl.c
863 COMPATIBLE_IOCTL(TIOCSPGRP)
864 COMPATIBLE_IOCTL(TIOCGPGRP)
865 COMPATIBLE_IOCTL(TIOCGPTN)
866 COMPATIBLE_IOCTL(TIOCSPTLCK)
867 COMPATIBLE_IOCTL(TIOCSERGETLSR)
868 COMPATIBLE_IOCTL(TIOCSIG)
> 869 COMPATIBLE_IOCTL(TIOCSRS485)
870 COMPATIBLE_IOCTL(TIOCGRS485)
871 #ifdef TCGETS2
872 COMPATIBLE_IOCTL(TCGETS2)
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* Re: [RFC 2/3] ARM: move udc_pxa2xx.h to linux/platform_data
From: Greg Kroah-Hartman @ 2012-09-21 23:05 UTC (permalink / raw)
To: Russell King
Cc: linux-arm-kernel, linux-serial, linux-usb, Imre Kaloz,
Krzysztof Halasa, Eric Miao, Haojian Zhuang, Felipe Balbi
In-Reply-To: <E1TEzet-00077v-VD@rmk-PC.arm.linux.org.uk>
On Fri, Sep 21, 2012 at 10:36:27AM +0100, Russell King wrote:
> Move the PXA2xx/IXP4xx UDC header file into linux/platform_data as it
> only contains a driver platform data structure.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RFC 1/3] ARM: move serial_sa1100.h header file to linux/platform_data
From: Greg Kroah-Hartman @ 2012-09-21 23:05 UTC (permalink / raw)
To: Russell King
Cc: linux-arm-kernel, linux-serial, linux-usb, Kristoffer Ericson,
Alan Cox
In-Reply-To: <E1TEzeZ-00077r-L1@rmk-PC.arm.linux.org.uk>
On Fri, Sep 21, 2012 at 10:36:07AM +0100, Russell King wrote:
> This is really driver platform data, so move it to the appropriate
> directory.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH v2] serial: set correct baud_base for EXSYS EX-41092 Dual 16950
From: Flavio Leitner @ 2012-09-22 0:04 UTC (permalink / raw)
To: linux-serial, linux-kernel; +Cc: Flavio Leitner
Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
drivers/tty/serial/8250/8250_pci.c | 9 +++++++--
include/linux/pci_ids.h | 1 -
2 files changed, 7 insertions(+), 3 deletions(-)
Changelog:
V2
moved IDs from pci_ids.h to 8250_pci.c
requested by greg k-h
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6b8fcb4 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1164,6 +1164,8 @@ pci_xr17c154_setup(struct serial_private *priv,
#define PCI_SUBDEVICE_ID_OCTPRO422 0x0208
#define PCI_SUBDEVICE_ID_POCTAL232 0x0308
#define PCI_SUBDEVICE_ID_POCTAL422 0x0408
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_00 0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_30 0x2530
#define PCI_VENDOR_ID_ADVANTECH 0x13fe
#define PCI_DEVICE_ID_INTEL_CE4100_UART 0x2e66
#define PCI_DEVICE_ID_ADVANTECH_PCI3620 0x3620
@@ -3232,8 +3234,11 @@ static struct pci_device_id serial_pci_tbl[] = {
* For now just used the hex ID 0x950a.
*/
{ PCI_VENDOR_ID_OXSEMI, 0x950a,
- PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
- pbn_b0_2_115200 },
+ PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_00,
+ 0, 0, pbn_b0_2_115200 },
+ { PCI_VENDOR_ID_OXSEMI, 0x950a,
+ PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_30,
+ 0, 0, pbn_b0_2_115200 },
{ PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_1130000 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..8d3c427 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,6 @@
#define PCI_DEVICE_ID_SIIG_8S_20x_650 0x2081
#define PCI_DEVICE_ID_SIIG_8S_20x_850 0x2082
#define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL 0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL 0x2530
#define PCI_VENDOR_ID_RADISYS 0x1331
--
1.7.11.4
^ permalink raw reply related
* Re: [RFC 3/3] ARM/AVR32: get rid of serial_at91.h
From: Greg Kroah-Hartman @ 2012-09-21 23:05 UTC (permalink / raw)
To: Russell King
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Nicolas Ferre, Alan Cox
In-Reply-To: <E1TEzfE-000780-1t-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
On Fri, Sep 21, 2012 at 10:36:48AM +0100, Russell King wrote:
> The definitions provided by serial_at91.h are only used by the
> atmel_serial driver, and the function that uses it is never called
> from anywhere in the kernel. Therefore, these definitions are unused
> and/or obsolete, and can be removed.
>
> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Vizzini
From: Greg KH @ 2012-09-21 22:52 UTC (permalink / raw)
To: Alan Cox, Rob Duncan; +Cc: linux-serial
In-Reply-To: <20120921154323.GH18601@kroah.com>
On Fri, Sep 21, 2012 at 04:43:23PM +0100, Greg KH wrote:
> [Rob added, as he wrote this driver.]
Ok, as Rob's email bounces, I'm just going to drop this driver entirely,
as I don't want to maintain it, and I can't answer any questions about
it.
Thanks for the review,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] serial: omap: fix the reciever line error case
From: Kevin Hilman @ 2012-09-21 21:46 UTC (permalink / raw)
To: Shubhrajyoti D; +Cc: linux-serial, linux-omap, linux-arm-kernel
In-Reply-To: <1348238239-18510-1-git-send-email-shubhrajyoti@ti.com>
Shubhrajyoti D <shubhrajyoti@ti.com> writes:
> This patch does the following
> - In case of errors if there least one data character in the RX FIFO
> read it otherwise it may stall the receiver.
>
> This is recommended in the interrupt reset method in the table 23-246 of
> the omap4 TRM.
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> - Tested on omap4sdp.
> - pm tested hitting off in idle and suspend.
> - v2 changes update the changelogs.
> - Also remove the dummy check as FE , PE , BI and OE are the only
> receiver errors.
Tested-by: Kevin Hilman <khilman@ti.com>
This one also makes the regression I was seeing on 3530/Overo disappear.
Thanks,
Kevin
^ permalink raw reply
* Re: [PATCH 3/3] serial: pl011: allow very high baudrates
From: Alan Cox @ 2012-09-21 20:55 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linus Walleij, Greg Kroah-Hartman, Alan Cox, Linus Walleij,
linux-serial, Guillaume Jaunet, Par-Gunnar Hjalmdahl, Anmar Oueja,
Matthias Locher, Rajanikanth H.V, Christophe Arnal,
linux-arm-kernel
In-Reply-To: <20120921203440.GA6796@n2100.arm.linux.org.uk>
On Fri, 21 Sep 2012 21:34:40 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Sep 21, 2012 at 08:56:03PM +0100, Alan Cox wrote:
> > If you are calling TCSETS2 passing BOTHER and an actual specific speed
> > you should always be getting handed back the speed requested as it'll see
> > the BOTHER flag is present and assume the caller is smart.
>
> Is this something that should be handled by glibc? If so, ARM for
> whatever reason still seems to use the standard TCGETS and TCSETS
> calls... at least stracing stty in ubuntu precise suggests that's
> the case.
The design was agreed with the glibc people years ago. The glibc folks
then repeatedly ignored it and refused to add it. So I gave up on them.
If you are doing low level tty speed stuff, use ioctl directly.
Now that glibc has had a management change and a clue implant maybe it
can be fixed. Feel free to go kicking deal whales down beaches if you
care.
Alan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox