Allocate the temporary buffer needed for initialization of the console
keyboard maps (512 bytes, as NR_KEYS = 256) on the stack instead of
statically, to reduce kernel size.
add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-512 (-512)
function old new delta
temp_map 512 - -512
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
If CONFIG_HW_CONSOLE is not set:
drivers/built-in.o: In function `amikbd_probe':
amikbd.c:(.init.text+0x3e4e): undefined reference to `key_maps'
amikbd.c:(.init.text+0x3dd4): undefined reference to `key_maps'
To fix this, extract the initialization of the console keyboard maps
into amikbd_init_console_keymaps(), protected by #ifdef
CONFIG_HW_CONSOLE.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The missing error handling here is not especially harmful but static
checkers complain that "i" can be used uninitialized.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Let's initialize atomic_t variables keeping track of number of various
devices created so far with -1 in order to avoid extra subtraction
operation.
Signed-off-by: Aniroop Mathur <aniroop.mathur@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Nobody is interested at which index the chunk is. What's needed is
a pointer to the chunk. Remove unused chunk_id field as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Completely unnecessary since the ww_mutex used to reserve a buffer
can detect double reservations from the same thread anyway.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch adds an optional list_head parameter to ttm_eu_reserve_buffers.
If specified duplicates in the execbuf list are no longer reported as errors,
but moved to this list instead.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Check the that ring we are using for copies is functional
rather than the GFX ring. On newer asics we use the DMA
ring for bo moves.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Instead of struct clk, as this should be only used by providers.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
As it's only used internally, in drivers/clk/clk.c.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
As __clk_release could call kfree on clk and then we wouldn't have a safe way
of getting the module that owns the clock.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Fixes: fcb0ee6a3d ("clk: Implement clk_unregister")
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The of_node_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
The ->next pointer in struct device_node is a hanger-on from when it was
used to iterate over the whole tree by a particular device_type property
value. Those days are long over, but the fdt unflattening code still
uses it to put nodes in the unflattened tree into the same order as node
in the flat tree. By reworking the unflattening code to reverse the list
after unflattening all the children of a node, the pointer can be
dropped which gives a small amount of memory savings.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Acked-by: Frank Rowand <frank.rowand@sonymobile.com>
Cc: Gaurav Minocha <gaurav.minocha.os@gmail.com>
Support specifying console options (like with console=ttyXN,<options>)
by appending them to the stdout-path property after a separating ':'.
Example:
stdout-path = "uart0:115200";
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
[grant.likely: minor rework to shorten the diffstat]
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Update of_find_node_by_path():
1) Rename function to of_find_node_opts_by_path(), adding an optional
pointer argument. Provide a static inline wrapper version of
of_find_node_by_path() which calls the new function with NULL as
the optional argument.
2) Ignore any part of the path beyond and including the ':' separator.
3) Set the new provided pointer argument to the beginning of the string
following the ':' separator.
4: Add tests.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Add a global binding for the chosen node. Include a description of the
stdout-path, and an explicit statement on its extra options in the
context of a UART console.
Opening description stolen from www.devicetree.org, and part of the
remaining text provided by Mark Rutland.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
[grant.likely: remove reference to uart_parse_options]
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
XFS traditionally sends all buffer I/O completion work to a single
workqueue. This includes metadata buffer completion and log buffer
completion. The log buffer completion requires a high priority queue to
prevent stalls due to log forces getting stuck behind other queued work.
Rather than continue to prioritize all buffer I/O completion due to the
needs of log completion, split log buffer completion off to
m_log_workqueue and move the high priority flag from m_buf_workqueue to
m_log_workqueue.
Add a b_ioend_wq wq pointer to xfs_buf to allow completion workqueue
customization on a per-buffer basis. Initialize b_ioend_wq to
m_buf_workqueue by default in the generic buffer I/O submission path.
Finally, override the default wq with the high priority m_log_workqueue
in the log buffer I/O submission path.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The kernel compile doesn't turn on these checks by default, so it's
only when I do a kernel-user sync that I find that there are lots of
compiler warnings waiting to be fixed. Fix up these set-but-unused
warnings.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
These are currently considered private to libxfs, but they are
widely used by the userspace code to decode, walk and check
directory structures. Hence they really form part of the external
API and as such need to bemoved to xfs_dir2.h.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
These functions are needed in userspace for repair and mkfs to
do the right thing. Move them to libxfs so they can be easily
shared.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
There's a case in that code where it checks for a buffer match in a
transaction where the buffer is not marked done. i.e. trying to
catch a buffer we have locked in the transaction but have not
completed IO on.
The only way we can find a buffer that has not had IO completed on
it is if it had readahead issued on it, but we never do readahead on
buffers that we have already joined into a transaction. Hence this
condition cannot occur, and buffers locked and joined into a
transaction should always be marked done and not under IO.
Remove this code and re-order xfs_trans_read_buf_map() to remove
duplicated IO dispatch and error handling code.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
vn_active only ever gets decremented, so it has a very large
negative number. Make it track the inode count we currently have
allocated properly so we can easily track the size of the inode
cache via tools like PCP.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
xfs_bmse_merge() has a jump label for return that just returns the
error value. Convert all the code to just return the error directly
and use XFS_WANT_CORRUPTED_RETURN. This also allows the final call
to xfs_bmbt_update() to return directly.
Noticed while reviewing coccinelle return cleanup patches and
wondering why the same return pattern as in xfs_bmse_shift_one()
wasn't picked up by the checker pattern...
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs_bmse_shift_one() jumps around determining whether to shift or
merge, making the code flow difficult to follow. Clean it up and
use direct error returns (including XFS_WANT_CORRUPTED_RETURN) to
make the code flow better and be easier to read.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
After growing a filesystem, XFS can fail to allocate inodes even
though there is a large amount of space available in the filesystem
for inodes. The issue is caused by a nearly full allocation group
having enough free space in it to be considered for inode
allocation, but not enough contiguous free space to actually
allocation inodes. This situation results in successful selection
of the AG for allocation, then failure of the allocation resulting
in ENOSPC being reported to the caller.
It is caused by two possible issues. Firstly, we only consider the
lognest free extent and whether it would fit an inode chunk. If the
extent is not correctly aligned, then we can't allocate an inode
chunk in it regardless of the fact that it is large enough. This
tends to be a permanent error until space in the AG is freed.
The second issue is that we don't actually lock the AGI or AGF when
we are doing these checks, and so by the time we get to actually
allocating the inode chunk the space we thought we had in the AG may
have been allocated. This tends to be a spurious error as it
requires a race to trigger. Hence this case is ignored in this patch
as the reported problem is for permanent errors.
The first issue could be addressed by simply taking into account the
alignment when checking the longest extent. This, however, would
prevent allocation in AGs that have aligned, exact sized extents
free. However, this case should be fairly rare compared to the
number of allocations that occur near ENOSPC that would trigger this
condition.
Hence, when selecting the inode AG, take into account the inode
cluster alignment when checking the lognest free extent in the AG.
If we can't find any AGs with a contiguous free space large
enough to be aligned, drop the alignment addition and just try for
an AG that has enough contiguous free space available for an inode
chunk. This won't prevent issues from occurring, but should avoid
situations where other AGs have lots of free space but the selected
AG can't allocate due to alignment constraints.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
If extsize is set and new_last_fsb is larger than 32 bits, the
roundup to extsize will overflow the align variable. Instead,
combine alignments by rounding stripe size up to extsize.
Signed-off-by: Peter Watkins <treestem@gmail.com>
Reviewed-by: Nathaniel W. Turner <nate@houseofnate.net>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Pull i2c bugfixes from Wolfram Sang:
"A few driver bugfixes for 3.18"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: omap: fix i207 errata handling
i2c: designware: prevent early stop on TX FIFO empty
i2c: omap: fix NACK and Arbitration Lost irq handling
NVIDIA Tegra
- Use physical range for I/O mapping (Thierry Reding)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUf1W0AAoJEFmIoMA60/r8wIUP/iFJKucfHJUDo3i/R96vXYhv
/PEosMwQu2FnfLC13vOnUnx9m2uv2gpthhI255guxm3DUIsurOcdBGR7ZoaQcMkD
0NMf/UeGlKPFkXk5ltJiO4SHsAv8ITMV7pYcUl4DX0E288kBjM4LV69+aprKw7GY
ULZDDqIE5x6SkmBv5PopTr7M+Z6omQ+nxZ6txMAM3ks2+rku6SzqPaWZFhpTinqn
AJlx9gqjN8OLuPNXqHia+hBzPk9xvisCOZ0kOXpS3ipeXvyLVPThqhO1fG9RFY0a
BXK+l8E7z3zcwIZIQMsVl3zuxYVpjQhgNlPqFyYE+TCW/kG6V3STWzmYW/kCT0ax
ipVeSKXZnmcf7iKZ78UdW8bXZGHi6WNouaN0/NAtXh9Gln8P2qOuSBwv1H3374in
NnIFPr8bFNXgSr8OPZWIqhwQEdPZgydxq28DxIEZCdYo4idP3Q+yElQPpmZzBeeC
8rnFyHsBFdazr7W44jsPnn45Fdy2LEEo07v80buj/RwdwMV2zj2OFLUMT9Nlyu6k
p7HLM40FZlyeu+OHjzc0zu/GjQ5CAt4SV0DSQ/Gi80Bq1X+qHPVc7u6MoKmS0wYr
wZ2/DCXHloMRsITZ6fyPVNsUHB9S9M01V4VCnzCSeJ65ArvNeP5+7yzQKUIEKLQ9
FclPrRsT+jaJUWVpNLjE
=KWwE
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.18-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fix from Bjorn Helgaas:
"This fixes a Tegra20 regression that we introduced during the v3.18
merge window"
* tag 'pci-v3.18-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: tegra: Use physical range for I/O mapping
The initial reason for this patch is that I noticed that:
if (len > TRACE_BUF_SIZE)
is off by one. In this code, if len == TRACE_BUF_SIZE, then it means we
have truncated the last character off the output string. If we truncate
two or more characters then we exit without printing.
After some discussion, we decided that printing truncated data is better
than not printing at all so we should just use vscnprintf() and remove
the test entirely. Also I have updated memcpy() to copy the NUL char
instead of setting the NUL in a separate step.
Link: http://lkml.kernel.org/r/20141127155752.GA21914@mwanda
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Currently, function graph tracer prints "!" or "+" just before
function execution time to signal a function overhead, depending
on the time. And some tracers tracing latency also print "!" or
"+" just after time to signal overhead, depending on the interval
between events. Even it is usually enough to do that, we sometimes
need to signal for bigger execution time than 100 micro seconds.
For example, I used function graph tracer to detect if there is
any case that exit_mm() takes too much time. I did following steps
in /sys/kernel/debug/tracing. It was easier to detect very large
excution time with patched kernel than with original kernel.
$ echo exit_mm > set_graph_function
$ echo function_graph > current_tracer
$ echo > trace
$ cat trace_pipe > $LOGFILE
... (do something and terminate logging)
$ grep "\\$" $LOGFILE
3) $ 22082032 us | } /* kernel_map_pages */
3) $ 22082040 us | } /* free_pages_prepare */
3) $ 22082113 us | } /* free_hot_cold_page */
3) $ 22083455 us | } /* free_hot_cold_page_list */
3) $ 22083895 us | } /* release_pages */
3) $ 22177873 us | } /* free_pages_and_swap_cache */
3) $ 22178929 us | } /* unmap_single_vma */
3) $ 22198885 us | } /* unmap_vmas */
3) $ 22206949 us | } /* exit_mmap */
3) $ 22207659 us | } /* mmput */
3) $ 22207793 us | } /* exit_mm */
And then, it was easy to find out that a schedule-out occured by
sub_preempt_count() within kernel_map_pages().
To detect very large function exection time caused by either problematic
function implementation or scheduling issues, this patch can be useful.
Link: http://lkml.kernel.org/r/1416789259-24038-1-git-send-email-byungchul.park@lge.com
Signed-off-by: Byungchul Park <byungchul.park@lge.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I'm stuck into panic that too litte free memory is left when I boot with
trace_buf_size parameter. After digging into the problem, I found that
trace_buf_size is the size of trace buffer on each cpu rather than total
size of trace buffer. To prevent victim like me, change description of
trace_buf_size parameter more accurately.
Link: http://lkml.kernel.org/r/1417570760-10620-1-git-send-email-iamjoonsoo.kim@lge.com
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Single bugfix for boot failure seen in the wild. The memory reserve code
tries to be clever about reserving the FDT, but it should just go ahead
and reserve it unconditionally to avoid the problem of partial overlap
described in the patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUea8yAAoJEMWQL496c2LN6UEP+wdAz7Qi4qSLmWyQD1Jf2U1t
VoXqAx4y8ptvwflXvxZkiM4/ikty+2/cU3plo3MToN8/UroWG94COZmF8K7dD9mw
W8aQFutoNT4zsvHN8i2t+SNYat+wCn1W9qfCou4k9vE+NWKEsbcrmHiLkPfAl4PE
ayrpEPGKvgh4wN1GlPiM6upnTIbJHPsG2VOvBF+7aqC4X/nTqXq/OzMZLfU4Cil2
pzeuYxxksr/tuPobPhhu1xW5vzdsY8ksdsnCI42xL/ZGAM0mMKEg0kBSwKNWvAj+
1JHiewzf035ZaHh/VJb5hu6wn29+w9xoKs9U+TSbCBfSY2giiI4bgNhxlQZUROR5
eiIffSdsJhGv5lsrFP18UAyPWoo4mVuH3RwT5u5D7z1m3BENS8Zv38WEzJKvVvdX
vPiQCKJX0S7i3XsJlwYmYGITb1eoROr4hxpcGl+tZATFGSdXKGDfNPD1kvT/N9HN
/kNW9JRCpXEl2gyqjovIXCHhLWYQrFncGIt7rIBhLVcvbjosEIYGbHrYDEgaVtcv
zH649JBQppQFqrtN25lQXJ7WPqLJdwqm6zMb9s6ynrsDaqEKTc/usaQ1/EtIowF/
DBu+pwDiywjeWLHpx+5PuzGgOhYwFEvx3f1v9m9U/3pNhP3M7rcttcqGmpFS+LVO
dt5pQygvgLJOQUxgK7zI
=iysY
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux
Pull devicetree bugfix from Grant Likely:
"One more bug fix for v3.18. I debated whether or not to send you this
merge request because we're at such a late rc. The bug isn't critical
in that there is only one system known to be affected and the patch is
easy to backport. The codepath is used by pretty much every DT based
system, so there is risk a of regression (it /should/ be safe, but
I've been bitten by stuff that should be safe before). I've had it in
linux-next for a week and haven't received any complaints.
I think it probably should just be merged right away rather than
waiting for the merge window and backporting. It does fix a real bug
and the code is theoretically safer after the change. I can't think
of any situation where it would be dangerous to reserve the DT memory
an extra time.
Summary from tag:
Single bugfix for boot failure seen in the wild. The memory reserve
code tries to be clever about reserving the FDT, but it should just
go ahead and reserve it unconditionally to avoid the problem of
partial overlap described in the patch"
* tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux:
of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap
Pull block core regression fix from Jens Axboe:
"Single fix for a regression introduced in this development cycle,
where dm on top of dif/dix is broken. From Darrick Wong"
* 'for-linus' of git://git.kernel.dk/linux-block:
block: fix regression where bio_integrity_process uses wrong bio_vec iterator
Pull drm fixes from Dave Airlie:
"Radeon and Nouveau fixes:
So nouveau had a few regression introduced, Ben and Maarten finally
tracked down the one that was causing problems on my MacBookPro, also
nvidia gave some info on the an engine we were using incorrectly, so
disable our use of it, and one regresion with pci hotplug affecting
optimus users.
Radeon has an oops fixs, sync fix, and one workaround to avoid broken
functionality on 32-bit x86, this needs better root causing and a
better fix, but the bandaid is a lot safer at this point"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6
drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86
drm/radeon: sync all BOs involved in a CS v2
nouveau: move the hotplug ignore to correct place.
drm/nouveau/gf116: remove copy1 engine
drm/nouveau: prevent stale fence->channel pointers, and protect with rcu
drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it
Pull networking fixes from David Miller:
1) Fill in ethtool link parameters for all link types in cxgb4, from
Hariprasad Shenai.
2) Fix probe regressions in stmmac driver, from Huacai Chen.
3) Network namespace leaks on errirs in rtnetlink, from Nicolas
Dichtel.
4) Remove erroneous BUG check which can actually trigger legitimately,
in xen-netfront. From Seth Forshee.
5) Validate length of IFLA_BOND_ARP_IP_TARGET netlink attributes, from
Thomas Grag.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
cxgb4: Fill in supported link mode for SFP modules
xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
sh_eth: Fix sleeping function called from invalid context
stmmac: platform: Move plat_dat checking earlier
sh_eth: Fix skb alloc size and alignment adjust rule.
rtnetlink: release net refcnt on error in do_setlink()
bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes
This patch increments the management interface revision due to the
addition of support for LE Secure Connection feature.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the addition of support for Bluetooth Low Energy Secure Connections
feature, it makes sense to increase the minor version of the Bluetooth
core module.
The module version is not used anywhere, but it gives a nice extra
hint for debugging purposes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Currently, all restart handler use the priority 128, including
watchdogs. Probably most SoC have a watchdog, and some of them
register it also as a restart handler. But if a SoC specifies
a dedicated reboot capability using this syscon driver, this is
usually the preferred reboot method. Hence, raise the priority
of this driver to 192.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Move the pointer declarations into the blocks that use them.
Neaten the kfree calls when the _init functions fail.
Trivially reduces object size (defconfig x86-64)
$ size sound/pci/ctxfi/ctdaio.o.*
text data bss dec hex filename
5287 224 0 5511 1587 sound/pci/ctxfi/ctdaio.o.new
5319 224 0 5543 15a7 sound/pci/ctxfi/ctdaio.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Noticed-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since we are now preserving the cursor across modesets, the cursor could
be left over in console if e.g. X crashed.
v2: add comment about universal plane support
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stop using the VM mutex for this
v2: fix typo in comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The BO_VA contains everything necessary.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Better match what it is actually doing.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's only used for duplicate check and that
can be done on the original as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's only used once after initializing and that
ptr can be calculated from the BO as well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
