Re: [PATCH 02/13] bluetooth: hci_ldisc: fix deadlock condition
Dear Felipe Balbi, On Wed, Apr 23, 2014 at 09:58:26AM -0500, Felipe Balbi wrote: > LDISCs shouldn't call tty->ops->write() from within > ->write_wakeup(). > > ->write_wakeup() is called with port lock taken and > IRQs disabled, tty->ops->write() will try to acquire > the same port lock and we will deadlock. > > Acked-by: Marcel Holtmann > Reviewed-by: Peter Hurley > Reported-by: Huang Shijie > Signed-off-by: Felipe Balbi Tested-by: Andreas Bießmann on custom TI AM37xx board with 3.4.87. Therefore I vote for adding this to stable branches (at least 3.4). It applies with a slight line shifting (init_work is not available there). I wonder if you have seen my approach [1] to fix this deadlock. This stuff is quiet new to me. As I understood the work_queue has a bit more overhead than a tasklet. Therefore I implemented my fix with a tasklet. Would be great if one could shed some light on that. Best regards Andreas Bießmann [1] https://lkml.org/lkml/2014/4/16/425 > --- > drivers/bluetooth/hci_ldisc.c | 24 +++- > drivers/bluetooth/hci_uart.h | 1 + > 2 files changed, 20 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/13] bluetooth: hci_ldisc: fix deadlock condition
Dear Felipe Balbi, On Wed, Apr 23, 2014 at 09:58:26AM -0500, Felipe Balbi wrote: LDISCs shouldn't call tty-ops-write() from within -write_wakeup(). -write_wakeup() is called with port lock taken and IRQs disabled, tty-ops-write() will try to acquire the same port lock and we will deadlock. Acked-by: Marcel Holtmann mar...@holtmann.org Reviewed-by: Peter Hurley pe...@hurleysoftware.com Reported-by: Huang Shijie b32...@freescale.com Signed-off-by: Felipe Balbi ba...@ti.com Tested-by: Andreas Bießmann andr...@biessmann.de on custom TI AM37xx board with 3.4.87. Therefore I vote for adding this to stable branches (at least 3.4). It applies with a slight line shifting (init_work is not available there). I wonder if you have seen my approach [1] to fix this deadlock. This stuff is quiet new to me. As I understood the work_queue has a bit more overhead than a tasklet. Therefore I implemented my fix with a tasklet. Would be great if one could shed some light on that. Best regards Andreas Bießmann [1] https://lkml.org/lkml/2014/4/16/425 --- drivers/bluetooth/hci_ldisc.c | 24 +++- drivers/bluetooth/hci_uart.h | 1 + 2 files changed, 20 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth:hci_ldisc: add tasklet for deferred TX handling
Hi Johan,
Am 2014-04-23 17:15, schrieb Johan Hedberg:
On Wed, Apr 16, 2014, Andreas Bießmann wrote:
This patch fixes a recursive locking scenario when using BCSP
connection via
8250 driver. The 8250 driver may tty_wakeup() in interrupt context
which
results in hci_uart_tx_wakeup(). This in turn will call uart_write()
in the
very same context and therefore will spin_lock() the same lock within
the
same context.
Here is the call stack:
---8<---
=
[ INFO: possible recursive locking detected ]
3.4.87-gf1a3cc3 #3 Tainted: G O
-
swapper/0 is trying to acquire lock:
(_lock_key){-.-...}, at: [] uart_write+0x60/0xfc
but task is already holding lock:
(_lock_key){-.-...}, at: []
serial8250_handle_irq+0x24/0x88
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_lock_key);
lock(_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by swapper/0:
#0: (&(>lock)->rlock){-.-...}, at: []
serial8250_interrupt+0x2c/0xc0
#1: (_lock_key){-.-...}, at: []
serial8250_handle_irq+0x24/0x88
stack backtrace:
[] (unwind_backtrace+0x0/0xec) from []
(dump_stack+0x20/0x24)
[] (dump_stack+0x20/0x24) from []
(print_deadlock_bug+0xb4/0xe4)
[] (print_deadlock_bug+0xb4/0xe4) from []
(check_deadlock.isra.20+0x160/0x18c)
[] (check_deadlock.isra.20+0x160/0x18c) from []
(validate_chain.isra.24+0x4a4/0x4f0)
[] (validate_chain.isra.24+0x4a4/0x4f0) from []
(__lock_acquire+0x670/0x740)
[] (__lock_acquire+0x670/0x740) from []
(lock_acquire+0x138/0x15c)
[] (lock_acquire+0x138/0x15c) from []
(_raw_spin_lock_irqsave+0x54/0x68)
[] (_raw_spin_lock_irqsave+0x54/0x68) from []
(uart_write+0x60/0xfc)
[] (uart_write+0x60/0xfc) from []
(hci_uart_tx_wakeup+0x9c/0x160 [hci_uart])
[] (hci_uart_tx_wakeup+0x9c/0x160 [hci_uart]) from
[] (hci_uart_tty_wakeup+0x58/0x5c [hci_uart])
[] (hci_uart_tty_wakeup+0x58/0x5c [hci_uart]) from
[] (tty_wakeup+0x48/0x68)
[] (tty_wakeup+0x48/0x68) from []
(uart_write_wakeup+0x2c/0x30)
[] (uart_write_wakeup+0x2c/0x30) from []
(serial8250_tx_chars+0xf0/0x140)
[] (serial8250_tx_chars+0xf0/0x140) from []
(serial8250_handle_irq+0x6c/0x88)
[] (serial8250_handle_irq+0x6c/0x88) from []
(serial8250_default_handle_irq+0x30/0x34)
[] (serial8250_default_handle_irq+0x30/0x34) from
[] (serial8250_interrupt+0x44/0xc0)
[] (serial8250_interrupt+0x44/0xc0) from []
(handle_irq_event_percpu+0xc4/0x2cc)
[] (handle_irq_event_percpu+0xc4/0x2cc) from []
(handle_irq_event+0x4c/0x6c)
[] (handle_irq_event+0x4c/0x6c) from []
(handle_edge_irq+0x114/0x14c)
[] (handle_edge_irq+0x114/0x14c) from []
(generic_handle_irq+0x40/0x54)
[] (generic_handle_irq+0x40/0x54) from []
(gpio_irq_handler+0x168/0x1ac)
[] (gpio_irq_handler+0x168/0x1ac) from []
(generic_handle_irq+0x40/0x54)
[] (generic_handle_irq+0x40/0x54) from []
(handle_IRQ+0x70/0x94)
[] (handle_IRQ+0x70/0x94) from []
(omap3_intc_handle_irq+0x64/0x78)
[] (omap3_intc_handle_irq+0x64/0x78) from []
(__irq_svc+0x44/0x78)
--->8---
Signed-off-by: Andreas Bießmann
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: linux-blueto...@vger.kernel.org
---
It seems at least one other guy had the very same problem with another
uart
(mpc52xx): http://www.spinics.net/lists/linux-rt-users/msg09246.html
I wonder, if my approach is right. It is runtime tested with 3.4.87 on
our
board and work around the mentioned recursive locking. But I do not
know, if
it should be fixed in another way.
If it is right, I'd work some more on it to get the fix mainline.
drivers/bluetooth/hci_ldisc.c | 49
-
drivers/bluetooth/hci_uart.h |2 ++
2 files changed, 45 insertions(+), 6 deletions(-)
This seems to be tackling the same problem as the following patch from
Felipe Balbi (of which a new revision was sent earlier today):
Subject: [PATCH 02/13] bluetooth: hci_ldisc: fix deadlock condition
seems so, thanks for the pointer!
Best regards
Andreas Bießmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth:hci_ldisc: add tasklet for deferred TX handling
Hi Johan,
Am 2014-04-23 17:15, schrieb Johan Hedberg:
On Wed, Apr 16, 2014, Andreas Bießmann wrote:
This patch fixes a recursive locking scenario when using BCSP
connection via
8250 driver. The 8250 driver may tty_wakeup() in interrupt context
which
results in hci_uart_tx_wakeup(). This in turn will call uart_write()
in the
very same context and therefore will spin_lock() the same lock within
the
same context.
Here is the call stack:
---8---
=
[ INFO: possible recursive locking detected ]
3.4.87-gf1a3cc3 #3 Tainted: G O
-
swapper/0 is trying to acquire lock:
(port_lock_key){-.-...}, at: [c023e21c] uart_write+0x60/0xfc
but task is already holding lock:
(port_lock_key){-.-...}, at: [c0242830]
serial8250_handle_irq+0x24/0x88
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(port_lock_key);
lock(port_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by swapper/0:
#0: ((i-lock)-rlock){-.-...}, at: [c0240f44]
serial8250_interrupt+0x2c/0xc0
#1: (port_lock_key){-.-...}, at: [c0242830]
serial8250_handle_irq+0x24/0x88
stack backtrace:
[c0014234] (unwind_backtrace+0x0/0xec) from [c0398448]
(dump_stack+0x20/0x24)
[c0398448] (dump_stack+0x20/0x24) from [c006eebc]
(print_deadlock_bug+0xb4/0xe4)
[c006eebc] (print_deadlock_bug+0xb4/0xe4) from [c006f04c]
(check_deadlock.isra.20+0x160/0x18c)
[c006f04c] (check_deadlock.isra.20+0x160/0x18c) from [c0070890]
(validate_chain.isra.24+0x4a4/0x4f0)
[c0070890] (validate_chain.isra.24+0x4a4/0x4f0) from [c00715a0]
(__lock_acquire+0x670/0x740)
[c00715a0] (__lock_acquire+0x670/0x740) from [c0071cb0]
(lock_acquire+0x138/0x15c)
[c0071cb0] (lock_acquire+0x138/0x15c) from [c03a5904]
(_raw_spin_lock_irqsave+0x54/0x68)
[c03a5904] (_raw_spin_lock_irqsave+0x54/0x68) from [c023e21c]
(uart_write+0x60/0xfc)
[c023e21c] (uart_write+0x60/0xfc) from [bf0716d8]
(hci_uart_tx_wakeup+0x9c/0x160 [hci_uart])
[bf0716d8] (hci_uart_tx_wakeup+0x9c/0x160 [hci_uart]) from
[bf0717f4] (hci_uart_tty_wakeup+0x58/0x5c [hci_uart])
[bf0717f4] (hci_uart_tty_wakeup+0x58/0x5c [hci_uart]) from
[c02246ec] (tty_wakeup+0x48/0x68)
[c02246ec] (tty_wakeup+0x48/0x68) from [c023efb0]
(uart_write_wakeup+0x2c/0x30)
[c023efb0] (uart_write_wakeup+0x2c/0x30) from [c0241d0c]
(serial8250_tx_chars+0xf0/0x140)
[c0241d0c] (serial8250_tx_chars+0xf0/0x140) from [c0242878]
(serial8250_handle_irq+0x6c/0x88)
[c0242878] (serial8250_handle_irq+0x6c/0x88) from [c02428c4]
(serial8250_default_handle_irq+0x30/0x34)
[c02428c4] (serial8250_default_handle_irq+0x30/0x34) from
[c0240f5c] (serial8250_interrupt+0x44/0xc0)
[c0240f5c] (serial8250_interrupt+0x44/0xc0) from [c0087c70]
(handle_irq_event_percpu+0xc4/0x2cc)
[c0087c70] (handle_irq_event_percpu+0xc4/0x2cc) from [c0087ec4]
(handle_irq_event+0x4c/0x6c)
[c0087ec4] (handle_irq_event+0x4c/0x6c) from [c008a368]
(handle_edge_irq+0x114/0x14c)
[c008a368] (handle_edge_irq+0x114/0x14c) from [c0087528]
(generic_handle_irq+0x40/0x54)
[c0087528] (generic_handle_irq+0x40/0x54) from [c01f1900]
(gpio_irq_handler+0x168/0x1ac)
[c01f1900] (gpio_irq_handler+0x168/0x1ac) from [c0087528]
(generic_handle_irq+0x40/0x54)
[c0087528] (generic_handle_irq+0x40/0x54) from [c000ed7c]
(handle_IRQ+0x70/0x94)
[c000ed7c] (handle_IRQ+0x70/0x94) from [c000877c]
(omap3_intc_handle_irq+0x64/0x78)
[c000877c] (omap3_intc_handle_irq+0x64/0x78) from [c000df44]
(__irq_svc+0x44/0x78)
---8---
Signed-off-by: Andreas Bießmann andr...@biessmann.de
Cc: Marcel Holtmann mar...@holtmann.org
Cc: Gustavo Padovan gust...@padovan.org
Cc: Johan Hedberg johan.hedb...@gmail.com
Cc: linux-blueto...@vger.kernel.org
---
It seems at least one other guy had the very same problem with another
uart
(mpc52xx): http://www.spinics.net/lists/linux-rt-users/msg09246.html
I wonder, if my approach is right. It is runtime tested with 3.4.87 on
our
board and work around the mentioned recursive locking. But I do not
know, if
it should be fixed in another way.
If it is right, I'd work some more on it to get the fix mainline.
drivers/bluetooth/hci_ldisc.c | 49
-
drivers/bluetooth/hci_uart.h |2 ++
2 files changed, 45 insertions(+), 6 deletions(-)
This seems to be tackling the same problem as the following patch from
Felipe Balbi (of which a new revision was sent earlier today):
Subject: [PATCH 02/13] bluetooth: hci_ldisc: fix deadlock condition
seems so, thanks for the pointer!
Best regards
Andreas Bießmann
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bluetooth:hci_ldisc: add tasklet for deferred TX handling
This patch fixes a recursive locking scenario when using BCSP connection via
8250 driver. The 8250 driver may tty_wakeup() in interrupt context which
results in hci_uart_tx_wakeup(). This in turn will call uart_write() in the
very same context and therefore will spin_lock() the same lock within the
same context.
Here is the call stack:
---8<---
=
[ INFO: possible recursive locking detected ]
3.4.87-gf1a3cc3 #3 Tainted: G O
-
swapper/0 is trying to acquire lock:
(_lock_key){-.-...}, at: [] uart_write+0x60/0xfc
but task is already holding lock:
(_lock_key){-.-...}, at: [] serial8250_handle_irq+0x24/0x88
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_lock_key);
lock(_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by swapper/0:
#0: (&(>lock)->rlock){-.-...}, at: []
serial8250_interrupt+0x2c/0xc0
#1: (_lock_key){-.-...}, at: [] serial8250_handle_irq+0x24/0x88
stack backtrace:
[] (unwind_backtrace+0x0/0xec) from []
(dump_stack+0x20/0x24)
[] (dump_stack+0x20/0x24) from []
(print_deadlock_bug+0xb4/0xe4)
[] (print_deadlock_bug+0xb4/0xe4) from []
(check_deadlock.isra.20+0x160/0x18c)
[] (check_deadlock.isra.20+0x160/0x18c) from []
(validate_chain.isra.24+0x4a4/0x4f0)
[] (validate_chain.isra.24+0x4a4/0x4f0) from []
(__lock_acquire+0x670/0x740)
[] (__lock_acquire+0x670/0x740) from []
(lock_acquire+0x138/0x15c)
[] (lock_acquire+0x138/0x15c) from []
(_raw_spin_lock_irqsave+0x54/0x68)
[] (_raw_spin_lock_irqsave+0x54/0x68) from []
(uart_write+0x60/0xfc)
[] (uart_write+0x60/0xfc) from []
(hci_uart_tx_wakeup+0x9c/0x160 [hci_uart])
[] (hci_uart_tx_wakeup+0x9c/0x160 [hci_uart]) from []
(hci_uart_tty_wakeup+0x58/0x5c [hci_uart])
[] (hci_uart_tty_wakeup+0x58/0x5c [hci_uart]) from []
(tty_wakeup+0x48/0x68)
[] (tty_wakeup+0x48/0x68) from []
(uart_write_wakeup+0x2c/0x30)
[] (uart_write_wakeup+0x2c/0x30) from []
(serial8250_tx_chars+0xf0/0x140)
[] (serial8250_tx_chars+0xf0/0x140) from []
(serial8250_handle_irq+0x6c/0x88)
[] (serial8250_handle_irq+0x6c/0x88) from []
(serial8250_default_handle_irq+0x30/0x34)
[] (serial8250_default_handle_irq+0x30/0x34) from []
(serial8250_interrupt+0x44/0xc0)
[] (serial8250_interrupt+0x44/0xc0) from []
(handle_irq_event_percpu+0xc4/0x2cc)
[] (handle_irq_event_percpu+0xc4/0x2cc) from []
(handle_irq_event+0x4c/0x6c)
[] (handle_irq_event+0x4c/0x6c) from []
(handle_edge_irq+0x114/0x14c)
[] (handle_edge_irq+0x114/0x14c) from []
(generic_handle_irq+0x40/0x54)
[] (generic_handle_irq+0x40/0x54) from []
(gpio_irq_handler+0x168/0x1ac)
[] (gpio_irq_handler+0x168/0x1ac) from []
(generic_handle_irq+0x40/0x54)
[] (generic_handle_irq+0x40/0x54) from []
(handle_IRQ+0x70/0x94)
[] (handle_IRQ+0x70/0x94) from []
(omap3_intc_handle_irq+0x64/0x78)
[] (omap3_intc_handle_irq+0x64/0x78) from []
(__irq_svc+0x44/0x78)
--->8---
Signed-off-by: Andreas Bießmann
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: linux-blueto...@vger.kernel.org
---
It seems at least one other guy had the very same problem with another uart
(mpc52xx): http://www.spinics.net/lists/linux-rt-users/msg09246.html
I wonder, if my approach is right. It is runtime tested with 3.4.87 on our
board and work around the mentioned recursive locking. But I do not know, if
it should be fixed in another way.
If it is right, I'd work some more on it to get the fix mainline.
drivers/bluetooth/hci_ldisc.c | 49 -
drivers/bluetooth/hci_uart.h |2 ++
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index f1fbf4f..4da2f12 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -116,20 +116,37 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
return skb;
}
-int hci_uart_tx_wakeup(struct hci_uart *hu)
+static void hci_uart_tx_fill(unsigned long data)
{
- struct tty_struct *tty = hu->tty;
- struct hci_dev *hdev = hu->hdev;
+ struct hci_uart *hu = (struct hci_uart *)data;
+ struct tty_struct *tty;
+ struct hci_dev *hdev;
struct sk_buff *skb;
+ if (!hu) {
+ BT_DBG("%s: no hci_uart", __func__);
+ return;
+ }
+
+ tty = hu->tty;
+ if (!tty) {
+ BT_DBG("%s: no tty", __func__);
+ return;
+ }
+ hdev = hu->hdev;
+ if (!hdev) {
+ BT_DBG("%s: no hdev", __func__);
+ return;
+ }
+
if (test_and_set_bit(HCI_UART_SENDING, >tx_state)) {
set_bit(HCI_UART_TX_WAKEUP, >tx_state);
- return 0;
+ return;
}
- BT_DBG("");
-
restart:
+ BT_DBG(&
[PATCH] bluetooth:hci_ldisc: add tasklet for deferred TX handling
This patch fixes a recursive locking scenario when using BCSP connection via
8250 driver. The 8250 driver may tty_wakeup() in interrupt context which
results in hci_uart_tx_wakeup(). This in turn will call uart_write() in the
very same context and therefore will spin_lock() the same lock within the
same context.
Here is the call stack:
---8---
=
[ INFO: possible recursive locking detected ]
3.4.87-gf1a3cc3 #3 Tainted: G O
-
swapper/0 is trying to acquire lock:
(port_lock_key){-.-...}, at: [c023e21c] uart_write+0x60/0xfc
but task is already holding lock:
(port_lock_key){-.-...}, at: [c0242830] serial8250_handle_irq+0x24/0x88
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(port_lock_key);
lock(port_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by swapper/0:
#0: ((i-lock)-rlock){-.-...}, at: [c0240f44]
serial8250_interrupt+0x2c/0xc0
#1: (port_lock_key){-.-...}, at: [c0242830] serial8250_handle_irq+0x24/0x88
stack backtrace:
[c0014234] (unwind_backtrace+0x0/0xec) from [c0398448]
(dump_stack+0x20/0x24)
[c0398448] (dump_stack+0x20/0x24) from [c006eebc]
(print_deadlock_bug+0xb4/0xe4)
[c006eebc] (print_deadlock_bug+0xb4/0xe4) from [c006f04c]
(check_deadlock.isra.20+0x160/0x18c)
[c006f04c] (check_deadlock.isra.20+0x160/0x18c) from [c0070890]
(validate_chain.isra.24+0x4a4/0x4f0)
[c0070890] (validate_chain.isra.24+0x4a4/0x4f0) from [c00715a0]
(__lock_acquire+0x670/0x740)
[c00715a0] (__lock_acquire+0x670/0x740) from [c0071cb0]
(lock_acquire+0x138/0x15c)
[c0071cb0] (lock_acquire+0x138/0x15c) from [c03a5904]
(_raw_spin_lock_irqsave+0x54/0x68)
[c03a5904] (_raw_spin_lock_irqsave+0x54/0x68) from [c023e21c]
(uart_write+0x60/0xfc)
[c023e21c] (uart_write+0x60/0xfc) from [bf0716d8]
(hci_uart_tx_wakeup+0x9c/0x160 [hci_uart])
[bf0716d8] (hci_uart_tx_wakeup+0x9c/0x160 [hci_uart]) from [bf0717f4]
(hci_uart_tty_wakeup+0x58/0x5c [hci_uart])
[bf0717f4] (hci_uart_tty_wakeup+0x58/0x5c [hci_uart]) from [c02246ec]
(tty_wakeup+0x48/0x68)
[c02246ec] (tty_wakeup+0x48/0x68) from [c023efb0]
(uart_write_wakeup+0x2c/0x30)
[c023efb0] (uart_write_wakeup+0x2c/0x30) from [c0241d0c]
(serial8250_tx_chars+0xf0/0x140)
[c0241d0c] (serial8250_tx_chars+0xf0/0x140) from [c0242878]
(serial8250_handle_irq+0x6c/0x88)
[c0242878] (serial8250_handle_irq+0x6c/0x88) from [c02428c4]
(serial8250_default_handle_irq+0x30/0x34)
[c02428c4] (serial8250_default_handle_irq+0x30/0x34) from [c0240f5c]
(serial8250_interrupt+0x44/0xc0)
[c0240f5c] (serial8250_interrupt+0x44/0xc0) from [c0087c70]
(handle_irq_event_percpu+0xc4/0x2cc)
[c0087c70] (handle_irq_event_percpu+0xc4/0x2cc) from [c0087ec4]
(handle_irq_event+0x4c/0x6c)
[c0087ec4] (handle_irq_event+0x4c/0x6c) from [c008a368]
(handle_edge_irq+0x114/0x14c)
[c008a368] (handle_edge_irq+0x114/0x14c) from [c0087528]
(generic_handle_irq+0x40/0x54)
[c0087528] (generic_handle_irq+0x40/0x54) from [c01f1900]
(gpio_irq_handler+0x168/0x1ac)
[c01f1900] (gpio_irq_handler+0x168/0x1ac) from [c0087528]
(generic_handle_irq+0x40/0x54)
[c0087528] (generic_handle_irq+0x40/0x54) from [c000ed7c]
(handle_IRQ+0x70/0x94)
[c000ed7c] (handle_IRQ+0x70/0x94) from [c000877c]
(omap3_intc_handle_irq+0x64/0x78)
[c000877c] (omap3_intc_handle_irq+0x64/0x78) from [c000df44]
(__irq_svc+0x44/0x78)
---8---
Signed-off-by: Andreas Bießmann andr...@biessmann.de
Cc: Marcel Holtmann mar...@holtmann.org
Cc: Gustavo Padovan gust...@padovan.org
Cc: Johan Hedberg johan.hedb...@gmail.com
Cc: linux-blueto...@vger.kernel.org
---
It seems at least one other guy had the very same problem with another uart
(mpc52xx): http://www.spinics.net/lists/linux-rt-users/msg09246.html
I wonder, if my approach is right. It is runtime tested with 3.4.87 on our
board and work around the mentioned recursive locking. But I do not know, if
it should be fixed in another way.
If it is right, I'd work some more on it to get the fix mainline.
drivers/bluetooth/hci_ldisc.c | 49 -
drivers/bluetooth/hci_uart.h |2 ++
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index f1fbf4f..4da2f12 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -116,20 +116,37 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
return skb;
}
-int hci_uart_tx_wakeup(struct hci_uart *hu)
+static void hci_uart_tx_fill(unsigned long data)
{
- struct tty_struct *tty = hu-tty;
- struct hci_dev *hdev = hu-hdev;
+ struct hci_uart *hu = (struct hci_uart *)data;
+ struct tty_struct *tty;
+ struct hci_dev *hdev;
struct sk_buff *skb;
+ if (!hu) {
+ BT_DBG(%s: no hci_uart, __func__);
+ return;
+ }
+
+ tty = hu-tty
[PATCH 1/2] avr32: setup crt for early panic()
Before the CRT was (fully) set up in kernel_entry (bss cleared before in _start, but also not before jump to panic() in no_tag_table case). This patch fixes this up to have a fully working CRT when branching to panic() in no_tag_table. Signed-off-by: Andreas Bießmann Cc: Haavard Skinnemoen Cc: Hans-Christian Egtvedt --- arch/avr32/boot/u-boot/head.S | 30 +- arch/avr32/kernel/head.S | 20 2 files changed, 25 insertions(+), 25 deletions(-) diff --git a/arch/avr32/boot/u-boot/head.S b/arch/avr32/boot/u-boot/head.S index 4488fa2..d36d865 100644 --- a/arch/avr32/boot/u-boot/head.S +++ b/arch/avr32/boot/u-boot/head.S @@ -8,6 +8,8 @@ * published by the Free Software Foundation. */ #include +#include +#include /* * The kernel is loaded where we want it to be and all caches @@ -20,11 +22,6 @@ .section .init.text,"ax" .global _start _start: - /* Check if the boot loader actually provided a tag table */ - lddpc r0, magic_number - cp.wr12, r0 - brneno_tag_table - /* Initialize .bss */ lddpc r2, bss_start_addr lddpc r3, end_addr @@ -34,6 +31,25 @@ _start: cp r2, r3 brlo1b + /* Initialize status register */ + lddpc r0, init_sr + mtsrSYSREG_SR, r0 + + /* Set initial stack pointer */ + lddpc sp, stack_addr + sub sp, -THREAD_SIZE + +#ifdef CONFIG_FRAME_POINTER + /* Mark last stack frame */ + mov lr, 0 + mov r7, 0 +#endif + + /* Check if the boot loader actually provided a tag table */ + lddpc r0, magic_number + cp.wr12, r0 + brneno_tag_table + /* * Save the tag table address for later use. This must be done * _after_ .bss has been initialized... @@ -53,6 +69,10 @@ bss_start_addr: .long __bss_start end_addr: .long _end +init_sr: + .long 0x007f /* Supervisor mode, everything masked */ +stack_addr: + .long init_thread_union no_tag_table: sub r12, pc, (. - 2f) diff --git a/arch/avr32/kernel/head.S b/arch/avr32/kernel/head.S index 6163bd0..59eae6d 100644 --- a/arch/avr32/kernel/head.S +++ b/arch/avr32/kernel/head.S @@ -10,33 +10,13 @@ #include #include -#include -#include .section .init.text,"ax" .global kernel_entry kernel_entry: - /* Initialize status register */ - lddpc r0, init_sr - mtsrSYSREG_SR, r0 - - /* Set initial stack pointer */ - lddpc sp, stack_addr - sub sp, -THREAD_SIZE - -#ifdef CONFIG_FRAME_POINTER - /* Mark last stack frame */ - mov lr, 0 - mov r7, 0 -#endif - /* Start the show */ lddpc pc, kernel_start_addr .align 2 -init_sr: - .long 0x007f /* Supervisor mode, everything masked */ -stack_addr: - .long init_thread_union kernel_start_addr: .long start_kernel -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] avr32: fix out-of-range jump in large kernels
This patch fixes following error (for big kernels):
---8<---
arch/avr32/boot/u-boot/head.o: In function `no_tag_table':
(.init.text+0x44): relocation truncated to fit: R_AVR32_22H_PCREL against
symbol `panic' defined in .text.unlikely section in kernel/built-in.o
arch/avr32/kernel/built-in.o: In function `bad_return':
(.ex.text+0x236): relocation truncated to fit: R_AVR32_22H_PCREL against symbol
`panic' defined in .text.unlikely section in kernel/built-in.o
--->8---
It comes up when the kernel increases and 'panic()' is too far away to fit in
the +/- 2MiB range. Which in turn issues from the 21-bit displacement in
'br{cond4}' mnemonic which is one of the two ways to do jumps (rjmp has just
10-bit displacement and therefore a way smaller range). This fact was stated
before in 8d29b7b9f81d6b83d869ff054e6c189d6da73f1f.
One solution to solve this is to add a local storage for the symbol address
and just load the $pc with that value.
Signed-off-by: Andreas Bießmann
Cc: Haavard Skinnemoen
Cc: Hans-Christian Egtvedt
---
arch/avr32/boot/u-boot/head.S|5 -
arch/avr32/kernel/entry-avr32b.S |3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/avr32/boot/u-boot/head.S b/arch/avr32/boot/u-boot/head.S
index d36d865..2ffc298 100644
--- a/arch/avr32/boot/u-boot/head.S
+++ b/arch/avr32/boot/u-boot/head.S
@@ -73,8 +73,11 @@ init_sr:
.long 0x007f /* Supervisor mode, everything masked */
stack_addr:
.long init_thread_union
+panic_addr:
+ .long panic
no_tag_table:
sub r12, pc, (. - 2f)
- bralpanic
+ /* branch to panic() which can be far away with that construct */
+ lddpc pc, panic_addr
2: .asciz "Boot loader didn't provide correct magic number\n"
diff --git a/arch/avr32/kernel/entry-avr32b.S b/arch/avr32/kernel/entry-avr32b.S
index 9899d3c..7301f48 100644
--- a/arch/avr32/kernel/entry-avr32b.S
+++ b/arch/avr32/kernel/entry-avr32b.S
@@ -401,9 +401,10 @@ handle_critical:
/* We should never get here... */
bad_return:
sub r12, pc, (. - 1f)
- bralpanic
+ lddpc pc, 2f
.align 2
1: .asciz "Return from critical exception!"
+2: .long panic
.align 1
do_bus_error_write:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] avr32: fix out-of-range jump in large kernels
This patch fixes following error (for big kernels):
---8---
arch/avr32/boot/u-boot/head.o: In function `no_tag_table':
(.init.text+0x44): relocation truncated to fit: R_AVR32_22H_PCREL against
symbol `panic' defined in .text.unlikely section in kernel/built-in.o
arch/avr32/kernel/built-in.o: In function `bad_return':
(.ex.text+0x236): relocation truncated to fit: R_AVR32_22H_PCREL against symbol
`panic' defined in .text.unlikely section in kernel/built-in.o
---8---
It comes up when the kernel increases and 'panic()' is too far away to fit in
the +/- 2MiB range. Which in turn issues from the 21-bit displacement in
'br{cond4}' mnemonic which is one of the two ways to do jumps (rjmp has just
10-bit displacement and therefore a way smaller range). This fact was stated
before in 8d29b7b9f81d6b83d869ff054e6c189d6da73f1f.
One solution to solve this is to add a local storage for the symbol address
and just load the $pc with that value.
Signed-off-by: Andreas Bießmann andr...@biessmann.de
Cc: Haavard Skinnemoen hskinnem...@gmail.com
Cc: Hans-Christian Egtvedt egtv...@samfundet.no
---
arch/avr32/boot/u-boot/head.S|5 -
arch/avr32/kernel/entry-avr32b.S |3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/avr32/boot/u-boot/head.S b/arch/avr32/boot/u-boot/head.S
index d36d865..2ffc298 100644
--- a/arch/avr32/boot/u-boot/head.S
+++ b/arch/avr32/boot/u-boot/head.S
@@ -73,8 +73,11 @@ init_sr:
.long 0x007f /* Supervisor mode, everything masked */
stack_addr:
.long init_thread_union
+panic_addr:
+ .long panic
no_tag_table:
sub r12, pc, (. - 2f)
- bralpanic
+ /* branch to panic() which can be far away with that construct */
+ lddpc pc, panic_addr
2: .asciz Boot loader didn't provide correct magic number\n
diff --git a/arch/avr32/kernel/entry-avr32b.S b/arch/avr32/kernel/entry-avr32b.S
index 9899d3c..7301f48 100644
--- a/arch/avr32/kernel/entry-avr32b.S
+++ b/arch/avr32/kernel/entry-avr32b.S
@@ -401,9 +401,10 @@ handle_critical:
/* We should never get here... */
bad_return:
sub r12, pc, (. - 1f)
- bralpanic
+ lddpc pc, 2f
.align 2
1: .asciz Return from critical exception!
+2: .long panic
.align 1
do_bus_error_write:
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] avr32: setup crt for early panic()
Before the CRT was (fully) set up in kernel_entry (bss cleared before in _start, but also not before jump to panic() in no_tag_table case). This patch fixes this up to have a fully working CRT when branching to panic() in no_tag_table. Signed-off-by: Andreas Bießmann andr...@biessmann.de Cc: Haavard Skinnemoen hskinnem...@gmail.com Cc: Hans-Christian Egtvedt egtv...@samfundet.no --- arch/avr32/boot/u-boot/head.S | 30 +- arch/avr32/kernel/head.S | 20 2 files changed, 25 insertions(+), 25 deletions(-) diff --git a/arch/avr32/boot/u-boot/head.S b/arch/avr32/boot/u-boot/head.S index 4488fa2..d36d865 100644 --- a/arch/avr32/boot/u-boot/head.S +++ b/arch/avr32/boot/u-boot/head.S @@ -8,6 +8,8 @@ * published by the Free Software Foundation. */ #include asm/setup.h +#include asm/thread_info.h +#include asm/sysreg.h /* * The kernel is loaded where we want it to be and all caches @@ -20,11 +22,6 @@ .section .init.text,ax .global _start _start: - /* Check if the boot loader actually provided a tag table */ - lddpc r0, magic_number - cp.wr12, r0 - brneno_tag_table - /* Initialize .bss */ lddpc r2, bss_start_addr lddpc r3, end_addr @@ -34,6 +31,25 @@ _start: cp r2, r3 brlo1b + /* Initialize status register */ + lddpc r0, init_sr + mtsrSYSREG_SR, r0 + + /* Set initial stack pointer */ + lddpc sp, stack_addr + sub sp, -THREAD_SIZE + +#ifdef CONFIG_FRAME_POINTER + /* Mark last stack frame */ + mov lr, 0 + mov r7, 0 +#endif + + /* Check if the boot loader actually provided a tag table */ + lddpc r0, magic_number + cp.wr12, r0 + brneno_tag_table + /* * Save the tag table address for later use. This must be done * _after_ .bss has been initialized... @@ -53,6 +69,10 @@ bss_start_addr: .long __bss_start end_addr: .long _end +init_sr: + .long 0x007f /* Supervisor mode, everything masked */ +stack_addr: + .long init_thread_union no_tag_table: sub r12, pc, (. - 2f) diff --git a/arch/avr32/kernel/head.S b/arch/avr32/kernel/head.S index 6163bd0..59eae6d 100644 --- a/arch/avr32/kernel/head.S +++ b/arch/avr32/kernel/head.S @@ -10,33 +10,13 @@ #include linux/linkage.h #include asm/page.h -#include asm/thread_info.h -#include asm/sysreg.h .section .init.text,ax .global kernel_entry kernel_entry: - /* Initialize status register */ - lddpc r0, init_sr - mtsrSYSREG_SR, r0 - - /* Set initial stack pointer */ - lddpc sp, stack_addr - sub sp, -THREAD_SIZE - -#ifdef CONFIG_FRAME_POINTER - /* Mark last stack frame */ - mov lr, 0 - mov r7, 0 -#endif - /* Start the show */ lddpc pc, kernel_start_addr .align 2 -init_sr: - .long 0x007f /* Supervisor mode, everything masked */ -stack_addr: - .long init_thread_union kernel_start_addr: .long start_kernel -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH v2] register_console: prevent adding the same console twice
This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0->next->con1->next->NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0->next->con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by: Andreas Bießmann Cc: Greg Kroah-Hartman Cc: Kay Sievers Cc: Ben Hutchings Cc: sta...@vger.kernel.org --- since v1: * use WARN() as Ben suggested * print 'already registered' instead of 'prevent registering' kernel/printk/printk.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 5b5a708..b4e8500 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2226,6 +2226,13 @@ void register_console(struct console *newcon) struct console *bcon = NULL; struct console_cmdline *c; + if (console_drivers) + for_each_console(bcon) + if (WARN(bcon == newcon, + "console '%s%d' already registered\n", + bcon->name, bcon->index)) + return; + /* * before we register a new CON_BOOT console, make sure we don't * already have a valid console -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH v2] register_console: prevent adding the same console twice
This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0-next-con1-next-NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0-next-con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by: Andreas Bießmann andr...@biessmann.de Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Kay Sievers k...@vrfy.org Cc: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- since v1: * use WARN() as Ben suggested * print 'already registered' instead of 'prevent registering' kernel/printk/printk.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 5b5a708..b4e8500 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2226,6 +2226,13 @@ void register_console(struct console *newcon) struct console *bcon = NULL; struct console_cmdline *c; + if (console_drivers) + for_each_console(bcon) + if (WARN(bcon == newcon, + console '%s%d' already registered\n, + bcon-name, bcon-index)) + return; + /* * before we register a new CON_BOOT console, make sure we don't * already have a valid console -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] register_console: prevent adding the same console twice
ping? Am 2013-03-25 09:59, schrieb Andreas Bießmann: This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0->next->con1->next->NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0->next->con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by: Andreas Bießmann Cc: Greg Kroah-Hartman Cc: Kay Sievers Cc: Ben Hutchings Cc: sta...@kernel.org --- since v1: * use WARN() as Ben suggested * print 'already registered' instead of 'prevent registering' kernel/printk.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/printk.c b/kernel/printk.c index abbdd9e..180ee25 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -2214,6 +2214,13 @@ void register_console(struct console *newcon) unsigned long flags; struct console *bcon = NULL; + if (console_drivers) + for_each_console(bcon) + if (WARN(bcon == newcon, + "console '%s%d' already registered\n", + bcon->name, bcon->index)) + return; + /* * before we register a new CON_BOOT console, make sure we don't * already have a valid console -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] register_console: prevent adding the same console twice
ping? Am 2013-03-25 09:59, schrieb Andreas Bießmann: This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0-next-con1-next-NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0-next-con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by: Andreas Bießmann andr...@biessmann.de Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Kay Sievers k...@vrfy.org Cc: Ben Hutchings b...@decadent.org.uk Cc: sta...@kernel.org --- since v1: * use WARN() as Ben suggested * print 'already registered' instead of 'prevent registering' kernel/printk.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/printk.c b/kernel/printk.c index abbdd9e..180ee25 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -2214,6 +2214,13 @@ void register_console(struct console *newcon) unsigned long flags; struct console *bcon = NULL; + if (console_drivers) + for_each_console(bcon) + if (WARN(bcon == newcon, + console '%s%d' already registered\n, + bcon-name, bcon-index)) + return; + /* * before we register a new CON_BOOT console, make sure we don't * already have a valid console -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] register_console: prevent adding the same console twice
This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0->next->con1->next->NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0->next->con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by: Andreas Bießmann Cc: Greg Kroah-Hartman Cc: Kay Sievers Cc: Ben Hutchings Cc: sta...@kernel.org --- since v1: * use WARN() as Ben suggested * print 'already registered' instead of 'prevent registering' kernel/printk.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/printk.c b/kernel/printk.c index abbdd9e..180ee25 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -2214,6 +2214,13 @@ void register_console(struct console *newcon) unsigned long flags; struct console *bcon = NULL; + if (console_drivers) + for_each_console(bcon) + if (WARN(bcon == newcon, + "console '%s%d' already registered\n", + bcon->name, bcon->index)) + return; + /* * before we register a new CON_BOOT console, make sure we don't * already have a valid console -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] register_console: prevent adding the same console twice
This patch guards the console_drivers list to be corrupted. The for_each_console() macro insist on a strictly forward list ended by NULL: con0-next-con1-next-NULL Without this patch it may happen easily to destroy this list for example by adding 'earlyprintk' twice, especially on embedded devices where the early console is often a single static instance. This will result in the following list: con0-next-con0 This in turn will result in an endless loop in console_unlock() later on by printing the first __log_buf line endlessly. Signed-off-by: Andreas Bießmann andr...@biessmann.de Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Kay Sievers k...@vrfy.org Cc: Ben Hutchings b...@decadent.org.uk Cc: sta...@kernel.org --- since v1: * use WARN() as Ben suggested * print 'already registered' instead of 'prevent registering' kernel/printk.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/printk.c b/kernel/printk.c index abbdd9e..180ee25 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -2214,6 +2214,13 @@ void register_console(struct console *newcon) unsigned long flags; struct console *bcon = NULL; + if (console_drivers) + for_each_console(bcon) + if (WARN(bcon == newcon, + console '%s%d' already registered\n, + bcon-name, bcon-index)) + return; + /* * before we register a new CON_BOOT console, make sure we don't * already have a valid console -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] register_console: prevent adding the same console twice
This patch guards the console_drivers list to be corrupted. The
for_each_console() macro insist on a strictly forward list ended by NULL:
con0->next->con1->next->NULL
Without this patch it may happen easily to destroy this list for example by
adding 'earlyprintk' twice. This will result in the following list:
con0->next->con0
This in turn will result in an endless loop in console_unlock() later on by
printing the first __log_buf line endlessly.
Signed-off-by: Andreas Bießmann
Cc: Greg Kroah-Hartman
Cc: Kay Sievers
Cc: sta...@vger.kernel.org
---
kernel/printk.c |8
1 file changed, 8 insertions(+)
diff --git a/kernel/printk.c b/kernel/printk.c
index 0b31715..f78bfcd 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -2254,6 +2254,14 @@ void register_console(struct console *newcon)
unsigned long flags;
struct console *bcon = NULL;
+ if (console_drivers)
+ for_each_console(bcon)
+ if (bcon == newcon) {
+ pr_warn("prevent adding console '%s%d' twice\n",
+ newcon->name, newcon->index);
+ return;
+ }
+
/*
* before we register a new CON_BOOT console, make sure we don't
* already have a valid console
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] register_console: prevent adding the same console twice
This patch guards the console_drivers list to be corrupted. The
for_each_console() macro insist on a strictly forward list ended by NULL:
con0-next-con1-next-NULL
Without this patch it may happen easily to destroy this list for example by
adding 'earlyprintk' twice. This will result in the following list:
con0-next-con0
This in turn will result in an endless loop in console_unlock() later on by
printing the first __log_buf line endlessly.
Signed-off-by: Andreas Bießmann andr...@biessmann.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Kay Sievers k...@vrfy.org
Cc: sta...@vger.kernel.org
---
kernel/printk.c |8
1 file changed, 8 insertions(+)
diff --git a/kernel/printk.c b/kernel/printk.c
index 0b31715..f78bfcd 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -2254,6 +2254,14 @@ void register_console(struct console *newcon)
unsigned long flags;
struct console *bcon = NULL;
+ if (console_drivers)
+ for_each_console(bcon)
+ if (bcon == newcon) {
+ pr_warn(prevent adding console '%s%d' twice\n,
+ newcon-name, newcon-index);
+ return;
+ }
+
/*
* before we register a new CON_BOOT console, make sure we don't
* already have a valid console
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "serial: omap: fix software flow control"
On 16.10.2012 16:09, Felipe Balbi wrote: > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 > (serial: omap: fix software flow control). > > As Russell has pointed out, that commit isn't fixing > Software Flow Control at all, and it actually makes > it even more broken. > > It was agreed to revert this commit and use Russell's > latest UART patches instead. > > Cc: Russell King > Signed-off-by: Felipe Balbi since 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 made it into stable (at least 3.4) I think it would be good decision to also apply this revert to stable until a working solution exists. Best regards Andreas Bießmann > --- > > Hi Greg, > > you might prefer to do the revert yourself, in that case just > revert commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6. > > thanks > > arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++-- > drivers/tty/serial/omap-serial.c | 12 ++-- > 2 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h > b/arch/arm/plat-omap/include/plat/omap-serial.h > index f4a4cd0..1957a85 100644 > --- a/arch/arm/plat-omap/include/plat/omap-serial.h > +++ b/arch/arm/plat-omap/include/plat/omap-serial.h > @@ -40,10 +40,10 @@ > #define OMAP_UART_WER_MOD_WKUP 0X7F > > /* Enable XON/XOFF flow control on output */ > -#define OMAP_UART_SW_TX 0x8 > +#define OMAP_UART_SW_TX 0x04 > > /* Enable XON/XOFF flow control on input */ > -#define OMAP_UART_SW_RX 0x2 > +#define OMAP_UART_SW_RX 0x04 > > #define OMAP_UART_SYSC_RESET 0X07 > #define OMAP_UART_TCR_TRIG 0X0F > diff --git a/drivers/tty/serial/omap-serial.c > b/drivers/tty/serial/omap-serial.c > index 6ede6fd..6d3d26a 100644 > --- a/drivers/tty/serial/omap-serial.c > +++ b/drivers/tty/serial/omap-serial.c > @@ -671,19 +671,19 @@ serial_omap_configure_xonxoff > > /* >* IXON Flag: > - * Flow control for OMAP.TX > - * OMAP.RX should listen for XON/XOFF > + * Enable XON/XOFF flow control on output. > + * Transmit XON1, XOFF1 >*/ > if (termios->c_iflag & IXON) > - up->efr |= OMAP_UART_SW_RX; > + up->efr |= OMAP_UART_SW_TX; > > /* >* IXOFF Flag: > - * Flow control for OMAP.RX > - * OMAP.TX should send XON/XOFF > + * Enable XON/XOFF flow control on input. > + * Receiver compares XON1, XOFF1. >*/ > if (termios->c_iflag & IXOFF) > - up->efr |= OMAP_UART_SW_TX; > + up->efr |= OMAP_UART_SW_RX; > > serial_out(up, UART_EFR, up->efr | UART_EFR_ECB); > serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert serial: omap: fix software flow control
On 16.10.2012 16:09, Felipe Balbi wrote: This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 (serial: omap: fix software flow control). As Russell has pointed out, that commit isn't fixing Software Flow Control at all, and it actually makes it even more broken. It was agreed to revert this commit and use Russell's latest UART patches instead. Cc: Russell King li...@arm.linux.org.uk Signed-off-by: Felipe Balbi ba...@ti.com since 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 made it into stable (at least 3.4) I think it would be good decision to also apply this revert to stable until a working solution exists. Best regards Andreas Bießmann --- Hi Greg, you might prefer to do the revert yourself, in that case just revert commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6. thanks arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++-- drivers/tty/serial/omap-serial.c | 12 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index f4a4cd0..1957a85 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -40,10 +40,10 @@ #define OMAP_UART_WER_MOD_WKUP 0X7F /* Enable XON/XOFF flow control on output */ -#define OMAP_UART_SW_TX 0x8 +#define OMAP_UART_SW_TX 0x04 /* Enable XON/XOFF flow control on input */ -#define OMAP_UART_SW_RX 0x2 +#define OMAP_UART_SW_RX 0x04 #define OMAP_UART_SYSC_RESET 0X07 #define OMAP_UART_TCR_TRIG 0X0F diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6ede6fd..6d3d26a 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -671,19 +671,19 @@ serial_omap_configure_xonxoff /* * IXON Flag: - * Flow control for OMAP.TX - * OMAP.RX should listen for XON/XOFF + * Enable XON/XOFF flow control on output. + * Transmit XON1, XOFF1 */ if (termios-c_iflag IXON) - up-efr |= OMAP_UART_SW_RX; + up-efr |= OMAP_UART_SW_TX; /* * IXOFF Flag: - * Flow control for OMAP.RX - * OMAP.TX should send XON/XOFF + * Enable XON/XOFF flow control on input. + * Receiver compares XON1, XOFF1. */ if (termios-c_iflag IXOFF) - up-efr |= OMAP_UART_SW_TX; + up-efr |= OMAP_UART_SW_RX; serial_out(up, UART_EFR, up-efr | UART_EFR_ECB); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts/pnmtologo: fix for plain PBM
PBM generated with current tools do not have a whitespace between the digits.
Therefore the pnmtologo tool fails to gernerate the required C-Array for these
images. This patch fixes that behaviour and can handle both 'old style' and
'new style' PBM files.
Signed-off-by: Andreas Bießmann
---
scripts/pnmtologo.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 5c11312..66f8d7a 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -74,6 +74,7 @@ static unsigned int logo_height;
static struct color **logo_data;
static struct color logo_clut[MAX_LINUX_LOGO_COLORS];
static unsigned int logo_clutsize;
+static int is_plain_pbm = 0;
static void die(const char *fmt, ...)
__attribute__ ((noreturn)) __attribute ((format (printf, 1, 2)));
@@ -103,6 +104,11 @@ static unsigned int get_number(FILE *fp)
val = 0;
while (isdigit(c)) {
val = 10*val+c-'0';
+ /* some PBM are 'broken'; GiMP for example exports a PBM without space
+* between the digits. This is Ok cause we know a PBM can only have a
'1'
+* or a '0' for the digit. */
+ if (is_plain_pbm)
+ break;
c = fgetc(fp);
if (c == EOF)
die("%s: end of file\n", filename);
@@ -167,6 +173,7 @@ static void read_image(void)
switch (magic) {
case '1':
/* Plain PBM */
+ is_plain_pbm = 1;
for (i = 0; i < logo_height; i++)
for (j = 0; j < logo_width; j++)
logo_data[i][j].red = logo_data[i][j].green =
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scripts/pnmtologo: fix for plain PBM
PBM generated with current tools do not have a whitespace between the digits.
Therefore the pnmtologo tool fails to gernerate the required C-Array for these
images. This patch fixes that behaviour and can handle both 'old style' and
'new style' PBM files.
Signed-off-by: Andreas Bießmann andr...@biessmann.de
---
scripts/pnmtologo.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 5c11312..66f8d7a 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -74,6 +74,7 @@ static unsigned int logo_height;
static struct color **logo_data;
static struct color logo_clut[MAX_LINUX_LOGO_COLORS];
static unsigned int logo_clutsize;
+static int is_plain_pbm = 0;
static void die(const char *fmt, ...)
__attribute__ ((noreturn)) __attribute ((format (printf, 1, 2)));
@@ -103,6 +104,11 @@ static unsigned int get_number(FILE *fp)
val = 0;
while (isdigit(c)) {
val = 10*val+c-'0';
+ /* some PBM are 'broken'; GiMP for example exports a PBM without space
+* between the digits. This is Ok cause we know a PBM can only have a
'1'
+* or a '0' for the digit. */
+ if (is_plain_pbm)
+ break;
c = fgetc(fp);
if (c == EOF)
die(%s: end of file\n, filename);
@@ -167,6 +173,7 @@ static void read_image(void)
switch (magic) {
case '1':
/* Plain PBM */
+ is_plain_pbm = 1;
for (i = 0; i logo_height; i++)
for (j = 0; j logo_width; j++)
logo_data[i][j].red = logo_data[i][j].green =
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avr32: fix build error in atstk1006_defconfig
On 16.10.2012 11:17, Hans-Christian Egtvedt wrote:
> Around Tue 16 Oct 2012 15:19:27 +0800 or thereabout, Josh Wu wrote:
>> fixed the following compile error when use avr32 atstk1006_defconfig:
>> drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location':
>> drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function
>> 'writel_relaxed'
>>
>> which was introduced by commit 1c7b874d33b463 ("mtd: at91: atmel_nand: add
>> Programmable Multibit ECC controller support").
>> The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is
>> no macro "writel_relaxed" defined. This patch add writex_relaxed macro
>> definitions.
>>
>> Signed-off-by: Josh Wu
>> ---
>> arch/avr32/include/asm/io.h |4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
>> index cf60d0a..fc6483f 100644
>> --- a/arch/avr32/include/asm/io.h
>> +++ b/arch/avr32/include/asm/io.h
>> @@ -165,6 +165,10 @@ BUILDIO_IOPORT(l, u32)
>> #define readw_be__raw_readw
>> #define readl_be__raw_readl
>>
>> +#define writeb_relaxed writeb
>> +#define writew_relaxed writew
>> +#define writel_relaxed writel
>> +
>
> I'm wondering if they should be something similar to SH arch:
>
> #define writeb_relaxed(v,c) ((void)__raw_writeb((__force u8)ioswabb(v),c))
I think it is OK to just use the writeX here. These are in fact an
inlined function built out of a macro. The inlined function does nearly
what you have written down here and in contrast to the ARM version omits
the memory barrier.
The main difference between __raw_ access and the writeX/readX access
for AVR32 is this little __swizzle_addr_. It takes the configuration of
SMC (8/16/32 bit access) into account which would be omitted when we
switch to __raw_ accessors here. This would be a major change if one
used the writeX/readX accessors before and switched the SMC to something
different than 32 Bit access.
Best regards
Andreas Bießmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avr32: fix build error in atstk1006_defconfig
On 16.10.2012 11:17, Hans-Christian Egtvedt wrote: Around Tue 16 Oct 2012 15:19:27 +0800 or thereabout, Josh Wu wrote: fixed the following compile error when use avr32 atstk1006_defconfig: drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed' which was introduced by commit 1c7b874d33b463 (mtd: at91: atmel_nand: add Programmable Multibit ECC controller support). The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is no macro writel_relaxed defined. This patch add writex_relaxed macro definitions. Signed-off-by: Josh Wu josh...@atmel.com --- arch/avr32/include/asm/io.h |4 1 file changed, 4 insertions(+) diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h index cf60d0a..fc6483f 100644 --- a/arch/avr32/include/asm/io.h +++ b/arch/avr32/include/asm/io.h @@ -165,6 +165,10 @@ BUILDIO_IOPORT(l, u32) #define readw_be__raw_readw #define readl_be__raw_readl +#define writeb_relaxed writeb +#define writew_relaxed writew +#define writel_relaxed writel + I'm wondering if they should be something similar to SH arch: #define writeb_relaxed(v,c) ((void)__raw_writeb((__force u8)ioswabb(v),c)) I think it is OK to just use the writeX here. These are in fact an inlined function built out of a macro. The inlined function does nearly what you have written down here and in contrast to the ARM version omits the memory barrier. The main difference between __raw_ access and the writeX/readX access for AVR32 is this little __swizzle_addr_. It takes the configuration of SMC (8/16/32 bit access) into account which would be omitted when we switch to __raw_ accessors here. This would be a major change if one used the writeX/readX accessors before and switched the SMC to something different than 32 Bit access. Best regards Andreas Bießmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] fixes for omap2 nand driver
These two patches fixes the omap_nand_remove function to release all resources properly and be able to re-load the driver later on. Andreas Bießmann (2): mtd/nand/omap2: fix omap_nand_remove segfault mtd/nand/omap2: fix module loading drivers/mtd/nand/omap2.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mtd/nand/omap2: fix omap_nand_remove segfault
Do not kfree() the mtd_info, it is handled in the mtd subsystem and already freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in omap_nand_probe which was not kfree()ed before. This patch fixes following error when unloading the omap2 module: ---8<--- ~ $ rmmod omap2 [ cut here ] kernel BUG at mm/slab.c:3126! Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap2(-) CPU: 0Not tainted (3.6.0-rc3-00230-g155e36d-dirty #3) PC is at cache_free_debugcheck+0x2d4/0x36c LR is at kfree+0xc8/0x2ac pc : []lr : []psr: 200d0193 sp : c521fe08 ip : c0e8ef90 fp : c521fe5c r10: bf0001fc r9 : c521e000 r8 : c0d99c8c r7 : c661ebc0 r6 : c065d5a4 r5 : c65c4060 r4 : c78005c0 r3 : r2 : 1000 r1 : c65c4000 r0 : 0001 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 86694019 DAC: 0015 Process rmmod (pid: 549, stack limit = 0xc521e2f0) Stack: (0xc521fe08 to 0xc522) fe00: c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240 fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc fe40: c780ff40 a00d0113 c521e000 c521fe84 c521fe60 c0112efc c01122d8 fe60: c65c4860 c0673778 c06737ac 00070013 c521fe9c c521fe88 fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8 fec0: c02c8dd8 c02c8250 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8 fee0: c02c804c c02c8d20 bf001924 bf001ca8 c521e000 c521ff1c c521ff08 ff00: c02c950c c02c7fbc bf001d48 c521ff2c c521ff20 c02ca3a4 c02c94b8 ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930 ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 0081 60070010 ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88 ff80: c008e368 0001a004 70616d6f b6fe0032 0081 c0015028 c521ffa8 ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 0880 bec2ab38 0880 ffc0: 0001a004 70616d6f b6fe0032 0081 0319 b6fe1000 ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 Backtrace: [] (cache_free_debugcheck+0x0/0x36c) from [] (kfree+0xc8/0x2ac) [] (kfree+0x0/0x2ac) from [] (omap_nand_remove+0x5c/0x64 [omap2]) [] (omap_nand_remove+0x0/0x64 [omap2]) from [] (platform_drv_remove+0x28/0x2c) r5:bf001ca8 r4:c0673778 [] (platform_drv_remove+0x0/0x2c) from [] (__device_release_driver+0x80/0xdc) [] (__device_release_driver+0x0/0xdc) from [] (driver_detach+0xc4/0xc8) r5:bf001ca8 r4:c0673778 [] (driver_detach+0x0/0xc8) from [] (bus_remove_driver+0x9c/0x104) r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3: [] (bus_remove_driver+0x0/0x104) from [] (driver_unregister+0x60/0x80) r6:c521e000 r5:bf001ca8 r4: r3:bf001924 [] (driver_unregister+0x0/0x80) from [] (platform_driver_unregister+0x1c/0x20) r5: r4:bf001d48 [] (platform_driver_unregister+0x0/0x20) from [] (omap_nand_driver_exit+0x14/0x1c [omap2]) [] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [] (sys_delete_module+0x1f0/0x2ec) [] (sys_delete_module+0x0/0x2ec) from [] (ret_fast_syscall+0x0/0x48) r8:c0015028 r7:0081 r6:b6fe0032 r5:70616d6f r4:0001a004 Code: e1a5 eb0d9172 e7f001f2 e7f001f2 (e7f001f2) ---[ end trace 6a30b24d8c0cc2ee ]--- Segmentation fault --->8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann cc: linux-...@lists.infradead.org --- drivers/mtd/nand/omap2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index ac4fd75..4cd7ac0 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1387,7 +1387,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(>mtd); iounmap(info->nand.IO_ADDR_R); - kfree(>mtd); + kfree(info); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mtd/nand/omap2: fix module loading
Unloading the omap2 nand driver missed to release the memory region which will result in not being able to request it again if one want to load the driver later on. This patch fixes following error when loading omap2 module after unloading: ---8<--- ~ $ rmmod omap2 ~ $ modprobe omap2 [ 37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16 ~ $ --->8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann cc: linux-...@lists.infradead.org --- drivers/mtd/nand/omap2.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 4cd7ac0..48f1d4e 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1387,6 +1387,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(>mtd); iounmap(info->nand.IO_ADDR_R); + release_mem_region(info->phys_base, NAND_IO_SIZE); kfree(info); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mtd/nand/omap2: fix module loading
Unloading the omap2 nand driver missed to release the memory region which will result in not being able to request it again if one want to load the driver later on. This patch fixes following error when loading omap2 module after unloading: ---8--- ~ $ rmmod omap2 ~ $ modprobe omap2 [ 37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16 ~ $ ---8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann andr...@biessmann.de cc: linux-...@lists.infradead.org --- drivers/mtd/nand/omap2.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 4cd7ac0..48f1d4e 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1387,6 +1387,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(info-mtd); iounmap(info-nand.IO_ADDR_R); + release_mem_region(info-phys_base, NAND_IO_SIZE); kfree(info); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mtd/nand/omap2: fix omap_nand_remove segfault
Do not kfree() the mtd_info, it is handled in the mtd subsystem and already freed by nand_release(). Instead kfree() the struct omap_nand_info allocated in omap_nand_probe which was not kfree()ed before. This patch fixes following error when unloading the omap2 module: ---8--- ~ $ rmmod omap2 [ cut here ] kernel BUG at mm/slab.c:3126! Internal error: Oops - BUG: 0 [#1] PREEMPT ARM Modules linked in: omap2(-) CPU: 0Not tainted (3.6.0-rc3-00230-g155e36d-dirty #3) PC is at cache_free_debugcheck+0x2d4/0x36c LR is at kfree+0xc8/0x2ac pc : [c01125a0]lr : [c0112efc]psr: 200d0193 sp : c521fe08 ip : c0e8ef90 fp : c521fe5c r10: bf0001fc r9 : c521e000 r8 : c0d99c8c r7 : c661ebc0 r6 : c065d5a4 r5 : c65c4060 r4 : c78005c0 r3 : r2 : 1000 r1 : c65c4000 r0 : 0001 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 86694019 DAC: 0015 Process rmmod (pid: 549, stack limit = 0xc521e2f0) Stack: (0xc521fe08 to 0xc522) fe00: c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240 fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc fe40: c780ff40 a00d0113 c521e000 c521fe84 c521fe60 c0112efc c01122d8 fe60: c65c4860 c0673778 c06737ac 00070013 c521fe9c c521fe88 fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8 fec0: c02c8dd8 c02c8250 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8 fee0: c02c804c c02c8d20 bf001924 bf001ca8 c521e000 c521ff1c c521ff08 ff00: c02c950c c02c7fbc bf001d48 c521ff2c c521ff20 c02ca3a4 c02c94b8 ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930 ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 0081 60070010 ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88 ff80: c008e368 0001a004 70616d6f b6fe0032 0081 c0015028 c521ffa8 ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 0880 bec2ab38 0880 ffc0: 0001a004 70616d6f b6fe0032 0081 0319 b6fe1000 ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 Backtrace: [c01122cc] (cache_free_debugcheck+0x0/0x36c) from [c0112efc] (kfree+0xc8/0x2ac) [c0112e34] (kfree+0x0/0x2ac) from [bf0001fc] (omap_nand_remove+0x5c/0x64 [omap2]) [bf0001a0] (omap_nand_remove+0x0/0x64 [omap2]) from [c02ca11c] (platform_drv_remove+0x28/0x2c) r5:bf001ca8 r4:c0673778 [c02ca0f4] (platform_drv_remove+0x0/0x2c) from [c02c82c4] (__device_release_driver+0x80/0xdc) [c02c8244] (__device_release_driver+0x0/0xdc) from [c02c8dd8] (driver_detach+0xc4/0xc8) r5:bf001ca8 r4:c0673778 [c02c8d14] (driver_detach+0x0/0xc8) from [c02c804c] (bus_remove_driver+0x9c/0x104) r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3: [c02c7fb0] (bus_remove_driver+0x0/0x104) from [c02c950c] (driver_unregister+0x60/0x80) r6:c521e000 r5:bf001ca8 r4: r3:bf001924 [c02c94ac] (driver_unregister+0x0/0x80) from [c02ca3a4] (platform_driver_unregister+0x1c/0x20) r5: r4:bf001d48 [c02ca388] (platform_driver_unregister+0x0/0x20) from [bf001938] (omap_nand_driver_exit+0x14/0x1c [omap2]) [bf001924] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [c009beb4] (sys_delete_module+0x1f0/0x2ec) [c009bcc4] (sys_delete_module+0x0/0x2ec) from [c0014dc0] (ret_fast_syscall+0x0/0x48) r8:c0015028 r7:0081 r6:b6fe0032 r5:70616d6f r4:0001a004 Code: e1a5 eb0d9172 e7f001f2 e7f001f2 (e7f001f2) ---[ end trace 6a30b24d8c0cc2ee ]--- Segmentation fault ---8--- This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which was the first commit of this driver. Signed-off-by: Andreas Bießmann andr...@biessmann.de cc: linux-...@lists.infradead.org --- drivers/mtd/nand/omap2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index ac4fd75..4cd7ac0 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1387,7 +1387,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(info-mtd); iounmap(info-nand.IO_ADDR_R); - kfree(info-mtd); + kfree(info); return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] fixes for omap2 nand driver
These two patches fixes the omap_nand_remove function to release all resources properly and be able to re-load the driver later on. Andreas Bießmann (2): mtd/nand/omap2: fix omap_nand_remove segfault mtd/nand/omap2: fix module loading drivers/mtd/nand/omap2.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm:gemini: fix irq.c
ping On 29.06.12 22:44, Andreas Bießmann wrote: > On 06.06.12 13:22, Andreas Bießmann wrote: >> Commit 9f97da78bf018206fb623cd351d454af2f105fe0 moved disable_hlt() from >> arch/arm/include/asm/system.h to arch/arm/include/asm/system_misc.h but >> missed >> to change arch/arm/mach-gemini/irq.c. >> >> This patch fixes following error: >> >> ---8<--- >> arch/arm/mach-gemini/irq.c: In function 'gemini_init_irq': >> arch/arm/mach-gemini/irq.c:79:2: error: implicit declaration of function >> 'disable_hlt' [-Werror=implicit-function-declaration] >> --->8--- >> >> Signed-off-by: Andreas Bießmann >> cc: Hans Ulli Kroll >> cc: Russell King >> cc: linux-arm-ker...@lists.infradead.org >> --- >> Note: this is broken since 3.4 release, 3.3 is sane. > > ping > >> >> arch/arm/mach-gemini/irq.c |1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/mach-gemini/irq.c b/arch/arm/mach-gemini/irq.c >> index ca70e5f..020852d 100644 >> --- a/arch/arm/mach-gemini/irq.c >> +++ b/arch/arm/mach-gemini/irq.c >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include >> +#include >> #include >> >> #define IRQ_SOURCE(base_addr) (base_addr + 0x00) >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm:gemini: fix irq.c
ping On 29.06.12 22:44, Andreas Bießmann wrote: On 06.06.12 13:22, Andreas Bießmann wrote: Commit 9f97da78bf018206fb623cd351d454af2f105fe0 moved disable_hlt() from arch/arm/include/asm/system.h to arch/arm/include/asm/system_misc.h but missed to change arch/arm/mach-gemini/irq.c. This patch fixes following error: ---8--- arch/arm/mach-gemini/irq.c: In function 'gemini_init_irq': arch/arm/mach-gemini/irq.c:79:2: error: implicit declaration of function 'disable_hlt' [-Werror=implicit-function-declaration] ---8--- Signed-off-by: Andreas Bießmann andr...@biessmann.de cc: Hans Ulli Kroll ulli.kr...@googlemail.com cc: Russell King li...@arm.linux.org.uk cc: linux-arm-ker...@lists.infradead.org --- Note: this is broken since 3.4 release, 3.3 is sane. ping arch/arm/mach-gemini/irq.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-gemini/irq.c b/arch/arm/mach-gemini/irq.c index ca70e5f..020852d 100644 --- a/arch/arm/mach-gemini/irq.c +++ b/arch/arm/mach-gemini/irq.c @@ -17,6 +17,7 @@ #include linux/sched.h #include asm/irq.h #include asm/mach/irq.h +#include asm/system_misc.h #include mach/hardware.h #define IRQ_SOURCE(base_addr) (base_addr + 0x00) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
