Skip to contentSkip to conversation

6.5.8-rc1 review

PATCH In review Greg Kroah-Hartman 9 participants 212 messages Oct 16, 2023 – Nov 30, 2023 2 messages not in the archive Page 2 of 2

Subsystems (2)
lore
Share & tools
lore
author maintainer
#155 lore raw

PATCH 150/191 Input: psmouse - fix fast_reconnect function for PS/2 mode

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeffery Miller <[email protected]>

commit e2cb5cc822b6c9ee72c56ce1d81671b22c05406a upstream.

When the SMBus connection is attempted psmouse_smbus_init() sets the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will fallback to PS/2 mode, replacing the psmouse private data. This can cause issues on resume, since psmouse_smbus_reconnect() expects to find an instance of struct psmouse_smbus_dev in psmouse->private.

The issue was uncovered when in 92e24e0e57f7 ("Input: psmouse - add delay when deactivating for SMBus mode") psmouse_smbus_reconnect() started attempting to use more of the data structure. The commit was since reverted, not because it was at fault, but because there was found a better way of doing what it was attempting to do.

Fix the problem by resetting the fast_reconnect pointer in psmouse structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2 mode is used.

---
 drivers/input/mouse/elantech.c  |    1 +
 drivers/input/mouse/synaptics.c |    1 +
 2 files changed, 2 insertions(+)
drivers/input/mouse/elantech.c +1 -0
@@ -2114,6 +2114,7 @@ static int elantech_setup_ps2(struct psm
 	psmouse->protocol_handler = elantech_process_byte;
 	psmouse->disconnect = elantech_disconnect;
 	psmouse->reconnect = elantech_reconnect;
+	psmouse->fast_reconnect = NULL;
 	psmouse->pktsize = info->hw_version > 1 ? 6 : 4;
 
 	return 0;
drivers/input/mouse/synaptics.c +1 -0
@@ -1623,6 +1623,7 @@ static int synaptics_init_ps2(struct psm
 	psmouse->set_rate = synaptics_set_rate;
 	psmouse->disconnect = synaptics_disconnect;
 	psmouse->reconnect = synaptics_reconnect;
+	psmouse->fast_reconnect = NULL;
 	psmouse->cleanup = synaptics_reset;
 	/* Synaptics can usually stay in sync without extra help */
 	psmouse->resync_time = 0;
author maintainer
#156 lore raw

PATCH 151/191 Input: xpad - add PXN V900 support

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthias Berndt <[email protected]>

commit a65cd7ef5a864bdbbe037267c327786b7759d4c6 upstream.

Add VID and PID to the xpad_device table to allow driver to use the PXN V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode.

---
 drivers/input/joystick/xpad.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/input/joystick/xpad.c +2 -0
@@ -271,6 +271,7 @@ static const struct xpad_device {
 	{ 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
 	{ 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
 	{ 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
+	{ 0x11ff, 0x0511, "PXN V900", 0, XTYPE_XBOX360 },
 	{ 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
 	{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
 	{ 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
@@ -475,6 +476,7 @@ static const struct usb_device_id xpad_t
 	XPAD_XBOX360_VENDOR(0x1038),		/* SteelSeries controllers */
 	XPAD_XBOXONE_VENDOR(0x10f5),		/* Turtle Beach Controllers */
 	XPAD_XBOX360_VENDOR(0x11c9),		/* Nacon GC100XF */
+	XPAD_XBOX360_VENDOR(0x11ff),		/* PXN V900 */
 	XPAD_XBOX360_VENDOR(0x1209),		/* Ardwiino Controllers */
 	XPAD_XBOX360_VENDOR(0x12ab),		/* Xbox 360 dance pads */
 	XPAD_XBOX360_VENDOR(0x1430),		/* RedOctane Xbox 360 controllers */
author maintainer
#157 lore raw

PATCH 152/191 Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Szilard Fabian <[email protected]>

commit 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 upstream.

In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411 refuses to work and it's not possible to type for example a dm-crypt passphrase without the help of an external keyboard.

i8042.nomux kernel parameter resolves this issue but using that a PS/2 mouse is detected. This input device is unused even when the i2c-hid-acpi kernel module is blacklisted making the integrated ELAN touchpad (04F3:308A) not working at all.

Since the integrated touchpad is managed by the i2c_designware input driver in the Linux kernel and you can't find a PS/2 mouse port on the computer I think it's safe to not use the PS/2 mouse port at all.

---
 drivers/input/serio/i8042-acpipnpio.h |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/input/serio/i8042-acpipnpio.h +8 -0
@@ -619,6 +619,14 @@ static const struct dmi_system_id i8042_
 		.driver_data = (void *)(SERIO_QUIRK_NOMUX)
 	},
 	{
+		/* Fujitsu Lifebook E5411 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU CLIENT COMPUTING LIMITED"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E5411"),
+		},
+		.driver_data = (void *)(SERIO_QUIRK_NOAUX)
+	},
+	{
 		/* Gigabyte M912 */
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
author maintainer
#158 lore raw

PATCH 153/191 Input: xpad - add HyperX Clutch Gladiate Support

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Max Nguyen <[email protected]>

commit e28a0974d749e5105d77233c0a84d35c37da047e upstream.

Add HyperX controller support to xpad_device and xpad_table.

---
 drivers/input/joystick/xpad.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/input/joystick/xpad.c +2 -0
@@ -130,6 +130,7 @@ static const struct xpad_device {
 	{ 0x0079, 0x18d4, "GPD Win 2 X-Box Controller", 0, XTYPE_XBOX360 },
 	{ 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 },
 	{ 0x03eb, 0xff02, "Wooting Two (Legacy)", 0, XTYPE_XBOX360 },
+	{ 0x03f0, 0x0495, "HyperX Clutch Gladiate", 0, XTYPE_XBOXONE },
 	{ 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
 	{ 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
 	{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
@@ -458,6 +459,7 @@ static const struct usb_device_id xpad_t
 	{ USB_INTERFACE_INFO('X', 'B', 0) },	/* Xbox USB-IF not-approved class */
 	XPAD_XBOX360_VENDOR(0x0079),		/* GPD Win 2 controller */
 	XPAD_XBOX360_VENDOR(0x03eb),		/* Wooting Keyboards (Legacy) */
+	XPAD_XBOXONE_VENDOR(0x03f0),		/* HP HyperX Xbox One controllers */
 	XPAD_XBOX360_VENDOR(0x044f),		/* Thrustmaster Xbox 360 controllers */
 	XPAD_XBOX360_VENDOR(0x045e),		/* Microsoft Xbox 360 controllers */
 	XPAD_XBOXONE_VENDOR(0x045e),		/* Microsoft Xbox One controllers */

A message that is not in the archive (sent off-list or not yet received): MW4PR84MB17804D57BB57C0E2FB66EFC6EBADA@MW4PR84MB1780.NAMPRD84.PROD.OUTLOOK.COM

A message that is not in the archive (sent off-list or not yet received): MW4PR84MB178083997D411DFFD45BEFCDEBB7A@MW4PR84MB1780.NAMPRD84.PROD.OUTLOOK.COM

#161 lore raw

PATCH 153/191 Input: xpad - add HyperX Clutch Gladiate Support

Quoted 11 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch.  This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next LTS branch due to project schedules.

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10, and 5.15 as well.  The main purpose would to add our device ID for support across older android devices.  Feel free to let us know if there are any concerns or issues.

Quoted 43 lines

*CAUTION: External Email *

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Max Nguyen <[email protected]>

commit e28a0974d749e5105d77233c0a84d35c37da047e upstream.

Add HyperX controller support to xpad_device and xpad_table.

---
drivers/input/joystick/xpad.c | 2 ++

1 file changed, 2 insertions(+)
drivers/input/joystick/xpad.c +1 -0
@@ -130,6 +130,7 @@ static const struct xpad_device {
 { 0x0079, 0x18d4, "GPD Win 2 X-Box Controller", 0, XTYPE_XBOX360 },
 { 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 },
 { 0x03eb, 0xff02, "Wooting Two (Legacy)", 0, XTYPE_XBOX360 },
+ { 0x03f0, 0x0495, "HyperX Clutch Gladiate", 0, XTYPE_XBOXONE },
 { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
 { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
 { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
@@ -458,6 +459,7 @@ static const struct usb_device_id xpad_t

{ USB_INTERFACE_INFO('X', 'B', 0) }, /* Xbox USB-IF not-approved class */ XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 controller */ XPAD_XBOX360_VENDOR(0x03eb), /* Wooting Keyboards (Legacy) */
+ XPAD_XBOXONE_VENDOR(0x03f0), /* HP HyperX Xbox One controllers */ XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster Xbox 360 controllers */ XPAD_XBOX360_VENDOR(0x045e), /* Microsoft Xbox 360 controllers */ XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft Xbox One controllers */

author maintainer
#162 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 12 lines · Max
Quoted 12 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next LTS branch due to project schedules.

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Quoted 8 lines
Quoted 2 lines

Max

Hi Linux team,

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10, and 5.15 as well.  The main purpose would to add our device ID for support across older android devices.  Feel free to let us know if there are any concerns or issues.

Please provide a working backport that you have tested as I think it did not apply cleanly on its own, right?

thanks,

greg k-h

#163 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 20 lines · Greg KH
Quoted 11 lines · Max
Quoted 11 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next LTS branch due to project schedules.

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Quoted 8 lines
Quoted 2 lines

Max

Hi Linux team,

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10, and 5.15 as well.  The main purpose would to add our device ID for support across older android devices.  Feel free to let us know if there are any concerns or issues.

Quoted 6 lines

Please provide a working backport that you have tested as I think it did not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Do you have any general suggestions or instructions on how I can create a backport to test?  I apologize as this is new to me.

Also, what do you mean by the patch did not apply cleanly on its own?

#164 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 27 lines · Max
Quoted 25 lines · Greg KH
Quoted 11 lines · Max
Quoted 11 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next LTS branch due to project schedules.

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Quoted 8 lines
Quoted 2 lines

Max

Hi Linux team,

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10, and 5.15 as well.  The main purpose would to add our device ID for support across older android devices.  Feel free to let us know if there are any concerns or issues.

Please provide a working backport that you have tested as I think it did not apply cleanly on its own, right?

thanks,

Quoted 8 lines
Quoted 1 line

greg k-h

Hi Greg,

Do you have any general suggestions or instructions on how I can create a backport to test?  I apologize as this is new to me.

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time.  We will be sending separate patches for each kernel shortly.

author maintainer
#165 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 37 lines · Max
Quoted 35 lines · Max
Quoted 24 lines · Greg KH
Quoted 16 lines · Max
Quoted 8 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next
LTS branch due to project schedules.

Quoted 6 lines

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

Quoted 7 lines

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10,
and 5.15 as well.  The main purpose would to add our device ID for support
across older android devices.  Feel free to let us know if there are any
concerns or issues.

Quoted 6 lines

Please provide a working backport that you have tested as I think it did not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Quoted 8 lines
Quoted 5 lines

Do you have any general suggestions or instructions on how I can create a backport to test?  I apologize as this is new to me.

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time. We will be sending separate patches for each kernel shortly.

Why not send a series adding all of the missing backported patches? That makes it better so that all of the supported devices are now working on the older kernels, not just this one.

thanks,

greg k-h

#166 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 43 lines · Greg KH
Quoted 34 lines · Max
Quoted 33 lines · Max
Quoted 24 lines · Greg KH
Quoted 16 lines · Max
Quoted 8 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next
LTS branch due to project schedules.

Quoted 6 lines

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

Quoted 7 lines

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10,
and 5.15 as well.  The main purpose would to add our device ID for support
across older android devices.  Feel free to let us know if there are any
concerns or issues.

Quoted 6 lines

Please provide a working backport that you have tested as I think it did not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Quoted 8 lines
Quoted 5 lines

Do you have any general suggestions or instructions on how I can create a backport to test?  I apologize as this is new to me.

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time. We will be sending separate patches for each kernel shortly.

Quoted 7 lines

Why not send a series adding all of the missing backported patches? That makes it better so that all of the supported devices are now working on the older kernels, not just this one.

thanks,

greg k-h

Hi Greg,

I am planning to send a patch for LTS versions 4.19 through 5.15 since the single patch can apply to all of these versions with no issues.  I plan to send a separate patch for LTS 6.1 since this patch could not apply to the older LTS versions.

Is this what you had in mind when you mentioned series?

#167 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 51 lines · Max
Quoted 49 lines · Greg KH
Quoted 34 lines · Max
Quoted 33 lines · Max
Quoted 24 lines · Greg KH
Quoted 16 lines · Max
Quoted 8 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next
LTS branch due to project schedules.

Quoted 6 lines

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

Quoted 7 lines

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10,
and 5.15 as well.  The main purpose would to add our device ID for support
across older android devices.  Feel free to let us know if there are any
concerns or issues.

Quoted 6 lines

Please provide a working backport that you have tested as I think it did not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Quoted 8 lines
Quoted 5 lines

Do you have any general suggestions or instructions on how I can create a backport to test?  I apologize as this is new to me.

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time. We will be sending separate patches for each kernel shortly.

Why not send a series adding all of the missing backported patches? That makes it better so that all of the supported devices are now working on the older kernels, not just this one.

thanks,

Quoted 8 lines
Quoted 1 line

greg k-h

Hi Greg,

I am planning to send a patch for LTS versions 4.19 through 5.15 since the single patch can apply to all of these versions with no issues.  I plan to send a separate patch for LTS 6.1 since this patch could not apply to the older LTS versions.

Is this what you had in mind when you mentioned series?

I resent the patches as a series as described in the patch submission process on the kernel webpage.  I reviewed and believe it should be formatted correctly now.  Let me know if there are any issues.

author maintainer
#168 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 65 lines · Max
Quoted 63 lines · Max
Quoted 46 lines · Greg KH
Quoted 39 lines · Max
Quoted 38 lines · Max
Quoted 24 lines · Greg KH
Quoted 16 lines · Max
Quoted 8 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next
LTS branch due to project schedules.

Quoted 6 lines

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

Quoted 7 lines

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10,
and 5.15 as well.  The main purpose would to add our device ID for support
across older android devices.  Feel free to let us know if there are any
concerns or issues.

Quoted 7 lines

Please provide a working backport that you have tested as I think it did
not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Do you have any general suggestions or instructions on how I can create
a backport to test?  I apologize as this is new to me.

Quoted 6 lines
Quoted 2 lines

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time.
We will be sending separate patches for each kernel shortly.

Quoted 7 lines

Why not send a series adding all of the missing backported patches? That makes it better so that all of the supported devices are now working on the older kernels, not just this one.

thanks,

greg k-h

Hi Greg,

I am planning to send a patch for LTS versions 4.19 through 5.15 since the single patch can apply to all of these versions with no issues.  I plan to send a separate patch for LTS 6.1 since this patch could not apply to the older LTS versions.

Quoted 5 lines
Quoted 2 lines

Is this what you had in mind when you mentioned series?

I resent the patches as a series as described in the patch submission process on the kernel webpage.  I reviewed and believe it should be formatted correctly now.  Let me know if there are any issues.

No, I mean, for each stable kernel version/tree/whatever, send a patch series that adds all of the missing ids to the table, not just your one specific device you are asking for here. That way the trees are all in sync proper AND any future patches will also apply cleanly/properly to the older kernel versions.

Does that help?

thanks,

greg k-h

#169 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 74 lines · Greg KH
Quoted 62 lines · Max
Quoted 61 lines · Max
Quoted 46 lines · Greg KH
Quoted 39 lines · Max
Quoted 38 lines · Max
Quoted 24 lines · Greg KH
Quoted 16 lines · Max
Quoted 8 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next
LTS branch due to project schedules.

Quoted 6 lines

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

Quoted 7 lines

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10,
and 5.15 as well.  The main purpose would to add our device ID for support
across older android devices.  Feel free to let us know if there are any
concerns or issues.

Quoted 7 lines

Please provide a working backport that you have tested as I think it did
not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Do you have any general suggestions or instructions on how I can create
a backport to test?  I apologize as this is new to me.

Quoted 6 lines
Quoted 2 lines

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time.
We will be sending separate patches for each kernel shortly.

Quoted 7 lines

Why not send a series adding all of the missing backported patches? That makes it better so that all of the supported devices are now working on the older kernels, not just this one.

thanks,

greg k-h

Hi Greg,

I am planning to send a patch for LTS versions 4.19 through 5.15 since the single patch can apply to all of these versions with no issues.  I plan to send a separate patch for LTS 6.1 since this patch could not apply to the older LTS versions.

Quoted 5 lines
Quoted 2 lines

Is this what you had in mind when you mentioned series?

I resent the patches as a series as described in the patch submission process on the kernel webpage.  I reviewed and believe it should be formatted correctly now.  Let me know if there are any issues.

No, I mean, for each stable kernel version/tree/whatever, send a patch series that adds all of the missing ids to the table, not just your one specific device you are asking for here. That way the trees are all in sync proper AND any future patches will also apply cleanly/properly to the older kernel versions.

Quoted 5 lines

Does that help?

thanks,

greg k-h

Hi Greg,

We only have 1 device for now as our other devices should not be known to public yet.  Do you mean missing IDs for other company/brand's devices?  We are unsure of the other device's compatibility requirements as they are not ours.

I sent a 2 series patch for the different stable kernel versions.  Does my latest patch submission work or should I be sending a patch for each individual stable kernel version?

author maintainer
#170 lore raw

Re: [PATCH 6.5 153/191] Input: xpad - add HyperX Clutch Gladiate Support

Quoted 78 lines · Max
Quoted 76 lines · Greg KH
Quoted 62 lines · Max
Quoted 61 lines · Max
Quoted 46 lines · Greg KH
Quoted 39 lines · Max
Quoted 38 lines · Max
Quoted 24 lines · Greg KH
Quoted 16 lines · Max
Quoted 8 lines

Hi,

We would like to apply this patch to version 6.1 of the LTS branch. This is to add a project ID for Android support for a gamepad controller.  We would like it to apply sooner than waiting for the next
LTS branch due to project schedules.

Quoted 6 lines

commite28a0974d749e5105d77233c0a84d35c37da047e

Regards,

Max

Hi Linux team,

Quoted 7 lines

We would like to have this patch backported to LTS versions 4.19, 5.4, 5.10,
and 5.15 as well.  The main purpose would to add our device ID for support
across older android devices.  Feel free to let us know if there are any
concerns or issues.

Quoted 7 lines

Please provide a working backport that you have tested as I think it did
not apply cleanly on its own, right?

thanks,

greg k-h

Hi Greg,

Do you have any general suggestions or instructions on how I can create
a backport to test?  I apologize as this is new to me.

Quoted 6 lines
Quoted 2 lines

Also, what do you mean by the patch did not apply cleanly on its own?

We found that the patch does not apply correctly to the previous LTS kernels.  This is most likely due to addition of newer devices over time.
We will be sending separate patches for each kernel shortly.

Quoted 7 lines

Why not send a series adding all of the missing backported patches? That makes it better so that all of the supported devices are now working on the older kernels, not just this one.

thanks,

greg k-h

Hi Greg,

I am planning to send a patch for LTS versions 4.19 through 5.15 since the single patch can apply to all of these versions with no issues.  I plan to send a separate patch for LTS 6.1 since this patch could not apply to the older LTS versions.

Quoted 5 lines
Quoted 2 lines

Is this what you had in mind when you mentioned series?

I resent the patches as a series as described in the patch submission process on the kernel webpage.  I reviewed and believe it should be formatted correctly now.  Let me know if there are any issues.

No, I mean, for each stable kernel version/tree/whatever, send a patch series that adds all of the missing ids to the table, not just your one specific device you are asking for here. That way the trees are all in sync proper AND any future patches will also apply cleanly/properly to the older kernel versions.

Does that help?

Quoted 8 lines
Quoted 3 lines

thanks,

greg k-h

Hi Greg,

We only have 1 device for now as our other devices should not be known to public yet.  Do you mean missing IDs for other company/brand's devices?

No, I mean the missing git commits for the file you are touching that has the list of the devices in it. That is out of date and should be brought up to the latest version with the full list of devices, right?

thanks,

greg k-h

author maintainer
#171 lore raw

PATCH 154/191 Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit 423622a90abb243944d1517b9f57db53729e45c4 upstream.

Add a special case for gpio_count == 1 && gpio_int_idx == 0 to goodix_add_acpi_gpio_mappings().

It seems that on newer x86/ACPI devices the reset and irq GPIOs are no longer listed as GPIO resources instead there is only 1 GpioInt resource and _PS0 does the whole reset sequence for us.

This means that we must call acpi_device_fix_up_power() on these devices to ensure that the chip is reset before we try to use it.

This part was already fixed in commit 3de93e6ed2df ("Input: goodix - call acpi_device_fix_up_power() in some cases") by adding a call to acpi_device_fix_up_power() to the generic "Unexpected ACPI resources" catch all.

But it turns out that this case on some hw needs some more special handling. Specifically the firmware may bootup with the IRQ pin in output mode. The reset sequence from ACPI _PS0 (executed by acpi_device_fix_up_power()) should put the pin in input mode, but the GPIO subsystem has cached the direction at bootup, causing request_irq() to fail due to gpiochip_lock_as_irq() failure:

[    9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0
[    9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060
[    9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8
[    9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
[    9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ
[    9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio
[    9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5

Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0 which adds an ACPI GPIO lookup table for the int GPIO even though we cannot use it for reset purposes (as there is no reset GPIO).

Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call succeed, which will explicitly set the direction to input fixing the issue.

Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since there is only 1 GPIO in the ACPI resources the reset entry in that lookup table will amount to a no-op.

---
 drivers/input/touchscreen/goodix.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
drivers/input/touchscreen/goodix.c +19 -0
@@ -900,6 +900,25 @@ static int goodix_add_acpi_gpio_mappings
 		dev_info(dev, "No ACPI GpioInt resource, assuming that the GPIO order is reset, int\n");
 		ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_GPIO;
 		gpio_mapping = acpi_goodix_int_last_gpios;
+	} else if (ts->gpio_count == 1 && ts->gpio_int_idx == 0) {
+		/*
+		 * On newer devices there is only 1 GpioInt resource and _PS0
+		 * does the whole reset sequence for us.
+		 */
+		acpi_device_fix_up_power(ACPI_COMPANION(dev));
+
+		/*
+		 * Before the _PS0 call the int GPIO may have been in output
+		 * mode and the call should have put the int GPIO in input mode,
+		 * but the GPIO subsys cached state may still think it is
+		 * in output mode, causing gpiochip_lock_as_irq() failure.
+		 *
+		 * Add a mapping for the int GPIO to make the
+		 * gpiod_int = gpiod_get(..., GPIOD_IN) call succeed,
+		 * which will explicitly set the direction to input.
+		 */
+		ts->irq_pin_access_method = IRQ_PIN_ACCESS_NONE;
+		gpio_mapping = acpi_goodix_int_first_gpios;
 	} else {
 		dev_warn(dev, "Unexpected ACPI resources: gpio_count %d, gpio_int_idx %d\n",
 			 ts->gpio_count, ts->gpio_int_idx);
author maintainer
#172 lore raw

PATCH 155/191 tee: amdtee: fix use-after-free vulnerability in amdtee_close_session

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Rijo Thomas <[email protected]>

commit f4384b3e54ea813868bb81a861bf5b2406e15d8f upstream.

There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via:

    kref_put(&sess->refcount, destroy_session);

the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session.

To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically.

---
 drivers/tee/amdtee/core.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/tee/amdtee/core.c +6 -4
@@ -217,12 +217,12 @@ unlock:
 	return rc;
 }
 
+/* mutex must be held by caller */
 static void destroy_session(struct kref *ref)
 {
 	struct amdtee_session *sess = container_of(ref, struct amdtee_session,
 						   refcount);
 
-	mutex_lock(&session_list_mutex);
 	list_del(&sess->list_node);
 	mutex_unlock(&session_list_mutex);
 	kfree(sess);
@@ -272,7 +272,8 @@ int amdtee_open_session(struct tee_conte
 	if (arg->ret != TEEC_SUCCESS) {
 		pr_err("open_session failed %d\n", arg->ret);
 		handle_unload_ta(ta_handle);
-		kref_put(&sess->refcount, destroy_session);
+		kref_put_mutex(&sess->refcount, destroy_session,
+			       &session_list_mutex);
 		goto out;
 	}
 
@@ -290,7 +291,8 @@ int amdtee_open_session(struct tee_conte
 		pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS);
 		handle_close_session(ta_handle, session_info);
 		handle_unload_ta(ta_handle);
-		kref_put(&sess->refcount, destroy_session);
+		kref_put_mutex(&sess->refcount, destroy_session,
+			       &session_list_mutex);
 		rc = -ENOMEM;
 		goto out;
 	}
@@ -331,7 +333,7 @@ int amdtee_close_session(struct tee_cont
 	handle_close_session(ta_handle, session_info);
 	handle_unload_ta(ta_handle);
 
-	kref_put(&sess->refcount, destroy_session);
+	kref_put_mutex(&sess->refcount, destroy_session, &session_list_mutex);
 
 	return 0;
 }
author maintainer
#173 lore raw

PATCH 156/191 mctp: perform route lookups under a RCU read-side lock

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jeremy Kerr <[email protected]>

commit 5093bbfc10ab6636b32728e35813cbd79feb063c upstream.

Our current route lookups (mctp_route_lookup and mctp_route_lookup_null) traverse the net's route list without the RCU read lock held. This means the route lookup is subject to preemption, resulting in an potential grace period expiry, and so an eventual kfree() while we still have the route pointer.

Add the proper read-side critical section locks around the route lookups, preventing premption and a possible parallel kfree.

The remaining net->mctp.routes accesses are already under a rcu_read_lock, or protected by the RTNL for updates.

Based on an analysis from Sili Luo <[email protected]>, where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion.

---
 net/mctp/route.c |   22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)
net/mctp/route.c +16 -6
@@ -737,6 +737,8 @@ struct mctp_route *mctp_route_lookup(str
 {
 	struct mctp_route *tmp, *rt = NULL;
 
+	rcu_read_lock();
+
 	list_for_each_entry_rcu(tmp, &net->mctp.routes, list) {
 		/* TODO: add metrics */
 		if (mctp_rt_match_eid(tmp, dnet, daddr)) {
@@ -747,21 +749,29 @@ struct mctp_route *mctp_route_lookup(str
 		}
 	}
 
+	rcu_read_unlock();
+
 	return rt;
 }
 
 static struct mctp_route *mctp_route_lookup_null(struct net *net,
 						 struct net_device *dev)
 {
-	struct mctp_route *rt;
+	struct mctp_route *tmp, *rt = NULL;
+
+	rcu_read_lock();
 
-	list_for_each_entry_rcu(rt, &net->mctp.routes, list) {
-		if (rt->dev->dev == dev && rt->type == RTN_LOCAL &&
-		    refcount_inc_not_zero(&rt->refs))
-			return rt;
+	list_for_each_entry_rcu(tmp, &net->mctp.routes, list) {
+		if (tmp->dev->dev == dev && tmp->type == RTN_LOCAL &&
+		    refcount_inc_not_zero(&tmp->refs)) {
+			rt = tmp;
+			break;
+		}
 	}
 
-	return NULL;
+	rcu_read_unlock();
+
+	return rt;
 }
 
 static int mctp_do_fragment_route(struct mctp_route *rt, struct sk_buff *skb,
author maintainer
#174 lore raw

PATCH 157/191 block: Dont invalidate pagecache for invalid falloc modes

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sarthak Kukreti <[email protected]>

commit 1364a3c391aedfeb32aa025303ead3d7c91cdf9d upstream.

Only call truncate_bdev_range() if the fallocate mode is supported. This fixes a bug where data in the pagecache could be invalidated if the fallocate() was called on the block device with an invalid mode.

Fixes 25f4c41415e5 ("block: implement (some of) fallocate for block devices")
Fixes line? I've never seen those wrapped.
---
 block/fops.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)
block/fops.c +16 -5
@@ -659,24 +659,35 @@ static long blkdev_fallocate(struct file
 
 	filemap_invalidate_lock(inode->i_mapping);
 
-	/* Invalidate the page cache, including dirty pages. */
-	error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
-	if (error)
-		goto fail;
-
+	/*
+	 * Invalidate the page cache, including dirty pages, for valid
+	 * de-allocate mode calls to fallocate().
+	 */
 	switch (mode) {
 	case FALLOC_FL_ZERO_RANGE:
 	case FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE:
+		error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
+		if (error)
+			goto fail;
+
 		error = blkdev_issue_zeroout(bdev, start >> SECTOR_SHIFT,
 					     len >> SECTOR_SHIFT, GFP_KERNEL,
 					     BLKDEV_ZERO_NOUNMAP);
 		break;
 	case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE:
+		error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
+		if (error)
+			goto fail;
+
 		error = blkdev_issue_zeroout(bdev, start >> SECTOR_SHIFT,
 					     len >> SECTOR_SHIFT, GFP_KERNEL,
 					     BLKDEV_ZERO_NOFALLBACK);
 		break;
 	case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE | FALLOC_FL_NO_HIDE_STALE:
+		error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end);
+		if (error)
+			goto fail;
+
 		error = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT,
 					     len >> SECTOR_SHIFT, GFP_KERNEL);
 		break;
author maintainer
#175 lore raw

PATCH 158/191 nfp: flower: avoid rmmod nfp crash issues

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yanguo Li <[email protected]>

commit 14690995c14109852c7ba6e316045c02e4254272 upstream.

When there are CT table entries, and you rmmod nfp, the following events can happen:

task1:

    nfp_net_pci_remove
          ↓
    nfp_flower_stop->(asynchronous)tcf_ct_flow_table_cleanup_work(3)
          ↓
    nfp_zone_table_entry_destroy(1)

task2:

    nfp_fl_ct_handle_nft_flow(2)

When the execution order is (1)->(2)->(3), it will crash. Therefore, in the function nfp_fl_ct_del_flow, nf_flow_table_offload_del_cb needs to be executed synchronously.

At the same time, in order to solve the deadlock problem and the problem of rtnl_lock sometimes failing, replace rtnl_lock with the private nfp_fl_lock.

Fixes 7cc93d888df7 ("nfp: flower-ct: remove callback delete deadlock")
---
 drivers/net/ethernet/netronome/nfp/flower/cmsg.c      |   10 ++++---
 drivers/net/ethernet/netronome/nfp/flower/conntrack.c |   19 +++++++++-----
 drivers/net/ethernet/netronome/nfp/flower/main.h      |    2 +
 drivers/net/ethernet/netronome/nfp/flower/metadata.c  |    2 +
 drivers/net/ethernet/netronome/nfp/flower/offload.c   |   24 +++++++++++++-----
 drivers/net/ethernet/netronome/nfp/flower/qos_conf.c  |   20 +++++++++------
 6 files changed, 54 insertions(+), 23 deletions(-)
drivers/net/ethernet/netronome/nfp/flower/cmsg.c +6 -4
@@ -210,6 +210,7 @@ nfp_flower_cmsg_merge_hint_rx(struct nfp
 	unsigned int msg_len = nfp_flower_cmsg_get_data_len(skb);
 	struct nfp_flower_cmsg_merge_hint *msg;
 	struct nfp_fl_payload *sub_flows[2];
+	struct nfp_flower_priv *priv;
 	int err, i, flow_cnt;
 
 	msg = nfp_flower_cmsg_get_data(skb);
@@ -228,14 +229,15 @@ nfp_flower_cmsg_merge_hint_rx(struct nfp
 		return;
 	}
 
-	rtnl_lock();
+	priv = app->priv;
+	mutex_lock(&priv->nfp_fl_lock);
 	for (i = 0; i < flow_cnt; i++) {
 		u32 ctx = be32_to_cpu(msg->flow[i].host_ctx);
 
 		sub_flows[i] = nfp_flower_get_fl_payload_from_ctx(app, ctx);
 		if (!sub_flows[i]) {
 			nfp_flower_cmsg_warn(app, "Invalid flow in merge hint\n");
-			goto err_rtnl_unlock;
+			goto err_mutex_unlock;
 		}
 	}
 
@@ -244,8 +246,8 @@ nfp_flower_cmsg_merge_hint_rx(struct nfp
 	if (err == -ENOMEM)
 		nfp_flower_cmsg_warn(app, "Flow merge memory fail.\n");
 
-err_rtnl_unlock:
-	rtnl_unlock();
+err_mutex_unlock:
+	mutex_unlock(&priv->nfp_fl_lock);
 }
 
 static void
drivers/net/ethernet/netronome/nfp/flower/conntrack.c +13 -6
@@ -2130,8 +2130,6 @@ nfp_fl_ct_offload_nft_flow(struct nfp_fl
 	struct nfp_fl_ct_flow_entry *ct_entry;
 	struct netlink_ext_ack *extack = NULL;
 
-	ASSERT_RTNL();
-
 	extack = flow->common.extack;
 	switch (flow->command) {
 	case FLOW_CLS_REPLACE:
@@ -2177,9 +2175,13 @@ int nfp_fl_ct_handle_nft_flow(enum tc_se
 
 	switch (type) {
 	case TC_SETUP_CLSFLOWER:
-		rtnl_lock();
+		while (!mutex_trylock(&zt->priv->nfp_fl_lock)) {
+			if (!zt->nft) /* avoid deadlock */
+				return err;
+			msleep(20);
+		}
 		err = nfp_fl_ct_offload_nft_flow(zt, flow);
-		rtnl_unlock();
+		mutex_unlock(&zt->priv->nfp_fl_lock);
 		break;
 	default:
 		return -EOPNOTSUPP;
@@ -2207,6 +2209,7 @@ int nfp_fl_ct_del_flow(struct nfp_fl_ct_
 	struct nfp_fl_ct_flow_entry *ct_entry;
 	struct nfp_fl_ct_zone_entry *zt;
 	struct rhashtable *m_table;
+	struct nf_flowtable *nft;
 
 	if (!ct_map_ent)
 		return -ENOENT;
@@ -2225,8 +2228,12 @@ int nfp_fl_ct_del_flow(struct nfp_fl_ct_
 		if (ct_map_ent->cookie > 0)
 			kfree(ct_map_ent);
 
-		if (!zt->pre_ct_count) {
-			zt->nft = NULL;
+		if (!zt->pre_ct_count && zt->nft) {
+			nft = zt->nft;
+			zt->nft = NULL; /* avoid deadlock */
+			nf_flow_table_offload_del_cb(nft,
+						     nfp_fl_ct_handle_nft_flow,
+						     zt);
 			nfp_fl_ct_clean_nft_entries(zt);
 		}
 		break;
drivers/net/ethernet/netronome/nfp/flower/main.h +2 -0
@@ -297,6 +297,7 @@ struct nfp_fl_internal_ports {
  * @predt_list:		List to keep track of decap pretun flows
  * @neigh_table:	Table to keep track of neighbor entries
  * @predt_lock:		Lock to serialise predt/neigh table updates
+ * @nfp_fl_lock:	Lock to protect the flow offload operation
  */
 struct nfp_flower_priv {
 	struct nfp_app *app;
@@ -339,6 +340,7 @@ struct nfp_flower_priv {
 	struct list_head predt_list;
 	struct rhashtable neigh_table;
 	spinlock_t predt_lock; /* Lock to serialise predt/neigh table updates */
+	struct mutex nfp_fl_lock; /* Protect the flow operation */
 };
 
 /**
drivers/net/ethernet/netronome/nfp/flower/metadata.c +2 -0
@@ -528,6 +528,8 @@ int nfp_flower_metadata_init(struct nfp_
 	if (err)
 		goto err_free_stats_ctx_table;
 
+	mutex_init(&priv->nfp_fl_lock);
+
 	err = rhashtable_init(&priv->ct_zone_table, &nfp_zone_table_params);
 	if (err)
 		goto err_free_merge_table;
drivers/net/ethernet/netronome/nfp/flower/offload.c +18 -6
@@ -1009,8 +1009,6 @@ int nfp_flower_merge_offloaded_flows(str
 	u64 parent_ctx = 0;
 	int err;
 
-	ASSERT_RTNL();
-
 	if (sub_flow1 == sub_flow2 ||
 	    nfp_flower_is_merge_flow(sub_flow1) ||
 	    nfp_flower_is_merge_flow(sub_flow2))
@@ -1727,19 +1725,30 @@ static int
 nfp_flower_repr_offload(struct nfp_app *app, struct net_device *netdev,
 			struct flow_cls_offload *flower)
 {
+	struct nfp_flower_priv *priv = app->priv;
+	int ret;
+
 	if (!eth_proto_is_802_3(flower->common.protocol))
 		return -EOPNOTSUPP;
 
+	mutex_lock(&priv->nfp_fl_lock);
 	switch (flower->command) {
 	case FLOW_CLS_REPLACE:
-		return nfp_flower_add_offload(app, netdev, flower);
+		ret = nfp_flower_add_offload(app, netdev, flower);
+		break;
 	case FLOW_CLS_DESTROY:
-		return nfp_flower_del_offload(app, netdev, flower);
+		ret = nfp_flower_del_offload(app, netdev, flower);
+		break;
 	case FLOW_CLS_STATS:
-		return nfp_flower_get_stats(app, netdev, flower);
+		ret = nfp_flower_get_stats(app, netdev, flower);
+		break;
 	default:
-		return -EOPNOTSUPP;
+		ret = -EOPNOTSUPP;
+		break;
 	}
+	mutex_unlock(&priv->nfp_fl_lock);
+
+	return ret;
 }
 
 static int nfp_flower_setup_tc_block_cb(enum tc_setup_type type,
@@ -1778,6 +1787,7 @@ static int nfp_flower_setup_tc_block(str
 	repr_priv = repr->app_priv;
 	repr_priv->block_shared = f->block_shared;
 	f->driver_block_list = &nfp_block_cb_list;
+	f->unlocked_driver_cb = true;
 
 	switch (f->command) {
 	case FLOW_BLOCK_BIND:
@@ -1876,6 +1886,8 @@ nfp_flower_setup_indr_tc_block(struct ne
 	     nfp_flower_internal_port_can_offload(app, netdev)))
 		return -EOPNOTSUPP;
 
+	f->unlocked_driver_cb = true;
+
 	switch (f->command) {
 	case FLOW_BLOCK_BIND:
 		cb_priv = nfp_flower_indr_block_cb_priv_lookup(app, netdev);
drivers/net/ethernet/netronome/nfp/flower/qos_conf.c +13 -7
@@ -523,25 +523,31 @@ int nfp_flower_setup_qos_offload(struct
 {
 	struct netlink_ext_ack *extack = flow->common.extack;
 	struct nfp_flower_priv *fl_priv = app->priv;
+	int ret;
 
 	if (!(fl_priv->flower_ext_feats & NFP_FL_FEATS_VF_RLIM)) {
 		NL_SET_ERR_MSG_MOD(extack, "unsupported offload: loaded firmware does not support qos rate limit offload");
 		return -EOPNOTSUPP;
 	}
 
+	mutex_lock(&fl_priv->nfp_fl_lock);
 	switch (flow->command) {
 	case TC_CLSMATCHALL_REPLACE:
-		return nfp_flower_install_rate_limiter(app, netdev, flow,
-						       extack);
+		ret = nfp_flower_install_rate_limiter(app, netdev, flow, extack);
+		break;
 	case TC_CLSMATCHALL_DESTROY:
-		return nfp_flower_remove_rate_limiter(app, netdev, flow,
-						      extack);
+		ret = nfp_flower_remove_rate_limiter(app, netdev, flow, extack);
+		break;
 	case TC_CLSMATCHALL_STATS:
-		return nfp_flower_stats_rate_limiter(app, netdev, flow,
-						     extack);
+		ret = nfp_flower_stats_rate_limiter(app, netdev, flow, extack);
+		break;
 	default:
-		return -EOPNOTSUPP;
+		ret = -EOPNOTSUPP;
+		break;
 	}
+	mutex_unlock(&fl_priv->nfp_fl_lock);
+
+	return ret;
 }
 
 /* Offload tc action, currently only for tc police */
author maintainer
#176 lore raw

PATCH 159/191 can: sja1000: Always restart the Tx queue after an overrun

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Miquel Raynal <[email protected]>

commit b5efb4e6fbb06da928526eca746f3de243c12ab2 upstream.

Upstream commit 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") fixes an issue with Renesas own SJA1000 CAN controller reception: the Rx buffer is only 5 messages long, so when the bus loaded (eg. a message every 50us), overrun may easily happen. Upon an overrun situation, due to a possible internal crosstalk situation, the controller enters a frozen state which only can be unlocked with a soft reset (experimentally). The solution was to offload a call to sja1000_start() in a threaded handler. This needs to happen in process context as this operation requires to sleep. sja1000_start() basically enters "reset mode", performs a proper software reset and returns back into "normal mode".

Since this fix was introduced, we no longer observe any stalls in reception. However it was sporadically observed that the transmit path would now freeze. Further investigation blamed the fix mentioned above, and especially the reset operation. Reproducing the reset in a loop helped identifying what could possibly go wrong. The sja1000 is a single Tx queue device, which leverages the netdev helpers to process one Tx message at a time. The logic is: the queue is stopped, the message sent to the transceiver, once properly transmitted the controller sets a status bit which triggers an interrupt, in the interrupt handler the transmission status is checked and the queue woken up. Unfortunately, if an overrun happens, we might perform the soft reset precisely between the transmission of the buffer to the transceiver and the advent of the transmission status bit. We would then stop the transmission operation without re-enabling the queue, leading to all further transmissions to be ignored.

The reset interrupt can only happen while the device is "open", and after a reset we anyway want to resume normal operations, no matter if a packet to transmit got dropped in the process, so we shall wake up the queue. Restarting the device and waking-up the queue is exactly what sja1000_set_mode(CAN_MODE_START) does. In order to be consistent about the queue state, we must acquire a lock both in the reset handler and in the transmit path to ensure serialization of both operations. It turns out, a lock is already held when entering the transmit path, so we can just acquire/release it as well with the regular net helpers inside the threaded interrupt handler and this way we should be safe. As the reset handler might still be called after the transmission of a frame to the transceiver but before it actually gets transmitted, we must ensure we don't leak the skb, so we free it (the behavior is consistent, no matter if there was an skb on the stack or not).

Fixes 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs")
[mkl: fixed call to can_free_echo_skb()]
---
 drivers/net/can/sja1000/sja1000.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/net/can/sja1000/sja1000.c +7 -1
index 0ada0e160e93..743c2eb62b87 100644
@@ -392,7 +392,13 @@ static irqreturn_t sja1000_reset_interrupt(int irq, void *dev_id)
 	struct net_device *dev = (struct net_device *)dev_id;
 
 	netdev_dbg(dev, "performing a soft reset upon overrun\n");
-	sja1000_start(dev);
+
+	netif_tx_lock(dev);
+
+	can_free_echo_skb(dev, 0, NULL);
+	sja1000_set_mode(dev, CAN_MODE_START);
+
+	netif_tx_unlock(dev);
 
 	return IRQ_HANDLED;
 }
Signature · 1 line
2.42.0
author maintainer
#177 lore raw

PATCH 160/191 power: supply: qcom_battmgr: fix battery_id type

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sebastian Reichel <[email protected]>

commit 383eba9f9a7f4cd639d367ea5daa6df2be392c54 upstream.

qcom_battmgr_update_request.battery_id is written to using cpu_to_le32() and should be of type __le32, just like all other 32bit integer requests for qcom_battmgr.

---
 drivers/power/supply/qcom_battmgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/power/supply/qcom_battmgr.c +1 -1
index de77df97b3a4..a05fd00711f6 100644
@@ -105,7 +105,7 @@ struct qcom_battmgr_property_request {
 
 struct qcom_battmgr_update_request {
 	struct pmic_glink_hdr hdr;
-	u32 battery_id;
+	__le32 battery_id;
 };
 
 struct qcom_battmgr_charge_time_request {
Signature · 1 line
2.42.0
author maintainer
#178 lore raw

PATCH 161/191 power: supply: qcom_battmgr: fix enable request endianness

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johan Hovold <[email protected]>

commit 8894b432548851f705f72ff135d3dcbd442a18d1 upstream.

Add the missing endianness conversion when sending the enable request so that the driver will work also on a hypothetical big-endian machine.

This issue was reported by sparse.

Fixes 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply")
Cc Bjorn Andersson <[email protected]>
---
 drivers/power/supply/qcom_battmgr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/power/supply/qcom_battmgr.c +3 -3
index a05fd00711f6..ec163d1bcd18 100644
@@ -1282,9 +1282,9 @@ static void qcom_battmgr_enable_worker(struct work_struct *work)
 {
 	struct qcom_battmgr *battmgr = container_of(work, struct qcom_battmgr, enable_work);
 	struct qcom_battmgr_enable_request req = {
-		.hdr.owner = PMIC_GLINK_OWNER_BATTMGR,
-		.hdr.type = PMIC_GLINK_NOTIFY,
-		.hdr.opcode = BATTMGR_REQUEST_NOTIFICATION,
+		.hdr.owner = cpu_to_le32(PMIC_GLINK_OWNER_BATTMGR),
+		.hdr.type = cpu_to_le32(PMIC_GLINK_NOTIFY),
+		.hdr.opcode = cpu_to_le32(BATTMGR_REQUEST_NOTIFICATION),
 	};
 	int ret;
 
Signature · 1 line
2.42.0
author maintainer
#179 lore raw

PATCH 162/191 usb: typec: ucsi: Use GET_CAPABILITY attributes data to set power supply scope

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mario Limonciello <[email protected]>

commit c9ca8de2eb15f9da24113e652980c61f95a47530 upstream.

On some OEM systems, adding a W7900 dGPU triggers RAS errors and hangs at a black screen on startup. This issue occurs only if ucsi_acpi has loaded before amdgpu has loaded. The reason for this failure is that amdgpu uses power_supply_is_system_supplied() to determine if running on AC or DC power at startup. If this value is reported incorrectly the dGPU will also be programmed incorrectly and trigger errors.

power_supply_is_system_supplied() reports the wrong value because UCSI power supplies provided as part of the system don't properly report the scope as "DEVICE" scope (not powering the system).

In order to fix this issue check the capabilities reported from the UCSI power supply to ensure that it supports charging a battery and that it can be powered by AC. Mark the scope accordingly.

---
 drivers/usb/typec/ucsi/psy.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/usb/typec/ucsi/psy.c +9 -0
@@ -37,6 +37,15 @@ static int ucsi_psy_get_scope(struct ucs
 	struct device *dev = con->ucsi->dev;
 
 	device_property_read_u8(dev, "scope", &scope);
+	if (scope == POWER_SUPPLY_SCOPE_UNKNOWN) {
+		u32 mask = UCSI_CAP_ATTR_POWER_AC_SUPPLY |
+			   UCSI_CAP_ATTR_BATTERY_CHARGING;
+
+		if (con->ucsi->cap.attributes & mask)
+			scope = POWER_SUPPLY_SCOPE_SYSTEM;
+		else
+			scope = POWER_SUPPLY_SCOPE_DEVICE;
+	}
 	val->intval = scope;
 	return 0;
 }
author maintainer
#180 lore raw

PATCH 163/191 cgroup: Remove duplicates in cgroup v1 tasks file

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michal Koutný <[email protected]>

commit 1ca0b605150501b7dc59f3016271da4eb3e96fce upstream.

One PID may appear multiple times in a preloaded pidlist. (Possibly due to PID recycling but we have reports of the same task_struct appearing with different PIDs, thus possibly involving transfer of PID via de_thread().)

Because v1 seq_file iterator uses PIDs as position, it leads to a message:

Quoted 1 line

seq_file: buggy .next function kernfs_seq_next did not update position index

Conservative and quick fix consists of removing duplicates from tasks file (as opposed to removing pidlists altogether). It doesn't affect correctness (it's sufficient to show a PID once), performance impact would be hidden by unconditional sorting of the pidlist already in place (asymptotically).

---
 kernel/cgroup/cgroup-v1.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
kernel/cgroup/cgroup-v1.c +2 -3
@@ -360,10 +360,9 @@ static int pidlist_array_load(struct cgr
 	}
 	css_task_iter_end(&it);
 	length = n;
-	/* now sort & (if procs) strip out duplicates */
+	/* now sort & strip out duplicates (tgids or recycled thread PIDs) */
 	sort(array, length, sizeof(pid_t), cmppid, NULL);
-	if (type == CGROUP_FILE_PROCS)
-		length = pidlist_uniq(array, length);
+	length = pidlist_uniq(array, length);
 
 	l = cgroup_pidlist_find_create(cgrp, type);
 	if (!l) {
author maintainer
#181 lore raw

PATCH 164/191 dma-buf: add dma_fence_timestamp helper

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christian König <[email protected]>

commit b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 upstream.

When a fence signals there is a very small race window where the timestamp isn't updated yet. sync_file solves this by busy waiting for the timestamp to appear, but on other ocassions didn't handled this correctly.

Provide a dma_fence_timestamp() helper function for this and use it in all appropriate cases.

Another alternative would be to grab the spinlock when that happens.

v2 by teddy: add a wait parameter to wait for the timestamp to show up, in case
the accurate timestamp is needed and/or the timestamp is not based on ktime (e.g. hw timestamp)
v3 chk: drop the parameter again for unified handling

---
 drivers/dma-buf/dma-fence-unwrap.c     |   13 ++++---------
 drivers/dma-buf/sync_file.c            |    9 +++------
 drivers/gpu/drm/scheduler/sched_main.c |    2 +-
 include/linux/dma-fence.h              |   19 +++++++++++++++++++
 4 files changed, 27 insertions(+), 16 deletions(-)
drivers/dma-buf/dma-fence-unwrap.c +4 -9
@@ -76,16 +76,11 @@ struct dma_fence *__dma_fence_unwrap_mer
 		dma_fence_unwrap_for_each(tmp, &iter[i], fences[i]) {
 			if (!dma_fence_is_signaled(tmp)) {
 				++count;
-			} else if (test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT,
-					    &tmp->flags)) {
-				if (ktime_after(tmp->timestamp, timestamp))
-					timestamp = tmp->timestamp;
 			} else {
-				/*
-				 * Use the current time if the fence is
-				 * currently signaling.
-				 */
-				timestamp = ktime_get();
+				ktime_t t = dma_fence_timestamp(tmp);
+
+				if (ktime_after(t, timestamp))
+					timestamp = t;
 			}
 		}
 	}
drivers/dma-buf/sync_file.c +3 -6
@@ -268,13 +268,10 @@ static int sync_fill_fence_info(struct d
 		sizeof(info->driver_name));
 
 	info->status = dma_fence_get_status(fence);
-	while (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) &&
-	       !test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags))
-		cpu_relax();
 	info->timestamp_ns =
-		test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags) ?
-		ktime_to_ns(fence->timestamp) :
-		ktime_set(0, 0);
+		dma_fence_is_signaled(fence) ?
+			ktime_to_ns(dma_fence_timestamp(fence)) :
+			ktime_set(0, 0);
 
 	return info->status;
 }
drivers/gpu/drm/scheduler/sched_main.c +1 -1
@@ -929,7 +929,7 @@ drm_sched_get_cleanup_job(struct drm_gpu
 
 		if (next) {
 			next->s_fence->scheduled.timestamp =
-				job->s_fence->finished.timestamp;
+				dma_fence_timestamp(&job->s_fence->finished);
 			/* start TO timer for next job */
 			drm_sched_start_timeout(sched);
 		}
include/linux/dma-fence.h +19 -0
@@ -568,6 +568,25 @@ static inline void dma_fence_set_error(s
 	fence->error = error;
 }
 
+/**
+ * dma_fence_timestamp - helper to get the completion timestamp of a fence
+ * @fence: fence to get the timestamp from.
+ *
+ * After a fence is signaled the timestamp is updated with the signaling time,
+ * but setting the timestamp can race with tasks waiting for the signaling. This
+ * helper busy waits for the correct timestamp to appear.
+ */
+static inline ktime_t dma_fence_timestamp(struct dma_fence *fence)
+{
+	if (WARN_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)))
+		return ktime_get();
+
+	while (!test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags))
+		cpu_relax();
+
+	return fence->timestamp;
+}
+
 signed long dma_fence_wait_timeout(struct dma_fence *,
 				   bool intr, signed long timeout);
 signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
author maintainer
#182 lore raw

PATCH 165/191 pinctrl: avoid unsafe code pattern in find_pinctrl()

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dmitry Torokhov <[email protected]>

commit c153a4edff6ab01370fcac8e46f9c89cca1060c2 upstream.

The code in find_pinctrl() takes a mutex and traverses a list of pinctrl structures. Later the caller bumps up reference count on the found structure. Such pattern is not safe as pinctrl that was found may get deleted before the caller gets around to increasing the reference count.

Fix this by taking the reference count in find_pinctrl(), while it still holds the mutex.

---
 drivers/pinctrl/core.c |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)
drivers/pinctrl/core.c +9 -7
@@ -1012,17 +1012,20 @@ static int add_setting(struct pinctrl *p
 
 static struct pinctrl *find_pinctrl(struct device *dev)
 {
-	struct pinctrl *p;
+	struct pinctrl *entry, *p = NULL;
 
 	mutex_lock(&pinctrl_list_mutex);
-	list_for_each_entry(p, &pinctrl_list, node)
-		if (p->dev == dev) {
-			mutex_unlock(&pinctrl_list_mutex);
-			return p;
+
+	list_for_each_entry(entry, &pinctrl_list, node) {
+		if (entry->dev == dev) {
+			p = entry;
+			kref_get(&p->users);
+			break;
 		}
+	}
 
 	mutex_unlock(&pinctrl_list_mutex);
-	return NULL;
+	return p;
 }
 
 static void pinctrl_free(struct pinctrl *p, bool inlist);
@@ -1130,7 +1133,6 @@ struct pinctrl *pinctrl_get(struct devic
 	p = find_pinctrl(dev);
 	if (p) {
 		dev_dbg(dev, "obtain a copy of previously claimed pinctrl\n");
-		kref_get(&p->users);
 		return p;
 	}
 
author maintainer
#183 lore raw

PATCH 166/191 scsi: ufs: core: Correct clear TM error log

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Wang <[email protected]>

commit a20c4350c6a12405b7f732b3ee6801ffe2cc45ce upstream.

The clear TM function error log status was inverted.

---
 drivers/ufs/core/ufshcd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ufs/core/ufshcd.c +1 -1
@@ -6955,7 +6955,7 @@ static int ufshcd_clear_tm_cmd(struct uf
 			mask, 0, 1000, 1000);
 
 	dev_err(hba->dev, "Clearing task management function with tag %d %s\n",
-		tag, err ? "succeeded" : "failed");
+		tag, err < 0 ? "failed" : "succeeded");
 
 out:
 	return err;
author maintainer
#184 lore raw

PATCH 167/191 riscv: Only consider swbp/ss handlers for correct privileged mode

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Björn Töpel <[email protected]>

commit 9f564b92cf6d0ecb398f9348600a7d8a7f8ea804 upstream.

RISC-V software breakpoint trap handlers are used for {k,u}probes.

When trapping from kernelmode, only the kernelmode handlers should be considered. Vice versa, only usermode handlers for usermode traps. This is not the case on RISC-V, which can trigger a bug if a userspace process uses uprobes, and a WARN() is triggered from kernelmode (which is implemented via {c.,}ebreak).

The kernel will trap on the kernelmode {c.,}ebreak, look for uprobes handlers, realize incorrectly that uprobes need to be handled, and exit the trap handler early. The trap returns to re-executing the {c.,}ebreak, and enter an infinite trap-loop.

The issue was found running the BPF selftest [1].

Fix this issue by only considering the swbp/ss handlers for kernel/usermode respectively. Also, move CONFIG ifdeffery from traps.c to the asm/{k,u}probes.h headers.

Note that linux/uprobes.h only include asm/uprobes.h if CONFIG_UPROBES is defined, which is why asm/uprobes.h needs to be unconditionally included in traps.c

---
 arch/riscv/include/asm/kprobes.h |    9 +++++++++
 arch/riscv/include/asm/uprobes.h |   11 +++++++++++
 arch/riscv/kernel/traps.c        |   28 ++++++++++++++++++----------
 3 files changed, 38 insertions(+), 10 deletions(-)
arch/riscv/include/asm/kprobes.h +9 -0
@@ -40,6 +40,15 @@ void arch_remove_kprobe(struct kprobe *p
 int kprobe_fault_handler(struct pt_regs *regs, unsigned int trapnr);
 bool kprobe_breakpoint_handler(struct pt_regs *regs);
 bool kprobe_single_step_handler(struct pt_regs *regs);
+#else
+static inline bool kprobe_breakpoint_handler(struct pt_regs *regs)
+{
+	return false;
+}
 
+static inline bool kprobe_single_step_handler(struct pt_regs *regs)
+{
+	return false;
+}
 #endif /* CONFIG_KPROBES */
 #endif /* _ASM_RISCV_KPROBES_H */
arch/riscv/include/asm/uprobes.h +11 -0
@@ -34,7 +34,18 @@ struct arch_uprobe {
 	bool simulate;
 };
 
+#ifdef CONFIG_UPROBES
 bool uprobe_breakpoint_handler(struct pt_regs *regs);
 bool uprobe_single_step_handler(struct pt_regs *regs);
+#else
+static inline bool uprobe_breakpoint_handler(struct pt_regs *regs)
+{
+	return false;
+}
 
+static inline bool uprobe_single_step_handler(struct pt_regs *regs)
+{
+	return false;
+}
+#endif /* CONFIG_UPROBES */
 #endif /* _ASM_RISCV_UPROBES_H */
arch/riscv/kernel/traps.c +18 -10
@@ -13,6 +13,8 @@
 #include <linux/kdebug.h>
 #include <linux/uaccess.h>
 #include <linux/kprobes.h>
+#include <linux/uprobes.h>
+#include <asm/uprobes.h>
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/irq.h>
@@ -246,22 +248,28 @@ static inline unsigned long get_break_in
 	return GET_INSN_LENGTH(insn);
 }
 
+static bool probe_single_step_handler(struct pt_regs *regs)
+{
+	bool user = user_mode(regs);
+
+	return user ? uprobe_single_step_handler(regs) : kprobe_single_step_handler(regs);
+}
+
+static bool probe_breakpoint_handler(struct pt_regs *regs)
+{
+	bool user = user_mode(regs);
+
+	return user ? uprobe_breakpoint_handler(regs) : kprobe_breakpoint_handler(regs);
+}
+
 void handle_break(struct pt_regs *regs)
 {
-#ifdef CONFIG_KPROBES
-	if (kprobe_single_step_handler(regs))
+	if (probe_single_step_handler(regs))
 		return;
 
-	if (kprobe_breakpoint_handler(regs))
-		return;
-#endif
-#ifdef CONFIG_UPROBES
-	if (uprobe_single_step_handler(regs))
+	if (probe_breakpoint_handler(regs))
 		return;
 
-	if (uprobe_breakpoint_handler(regs))
-		return;
-#endif
 	current->thread.bad_cause = regs->cause;
 
 	if (user_mode(regs))
author maintainer
#185 lore raw

PATCH 168/191 counter: chrdev: fix getting array extensions

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Fabrice Gasnier <[email protected]>

commit 3170256d7bc1ef81587caf4b83573eb1f5bb4fb6 upstream.

When trying to watch a component array extension, and the array isn't the first extended element, it fails as the type comparison is always done on the 1st element. Fix it by indexing the 'ext' array.

Example on a dummy struct counter_comp:

static struct counter_comp dummy[] = {
	COUNTER_COMP_DIRECTION(..),
	...,
	COUNTER_COMP_ARRAY_CAPTURE(...),
};

static struct counter_count dummy_cnt = {
...
.ext = dummy,
.num_ext = ARRAY_SIZE(dummy),
}

Currently, counter_get_ext() returns -EINVAL when trying to add a watch event on one of the capture array element in such example.

Fixes d2011be1e22f ("counter: Introduce the COUNTER_COMP_ARRAY component type")
---
 drivers/counter/counter-chrdev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/counter/counter-chrdev.c +2 -2
@@ -247,8 +247,8 @@ static int counter_get_ext(const struct
 		if (*id == component_id)
 			return 0;
 
-		if (ext->type == COUNTER_COMP_ARRAY) {
-			element = ext->priv;
+		if (ext[*ext_idx].type == COUNTER_COMP_ARRAY) {
+			element = ext[*ext_idx].priv;
 
 			if (component_id - *id < element->length)
 				return 0;
author maintainer
#186 lore raw

PATCH 169/191 counter: microchip-tcb-capture: Fix the use of internal GCLK logic

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dharma Balasubiramani <[email protected]>

commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream.

As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should be set to 0 while using the internal GCLK (TIMER_CLOCK1).

---
 drivers/counter/microchip-tcb-capture.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/counter/microchip-tcb-capture.c +1 -1
@@ -98,7 +98,7 @@ static int mchp_tc_count_function_write(
 		priv->qdec_mode = 0;
 		/* Set highest rate based on whether soc has gclk or not */
 		bmr &= ~(ATMEL_TC_QDEN | ATMEL_TC_POSEN);
-		if (priv->tc_cfg->has_gclk)
+		if (!priv->tc_cfg->has_gclk)
 			cmr |= ATMEL_TC_TIMER_CLOCK2;
 		else
 			cmr |= ATMEL_TC_TIMER_CLOCK1;
author maintainer
#187 lore raw

PATCH 170/191 coresight: Fix run time warnings while reusing ETR buffer

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Linu Cherian <[email protected]>

commit bd2767ec3df2775bc336f441f9068a989ccb919d upstream.

Fix the below warning by avoding calls to tmc_etr_enable_hw, if we are reusing the ETR buffer for multiple sources in sysfs mode.

echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink echo 1 > /sys/bus/coresight/devices/ete1/enable_source echo 1 > /sys/bus/coresight/devices/ete2/enable_source

[  166.918290] ------------[ cut here ]------------
[  166.922905] WARNING: CPU: 4 PID: 2288 at
drivers/hwtracing/coresight/coresight-tmc-etr.c:1037
tmc_etr_enable_hw+0xb0/0xc8
[  166.933862] Modules linked in:
[  166.936911] CPU: 4 PID: 2288 Comm: bash Not tainted 6.5.0-rc7 #132
[  166.943084] Hardware name: Marvell CN106XX board (DT)
[  166.948127] pstate: 834000c9 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS
BTYPE=--)
[  166.955083] pc : tmc_etr_enable_hw+0xb0/0xc8
[  166.959345] lr : tmc_enable_etr_sink+0x134/0x210
snip..
  167.038545] Call trace:
[  167.040982]  tmc_etr_enable_hw+0xb0/0xc8
[  167.044897]  tmc_enable_etr_sink+0x134/0x210
[  167.049160]  coresight_enable_path+0x160/0x278
[  167.053596]  coresight_enable+0xd4/0x298
[  167.057510]  enable_source_store+0x54/0xa0
[  167.061598]  dev_attr_store+0x20/0x40
[  167.065254]  sysfs_kf_write+0x4c/0x68
[  167.068909]  kernfs_fop_write_iter+0x128/0x200
[  167.073345]  vfs_write+0x1ac/0x2f8
[  167.076739]  ksys_write+0x74/0x110
[  167.080132]  __arm64_sys_write+0x24/0x38
[  167.084045]  invoke_syscall.constprop.0+0x58/0xf8
[  167.088744]  do_el0_svc+0x60/0x160
[  167.092137]  el0_svc+0x40/0x170
[  167.095273]  el0t_64_sync_handler+0x100/0x130
[  167.099621]  el0t_64_sync+0x190/0x198
[  167.103277] ---[ end trace 0000000000000000 ]---

-bash: echo: write error: Device or resource busy

Fixes 296b01fd106e ("coresight: Refactor out buffer allocation function for ETR")
---
 .../hwtracing/coresight/coresight-tmc-etr.c   | 24 ++++++++++---------
 1 file changed, 13 insertions(+), 11 deletions(-)
drivers/hwtracing/coresight/coresight-tmc-etr.c +13 -11
index 66dc5f97a009..6132c5b3db9c 100644
@@ -1173,16 +1173,6 @@ static struct etr_buf *tmc_etr_get_sysfs_buffer(struct coresight_device *csdev)
 		goto out;
 	}
 
-	/*
-	 * In sysFS mode we can have multiple writers per sink.  Since this
-	 * sink is already enabled no memory is needed and the HW need not be
-	 * touched, even if the buffer size has changed.
-	 */
-	if (drvdata->mode == CS_MODE_SYSFS) {
-		atomic_inc(&csdev->refcnt);
-		goto out;
-	}
-
 	/*
 	 * If we don't have a buffer or it doesn't match the requested size,
 	 * use the buffer allocated above. Otherwise reuse the existing buffer.
@@ -1204,7 +1194,7 @@ static struct etr_buf *tmc_etr_get_sysfs_buffer(struct coresight_device *csdev)
 
 static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
 {
-	int ret;
+	int ret = 0;
 	unsigned long flags;
 	struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	struct etr_buf *sysfs_buf = tmc_etr_get_sysfs_buffer(csdev);
@@ -1213,12 +1203,24 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
 		return PTR_ERR(sysfs_buf);
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
+
+	/*
+	 * In sysFS mode we can have multiple writers per sink.  Since this
+	 * sink is already enabled no memory is needed and the HW need not be
+	 * touched, even if the buffer size has changed.
+	 */
+	if (drvdata->mode == CS_MODE_SYSFS) {
+		atomic_inc(&csdev->refcnt);
+		goto out;
+	}
+
 	ret = tmc_etr_enable_hw(drvdata, sysfs_buf);
 	if (!ret) {
 		drvdata->mode = CS_MODE_SYSFS;
 		atomic_inc(&csdev->refcnt);
 	}
 
+out:
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
 	if (!ret)
Signature · 1 line
2.42.0
author maintainer
#188 lore raw

PATCH 171/191 riscv: Remove duplicate objcopy flag

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Song Shuai <[email protected]>

commit 505b02957e74f0c5c4655647ccb04bdc945d18f6 upstream.

There are two duplicate -O binary flags when objcopying from vmlinux to Image/xipImage.

RISC-V set -O binary flag in both OBJCOPYFLAGS in the top-level riscv Makefile and OBJCOPYFLAGS_* in the boot/Makefile, and the objcopy cmd in Kbuild would join them together.

The -O binary flag is only needed for objcopying Image, so remove the OBJCOPYFLAGS in the top-level riscv Makefile.

---
 arch/riscv/Makefile |    1 -
 1 file changed, 1 deletion(-)
arch/riscv/Makefile +0 -1
@@ -6,7 +6,6 @@
 # for more details.
 #
 
-OBJCOPYFLAGS    := -O binary
 LDFLAGS_vmlinux := -z norelro
 ifeq ($(CONFIG_RELOCATABLE),y)
 	LDFLAGS_vmlinux += -shared -Bsymbolic -z notext --emit-relocs
author maintainer
#189 lore raw

PATCH 172/191 RISC-V: Fix wrong use of CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jiexun Wang <[email protected]>

commit 07a27665754bf649b5de8e55c655e4d6837406be upstream.

If configuration options SOFTIRQ_ON_OWN_STACK and PREEMPT_RT are enabled simultaneously under RISC-V architecture, it will result in a compilation failure:

arch/riscv/kernel/irq.c:64:6: error: redefinition of 'do_softirq_own_stack'
64 | void do_softirq_own_stack(void)

      |      ^~~~~~~~~~~~~~~~~~~~

In file included from ./arch/riscv/include/generated/asm/softirq_stack.h:1,
from arch/riscv/kernel/irq.c:15:
./include/asm-generic/softirq_stack.h:8:20: note: previous definition of 'do_softirq_own_stack' was here
8 | static inline void do_softirq_own_stack(void)
| ^~~~~~~~~~~~~~~~~~~~

After changing CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK to CONFIG_SOFTIRQ_ON_OWN_STACK, compilation can be successful.

---
 arch/riscv/kernel/irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/riscv/kernel/irq.c +2 -2
index a8efa053c4a5..9cc0a7669271 100644
@@ -60,7 +60,7 @@ static void init_irq_stacks(void)
 }
 #endif /* CONFIG_VMAP_STACK */
 
-#ifdef CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK
+#ifdef CONFIG_SOFTIRQ_ON_OWN_STACK
 void do_softirq_own_stack(void)
 {
 #ifdef CONFIG_IRQ_STACKS
@@ -92,7 +92,7 @@ void do_softirq_own_stack(void)
 #endif
 		__do_softirq();
 }
-#endif /* CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK */
+#endif /* CONFIG_SOFTIRQ_ON_OWN_STACK */
 
 #else
 static void init_irq_stacks(void) {}
Signature · 1 line
2.42.0
author maintainer
#190 lore raw

PATCH 173/191 usb: typec: ucsi: Fix missing link removal

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heikki Krogerus <[email protected]>

commit dddb91cde52b4a57fa06a332b230fca3b11b885f upstream.

The link between the partner device and its USB Power Delivery instance was never removed which prevented the device from being released. Removing the link always when the partner is unregistered.

---
 drivers/usb/typec/ucsi/ucsi.c | 1 +
 1 file changed, 1 insertion(+)
drivers/usb/typec/ucsi/ucsi.c +1 -0
index 509c67c94a70..61b64558f96c 100644
@@ -787,6 +787,7 @@ static void ucsi_unregister_partner(struct ucsi_connector *con)
 
 	typec_set_mode(con->port, TYPEC_STATE_SAFE);
 
+	typec_partner_set_usb_power_delivery(con->partner, NULL);
 	ucsi_unregister_partner_pdos(con);
 	ucsi_unregister_altmodes(con, UCSI_RECIPIENT_SOP);
 	typec_unregister_partner(con->partner);
Signature · 1 line
2.42.0
author maintainer
#191 lore raw

PATCH 174/191 usb: typec: altmodes/displayport: Signal hpd low when exiting mode

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: RD Babiera <[email protected]>

commit 89434b069e460967624903b049e5cf5c9e6b99b9 upstream.

Upon receiving an ACK for a sent EXIT_MODE message, the DisplayPort driver currently resets the status and configuration of the port partner. The hpd signal is not updated despite being part of the status, so the Display stack can still transmit video despite typec_altmode_exit placing the lanes in a Safe State.

Set hpd to low when a sent EXIT_MODE message is ACK'ed.

Fixes 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
---
 drivers/usb/typec/altmodes/displayport.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/usb/typec/altmodes/displayport.c +5 -0
@@ -304,6 +304,11 @@ static int dp_altmode_vdm(struct typec_a
 			typec_altmode_update_active(alt, false);
 			dp->data.status = 0;
 			dp->data.conf = 0;
+			if (dp->hpd) {
+				drm_connector_oob_hotplug_event(dp->connector_fwnode);
+				dp->hpd = false;
+				sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
+			}
 			break;
 		case DP_CMD_STATUS_UPDATE:
 			dp->data.status = *vdo;
author maintainer
#192 lore raw

PATCH 175/191 usb: typec: ucsi: Clear EVENT_PENDING bit if ucsi_send_command fails

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Prashanth K <[email protected]>

commit a00e197daec52bcd955e118f5f57d706da5bfe50 upstream.

Currently if ucsi_send_command() fails, then we bail out without clearing EVENT_PENDING flag. So when the next connector change event comes, ucsi_connector_change() won't queue the con->work, because of which none of the new events will be processed.

Fix this by clearing EVENT_PENDING flag if ucsi_send_command() fails.

Fixes 512df95b9432 ("usb: typec: ucsi: Better fix for missing unplug events issue")
---
 drivers/usb/typec/ucsi/ucsi.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/typec/ucsi/ucsi.c +1 -0
@@ -885,6 +885,7 @@ static void ucsi_handle_connector_change
 	if (ret < 0) {
 		dev_err(ucsi->dev, "%s: GET_CONNECTOR_STATUS failed (%d)\n",
 			__func__, ret);
+		clear_bit(EVENT_PENDING, &con->ucsi->flags);
 		goto out_unlock;
 	}
 
author maintainer
#193 lore raw

PATCH 176/191 usb: gadget: udc-xilinx: replace memcpy with memcpy_toio

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Piyush Mehta <[email protected]>

commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream.

For ARM processor, unaligned access to device memory is not allowed. Method memcpy does not take care of alignment.

USB detection failure with the unalingned address of memory, with below kernel crash. To fix the unalingned address kernel panic, replace memcpy with memcpy_toio method.

Kernel crash:

Unable to handle kernel paging request at virtual address ffff80000c05008a

Mem abort info:
ESR = 0x96000061
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x21: alignment fault
Data abort info:
ISV = 0, ISS = 0x00000061
CM = 0, WnR = 1
swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000 [ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003, pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713

Internal error: Oops: 96000061 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __memcpy+0x30/0x260
lr : __xudc_ep0_queue+0xf0/0x110

sp : ffff800008003d00
x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0
x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080
x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080
x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000
x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000
x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200
x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0 x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112 x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80 x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088

Call trace:
 __memcpy+0x30/0x260
 xudc_ep0_queue+0x3c/0x60
 usb_ep_queue+0x38/0x44
 composite_ep0_queue.constprop.0+0x2c/0xc0
 composite_setup+0x8d0/0x185c
 configfs_composite_setup+0x74/0xb0
 xudc_irq+0x570/0xa40
 __handle_irq_event_percpu+0x58/0x170
 handle_irq_event+0x60/0x120
 handle_fasteoi_irq+0xc0/0x220
 handle_domain_irq+0x60/0x90
 gic_handle_irq+0x74/0xa0
 call_on_irq_stack+0x2c/0x60
 do_interrupt_handler+0x54/0x60
 el1_interrupt+0x30/0x50
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x78/0x7c
 arch_cpu_idle+0x18/0x2c
 do_idle+0xdc/0x15c
 cpu_startup_entry+0x28/0x60
 rest_init+0xc8/0xe0
 arch_call_rest_init+0x10/0x1c
 start_kernel+0x694/0x6d4
 __primary_switched+0xa4/0xac
---
 drivers/usb/gadget/udc/udc-xilinx.c |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)
drivers/usb/gadget/udc/udc-xilinx.c +12 -8
@@ -499,11 +499,13 @@ static int xudc_eptxrx(struct xusb_ep *e
 		/* Get the Buffer address and copy the transmit data.*/
 		eprambase = (u32 __force *)(udc->addr + ep->rambase);
 		if (ep->is_in) {
-			memcpy(eprambase, bufferptr, bytestosend);
+			memcpy_toio((void __iomem *)eprambase, bufferptr,
+				    bytestosend);
 			udc->write_fn(udc->addr, ep->offset +
 				      XUSB_EP_BUF0COUNT_OFFSET, bufferlen);
 		} else {
-			memcpy(bufferptr, eprambase, bytestosend);
+			memcpy_toio((void __iomem *)bufferptr, eprambase,
+				    bytestosend);
 		}
 		/*
 		 * Enable the buffer for transmission.
@@ -517,11 +519,13 @@ static int xudc_eptxrx(struct xusb_ep *e
 		eprambase = (u32 __force *)(udc->addr + ep->rambase +
 			     ep->ep_usb.maxpacket);
 		if (ep->is_in) {
-			memcpy(eprambase, bufferptr, bytestosend);
+			memcpy_toio((void __iomem *)eprambase, bufferptr,
+				    bytestosend);
 			udc->write_fn(udc->addr, ep->offset +
 				      XUSB_EP_BUF1COUNT_OFFSET, bufferlen);
 		} else {
-			memcpy(bufferptr, eprambase, bytestosend);
+			memcpy_toio((void __iomem *)bufferptr, eprambase,
+				    bytestosend);
 		}
 		/*
 		 * Enable the buffer for transmission.
@@ -1023,7 +1027,7 @@ static int __xudc_ep0_queue(struct xusb_
 			   udc->addr);
 		length = req->usb_req.actual = min_t(u32, length,
 						     EP0_MAX_PACKET);
-		memcpy(corebuf, req->usb_req.buf, length);
+		memcpy_toio((void __iomem *)corebuf, req->usb_req.buf, length);
 		udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, length);
 		udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1);
 	} else {
@@ -1752,7 +1756,7 @@ static void xudc_handle_setup(struct xus
 
 	/* Load up the chapter 9 command buffer.*/
 	ep0rambase = (u32 __force *) (udc->addr + XUSB_SETUP_PKT_ADDR_OFFSET);
-	memcpy(&setup, ep0rambase, 8);
+	memcpy_toio((void __iomem *)&setup, ep0rambase, 8);
 
 	udc->setup = setup;
 	udc->setup.wValue = cpu_to_le16(setup.wValue);
@@ -1839,7 +1843,7 @@ static void xudc_ep0_out(struct xusb_udc
 			     (ep0->rambase << 2));
 		buffer = req->usb_req.buf + req->usb_req.actual;
 		req->usb_req.actual = req->usb_req.actual + bytes_to_rx;
-		memcpy(buffer, ep0rambase, bytes_to_rx);
+		memcpy_toio((void __iomem *)buffer, ep0rambase, bytes_to_rx);
 
 		if (req->usb_req.length == req->usb_req.actual) {
 			/* Data transfer completed get ready for Status stage */
@@ -1915,7 +1919,7 @@ static void xudc_ep0_in(struct xusb_udc
 				     (ep0->rambase << 2));
 			buffer = req->usb_req.buf + req->usb_req.actual;
 			req->usb_req.actual = req->usb_req.actual + length;
-			memcpy(ep0rambase, buffer, length);
+			memcpy_toio((void __iomem *)ep0rambase, buffer, length);
 		}
 		udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, count);
 		udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1);
author maintainer
#194 lore raw

PATCH 177/191 usb: gadget: ncm: Handle decoding of multiple NTBs in unwrap call

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Krishna Kurapati <[email protected]>

commit 427694cfaafa565a3db5c5ea71df6bc095dca92f upstream.

When NCM is used with hosts like Windows PC, it is observed that there are multiple NTB's contained in one usb request giveback. Since the driver unwraps the obtained request data assuming only one NTB is present, we loose the subsequent NTB's present resulting in data loss.

Fix this by checking the parsed block length with the obtained data length in usb request and continue parsing after the last byte of current NTB.

---
 drivers/usb/gadget/function/f_ncm.c |   26 +++++++++++++++++++-------
 1 file changed, 19 insertions(+), 7 deletions(-)
drivers/usb/gadget/function/f_ncm.c +19 -7
@@ -1171,7 +1171,8 @@ static int ncm_unwrap_ntb(struct gether
 			  struct sk_buff_head *list)
 {
 	struct f_ncm	*ncm = func_to_ncm(&port->func);
-	__le16		*tmp = (void *) skb->data;
+	unsigned char	*ntb_ptr = skb->data;
+	__le16		*tmp;
 	unsigned	index, index2;
 	int		ndp_index;
 	unsigned	dg_len, dg_len2;
@@ -1184,6 +1185,10 @@ static int ncm_unwrap_ntb(struct gether
 	const struct ndp_parser_opts *opts = ncm->parser_opts;
 	unsigned	crc_len = ncm->is_crc ? sizeof(uint32_t) : 0;
 	int		dgram_counter;
+	int		to_process = skb->len;
+
+parse_ntb:
+	tmp = (__le16 *)ntb_ptr;
 
 	/* dwSignature */
 	if (get_unaligned_le32(tmp) != opts->nth_sign) {
@@ -1230,7 +1235,7 @@ static int ncm_unwrap_ntb(struct gether
 		 * walk through NDP
 		 * dwSignature
 		 */
-		tmp = (void *)(skb->data + ndp_index);
+		tmp = (__le16 *)(ntb_ptr + ndp_index);
 		if (get_unaligned_le32(tmp) != ncm->ndp_sign) {
 			INFO(port->func.config->cdev, "Wrong NDP SIGN\n");
 			goto err;
@@ -1287,11 +1292,11 @@ static int ncm_unwrap_ntb(struct gether
 			if (ncm->is_crc) {
 				uint32_t crc, crc2;
 
-				crc = get_unaligned_le32(skb->data +
+				crc = get_unaligned_le32(ntb_ptr +
 							 index + dg_len -
 							 crc_len);
 				crc2 = ~crc32_le(~0,
-						 skb->data + index,
+						 ntb_ptr + index,
 						 dg_len - crc_len);
 				if (crc != crc2) {
 					INFO(port->func.config->cdev,
@@ -1318,7 +1323,7 @@ static int ncm_unwrap_ntb(struct gether
 							 dg_len - crc_len);
 			if (skb2 == NULL)
 				goto err;
-			skb_put_data(skb2, skb->data + index,
+			skb_put_data(skb2, ntb_ptr + index,
 				     dg_len - crc_len);
 
 			skb_queue_tail(list, skb2);
@@ -1331,10 +1336,17 @@ static int ncm_unwrap_ntb(struct gether
 		} while (ndp_len > 2 * (opts->dgram_item_len * 2));
 	} while (ndp_index);
 
-	dev_consume_skb_any(skb);
-
 	VDBG(port->func.config->cdev,
 	     "Parsed NTB with %d frames\n", dgram_counter);
+
+	to_process -= block_len;
+	if (to_process != 0) {
+		ntb_ptr = (unsigned char *)(ntb_ptr + block_len);
+		goto parse_ntb;
+	}
+
+	dev_consume_skb_any(skb);
+
 	return 0;
 err:
 	skb_queue_purge(list);
author maintainer
#195 lore raw

PATCH 178/191 usb: cdnsp: Fixes issue with dequeuing not queued requests

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pawel Laszczak <[email protected]>

commit 34f08eb0ba6e4869bbfb682bf3d7d0494ffd2f87 upstream.

Gadget ACM while unloading module try to dequeue not queued usb request which causes the kernel to crash.
Patch adds extra condition to check whether usb request is processed by CDNSP driver.

Fixes 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
---
 drivers/usb/cdns3/cdnsp-gadget.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/usb/cdns3/cdnsp-gadget.c +3 -0
@@ -1125,6 +1125,9 @@ static int cdnsp_gadget_ep_dequeue(struc
 	unsigned long flags;
 	int ret;
 
+	if (request->status != -EINPROGRESS)
+		return 0;
+
 	if (!pep->endpoint.desc) {
 		dev_err(pdev->dev,
 			"%s: can't dequeue to disabled endpoint\n",
author maintainer
#196 lore raw

PATCH 179/191 usb: typec: qcom: Update the logic of regulator enable and disable

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hui Liu <[email protected]>

commit 76750f1dcad3e1af2295cdf2f9434e06e3178ef3 upstream.

Removed the call logic of disable and enable regulator in reset function. Enable the regulator in qcom_pmic_typec_start function and disable it in qcom_pmic_typec_stop function to avoid unbalanced regulator disable warnings.

---
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c +6 -6
@@ -383,10 +383,6 @@ static int qcom_pmic_typec_pdphy_enable(
 	struct device *dev = pmic_typec_pdphy->dev;
 	int ret;
 
-	ret = regulator_enable(pmic_typec_pdphy->vdd_pdphy);
-	if (ret)
-		return ret;
-
 	/* PD 2.0, DR=TYPEC_DEVICE, PR=TYPEC_SINK */
 	ret = regmap_update_bits(pmic_typec_pdphy->regmap,
 				 pmic_typec_pdphy->base + USB_PDPHY_MSG_CONFIG_REG,
@@ -424,8 +420,6 @@ static int qcom_pmic_typec_pdphy_disable
 	ret = regmap_write(pmic_typec_pdphy->regmap,
 			   pmic_typec_pdphy->base + USB_PDPHY_EN_CONTROL_REG, 0);
 
-	regulator_disable(pmic_typec_pdphy->vdd_pdphy);
-
 	return ret;
 }
 
@@ -449,6 +443,10 @@ int qcom_pmic_typec_pdphy_start(struct p
 	int i;
 	int ret;
 
+	ret = regulator_enable(pmic_typec_pdphy->vdd_pdphy);
+	if (ret)
+		return ret;
+
 	pmic_typec_pdphy->tcpm_port = tcpm_port;
 
 	ret = pmic_typec_pdphy_reset(pmic_typec_pdphy);
@@ -469,6 +467,8 @@ void qcom_pmic_typec_pdphy_stop(struct p
 		disable_irq(pmic_typec_pdphy->irq_data[i].irq);
 
 	qcom_pmic_typec_pdphy_reset_on(pmic_typec_pdphy);
+
+	regulator_disable(pmic_typec_pdphy->vdd_pdphy);
 }
 
 struct pmic_typec_pdphy *qcom_pmic_typec_pdphy_alloc(struct device *dev)
author maintainer
#197 lore raw

PATCH 180/191 usb: misc: onboard_hub: add support for Microchip USB2412 USB 2.0 hub

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Javier Carrasco <[email protected]>

commit e59e38158c61162f2e8beb4620df21a1585117df upstream.

The USB2412 is a 2-Port USB 2.0 hub controller that provides a reset pin and a single 3v3 powre source, which makes it suitable to be controlled by the onboard_hub driver.

This hub has the same reset timings as USB2514/2517 and the same onboard hub specific-data can be reused for USB2412.

---
 drivers/usb/misc/onboard_usb_hub.c |    1 +
 drivers/usb/misc/onboard_usb_hub.h |    1 +
 2 files changed, 2 insertions(+)
drivers/usb/misc/onboard_usb_hub.c +1 -0
@@ -409,6 +409,7 @@ static void onboard_hub_usbdev_disconnec
 static const struct usb_device_id onboard_hub_id_table[] = {
 	{ USB_DEVICE(VENDOR_ID_GENESYS, 0x0608) }, /* Genesys Logic GL850G USB 2.0 */
 	{ USB_DEVICE(VENDOR_ID_GENESYS, 0x0610) }, /* Genesys Logic GL852G USB 2.0 */
+	{ USB_DEVICE(VENDOR_ID_MICROCHIP, 0x2412) }, /* USB2412 USB 2.0 */
 	{ USB_DEVICE(VENDOR_ID_MICROCHIP, 0x2514) }, /* USB2514B USB 2.0 */
 	{ USB_DEVICE(VENDOR_ID_MICROCHIP, 0x2517) }, /* USB2517 USB 2.0 */
 	{ USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS5411 USB 3.1 */
drivers/usb/misc/onboard_usb_hub.h +1 -0
@@ -35,6 +35,7 @@ static const struct onboard_hub_pdata vi
 };
 
 static const struct of_device_id onboard_hub_match[] = {
+	{ .compatible = "usb424,2412", .data = &microchip_usb424_data, },
 	{ .compatible = "usb424,2514", .data = &microchip_usb424_data, },
 	{ .compatible = "usb424,2517", .data = &microchip_usb424_data, },
 	{ .compatible = "usb451,8140", .data = &ti_tusb8041_data, },
author maintainer
#198 lore raw

PATCH 181/191 Revert "x86/smp: Put CPUs into INIT on shutdown if possible"

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Linus Torvalds <[email protected]>

commit fbe1bf1e5ff1e3b298420d7a8434983ef8d72bd1 upstream.

This reverts commit 45e34c8af58f23db4474e2bfe79183efec09a18b, and the two subsequent fixes to it:

3f874c9b2aae ("x86/smp: Don't send INIT to non-present and non-booted CPUs") b1472a60a584 ("x86/smp: Don't send INIT to boot CPU")

because it seems to result in hung machines at shutdown. Particularly some Dell machines, but Thomas says

"The rest seems to be Lenovo and Sony with Alderlake/Raptorlake CPUs -
at least that's what I could figure out from the various bug reports.

I don't know which CPUs the DELL machines have, so I can't say it's a pattern.

I agree with the revert for now"

Ashok Raj chimes in:

"There was a report (probably this same one), and it turns out it was a
bug in the BIOS SMI handler.

The client BIOS's were waiting for the lowest APICID to be the SMI rendevous master. If this is MeteorLake, the BSP wasn't the one with the lowest APIC and it triped here.

The BIOS change is also being pushed to others for assimilation :)

Server BIOS's had this correctly for a while now"

and it does look likely to be some bad interaction between SMI and the non-BSP cores having put into INIT (and thus unresponsive until reset).

---
 arch/x86/include/asm/smp.h |    2 --
 arch/x86/kernel/smp.c      |   39 +++++++--------------------------------
 arch/x86/kernel/smpboot.c  |   27 ---------------------------
 3 files changed, 7 insertions(+), 61 deletions(-)
arch/x86/include/asm/smp.h +0 -2
@@ -134,8 +134,6 @@ void native_send_call_func_ipi(const str
 void native_send_call_func_single_ipi(int cpu);
 void x86_idle_thread_init(unsigned int cpu, struct task_struct *idle);
 
-bool smp_park_other_cpus_in_init(void);
-
 void smp_store_boot_cpu_info(void);
 void smp_store_cpu_info(int id);
 
arch/x86/kernel/smp.c +7 -32
@@ -131,7 +131,7 @@ static int smp_stop_nmi_callback(unsigne
 }
 
 /*
- * Disable virtualization, APIC etc. and park the CPU in a HLT loop
+ * this function calls the 'stop' function on all other CPUs in the system.
  */
 DEFINE_IDTENTRY_SYSVEC(sysvec_reboot)
 {
@@ -172,17 +172,13 @@ static void native_stop_other_cpus(int w
 	 * 2) Wait for all other CPUs to report that they reached the
 	 *    HLT loop in stop_this_cpu()
 	 *
-	 * 3) If the system uses INIT/STARTUP for CPU bringup, then
-	 *    send all present CPUs an INIT vector, which brings them
-	 *    completely out of the way.
+	 * 3) If #2 timed out send an NMI to the CPUs which did not
+	 *    yet report
 	 *
-	 * 4) If #3 is not possible and #2 timed out send an NMI to the
-	 *    CPUs which did not yet report
-	 *
-	 * 5) Wait for all other CPUs to report that they reached the
+	 * 4) Wait for all other CPUs to report that they reached the
 	 *    HLT loop in stop_this_cpu()
 	 *
-	 * #4 can obviously race against a CPU reaching the HLT loop late.
+	 * #3 can obviously race against a CPU reaching the HLT loop late.
 	 * That CPU will have reported already and the "have all CPUs
 	 * reached HLT" condition will be true despite the fact that the
 	 * other CPU is still handling the NMI. Again, there is no
@@ -198,7 +194,7 @@ static void native_stop_other_cpus(int w
 		/*
 		 * Don't wait longer than a second for IPI completion. The
 		 * wait request is not checked here because that would
-		 * prevent an NMI/INIT shutdown in case that not all
+		 * prevent an NMI shutdown attempt in case that not all
 		 * CPUs reach shutdown state.
 		 */
 		timeout = USEC_PER_SEC;
@@ -206,27 +202,7 @@ static void native_stop_other_cpus(int w
 			udelay(1);
 	}
 
-	/*
-	 * Park all other CPUs in INIT including "offline" CPUs, if
-	 * possible. That's a safe place where they can't resume execution
-	 * of HLT and then execute the HLT loop from overwritten text or
-	 * page tables.
-	 *
-	 * The only downside is a broadcast MCE, but up to the point where
-	 * the kexec() kernel brought all APs online again an MCE will just
-	 * make HLT resume and handle the MCE. The machine crashes and burns
-	 * due to overwritten text, page tables and data. So there is a
-	 * choice between fire and frying pan. The result is pretty much
-	 * the same. Chose frying pan until x86 provides a sane mechanism
-	 * to park a CPU.
-	 */
-	if (smp_park_other_cpus_in_init())
-		goto done;
-
-	/*
-	 * If park with INIT was not possible and the REBOOT_VECTOR didn't
-	 * take all secondary CPUs offline, try with the NMI.
-	 */
+	/* if the REBOOT_VECTOR didn't work, try with the NMI */
 	if (!cpumask_empty(&cpus_stop_mask)) {
 		/*
 		 * If NMI IPI is enabled, try to register the stop handler
@@ -249,7 +225,6 @@ static void native_stop_other_cpus(int w
 			udelay(1);
 	}
 
-done:
 	local_irq_save(flags);
 	disable_local_APIC();
 	mcheck_cpu_clear(this_cpu_ptr(&cpu_info));
arch/x86/kernel/smpboot.c +0 -27
@@ -1346,33 +1346,6 @@ void arch_thaw_secondary_cpus_end(void)
 	cache_aps_init();
 }
 
-bool smp_park_other_cpus_in_init(void)
-{
-	unsigned int cpu, this_cpu = smp_processor_id();
-	unsigned int apicid;
-
-	if (apic->wakeup_secondary_cpu_64 || apic->wakeup_secondary_cpu)
-		return false;
-
-	/*
-	 * If this is a crash stop which does not execute on the boot CPU,
-	 * then this cannot use the INIT mechanism because INIT to the boot
-	 * CPU will reset the machine.
-	 */
-	if (this_cpu)
-		return false;
-
-	for_each_cpu_and(cpu, &cpus_booted_once_mask, cpu_present_mask) {
-		if (cpu == this_cpu)
-			continue;
-		apicid = apic->cpu_present_to_apicid(cpu);
-		if (apicid == BAD_APICID)
-			continue;
-		send_init_sequence(apicid);
-	}
-	return true;
-}
-
 /*
  * Early setup to make printk work.
  */
author maintainer
#199 lore raw

PATCH 182/191 dmaengine: idxd: use spin_lock_irqsave before wait_event_lock_irq

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Rex Zhang <[email protected]>

[ Upstream commit c0409dd3d151f661e7e57b901a81a02565df163c ]

In idxd_cmd_exec(), wait_event_lock_irq() explicitly calls spin_unlock_irq()/spin_lock_irq(). If the interrupt is on before entering wait_event_lock_irq(), it will become off status after wait_event_lock_irq() is called. Later, wait_for_completion() may go to sleep but irq is disabled. The scenario is warned in might_sleep().

Fix it by using spin_lock_irqsave() instead of the primitive spin_lock() to save the irq status before entering wait_event_lock_irq() and using spin_unlock_irqrestore() instead of the primitive spin_unlock() to restore the irq status before entering wait_for_completion().

Before the change:
idxd_cmd_exec() {
interrupt is on
spin_lock() // interrupt is on
wait_event_lock_irq()
spin_unlock_irq() // interrupt is enabled
...
spin_lock_irq() // interrupt is disabled
spin_unlock() // interrupt is still disabled
wait_for_completion() // report "BUG: sleeping function

				   // called from invalid context...
				   // in_atomic() irqs_disabled()"
}

After applying spin_lock_irqsave():
idxd_cmd_exec() {
interrupt is on
spin_lock_irqsave() // save the on state

				   // interrupt is disabled
	wait_event_lock_irq()
		spin_unlock_irq()  // interrupt is enabled
		...
		spin_lock_irq()    // interrupt is disabled

spin_unlock_irqrestore() // interrupt is restored to on
wait_for_completion() // No Call trace
}

Fixes f9f4082dbc56 ("dmaengine: idxd: remove interrupt disable for cmd_lock")
---
 drivers/dma/idxd/device.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/dma/idxd/device.c +3 -2
index 9a15f0d12c799..97b505f1115ab 100644
@@ -492,6 +492,7 @@ static void idxd_cmd_exec(struct idxd_device *idxd, int cmd_code, u32 operand,
 	union idxd_command_reg cmd;
 	DECLARE_COMPLETION_ONSTACK(done);
 	u32 stat;
+	unsigned long flags;
 
 	if (idxd_device_is_halted(idxd)) {
 		dev_warn(&idxd->pdev->dev, "Device is HALTED!\n");
@@ -505,7 +506,7 @@ static void idxd_cmd_exec(struct idxd_device *idxd, int cmd_code, u32 operand,
 	cmd.operand = operand;
 	cmd.int_req = 1;
 
-	spin_lock(&idxd->cmd_lock);
+	spin_lock_irqsave(&idxd->cmd_lock, flags);
 	wait_event_lock_irq(idxd->cmd_waitq,
 			    !test_bit(IDXD_FLAG_CMD_RUNNING, &idxd->flags),
 			    idxd->cmd_lock);
@@ -522,7 +523,7 @@ static void idxd_cmd_exec(struct idxd_device *idxd, int cmd_code, u32 operand,
 	 * After command submitted, release lock and go to sleep until
 	 * the command completes via interrupt.
 	 */
-	spin_unlock(&idxd->cmd_lock);
+	spin_unlock_irqrestore(&idxd->cmd_lock, flags);
 	wait_for_completion(&done);
 	stat = ioread32(idxd->reg_base + IDXD_CMDSTS_OFFSET);
 	spin_lock(&idxd->cmd_lock);
Signature · 1 line
2.40.1
author maintainer
#200 lore raw

PATCH 183/191 dmaengine: mediatek: Fix deadlock caused by synchronize_irq()

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Duoming Zhou <[email protected]>

[ Upstream commit 01f1ae2733e2bb4de92fefcea5fda847d92aede1 ]

The synchronize_irq(c->irq) will not return until the IRQ handler mtk_uart_apdma_irq_handler() is completed. If the synchronize_irq() holds a spin_lock and waits the IRQ handler to complete, but the IRQ handler also needs the same spin_lock. The deadlock will happen. The process is shown below:

cpu0 cpu1

mtk_uart_apdma_device_pause() | mtk_uart_apdma_irq_handler()
  spin_lock_irqsave()         |
                              |   spin_lock_irqsave()
  //hold the lock to wait     |
  synchronize_irq()           |

This patch reorders the synchronize_irq(c->irq) outside the spin_lock in order to mitigate the bug.

Fixes 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support")
---
 drivers/dma/mediatek/mtk-uart-apdma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/dma/mediatek/mtk-uart-apdma.c +1 -2
index a1517ef1f4a01..0acf6a92a4ad3 100644
@@ -451,9 +451,8 @@ static int mtk_uart_apdma_device_pause(struct dma_chan *chan)
 	mtk_uart_apdma_write(c, VFF_EN, VFF_EN_CLR_B);
 	mtk_uart_apdma_write(c, VFF_INT_EN, VFF_INT_EN_CLR_B);
 
-	synchronize_irq(c->irq);
-
 	spin_unlock_irqrestore(&c->vc.lock, flags);
+	synchronize_irq(c->irq);
 
 	return 0;
 }
Signature · 1 line
2.40.1
author maintainer
#201 lore raw

PATCH 184/191 powerpc/8xx: Fix pte_access_permitted() for PAGE_NONE

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christophe Leroy <[email protected]>

[ Upstream commit 5d9cea8a552ee122e21fbd5a3c5d4eb85f648e06 ]

On 8xx, PAGE_NONE is handled by setting _PAGE_NA instead of clearing _PAGE_USER.

But then pte_user() returns 1 also for PAGE_NONE.

As _PAGE_NA prevent reads, add a specific version of pte_read() that returns 0 when _PAGE_NA is set instead of always returning 1.

---
 arch/powerpc/include/asm/nohash/32/pte-8xx.h | 7 +++++++
 arch/powerpc/include/asm/nohash/pgtable.h    | 2 ++
 2 files changed, 9 insertions(+)
arch/powerpc/include/asm/nohash/32/pte-8xx.h +7 -0
index 1a89ebdc3acc9..0238e6bd0d6c1 100644
@@ -94,6 +94,13 @@ static inline pte_t pte_wrprotect(pte_t pte)
 
 #define pte_wrprotect pte_wrprotect
 
+static inline int pte_read(pte_t pte)
+{
+	return (pte_val(pte) & _PAGE_RO) != _PAGE_NA;
+}
+
+#define pte_read pte_read
+
 static inline int pte_write(pte_t pte)
 {
 	return !(pte_val(pte) & _PAGE_RO);
arch/powerpc/include/asm/nohash/pgtable.h +2 -0
index a6caaaab6f922..3af11981fcd55 100644
@@ -25,7 +25,9 @@ static inline int pte_write(pte_t pte)
 	return pte_val(pte) & _PAGE_RW;
 }
 #endif
+#ifndef pte_read
 static inline int pte_read(pte_t pte)		{ return 1; }
+#endif
 static inline int pte_dirty(pte_t pte)		{ return pte_val(pte) & _PAGE_DIRTY; }
 static inline int pte_special(pte_t pte)	{ return pte_val(pte) & _PAGE_SPECIAL; }
 static inline int pte_none(pte_t pte)		{ return (pte_val(pte) & ~_PTE_NONE_MASK) == 0; }
Signature · 1 line
2.40.1
author maintainer
#202 lore raw

PATCH 185/191 powerpc/64e: Fix wrong test in __ptep_test_and_clear_young()

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christophe Leroy <[email protected]>

[ Upstream commit 5ea0bbaa32e8f54e9a57cfee4a3b8769b80be0d2 ]

Commit 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.") replaced:

if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0)

	return 0;

By:

if (pte_young(*ptep))

	return 0;

But it should be:

if (!pte_young(*ptep))

	return 0;

Fix it.

---
 arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/include/asm/nohash/64/pgtable.h +1 -1
index 287e25864ffae..072048e723c9b 100644
@@ -197,7 +197,7 @@ static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
 {
 	unsigned long old;
 
-	if (pte_young(*ptep))
+	if (!pte_young(*ptep))
 		return 0;
 	old = pte_update(mm, addr, ptep, _PAGE_ACCESSED, 0, 0);
 	return (old & _PAGE_ACCESSED) != 0;
Signature · 1 line
2.40.1
author maintainer
#203 lore raw

PATCH 186/191 fs: Fix kernel-doc warnings

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthew Wilcox (Oracle) <[email protected]>

[ Upstream commit 35931eb3945b8d38c31f8e956aee3cf31c52121b ]

These have a variety of causes and a corresponding variety of solutions.

Message-Id: <[email protected]>

Stable-dep-of: c34706acf40b ("ovl: fix regression in parsing of mount options with escaped comma")

---
 fs/file.c             |  3 ++-
 fs/fs_context.c       | 12 +++++++++---
 fs/ioctl.c            | 10 +++++++---
 fs/kernel_read_file.c | 12 ++++++------
 fs/namei.c            |  3 +++
 fs/open.c             |  4 ++--
 6 files changed, 29 insertions(+), 15 deletions(-)
fs/file.c +2 -1
index 3fd003a8604f8..568a98178007c 100644
@@ -668,7 +668,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */
 
 /**
  * last_fd - return last valid index into fd table
- * @cur_fds: files struct
+ * @fdt: File descriptor table.
  *
  * Context: Either rcu read lock or files_lock must be held.
  *
@@ -723,6 +723,7 @@ static inline void __range_close(struct files_struct *cur_fds, unsigned int fd,
  *
  * @fd:     starting file descriptor to close
  * @max_fd: last file descriptor to close
+ * @flags:  CLOSE_RANGE flags.
  *
  * This closes a range of file descriptors. All file descriptors
  * from @fd up to and including @max_fd are closed.
fs/fs_context.c +9 -3
index 375023e40161d..a48a69caddce1 100644
@@ -162,6 +162,10 @@ EXPORT_SYMBOL(vfs_parse_fs_param);
 
 /**
  * vfs_parse_fs_string - Convenience function to just parse a string.
+ * @fc: Filesystem context.
+ * @key: Parameter name.
+ * @value: Default value.
+ * @v_size: Maximum number of bytes in the value.
  */
 int vfs_parse_fs_string(struct fs_context *fc, const char *key,
 			const char *value, size_t v_size)
@@ -189,7 +193,7 @@ EXPORT_SYMBOL(vfs_parse_fs_string);
 
 /**
  * generic_parse_monolithic - Parse key[=val][,key[=val]]* mount data
- * @ctx: The superblock configuration to fill in.
+ * @fc: The superblock configuration to fill in.
  * @data: The data to parse
  *
  * Parse a blob of data that's in key[=val][,key[=val]]* form.  This can be
@@ -354,7 +358,7 @@ void fc_drop_locked(struct fs_context *fc)
 static void legacy_fs_context_free(struct fs_context *fc);
 
 /**
- * vfs_dup_fc_config: Duplicate a filesystem context.
+ * vfs_dup_fs_context - Duplicate a filesystem context.
  * @src_fc: The context to copy.
  */
 struct fs_context *vfs_dup_fs_context(struct fs_context *src_fc)
@@ -400,7 +404,9 @@ EXPORT_SYMBOL(vfs_dup_fs_context);
 
 /**
  * logfc - Log a message to a filesystem context
- * @fc: The filesystem context to log to.
+ * @log: The filesystem context to log to, or NULL to use printk.
+ * @prefix: A string to prefix the output with, or NULL.
+ * @level: 'w' for a warning, 'e' for an error.  Anything else is a notice.
  * @fmt: The format of the buffer.
  */
 void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, ...)
fs/ioctl.c +7 -3
index 5b2481cd47501..d413e0b8f6c29 100644
@@ -109,9 +109,6 @@ static int ioctl_fibmap(struct file *filp, int __user *p)
  * Returns 0 on success, -errno on error, 1 if this was the last
  * extent that will fit in user array.
  */
-#define SET_UNKNOWN_FLAGS	(FIEMAP_EXTENT_DELALLOC)
-#define SET_NO_UNMOUNTED_IO_FLAGS	(FIEMAP_EXTENT_DATA_ENCRYPTED)
-#define SET_NOT_ALIGNED_FLAGS	(FIEMAP_EXTENT_DATA_TAIL|FIEMAP_EXTENT_DATA_INLINE)
 int fiemap_fill_next_extent(struct fiemap_extent_info *fieinfo, u64 logical,
 			    u64 phys, u64 len, u32 flags)
 {
@@ -127,6 +124,10 @@ int fiemap_fill_next_extent(struct fiemap_extent_info *fieinfo, u64 logical,
 	if (fieinfo->fi_extents_mapped >= fieinfo->fi_extents_max)
 		return 1;
 
+#define SET_UNKNOWN_FLAGS	(FIEMAP_EXTENT_DELALLOC)
+#define SET_NO_UNMOUNTED_IO_FLAGS	(FIEMAP_EXTENT_DATA_ENCRYPTED)
+#define SET_NOT_ALIGNED_FLAGS	(FIEMAP_EXTENT_DATA_TAIL|FIEMAP_EXTENT_DATA_INLINE)
+
 	if (flags & SET_UNKNOWN_FLAGS)
 		flags |= FIEMAP_EXTENT_UNKNOWN;
 	if (flags & SET_NO_UNMOUNTED_IO_FLAGS)
@@ -877,6 +878,9 @@ SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
 #ifdef CONFIG_COMPAT
 /**
  * compat_ptr_ioctl - generic implementation of .compat_ioctl file operation
+ * @file: The file to operate on.
+ * @cmd: The ioctl command number.
+ * @arg: The argument to the ioctl.
  *
  * This is not normally called as a function, but instead set in struct
  * file_operations as
fs/kernel_read_file.c +6 -6
index 5d826274570ca..c429c42a68679 100644
@@ -8,16 +8,16 @@
 /**
  * kernel_read_file() - read file contents into a kernel buffer
  *
- * @file	file to read from
- * @offset	where to start reading from (see below).
- * @buf		pointer to a "void *" buffer for reading into (if
+ * @file:	file to read from
+ * @offset:	where to start reading from (see below).
+ * @buf:	pointer to a "void *" buffer for reading into (if
  *		*@buf is NULL, a buffer will be allocated, and
  *		@buf_size will be ignored)
- * @buf_size	size of buf, if already allocated. If @buf not
+ * @buf_size:	size of buf, if already allocated. If @buf not
  *		allocated, this is the largest size to allocate.
- * @file_size	if non-NULL, the full size of @file will be
+ * @file_size:	if non-NULL, the full size of @file will be
  *		written here.
- * @id		the kernel_read_file_id identifying the type of
+ * @id:		the kernel_read_file_id identifying the type of
  *		file contents being read (for LSMs to examine)
  *
  * @offset must be 0 unless both @buf and @file_size are non-NULL
fs/namei.c +3 -0
index 2bae29ea52ffa..567ee547492bc 100644
@@ -643,6 +643,8 @@ static bool nd_alloc_stack(struct nameidata *nd)
 
 /**
  * path_connected - Verify that a dentry is below mnt.mnt_root
+ * @mnt: The mountpoint to check.
+ * @dentry: The dentry to check.
  *
  * Rename can sometimes move a file or directory outside of a bind
  * mount, path_connected allows those cases to be detected.
@@ -1083,6 +1085,7 @@ fs_initcall(init_fs_namei_sysctls);
 /**
  * may_follow_link - Check symlink following for unsafe situations
  * @nd: nameidata pathwalk data
+ * @inode: Used for idmapping.
  *
  * In the case of the sysctl_protected_symlinks sysctl being enabled,
  * CAP_DAC_OVERRIDE needs to be specifically ignored if the symlink is
fs/open.c +2 -2
index e6ead0f199649..7c9647a8f219d 100644
@@ -1150,7 +1150,7 @@ EXPORT_SYMBOL_GPL(kernel_file_open);
  * backing_file_open - open a backing file for kernel internal use
  * @path:	path of the file to open
  * @flags:	open flags
- * @path:	path of the backing file
+ * @real_path:	path of the backing file
  * @cred:	credentials for open
  *
  * Open a backing file for a stackable filesystem (e.g., overlayfs).
@@ -1546,7 +1546,7 @@ SYSCALL_DEFINE1(close, unsigned int, fd)
 }
 
 /**
- * close_range() - Close all file descriptors in a given range.
+ * sys_close_range() - Close all file descriptors in a given range.
  *
  * @fd:     starting file descriptor to close
  * @max_fd: last file descriptor to close
Signature · 1 line
2.40.1
author maintainer
#204 lore raw

PATCH 187/191 fs: factor out vfs_parse_monolithic_sep() helper

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amir Goldstein <[email protected]>

[ Upstream commit e001d1447cd4585d7f23a44ff668ba2bc624badb ]

Factor out vfs_parse_monolithic_sep() from generic_parse_monolithic(), so filesystems could use it with a custom option separator callback.

Stable-dep-of: c34706acf40b ("ovl: fix regression in parsing of mount options with escaped comma")

---
 fs/fs_context.c            | 34 +++++++++++++++++++++++++++++-----
 include/linux/fs_context.h |  2 ++
 2 files changed, 31 insertions(+), 5 deletions(-)
fs/fs_context.c +29 -5
index a48a69caddce1..896e89acac5c2 100644
@@ -192,17 +192,19 @@ int vfs_parse_fs_string(struct fs_context *fc, const char *key,
 EXPORT_SYMBOL(vfs_parse_fs_string);
 
 /**
- * generic_parse_monolithic - Parse key[=val][,key[=val]]* mount data
+ * vfs_parse_monolithic_sep - Parse key[=val][,key[=val]]* mount data
  * @fc: The superblock configuration to fill in.
  * @data: The data to parse
+ * @sep: callback for separating next option
  *
- * Parse a blob of data that's in key[=val][,key[=val]]* form.  This can be
- * called from the ->monolithic_mount_data() fs_context operation.
+ * Parse a blob of data that's in key[=val][,key[=val]]* form with a custom
+ * option separator callback.
  *
  * Returns 0 on success or the error returned by the ->parse_option() fs_context
  * operation on failure.
  */
-int generic_parse_monolithic(struct fs_context *fc, void *data)
+int vfs_parse_monolithic_sep(struct fs_context *fc, void *data,
+			     char *(*sep)(char **))
 {
 	char *options = data, *key;
 	int ret = 0;
@@ -214,7 +216,7 @@ int generic_parse_monolithic(struct fs_context *fc, void *data)
 	if (ret)
 		return ret;
 
-	while ((key = strsep(&options, ",")) != NULL) {
+	while ((key = sep(&options)) != NULL) {
 		if (*key) {
 			size_t v_len = 0;
 			char *value = strchr(key, '=');
@@ -233,6 +235,28 @@ int generic_parse_monolithic(struct fs_context *fc, void *data)
 
 	return ret;
 }
+EXPORT_SYMBOL(vfs_parse_monolithic_sep);
+
+static char *vfs_parse_comma_sep(char **s)
+{
+	return strsep(s, ",");
+}
+
+/**
+ * generic_parse_monolithic - Parse key[=val][,key[=val]]* mount data
+ * @fc: The superblock configuration to fill in.
+ * @data: The data to parse
+ *
+ * Parse a blob of data that's in key[=val][,key[=val]]* form.  This can be
+ * called from the ->monolithic_mount_data() fs_context operation.
+ *
+ * Returns 0 on success or the error returned by the ->parse_option() fs_context
+ * operation on failure.
+ */
+int generic_parse_monolithic(struct fs_context *fc, void *data)
+{
+	return vfs_parse_monolithic_sep(fc, data, vfs_parse_comma_sep);
+}
 EXPORT_SYMBOL(generic_parse_monolithic);
 
 /**
include/linux/fs_context.h +2 -0
index ff6341e09925b..ae556dc8e18fe 100644
@@ -135,6 +135,8 @@ extern struct fs_context *vfs_dup_fs_context(struct fs_context *fc);
 extern int vfs_parse_fs_param(struct fs_context *fc, struct fs_parameter *param);
 extern int vfs_parse_fs_string(struct fs_context *fc, const char *key,
 			       const char *value, size_t v_size);
+int vfs_parse_monolithic_sep(struct fs_context *fc, void *data,
+			     char *(*sep)(char **));
 extern int generic_parse_monolithic(struct fs_context *fc, void *data);
 extern int vfs_get_tree(struct fs_context *fc);
 extern void put_fs_context(struct fs_context *fc);
Signature · 1 line
2.40.1
author maintainer
#205 lore raw

PATCH 188/191 ovl: fix regression in parsing of mount options with escaped comma

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amir Goldstein <[email protected]>

[ Upstream commit c34706acf40b43dd31f67c92c5a95d39666a1eb3 ]

Ever since commit 91c77947133f ("ovl: allow filenames with comma"), the following example was legit overlayfs mount options:

mount -t overlay overlay -o 'lowerdir=/tmp/a\,b/lower' /mnt

The conversion to new mount api moved to using the common helper generic_parse_monolithic() and discarded the specialized ovl_next_opt() option separator.

Bring back ovl_next_opt() and use vfs_parse_monolithic_sep() to fix the regression.

---
 fs/overlayfs/params.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
fs/overlayfs/params.c +29 -0
index c69d97aef2cf9..c0f70af422d6c 100644
@@ -120,6 +120,34 @@ const struct fs_parameter_spec ovl_parameter_spec[] = {
 	{}
 };
 
+static char *ovl_next_opt(char **s)
+{
+	char *sbegin = *s;
+	char *p;
+
+	if (sbegin == NULL)
+		return NULL;
+
+	for (p = sbegin; *p; p++) {
+		if (*p == '\\') {
+			p++;
+			if (!*p)
+				break;
+		} else if (*p == ',') {
+			*p = '\0';
+			*s = p + 1;
+			return sbegin;
+		}
+	}
+	*s = NULL;
+	return sbegin;
+}
+
+static int ovl_parse_monolithic(struct fs_context *fc, void *data)
+{
+	return vfs_parse_monolithic_sep(fc, data, ovl_next_opt);
+}
+
 static ssize_t ovl_parse_param_split_lowerdirs(char *str)
 {
 	ssize_t nr_layers = 1, nr_colons = 0;
@@ -596,6 +624,7 @@ static int ovl_reconfigure(struct fs_context *fc)
 }
 
 static const struct fs_context_operations ovl_context_ops = {
+	.parse_monolithic = ovl_parse_monolithic,
 	.parse_param = ovl_parse_param,
 	.get_tree    = ovl_get_tree,
 	.reconfigure = ovl_reconfigure,
Signature · 1 line
2.40.1
author maintainer
#206 lore raw

PATCH 189/191 ovl: make use of ->layers safe in rcu pathwalk

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amir Goldstein <[email protected]>

[ Upstream commit a535116d80339dbfe50b9b81b2f808c69eefbbc3 ]

ovl_permission() accesses ->layers[...].mnt; we can't have ->layers freed without an RCU delay on fs shutdown.

Fortunately, kern_unmount_array() that is used to drop those mounts does include an RCU delay, so freeing is delayed; unfortunately, the array passed to kern_unmount_array() is formed by mangling ->layers contents and that happens without any delays.

The ->layers[...].name string entries are used to store the strings to display in "lowerdir=..." by ovl_show_options(). Those entries are not accessed in RCU walk.

Move the name strings into a separate array ofs->config.lowerdirs and reuse the ofs->config.lowerdirs array as the temporary mount array to pass to kern_unmount_array().

Stable-dep-of: 32db51070850 ("ovl: fix regression in showing lowerdir mount option")

---
 fs/overlayfs/ovl_entry.h | 10 +---------
 fs/overlayfs/params.c    | 17 +++++++++--------
 fs/overlayfs/super.c     | 18 +++++++++++-------
 3 files changed, 21 insertions(+), 24 deletions(-)
fs/overlayfs/ovl_entry.h +1 -9
index 306e1ecdc96d3..2b703521871ea 100644
@@ -8,6 +8,7 @@
 struct ovl_config {
 	char *upperdir;
 	char *workdir;
+	char **lowerdirs;
 	bool default_permissions;
 	int redirect_mode;
 	bool index;
@@ -38,17 +39,8 @@ struct ovl_layer {
 	int idx;
 	/* One fsid per unique underlying sb (upper fsid == 0) */
 	int fsid;
-	char *name;
 };
 
-/*
- * ovl_free_fs() relies on @mnt being the first member when unmounting
- * the private mounts created for each layer. Let's check both the
- * offset and type.
- */
-static_assert(offsetof(struct ovl_layer, mnt) == 0);
-static_assert(__same_type(typeof_member(struct ovl_layer, mnt), struct vfsmount *));
-
 struct ovl_path {
 	const struct ovl_layer *layer;
 	struct dentry *dentry;
fs/overlayfs/params.c +9 -8
index c0f70af422d6c..e6edad7542e88 100644
@@ -695,12 +695,12 @@ void ovl_free_fs(struct ovl_fs *ofs)
 	if (ofs->upperdir_locked)
 		ovl_inuse_unlock(ovl_upper_mnt(ofs)->mnt_root);
 
-	/* Hack!  Reuse ofs->layers as a vfsmount array before freeing it */
-	mounts = (struct vfsmount **) ofs->layers;
+	/* Reuse ofs->config.lowerdirs as a vfsmount array before freeing it */
+	mounts = (struct vfsmount **) ofs->config.lowerdirs;
 	for (i = 0; i < ofs->numlayer; i++) {
 		iput(ofs->layers[i].trap);
+		kfree(ofs->config.lowerdirs[i]);
 		mounts[i] = ofs->layers[i].mnt;
-		kfree(ofs->layers[i].name);
 	}
 	kern_unmount_array(mounts, ofs->numlayer);
 	kfree(ofs->layers);
@@ -708,6 +708,7 @@ void ovl_free_fs(struct ovl_fs *ofs)
 		free_anon_bdev(ofs->fs[i].pseudo_dev);
 	kfree(ofs->fs);
 
+	kfree(ofs->config.lowerdirs);
 	kfree(ofs->config.upperdir);
 	kfree(ofs->config.workdir);
 	if (ofs->creator_cred)
@@ -857,16 +858,16 @@ int ovl_show_options(struct seq_file *m, struct dentry *dentry)
 	struct super_block *sb = dentry->d_sb;
 	struct ovl_fs *ofs = sb->s_fs_info;
 	size_t nr, nr_merged_lower = ofs->numlayer - ofs->numdatalayer;
-	const struct ovl_layer *data_layers = &ofs->layers[nr_merged_lower];
+	char **lowerdatadirs = &ofs->config.lowerdirs[nr_merged_lower];
 
-	/* ofs->layers[0] is the upper layer */
-	seq_printf(m, ",lowerdir=%s", ofs->layers[1].name);
+	/* lowerdirs[] starts from offset 1 */
+	seq_printf(m, ",lowerdir=%s", ofs->config.lowerdirs[1]);
 	/* dump regular lower layers */
 	for (nr = 2; nr < nr_merged_lower; nr++)
-		seq_printf(m, ":%s", ofs->layers[nr].name);
+		seq_printf(m, ":%s", ofs->config.lowerdirs[nr]);
 	/* dump data lower layers */
 	for (nr = 0; nr < ofs->numdatalayer; nr++)
-		seq_printf(m, "::%s", data_layers[nr].name);
+		seq_printf(m, "::%s", lowerdatadirs[nr]);
 	if (ofs->config.upperdir) {
 		seq_show_option(m, "upperdir", ofs->config.upperdir);
 		seq_show_option(m, "workdir", ofs->config.workdir);
fs/overlayfs/super.c +11 -7
index 1090c68e5b051..80a70eaa30d90 100644
@@ -565,11 +565,6 @@ static int ovl_get_upper(struct super_block *sb, struct ovl_fs *ofs,
 	upper_layer->idx = 0;
 	upper_layer->fsid = 0;
 
-	err = -ENOMEM;
-	upper_layer->name = kstrdup(ofs->config.upperdir, GFP_KERNEL);
-	if (!upper_layer->name)
-		goto out;
-
 	/*
 	 * Inherit SB_NOSEC flag from upperdir.
 	 *
@@ -1113,7 +1108,8 @@ static int ovl_get_layers(struct super_block *sb, struct ovl_fs *ofs,
 		layers[ofs->numlayer].idx = ofs->numlayer;
 		layers[ofs->numlayer].fsid = fsid;
 		layers[ofs->numlayer].fs = &ofs->fs[fsid];
-		layers[ofs->numlayer].name = l->name;
+		/* Store for printing lowerdir=... in ovl_show_options() */
+		ofs->config.lowerdirs[ofs->numlayer] = l->name;
 		l->name = NULL;
 		ofs->numlayer++;
 		ofs->fs[fsid].is_lower = true;
@@ -1358,8 +1354,16 @@ int ovl_fill_super(struct super_block *sb, struct fs_context *fc)
 	if (!layers)
 		goto out_err;
 
+	ofs->config.lowerdirs = kcalloc(ctx->nr + 1, sizeof(char *), GFP_KERNEL);
+	if (!ofs->config.lowerdirs) {
+		kfree(layers);
+		goto out_err;
+	}
 	ofs->layers = layers;
-	/* Layer 0 is reserved for upper even if there's no upper */
+	/*
+	 * Layer 0 is reserved for upper even if there's no upper.
+	 * For consistency, config.lowerdirs[0] is NULL.
+	 */
 	ofs->numlayer = 1;
 
 	sb->s_stack_depth = 0;
Signature · 1 line
2.40.1
author maintainer
#207 lore raw

PATCH 190/191 ovl: fix regression in showing lowerdir mount option

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Amir Goldstein <[email protected]>

[ Upstream commit 32db510708507f6133f496ff385cbd841d8f9098 ]

Before commit b36a5780cb44 ("ovl: modify layer parameter parsing"), spaces and commas in lowerdir mount option value used to be escaped using seq_show_option().

In current upstream, when lowerdir value has a space, it is not escaped in /proc/mounts, e.g.:

none /mnt overlay rw,relatime,lowerdir=l l,upperdir=u,workdir=w 0 0

which results in broken output of the mount utility:

none on /mnt type overlay (rw,relatime,lowerdir=l)

Store the original lowerdir mount options before unescaping and show them using the same escaping used for seq_show_option() in addition to escaping the colon separator character.

Fixes b36a5780cb44 ("ovl: modify layer parameter parsing")
---
 Documentation/filesystems/overlayfs.rst | 12 ++++++++
 fs/overlayfs/params.c                   | 38 +++++++++++++++----------
 2 files changed, 35 insertions(+), 15 deletions(-)
Documentation/filesystems/overlayfs.rst +12 -0
index eb7d2c88ddece..8e1b27288afd4 100644
@@ -339,6 +339,18 @@ The specified lower directories will be stacked beginning from the
 rightmost one and going left.  In the above example lower1 will be the
 top, lower2 the middle and lower3 the bottom layer.
 
+Note: directory names containing colons can be provided as lower layer by
+escaping the colons with a single backslash.  For example:
+
+  mount -t overlay overlay -olowerdir=/a\:lower\:\:dir /merged
+
+Since kernel version v6.5, directory names containing colons can also
+be provided as lower layer using the fsconfig syscall from new mount api:
+
+  fsconfig(fs_fd, FSCONFIG_SET_STRING, "lowerdir", "/a:lower::dir", 0);
+
+In the latter case, colons in lower layer directory names will be escaped
+as an octal characters (\072) when displayed in /proc/self/mountinfo.
 
 Metadata only copy up
 ---------------------
fs/overlayfs/params.c +23 -15
index e6edad7542e88..644badb13fe01 100644
@@ -155,7 +155,8 @@ static ssize_t ovl_parse_param_split_lowerdirs(char *str)
 
 	for (s = d = str;; s++, d++) {
 		if (*s == '\\') {
-			s++;
+			/* keep esc chars in split lowerdir */
+			*d++ = *s++;
 		} else if (*s == ':') {
 			bool next_colon = (*(s + 1) == ':');
 
@@ -230,7 +231,7 @@ static void ovl_unescape(char *s)
 	}
 }
 
-static int ovl_mount_dir(const char *name, struct path *path)
+static int ovl_mount_dir(const char *name, struct path *path, bool upper)
 {
 	int err = -ENOMEM;
 	char *tmp = kstrdup(name, GFP_KERNEL);
@@ -239,7 +240,7 @@ static int ovl_mount_dir(const char *name, struct path *path)
 		ovl_unescape(tmp);
 		err = ovl_mount_dir_noesc(tmp, path);
 
-		if (!err && path->dentry->d_flags & DCACHE_OP_REAL) {
+		if (!err && upper && path->dentry->d_flags & DCACHE_OP_REAL) {
 			pr_err("filesystem on '%s' not supported as upperdir\n",
 			       tmp);
 			path_put_init(path);
@@ -260,7 +261,7 @@ static int ovl_parse_param_upperdir(const char *name, struct fs_context *fc,
 	struct path path;
 	char *dup;
 
-	err = ovl_mount_dir(name, &path);
+	err = ovl_mount_dir(name, &path, true);
 	if (err)
 		return err;
 
@@ -417,7 +418,7 @@ static int ovl_parse_param_lowerdir(const char *name, struct fs_context *fc)
 		l = &ctx->lower[nr];
 		memset(l, 0, sizeof(*l));
 
-		err = ovl_mount_dir_noesc(dup_iter, &l->path);
+		err = ovl_mount_dir(dup_iter, &l->path, false);
 		if (err)
 			goto out_put;
 
@@ -858,16 +859,23 @@ int ovl_show_options(struct seq_file *m, struct dentry *dentry)
 	struct super_block *sb = dentry->d_sb;
 	struct ovl_fs *ofs = sb->s_fs_info;
 	size_t nr, nr_merged_lower = ofs->numlayer - ofs->numdatalayer;
-	char **lowerdatadirs = &ofs->config.lowerdirs[nr_merged_lower];
-
-	/* lowerdirs[] starts from offset 1 */
-	seq_printf(m, ",lowerdir=%s", ofs->config.lowerdirs[1]);
-	/* dump regular lower layers */
-	for (nr = 2; nr < nr_merged_lower; nr++)
-		seq_printf(m, ":%s", ofs->config.lowerdirs[nr]);
-	/* dump data lower layers */
-	for (nr = 0; nr < ofs->numdatalayer; nr++)
-		seq_printf(m, "::%s", lowerdatadirs[nr]);
+
+	/*
+	 * lowerdirs[] starts from offset 1, then
+	 * >= 0 regular lower layers prefixed with : and
+	 * >= 0 data-only lower layers prefixed with ::
+	 *
+	 * we need to escase comma and space like seq_show_option() does and
+	 * we also need to escape the colon separator from lowerdir paths.
+	 */
+	seq_puts(m, ",lowerdir=");
+	for (nr = 1; nr < ofs->numlayer; nr++) {
+		if (nr > 1)
+			seq_putc(m, ':');
+		if (nr >= nr_merged_lower)
+			seq_putc(m, ':');
+		seq_escape(m, ofs->config.lowerdirs[nr], ":, \t\n\\");
+	}
 	if (ofs->config.upperdir) {
 		seq_show_option(m, "upperdir", ofs->config.upperdir);
 		seq_show_option(m, "workdir", ofs->config.workdir);
Signature · 1 line
2.40.1
author maintainer
#208 lore raw

PATCH 191/191 ALSA: hda/realtek - Fixed two speaker platform

In reply to Greg Kroah-Hartman

6.5-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kailang Yang <[email protected]>

commit fb6254df09bba303db2a1002085f6c0b90a456ed upstream.

If system has two speakers and one connect to 0x14 pin, use this function will disable it.

Fixes e43252db7e20 ("ALSA: hda/realtek - ALC287 I2S speaker platform support")
---
 sound/pci/hda/patch_realtek.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
sound/pci/hda/patch_realtek.c +4 -2
@@ -7004,8 +7004,10 @@ static void alc287_fixup_bind_dacs(struc
 	snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn);
 	spec->gen.preferred_dacs = preferred_pairs;
 	spec->gen.auto_mute_via_amp = 1;
-	snd_hda_codec_write_cache(codec, 0x14, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
-			    0x0); /* Make sure 0x14 was disable */
+	if (spec->gen.autocfg.speaker_pins[0] != 0x14) {
+		snd_hda_codec_write_cache(codec, 0x14, 0, AC_VERB_SET_PIN_WIDGET_CONTROL,
+					0x0); /* Make sure 0x14 was disable */
+	}
 }
 
 
Tested-by on the v1 series
#209 lore raw
In reply to Greg Kroah-Hartman
Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.5.8 release. There are 191 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, 18 Oct 2023 08:39:48 +0000. Anything received after that time might be too late.

No regressions or build warnings on my system.

[    0.000000] Linux version 6.5.8-rc1+ (rbmarliere@debian) (Debian clang version 16.0.6 (15), GNU ld (GNU Binutils for Debian) 2.41) #2 SMP PREEMPT_DYNAMIC Mon Oct 16 14:24:07 -03 2023

Thanks!

maintainer Tested-by on the v1 series
#210 lore raw
In reply to Greg Kroah-Hartman

Hello,

Quoted 5 lines · On Mon, 16 Oct 2023 10:39:45 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 6.5.8 release. There are 191 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 8 lines

Responses should be made by Wed, 18 Oct 2023 08:39:48 +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.5.8-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y
and the diffstat can be found below.

This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].

[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 128a14e9d36d ("Linux 6.5.8-rc1")

Thanks,
SJ

[...]

---

ok 1 selftests: damon: debugfs_attrs.sh
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: debugfs_rm_non_contexts.sh
ok 8 selftests: damon: sysfs.sh
ok 9 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 10 selftests: damon: reclaim.sh
ok 11 selftests: damon: lru_sort.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_i386_idle_flag.sh
ok 13 selftests: damon-tests: build_i386_highpte.sh
ok 14 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
_remote_run_corr.sh SUCCESS

Tested-by on the v1 series
#211 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.5.8 release. There are 191 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, 18 Oct 2023 08:39:48 +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.5.8-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.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
Tested-by on the v1 series
#212 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.5.8 release. There are 191 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, 18 Oct 2023 08:39:48 +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.5.8-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Tested-by on the v1 series
#213 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.5.8 release. There are 191 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, 18 Oct 2023 08:39:48 +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.5.8-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.5.y
and the diffstat can be found below.

thanks,

greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).