[ Upstream commit 987aa5f8059613bf85cbb6f64ffbd34f5cb7a9d1 ]
with CONFIG_HZ=100, the precision of jiffies is 10ms, and the
generic_cmd6_time of some card is also 10ms. then, may be current
time is only 5ms, but already timed out caused by jiffies precision.
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ace6033ec5c356615eaa3582fb1946e9eaff6662 ]
User space Android code identifies pixclock == 0 as a sign for emulation
and will set the frame rate to 60 fps when reading this value, which is
the desired outcome.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Roman Kiryanov <rkir@google.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 812264550dcba6cdbe84bfac2f27e7d23b5b8733 ]
page.h uses '_AC' in the definition of PAGE_SIZE, but doesn't include
linux/const.h where this is defined. This produces build warnings when only
asm/page.h is included by asm code.
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4532150762ceb0d6fd765ebcb3ba6966fbb8faab ]
We do actually need slab.h, by luck we get it on other platforms but not
always on ARM. Include it properly.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Jin Qian <jinqian@android.com>
Signed-off-by: Alan <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1328d8efef17d5e16bd6e9cfe59130a833674534 ]
In carveout heap, change minimum allocation order from 12 to
PAGE_SHIFT. After this change each bit in bitmap (genalloc -
General purpose special memory pool) represents one page size
memory.
Cc: sprd-ind-kernel-group@googlegroups.com
Cc: sanjeev.yadav@spreadtrum.com
Cc: Colin Cross <ccross@android.com>
Cc: Android Kernel Team <kernel-team@android.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Rajmal Menariya <rajmal.menariya@spreadtrum.com>
[jstultz: Reworked commit message]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3694bd76781b76c4f8d2ecd85018feeb1609f0e5 ]
Currently __set_fixmap_offset is a macro function which has a local
variable called 'addr'. If a caller passes a 'phys' parameter which is
derived from a variable also called 'addr', the local variable will
shadow this, and the compiler will complain about the use of an
uninitialized variable. To avoid the issue with namespace clashes,
'addr' is prefixed with a liberal sprinkling of underscores.
Turning __set_fixmap_offset into a static inline breaks the build for
several architectures. Fixing this properly requires updates to a number
of architectures to make them agree on the prototype of __set_fixmap (it
could be done as a subsequent patch series).
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
[catalin.marinas@arm.com: squashed the original function patch and macro fixup]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b9b7aebb42d1b1392f3111de61136bb6cf3aae3f ]
ARM glibc uses (4 * __getpagesize()) for SHMLBA, which is correct for
4KB pages and works fine for 64KB pages, but the kernel uses a hardcoded
16KB that is too small for 64KB page based kernels. This changes the
definition to what user space sees when using 64KB pages.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7c9cbd0b5e38a1672fcd137894ace3b042dfbf69 upstream.
The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
as length value. The opt->len however is in control over the remote user
and can be used by an attacker to gain access beyond the bounds of the
actual packet.
To prevent any potential leak of heap memory, it is enough to check that
the resulting len calculation after calling l2cap_get_conf_opt is not
below zero. A well formed packet will always return >= 0 here and will
end with the length value being zero after the last option has been
parsed. In case of malformed packets messing with the opt->len field the
length value will become negative. If that is the case, then just abort
and ignore the option.
In case an attacker uses a too short opt->len value, then garbage will
be parsed, but that is protected by the unknown option handling and also
the option parameter size checks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit af3d5d1c87664a4f150fcf3534c6567cb19909b0 upstream.
When doing option parsing for standard type values of 1, 2 or 4 octets,
the value is converted directly into a variable instead of a pointer. To
avoid being tricked into being a pointer, check that for these option
types that sizes actually match. In L2CAP every option is fixed size and
thus it is prudent anyway to ensure that the remote side sends us the
right option size along with option paramters.
If the option size is not matching the option type, then that option is
silently ignored. It is a protocol violation and instead of trying to
give the remote attacker any further hints just pretend that option is
not present and proceed with the default values. Implementation
following the specification and its qualification procedures will always
use the correct size and thus not being impacted here.
To keep the code readable and consistent accross all options, a few
cosmetic changes were also required.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream.
Control events can leak kernel memory since they do not fully zero the
event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so
fix both.
It appears that all other event code is properly zeroing the structure,
it's these two places.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 372a03e01853f860560eade508794dd274e9b390 upstream.
Ext4 needs to serialize unaligned direct AIO because the zeroing of
partial blocks of two competing unaligned AIOs can result in data
corruption.
However it decides not to serialize if the potentially unaligned aio is
past i_size with the rationale that no pending writes are possible past
i_size. Unfortunately if the i_size is not block aligned and the second
unaligned write lands past i_size, but still into the same block, it has
the potential of corrupting the previous unaligned write to the same
block.
This is (very simplified) reproducer from Frank
// 41472 = (10 * 4096) + 512
// 37376 = 41472 - 4096
ftruncate(fd, 41472);
io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376);
io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472);
io_submit(io_ctx, 1, &iocbs[1]);
io_submit(io_ctx, 1, &iocbs[2]);
io_getevents(io_ctx, 2, 2, events, NULL);
Without this patch the 512B range from 40960 up to the start of the
second unaligned write (41472) is going to be zeroed overwriting the data
written by the first write. This is a data corruption.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
With this patch the data corruption is avoided because we will recognize
the unaligned_aio and wait for the unwritten extent conversion.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
*
0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31
*
0000b200
Reported-by: Frank Sorenson <fsorenso@redhat.com>
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Fixes: e9e3bcecf4 ("ext4: serialize unaligned asynchronous DIO")
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fa30dde38aa8628c73a6dded7cb0bba38c27b576 upstream.
We see the following NULL pointer dereference while running xfstests
generic/475:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
PGD 8000000c84bad067 P4D 8000000c84bad067 PUD c84e62067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 9886 Comm: fsstress Kdump: loaded Not tainted 5.0.0-rc8 #10
RIP: 0010:ext4_do_update_inode+0x4ec/0x760
...
Call Trace:
? jbd2_journal_get_write_access+0x42/0x50
? __ext4_journal_get_write_access+0x2c/0x70
? ext4_truncate+0x186/0x3f0
ext4_mark_iloc_dirty+0x61/0x80
ext4_mark_inode_dirty+0x62/0x1b0
ext4_truncate+0x186/0x3f0
? unmap_mapping_pages+0x56/0x100
ext4_setattr+0x817/0x8b0
notify_change+0x1df/0x430
do_truncate+0x5e/0x90
? generic_permission+0x12b/0x1a0
This is triggered because the NULL pointer handle->h_transaction was
dereferenced in function ext4_update_inode_fsync_trans().
I found that the h_transaction was set to NULL in jbd2__journal_restart
but failed to attached to a new transaction while the journal is aborted.
Fix this by checking the handle before updating the inode.
Fixes: b436b9bef8 ("ext4: Wait for proper transaction commit on fsync")
Signed-off-by: Jiufei Xue <jiufei.xue@linux.alibaba.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a07168d8d89b00fe1760120714378175b3ef992 upstream.
The futex code requires that the user space addresses of futexes are 32bit
aligned. sys_futex() checks this in futex_get_keys() but the robust list
code has no alignment check in place.
As a consequence the kernel crashes on architectures with strict alignment
requirements in handle_futex_death() when trying to cmpxchg() on an
unaligned futex address which was retrieved from the robust list.
[ tglx: Rewrote changelog, proper sizeof() based alignement check and add
comment ]
Fixes: 0771dfefc9 ("[PATCH] lightweight robust futexes: core")
Signed-off-by: Chen Jie <chenjie6@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: <dvhart@infradead.org>
Cc: <peterz@infradead.org>
Cc: <zengweilin@huawei.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1552621478-119787-1-git-send-email-chenjie6@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[cvxda: qcacld-3.0 to qcacld-2.0 propagation:
WMI_SVC_MSG_MAX_SIZE is called WMA_SVC_MSG_MAX_SIZE]
The excess buffer check in wma_stats_event_handler is such that
if buflen is greater than WMI_SVC_MSG_MAX_SIZE, the resulting
difference of the two values will be a negative integer, which
will be treated as a very large positive integer since the data type
is unsigned. This will result in the check failing to detect overflow
when compared with sizeof(*event).
Fix the buflen check condition such that buflen is compared with the
difference of WMI_SVC_MSG_MAX_SIZE and sizeof(*event), eliminating
the possibility of overflow.
Bug: 112276863
Test: Regression test
Change-Id: Ic20bfa554476db36e28557402cec23fcce5af85d
CRs-Fixed: 2224443
Signed-off-by: Sunil Ravi <sunilravi@google.com>
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
[ Upstream commit b5476022bbada3764609368f03329ca287528dc8 ]
IPv4 stack reacts to changes to small MTU, by disabling itself under
RTNL.
But there is a window where threads not using RTNL can see a wrong
device mtu. This can lead to surprises, in igmp code where it is
assumed the mtu is suitable.
Fix this by reading device mtu once and checking IPv4 minimal MTU.
This patch adds missing IPV4_MIN_MTU define, to not abuse
ETH_MIN_MTU anymore.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use READ_ONCE in patches applied after importing the Samsung kernel
where the upstream patch did it.
Change-Id: I7c4bbf99dc45c105289bfb404d1818e571069113
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
[ Upstream commit dd36929720f40f17685e841ae0d4c581c165ea60 ]
The use of READ_ONCE() causes lots of warnings witht he pending paravirt
spinlock fixes, because those ends up having passing a member to a
'const' structure to READ_ONCE().
There should certainly be nothing wrong with using READ_ONCE() with a
const source, but the helper function __read_once_size() would cause
warnings because it would drop the 'const' qualifier, but also because
the destination would be marked 'const' too due to the use of 'typeof'.
Use a union of types in READ_ONCE() to avoid this issue.
Also make sure to use parenthesis around the macro arguments to avoid
possible operator precedence issues.
Change-Id: I84a7bc59753db5c5343441c2fb727d1009167e3f
Tested-by: Ingo Molnar <mingo@kernel.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
[ Upstream commit 43239cbe79fc369f5d2160bd7f69e28b5c50a58c ]
Feedback has shown that WRITE_ONCE(x, val) is easier to use than
ASSIGN_ONCE(val,x).
There are no in-tree users yet, so lets change it for 3.19.
Change-Id: I6b43d7873b5e54fb0284eeb4795d7511d3c4b8a2
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Davidlohr Bueso <dave@stgolabs.net>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Let's provide READ_ONCE/ASSIGN_ONCE that will do all accesses via
scalar types as suggested by Linus Torvalds. Accesses larger than
the machines word size cannot be guaranteed to be atomic. These
macros will use memcpy and emit a build warning.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Bug: 28705983
(cherry picked from commit 230fa253df6352af12ad0a16128760b5cb3f92df)
Change-Id: I6235247c7b3a5e14093d477417000ed82f7586a3
Git-commit: 430d1abe23d2252fee64236593f74073a2b6d8ec
Git-repo: https://android.googlesource.com/kernel/common.git/
Signed-off-by: Chetan C R <cravin@codeaurora.org>
Add range check to make sure the received audio port index
from ADSP is within the valid range.
Change-Id: Ief647df1659f7f349a843f666d8f92f34a9a43be
Signed-off-by: Xiaoyu Ye <benyxy@codeaurora.org>
Check if packet size is large enough to hold the header.
Change-Id: I7261f8111d8b5f4f7c181e469de248a732242d64
Signed-off-by: Vatsal Bucha <vbucha@codeaurora.org>
Currently, there is a possibility of nested sleep
during handling of data ready notification to diag
clients. The patch fixes the issue by properly
handling data ready notifications.
Change-Id: Ib30455b41d1b05bff33cc0a627c1fc7e9a1b7568
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: Hardik Arya <harya@codeaurora.org>
There can be many ice instances present in dtsi file but
not all of them will be initialized by storage driver.
Check if crypto instance is initialized before setting
it up for data encryption/decryption usage.
Change-Id: I7c9227007474052513b277dec5963a973781c524
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
The range checking for audio buffer copying in function
"audio_in_write" is using the incorrect buffer size.
Change it to the actual allocated audio buffer size.
Change-Id: Ib7aaa2163c0d99161369eb85d09dc2d23d8c787b
Signed-off-by: Xiaoyu Ye <benyxy@codeaurora.org>
There is a possibility of out-of-bound read if msg mask
ranges received from peripheral are more than max ssid per
range. Cap msg mask's ssid ranges to MAX_SSID_PER_RANGE if
ranges received from peripheral are greater than the same.
Change-Id: I886692ad223e16678bfaecbe381c62fdf3503cb5
Signed-off-by: Hardik Arya <harya@codeaurora.org>
Currently we are not validating read and write index of
tx and rx fifo's before calculating ptr, this can lead to
out-of-bound access. The patch adds proper check for the same.
Change-Id: I7b158e94ae743a90ac364783fe31914ca0fa582b
Signed-off-by: Hardik Arya <harya@codeaurora.org>
commit 29b75eb2d56a714190a93d7be4525e617591077a upstream.
Commit e91467ecd1 ("bug in futex unqueue_me") introduced a barrier() in
unqueue_me() to prevent the compiler from rereading the lock pointer which
might change after a check for NULL.
Replace the barrier() with a READ_ONCE() for the following reasons:
1) READ_ONCE() is a weaker form of barrier() that affects only the specific
load operation, while barrier() is a general compiler level memory barrier.
READ_ONCE() was not available at the time when the barrier was added.
2) Aside of that READ_ONCE() is descriptive and self explainatory while a
barrier without comment is not clear to the casual reader.
No functional change.
[ tglx: Massaged changelog ]
Change-Id: I41b0f0c77dc827536685dddb60f32a31c1cde559
Signed-off-by: Jianyu Zhan <nasa4836@gmail.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Cc: dave@stgolabs.net
Cc: peterz@infradead.org
Cc: linux@rasmusvillemoes.dk
Cc: akpm@linux-foundation.org
Cc: fengguang.wu@intel.com
Cc: bigeasy@linutronix.de
Link: http://lkml.kernel.org/r/1457314344-5685-1-git-send-email-nasa4836@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-repo: https://android.googlesource.com/kernel/msm
Git-commit: 1920b8a6a6ed80d3a595ff718c0a99c7d4d895c4
Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
Correctly free pointers allocated by kzalloc. Remove devm_kfree
in error handling as device associated memory is automatically
freed upon destruction of device. Always use put_device instead
of kfree on initialized device.
Change-Id: Icbd88e9ccd42fedb4fbce5eff69248c3fceffc02
Signed-off-by: David Dai <daidavid1@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
Ensure the count of supported encoder and decoder returned
from firmware are within the range of supported sessions.
Change-Id: If3eae7bc82dc8302444e2e4104fb6ae3cfbfed5a
Signed-off-by: Dikshita Agarwal <dikshita@codeaurora.org>
Smp2p test code is used internally to test the
functionality of drivers and has no real use case
in end product.
Change-Id: I7a50c077bb71068188b5411424c5782b3d0edbb7
Signed-off-by: Hardik Arya <harya@codeaurora.org>
sockaddr structure is filled with required information only which
results in few memory locations of structure with uninitialized data.
Memset complete structure before using it to remove uninitialized data.
CRs-Fixed: 2274853
Change-Id: I181710bde100fb1553b925d9fdf227af35ff38b5
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
TX and RX FIFOs of Microcontroller are used to exchange commands
and messages between Micro FW and CPP driver. TX FIFO depth is
16 32-bit words, incase of errors there is a chance of overflow.
To prevent possible out of bound access, TX FIFO depth or
level is checked for MAX depth before accessing the FIFO.
Change-Id: I5adf39b46ff10e358c4a2c03a2de07d44b99cedb
Signed-off-by: Pratap Nirujogi <pratapn@codeaurora.org>
Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
Input num_streams cannot be greater than the max allowed
number of streams, otherwise this casue OOB read access.
Add bounds check for num_streams which user input.
CRs-Fixed: 2330040
Change-Id: I76fb785dc54c597603d748d604844952cea659ea
Signed-off-by: Haibin Liu <haibinl@codeaurora.org>
Limit the index to buffer length while copying from
'strptr' to 'firmware_id'.
Change-Id: I1d7cb7a3d9593ca213c7f7341776632e635eb0df
Signed-off-by: Venkata Prahlad Valluru <vvalluru@codeaurora.org>
Sanitize debugfs inputs to only allow access to mdp memory block
specified in dtsi file. This change will allow only one single block
to be read at the time and will avoid accessing memory outside of valid
decode space which can trigger AHB error bus response.
Change-Id: Icede9a8939a66faa59d674c18183fb0ebcf67908
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
Currently, mask pointers are not updated in
case peripherals are supporting more mask
tables. The patch updates the mask pointers
properly.
Change-Id: I1360c722076fca0215e0ccd28247c4741a1ebd88
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
SSM driver is not enabled and hence needs deprecation.
Remove all the SSM driver references.
CRs-Fixed: 2268386
Change-Id: I02f82817023d2fcc6d05a2f0d7eb3aec8f60a7d5
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
Memory allocated with "devm_kzalloc" is automatically released
by the kernel if the "probe" function fails with an error code.
Therefore, using "kfree" is unsafe because it can lead to the Double-Free.
Change-Id: Ic9285ebbd7d246e275a93cde4d03656d99d5ea3d
Signed-off-by: Raghavendra Ambadas <rambad@codeaurora.org>
There is a possible buffer overflow in the "reg_debug_volt_get"
function. Fix it by passing the appropriate byte count.
Change-Id: I30868790c42cdb225af74054532a75c49506fe82
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
The gerrit removes debug code which is not being
used anymore.
CRs-Fixed: 2054144
Change-Id: I579d641f00592fcbbd6d75c6a0845a1b986973da
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Do not use kfree for memory allocated with devm_kzalloc during
failures as device memory will get freed in device release.
Change-Id: I6c4d3f8ed55ab02e3e70a1fe65452a8817c8b64e
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
commit 5539b3c938d64a60cb1fc442ac3ce9263d52de0c upstream.
Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).
Fixes: 391c970c0d ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events
automatically")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
[syphyr: removed references to acpi_gpiochip_remove for 3.10]
Signed-off-by: L R <syphyr@gmail.com>
Patch be1a4b brought some improvements to the GPIO error handling code,
but also changed the return value of gpiod_request() when called on a
not yet initialized GPIO descriptor: it now returns -EINVAL instead of
-EPROBE_DEFER, and this affects some drivers.
This patch restores the original behavior for gpiod_request(). It is
safe to do so now that desc_to_gpio() does not rely on the GPIO
descriptor to be initialized. Other functions changed by patch be1a4b
do not see their return value affected, so these are not reverted.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It appears some drivers are using gpio_set_debounce()
opportunistically, i.e. without knowing whether it works or
not. (Example: input/keyboard/gpio_keys.c) to account for
this use case, return -ENOTSUPP and do not print any
warnings in this case.
Took a round over the other gpio_set_debounce() consumers
to make sure that none of them are relying on the returned
error code to be something specific.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
At several places the gpiolib will proceed to handle a GPIO
descriptor even if it's ->chip member is NULL and no gpiochip
is associated.
Fix this by checking that both the descriptor cookie *and*
the chip pointer are valid.
Also bail out earlier with more specific diagnostic messages
on missing operations for setting as input/output or debounce.
ChangeLog v1->v2:
- Also return -EIO on gpiod_set_debounce() with missing
operations in the vtable
- Fix indentations.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Frank Rowand <frank.rowand@sonymobile.com>
Cc: Tim Bird <tim.bird@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Chaotian Jing
Christoffer Dall
James Morse
Greg Hackmann
Rajmal Menariya
Mark Rutland
Yury Norov
Marcel Holtmann
Hans Verkuil
Lukas Czerner
Jiufei Xue
Chen Jie
Sunil Ravi
Eric Dumazet
syphyr
Corinna Vinschen
Linus Torvalds
Christian Borntraeger
Xiaoyu Ye
Vatsal Bucha
Hardik Arya
Neeraj Soni
Jianyu Zhan
David Dai
Dikshita Agarwal
Arun Kumar Neelakantam
Pratap Nirujogi
Haibin Liu
Venkata Prahlad Valluru
Amine Najahi
Mohit Aggarwal
Manoj Prabhu B
raghavendra ambadas
Kiran Gunda
Vikash Garodia
Maulik Shah
Johan Hovold
Alexandre Courbot
Linus Walleij