- 10 5月, 2019 30 次提交
-
-
由 Peter Zijlstra 提交于
[ Upstream commit d7262457e35dbe239659e62654e56f8ddb814bed ] 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: NStephane Eranian <eranian@google.com> Tested-by: NNelson DSouza <nelson.dsouza@intel.com> Signed-off-by: NPeter 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: NIngo Molnar <mingo@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Stephane Eranian 提交于
[ Upstream commit 583feb08e7f7ac9d533b446882eb3a54737a6dbb ] 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: NStephane Eranian <eranian@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NAndi 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: NIngo Molnar <mingo@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Dan Carpenter 提交于
[ Upstream commit 2d85978341e6a32e7443d9f28639da254d53f400 ] 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: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NCK Hu <ck.hu@mediatek.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Annaliese McDermond 提交于
[ Upstream commit c63adb28f6d913310430f14c69f0a2ea55eed0cc ] The common pins were mistakenly not added to the DAPM graph. Adding these pins will allow valid graphs to be created. Signed-off-by: NAnnaliese McDermond <nh6z@nh6z.net> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Chong Qiao 提交于
[ Upstream commit ab8a6d821179ab9bea1a9179f535ccba6330c1ed ] 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: NChong Qiao <qiaochong@loongson.cn> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Acked-by: NDaniel Thompson <daniel.thompson@linaro.org> Signed-off-by: NPaul 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: NSasha Levin <sashal@kernel.org>
-
由 Kaike Wan 提交于
[ Upstream commit d0294344470e6b52d097aa7369173f32d11f2f52 ] 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: NMike Marciniszyn <mike.marciniszyn@intel.com> Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by: NKaike Wan <kaike.wan@intel.com> Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: NJason Gunthorpe <jgg@mellanox.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Kaike Wan 提交于
[ Upstream commit a8639a79e85c18c16c10089edd589c7948f19bbd ] 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: NMike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: NKaike Wan <kaike.wan@intel.com> Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: NJason Gunthorpe <jgg@mellanox.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Tony Lindgren 提交于
[ Upstream commit 36a1da15b5df493241b0011d2185fdd724ac1ed1 ] 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: NHans 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: NTony Lindgren <tony@atomide.com> Reviewed-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326151438.32414-1-tony@atomide.comSigned-off-by: NSasha Levin <sashal@kernel.org>
-
由 Pankaj Bharadiya 提交于
[ Upstream commit cacea3a90e211f0c111975535508d446a4a928d2 ] 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: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Daniel Mack 提交于
[ Upstream commit f0f2338a9cfaf71db895fa989ea7234e8a9b471d ] 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: NDaniel Mack <daniel@zonque.org> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Olivier Moysan 提交于
[ Upstream commit c47255b61129857b74b0d86eaf59335348be05e0 ] Register platform component with a prefix, to avoid warnings on debugfs entries creation, due to component name redundancy. Signed-off-by: NOlivier Moysan <olivier.moysan@st.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Olivier Moysan 提交于
[ Upstream commit 19441e35a43b616ea6afad91ed0d9e77268d8f6a ] The DFSDM must be stopped when a new setting is applied. restart systematically DFSDM on multiple prepare calls, to apply changes. Signed-off-by: NOlivier Moysan <olivier.moysan@st.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Maxime Jourdan 提交于
[ Upstream commit 9b70c697e87286ade406e6a02091757307dd4b7c ] 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: NMaxime Jourdan <mjourdan@baylibre.com> Acked-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com> Link: https://lkml.kernel.org/r/20190319102537.2043-1-mjourdan@baylibre.comSigned-off-by: NSasha Levin <sashal@kernel.org>
-
由 Charles Keepax 提交于
[ Upstream commit a2225a6d155fcb247fe4c6d87f7c91807462966d ] 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: NCharles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Shuming Fan 提交于
[ Upstream commit 1c5b6a27e432e4fe170a924c8b41012271496a4c ] 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: NShuming Fan <shumingf@realtek.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Sylwester Nawrocki 提交于
[ Upstream commit 2b13bee3884926cba22061efa75bd315e871de24 ] 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: NJaeChul Lee <jcsing.lee@samsung.com> Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 John Hsu 提交于
[ Upstream commit 54d1cf78b0f4ba348a7c7fb8b7d0708d71b6cc8a ] 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: NJohn Hsu <KCHSU0@nuvoton.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 John Hsu 提交于
[ Upstream commit 844a4a362dbec166b44d6b9b3dd45b08cb273703 ] 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: NJohn Hsu <KCHSU0@nuvoton.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rander Wang 提交于
[ Upstream commit c899df3e9b0bf7b76e642aed1a214582ea7012d5 ] 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: NRander Wang <rander.wang@linux.intel.com> Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Rander Wang 提交于
[ Upstream commit 570f18b6a8d1f0e60e8caf30e66161b6438dcc91 ] 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: NRander Wang <rander.wang@linux.intel.com> Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Olivier Moysan 提交于
[ Upstream commit b8468192971807c43a80d6e2c41f83141cb7b211 ] 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: NOlivier Moysan <olivier.moysan@st.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Olivier Moysan 提交于
[ Upstream commit 5f8a1000c3e630c3ac06f1d664eeaa755bce8823 ] Allow indexation of sai iec958 controls according to device id. Signed-off-by: NOlivier Moysan <olivier.moysan@st.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Russell King 提交于
[ Upstream commit 2e95f984aae4cf0608d0ba2189c756f2bd50b44a ] 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: NRussell King <rmk+kernel@armlinux.org.uk> Reviewed-by: NJyri Sarha <jsarha@ti.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Philipp Puschmann 提交于
[ Upstream commit 82ad759143ed77673db0d93d53c1cde7b99917ee ] 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: NPhilipp Puschmann <philipp.puschmann@emlix.com> Signed-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Suresh Udipi 提交于
commit af708900e9a48c0aa46070c8a8cdf0608a1d2025 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: NSuresh Udipi <sudipi@jp.adit-jv.com> Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com> Acked-by: NChristian Gromm <christian.gromm@microchip.com> Fixes: aba258b7 ("staging: most: cdev: fix chrdev_region leak") Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
commit 47830c1127ef166af787caf2f871f23089610a7f 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: NJohan Hovold <johan@kernel.org> Reviewed-by: NRui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Andrey Ryabinin 提交于
commit f0996bc2978e02d2ea898101462b960f6119b18f 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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com> Fixes: c6d30853 ("UBSAN: run-time undefined behavior sanity checker") Cc: <stable@vger.kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dexuan Cui 提交于
commit a0033bd1eae4650b69be07c17cb87393da584563 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: NDexuan Cui <decui@microsoft.com> Reviewed-by: NMichael Kelley <mikelley@microsoft.com> Signed-off-by: NSasha Levin (Microsoft) <sashal@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jason Yan 提交于
commit b90cd6f2b905905fb42671009dc0e27c310a16ae 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: Nchenxiang <chenxiang66@hisilicon.com> Signed-off-by: NJason 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: NHannes Reinecke <hare@suse.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Cc: Guenter Roeck <linux@roeck-us.net Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 YueHaibing 提交于
commit f87db4dbd52f2f8a170a2b51cb0926221ca7c9e2 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: 583e63614149 ("net: stmmac: use correct DMA buffer size in the RX descriptor") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Reviewed-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 08 5月, 2019 10 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
由 Arnd Bergmann 提交于
commit dce5b0bdeec61bdbee56121ceb1d014151d5cab1 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: 298a32b13208 ("kmemleak: powerpc: skip scanning holes in the .bss section") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NCatalin Marinas <catalin.marinas@arm.com> Cc: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Charles Keepax 提交于
commit 43d147be5738a9ed6cfb25c285ac50d6dd5793be 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: 639e5eb3c7d6 ("ASoC: wm_adsp: Correct handling of compressed streams that restart") Signed-off-by: NCharles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jacopo Mondi 提交于
commit 61da76beef1e4f0b6ba7be4f8d0cf0dac7ce1f55 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: NJacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Nicolas Le Bayon 提交于
commit c86da50cfd840edf223a242580913692acddbcf6 upstream. It conforms with Reference Manual I2C timing section. Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver") Signed-off-by: NNicolas Le Bayon <nicolas.le.bayon@st.com> Signed-off-by: NBich Hemon <bich.hemon@st.com> Reviewed-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Zijlstra 提交于
commit 780e0106d468a2962b16b52fdf42898f2639e0a0 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: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Acked-by: NNadav 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: NIngo Molnar <mingo@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Qian Cai 提交于
commit 0d02113b31b2017dd349ec9df2314e798a90fa6e 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: NQian Cai <cai@lca.pw> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190423165811.36699-1-cai@lca.pwSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Baoquan He 提交于
commit ec3937107ab43f3e8b2bc9dad95710043c462ff7 upstream. kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate the maximum amount of system RAM supported. The size of the direct mapping section is obtained from the smaller one of the below two values: (actual system RAM size + padding size) vs (max system RAM size supported) This calculation is wrong since commit b83ce5ee ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"). In it, __PHYSICAL_MASK_SHIFT was changed to be 52, regardless of whether the kernel is using 4-level or 5-level page tables. Thus, it will always use 4 PB as the maximum amount of system RAM, even in 4-level paging mode where it should actually be 64 TB. Thus, the size of the direct mapping section will always be the sum of the actual system RAM size plus the padding size. Even when the amount of system RAM is 64 TB, the following layout will still be used. Obviously KALSR will be weakened significantly. |____|_______actual RAM_______|_padding_|______the rest_______| 0 64TB ~120TB Instead, it should be like this: |____|_______actual RAM_______|_________the rest______________| 0 64TB ~120TB The size of padding region is controlled by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, which is 10 TB by default. The above issue only exists when CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is set to a non-zero value, which is the case when CONFIG_MEMORY_HOTPLUG is enabled. Otherwise, using __PHYSICAL_MASK_SHIFT doesn't affect KASLR. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. [ bp: Massage commit message. ] Fixes: b83ce5ee ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52") Signed-off-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NThomas Garnier <thgarnie@google.com> Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: frank.ramsay@hpe.com Cc: herbert@gondor.apana.org.au Cc: kirill@shutemov.name Cc: mike.travis@hpe.com Cc: thgarnie@google.com Cc: x86-ml <x86@kernel.org> Cc: yamada.masahiro@socionext.com Link: https://lkml.kernel.org/r/20190417083536.GE7065@MiWiFi-R3L-srvSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 David Müller 提交于
commit 7c2e07130090ae001a97a6b65597830d6815e93e upstream. Since commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are unconditionally gated off. Unfortunately this will break systems where these clocks are used for external purposes beyond the kernel's knowledge. Fix it by implementing a system specific quirk to mark the necessary pmc_plt_clks as critical. Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by: NDavid Müller <dave.mueller@gmx.ch> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: NStephen Boyd <sboyd@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Tony Luck 提交于
commit 41f035a86b5b72a4f947c38e94239d20d595352a upstream. In c7d606f5 ("x86/mce: Improve error message when kernel cannot recover") a case was added for a machine check caused by a DATA access to poison memory from the kernel. A case should have been added also for an uncorrectable error during an instruction fetch in the kernel. Add that extra case so the error message now reads: mce: [Hardware Error]: Machine check: Instruction fetch error in kernel Fixes: c7d606f5 ("x86/mce: Improve error message when kernel cannot recover") Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Pu Wen <puwen@hygon.cn> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190225205940.15226-1-tony.luck@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-