- 03 10月, 2021 1 次提交
-
-
由 Hugh Dickins 提交于
5.15-rc1 crashes with blank screen when booting up on two ThinkPads using i915. Bisections converge convincingly, but arrive at different and suprising "culprits", none of them the actual culprit. netconsole (with init_netconsole() hacked to call i915_init() when logging has started, instead of by module_init()) tells the story: kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! with RSI: ffffffff814d408b pointing to sw_fence_dummy_notify(). I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that function needs to be 4-byte aligned. Fixes: 62eaf0ae ("drm/i915/guc: Support request cancellation") Signed-off-by: NHugh Dickins <hughd@google.com> Tested-by: NSteven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 02 10月, 2021 6 次提交
-
-
由 Nadezda Lutovinova 提交于
If driver read tmp value sufficient for (tmp & 0x08) && (!(tmp & 0x80)) && ((tmp & 0x7) == ((tmp >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: NNadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-3-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignments] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Nadezda Lutovinova 提交于
If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: NNadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-2-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multipline alignment] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Nadezda Lutovinova 提交于
If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: NNadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210921155153.28098-1-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Vadim Pasternak 提交于
Add missed attribute for reading POUT from page 1. It is supported by device, but has been missed in initial commit. Fixes: 2c6fcbb2 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Signed-off-by: NVadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20210927070740.2149290-1-vadimp@nvidia.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Brandon Wyman 提交于
The bytes for max_power_out from the ibm-cffps devices differ in byte order for some power supplies. The Witherspoon power supply returns the bytes in MSB/LSB order. The Rainier power supply returns the bytes in LSB/MSB order. The Witherspoon power supply uses version cffps1. The Rainier power supply should use version cffps2. If version is cffps1, swap the bytes before output to max_power_out. Tested: Witherspoon before: 3148. Witherspoon after: 3148. Rainier before: 53255. Rainier after: 2000. Signed-off-by: NBrandon Wyman <bjwyman@gmail.com> Reviewed-by: NEddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210928205051.1222815-1-bjwyman@gmail.com [groeck: Replaced yoda programming] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Eddie James 提交于
The P10 (temp sensor version 0x10) doesn't do the same VRM status reporting that was used on P9. It just reports the temperature, so drop the check for VRM fru type in the sysfs show function, and don't set the name to "alarm". Fixes: db4919ec ("hwmon: (occ) Add new temperature sensor type") Signed-off-by: NEddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210929153604.14968-1-eajames@linux.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 30 9月, 2021 4 次提交
-
-
由 Wong Vee Khee 提交于
When STMMAC is paired with Energy-Efficient Ethernet(EEE) capable PHY, and the PHY is advertising EEE by default, we need to enable EEE on the xPCS side too, instead of having user to manually trigger the enabling config via ethtool. Fixed this by adding xpcs_config_eee() call in stmmac_eee_init(). Fixes: 7617af3d ("net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet") Cc: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> Signed-off-by: NWong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Zelin Deng 提交于
hv_clock is preallocated to have only HVC_BOOT_ARRAY_SIZE (64) elements; if the PTP_SYS_OFFSET_PRECISE ioctl is executed on vCPUs whose index is 64 of higher, retrieving the struct pvclock_vcpu_time_info pointer with "src = &hv_clock[cpu].pvti" will result in an out-of-bounds access and a wild pointer. Change it to "this_cpu_pvti()" which is guaranteed to be valid. Fixes: 95a3d445 ("Switch kvmclock data to a PER_CPU variable") Signed-off-by: NZelin Deng <zelin.deng@linux.alibaba.com> Cc: <stable@vger.kernel.org> Message-Id: <1632892429-101194-3-git-send-email-zelin.deng@linux.alibaba.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Nick Desaulniers 提交于
commit fad7cd33 ("nbd: add the check to prevent overflow in __nbd_ioctl()") raised an issue from the fallback helpers added in commit f0907827 ("compiler.h: enable builtin overflow checkers and add fallback code") ERROR: modpost: "__divdi3" [drivers/block/nbd.ko] undefined! As Stephen Rothwell notes: The added check_mul_overflow() call is being passed 64 bit values. COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW is not set for this build (see include/linux/overflow.h). Specifically, the helpers for checking whether the results of a multiplication overflowed (__unsigned_mul_overflow, __signed_add_overflow) use the division operator when !COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW. This is problematic for 64b operands on 32b hosts. This was fixed upstream by commit 76ae8474 ("Documentation: raise minimum supported version of GCC to 5.1") which is not suitable to be backported to stable. Further, __builtin_mul_overflow() would emit a libcall to a compiler-rt-only symbol when compiling with clang < 14 for 32b targets. ld.lld: error: undefined symbol: __mulodi4 In order to keep stable buildable with GCC 4.9 and clang < 14, modify struct nbd_config to instead track the number of bits of the block size; reconstructing the block size using runtime checked shifts that are not problematic for those compilers and in a ways that can be backported to stable. In nbd_set_size, we do validate that the value of blksize must be a power of two (POT) and is in the range of [512, PAGE_SIZE] (both inclusive). This does modify the debugfs interface. Cc: stable@vger.kernel.org Cc: Arnd Bergmann <arnd@kernel.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://github.com/ClangBuiltLinux/linux/issues/1438 Link: https://lore.kernel.org/all/20210909182525.372ee687@canb.auug.org.au/ Link: https://lore.kernel.org/stable/CAHk-=whiQBofgis_rkniz8GBP9wZtSZdcDEffgSLO62BUGV3gg@mail.gmail.com/Reported-by: NNaresh Kamboju <naresh.kamboju@linaro.org> Reported-by: NNathan Chancellor <nathan@kernel.org> Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Suggested-by: NKees Cook <keescook@chromium.org> Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org> Suggested-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NNick Desaulniers <ndesaulniers@google.com> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20210920232533.4092046-1-ndesaulniers@google.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Andrey Gusakov 提交于
Per gpio_chip interface, error shall be proparated to the caller. Attempt to silent diagnostics by returning zero (as written in the comment) is plain wrong, because the zero return can be interpreted by the caller as the gpio value. Cc: stable@vger.kernel.org Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com> Signed-off-by: NNikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
-
- 29 9月, 2021 23 次提交
-
-
由 Florian Fainelli 提交于
When EEE support was added to the 28nm EPHY it was assumed that it would be able to support the standard clause 45 over clause 22 register access method. It turns out that the PHY does not support that, which is the very reason for using the indirect shadow mode 2 bank 3 access method. Implement {read,write}_mmd to allow the standard PHY library routines pertaining to EEE querying and configuration to work correctly on these PHYs. This forces us to implement a __phy_set_clr_bits() function that does not grab the MDIO bus lock since the PHY driver's {read,write}_mmd functions are always called with that lock held. Fixes: 83ee102a ("net: phy: bcm7xxx: add support for 28nm EPHY") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
Currently, the firmware compatible features are enabled in PF driver initialization process, but they are not disabled in PF driver deinitialization process and firmware keeps these features in enabled status. In this case, if load an old PF driver (for example, in VM) which not support the firmware compatible features, firmware will still send mailbox message to PF when link status changed and PF will print "un-supported mailbox message, code = 201". To fix this problem, disable these firmware compatible features in PF driver deinitialization process. Fixes: ed8fb4b2 ("net: hns3: add link change event report") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
Currently, the rx vlan filter will always be disabled before selftest and be enabled after selftest as the rx vlan filter feature is fixed on in old device earlier than V3. However, this feature is not fixed in some new devices and it can be disabled by user. In this case, it is wrong if rx vlan filter is enabled after selftest. So fix it. Fixes: bcc26e8d ("net: hns3: remove unused code in hns3_self_test()") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
If unicast mac address table is full, and user add a new mac address, the unicast promisc needs to be enabled for the new unicast mac address can be used. So does the multicast promisc. Now this feature has been implemented for PF, and VF should be implemented too. When the mac table of VF is overflow, PF will enable promisc for this VF. Fixes: 1e6e7610 ("net: hns3: configure promisc mode for VF asynchronously") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jian Shen 提交于
Currently, if function adds an existing unicast mac address, eventhough driver will not add this address into hardware, but it will return 0 in function hclge_add_uc_addr_common(). It will cause the state of this unicast mac address is ACTIVE in driver, but it should be in TO-ADD state. To fix this problem, function hclge_add_uc_addr_common() returns -EEXIST if mac address is existing, and delete two error log to avoid printing them all the time after this modification. Fixes: 72110b56 ("net: hns3: return 0 and print warning when hit duplicate MAC") Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jian Shen 提交于
HCLGE_FLAG_MQPRIO_ENABLE is supposed to set when enable multiple TCs with tc mqprio, and HCLGE_FLAG_DCB_ENABLE is supposed to set when enable multiple TCs with ets. But the driver mixed the flags when updating the tm configuration. Furtherly, PFC should be available when HCLGE_FLAG_MQPRIO_ENABLE too, so remove the unnecessary limitation. Fixes: 5a5c9091 ("net: hns3: add support for tc mqprio offload") Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jian Shen 提交于
For destroy mqprio is irreversible in stack, so it's unnecessary to rollback the tc configuration when destroy mqprio failed. Otherwise, it may cause the configuration being inconsistent between driver and netstack. As the failure is usually caused by reset, and the driver will restore the configuration after reset, so it can keep the configuration being consistent between driver and hardware. Fixes: 5a5c9091 ("net: hns3: add support for tc mqprio offload") Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jian Shen 提交于
Currently, in function hns3_nic_set_real_num_queue(), the driver doesn't report the queue count and offset for disabled tc. If user enables multiple TCs, but only maps user priorities to partial of them, it may cause the queue range of the unmapped TC being displayed abnormally. Fix it by removing the tc enable checking, ensure the queue count is not zero. With this change, the tc_en is useless now, so remove it. Fixes: a75a8efa ("net: hns3: Fix tc setup when netdev is first up") Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jian Shen 提交于
hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set. Fixes: e8884027 ("net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT") Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Feng Zhou 提交于
The ixgbe driver currently generates a NULL pointer dereference with some machine (online cpus < 63). This is due to the fact that the maximum value of num_xdp_queues is nr_cpu_ids. Code is in "ixgbe_set_rss_queues"". Here's how the problem repeats itself: Some machine (online cpus < 63), And user set num_queues to 63 through ethtool. Code is in the "ixgbe_set_channels", adapter->ring_feature[RING_F_FDIR].limit = count; It becomes 63. When user use xdp, "ixgbe_set_rss_queues" will set queues num. adapter->num_rx_queues = rss_i; adapter->num_tx_queues = rss_i; adapter->num_xdp_queues = ixgbe_xdp_queues(adapter); And rss_i's value is from f = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit; So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup", for (i = 0; i < adapter->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem) It leads to panic. Call trace: [exception RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88 14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64 18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9 19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c So I fix ixgbe_max_channels so that it will not allow a setting of queues to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup, take the smaller value of num_rx_queues and num_xdp_queues. Fixes: 4a9b32f3 ("ixgbe: fix potential RX buffer starvation for AF_XDP") Signed-off-by: NFeng Zhou <zhoufeng.zf@bytedance.com> Tested-by: NSandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Rahul Lakkireddy 提交于
Both cxgb4 and csiostor drivers run on their own independent Physical Function. But when cxgb4 and csiostor are both being loaded in parallel via modprobe, there is a race when firmware upgrade is attempted by both the drivers. When the cxgb4 driver initiates the firmware upgrade, it halts the firmware and the chip until upgrade is complete. When the csiostor driver is coming up in parallel, the firmware mailbox communication fails with timeouts and the csiostor driver probe fails. Add a module soft dependency on cxgb4 driver to ensure loading csiostor triggers cxgb4 to load first when available to avoid the firmware upgrade race. Link: https://lore.kernel.org/r/1632759248-15382-1-git-send-email-rahul.lakkireddy@chelsio.com Fixes: a3667aae ("[SCSI] csiostor: Chelsio FCoE offload driver") Signed-off-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Arun Easi 提交于
Disable default logging of some I/O path messages. If desired, the messages can be turned back on by setting ql2xextended_error_logging. Link: https://lore.kernel.org/r/20210925035154.29815-1-njavali@marvell.comReviewed-by: NEwan D. Milne <emilne@redhat.com> Reviewed-by: NHimanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: NArun Easi <aeasi@marvell.com> Signed-off-by: NNilesh Javali <njavali@marvell.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Colin Ian King 提交于
There are a couple of spelling mistakes in pr_info and pr_err messages. Fix them. Link: https://lore.kernel.org/r/20210924230330.143785-1-colin.king@canonical.comSigned-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Jiapeng Chong 提交于
Fix the following coccicheck warning: ./drivers/scsi/ses.c:137:10-16: WARNING: Unsigned expression compared with zero: result > 0. Link: https://lore.kernel.org/r/1632477113-90378-1-git-send-email-jiapeng.chong@linux.alibaba.comReported-by: NAbaci Robot <abaci@linux.alibaba.com> Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Jonathan Hsu 提交于
Fix incorrect index for UTMRD reference in ufshcd_add_tm_upiu_trace(). Link: https://lore.kernel.org/r/20210924085848.25500-1-jonathan.hsu@mediatek.com Fixes: 4b42d557 ("scsi: ufs: core: Fix wrong Task Tag used in task management request UPIUs") Cc: stable@vger.kernel.org Reviewed-by: NStanley Chu <stanley.chu@mediatek.com> Reviewed-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NJonathan Hsu <jonathan.hsu@mediatek.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Cai Huoqing 提交于
The second resource is optional which is only provided on the chipset IPQ5018. But the blamed commit ignores that and if the resource is not there it just fails. the resource is used like this, if (priv->eth_ldo_rdy) { val = readl(priv->eth_ldo_rdy); val |= BIT(0); writel(val, priv->eth_ldo_rdy); fsleep(IPQ_PHY_SET_DELAY_US); } This patch reverts that to still allow the second resource to be optional because other SoC have the some MDIO controller and doesn't need to second resource. Fixes: fa14d03e ("net: mdio-ipq4019: Make use of devm_platform_ioremap_resource()") Signed-off-by: NCai Huoqing <caihuoqing@baidu.com> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210928134849.2092-1-caihuoqing@baidu.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Prike Liang 提交于
In the s2idle stress test sdma resume fail occasionally,in the failed case GPU is in the gfxoff state.This issue may introduce by firmware miss handle doorbell S/R and now temporary fix the issue by forcing exit gfxoff for sdma resume. Signed-off-by: NPrike Liang <Prike.Liang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Simon Ser 提交于
On GFX9+, format modifiers are always enabled and ensure the frame-buffers can be scanned out at ADDFB2 time. On GFX8-, format modifiers are not supported and no other check is performed. This means ADDFB2 IOCTLs will succeed even if the tiling isn't supported for scan-out, and will result in garbage displayed on screen [1]. Fix this by adding a check for tiling flags for GFX8 and older. The check is taken from radeonsi in Mesa (see how is_displayable is populated in gfx6_compute_surface). Changes in v2: use drm_WARN_ONCE instead of drm_WARN (Michel) [1]: https://github.com/swaywm/wlroots/issues/3185Signed-off-by: NSimon Ser <contact@emersion.fr> Acked-by: NMichel Dänzer <mdaenzer@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Charlene Liu 提交于
[why] pci deviceid not passed to dal dc, without proper break, dcn2.x falls into dcn3.x code path [how] pass in pci deviceid, and break once dal_version initialized. Reviewed-by: NZhan Liu <Zhan.Liu@amd.com> Acked-by: NAnson Jacob <Anson.Jacob@amd.com> Signed-off-by: NCharlene Liu <Charlene.Liu@amd.com> Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Josip Pavic 提交于
[Why] Stack variable params.backlight_ramping_override is uninitialized, so it contains junk data [How] Initialize the variable to false Reviewed-by: NRoman Li <Roman.Li@amd.com> Acked-by: NAnson Jacob <Anson.Jacob@amd.com> Signed-off-by: NJosip Pavic <Josip.Pavic@amd.com> Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Hawking Zhang 提交于
didn't read the value of mmCP_HQD_QUANTUM from correct register offset Signed-off-by: NHawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: NLe Ma <Le.Ma@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Praful Swarnakar 提交于
[Why] ASSR is dependent on Signed PSP Verstage to enable Content Protection for eDP panels. Unsigned PSP verstage is used during development phase causing ASSR to FAIL. As a result, link training is performed with DP_PANEL_MODE_DEFAULT instead of DP_PANEL_MODE_EDP for eDP panels that causes display flicker on some panels. [How] - Do not change panel mode, if ASSR is disabled - Just report and continue to perform eDP link training with right settings further. Signed-off-by: NPraful Swarnakar <Praful.Swarnakar@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Leslie Shi 提交于
gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: NLeslie Shi <Yuliang.Shi@amd.com> Signed-off-by: NGuchun Chen <guchun.chen@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 28 9月, 2021 6 次提交
-
-
由 Arnd Bergmann 提交于
This function copies strings around between multiple buffers including a large on-stack array that causes a build warning on 32-bit systems: drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c: In function 'hclge_dbg_dump_tm_pg': drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c:782:1: error: the frame size of 1424 bytes is larger than 1400 bytes [-Werror=frame-larger-than=] The function can probably be cleaned up a lot, to go back to printing directly into the output buffer, but dynamically allocating the structure is a simpler workaround for now. Fixes: 04d96139 ("net: hns3: refine function hclge_dbg_dump_tm_pri()") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Horatiu Vultur 提交于
According to the documentation the second resource is optional. But the blamed commit ignores that and if the resource is not there it just fails. This patch reverts that to still allow the second resource to be optional because other SoC have the some MDIO controller and doesn't need to second resource. Fixes: 672a1c39 ("net: mdio: mscc-miim: Make use of the helper function devm_platform_ioremap_resource()") Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: NCai Huoqing <caihuoqing@baidu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Randy Dunlap 提交于
When CONFIG_INET is not set, there are failing references to IPv4 functions, so make this driver depend on INET. Fixes these build errors: sparc64-linux-ld: drivers/net/ethernet/sun/sunvnet_common.o: in function `sunvnet_start_xmit_common': sunvnet_common.c:(.text+0x1a68): undefined reference to `__icmp_send' sparc64-linux-ld: drivers/net/ethernet/sun/sunvnet_common.o: in function `sunvnet_poll_common': sunvnet_common.c:(.text+0x358c): undefined reference to `ip_send_check' Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Aaron Young <aaron.young@oracle.com> Cc: Rashmi Narasimhan <rashmi.narasimhan@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Shannon Nelson 提交于
Don't print stats for which we haven't reserved space as it can cause nasty memory bashing and related bad behaviors. Fixes: aa620993 ("ionic: pull per-q stats work out of queue loops") Signed-off-by: NShannon Nelson <snelson@pensando.io> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arnd Bergmann 提交于
Many architectures don't define virt_to_bus() any more, as drivers should be using the dma-mapping interfaces where possible: In file included from drivers/net/hamradio/dmascc.c:27: drivers/net/hamradio/dmascc.c: In function 'tx_on': drivers/net/hamradio/dmascc.c:976:30: error: implicit declaration of function 'virt_to_bus'; did you mean 'virt_to_fix'? [-Werror=implicit-function-declaration] 976 | virt_to_bus(priv->tx_buf[priv->tx_tail]) + n); | ^~~~~~~~~~~ arch/arm/include/asm/dma.h:109:52: note: in definition of macro 'set_dma_addr' 109 | __set_dma_addr(chan, (void *)__bus_to_virt(addr)) | ^~~~ Add the Kconfig dependency to prevent this from being built on architectures without virt_to_bus(). Fixes: bc1abb9e ("dmascc: use proper 'virt_to_bus()' rather than casting to 'int'") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arnd Bergmann 提交于
An object file cannot be built for both loadable module and built-in use at the same time: arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common': ks8851_common.c:(.text+0xf80): undefined reference to `__this_module' Change the ks8851_common code to be a standalone module instead, and use Makefile logic to ensure this is built-in if at least one of its two users is. Fixes: 797047f8 ("net: ks8851: Implement Parallel bus operations") Link: https://lore.kernel.org/netdev/20210125121937.3900988-1-arnd@kernel.org/Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NMarek Vasut <marex@denx.de> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-