01 Nov, 2012
6 commits
-
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:http://www.spinics.net/lists/linux-omap/msg80520.html
To fix this for the shared i2c.h, let's re-introduce
a minimal plat/i2c.h.Note that drivers must not use this header as it will
break build for omap2+ CONFIG_MULTIPLATFORM builds.Signed-off-by: Tony Lindgren
-
The common code should not have any omap1 or omap2+
specific code, and should not need to call the cpu_is_omap
macros.The only remaining user for cpu_is_omap macros is
omap_i2c_nr_ports(). Let's make those checks in
the omap specific implementation of omap_i2c_add_bus()
instead in order to remove cpu_is_omap usage from
the common code.Signed-off-by: Tony Lindgren
-
Let's make the omap2+ specific parts private to mach-omap2.
This leaves just a minimal shared code into plat-omap like
it should be.Signed-off-by: Tony Lindgren
-
Let's make the omap1 specific parts private to mach-omap1.
These should not be in the shared code.Signed-off-by: Tony Lindgren
-
This will allow us to separate out omap1 and omap2+ specific
code in the later patches.Signed-off-by: Tony Lindgren
-
Most of the defines are specific to omap1 and omap2+,
and should be in the local headers. Only minimal function
prototypes need to be shared.As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:http://www.spinics.net/lists/linux-omap/msg80520.html
So this patch re-adds a minimal plat/sram.h.
The new plat/sram.h must not be included from drivers,
that will break build for omap2+ CONFIG_MULTIPLATFORM.Note that this patch temporarily adds two more
relative includes; Those will be removed in the
following patch.Signed-off-by: Tony Lindgren
27 Oct, 2012
5 commits
-
Resolve the following sparse warnings:
arch/arm/mach-omap1/usb.c:304:12: warning: symbol 'omap1_usb0_init' was not declared. Should it be static?
arch/arm/mach-omap1/usb.c:412:12: warning: symbol 'omap1_usb1_init' was not declared. Should it be static?
arch/arm/mach-omap1/usb.c:478:12: warning: symbol 'omap1_usb2_init' was not declared. Should it be static?by declaring those functions as static.
Signed-off-by: Paul Walmsley
Cc: Tony Lindgren
Cc: Felipe Balbi
[tony@atomide.com: this was missed with plat/usb.h removal]
Signed-off-by: Tony Lindgren -
…ernel/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. -
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
Cc: Tony Lindgren -
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 1Fix by adding a missing include.
Signed-off-by: Paul Walmsley
Cc: Tony Lindgren -
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
Cc: Afzal Mohammed
Cc: Tony Lindgren
26 Oct, 2012
1 commit
-
Conflicts:
arch/arm/mach-omap2/board-h4.c
arch/arm/mach-omap2/board-n8x0.c
25 Oct, 2012
10 commits
-
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 -
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
and add a minimal drivers/mfd/usb-omap.h.Cc: Samuel Ortiz
Cc: Alan Stern
Cc: Greg Kroah-Hartman
Cc: Partha Basak
Cc: Keshava Munegowda
Cc: linux-usb@vger.kernel.org
Signed-off-by: Felipe Balbi
[tony@atomide.com: updated for local mfd/usb-omap.h]
Signed-off-by: Tony Lindgren -
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
Cc: Alan Stern
Cc: Greg Kroah-Hartman
Cc: Partha Basak
Cc: Keshava Munegowda
Cc: linux-usb@vger.kernel.org
Acked-by: Felipe Balbi
Signed-off-by: Tony Lindgren -
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
-
This allows us to eventually move omap2+ to generic
debug code that's configured in Kconfig for the port.Signed-off-by: Tony Lindgren
-
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 changesNote 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. -
This allows us to get rid of the ifdefs in 8250.c.
Cc: Alan Cox
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.Signed-off-by: Thomas Abraham
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
24 Oct, 2012
1 commit
-
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
Cc: Thomas Gleixner
Cc: Alan Cox
Cc: Peter Zijlstra
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman
23 Oct, 2012
17 commits
-
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
All the ring-buffers...
Signed-off-by: Jiri Slaby
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
All n_tty related members from tty_struct will be moved here.
Signed-off-by: Jiri Slaby
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
* 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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: linux-bluetooth@vger.kernel.org
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
