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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
On 12/05/2013 06:13 PM, Tony Lindgren wrote: * Peter Meerwald pme...@pmeerw.net [131205 08:13]: I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! Hmm well both methods should work, but is there anything stopping us merging the module param patch to the mainline tree? We could do so, should I provide a proper patch? On the other hand I think this approach is a workaround to circumvent the MTD architecture flaws mostly needed in embedded systems where we control the whole environment. Should we really introduce this switch to the whole bunch of users working with mainline distros on their beagle style HW? I think the user space tool approach is more useful there. regards Andreas Bießmann signature.asc Description: OpenPGP digital signature
Re: OMAP3 NAND ECC selection
Hi Peter, On 12/05/2013 10:47 AM, Enric Balletbo Serra wrote: 2013/12/5 Peter Meerwald pme...@pmeerw.net: snip I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 Best regards Andreas Bießmann signature.asc Description: OpenPGP digital signature
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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
