- 10 May, 2019 33 commits
-
-
tiancyin authored
[ Upstream commit c1cefe11 ] [Why] the member sdr_white_level of struct dc_cursor_attributes was not initialized, then the random value result that dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal value is 0x3c00), this cause the black cursor issue. [how] just initilize the obj of struct dc_cursor_attributes to zero to avoid the random value. Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Tianci Yin <tianci.yin@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Sugar Zhang authored
[ Upstream commit c8506443 ] This is because set_fmt ops maybe called when PD is off, and in such case, regmap_ops will lead system hang. enale PD before doing regmap_ops. Signed-off-by:
Sugar Zhang <sugar.zhang@rock-chips.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Jann Horn authored
[ Upstream commit a0fe2c64 ] Use parentheses around uses of the argument in u64_to_user_ptr() to ensure that the cast doesn't apply to part of the argument. There are existing uses of the macro of the form u64_to_user_ptr(A + B) which expands to (void __user *)(uintptr_t)A + B (the cast applies to the first operand of the addition, the addition is a pointer addition). This happens to still work as intended, the semantic difference doesn't cause a difference in behavior. But I want to use u64_to_user_ptr() with a ternary operator in the argument, like so: u64_to_user_ptr(A ? B : C) This currently doesn't work as intended. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Cc: Andrei Vagin <avagin@openvz.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: NeilBrown <neilb@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Qiaowei Ren <qiaowei.ren@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190329214652.258477-1-jannh@google.comSigned-off-by:
-
Peter Zijlstra authored
[ Upstream commit d7262457 ] Stephane reported that the TFA MSR is not initialized by the kernel, but the TFA bit could set by firmware or as a leftover from a kexec, which makes the state inconsistent. Reported-by:
Stephane Eranian <eranian@google.com> Tested-by:
Nelson DSouza <nelson.dsouza@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: tonyj@suse.com Link: https://lkml.kernel.org/r/20190321123849.GN6521@hirez.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stephane Eranian authored
[ Upstream commit 583feb08 ] When an event is programmed with attr.wakeup_events=N (N>0), it means the caller is interested in getting a user level notification after N samples have been recorded in the kernel sampling buffer. With precise events on Intel processors, the kernel uses PEBS. The kernel tries minimize sampling overhead by verifying if the event configuration is compatible with multi-entry PEBS mode. If so, the kernel is notified only when the buffer has reached its threshold. Other PEBS operates in single-entry mode, the kenrel is notified for each PEBS sample. The problem is that the current implementation look at frequency mode and event sample_type but ignores the wakeup_events field. Thus, it may not be possible to receive a notification after each precise event. This patch fixes this problem by disabling multi-entry PEBS if wakeup_events is non-zero. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: kan.liang@intel.com Link: https://lkml.kernel.org/r/20190306195048.189514-1-eranian@google.comSigned-off-by:
-
Dan Carpenter authored
[ Upstream commit 2d859783 ] We don't want to overwrite "ret", it already holds the correct error code. The "regmap" variable might be a valid pointer as this point. Fixes: 8f83f268 ("drm/mediatek: Add HDMI support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
CK Hu <ck.hu@mediatek.com> Signed-off-by:
-
Annaliese McDermond authored
[ Upstream commit c63adb28 ] The common pins were mistakenly not added to the DAPM graph. Adding these pins will allow valid graphs to be created. Signed-off-by:
Annaliese McDermond <nh6z@nh6z.net> Signed-off-by:
-
Chong Qiao authored
[ Upstream commit ab8a6d82 ] KGDB_call_nmi_hook is called by other cpu through smp call. MIPS smp call is processed in ipi irq handler and regs is saved in handle_int. So kgdb_call_nmi_hook get regs by get_irq_regs and regs will be passed to kgdb_cpu_enter. Signed-off-by:
Chong Qiao <qiaochong@loongson.cn> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: QiaoChong <qiaochong@loongson.cn> Signed-off-by:
-
Kaike Wan authored
[ Upstream commit d0294344 ] The receive side mapping (RSM) on hfi1 hardware is a special matching mechanism to direct an incoming packet to a given hardware receive context. It has 4 instances of matching capabilities (RSM0 - RSM3) that share the same RSM table (RMT). The RMT has a total of 256 entries, each of which points to a receive context. Currently, three instances of RSM have been used: 1. RSM0 by QOS; 2. RSM1 by PSM FECN; 3. RSM2 by VNIC. Each RSM instance should reserve enough entries in RMT to function properly. Since both PSM and VNIC could allocate any receive context between dd->first_dyn_alloc_ctxt and dd->num_rcv_contexts, PSM FECN must reserve enough RMT entries to cover the entire receive context index range (dd->num_rcv_contexts - dd->first_dyn_alloc_ctxt) instead of only the user receive contexts allocated for PSM (dd->num_user_contexts). Consequently, the sizing of dd->num_user_contexts in set_up_context_variables is incorrect. Fixes: 2280740f ("IB/hfi1: Virtual Network Interface Controller (VNIC) HW support") Reviewed-by:
Mike Marciniszyn <mike.marciniszyn@intel.com> Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
Kaike Wan <kaike.wan@intel.com> Signed-off-by:
Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Kaike Wan authored
[ Upstream commit a8639a79 ] When an old ack_queue entry is used to store an incoming request, it may need to clean up the old entry if it is still referencing the MR. Originally only RDMA READ request needed to reference MR on the responder side and therefore the opcode was tested when cleaning up the old entry. The introduction of tid rdma specific operations in the ack_queue makes the specific opcode tests wrong. Multiple opcodes (RDMA READ, TID RDMA READ, and TID RDMA WRITE) may need MR ref cleanup. Remove the opcode specific tests associated with the ack_queue. Fixes: f48ad614 ("IB/hfi1: Move driver out of staging") Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 36a1da15 ] If CONFIG_OMAP4_DSS_HDMI_CEC is enabled in .config, deeper SoC idle states are blocked because the CEC clock gets always enabled on init. Let's fix the issue by moving the CEC clock handling to happen later in hdmi_cec_adap_enable() as suggested by Hans Verkuil <hverkuil@xs4all.nl>. This way the CEC clock gets only enabled when needed. This can be tested by doing cec-ctl --playback to enable the CEC, and doing cec-ctl --clear to disable it. Let's also fix the typo for "divider" in the comments while at it. Fixes: 8d7f934d ("omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support") Suggested-by:
Hans Verkuil <hverkuil@xs4all.nl> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Jyri Sarha <jsarha@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326151438.32414-1-tony@atomide.comSigned-off-by:
-
Pankaj Bharadiya authored
[ Upstream commit cacea3a9 ] w_text_param can be NULL and it is being dereferenced without checking. Add the missing sanity check to prevent NULL pointer dereference. Signed-off-by:
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Acked-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
Daniel Mack authored
[ Upstream commit f0f2338a ] The CS4270 does not by default increment the register address on consecutive writes. During normal operation it doesn't matter as all register accesses are done individually. At resume time after suspend, however, the regcache code gathers the biggest possible block of registers to sync and sends them one on one go. To fix this, set the INCR bit in all cases. Signed-off-by:
Daniel Mack <daniel@zonque.org> Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit c47255b6 ] Register platform component with a prefix, to avoid warnings on debugfs entries creation, due to component name redundancy. Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit 19441e35 ] The DFSDM must be stopped when a new setting is applied. restart systematically DFSDM on multiple prepare calls, to apply changes. Signed-off-by:
-
Maxime Jourdan authored
[ Upstream commit 9b70c697 ] We want the video decoder clocks to always round to closest. While the muxes are already using CLK_MUX_ROUND_CLOSEST, the corresponding CLK_DIVIDER_ROUND_CLOSEST was forgotten for the dividers. Fix this by adding the flag to the two vdec dividers. Fixes: a565242e ("clk: meson: gxbb: add the video decoder clocks") Signed-off-by:
Maxime Jourdan <mjourdan@baylibre.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Charles Keepax authored
[ Upstream commit a2225a6d ] Best to lock across handling the bus error to ensure the DSP doesn't change power state as we are reading the status registers. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Shuming Fan authored
[ Upstream commit 1c5b6a27 ] If ASRC turns on, HW will use clk_dac as the reference clock whether recording or playback. Both of clk_dac and clk_adc should set proper clock while using ASRC. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Signed-off-by:
-
Sylwester Nawrocki authored
[ Upstream commit 2b13bee3 ] After commit fbeec965b8d1c ("ASoC: samsung: odroid: Fix 32000 sample rate handling") the audio root clock frequency is configured improperly for 44100 sample rate. Due to clock rate rounding it's 20070401 Hz instead of 22579000 Hz. This results in a too low value of the PSR clock divider in the CPU DAI driver and too fast actual sample rate for fs=44100. E.g. 1 kHz tone has actual 1780 Hz frequency (1 kHz * 20070401/22579000 * 2). Fix this by increasing the correction passed to clk_set_rate() to take into account inaccuracy of the EPLL frequency properly. Fixes: fbeec965b8d1c ("ASoC: samsung: odroid: Fix 32000 sample rate handling") Reported-by:
JaeChul Lee <jcsing.lee@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
John Hsu authored
[ Upstream commit 54d1cf78 ] The driver changes the stream name of DAC and ADC to avoid the issue of widget with prefixed name. When the machine adds prefixed name for codec, the stream name of DAI may not find the widgets. Signed-off-by:
John Hsu <KCHSU0@nuvoton.com> Signed-off-by:
-
John Hsu authored
[ Upstream commit 844a4a36 ] The driver has two issues when machine add prefix name for codec. (1)The stream name of DAI can't find the AIF widgets. (2)The drivr can enable/disalbe the MICBIAS and SAR widgets. The patch will fix these issues caused by prefixed name added. Signed-off-by:
-
Rander Wang authored
[ Upstream commit c899df3e ] If playback and capture are enabled concurrently, when the capture stops the output becomes inaudile. The playback application will become stuck and underrun after a timeout. This is caused by mistaken use of the stream_id, which should only be set for playback and not for capture Tested on Apollolake and Kabylake with SST driver. Signed-off-by:
Rander Wang <rander.wang@linux.intel.com> Acked-by:
-
Rander Wang authored
[ Upstream commit 570f18b6 ] On HDaudio platforms, if playback is started when capture is working, there is no audible output. This can be root-caused to the use of the rx|tx_mask to store an HDaudio stream tag. If capture is stared before playback, rx_mask would be non-zero on HDaudio platform, then the channel number of playback, which is in the same codec dai with the capture, would be changed by soc_pcm_codec_params_fixup based on the tx_mask at first, then overwritten by this function based on rx_mask at last. According to the author of tx|rx_mask, tx_mask is for playback and rx_mask is for capture. And stream direction is checked at all other references of tx|rx_mask in ASoC, so here should be an error. This patch checks stream direction for tx|rx_mask for fixup function. This issue would affect not only HDaudio+ASoC, but also I2S codecs if the channel number based on rx_mask is not equal to the one for tx_mask. It could be rarely reproduecd because most drivers in kernel set the same channel number to tx|rx_mask or rx_mask is zero. Tested on all platforms using stream_tag & HDaudio and intel I2S platforms. Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit b8468192 ] Change capabilities exposed in SAI S/PDIF mode, to match actually supported formats. In S/PDIF mode only 32 bits stereo is supported. Signed-off-by:
-
Olivier Moysan authored
[ Upstream commit 5f8a1000 ] Allow indexation of sai iec958 controls according to device id. Signed-off-by:
-
Russell King authored
[ Upstream commit 2e95f984 ] When using the S/PDIF DAI, there is no requirement to call snd_soc_dai_set_fmt() as there is no DAI format definition that defines S/PDIF. In any case, S/PDIF does not have separate clocks, this is embedded into the data stream. Consequently, when attempting to use TDA998x in S/PDIF mode, the attempt to configure TDA998x via the hw_params callback fails as the hdmi_codec_daifmt is left initialised to zero. Since the S/PDIF DAI will only be used by S/PDIF, prepare the hdmi_codec_daifmt structure for this format. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
Philipp Puschmann authored
[ Upstream commit 82ad7591 ] This patch fixes a bug that prevents freeing the reset gpio on unloading the module. aic3x_i2c_probe is called when loading the module and it calls list_add with a probably uninitialized list entry aic3x->list (next = prev = NULL)). So even if list_del is called it does nothing and in the end the gpio_reset is not freed. Then a repeated module probing fails silently because gpio_request fails. When moving INIT_LIST_HEAD to aic3x_i2c_probe we also have to move list_del to aic3x_i2c_remove because aic3x_remove may be called multiple times without aic3x_i2c_remove being called which leads to a NULL pointer dereference. Signed-off-by:
Philipp Puschmann <philipp.puschmann@emlix.com> Signed-off-by:
-
Suresh Udipi authored
commit af708900 upstream. It looks like v4.18-rc1 commit [0] which upstreams mld-1.8.0 commit [1] missed to fix the memory leak in mod_exit function. Do it now. [0] aba258b7 ("staging: most: cdev: fix chrdev_region leak") [1] https://github.com/microchip-ais/linux/commit/a2d8f7ae7ea381 ("staging: most: cdev: fix leak for chrdev_region") Signed-off-by:
Suresh Udipi <sudipi@jp.adit-jv.com> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by:
Christian Gromm <christian.gromm@microchip.com> Fixes: aba258b7 ("staging: most: cdev: fix chrdev_region leak") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 47830c11 upstream. Since moving the message buffers off the stack, the dynamically allocated get-prop-descriptor request buffer is incorrectly sized due to using the pointer rather than request-struct size when creating the operation. Fortunately, the pointer size is always larger than this one-byte request, but this could still cause trouble on the remote end due to the unexpected message size. Fixes: 9d15134d ("greybus: power_supply: rework get descriptors") Cc: stable <stable@vger.kernel.org> # 4.9 Cc: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by:
-
Andrey Ryabinin authored
commit f0996bc2 upstream. Building lib/ubsan.c with gcc-9 results in a ton of nasty warnings like this one: lib/ubsan.c warning: conflicting types for built-in function ‘__ubsan_handle_negate_overflow’; expected ‘void(void *, void *)’ [-Wbuiltin-declaration-mismatch] The kernel's declarations of __ubsan_handle_*() often uses 'unsigned long' types in parameters while GCC these parameters as 'void *' types, hence the mismatch. Fix this by using 'void *' to match GCC's declarations. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Fixes: c6d30853 ("UBSAN: run-time undefined behavior sanity checker") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dexuan Cui authored
commit a0033bd1 upstream. With CONFIG_DEBUG_PREEMPT=y, the put_cpu_ptr() triggers an underflow warning in preempt_count_sub(). Fixes: 37cdd991 ("vmbus: put related per-cpu variable together") Cc: stable@vger.kernel.org Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
-
Jason Yan authored
commit b90cd6f2 upstream. When the lldd is processing the complete sas task in interrupt and set the task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to be triggered at the same time. And smp_task_timedout() will complete the task wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may freed before lldd end the interrupt process. Thus a use-after-free will happen. Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not set. And remove the check of the return value of the del_timer(). Once the LLDD sets DONE, it must call task->done(), which will call smp_task_done()->complete() and the task will be completed and freed correctly. Reported-by:
chenxiang <chenxiang66@hisilicon.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> CC: Hannes Reinecke <hare@suse.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: Guenter Roeck <linux@roeck-us.net Signed-off-by:
-
YueHaibing authored
commit f87db4db upstream. gcc warn this: drivers/net/ethernet/stmicro/stmmac/norm_desc.c: In function ndesc_init_rx_desc: drivers/net/ethernet/stmicro/stmmac/norm_desc.c:138:6: warning: variable 'bfsize1' set but not used [-Wunused-but-set-variable] Like enh_desc_init_rx_desc, we should use bfsize1 in ndesc_init_rx_desc to calculate 'p->des1' Fixes: 583e6361 ("net: stmmac: use correct DMA buffer size in the RX descriptor") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by:
-
- 08 May, 2019 7 commits
-
-
Greg Kroah-Hartman authored
-
Arnd Bergmann authored
commit dce5b0bd upstream. The only references outside of the #ifdef have been removed, so now we get a warning in non-SMP configurations: mm/kmemleak.c:1404:13: error: unused function 'scan_large_block' [-Werror,-Wunused-function] Add a new #ifdef around it. Link: http://lkml.kernel.org/r/20190416123148.3502045-1-arnd@arndb.de Fixes: 298a32b1 ("kmemleak: powerpc: skip scanning holes in the .bss section") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Charles Keepax authored
commit 43d147be upstream. Trigger stop can be called in situations where trigger start failed and as such it can't be assumed the buffer is already attached to the compressed stream or a NULL pointer may be dereferenced. Fixes: 639e5eb3 ("ASoC: wm_adsp: Correct handling of compressed streams that restart") Signed-off-by:
-
Jacopo Mondi authored
commit 61da76be upstream. The following commits: commit f6dd927f ("[media] media: ov7670: calculate framerate properly for ov7675") commit 04ee6d92 ("[media] media: ov7670: add possibility to bypass pll for ov7675") introduced the ability to bypass PLL multiplier and use input clock (xvclk) as pixel clock output frequency for ov7675 sensor. PLL is bypassed using register DBLV[7:6], according to ov7670 and ov7675 sensor manuals. Macros used to set DBLV register seem wrong in the driver, as their values do not match what reported in the datasheet. Fix by changing DBLV_* macros to use bits [7:6] and set bits [3:0] to default 0x0a reserved value (according to datasheets). While at there, remove a write to DBLV register in "ov7675_set_framerate()" that over-writes the previous one to the same register that takes "info->pll_bypass" flag into account instead of setting PLL multiplier to 4x unconditionally. And, while at there, since "info->pll_bypass" is only used in set/get_framerate() functions used by ov7675 only, it is not necessary to check for the device id at probe time to make sure that when using ov7670 "info->pll_bypass" is set to false. Fixes: f6dd927f ("[media] media: ov7670: calculate framerate properly for ov7675") Signed-off-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Nicolas Le Bayon authored
commit c86da50c upstream. It conforms with Reference Manual I2C timing section. Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver") Signed-off-by:
Nicolas Le Bayon <nicolas.le.bayon@st.com> Signed-off-by:
Bich Hemon <bich.hemon@st.com> Reviewed-by:
Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Peter Zijlstra authored
commit 780e0106 upstream. Revert the following commit: 515ab7c4: ("x86/mm: Align TLB invalidation info") I found out (the hard way) that under some .config options (notably L1_CACHE_SHIFT=7) and compiler combinations this on-stack alignment leads to a 320 byte stack usage, which then triggers a KASAN stack warning elsewhere. Using 320 bytes of stack space for a 40 byte structure is ludicrous and clearly not right. Signed-off-by:
Nadav Amit <namit@vmware.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 515ab7c4 ("x86/mm: Align TLB invalidation info") Link: http://lkml.kernel.org/r/20190416080335.GM7905@worktop.programming.kicks-ass.net [ Minor changelog edits. ] Signed-off-by:
-
Qian Cai authored
commit 0d02113b upstream. The first kmemleak_scan() call after boot would trigger the crash below because this callpath: kernel_init free_initmem mem_encrypt_free_decrypted_mem free_init_pages unmaps memory inside the .bss when DEBUG_PAGEALLOC=y. kmemleak_init() will register the .data/.bss sections and then kmemleak_scan() will scan those addresses and dereference them looking for pointer references. If free_init_pages() frees and unmaps pages in those sections, kmemleak_scan() will crash if referencing one of those addresses: BUG: unable to handle kernel paging request at ffffffffbd402000 CPU: 12 PID: 325 Comm: kmemleak Not tainted 5.1.0-rc4+ #4 RIP: 0010:scan_block Call Trace: scan_gray_list kmemleak_scan kmemleak_scan_thread kthread ret_from_fork Since kmemleak_free_part() is tolerant to unknown objects (not tracked by kmemleak), it is fine to call it from free_init_pages() even if not all address ranges passed to this function are known to kmemleak. [ bp: Massage. ] Fixes: b3f0907c ("x86/mm: Add .bss..decrypted section to hold shared variables") Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
-
