5.10.82-rc1 review

PATCH In review Greg Kroah-Hartman 11 participants 174 messages Nov 24, 2021 – Nov 25, 2021 Page 2 of 2

Subsystems (8)

Networking Network drivers Stable branch MIPS +4 more subsystems

lore

Share & tools

lore

Greg Kroah-Hartman

author maintainer

2021-11-24 13:41 UTC #159 lore raw

PATCH 149/154 ASoC: DAPM: Cover regression by kctl change notification fix

In reply to Greg Kroah-Hartman

From: Takashi Iwai <[email protected]>

commit 827b0913a9d9d07a0c3e559dbb20ca4d6d285a54 upstream.

The recent fix for DAPM to correct the kctl change notification by the commit 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") caused other regressions since it changed the behavior of snd_soc_dapm_set_pin() that is called from several API functions. Formerly it returned always 0 for success, but now it returns 0 or 1.

This patch addresses it, restoring the old behavior of snd_soc_dapm_set_pin() while keeping the fix in snd_soc_dapm_put_pin_switch().

Fixes 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications")

Reported-by Yu-Hsuan Hsu <[email protected]>

Cc <[email protected]>

Signed-off-by Takashi Iwai <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/soc-dapm.c |   29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

sound/soc/soc-dapm.c +23 -6

@@ -2555,8 +2555,13 @@ static struct snd_soc_dapm_widget *dapm_
 	return NULL;
 }
 
-static int snd_soc_dapm_set_pin(struct snd_soc_dapm_context *dapm,
-				const char *pin, int status)
+/*
+ * set the DAPM pin status:
+ * returns 1 when the value has been updated, 0 when unchanged, or a negative
+ * error code; called from kcontrol put callback
+ */
+static int __snd_soc_dapm_set_pin(struct snd_soc_dapm_context *dapm,
+				  const char *pin, int status)
 {
 	struct snd_soc_dapm_widget *w = dapm_find_widget(dapm, pin, true);
 	int ret = 0;

@@ -2582,6 +2587,18 @@ static int snd_soc_dapm_set_pin(struct s
 	return ret;
 }
 
+/*
+ * similar as __snd_soc_dapm_set_pin(), but returns 0 when successful;
+ * called from several API functions below
+ */
+static int snd_soc_dapm_set_pin(struct snd_soc_dapm_context *dapm,
+				const char *pin, int status)
+{
+	int ret = __snd_soc_dapm_set_pin(dapm, pin, status);
+
+	return ret < 0 ? ret : 0;
+}
+
 /**
  * snd_soc_dapm_sync_unlocked - scan and power dapm paths
  * @dapm: DAPM context

@@ -3586,10 +3603,10 @@ int snd_soc_dapm_put_pin_switch(struct s
 	const char *pin = (const char *)kcontrol->private_value;
 	int ret;
 
-	if (ucontrol->value.integer.value[0])
-		ret = snd_soc_dapm_enable_pin(&card->dapm, pin);
-	else
-		ret = snd_soc_dapm_disable_pin(&card->dapm, pin);
+	mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
+	ret = __snd_soc_dapm_set_pin(&card->dapm, pin,
+				     !!ucontrol->value.integer.value[0]);
+	mutex_unlock(&card->dapm_mutex);
 
 	snd_soc_dapm_sync(&card->dapm);
 	return ret;

Greg Kroah-Hartman

author maintainer

2021-11-24 13:41 UTC #160 lore raw

PATCH 150/154 usb: max-3421: Use driver data instead of maintaining a list of bound devices

In reply to Greg Kroah-Hartman

From: Uwe Kleine-König <[email protected]>

commit fc153aba3ef371d0d76eb88230ed4e0dee5b38f2 upstream.

Instead of maintaining a single-linked list of devices that must be searched linearly in .remove() just use spi_set_drvdata() to remember the link between the spi device and the driver struct. Then the global list and the next member can be dropped.

This simplifies the driver, reduces the memory footprint and the time to search the list. Also it makes obvious that there is always a corresponding driver struct for a given device in .remove(), so the error path for !max3421_hcd can be dropped, too.

As a side effect this fixes a data inconsistency when .probe() races with itself for a second max3421 device in manipulating max3421_hcd_list. A similar race is fixed in .remove(), too.

Fixes 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.")

Signed-off-by Uwe Kleine-König <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/max3421-hcd.c |   25 +++++--------------------
 1 file changed, 5 insertions(+), 20 deletions(-)

drivers/usb/host/max3421-hcd.c +5 ~~-20~~

@@ -125,8 +125,6 @@ struct max3421_hcd {
 
 	struct task_struct *spi_thread;
 
-	struct max3421_hcd *next;
-
 	enum max3421_rh_state rh_state;
 	/* lower 16 bits contain port status, upper 16 bits the change mask: */
 	u32 port_status;

@@ -174,8 +172,6 @@ struct max3421_ep {
 	u8 retransmit;			/* packet needs retransmission */
 };
 
-static struct max3421_hcd *max3421_hcd_list;
-
 #define MAX3421_FIFO_SIZE	64
 
 #define MAX3421_SPI_DIR_RD	0	/* read register from MAX3421 */

@@ -1882,9 +1878,8 @@ max3421_probe(struct spi_device *spi)
 	}
 	set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
 	max3421_hcd = hcd_to_max3421(hcd);
-	max3421_hcd->next = max3421_hcd_list;
-	max3421_hcd_list = max3421_hcd;
 	INIT_LIST_HEAD(&max3421_hcd->ep_list);
+	spi_set_drvdata(spi, max3421_hcd);
 
 	max3421_hcd->tx = kmalloc(sizeof(*max3421_hcd->tx), GFP_KERNEL);
 	if (!max3421_hcd->tx)

@@ -1934,28 +1929,18 @@ error:
 static int
 max3421_remove(struct spi_device *spi)
 {
-	struct max3421_hcd *max3421_hcd = NULL, **prev;
-	struct usb_hcd *hcd = NULL;
+	struct max3421_hcd *max3421_hcd;
+	struct usb_hcd *hcd;
 	unsigned long flags;
 
-	for (prev = &max3421_hcd_list; *prev; prev = &(*prev)->next) {
-		max3421_hcd = *prev;
-		hcd = max3421_to_hcd(max3421_hcd);
-		if (hcd->self.controller == &spi->dev)
-			break;
-	}
-	if (!max3421_hcd) {
-		dev_err(&spi->dev, "no MAX3421 HCD found for SPI device %p\n",
-			spi);
-		return -ENODEV;
-	}
+	max3421_hcd = spi_get_drvdata(spi);
+	hcd = max3421_to_hcd(max3421_hcd);
 
 	usb_remove_hcd(hcd);
 
 	spin_lock_irqsave(&max3421_hcd->lock, flags);
 
 	kthread_stop(max3421_hcd->spi_thread);
-	*prev = max3421_hcd->next;
 
 	spin_unlock_irqrestore(&max3421_hcd->lock, flags);

Greg Kroah-Hartman

author maintainer

2021-11-24 13:41 UTC #161 lore raw

PATCH 151/154 ice: Delete always true check of PF pointer

In reply to Greg Kroah-Hartman

From: Leon Romanovsky <[email protected]>

commit 2ff04286a9569675948f39cec2c6ad47c3584633 upstream.

PF pointer is always valid when PCI core calls its .shutdown() and .remove() callbacks. There is no need to check it again.

Fixes 837f08fdecbe ("ice: Add basic driver framework for Intel(R) E800 Series")

Signed-off-by Leon Romanovsky <[email protected]>

Signed-off-by David S. Miller <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/ice/ice_main.c |    3 ---
 1 file changed, 3 deletions(-)

drivers/net/ethernet/intel/ice/ice_main.c +0 -3

@@ -4361,9 +4361,6 @@ static void ice_remove(struct pci_dev *p
 	struct ice_pf *pf = pci_get_drvdata(pdev);
 	int i;
 
-	if (!pf)
-		return;
-
 	for (i = 0; i < ICE_MAX_RESET_WAIT; i++) {
 		if (!ice_is_reset_in_progress(pf->state))
 			break;

Greg Kroah-Hartman

author maintainer

2021-11-24 13:42 UTC #162 lore raw

PATCH 152/154 fs: export an inode_update_time helper

In reply to Greg Kroah-Hartman

From: Josef Bacik <[email protected]>

commit e60feb445fce9e51c1558a6aa7faf9dd5ded533b upstream.

If you already have an inode and need to update the time on the inode there is no way to do this properly. Export this helper to allow file systems to update time on the inode so the appropriate handler is called, either ->update_time or generic_update_time.

Signed-off-by Josef Bacik <[email protected]>

Reviewed-by David Sterba <[email protected]>

Signed-off-by David Sterba <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/inode.c         |    7 ++++---
 include/linux/fs.h |    2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

fs/inode.c +4 -3

@@ -1772,12 +1772,13 @@ EXPORT_SYMBOL(generic_update_time);
  * This does the actual work of updating an inodes time or version.  Must have
  * had called mnt_want_write() before calling this.
  */
-static int update_time(struct inode *inode, struct timespec64 *time, int flags)
+int inode_update_time(struct inode *inode, struct timespec64 *time, int flags)
 {
 	if (inode->i_op->update_time)
 		return inode->i_op->update_time(inode, time, flags);
 	return generic_update_time(inode, time, flags);
 }
+EXPORT_SYMBOL(inode_update_time);
 
 /**
  *	touch_atime	-	update the access time

@@ -1847,7 +1848,7 @@ void touch_atime(const struct path *path
 	 * of the fs read only, e.g. subvolumes in Btrfs.
 	 */
 	now = current_time(inode);
-	update_time(inode, &now, S_ATIME);
+	inode_update_time(inode, &now, S_ATIME);
 	__mnt_drop_write(mnt);
 skip_update:
 	sb_end_write(inode->i_sb);

@@ -1991,7 +1992,7 @@ int file_update_time(struct file *file)
 	if (__mnt_want_write_file(file))
 		return 0;
 
-	ret = update_time(inode, &now, sync_it);
+	ret = inode_update_time(inode, &now, sync_it);
 	__mnt_drop_write_file(file);
 
 	return ret;

include/linux/fs.h +2 -0

@@ -2214,6 +2214,8 @@ enum file_time_flags {
 
 extern bool atime_needs_update(const struct path *, struct inode *);
 extern void touch_atime(const struct path *);
+int inode_update_time(struct inode *inode, struct timespec64 *time, int flags);
+
 static inline void file_accessed(struct file *file)
 {
 	if (!(file->f_flags & O_NOATIME))

Greg Kroah-Hartman

author maintainer

2021-11-24 13:42 UTC #163 lore raw

PATCH 153/154 btrfs: update device path inode time instead of bd_inode

In reply to Greg Kroah-Hartman

From: Josef Bacik <[email protected]>

commit 54fde91f52f515e0b1514f0f0fa146e87a672227 upstream.

Christoph pointed out that I'm updating bdev->bd_inode for the device time when we remove block devices from a btrfs file system, however this isn't actually exposed to anything. The inode we want to update is the one that's associated with the path to the device, usually on devtmpfs, so that blkid notices the difference.

We still don't want to do the blkdev_open, so use kern_path() to get the path to the given device and do the update time on that inode.

Fixes 8f96a5bfa150 ("btrfs: update the bdev time directly when closing")

Reported-by Christoph Hellwig <[email protected]>

Signed-off-by Josef Bacik <[email protected]>

Signed-off-by David Sterba <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/volumes.c |   21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

fs/btrfs/volumes.c +13 -8

@@ -14,6 +14,7 @@
 #include <linux/semaphore.h>
 #include <linux/uuid.h>
 #include <linux/list_sort.h>
+#include <linux/namei.h>
 #include "misc.h"
 #include "ctree.h"
 #include "extent_map.h"

@@ -1871,18 +1872,22 @@ out:
 /*
  * Function to update ctime/mtime for a given device path.
  * Mainly used for ctime/mtime based probe like libblkid.
+ *
+ * We don't care about errors here, this is just to be kind to userspace.
  */
-static void update_dev_time(struct block_device *bdev)
+static void update_dev_time(const char *device_path)
 {
-	struct inode *inode = bdev->bd_inode;
+	struct path path;
 	struct timespec64 now;
+	int ret;
 
-	/* Shouldn't happen but just in case. */
-	if (!inode)
+	ret = kern_path(device_path, LOOKUP_FOLLOW, &path);
+	if (ret)
 		return;
 
-	now = current_time(inode);
-	generic_update_time(inode, &now, S_MTIME | S_CTIME);
+	now = current_time(d_inode(path.dentry));
+	inode_update_time(d_inode(path.dentry), &now, S_MTIME | S_CTIME);
+	path_put(&path);
 }
 
 static int btrfs_rm_dev_item(struct btrfs_device *device)

@@ -2057,7 +2062,7 @@ void btrfs_scratch_superblocks(struct bt
 	btrfs_kobject_uevent(bdev, KOBJ_CHANGE);
 
 	/* Update ctime/mtime for device path for libblkid */
-	update_dev_time(bdev);
+	update_dev_time(device_path);
 }
 
 int btrfs_rm_device(struct btrfs_fs_info *fs_info, const char *device_path,

@@ -2700,7 +2705,7 @@ int btrfs_init_new_device(struct btrfs_f
 	btrfs_forget_devices(device_path);
 
 	/* Update ctime/mtime for blkid or udev */
-	update_dev_time(bdev);
+	update_dev_time(device_path);
 
 	return ret;

Pavel Machek

2021-11-24 13:56 UTC #164 lore raw

In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 5.10.82 release. There are 154 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.

CIP is running tests here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

And there's a build failure in CIP testing there:

CC drivers/mmc/core/sdio_ops.o
5040drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
5041drivers/cpuidle/cpuidle-tegra.c:349:38: error: 'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'? 5042 if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
5043 ^~~~~~~~~~~~~~~~~~~~~~~
5044 TEGRA_SUSPEND_NONE
5045drivers/cpuidle/cpuidle-tegra.c:349:38: note: each undeclared identifier is reported only once for each function it appears in
5046 CC drivers/gpu/drm/drm_dma.o
5047scripts/Makefile.build:280: recipe for target 'drivers/cpuidle/cpuidle-tegra.o' failed
5048scripts/Makefile.build:497: recipe for target 'drivers/cpuidle' failed
5049make[2]: *** [drivers/cpuidle/cpuidle-tegra.o] Error 1
5050make[1]: *** [drivers/cpuidle] Error 2
5051make[1]: *** Waiting for unfinished jobs....
5052 CC drivers/cpufreq/raspberrypi-cpufreq.o

Best regards,
Pavel

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Greg Kroah-Hartman

author maintainer

2021-11-24 16:11 UTC #165 lore raw

Quoted 13 lines · Pavel Machek

Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.82 release. There are 154 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.
CIP is running tests here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
And there's a build failure in CIP testing there:

Quoted 14 lines

CC drivers/mmc/core/sdio_ops.o
5040drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
5041drivers/cpuidle/cpuidle-tegra.c:349:38: error: 'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'? 5042 if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
5043 ^~~~~~~~~~~~~~~~~~~~~~~
5044 TEGRA_SUSPEND_NONE
5045drivers/cpuidle/cpuidle-tegra.c:349:38: note: each undeclared identifier is reported only once for each function it appears in
5046 CC drivers/gpu/drm/drm_dma.o
5047scripts/Makefile.build:280: recipe for target 'drivers/cpuidle/cpuidle-tegra.o' failed
5048scripts/Makefile.build:497: recipe for target 'drivers/cpuidle' failed
5049make[2]: *** [drivers/cpuidle/cpuidle-tegra.o] Error 1
5050make[1]: *** [drivers/cpuidle] Error 2
5051make[1]: *** Waiting for unfinished jobs....
5052 CC drivers/cpufreq/raspberrypi-cpufreq.o

Will go drop that patch, thanks.

greg k-h

Sudip Mukherjee

2021-11-25 11:43 UTC #166 lore raw

In reply to Pavel Machek

Hi Greg,

Quoted 10 lines · Pavel Machek

Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.82 release. There are 154 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.
CIP is running tests here:

Quoted 8 lines

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
And there's a build failure in CIP testing there:
CC drivers/mmc/core/sdio_ops.o
5040drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
5041drivers/cpuidle/cpuidle-tegra.c:349:38: error: 'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'? 5042 if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)

I also having the same build failures for arm.

drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
drivers/cpuidle/cpuidle-tegra.c:349:45: error:
'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'?
349 | if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)

And it should be for 4d895b601038 (\"cpuidle: tegra: Check whether PMC is ready\").

Signature · 2 lines

Regards
Sudip

Greg Kroah-Hartman

author maintainer

2021-11-25 11:45 UTC #167 lore raw

Quoted 24 lines · Sudip Mukherjee

Hi Greg,
Quoted 10 lines · Pavel Machek
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.82 release. There are 154 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.
CIP is running tests here:
Quoted 8 lines
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
And there's a build failure in CIP testing there:
CC drivers/mmc/core/sdio_ops.o
5040drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
5041drivers/cpuidle/cpuidle-tegra.c:349:38: error: 'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'? 5042 if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
I also having the same build failures for arm.

Quoted 8 lines

drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
drivers/cpuidle/cpuidle-tegra.c:349:45: error:
'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'?
349 | if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
And it should be for 4d895b601038 (\"cpuidle: tegra: Check whether PMC is ready\").

Should be fixed -rc2.

thanks,

greg k-h

Greg Kroah-Hartman

author maintainer

2021-11-24 13:41 UTC #168 lore raw

PATCH 154/154 x86/Kconfig: Fix an unused variable error in dell-smm-hwmon

In reply to Greg Kroah-Hartman

From: Randy Dunlap <[email protected]>

commit ef775a0e36c6a81c5b07cb228c02f967133fe768 upstream.

When CONFIG_PROC_FS is not set, there is a build warning (turned into an error):

../drivers/hwmon/dell-smm-hwmon.c: In function 'i8k_init_procfs':
../drivers/hwmon/dell-smm-hwmon.c:624:24: error: unused variable 'data' [-Werror=unused-variable]

    struct dell_smm_data *data = dev_get_drvdata(dev);

Make I8K depend on PROC_FS and HWMON (instead of selecting HWMON -- it is strongly preferred to not select entire subsystems).

Build tested in all possible combinations of SENSORS_DELL_SMM, I8K, and PROC_FS.

Fixes 039ae58503f3 ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k")

Reported-by Arnd Bergmann <[email protected]>

Signed-off-by Randy Dunlap <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

Reviewed-by Arnd Bergmann <[email protected]>

Acked-by Guenter Roeck <[email protected]>

Acked-by Pali Rohár <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/Kconfig |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/x86/Kconfig +2 -1

@@ -1266,7 +1266,8 @@ config TOSHIBA
 
 config I8K
 	tristate "Dell i8k legacy laptop support"
-	select HWMON
+	depends on HWMON
+	depends on PROC_FS
 	select SENSORS_DELL_SMM
 	help
 	  This option enables legacy /proc/i8k userspace interface in hwmon

Naresh Kamboju

2021-11-24 15:16 UTC #169 lore raw

In reply to Greg Kroah-Hartman

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.82 release. There are 154 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 Fri, 26 Nov 2021 11:56:36 +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/v5.x/stable-review/patch-5.10.82-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

Regression found on arm gcc-11 builds
As I have already reported,
https://lore.kernel.org/stable/CA+G9fYskrxZvmrjhO32Q9r7mb1AtKdLBm4OvDNvt5v4PTgm4pA@mail.gmail.com/

drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
drivers/cpuidle/cpuidle-tegra.c:349:38: error:
'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'?

  349 |  if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~
      |                                      TEGRA_SUSPEND_NONE

Reported-by Linux Kernel Functional Testing <[email protected]>

Due to the following patch,

cpuidle: tegra: Check whether PMC is ready
[ Upstream commit bdb1ffdad3b73e4d0538098fc02e2ea87a6b27cd ]

--
Linaro LKFT
https://lkft.linaro.org

Dmitry Osipenko

2021-11-24 15:27 UTC #170 lore raw

24.11.2021 18:16, Naresh Kamboju пишет:

Quoted 33 lines

Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.82 release. There are 154 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 Fri, 26 Nov 2021 11:56:36 +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/v5.x/stable-review/patch-5.10.82-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
Regression found on arm gcc-11 builds
As I have already reported,
https://lore.kernel.org/stable/CA+G9fYskrxZvmrjhO32Q9r7mb1AtKdLBm4OvDNvt5v4PTgm4pA@mail.gmail.com/
drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
drivers/cpuidle/cpuidle-tegra.c:349:38: error:
'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'?
  349 |  if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~
      |                                      TEGRA_SUSPEND_NONE

Quoted 6 lines

Reported-by Linux Kernel Functional Testing <[email protected]>
Due to the following patch,
cpuidle: tegra: Check whether PMC is ready
[ Upstream commit bdb1ffdad3b73e4d0538098fc02e2ea87a6b27cd ]

Hi Greg and all,

Greg, could you please drop this patch from the stable trees? It shouldn't be backported since the actual offending patch which causes the "fixed" problem is still pending to be merged. I assumed that all patches would be merged much earlier when was typing the commit message, but only a part of patches were merged yet. Sorry for noticing this so late.

Greg Kroah-Hartman

author maintainer

2021-11-24 16:11 UTC #171 lore raw

Quoted 41 lines · Dmitry Osipenko

24.11.2021 18:16, Naresh Kamboju пишет:
Quoted 33 lines
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.82 release. There are 154 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 Fri, 26 Nov 2021 11:56:36 +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/v5.x/stable-review/patch-5.10.82-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
Regression found on arm gcc-11 builds
As I have already reported,
https://lore.kernel.org/stable/CA+G9fYskrxZvmrjhO32Q9r7mb1AtKdLBm4OvDNvt5v4PTgm4pA@mail.gmail.com/
drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
drivers/cpuidle/cpuidle-tegra.c:349:38: error:
'TEGRA_SUSPEND_NOT_READY' undeclared (first use in this function); did you mean 'TEGRA_SUSPEND_NONE'?
  349 |  if (tegra_pmc_get_suspend_mode() == TEGRA_SUSPEND_NOT_READY)
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~
      |                                      TEGRA_SUSPEND_NONE
Quoted 6 lines
Reported-by Linux Kernel Functional Testing <[email protected]>
Due to the following patch,
cpuidle: tegra: Check whether PMC is ready
[ Upstream commit bdb1ffdad3b73e4d0538098fc02e2ea87a6b27cd ]

Quoted 7 lines

Hi Greg and all,
Greg, could you please drop this patch from the stable trees? It shouldn't be backported since the actual offending patch which causes the "fixed" problem is still pending to be merged. I assumed that all patches would be merged much earlier when was typing the commit message, but only a part of patches were merged yet. Sorry for noticing this so late.

Now dropped from both 5.15 and 5.10 queues, thanks.

greg k-h

Fox Chen

Tested-by on the v1 series

2021-11-24 17:23 UTC #172 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 5.10.82 release. There are 154 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 Fri, 26 Nov 2021 11:56:36 +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/v5.x/stable-review/patch-5.10.82-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-5.10.y
and the diffstat can be found below.
thanks,
greg k-h

5.10.82-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

Tested-by Fox Chen <[email protected]>

Guenter Roeck

2021-11-25 02:06 UTC #173 lore raw

In reply to Greg Kroah-Hartman

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.82 release. There are 154 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 Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.

Build results:

	total: 159 pass: 158 fail: 1
Failed builds:
	arm:allmodconfig
Qemu test results:
	total: 477 pass: 446 fail: 31

Failed tests:
<lots of arm tests>

drivers/cpuidle/cpuidle-tegra.c: In function 'tegra_cpuidle_probe':
drivers/cpuidle/cpuidle-tegra.c:349:45: error: 'TEGRA_SUSPEND_NOT_READY' undeclared

Guenter