- 25 Mar, 2020 38 commits
-
-
Johan Hovold authored
commit 8f3675be upstream. A scripted conversion from userland POLL* to kernel EPOLL* constants mistakingly replaced the poll flags in the loopback_test tool, which therefore no longer builds. Fixes: a9a08845 ("vfs: do bulk POLL* -> EPOLL* replacement") Cc: stable <stable@vger.kernel.org> # 4.16 Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200312110151.22028-2-johan@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Straube authored
commit bb5786b9 upstream. This device was added to the stand-alone driver on github. Add it to the staging driver as well. Link: https://github.com/lwfinger/rtl8188eu/commit/2141f244c3e7Signed-off-by:
Michael Straube <straube.linux@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312093652.13918-1-straube.linux@gmail.comSigned-off-by:
-
Michał Mirosław authored
commit 53dd0a7c upstream. SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least SAMA5D27 doesn't). Fix this by forcing card-detect in the module if module-controlled CD is not used. Fixed commit addresses the problem only for non-removable cards. This amends it to also cover gpio-cd case. Cc: stable@vger.kernel.org Fixes: 7a1e3f14 ("mmc: sdhci-of-at91: force card detect value for non removable devices") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.plSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Ricky Wu authored
commit 4686392c upstream. The TX/RX register should not be treated the same way to allow for better support of tuning. Fix this by using a default initial value for TX. Signed-off-by:
Ricky Wu <ricky_wu@realtek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com [Ulf: Updated changelog] Signed-off-by:
-
Eugen Hristev authored
commit a500f3bd upstream. The differential channels require writing the channel offset register (COR). Otherwise they do not work in differential mode. The configuration of COR is missing in triggered mode. Fixes: 5e1a1da0 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Stephan Gerhold authored
commit b500c086 upstream. At the moment, reading from in_magn_*_raw in sysfs tends to return large values around 65000, even though the output of ak8974 is actually limited to ±32768. This happens because the value is never converted to the signed 16-bit integer variant. Add an explicit cast to s16 to fix this. Fixes: 7c94a8b2 ("iio: magn: add a driver for AK8974") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Waleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Fabrice Gasnier authored
commit 29e8c825 upstream. Master mode should be disabled when stopping. This mainly impacts possible other use-case after timer has been stopped. Currently, master mode remains set (from start routine). Fixes: 6fb34812 ("iio: stm32 trigger: Add support for TRGO2 triggers") Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Wen-chien Jesse Sung authored
commit e43d110c upstream. According to ST, the HID is for LIS2DH12. Fixes: 3d56e198 ("iio: accel: st_accel: Add support for the SMO8840 ACPI id") Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Tested-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Takashi Iwai authored
commit 5461e053 upstream. The return value checks in snd_pcm_plug_alloc() are covered with snd_BUG_ON() macro that may trigger a kernel WARNING depending on the kconfig. But since the error condition can be triggered by a weird user space parameter passed to OSS layer, we shouldn't give the kernel stack trace just for that. As it's a normal error condition, let's remove snd_BUG_ON() macro usage there. Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit f2ecf903 upstream. Each OSS PCM plugins allocate its internal buffer per pre-calculation of the max buffer size through the chain of plugins (calling src_frames and dst_frames callbacks). This works for most plugins, but the rate plugin might behave incorrectly. The calculation in the rate plugin involves with the fractional position, i.e. it may vary depending on the input position. Since the buffer size pre-calculation is always done with the offset zero, it may return a shorter size than it might be; this may result in the out-of-bound access as spotted by fuzzer. This patch addresses those possible buffer overflow accesses by simply setting the upper limit per the given buffer size for each plugin before src_frames() and after dst_frames() calls. Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
commit 6c3171ef upstream. This is a similar bug like the previous case for virmidi: the invalid running status is kept after receiving a sysex message. Again the fix is to clear the running status after handling the sysex. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
commit 4384f167 upstream. The virmidi driver handles sysex event exceptionally in a short-cut snd_seq_dump_var_event() call, but this missed the reset of the running status. As a result, it may lead to an incomplete command right after the sysex when an event with the same running status was queued. Fix it by clearing the running status properly via alling snd_midi_event_reset_decode() for that code path. Reported-by:
Andreas Steinmetz <ast@domdv.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
commit d683469b upstream. The MIDI input event parser of the LINE6 driver may enter into an endless loop when the unexpected data sequence is given, as it tries to continue the secondary bytes without termination. Also, when the input data is too short, the parser returns a negative error, while the caller doesn't handle it properly. This would lead to the unexpected behavior as well. This patch addresses those issues by checking the return value correctly and handling the one-byte event in the parser properly. The bug was reported by syzkaller. Reported-by: syzbot+cce32521ee0a824c21f7@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000033087059f8f8fa3@google.com Link: https://lore.kernel.org/r/20200309095922.30269-1-tiwai@suse.deSigned-off-by:
-
Alberto Mattea authored
commit 16263abc upstream. This controller timeouts during suspend (S3) with [ 240.521724] xhci_hcd 0000:30:00.3: WARN: xHC save state timeout [ 240.521729] xhci_hcd 0000:30:00.3: ERROR mismatched command completion event thus preventing the system from entering S3. Moreover it remains in an undefined state where some connected devices stop working until a reboot. Apply the XHCI_SUSPEND_DELAY quirk to make it suspend properly. CC: stable@vger.kernel.org Signed-off-by:
Alberto Mattea <alberto@mattea.info> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200306150858.21904-3-mathias.nyman@linux.intel.comSigned-off-by:
-
Scott Chen authored
commit cecc113c upstream. Add a device id for HP LD381 Display LD381: 03f0:0f7f Signed-off-by:
Scott Chen <scott@labau.com.tw> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Ran Wang authored
commit b433e340 upstream. When loading new kernel via kexec, we need to shutdown host controller to avoid any un-expected memory accessing during new kernel boot. Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Cc: stable <stable@vger.kernel.org> Tested-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.comSigned-off-by:
-
Daniele Palmas authored
commit 8e852a79 upstream. Add ME910G1 ECM composition 0x110b: tty, tty, tty, ecm Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20200304104310.2938-1-dnlplm@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Hans de Goede authored
commit 75d7676e upstream. We have been receiving bug reports that ethernet connections over RTL8153 based ethernet adapters stops working after a while with errors like these showing up in dmesg when the ethernet stops working: [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1 docks and with generic USB to ethernet dongles using the RTL8153 chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to the kernel commandline and all users who have tried this report that this fixes this. Also note that we already have an existing NO_LPM quirk for the RTL8153 used in the Microsoft Surface Dock (where it uses a different usb-id). This commit adds a NO_LPM quirk for the generic Realtek RTL8153 0bda:8153 usb-id, fixing the Tx timeout errors on these devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931 Cc: stable@vger.kernel.org Cc: russianneuromancer@ya.ru Signed-off-by:
-
Kai-Heng Feng authored
commit b63e48fb upstream. Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the bus when bringing underlying ports from U3 to U0. Disabling LPM on the hub during setting link state is not enough, so let's disable LPM completely for this hub. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200205112633.25995-3-kai.heng.feng@canonical.comSigned-off-by:
-
Jonathan Neuschäfer authored
[ Upstream commit 611d61f9 ] This makes the script more convenient to run. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Carlo Nonato authored
[ Upstream commit 14afc593 ] The bfq_find_set_group() function takes as input a blkcg (which represents a cgroup) and retrieves the corresponding bfq_group, then it updates the bfq internal group hierarchy (see comments inside the function for why this is needed) and finally it returns the bfq_group. In the hierarchy update cycle, the pointer holding the correct bfq_group that has to be returned is mistakenly used to traverse the hierarchy bottom to top, meaning that in each iteration it gets overwritten with the parent of the current group. Since the update cycle stops at root's children (depth = 2), the overwrite becomes a problem only if the blkcg describes a cgroup at a hierarchy level deeper than that (depth > 2). In this case the root's child that happens to be also an ancestor of the correct bfq_group is returned. The main consequence is that processes contained in a cgroup at depth greater than 2 are wrongly placed in the group described above by BFQ. This commits fixes this problem by using a different bfq_group pointer in the update cycle in order to avoid the overwrite of the variable holding the original group reference. Reported-by:
Kwon Je Oh <kwonje.oh2@gmail.com> Signed-off-by:
Carlo Nonato <carlo.nonato95@gmail.com> Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Dongli Zhang authored
[ Upstream commit 8130b9d5 ] This patch adds the barrier to guarantee that req->err is always updated before req->state. Otherwise, read_reply() would not return ERR_PTR(req->err) but req->body, when process_writes()->xb_write() is failed. Signed-off-by:
Dongli Zhang <dongli.zhang@oracle.com> Link: https://lore.kernel.org/r/20200303221423.21962-2-dongli.zhang@oracle.comReviewed-by:
Julien Grall <jgrall@amazon.com> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Dongli Zhang authored
[ Upstream commit 1b6a51e8 ] The req->body should be updated before req->state is updated and the order should be guaranteed by a barrier. Otherwise, read_reply() might return req->body = NULL. Below is sample callstack when the issue is reproduced on purpose by reordering the updates of req->body and req->state and adding delay in code between updates of req->state and req->body. [ 22.356105] general protection fault: 0000 [#1] SMP PTI [ 22.361185] CPU: 2 PID: 52 Comm: xenwatch Not tainted 5.5.0xen+ #6 [ 22.366727] Hardware name: Xen HVM domU, BIOS ... [ 22.372245] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60 ... ... [ 22.392163] RSP: 0018:ffffb2d64023fdf0 EFLAGS: 00010246 [ 22.395933] RAX: 0000000000000000 RBX: 75746e7562755f6d RCX: 0000000000000000 [ 22.400871] RDX: 0000000000000000 RSI: ffffb2d64023fdfc RDI: 75746e7562755f6d [ 22.405874] RBP: 0000000000000000 R08: 00000000000001e8 R09: 0000000000cdcdcd [ 22.410945] R10: ffffb2d6402ffe00 R11: ffff9d95395eaeb0 R12: ffff9d9535935000 [ 22.417613] R13: ffff9d9526d4a000 R14: ffff9d9526f4f340 R15: ffff9d9537654000 [ 22.423726] FS: 0000000000000000(0000) GS:ffff9d953bc80000(0000) knlGS:0000000000000000 [ 22.429898] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 22.434342] CR2: 000000c4206a9000 CR3: 00000001ea3fc002 CR4: 00000000001606e0 [ 22.439645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 22.444941] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 22.450342] Call Trace: [ 22.452509] simple_strtoull+0x27/0x70 [ 22.455572] xenbus_transaction_start+0x31/0x50 [ 22.459104] netback_changed+0x76c/0xcc1 [xen_netfront] [ 22.463279] ? find_watch+0x40/0x40 [ 22.466156] xenwatch_thread+0xb4/0x150 [ 22.469309] ? wait_woken+0x80/0x80 [ 22.472198] kthread+0x10e/0x130 [ 22.474925] ? kthread_park+0x80/0x80 [ 22.477946] ret_from_fork+0x35/0x40 [ 22.480968] Modules linked in: xen_kbdfront xen_fbfront(+) xen_netfront xen_blkfront [ 22.486783] ---[ end trace a9222030a747c3f7 ]--- [ 22.490424] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60 The virt_rmb() is added in the 'true' path of test_reply(). The "while" is changed to "do while" so that test_reply() is used as a read memory barrier. Signed-off-by:
-
Josip Pavic authored
[ Upstream commit a0275dfc ] [Why] Swath sizes are being calculated incorrectly. The horizontal swath size should be the product of block height, viewport width, and bytes per element, but the calculation uses viewport height instead of width. The vertical swath size is similarly incorrectly calculated. The effect of this is that we report the wrong DCC caps. [How] Use viewport width in the horizontal swath size calculation and viewport height in the vertical swath size calculation. Signed-off-by:
Josip Pavic <Josip.Pavic@amd.com> Reviewed-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Bhawanpreet Lakha authored
[ Upstream commit 5ac7fd2f ] [Why] If we have a single MST display and we disconnect it, we dont disable that link. This causes the old link settings to still exist Now on a replug for MST we think its a link loss and will try to reallocate mst payload which will fail, throwing warning below. [ 129.374192] [drm] Failed to updateMST allocation table forpipe idx:0 [ 129.374206] ------------[ cut here ]------------ [ 129.374284] WARNING: CPU: 14 PID: 1710 at drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/core/dc_link.c:3153 dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu] [ 129.374285] Modules linked in: amdgpu(OE) amd_iommu_v2 gpu_sched ttm drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt binfmt_misc nls_iso8859_1 edac_mce_amd snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio kvm snd_hda_codec_hdmi snd_hda_intel snd_intel_nhlt snd_hda_codec irqbypass snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul snd_seq crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer snd aesni_intel eeepc_wmi crypto_simd asus_wmi joydev cryptd sparse_keymap input_leds soundcore video glue_helper wmi_bmof mxm_wmi k10temp ccp mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid igb i2c_algo_bit ahci dca i2c_piix4 libahci gpio_amdpt wmi gpio_generic [ 129.374318] CPU: 14 PID: 1710 Comm: kworker/14:2 Tainted: G W OE 5.4.0-rc7bhawan+ #480 [ 129.374318] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0515 03/30/2017 [ 129.374397] Workqueue: events dm_irq_work_func [amdgpu] [ 129.374468] RIP: 0010:dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu] [ 129.374470] Code: 52 20 e8 1c 63 ad f4 48 8b 5d d0 65 48 33 1c 25 28 00 00 00 b8 01 00 00 00 75 16 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e9 fa fe ff ff e8 ed 5b d6 f3 41 0f b6 b6 c4 02 00 00 48 c7 [ 129.374471] RSP: 0018:ffff9f9141e7fcc0 EFLAGS: 00010246 [ 129.374472] RAX: 0000000000000000 RBX: ffff91ef0762f800 RCX: 0000000000000000 [ 129.374473] RDX: 0000000000000005 RSI: ffffffffc0c4a988 RDI: 0000000000000004 [ 129.374474] RBP: ffff9f9141e7fd10 R08: 0000000000000005 R09: 0000000000000000 [ 129.374475] R10: 0000000000000002 R11: 0000000000000001 R12: ffff91eebd510c00 [ 129.374475] R13: ffff91eebd510e58 R14: ffff91ef052c01b8 R15: 0000000000000006 [ 129.374476] FS: 0000000000000000(0000) GS:ffff91ef0ef80000(0000) knlGS:0000000000000000 [ 129.374477] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 129.374478] CR2: 000055623ea01d50 CR3: 0000000408a8c000 CR4: 00000000003406e0 [ 129.374479] Call Trace: [ 129.374550] dc_link_reallocate_mst_payload+0x12e/0x150 [amdgpu] [ 129.374617] dc_link_handle_hpd_rx_irq+0x6d4/0x6e0 [amdgpu] [ 129.374693] handle_hpd_rx_irq+0x77/0x310 [amdgpu] [ 129.374768] dm_irq_work_func+0x53/0x70 [amdgpu] [ 129.374774] process_one_work+0x1fd/0x3f0 [ 129.374776] worker_thread+0x255/0x410 [ 129.374778] kthread+0x121/0x140 [ 129.374780] ? process_one_work+0x3f0/0x3f0 [ 129.374781] ? kthread_park+0x90/0x90 [ 129.374785] ret_from_fork+0x22/0x40 [How] when we disable MST we should clear the cur link settings (lane_count=0 is good enough). This will cause us to not reallocate payloads earlier than expected and not throw the warning Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
Vincent Chen authored
[ Upstream commit 0cff8bff ] The compiler uses the PIC-relative method to access static variables instead of GOT when the code model is PIC. Therefore, the limitation of the access range from the instruction to the symbol address is +-2GB. Under this circumstance, the kernel cannot load a kernel module if this module has static per-CPU symbols declared by DEFINE_PER_CPU(). The reason is that kernel relocates the .data..percpu section of the kernel module to the end of kernel's .data..percpu. Hence, the distance between the per-CPU symbols and the instruction will exceed the 2GB limits. To solve this problem, the kernel should place the loaded module in the memory area [&_end-2G, VMALLOC_END]. Signed-off-by:
Vincent Chen <vincent.chen@sifive.com> Suggested-by:
Alexandre Ghiti <alex@ghiti.fr> Suggested-by:
Anup Patel <anup@brainfault.org> Tested-by:
Carlos de Paula <me@carlosedp.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
-
Mike Snitzer authored
[ Upstream commit 248aa264 ] In cases where dec_in_flight() has to requeue the integrity_bio_wait work to transfer the rest of the data, the bio's __bi_remaining might already have been decremented to 0, e.g.: if bio passed to underlying data device was split via blk_queue_split(). Use dm_bio_{record,restore} rather than effectively open-coding them in dm-integrity -- these methods now manage __bi_remaining too. Depends-on: f7f0b057a9c1 ("dm bio record: save/restore bi_end_io and bi_integrity") Reported-by:
Daniel Glöckner <dg@emlix.com> Suggested-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mike Snitzer authored
[ Upstream commit 1b17159e ] Also, save/restore __bi_remaining in case the bio was used in a BIO_CHAIN (e.g. due to blk_queue_split). Suggested-by:
-
Daniel Axtens authored
[ Upstream commit 3745488e ] altera_get_note is called from altera_init, where key is kzalloc(33). When the allocation functions are annotated to allow the compiler to see the sizes of objects, and with FORTIFY_SOURCE, we see: In file included from drivers/misc/altera-stapl/altera.c:14:0: In function ‘strlcpy’, inlined from ‘altera_init’ at drivers/misc/altera-stapl/altera.c:2189:5: include/linux/string.h:378:4: error: call to ‘__write_overflow’ declared with attribute error: detected write beyond size of object passed as 1st parameter __write_overflow(); ^~~~~~~~~~~~~~~~~~ That refers to this code in altera_get_note: if (key != NULL) strlcpy(key, &p[note_strings + get_unaligned_be32( &p[note_table + (8 * i)])], length); The error triggers because the length of 'key' is 33, but the copy uses length supplied as the 'length' parameter, which is always 256. Split the size parameter into key_len and val_len, and use the appropriate length depending on what is being copied. Detected by compiler error, only compile-tested. Cc: "Igor M. Liplianin" <liplianin@netup.ru> Signed-off-by:
Daniel Axtens <dja@axtens.net> Link: https://lore.kernel.org/r/20200120074344.504-2-dja@axtens.netSigned-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/202002251042.D898E67AC@keescookSigned-off-by:
-
luanshi authored
[ Upstream commit 3ba52ad5 ] Fix bogus NULL checks on the return value of acpi_cpu_get_madt_gicc() by checking for a 0 'gicc->performance_interrupt' value instead. Signed-off-by:
Liguang Zhang <zhangliguang@linux.alibaba.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit c0fd99d6 ] Writing to the built-in strings arrays doesn't work if driver is loaded as kernel module. This is also considered as a bad pattern. Fix this by adding a call to clk_get() with legacy clock name. This fixes following kernel oops if driver is loaded as module: Unable to handle kernel paging request at virtual address bf047978 pgd = (ptrval) [bf047978] *pgd=59344811, *pte=5903c6df, *ppte=5903c65f Internal error: Oops: 80f [#1] SMP ARM Modules linked in: mc exynosdrm(+) analogix_dp rtc_s3c exynos_ppmu i2c_gpio CPU: 1 PID: 212 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200219 #326 videodev: Linux video capture interface: v2.00 Hardware name: Samsung Exynos (Flattened Device Tree) PC is at exynos_dsi_probe+0x1f0/0x384 [exynosdrm] LR is at exynos_dsi_probe+0x1dc/0x384 [exynosdrm] ... Process systemd-udevd (pid: 212, stack limit = 0x(ptrval)) ... [<bf03cf14>] (exynos_dsi_probe [exynosdrm]) from [<c09b1ca0>] (platform_drv_probe+0x6c/0xa4) [<c09b1ca0>] (platform_drv_probe) from [<c09afcb8>] (really_probe+0x210/0x350) [<c09afcb8>] (really_probe) from [<c09aff74>] (driver_probe_device+0x60/0x1a0) [<c09aff74>] (driver_probe_device) from [<c09b0254>] (device_driver_attach+0x58/0x60) [<c09b0254>] (device_driver_attach) from [<c09b02dc>] (__driver_attach+0x80/0xbc) [<c09b02dc>] (__driver_attach) from [<c09ade00>] (bus_for_each_dev+0x68/0xb4) [<c09ade00>] (bus_for_each_dev) from [<c09aefd8>] (bus_add_driver+0x130/0x1e8) [<c09aefd8>] (bus_add_driver) from [<c09b0d64>] (driver_register+0x78/0x110) [<c09b0d64>] (driver_register) from [<bf038558>] (exynos_drm_init+0xe8/0x11c [exynosdrm]) [<bf038558>] (exynos_drm_init [exynosdrm]) from [<c0302fa8>] (do_one_initcall+0x50/0x220) [<c0302fa8>] (do_one_initcall) from [<c03dd02c>] (do_init_module+0x60/0x210) [<c03dd02c>] (do_init_module) from [<c03dbf44>] (load_module+0x1c0c/0x2310) [<c03dbf44>] (load_module) from [<c03dc85c>] (sys_finit_module+0xac/0xbc) [<c03dc85c>] (sys_finit_module) from [<c0301000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xd979bfa8 to 0xd979bff0) ... ---[ end trace db16efe05faab470 ]--- Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 0a9d1e3f ] Properly propagate error value from devm_regulator_bulk_get() and don't confuse user with meaningless warning about failure in getting regulators in case of deferred probe. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Thommy Jakobsson authored
[ Upstream commit 5dd83049 ] In the public interface for chipselect, there is always an entry commented as "Dummy generic FIFO entry" pushed down to the fifo right after the activate/deactivate command. The dummy entry is 0x0, irregardless if the intention was to activate or deactive the cs. This causes the cs line to glitch rather than beeing activated in the case when there was an activate command. This has been observed on oscilloscope, and have caused problems for at least one specific flash device type connected to the qspi port. After the change the glitch is gone and cs goes active when intended. The reason why this worked before (except for the glitch) was because when sending the actual data, the CS bits are once again set. Since most flashes uses mode 0, there is always a half clk period anyway for cs to clk active setup time. If someone would rely on timing from a chip_select call to a transfer_one, it would fail though. It is unknown why the dummy entry was there in the first place, git log seems to be of no help in this case. The reference manual gives no indication of the necessity of this. In fact the lower 8 bits are a setup (or hold in case of deactivate) time expressed in cycles. So this should not be needed to fulfill any setup/hold timings. Signed-off-by:
Thommy Jakobsson <thommyj@gmail.com> Reviewed-by:
Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Link: https://lore.kernel.org/r/20200224162643.29102-1-thommyj@gmail.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Evan Green authored
[ Upstream commit 683f65de ] In some circumstances on Intel LPSS controllers, toggling the LPSS CS control register doesn't actually cause the CS line to toggle. This seems to be failure of dynamic clock gating that occurs after going through a suspend/resume transition, where the controller is sent through a reset transition. This ruins SPI transactions that either rely on delay_usecs, or toggle the CS line without sending data. Whenever CS is toggled, momentarily set the clock gating register to "Force On" to poke the controller into acting on CS. Signed-off-by:
Rajat Jain <rajatja@google.com> Signed-off-by:
Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20200211223700.110252-1-rajatja@google.comSigned-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit 27f13774 ] 'dma-ranges' in a PCI bridge node does correctly set dma masks for PCI devices not described in the DT. Certain DRA7 platforms (e.g., DRA76) has RAM above 32-bit boundary (accessible with LPAE config) though the PCIe bridge will be able to access only 32-bits. Add 'dma-ranges' property in PCIe RC DT nodes to indicate the host bridge can access only 32 bits. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Naveen N. Rao authored
[ Upstream commit cb0cc635 ] Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld: ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed in section `.BTF' Include .BTF section in vmlinux explicitly to fix the same. Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200220113132.857132-1-naveen.n.rao@linux.vnet.ibm.comSigned-off-by:
-
Yuji Sasaki authored
[ Upstream commit 136b5cd2 ] spi_qup_suspend() will cause synchronous external abort when runtime suspend is enabled and applied, as it tries to access SPI controller register while clock is already disabled in spi_qup_pm_suspend_runtime(). Signed-off-by:
Yuji sasaki <sasakiy@chromium.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200214074340.2286170-1-vkoul@kernel.orgSigned-off-by:
-
Evan Benn authored
[ Upstream commit 318caac7 ] The cursor and primary planes were hard coded. Now search for them for passing to drm_crtc_init_with_planes Signed-off-by:
Evan Benn <evanbenn@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
CK Hu <ck.hu@mediatek.com> Signed-off-by:
-
- 20 Mar, 2020 2 commits
-
-
Greg Kroah-Hartman authored
-
Matteo Croce authored
commit 3e72dfdf upstream. Similarly to commit c543cb4a ("ipv4: ensure rcu_read_lock() in ipv4_link_failure()"), __ip_options_compile() must be called under rcu protection. Fixes: 3da1ed7a ("net: avoid use IPCB in cipso_v4_error") Suggested-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Matteo Croce <mcroce@redhat.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
