- 07 10月, 2020 1 次提交
-
-
由 Karol Herbst 提交于
Previously the code relied on device->pri to be NULL and to fail probing later. We really should just return an error inside nvkm_device_ctor for unsupported GPUs. Fixes: 24d5ff40 ("drm/nouveau/device: rework mmio mapping code to get rid of second map") Signed-off-by: NKarol Herbst <kherbst@redhat.com> Cc: dann frazier <dann.frazier@canonical.com> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Dave Airlie <airlied@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: NJeremy Cline <jcline@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-1-kherbst@redhat.com
-
- 01 10月, 2020 7 次提交
-
-
由 Lu Baolu 提交于
Lock(&iommu->lock) without disabling irq causes lockdep warnings. [ 12.703950] ======================================================== [ 12.703962] WARNING: possible irq lock inversion dependency detected [ 12.703975] 5.9.0-rc6+ #659 Not tainted [ 12.703983] -------------------------------------------------------- [ 12.703995] systemd-udevd/284 just changed the state of lock: [ 12.704007] ffffffffbd6ff4d8 (device_domain_lock){..-.}-{2:2}, at: iommu_flush_dev_iotlb.part.57+0x2e/0x90 [ 12.704031] but this lock took another, SOFTIRQ-unsafe lock in the past: [ 12.704043] (&iommu->lock){+.+.}-{2:2} [ 12.704045] and interrupts could create inverse lock ordering between them. [ 12.704073] other info that might help us debug this: [ 12.704085] Possible interrupt unsafe locking scenario: [ 12.704097] CPU0 CPU1 [ 12.704106] ---- ---- [ 12.704115] lock(&iommu->lock); [ 12.704123] local_irq_disable(); [ 12.704134] lock(device_domain_lock); [ 12.704146] lock(&iommu->lock); [ 12.704158] <Interrupt> [ 12.704164] lock(device_domain_lock); [ 12.704174] *** DEADLOCK *** Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20200927062428.13713-1-baolu.lu@linux.intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Juergen Gross 提交于
Since commit c330fb1d ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.") Xen is using the chip_data pointer for storing IRQ specific data. When running as a HVM domain this can result in problems for legacy IRQs, as those might use chip_data for their own purposes. Use a local array for this purpose in case of legacy IRQs, avoiding the double use. Cc: stable@vger.kernel.org Fixes: c330fb1d ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.") Signed-off-by: NJuergen Gross <jgross@suse.com> Tested-by: NStefan Bader <stefan.bader@canonical.com> Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20200930091614.13660-1-jgross@suse.comSigned-off-by: NJuergen Gross <jgross@suse.com>
-
由 Adrian Huang 提交于
Commit 387caf0b ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions") accidentally overwrites the 'flags' field in IVMD (struct ivmd_header) when the I/O virtualization memory definition is associated with the exclusion range entry. This leads to the corrupted IVMD table (incorrect checksum). The kdump kernel reports the invalid checksum: ACPI BIOS Warning (bug): Incorrect checksum in table [IVRS] - 0x5C, should be 0x60 (20200717/tbprint-177) AMD-Vi: [Firmware Bug]: IVRS invalid checksum Fix the above-mentioned issue by modifying the 'struct unity_map_entry' member instead of the IVMD header. Cleanup: The *exclusion_range* functions are not used anymore, so get rid of them. Fixes: 387caf0b ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions") Reported-and-tested-by: NBaoquan He <bhe@redhat.com> Signed-off-by: NAdrian Huang <ahuang12@lenovo.com> Cc: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20200926102602.19177-1-adrianhuang0701@gmail.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Andy Shevchenko 提交于
When driver has been converted to the bitmap API the non-bitmap functions started behaving differently on 32-bit BE architectures since the bytes in two consequent unsigned longs are in different order in comparison to byte array. Hence if the chip had had more than 32 lines the memset() call over it would have not set up upper lines correctly. Although it's currently a theoretical case (no supported chips of this type has 32+ lines), it's better to provide a clean code to avoid people thinking this is okay and potentially producing not fully working things. Fixes: 35d13d94 ("gpio: pca953x: convert to use bitmap API") Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200930142013.59247-2-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Andy Shevchenko 提交于
In IRQ handler we have to clear bitmap before use. Currently the GCC extension has been used for that. For sake of the consistency switch to bitmap API. As expected bloat-o-meter shows no difference in the object size. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NBartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200930142013.59247-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Hanks Chen 提交于
check mtk_is_virt_gpio input parameter, virtual gpio need to support eint mode. add error handler for the ko case to fix this boot fail: pc : mtk_is_virt_gpio+0x20/0x38 [pinctrl_mtk_common_v2] lr : mtk_gpio_get_direction+0x44/0xb0 [pinctrl_paris] Fixes: edd54646 ("pinctrl: mediatek: avoid virtual gpio trying to set reg") Signed-off-by: NHanks Chen <hanks.chen@mediatek.com> Acked-by: NSean Wang <sean.wang@kernel.org> Singed-off-by: NJie Yang <sin_jieyang@mediatek.com> Link: https://lore.kernel.org/r/1597922546-29633-1-git-send-email-hanks.chen@mediatek.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Dmitry Baryshkov 提交于
Correct sdc2_clk pin definition (register offset is wrong, verified by the msm-4.19 driver). Fixes: 4e3ec9e4 ("pinctrl: qcom: Add sm8250 pinctrl driver.") Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org> Acked-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20200914091846.55204-1-dmitry.baryshkov@linaro.orgSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 30 9月, 2020 14 次提交
-
-
由 Zhang Rui 提交于
Fix missing return statement when writing "off" to intel_pstate status sysfs I/F. Fixes: 55671ea3 ("cpufreq: intel_pstate: Free memory only when turning off") Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Peter Collingbourne 提交于
Also partially revert the follow-up change "drm: pl111: Absorb the external register header". This reverts the parts of commits 7e4e589d and 0fb81256 that touch paths outside of drivers/gpu/drm/pl111. The fbdev driver is used by Android's FVP configuration. Using the DRM driver together with DRM's fbdev emulation results in a failure to boot Android. The root cause is that Android's generic fbdev userspace driver relies on the ability to set the pixel format via FBIOPUT_VSCREENINFO, which is not supported by fbdev emulation. There have been other less critical behavioral differences identified between the fbdev driver and the DRM driver with fbdev emulation. The DRM driver exposes different values for the panel's width, height and refresh rate, and the DRM driver fails a FBIOPUT_VSCREENINFO syscall with yres_virtual greater than the maximum supported value instead of letting the syscall succeed and setting yres_virtual based on yres. Signed-off-by: NPeter Collingbourne <pcc@google.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200929195344.2219796-1-pcc@google.com
-
由 Jiansong Chen 提交于
gfxoff is temporarily disabled for navy_flounder, since at present the feature caused some tdr when performing display operations. Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: NTao Zhou <tao.zhou1@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
As the dpm clock table is needed during DC HW initialization. And that (DC HW initialization) comes before smu_late_init() where current APU dpm clock table setup is performed. So, NULL pointer dereference will be triggered. By moving APU dpm clock table setup to smu_hw_init(), this can be avoided. Fixes: 02cf91c1 ("drm/amd/powerplay: postpone operations not required for hw setup to late_init") Acked-by: NNirmoy Das <nirmoy.das@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NEvan Quan <evan.quan@amd.com> Reported-by: NDirk Gouders <dirk@gouders.net> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Palmer Dabbelt 提交于
clint_time_val will soon be used by the RISC-V implementation of random_get_entropy(), which is a static inline function that may be used by modules (at least CRYPTO_JITTERENTROPY=m). Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
-
由 Zack Rusin 提交于
ttm_mem_type_manager_func.get_node was changed to return -ENOSPC instead of setting the node pointer to NULL. Unfortunately vmwgfx still had two places where it was explicitly converting -ENOSPC to 0 causing regressions. This fixes those spots by allowing -ENOSPC to be returned. That seems to fix recent regressions with vmwgfx. Signed-off-by: NZack Rusin <zackr@vmware.com> Reviewed-by: NRoland Scheidegger <sroland@vmware.com> Reviewed-by: NMartin Krastev <krastevm@vmware.com> Sigend-off-by: NRoland Scheidegger <sroland@vmware.com>
-
由 Mark Mielke 提交于
The kernel may fail to boot or devices may fail to come up when initializing iscsi_tcp devices starting with Linux 5.8. Commit a79af8a6 ("[SCSI] iscsi_tcp: use iscsi_conn_get_addr_param libiscsi function") introduced getpeername() within the session spinlock. Commit 1b66d253 ("bpf: Add get{peer, sock}name attach types for sock_addr") introduced BPF_CGROUP_RUN_SA_PROG_LOCK() within getpeername(), which acquires a mutex and when used from iscsi_tcp devices can now lead to "BUG: scheduling while atomic:" and subsequent damage. Ensure that the spinlock is released before calling getpeername() or getsockname(). sock_hold() and sock_put() are used to ensure that the socket reference is preserved until after the getpeername() or getsockname() complete. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1877345 Link: https://lkml.org/lkml/2020/7/28/1085 Link: https://lkml.org/lkml/2020/8/31/459 Link: https://lore.kernel.org/r/20200928043329.606781-1-mark.mielke@gmail.com Fixes: a79af8a6 ("[SCSI] iscsi_tcp: use iscsi_conn_get_addr_param libiscsi function") Fixes: 1b66d253 ("bpf: Add get{peer, sock}name attach types for sock_addr") Cc: stable@vger.kernel.org Reported-by: NMarc Dionne <marc.c.dionne@gmail.com> Tested-by: NMarc Dionne <marc.c.dionne@gmail.com> Reviewed-by: NMike Christie <michael.christie@oracle.com> Signed-off-by: NMark Mielke <mark.mielke@gmail.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Dirk Gouders 提交于
Commit 78fe9f63 ("drm/amd/display: Remove DISPCLK Limit Floor for Certain SMU Versions") added a call to rn_vbios_smu_get_smu_version() to set clk_mgr->smu_ver. That field is initialized prior to the if-statement, already. Fixes: 78fe9f63 (drm/amd/display: Remove DISPCLK Limit Floor for Certain SMU Versions) Signed-off-by: NDirk Gouders <dirk@gouders.net> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Sung Lee <sung.lee@amd.com> Cc: Yongqiang Sun <yongqiang.sun@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
The state array is in the reverse order compared to other asics (high to low rather than low to high). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1313Reviewed-by: NPrike Liang <Prike.Liang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jean Delvare 提交于
A recent attempt to fix a ref count leak in amdgpu_display_crtc_set_config() turned out to be doing too much and "fixed" an intended decrease as if it were a leak. Undo that part to restore the proper balance. This is the very nature of this function to increase or decrease the power reference count depending on the situation. Consequences of this bug is that the power reference would eventually get down to 0 while the display was still in use, resulting in that display switching off unexpectedly. Signed-off-by: NJean Delvare <jdelvare@suse.de> Fixes: e008fa6f ("drm/amdgpu: fix ref count leak in amdgpu_display_crtc_set_config") Cc: stable@vger.kernel.org Cc: Navid Emamdoost <navid.emamdoost@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Properly handle clang and older versions of gcc. Fixes: e77165bf ("drm/amd/display: Add DCN3 blocks to Makefile") Acked-by: NNirmoy Das <nirmoy.das@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Flora Cui 提交于
max_caps might be 0, thus hdcp_work might be ZERO_SIZE_PTR Signed-off-by: NFlora Cui <flora.cui@amd.com> Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jiansong Chen 提交于
Remove gpu_info fw support for sienna_cichlid etc., since the information can be retrieved from discovery binary. Signed-off-by: NJiansong Chen <Jiansong.Chen@amd.com> Reviewed-by: NLikun Gao <Likun.Gao@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Sudheesh Mavila 提交于
SMU10_UMD_PSTATE_PEAK_FCLK value should not be used to set the DPM. Suggested-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NEvan Quan <evan.quan@amd.com> Signed-off-by: NSudheesh Mavila <sudheesh.mavila@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 29 9月, 2020 2 次提交
-
-
由 Jiri Kosina 提交于
Touchpad on this laptop is not detected properly during boot, as PNP enumerates (wrongly) AUX port as disabled on this machine. Fix that by adding this board (with admittedly quite funny DMI identifiers) to nopnp quirk list. Reported-by: NAndrés Barrantes Silman <andresbs2000@protonmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2009252337340.3336@cbobk.fhfr.pm Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Vincent Huang 提交于
Add Synaptics IDs in trackpoint_start_protocol() to mark them as valid. Signed-off-by: NVincent Huang <vincent.huang@tw.synaptics.com> Fixes: 6c77545a ("Input: trackpoint - add new trackpoint variant IDs") Reviewed-by: NHarry Cutts <hcutts@chromium.org> Tested-by: NHarry Cutts <hcutts@chromium.org> Link: https://lore.kernel.org/r/20200924053013.1056953-1-vincent.huang@tw.synaptics.comSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 28 9月, 2020 4 次提交
-
-
由 Ed Wildgoose 提交于
The original commit appears to have the logic reversed in amd_fch_gpio_get_direction. Also confirmed by observing the value of "direction" in the sys tree. Signed-off-by: NEd Wildgoose <lists@wildgooses.com> Fixes: e09d168f ("gpio: AMD G-Series PCH gpio driver") Cc: stable@vger.kernel.org Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
-
由 Hans de Goede 提交于
Commit bedf9fc0 ("mmc: sdhci: Workaround broken command queuing on Intel GLK"), disabled command-queuing on Intel GLK based LENOVO models because of it being broken due to what is believed to be a bug in the BIOS. It seems that the BIOS of some IRBIS models, including the IRBIS NB111 model has the same issue, so disable command queuing there too. Fixes: bedf9fc0 ("mmc: sdhci: Workaround broken command queuing on Intel GLK") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209397Reported-and-tested-by: NRussianNeuroMancer <russianneuromancer@ya.ru> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200927104821.5676-1-hdegoede@redhat.com Cc: stable@vger.kernel.org Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Kai-Heng Feng 提交于
After commit 6827ca57 ("memstick: rtsx_usb_ms: Support runtime power management"), removing module rtsx_usb_ms will be stuck. The deadlock is caused by powering on and powering off at the same time, the former one is when memstick_check() is flushed, and the later is called by memstick_remove_host(). Soe let's skip allocating card to prevent this issue. Fixes: 6827ca57 ("memstick: rtsx_usb_ms: Support runtime power management") Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200925084952.13220-1-kai.heng.feng@canonical.com Cc: stable@vger.kernel.org Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Tali Perry 提交于
Due to a HW issue, in some scenarios the LAST bit might remain set. This will cause an unexpected NACK after reading 16 bytes on the next read. Example: if user tries to read from a missing device, get a NACK, then if the next command is a long read ( > 16 bytes), the master will stop reading after 16 bytes. To solve this, if a command fails, check if LAST bit is still set. If it does, reset the module. Fixes: 56a1485b (i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver) Signed-off-by: NTali Perry <tali.perry1@gmail.com> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
- 27 9月, 2020 2 次提交
-
-
由 Nicolas VINCENT 提交于
the i2c_ram structure is missing the sdmatmp field mentionned in datasheet for MPC8272 at paragraph 36.5. With this field missing, the hardware would write past the allocated memory done through cpm_muram_alloc for the i2c_ram structure and land in memory allocated for the buffers descriptors corrupting the cbd_bufaddr field. Since this field is only set during setup(), the first i2c transaction would work and the following would send data read from an arbitrary memory location. Fixes: 61045dbe ("i2c: Add support for I2C bus on Freescale CPM1/CPM2 controllers") Signed-off-by: NNicolas VINCENT <nicolas.vincent@vossloh.com> Acked-by: NJochen Friedrich <jochen@scram.de> Acked-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: NWolfram Sang <wsa@kernel.org>
-
由 Laurent Dufour 提交于
In register_mem_sect_under_node() the system_state's value is checked to detect whether the call is made during boot time or during an hot-plug operation. Unfortunately, that check against SYSTEM_BOOTING is wrong because regular memory is registered at SYSTEM_SCHEDULING state. In addition, memory hot-plug operation can be triggered at this system state by the ACPI [1]. So checking against the system state is not enough. The consequence is that on system with interleaved node's ranges like this: Early memory node ranges node 1: [mem 0x0000000000000000-0x000000011fffffff] node 2: [mem 0x0000000120000000-0x000000014fffffff] node 1: [mem 0x0000000150000000-0x00000001ffffffff] node 0: [mem 0x0000000200000000-0x000000048fffffff] node 2: [mem 0x0000000490000000-0x00000007ffffffff] This can be seen on PowerPC LPAR after multiple memory hot-plug and hot-unplug operations are done. At the next reboot the node's memory ranges can be interleaved and since the call to link_mem_sections() is made in topology_init() while the system is in the SYSTEM_SCHEDULING state, the node's id is not checked, and the sections registered to multiple nodes: $ ls -l /sys/devices/system/memory/memory21/node* total 0 lrwxrwxrwx 1 root root 0 Aug 24 05:27 node1 -> ../../node/node1 lrwxrwxrwx 1 root root 0 Aug 24 05:27 node2 -> ../../node/node2 In that case, the system is able to boot but if later one of theses memory blocks is hot-unplugged and then hot-plugged, the sysfs inconsistency is detected and this is triggering a BUG_ON(): kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto gf128mul binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4 CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25 Call Trace: add_memory_resource+0x23c/0x340 (unreliable) __add_memory+0x5c/0xf0 dlpar_add_lmb+0x1b4/0x500 dlpar_memory+0x1f8/0xb80 handle_dlpar_errorlog+0xc0/0x190 dlpar_store+0x198/0x4a0 kobj_attr_store+0x30/0x50 sysfs_kf_write+0x64/0x90 kernfs_fop_write+0x1b0/0x290 vfs_write+0xe8/0x290 ksys_write+0xdc/0x130 system_call_exception+0x160/0x270 system_call_common+0xf0/0x27c This patch addresses the root cause by not relying on the system_state value to detect whether the call is due to a hot-plug operation. An extra parameter is added to link_mem_sections() detailing whether the operation is due to a hot-plug operation. [1] According to Oscar Salvador, using this qemu command line, ACPI memory hotplug operations are raised at SYSTEM_SCHEDULING state: $QEMU -enable-kvm -machine pc -smp 4,sockets=4,cores=1,threads=1 -cpu host -monitor pty \ -m size=$MEM,slots=255,maxmem=4294967296k \ -numa node,nodeid=0,cpus=0-3,mem=512 -numa node,nodeid=1,mem=512 \ -object memory-backend-ram,id=memdimm0,size=134217728 -device pc-dimm,node=0,memdev=memdimm0,id=dimm0,slot=0 \ -object memory-backend-ram,id=memdimm1,size=134217728 -device pc-dimm,node=0,memdev=memdimm1,id=dimm1,slot=1 \ -object memory-backend-ram,id=memdimm2,size=134217728 -device pc-dimm,node=0,memdev=memdimm2,id=dimm2,slot=2 \ -object memory-backend-ram,id=memdimm3,size=134217728 -device pc-dimm,node=0,memdev=memdimm3,id=dimm3,slot=3 \ -object memory-backend-ram,id=memdimm4,size=134217728 -device pc-dimm,node=1,memdev=memdimm4,id=dimm4,slot=4 \ -object memory-backend-ram,id=memdimm5,size=134217728 -device pc-dimm,node=1,memdev=memdimm5,id=dimm5,slot=5 \ -object memory-backend-ram,id=memdimm6,size=134217728 -device pc-dimm,node=1,memdev=memdimm6,id=dimm6,slot=6 \ Fixes: 4fbce633 ("mm/memory_hotplug.c: make register_mem_sect_under_node() a callback of walk_memory_range()") Signed-off-by: NLaurent Dufour <ldufour@linux.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NOscar Salvador <osalvador@suse.de> Acked-by: NMichal Hocko <mhocko@suse.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Nathan Lynch <nathanl@linux.ibm.com> Cc: Scott Cheloha <cheloha@linux.ibm.com> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20200915094143.79181-3-ldufour@linux.ibm.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 25 9月, 2020 6 次提交
-
-
由 M. Vefa Bicakci 提交于
Commit 88b7381a ("USB: Select better matching USB drivers when available") inadvertently broke usbip functionality. The commit in question allows USB device drivers to be explicitly matched with USB devices via the use of driver-provided identifier tables and match functions, which is useful for a specialised device driver to be chosen for a device that can also be handled by another, more generic, device driver. Prior, the USB device section of usb_device_match() had an unconditional "return 1" statement, which allowed user-space to bind USB devices to the usbip_host device driver, if desired. However, the aforementioned commit changed the default/fallback return value to zero. This breaks device drivers such as usbip_host, so this commit restores the legacy behaviour, but only if a device driver does not have an id_table and a match() function. In addition, if usb_device_match is called for a device driver and device pair where the device does not match the id_table of the device driver in question, then the device driver will be disqualified for the device. This allows avoiding the default case of "return 1", which prevents undesirable probe() calls to a driver even though its id_table did not match the device. Finally, this commit changes the specialised-driver-to-generic-driver transition code so that when a device driver returns -ENODEV, a more generic device driver is only considered if the current device driver does not have an id_table and a match() function. This ensures that "generic" drivers such as usbip_host will not be considered specialised device drivers and will not cause the device to be locked in to the generic device driver, when a more specialised device driver could be tried. All of these changes restore usbip functionality without regressions, ensure that the specialised/generic device driver selection logic works as expected with the usb and apple-mfi-fastcharge drivers, and do not negatively affect the use of devices provided by dummy_hcd. Fixes: 88b7381a ("USB: Select better matching USB drivers when available") Cc: <stable@vger.kernel.org> # 5.8 Cc: Bastien Nocera <hadess@hadess.net> Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: <syzkaller@googlegroups.com> Tested-by: NAndrey Konovalov <andreyknvl@google.com> Acked-by: NShuah Khan <skhan@linuxfoundation.org> Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com> Link: https://lore.kernel.org/r/20200922110703.720960-5-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 M. Vefa Bicakci 提交于
This commit resolves a minor bug in the selection/discovery of more specific USB device drivers for devices that are currently bound to generic USB device drivers. The bug is related to the way a candidate USB device driver is compared against the generic USB device driver. The code in is_dev_usb_generic_driver() assumes that the device driver in question is a USB device driver by calling to_usb_device_driver(dev->driver) to downcast; however I have observed that this assumption is not always true, through code instrumentation. This commit avoids the incorrect downcast altogether by comparing the USB device's driver (i.e., dev->driver) to the generic USB device driver directly. This method was suggested by Alan Stern. This bug was found while investigating Andrey Konovalov's report indicating usbip device driver misbehaviour with the recently merged generic USB device driver selection feature. The report is linked below. Fixes: d5643d22 ("USB: Fix device driver race") Cc: <stable@vger.kernel.org> # 5.8 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Bastien Nocera <hadess@hadess.net> Cc: Shuah Khan <shuah@kernel.org> Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: <syzkaller@googlegroups.com> Tested-by: NAndrey Konovalov <andreyknvl@google.com> Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com> Link: https://lore.kernel.org/r/20200922110703.720960-4-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 M. Vefa Bicakci 提交于
This commit resolves a bug in the selection/discovery of more specific USB device drivers for devices that are currently bound to generic USB device drivers. The bug is in the logic that determines whether a device currently bound to a generic USB device driver should be re-probed by a more specific USB device driver or not. The code in __usb_bus_reprobe_drivers() used to have the following lines: if (usb_device_match_id(udev, new_udriver->id_table) == NULL && (!new_udriver->match || new_udriver->match(udev) != 0)) return 0; ret = device_reprobe(dev); As the reader will notice, the code checks whether the USB device in consideration matches the identifier table (id_table) of a specific USB device_driver (new_udriver), followed by a similar check, but this time with the USB device driver's match function. However, the match function's return value is not checked correctly. When match() returns zero, it means that the specific USB device driver is *not* applicable to the USB device in question, but the code then goes on to reprobe the device with the new USB device driver under consideration. All this to say, the logic is inverted. This bug was found by code inspection and instrumentation while investigating the root cause of the issue reported by Andrey Konovalov, where usbip took over syzkaller's virtual USB devices in an undesired manner. The report is linked below. Fixes: d5643d22 ("USB: Fix device driver race") Cc: <stable@vger.kernel.org> # 5.8 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Bastien Nocera <hadess@hadess.net> Cc: Shuah Khan <shuah@kernel.org> Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: <syzkaller@googlegroups.com> Tested-by: NAndrey Konovalov <andreyknvl@google.com> Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com> Link: https://lore.kernel.org/r/20200922110703.720960-3-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 M. Vefa Bicakci 提交于
This commit reverts commit 7a2f2974 ("usbip: Implement a match function to fix usbip"). In summary, commit d5643d22 ("USB: Fix device driver race") inadvertently broke usbip functionality, which I resolved in an incorrect manner by introducing a match function to usbip, usbip_match(), that unconditionally returns true. However, the usbip_match function, as is, causes usbip to take over virtual devices used by syzkaller for USB fuzzing, which is a regression reported by Andrey Konovalov. Furthermore, in conjunction with the fix of another bug, handled by another patch titled "usbcore/driver: Fix specific driver selection" in this patch set, the usbip_match function causes unexpected USB subsystem behaviour when the usbip_host driver is loaded. The unexpected behaviour can be qualified as follows: - If commit 41160802ab8e ("USB: Simplify USB ID table match") is included in the kernel, then all USB devices are bound to the usbip_host driver, which appears to the user as if all USB devices were disconnected. - If the same commit (41160802ab8e) is not in the kernel (as is the case with v5.8.10) then all USB devices are re-probed and re-bound to their original device drivers, which appears to the user as a disconnection and re-connection of USB devices. Please note that this commit will make usbip non-operational again, until yet another patch in this patch set is merged, titled "usbcore/driver: Accommodate usbip". Cc: <stable@vger.kernel.org> # 5.8: 41160802ab8e: USB: Simplify USB ID table match Cc: <stable@vger.kernel.org> # 5.8 Cc: Bastien Nocera <hadess@hadess.net> Cc: Valentina Manea <valentina.manea.m@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: <syzkaller@googlegroups.com> Reported-by: NAndrey Konovalov <andreyknvl@google.com> Tested-by: NAndrey Konovalov <andreyknvl@google.com> Acked-by: NShuah Khan <skhan@linuxfoundation.org> Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com> Link: https://lore.kernel.org/r/20200922110703.720960-2-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peilin Ye 提交于
fbcon_get_font() is reading out-of-bounds. A malicious user may resize `vc->vc_font.height` to a large value, causing fbcon_get_font() to read out of `fontdata`. fbcon_get_font() handles both built-in and user-provided fonts. Fortunately, recently we have added FONT_EXTRA_WORDS support for built-in fonts, so fix it by adding range checks using FNTSIZE(). This patch depends on patch "fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h", and patch "Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts". Cc: stable@vger.kernel.org Reported-and-tested-by: syzbot+29d4ed7f3bdedf2aa2fd@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfdSigned-off-by: NPeilin Ye <yepeilin.cs@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/b34544687a1a09d6de630659eb7a773f4953238b.1600953813.git.yepeilin.cs@gmail.com
-
由 Peilin Ye 提交于
drivers/video/console/newport_con.c is borrowing FONT_EXTRA_WORDS macros from drivers/video/fbdev/core/fbcon.h. To keep things simple, move all definitions into <linux/font.h>. Since newport_con now uses four extra words, initialize the fourth word in newport_set_font() properly. Cc: stable@vger.kernel.org Signed-off-by: NPeilin Ye <yepeilin.cs@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/7fb8bc9b0abc676ada6b7ac0e0bd443499357267.1600953813.git.yepeilin.cs@gmail.com
-
- 24 9月, 2020 4 次提交
-
-
由 Tao Ren 提交于
GPIO_U is mapped to the least significant byte of input/output mask, and the byte in "output" mask should be 0 because GPIO_U is input only. All the other bits need to be 1 because GPIO_V/W/X support both input and output modes. Similarly, GPIO_Y/Z are mapped to the 2 least significant bytes, and the according bits need to be 1 because GPIO_Y/Z support both input and output modes. Fixes: ab4a8553 ("gpio: aspeed: Add in ast2600 details to Aspeed driver") Signed-off-by: NTao Ren <rentao.bupt@gmail.com> Reviewed-by: NAndrew Jeffery <andrew@aj.id.au> Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
-
由 Jeremy Kerr 提交于
Currently, the IRQ setup for the SGPIO driver enables all interrupts in dual-edge trigger mode. Since the default handler is handle_bad_irq, any state change on input GPIOs will trigger bad IRQ warnings. This change applies sensible IRQ defaults: single-edge trigger, and all IRQs disabled. Signed-off-by: NJeremy Kerr <jk@codeconstruct.com.au> Fixes: 7db47faa ("gpio: aspeed: Add SGPIO driver") Reviewed-by: NJoel Stanley <joel@jms.id.au> Acked-by: NAndrew Jeffery <andrew@aj.id.au> Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
-
由 Jeremy Kerr 提交于
Currently, the aspeed-sgpio driver exposes up to 80 GPIO lines, corresponding to the 80 status bits available in hardware. Each of these lines can be configured as either an input or an output. However, each of these GPIOs is actually an input *and* an output; we actually have 80 inputs plus 80 outputs. This change expands the maximum number of GPIOs to 160; the lower half of this range are the input-only GPIOs, the upper half are the outputs. We fix the GPIO directions to correspond to this mapping. This also fixes a bug when setting GPIOs - we were reading from the input register, making it impossible to set more than one output GPIO. Signed-off-by: NJeremy Kerr <jk@codeconstruct.com.au> Fixes: 7db47faa ("gpio: aspeed: Add SGPIO driver") Reviewed-by: NJoel Stanley <joel@jms.id.au> Reviewed-by: NAndrew Jeffery <andrew@aj.id.au> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
-
由 Ye Li 提交于
When pca953x_irq_pending returns false, the pending parameter won't be set. But pca953x_irq_handler continues using this uninitialized variable as pending irqs and will cause problem. Fix the issue by initializing pending to 0. Fixes: 064c73af ("gpio: pca953x: Synchronize interrupt handler properly") Signed-off-by: NYe Li <ye.li@nxp.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
-