6.17.6-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 148/184 sched: Remove never used code in mm_cid_get()
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit 53abe3e1c154628cc74e33a1bfcd865656e433a5 ]
Clang is not happy with set but unused variable (this is visible with make W=1 build:
kernel/sched/sched.h:3744:18: error: variable 'cpumask' set but not used [-Werror,-Wunused-but-set-variable]
It seems like the variable was never used along with the assignment that does not have side effects as far as I can see. Remove those altogether.
--- kernel/sched/sched.h | 2 -- 1 file changed, 2 deletions(-)
kernel/sched/sched.h +0 -2
@@ -3735,11 +3735,9 @@ static inline int mm_cid_get(struct rq *rq, struct task_struct *t, struct mm_struct *mm) {struct mm_cid __percpu *pcpu_cid = mm->pcpu_cid; -struct cpumask *cpumask;int cid;lockdep_assert_rq_held (rq); - cpumask =mm_cidmask (mm); cid =__this_cpu_read (pcpu_cid->cid);if (mm_cid_is_valid (cid)) {mm_cid_snapshot_time (rq, mm);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 149/184 USB: serial: option: add UNISOC UIS7720
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Renjun Wang <[email protected]>
commit 71c07570b918f000de5d0f7f1bf17a2887e303b5 upstream.
Add support for UNISOC (Spreadtrum) UIS7720 (A7720) module.
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1782 ProdID=4064 Rev=04.04 S: Manufacturer=Unisoc-phone S: Product=Unisoc-phone S: SerialNumber=0123456789ABCDEF C: #Ifs= 9 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
0&1: RNDIS, 2: LOG, 3: DIAG, 4&5: AT Ports, 6&7: AT2 Ports, 8: ADB
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -617,6 +617,7 @@ static void option_instat_callback(struc#define UNISOC_VENDOR_ID 0x1782/* TOZED LT70-C based on UNISOC SL8563 uses UNISOC's vendor ID */ #define TOZED_PRODUCT_LT70C 0x4055 +#define UNISOC_PRODUCT_UIS7720 0x4064/* Luat Air72*U series based on UNISOC UIS8910 uses UNISOC's vendor ID */ #define LUAT_PRODUCT_AIR720U 0x4e00
@@ -2466,6 +2467,7 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9291, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9291, 0xff, 0xff, 0x40) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, TOZED_PRODUCT_LT70C, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, UNISOC_PRODUCT_UIS7720, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, LUAT_PRODUCT_AIR720U, 0xff, 0, 0) }, { USB_DEVICE_INTERFACE_CLASS(0x1bbb, 0x0530, 0xff), /* TCL IK512 MBIM */ .driver_info = NCTRL(1) },
Greg Kroah-Hartman
maintainerPATCH 150/184 USB: serial: option: add Quectel RG255C
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Reinhard Speyerer <[email protected]>
commit 89205c60c0fc96b73567a2e9fe27ee3f59d01193 upstream.
Add support for Quectel RG255C devices to complement commit 5c964c8a97c1 ("net: usb: qmi_wwan: add Quectel RG255C").
The composition is DM / NMEA / AT / QMI.
T: Bus=01 Lev=02 Prnt=99 Port=01 Cnt=02 Dev#=110 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0316 Rev= 5.15 S: Manufacturer=Quectel S: Product=RG255C-GL S: SerialNumber=xxxxxxxx C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -273,6 +273,7 @@ static void option_instat_callback(struc#define QUECTEL_PRODUCT_EM05CN 0x0312#define QUECTEL_PRODUCT_EM05G_GR 0x0313#define QUECTEL_PRODUCT_EM05G_RS 0x0314 +#define QUECTEL_PRODUCT_RG255C 0x0316#define QUECTEL_PRODUCT_EM12 0x0512#define QUECTEL_PRODUCT_RM500Q 0x0800#define QUECTEL_PRODUCT_RM520N 0x0801
@@ -1271,6 +1272,9 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500K, 0xff, 0x00, 0x00) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0xff, 0x30) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0xff, 0x30) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG255C, 0xff, 0xff, 0x40) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
Greg Kroah-Hartman
maintainerPATCH 151/184 USB: serial: option: add Telit FN920C04 ECM compositions
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: LI Qingwu <[email protected]>
commit 622865c73ae30f254abdf182f4b66cccbe3e0f10 upstream.
Add support for the Telit Cinterion FN920C04 module when operating in ECM (Ethernet Control Model) mode. The following USB product IDs are used by the module when AT#USBCFG is set to 3 or 7.
0x10A3: ECM + tty (NMEA) + tty (DUN) [+ tty (DIAG)]
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a3 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
0x10A8: ECM + tty (DUN) + tty (AUX) [+ tty (DIAG)]
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=10a8 Rev= 5.15 S: Manufacturer=Telit Cinterion S: Product=FN920 S: SerialNumber=76e7cb38 C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Adding these IDs allows the option driver to automatically create the corresponding /dev/ttyUSB* ports under ECM mode.
Tested with FN920C04 under ECM configuration (USBCFG=3 and 7).
--- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/serial/option.c +4 -0
@@ -1403,10 +1403,14 @@ static const struct usb_device_id option .driver_info = RSVD(0) | NCTRL(3) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a2, 0xff), /* Telit FN920C04 (MBIM) */ .driver_info = NCTRL(4) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a3, 0xff), /* Telit FN920C04 (ECM) */ + .driver_info = NCTRL(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a4, 0xff), /* Telit FN20C04 (rmnet) */ .driver_info = RSVD(0) | NCTRL(3) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a7, 0xff), /* Telit FN920C04 (MBIM) */ .driver_info = NCTRL(4) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a8, 0xff), /* Telit FN920C04 (ECM) */ + .driver_info = NCTRL(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10a9, 0xff), /* Telit FN20C04 (rmnet) */ .driver_info = RSVD(0) | NCTRL(2) | RSVD(3) | RSVD(4) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x10aa, 0xff), /* Telit FN920C04 (MBIM) */
Greg Kroah-Hartman
maintainerPATCH 152/184 usb/core/quirks: Add Huawei ME906S to wakeup quirk
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tim Guttzeit <[email protected]>
commit dfc2cf4dcaa03601cd4ca0f7def88b2630fca6ab upstream.
The list of Huawei LTE modules needing the quirk fixing spurious wakeups was missing the IDs of the Huawei ME906S module, therefore suspend did not work.
--- drivers/usb/core/quirks.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/core/quirks.c +2 -0
@@ -467,6 +467,8 @@ static const struct usb_device_id usb_qu/* Huawei 4G LTE module */ { USB_DEVICE(0x12d1, 0x15bb), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND }, + { USB_DEVICE(0x12d1, 0x15c1), .driver_info = + USB_QUIRK_DISCONNECT_SUSPEND }, { USB_DEVICE(0x12d1, 0x15c3), .driver_info = USB_QUIRK_DISCONNECT_SUSPEND },
Greg Kroah-Hartman
maintainerPATCH 153/184 usb: raw-gadget: do not limit transfer length
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Konovalov <[email protected]>
commit 37b9dd0d114a0e38c502695e30f55a74fb0c37d0 upstream.
Drop the check on the maximum transfer length in Raw Gadget for both control and non-control transfers.
Limiting the transfer length causes a problem with emulating USB devices whose full configuration descriptor exceeds PAGE_SIZE in length.
Overall, there does not appear to be any reason to enforce any kind of transfer length limit on the Raw Gadget side for either control or non-control transfers, so let's just drop the related check.
--- drivers/usb/gadget/legacy/raw_gadget.c | 2 -- 1 file changed, 2 deletions(-)
drivers/usb/gadget/legacy/raw_gadget.c +0 -2
@@ -667,8 +667,6 @@ static void *raw_alloc_io_data(struct usreturn ERR_PTR (-EINVAL );if (!usb_raw_io_flags_valid (io->flags))return ERR_PTR (-EINVAL ); -if (io->length >PAGE_SIZE ) -return ERR_PTR (-EINVAL );if (get_from_user) data =memdup_user (ptr +sizeof (*io), io->length);else {
Greg Kroah-Hartman
maintainerPATCH 154/184 xhci: dbc: enable back DbC in resume if it was enabled before suspend
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit 2bbd38fcd29670e46c0fdb9cd0e90507a8a1bf6a upstream.
DbC is currently only enabled back if it's in configured state during suspend.
If system is suspended after DbC is enabled, but before the device is properly enumerated by the host, then DbC would not be enabled back in resume.
Always enable DbC back in resume if it's suspended in enabled, connected, or configured state
--- drivers/usb/host/xhci-dbgcap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-dbgcap.c +8 -1
@@ -1390,8 +1390,15 @@ int xhci_dbc_suspend(struct xhci_hcd *xhif (!dbc)return 0 ; -if (dbc->state ==DS_CONFIGURED ) +switch (dbc->state) { +case DS_ENABLED : +case DS_CONNECTED : +case DS_CONFIGURED : dbc->resume_required =1 ; +break ; +default : +break ; + }xhci_dbc_stop (dbc);
Greg Kroah-Hartman
maintainerPATCH 155/184 xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit f3d12ec847b945d5d65846c85f062d07d5e73164 upstream.
DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs.
This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length.
As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred.
DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued.
The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data
This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued.
This does in practice solve the issue, but still leaves a small possible gap for the race to trigger.
We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted.
--- drivers/usb/host/xhci-dbgcap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/usb/host/xhci-dbgcap.c +4 -2
@@ -892,7 +892,8 @@ static enum evtreturn xhci_dbc_do_handledev_info (dbc->dev,"DbC configured\n" ); portsc =readl (&dbc->regs->portsc);writel (portsc, &dbc->regs->portsc); -return EVT_GSER ; + ret =EVT_GSER ; +break ; }return EVT_DONE ;
@@ -954,7 +955,8 @@ static enum evtreturn xhci_dbc_do_handlebreak ;case TRB_TYPE (TRB_TRANSFER ):dbc_handle_xfer_event (dbc, evt); - ret =EVT_XFER_DONE ; +if (ret !=EVT_GSER ) + ret =EVT_XFER_DONE ;break ;default :break ;
Greg Kroah-Hartman
maintainerPATCH 156/184 x86/microcode: Fix Entrysign revision check for Zen1/Naples
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Cooper <[email protected]>
commit 876f0d43af78639790bee0e57b39d498ae35adcf upstream.
... to match AMD's statement here:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
--- arch/x86/kernel/cpu/microcode/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/microcode/amd.c +1 -1
@@ -194,7 +194,7 @@ static bool need_sha_check(u32 cur_rev) }switch (cur_rev >>8 ) { -case 0x80012 :return cur_rev <=0x800126f ;break ; +case 0x80012 :return cur_rev <=0x8001277 ;break ;case 0x80082 :return cur_rev <=0x800820f ;break ;case 0x83010 :return cur_rev <=0x830107c ;break ;case 0x86001 :return cur_rev <=0x860010e ;break ;
Greg Kroah-Hartman
maintainerPATCH 157/184 binder: remove "invalid inc weak" check
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alice Ryhl <[email protected]>
commit d90eeb8ecd227c204ab6c34a17b372bd950b7aa2 upstream.
There are no scenarios where a weak increment is invalid on binder_node. The only possible case where it could be invalid is if the kernel delivers BR_DECREFS to the process that owns the node, and then increments the weak refcount again, effectively "reviving" a dead node.
However, that is not possible: when the BR_DECREFS command is delivered, the kernel removes and frees the binder_node. The fact that you were able to call binder_inc_node_nilocked() implies that the node is not yet destroyed, which implies that BR_DECREFS has not been delivered to userspace, so incrementing the weak refcount is valid.
Note that it's currently possible to trigger this condition if the owner calls BINDER_THREAD_EXIT while node->has_weak_ref is true. This causes BC_INCREFS on binder_ref instances to fail when they should not.
--- drivers/android/binder.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-)
drivers/android/binder.c +1 -10
@@ -850,17 +850,8 @@ static int binder_inc_node_nilocked(stru }else {if (!internal) node->local_weak_refs++; -if (!node->has_weak_ref &&list_empty (&node->work.entry)) { -if (target_list ==NULL ) { -pr_err ("invalid inc weak node for %d\n" , - node->debug_id); -return -EINVAL ; - } -/* -* See comment above -*/ +if (!node->has_weak_ref && target_list &&list_empty (&node->work.entry))binder_enqueue_work_ilocked (&node->work, target_list); - } }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 158/184 comedi: fix divide-by-zero in comedi_buf_munge()
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepanshu Kartikey <[email protected]>
commit 87b318ba81dda2ee7b603f4f6c55e78ec3e95974 upstream.
The comedi_buf_munge() function performs a modulo operation async->munge_chan %= async->cmd.chanlist_len without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path.
Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging.
This prevents potential kernel panics from malformed user commands.
--- drivers/comedi/comedi_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/comedi/comedi_buf.c +1 -1
@@ -317,7 +317,7 @@ static unsigned int comedi_buf_munge(strunsigned int count =0 ;const unsigned int num_sample_bytes =comedi_bytes_per_sample (s); -if (!s->munge || (async->cmd.flags &CMDF_RAWDATA )) { +if (!s->munge || (async->cmd.flags &CMDF_RAWDATA ) || async->cmd.chanlist_len ==0 ) { async->munge_count += num_bytes;return num_bytes; }
Greg Kroah-Hartman
maintainerPATCH 159/184 mei: me: add wildcat lake P DID
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Usyskin <[email protected]>
commit 410d6c2ad4d1a88efa0acbb9966693725b564933 upstream.
Add Wildcat Lake P device id.
--- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/misc/mei/hw-me-regs.h +2 -0
@@ -120,6 +120,8 @@#define MEI_DEV_ID_PTL_H 0xE370/* Panther Lake H */ #define MEI_DEV_ID_PTL_P 0xE470/* Panther Lake P */ +#define MEI_DEV_ID_WCL_P 0x4D70/* Wildcat Lake P */ +/* * MEI HW Section */
drivers/misc/mei/pci-me.c +2 -0
@@ -127,6 +127,8 @@ static const struct pci_device_id mei_me {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_H, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_P, MEI_ME_PCH15_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_WCL_P, MEI_ME_PCH15_CFG)}, +/* required last entry */ {0, } };
Greg Kroah-Hartman
maintainerPATCH 160/184 objtool/rust: add one more `noreturn` Rust function
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Ojeda <[email protected]>
commit dbdf2a7feb422f9bacfd12774e624cf26f503eb0 upstream.
Between Rust 1.79 and 1.86, under CONFIG_RUST_KERNEL_DOCTESTS=y, objtool may report:
rust/doctests_kernel_generated.o: warning: objtool:
rust_doctest_kernel_alloc_kbox_rs_13() falls through to next function rust_doctest_kernel_alloc_kvec_rs_0()
(as well as in rust_doctest_kernel_alloc_kvec_rs_0) due to calls to the noreturn symbol:
core::option::expect_failed
from code added in commits 779db37373a3 ("rust: alloc: kvec: implement AsPageIter for VVec") and 671618432f46 ("rust: alloc: kbox: implement AsPageIter for VBox").
Thus add the mangled one to the list so that objtool knows it is actually noreturn.
This can be reproduced as well in other versions by tweaking the code, such as the latest stable Rust (1.90.0).
Stable does not have code that triggers this, but it could have it in the future. Downstream forks could too. Thus tag it for backport.
See commit 56d680dd23c3 ("objtool/rust: list noreturn Rust functions") for more details.
--- tools/objtool/check.c | 1 + 1 file changed, 1 insertion(+)
tools/objtool/check.c +1 -0
@@ -217,6 +217,7 @@ static bool is_rust_noreturn(const struc* these come from the Rust standard library). */ return str_ends_with (func->name,"_4core5sliceSp15copy_from_slice17len_mismatch_fail" ) || +str_ends_with (func->name,"_4core6option13expect_failed" ) ||str_ends_with (func->name,"_4core6option13unwrap_failed" ) ||str_ends_with (func->name,"_4core6result13unwrap_failed" ) || str_ends_with(func->name, "_4core9panicking5panic") ||
Greg Kroah-Hartman
maintainerPATCH 161/184 nvmem: rcar-efuse: add missing MODULE_DEVICE_TABLE
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cosmin Tanislav <[email protected]>
commit 7959ffbec062c35bda02aa635d21ac45dbfacd80 upstream.
The nvmem-rcar-efuse driver can be compiled as a module. Add missing MODULE_DEVICE_TABLE so it can be matched by modalias and automatically loaded by udev.
--- drivers/nvmem/rcar-efuse.c | 1 + 1 file changed, 1 insertion(+)
drivers/nvmem/rcar-efuse.c +1 -0
@@ -127,6 +127,7 @@ static const struct of_device_id rcar_fu { .compatible = "renesas,r8a779h0-otp", .data = &rcar_fuse_v4m }, {/* sentinel */ } }; +MODULE_DEVICE_TABLE (of, rcar_fuse_match);static struct platform_driver rcar_fuse_driver = { .probe = rcar_fuse_probe,
Greg Kroah-Hartman
maintainerPATCH 162/184 misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Junhao Xie <[email protected]>
commit fff111bf45cbeeb659324316d68554e35d350092 upstream.
In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to the dma_buf for comparison purposes. However, this reference is never released when the function returns, leading to a dma_buf memory leak.
Fix this by adding dma_buf_put before returning from the function, ensuring that the temporarily acquired reference is properly released regardless of whether a matching map is found.
--- drivers/misc/fastrpc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/misc/fastrpc.c +2 -0
@@ -384,6 +384,8 @@ static int fastrpc_map_lookup(struct fas }spin_unlock (&fl->lock); +dma_buf_put (buf); +return ret; }
Greg Kroah-Hartman
maintainerPATCH 163/184 most: usb: Fix use-after-free in hdm_disconnect
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victoria Votokina <[email protected]>
commit 4b1270902609ef0d935ed2faa2ea6d122bd148f5 upstream.
hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing.
The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts).
Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface().
This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.
--- drivers/most/most_usb.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
drivers/most/most_usb.c +4 -7
@@ -929,6 +929,10 @@ static void release_mdev(struct device * {struct most_dev *mdev =to_mdev_from_dev (dev); +kfree (mdev->busy_urbs); +kfree (mdev->cap); +kfree (mdev->conf); +kfree (mdev->ep_address);kfree (mdev); }/**
@@ -1121,13 +1125,6 @@ static void hdm_disconnect(struct usb_inif (mdev->dci)device_unregister (&mdev->dci->dev);most_deregister_interface (&mdev->iface); - -kfree (mdev->busy_urbs); -kfree (mdev->cap); -kfree (mdev->conf); -kfree (mdev->ep_address); -put_device (&mdev->dci->dev); -put_device (&mdev->dev); }static int hdm_suspend (struct usb_interface *interface,pm_message_t message)
Greg Kroah-Hartman
maintainerPATCH 164/184 most: usb: hdm_probe: Fix calling put_device() before device initialization
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victoria Votokina <[email protected]>
commit a8cc9e5fcb0e2eef21513a4fec888f5712cb8162 upstream.
The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject.
In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device.
This removes the WARNING and fixes the pre-initialization error path.
--- drivers/most/most_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/most/most_usb.c +1 -1
@@ -1097,7 +1097,7 @@ err_free_cap: err_free_conf:kfree (mdev->conf); err_free_mdev: -put_device (&mdev->dev); +kfree (mdev);return ret; }
Greg Kroah-Hartman
maintainerPATCH 165/184 tcpm: switch check for role_sw device with fw_node
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Grzeschik <[email protected]>
commit 2d8713f807a49b8a67c221670e50ae04967e915d upstream.
When there is no port entry in the tcpci entry itself, the driver will trigger an error message "OF: graph: no port node found in /...../typec" .
It is documented that the dts node should contain an connector entry with ports and several port pointing to devices with usb-role-switch property set. Only when those connector entry is missing, it should check for port entries in the main node.
We switch the search order for looking after ports, which will avoid the failure message while there are explicit connector entries.
--- drivers/usb/typec/tcpm/tcpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/typec/tcpm/tcpm.c +2 -2
@@ -7876,9 +7876,9 @@ struct tcpm_port *tcpm_register_port(str port->partner_desc.identity = &port->partner_ident; - port->role_sw =usb_role_switch_get (port->dev); + port->role_sw =fwnode_usb_role_switch_get (tcpc->fwnode);if (!port->role_sw) - port->role_sw =fwnode_usb_role_switch_get (tcpc->fwnode); + port->role_sw =usb_role_switch_get (port->dev);if (IS_ERR (port->role_sw)) { err =PTR_ERR (port->role_sw); goto out_destroy_wq;
Greg Kroah-Hartman
maintainerPATCH 166/184 tty: serial: sh-sci: fix RSCI FIFO overrun handling
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cosmin Tanislav <[email protected]>
commit ef8fef45c74b5a0059488fda2df65fa133f7d7d0 upstream.
The receive error handling code is shared between RSCI and all other SCIF port types, but the RSCI overrun_reg is specified as a memory offset, while for other SCIF types it is an enum value used to index into the sci_port_params->regs array, as mentioned above the sci_serial_in() function.
For RSCI, the overrun_reg is CSR (0x48), causing the sci_getreg() call inside the sci_handle_fifo_overrun() function to index outside the bounds of the regs array, which currently has a size of 20, as specified by SCI_NR_REGS.
Because of this, we end up accessing memory outside of RSCI's rsci_port_params structure, which, when interpreted as a plat_sci_reg, happens to have a non-zero size, causing the following WARN when sci_serial_in() is called, as the accidental size does not match the supported register sizes.
The existence of the overrun_reg needs to be checked because SCIx_SH3_SCIF_REGTYPE has overrun_reg set to SCLSR, but SCLSR is not present in the regs array.
Avoid calling sci_getreg() for port types which don't use standard register handling.
Use the ops->read_reg() and ops->write_reg() functions to properly read and write registers for RSCI, and change the type of the status variable to accommodate the 32-bit CSR register.
sci_getreg() and sci_serial_in() are also called with overrun_reg in the sci_mpxed_interrupt() interrupt handler, but that code path is not used for RSCI, as it does not have a muxed interrupt.
------------[ cut here ]------------ Invalid register access WARNING: CPU: 0 PID: 0 at drivers/tty/serial/sh-sci.c:522 sci_serial_in+0x38/0xac Modules linked in: renesas_usbhs at24 rzt2h_adc industrialio_adc sha256 cfg80211 bluetooth ecdh_generic ecc rfkill fuse drm backlight ipv6 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.17.0-rc1+ #30 PREEMPT Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sci_serial_in+0x38/0xac lr : sci_serial_in+0x38/0xac
sp : ffff800080003e80
x29: ffff800080003e80 x28: ffff800082195b80 x27: 000000000000000d
x26: ffff8000821956d0 x25: 0000000000000000 x24: ffff800082195b80
x23: ffff000180e0d800 x22: 0000000000000010 x21: 0000000000000000
x20: 0000000000000010 x19: ffff000180e72000 x18: 000000000000000a
x17: ffff8002bcee7000 x16: ffff800080000000 x15: 0720072007200720
x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720
x11: 0000000000000058 x10: 0000000000000018 x9 : ffff8000821a6a48 x8 : 0000000000057fa8 x7 : 0000000000000406 x6 : ffff8000821fea48 x5 : ffff00033ef88408 x4 : ffff8002bcee7000 x3 : ffff800082195b80 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800082195b80
Call trace: sci_serial_in+0x38/0xac (P) sci_handle_fifo_overrun.isra.0+0x70/0x134 sci_er_interrupt+0x50/0x39c __handle_irq_event_percpu+0x48/0x140 handle_irq_event+0x44/0xb0 handle_fasteoi_irq+0xf4/0x1a0 handle_irq_desc+0x34/0x58 generic_handle_domain_irq+0x1c/0x28 gic_handle_irq+0x4c/0x140 call_on_irq_stack+0x30/0x48 do_interrupt_handler+0x80/0x84 el1_interrupt+0x34/0x68 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 default_idle_call+0x28/0x58 (P) do_idle+0x1f8/0x250 cpu_startup_entry+0x34/0x3c rest_init+0xd8/0xe0 console_on_rootfs+0x0/0x6c __primary_switched+0x88/0x90 ---[ end trace 0000000000000000 ]---
--- drivers/tty/serial/sh-sci.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/tty/serial/sh-sci.c +8 -6
@@ -1014,16 +1014,18 @@ static int sci_handle_fifo_overrun(struct uart_port *port)struct sci_port *s =to_sci_port (port);const struct plat_sci_reg *reg;int copied =0 ; -u16 status; +u32 status; - reg =sci_getreg (port, s->params->overrun_reg); -if (!reg->size) -return 0 ; +if (s->type !=SCI_PORT_RSCI ) { + reg =sci_getreg (port, s->params->overrun_reg); +if (!reg->size) +return 0 ; + } - status =sci_serial_in (port, s->params->overrun_reg); + status = s->ops->read_reg (port, s->params->overrun_reg);if (status & s->params->overrun_mask) { status &= ~s->params->overrun_mask; -sci_serial_out (port, s->params->overrun_reg, status); + s->ops->write_reg (port, s->params->overrun_reg, status); port->icount.overrun++;
Signature · 1 line
2.51.1
Greg Kroah-Hartman
maintainerPATCH 167/184 dt-bindings: serial: sh-sci: Fix r8a78000 interrupts
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geert Uytterhoeven <[email protected]>
commit ea9f6d316782bf36141df764634a53d085061091 upstream.
The SCIF instances on R-Car Gen5 have a single interrupt, just like on other R-Car SoCs.
--- Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/serial/renesas,scif.yaml +1 -0
@@ -197,6 +197,7 @@ allOf: - renesas,rcar-gen2-scif - renesas,rcar-gen3-scif - renesas,rcar-gen4-scif + - renesas,rcar-gen5-scif then: properties: interrupts:
Signature · 1 line
2.51.1
Greg Kroah-Hartman
maintainerPATCH 168/184 dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xu Yang <[email protected]>
commit 268eb6fb908bc82ce479e4dba9a2cad11f536c9c upstream.
Only i.MX8MP need dma-range property to let USB controller work properly. Remove dma-range from required list and add limitation for imx8mp.
--- Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +9 -1
@@ -89,13 +89,21 @@ required: - reg - "#address-cells" - "#size-cells" - - dma-ranges - ranges - clocks - clock-names - interrupts - power-domains +allOf: + - if: + properties: + compatible: + const: fsl,imx8mp-dwc3 + then: + required: + - dma-ranges + additionalProperties: false examples:
Greg Kroah-Hartman
maintainerPATCH 169/184 dt-bindings: usb: qcom,snps-dwc3: Fix bindings for X1E80100
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krishna Kurapati <[email protected]>
commit 51cb04abd39097209b871e95ffa7e8584ce7dcba upstream.
Add the missing multiport controller binding to target list.
Fix minItems for interrupt-names to avoid the following error on High Speed controller:
usb@a200000: interrupt-names: ['dwc_usb3', 'pwr_event', 'dp_hs_phy_irq', 'dm_hs_phy_irq'] is too short
--- Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml | 3 +++ 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml +3 -0
@@ -68,6 +68,7 @@ properties: - qcom,sm8550-dwc3 - qcom,sm8650-dwc3 - qcom,x1e80100-dwc3 + - qcom,x1e80100-dwc3-mp - const: qcom,snps-dwc3 reg:
@@ -460,8 +461,10 @@ allOf: then: properties: interrupts: + minItems: 4 maxItems: 5 interrupt-names: + minItems: 4 items: - const: dwc_usb3 - const: pwr_event
Signature · 1 line
2.51.1
Greg Kroah-Hartman
maintainerPATCH 170/184 serial: 8250_dw: handle reset control deassert error
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Shimko <[email protected]>
commit daeb4037adf7d3349b4a1fb792f4bc9824686a4b upstream.
Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails.
Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted.
The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics.
--- drivers/tty/serial/8250/8250_dw.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_dw.c +3 -1
@@ -635,7 +635,9 @@ static int dw8250_probe(struct platform_if (IS_ERR (data->rst))return PTR_ERR (data->rst); -reset_control_deassert (data->rst); + err =reset_control_deassert (data->rst); +if (err) +return dev_err_probe (dev, err,"failed to deassert resets\n" ); err =devm_add_action_or_reset (dev, dw8250_reset_control_assert, data->rst);if (err)
Greg Kroah-Hartman
maintainerPATCH 171/184 serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Eckert <[email protected]>
commit e7cbce761fe3fcbcb49bcf30d4f8ca5e1a9ee2a0 upstream.
The Advantech 2-port serial card with PCI vendor=0x13fe and device=0x0018 has a 'XR17V35X' chip installed on the circuit board. Therefore, this driver can be used instead of theu outdated out-of-tree driver from the manufacturer.
--- drivers/tty/serial/8250/8250_exar.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/tty/serial/8250/8250_exar.c +11 -0
@@ -40,6 +40,8 @@#define PCI_DEVICE_ID_ACCESSIO_COM_4SM 0x10db#define PCI_DEVICE_ID_ACCESSIO_COM_8SM 0x10ea +#define PCI_DEVICE_ID_ADVANTECH_XR17V352 0x0018 +#define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002#define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004#define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
@@ -1622,6 +1624,12 @@ static const struct exar8250_board pbn_f .exit = pci_xr17v35x_exit, }; +static const struct exar8250_board pbn_adv_XR17V352 = { + .num_ports =2 , + .setup = pci_xr17v35x_setup, + .exit = pci_xr17v35x_exit, +}; +static const struct exar8250_board pbn_exar_XR17V4358 = { .num_ports =12 , .setup = pci_xr17v35x_setup,
@@ -1696,6 +1704,9 @@ static const struct pci_device_id exar_pUSR_DEVICE (XR17C152 ,2980 , pbn_exar_XR17C15x),USR_DEVICE (XR17C152 ,2981 , pbn_exar_XR17C15x), +/* ADVANTECH devices */ +EXAR_DEVICE (ADVANTECH ,XR17V352 , pbn_adv_XR17V352), +/* Exar Corp. XR17C15[248] Dual/Quad/Octal UART */ EXAR_DEVICE (EXAR ,XR17C152 , pbn_exar_XR17C15x), EXAR_DEVICE(EXAR, XR17C154, pbn_exar_XR17C15x),
Greg Kroah-Hartman
maintainerPATCH 172/184 serial: 8250_mtk: Enable baud clock and manage in runtime PM
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Golle <[email protected]>
commit d518314a1fa4e980a227d1b2bda1badf433cb932 upstream.
Some MediaTek SoCs got a gated UART baud clock, which currently gets disabled as the clk subsystem believes it would be unused. This results in the uart freezing right after "clk: Disabling unused clocks" on those platforms.
Request the baud clock to be prepared and enabled during probe, and to restore run-time power management capabilities to what it was before commit e32a83c70cf9 ("serial: 8250-mtk: modify mtk uart power and clock management") disable and unprepare the baud clock when suspending the UART, prepare and enable it again when resuming it.
--- drivers/tty/serial/8250/8250_mtk.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_mtk.c +4 -2
@@ -435,6 +435,7 @@ static int __maybe_unused mtk8250_runtimwhile (serial_in (up,MTK_UART_DEBUG0 )); +clk_disable_unprepare (data->uart_clk);clk_disable_unprepare (data->bus_clk);return 0 ;
@@ -445,6 +446,7 @@ static int __maybe_unused mtk8250_runtimstruct mtk8250_data *data =dev_get_drvdata (dev);clk_prepare_enable (data->bus_clk); +clk_prepare_enable (data->uart_clk);return 0 ; }
@@ -475,13 +477,13 @@ static int mtk8250_probe_of(struct platfint dmacnt;#endif - data->uart_clk =devm_clk_get (&pdev->dev,"baud" ); + data->uart_clk =devm_clk_get_enabled (&pdev->dev,"baud" );if (IS_ERR (data->uart_clk)) {/* * For compatibility with older device trees try unnamed * clk when no baud clk can be found. */ - data->uart_clk =devm_clk_get (&pdev->dev,NULL ); + data->uart_clk =devm_clk_get_enabled (&pdev->dev,NULL );if (IS_ERR (data->uart_clk)) {dev_warn (&pdev->dev,"Can't get uart clock\n" );return PTR_ERR (data->uart_clk);
Greg Kroah-Hartman
maintainerPATCH 173/184 serial: sc16is7xx: remove useless enable of enhanced features
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugo Villeneuve <[email protected]>
commit 1c05bf6c0262f946571a37678250193e46b1ff0f upstream.
Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that.
Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured.
--- drivers/tty/serial/sc16is7xx.c | 7 ------- 1 file changed, 7 deletions(-)
drivers/tty/serial/sc16is7xx.c +0 -7
@@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uar div /= prescaler; } -/* Enable enhanced features */ -sc16is7xx_efr_lock (port); -sc16is7xx_port_update (port,SC16IS7XX_EFR_REG , -SC16IS7XX_EFR_ENABLE_BIT , -SC16IS7XX_EFR_ENABLE_BIT ); -sc16is7xx_efr_unlock (port); -/* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT,
Greg Kroah-Hartman
maintainerPATCH 174/184 staging: gpib: Fix device reference leak in fmh_gpib driver
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
commit b1aabb8ef09b4cf0cc0c92ca9dfd19482f3192c1 upstream.
The fmh_gpib driver contains a device reference count leak in fmh_gpib_attach_impl() where driver_find_device() increases the reference count of the device by get_device() when matching but this reference is not properly decreased. Add put_device() in fmh_gpib_detach(), which ensures that the reference count of the device is correctly managed.
Found by code review.
--- drivers/staging/gpib/fmh_gpib/fmh_gpib.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/staging/gpib/fmh_gpib/fmh_gpib.c +5 -0
@@ -1517,6 +1517,11 @@ void fmh_gpib_detach(struct gpib_board * resource_size(e_priv->gpib_iomem_res)); }fmh_gpib_generic_detach (board); + +if (board->dev) { +put_device (board->dev); + board->dev =NULL ; + } } static int fmh_gpib_pci_attach_impl(struct gpib_board *board,
Greg Kroah-Hartman
maintainerPATCH 175/184 staging: gpib: Fix no EOI on 1 and 2 byte writes
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Penkler <[email protected]>
commit d3c4c1f29aadccf2f43530bfa1e60a6d8030fd4a upstream.
EOI (End Or Identify) is a hardware line on the GPIB bus that can be asserted with the last byte of a message to indicate the end of the transfer to the receiving device.
In this driver, a write with send_eoi true is done in 3 parts:
Send first byte directly
Send remaining but 1 bytes using the fifo
Send the last byte directly with EOI asserted
The first byte in a write is always sent by writing to the tms9914 chip directly to setup for the subsequent fifo transfer. We were not checking for a 1 byte write with send_eoi true resulting in EOI not being asserted. Since the fifo transfer was not executed (fifotransfersize == 0) the retval in the test after the fifo transfer code was still 1 from the preceding direct write. This caused it to return without executing the final direct write which would have sent an unsollicited extra byte.
For a 2 byte message the first byte was sent directly. But since the fifo transfer was not executed (fifotransfersize == 1) and the retval in the test after the fifo transfer code was still 1 from the preceding first byte write it returned before the final direct byte write with send_eoi true. The second byte was then sent as a separate 1 byte write to complete the 2 byte write count again without EOI being asserted as above.
Only send the first byte directly if more than 1 byte is to be transferred with send_eoi true.
Also check for retval < 0 for the error return in case the fifo code is not used (1 or 2 byte message with send_eoi true).
--- drivers/staging/gpib/agilent_82350b/agilent_82350b.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/staging/gpib/agilent_82350b/agilent_82350b.c +7 -5
@@ -182,10 +182,12 @@ static int agilent_82350b_accel_write(streturn retval;#endif - retval =agilent_82350b_write (board, buffer,1 ,0 , &num_bytes); - *bytes_written += num_bytes; -if (retval <0 ) -return retval; +if (fifotransferlength >0 ) { + retval =agilent_82350b_write (board, buffer,1 ,0 , &num_bytes); + *bytes_written += num_bytes; +if (retval <0 ) +return retval; + }write_byte (tms_priv, tms_priv->imr0_bits & ~HR_BOIE ,IMR0 );for (i =1 ; i < fifotransferlength;) {
@@ -217,7 +219,7 @@ static int agilent_82350b_accel_write(stbreak ; }write_byte (tms_priv, tms_priv->imr0_bits,IMR0 ); -if (retval) +if (retval <0 )return retval;if (send_eoi) {
Greg Kroah-Hartman
maintainerPATCH 176/184 staging: gpib: Return -EINTR on device clear
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Penkler <[email protected]>
commit aaf2af1ed147ef49be65afb541a67255e9f60d15 upstream.
When the ATN (Attention) line is asserted during a read we get a NIUSB_ATN_STATE_ERROR during a read. For the controller to send a device clear it asserts ATN. Normally this is an error but in the case of a device clear it should be regarded as an interrupt.
Return -EINTR when the Device Clear Active State (DCAS) is entered else signal an error with dev_dbg with status instead of just dev_err.
--- drivers/staging/gpib/ni_usb/ni_usb_gpib.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/staging/gpib/ni_usb/ni_usb_gpib.c +6 -2
@@ -694,8 +694,12 @@ static int ni_usb_read(struct gpib_board*/ break ;case NIUSB_ATN_STATE_ERROR : - retval = -EIO ; -dev_err (&usb_dev->dev,"read when ATN set\n" ); +if (status.ibsta &DCAS ) { + retval = -EINTR ; + }else { + retval = -EIO ; +dev_dbg (&usb_dev->dev,"read when ATN set stat: 0x%06x\n" , status.ibsta); + }break ;case NIUSB_ADDRESSING_ERROR : retval = -EIO ;
Greg Kroah-Hartman
maintainerPATCH 177/184 staging: gpib: Fix sending clear and trigger events
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Penkler <[email protected]>
commit 92a2b74a6b5a5d9b076cd9aa75e63c6461cbd073 upstream.
This driver was not sending device clear or trigger events when the board entered the DCAS or DTAS state respectively in device mode.
DCAS is the Device Clear Active State which is entered on receiving a selective device clear message (SDC) or universal device clear message (DCL) from the controller in charge.
DTAS is the Device Trigger Active State which is entered on receiving a group execute trigger (GET) message from the controller.
In order for an application, implementing a particular device, to detect when one of these states is entered the driver needs to send the appropriate event.
Send the appropriate gpib_event when DCAS or DTAS is set in the reported status word. This sets the DCAS or DTAS bits in the board's status word which can be monitored by the application.
--- drivers/staging/gpib/ni_usb/ni_usb_gpib.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/staging/gpib/ni_usb/ni_usb_gpib.c +4 -1
@@ -327,7 +327,10 @@ static void ni_usb_soft_update_status(st board->status &= ~clear_mask; board->status &= ~ni_usb_ibsta_mask; board->status |= ni_usb_ibsta & ni_usb_ibsta_mask; -//FIXME should generate events on DTAS and DCAS +if (ni_usb_ibsta &DCAS ) +push_gpib_event (board,EVENT_DEV_CLR ); +if (ni_usb_ibsta &DTAS ) +push_gpib_event (board,EVENT_DEV_TRG );spin_lock_irqsave (&board->spinlock, flags);/* remove set status bits from monitored set why ?***/
Greg Kroah-Hartman
maintainerPATCH 178/184 mm/migrate: remove MIGRATEPAGE_UNMAP
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
[ Upstream commit 95c2908f1a4fd608b1cdbb5acef3572e5d769e1c ]
migrate_folio_unmap() is the only user of MIGRATEPAGE_UNMAP. We want to remove MIGRATEPAGE_* completely.
It's rather weird to have a generic MIGRATEPAGE_UNMAP, documented to be returned from address-space callbacks, when it's only used for an internal helper.
Let's start by having only a single "success" return value for migrate_folio_unmap() -- 0 -- by moving the "folio was already freed" check into the single caller.
There is a remaining comment for PG_isolated, which we renamed to PG_movable_ops_isolated recently and forgot to update.
While we might still run into that case with zsmalloc, it's something we want to get rid of soon. So let's just focus that optimization on real folios only for now by excluding movable_ops pages. Note that concurrent freeing can happen at any time and this "already freed" check is not relevant for correctness.
Stable-dep-of: 4ba5a8a7faa6 ("vmw_balloon: indicate success when effectively deflating during migration")
--- include/linux/migrate.h | 1 - mm/migrate.c | 45 ++++++++++++++++++++++----------------------- 2 files changed, 22 insertions(+), 24 deletions(-)
include/linux/migrate.h +0 -1
@@ -18,7 +18,6 @@ struct migration_target_control;* - zero on page migration success; */ #define MIGRATEPAGE_SUCCESS 0 -#define MIGRATEPAGE_UNMAP 1/** * struct movable_operations - Driver page migration
mm/migrate.c +22 -23
84 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 179/184 treewide: remove MIGRATEPAGE_SUCCESS
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
[ Upstream commit fb49a4425cfa163faccd91f913773d3401d3a7d4 ]
At this point MIGRATEPAGE_SUCCESS is misnamed for all folio users, and now that we remove MIGRATEPAGE_UNMAP, it's really the only "success" return value that the code uses and expects.
Let's just get rid of MIGRATEPAGE_SUCCESS completely and just use "0" for success.
Stable-dep-of: 4ba5a8a7faa6 ("vmw_balloon: indicate success when effectively deflating during migration")
--- arch/powerpc/platforms/pseries/cmm.c | 2 - drivers/misc/vmw_balloon.c | 4 +-- drivers/virtio/virtio_balloon.c | 2 - fs/aio.c | 2 - fs/btrfs/inode.c | 4 +-- fs/hugetlbfs/inode.c | 4 +-- fs/jfs/jfs_metapage.c | 8 +++---- include/linux/migrate.h | 10 -------- mm/migrate.c | 40 ++++++++++++++++------------------- mm/migrate_device.c | 2 - mm/zsmalloc.c | 4 +-- 11 files changed, 36 insertions(+), 46 deletions(-)
arch/powerpc/platforms/pseries/cmm.c +1 -1
@@ -545,7 +545,7 @@ static int cmm_migratepage(struct balloo/* balloon page list reference */ put_page (page); -return MIGRATEPAGE_SUCCESS ; +return 0 ; }static void cmm_balloon_compaction_init (void )
drivers/misc/vmw_balloon.c +2 -2
@@ -1806,7 +1806,7 @@ static int vmballoon_migratepage(struct* the list after acquiring the lock. */ get_page (newpage); - ret =MIGRATEPAGE_SUCCESS ; + ret =0 ; }/* Update the balloon list under the @pages_lock */
@@ -1817,7 +1817,7 @@ static int vmballoon_migratepage(struct* If we succeed just insert it to the list and update the statistics * under the lock. */ -if (ret ==MIGRATEPAGE_SUCCESS ) { +if (!ret) {balloon_page_insert (&b->b_dev_info, newpage);__count_vm_event (BALLOON_MIGRATE ); }
drivers/virtio/virtio_balloon.c +1 -1
@@ -875,7 +875,7 @@ static int virtballoon_migratepage(strucballoon_page_finalize (page);put_page (page);/* balloon reference */ - return MIGRATEPAGE_SUCCESS; + return 0; }#endif /* CONFIG_BALLOON_COMPACTION */
fs/aio.c +1 -1
@@ -445,7 +445,7 @@ static int aio_migrate_folio(struct addrfolio_get (dst); rc =folio_migrate_mapping (mapping, dst, src,1 ); -if (rc !=MIGRATEPAGE_SUCCESS ) { +if (rc) {folio_put (dst); goto out_unlock; }
fs/btrfs/inode.c +2 -2
@@ -7430,7 +7430,7 @@ static int btrfs_migrate_folio(struct ad {int ret =filemap_migrate_folio (mapping, dst, src, mode); -if (ret !=MIGRATEPAGE_SUCCESS ) +if (ret)return ret;if (folio_test_ordered (src)) {
@@ -7438,7 +7438,7 @@ static int btrfs_migrate_folio(struct ad folio_set_ordered(dst); } -return MIGRATEPAGE_SUCCESS ; +return 0 ; }#else #define btrfs_migrate_folio NULL
fs/hugetlbfs/inode.c +2 -2
@@ -1054,7 +1054,7 @@ static int hugetlbfs_migrate_folio(strucint rc; rc =migrate_huge_page_move_mapping (mapping, dst, src); -if (rc !=MIGRATEPAGE_SUCCESS ) +if (rc)return rc;if (hugetlb_folio_subpool (src)) {
@@ -1065,7 +1065,7 @@ static int hugetlbfs_migrate_folio(strucfolio_migrate_flags (dst, src); - return MIGRATEPAGE_SUCCESS; + return 0; }#else #define hugetlbfs_migrate_folio NULL
fs/jfs/jfs_metapage.c +4 -4
@@ -169,7 +169,7 @@ static int __metapage_migrate_folio(stru } rc =filemap_migrate_folio (mapping, dst, src, mode); -if (rc !=MIGRATEPAGE_SUCCESS ) +if (rc)return rc;for (i =0 ; i <MPS_PER_PAGE ; i++) {
@@ -199,7 +199,7 @@ static int __metapage_migrate_folio(stru } } -return MIGRATEPAGE_SUCCESS ; +return 0 ; }#endif /* CONFIG_MIGRATION */
@@ -242,7 +242,7 @@ static int __metapage_migrate_folio(strureturn -EAGAIN ; rc =filemap_migrate_folio (mapping, dst, src, mode); -if (rc !=MIGRATEPAGE_SUCCESS ) +if (rc)return rc;if (unlikely (insert_metapage (dst, mp)))
@@ -253,7 +253,7 @@ static int __metapage_migrate_folio(stru mp->folio = dst;remove_metapage (src, mp); - return MIGRATEPAGE_SUCCESS; + return 0; }#endif /* CONFIG_MIGRATION */
include/linux/migrate.h +1 -9
@@ -12,13 +12,6 @@ typedef void free_folio_t(struct folio *struct migration_target_control ; -/* -* Return values from addresss_space_operations.migratepage(): -* - negative errno on page migration failure; -* - zero on page migration success; -*/ -#define MIGRATEPAGE_SUCCESS 0 -/** * struct movable_operations - Driver page migration * @isolate_page:
@@ -34,8 +27,7 @@ struct migration_target_control;* @src page. The driver should copy the contents of the * @src page to the @dst page and set up the fields of @dst page. * Both pages are locked. -* If page migration is successful, the driver should -* return MIGRATEPAGE_SUCCESS. +* If page migration is successful, the driver should return 0. * If the driver cannot migrate the page at the moment, it can return * -EAGAIN. The VM interprets this as a temporary migration failure and * will retry it later. Any other error value is a permanent migration
mm/migrate.c +19 -21
@@ -231,18 +231,17 @@ static void putback_movable_ops_page(str* src and dst are also released by migration core. These pages will not be * folios in the future, so that must be reworked. * -* Returns MIGRATEPAGE_SUCCESS on success, otherwise a negative error -* code. +* Returns 0 on success, otherwise a negative error code. */ static int migrate_movable_ops_page (struct page *dst,struct page *src,enum migrate_mode mode) { -int rc =MIGRATEPAGE_SUCCESS ; +int rc;VM_WARN_ON_ONCE_PAGE (!page_has_movable_ops (src), src);VM_WARN_ON_ONCE_PAGE (!PageMovableOpsIsolated (src), src); rc =page_movable_ops (src)->migrate_page (dst, src, mode); -if (rc ==MIGRATEPAGE_SUCCESS ) +if (!rc)ClearPageMovableOpsIsolated (src);return rc; }
@@ -587,7 +586,7 @@ static int __folio_migrate_mapping(strucif (folio_test_swapbacked (folio))__folio_set_swapbacked (newfolio); -return MIGRATEPAGE_SUCCESS ; +return 0 ; } oldzone =folio_zone (folio);
@@ -688,7 +687,7 @@ static int __folio_migrate_mapping(struc }local_irq_enable (); -return MIGRATEPAGE_SUCCESS ; +return 0 ; } int folio_migrate_mapping(struct address_space *mapping,
@@ -737,7 +736,7 @@ int migrate_huge_page_move_mapping(strucxas_unlock_irq (&xas); -return MIGRATEPAGE_SUCCESS ; +return 0 ; }/*
@@ -853,14 +852,14 @@ static int __migrate_folio(struct addresreturn rc; rc =__folio_migrate_mapping (mapping, dst, src, expected_count); -if (rc !=MIGRATEPAGE_SUCCESS ) +if (rc)return rc;if (src_private)folio_attach_private (dst,folio_detach_private (src));folio_migrate_flags (dst, src); -return MIGRATEPAGE_SUCCESS ; +return 0 ; }/**
@@ -967,7 +966,7 @@ recheck_buffers: } rc =filemap_migrate_folio (mapping, dst, src, mode); -if (rc !=MIGRATEPAGE_SUCCESS ) +if (rc) goto unlock_buffers; bh = head;
@@ -1071,7 +1070,7 @@ static int fallback_migrate_folio(struct* * Return value: * < 0 - error code -* MIGRATEPAGE_SUCCESS - success +* 0 - success */ static int move_to_new_folio (struct folio *dst,struct folio *src,enum migrate_mode mode)
@@ -1099,7 +1098,7 @@ static int move_to_new_folio(struct folielse rc =fallback_migrate_folio (mapping, dst, src, mode); -if (rc ==MIGRATEPAGE_SUCCESS ) { +if (!rc) {/* * For pagecache folios, src->mapping must be cleared before src * is freed. Anonymous folios must stay anonymous until freed.
@@ -1449,7 +1448,7 @@ static int unmap_and_move_huge_page(new_if (folio_ref_count (src) ==1 ) {/* page was freed from under us. So we are done. */ folio_putback_hugetlb (src); -return MIGRATEPAGE_SUCCESS ; +return 0 ; } dst =get_new_folio (src, private);
@@ -1512,8 +1511,7 @@ static int unmap_and_move_huge_page(new_ rc =move_to_new_folio (dst, src, mode);if (page_was_mapped) -remove_migration_ptes (src, - rc ==MIGRATEPAGE_SUCCESS ? dst : src,0 ); +remove_migration_ptes (src, !rc ? dst : src,0 ); unlock_put_anon:folio_unlock (dst);
@@ -1522,7 +1520,7 @@ put_anon:if (anon_vma)put_anon_vma (anon_vma); -if (rc ==MIGRATEPAGE_SUCCESS ) { +if (!rc) {move_hugetlb_state (src, dst, reason); put_new_folio =NULL ; }
@@ -1530,7 +1528,7 @@ put_anon: out_unlock:folio_unlock (src); out: -if (rc ==MIGRATEPAGE_SUCCESS ) +if (!rc)folio_putback_hugetlb (src);else if (rc != -EAGAIN )list_move_tail (&src->lru, ret);
@@ -1640,7 +1638,7 @@ static int migrate_hugetlbs(struct list_ reason, ret_folios);/* * The rules are: -* Success: hugetlb folio will be put back +* 0: hugetlb folio will be put back * -EAGAIN: stay on the from list * -ENOMEM: stay on the from list * Other errno: put on ret_folios list
@@ -1657,7 +1655,7 @@ static int migrate_hugetlbs(struct list_ retry++; nr_retry_pages += nr_pages;break ; -case MIGRATEPAGE_SUCCESS : +case 0 : stats->nr_succeeded += nr_pages;break ;default :
@@ -1711,7 +1709,7 @@ static void migrate_folios_move(struct l reason, ret_folios);/* * The rules are: -* Success: folio will be freed +* 0: folio will be freed * -EAGAIN: stay on the unmap_folios list * Other errno: put on ret_folios list */
@@ -1721,7 +1719,7 @@ static void migrate_folios_move(struct l *thp_retry += is_thp; *nr_retry_pages += nr_pages;break ; -case MIGRATEPAGE_SUCCESS : +case 0 : stats->nr_succeeded += nr_pages; stats->nr_thp_succeeded += is_thp;break ;
mm/migrate_device.c +1 -1
@@ -778,7 +778,7 @@ static void __migrate_device_pages(unsigif (migrate && migrate->fault_page == page) extra_cnt =1 ; r =folio_migrate_mapping (mapping, newfolio, folio, extra_cnt); -if (r !=MIGRATEPAGE_SUCCESS ) +if (r) src_pfns[i] &= ~MIGRATE_PFN_MIGRATE ;else folio_migrate_flags (newfolio, folio);
mm/zsmalloc.c +2 -2
@@ -1746,7 +1746,7 @@ static int zs_page_migrate(struct page ** instead. */ if (!zpdesc->zspage) -return MIGRATEPAGE_SUCCESS ; +return 0 ;/* The page is locked, so this pointer must remain valid */ zspage =get_zspage (zpdesc);
@@ -1813,7 +1813,7 @@ static int zs_page_migrate(struct page *reset_zpdesc (zpdesc);zpdesc_put (zpdesc); -return MIGRATEPAGE_SUCCESS ; +return 0 ; }static void zs_page_putback (struct page *page)
Greg Kroah-Hartman
maintainerPATCH 180/184 vmw_balloon: indicate success when effectively deflating during migration
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Hildenbrand <[email protected]>
[ Upstream commit 4ba5a8a7faa647ada8eae61a36517cf369f5bbe4 ]
When migrating a balloon page, we first deflate the old page to then inflate the new page.
However, if inflating the new page succeeded, we effectively deflated the old page, reducing the balloon size.
In that case, the migration actually worked: similar to migrating+ immediately deflating the new page. The old page will be freed back to the buddy.
Right now, the core will leave the page be marked as isolated (as we returned an error). When later trying to putback that page, we will run into the WARN_ON_ONCE() in balloon_page_putback().
That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction:
stop using __ClearPageMovable()"); before that change, we would have tolerated that way of handling it.
To fix it, let's just return 0 in that case, making the core effectively just clear the "isolated" flag + freeing it back to the buddy as if the migration succeeded. Note that the new page will also get freed when the core puts the last reference.
Note that this also makes it all be more consistent: we will no longer unisolate the page in the balloon driver while keeping it marked as being isolated in migration core.
This was found by code inspection.
--- drivers/misc/vmw_balloon.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/misc/vmw_balloon.c +3 -5
@@ -1737,7 +1737,7 @@ static int vmballoon_migratepage(struct {unsigned long status, flags;struct vmballoon *b; -int ret; +int ret =0 ; b = container_of(b_dev_info, struct vmballoon, b_dev_info);
@@ -1796,17 +1796,15 @@ static int vmballoon_migratepage(struct* A failure happened. While we can deflate the page we just * inflated, this deflation can also encounter an error. Instead * we will decrease the size of the balloon to reflect the -* change and report failure. +* change. */ atomic64_dec (&b->size); - ret = -EBUSY ; }else {/* * Success. Take a reference for the page, and we will add it to * the list after acquiring the lock. */ get_page (newpage); - ret =0 ; }/* Update the balloon list under the @pages_lock */
@@ -1817,7 +1815,7 @@ static int vmballoon_migratepage(struct* If we succeed just insert it to the list and update the statistics * under the lock. */ -if (!ret) { +if (status ==VMW_BALLOON_SUCCESS ) {balloon_page_insert (&b->b_dev_info, newpage);__count_vm_event (BALLOON_MIGRATE ); }
Greg Kroah-Hartman
maintainerPATCH 181/184 xfs: always warn about deprecated mount options
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <[email protected]>
[ Upstream commit 630785bfbe12c3ee3ebccd8b530a98d632b7e39d ]
The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs.
Fix this by making it complain all the time.
--- fs/xfs/xfs_super.c | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-)
fs/xfs/xfs_super.c +21 -12
@@ -1386,16 +1386,25 @@ suffix_kstrtoull(static inline void xfs_fs_warn_deprecated (struct fs_context *fc, -struct fs_parameter *param, -uint64_t flag, -bool value) +struct fs_parameter *param) { -/* Don't print the warning if reconfiguring and current mount point -* already had the flag set +/* +* Always warn about someone passing in a deprecated mount option. +* Previously we wouldn't print the warning if we were reconfiguring +* and current mount point already had the flag set, but that was not +* the right thing to do. +* +* Many distributions mount the root filesystem with no options in the +* initramfs and rely on mount -a to remount the root fs with the +* options in fstab. However, the old behavior meant that there would +* never be a warning about deprecated mount options for the root fs in +* /etc/fstab. On a single-fs system, that means no warning at all. +* +* Compounding this problem are distribution scripts that copy +* /proc/mounts to fstab, which means that we can't remove mount +* options unless we're 100% sure they have only ever been advertised +* in /proc/mounts in response to explicitly provided mount options. */ -if ((fc->purpose &FS_CONTEXT_FOR_RECONFIGURE ) && - !!(XFS_M (fc->root->d_sb)->m_features & flag) == value) -return ;xfs_warn (fc->s_fs_info,"%s mount option is deprecated." , param->key); }
@@ -1543,19 +1552,19 @@ xfs_fs_parse_param(#endif /* Following mount options will be removed in September 2025 */ case Opt_ikeep: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_IKEEP , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_IKEEP ;return 0 ;case Opt_noikeep: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_IKEEP , false); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features &= ~XFS_FEAT_IKEEP ;return 0 ;case Opt_attr2: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_ATTR2 , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_ATTR2 ;return 0 ;case Opt_noattr2: -xfs_fs_warn_deprecated (fc, param,XFS_FEAT_NOATTR2 , true); +xfs_fs_warn_deprecated (fc, param); parsing_mp->m_features |=XFS_FEAT_NOATTR2 ;return 0 ;case Opt_max_open_zones:
Greg Kroah-Hartman
maintainerPATCH 182/184 gpio: regmap: Allow to allocate regmap-irq device
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathieu Dubois-Briand <[email protected]>
[ Upstream commit 553b75d4bfe9264f631d459fe9996744e0672b0e ]
GPIO controller often have support for IRQ: allow to easily allocate both gpio-regmap and regmap-irq in one operation.
Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines")
--- drivers/gpio/gpio-regmap.c | 29 +++++++++++++++++++++++++++-- include/linux/gpio/regmap.h | 11 +++++++++++ 2 files changed, 38 insertions(+), 2 deletions(-)
drivers/gpio/gpio-regmap.c +27 -2
@@ -32,6 +32,11 @@ struct gpio_regmap {unsigned int reg_dir_in_base;unsigned int reg_dir_out_base; +#ifdef CONFIG_REGMAP_IRQ +int regmap_irq_line; +struct regmap_irq_chip_data *irq_chip_data; +#endif +int (*reg_mask_xlate)(struct gpio_regmap *gpio,unsigned int base,unsigned int offset,unsigned int *reg,unsigned int *mask);
@@ -215,6 +220,7 @@ EXPORT_SYMBOL_GPL(gpio_regmap_get_drvdat*/ struct gpio_regmap *gpio_regmap_register (const struct gpio_regmap_config *config) { +struct irq_domain *irq_domain;struct gpio_regmap *gpio;struct gpio_chip *chip;int ret;
@@ -295,8 +301,22 @@ struct gpio_regmap *gpio_regmap_registerif (ret <0 ) goto err_free_gpio; -if (config->irq_domain) { - ret =gpiochip_irqchip_add_domain (chip, config->irq_domain); +#ifdef CONFIG_REGMAP_IRQ +if (config->regmap_irq_chip) { + gpio->regmap_irq_line = config->regmap_irq_line; + ret =regmap_add_irq_chip_fwnode (dev_fwnode (config->parent), config->regmap, + config->regmap_irq_line, config->regmap_irq_flags, +0 , config->regmap_irq_chip, &gpio->irq_chip_data); +if (ret) + goto err_free_gpio; + + irq_domain =regmap_irq_get_domain (gpio->irq_chip_data); + } else +#endif + irq_domain = config->irq_domain; + +if (irq_domain) { + ret =gpiochip_irqchip_add_domain (chip, irq_domain);if (ret) goto err_remove_gpiochip; }
@@ -317,6 +337,11 @@ EXPORT_SYMBOL_GPL(gpio_regmap_register);*/ void gpio_regmap_unregister (struct gpio_regmap *gpio) { +#ifdef CONFIG_REGMAP_IRQ +if (gpio->irq_chip_data) +regmap_del_irq_chip (gpio->regmap_irq_line, gpio->irq_chip_data); +#endif +gpiochip_remove (&gpio->gpio_chip);kfree (gpio); }
include/linux/gpio/regmap.h +11 -0
@@ -40,6 +40,11 @@ struct regmap;* @drvdata: (Optional) Pointer to driver specific data which is * not used by gpio-remap but is provided "as is" to the * driver callback(s). +* @regmap_irq_chip: (Optional) Pointer on an regmap_irq_chip structure. If +* set, a regmap-irq device will be created and the IRQ +* domain will be set accordingly. +* @regmap_irq_line (Optional) The IRQ the device uses to signal interrupts. +* @regmap_irq_flags (Optional) The IRQF_ flags to use for the interrupt. * * The ->reg_mask_xlate translates a given base address and GPIO offset to * register and mask pair. The base address is one of the given register
@@ -78,6 +83,12 @@ struct gpio_regmap_config {int ngpio_per_reg;struct irq_domain *irq_domain; +#ifdef CONFIG_REGMAP_IRQ +struct regmap_irq_chip *regmap_irq_chip; +int regmap_irq_line; +unsigned long regmap_irq_flags; +#endif +int (*reg_mask_xlate)(struct gpio_regmap *gpio,unsigned int base,unsigned int offset,unsigned int *reg,unsigned int *mask);
Greg Kroah-Hartman
maintainerPATCH 183/184 gpio: regmap: add the .fixed_direction_output configuration parameter
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ioana Ciornei <[email protected]>
[ Upstream commit 00aaae60faf554c27c95e93d47f200a93ff266ef ]
There are GPIO controllers such as the one present in the LX2160ARDB QIXIS FPGA which have fixed-direction input and output GPIO lines mixed together in a single register. This cannot be modeled using the gpio-regmap as-is since there is no way to present the true direction of a GPIO line.
In order to make this use case possible, add a new configuration parameter - fixed_direction_output - into the gpio_regmap_config structure. This will enable user drivers to provide a bitmap that represents the fixed direction of the GPIO lines.
Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines")
--- drivers/gpio/gpio-regmap.c | 26 ++++++++++++++++++++++++-- include/linux/gpio/regmap.h | 5 +++++ 2 files changed, 29 insertions(+), 2 deletions(-)
drivers/gpio/gpio-regmap.c +24 -2
@@ -31,6 +31,7 @@ struct gpio_regmap {unsigned int reg_clr_base;unsigned int reg_dir_in_base;unsigned int reg_dir_out_base; +unsigned long *fixed_direction_output;#ifdef CONFIG_REGMAP_IRQ int regmap_irq_line;
@@ -134,6 +135,13 @@ static int gpio_regmap_get_direction(strunsigned int base, val, reg, mask;int invert, ret; +if (gpio->fixed_direction_output) { +if (test_bit (offset, gpio->fixed_direction_output)) +return GPIO_LINE_DIRECTION_OUT ; +else +return GPIO_LINE_DIRECTION_IN ; + } +if (gpio->reg_dat_base && !gpio->reg_set_base)return GPIO_LINE_DIRECTION_IN ;if (gpio->reg_set_base && !gpio->reg_dat_base)
@@ -283,6 +291,17 @@ struct gpio_regmap *gpio_regmap_register goto err_free_gpio; } +if (config->fixed_direction_output) { + gpio->fixed_direction_output =bitmap_alloc (chip->ngpio, +GFP_KERNEL ); +if (!gpio->fixed_direction_output) { + ret = -ENOMEM ; + goto err_free_gpio; + } +bitmap_copy (gpio->fixed_direction_output, + config->fixed_direction_output, chip->ngpio); + } +/* if not set, assume there is only one register */ gpio->ngpio_per_reg = config->ngpio_per_reg;if (!gpio->ngpio_per_reg)
@@ -299,7 +318,7 @@ struct gpio_regmap *gpio_regmap_register ret =gpiochip_add_data (chip, gpio);if (ret <0 ) - goto err_free_gpio; + goto err_free_bitmap;#ifdef CONFIG_REGMAP_IRQ if (config->regmap_irq_chip) {
@@ -308,7 +327,7 @@ struct gpio_regmap *gpio_regmap_register config->regmap_irq_line, config->regmap_irq_flags, 0, config->regmap_irq_chip, &gpio->irq_chip_data);if (ret) - goto err_free_gpio; + goto err_free_bitmap; irq_domain =regmap_irq_get_domain (gpio->irq_chip_data); }else
@@ -325,6 +344,8 @@ struct gpio_regmap *gpio_regmap_register err_remove_gpiochip:gpiochip_remove (chip); +err_free_bitmap: +bitmap_free (gpio->fixed_direction_output); err_free_gpio:kfree (gpio);return ERR_PTR (ret);
@@ -343,6 +364,7 @@ void gpio_regmap_unregister(struct gpio_#endif gpiochip_remove (&gpio->gpio_chip); +bitmap_free (gpio->fixed_direction_output);kfree (gpio); }EXPORT_SYMBOL_GPL (gpio_regmap_unregister);
include/linux/gpio/regmap.h +5 -0
@@ -37,6 +37,10 @@ struct regmap;* offset to a register/bitmask pair. If not * given the default gpio_regmap_simple_xlate() * is used. +* @fixed_direction_output: +* (Optional) Bitmap representing the fixed direction of +* the GPIO lines. Useful when there are GPIO lines with a +* fixed direction mixed together in the same register. * @drvdata: (Optional) Pointer to driver specific data which is * not used by gpio-remap but is provided "as is" to the * driver callback(s).
@@ -82,6 +86,7 @@ struct gpio_regmap_config {int reg_stride;int ngpio_per_reg;struct irq_domain *irq_domain; +unsigned long *fixed_direction_output;#ifdef CONFIG_REGMAP_IRQ struct regmap_irq_chip *regmap_irq_chip;
Greg Kroah-Hartman
maintainerPATCH 184/184 gpio: idio-16: Define fixed direction of the GPIO lines
In reply to Greg Kroah-Hartman6.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Breathitt Gray <[email protected]>
[ Upstream commit 2ba5772e530f73eb847fb96ce6c4017894869552 ]
The direction of the IDIO-16 GPIO lines is fixed with the first 16 lines as output and the remaining 16 lines as input. Set the gpio_config fixed_direction_output member to represent the fixed direction of the GPIO lines.
--- drivers/gpio/gpio-idio-16.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpio/gpio-idio-16.c +5 -0
@@ -6,6 +6,7 @@#define DEFAULT_SYMBOL_NAMESPACE "GPIO_IDIO_16" +#include <linux/bitmap.h> #include <linux/bits.h> #include <linux/device.h> #include <linux/err.h>
@@ -107,6 +108,7 @@ int devm_idio_16_regmap_register(structstruct idio_16_data *data;struct regmap_irq_chip *chip;struct regmap_irq_chip_data *chip_data; +DECLARE_BITMAP (fixed_direction_output,IDIO_16_NGPIO );if (!config->parent)return -EINVAL ;
@@ -164,6 +166,9 @@ int devm_idio_16_regmap_register(struct gpio_config.irq_domain =regmap_irq_get_domain (chip_data); gpio_config.reg_mask_xlate = idio_16_reg_mask_xlate; +bitmap_from_u64 (fixed_direction_output,GENMASK_U64 (15 ,0 )); + gpio_config.fixed_direction_output = fixed_direction_output; +return PTR_ERR_OR_ZERO (devm_gpio_regmap_register (dev, &gpio_config)); }EXPORT_SYMBOL_GPL (devm_idio_16_regmap_register);
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Hi
no regressions here on x86_64 (RKL, Intel 11th Gen. CPU)
Thanks
Am 27.10.2025 um 19:34 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.17.6-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 10e3f8e671f7771f981d181af9ed5a9382cb11f3
* git describe: v6.17.4-346-g10e3f8e671f7
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.17.y/build/v6.17.4-346-g10e3f8e671f7
## Test Regressions (compared to v6.17.4-161-g3cc198d00990)
## Metric Regressions (compared to v6.17.4-161-g3cc198d00990)
## Test Fixes (compared to v6.17.4-161-g3cc198d00990)
## Metric Fixes (compared to v6.17.4-161-g3cc198d00990)
## Test result summary
total: 130764, pass: 110823, fail: 4161, skip: 15780, xfail: 0
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 139 passed, 0 failed
* arm64: 57 total, 54 passed, 3 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 33 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 39 passed, 1 failed
* riscv: 25 total, 25 passed, 0 failed
* s390: 22 total, 22 passed, 0 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 48 passed, 1 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mm
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-rust
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
6.17.6-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.17.6-rc1rv-g10e3f8e671f7
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #1 SMP PREEMPT_DYNAMIC Tue Oct 28 19:19:34 JST 2025
Thanks
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.17:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
120 tests: 120 pass, 0 failLinux version: 6.17.6-rc1-g10e3f8e671f7
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.17.6-rc1-g10e3f8e671f7 #118 SMP PREEMPT_DYNAMIC Tue Oct 28 13:25:13 -00 2025 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Hi Greg
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.
Quoted 5 lines
thanks,
greg k-h
-------------
Build and Boot Report for 6.17.6-rc1
The kernel version 6.17.6-rc1 was built and boot-tested using qemu-x86_64 and qemu-arm64 with the default configuration (defconfig). The build and boot processes completed successfully, and the kernel operated as expected in the virtualized environments without any issues.
Build Details :
Kernel Version: 6.17.6-rc1
Source: linux-stable-rc.git
Commit : 10e3f8e671f7771f981d181af9ed5a9382cb11f3
Best regards,
Dileep Malepu
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.6-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.17.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · On Mon, 27 Oct 2025 19:34:42 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.17.6 release. There are 184 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 29 Oct 2025 18:34:15 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for arm and loongarch64:
Thanks!
Cheers,
Miguel