summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-11-08ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()Paul Walmsley7-48/+85
Convert the OMAP2xxx APLL code to use omap2_cm_wait_module_ready(), and move the low-level CM register manipulation functions to mach-omap2/cm2xxx.c. The objectives here are to remove the dependency on the deprecated omap2_cm_wait_idlest() function in mach-omap2/prcm.c, so that code can be removed later; and move low-level register accesses to the CM IP block to the CM code, which will soon be moved into drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08ARM: OMAP2+: board files: use SoC-specific system restart functionsPaul Walmsley33-151/+46
Modify the board files to use the SoC-specific system restart functions. At this point it's possible to remove omap_prcm_restart() from mach-omap2/prcm.c. While removing the prototypes for the now-unused restart functions, clean up a few more obsolete prototypes in mach-omap2/clock.h. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08ARM: OMAP2+: PRCM: create SoC-specific chip restart functionsPaul Walmsley5-0/+147
Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific variants. These functions need to be able to save the reboot reason into the scratchpad RAM. This implies a dependency on both the PRM and SCM IP blocks, so they've been moved into their own file. This will eventually call functions in the PRM and SCM drivers, once those are created. Vaibhav Hiremath <hvaibhav@ti.com> identified an unused prototype in the first version of this patch - now removed. Tony Lindgren <tony@atomide.com> noted a compile problem with some RMK Kconfigs; resolved in this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Tony Lindgren <tony@atomide.com>
2012-11-08ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.cPaul Walmsley4-36/+70
Collect all of the virt_prcm_set-specific clocktype code into mach-omap2/clkt2xxx_virt_prcm_set.c. Remove its dependency on the 'sclk' and 'vclk' global variables. Those variables will be removed by subsequent patches. This is part of the process of cleaning up the OMAP2xxx clock code and preparing for the removal of the omap_prcm_restart() function. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08ARM: OMAP2xxx: clock: remove global 'dclk' variablePaul Walmsley6-14/+37
Remove the global 'dclk' variable, instead replacing it with a variable local to the dpllcore clock type C file. This removes some of the special-case code surrounding the OMAP2xxx clock init. This patch is a prerequisite for the removal of the omap_prcm_restart() code from arch/arm/mach-omap2/prcm.c. It also cleans up some special-case OMAP2xxx clock code in the process. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)Paul Walmsley4-0/+33
Add SoC reset functions into the PRM code. These functions are based on code from mach-omap2/prcm.c. They reset the SoC using the CORE DPLL reset method (as opposed to one of the other two or three chip reset methods). Adding them here will facilitate their removal from arch/arm/mach-omap2/prcm.c. (prcm.c is deprecated.) Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io codePaul Walmsley13-320/+112
Get rid of the mach-omap2/common.c globals by moving the global initialization for IP block addresses that must occur early into mach-omap2/io.c. In the process, remove the *_map_common_io*() and SoC-specific *set_globals* functions. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()Paul Walmsley2-13/+0
omap_prcm_get_reset_sources() is now unused; so, remove it. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
2012-11-08watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptrPaul Walmsley1-14/+12
Previously the OMAP watchdog driver used a non-standard way to report the chip reset source via the GETBOOTSTATUS ioctl. This patch converts the driver to use the standard WDIOF_* flags for this purpose. This patch may break existing userspace code that uses the existing non-standard data format returned by the OMAP watchdog driver's GETBOOTSTATUS ioctl. To fetch detailed reset source information, userspace code will need to retrieve it directly from the CGRM or PRM drivers when those are completed. Previously, to fetch the reset source, the driver either read a register outside the watchdog IP block (OMAP1), or called a function exported directly from arch/arm/mach-omap2. Both approaches are broken. This patch also converts the driver to use a platform_data function pointer. This approach is temporary, and is due to the lack of drivers for the OMAP16xx+ Clock Generation and Reset Management IP block and the OMAP2+ Power and Reset Management IP block. Once drivers are available for those IP blocks, the watchdog driver can be converted to call exported functions from those drivers directly. At that point, the platform_data function pointer can be removed. In the short term, this patch is needed to allow the PRM code to be removed from arch/arm/mach-omap2 (it is being moved to a driver). This version integrates a fix from Jon Hunter <jon-hunter@ti.com> that avoids a NULL pointer dereference in a DT-only boot, and integrates a patch commit message fix from Felipe Balbi <balbi@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Wim Van Sebroeck <wim@iguana.be> Acked-by: Wim Van Sebroeck <wim@iguana.be> [paul@pwsan.com: integrated pdata fix from Jon Hunter] Cc: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: integrated changelog fix from Felipe Balbi] Cc: Felipe Balbi <balbi@ti.com>
2012-10-30ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointerPaul Walmsley4-30/+90
The OMAP watchdog timer driver directly calls a function exported by code in arch/arm/mach-omap2. This is not good; it tightly couples this driver to the mach-omap2 integration code. Instead, add a temporary platform_data function pointer to abstract this function call. A subsequent patch will convert the watchdog driver to use this function pointer. This patch also moves the device creation code out of arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c. This is another step towards the removal of arch/arm/mach-omap2/devices.c. Cc: Wim Van Sebroeck <wim@iguana.be> Acked-by: Wim Van Sebroeck <wim@iguana.be> [paul@pwsan.com: skip wd_timer device creation when DT blob is present] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-10-30ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return typePaul Walmsley2-4/+5
An older version of the patch "ARM: OMAP1: create read_reset_sources() function (for initial use by watchdog)" was sent upstream, which used the wrong return type for the omap1_get_reset_sources() function. Fix it to return a u32, which is what the WDTIMER platform_data function pointer read_reset_sources() expects. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-10-27Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcmTony Lindgren7-17/+30
2012-10-27Merge tag 'omap-cleanup-fixes-a-for-3.8' of ↵Tony Lindgren3-12/+27
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-headers Several fixes for build failures and sparse warnings in the OMAP cleanup-headers branch. Intended for 3.8 cleanup. Basic build, boot, and PM test logs are available from here: http://www.pwsan.com/omap/testlogs/cleanup-headers-compile-fixes-3.8/20121026132711/ Due to underlying problems in v3.7-rc2, several tests fail. These failures are unrelated to these patches.
2012-10-26ARM: OMAP1: fix sparse warning added by commit ↵Paul Walmsley1-0/+1
4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3 Commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3 ("ARM: OMAP: Make plat/fpga.h local to arch/arm/plat-omap") results in a new warning from sparse: arch/arm/mach-omap1/fpga.c:147:6: warning: symbol 'omap1510_fpga_init_irq' was not declared. Should it be static? Fix by adding a missing include. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2012-10-26ARM: OMAP1: fix build breakage introduced by commit ↵Paul Walmsley1-0/+2
25c7d49ed48b4843da7dea56a81ae7f620211ee0 Commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0 ("ARM: OMAP: Make omap_device local to mach-omap2") broke an OMAP5912-only build here: arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_init': arch/arm/mach-omap1/pm_bus.c:69:2: error: implicit declaration of function 'cpu_class_is_omap1' make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1 Fix by adding a missing include. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2012-10-26ARM: OMAP2+: fix build breakage introduced by commit ↵Paul Walmsley1-12/+24
b7754452b3e27716347a528b47b0a1083af32520 Commit b7754452b3e27716347a528b47b0a1083af32520 ("mtd: onenand: omap: use pdata info instead of cpu_is") broke an OMAP3+4 build and an N800 multi-OMAP2xxx build here: drivers/built-in.o: In function `omap2_onenand_probe': drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram' drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram' drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram' drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram' ... drivers/built-in.o: In function `omap2_onenand_probe': drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_read_bufferram' drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_write_bufferram' Fix by declaring static functions for the missing symbols, rather than just prototypes. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Afzal Mohammed <afzal@ti.com> Cc: Tony Lindgren <tony@atomide.com>
2012-10-25Merge branch 'omap-for-v3.8/cleanup-headers-menelaus' into ↵Tony Lindgren4-5/+3
omap-for-v3.8/cleanup-headers Conflicts: arch/arm/mach-omap2/board-h4.c arch/arm/mach-omap2/board-n8x0.c
2012-10-25Merge tag 'omap-cleanup-a-for-3.8' of ↵Tony Lindgren49-2099/+2750
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-prcm The first set of OMAP PRM/CM-related cleanup patches for 3.8. Prepares for the future move of the PRM/CM code to drivers/. Also includes some prcm.[ch] cleanup patches from the WDTIMER cleanup series that don't need external acks. Basic test logs for this branch on top of v3.7-rc2 are here: http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/ But due to the number of unrelated regressions present in v3.7-rc[12], it's not particularly usable as a testing base. With reverts, fixes, and workarounds applied as documented in: http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt the following test logs were obtained: http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/ which indicate that the series tests cleanly. Conflicts: arch/arm/mach-omap2/Makefile arch/arm/mach-omap2/clockdomain2xxx_3xxx.c arch/arm/mach-omap2/pm24xx.c
2012-10-25Merge branch 'omap-for-v3.8/cleanup-headers-usb' into ↵Tony Lindgren42-237/+201
omap-for-v3.8/cleanup-headers Conflicts: arch/arm/mach-omap1/clock.c arch/arm/mach-omap2/board-2430sdp.c arch/arm/mach-omap2/board-4430sdp.c arch/arm/mach-omap2/board-cm-t35.c arch/arm/mach-omap2/board-igep0020.c arch/arm/mach-omap2/board-ldp.c arch/arm/mach-omap2/board-omap3beagle.c arch/arm/mach-omap2/board-omap3logic.c arch/arm/mach-omap2/board-omap4panda.c arch/arm/mach-omap2/board-overo.c arch/arm/mach-omap2/board-rm680.c arch/arm/mach-omap2/board-rx51.c arch/arm/mach-omap2/twl-common.c arch/arm/mach-omap2/usb-host.c arch/arm/mach-omap2/usb-musb.c
2012-10-25ARM: OMAP: move OMAP USB platform data to <linux/platform_data/omap-usb.h>Felipe Balbi17-30/+48
In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to <linux/platform_data/omap-usb.h> and add a minimal drivers/mfd/usb-omap.h. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Partha Basak <parthab@india.ti.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Felipe Balbi <balbi@ti.com> [tony@atomide.com: updated for local mfd/usb-omap.h] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-25ARM: OMAP2+: Introduce local usb.hTony Lindgren32-136/+88
Let's move what we can from plat/usb.h to the local usb.h for ARM common zImage support. This is needed so we can remove plat/usb.h for ARM common zImage support. Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Partha Basak <parthab@india.ti.com> Cc: Keshava Munegowda <keshava_mgowda@ti.com> Cc: linux-usb@vger.kernel.org Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-25ARM: OMAP: Split plat/serial.h for omap1 and omap2+Tony Lindgren17-29/+64
For omap1, we'll keep mach/serial.h around for 8250.c hardware workarounds. For omap2+, we no longer need mach/serial.h and can make it local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-25ARM: OMAP: Split uncompress.h to mach-omap1 and mach-omap2Tony Lindgren3-208/+292
This allows us to eventually move omap2+ to generic debug code that's configured in Kconfig for the port. Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-25Merge tag 'omap-for-v3.8/cleanup-headers-signed' into ↵Tony Lindgren258-3852/+4348
omap-for-v3.8/cleanup-headers-serial-take2 This is the first set of omap cleanup patches for v3.8 merge window to remove most of the remaining plat includes to get us closer to ARM common zImage support. To avoid a huge amount of trivial merge conflicts with includes, this branch is based on several small topic branches coordinated with the driver subsystem maintainers. These branches are based on v3.7-rc1 and can also be merged into the related driver subsystem branches as needed: omap-for-v3.8/cleanup-headers-prepare few trivial driver changes omap-for-v3.8/cleanup-headers-dma move of the DMA header omap-for-v3.8/cleanup-headers-gpmc GPMC and MTD changes omap-for-v3.8/cleanup-headers-mmc MMC related changes omap-for-v3.8/cleanup-headers-dss DSS related changes omap-for-v3.8/cleanup-headers-asoc ASoC related changes Note that for the dma-omap.h, it was decided that it should be is completed. For the related discussion, please see: https://patchwork.kernel.org/patch/1519591/# After these patches we still have a few plat headers remaining that will be handled in later pull requests.
2012-10-24tty/serial/8250: Make omap hardware workarounds local to 8250.hTony Lindgren3-15/+39
This allows us to get rid of the ifdefs in 8250.c. Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24serial/8250/8250_early: Prevent rounding error in uartclkAlexey Brodkin1-1/+1
Modify divisor to select the nearest baud rate divider rather than the lowest. It minimizes baud rate errors especially on low UART clock frequencies. For example, if uartclk is 33000000 and baud is 115200 the ratio is about 17.9 The current code selects 17 (5% error) but should select 18 (0.5% error). This 5% error in baud rate leads to garbage on receiving end, while 0.5% doesn't. The issue showed up when using the stock 8250 driver for Synopsys DW UART. This was on a FPGA with ~12MHz UART clock. When we enabled early serial, we saw garbage which was narrowed down to the rounding error. So the bug had been latent and it only showed up with such low clock rates. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24serial: samsung: use clk_prepare_enable and clk_disable_unprepareThomas Abraham1-8/+8
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24TTY: Report warning when low_latency flag is wrongly usedIvo Sieben1-0/+1
When a driver has the low_latency flag set and uses the schedule_flip() function to initiate copying data to the line discipline, a workqueue is scheduled in but never actually flushed. This is incorrect use of the low_latency flag (driver should not support the low_latency flag, or use the tty_flip_buffer_push() function instead). Make sure a warning is reported to catch incorrect use of the low_latency flag. This patch goes with: cee4ad1ed90a0959fc29f9d30a2526e5e9522cfa Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-24console: use might_sleep in console_lockDaniel Vetter1-1/+2
Instead of BUG_ON(in_interrupt()), since that doesn't check for all the newfangled stuff like preempt. Note that this is valid since the console_sem is essentially used like a real mutex with only two twists: - we allow trylock from hardirq context - across suspend/resume we lock the logical console_lock, but drop the semaphore protecting the locking state. Now that doesn't guarantee that no one is playing tricks in single-thread atomic contexts at suspend/resume/boot time, but - I couldn't find anything suspicious with some grepping, - might_sleep shouldn't die, - and I think the upside of catching more potential issues is worth the risk of getting a might_sleep backtrace that would have been save (and then dealing with that fallout). Cc: Dave Airlie <airlied@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move tty buffers to tty_portJiri Slaby8-63/+70
So this is it. The big step why we did all the work over the past kernel releases. Now everything is prepared, so nothing protects us from doing that big step. | | \ \ nnnn/^l | | | | \ / / | | | '-,.__ => \/ ,-` => | '-,.__ | O __.´´) ( .` | O __.´´) ~~~ ~~ `` ~~~ ~~ The buffers are now in the tty_port structure and we can start teaching the buffer helpers (insert char/string, flip etc.) to use tty_port instead of tty_struct all around. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: add port -> tty linkJiri Slaby3-0/+6
For that purpose we have to temporarily introduce a second tty back pointer into tty_port. It is because serial layer, and maybe others, still do not use tty_port_tty_set/get. So that we cannot set the tty_port->tty to NULL at will now. Yes, the fix would be to convert whole serial layer and all its users to tty_port_tty_set/get. However we are in the process of removing the need of tty in most of the call sites, so this would lead to a duplicated work. Instead we have now tty_port->itty (internal tty) which will be used only in flush_to_ldisc. For that one it is ensured that itty is valid wherever the work is run. IOW, the work is synchronously cancelled before we set itty to NULL and also before hangup is processed. After we need only tty_port and not tty_struct in most code, this shall be changed to tty_port_tty_set/get and itty removed completely. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: tty_buffer, cache pointer to tty->bufJiri Slaby1-56/+76
During the move of tty buffers from tty_struct to tty_port, we will need to switch all users of buf to tty->port->buf. There are many functions where this is accessed directly in their code many times. Cache the tty->buf pointer in such functions now and change only single lines in each function in the next patch. Not that it is convenient for the next patch, but the code is now also more readable. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move TTY_FLUSH* flags to tty_portJiri Slaby2-10/+13
They are only TTY buffers specific. And the buffers will go to tty_port in the next patches. So to remove the need to have both tty_port and tty_struct at some places, let us move the flags to tty_port. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: n_tty, propagate n_tty_dataJiri Slaby1-93/+78
In some funtions we need only n_tty_data, so pass it down directly in case tty is not needed there. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move ldisc data from tty_struct: locksJiri Slaby3-65/+73
atomic_write_lock is not n_tty specific, so move it up in the tty_struct. And since these are the last ones to move, remove also the comment saying there are some ldisc' members. There are none now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move ldisc data from tty_struct: read_* and echo_* and canon_* stuffJiri Slaby2-133/+137
All the ring-buffers... Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move ldisc data from tty_struct: bitmapsJiri Slaby2-26/+28
Here we move bitmaps and use DECLARE_BITMAP to declare them in the new structure. And instead of memset, we use bitmap_zero as it is more appropriate. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move ldisc data from tty_struct: simple membersJiri Slaby3-73/+93
Here we start moving all the n_tty related bits from tty_struct to the newly defined n_tty_data struct in n_tty proper. In this patch primitive members and bits are moved. The rest will be done per-partes in the next patches. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: n_tty, add ldisc data to n_ttyJiri Slaby1-1/+18
All n_tty related members from tty_struct will be moved here. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: audit, stop accessing tty->icountJiri Slaby3-11/+13
This is a private member of n_tty. Stop accessing it. Instead, take is as an argument. This is needed to allow clean switch of the private members to a separate private structure of n_tty. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: n_tty, remove bogus checksJiri Slaby1-12/+0
* BUG_ON(!tty) in n_tty_set_termios -- it cannot be called with tty == NULL. It is called from two call sites. First, from n_tty_open where we have a valid tty. Second, as ld->ops->set_termios from tty_set_termios. But there we have a valid tty too. * if (!tty) in n_tty_open -- why would the TTY layer call ldisc's open with an invalid TTY? No it indeed does not. All call sites have a tty and dereference that. * BUG_ON(!tty->read_buf) in n_tty_read -- this used to be a valid check. The ldisc handling was broken some time ago when I added the check to ensure everything is OK. It still can catch the case, but no later than we move the buffer to ldisc data. Then there will be no read_buf in tty_struct, i.e. nothing to check for. * if (!tty->read_buf) in n_tty_receive_buf -- this should never happen. All callers of ldisc->ops->receive_ops should hold a reference to an ldisc and close (which frees read_buf) cannot be called until the reference is dropped. * if (WARN_ON(!tty->read_buf)) in n_tty_read -- the same as in the previous case. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: n_tty, simplify read_buf+echo_buf allocationJiri Slaby1-18/+13
ldisc->open and close are called only once and cannot cross. So the tests in open and close are superfluous. Remove them. (But leave sets to NULL to ensure there is not a bug somewhere.) And when the tests are gone, handle properly failures in open. We leaked read_buf if allocation of echo_buf failed before. Now this is not the case anymore. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: hci_ldisc, remove invalid check in openJiri Slaby1-6/+1
hci_ldisc's open checks if tty_struct->disc_data is set. And if so it returns with an error. But nothing ensures disc_data to be NULL. And since ld->ops->open shall be called only once, we do not need the check at all. So remove it. Note that this is not an issue now, but n_tty will start using the disc_data pointer and this invalid 'if' would trigger then rendering TTYs over BT unusable. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Marcel Holtmann <marcel@holtmann.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: linux-bluetooth@vger.kernel.org Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: ldisc, wait for idle ldisc in releaseJiri Slaby1-0/+5
We reintroduced tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore tty_ldisc_wait_idle) and used in set_ldisc. Then we added it also to the hangup path in 92f6fa09bd453 (TTY: ldisc, do not close until there are readers). And we noted that there is one more path: ~ Before 65b770468e98 tty_ldisc_wait_idle was called also from ~ tty_ldisc_release. It is called from tty_release, so I don't think ~ we need to restore that one. Well, I was wrong. There might still be holders of an ldisc reference. Not from userspace, but drivers. If they take a reference and a user closes the device immediately after that, we have a problem. ldisc is halted and closed by TTY, but the driver still may call some ldisc's operation and cause a crash. So restore the tty_ldisc_wait_idle call also to the third location where it was before 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount). Now we should be safe with respect to the ldisc reference counting as all* tty_ldisc_close paths are safely called with reference count of one. * Not the one in tty_ldisc_setup's fail path. But that is called before the first open finishes. So userspace does not see it yet. Even thought the driver is given the TTY already via ->install, it should not take a reference to the ldisc yet. If some driver is to do this, we should put one tty_ldisc_wait_idle also in the setup. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: vt, fix paste_selection ldisc handlingJiri Slaby1-7/+2
There used to be a single tty_ldisc_ref_wait. But then, when a big-tty-mutex (BTM) was introduced, it has to be tty_ldisc_ref + tty_unlock + tty_ldisc_ref_wait + tty_lock. Later, BTM was removed from that path and tty_ldisc_ref + tty_ldisc_ref_wait remained there. But it makes no sense now. So leave there only tty_ldisc_ref_wait. And when we have a reference to an ldisc, actually use it in the loop. Otherwise it may be racy. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: move devpts kill to ptyJiri Slaby2-5/+9
Now that we have control over tty->driver_data in pty, we can just kill the /dev/pts/ in pty code too. Namely, in ->shutdown hook of tty. For pty, this is called only once, for whichever end is closed last. But we don't care, both driver_data are the inode as it used to be till now. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: devpts, document devpts inode operationsJiri Slaby1-0/+21
Add kernel-doc texts for some devpts functions, i.e. document them. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: devpts, do not set driver_dataJiri Slaby3-24/+16
The goal is to stop setting and using tty->driver_data in devpts code. It should be used solely by the driver's code, pty in this case. Now driver_data are managed only in the pty driver. devpts_pty_new is switched to accept what we used to dig out of tty_struct, i.e. device node number and index. This also removes a note about driver_data being set outside of the driver. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: devpts, return created inode from devpts_pty_newJiri Slaby3-12/+15
The goal is to stop setting and using tty->driver_data in devpts code. It should be used solely by the driver's code, pty in this case. For the cleanup of layering, we will need the inode created in devpts_pty_new to be stored into slave's driver_data. So we convert devpts_pty_new to return the inode or an ERR_PTR-encoded error in case of failure. The move of 'inode = new_inode(sb);' from declarators to the code is only cosmetical, but it makes the code easier to read. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-10-23TTY: devpts, don't care about TTY in devpts_get_ttyJiri Slaby3-10/+8
The goal is to stop setting and using tty->driver_data in devpts code. It should be used solely by the driver's code, pty in this case. First, here we remove TTY from devpts_get_tty and rename it to devpts_get_priv. Note we do not remove type safety, we just shift the [implicit] (void *) cast one layer up. index was unused in devpts_get_tty, so remove that from the prototype too. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>