- 09 Oct, 2014 2 commits
-
-
Stefan Kristiansson authored
commit fe2a08b3 upstream. The correct type (SSM2602/SSM2603/SSM2604) is passed down from the ssm2602_spi_probe()/ssm2602_spi_probe() functions, so use that instead of hardcoding it to SSM2602 in ssm2602_probe(). Fixes: c924dc68 ("ASoC: ssm2602: Split SPI and I2C code into different modules") Signed-off-by:
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by:
Mark Brown <broonie@kernel.org> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit c03aa9f6 upstream. We did not implement any bound on number of indirect ICBs we follow when loading inode. Thus corrupted medium could cause kernel to go into an infinite loop, possibly causing a stack overflow. Fix the possible stack overflow by removing recursion from __udf_read_inode() and limit number of indirect ICBs we follow to avoid infinite loops. Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Chuck Ebbert <cebbert.lkml@gmail.com> Signed-off-by:
-
- 05 Oct, 2014 38 commits
-
-
Greg Kroah-Hartman authored
-
Rajendra Nayak authored
commit af438fec upstream. Use the corresponding compatibles to identify the devices. Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Tested-by:
Paul Walmsley <paul@pwsan.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Stephen Boyd authored
commit 5b6b7490 upstream. Sometimes we need to program PLLs with a fixed rate configuration during driver probe. Doing this after we register the PLLs with the clock framework causes the common clock framework to assume the rate of the PLLs are 0. This causes all sorts of problems for rate recalculations because the common clock framework caches the rate once at registration time unless a flag is set to always recalculate the rates. Split the qcom_cc_probe() function into two pieces, map and everything else, so that drivers which need to configure some PLL rates or otherwise twiddle bits in the clock controller can do so before registering clocks. This allows us to properly detect the rates of PLLs that are programmed at boot. Fixes: 49fc825f "clk: qcom: Consolidate common probe code" Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
commit f87dfcab upstream. The mdp_lut_clk isn't a child of the mdp_clk. Instead it's the child of the mdp_src clock. Fix it. Fixes: 6d00b56f "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Signed-off-by:
-
Stephen Boyd authored
commit ff20783f upstream. Clocks that don't have a pre-divider don't list any pre-divider in their frequency tables, but their tables are initialized using aggregate initializers. Use tagged initializers so we properly assign the m and n values for each frequency. Furthermore, the mmcc_pxo_pll8_pll2_pll3 array improperly mapped the second element to pll2 instead of pll8, causing the clock driver to recalculate the wrong rate for any clocks using this array along with a rate that uses pll2. Plus the .num_parents field is 3 instead of 4 so you can't even switch the parent to pll3. Finally I noticed that the jpegd clock improperly indicates that the pre-divider width is only 2, when it's actually 4 bits wide. Fixes: 6d00b56f "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)" Tested-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit 0bf22be0 upstream. The lustre virtual block device cannot handle 64K pages and fails at compile time. To avoid running into this error, let's disable the Kconfig option for this driver in cases it doesn't support. Reported-by:
Dann Frazier <dann.frazier@canonical.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Theodore Ts'o authored
commit a9cfcd63 upstream. Thanks to Dan Carpenter for extending smatch to find bugs like this. (This was found using a development version of smatch.) Fixes: 36de9286 Reported-by: Dan Carpenter <dan.carpenter@oracle.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
commit 36de9286 upstream. If we run into some kind of error, such as ENOMEM, while calling ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error gets propagated up to ext4_find_entry() and then to its callers. This way, transient errors such as ENOMEM can get propagated to the VFS. This is important so that the system calls return the appropriate error, and also so that in the case of ext4_lookup(), we return an error instead of a NULL inode, since that will result in a negative dentry cache entry that will stick around long past the OOM condition which caused a transient ENOMEM error. Google-Bug-Id: #17142205 Signed-off-by:
-
Gu Zheng authored
commit 6098b45b upstream. It seems that exit_aio() also needs to wait for all iocbs to complete (like io_destroy), but we missed the wait step in current implemention, so fix it in the same way as we did in io_destroy. Signed-off-by:
Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> [bwh: Backported to 3.16: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Suman Tripathi authored
commit 72f79f9e upstream. This patch removes the NCQ support from the APM X-Gene SoC AHCI Host Controller driver as it doesn't support it. Signed-off-by:
Loc Ho <lho@apm.com> Signed-off-by:
Suman Tripathi <stripathi@apm.com> Signed-off-by:
Tejun Heo <tj@kernel.org> [bwh: Backported to 3.16: host flags are passed to ahci_platform_init_host()] Signed-off-by:
-
Nishanth Menon authored
commit 2f103251 upstream. Check for valid parameters in check rate. Else, we end up getting errors like: [ 0.000000] Division by zero in kernel. [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc1 #1 [ 0.000000] [<c0015160>] (unwind_backtrace) from [<c0011978>] (show_stack+0x10/0x14) [ 0.000000] [<c0011978>] (show_stack) from [<c055f5f4>] (dump_stack+0x78/0x94) [ 0.000000] [<c055f5f4>] (dump_stack) from [<c02e17cc>] (Ldiv0+0x8/0x10) [ 0.000000] [<c02e17cc>] (Ldiv0) from [<c047d228>] (ti_clk_divider_set_rate+0x14/0x14c) [ 0.000000] [<c047d228>] (ti_clk_divider_set_rate) from [<c047a938>] (clk_change_rate+0x138/0x180) [ 0.000000] [<c047a938>] (clk_change_rate) from [<c047a908>] (clk_change_rate+0x108/0x180) This occurs as part of the inital clock tree update of child clock nodes where new_rate could be 0 for non functional clocks. Fixes: b4761198 ("CLK: ti: add support for ti divider-clock") Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Tero Kristo authored
commit 067bb174 upstream. In some cases, clocks can switch their parent with clk_set_rate, for example clk_mux can do this in some cases. Current implementation of clk_change_rate uses un-safe list iteration on the clock children, which will cause wrong clocks to be parsed in case any of the clock children change their parents during the change rate operation. Fixed by using the safe list iterator instead. The problem was detected due to some divide by zero errors generated by clock init on dra7-evm board, see discussion under http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details. Fixes: 71472c0c ("clk: add support for clock reparent on set_rate") Signed-off-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Nishanth Menon authored
commit 20411dad upstream. Check for valid parameters in check rate. Else, we end up getting errors. This occurs as part of the inital clock tree update of child clock nodes where new_rate could be 0 for non functional clocks. Fixes: 9ac33b0c (" CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)") Signed-off-by:
-
Viresh Kumar authored
commit b1b12bab upstream. Commit 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate") introduced a bug where the governors wouldn't be stopped anymore for ->target{_index}() drivers during suspend. This happens because 'cpufreq_suspended' is updated before stopping the governors during suspend and due to this __cpufreq_governor() would return early due to this check: /* Don't start any governor operations if we are entering suspend */ if (cpufreq_suspended) return 0; Fixes: 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate") Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Dan Carpenter authored
commit d97a86c1 upstream. The lvip[] array has "state->limit" elements so the condition here should be >= instead of >. Fixes: 6ceea22b ('partitions: add aix lvm partition support files') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Philippe De Muyter <phdm@macqel.be> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Andy Shevchenko authored
commit dd8ecfca upstream. Accordingly to discussion [1] and followed up documentation the DMA controller driver shouldn't start any DMA operations when dmaengine_submit() is called. This patch fixes the workflow in dw_dmac driver to follow the documentation. [1] http://www.spinics.net/lists/arm-kernel/msg125987.htmlSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Cc: "Petallo, MauriceX R" <mauricex.r.petallo@intel.com> Signed-off-by:
-
Andy Shevchenko authored
commit e7637c6c upstream. We have a duplicate code which starts first descriptor in the queue. Let's make this as a separate helper that can be used in future as well. Signed-off-by:
-
Ulf Hansson authored
commit 7878289b upstream. Commit "mmc: mmci: Handle CMD irq before DATA irq", caused an issue when using the ARM model of the PL181 and running QEMU. The bug was reported for the following QEMU version: $ qemu-system-arm -version QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), Copyright (c) 2003-2008 Fabrice Bellard To resolve the problem, let's restore the old behavior were the DATA irq is handled prior the CMD irq, but only for the arm_variant, which the problem was reported for. Reported-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Tested-by:
Kees Cook <keescook@chromium.org> Tested-by:
Ulf Hansson <ulf.hansson@linaro.org> [kees: backported to 3.16] Signed-off-by:
-
Pablo Neira Ayuso authored
commit b88825de upstream. Fix possible replacement of the per-cpu chain counters by null pointer when updating an existing chain in the commit path. Reported-by:
Matteo Croce <technoboy85@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Julian Anastasov authored
commit eb90b0c7 upstream. commit fc604767 ("ipvs: changes for local real server") from 2.6.37 introduced DNAT support to local real server but the IPv6 LOCAL_OUT handler ip_vs_local_reply6() is registered incorrectly as IPv4 hook causing any outgoing IPv4 traffic to be dropped depending on the IP header values. Chris tracked down the problem to CONFIG_IP_VS_IPV6=y Bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768Reported-by:
Chris J Arges <chris.j.arges@canonical.com> Tested-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
Daniel Borkmann authored
commit caa8ad94 upstream. There's actually no good reason why we cannot use cgroup id 0, so lets just remove this artificial barrier. Reported-by:
Alexey Perevalov <a.perevalov@samsung.com> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Tested-by:
-
Alex Gartrell authored
commit 76f084bc upstream. Previously, only the four high bits of the tclass were maintained in the ipv6 case. This matches the behavior of ipv4, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by:
Alex Gartrell <agartrell@fb.com> Acked-by:
-
Eric Dumazet authored
commit 7bd8490e upstream. xt_hashlimit cannot be used with large hash tables, because garbage collector is run from a timer. If table is really big, its possible to hold cpu for more than 500 msec, which is unacceptable. Switch to a work queue, and use proper scheduling points to remove latencies spikes. Later, we also could switch to a smoother garbage collection done at lookup time, one bucket at a time... Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Florian Westphal <fw@strlen.de> Cc: Patrick McHardy <kaber@trash.net> Reviewed-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
NeilBrown authored
commit f0cc9a05 upstream. r1_bio->start_next_window is not initialised in the READ case, so allow_barrier may incorrectly decrement conf->current_window_requests which can cause raise_barrier() to block forever. Fixes: 79ef3a8aReported-by:
Brassow Jonathan <jbrassow@redhat.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
commit b8cb6b4c upstream. If a devices is being recovered it is not InSync and is not Faulty. If a read error is experienced on that device, fix_read_error() will be called, but it ignores non-InSync devices. So it will neither fix the error nor fail the device. It is incorrect that fix_read_error() ignores non-InSync devices. It should only ignore Faulty devices. So fix it. This became a bug when we allowed reading from a device that was being recovered. It is suitable for any subsequent -stable kernel. Fixes: da8840a7Reported-by:
Alexander Lyakas <alex.bolshoy@gmail.com> Tested-by:
-
NeilBrown authored
commit 34e97f17 upstream. Both normal IO and resync IO can be retried with reschedule_retry() and so be counted into ->nr_queued, but only normal IO gets counted in ->nr_pending. Before the recent improvement to RAID1 resync there could only possibly have been one or the other on the queue. When handling a read failure it could only be normal IO. So when handle_read_error() called freeze_array() the fact that freeze_array only compares ->nr_queued against ->nr_pending was safe. But now that these two types can interleave, we can have both normal and resync IO requests queued, so we need to count them both in nr_pending. This error can lead to freeze_array() hanging if there is a read error, so it is suitable for -stable. Fixes: 79ef3a8aReported-by:
-
NeilBrown authored
commit c2fd4c94 upstream. raise_barrier() uses next_resync as part of its calculations, so it really should be updated first, instead of afterwards. next_resync is always used under resync_lock so update it under resync lock to, just before it is used. That is safest. This could cause normal IO and resync IO to interact badly so it suitable for -stable. Fixes: 79ef3a8aSigned-off-by:
-
NeilBrown authored
commit 23554960 upstream. next_resync is (approximately) the location for the next resync request. However it does *not* reliably determine the earliest location at which resync might be happening. This is because resync requests can complete out of order, and we only limit the number of current requests, not the distance from the earliest pending request to the latest. mddev->curr_resync_completed is a reliable indicator of the earliest position at which resync could be happening. It is updated less frequently, but is actually reliable which is more important. So use it to determine if a write request is before the region being resynced and so safe from conflict. This error can allow resync IO to interfere with normal IO which could lead to data corruption. Hence: stable. Fixes: 79ef3a8aSigned-off-by:
-
NeilBrown authored
commit 2f73d3c5 upstream. The resync/recovery process for raid1 was recently changed so that writes could happen in parallel with resync providing they were in different regions of the device. There is a problem though: While a write request will always wait for conflicting resync to complete, a resync request will *not* always wait for conflicting writes to complete. Two changes are needed to fix this: 1/ raise_barrier (which waits until it is safe to do resync) must wait until current_window_requests is zero 2/ wait_battier (which waits at the start of a new write request) must update current_window_requests if the request could possible conflict with a concurrent resync. As concurrent writes and resync can lead to data loss, this patch is suitable for -stable. Fixes: 79ef3a8a Cc: majianpeng <majianpeng@gmail.com> Signed-off-by:
-
NeilBrown authored
commit c6d119cf upstream. commit 79ef3a8a made it possible for reads to happen concurrently with resync. This means that we need to be more careful where read_balancing is allowed during resync - we can no longer be sure that any resync that has already started will definitely finish. So keep read_balancing to before recovery_cp, which is conservative but safe. This bug makes it possible to read from a device that doesn't have up-to-date data, so it can cause data corruption. So it is suitable for any kernel since 3.11. Fixes: 79ef3a8aSigned-off-by:
-
NeilBrown authored
commit 669cc7ba upstream. If there are outstanding writes when close_sync is called, the change to ->start_next_window might cause them to decrement the wrong counter when they complete. Fix this by merging the two counters into the one that will be decremented. Having an incorrect value in a counter can cause raise_barrier() to hangs, so this is suitable for -stable. Fixes: 79ef3a8aSigned-off-by:
-
Zhaowei Yuan authored
commit a9ae4692 upstream. It's also invalid when plane_no is equal to vb->num_planes Signed-off-by:
Zhaowei Yuan <zhaowei.yuan@samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Hans Verkuil authored
commit bf3593d9 upstream. Commit bd994ddb (vb2: Fix stream start and buffer completion race) broke the buffer state check in vb2_buffer_done. So accept all three possible states there since I can no longer tell the difference between vb2_buffer_done called from start_streaming or from elsewhere. Instead add a WARN_ON at the end of start_streaming that will check whether any buffers were added to the done list, since that implies that the wrong state was used as well. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
commit 47bc59c5 upstream. sg_alloc_table_from_pages() only allocates a sg_table, so it should just use GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c will call BUG_ON: [ 358.027515] ------------[ cut here ]------------ [ 358.027546] kernel BUG at mm/slub.c:1416! [ 358.027558] invalid opcode: 0000 [#1] PREEMPT SMP [ 358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci [ 358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167 [ 358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014 [ 358.027741] task: ffff880897c7d960 ti: ffff88089b4d4000 task.ti: ffff88089b4d4000 [ 358.027753] RIP: 0010:[<ffffffff81196040>] [<ffffffff81196040>] new_slab+0x280/0x320 [ 358.027776] RSP: 0018:ffff88089b4d7ae8 EFLAGS: 00010002 [ 358.027787] RAX: ffff880897c7d960 RBX: 0000000000000000 RCX: ffff88089b4d7b50 [ 358.027798] RDX: 00000000ffffffff RSI: 0000000000000004 RDI: ffff88089f803b00 [ 358.027809] RBP: ffff88089b4d7bb8 R08: 0000000000000000 R09: 0000000100400040 [ 358.027821] R10: 0000160000000000 R11: ffff88109bc02c40 R12: 0000000000000001 [ 358.027832] R13: ffff88089f8000c0 R14: ffff88089f803b00 R15: ffff8810bfcf4be0 [ 358.027845] FS: 00007f83fe5c0700(0000) GS:ffff8810bfce0000(0000) knlGS:0000000000000000 [ 358.027858] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 358.027868] CR2: 0000000001dfd568 CR3: 0000001097d5a000 CR4: 00000000000407e0 [ 358.027878] Stack: [ 358.027885] ffffffff81198860 ffff8810bfcf4be0 ffff880897c7d960 0000000000001b00 [ 358.027905] ffff880897c7d960 0000000000000000 ffff8810bfcf4bf0 0000000000000000 [ 358.027924] 0000000000000000 0000000100000100 ffffffff813ef84a 00000004ffffffff [ 358.027944] Call Trace: [ 358.027956] [<ffffffff81198860>] ? __slab_alloc+0x400/0x4e0 [ 358.027973] [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30 [ 358.027985] [<ffffffff81198f17>] __kmalloc+0x127/0x150 [ 358.027997] [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30 [ 358.028009] [<ffffffff813ef84a>] sg_kmalloc+0x1a/0x30 [ 358.028023] [<ffffffff813eff84>] __sg_alloc_table+0x74/0x180 [ 358.028035] [<ffffffff813ef830>] ? sg_kfree+0x20/0x20 [ 358.028048] [<ffffffff813f00af>] sg_alloc_table+0x1f/0x60 [ 358.028061] [<ffffffff813f0174>] sg_alloc_table_from_pages+0x84/0x1f0 [ 358.028077] [<ffffffffa007c3f9>] vb2_dma_sg_alloc+0x159/0x230 [videobuf2_dma_sg] [ 358.028095] [<ffffffffa003d55a>] __vb2_queue_alloc+0x10a/0x680 [videobuf2_core] [ 358.028113] [<ffffffffa003e110>] __reqbufs.isra.14+0x220/0x3e0 [videobuf2_core] [ 358.028130] [<ffffffffa003e79d>] __vb2_init_fileio+0xbd/0x380 [videobuf2_core] [ 358.028147] [<ffffffffa003f563>] __vb2_perform_fileio+0x5b3/0x6e0 [videobuf2_core] [ 358.028164] [<ffffffffa003f871>] vb2_fop_read+0xb1/0x100 [videobuf2_core] [ 358.028184] [<ffffffffa06dd2e5>] v4l2_read+0x65/0xb0 [videodev] [ 358.028198] [<ffffffff811a243f>] vfs_read+0x8f/0x170 [ 358.028210] [<ffffffff811a30a1>] SyS_read+0x41/0xb0 [ 358.028224] [<ffffffff818f02e9>] system_call_fastpath+0x16/0x1b [ 358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff ff 0f 1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48 [ 358.028415] RIP [<ffffffff81196040>] new_slab+0x280/0x320 [ 358.028432] RSP <ffff88089b4d7ae8> [ 358.032208] ---[ end trace 6443240199c706e4 ]--- Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit c7854c2c upstream. When both VBI and video are streaming, and video stream is stopped, a subsequent trial to restart it will fail, because S_FMT will return -EBUSY. That prevents applications like zvbi to work properly. Please notice that, while this fix it fully for zvbi, the best is to get rid of streaming_users and res_get logic as a hole. However, this single-line patch is better to be merged at -stable. Signed-off-by:
-
Hans Verkuil authored
commit 77639ff2 upstream. The log_status function should show HDMI information, but the test checking for an HDMI input was inverted. Fix this. Signed-off-by:
-
Bimow Chen authored
commit 0df6580c upstream. Update IT9135 BX tuner config 60 and 61 inittabs. [crope@iki.fi: removed two reg writes from driver init itself] Signed-off-by:
Bimow Chen <Bimow.Chen@ite.com.tw> Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Hans Verkuil authored
commit 6a03dc92 upstream. This was caused by an uninitialized setup.config field. Based on a suggestion from Devin Heitmueller. Signed-off-by:
Scott Robinson <scott.robinson55@gmail.com> Tested-by:
-
