Linux-stable-mirror April 2024

linux-stable-mirror@lists.linaro.org

482 participants
1073 discussions

[RFC PATCH v2 1/6] cxl/core: correct length of DPA field masks

by Shiyang Ruan

The length of Physical Address in General Media Event Record/DRAM Event Record is 64-bit, so the field mask should be defined as such length. Otherwise, this causes cxl_general_media and cxl_dram tracepoints to mask off the upper-32-bits of DPA addresses. The cxl_poison event is unaffected. If userspace was doing its own DPA-to-HPA translation this could lead to incorrect page retirement decisions, but there is no known consumer (like rasdaemon) of this event today. Fixes: d54a531a430b ("cxl/mem: Trace General Media Event Record") Cc: <stable(a)vger.kernel.org> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Cc: Ira Weiny <ira.weiny(a)intel.com> Signed-off-by: Shiyang Ruan <ruansy.fnst(a)fujitsu.com> --- drivers/cxl/core/trace.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h index e5f13260fc52..e2d1f296df97 100644 --- a/drivers/cxl/core/trace.h +++ b/drivers/cxl/core/trace.h @@ -253,11 +253,11 @@ TRACE_EVENT(cxl_generic_event, * DRAM Event Record * CXL rev 3.0 section 8.2.9.2.1.2; Table 8-44 */ -#define CXL_DPA_FLAGS_MASK 0x3F +#define CXL_DPA_FLAGS_MASK 0x3FULL #define CXL_DPA_MASK (~CXL_DPA_FLAGS_MASK) -#define CXL_DPA_VOLATILE BIT(0) -#define CXL_DPA_NOT_REPAIRABLE BIT(1) +#define CXL_DPA_VOLATILE BIT_ULL(0) +#define CXL_DPA_NOT_REPAIRABLE BIT_ULL(1) #define show_dpa_flags(flags) __print_flags(flags, "|", \ { CXL_DPA_VOLATILE, "VOLATILE" }, \ { CXL_DPA_NOT_REPAIRABLE, "NOT_REPAIRABLE" } \ -- 2.34.1

1 year

[PATCH] net: usb: ax88179_178a: avoid the interface always configured as random address

by Jose Ignacio Tornos Martinez

After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets"), reset is not executed from bind operation and mac address is not read from the device registers or the devicetree at that moment. Since the check to configure if the assigned mac address is random or not for the interface, happens after the bind operation from usbnet_probe, the interface keeps configured as random address, although the address is correctly read and set during open operation (the only reset now). In order to keep only one reset for the device and to avoid the interface always configured as random address, after reset, configure correctly the suitable field from the driver, if the mac address is read successfully from the device registers or the devicetree. In addition, if mac address can not be read from the driver, a random address is configured again, so it is not necessary to call eth_hw_addr_random from here. Indeed, in this situtatuon, when reset was also executed from bind, this was invalidating the check to configure if the assigned mac address for the interface was random or not. cc: stable(a)vger.kernel.org # 6.6+ Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets") Reported-by: Dave Stevenson <dave.stevenson(a)raspberrypi.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> --- drivers/net/usb/ax88179_178a.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c index 88e084534853..d2324cc02461 100644 --- a/drivers/net/usb/ax88179_178a.c +++ b/drivers/net/usb/ax88179_178a.c @@ -1273,10 +1273,9 @@ static void ax88179_get_mac_addr(struct usbnet *dev) if (is_valid_ether_addr(mac)) { eth_hw_addr_set(dev->net, mac); - } else { + dev->net->addr_assign_type = NET_ADDR_PERM; + } else netdev_info(dev->net, "invalid MAC address, using random\n"); - eth_hw_addr_random(dev->net); - } ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN, ETH_ALEN, dev->net->dev_addr); -- 2.44.0

1 year

[REGRESSION] external monitor+Dell dock in 6.8

by Andrei Gaponenko

Hello, I noticed a regression with the mailine kernel pre-compiled by EPEL. I have just tried linux-6.9-rc1.tar.gz from kernel.org, and it still misbehaves. The default setup: a laptop is connected to a dock, Dell WD22TB4, via a USB-C cable. The dock is connected to an external monitor via a Display Port cable. With a "good" kernel everything works. With a "broken" kernel, the external monitor is still correctly identified by the system, and is shown as enabled in plasma systemsettings. The system also behaves like the monitor is working, for example, one can move the mouse pointer off the laptop screen. However the external monitor screen stays black, and it eventually goes to sleep. Everything worked with EPEL mainline kernels up to and including kernel-ml-6.7.9-1.el9.elrepo.x86_64 The breakage is observed in kernel-ml-6.8.1-1.el9.elrepo.x86_64 kernel-ml-6.8.2-1.el9.elrepo.x86_64 linux-6.9-rc1.tar.gz from kernel.org (with olddefconfig) Other tests: using an HDMI cable instead of the Display Port cable between the monitor and the dock does not change things, black screen with the newer kernels. Using a small HDMI-to-USB-C adapter instead of the dock results in a working system, even with the newer kernels. So the breakage appears to be specific to the Dell WD22TB4 dock. Operating System: AlmaLinux 9.3 (Shamrock Pampas Cat) uname -mi: x86_64 x86_64 Laptop: Dell Precision 5470/02RK6V lsusb |grep dock Bus 003 Device 007: ID 413c:b06e Dell Computer Corp. Dell dock Bus 003 Device 008: ID 413c:b06f Dell Computer Corp. Dell dock Bus 003 Device 006: ID 0bda:5413 Realtek Semiconductor Corp. Dell dock Bus 003 Device 005: ID 0bda:5487 Realtek Semiconductor Corp. Dell dock Bus 002 Device 004: ID 0bda:0413 Realtek Semiconductor Corp. Dell dock Bus 002 Device 003: ID 0bda:0487 Realtek Semiconductor Corp. Dell dock dmesg and kernel config are attached to https://bugzilla.kernel.org/show_bug.cgi?id=218663 #regzbot introduced: v6.7.9..v6.8.1 Andrei

1 year

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024