* [PATCH 05/12] usb, kobil: Sort out some bogus tty handling
From: Alan Cox @ 2012-06-27 11:21 UTC (permalink / raw)
To: greg, linux-serial
In-Reply-To: <20120627112102.5678.4141.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Stuff noticed while doing the termios conversion.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/usb/serial/kobil_sct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c
index fafeabb..0852472 100644
--- a/drivers/usb/serial/kobil_sct.c
+++ b/drivers/usb/serial/kobil_sct.c
@@ -192,8 +192,8 @@ static void kobil_init_termios(struct tty_struct *tty)
{
/* Default to echo off and other sane device settings */
tty->termios->c_lflag = 0;
- tty->termios->c_lflag &= ~(ISIG | ICANON | ECHO | IEXTEN | XCASE);
- tty->termios->c_iflag = IGNBRK | IGNPAR | IXOFF;
+ tty->termios->c_iflag &= ~(ISIG | ICANON | ECHO | IEXTEN | XCASE);
+ tty->termios->c_iflag |= IGNBRK | IGNPAR | IXOFF;
/* do NOT translate CR to CR-NL (0x0A -> 0x0A 0x0D) */
tty->termios->c_oflag &= ~ONLCR;
}
@@ -588,7 +588,7 @@ static void kobil_set_termios(struct tty_struct *tty,
if (priv->device_type == KOBIL_USBTWIN_PRODUCT_ID ||
priv->device_type == KOBIL_KAAN_SIM_PRODUCT_ID) {
/* This device doesn't support ioctl calls */
- *tty->termios = *old;
+ tty_termios_copy_hw(tty->termios, old_termios);
return;
}
^ permalink raw reply related
* [PATCH 04/12] gpio-sch: Fix leak of resource
From: Alan Cox @ 2012-06-27 11:21 UTC (permalink / raw)
To: greg, linux-serial
In-Reply-To: <20120627112102.5678.4141.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/gpio/gpio-sch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 424dce8..8707d45 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -241,7 +241,8 @@ static int __devinit sch_gpio_probe(struct platform_device *pdev)
break;
default:
- return -ENODEV;
+ err = -ENODEV;
+ goto err_sch_gpio_core;
}
sch_gpio_core.dev = &pdev->dev;
^ permalink raw reply related
* [PATCH 03/12] tty: Note n_tty race
From: Alan Cox @ 2012-06-27 11:21 UTC (permalink / raw)
To: greg, linux-serial
In-Reply-To: <20120627112102.5678.4141.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
This was identified by Vincent Pillet with a high speed interface that uses
low latency mode. In the low latency case we have a tiny race but it can
be hit.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/n_tty.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index ee1c268..4f34491 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -1432,6 +1432,12 @@ static void n_tty_receive_buf(struct tty_struct *tty, const unsigned char *cp,
*/
if (tty->receive_room < TTY_THRESHOLD_THROTTLE)
tty_throttle(tty);
+
+ /* FIXME: there is a tiny race here if the receive room check runs
+ before the other work executes and empties the buffer (upping
+ the receiving room and unthrottling. We then throttle and get
+ stuck. This has been observed and traced down by Vincent Pillet/
+ We need to address this when we sort out out the rx path locking */
}
int is_ignored(int sig)
^ permalink raw reply related
* [PATCH 02/12] usb: fix sillies in the metro USB driver
From: Alan Cox @ 2012-06-27 11:21 UTC (permalink / raw)
To: greg, linux-serial
In-Reply-To: <20120627112102.5678.4141.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Bits noticed doing the termios conversion
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/usb/serial/metro-usb.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/usb/serial/metro-usb.c b/drivers/usb/serial/metro-usb.c
index 81423f7..bad5f0c 100644
--- a/drivers/usb/serial/metro-usb.c
+++ b/drivers/usb/serial/metro-usb.c
@@ -130,20 +130,14 @@ static void metrousb_read_int_callback(struct urb *urb)
/* Set the data read from the usb port into the serial port buffer. */
tty = tty_port_tty_get(&port->port);
- if (!tty) {
- dev_err(&port->dev, "%s - bad tty pointer - exiting\n",
- __func__);
- return;
- }
-
if (tty && urb->actual_length) {
/* Loop through the data copying each byte to the tty layer. */
tty_insert_flip_string(tty, data, urb->actual_length);
/* Force the data to the tty layer. */
tty_flip_buffer_push(tty);
+ tty_kref_put(tty);
}
- tty_kref_put(tty);
/* Set any port variables. */
spin_lock_irqsave(&metro_priv->lock, flags);
^ permalink raw reply related
* [PATCH 01/12] f81232: correct stubbed termios handler
From: Alan Cox @ 2012-06-27 11:21 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/usb/serial/f81232.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 499b15f..acd3267 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -177,6 +177,7 @@ static void f81232_set_termios(struct tty_struct *tty,
return;
/* Do the real work here... */
+ tty_termios_copy_hw(&tty->termios, old_termios);
}
static int f81232_tiocmget(struct tty_struct *tty)
^ permalink raw reply related
* sua caixa de correio
From: System Administrator @ 2012-06-27 9:04 UTC (permalink / raw)
ATENÇÃO;
Sua caixa de correio excedeu o limite de armazenamento que é de 5 GB, como definido pelo administrador, que está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa postal, envie os seguintes dados abaixo:
nome:
Nome de usuário:
senha:
Confirme a Senha:
E-mail:
Se você não conseguir revalidar sua caixa de correio, o correio será desactivado!
obrigado
Administrador do Sistema
--
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 06/12] 8250: use the 8250 register interface not the legacy one
From: Greg KH @ 2012-06-27 2:30 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, linux-serial
In-Reply-To: <20120622154333.1405.21372.stgit@localhost.localdomain>
On Fri, Jun 22, 2012 at 04:43:51PM +0100, Alan Cox wrote:
> @@ -69,7 +69,6 @@ struct uart_port;
> struct uart_8250_port;
>
> int serial8250_register_8250_port(struct uart_8250_port *);
> -int serial8250_register_port(struct uart_port *);
There are still in-kernel callers of this function, so I don't think
it's safe to remove just yet, otherwise the build will break:
drivers/char/mwave/mwavedd.c: return serial8250_register_port(&uart);
drivers/misc/ibmasm/uart.c: sp->serial_line = serial8250_register_port(&uport);
drivers/net/ethernet/sgi/ioc3-eth.c: serial8250_register_port(&port);
drivers/tty/serial/of_serial.c: ret = serial8250_register_port(&port);
I'm stopping here on this series, I've only applied the one that added
the comment, that seems to be the only one that compiled properly :(
Care to redo these please?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 04/12] gpio-sch: Fix resource leak
From: Greg KH @ 2012-06-27 2:25 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, linux-serial
In-Reply-To: <20120622154040.1405.28472.stgit@localhost.localdomain>
On Fri, Jun 22, 2012 at 04:42:40PM +0100, Alan Cox wrote:
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/gpio/gpio-sch.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Is this a serial driver? I can't take this :(
greg k-h
^ permalink raw reply
* Re: [PATCH 05/12] kobil_sct: Fix some bogus tty handling
From: Greg KH @ 2012-06-27 2:24 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, linux-serial
In-Reply-To: <20120622154251.1405.12270.stgit@localhost.localdomain>
On Fri, Jun 22, 2012 at 04:43:22PM +0100, Alan Cox wrote:
> Stuff noticed while doing the termios conversion.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/usb/serial/kobil_sct.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c
> index fafeabb..0852472 100644
> --- a/drivers/usb/serial/kobil_sct.c
> +++ b/drivers/usb/serial/kobil_sct.c
> @@ -192,8 +192,8 @@ static void kobil_init_termios(struct tty_struct *tty)
> {
> /* Default to echo off and other sane device settings */
> tty->termios->c_lflag = 0;
> - tty->termios->c_lflag &= ~(ISIG | ICANON | ECHO | IEXTEN | XCASE);
> - tty->termios->c_iflag = IGNBRK | IGNPAR | IXOFF;
> + tty->termios->c_iflag &= ~(ISIG | ICANON | ECHO | IEXTEN | XCASE);
> + tty->termios->c_iflag |= IGNBRK | IGNPAR | IXOFF;
> /* do NOT translate CR to CR-NL (0x0A -> 0x0A 0x0D) */
> tty->termios->c_oflag &= ~ONLCR;
> }
> @@ -588,7 +588,7 @@ static void kobil_set_termios(struct tty_struct *tty,
> if (priv->device_type == KOBIL_USBTWIN_PRODUCT_ID ||
> priv->device_type == KOBIL_KAAN_SIM_PRODUCT_ID) {
> /* This device doesn't support ioctl calls */
> - *tty->termios = *old;
> + tty_termios_copy_hw(tty->termios, old_termios);
> return;
> }
>
This patch also breaks the build:
drivers/usb/serial/kobil_sct.c: In function ‘kobil_set_termios’:
drivers/usb/serial/kobil_sct.c:591:37: error: ‘old_termios’ undeclared (first use in this function)
drivers/usb/serial/kobil_sct.c:591:37: note: each undeclared identifier is reported only once for each function it appears in
^ permalink raw reply
* Re: [PATCH 01/12] f81232: correct stubbed termios handler
From: Greg KH @ 2012-06-27 2:22 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, linux-serial
In-Reply-To: <20120622153600.1405.15575.stgit@localhost.localdomain>
On Fri, Jun 22, 2012 at 04:36:42PM +0100, Alan Cox wrote:
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/usb/serial/f81232.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index 499b15f..acd3267 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -177,6 +177,7 @@ static void f81232_set_termios(struct tty_struct *tty,
> return;
>
> /* Do the real work here... */
> + tty_termios_copy_hw(&tty->termios, old_termios);
> }
This patch breaks the build:
drivers/usb/serial/f81232.c: In function ‘f81232_set_termios’:
drivers/usb/serial/f81232.c:180:2: warning: passing argument 1 of ‘tty_termios_copy_hw’ from incompatible pointer type [enabled by default]
include/linux/tty.h:454:13: note: expected ‘struct ktermios *’ but argument is of type ‘struct ktermios **’
I know the driver isn't complete, but it should at least build :)
thanks,
greg k-h
--
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
* [PATCH 3/3] serial/8250: delete WR SBC850 UART quirk handling
From: Paul Gortmaker @ 2012-06-26 19:54 UTC (permalink / raw)
To: benh
Cc: linuxppc-dev, Paul Gortmaker, Alan Cox, Greg Kroah-Hartman,
linux-serial
In-Reply-To: <1340740469-31445-1-git-send-email-paul.gortmaker@windriver.com>
We've are dropping the support for the EOL SBC8560, so we can
also delete this variant of the Alpha quirk support.
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/tty/serial/8250/8250.h | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index f9719d1..ffd1e6e 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -119,13 +119,6 @@ static inline void serial_dl_write(struct uart_8250_port *up, int value)
* is cleared, the machine locks up with endless interrupts.
*/
#define ALPHA_KLUDGE_MCR (UART_MCR_OUT2 | UART_MCR_OUT1)
-#elif defined(CONFIG_SBC8560)
-/*
- * WindRiver did something similarly broken on their SBC8560 board. The
- * UART tristates its IRQ output while OUT2 is clear, but they pulled
- * the interrupt line _up_ instead of down, so if we register the IRQ
- * while the UART is in that state, we die in an IRQ storm. */
-#define ALPHA_KLUDGE_MCR (UART_MCR_OUT2)
#else
#define ALPHA_KLUDGE_MCR 0
#endif
--
1.7.9.1
^ permalink raw reply related
* Re: Patch for panic in n_tty_read()
From: Alan Cox @ 2012-06-26 14:21 UTC (permalink / raw)
To: Stanislav Kozina; +Cc: Greg Kroah-Hartman, linux-serial
In-Reply-To: <4FE886C6.7090606@redhat.com>
> We had few customers who met panics in n_tty_read() with following
> backtrace:
>
> #8 [ffff880018b8dcd0] page_fault at ffffffff814ddfe5
> [exception RIP: n_tty_read+0x2c9]
> <register output removed>
> #9 [ffff880018b8dea0] tty_read at ffffffff81300b16
> #10 [ffff880018b8def0] vfs_read at ffffffff81172f85
> #11 [ffff880018b8df30] sys_read at ffffffff811730c1
> #12 [ffff880018b8df80] system_call_fastpath at ffffffff8100b172
What serial driver are they using when they hit this ?
>
> My patch for this panic is attached (tty_panic.patch), in short - I
> believe that we need to hold &tty->read_lock while checking
> tty->read_cnt in while-loop condition in n_tty_read() here:
We can't hold the lock for the loop because we touch user space memory.
Alan
^ permalink raw reply
* Re: [PATCH] serial/amba-pl011: move custom pin control to driver
From: Linus Walleij @ 2012-06-25 18:46 UTC (permalink / raw)
To: viresh kumar
Cc: Linus Walleij, Vipul Kumar SAMAR, Greg Kroah-Hartman,
linux-serial, linux-arm-kernel, Lee Jones, Shawn Guo,
Russell King, spear-devel
In-Reply-To: <CAOh2x==OPVVLeKxCT0mkYX3NmOjGQRcsSY=GHCaHEJfy6wOg3Q@mail.gmail.com>
On Mon, Jun 25, 2012 at 7:31 PM, viresh kumar <viresh.kumar@linaro.org> wrote:
> People testing SPEAr with v3.5-rc1 saw that serial devices don't show
> up during boot and they
> actually return with error from this point, after Shawn's last patch.
> That will still happen with
> this patch i believe.
>
> What is expected from Platforms to handle this? AFAICR, we haven't
> done anything special
> to bind a pinctrl node to a struct dev for uart.
Yeah as Fabio pointed out, activate dummies is the quick
fix.
The "real" fix is to provide atleast a default pin map table
entry (sleep is not needed).
However I think you could benefit from using this on
SPEAr by providing two different pinconf lists for
the default and sleep modes as the ux500 does:
usually this saves some power.
Yours,
Linus Walleij
^ permalink raw reply
* Patch for panic in n_tty_read()
From: Stanislav Kozina @ 2012-06-25 15:41 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]
Greg,
(my first suggested patch for Linux kernel, so please bear with me if I
don't follow process correctly. Thank you.)
We had few customers who met panics in n_tty_read() with following
backtrace:
#8 [ffff880018b8dcd0] page_fault at ffffffff814ddfe5
[exception RIP: n_tty_read+0x2c9]
<register output removed>
#9 [ffff880018b8dea0] tty_read at ffffffff81300b16
#10 [ffff880018b8def0] vfs_read at ffffffff81172f85
#11 [ffff880018b8df30] sys_read at ffffffff811730c1
#12 [ffff880018b8df80] system_call_fastpath at ffffffff8100b172
My patch for this panic is attached (tty_panic.patch), in short - I
believe that we need to hold &tty->read_lock while checking
tty->read_cnt in while-loop condition in n_tty_read() here:
1835 while (nr && tty->read_cnt) {
1836 int eol;
1837
1838 eol =
test_and_clear_bit(tty->read_tail,
1839 tty->read_flags);
1840 c = tty->read_buf[tty->read_tail];
1841 spin_lock_irqsave(&tty->read_lock,
flags);
We gave this patch to the customers, they were testing it for a month on
several tens of machines without being able to reproduce the problem.
Please can you integrate the patch into the kernel?
My testing
====
The patch pulls the spinlock out of the while loop. This makes
reset_buffer_flags() and others wait before changing either read_buf or
read_cnt. So this should solve the issue - the question is if this can
cause any deadlock.
I inserted the msleep(2000) when the lock is held. This should trigger
any deadlock of possible.
I found out that:
1) n_tty_read() runs when I e.g. log on the serial console
2) reset_buffer_flags() is running when I push CTRL+C on any terminal
That's why my plan was to log on serial console, and than (in shorter
time than 2 seconds) press CTRL+C on any terminal. I wrote a stap script
to verify that both functions were running, the stap script is attached.
And this is part of the output from attached stap script:
1336070859652 -> reset_buffer_flags (PID: 225)
1336070859652 <- reset_buffer_flags (PID: 225)
1336070859652 <- n_tty_read (PID: 7527, retval: -512)
1336070859652 -> n_tty_read (PID: 7527)
1336070859654 -> n_tty_read (PID: 7502)
1336070859654 <- n_tty_read (PID: 7502, retval: 53)
1336070867135 -> n_tty_read (PID: 7498)
1336070867135 <- n_tty_read (PID: 7498, retval: 1)
1336070868260 -> reset_buffer_flags (PID: 237)
1336070868260 <- reset_buffer_flags (PID: 237)
It's clear to see when we were in the msleep(2000) - it forced
n_tty_read to be delayed by 2 seconds in PID 7498. That's why even
reset_buffer_flags was not running.
[-- Attachment #2: tty_panic.patch --]
[-- Type: text/plain, Size: 987 bytes --]
diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
index 2e50f4d..ace0c19 100644
--- a/drivers/char/n_tty.c
+++ b/drivers/char/n_tty.c
@@ -1813,13 +1813,13 @@ do_it_again:
if (tty->icanon) {
/* N.B. avoid overrun if nr == 0 */
+ spin_lock_irqsave(&tty->read_lock, flags);
while (nr && tty->read_cnt) {
int eol;
eol = test_and_clear_bit(tty->read_tail,
tty->read_flags);
c = tty->read_buf[tty->read_tail];
- spin_lock_irqsave(&tty->read_lock, flags);
tty->read_tail = ((tty->read_tail+1) &
(N_TTY_BUF_SIZE-1));
tty->read_cnt--;
@@ -1831,7 +1831,6 @@ do_it_again:
if (--tty->canon_data < 0)
tty->canon_data = 0;
}
- spin_unlock_irqrestore(&tty->read_lock, flags);
if (!eol || (c != __DISABLED_CHAR)) {
if (tty_put_user(tty, c, b++)) {
@@ -1846,6 +1845,7 @@ do_it_again:
break;
}
}
+ spin_unlock_irqrestore(&tty->read_lock, flags);
if (retval)
break;
} else {
[-- Attachment #3: trace.stp --]
[-- Type: text/plain, Size: 511 bytes --]
probe kernel.function("reset_buffer_flags").call
{
printf("%d -> %s (PID: %d)\n", gettimeofday_ms(), probefunc(), pid());
}
probe kernel.function("reset_buffer_flags").return
{
printf("%d <- %s (PID: %d)\n", gettimeofday_ms(), probefunc(), pid());
}
probe kernel.function("n_tty_read").call
{
printf("%d -> %s (PID: %d)\n", gettimeofday_ms(), probefunc(), pid());
}
probe kernel.function("n_tty_read").return
{
printf("%d <- %s (PID: %d, retval: %d)\n", gettimeofday_ms(), probefunc(), pid(), $return)
}
^ permalink raw reply related
* Re: [PATCH] serial/amba-pl011: move custom pin control to driver
From: viresh kumar @ 2012-06-25 13:17 UTC (permalink / raw)
To: Fabio Estevam
Cc: Linus Walleij, Vipul Kumar SAMAR, Greg Kroah-Hartman,
Linus Walleij, spear-devel, linux-serial, Russell King, Shawn Guo,
Lee Jones, linux-arm-kernel
In-Reply-To: <CAOMZO5DoO32LZyZAqrY=ut5HN=bEf7UgAhVkRBwZzrexeTKOXA@mail.gmail.com>
On Mon, Jun 25, 2012 at 2:09 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Jun 25, 2012 at 8:31 AM, viresh kumar <viresh.kumar@linaro.org> wrote:
>> What is expected from Platforms to handle this? AFAICR, we haven't
>> done anything special
>> to bind a pinctrl node to a struct dev for uart.
>
> Does using "pinctrl_provide_dummies()" fix this problem?
I have seen imx patches using this stuff and probably it will fix our
problem. We are
checking and will come back tomorrow.
--
viresh
^ permalink raw reply
* Re: [PATCH] serial/amba-pl011: move custom pin control to driver
From: Fabio Estevam @ 2012-06-25 13:09 UTC (permalink / raw)
To: viresh kumar
Cc: Linus Walleij, Vipul Kumar SAMAR, Greg Kroah-Hartman,
Linus Walleij, spear-devel, linux-serial, Russell King, Shawn Guo,
Lee Jones, linux-arm-kernel
In-Reply-To: <CAOh2x==OPVVLeKxCT0mkYX3NmOjGQRcsSY=GHCaHEJfy6wOg3Q@mail.gmail.com>
Hi Viresh,
On Mon, Jun 25, 2012 at 8:31 AM, viresh kumar <viresh.kumar@linaro.org> wrote:
> What is expected from Platforms to handle this? AFAICR, we haven't
> done anything special
> to bind a pinctrl node to a struct dev for uart.
Does using "pinctrl_provide_dummies()" fix this problem?
^ permalink raw reply
* Re: [PATCH] serial/amba-pl011: move custom pin control to driver
From: viresh kumar @ 2012-06-25 11:31 UTC (permalink / raw)
To: Linus Walleij, Vipul Kumar SAMAR
Cc: Greg Kroah-Hartman, linux-serial, linux-arm-kernel, Lee Jones,
Linus Walleij, Shawn Guo, Russell King, spear-devel
In-Reply-To: <1337800726-4076-1-git-send-email-linus.walleij@stericsson.com>
On Wed, May 23, 2012 at 8:18 PM, Linus Walleij
<linus.walleij@stericsson.com> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> We had a boot regression in Ux500 in the merge window because
> two orthogonal pin control schemes for the PL011 were merged
> at the same time:
>
> - One using the .init() and .exit() hooks into the platform
> for Ux500 putting the pins into default vs sleep state
> respectively as the port was started/stopped.
> commit a09806607fd20bed2f8c41fe22793386790a14aa
> "ARM: ux500: switch to using pinctrl for uart0"
>
> - One hogging the default setting at PL011 probe()
> commit 258e055111d3cde2607e0d04eb91da2f7a59b591
> "serial: amba-pl011: adopt pinctrl support"
>
> To get a solution that works for both let's scrap the stuff
> in the platform callbacks, instead have the driver itself
> select default and sleep states when the port is
> started/stopped. Hopefully this works for all clients.
> Platform callbacks are bad for device tree migration anyway,
> so this rids us of another problem in Ux500.
>
> Cc: linux-serial@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Reported-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/mach-ux500/board-mop500.c | 54 +-----------------------------------
> drivers/tty/serial/amba-pl011.c | 45 +++++++++++++++++++++++++++---
> 2 files changed, 42 insertions(+), 57 deletions(-)
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> @@ -1869,11 +1897,20 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
> goto free;
> }
>
> - pinctrl = devm_pinctrl_get_select_default(&dev->dev);
> - if (IS_ERR(pinctrl)) {
> - ret = PTR_ERR(pinctrl);
> + uap->pinctrl = devm_pinctrl_get(&dev->dev);
> + if (IS_ERR(uap->pinctrl)) {
> + ret = PTR_ERR(uap->pinctrl);
> goto unmap;
> }
Hi Linus,
People testing SPEAr with v3.5-rc1 saw that serial devices don't show
up during boot and they
actually return with error from this point, after Shawn's last patch.
That will still happen with
this patch i believe.
What is expected from Platforms to handle this? AFAICR, we haven't
done anything special
to bind a pinctrl node to a struct dev for uart.
--
Viresh
--
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 02/12] usb: fix sillies in the metro USB driver
From: Jiri Slaby @ 2012-06-24 21:49 UTC (permalink / raw)
To: Alan Cox; +Cc: greg, linux-kernel, linux-serial, Jiri Slaby
In-Reply-To: <20120622153655.1405.21453.stgit@localhost.localdomain>
On 06/22/2012 05:38 PM, Alan Cox wrote:
> Bits noticed doing the termios conversion
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/usb/serial/metro-usb.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/usb/serial/metro-usb.c b/drivers/usb/serial/metro-usb.c
> index 81423f7..bad5f0c 100644
> --- a/drivers/usb/serial/metro-usb.c
> +++ b/drivers/usb/serial/metro-usb.c
> @@ -130,20 +130,14 @@ static void metrousb_read_int_callback(struct urb *urb)
...
> if (tty && urb->actual_length) {
> /* Loop through the data copying each byte to the tty layer. */
> tty_insert_flip_string(tty, data, urb->actual_length);
>
> /* Force the data to the tty layer. */
> tty_flip_buffer_push(tty);
> + tty_kref_put(tty);
> }
> - tty_kref_put(tty);
This doesn't seem right. (Depends on whether tty is non-null iff
urb->actual_length is non-zero.)
thanks,
--
js
suse labs
^ permalink raw reply
* Re: serial/mxs-auart: Unable to get interrupt counter from user space
From: Greg KH @ 2012-06-24 17:53 UTC (permalink / raw)
To: Stefan Wahren; +Cc: linux-serial
In-Reply-To: <4FE6DA89.50503@lategoodbye.de>
On Sun, Jun 24, 2012 at 11:14:49AM +0200, Stefan Wahren wrote:
> Hi,
>
> Am 24.06.2012 04:25, schrieb Greg KH:
> >On Sat, Jun 23, 2012 at 09:19:40PM +0200, Stefan Wahren wrote:
> >>Hello,
> >>
> >>i'm using Linux 2.6.35 at ARM and i experience the following issue
> >>with the mxs-auart (App UART). If i transmit and receive data over
> >>the serial port (using mxs-auart), all the interrupt counter (RX,
> >>TX, frame, parity, break) accessed from user space (ioctl with
> >>TIOCGICOUNT or /proc/tty/driver/auart) are zero.
> >>
> >>Here is the scenario to reproduce the problem:
> >>
> >>1. echoing some characters to the uart device
> >>2. fetch the statistics from proc-Filesystem
> >>
> >>Expected results: transmit counter greater than zero
> >>
> >>Observed results: transmit counter is always zero
> >>
> >>The same szenario on the mxs-duart (Debug UART) doesn't show this problem.
> >>
> >>Is this a bug in mxs-auart or just not implemented?
> >
> >We disabled the transmit counter from being displayed a while ago for
> >security reasons, perhaps that is what you are seeing?
>
> Does this security fix affect serial_core or only mxs-auart?
I do not recall, sorry.
> Prevent this security fix from reading all counter (TX, RX, frame
> erros, parity errors, breaks)?
>
> Do you mean this security issue (
> https://bugzilla.redhat.com/show_bug.cgi?id=648660 ) ?
Nope, a different one.
> >Also, you do realize just how old 2.6.35 really is, right?
>
> Unfortunaley yes, Freescale the vendor delivers the Board Support
> Package only with 2.6.35.
I suggest you contact Freescale for support for this issue then, as
there's nothing we can do about that old kernel version, sorry.
good luck,
greg k-h
^ permalink raw reply
* Re: serial/mxs-auart: Unable to get interrupt counter from user space
From: Stefan Wahren @ 2012-06-24 9:14 UTC (permalink / raw)
To: Greg KH; +Cc: linux-serial
In-Reply-To: <20120624022547.GA7307@kroah.com>
Hi,
Am 24.06.2012 04:25, schrieb Greg KH:
> On Sat, Jun 23, 2012 at 09:19:40PM +0200, Stefan Wahren wrote:
>> Hello,
>>
>> i'm using Linux 2.6.35 at ARM and i experience the following issue
>> with the mxs-auart (App UART). If i transmit and receive data over
>> the serial port (using mxs-auart), all the interrupt counter (RX,
>> TX, frame, parity, break) accessed from user space (ioctl with
>> TIOCGICOUNT or /proc/tty/driver/auart) are zero.
>>
>> Here is the scenario to reproduce the problem:
>>
>> 1. echoing some characters to the uart device
>> 2. fetch the statistics from proc-Filesystem
>>
>> Expected results: transmit counter greater than zero
>>
>> Observed results: transmit counter is always zero
>>
>> The same szenario on the mxs-duart (Debug UART) doesn't show this problem.
>>
>> Is this a bug in mxs-auart or just not implemented?
>
> We disabled the transmit counter from being displayed a while ago for
> security reasons, perhaps that is what you are seeing?
Does this security fix affect serial_core or only mxs-auart?
Prevent this security fix from reading all counter (TX, RX, frame erros,
parity errors, breaks)?
Do you mean this security issue (
https://bugzilla.redhat.com/show_bug.cgi?id=648660 ) ?
>
> Also, you do realize just how old 2.6.35 really is, right?
Unfortunaley yes, Freescale the vendor delivers the Board Support
Package only with 2.6.35.
>
> thanks,
>
> greg k-h
>
Thanks
Stefan
^ permalink raw reply
* Re: serial/mxs-auart: Unable to get interrupt counter from user space
From: Greg KH @ 2012-06-24 2:25 UTC (permalink / raw)
To: Stefan Wahren; +Cc: linux-serial
In-Reply-To: <4FE616CC.9000709@lategoodbye.de>
On Sat, Jun 23, 2012 at 09:19:40PM +0200, Stefan Wahren wrote:
> Hello,
>
> i'm using Linux 2.6.35 at ARM and i experience the following issue
> with the mxs-auart (App UART). If i transmit and receive data over
> the serial port (using mxs-auart), all the interrupt counter (RX,
> TX, frame, parity, break) accessed from user space (ioctl with
> TIOCGICOUNT or /proc/tty/driver/auart) are zero.
>
> Here is the scenario to reproduce the problem:
>
> 1. echoing some characters to the uart device
> 2. fetch the statistics from proc-Filesystem
>
> Expected results: transmit counter greater than zero
>
> Observed results: transmit counter is always zero
>
> The same szenario on the mxs-duart (Debug UART) doesn't show this problem.
>
> Is this a bug in mxs-auart or just not implemented?
We disabled the transmit counter from being displayed a while ago for
security reasons, perhaps that is what you are seeing?
Also, you do realize just how old 2.6.35 really is, right?
thanks,
greg k-h
^ permalink raw reply
* serial/mxs-auart: Unable to get interrupt counter from user space
From: Stefan Wahren @ 2012-06-23 19:19 UTC (permalink / raw)
To: linux-serial
Hello,
i'm using Linux 2.6.35 at ARM and i experience the following issue with
the mxs-auart (App UART). If i transmit and receive data over the serial
port (using mxs-auart), all the interrupt counter (RX, TX, frame,
parity, break) accessed from user space (ioctl with TIOCGICOUNT or
/proc/tty/driver/auart) are zero.
Here is the scenario to reproduce the problem:
1. echoing some characters to the uart device
2. fetch the statistics from proc-Filesystem
Expected results: transmit counter greater than zero
Observed results: transmit counter is always zero
The same szenario on the mxs-duart (Debug UART) doesn't show this problem.
Is this a bug in mxs-auart or just not implemented?
Best Regards
Stefan
^ permalink raw reply
* What'd u say if I offer meeting???
From: Shawnee Hollingshead @ 2012-06-23 15:04 UTC (permalink / raw)
To: sibyjc@yahoo.co.in
How are you doing,
I am Shawnee - playful babe with a lot of mad thoughts in a head!
What I look for here? You know, I am not sure! It could be just interesting conversations with guys, maybe some flirt, maybe some bedroom relations or maybe something like serious relations if we're lucky. Who knows, maybe you're what I wanted to find here?!
Well, bye-bye, give me a message, my sweet boy. I gonna wait for it! Kissing
Shawnee
^ permalink raw reply
* Re: [PATCH 09/12] commit 22126843cb3c2a782c2d52614486115f3e9db478
From: Alan Cox @ 2012-06-22 17:04 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-serial
In-Reply-To: <20120622153657.GB6081@kroah.com>
On Fri, 22 Jun 2012 08:36:57 -0700
Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Jun 22, 2012 at 04:44:59PM +0100, Alan Cox wrote:
> > From: Alan Cox <alan@linux.intel.com>
> >
> > tty: move the termios object into the tty
> >
> > This will let us sort out a whole pile of tty related races. The
> > alternative would be to keep points and refcount the termios objects.
> > However
> > 1. They are tiny anyway
> > 2. Many devices don't use the stored copies
> > 3. We can remove a pty special case
> >
> > Signed-off-by: Alan Cox <alan@linux.intel.com>
>
> Odd subject line, and formatting, did something go wrong with your
> scripts?
Apparently so. I will given them a stern talking to and repost
^ permalink raw reply
* [PATCH 12/12] tty: move the handling of the tty release logic
From: Alan Cox @ 2012-06-22 15:47 UTC (permalink / raw)
To: greg, linux-kernel, linux-serial
In-Reply-To: <20120622153600.1405.15575.stgit@localhost.localdomain>
Now that we don't have tty->termios tied to drivers->tty we can untangle
the logic here. In addition we can push the removal logic out of the
destructor path.
At that point we can think about sorting out tty_port and console and all
the other ugly hangovers.
An important other property we now have is that the tty mutex does now cover
the drivers array. An assumption other bits of the code made and which is
necessary for the tty lock patch.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/tty/pty.c | 8 --------
drivers/tty/tty_io.c | 16 +++++-----------
drivers/tty/vt/vt.c | 1 -
drivers/usb/serial/usb-serial.c | 3 +--
include/linux/tty.h | 1 -
include/linux/tty_driver.h | 11 +++--------
6 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 56dcef4..f1ba793 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -497,12 +497,6 @@ static struct tty_struct *pts_unix98_lookup(struct tty_driver *driver,
return tty;
}
-static void pty_unix98_shutdown(struct tty_struct *tty)
-{
- tty_driver_remove_tty(tty->driver, tty);
- /* We have our own method as we don't use the tty index */
-}
-
/* We have no need to install and remove our tty objects as devpts does all
the work for us */
@@ -563,7 +557,6 @@ static const struct tty_operations ptm_unix98_ops = {
.unthrottle = pty_unthrottle,
.set_termios = pty_set_termios,
.ioctl = pty_unix98_ioctl,
- .shutdown = pty_unix98_shutdown,
.resize = pty_resize
};
@@ -579,7 +572,6 @@ static const struct tty_operations pty_unix98_ops = {
.chars_in_buffer = pty_chars_in_buffer,
.unthrottle = pty_unthrottle,
.set_termios = pty_set_termios,
- .shutdown = pty_unix98_shutdown
};
/**
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 14db2a8..e062c1b 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1443,12 +1443,6 @@ void tty_free_termios(struct tty_struct *tty)
}
EXPORT_SYMBOL(tty_free_termios);
-void tty_shutdown(struct tty_struct *tty)
-{
- tty_driver_remove_tty(tty->driver, tty);
- tty_free_termios(tty);
-}
-EXPORT_SYMBOL(tty_shutdown);
/**
* release_one_tty - release tty structure memory
@@ -1492,11 +1486,6 @@ static void queue_release_one_tty(struct kref *kref)
{
struct tty_struct *tty = container_of(kref, struct tty_struct, kref);
- if (tty->ops->shutdown)
- tty->ops->shutdown(tty);
- else
- tty_shutdown(tty);
-
/* The hangup queue is now free so we can reuse it rather than
waste a chunk of memory for each port */
INIT_WORK(&tty->hangup_work, release_one_tty);
@@ -1536,6 +1525,11 @@ static void release_tty(struct tty_struct *tty, int idx)
/* This should always be true but check for the moment */
WARN_ON(tty->index != idx);
+ if (tty->ops->shutdown)
+ tty->ops->shutdown(tty);
+ tty_free_termios(tty);
+ tty_driver_remove_tty(tty->driver, tty);
+
if (tty->link)
tty_kref_put(tty->link);
tty_kref_put(tty);
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 02c7cdd..2c9af9c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2839,7 +2839,6 @@ static void con_shutdown(struct tty_struct *tty)
console_lock();
vc->port.tty = NULL;
console_unlock();
- tty_shutdown(tty);
}
static int default_italic_color = 2; // green (ASCII)
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 003b191..3bca1ea 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -305,8 +305,7 @@ static void serial_close(struct tty_struct *tty, struct file *filp)
* Do the resource freeing and refcount dropping for the port.
* Avoid freeing the console.
*
- * Called asynchronously after the last tty kref is dropped,
- * and the tty layer has already done the tty_shutdown(tty);
+ * Called asynchronously after the last tty kref is dropped.
*/
static void serial_cleanup(struct tty_struct *tty)
{
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 86fce83..4132d9e 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -423,7 +423,6 @@ extern void tty_unthrottle(struct tty_struct *tty);
extern int tty_do_resize(struct tty_struct *tty, struct winsize *ws);
extern void tty_driver_remove_tty(struct tty_driver *driver,
struct tty_struct *tty);
-extern void tty_shutdown(struct tty_struct *tty);
extern void tty_free_termios(struct tty_struct *tty);
extern int is_current_pgrp_orphaned(void);
extern struct pid *tty_get_pgrp(struct tty_struct *tty);
diff --git a/include/linux/tty_driver.h b/include/linux/tty_driver.h
index 6e6dbb7..2bcf2a9 100644
--- a/include/linux/tty_driver.h
+++ b/include/linux/tty_driver.h
@@ -45,14 +45,9 @@
*
* void (*shutdown)(struct tty_struct * tty);
*
- * This routine is called synchronously when a particular tty device
- * is closed for the last time freeing up the resources.
- * Note that tty_shutdown() is not called if ops->shutdown is defined.
- * This means one is responsible to take care of calling ops->remove (e.g.
- * via tty_driver_remove_tty) and releasing tty->termios.
- * Note that this hook may be called from *all* the contexts where one
- * uses tty refcounting (e.g. tty_port_tty_get).
- *
+ * This routine is called under the tty lock when a particular tty device
+ * is closed for the last time. It executes before the tty resources
+ * are freed so may execute while another function holds a tty kref.
*
* void (*cleanup)(struct tty_struct * tty);
*
^ permalink raw reply related
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