* [PATCH 5.14 001/151] ALSA: usb-audio: Add quirk for VF0770
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 002/151] ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl Greg Kroah-Hartman
` (155 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jonas Hahnfeld, Takashi Iwai
From: Jonas Hahnfeld <hahnjo@hahnjo.de>
commit 48827e1d6af58f219e89c7ec08dccbca28c7694e upstream.
The device advertises 8 formats, but only a rate of 48kHz is honored
by the hardware and 24 bits give chopped audio, so only report the
one working combination. This fixes out-of-the-box audio experience
with PipeWire which otherwise attempts to choose S24_3LE (while
PulseAudio defaulted to S16_LE).
Signed-off-by: Jonas Hahnfeld <hahnjo@hahnjo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/quirks-table.h | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -78,6 +78,48 @@
{ USB_DEVICE_VENDOR_SPEC(0x041e, 0x3f19) },
/*
+ * Creative Technology, Ltd Live! Cam Sync HD [VF0770]
+ * The device advertises 8 formats, but only a rate of 48kHz is honored by the
+ * hardware and 24 bits give chopped audio, so only report the one working
+ * combination.
+ */
+{
+ USB_DEVICE(0x041e, 0x4095),
+ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_COMPOSITE,
+ .data = &(const struct snd_usb_audio_quirk[]) {
+ {
+ .ifnum = 2,
+ .type = QUIRK_AUDIO_STANDARD_MIXER,
+ },
+ {
+ .ifnum = 3,
+ .type = QUIRK_AUDIO_FIXED_ENDPOINT,
+ .data = &(const struct audioformat) {
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .channels = 2,
+ .fmt_bits = 16,
+ .iface = 3,
+ .altsetting = 4,
+ .altset_idx = 4,
+ .endpoint = 0x82,
+ .ep_attr = 0x05,
+ .rates = SNDRV_PCM_RATE_48000,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ .nr_rates = 1,
+ .rate_table = (unsigned int[]) { 48000 },
+ },
+ },
+ {
+ .ifnum = -1
+ },
+ },
+ },
+},
+
+/*
* HP Wireless Audio
* When not ignored, causes instability issues for some users, forcing them to
* skip the entire module.
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 002/151] ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 001/151] ALSA: usb-audio: Add quirk for VF0770 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 003/151] ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer Greg Kroah-Hartman
` (154 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Forney, Arnd Bergmann,
Rich Felker, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 228af5a4fa3a8293bd8b7ac5cf59548ee29627bf upstream.
Michael Forney reported an incorrect padding type that was defined in
the commit 80fe7430c708 ("ALSA: add new 32-bit layout for
snd_pcm_mmap_status/control") for PCM control mmap data.
His analysis is correct, and this caused the misplacements of PCM
control data on 32bit arch and 32bit compat mode.
The bug is that the __pad2 definition in __snd_pcm_mmap_control64
struct was wrongly with __pad_before_uframe, which should have been
__pad_after_uframe instead. This struct is used in SYNC_PTR ioctl and
control mmap. Basically this bug leads to two problems:
- The offset of avail_min field becomes wrong, it's placed right after
appl_ptr without padding on little-endian
- When appl_ptr and avail_min are read as 64bit values in kernel side,
the values become either zero or corrupted (mixed up)
One good news is that, because both user-space and kernel
misunderstand the wrong offset, at least, 32bit application running on
32bit kernel works as is. Also, 64bit applications are unaffected
because the padding size is zero. The remaining problem is the 32bit
compat mode; as mentioned in the above, avail_min is placed right
after appl_ptr on little-endian archs, 64bit kernel reads bogus values
for appl_ptr updates, which may lead to streaming bugs like jumping,
XRUN or whatever unexpected.
(However, we haven't heard any serious bug reports due to this over
years, so practically seen, it's fairly safe to assume that the impact
by this bug is limited.)
Ideally speaking, we should correct the wrong mmap status control
definition. But this would cause again incompatibility with the
existing binaries, and fixing it (e.g. by renumbering ioctls) would be
really messy.
So, as of this patch, we only correct the behavior of 32bit compat
mode and keep the rest as is. Namely, the SYNC_PTR ioctl is now
handled differently in compat mode to read/write the 32bit values at
the right offsets. The control mmap of 32bit apps on 64bit kernels
has been already disabled (which is likely rather an overlook, but
this worked fine at this time :), so covering SYNC_PTR ioctl should
suffice as a fallback.
Fixes: 80fe7430c708 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
Reported-by: Michael Forney <mforney@mforney.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org>
Cc: Rich Felker <dalias@libc.org>
Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/pcm_compat.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 71 insertions(+), 1 deletion(-)
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -468,6 +468,76 @@ static int snd_pcm_ioctl_sync_ptr_x32(st
}
#endif /* CONFIG_X86_X32 */
+#ifdef __BIG_ENDIAN
+typedef char __pad_before_u32[4];
+typedef char __pad_after_u32[0];
+#else
+typedef char __pad_before_u32[0];
+typedef char __pad_after_u32[4];
+#endif
+
+/* PCM 2.0.15 API definition had a bug in mmap control; it puts the avail_min
+ * at the wrong offset due to a typo in padding type.
+ * The bug hits only 32bit.
+ * A workaround for incorrect read/write is needed only in 32bit compat mode.
+ */
+struct __snd_pcm_mmap_control64_buggy {
+ __pad_before_u32 __pad1;
+ __u32 appl_ptr;
+ __pad_before_u32 __pad2; /* SiC! here is the bug */
+ __pad_before_u32 __pad3;
+ __u32 avail_min;
+ __pad_after_uframe __pad4;
+};
+
+static int snd_pcm_ioctl_sync_ptr_buggy(struct snd_pcm_substream *substream,
+ struct snd_pcm_sync_ptr __user *_sync_ptr)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_pcm_sync_ptr sync_ptr;
+ struct __snd_pcm_mmap_control64_buggy *sync_cp;
+ volatile struct snd_pcm_mmap_status *status;
+ volatile struct snd_pcm_mmap_control *control;
+ int err;
+
+ memset(&sync_ptr, 0, sizeof(sync_ptr));
+ sync_cp = (struct __snd_pcm_mmap_control64_buggy *)&sync_ptr.c.control;
+ if (get_user(sync_ptr.flags, (unsigned __user *)&(_sync_ptr->flags)))
+ return -EFAULT;
+ if (copy_from_user(sync_cp, &(_sync_ptr->c.control), sizeof(*sync_cp)))
+ return -EFAULT;
+ status = runtime->status;
+ control = runtime->control;
+ if (sync_ptr.flags & SNDRV_PCM_SYNC_PTR_HWSYNC) {
+ err = snd_pcm_hwsync(substream);
+ if (err < 0)
+ return err;
+ }
+ snd_pcm_stream_lock_irq(substream);
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
+ err = pcm_lib_apply_appl_ptr(substream, sync_cp->appl_ptr);
+ if (err < 0) {
+ snd_pcm_stream_unlock_irq(substream);
+ return err;
+ }
+ } else {
+ sync_cp->appl_ptr = control->appl_ptr;
+ }
+ if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
+ control->avail_min = sync_cp->avail_min;
+ else
+ sync_cp->avail_min = control->avail_min;
+ sync_ptr.s.status.state = status->state;
+ sync_ptr.s.status.hw_ptr = status->hw_ptr;
+ sync_ptr.s.status.tstamp = status->tstamp;
+ sync_ptr.s.status.suspended_state = status->suspended_state;
+ sync_ptr.s.status.audio_tstamp = status->audio_tstamp;
+ snd_pcm_stream_unlock_irq(substream);
+ if (copy_to_user(_sync_ptr, &sync_ptr, sizeof(sync_ptr)))
+ return -EFAULT;
+ return 0;
+}
+
/*
*/
enum {
@@ -537,7 +607,7 @@ static long snd_pcm_ioctl_compat(struct
if (in_x32_syscall())
return snd_pcm_ioctl_sync_ptr_x32(substream, argp);
#endif /* CONFIG_X86_X32 */
- return snd_pcm_common_ioctl(file, substream, cmd, argp);
+ return snd_pcm_ioctl_sync_ptr_buggy(substream, argp);
case SNDRV_PCM_IOCTL_HW_REFINE32:
return snd_pcm_ioctl_hw_params_compat(substream, 1, argp);
case SNDRV_PCM_IOCTL_HW_PARAMS32:
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 003/151] ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 001/151] ALSA: usb-audio: Add quirk for VF0770 Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 002/151] ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 004/151] ALSA: seq: Fix a potential UAF by wrong private_free call order Greg Kroah-Hartman
` (153 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, kernel test robot, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 8ec59ac3ad29891c0afef627640df36f2daa0349 upstream.
The check of the returned error code is missing in
scarlett2_update_monitor_other(). Let's fix it.
Fixes: d5bda7e03982 ("ALSA: usb-audio: scarlett2: Add support for the talkback feature")
Reported-by: kernel test robot <lkp@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/202109131831.9IodEzRx-lkp@intel.com
Link: https://lore.kernel.org/r/20210929073540.9611-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer_scarlett_gen2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/usb/mixer_scarlett_gen2.c
+++ b/sound/usb/mixer_scarlett_gen2.c
@@ -2450,6 +2450,8 @@ static int scarlett2_update_monitor_othe
err = scarlett2_usb_get_config(mixer,
SCARLETT2_CONFIG_TALKBACK_MAP,
1, &bitmap);
+ if (err < 0)
+ return err;
for (i = 0; i < num_mixes; i++, bitmap >>= 1)
private->talkback_map[i] = bitmap & 1;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 004/151] ALSA: seq: Fix a potential UAF by wrong private_free call order
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 003/151] ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 005/151] ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop Greg Kroah-Hartman
` (152 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai, John Keeping
From: Takashi Iwai <tiwai@suse.de>
commit 1f8763c59c4ec6254d629fe77c0a52220bd907aa upstream.
John Keeping reported and posted a patch for a potential UAF in
rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be
called after the associated rawmidi object got already freed.
After a deeper look, it turned out that the bug is rather the
incorrect private_free call order for a snd_seq_device. The
snd_seq_device private_free gets called at the release callback of the
sequencer device object, while this was rather expected to be executed
at the snd_device call chains that runs at the beginning of the whole
card-free procedure. It's been broken since the rewrite of
sequencer-device binding (although it hasn't surfaced because the
sequencer device release happens usually right along with the card
device release).
This patch corrects the private_free call to be done in the right
place, at snd_seq_device_dev_free().
Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus")
Reported-and-tested-by: John Keeping <john@metanate.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq_device.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/sound/core/seq_device.c
+++ b/sound/core/seq_device.c
@@ -156,6 +156,8 @@ static int snd_seq_device_dev_free(struc
struct snd_seq_device *dev = device->device_data;
cancel_autoload_drivers();
+ if (dev->private_free)
+ dev->private_free(dev);
put_device(&dev->dev);
return 0;
}
@@ -183,11 +185,7 @@ static int snd_seq_device_dev_disconnect
static void snd_seq_dev_release(struct device *dev)
{
- struct snd_seq_device *sdev = to_seq_dev(dev);
-
- if (sdev->private_free)
- sdev->private_free(sdev);
- kfree(sdev);
+ kfree(to_seq_dev(dev));
}
/*
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 005/151] ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 004/151] ALSA: seq: Fix a potential UAF by wrong private_free call order Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 006/151] ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254 Greg Kroah-Hartman
` (151 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, John Liu, Takashi Iwai
From: John Liu <johnliu55tw@gmail.com>
commit eb676622846b34a751e2ff9b5910a5322a4e0000 upstream.
The Dell Precision 5560 laptop appears to use the 4-speakers-on-ALC289
audio just like its sibling product XPS 9510, so it requires the same
quirk to enable woofer output. Tested on my Dell Precision 5560.
Signed-off-by: John Liu <johnliu55tw@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930115316.659-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8465,6 +8465,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x0a30, "Dell", ALC236_FIXUP_DELL_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0a58, "Dell", ALC255_FIXUP_DELL_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0a61, "Dell XPS 15 9510", ALC289_FIXUP_DUAL_SPK),
+ SND_PCI_QUIRK(0x1028, 0x0a62, "Dell Precision 5560", ALC289_FIXUP_DUAL_SPK),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 006/151] ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 005/151] ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 007/151] ALSA: hda/realtek: Complete partial device name to avoid ambiguity Greg Kroah-Hartman
` (150 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Chris Chiu, Takashi Iwai
From: Chris Chiu <chris.chiu@canonical.com>
commit 2b987fe84429361c7f189568c476d1bd00d2ff7e upstream.
The headphone mic is not working on Dell Latitude laptops with ALC3254.
The codec vendor id is 0x10ec0295 and share the same pincfg as defined
in ALC295_STANDARD_PINS. So the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE will
be applied per alc269_pin_fixup_tbl[] but actually the headphone mic is
using NID 0x1b instead of 0x1a. The ALC269_FIXUP_DELL4_MIC_NO_PRESENCE
need to be applied instead.
Use ALC269_FIXUP_DELL4_MIC_NO_PRESENCE for particular models before
a generic fixup comes out.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001062856.1037901-1-chris.chiu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8466,6 +8466,8 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x0a58, "Dell", ALC255_FIXUP_DELL_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0a61, "Dell XPS 15 9510", ALC289_FIXUP_DUAL_SPK),
SND_PCI_QUIRK(0x1028, 0x0a62, "Dell Precision 5560", ALC289_FIXUP_DUAL_SPK),
+ SND_PCI_QUIRK(0x1028, 0x0a9d, "Dell Latitude 5430", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1028, 0x0a9e, "Dell Latitude 5430", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 007/151] ALSA: hda/realtek: Complete partial device name to avoid ambiguity
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 006/151] ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 008/151] ALSA: hda/realtek: Add quirk for Clevo X170KM-G Greg Kroah-Hartman
` (149 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Werner Sembach, Takashi Iwai
From: Werner Sembach <wse@tuxedocomputers.com>
commit 1f8d398e1cd8813f8ec16d55c086e8270a9c18ab upstream.
The string "Clevo X170" is not enough to unambiguously identify the correct
device.
Fixing it so another Clevo barebone name starting with "X170" can be added
without causing confusion.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001133111.428249-2-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2549,7 +2549,7 @@ static const struct snd_pci_quirk alc882
SND_PCI_QUIRK(0x1558, 0x67e1, "Clevo PB71[DE][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
SND_PCI_QUIRK(0x1558, 0x67e5, "Clevo PC70D[PRS](?:-D|-G)?", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
SND_PCI_QUIRK(0x1558, 0x70d1, "Clevo PC70[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
- SND_PCI_QUIRK(0x1558, 0x7714, "Clevo X170", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
+ SND_PCI_QUIRK(0x1558, 0x7714, "Clevo X170SM", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
SND_PCI_QUIRK(0x1558, 0x9501, "Clevo P950HR", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1558, 0x9506, "Clevo P955HQ", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1558, 0x950a, "Clevo P955H[PR]", ALC1220_FIXUP_CLEVO_P950),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 008/151] ALSA: hda/realtek: Add quirk for Clevo X170KM-G
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 007/151] ALSA: hda/realtek: Complete partial device name to avoid ambiguity Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 009/151] ALSA: hda/realtek - ALC236 headset MIC recording issue Greg Kroah-Hartman
` (148 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Werner Sembach, Takashi Iwai
From: Werner Sembach <wse@tuxedocomputers.com>
commit cc03069a397005da24f6783835c274d5aedf6043 upstream.
This applies a SND_PCI_QUIRK(...) to the Clevo X170KM-G barebone. This
fixes the issue of the devices internal Speaker not working.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001133111.428249-3-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2550,6 +2550,7 @@ static const struct snd_pci_quirk alc882
SND_PCI_QUIRK(0x1558, 0x67e5, "Clevo PC70D[PRS](?:-D|-G)?", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
SND_PCI_QUIRK(0x1558, 0x70d1, "Clevo PC70[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
SND_PCI_QUIRK(0x1558, 0x7714, "Clevo X170SM", ALC1220_FIXUP_CLEVO_PB51ED_PINS),
+ SND_PCI_QUIRK(0x1558, 0x7715, "Clevo X170KM-G", ALC1220_FIXUP_CLEVO_PB51ED),
SND_PCI_QUIRK(0x1558, 0x9501, "Clevo P950HR", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1558, 0x9506, "Clevo P955HQ", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1558, 0x950a, "Clevo P955H[PR]", ALC1220_FIXUP_CLEVO_P950),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 009/151] ALSA: hda/realtek - ALC236 headset MIC recording issue
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 008/151] ALSA: hda/realtek: Add quirk for Clevo X170KM-G Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 010/151] ALSA: hda/realtek: Add quirk for TongFang PHxTxX1 Greg Kroah-Hartman
` (147 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kailang Yang, Kai-Heng Feng, Takashi Iwai
From: Kailang Yang <kailang@realtek.com>
commit 5aec98913095ed3b4424ed6c5fdeb6964e9734da upstream.
In power save mode, the recording voice from headset mic will 2s more delay.
Add this patch will solve this issue.
[ minor coding style fix by tiwai ]
Signed-off-by: Kailang Yang <kailang@realtek.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/ccb0cdd5bbd7486eabbd8d987d384cb0@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -527,6 +527,8 @@ static void alc_shutup_pins(struct hda_c
struct alc_spec *spec = codec->spec;
switch (codec->core.vendor_id) {
+ case 0x10ec0236:
+ case 0x10ec0256:
case 0x10ec0283:
case 0x10ec0286:
case 0x10ec0288:
@@ -3541,7 +3543,8 @@ static void alc256_shutup(struct hda_cod
/* If disable 3k pulldown control for alc257, the Mic detection will not work correctly
* when booting with headset plugged. So skip setting it for the codec alc257
*/
- if (codec->core.vendor_id != 0x10ec0257)
+ if (spec->codec_variant != ALC269_TYPE_ALC257 &&
+ spec->codec_variant != ALC269_TYPE_ALC256)
alc_update_coef_idx(codec, 0x46, 0, 3 << 12);
if (!spec->no_shutup_pins)
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 010/151] ALSA: hda/realtek: Add quirk for TongFang PHxTxX1
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 009/151] ALSA: hda/realtek - ALC236 headset MIC recording issue Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 011/151] ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2 Greg Kroah-Hartman
` (146 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Werner Sembach, Takashi Iwai
From: Werner Sembach <wse@tuxedocomputers.com>
commit dd6dd6e3c791db7fdbc5433ec7e450717aa3a0ce upstream.
This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This
fixes the issue of the internal Microphone not working after booting
another OS.
When booting a certain another OS this barebone keeps some coeff settings
even after a cold shutdown. These coeffs prevent the microphone detection
from working in Linux, making the Laptop think that there is always an
external microphone plugged-in and therefore preventing the use of the
internal one.
The relevant indexes and values where gathered by naively diff-ing and
reading a working and a non-working coeff dump.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211006130415.538243-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6466,6 +6466,24 @@ static void alc287_fixup_legion_15imhg05
/* for alc285_fixup_ideapad_s740_coef() */
#include "ideapad_s740_helper.c"
+static void alc256_fixup_tongfang_reset_persistent_settings(struct hda_codec *codec,
+ const struct hda_fixup *fix,
+ int action)
+{
+ /*
+ * A certain other OS sets these coeffs to different values. On at least one TongFang
+ * barebone these settings might survive even a cold reboot. So to restore a clean slate the
+ * values are explicitly reset to default here. Without this, the external microphone is
+ * always in a plugged-in state, while the internal microphone is always in an unplugged
+ * state, breaking the ability to use the internal microphone.
+ */
+ alc_write_coef_idx(codec, 0x24, 0x0000);
+ alc_write_coef_idx(codec, 0x26, 0x0000);
+ alc_write_coef_idx(codec, 0x29, 0x3000);
+ alc_write_coef_idx(codec, 0x37, 0xfe05);
+ alc_write_coef_idx(codec, 0x45, 0x5089);
+}
+
enum {
ALC269_FIXUP_GPIO2,
ALC269_FIXUP_SONY_VAIO,
@@ -6680,7 +6698,8 @@ enum {
ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS,
ALC287_FIXUP_LEGION_15IMHG05_AUTOMUTE,
ALC287_FIXUP_YOGA7_14ITL_SPEAKERS,
- ALC287_FIXUP_13S_GEN2_SPEAKERS
+ ALC287_FIXUP_13S_GEN2_SPEAKERS,
+ ALC256_FIXUP_TONGFANG_RESET_PERSISTENT_SETTINGS,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -8378,6 +8397,10 @@ static const struct hda_fixup alc269_fix
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE,
},
+ [ALC256_FIXUP_TONGFANG_RESET_PERSISTENT_SETTINGS] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc256_fixup_tongfang_reset_persistent_settings,
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -8809,6 +8832,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
SND_PCI_QUIRK(0x1c06, 0x2013, "Lemote A1802", ALC269_FIXUP_LEMOTE_A1802),
SND_PCI_QUIRK(0x1c06, 0x2015, "Lemote A190X", ALC269_FIXUP_LEMOTE_A190X),
+ SND_PCI_QUIRK(0x1d05, 0x1132, "TongFang PHxTxX1", ALC256_FIXUP_TONGFANG_RESET_PERSISTENT_SETTINGS),
SND_PCI_QUIRK(0x1d72, 0x1602, "RedmiBook", ALC255_FIXUP_XIAOMI_HEADSET_MIC),
SND_PCI_QUIRK(0x1d72, 0x1701, "XiaomiNotebook Pro", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1d72, 0x1901, "RedmiBook 14", ALC256_FIXUP_ASUS_HEADSET_MIC),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 011/151] ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 010/151] ALSA: hda/realtek: Add quirk for TongFang PHxTxX1 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 012/151] ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW Greg Kroah-Hartman
` (145 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Cameron Berkenpas, Takashi Iwai
From: Cameron Berkenpas <cam@neo-zeon.de>
commit 023a062f238129e8a542b5163c4350ceb076283e upstream.
The previous patch's HDA verb initialization for the Lenovo 13s
sequence was slightly off. This updated verb sequence has been tested
and confirmed working.
Fixes: ad7cc2d41b7a ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
Cc: <stable@vger.kernel.org>
Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de>
Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8380,7 +8380,7 @@ static const struct hda_fixup alc269_fix
.v.verbs = (const struct hda_verb[]) {
{ 0x20, AC_VERB_SET_COEF_INDEX, 0x24 },
{ 0x20, AC_VERB_SET_PROC_COEF, 0x41 },
- { 0x20, AC_VERB_SET_PROC_COEF, 0xb020 },
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x26 },
{ 0x20, AC_VERB_SET_PROC_COEF, 0x2 },
{ 0x20, AC_VERB_SET_PROC_COEF, 0x0 },
{ 0x20, AC_VERB_SET_PROC_COEF, 0x0 },
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 012/151] ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 011/151] ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 013/151] platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2 Greg Kroah-Hartman
` (144 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hui Wang, Takashi Iwai, msd
From: Hui Wang <hui.wang@canonical.com>
commit a3fd1a986e499a06ac5ef95c3a39aa4611e7444c upstream.
We need to define the codec pin 0x1b to be the mic, but somehow
the mic doesn't support hot plugging detection, and Windows also has
this issue, so we set it to phantom headset-mic.
Also the determine_headset_type() often returns the omtp type by a
mistake when we plug a ctia headset, this makes the mic can't record
sound at all. Because most of the headset are ctia type nowadays and
some machines have the fixed ctia type audio jack, it is possible this
machine has the fixed ctia jack too. Here we set this mic jack to
fixed ctia type, this could avoid the mic type detection mistake and
make the ctia headset work stable.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537
Reported-and-tested-by: msd <msd.mmq@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -10210,6 +10210,9 @@ enum {
ALC671_FIXUP_HP_HEADSET_MIC2,
ALC662_FIXUP_ACER_X2660G_HEADSET_MODE,
ALC662_FIXUP_ACER_NITRO_HEADSET_MODE,
+ ALC668_FIXUP_ASUS_NO_HEADSET_MIC,
+ ALC668_FIXUP_HEADSET_MIC,
+ ALC668_FIXUP_MIC_DET_COEF,
};
static const struct hda_fixup alc662_fixups[] = {
@@ -10593,6 +10596,29 @@ static const struct hda_fixup alc662_fix
.chained = true,
.chain_id = ALC662_FIXUP_USI_FUNC
},
+ [ALC668_FIXUP_ASUS_NO_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x1b, 0x04a1112c },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC668_FIXUP_HEADSET_MIC
+ },
+ [ALC668_FIXUP_HEADSET_MIC] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc269_fixup_headset_mic,
+ .chained = true,
+ .chain_id = ALC668_FIXUP_MIC_DET_COEF
+ },
+ [ALC668_FIXUP_MIC_DET_COEF] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x15 },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x0d60 },
+ {}
+ },
+ },
};
static const struct snd_pci_quirk alc662_fixup_tbl[] = {
@@ -10628,6 +10654,7 @@ static const struct snd_pci_quirk alc662
SND_PCI_QUIRK(0x1043, 0x15a7, "ASUS UX51VZH", ALC662_FIXUP_BASS_16),
SND_PCI_QUIRK(0x1043, 0x177d, "ASUS N551", ALC668_FIXUP_ASUS_Nx51),
SND_PCI_QUIRK(0x1043, 0x17bd, "ASUS N751", ALC668_FIXUP_ASUS_Nx51),
+ SND_PCI_QUIRK(0x1043, 0x185d, "ASUS G551JW", ALC668_FIXUP_ASUS_NO_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x1963, "ASUS X71SL", ALC662_FIXUP_ASUS_MODE8),
SND_PCI_QUIRK(0x1043, 0x1b73, "ASUS N55SF", ALC662_FIXUP_BASS_16),
SND_PCI_QUIRK(0x1043, 0x1bf3, "ASUS N76VZ", ALC662_FIXUP_BASS_MODE4_CHMAP),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 013/151] platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 012/151] ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 014/151] platform/x86: amd-pmc: Add alternative acpi id for PMC controller Greg Kroah-Hartman
` (143 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zephaniah E. Loss-Cutler-Hull, Hans de Goede
From: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
commit 0f607d6b227470456a69a37d7c7badea51d52844 upstream.
This works just fine on my system.
Signed-off-by: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211005044855.1429724-1-zephaniah@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/gigabyte-wmi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/platform/x86/gigabyte-wmi.c
+++ b/drivers/platform/x86/gigabyte-wmi.c
@@ -141,6 +141,7 @@ static u8 gigabyte_wmi_detect_sensor_usa
static const struct dmi_system_id gigabyte_wmi_known_working_platforms[] = {
DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M S2H V2"),
+ DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE AX V2"),
DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE"),
DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE V2"),
DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 GAMING X V2"),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 014/151] platform/x86: amd-pmc: Add alternative acpi id for PMC controller
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 013/151] platform/x86: gigabyte-wmi: add support for B550 AORUS ELITE AX V2 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 015/151] spi: atmel: Fix PDC transfer setup bug Greg Kroah-Hartman
` (142 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sachi King, Mario Limonciello, Hans de Goede
From: Sachi King <nakato@nakato.io>
commit c0d84d2c7c23e9cf23a5abdda40eeaa79eabfe69 upstream.
The Surface Laptop 4 AMD has used the AMD0005 to identify this
controller instead of using the appropriate ACPI ID AMDI0005. Include
AMD0005 in the acpi id list.
Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd
Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863
Cc: <stable@vger.kernel.org> # 5.14+
Signed-off-by: Sachi King <nakato@nakato.io>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.io
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/amd-pmc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/platform/x86/amd-pmc.c
+++ b/drivers/platform/x86/amd-pmc.c
@@ -476,6 +476,7 @@ static const struct acpi_device_id amd_p
{"AMDI0006", 0},
{"AMDI0007", 0},
{"AMD0004", 0},
+ {"AMD0005", 0},
{ }
};
MODULE_DEVICE_TABLE(acpi, amd_pmc_acpi_ids);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 015/151] spi: atmel: Fix PDC transfer setup bug
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 014/151] platform/x86: amd-pmc: Add alternative acpi id for PMC controller Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 016/151] mtd: rawnand: qcom: Update code word value for raw read Greg Kroah-Hartman
` (141 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ville Baillie, Mark Brown
From: Ville Baillie <villeb@bytesnap.co.uk>
commit 75e33c55ae8fb4a177fe07c284665e1d61b02560 upstream.
atmel_spi_dma_map_xfer to never be called in PDC mode. This causes the
driver to silently fail.
This patch changes the conditional to match the behaviour of the
previous commit before the refactor.
Fixes: 5fa5e6dec762 ("spi: atmel: Switch to transfer_one transfer method")
Signed-off-by: Ville Baillie <villeb@bytesnap.co.uk>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210921072132.21831-1-villeb@bytesnap.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-atmel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1301,7 +1301,7 @@ static int atmel_spi_one_transfer(struct
* DMA map early, for performance (empties dcache ASAP) and
* better fault reporting.
*/
- if ((!master->cur_msg_mapped)
+ if ((!master->cur_msg->is_dma_mapped)
&& as->use_pdc) {
if (atmel_spi_dma_map_xfer(as, xfer) < 0)
return -ENOMEM;
@@ -1381,7 +1381,7 @@ static int atmel_spi_one_transfer(struct
}
}
- if (!master->cur_msg_mapped
+ if (!master->cur_msg->is_dma_mapped
&& as->use_pdc)
atmel_spi_dma_unmap_xfer(master, xfer);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 016/151] mtd: rawnand: qcom: Update code word value for raw read
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 015/151] spi: atmel: Fix PDC transfer setup bug Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 017/151] nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^ Greg Kroah-Hartman
` (140 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, stable, Md Sadre Alam, Miquel Raynal
From: Md Sadre Alam <mdalam@codeaurora.org>
commit f60f5741002b9fde748cff65fd09bd6222c5db0c upstream.
>From QPIC V2 onwards there is a separate register to read
last code word "QPIC_NAND_READ_LOCATION_LAST_CW_n".
qcom_nandc_read_cw_raw() is used to read only one code word
at a time. If we will configure number of code words to 1 in
in QPIC_NAND_DEV0_CFG0 register then QPIC controller thinks
its reading the last code word, since from QPIC V2 onwards
we are having separate register to read the last code word,
we have to configure "QPIC_NAND_READ_LOCATION_LAST_CW_n"
register to fetch data from controller buffer to system
memory.
Fixes: 503ee5aad430 ("mtd: rawnand: qcom: update last code word register")
Cc: stable@kernel.org
Signed-off-by: Md Sadre Alam <mdalam@codeaurora.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/1630998357-1359-1-git-send-email-mdalam@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/nand/raw/qcom_nandc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -1676,13 +1676,17 @@ qcom_nandc_read_cw_raw(struct mtd_info *
struct nand_ecc_ctrl *ecc = &chip->ecc;
int data_size1, data_size2, oob_size1, oob_size2;
int ret, reg_off = FLASH_BUF_ACC, read_loc = 0;
+ int raw_cw = cw;
nand_read_page_op(chip, page, 0, NULL, 0);
host->use_ecc = false;
+ if (nandc->props->qpic_v2)
+ raw_cw = ecc->steps - 1;
+
clear_bam_transaction(nandc);
set_address(host, host->cw_size * cw, page);
- update_rw_regs(host, 1, true, cw);
+ update_rw_regs(host, 1, true, raw_cw);
config_nand_page_read(chip);
data_size1 = mtd->writesize - host->cw_size * (ecc->steps - 1);
@@ -1711,7 +1715,7 @@ qcom_nandc_read_cw_raw(struct mtd_info *
nandc_set_read_loc(chip, cw, 3, read_loc, oob_size2, 1);
}
- config_nand_cw_read(chip, false, cw);
+ config_nand_cw_read(chip, false, raw_cw);
read_data_dma(nandc, reg_off, data_buf, data_size1, 0);
reg_off += data_size1;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 017/151] nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 016/151] mtd: rawnand: qcom: Update code word value for raw read Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 018/151] dm: fix mempool NULL pointer race when completing IO Greg Kroah-Hartman
` (139 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Greentime Hu, Steven Rostedt (VMware)
From: Steven Rostedt <rostedt@goodmis.org>
commit be358af1191b1b2fedebd8f3421cafdc8edacc7d upstream.
I received a build failure for a new patch I'm working on the nds32
architecture, and when I went to test it, I couldn't get to my build error,
because it failed to build with a bunch of:
Error: invalid operands (*UND* and *UND* sections) for `^'
issues with various files. Those files were temporary asm files that looked
like: kernel/.tmp_mc_fork.s
I decided to look deeper, and found that the "mc" portion of that name
stood for "mcount", and was created by the recordmcount.pl script. One that
I wrote over a decade ago. Once I knew the source of the problem, I was
able to investigate it further.
The way the recordmcount.pl script works (BTW, there's a C version that
simply modifies the ELF object) is by doing an "objdump" on the object
file. Looks for all the calls to "mcount", and creates an offset of those
locations from some global variable it can use (usually a global function
name, found with <.*>:). Creates a asm file that is a table of references
to these locations, using the found variable/function. Compiles it and
links it back into the original object file. This asm file is called
".tmp_mc_<object_base_name>.s".
The problem here is that the objdump produced by the nds32 object file,
contains things that look like:
0000159a <.L3^B1>:
159a: c6 00 beqz38 $r6, 159a <.L3^B1>
159a: R_NDS32_9_PCREL_RELA .text+0x159e
159c: 84 d2 movi55 $r6, #-14
159e: 80 06 mov55 $r0, $r6
15a0: ec 3c addi10.sp #0x3c
Where ".L3^B1 is somehow selected as the "global" variable to index off of.
Then the assembly file that holds the mcount locations looks like this:
.section __mcount_loc,"a",@progbits
.align 2
.long .L3^B1 + -5522
.long .L3^B1 + -5384
.long .L3^B1 + -5270
.long .L3^B1 + -5098
.long .L3^B1 + -4970
.long .L3^B1 + -4758
.long .L3^B1 + -4122
[...]
And when it is compiled back to an object to link to the original object,
the compile fails on the "^" symbol.
Simple solution for now, is to have the perl script ignore using function
symbols that have an "^" in the name.
Link: https://lkml.kernel.org/r/20211014143507.4ad2c0f7@gandalf.local.home
Cc: stable@vger.kernel.org
Acked-by: Greentime Hu <green.hu@gmail.com>
Fixes: fbf58a52ac088 ("nds32/ftrace: Add RECORD_MCOUNT support")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
scripts/recordmcount.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -189,7 +189,7 @@ if ($arch =~ /(x86(_64)?)|(i386)/) {
$local_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\S+)";
$weak_regex = "^[0-9a-fA-F]+\\s+([wW])\\s+(\\S+)";
$section_regex = "Disassembly of section\\s+(\\S+):";
-$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
+$function_regex = "^([0-9a-fA-F]+)\\s+<([^^]*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s(mcount|__fentry__)\$";
$section_type = '@progbits';
$mcount_adjust = 0;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 018/151] dm: fix mempool NULL pointer race when completing IO
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 017/151] nds32/ftrace: Fix Error: invalid operands (*UND* and *UND* sections) for `^ Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 019/151] ACPI: PM: Include alternate AMDI0005 id in special behaviour Greg Kroah-Hartman
` (138 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jiazi Li, Mike Snitzer
From: Jiazi Li <jqqlijiazi@gmail.com>
commit d208b89401e073de986dc891037c5a668f5d5d95 upstream.
dm_io_dec_pending() calls end_io_acct() first and will then dec md
in-flight pending count. But if a task is swapping DM table at same
time this can result in a crash due to mempool->elements being NULL:
task1 task2
do_resume
->do_suspend
->dm_wait_for_completion
bio_endio
->clone_endio
->dm_io_dec_pending
->end_io_acct
->wakeup task1
->dm_swap_table
->__bind
->__bind_mempools
->bioset_exit
->mempool_exit
->free_io
[ 67.330330] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
......
[ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[ 67.330510] pc : mempool_free+0x70/0xa0
[ 67.330515] lr : mempool_free+0x4c/0xa0
[ 67.330520] sp : ffffff8008013b20
[ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004
[ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8
[ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800
[ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800
[ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80
[ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c
[ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd
[ 67.330563] x15: 000000000093b41e x14: 0000000000000010
[ 67.330569] x13: 0000000000007f7a x12: 0000000034155555
[ 67.330574] x11: 0000000000000001 x10: 0000000000000001
[ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000
[ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a
[ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001
[ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8
[ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970
[ 67.330609] Call trace:
[ 67.330616] mempool_free+0x70/0xa0
[ 67.330627] bio_put+0xf8/0x110
[ 67.330638] dec_pending+0x13c/0x230
[ 67.330644] clone_endio+0x90/0x180
[ 67.330649] bio_endio+0x198/0x1b8
[ 67.330655] dec_pending+0x190/0x230
[ 67.330660] clone_endio+0x90/0x180
[ 67.330665] bio_endio+0x198/0x1b8
[ 67.330673] blk_update_request+0x214/0x428
[ 67.330683] scsi_end_request+0x2c/0x300
[ 67.330688] scsi_io_completion+0xa0/0x710
[ 67.330695] scsi_finish_command+0xd8/0x110
[ 67.330700] scsi_softirq_done+0x114/0x148
[ 67.330708] blk_done_softirq+0x74/0xd0
[ 67.330716] __do_softirq+0x18c/0x374
[ 67.330724] irq_exit+0xb4/0xb8
[ 67.330732] __handle_domain_irq+0x84/0xc0
[ 67.330737] gic_handle_irq+0x148/0x1b0
[ 67.330744] el1_irq+0xe8/0x190
[ 67.330753] lpm_cpuidle_enter+0x4f8/0x538
[ 67.330759] cpuidle_enter_state+0x1fc/0x398
[ 67.330764] cpuidle_enter+0x18/0x20
[ 67.330772] do_idle+0x1b4/0x290
[ 67.330778] cpu_startup_entry+0x20/0x28
[ 67.330786] secondary_start_kernel+0x160/0x170
Fix this by:
1) Establishing pointers to 'struct dm_io' members in
dm_io_dec_pending() so that they may be passed into end_io_acct()
_after_ free_io() is called.
2) Moving end_io_acct() after free_io().
Cc: stable@vger.kernel.org
Signed-off-by: Jiazi Li <lijiazi@xiaomi.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -492,18 +492,17 @@ static void start_io_acct(struct dm_io *
false, 0, &io->stats_aux);
}
-static void end_io_acct(struct dm_io *io)
+static void end_io_acct(struct mapped_device *md, struct bio *bio,
+ unsigned long start_time, struct dm_stats_aux *stats_aux)
{
- struct mapped_device *md = io->md;
- struct bio *bio = io->orig_bio;
- unsigned long duration = jiffies - io->start_time;
+ unsigned long duration = jiffies - start_time;
- bio_end_io_acct(bio, io->start_time);
+ bio_end_io_acct(bio, start_time);
if (unlikely(dm_stats_used(&md->stats)))
dm_stats_account_io(&md->stats, bio_data_dir(bio),
bio->bi_iter.bi_sector, bio_sectors(bio),
- true, duration, &io->stats_aux);
+ true, duration, stats_aux);
/* nudge anyone waiting on suspend queue */
if (unlikely(wq_has_sleeper(&md->wait)))
@@ -786,6 +785,8 @@ void dm_io_dec_pending(struct dm_io *io,
blk_status_t io_error;
struct bio *bio;
struct mapped_device *md = io->md;
+ unsigned long start_time = 0;
+ struct dm_stats_aux stats_aux;
/* Push-back supersedes any I/O errors */
if (unlikely(error)) {
@@ -817,8 +818,10 @@ void dm_io_dec_pending(struct dm_io *io,
}
io_error = io->status;
- end_io_acct(io);
+ start_time = io->start_time;
+ stats_aux = io->stats_aux;
free_io(md, io);
+ end_io_acct(md, bio, start_time, &stats_aux);
if (io_error == BLK_STS_DM_REQUEUE)
return;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 019/151] ACPI: PM: Include alternate AMDI0005 id in special behaviour
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 018/151] dm: fix mempool NULL pointer race when completing IO Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 020/151] dm rq: dont queue request to blk-mq during DM suspend Greg Kroah-Hartman
` (137 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sachi King, Mario Limonciello,
Rafael J. Wysocki
From: Sachi King <nakato@nakato.io>
commit 1ea1dbf1f54c3345072c963b3acf8830e2468c1b upstream.
The Surface Laptop 4 AMD has used the AMD0005 to identify this
controller instead of using the appropriate ACPI ID AMDI0005. The
AMD0005 needs the same special casing as AMDI0005.
Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd
Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863
Signed-off-by: Sachi King <nakato@nakato.io>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Cc: 5.14+ <stable@vger.kernel.org> # 5.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/x86/s2idle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -371,7 +371,7 @@ static int lps0_device_attach(struct acp
return 0;
if (acpi_s2idle_vendor_amd()) {
- /* AMD0004, AMDI0005:
+ /* AMD0004, AMD0005, AMDI0005:
* - Should use rev_id 0x0
* - function mask > 0x3: Should use AMD method, but has off by one bug
* - function mask = 0x3: Should use Microsoft method
@@ -390,6 +390,7 @@ static int lps0_device_attach(struct acp
ACPI_LPS0_DSM_UUID_MICROSOFT, 0,
&lps0_dsm_guid_microsoft);
if (lps0_dsm_func_mask > 0x3 && (!strcmp(hid, "AMD0004") ||
+ !strcmp(hid, "AMD0005") ||
!strcmp(hid, "AMDI0005"))) {
lps0_dsm_func_mask = (lps0_dsm_func_mask << 1) | 0x1;
acpi_handle_debug(adev->handle, "_DSM UUID %s: Adjusted function mask: 0x%x\n",
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 020/151] dm rq: dont queue request to blk-mq during DM suspend
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 019/151] ACPI: PM: Include alternate AMDI0005 id in special behaviour Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 021/151] s390: fix strrchr() implementation Greg Kroah-Hartman
` (136 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ming Lei, Mike Snitzer
From: Ming Lei <ming.lei@redhat.com>
commit b4459b11e84092658fa195a2587aff3b9637f0e7 upstream.
DM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue.
But blk-mq's unquiesce may come from outside events, such as elevator
switch, updating nr_requests or others, and request may come during
suspend, so simply ask for blk-mq to requeue it.
Fixes one kernel panic issue when running updating nr_requests and
dm-mpath suspend/resume stress test.
Cc: stable@vger.kernel.org
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-rq.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/md/dm-rq.c
+++ b/drivers/md/dm-rq.c
@@ -490,6 +490,14 @@ static blk_status_t dm_mq_queue_rq(struc
struct mapped_device *md = tio->md;
struct dm_target *ti = md->immutable_target;
+ /*
+ * blk-mq's unquiesce may come from outside events, such as
+ * elevator switch, updating nr_requests or others, and request may
+ * come during suspend, so simply ask for blk-mq to requeue it.
+ */
+ if (unlikely(test_bit(DMF_BLOCK_IO_FOR_SUSPEND, &md->flags)))
+ return BLK_STS_RESOURCE;
+
if (unlikely(!ti)) {
int srcu_idx;
struct dm_table *map = dm_get_live_table(md, &srcu_idx);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 021/151] s390: fix strrchr() implementation
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 020/151] dm rq: dont queue request to blk-mq during DM suspend Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 022/151] clk: socfpga: agilex: fix duplicate s2f_user0_clk Greg Kroah-Hartman
` (135 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roberto Sassu, Heiko Carstens, Vasily Gorbik
From: Roberto Sassu <roberto.sassu@huawei.com>
commit 8e0ab8e26b72a80e991c66a8abc16e6c856abe3d upstream.
Fix two problems found in the strrchr() implementation for s390
architectures: evaluate empty strings (return the string address instead of
NULL, if '\0' is passed as second argument); evaluate the first character
of non-empty strings (the current implementation stops at the second).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Heiko Carstens <hca@linux.ibm.com> (incorrect behavior with empty strings)
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Link: https://lore.kernel.org/r/20211005120836.60630-1-roberto.sassu@huawei.com
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/lib/string.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/arch/s390/lib/string.c
+++ b/arch/s390/lib/string.c
@@ -259,14 +259,13 @@ EXPORT_SYMBOL(strcmp);
#ifdef __HAVE_ARCH_STRRCHR
char *strrchr(const char *s, int c)
{
- size_t len = __strend(s) - s;
+ ssize_t len = __strend(s) - s;
- if (len)
- do {
- if (s[len] == (char) c)
- return (char *) s + len;
- } while (--len > 0);
- return NULL;
+ do {
+ if (s[len] == (char)c)
+ return (char *)s + len;
+ } while (--len >= 0);
+ return NULL;
}
EXPORT_SYMBOL(strrchr);
#endif
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 022/151] clk: socfpga: agilex: fix duplicate s2f_user0_clk
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 021/151] s390: fix strrchr() implementation Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 023/151] csky: dont let sigreturn play with priveleged bits of status register Greg Kroah-Hartman
` (134 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dinh Nguyen, Stephen Boyd
From: Dinh Nguyen <dinguyen@kernel.org>
commit 09540fa337196be20e9f0241652364f09275d374 upstream.
Remove the duplicate s2f_user0_clk and the unused s2f_usr0_mux define.
Fixes: f817c132db67 ("clk: socfpga: agilex: fix up s2f_user0_clk representation")
Cc: stable@vger.kernel.org
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20210916225126.1427700-1-dinguyen@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/socfpga/clk-agilex.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/drivers/clk/socfpga/clk-agilex.c
+++ b/drivers/clk/socfpga/clk-agilex.c
@@ -165,13 +165,6 @@ static const struct clk_parent_data mpu_
.name = "boot_clk", },
};
-static const struct clk_parent_data s2f_usr0_mux[] = {
- { .fw_name = "f2s-free-clk",
- .name = "f2s-free-clk", },
- { .fw_name = "boot_clk",
- .name = "boot_clk", },
-};
-
static const struct clk_parent_data emac_mux[] = {
{ .fw_name = "emaca_free_clk",
.name = "emaca_free_clk", },
@@ -312,8 +305,6 @@ static const struct stratix10_gate_clock
4, 0x44, 28, 1, 0, 0, 0},
{ AGILEX_CS_TIMER_CLK, "cs_timer_clk", NULL, noc_mux, ARRAY_SIZE(noc_mux), 0, 0x24,
5, 0, 0, 0, 0x30, 1, 0},
- { AGILEX_S2F_USER0_CLK, "s2f_user0_clk", NULL, s2f_usr0_mux, ARRAY_SIZE(s2f_usr0_mux), 0, 0x24,
- 6, 0, 0, 0, 0, 0, 0},
{ AGILEX_EMAC0_CLK, "emac0_clk", NULL, emac_mux, ARRAY_SIZE(emac_mux), 0, 0x7C,
0, 0, 0, 0, 0x94, 26, 0},
{ AGILEX_EMAC1_CLK, "emac1_clk", NULL, emac_mux, ARRAY_SIZE(emac_mux), 0, 0x7C,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 023/151] csky: dont let sigreturn play with priveleged bits of status register
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 022/151] clk: socfpga: agilex: fix duplicate s2f_user0_clk Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 024/151] csky: Fixup regs.sr broken in ptrace Greg Kroah-Hartman
` (133 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro, Guo Ren
From: Al Viro <viro@zeniv.linux.org.uk>
commit fbd63c08cdcca5fb1315aca3172b3c9c272cfb4f upstream.
csky restore_sigcontext() blindly overwrites regs->sr with the value
it finds in sigcontext. Attacker can store whatever they want in there,
which includes things like S-bit. Userland shouldn't be able to set
that, or anything other than C flag (bit 0).
Do the same thing other architectures with protected bits in flags
register do - preserve everything that shouldn't be settable in
user mode, picking the rest from the value saved is sigcontext.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Guo Ren <guoren@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/csky/kernel/signal.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/csky/kernel/signal.c
+++ b/arch/csky/kernel/signal.c
@@ -52,10 +52,14 @@ static long restore_sigcontext(struct pt
struct sigcontext __user *sc)
{
int err = 0;
+ unsigned long sr = regs->sr;
/* sc_pt_regs is structured the same as the start of pt_regs */
err |= __copy_from_user(regs, &sc->sc_pt_regs, sizeof(struct pt_regs));
+ /* BIT(0) of regs->sr is Condition Code/Carry bit */
+ regs->sr = (sr & ~1) | (regs->sr & 1);
+
/* Restore the floating-point state. */
err |= restore_fpu_state(sc);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 024/151] csky: Fixup regs.sr broken in ptrace
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 023/151] csky: dont let sigreturn play with priveleged bits of status register Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 025/151] drm/fbdev: Clamp fbdev surface size if too large Greg Kroah-Hartman
` (132 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Guo Ren, Al Viro
From: Guo Ren <guoren@linux.alibaba.com>
commit af89ebaa64de726ca0a39bbb0bf0c81a1f43ad50 upstream.
gpr_get() return the entire pt_regs (include sr) to userspace, if we
don't restore the C bit in gpr_set, it may break the ALU result in
that context. So the C flag bit is part of gpr context, that's why
riscv totally remove the C bit in the ISA. That makes sr reg clear
from userspace to supervisor privilege.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/csky/kernel/ptrace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/csky/kernel/ptrace.c
+++ b/arch/csky/kernel/ptrace.c
@@ -99,7 +99,8 @@ static int gpr_set(struct task_struct *t
if (ret)
return ret;
- regs.sr = task_pt_regs(target)->sr;
+ /* BIT(0) of regs.sr is Condition Code/Carry bit */
+ regs.sr = (regs.sr & BIT(0)) | (task_pt_regs(target)->sr & ~BIT(0));
#ifdef CONFIG_CPU_HAS_HILO
regs.dcsr = task_pt_regs(target)->dcsr;
#endif
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 025/151] drm/fbdev: Clamp fbdev surface size if too large
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 024/151] csky: Fixup regs.sr broken in ptrace Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 026/151] arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE Greg Kroah-Hartman
` (131 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Zimmermann,
Ville Syrjälä,
Alex Deucher, Amanoel Dawod, Zoltán Kővágó,
Michael Stapelberg, Daniel Vetter, Maxime Ripard, dri-devel,
Dave Airlie
From: Thomas Zimmermann <tzimmermann@suse.de>
commit b693e42921e0220c0d564c55c6cdc680b0f85390 upstream.
Clamp the fbdev surface size of the available maximumi height to avoid
failing to init console emulation. An example error is shown below.
bad framebuffer height 2304, should be >= 768 && <= 768
[drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22)
This is especially a problem with drivers that have very small screen
sizes and cannot over-allocate at all.
v2:
* reduce warning level (Ville)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Amanoel Dawod <kernel@amanoeldawod.com>
Reported-by: Zoltán Kővágó <dirty.ice.hu@gmail.com>
Reported-by: Michael Stapelberg <michael+lkml@stapelberg.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.14+
Link: https://patchwork.freedesktop.org/patch/msgid/20211005070355.7680-1-tzimmermann@suse.de
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1506,6 +1506,7 @@ static int drm_fb_helper_single_fb_probe
{
struct drm_client_dev *client = &fb_helper->client;
struct drm_device *dev = fb_helper->dev;
+ struct drm_mode_config *config = &dev->mode_config;
int ret = 0;
int crtc_count = 0;
struct drm_connector_list_iter conn_iter;
@@ -1663,6 +1664,11 @@ static int drm_fb_helper_single_fb_probe
/* Handle our overallocation */
sizes.surface_height *= drm_fbdev_overalloc;
sizes.surface_height /= 100;
+ if (sizes.surface_height > config->max_height) {
+ drm_dbg_kms(dev, "Fbdev over-allocation too large; clamping height to %d\n",
+ config->max_height);
+ sizes.surface_height = config->max_height;
+ }
/* push down into drivers */
ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 026/151] arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 025/151] drm/fbdev: Clamp fbdev surface size if too large Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 027/151] drm/nouveau/fifo: Reinstate the correct engine bit programming Greg Kroah-Hartman
` (130 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Kravetz, Anshuman Khandual,
Catalin Marinas
From: Mike Kravetz <mike.kravetz@oracle.com>
commit 2e5809a4ddb15969503e43b06662a9a725f613ea upstream.
For non-4K PAGE_SIZE configs, the largest gigantic huge page size is
CONT_PMD_SHIFT order. On arm64 with 64K PAGE_SIZE, the gigantic page is
16G. Therefore, one should be able to specify 'hugetlb_cma=16G' on the
kernel command line so that one gigantic page can be allocated from CMA.
However, when adding such an option the following message is produced:
hugetlb_cma: cma area should be at least 8796093022208 MiB
This is because the calculation for non-4K gigantic page order is
incorrect in the arm64 specific routine arm64_hugetlb_cma_reserve().
Fixes: abb7962adc80 ("arm64/hugetlb: Reserve CMA areas for gigantic pages on 16K and 64K configs")
Cc: <stable@vger.kernel.org> # 5.9.x
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20211005202529.213812-1-mike.kravetz@oracle.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -43,7 +43,7 @@ void __init arm64_hugetlb_cma_reserve(vo
#ifdef CONFIG_ARM64_4K_PAGES
order = PUD_SHIFT - PAGE_SHIFT;
#else
- order = CONT_PMD_SHIFT + PMD_SHIFT - PAGE_SHIFT;
+ order = CONT_PMD_SHIFT - PAGE_SHIFT;
#endif
/*
* HugeTLB CMA reservation is required for gigantic
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 027/151] drm/nouveau/fifo: Reinstate the correct engine bit programming
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 026/151] arm64/hugetlb: fix CMA gigantic page order for non-4K PAGE_SIZE Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 028/151] drm/msm: Do not run snapshot on non-DPU devices Greg Kroah-Hartman
` (129 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Ben Skeggs,
Karol Herbst, Lyude Paul, Dave Airlie
From: Marek Vasut <marex@denx.de>
commit d1d94b0129dccd226784633c60b7df90e8a051b5 upstream.
Commit 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook") replaced
fifo/chang84.c g84_fifo_chan_engine() call with an indirect call of
fifo/g84.c g84_fifo_engine_id(). The G84_FIFO_ENGN_* values returned
from the later g84_fifo_engine_id() are incremented by 1 compared to
the previous g84_fifo_chan_engine() return values.
This is fine either way for most of the code, except this one line
where an engine bit programmed into the hardware is derived from the
return value. Decrement the return value accordingly, otherwise the
wrong engine bit is programmed into the hardware and that leads to
the following failure:
nouveau 0000:01:00.0: gr: 00000030 [ILLEGAL_MTHD ILLEGAL_CLASS] ch 1 [003fbce000 DRM] subc 3 class 0000 mthd 085c data 00000420
On the following hardware:
lspci -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2)
lspci -ns 01:00.0
01:00.0 0300: 10de:0a3c (rev a2)
Fixes: 64f7c698bea9 ("drm/nouveau/fifo: add engine_id hook")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: <stable@vger.kernel.org> # 5.12+
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211007214117.231472-1-marex@denx.de
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
@@ -82,7 +82,7 @@ g84_fifo_chan_engine_fini(struct nvkm_fi
if (offset < 0)
return 0;
- engn = fifo->base.func->engine_id(&fifo->base, engine);
+ engn = fifo->base.func->engine_id(&fifo->base, engine) - 1;
save = nvkm_mask(device, 0x002520, 0x0000003f, 1 << engn);
nvkm_wr32(device, 0x0032fc, chan->base.inst->addr >> 12);
done = nvkm_msec(device, 2000,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 028/151] drm/msm: Do not run snapshot on non-DPU devices
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 027/151] drm/nouveau/fifo: Reinstate the correct engine bit programming Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 029/151] drm/msm: Avoid potential overflow in timeout_to_jiffies() Greg Kroah-Hartman
` (128 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Fabio Estevam, Rob Clark
From: Fabio Estevam <festevam@gmail.com>
commit 6a7e0b0e9fb839caa7c7f25bcf91a95b1c2cbef1 upstream.
Since commit 98659487b845 ("drm/msm: add support to take dpu snapshot")
the following NULL pointer dereference is seen on i.MX53:
[ 3.275493] msm msm: bound 30000000.gpu (ops a3xx_ops)
[ 3.287174] [drm] Initialized msm 1.8.0 20130625 for msm on minor 0
[ 3.293915] 8<--- cut here ---
[ 3.297012] Unable to handle kernel NULL pointer dereference at virtual address 00000028
[ 3.305244] pgd = (ptrval)
[ 3.307989] [00000028] *pgd=00000000
[ 3.311624] Internal error: Oops: 805 [#1] SMP ARM
[ 3.316430] Modules linked in:
[ 3.319503] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+g682d702b426b #1
[ 3.326652] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 3.332754] PC is at __mutex_init+0x14/0x54
[ 3.336969] LR is at msm_disp_snapshot_init+0x24/0xa0
i.MX53 does not use the DPU controller.
Fix the problem by only calling msm_disp_snapshot_init() on platforms that
use the DPU controller.
Cc: stable@vger.kernel.org
Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20210914174831.2044420-1-festevam@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/msm_drv.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -566,10 +566,11 @@ static int msm_drm_init(struct device *d
if (ret)
goto err_msm_uninit;
- ret = msm_disp_snapshot_init(ddev);
- if (ret)
- DRM_DEV_ERROR(dev, "msm_disp_snapshot_init failed ret = %d\n", ret);
-
+ if (kms) {
+ ret = msm_disp_snapshot_init(ddev);
+ if (ret)
+ DRM_DEV_ERROR(dev, "msm_disp_snapshot_init failed ret = %d\n", ret);
+ }
drm_mode_config_reset(ddev);
#ifdef CONFIG_DRM_FBDEV_EMULATION
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 029/151] drm/msm: Avoid potential overflow in timeout_to_jiffies()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 028/151] drm/msm: Do not run snapshot on non-DPU devices Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 030/151] btrfs: unlock newly allocated extent buffer after error Greg Kroah-Hartman
` (127 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Arnd Bergmann,
Jordan Crouse, Rob Clark, Dmitry Baryshkov
From: Marek Vasut <marex@denx.de>
commit 171316a68d9a8e0d9e28b7cf4c15afc4c6244a4e upstream.
The return type of ktime_divns() is s64. The timeout_to_jiffies() currently
assigns the result of this ktime_divns() to unsigned long, which on 32 bit
systems may overflow. Furthermore, the result of this function is sometimes
also passed to functions which expect signed long, dma_fence_wait_timeout()
is one such example.
Fix this by adjusting the type of remaining_jiffies to s64, so we do not
suffer overflow there, and return a value limited to range of 0..INT_MAX,
which is safe for all usecases of this timeout.
The above overflow can be triggered if userspace passes in too large timeout
value, larger than INT_MAX / HZ seconds. The kernel detects it and complains
about "schedule_timeout: wrong timeout value %lx" and generates a warning
backtrace.
Note that this fixes commit 6cedb8b377bb ("drm/msm: avoid using 'timespec'"),
because the previously used timespec_to_jiffies() function returned unsigned
long instead of s64:
static inline unsigned long timespec_to_jiffies(const struct timespec *value)
Fixes: 6cedb8b377bb ("drm/msm: avoid using 'timespec'")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Cc: stable@vger.kernel.org # 5.6+
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210917005913.157379-1-marex@denx.de
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/msm_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -535,7 +535,7 @@ static inline int align_pitch(int width,
static inline unsigned long timeout_to_jiffies(const ktime_t *timeout)
{
ktime_t now = ktime_get();
- unsigned long remaining_jiffies;
+ s64 remaining_jiffies;
if (ktime_compare(*timeout, now) < 0) {
remaining_jiffies = 0;
@@ -544,7 +544,7 @@ static inline unsigned long timeout_to_j
remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
}
- return remaining_jiffies;
+ return clamp(remaining_jiffies, 0LL, (s64)INT_MAX);
}
#endif /* __MSM_DRV_H__ */
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 030/151] btrfs: unlock newly allocated extent buffer after error
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 029/151] drm/msm: Avoid potential overflow in timeout_to_jiffies() Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 031/151] btrfs: deal with errors when replaying dir entry during log replay Greg Kroah-Hartman
` (126 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hao Sun, Qu Wenruo, David Sterba
From: Qu Wenruo <wqu@suse.com>
commit 19ea40dddf1833db868533958ca066f368862211 upstream.
[BUG]
There is a bug report that injected ENOMEM error could leave a tree
block locked while we return to user-space:
BTRFS info (device loop0): enabling ssd optimizations
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 0 PID: 7579 Comm: syz-executor Not tainted 5.15.0-rc1 #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106
fail_dump lib/fault-inject.c:52 [inline]
should_fail+0x13c/0x160 lib/fault-inject.c:146
should_failslab+0x5/0x10 mm/slab_common.c:1328
slab_pre_alloc_hook.constprop.99+0x4e/0xc0 mm/slab.h:494
slab_alloc_node mm/slub.c:3120 [inline]
slab_alloc mm/slub.c:3214 [inline]
kmem_cache_alloc+0x44/0x280 mm/slub.c:3219
btrfs_alloc_delayed_extent_op fs/btrfs/delayed-ref.h:299 [inline]
btrfs_alloc_tree_block+0x38c/0x670 fs/btrfs/extent-tree.c:4833
__btrfs_cow_block+0x16f/0x7d0 fs/btrfs/ctree.c:415
btrfs_cow_block+0x12a/0x300 fs/btrfs/ctree.c:570
btrfs_search_slot+0x6b0/0xee0 fs/btrfs/ctree.c:1768
btrfs_insert_empty_items+0x80/0xf0 fs/btrfs/ctree.c:3905
btrfs_new_inode+0x311/0xa60 fs/btrfs/inode.c:6530
btrfs_create+0x12b/0x270 fs/btrfs/inode.c:6783
lookup_open+0x660/0x780 fs/namei.c:3282
open_last_lookups fs/namei.c:3352 [inline]
path_openat+0x465/0xe20 fs/namei.c:3557
do_filp_open+0xe3/0x170 fs/namei.c:3588
do_sys_openat2+0x357/0x4a0 fs/open.c:1200
do_sys_open+0x87/0xd0 fs/open.c:1216
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x34/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x46ae99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f46711b9c48 EFLAGS: 00000246 ORIG_RAX: 0000000000000055
RAX: ffffffffffffffda RBX: 000000000078c0a0 RCX: 000000000046ae99
RDX: 0000000000000000 RSI: 00000000000000a1 RDI: 0000000020005800
RBP: 00007f46711b9c80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000017
R13: 0000000000000000 R14: 000000000078c0a0 R15: 00007ffc129da6e0
================================================
WARNING: lock held when returning to user space!
5.15.0-rc1 #16 Not tainted
------------------------------------------------
syz-executor/7579 is leaving the kernel with locks still held!
1 lock held by syz-executor/7579:
#0: ffff888104b73da8 (btrfs-tree-01/1){+.+.}-{3:3}, at:
__btrfs_tree_lock+0x2e/0x1a0 fs/btrfs/locking.c:112
[CAUSE]
In btrfs_alloc_tree_block(), after btrfs_init_new_buffer(), the new
extent buffer @buf is locked, but if later operations like adding
delayed tree ref fail, we just free @buf without unlocking it,
resulting above warning.
[FIX]
Unlock @buf in out_free_buf: label.
Reported-by: Hao Sun <sunhao.th@gmail.com>
Link: https://lore.kernel.org/linux-btrfs/CACkBjsZ9O6Zr0KK1yGn=1rQi6Crh1yeCRdTSBxx9R99L4xdn-Q@mail.gmail.com/
CC: stable@vger.kernel.org # 5.4+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/extent-tree.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4859,6 +4859,7 @@ struct extent_buffer *btrfs_alloc_tree_b
out_free_delayed:
btrfs_free_delayed_extent_op(extent_op);
out_free_buf:
+ btrfs_tree_unlock(buf);
free_extent_buffer(buf);
out_free_reserved:
btrfs_free_reserved_extent(fs_info, ins.objectid, ins.offset, 0);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 031/151] btrfs: deal with errors when replaying dir entry during log replay
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 030/151] btrfs: unlock newly allocated extent buffer after error Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 032/151] btrfs: deal with errors when adding inode reference " Greg Kroah-Hartman
` (125 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba
From: Filipe Manana <fdmanana@suse.com>
commit e15ac6413745e3def00e663de00aea5a717311c1 upstream.
At replay_one_one(), we are treating any error returned from
btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning
that there is no existing directory entry in the fs/subvolume tree.
This is not correct since we can get errors such as, for example, -EIO
when reading extent buffers while searching the fs/subvolume's btree.
So fix that and return the error to the caller when it is not -ENOENT.
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1977,7 +1977,14 @@ static noinline int replay_one_name(stru
ret = -EINVAL;
goto out;
}
- if (IS_ERR_OR_NULL(dst_di)) {
+
+ if (dst_di == ERR_PTR(-ENOENT))
+ dst_di = NULL;
+
+ if (IS_ERR(dst_di)) {
+ ret = PTR_ERR(dst_di);
+ goto out;
+ } else if (!dst_di) {
/* we need a sequence number to insert, so we only
* do inserts for the BTRFS_DIR_INDEX_KEY types
*/
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 032/151] btrfs: deal with errors when adding inode reference during log replay
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 031/151] btrfs: deal with errors when replaying dir entry during log replay Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 033/151] btrfs: check for error when looking up inode during dir entry replay Greg Kroah-Hartman
` (124 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba
From: Filipe Manana <fdmanana@suse.com>
commit 52db77791fe24538c8aa2a183248399715f6b380 upstream.
At __inode_add_ref(), we treating any error returned from
btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning
that there is no existing directory entry in the fs/subvolume tree.
This is not correct since we can get errors such as, for example, -EIO
when reading extent buffers while searching the fs/subvolume's btree.
So fix that and return the error to the caller when it is not -ENOENT.
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1182,7 +1182,10 @@ next:
/* look for a conflicting sequence number */
di = btrfs_lookup_dir_index_item(trans, root, path, btrfs_ino(dir),
ref_index, name, namelen, 0);
- if (di && !IS_ERR(di)) {
+ if (IS_ERR(di)) {
+ if (PTR_ERR(di) != -ENOENT)
+ return PTR_ERR(di);
+ } else if (di) {
ret = drop_one_dir_item(trans, root, path, dir, di);
if (ret)
return ret;
@@ -1192,7 +1195,9 @@ next:
/* look for a conflicting name */
di = btrfs_lookup_dir_item(trans, root, path, btrfs_ino(dir),
name, namelen, 0);
- if (di && !IS_ERR(di)) {
+ if (IS_ERR(di)) {
+ return PTR_ERR(di);
+ } else if (di) {
ret = drop_one_dir_item(trans, root, path, dir, di);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 033/151] btrfs: check for error when looking up inode during dir entry replay
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 032/151] btrfs: deal with errors when adding inode reference " Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 034/151] btrfs: update refs for any root except tree log roots Greg Kroah-Hartman
` (123 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba
From: Filipe Manana <fdmanana@suse.com>
commit cfd312695b71df04c3a2597859ff12c470d1e2e4 upstream.
At replay_one_name(), we are treating any error from btrfs_lookup_inode()
as if the inode does not exists. Fix this by checking for an error and
returning it to the caller.
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -1941,8 +1941,8 @@ static noinline int replay_one_name(stru
struct btrfs_key log_key;
struct inode *dir;
u8 log_type;
- int exists;
- int ret = 0;
+ bool exists;
+ int ret;
bool update_size = (key->type == BTRFS_DIR_INDEX_KEY);
bool name_added = false;
@@ -1962,12 +1962,12 @@ static noinline int replay_one_name(stru
name_len);
btrfs_dir_item_key_to_cpu(eb, di, &log_key);
- exists = btrfs_lookup_inode(trans, root, path, &log_key, 0);
- if (exists == 0)
- exists = 1;
- else
- exists = 0;
+ ret = btrfs_lookup_inode(trans, root, path, &log_key, 0);
btrfs_release_path(path);
+ if (ret < 0)
+ goto out;
+ exists = (ret == 0);
+ ret = 0;
if (key->type == BTRFS_DIR_ITEM_KEY) {
dst_di = btrfs_lookup_dir_item(trans, root, path, key->objectid,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 034/151] btrfs: update refs for any root except tree log roots
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 033/151] btrfs: check for error when looking up inode during dir entry replay Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 035/151] btrfs: fix abort logic in btrfs_replace_file_extents Greg Kroah-Hartman
` (122 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Qu Wenruo, Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit d175209be04d7d263fa1a54cde7608c706c9d0d7 upstream.
I hit a stuck relocation on btrfs/061 during my overnight testing. This
turned out to be because we had left over extent entries in our extent
root for a data reloc inode that no longer existed. This happened
because in btrfs_drop_extents() we only update refs if we have SHAREABLE
set or we are the tree_root. This regression was introduced by
aeb935a45581 ("btrfs: don't set SHAREABLE flag for data reloc tree")
where we stopped setting SHAREABLE for the data reloc tree.
The problem here is we actually do want to update extent references for
data extents in the data reloc tree, in fact we only don't want to
update extent references if the file extents are in the log tree.
Update this check to only skip updating references in the case of the
log tree.
This is relatively rare, because you have to be running scrub at the
same time, which is what btrfs/061 does. The data reloc inode has its
extents pre-allocated, and then we copy the extent into the
pre-allocated chunks. We theoretically should never be calling
btrfs_drop_extents() on a data reloc inode. The exception of course is
with scrub, if our pre-allocated extent falls inside of the block group
we are scrubbing, then the block group will be marked read only and we
will be forced to cow that extent. This means we will call
btrfs_drop_extents() on that range when we COW that file extent.
This isn't really problematic if we do this, the data reloc inode
requires that our extent lengths match exactly with the extent we are
copying, thankfully we validate the extent is correct with
get_new_location(), so if we happen to COW only part of the extent we
won't link it in when we do the relocation, so we are safe from any
other shenanigans that arise because of this interaction with scrub.
Fixes: aeb935a45581 ("btrfs: don't set SHAREABLE flag for data reloc tree")
CC: stable@vger.kernel.org # 5.8+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/file.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -733,8 +733,7 @@ int btrfs_drop_extents(struct btrfs_tran
if (args->start >= inode->disk_i_size && !args->replace_extent)
modify_tree = 0;
- update_refs = (test_bit(BTRFS_ROOT_SHAREABLE, &root->state) ||
- root == fs_info->tree_root);
+ update_refs = (root->root_key.objectid != BTRFS_TREE_LOG_OBJECTID);
while (1) {
recow = 0;
ret = btrfs_lookup_file_extent(trans, root, path, ino,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 035/151] btrfs: fix abort logic in btrfs_replace_file_extents
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 034/151] btrfs: update refs for any root except tree log roots Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 036/151] module: fix clang CFI with MODULE_UNLOAD=n Greg Kroah-Hartman
` (121 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Borisov, Filipe Manana,
Josef Bacik, David Sterba
From: Josef Bacik <josef@toxicpanda.com>
commit 4afb912f439c4bc4e6a4f3e7547f2e69e354108f upstream.
Error injection testing uncovered a case where we'd end up with a
corrupt file system with a missing extent in the middle of a file. This
occurs because the if statement to decide if we should abort is wrong.
The only way we would abort in this case is if we got a ret !=
-EOPNOTSUPP and we called from the file clone code. However the
prealloc code uses this path too. Instead we need to abort if there is
an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only
if we came from the clone file code.
CC: stable@vger.kernel.org # 5.10+
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/file.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2691,14 +2691,16 @@ int btrfs_replace_file_extents(struct bt
drop_args.bytes_found);
if (ret != -ENOSPC) {
/*
- * When cloning we want to avoid transaction aborts when
- * nothing was done and we are attempting to clone parts
- * of inline extents, in such cases -EOPNOTSUPP is
- * returned by __btrfs_drop_extents() without having
- * changed anything in the file.
+ * The only time we don't want to abort is if we are
+ * attempting to clone a partial inline extent, in which
+ * case we'll get EOPNOTSUPP. However if we aren't
+ * clone we need to abort no matter what, because if we
+ * got EOPNOTSUPP via prealloc then we messed up and
+ * need to abort.
*/
- if (extent_info && !extent_info->is_new_extent &&
- ret && ret != -EOPNOTSUPP)
+ if (ret &&
+ (ret != -EOPNOTSUPP ||
+ (extent_info && extent_info->is_new_extent)))
btrfs_abort_transaction(trans, ret);
break;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 036/151] module: fix clang CFI with MODULE_UNLOAD=n
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 035/151] btrfs: fix abort logic in btrfs_replace_file_extents Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 037/151] x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails Greg Kroah-Hartman
` (120 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Sami Tolvanen,
Miroslav Benes, Arnd Bergmann, Jessica Yu
From: Arnd Bergmann <arnd@arndb.de>
commit 0d67e332e6df72f43eaa21228daa3a79e23093f3 upstream.
When CONFIG_MODULE_UNLOAD is disabled, the module->exit member
is not defined, causing a build failure:
kernel/module.c:4493:8: error: no member named 'exit' in 'struct module'
mod->exit = *exit;
add an #ifdef block around this.
Fixes: cf68fffb66d6 ("add support for Clang CFI")
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/module.c | 2 ++
1 file changed, 2 insertions(+)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4484,8 +4484,10 @@ static void cfi_init(struct module *mod)
/* Fix init/exit functions to point to the CFI jump table */
if (init)
mod->init = *init;
+#ifdef CONFIG_MODULE_UNLOAD
if (exit)
mod->exit = *exit;
+#endif
cfi_module_add(mod, module_addr_min);
#endif
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 037/151] x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 036/151] module: fix clang CFI with MODULE_UNLOAD=n Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 038/151] mei: me: add Ice Lake-N device id Greg Kroah-Hartman
` (119 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, James Morse, Borislav Petkov,
Reinette Chatre
From: James Morse <james.morse@arm.com>
commit 64e87d4bd3201bf8a4685083ee4daf5c0d001452 upstream.
domain_add_cpu() is called whenever a CPU is brought online. The
earlier call to domain_setup_ctrlval() allocates the control value
arrays.
If domain_setup_mon_state() fails, the control value arrays are not
freed.
Add the missing kfree() calls.
Fixes: 1bd2a63b4f0de ("x86/intel_rdt/mba_sc: Add initialization support")
Fixes: edf6fa1c4a951 ("x86/intel_rdt/cqm: Add RMID (Resource monitoring ID) management")
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20210917165958.28313-1-james.morse@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/resctrl/core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -590,6 +590,8 @@ static void domain_add_cpu(int cpu, stru
}
if (r->mon_capable && domain_setup_mon_state(r, d)) {
+ kfree(d->ctrl_val);
+ kfree(d->mbps_val);
kfree(d);
return;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 038/151] mei: me: add Ice Lake-N device id.
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 037/151] x86/resctrl: Free the ctrlval arrays when domain_setup_mon_state() fails Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 039/151] mei: hbm: drop hbm responses on early shutdown Greg Kroah-Hartman
` (118 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andy Shevchenko
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
commit 75c10c5e7a715550afdd51ef8cfd1d975f48f9e1 upstream.
Add Ice Lake-N device ID.
The device can be found on MacBookPro16,2 [1].
[1]: https://linux-hardware.org/?probe=f1c5cf0c43
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211001173644.16068-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 1 +
drivers/misc/mei/pci-me.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -92,6 +92,7 @@
#define MEI_DEV_ID_CDF 0x18D3 /* Cedar Fork */
#define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */
+#define MEI_DEV_ID_ICP_N 0x38E0 /* Ice Lake Point N */
#define MEI_DEV_ID_JSP_N 0x4DE0 /* Jasper Lake Point N */
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -96,6 +96,7 @@ static const struct pci_device_id mei_me
{MEI_PCI_DEVICE(MEI_DEV_ID_CMP_H_3, MEI_ME_PCH8_ITOUCH_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_ICP_LP, MEI_ME_PCH12_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_ICP_N, MEI_ME_PCH12_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_TGP_LP, MEI_ME_PCH15_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_TGP_H, MEI_ME_PCH15_SPS_CFG)},
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 039/151] mei: hbm: drop hbm responses on early shutdown
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 038/151] mei: me: add Ice Lake-N device id Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 040/151] USB: xhci: dbc: fix tty registration race Greg Kroah-Hartman
` (117 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alexander Usyskin, Tomas Winkler
From: Alexander Usyskin <alexander.usyskin@intel.com>
commit 6d7163f2c49fda5658e43105a96b555c89a4548d upstream.
Drop HBM responses also in the early shutdown phase where
the usual traffic is allowed.
Extend the rule that drop HBM responses received during the shutdown phase
by also in MEI_DEV_POWERING_DOWN state.
This resolves the stall if the driver is stopping in the middle
of the link init or link reset.
Fixes: da3eb47c90d4 ("mei: hbm: drop hbm responses on shutdown")
Fixes: 36edb1407c3c ("mei: allow clients on bus to communicate in remove callback")
Cc: <stable@vger.kernel.org> # v5.12+
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20211013074552.2278419-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/mei/hbm.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -1298,7 +1298,8 @@ int mei_hbm_dispatch(struct mei_device *
if (dev->dev_state != MEI_DEV_INIT_CLIENTS ||
dev->hbm_state != MEI_HBM_STARTING) {
- if (dev->dev_state == MEI_DEV_POWER_DOWN) {
+ if (dev->dev_state == MEI_DEV_POWER_DOWN ||
+ dev->dev_state == MEI_DEV_POWERING_DOWN) {
dev_dbg(dev->dev, "hbm: start: on shutdown, ignoring\n");
return 0;
}
@@ -1381,7 +1382,8 @@ int mei_hbm_dispatch(struct mei_device *
if (dev->dev_state != MEI_DEV_INIT_CLIENTS ||
dev->hbm_state != MEI_HBM_DR_SETUP) {
- if (dev->dev_state == MEI_DEV_POWER_DOWN) {
+ if (dev->dev_state == MEI_DEV_POWER_DOWN ||
+ dev->dev_state == MEI_DEV_POWERING_DOWN) {
dev_dbg(dev->dev, "hbm: dma setup response: on shutdown, ignoring\n");
return 0;
}
@@ -1448,7 +1450,8 @@ int mei_hbm_dispatch(struct mei_device *
if (dev->dev_state != MEI_DEV_INIT_CLIENTS ||
dev->hbm_state != MEI_HBM_CLIENT_PROPERTIES) {
- if (dev->dev_state == MEI_DEV_POWER_DOWN) {
+ if (dev->dev_state == MEI_DEV_POWER_DOWN ||
+ dev->dev_state == MEI_DEV_POWERING_DOWN) {
dev_dbg(dev->dev, "hbm: properties response: on shutdown, ignoring\n");
return 0;
}
@@ -1490,7 +1493,8 @@ int mei_hbm_dispatch(struct mei_device *
if (dev->dev_state != MEI_DEV_INIT_CLIENTS ||
dev->hbm_state != MEI_HBM_ENUM_CLIENTS) {
- if (dev->dev_state == MEI_DEV_POWER_DOWN) {
+ if (dev->dev_state == MEI_DEV_POWER_DOWN ||
+ dev->dev_state == MEI_DEV_POWERING_DOWN) {
dev_dbg(dev->dev, "hbm: enumeration response: on shutdown, ignoring\n");
return 0;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 040/151] USB: xhci: dbc: fix tty registration race
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 039/151] mei: hbm: drop hbm responses on early shutdown Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 041/151] xhci: guard accesses to ep_state in xhci_endpoint_reset() Greg Kroah-Hartman
` (116 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lu Baolu, Johan Hovold, Mathias Nyman
From: Johan Hovold <johan@kernel.org>
commit 880de403777376e50bdf60def359fa50a722006f upstream.
Make sure to allocate resources before registering the tty device to
avoid having a racing open() and write() fail to enable rx or
dereference a NULL pointer when accessing the uninitialised fifo.
Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Cc: stable@vger.kernel.org # 4.16
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-dbgtty.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
--- a/drivers/usb/host/xhci-dbgtty.c
+++ b/drivers/usb/host/xhci-dbgtty.c
@@ -408,40 +408,38 @@ static int xhci_dbc_tty_register_device(
return -EBUSY;
xhci_dbc_tty_init_port(dbc, port);
- tty_dev = tty_port_register_device(&port->port,
- dbc_tty_driver, 0, NULL);
- if (IS_ERR(tty_dev)) {
- ret = PTR_ERR(tty_dev);
- goto register_fail;
- }
ret = kfifo_alloc(&port->write_fifo, DBC_WRITE_BUF_SIZE, GFP_KERNEL);
if (ret)
- goto buf_alloc_fail;
+ goto err_exit_port;
ret = xhci_dbc_alloc_requests(dbc, BULK_IN, &port->read_pool,
dbc_read_complete);
if (ret)
- goto request_fail;
+ goto err_free_fifo;
ret = xhci_dbc_alloc_requests(dbc, BULK_OUT, &port->write_pool,
dbc_write_complete);
if (ret)
- goto request_fail;
+ goto err_free_requests;
+
+ tty_dev = tty_port_register_device(&port->port,
+ dbc_tty_driver, 0, NULL);
+ if (IS_ERR(tty_dev)) {
+ ret = PTR_ERR(tty_dev);
+ goto err_free_requests;
+ }
port->registered = true;
return 0;
-request_fail:
+err_free_requests:
xhci_dbc_free_requests(&port->read_pool);
xhci_dbc_free_requests(&port->write_pool);
+err_free_fifo:
kfifo_free(&port->write_fifo);
-
-buf_alloc_fail:
- tty_unregister_device(dbc_tty_driver, 0);
-
-register_fail:
+err_exit_port:
xhci_dbc_tty_exit_port(port);
dev_err(dbc->dev, "can't register tty port, err %d\n", ret);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 041/151] xhci: guard accesses to ep_state in xhci_endpoint_reset()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 040/151] USB: xhci: dbc: fix tty registration race Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 042/151] xhci: add quirk for host controllers that dont update endpoint DCS Greg Kroah-Hartman
` (115 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jonathan Bell, Mathias Nyman
From: Jonathan Bell <jonathan@raspberrypi.com>
commit a01ba2a3378be85538e0183ae5367c1bc1d5aaf3 upstream.
See https://github.com/raspberrypi/linux/issues/3981
Two read-modify-write cycles on ep->ep_state are not guarded by
xhci->lock. Fix these.
Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset")
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3212,10 +3212,13 @@ static void xhci_endpoint_reset(struct u
return;
/* Bail out if toggle is already being cleared by a endpoint reset */
+ spin_lock_irqsave(&xhci->lock, flags);
if (ep->ep_state & EP_HARD_CLEAR_TOGGLE) {
ep->ep_state &= ~EP_HARD_CLEAR_TOGGLE;
+ spin_unlock_irqrestore(&xhci->lock, flags);
return;
}
+ spin_unlock_irqrestore(&xhci->lock, flags);
/* Only interrupt and bulk ep's use data toggle, USB2 spec 5.5.4-> */
if (usb_endpoint_xfer_control(&host_ep->desc) ||
usb_endpoint_xfer_isoc(&host_ep->desc))
@@ -3301,8 +3304,10 @@ static void xhci_endpoint_reset(struct u
xhci_free_command(xhci, cfg_cmd);
cleanup:
xhci_free_command(xhci, stop_cmd);
+ spin_lock_irqsave(&xhci->lock, flags);
if (ep->ep_state & EP_SOFT_CLEAR_TOGGLE)
ep->ep_state &= ~EP_SOFT_CLEAR_TOGGLE;
+ spin_unlock_irqrestore(&xhci->lock, flags);
}
static int xhci_check_streams_endpoint(struct xhci_hcd *xhci,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 042/151] xhci: add quirk for host controllers that dont update endpoint DCS
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 041/151] xhci: guard accesses to ep_state in xhci_endpoint_reset() Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 043/151] xhci: Fix command ring pointer corruption while aborting a command Greg Kroah-Hartman
` (114 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jonathan Bell, Bjørn Mork,
Mathias Nyman
From: Jonathan Bell <jonathan@raspberrypi.org>
commit 5255660b208aebfdb71d574f3952cf48392f4306 upstream.
Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints
at least, if the xHC halts on a particular TRB due to an error then
the DCS field in the Out Endpoint Context maintained by the hardware
is not updated with the current cycle state.
Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit
from the TRB that the xHC stopped on.
[ bjorn: rebased to v5.14-rc2 ]
Link: https://github.com/raspberrypi/linux/issues/3060
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 4 +++-
drivers/usb/host/xhci-ring.c | 25 ++++++++++++++++++++++++-
drivers/usb/host/xhci.h | 1 +
3 files changed, 28 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -279,8 +279,10 @@ static void xhci_pci_quirks(struct devic
pdev->device == 0x3432)
xhci->quirks |= XHCI_BROKEN_STREAMS;
- if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483)
+ if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) {
xhci->quirks |= XHCI_LPM_SUPPORT;
+ xhci->quirks |= XHCI_EP_CTX_BROKEN_DCS;
+ }
if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -559,8 +559,11 @@ static int xhci_move_dequeue_past_td(str
struct xhci_ring *ep_ring;
struct xhci_command *cmd;
struct xhci_segment *new_seg;
+ struct xhci_segment *halted_seg = NULL;
union xhci_trb *new_deq;
int new_cycle;
+ union xhci_trb *halted_trb;
+ int index = 0;
dma_addr_t addr;
u64 hw_dequeue;
bool cycle_found = false;
@@ -598,7 +601,27 @@ static int xhci_move_dequeue_past_td(str
hw_dequeue = xhci_get_hw_deq(xhci, dev, ep_index, stream_id);
new_seg = ep_ring->deq_seg;
new_deq = ep_ring->dequeue;
- new_cycle = hw_dequeue & 0x1;
+
+ /*
+ * Quirk: xHC write-back of the DCS field in the hardware dequeue
+ * pointer is wrong - use the cycle state of the TRB pointed to by
+ * the dequeue pointer.
+ */
+ if (xhci->quirks & XHCI_EP_CTX_BROKEN_DCS &&
+ !(ep->ep_state & EP_HAS_STREAMS))
+ halted_seg = trb_in_td(xhci, td->start_seg,
+ td->first_trb, td->last_trb,
+ hw_dequeue & ~0xf, false);
+ if (halted_seg) {
+ index = ((dma_addr_t)(hw_dequeue & ~0xf) - halted_seg->dma) /
+ sizeof(*halted_trb);
+ halted_trb = &halted_seg->trbs[index];
+ new_cycle = halted_trb->generic.field[3] & 0x1;
+ xhci_dbg(xhci, "Endpoint DCS = %d TRB index = %d cycle = %d\n",
+ (u8)(hw_dequeue & 0x1), index, new_cycle);
+ } else {
+ new_cycle = hw_dequeue & 0x1;
+ }
/*
* We want to find the pointer, segment and cycle state of the new trb
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1899,6 +1899,7 @@ struct xhci_hcd {
#define XHCI_SG_TRB_CACHE_SIZE_QUIRK BIT_ULL(39)
#define XHCI_NO_SOFT_RETRY BIT_ULL(40)
#define XHCI_BROKEN_D3COLD BIT_ULL(41)
+#define XHCI_EP_CTX_BROKEN_DCS BIT_ULL(42)
unsigned int num_active_eps;
unsigned int limit_active_eps;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 043/151] xhci: Fix command ring pointer corruption while aborting a command
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 042/151] xhci: add quirk for host controllers that dont update endpoint DCS Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 044/151] xhci: Enable trust tx length quirk for Fresco FL11 USB controller Greg Kroah-Hartman
` (113 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pavankumar Kondeti, Mathias Nyman
From: Pavankumar Kondeti <pkondeti@codeaurora.org>
commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream.
The command ring pointer is located at [6:63] bits of the command
ring control register (CRCR). All the control bits like command stop,
abort are located at [0:3] bits. While aborting a command, we read the
CRCR and set the abort bit and write to the CRCR. The read will always
give command ring pointer as all zeros. So we essentially write only
the control bits. Since we split the 64 bit write into two 32 bit writes,
there is a possibility of xHC command ring stopped before the upper
dword (all zeros) is written. If that happens, xHC updates the upper
dword of its internal command ring pointer with all zeros. Next time,
when the command ring is restarted, we see xHC memory access failures.
Fix this issue by only writing to the lower dword of CRCR where all
control bits are located.
Cc: stable@vger.kernel.org
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -366,16 +366,22 @@ static void xhci_handle_stopped_cmd_ring
/* Must be called with xhci->lock held, releases and aquires lock back */
static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags)
{
- u64 temp_64;
+ u32 temp_32;
int ret;
xhci_dbg(xhci, "Abort command ring\n");
reinit_completion(&xhci->cmd_ring_stop_completion);
- temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
- xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
- &xhci->op_regs->cmd_ring);
+ /*
+ * The control bits like command stop, abort are located in lower
+ * dword of the command ring control register. Limit the write
+ * to the lower dword to avoid corrupting the command ring pointer
+ * in case if the command ring is stopped by the time upper dword
+ * is written.
+ */
+ temp_32 = readl(&xhci->op_regs->cmd_ring);
+ writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring);
/* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the
* completion of the Command Abort operation. If CRR is not negated in 5
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 044/151] xhci: Enable trust tx length quirk for Fresco FL11 USB controller
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 043/151] xhci: Fix command ring pointer corruption while aborting a command Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 045/151] cb710: avoid NULL pointer subtraction Greg Kroah-Hartman
` (112 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Nikolay Martynov, Mathias Nyman
From: Nikolay Martynov <mar.kolya@gmail.com>
commit ea0f69d8211963c4b2cc1998b86779a500adb502 upstream.
Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host
Controller.
Before this patch streaming video from USB cam made mouse and keyboard
connected to the same USB bus unusable. Also video was jerky.
With this patch streaming video doesn't have any effect on other
periferals and video is smooth.
Cc: stable@vger.kernel.org
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -30,6 +30,7 @@
#define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73
#define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000
#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1009 0x1009
+#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 0x1100
#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 0x1400
#define PCI_VENDOR_ID_ETRON 0x1b6f
@@ -113,6 +114,7 @@ static void xhci_pci_quirks(struct devic
/* Look for vendor-specific quirks */
if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC &&
(pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK ||
+ pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 ||
pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1400)) {
if (pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK &&
pdev->revision == 0x0) {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 045/151] cb710: avoid NULL pointer subtraction
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 044/151] xhci: Enable trust tx length quirk for Fresco FL11 USB controller Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 046/151] efi/cper: use stack buffer for error record decoding Greg Kroah-Hartman
` (111 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann
From: Arnd Bergmann <arnd@arndb.de>
commit 42641042c10c757fe10cc09088cf3f436cec5007 upstream.
clang-14 complains about an unusual way of converting a pointer to
an integer:
drivers/misc/cb710/sgbuf2.c:50:15: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction]
return ((ptr - NULL) & 3) != 0;
Replace this with a normal cast to uintptr_t.
Fixes: 5f5bac8272be ("mmc: Driver for CB710/720 memory card reader (MMC part)")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210927121408.939246-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/cb710/sgbuf2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/misc/cb710/sgbuf2.c
+++ b/drivers/misc/cb710/sgbuf2.c
@@ -47,7 +47,7 @@ static inline bool needs_unaligned_copy(
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
return false;
#else
- return ((ptr - NULL) & 3) != 0;
+ return ((uintptr_t)ptr & 3) != 0;
#endif
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 046/151] efi/cper: use stack buffer for error record decoding
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 045/151] cb710: avoid NULL pointer subtraction Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 047/151] efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock() Greg Kroah-Hartman
` (110 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Perches, Ard Biesheuvel
From: Ard Biesheuvel <ardb@kernel.org>
commit b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream.
Joe reports that using a statically allocated buffer for converting CPER
error records into human readable text is probably a bad idea. Even
though we are not aware of any actual issues, a stack buffer is clearly
a better choice here anyway, so let's move the buffer into the stack
frames of the two functions that refer to it.
Cc: <stable@vger.kernel.org>
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/cper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -25,8 +25,6 @@
#include <acpi/ghes.h>
#include <ras/ras_event.h>
-static char rcd_decode_str[CPER_REC_LEN];
-
/*
* CPER record ID need to be unique even after reboot, because record
* ID is used as index for ERST storage, while CPER records from
@@ -313,6 +311,7 @@ const char *cper_mem_err_unpack(struct t
struct cper_mem_err_compact *cmem)
{
const char *ret = trace_seq_buffer_ptr(p);
+ char rcd_decode_str[CPER_REC_LEN];
if (cper_mem_err_location(cmem, rcd_decode_str))
trace_seq_printf(p, "%s", rcd_decode_str);
@@ -327,6 +326,7 @@ static void cper_print_mem(const char *p
int len)
{
struct cper_mem_err_compact cmem;
+ char rcd_decode_str[CPER_REC_LEN];
/* Don't trust UEFI 2.1/2.2 structure with bad validation bits */
if (len == sizeof(struct cper_sec_mem_err_old) &&
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 047/151] efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 046/151] efi/cper: use stack buffer for error record decoding Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 048/151] usb: musb: dsps: Fix the probe error path Greg Kroah-Hartman
` (109 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Zhang Jianhua, Ard Biesheuvel
From: Zhang Jianhua <chris.zjh@huawei.com>
commit 38fa3206bf441911258e5001ac8b6738693f8d82 upstream.
While reboot the system by sysrq, the following bug will be occur.
BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90
in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown
CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1
Call trace:
dump_backtrace+0x0/0x1c8
show_stack+0x18/0x28
dump_stack+0xd0/0x110
___might_sleep+0x14c/0x160
__might_sleep+0x74/0x88
down_interruptible+0x40/0x118
virt_efi_reset_system+0x3c/0xd0
efi_reboot+0xd4/0x11c
machine_restart+0x60/0x9c
emergency_restart+0x1c/0x2c
sysrq_handle_reboot+0x1c/0x2c
__handle_sysrq+0xd0/0x194
write_sysrq_trigger+0xbc/0xe4
proc_reg_write+0xd4/0xf0
vfs_write+0xa8/0x148
ksys_write+0x6c/0xd8
__arm64_sys_write+0x18/0x28
el0_svc_common.constprop.3+0xe4/0x16c
do_el0_svc+0x1c/0x2c
el0_svc+0x20/0x30
el0_sync_handler+0x80/0x17c
el0_sync+0x158/0x180
The reason for this problem is that irq has been disabled in
machine_restart() and then it calls down_interruptible() in
virt_efi_reset_system(), which would occur sleep in irq context,
it is dangerous! Commit 99409b935c9a("locking/semaphore: Add
might_sleep() to down_*() family") add might_sleep() in
down_interruptible(), so the bug info is here. down_trylock()
can solve this problem, cause there is no might_sleep.
--------
Cc: <stable@vger.kernel.org>
Signed-off-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/runtime-wrappers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -414,7 +414,7 @@ static void virt_efi_reset_system(int re
unsigned long data_size,
efi_char16_t *data)
{
- if (down_interruptible(&efi_runtime_lock)) {
+ if (down_trylock(&efi_runtime_lock)) {
pr_warn("failed to invoke the reset_system() runtime service:\n"
"could not get exclusive access to the firmware\n");
return;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 048/151] usb: musb: dsps: Fix the probe error path
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 047/151] efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock() Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 049/151] Input: xpad - add support for another USB ID of Nacon GC-100 Greg Kroah-Hartman
` (108 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Miquel Raynal
From: Miquel Raynal <miquel.raynal@bootlin.com>
commit c2115b2b16421d93d4993f3fe4c520e91d6fe801 upstream.
Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after
initializing musb") has inverted the calls to
dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without
updating correctly the error path. dsps_create_musb_pdev() allocates and
registers a new platform device which must be unregistered and freed
with platform_device_unregister(), and this is missing upon
dsps_setup_optional_vbus_irq() error.
While on the master branch it seems not to trigger any issue, I observed
a kernel crash because of a NULL pointer dereference with a v5.10.70
stable kernel where the patch mentioned above was backported. With this
kernel version, -EPROBE_DEFER is returned the first time
dsps_setup_optional_vbus_irq() is called which triggers the probe to
error out without unregistering the platform device. Unfortunately, on
the Beagle Bone Black Wireless, the platform device still living in the
system is being used by the USB Ethernet gadget driver, which during the
boot phase triggers the crash.
My limited knowledge of the musb world prevents me to revert this commit
which was sent to silence a robot warning which, as far as I understand,
does not make sense. The goal of this patch was to prevent an IRQ to
fire before the platform device being registered. I think this cannot
ever happen due to the fact that enabling the interrupts is done by the
->enable() callback of the platform musb device, and this platform
device must be already registered in order for the core or any other
user to use this callback.
Hence, I decided to fix the error path, which might prevent future
errors on mainline kernels while also fixing older ones.
Fixes: 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20211005221631.1529448-1-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/musb_dsps.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -899,11 +899,13 @@ static int dsps_probe(struct platform_de
if (usb_get_dr_mode(&pdev->dev) == USB_DR_MODE_PERIPHERAL) {
ret = dsps_setup_optional_vbus_irq(pdev, glue);
if (ret)
- goto err;
+ goto unregister_pdev;
}
return 0;
+unregister_pdev:
+ platform_device_unregister(glue->musb);
err:
pm_runtime_disable(&pdev->dev);
iounmap(glue->usbss_base);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 049/151] Input: xpad - add support for another USB ID of Nacon GC-100
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 048/151] usb: musb: dsps: Fix the probe error path Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 050/151] USB: serial: qcserial: add EM9191 QDL support Greg Kroah-Hartman
` (107 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Cullen, Dmitry Torokhov
From: Michael Cullen <michael@michaelcullen.name>
commit 3378a07daa6cdd11e042797454c706d1c69f9ca6 upstream.
The Nacon GX100XF is already mapped, but it seems there is a Nacon
GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other
colours exist) with a different USB ID when in XInput mode.
Signed-off-by: Michael Cullen <michael@michaelcullen.name>
Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -334,6 +334,7 @@ static const struct xpad_device {
{ 0x24c6, 0x5b03, "Thrustmaster Ferrari 458 Racing Wheel", 0, XTYPE_XBOX360 },
{ 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 },
{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 },
{ 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX },
{ 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
{ 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
@@ -451,6 +452,7 @@ static const struct usb_device_id xpad_t
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */
XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
+ XPAD_XBOX360_VENDOR(0x3285), /* Nacon GC-100 */
{ }
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 050/151] USB: serial: qcserial: add EM9191 QDL support
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 049/151] Input: xpad - add support for another USB ID of Nacon GC-100 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 051/151] USB: serial: option: add Quectel EC200S-CN module support Greg Kroah-Hartman
` (106 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Aleksander Morgado, Johan Hovold
From: Aleksander Morgado <aleksander@aleksander.es>
commit 11c52d250b34a0862edc29db03fbec23b30db6da upstream.
When the module boots into QDL download mode it exposes the 1199:90d2
ids, which can be mapped to the qcserial driver, and used to run
firmware upgrades (e.g. with the qmi-firmware-update program).
T: Bus=01 Lev=03 Prnt=08 Port=03 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1199 ProdID=90d2 Rev=00.00
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=Sierra Wireless EM9191
S: SerialNumber=8W0382004102A109
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/qcserial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -165,6 +165,7 @@ static const struct usb_device_id id_tab
{DEVICE_SWI(0x1199, 0x907b)}, /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x1199, 0x9090)}, /* Sierra Wireless EM7565 QDL */
{DEVICE_SWI(0x1199, 0x9091)}, /* Sierra Wireless EM7565 */
+ {DEVICE_SWI(0x1199, 0x90d2)}, /* Sierra Wireless EM9191 QDL */
{DEVICE_SWI(0x413c, 0x81a2)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 051/151] USB: serial: option: add Quectel EC200S-CN module support
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 050/151] USB: serial: qcserial: add EM9191 QDL support Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 052/151] USB: serial: option: add Telit LE910Cx composition 0x1204 Greg Kroah-Hartman
` (105 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yu-Tung Chang, Johan Hovold
From: Yu-Tung Chang <mtwget@gmail.com>
commit 2263eb7370060bdb0013bc14e1a7c9bf33617a55 upstream.
Add usb product id of the Quectel EC200S-CN module.
usb-devices output for 0x6002:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=6002 Rev=03.18
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=0000
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
Signed-off-by: Yu-Tung Chang <mtwget@gmail.com>
Link: https://lore.kernel.org/r/20210930021112.330396-1-mtwget@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -251,6 +251,7 @@ static void option_instat_callback(struc
#define QUECTEL_PRODUCT_EP06 0x0306
#define QUECTEL_PRODUCT_EM12 0x0512
#define QUECTEL_PRODUCT_RM500Q 0x0800
+#define QUECTEL_PRODUCT_EC200S_CN 0x6002
#define QUECTEL_PRODUCT_EC200T 0x6026
#define CMOTECH_VENDOR_ID 0x16d8
@@ -1128,6 +1129,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500Q, 0xff, 0, 0) },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500Q, 0xff, 0xff, 0x10),
.driver_info = ZLP },
+ { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200S_CN, 0xff, 0, 0) },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200T, 0xff, 0, 0) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 052/151] USB: serial: option: add Telit LE910Cx composition 0x1204
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 051/151] USB: serial: option: add Quectel EC200S-CN module support Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 053/151] USB: serial: option: add prod. id for Quectel EG91 Greg Kroah-Hartman
` (104 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Daniele Palmas, Johan Hovold
From: Daniele Palmas <dnlplm@gmail.com>
commit f5a8a07edafed8bede17a95ef8940fe3a57a77d5 upstream.
Add the following Telit LE910Cx composition:
0x1204: tty, adb, mbim, tty, tty, tty, tty
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Link: https://lore.kernel.org/r/20211004105655.8515-1-dnlplm@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1229,6 +1229,8 @@ static const struct usb_device_id option
.driver_info = NCTRL(0) | RSVD(1) | RSVD(2) },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1203, 0xff), /* Telit LE910Cx (RNDIS) */
.driver_info = NCTRL(2) | RSVD(3) },
+ { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1204, 0xff), /* Telit LE910Cx (MBIM) */
+ .driver_info = NCTRL(0) | RSVD(1) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910_USBCFG4),
.driver_info = NCTRL(0) | RSVD(1) | RSVD(2) | RSVD(3) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 053/151] USB: serial: option: add prod. id for Quectel EG91
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 052/151] USB: serial: option: add Telit LE910Cx composition 0x1204 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 054/151] misc: fastrpc: Add missing lock before accessing find_vma() Greg Kroah-Hartman
` (103 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tomaz Solc, Johan Hovold
From: Tomaz Solc <tomaz.solc@tablix.org>
commit c184accc4a42c7872dc8e8d0fc97a740dc61fe24 upstream.
Adding support for Quectel EG91 LTE module.
The interface layout is same as for EG95.
usb-devices output:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0191 Rev=03.18
S: Manufacturer=Android
S: Product=Android
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
Interfaces:
0: Diag
1: GNSS
2: AT-command interface/modem
3: Modem
4: QMI
Signed-off-by: Tomaz Solc <tomaz.solc@tablix.org>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -246,6 +246,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_EG91 0x0191
#define QUECTEL_PRODUCT_EG95 0x0195
#define QUECTEL_PRODUCT_BG96 0x0296
#define QUECTEL_PRODUCT_EP06 0x0306
@@ -1112,6 +1113,9 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25, 0xff, 0xff, 0xff),
.driver_info = NUMEP2 },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25, 0xff, 0, 0) },
+ { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG91, 0xff, 0xff, 0xff),
+ .driver_info = NUMEP2 },
+ { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG91, 0xff, 0, 0) },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95, 0xff, 0xff, 0xff),
.driver_info = NUMEP2 },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95, 0xff, 0, 0) },
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 054/151] misc: fastrpc: Add missing lock before accessing find_vma()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 053/151] USB: serial: option: add prod. id for Quectel EG91 Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 055/151] virtio: write back F_VERSION_1 before validate Greg Kroah-Hartman
` (102 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Srinivas Kandagatla
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
commit f9a470db2736b01538ad193c316eb3f26be37d58 upstream.
fastrpc driver is using find_vma() without any protection, as a
result we see below warning due to recent patch 5b78ed24e8ec
("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()")
which added mmap_assert_locked() in find_vma() function.
This bug went un-noticed in previous versions. Fix this issue by adding
required protection while calling find_vma().
CPU: 0 PID: 209746 Comm: benchmark_model Not tainted 5.15.0-rc2-00445-ge14fe2bf817a-dirty #969
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : find_vma+0x64/0xd0
lr : find_vma+0x60/0xd0
sp : ffff8000158ebc40
...
Call trace:
find_vma+0x64/0xd0
fastrpc_internal_invoke+0x570/0xda8
fastrpc_device_ioctl+0x3e0/0x928
__arm64_sys_ioctl+0xac/0xf0
invoke_syscall+0x44/0x100
el0_svc_common.constprop.3+0x70/0xf8
do_el0_svc+0x24/0x88
el0_svc+0x3c/0x138
el0t_64_sync_handler+0x90/0xb8
el0t_64_sync+0x180/0x184
Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP")
Cc: stable@vger.kernel.org
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210922154326.8927-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/fastrpc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -814,10 +814,12 @@ static int fastrpc_get_args(u32 kernel,
rpra[i].pv = (u64) ctx->args[i].ptr;
pages[i].addr = ctx->maps[i]->phys;
+ mmap_read_lock(current->mm);
vma = find_vma(current->mm, ctx->args[i].ptr);
if (vma)
pages[i].addr += ctx->args[i].ptr -
vma->vm_start;
+ mmap_read_unlock(current->mm);
pg_start = (ctx->args[i].ptr & PAGE_MASK) >> PAGE_SHIFT;
pg_end = ((ctx->args[i].ptr + len - 1) & PAGE_MASK) >>
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 055/151] virtio: write back F_VERSION_1 before validate
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 054/151] misc: fastrpc: Add missing lock before accessing find_vma() Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 056/151] EDAC/armada-xp: Fix output of uncorrectable error counter Greg Kroah-Hartman
` (101 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Halil Pasic, markver, Cornelia Huck,
Michael S. Tsirkin
From: Halil Pasic <pasic@linux.ibm.com>
commit 2f9a174f918e29608564c7a4e8329893ab604fb4 upstream.
The virtio specification virtio-v1.1-cs01 states: "Transitional devices
MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
been acknowledged by the driver." This is exactly what QEMU as of 6.1
has done relying solely on VIRTIO_F_VERSION_1 for detecting that.
However, the specification also says: "... the driver MAY read (but MUST
NOT write) the device-specific configuration fields to check that it can
support the device ..." before setting FEATURES_OK.
In that case, any transitional device relying solely on
VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in
legacy format. In particular, this implies that it is in big endian
format for big endian guests. This naturally confuses the driver which
expects little endian in the modern mode.
It is probably a good idea to amend the spec to clarify that
VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation
is complete. Before validate callback existed, config space was only
read after FEATURES_OK. However, we already have two regressions, so
let's address this here as well.
The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and
the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when
virtio 1.0 is used on both sides. The latter renders virtio-blk unusable
with DASD backing, because things simply don't work with the default.
See Fixes tags for relevant commits.
For QEMU, we can work around the issue by writing out the feature bits
with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features
config op for this. This isn't enough to address all vhost devices since
these do not get the features until FEATURES_OK, however it looks like
the affected devices actually never handled the endianness for legacy
mode correctly, so at least that's not a regression.
No devices except virtio net and virtio blk seem to be affected.
Long term the right thing to do is to fix the hypervisors.
Cc: <stable@vger.kernel.org> #v4.11
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space")
Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range")
Reported-by: markver@us.ibm.com
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Link: https://lore.kernel.org/r/20211011053921.1198936-1-pasic@linux.ibm.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/virtio/virtio.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -238,6 +238,17 @@ static int virtio_dev_probe(struct devic
driver_features_legacy = driver_features;
}
+ /*
+ * Some devices detect legacy solely via F_VERSION_1. Write
+ * F_VERSION_1 to force LE config space accesses before FEATURES_OK for
+ * these when needed.
+ */
+ if (drv->validate && !virtio_legacy_is_little_endian()
+ && device_features & BIT_ULL(VIRTIO_F_VERSION_1)) {
+ dev->features = BIT_ULL(VIRTIO_F_VERSION_1);
+ dev->config->finalize_features(dev);
+ }
+
if (device_features & (1ULL << VIRTIO_F_VERSION_1))
dev->features = driver_features & device_features;
else
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 056/151] EDAC/armada-xp: Fix output of uncorrectable error counter
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 055/151] virtio: write back F_VERSION_1 before validate Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 057/151] nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells Greg Kroah-Hartman
` (100 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans Potsch, Borislav Petkov
From: Hans Potsch <hans.potsch@nokia.com>
commit d9b7748ffc45250b4d7bcf22404383229bc495f5 upstream.
The number of correctable errors is displayed as uncorrectable
errors because the "SBE" error count is passed to both calls of
edac_mc_handle_error().
Pass the correct uncorrectable error count to the second
edac_mc_handle_error() call when logging uncorrectable errors.
[ bp: Massage commit message. ]
Fixes: 7f6998a41257 ("ARM: 8888/1: EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC")
Signed-off-by: Hans Potsch <hans.potsch@nokia.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20211006121332.58788-1-hans.potsch@nokia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/edac/armada_xp_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -178,7 +178,7 @@ static void axp_mc_check(struct mem_ctl_
"details unavailable (multiple errors)");
if (cnt_dbe)
edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
- cnt_sbe, /* error count */
+ cnt_dbe, /* error count */
0, 0, 0, /* pfn, offset, syndrome */
-1, -1, -1, /* top, mid, low layer */
mci->ctl_name,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 057/151] nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 056/151] EDAC/armada-xp: Fix output of uncorrectable error counter Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 058/151] virtio-blk: remove unneeded "likely" statements Greg Kroah-Hartman
` (99 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Stephen Boyd,
Srinivas Kandagatla
From: Stephen Boyd <swboyd@chromium.org>
commit 5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream.
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
subtract one from that making a large number that is then shifted more than the
number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
shift exponent 64 is too large for 64-bit type 'unsigned long'
CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0x0/0x170
show_stack+0x24/0x30
dump_stack_lvl+0x64/0x7c
dump_stack+0x18/0x38
ubsan_epilogue+0x10/0x54
__ubsan_handle_shift_out_of_bounds+0x180/0x194
__nvmem_cell_read+0x1ec/0x21c
nvmem_cell_read+0x58/0x94
nvmem_cell_read_variable_common+0x4c/0xb0
nvmem_cell_read_variable_le_u32+0x40/0x100
a6xx_gpu_init+0x170/0x2f4
adreno_bind+0x174/0x284
component_bind_all+0xf0/0x264
msm_drm_bind+0x1d8/0x7a0
try_to_bring_up_master+0x164/0x1ac
__component_add+0xbc/0x13c
component_add+0x20/0x2c
dp_display_probe+0x340/0x384
platform_probe+0xc0/0x100
really_probe+0x110/0x304
__driver_probe_device+0xb8/0x120
driver_probe_device+0x4c/0xfc
__device_attach_driver+0xb0/0x128
bus_for_each_drv+0x90/0xdc
__device_attach+0xc8/0x174
device_initial_probe+0x20/0x2c
bus_probe_device+0x40/0xa4
deferred_probe_work_func+0x7c/0xb8
process_one_work+0x128/0x21c
process_scheduled_works+0x40/0x54
worker_thread+0x1ec/0x2a8
kthread+0x138/0x158
ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.
Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers")
Cc: Douglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvmem/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1383,7 +1383,8 @@ static void nvmem_shift_read_buffer_in_p
*p-- = 0;
/* clear msb bits if any leftover in the last byte */
- *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
+ if (cell->nbits % BITS_PER_BYTE)
+ *p &= GENMASK((cell->nbits % BITS_PER_BYTE) - 1, 0);
}
static int __nvmem_cell_read(struct nvmem_device *nvmem,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 058/151] virtio-blk: remove unneeded "likely" statements
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 057/151] nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 059/151] Revert "virtio-blk: Add validation for block size in config space" Greg Kroah-Hartman
` (98 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Hajnoczi, Max Gurtovoy,
Michael S. Tsirkin, Chaitanya Kulkarni, Christoph Hellwig
From: Max Gurtovoy <mgurtovoy@nvidia.com>
commit 6105d1fe6f4c24ce8c13e2e6568b16b76e04983d upstream.
Usually we use "likely/unlikely" to optimize the fast path. Remove
redundant "likely/unlikely" statements in the control path to simplify
the code and make it easier to read.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Link: https://lore.kernel.org/r/20210905085717.7427-1-mgurtovoy@nvidia.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/virtio_blk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -765,7 +765,7 @@ static int virtblk_probe(struct virtio_d
goto out_free_vblk;
/* Default queue sizing is to fill the ring. */
- if (likely(!virtblk_queue_depth)) {
+ if (!virtblk_queue_depth) {
queue_depth = vblk->vqs[0].vq->num_free;
/* ... but without indirect descs, we use 2 descs per req */
if (!virtio_has_feature(vdev, VIRTIO_RING_F_INDIRECT_DESC))
@@ -839,7 +839,7 @@ static int virtblk_probe(struct virtio_d
else
blk_size = queue_logical_block_size(q);
- if (unlikely(blk_size < SECTOR_SIZE || blk_size > PAGE_SIZE)) {
+ if (blk_size < SECTOR_SIZE || blk_size > PAGE_SIZE) {
dev_err(&vdev->dev,
"block size is changed unexpectedly, now is %u\n",
blk_size);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 059/151] Revert "virtio-blk: Add validation for block size in config space"
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 058/151] virtio-blk: remove unneeded "likely" statements Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-18 13:23 ` [PATCH 5.14 060/151] KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() Greg Kroah-Hartman
` (97 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Xie Yongji, Michael S. Tsirkin
From: Michael S. Tsirkin <mst@redhat.com>
commit ff63198850f33eab54b2da6905380fd4d4fc0739 upstream.
It turns out that access to config space before completing the feature
negotiation is broken for big endian guests at least with QEMU hosts up
to 6.1 inclusive. This affects any device that accesses config space in
the validate callback: at the moment that is virtio-net with
VIRTIO_NET_F_MTU but since 82e89ea077b9 ("virtio-blk: Add validation for
block size in config space") that also started affecting virtio-blk with
VIRTIO_BLK_F_BLK_SIZE. Further, unlike VIRTIO_NET_F_MTU which is off by
default on QEMU, VIRTIO_BLK_F_BLK_SIZE is on by default, which resulted
in lots of people not being able to boot VMs on BE.
The spec is very clear that what we are doing is legal so QEMU needs to
be fixed, but given it's been broken for so many years and no one
noticed, we need to give QEMU a bit more time before applying this.
Further, this patch is incomplete (does not check blk size is a power
of two) and it duplicates the logic from nbd.
Revert for now, and we'll reapply a cleaner logic in the next release.
Cc: stable@vger.kernel.org
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space")
Cc: Xie Yongji <xieyongji@bytedance.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/virtio_blk.c | 39 ++++++---------------------------------
1 file changed, 6 insertions(+), 33 deletions(-)
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -692,28 +692,6 @@ static const struct blk_mq_ops virtio_mq
static unsigned int virtblk_queue_depth;
module_param_named(queue_depth, virtblk_queue_depth, uint, 0444);
-static int virtblk_validate(struct virtio_device *vdev)
-{
- u32 blk_size;
-
- if (!vdev->config->get) {
- dev_err(&vdev->dev, "%s failure: config access disabled\n",
- __func__);
- return -EINVAL;
- }
-
- if (!virtio_has_feature(vdev, VIRTIO_BLK_F_BLK_SIZE))
- return 0;
-
- blk_size = virtio_cread32(vdev,
- offsetof(struct virtio_blk_config, blk_size));
-
- if (blk_size < SECTOR_SIZE || blk_size > PAGE_SIZE)
- __virtio_clear_bit(vdev, VIRTIO_BLK_F_BLK_SIZE);
-
- return 0;
-}
-
static int virtblk_probe(struct virtio_device *vdev)
{
struct virtio_blk *vblk;
@@ -725,6 +703,12 @@ static int virtblk_probe(struct virtio_d
u8 physical_block_exp, alignment_offset;
unsigned int queue_depth;
+ if (!vdev->config->get) {
+ dev_err(&vdev->dev, "%s failure: config access disabled\n",
+ __func__);
+ return -EINVAL;
+ }
+
err = ida_simple_get(&vd_index_ida, 0, minor_to_index(1 << MINORBITS),
GFP_KERNEL);
if (err < 0)
@@ -839,14 +823,6 @@ static int virtblk_probe(struct virtio_d
else
blk_size = queue_logical_block_size(q);
- if (blk_size < SECTOR_SIZE || blk_size > PAGE_SIZE) {
- dev_err(&vdev->dev,
- "block size is changed unexpectedly, now is %u\n",
- blk_size);
- err = -EINVAL;
- goto err_cleanup_disk;
- }
-
/* Use topology information if available */
err = virtio_cread_feature(vdev, VIRTIO_BLK_F_TOPOLOGY,
struct virtio_blk_config, physical_block_exp,
@@ -905,8 +881,6 @@ static int virtblk_probe(struct virtio_d
device_add_disk(&vdev->dev, vblk->disk, virtblk_attr_groups);
return 0;
-err_cleanup_disk:
- blk_cleanup_disk(vblk->disk);
out_free_tags:
blk_mq_free_tag_set(&vblk->tag_set);
out_free_vq:
@@ -1009,7 +983,6 @@ static struct virtio_driver virtio_blk =
.driver.name = KBUILD_MODNAME,
.driver.owner = THIS_MODULE,
.id_table = id_table,
- .validate = virtblk_validate,
.probe = virtblk_probe,
.remove = virtblk_remove,
.config_changed = virtblk_config_changed,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 060/151] KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 059/151] Revert "virtio-blk: Add validation for block size in config space" Greg Kroah-Hartman
@ 2021-10-18 13:23 ` Greg Kroah-Hartman
2021-10-19 10:55 ` Michael Ellerman
2021-10-18 13:24 ` [PATCH 5.14 061/151] KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if it went to guest Greg Kroah-Hartman
` (96 subsequent siblings)
156 siblings, 1 reply; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Ellerman
From: Michael Ellerman <mpe@ellerman.id.au>
commit 9b4416c5095c20e110c82ae602c254099b83b72f upstream.
In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in
C") kvm_start_guest() became idle_kvm_start_guest(). The old code
allocated a stack frame on the emergency stack, but didn't use the
frame to store anything, and also didn't store anything in its caller's
frame.
idle_kvm_start_guest() on the other hand is written more like a normal C
function, it creates a frame on entry, and also stores CR/LR into its
callers frame (per the ABI). The problem is that there is no caller
frame on the emergency stack.
The emergency stack for a given CPU is allocated with:
paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE;
So emergency_sp actually points to the first address above the emergency
stack allocation for a given CPU, we must not store above it without
first decrementing it to create a frame. This is different to the
regular kernel stack, paca->kstack, which is initialised to point at an
initial frame that is ready to use.
idle_kvm_start_guest() stores the backchain, CR and LR all of which
write outside the allocation for the emergency stack. It then creates a
stack frame and saves the non-volatile registers. Unfortunately the
frame it creates is not large enough to fit the non-volatiles, and so
the saving of the non-volatile registers also writes outside the
emergency stack allocation.
The end result is that we corrupt whatever is at 0-24 bytes, and 112-248
bytes above the emergency stack allocation.
In practice this has gone unnoticed because the memory immediately above
the emergency stack happens to be used for other stack allocations,
either another CPUs mc_emergency_sp or an IRQ stack. See the order of
calls to irqstack_early_init() and emergency_stack_init().
The low addresses of another stack are the top of that stack, and so are
only used if that stack is under extreme pressue, which essentially
never happens in practice - and if it did there's a high likelyhood we'd
crash due to that stack overflowing.
Still, we shouldn't be corrupting someone else's stack, and it is purely
luck that we aren't corrupting something else.
To fix it we save CR/LR into the caller's frame using the existing r1 on
entry, we then create a SWITCH_FRAME_SIZE frame (which has space for
pt_regs) on the emergency stack with the backchain pointing to the
existing stack, and then finally we switch to the new frame on the
emergency stack.
Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211015133929.832061-1-mpe@ellerman.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -255,13 +255,15 @@ kvm_novcpu_exit:
* r3 contains the SRR1 wakeup value, SRR1 is trashed.
*/
_GLOBAL(idle_kvm_start_guest)
- ld r4,PACAEMERGSP(r13)
mfcr r5
mflr r0
- std r1,0(r4)
- std r5,8(r4)
- std r0,16(r4)
- subi r1,r4,STACK_FRAME_OVERHEAD
+ std r5, 8(r1) // Save CR in caller's frame
+ std r0, 16(r1) // Save LR in caller's frame
+ // Create frame on emergency stack
+ ld r4, PACAEMERGSP(r13)
+ stdu r1, -SWITCH_FRAME_SIZE(r4)
+ // Switch to new frame on emergency stack
+ mr r1, r4
SAVE_NVGPRS(r1)
/*
@@ -395,10 +397,9 @@ kvm_no_guest:
/* set up r3 for return */
mfspr r3,SPRN_SRR1
REST_NVGPRS(r1)
- addi r1, r1, STACK_FRAME_OVERHEAD
- ld r0, 16(r1)
- ld r5, 8(r1)
- ld r1, 0(r1)
+ ld r1, 0(r1) // Switch back to caller stack
+ ld r0, 16(r1) // Reload LR
+ ld r5, 8(r1) // Reload CR
mtlr r0
mtcr r5
blr
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 060/151] KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()
2021-10-18 13:23 ` [PATCH 5.14 060/151] KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() Greg Kroah-Hartman
@ 2021-10-19 10:55 ` Michael Ellerman
2021-10-19 11:22 ` Greg Kroah-Hartman
0 siblings, 1 reply; 167+ messages in thread
From: Michael Ellerman @ 2021-10-19 10:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel; +Cc: Greg Kroah-Hartman, stable
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> From: Michael Ellerman <mpe@ellerman.id.au>
>
> commit 9b4416c5095c20e110c82ae602c254099b83b72f upstream.
>
> In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in
> C") kvm_start_guest() became idle_kvm_start_guest(). The old code
> allocated a stack frame on the emergency stack, but didn't use the
> frame to store anything, and also didn't store anything in its caller's
> frame.
Please drop this and the next patch.
cheers
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 060/151] KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()
2021-10-19 10:55 ` Michael Ellerman
@ 2021-10-19 11:22 ` Greg Kroah-Hartman
0 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-19 11:22 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, stable
On Tue, Oct 19, 2021 at 09:55:04PM +1100, Michael Ellerman wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> > From: Michael Ellerman <mpe@ellerman.id.au>
> >
> > commit 9b4416c5095c20e110c82ae602c254099b83b72f upstream.
> >
> > In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in
> > C") kvm_start_guest() became idle_kvm_start_guest(). The old code
> > allocated a stack frame on the emergency stack, but didn't use the
> > frame to store anything, and also didn't store anything in its caller's
> > frame.
>
> Please drop this and the next patch.
All now dropped from all 3 queues, thanks!
greg k-h
^ permalink raw reply [flat|nested] 167+ messages in thread
* [PATCH 5.14 061/151] KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if it went to guest
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2021-10-18 13:23 ` [PATCH 5.14 060/151] KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 062/151] x86/fpu: Mask out the invalid MXCSR bits properly Greg Kroah-Hartman
` (95 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Ellerman
From: Michael Ellerman <mpe@ellerman.id.au>
commit cdeb5d7d890e14f3b70e8087e745c4a6a7d9f337 upstream.
We call idle_kvm_start_guest() from power7_offline() if the thread has
been requested to enter KVM. We pass it the SRR1 value that was returned
from power7_idle_insn() which tells us what sort of wakeup we're
processing.
Depending on the SRR1 value we pass in, the KVM code might enter the
guest, or it might return to us to do some host action if the wakeup
requires it.
If idle_kvm_start_guest() is able to handle the wakeup, and enter the
guest it is supposed to indicate that by returning a zero SRR1 value to
us.
That was the behaviour prior to commit 10d91611f426 ("powerpc/64s:
Reimplement book3s idle code in C"), however in that commit the
handling of SRR1 was reworked, and the zeroing behaviour was lost.
Returning from idle_kvm_start_guest() without zeroing the SRR1 value can
confuse the host offline code, causing the guest to crash and other
weirdness.
Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211015133929.832061-2-mpe@ellerman.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -264,6 +264,7 @@ _GLOBAL(idle_kvm_start_guest)
stdu r1, -SWITCH_FRAME_SIZE(r4)
// Switch to new frame on emergency stack
mr r1, r4
+ std r3, 32(r1) // Save SRR1 wakeup value
SAVE_NVGPRS(r1)
/*
@@ -315,6 +316,10 @@ kvm_unsplit_wakeup:
kvm_secondary_got_guest:
+ // About to go to guest, clear saved SRR1
+ li r0, 0
+ std r0, 32(r1)
+
/* Set HSTATE_DSCR(r13) to something sensible */
ld r6, PACA_DSCR_DEFAULT(r13)
std r6, HSTATE_DSCR(r13)
@@ -394,8 +399,8 @@ kvm_no_guest:
mfspr r4, SPRN_LPCR
rlwimi r4, r3, 0, LPCR_PECE0 | LPCR_PECE1
mtspr SPRN_LPCR, r4
- /* set up r3 for return */
- mfspr r3,SPRN_SRR1
+ // Return SRR1 wakeup value, or 0 if we went into the guest
+ ld r3, 32(r1)
REST_NVGPRS(r1)
ld r1, 0(r1) // Switch back to caller stack
ld r0, 16(r1) // Reload LR
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 062/151] x86/fpu: Mask out the invalid MXCSR bits properly
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (60 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 061/151] KVM: PPC: Book3S HV: Make idle_kvm_start_guest() return 0 if it went to guest Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 063/151] x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically Greg Kroah-Hartman
` (94 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Borislav Petkov,
Ville Syrjälä,
Ser Olmy
From: Borislav Petkov <bp@suse.de>
commit b2381acd3fd9bacd2c63f53b2c610c89959b31cc upstream.
This is a fix for the fix (yeah, /facepalm).
The correct mask to use is not the negation of the MXCSR_MASK but the
actual mask which contains the supported bits in the MXCSR register.
Reported and debugged by Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: d298b03506d3 ("x86/fpu: Restore the masking out of reserved MXCSR bits")
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ser Olmy <ser.olmy@protonmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/YWgYIYXLriayyezv@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/fpu/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -385,7 +385,7 @@ static int __fpu_restore_sig(void __user
return -EINVAL;
} else {
/* Mask invalid bits out for historical reasons (broken hardware). */
- fpu->state.fxsave.mxcsr &= ~mxcsr_feature_mask;
+ fpu->state.fxsave.mxcsr &= mxcsr_feature_mask;
}
/* Enforce XFEATURE_MASK_FPSSE when XSAVE is enabled */
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 063/151] x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (61 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 062/151] x86/fpu: Mask out the invalid MXCSR bits properly Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 064/151] powerpc/xive: Discard disabled interrupts in get_irqchip_state() Greg Kroah-Hartman
` (93 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul Menzel, Borislav Petkov,
Alex Deucher, Tom Lendacky
From: Borislav Petkov <bp@suse.de>
commit 711885906b5c2df90746a51f4cd674f1ab9fbb1d upstream.
This Kconfig option was added initially so that memory encryption is
enabled by default on machines which support it.
However, devices which have DMA masks that are less than the bit
position of the encryption bit, aka C-bit, require the use of an IOMMU
or the use of SWIOTLB.
If the IOMMU is disabled or in passthrough mode, the kernel would switch
to SWIOTLB bounce-buffering for those transfers.
In order to avoid that,
2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active")
disables the default IOMMU passthrough mode so that devices for which the
default 256K DMA is insufficient, can use the IOMMU instead.
However 2, there are cases where the IOMMU is disabled in the BIOS, etc.
(think the usual hardware folk "oops, I dropped the ball there" cases) or a
driver doesn't properly use the DMA APIs or a device has a firmware or
hardware bug, e.g.:
ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active")
However 3, in the above GPU use case, there are APIs like Vulkan and
some OpenGL/OpenCL extensions which are under the assumption that
user-allocated memory can be passed in to the kernel driver and both the
GPU and CPU can do coherent and concurrent access to the same memory.
That cannot work with SWIOTLB bounce buffers, of course.
So, in order for those devices to function, drop the "default y" for the
SME by default active option so that users who want to have SME enabled,
will need to either enable it in their config or use "mem_encrypt=on" on
the kernel command line.
[ tlendacky: Generalize commit message. ]
Fixes: 7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/Kconfig | 1 -
1 file changed, 1 deletion(-)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1520,7 +1520,6 @@ config AMD_MEM_ENCRYPT
config AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
bool "Activate AMD Secure Memory Encryption (SME) by default"
- default y
depends on AMD_MEM_ENCRYPT
help
Say yes to have system memory encrypted by default if running on
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 064/151] powerpc/xive: Discard disabled interrupts in get_irqchip_state()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (62 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 063/151] x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 065/151] iio: adc: aspeed: set driver data when adc probe Greg Kroah-Hartman
` (92 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Cédric Le Goater, seeteena,
Michael Ellerman
From: Cédric Le Goater <clg@kaod.org>
commit 6f779e1d359b8d5801f677c1d49dcfa10bf95674 upstream.
When an interrupt is passed through, the KVM XIVE device calls the
set_vcpu_affinity() handler which raises the P bit to mask the
interrupt and to catch any in-flight interrupts while routing the
interrupt to the guest.
On the guest side, drivers (like some Intels) can request at probe
time some MSIs and call synchronize_irq() to check that there are no
in flight interrupts. This will call the XIVE get_irqchip_state()
handler which will always return true as the interrupt P bit has been
set on the host side and lock the CPU in an infinite loop.
Fix that by discarding disabled interrupts in get_irqchip_state().
Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race")
Cc: stable@vger.kernel.org #v5.4+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Tested-by: seeteena <s1seetee@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211011070203.99726-1-clg@kaod.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/sysdev/xive/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -961,7 +961,8 @@ static int xive_get_irqchip_state(struct
* interrupt to be inactive in that case.
*/
*state = (pq != XIVE_ESB_INVALID) && !xd->stale_p &&
- (xd->saved_p || !!(pq & XIVE_ESB_VAL_P));
+ (xd->saved_p || (!!(pq & XIVE_ESB_VAL_P) &&
+ !irqd_irq_disabled(data)));
return 0;
default:
return -EINVAL;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 065/151] iio: adc: aspeed: set driver data when adc probe.
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (63 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 064/151] powerpc/xive: Discard disabled interrupts in get_irqchip_state() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 066/151] drivers: bus: simple-pm-bus: Add support for probing simple bus only devices Greg Kroah-Hartman
` (91 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Billy Tsai, Stable, Jonathan Cameron
From: Billy Tsai <billy_tsai@aspeedtech.com>
commit eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream.
Fix the issue when adc remove will get the null driver data.
Fixed: commit 573803234e72 ("iio: Aspeed ADC")
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/aspeed_adc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/aspeed_adc.c
+++ b/drivers/iio/adc/aspeed_adc.c
@@ -183,6 +183,7 @@ static int aspeed_adc_probe(struct platf
data = iio_priv(indio_dev);
data->dev = &pdev->dev;
+ platform_set_drvdata(pdev, indio_dev);
data->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(data->base))
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 066/151] drivers: bus: simple-pm-bus: Add support for probing simple bus only devices
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (64 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 065/151] iio: adc: aspeed: set driver data when adc probe Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 067/151] driver core: Reject pointless SYNC_STATE_ONLY device links Greg Kroah-Hartman
` (90 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Herring, Saravana Kannan,
Ulf Hansson, Geert Uytterhoeven, Damien Le Moal
From: Saravana Kannan <saravanak@google.com>
commit 98e96cf80045a383fcc47c58dd4e87b3ae587b3e upstream.
fw_devlink could end up creating device links for bus only devices.
However, bus only devices don't get probed and can block probe() or
sync_state() [1] call backs of other devices. To avoid this, probe these
devices using the simple-pm-bus driver.
However, there are instances of devices that are not simple buses (they get
probed by their specific drivers) that also list the "simple-bus" (or other
bus only compatible strings) in their compatible property to automatically
populate their child devices. We still want these devices to get probed by
their specific drivers. So, we make sure this driver only probes devices
that are only buses.
[1] - https://lore.kernel.org/lkml/CAPDyKFo9Bxremkb1dDrr4OcXSpE0keVze94Cm=zrkOVxHHxBmQ@mail.gmail.com/
Fixes: c442a0d18744 ("driver core: Set fw_devlink to "permissive" behavior by default")
Cc: stable <stable@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Tested-by: Saravana Kannan <saravanak@google.com>
Tested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210929000735.585237-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/bus/simple-pm-bus.c | 42 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -13,11 +13,36 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
-
static int simple_pm_bus_probe(struct platform_device *pdev)
{
- const struct of_dev_auxdata *lookup = dev_get_platdata(&pdev->dev);
- struct device_node *np = pdev->dev.of_node;
+ const struct device *dev = &pdev->dev;
+ const struct of_dev_auxdata *lookup = dev_get_platdata(dev);
+ struct device_node *np = dev->of_node;
+ const struct of_device_id *match;
+
+ /*
+ * Allow user to use driver_override to bind this driver to a
+ * transparent bus device which has a different compatible string
+ * that's not listed in simple_pm_bus_of_match. We don't want to do any
+ * of the simple-pm-bus tasks for these devices, so return early.
+ */
+ if (pdev->driver_override)
+ return 0;
+
+ match = of_match_device(dev->driver->of_match_table, dev);
+ /*
+ * These are transparent bus devices (not simple-pm-bus matches) that
+ * have their child nodes populated automatically. So, don't need to
+ * do anything more. We only match with the device if this driver is
+ * the most specific match because we don't want to incorrectly bind to
+ * a device that has a more specific driver.
+ */
+ if (match && match->data) {
+ if (of_property_match_string(np, "compatible", match->compatible) == 0)
+ return 0;
+ else
+ return -ENODEV;
+ }
dev_dbg(&pdev->dev, "%s\n", __func__);
@@ -31,14 +56,25 @@ static int simple_pm_bus_probe(struct pl
static int simple_pm_bus_remove(struct platform_device *pdev)
{
+ const void *data = of_device_get_match_data(&pdev->dev);
+
+ if (pdev->driver_override || data)
+ return 0;
+
dev_dbg(&pdev->dev, "%s\n", __func__);
pm_runtime_disable(&pdev->dev);
return 0;
}
+#define ONLY_BUS ((void *) 1) /* Match if the device is only a bus. */
+
static const struct of_device_id simple_pm_bus_of_match[] = {
{ .compatible = "simple-pm-bus", },
+ { .compatible = "simple-bus", .data = ONLY_BUS },
+ { .compatible = "simple-mfd", .data = ONLY_BUS },
+ { .compatible = "isa", .data = ONLY_BUS },
+ { .compatible = "arm,amba-bus", .data = ONLY_BUS },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 067/151] driver core: Reject pointless SYNC_STATE_ONLY device links
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (65 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 066/151] drivers: bus: simple-pm-bus: Add support for probing simple bus only devices Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 068/151] iio: adc: ad7192: Add IRQ flag Greg Kroah-Hartman
` (89 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ulf Hansson, Rafael J. Wysocki,
Saravana Kannan
From: Saravana Kannan <saravanak@google.com>
commit f729a592adb6760013c3e48622a5bf256b992452 upstream.
SYNC_STATE_ONLY device links intentionally allow cycles because cyclic
sync_state() dependencies are valid and necessary.
However a SYNC_STATE_ONLY device link where the consumer and the supplier
are the same device is pointless because the device link would be deleted
as soon as the device probes (because it's also the consumer) and won't
affect when the sync_state() callback is called. It's a waste of CPU cycles
and memory to create this device link. So reject any attempts to create
such a device link.
Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Cc: stable <stable@vger.kernel.org>
Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210929190549.860541-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -675,7 +675,8 @@ struct device_link *device_link_add(stru
{
struct device_link *link;
- if (!consumer || !supplier || flags & ~DL_ADD_VALID_FLAGS ||
+ if (!consumer || !supplier || consumer == supplier ||
+ flags & ~DL_ADD_VALID_FLAGS ||
(flags & DL_FLAG_STATELESS && flags & DL_MANAGED_LINK_FLAGS) ||
(flags & DL_FLAG_SYNC_STATE_ONLY &&
(flags & ~DL_FLAG_INFERRED) != DL_FLAG_SYNC_STATE_ONLY) ||
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 068/151] iio: adc: ad7192: Add IRQ flag
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (66 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 067/151] driver core: Reject pointless SYNC_STATE_ONLY device links Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 069/151] iio: adc: ad7780: Fix " Greg Kroah-Hartman
` (88 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexandru Tachici, Stable, Jonathan Cameron
From: Alexandru Tachici <alexandru.tachici@analog.com>
commit 89a86da5cb8e0ee153111fb68a719d31582c206b upstream.
IRQ type in ad_sigma_delta_info struct was missing.
In Sigma-Delta devices the SDO line is also used as an interrupt.
Leaving IRQ on level instead of falling might trigger a sample read
when the IRQ is enabled, as the SDO line is already low. Not sure
if SDO line will always immediately go high in ad_sd_buffer_postenable
before the IRQ is enabled.
Also the datasheet seem to explicitly say the falling edge of the SDO
should be used as an interrupt:
>From the AD7192 datasheet: "The DOUT/RDY falling edge can be used
as an interrupt to a processor,"
Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags")
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210906065630.16325-2-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/ad7192.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/ad7192.c
+++ b/drivers/iio/adc/ad7192.c
@@ -293,6 +293,7 @@ static const struct ad_sigma_delta_info
.has_registers = true,
.addr_shift = 3,
.read_mask = BIT(6),
+ .irq_flags = IRQF_TRIGGER_FALLING,
};
static const struct ad_sd_calib_data ad7192_calib_arr[8] = {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 069/151] iio: adc: ad7780: Fix IRQ flag
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (67 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 068/151] iio: adc: ad7192: Add IRQ flag Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 070/151] iio: adc: ad7793: " Greg Kroah-Hartman
` (87 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexandru Tachici, Stable, Jonathan Cameron
From: Alexandru Tachici <alexandru.tachici@analog.com>
commit e081102f3077aa716974ccebec97003c890d5641 upstream.
Correct IRQ flag here is falling.
In Sigma-Delta devices the SDO line is also used as an interrupt.
Leaving IRQ on level instead of falling might trigger a sample read
when the IRQ is enabled, as the SDO line is already low. Not sure
if SDO line will always immediately go high in ad_sd_buffer_postenable
before the IRQ is enabled.
Also the datasheet seem to explicitly say the falling edge of the SDO
should be used as an interrupt:
>From the AD7780 datasheet: " The DOUT/Figure 22 RDY falling edge
can be used as an interrupt to a processor"
Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags")
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210906065630.16325-3-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/ad7780.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/adc/ad7780.c
+++ b/drivers/iio/adc/ad7780.c
@@ -203,7 +203,7 @@ static const struct ad_sigma_delta_info
.set_mode = ad7780_set_mode,
.postprocess_sample = ad7780_postprocess_sample,
.has_registers = false,
- .irq_flags = IRQF_TRIGGER_LOW,
+ .irq_flags = IRQF_TRIGGER_FALLING,
};
#define _AD7780_CHANNEL(_bits, _wordsize, _mask_all) \
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 070/151] iio: adc: ad7793: Fix IRQ flag
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (68 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 069/151] iio: adc: ad7780: Fix " Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 071/151] iio: adis16480: fix devices that do not support sleep mode Greg Kroah-Hartman
` (86 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexandru Tachici, Stable, Jonathan Cameron
From: Alexandru Tachici <alexandru.tachici@analog.com>
commit 1a913270e57a8e7f1e3789802f1f64e6d0654626 upstream.
In Sigma-Delta devices the SDO line is also used as an interrupt.
Leaving IRQ on level instead of falling might trigger a sample read
when the IRQ is enabled, as the SDO line is already low. Not sure
if SDO line will always immediately go high in ad_sd_buffer_postenable
before the IRQ is enabled.
Also the datasheet seem to explicitly say the falling edge of the SDO
should be used as an interrupt:
>From the AD7793 datasheet: " The DOUT/RDY falling edge can be
used as an interrupt to a processor"
Fixes: da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags")
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210906065630.16325-4-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/ad7793.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/adc/ad7793.c
+++ b/drivers/iio/adc/ad7793.c
@@ -206,7 +206,7 @@ static const struct ad_sigma_delta_info
.has_registers = true,
.addr_shift = 3,
.read_mask = BIT(6),
- .irq_flags = IRQF_TRIGGER_LOW,
+ .irq_flags = IRQF_TRIGGER_FALLING,
};
static const struct ad_sd_calib_data ad7793_calib_arr[6] = {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 071/151] iio: adis16480: fix devices that do not support sleep mode
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (69 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 070/151] iio: adc: ad7793: " Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 072/151] iio: adc128s052: Fix the error handling path of adc128_probe() Greg Kroah-Hartman
` (85 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nuno Sá, Stable, Jonathan Cameron
From: Nuno Sá <nuno.sa@analog.com>
commit ea1945c2f72d7bd253e2ebaa97cdd8d9ffcde076 upstream.
Not all devices supported by this driver support being put to sleep
mode. For those devices, when calling 'adis16480_stop_device()' on the
unbind path, we where actually writing in the SYNC_SCALE register.
Fixes: 80cbc848c4fa0 ("iio: imu: adis16480: Add support for ADIS16490")
Fixes: 82e7a1b250170 ("iio: imu: adis16480: Add support for ADIS1649x family of devices")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210903141423.517028-6-nuno.sa@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/imu/adis16480.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis16480.c
+++ b/drivers/iio/imu/adis16480.c
@@ -144,6 +144,7 @@ struct adis16480_chip_info {
unsigned int max_dec_rate;
const unsigned int *filter_freqs;
bool has_pps_clk_mode;
+ bool has_sleep_cnt;
const struct adis_data adis_data;
};
@@ -939,6 +940,7 @@ static const struct adis16480_chip_info
.temp_scale = 5650, /* 5.65 milli degree Celsius */
.int_clk = 2460000,
.max_dec_rate = 2048,
+ .has_sleep_cnt = true,
.filter_freqs = adis16480_def_filter_freqs,
.adis_data = ADIS16480_DATA(16375, &adis16485_timeouts, 0),
},
@@ -952,6 +954,7 @@ static const struct adis16480_chip_info
.temp_scale = 5650, /* 5.65 milli degree Celsius */
.int_clk = 2460000,
.max_dec_rate = 2048,
+ .has_sleep_cnt = true,
.filter_freqs = adis16480_def_filter_freqs,
.adis_data = ADIS16480_DATA(16480, &adis16480_timeouts, 0),
},
@@ -965,6 +968,7 @@ static const struct adis16480_chip_info
.temp_scale = 5650, /* 5.65 milli degree Celsius */
.int_clk = 2460000,
.max_dec_rate = 2048,
+ .has_sleep_cnt = true,
.filter_freqs = adis16480_def_filter_freqs,
.adis_data = ADIS16480_DATA(16485, &adis16485_timeouts, 0),
},
@@ -978,6 +982,7 @@ static const struct adis16480_chip_info
.temp_scale = 5650, /* 5.65 milli degree Celsius */
.int_clk = 2460000,
.max_dec_rate = 2048,
+ .has_sleep_cnt = true,
.filter_freqs = adis16480_def_filter_freqs,
.adis_data = ADIS16480_DATA(16488, &adis16485_timeouts, 0),
},
@@ -1425,9 +1430,12 @@ static int adis16480_probe(struct spi_de
if (ret)
return ret;
- ret = devm_add_action_or_reset(&spi->dev, adis16480_stop, indio_dev);
- if (ret)
- return ret;
+ if (st->chip_info->has_sleep_cnt) {
+ ret = devm_add_action_or_reset(&spi->dev, adis16480_stop,
+ indio_dev);
+ if (ret)
+ return ret;
+ }
ret = adis16480_config_irq_pin(spi->dev.of_node, st);
if (ret)
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 072/151] iio: adc128s052: Fix the error handling path of adc128_probe()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (70 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 071/151] iio: adis16480: fix devices that do not support sleep mode Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 073/151] iio: adc: max1027: Fix wrong shift with 12-bit devices Greg Kroah-Hartman
` (84 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christophe JAILLET,
Alexandru Ardelean, Stable, Jonathan Cameron
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
commit bbcf40816b547b3c37af49168950491d20d81ce1 upstream.
A successful 'regulator_enable()' call should be balanced by a
corresponding 'regulator_disable()' call in the error handling path of the
probe, as already done in the remove function.
Update the error handling path accordingly.
Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/ti-adc128s052.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/iio/adc/ti-adc128s052.c
+++ b/drivers/iio/adc/ti-adc128s052.c
@@ -171,7 +171,13 @@ static int adc128_probe(struct spi_devic
mutex_init(&adc->lock);
ret = iio_device_register(indio_dev);
+ if (ret)
+ goto err_disable_regulator;
+ return 0;
+
+err_disable_regulator:
+ regulator_disable(adc->reg);
return ret;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 073/151] iio: adc: max1027: Fix wrong shift with 12-bit devices
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (71 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 072/151] iio: adc128s052: Fix the error handling path of adc128_probe() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 074/151] iio: adis16475: fix deadlock on frequency set Greg Kroah-Hartman
` (83 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Miquel Raynal, Nuno Sá,
Jonathan Cameron
From: Miquel Raynal <miquel.raynal@bootlin.com>
commit 732ae19ee8f58ecaf30cbc1bbbda5cbee6a45043 upstream.
10-bit devices must shift the value twice.
This is not needed anymore on 12-bit devices.
Fixes: ae47d009b508 ("iio: adc: max1027: Introduce 12-bit devices support")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210818111139.330636-2-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/max1027.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/adc/max1027.c
+++ b/drivers/iio/adc/max1027.c
@@ -103,7 +103,7 @@ MODULE_DEVICE_TABLE(of, max1027_adc_dt_i
.sign = 'u', \
.realbits = depth, \
.storagebits = 16, \
- .shift = 2, \
+ .shift = (depth == 10) ? 2 : 0, \
.endianness = IIO_BE, \
}, \
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 074/151] iio: adis16475: fix deadlock on frequency set
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (72 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 073/151] iio: adc: max1027: Fix wrong shift with 12-bit devices Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 075/151] iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED Greg Kroah-Hartman
` (82 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nuno Sá,
Alexandru Ardelean, Stable, Jonathan Cameron
From: Nuno Sá <nuno.sa@analog.com>
commit 9da1b86865ab4376408c58cd9fec332c8bdb5c73 upstream.
With commit 39c024b51b560
("iio: adis16475: improve sync scale mode handling"), two deadlocks were
introduced:
1) The call to 'adis_write_reg_16()' was not changed to it's unlocked
version.
2) The lock was not being released on the success path of the function.
This change fixes both these issues.
Fixes: 39c024b51b560 ("iio: adis16475: improve sync scale mode handling")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210920090047.74903-1-nuno.sa@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/imu/adis16475.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/iio/imu/adis16475.c
+++ b/drivers/iio/imu/adis16475.c
@@ -353,10 +353,11 @@ static int adis16475_set_freq(struct adi
if (dec > st->info->max_dec)
dec = st->info->max_dec;
- ret = adis_write_reg_16(&st->adis, ADIS16475_REG_DEC_RATE, dec);
+ ret = __adis_write_reg_16(&st->adis, ADIS16475_REG_DEC_RATE, dec);
if (ret)
goto error;
+ adis_dev_unlock(&st->adis);
/*
* If decimation is used, then gyro and accel data will have meaningful
* bits on the LSB registers. This info is used on the trigger handler.
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 075/151] iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (73 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 074/151] iio: adis16475: fix deadlock on frequency set Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 076/151] iio: light: opt3001: Fixed timeout error when 0 lux Greg Kroah-Hartman
` (81 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hui Liu, Stable, Jonathan Cameron
From: Hui Liu <hui.liu@mediatek.com>
commit c2980c64c7fd4585d684574c92d1624d44961edd upstream.
The previous driver does't apply the necessary scaling to take the
voltage range into account.
We change readback value from raw data to input voltage to fix case
IIO_CHAN_INFO_PROCESSED.
Fixes: ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.")
Signed-off-by: Hui Liu <hui.liu@mediatek.com>
Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/mt6577_auxadc.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -82,6 +82,10 @@ static const struct iio_chan_spec mt6577
MT6577_AUXADC_CHANNEL(15),
};
+/* For Voltage calculation */
+#define VOLTAGE_FULL_RANGE 1500 /* VA voltage */
+#define AUXADC_PRECISE 4096 /* 12 bits */
+
static int mt_auxadc_get_cali_data(int rawdata, bool enable_cali)
{
return rawdata;
@@ -191,6 +195,10 @@ static int mt6577_auxadc_read_raw(struct
}
if (adc_dev->dev_comp->sample_data_cali)
*val = mt_auxadc_get_cali_data(*val, true);
+
+ /* Convert adc raw data to voltage: 0 - 1500 mV */
+ *val = *val * VOLTAGE_FULL_RANGE / AUXADC_PRECISE;
+
return IIO_VAL_INT;
default:
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 076/151] iio: light: opt3001: Fixed timeout error when 0 lux
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (74 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 075/151] iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 077/151] iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed Greg Kroah-Hartman
` (80 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Valek - 2N, Stable, Jonathan Cameron
From: Jiri Valek - 2N <valek@2n.cz>
commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream.
Reading from sensor returned timeout error under
zero light conditions.
Signed-off-by: Jiri Valek - 2N <valek@2n.cz>
Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ")
Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/light/opt3001.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/iio/light/opt3001.c
+++ b/drivers/iio/light/opt3001.c
@@ -276,6 +276,8 @@ static int opt3001_get_lux(struct opt300
ret = wait_event_timeout(opt->result_ready_queue,
opt->result_ready,
msecs_to_jiffies(OPT3001_RESULT_READY_LONG));
+ if (ret == 0)
+ return -ETIMEDOUT;
} else {
/* Sleep for result ready time */
timeout = (opt->int_time == OPT3001_INT_TIME_SHORT) ?
@@ -312,9 +314,7 @@ err:
/* Disallow IRQ to access the device while lock is active */
opt->ok_to_ignore_lock = false;
- if (ret == 0)
- return -ETIMEDOUT;
- else if (ret < 0)
+ if (ret < 0)
return ret;
if (opt->use_irq) {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 077/151] iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (75 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 076/151] iio: light: opt3001: Fixed timeout error when 0 lux Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 078/151] iio: adc: max1027: Fix the number of max1X31 channels Greg Kroah-Hartman
` (79 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Nyekjaer, Stable, Jonathan Cameron
From: Sean Nyekjaer <sean@geanix.com>
commit 9033c7a357481fb5bcc1737bafa4aec572dca5c6 upstream.
fxls8962af_fifo_flush() will return the samples flushed.
So return IRQ_NONE only if an error is returned.
Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling")
Signed-off-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20210817124336.1672169-1-sean@geanix.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/accel/fxls8962af-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/accel/fxls8962af-core.c
+++ b/drivers/iio/accel/fxls8962af-core.c
@@ -738,7 +738,7 @@ static irqreturn_t fxls8962af_interrupt(
if (reg & FXLS8962AF_INT_STATUS_SRC_BUF) {
ret = fxls8962af_fifo_flush(indio_dev);
- if (ret)
+ if (ret < 0)
return IRQ_NONE;
return IRQ_HANDLED;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 078/151] iio: adc: max1027: Fix the number of max1X31 channels
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (76 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 077/151] iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 079/151] iio: ssp_sensors: add more range checking in ssp_parse_dataframe() Greg Kroah-Hartman
` (78 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Miquel Raynal, Nuno Sá,
Jonathan Cameron
From: Miquel Raynal <miquel.raynal@bootlin.com>
commit f0cb5fed37ab37f6a6c5463c5fd39b58a45670c8 upstream.
The macro MAX1X29_CHANNELS() already calls MAX1X27_CHANNELS().
Calling MAX1X27_CHANNELS() before MAX1X29_CHANNELS() in the definition
of MAX1X31_CHANNELS() declares the first 8 channels twice. So drop this
extra call from the MAX1X31 channels list definition.
Fixes: 7af5257d8427 ("iio: adc: max1027: Prepare the introduction of different resolutions")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210818111139.330636-3-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/max1027.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/iio/adc/max1027.c
+++ b/drivers/iio/adc/max1027.c
@@ -142,7 +142,6 @@ MODULE_DEVICE_TABLE(of, max1027_adc_dt_i
MAX1027_V_CHAN(11, depth)
#define MAX1X31_CHANNELS(depth) \
- MAX1X27_CHANNELS(depth), \
MAX1X29_CHANNELS(depth), \
MAX1027_V_CHAN(12, depth), \
MAX1027_V_CHAN(13, depth), \
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 079/151] iio: ssp_sensors: add more range checking in ssp_parse_dataframe()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (77 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 078/151] iio: adc: max1027: Fix the number of max1X31 channels Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 080/151] iio: ssp_sensors: fix error code in ssp_print_mcu_debug() Greg Kroah-Hartman
` (77 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Stable, Jonathan Cameron
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream.
The "idx" is validated at the start of the loop but it gets incremented
during the iteration so it needs to be checked again.
Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210909091336.GA26312@kili
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/common/ssp_sensors/ssp_spi.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/iio/common/ssp_sensors/ssp_spi.c
+++ b/drivers/iio/common/ssp_sensors/ssp_spi.c
@@ -273,6 +273,8 @@ static int ssp_parse_dataframe(struct ss
for (idx = 0; idx < len;) {
switch (dataframe[idx++]) {
case SSP_MSG2AP_INST_BYPASS_DATA:
+ if (idx >= len)
+ return -EPROTO;
sd = dataframe[idx++];
if (sd < 0 || sd >= SSP_SENSOR_MAX) {
dev_err(SSP_DEV,
@@ -282,10 +284,13 @@ static int ssp_parse_dataframe(struct ss
if (indio_devs[sd]) {
spd = iio_priv(indio_devs[sd]);
- if (spd->process_data)
+ if (spd->process_data) {
+ if (idx >= len)
+ return -EPROTO;
spd->process_data(indio_devs[sd],
&dataframe[idx],
data->timestamp);
+ }
} else {
dev_err(SSP_DEV, "no client for frame\n");
}
@@ -293,6 +298,8 @@ static int ssp_parse_dataframe(struct ss
idx += ssp_offset_map[sd];
break;
case SSP_MSG2AP_INST_DEBUG_DATA:
+ if (idx >= len)
+ return -EPROTO;
sd = ssp_print_mcu_debug(dataframe, &idx, len);
if (sd) {
dev_err(SSP_DEV,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 080/151] iio: ssp_sensors: fix error code in ssp_print_mcu_debug()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (78 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 079/151] iio: ssp_sensors: add more range checking in ssp_parse_dataframe() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 081/151] Input: resistive-adc-touch - fix division by zero error on z1 == 0 Greg Kroah-Hartman
` (76 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jonathan Cameron, Dan Carpenter,
Stable, Jonathan Cameron
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 4170d3dd1467e9d78cb9af374b19357dc324b328 upstream.
The ssp_print_mcu_debug() function should return negative error codes on
error. Returning "length" is meaningless. This change does not affect
runtime because the callers only care about zero/non-zero.
Reported-by: Jonathan Cameron <jic23@kernel.org>
Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210914105333.GA11657@kili
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/common/ssp_sensors/ssp_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/common/ssp_sensors/ssp_spi.c
+++ b/drivers/iio/common/ssp_sensors/ssp_spi.c
@@ -137,7 +137,7 @@ static int ssp_print_mcu_debug(char *dat
if (length > received_len - *data_index || length <= 0) {
ssp_dbg("[SSP]: MSG From MCU-invalid debug length(%d/%d)\n",
length, received_len);
- return length ? length : -EPROTO;
+ return -EPROTO;
}
ssp_dbg("[SSP]: MSG From MCU - %s\n", &data_frame[*data_index]);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 081/151] Input: resistive-adc-touch - fix division by zero error on z1 == 0
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (79 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 080/151] iio: ssp_sensors: fix error code in ssp_print_mcu_debug() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 082/151] eeprom: 93xx46: Add SPI device ID table Greg Kroah-Hartman
` (75 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Oleksij Rempel, Dmitry Torokhov
From: Oleksij Rempel <o.rempel@pengutronix.de>
commit fe0a7e3d012738b0034b3c97ddb0e8bc0a3ff0e6 upstream.
For proper pressure calculation we need at least x and z1 to be non
zero. Even worse, in case z1 we may run in to division by zero
error.
Fixes: 60b7db914ddd ("Input: resistive-adc-touch - rework mapping of channels")
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20211007095727.29579-1-o.rempel@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/resistive-adc-touch.c | 29 +++++++++++++-----------
1 file changed, 16 insertions(+), 13 deletions(-)
--- a/drivers/input/touchscreen/resistive-adc-touch.c
+++ b/drivers/input/touchscreen/resistive-adc-touch.c
@@ -71,19 +71,22 @@ static int grts_cb(const void *data, voi
unsigned int z2 = touch_info[st->ch_map[GRTS_CH_Z2]];
unsigned int Rt;
- Rt = z2;
- Rt -= z1;
- Rt *= st->x_plate_ohms;
- Rt = DIV_ROUND_CLOSEST(Rt, 16);
- Rt *= x;
- Rt /= z1;
- Rt = DIV_ROUND_CLOSEST(Rt, 256);
- /*
- * On increased pressure the resistance (Rt) is decreasing
- * so, convert values to make it looks as real pressure.
- */
- if (Rt < GRTS_DEFAULT_PRESSURE_MAX)
- press = GRTS_DEFAULT_PRESSURE_MAX - Rt;
+ if (likely(x && z1)) {
+ Rt = z2;
+ Rt -= z1;
+ Rt *= st->x_plate_ohms;
+ Rt = DIV_ROUND_CLOSEST(Rt, 16);
+ Rt *= x;
+ Rt /= z1;
+ Rt = DIV_ROUND_CLOSEST(Rt, 256);
+ /*
+ * On increased pressure the resistance (Rt) is
+ * decreasing so, convert values to make it looks as
+ * real pressure.
+ */
+ if (Rt < GRTS_DEFAULT_PRESSURE_MAX)
+ press = GRTS_DEFAULT_PRESSURE_MAX - Rt;
+ }
}
if ((!x && !y) || (st->pressure && (press < st->pressure_min))) {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 082/151] eeprom: 93xx46: Add SPI device ID table
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (80 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 081/151] Input: resistive-adc-touch - fix division by zero error on z1 == 0 Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 083/151] eeprom: 93xx46: fix MODULE_DEVICE_TABLE Greg Kroah-Hartman
` (74 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mark Brown
From: Mark Brown <broonie@kernel.org>
commit 137879f7ff23c635d2c6b2e43f4b39e2d305c3e2 upstream.
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI device ID table.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210922184048.34770-1-broonie@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/eeprom/eeprom_93xx46.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -406,6 +406,23 @@ static const struct of_device_id eeprom_
};
MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+static const struct spi_device_id eeprom_93xx46_spi_ids[] = {
+ { .name = "eeprom-93xx46",
+ .driver_data = (kernel_ulong_t)&at93c46_data, },
+ { .name = "at93c46",
+ .driver_data = (kernel_ulong_t)&at93c46_data, },
+ { .name = "at93c46d",
+ .driver_data = (kernel_ulong_t)&atmel_at93c46d_data, },
+ { .name = "at93c56",
+ .driver_data = (kernel_ulong_t)&at93c56_data, },
+ { .name = "at93c66",
+ .driver_data = (kernel_ulong_t)&at93c66_data, },
+ { .name = "93lc46b",
+ .driver_data = (kernel_ulong_t)µchip_93lc46b_data, },
+ {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
static int eeprom_93xx46_probe_dt(struct spi_device *spi)
{
const struct of_device_id *of_id =
@@ -555,6 +572,7 @@ static struct spi_driver eeprom_93xx46_d
},
.probe = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
+ .id_table = eeprom_93xx46_spi_ids,
};
module_spi_driver(eeprom_93xx46_driver);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 083/151] eeprom: 93xx46: fix MODULE_DEVICE_TABLE
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (81 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 082/151] eeprom: 93xx46: Add SPI device ID table Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 084/151] eeprom: at25: Add SPI ID table Greg Kroah-Hartman
` (73 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann
From: Arnd Bergmann <arnd@arndb.de>
commit f42752729e2068a92c7d8b576d0dbbc9c1464149 upstream.
The newly added SPI device ID table does not work because the
entry is incorrectly copied from the OF device table.
During build testing, this shows as a compile failure when building
it as a loadable module:
drivers/misc/eeprom/eeprom_93xx46.c:424:1: error: redefinition of '__mod_of__eeprom_93xx46_of_table_device_table'
MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
Change the entry to refer to the correct symbol.
Fixes: 137879f7ff23 ("eeprom: 93xx46: Add SPI device ID table")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211014153730.3821376-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/eeprom/eeprom_93xx46.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -421,7 +421,7 @@ static const struct spi_device_id eeprom
.driver_data = (kernel_ulong_t)µchip_93lc46b_data, },
{}
};
-MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+MODULE_DEVICE_TABLE(spi, eeprom_93xx46_spi_ids);
static int eeprom_93xx46_probe_dt(struct spi_device *spi)
{
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 084/151] eeprom: at25: Add SPI ID table
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (82 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 083/151] eeprom: 93xx46: fix MODULE_DEVICE_TABLE Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 085/151] fpga: ice40-spi: Add SPI device " Greg Kroah-Hartman
` (72 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mark Brown
From: Mark Brown <broonie@kernel.org>
commit 9e2cd444909b3c93f5cc83463d12291e3e0f990b upstream.
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210923172453.4921-1-broonie@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/eeprom/at25.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/misc/eeprom/at25.c
+++ b/drivers/misc/eeprom/at25.c
@@ -366,6 +366,13 @@ static const struct of_device_id at25_of
};
MODULE_DEVICE_TABLE(of, at25_of_match);
+static const struct spi_device_id at25_spi_ids[] = {
+ { .name = "at25",},
+ { .name = "fm25",},
+ { }
+};
+MODULE_DEVICE_TABLE(spi, at25_spi_ids);
+
static int at25_probe(struct spi_device *spi)
{
struct at25_data *at25 = NULL;
@@ -491,6 +498,7 @@ static struct spi_driver at25_driver = {
.dev_groups = sernum_groups,
},
.probe = at25_probe,
+ .id_table = at25_spi_ids,
};
module_spi_driver(at25_driver);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 085/151] fpga: ice40-spi: Add SPI device ID table
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (83 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 084/151] eeprom: at25: Add SPI ID table Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 086/151] iio: dac: ti-dac5571: fix an error code in probe() Greg Kroah-Hartman
` (71 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mark Brown, Moritz Fischer
From: Mark Brown <broonie@kernel.org>
commit 2a2a79577ddae7d5314b2f57ca86b44d794403d5 upstream.
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI ID table.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/fpga/ice40-spi.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/fpga/ice40-spi.c
+++ b/drivers/fpga/ice40-spi.c
@@ -192,12 +192,19 @@ static const struct of_device_id ice40_f
};
MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
+static const struct spi_device_id ice40_fpga_spi_ids[] = {
+ { .name = "ice40-fpga-mgr", },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, ice40_fpga_spi_ids);
+
static struct spi_driver ice40_fpga_driver = {
.probe = ice40_fpga_probe,
.driver = {
.name = "ice40spi",
.of_match_table = of_match_ptr(ice40_fpga_of_match),
},
+ .id_table = ice40_fpga_spi_ids,
};
module_spi_driver(ice40_fpga_driver);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 086/151] iio: dac: ti-dac5571: fix an error code in probe()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (84 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 085/151] fpga: ice40-spi: Add SPI device " Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 087/151] tracing: Fix missing osnoise tracer on max_latency Greg Kroah-Hartman
` (70 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Jonathan Cameron
From: Dan Carpenter <dan.carpenter@oracle.com>
commit f7a28df7db84eb3410e9eca37832efa5aed93338 upstream.
If we have an unexpected number of channels then return -EINVAL instead
of returning success.
Fixes: df38a4a72a3b ("iio: dac: add TI DAC5571 family support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210816183954.GB2068@kili
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/dac/ti-dac5571.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/dac/ti-dac5571.c
+++ b/drivers/iio/dac/ti-dac5571.c
@@ -350,6 +350,7 @@ static int dac5571_probe(struct i2c_clie
data->dac5571_pwrdwn = dac5571_pwrdwn_quad;
break;
default:
+ ret = -EINVAL;
goto err;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 087/151] tracing: Fix missing osnoise tracer on max_latency
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (85 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 086/151] iio: dac: ti-dac5571: fix an error code in probe() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 088/151] tee: optee: Fix missing devices unregister during optee_remove Greg Kroah-Hartman
` (69 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Bristot de Oliveira,
Steven Rostedt, Daniel Bristot de Oliveira, Jackie Liu,
Randy Dunlap
From: Jackie Liu <liuyun01@kylinos.cn>
commit 424b650f35c77defbb3cbd6e5221d3697af42250 upstream.
The compiler warns when the data are actually unused:
kernel/trace/trace.c:1712:13: error: ‘trace_create_maxlat_file’ defined but not used [-Werror=unused-function]
1712 | static void trace_create_maxlat_file(struct trace_array *tr,
| ^~~~~~~~~~~~~~~~~~~~~~~~
[Why]
CONFIG_HWLAT_TRACER=n, CONFIG_TRACER_MAX_TRACE=n, CONFIG_OSNOISE_TRACER=y
gcc report warns.
[How]
Now trace_create_maxlat_file will only take effect when
CONFIG_HWLAT_TRACER=y or CONFIG_TRACER_MAX_TRACE=y. In fact, after
adding osnoise trace, it also needs to take effect.
Link: https://lore.kernel.org/all/c1d9e328-ad7c-920b-6c24-9e1598a6421c@infradead.org/
Link: https://lkml.kernel.org/r/20210922025122.3268022-1-liu.yun@linux.dev
Fixes: bce29ac9ce0b ("trace: Add osnoise tracer")
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/trace.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1744,16 +1744,15 @@ void latency_fsnotify(struct trace_array
irq_work_queue(&tr->fsnotify_irqwork);
}
-/*
- * (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
- * defined(CONFIG_FSNOTIFY)
- */
-#else
+#elif defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+ || defined(CONFIG_OSNOISE_TRACER)
#define trace_create_maxlat_file(tr, d_tracer) \
trace_create_file("tracing_max_latency", 0644, d_tracer, \
&tr->max_latency, &tracing_max_lat_fops)
+#else
+#define trace_create_maxlat_file(tr, d_tracer) do { } while (0)
#endif
#ifdef CONFIG_TRACER_MAX_TRACE
@@ -9457,9 +9456,7 @@ init_tracer_tracefs(struct trace_array *
create_trace_options_dir(tr);
-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)
trace_create_maxlat_file(tr, d_tracer);
-#endif
if (ftrace_create_function_files(tr, d_tracer))
MEM_FAIL(1, "Could not allocate function filter files");
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 088/151] tee: optee: Fix missing devices unregister during optee_remove
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (86 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 087/151] tracing: Fix missing osnoise tracer on max_latency Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 089/151] ARM: dts: bcm2711-rpi-4-b: Fix usbs unit address Greg Kroah-Hartman
` (68 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sudeep Holla, Sumit Garg, Jens Wiklander
From: Sumit Garg <sumit.garg@linaro.org>
commit 7f565d0ead264329749c0da488de9c8dfa2f18ce upstream.
When OP-TEE driver is built as a module, OP-TEE client devices
registered on TEE bus during probe should be unregistered during
optee_remove. So implement optee_unregister_devices() accordingly.
Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support")
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tee/optee/core.c | 3 +++
drivers/tee/optee/device.c | 22 ++++++++++++++++++++++
drivers/tee/optee/optee_private.h | 1 +
3 files changed, 26 insertions(+)
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -585,6 +585,9 @@ static int optee_remove(struct platform_
{
struct optee *optee = platform_get_drvdata(pdev);
+ /* Unregister OP-TEE specific client devices on TEE bus */
+ optee_unregister_devices();
+
/*
* Ask OP-TEE to free all cached shared memory objects to decrease
* reference counters and also avoid wild pointers in secure world
--- a/drivers/tee/optee/device.c
+++ b/drivers/tee/optee/device.c
@@ -53,6 +53,13 @@ static int get_devices(struct tee_contex
return 0;
}
+static void optee_release_device(struct device *dev)
+{
+ struct tee_client_device *optee_device = to_tee_client_device(dev);
+
+ kfree(optee_device);
+}
+
static int optee_register_device(const uuid_t *device_uuid)
{
struct tee_client_device *optee_device = NULL;
@@ -63,6 +70,7 @@ static int optee_register_device(const u
return -ENOMEM;
optee_device->dev.bus = &tee_bus_type;
+ optee_device->dev.release = optee_release_device;
if (dev_set_name(&optee_device->dev, "optee-ta-%pUb", device_uuid)) {
kfree(optee_device);
return -ENOMEM;
@@ -154,3 +162,17 @@ int optee_enumerate_devices(u32 func)
{
return __optee_enumerate_devices(func);
}
+
+static int __optee_unregister_device(struct device *dev, void *data)
+{
+ if (!strncmp(dev_name(dev), "optee-ta", strlen("optee-ta")))
+ device_unregister(dev);
+
+ return 0;
+}
+
+void optee_unregister_devices(void)
+{
+ bus_for_each_dev(&tee_bus_type, NULL, NULL,
+ __optee_unregister_device);
+}
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -184,6 +184,7 @@ void optee_fill_pages_list(u64 *dst, str
#define PTA_CMD_GET_DEVICES 0x0
#define PTA_CMD_GET_DEVICES_SUPP 0x1
int optee_enumerate_devices(u32 func);
+void optee_unregister_devices(void);
/*
* Small helpers
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 089/151] ARM: dts: bcm2711-rpi-4-b: Fix usbs unit address
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (87 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 088/151] tee: optee: Fix missing devices unregister during optee_remove Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 090/151] ARM: dts: bcm283x: Fix VEC address for BCM2711 Greg Kroah-Hartman
` (67 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Herring, Nicolas Saenz Julienne
From: Nicolas Saenz Julienne <nsaenz@kernel.org>
commit 3f32472854614d6f53b09b4812372dba9fc5c7de upstream.
The unit address is supposed to represent '<device>,<function>'. Which
are both 0 for RPi4b's XHCI controller. On top of that although
OpenFirmware states bus number goes in the high part of the last reg
parameter, FDT doesn't seem to care for it[1], so remove it.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210830103909.323356-1-nsaenzju@redhat.com/#24414633
Fixes: 258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node")
Suggested-by: Rob Herring <robh@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210831125843.1233488-2-nsaenzju@redhat.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -224,8 +224,8 @@
reg = <0 0 0 0 0>;
- usb@1,0 {
- reg = <0x10000 0 0 0 0>;
+ usb@0,0 {
+ reg = <0 0 0 0 0>;
resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
};
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 090/151] ARM: dts: bcm283x: Fix VEC address for BCM2711
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (88 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 089/151] ARM: dts: bcm2711-rpi-4-b: Fix usbs unit address Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 091/151] ARM: dts: bcm2711: fix MDIO #address- and #size-cells Greg Kroah-Hartman
` (66 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mateusz Kwiatkowski, Stefan Wahren,
Nicolas Saenz Julienne
From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
commit 9287e91e9019d4bc1018adb55ab791ae672e0b14 upstream.
The VEC has a different address (0x7ec13000) on the BCM2711 (used in
e.g. Raspberry Pi 4) compared to BCM283x (e.g. Pi 3 and earlier). This
was erroneously not taken account for.
Definition of the VEC in the devicetrees had to be moved from
bcm283x.dtsi to bcm2711.dtsi and bcm2835-common.dtsi to allow for this
differentiation.
Fixes: 7894bdc6228f ("ARM: boot: dts: bcm2711: Add BCM2711 VEC compatible")
Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/1626980528-3835-1-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm2711.dtsi | 8 ++++++++
arch/arm/boot/dts/bcm2835-common.dtsi | 8 ++++++++
arch/arm/boot/dts/bcm283x.dtsi | 8 --------
3 files changed, 16 insertions(+), 8 deletions(-)
--- a/arch/arm/boot/dts/bcm2711.dtsi
+++ b/arch/arm/boot/dts/bcm2711.dtsi
@@ -300,6 +300,14 @@
status = "disabled";
};
+ vec: vec@7ec13000 {
+ compatible = "brcm,bcm2711-vec";
+ reg = <0x7ec13000 0x1000>;
+ clocks = <&clocks BCM2835_CLOCK_VEC>;
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
dvp: clock@7ef00000 {
compatible = "brcm,brcm2711-dvp";
reg = <0x7ef00000 0x10>;
--- a/arch/arm/boot/dts/bcm2835-common.dtsi
+++ b/arch/arm/boot/dts/bcm2835-common.dtsi
@@ -106,6 +106,14 @@
status = "okay";
};
+ vec: vec@7e806000 {
+ compatible = "brcm,bcm2835-vec";
+ reg = <0x7e806000 0x1000>;
+ clocks = <&clocks BCM2835_CLOCK_VEC>;
+ interrupts = <2 27>;
+ status = "disabled";
+ };
+
pixelvalve@7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
reg = <0x7e807000 0x100>;
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -464,14 +464,6 @@
status = "disabled";
};
- vec: vec@7e806000 {
- compatible = "brcm,bcm2835-vec";
- reg = <0x7e806000 0x1000>;
- clocks = <&clocks BCM2835_CLOCK_VEC>;
- interrupts = <2 27>;
- status = "disabled";
- };
-
usb: usb@7e980000 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e980000 0x10000>;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 091/151] ARM: dts: bcm2711: fix MDIO #address- and #size-cells
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (89 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 090/151] ARM: dts: bcm283x: Fix VEC address for BCM2711 Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 092/151] firmware: arm_ffa: Fix __ffa_devices_unregister Greg Kroah-Hartman
` (65 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Wahren, Nicolas Saenz Julienne
From: Stefan Wahren <stefan.wahren@i2se.com>
commit 2faff6737a8a684b077264f0aed131526c99eec4 upstream.
The values of #address-cells and #size-cells are swapped. Fix this
and avoid the following DT schema warnings for mdio@e14:
#address-cells:0:0: 1 was expected
#size-cells:0:0: 0 was expected
Fixes: be8af7a9e3cc ("ARM: dts: bcm2711-rpi-4: Enable GENET support")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/1628334401-6577-2-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm2711.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/bcm2711.dtsi
+++ b/arch/arm/boot/dts/bcm2711.dtsi
@@ -540,8 +540,8 @@
compatible = "brcm,genet-mdio-v5";
reg = <0xe14 0x8>;
reg-names = "mdio";
- #address-cells = <0x0>;
- #size-cells = <0x1>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
};
};
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 092/151] firmware: arm_ffa: Fix __ffa_devices_unregister
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (90 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 091/151] ARM: dts: bcm2711: fix MDIO #address- and #size-cells Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 093/151] firmware: arm_ffa: Add missing remove callback to ffa_bus_type Greg Kroah-Hartman
` (64 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jens Wiklander, Sudeep Holla
From: Sudeep Holla <sudeep.holla@arm.com>
commit eb7b52e6db7c21400b9b2d539f9343fb6e94bd94 upstream.
When arm_ffa firmware driver module is unloaded or removed we call
__ffa_devices_unregister on all the devices on the ffa bus. It must
unregister all the devices instead it is currently just releasing the
devices without unregistering. That is pure wrong as when we try to
load the module back again, it will result in the kernel crash something
like below.
-->8
CPU: 2 PID: 232 Comm: modprobe Not tainted 5.15.0-rc2+ #169
Hardware name: FVP Base RevC (DT)
Call trace:
dump_backtrace+0x0/0x1cc
show_stack+0x18/0x64
dump_stack_lvl+0x64/0x7c
dump_stack+0x18/0x38
sysfs_create_dir_ns+0xe4/0x140
kobject_add_internal+0x170/0x358
kobject_add+0x94/0x100
device_add+0x178/0x5f0
device_register+0x20/0x30
ffa_device_register+0x80/0xcc [ffa_module]
ffa_setup_partitions+0x7c/0x108 [ffa_module]
init_module+0x290/0x2dc [ffa_module]
do_one_initcall+0xbc/0x230
do_init_module+0x58/0x304
load_module+0x15e0/0x1f68
__arm64_sys_finit_module+0xb8/0xf4
invoke_syscall+0x44/0x140
el0_svc_common+0xb4/0xf0
do_el0_svc+0x24/0x80
el0_svc+0x20/0x50
el0t_64_sync_handler+0x84/0xe4
el0t_64_sync+0x1a0/0x1a4
kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to
register things with the same name in the same directory.
----
Fix the issue by calling device_unregister in __ffa_devices_unregister
which will also take care of calling device_release(which is mapped to
ffa_release_device)
Link: https://lore.kernel.org/r/20210924092859.3057562-2-sudeep.holla@arm.com
Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Tested-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/arm_ffa/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -127,7 +127,7 @@ static void ffa_release_device(struct de
static int __ffa_devices_unregister(struct device *dev, void *data)
{
- ffa_release_device(dev);
+ device_unregister(dev);
return 0;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 093/151] firmware: arm_ffa: Add missing remove callback to ffa_bus_type
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (91 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 092/151] firmware: arm_ffa: Fix __ffa_devices_unregister Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 094/151] ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator states Greg Kroah-Hartman
` (63 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jens Wiklander, Sudeep Holla
From: Sudeep Holla <sudeep.holla@arm.com>
commit 244f5d597e1ea519c2085fbd9819458688775e42 upstream.
Currently the arm_ffa firmware driver can be built as module and hence
all the users of FFA driver. If any driver on the ffa bus is removed or
unregistered, the remove callback on all the device bound to the driver
being removed should be callback. For that to happen, we must register
a remove callback on the ffa_bus which is currently missing. This results
in the probe getting called again without the previous remove callback
on a device which may result in kernel crash.
Fix the issue by registering the remove callback on the FFA bus.
Link: https://lore.kernel.org/r/20210924092859.3057562-1-sudeep.holla@arm.com
Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Reported-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/arm_ffa/bus.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -49,6 +49,13 @@ static int ffa_device_probe(struct devic
return ffa_drv->probe(ffa_dev);
}
+static void ffa_device_remove(struct device *dev)
+{
+ struct ffa_driver *ffa_drv = to_ffa_driver(dev->driver);
+
+ ffa_drv->remove(to_ffa_dev(dev));
+}
+
static int ffa_device_uevent(struct device *dev, struct kobj_uevent_env *env)
{
struct ffa_device *ffa_dev = to_ffa_dev(dev);
@@ -86,6 +93,7 @@ struct bus_type ffa_bus_type = {
.name = "arm_ffa",
.match = ffa_device_match,
.probe = ffa_device_probe,
+ .remove = ffa_device_remove,
.uevent = ffa_device_uevent,
.dev_groups = ffa_device_attributes_groups,
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 094/151] ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator states
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (92 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 093/151] firmware: arm_ffa: Add missing remove callback to ffa_bus_type Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 095/151] ARM: dts: bcm2711-rpi-4-b: Fix pcie0s unit address formatting Greg Kroah-Hartman
` (62 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Wahren, Nicolas Saenz Julienne
From: Stefan Wahren <stefan.wahren@i2se.com>
commit b55ec7528879a822a4d350248daa04bbb27f25fd upstream.
DT schema check complains at sd_io_1v8_reg about the following:
[1800000, 1, 3300000, 0] is too long
Additional items are not allowed (3300000, 0 were unexpected)
So fix the states definition.
Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/1628334401-6577-3-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -40,8 +40,8 @@
regulator-always-on;
regulator-settling-time-us = <5000>;
gpios = <&expgpio 4 GPIO_ACTIVE_HIGH>;
- states = <1800000 0x1
- 3300000 0x0>;
+ states = <1800000 0x1>,
+ <3300000 0x0>;
status = "okay";
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 095/151] ARM: dts: bcm2711-rpi-4-b: Fix pcie0s unit address formatting
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (93 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 094/151] ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator states Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 096/151] clk: renesas: rzg2l: Fix clk status function Greg Kroah-Hartman
` (61 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Herring, Nicolas Saenz Julienne
From: Nicolas Saenz Julienne <nsaenz@kernel.org>
commit 13dbc954b3c9a9de0ad5b7279e8d3b708d31068b upstream.
dtbs_check currently complains that:
arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning
(pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format
error, expected "0,0"
Unsurprisingly pci@0,0 is the right address, as illustrated by its reg
property:
&pcie0 {
pci@0,0 {
/*
* As defined in the IEEE Std 1275-1994 document,
* reg is a five-cell address encoded as (phys.hi
* phys.mid phys.lo size.hi size.lo). phys.hi
* should contain the device's BDF as 0b00000000
* bbbbbbbb dddddfff 00000000. The other cells
* should be zero.
*/
reg = <0 0 0 0 0>;
};
};
The device is clearly 0. So fix it.
Also add a missing 'device_type = "pci"'.
Fixes: 258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node")
Suggested-by: Rob Herring <robh@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210831125843.1233488-1-nsaenzju@redhat.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -217,7 +217,8 @@
};
&pcie0 {
- pci@1,0 {
+ pci@0,0 {
+ device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
ranges;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 096/151] clk: renesas: rzg2l: Fix clk status function
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (94 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 095/151] ARM: dts: bcm2711-rpi-4-b: Fix pcie0s unit address formatting Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 097/151] nvme-pci: Fix abort command id Greg Kroah-Hartman
` (60 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Biju Das, Geert Uytterhoeven
From: Biju Das <biju.das.jz@bp.renesas.com>
commit fa2a30f8e0aa9304919750b116a9e9e322465299 upstream.
As per RZ/G2L HW(Rev.0.50) manual, clock monitor register value
0 means clock is not supplied and 1 means clock is supplied.
This patch fixes the issue by removing the inverted logic.
Fixing the above, triggered following 2 issues
1) GIC interrupts don't work if we disable IA55_CLK and DMAC_ACLK.
Fixed this issue by adding these clocks as critical clocks.
2) DMA is not working, since the DMA driver is not turning on DMAC_PCLK.
So will provide a fix in the DMA driver to turn on DMA_PCLK.
Fixes: ef3c613ccd68 ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20210922112405.26413-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/renesas/renesas-rzg2l-cpg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/renesas/renesas-rzg2l-cpg.c
+++ b/drivers/clk/renesas/renesas-rzg2l-cpg.c
@@ -398,7 +398,7 @@ static int rzg2l_mod_clock_is_enabled(st
value = readl(priv->base + CLK_MON_R(clock->off));
- return !(value & bitmask);
+ return value & bitmask;
}
static const struct clk_ops rzg2l_mod_clock_ops = {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 097/151] nvme-pci: Fix abort command id
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (95 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 096/151] clk: renesas: rzg2l: Fix clk status function Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 098/151] sctp: account stream padding length for reconf chunk Greg Kroah-Hartman
` (59 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sagi Grimberg, Keith Busch
From: Keith Busch <kbusch@kernel.org>
commit 85f74acf097a63a07f5a7c215db6883e5c35e3ff upstream.
The request tag is no longer the only component of the command id.
Fixes: e7006de6c2380 ("nvme: code command_id with a genctr for use-after-free validation")
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1331,7 +1331,7 @@ static enum blk_eh_timer_return nvme_tim
iod->aborted = 1;
cmd.abort.opcode = nvme_admin_abort_cmd;
- cmd.abort.cid = req->tag;
+ cmd.abort.cid = nvme_cid(req);
cmd.abort.sqid = cpu_to_le16(nvmeq->qid);
dev_warn(nvmeq->dev->ctrl.device,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 098/151] sctp: account stream padding length for reconf chunk
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (96 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 097/151] nvme-pci: Fix abort command id Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 099/151] gpio: 74x164: Add SPI device ID table Greg Kroah-Hartman
` (58 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vlad Yasevich, Neil Horman,
Eiichi Tsukata, Marcelo Ricardo Leitner, Marcelo Ricardo Leitner,
Xin Long, Jakub Kicinski
From: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
commit a2d859e3fc97e79d907761550dbc03ff1b36479c upstream.
sctp_make_strreset_req() makes repeated calls to sctp_addto_chunk()
which will automatically account for padding on each call. inreq and
outreq are already 4 bytes aligned, but the payload is not and doing
SCTP_PAD4(a + b) (which _sctp_make_chunk() did implicitly here) is
different from SCTP_PAD4(a) + SCTP_PAD4(b) and not enough. It led to
possible attempt to use more buffer than it was allocated and triggered
a BUG_ON.
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
Reported-by: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
Signed-off-by: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Link: https://lore.kernel.org/r/b97c1f8b0c7ff79ac4ed206fc2c49d3612e0850c.1634156849.git.mleitner@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/sm_make_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3697,7 +3697,7 @@ struct sctp_chunk *sctp_make_strreset_re
outlen = (sizeof(outreq) + stream_len) * out;
inlen = (sizeof(inreq) + stream_len) * in;
- retval = sctp_make_reconf(asoc, outlen + inlen);
+ retval = sctp_make_reconf(asoc, SCTP_PAD4(outlen) + SCTP_PAD4(inlen));
if (!retval)
return NULL;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 099/151] gpio: 74x164: Add SPI device ID table
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (97 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 098/151] sctp: account stream padding length for reconf chunk Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 100/151] gpio: pca953x: Improve bias setting Greg Kroah-Hartman
` (57 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Brown, Linus Walleij,
Bartosz Golaszewski
From: Mark Brown <broonie@kernel.org>
commit be4491838359e78e42e88db4ac479e21c5eda1e0 upstream.
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI device ID table.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpio-74x164.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/gpio/gpio-74x164.c
+++ b/drivers/gpio/gpio-74x164.c
@@ -174,6 +174,13 @@ static int gen_74x164_remove(struct spi_
return 0;
}
+static const struct spi_device_id gen_74x164_spi_ids[] = {
+ { .name = "74hc595" },
+ { .name = "74lvc594" },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, gen_74x164_spi_ids);
+
static const struct of_device_id gen_74x164_dt_ids[] = {
{ .compatible = "fairchild,74hc595" },
{ .compatible = "nxp,74lvc594" },
@@ -188,6 +195,7 @@ static struct spi_driver gen_74x164_driv
},
.probe = gen_74x164_probe,
.remove = gen_74x164_remove,
+ .id_table = gen_74x164_spi_ids,
};
module_spi_driver(gen_74x164_driver);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 100/151] gpio: pca953x: Improve bias setting
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (98 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 099/151] gpio: 74x164: Add SPI device ID table Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 101/151] net: arc: select CRC32 Greg Kroah-Hartman
` (56 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Petazzoni, Andy Shevchenko,
Bartosz Golaszewski
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
commit 55a9968c7e139209a9e93d4ca4321731bea5fc95 upstream.
The commit 15add06841a3 ("gpio: pca953x: add ->set_config implementation")
introduced support for bias setting. However this, due to being half-baked,
brought potential issues:
- the turning bias via disabling makes the pin floating for a while;
- once enabled, bias can't be disabled.
Fix all these by adding support for bias disabling and move the disabling
part under the corresponding conditional.
While at it, add support for default setting, since it's cheap to add.
Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation")
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpio-pca953x.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -559,21 +559,21 @@ static int pca953x_gpio_set_pull_up_down
mutex_lock(&chip->i2c_lock);
- /* Disable pull-up/pull-down */
- ret = regmap_write_bits(chip->regmap, pull_en_reg, bit, 0);
- if (ret)
- goto exit;
-
/* Configure pull-up/pull-down */
if (config == PIN_CONFIG_BIAS_PULL_UP)
ret = regmap_write_bits(chip->regmap, pull_sel_reg, bit, bit);
else if (config == PIN_CONFIG_BIAS_PULL_DOWN)
ret = regmap_write_bits(chip->regmap, pull_sel_reg, bit, 0);
+ else
+ ret = 0;
if (ret)
goto exit;
- /* Enable pull-up/pull-down */
- ret = regmap_write_bits(chip->regmap, pull_en_reg, bit, bit);
+ /* Disable/Enable pull-up/pull-down */
+ if (config == PIN_CONFIG_BIAS_DISABLE)
+ ret = regmap_write_bits(chip->regmap, pull_en_reg, bit, 0);
+ else
+ ret = regmap_write_bits(chip->regmap, pull_en_reg, bit, bit);
exit:
mutex_unlock(&chip->i2c_lock);
@@ -587,7 +587,9 @@ static int pca953x_gpio_set_config(struc
switch (pinconf_to_config_param(config)) {
case PIN_CONFIG_BIAS_PULL_UP:
+ case PIN_CONFIG_BIAS_PULL_PIN_DEFAULT:
case PIN_CONFIG_BIAS_PULL_DOWN:
+ case PIN_CONFIG_BIAS_DISABLE:
return pca953x_gpio_set_pull_up_down(chip, offset, config);
default:
return -ENOTSUPP;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 101/151] net: arc: select CRC32
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (99 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 100/151] gpio: pca953x: Improve bias setting Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 102/151] net: korina: " Greg Kroah-Hartman
` (55 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Vegard Nossum, Jakub Kicinski
From: Vegard Nossum <vegard.nossum@oracle.com>
commit e599ee234ad4fdfe241d937bbabd96e0d8f9d868 upstream.
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/net/ethernet/arc/emac_main.o: in function `arc_emac_set_rx_mode':
emac_main.c:(.text+0xb11): undefined reference to `crc32_le'
The crc32_le() call comes through the ether_crc_le() call in
arc_emac_set_rx_mode().
[v2: moved the select to ARC_EMAC_CORE; the Makefile is a bit confusing,
but the error comes from emac_main.o, which is part of the arc_emac module,
which in turn is enabled by CONFIG_ARC_EMAC_CORE. Note that arc_emac is
different from emac_arc...]
Fixes: 775dd682e2b0ec ("arc_emac: implement promiscuous mode and multicast filtering")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Link: https://lore.kernel.org/r/20211012093446.1575-1-vegard.nossum@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/arc/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -21,6 +21,7 @@ config ARC_EMAC_CORE
depends on ARC || ARCH_ROCKCHIP || COMPILE_TEST
select MII
select PHYLIB
+ select CRC32
config ARC_EMAC
tristate "ARC EMAC support"
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 102/151] net: korina: select CRC32
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (100 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 101/151] net: arc: select CRC32 Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 103/151] net/smc: improved fix wait on already cleared link Greg Kroah-Hartman
` (54 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Vegard Nossum,
Florian fainelli, Jakub Kicinski
From: Vegard Nossum <vegard.nossum@oracle.com>
commit 427f974d9727ca681085ddcd0530c97ab5811ae0 upstream.
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/net/ethernet/korina.o: in function `korina_multicast_list':
korina.c:(.text+0x1af): undefined reference to `crc32_le'
Fixes: ef11291bcd5f9 ("Add support the Korina (IDT RC32434) Ethernet MAC")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Acked-by: Florian fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20211012152509.21771-1-vegard.nossum@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -100,6 +100,7 @@ config JME
config KORINA
tristate "Korina (IDT RC32434) Ethernet support"
depends on MIKROTIK_RB532 || COMPILE_TEST
+ select CRC32
select MII
help
If you have a Mikrotik RouterBoard 500 or IDT RC32434
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 103/151] net/smc: improved fix wait on already cleared link
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (101 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 102/151] net: korina: " Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 104/151] net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path Greg Kroah-Hartman
` (53 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Karsten Graul, David S. Miller
From: Karsten Graul <kgraul@linux.ibm.com>
commit 95f7f3e7dc6bd2e735cb5de11734ea2222b1e05a upstream.
Commit 8f3d65c16679 ("net/smc: fix wait on already cleared link")
introduced link refcounting to avoid waits on already cleared links.
This patch extents and improves the refcounting to cover all
remaining possible cases for this kind of error situation.
Fixes: 15e1b99aadfb ("net/smc: no WR buffer wait for terminating link group")
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/smc/smc_cdc.c | 7 +++++
net/smc/smc_core.c | 20 +++++++++-------
net/smc/smc_llc.c | 63 +++++++++++++++++++++++++++++++++++++++++------------
net/smc/smc_tx.c | 22 ++++--------------
net/smc/smc_wr.h | 14 +++++++++++
5 files changed, 85 insertions(+), 41 deletions(-)
--- a/net/smc/smc_cdc.c
+++ b/net/smc/smc_cdc.c
@@ -150,9 +150,11 @@ static int smcr_cdc_get_slot_and_msg_sen
again:
link = conn->lnk;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_cdc_get_free_slot(conn, link, &wr_buf, NULL, &pend);
if (rc)
- return rc;
+ goto put_out;
spin_lock_bh(&conn->send_lock);
if (link != conn->lnk) {
@@ -160,6 +162,7 @@ again:
spin_unlock_bh(&conn->send_lock);
smc_wr_tx_put_slot(link,
(struct smc_wr_tx_pend_priv *)pend);
+ smc_wr_tx_link_put(link);
if (again)
return -ENOLINK;
again = true;
@@ -167,6 +170,8 @@ again:
}
rc = smc_cdc_msg_send(conn, wr_buf, pend);
spin_unlock_bh(&conn->send_lock);
+put_out:
+ smc_wr_tx_link_put(link);
return rc;
}
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -949,7 +949,7 @@ struct smc_link *smc_switch_conns(struct
to_lnk = &lgr->lnk[i];
break;
}
- if (!to_lnk) {
+ if (!to_lnk || !smc_wr_tx_link_hold(to_lnk)) {
smc_lgr_terminate_sched(lgr);
return NULL;
}
@@ -981,24 +981,26 @@ again:
read_unlock_bh(&lgr->conns_lock);
/* pre-fetch buffer outside of send_lock, might sleep */
rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend);
- if (rc) {
- smcr_link_down_cond_sched(to_lnk);
- return NULL;
- }
+ if (rc)
+ goto err_out;
/* avoid race with smcr_tx_sndbuf_nonempty() */
spin_lock_bh(&conn->send_lock);
smc_switch_link_and_count(conn, to_lnk);
rc = smc_switch_cursor(smc, pend, wr_buf);
spin_unlock_bh(&conn->send_lock);
sock_put(&smc->sk);
- if (rc) {
- smcr_link_down_cond_sched(to_lnk);
- return NULL;
- }
+ if (rc)
+ goto err_out;
goto again;
}
read_unlock_bh(&lgr->conns_lock);
+ smc_wr_tx_link_put(to_lnk);
return to_lnk;
+
+err_out:
+ smcr_link_down_cond_sched(to_lnk);
+ smc_wr_tx_link_put(to_lnk);
+ return NULL;
}
static void smcr_buf_unuse(struct smc_buf_desc *rmb_desc,
--- a/net/smc/smc_llc.c
+++ b/net/smc/smc_llc.c
@@ -383,9 +383,11 @@ int smc_llc_send_confirm_link(struct smc
struct smc_wr_buf *wr_buf;
int rc;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
confllc = (struct smc_llc_msg_confirm_link *)wr_buf;
memset(confllc, 0, sizeof(*confllc));
confllc->hd.common.type = SMC_LLC_CONFIRM_LINK;
@@ -402,6 +404,8 @@ int smc_llc_send_confirm_link(struct smc
confllc->max_links = SMC_LLC_ADD_LNK_MAX_LINKS;
/* send llc message */
rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
return rc;
}
@@ -415,9 +419,11 @@ static int smc_llc_send_confirm_rkey(str
struct smc_link *link;
int i, rc, rtok_ix;
+ if (!smc_wr_tx_link_hold(send_link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(send_link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
rkeyllc = (struct smc_llc_msg_confirm_rkey *)wr_buf;
memset(rkeyllc, 0, sizeof(*rkeyllc));
rkeyllc->hd.common.type = SMC_LLC_CONFIRM_RKEY;
@@ -444,6 +450,8 @@ static int smc_llc_send_confirm_rkey(str
(u64)sg_dma_address(rmb_desc->sgt[send_link->link_idx].sgl));
/* send llc message */
rc = smc_wr_tx_send(send_link, pend);
+put_out:
+ smc_wr_tx_link_put(send_link);
return rc;
}
@@ -456,9 +464,11 @@ static int smc_llc_send_delete_rkey(stru
struct smc_wr_buf *wr_buf;
int rc;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
rkeyllc = (struct smc_llc_msg_delete_rkey *)wr_buf;
memset(rkeyllc, 0, sizeof(*rkeyllc));
rkeyllc->hd.common.type = SMC_LLC_DELETE_RKEY;
@@ -467,6 +477,8 @@ static int smc_llc_send_delete_rkey(stru
rkeyllc->rkey[0] = htonl(rmb_desc->mr_rx[link->link_idx]->rkey);
/* send llc message */
rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
return rc;
}
@@ -480,9 +492,11 @@ int smc_llc_send_add_link(struct smc_lin
struct smc_wr_buf *wr_buf;
int rc;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
addllc = (struct smc_llc_msg_add_link *)wr_buf;
memset(addllc, 0, sizeof(*addllc));
@@ -504,6 +518,8 @@ int smc_llc_send_add_link(struct smc_lin
}
/* send llc message */
rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
return rc;
}
@@ -517,9 +533,11 @@ int smc_llc_send_delete_link(struct smc_
struct smc_wr_buf *wr_buf;
int rc;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
delllc = (struct smc_llc_msg_del_link *)wr_buf;
memset(delllc, 0, sizeof(*delllc));
@@ -536,6 +554,8 @@ int smc_llc_send_delete_link(struct smc_
delllc->reason = htonl(reason);
/* send llc message */
rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
return rc;
}
@@ -547,9 +567,11 @@ static int smc_llc_send_test_link(struct
struct smc_wr_buf *wr_buf;
int rc;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
testllc = (struct smc_llc_msg_test_link *)wr_buf;
memset(testllc, 0, sizeof(*testllc));
testllc->hd.common.type = SMC_LLC_TEST_LINK;
@@ -557,6 +579,8 @@ static int smc_llc_send_test_link(struct
memcpy(testllc->user_data, user_data, sizeof(testllc->user_data));
/* send llc message */
rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
return rc;
}
@@ -567,13 +591,16 @@ static int smc_llc_send_message(struct s
struct smc_wr_buf *wr_buf;
int rc;
- if (!smc_link_usable(link))
+ if (!smc_wr_tx_link_hold(link))
return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
memcpy(wr_buf, llcbuf, sizeof(union smc_llc_msg));
- return smc_wr_tx_send(link, pend);
+ rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
+ return rc;
}
/* schedule an llc send on link, may wait for buffers,
@@ -586,13 +613,16 @@ static int smc_llc_send_message_wait(str
struct smc_wr_buf *wr_buf;
int rc;
- if (!smc_link_usable(link))
+ if (!smc_wr_tx_link_hold(link))
return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
memcpy(wr_buf, llcbuf, sizeof(union smc_llc_msg));
- return smc_wr_tx_send_wait(link, pend, SMC_LLC_WAIT_TIME);
+ rc = smc_wr_tx_send_wait(link, pend, SMC_LLC_WAIT_TIME);
+put_out:
+ smc_wr_tx_link_put(link);
+ return rc;
}
/********************************* receive ***********************************/
@@ -672,9 +702,11 @@ static int smc_llc_add_link_cont(struct
struct smc_buf_desc *rmb;
u8 n;
+ if (!smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_llc_add_pending_send(link, &wr_buf, &pend);
if (rc)
- return rc;
+ goto put_out;
addc_llc = (struct smc_llc_msg_add_link_cont *)wr_buf;
memset(addc_llc, 0, sizeof(*addc_llc));
@@ -706,7 +738,10 @@ static int smc_llc_add_link_cont(struct
addc_llc->hd.length = sizeof(struct smc_llc_msg_add_link_cont);
if (lgr->role == SMC_CLNT)
addc_llc->hd.flags |= SMC_LLC_FLAG_RESP;
- return smc_wr_tx_send(link, pend);
+ rc = smc_wr_tx_send(link, pend);
+put_out:
+ smc_wr_tx_link_put(link);
+ return rc;
}
static int smc_llc_cli_rkey_exchange(struct smc_link *link,
--- a/net/smc/smc_tx.c
+++ b/net/smc/smc_tx.c
@@ -496,7 +496,7 @@ static int smc_tx_rdma_writes(struct smc
/* Wakeup sndbuf consumers from any context (IRQ or process)
* since there is more data to transmit; usable snd_wnd as max transmit
*/
-static int _smcr_tx_sndbuf_nonempty(struct smc_connection *conn)
+static int smcr_tx_sndbuf_nonempty(struct smc_connection *conn)
{
struct smc_cdc_producer_flags *pflags = &conn->local_tx_ctrl.prod_flags;
struct smc_link *link = conn->lnk;
@@ -505,8 +505,11 @@ static int _smcr_tx_sndbuf_nonempty(stru
struct smc_wr_buf *wr_buf;
int rc;
+ if (!link || !smc_wr_tx_link_hold(link))
+ return -ENOLINK;
rc = smc_cdc_get_free_slot(conn, link, &wr_buf, &wr_rdma_buf, &pend);
if (rc < 0) {
+ smc_wr_tx_link_put(link);
if (rc == -EBUSY) {
struct smc_sock *smc =
container_of(conn, struct smc_sock, conn);
@@ -547,22 +550,7 @@ static int _smcr_tx_sndbuf_nonempty(stru
out_unlock:
spin_unlock_bh(&conn->send_lock);
- return rc;
-}
-
-static int smcr_tx_sndbuf_nonempty(struct smc_connection *conn)
-{
- struct smc_link *link = conn->lnk;
- int rc = -ENOLINK;
-
- if (!link)
- return rc;
-
- atomic_inc(&link->wr_tx_refcnt);
- if (smc_link_usable(link))
- rc = _smcr_tx_sndbuf_nonempty(conn);
- if (atomic_dec_and_test(&link->wr_tx_refcnt))
- wake_up_all(&link->wr_tx_wait);
+ smc_wr_tx_link_put(link);
return rc;
}
--- a/net/smc/smc_wr.h
+++ b/net/smc/smc_wr.h
@@ -60,6 +60,20 @@ static inline void smc_wr_tx_set_wr_id(a
atomic_long_set(wr_tx_id, val);
}
+static inline bool smc_wr_tx_link_hold(struct smc_link *link)
+{
+ if (!smc_link_usable(link))
+ return false;
+ atomic_inc(&link->wr_tx_refcnt);
+ return true;
+}
+
+static inline void smc_wr_tx_link_put(struct smc_link *link)
+{
+ if (atomic_dec_and_test(&link->wr_tx_refcnt))
+ wake_up_all(&link->wr_tx_wait);
+}
+
static inline void smc_wr_wakeup_tx_wait(struct smc_link *lnk)
{
wake_up_all(&lnk->wr_tx_wait);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 104/151] net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (102 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 103/151] net/smc: improved fix wait on already cleared link Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 105/151] net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp Greg Kroah-Hartman
` (52 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Valentine Fatiev, Moshe Shemesh,
Saeed Mahameed
From: Valentine Fatiev <valentinef@nvidia.com>
commit 94b960b9deffc02fc0747afc01f72cc62ab099e3 upstream.
Prior to this patch in case mlx5_core_destroy_cq() failed it returns
without completing all destroy operations and that leads to memory leak.
Instead, complete the destroy flow before return error.
Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()
to be symmetrical with mlx5_core_create_cq().
kmemleak complains on:
unreferenced object 0xc000000038625100 (size 64):
comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)
hex dump (first 32 bytes):
60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....
02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....
backtrace:
[<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]
[<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]
[<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]
[<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]
[<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]
[<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]
[<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]
[<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230
[mlx5_core]
[<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300
[mlx5_core]
[<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]
[<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]
[<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0
[<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0
[<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0
[<00000000646c5c2c>] genl_rcv_msg+0x78/0x120
[<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Valentine Fatiev <valentinef@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/cq.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/cq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cq.c
@@ -154,6 +154,8 @@ int mlx5_core_destroy_cq(struct mlx5_cor
u32 in[MLX5_ST_SZ_DW(destroy_cq_in)] = {};
int err;
+ mlx5_debug_cq_remove(dev, cq);
+
mlx5_eq_del_cq(mlx5_get_async_eq(dev), cq);
mlx5_eq_del_cq(&cq->eq->core, cq);
@@ -161,16 +163,13 @@ int mlx5_core_destroy_cq(struct mlx5_cor
MLX5_SET(destroy_cq_in, in, cqn, cq->cqn);
MLX5_SET(destroy_cq_in, in, uid, cq->uid);
err = mlx5_cmd_exec_in(dev, destroy_cq, in);
- if (err)
- return err;
synchronize_irq(cq->irqn);
- mlx5_debug_cq_remove(dev, cq);
mlx5_cq_put(cq);
wait_for_completion(&cq->free);
- return 0;
+ return err;
}
EXPORT_SYMBOL(mlx5_core_destroy_cq);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 105/151] net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (103 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 104/151] net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 106/151] net/mlx5e: Switchdev representors are not vlan challenged Greg Kroah-Hartman
` (51 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aya Levin, Tariq Toukan,
Moshe Shemesh, Saeed Mahameed
From: Aya Levin <ayal@nvidia.com>
commit 0bc73ad46a76ed6ece4dcacb28858e7b38561e1c upstream.
Due to current HW arch limitations, RX-FCS (scattering FCS frame field
to software) and RX-port-timestamp (improved timestamp accuracy on the
receive side) can't work together.
RX-port-timestamp is not controlled by the user and it is enabled by
default when supported by the HW/FW.
This patch sets RX-port-timestamp opposite to RX-FCS configuration.
Fixes: 102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 57 ++++++++++++++++++++--
include/linux/mlx5/mlx5_ifc.h | 10 +++
2 files changed, 60 insertions(+), 7 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3724,20 +3724,67 @@ static int set_feature_rx_all(struct net
return mlx5_set_port_fcs(mdev, !enable);
}
+static int mlx5e_set_rx_port_ts(struct mlx5_core_dev *mdev, bool enable)
+{
+ u32 in[MLX5_ST_SZ_DW(pcmr_reg)] = {};
+ bool supported, curr_state;
+ int err;
+
+ if (!MLX5_CAP_GEN(mdev, ports_check))
+ return 0;
+
+ err = mlx5_query_ports_check(mdev, in, sizeof(in));
+ if (err)
+ return err;
+
+ supported = MLX5_GET(pcmr_reg, in, rx_ts_over_crc_cap);
+ curr_state = MLX5_GET(pcmr_reg, in, rx_ts_over_crc);
+
+ if (!supported || enable == curr_state)
+ return 0;
+
+ MLX5_SET(pcmr_reg, in, local_port, 1);
+ MLX5_SET(pcmr_reg, in, rx_ts_over_crc, enable);
+
+ return mlx5_set_ports_check(mdev, in, sizeof(in));
+}
+
static int set_feature_rx_fcs(struct net_device *netdev, bool enable)
{
struct mlx5e_priv *priv = netdev_priv(netdev);
+ struct mlx5e_channels *chs = &priv->channels;
+ struct mlx5_core_dev *mdev = priv->mdev;
int err;
mutex_lock(&priv->state_lock);
- priv->channels.params.scatter_fcs_en = enable;
- err = mlx5e_modify_channels_scatter_fcs(&priv->channels, enable);
- if (err)
- priv->channels.params.scatter_fcs_en = !enable;
+ if (enable) {
+ err = mlx5e_set_rx_port_ts(mdev, false);
+ if (err)
+ goto out;
+
+ chs->params.scatter_fcs_en = true;
+ err = mlx5e_modify_channels_scatter_fcs(chs, true);
+ if (err) {
+ chs->params.scatter_fcs_en = false;
+ mlx5e_set_rx_port_ts(mdev, true);
+ }
+ } else {
+ chs->params.scatter_fcs_en = false;
+ err = mlx5e_modify_channels_scatter_fcs(chs, false);
+ if (err) {
+ chs->params.scatter_fcs_en = true;
+ goto out;
+ }
+ err = mlx5e_set_rx_port_ts(mdev, true);
+ if (err) {
+ mlx5_core_warn(mdev, "Failed to set RX port timestamp %d\n", err);
+ err = 0;
+ }
+ }
+out:
mutex_unlock(&priv->state_lock);
-
return err;
}
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -9467,16 +9467,22 @@ struct mlx5_ifc_pcmr_reg_bits {
u8 reserved_at_0[0x8];
u8 local_port[0x8];
u8 reserved_at_10[0x10];
+
u8 entropy_force_cap[0x1];
u8 entropy_calc_cap[0x1];
u8 entropy_gre_calc_cap[0x1];
- u8 reserved_at_23[0x1b];
+ u8 reserved_at_23[0xf];
+ u8 rx_ts_over_crc_cap[0x1];
+ u8 reserved_at_33[0xb];
u8 fcs_cap[0x1];
u8 reserved_at_3f[0x1];
+
u8 entropy_force[0x1];
u8 entropy_calc[0x1];
u8 entropy_gre_calc[0x1];
- u8 reserved_at_43[0x1b];
+ u8 reserved_at_43[0xf];
+ u8 rx_ts_over_crc[0x1];
+ u8 reserved_at_53[0xb];
u8 fcs_chk[0x1];
u8 reserved_at_5f[0x1];
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 106/151] net/mlx5e: Switchdev representors are not vlan challenged
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (104 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 105/151] net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 107/151] net: stmmac: fix get_hw_feature() on old hardware Greg Kroah-Hartman
` (50 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roopa Prabhu, Saeed Mahameed, Roi Dayan
From: Saeed Mahameed <saeedm@nvidia.com>
commit b2107cdc43d8601f2cadfba990ae844cc1f44e68 upstream.
Before this patch, mlx5 representors advertised the
NETIF_F_VLAN_CHALLENGED bit, this could lead to missing features when
using reps with vxlan/bridge and maybe other virtual interfaces,
when such interfaces inherit this bit and block vlan usage in their
topology.
Example:
$ip link add dev bridge type bridge
# add representor interface to the bridge
$ip link set dev pf0hpf master
$ip link add link bridge name vlan10 type vlan id 10 protocol 802.1q
Error: 8021q: VLANs not supported on device.
Reps are perfectly capable of handling vlan traffic, although they don't
implement vlan_{add,kill}_vid ndos, hence, remove
NETIF_F_VLAN_CHALLENGED advertisement.
Fixes: cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors")
Reported-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -611,7 +611,6 @@ static void mlx5e_build_rep_netdev(struc
netdev->hw_features |= NETIF_F_RXCSUM;
netdev->features |= netdev->hw_features;
- netdev->features |= NETIF_F_VLAN_CHALLENGED;
netdev->features |= NETIF_F_NETNS_LOCAL;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 107/151] net: stmmac: fix get_hw_feature() on old hardware
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (105 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 106/151] net/mlx5e: Switchdev representors are not vlan challenged Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 108/151] net: phy: Do not shutdown PHYs in READY state Greg Kroah-Hartman
` (49 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Herve Codina, David S. Miller
From: Herve Codina <herve.codina@bootlin.com>
commit 075da584bae2da6a37428d59a477b6bdad430ac3 upstream.
Some old IPs do not provide the hardware feature register.
On these IPs, this register is read 0x00000000.
In old driver version, this feature was handled but a regression came
with the commit f10a6a3541b4 ("stmmac: rework get_hw_feature function").
Indeed, this commit removes the return value in dma->get_hw_feature().
This return value was used to indicate the validity of retrieved
information and used later on in stmmac_hw_init() to override
priv->plat data if this hardware feature were valid.
This patch restores the return code in ->get_hw_feature() in order
to indicate the hardware feature validity and override priv->plat
data only if this hardware feature is valid.
Fixes: f10a6a3541b4 ("stmmac: rework get_hw_feature function")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 13 +++++++++++--
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 6 ++++--
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 6 ++++--
drivers/net/ethernet/stmicro/stmmac/hwif.h | 6 +++---
4 files changed, 22 insertions(+), 9 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -218,11 +218,18 @@ static void dwmac1000_dump_dma_regs(void
readl(ioaddr + DMA_BUS_MODE + i * 4);
}
-static void dwmac1000_get_hw_feature(void __iomem *ioaddr,
- struct dma_features *dma_cap)
+static int dwmac1000_get_hw_feature(void __iomem *ioaddr,
+ struct dma_features *dma_cap)
{
u32 hw_cap = readl(ioaddr + DMA_HW_FEATURE);
+ if (!hw_cap) {
+ /* 0x00000000 is the value read on old hardware that does not
+ * implement this register
+ */
+ return -EOPNOTSUPP;
+ }
+
dma_cap->mbps_10_100 = (hw_cap & DMA_HW_FEAT_MIISEL);
dma_cap->mbps_1000 = (hw_cap & DMA_HW_FEAT_GMIISEL) >> 1;
dma_cap->half_duplex = (hw_cap & DMA_HW_FEAT_HDSEL) >> 2;
@@ -252,6 +259,8 @@ static void dwmac1000_get_hw_feature(voi
dma_cap->number_tx_channel = (hw_cap & DMA_HW_FEAT_TXCHCNT) >> 22;
/* Alternate (enhanced) DESC mode */
dma_cap->enh_desc = (hw_cap & DMA_HW_FEAT_ENHDESSEL) >> 24;
+
+ return 0;
}
static void dwmac1000_rx_watchdog(void __iomem *ioaddr, u32 riwt,
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -347,8 +347,8 @@ static void dwmac4_dma_tx_chan_op_mode(v
writel(mtl_tx_op, ioaddr + MTL_CHAN_TX_OP_MODE(channel));
}
-static void dwmac4_get_hw_feature(void __iomem *ioaddr,
- struct dma_features *dma_cap)
+static int dwmac4_get_hw_feature(void __iomem *ioaddr,
+ struct dma_features *dma_cap)
{
u32 hw_cap = readl(ioaddr + GMAC_HW_FEATURE0);
@@ -437,6 +437,8 @@ static void dwmac4_get_hw_feature(void _
dma_cap->frpbs = (hw_cap & GMAC_HW_FEAT_FRPBS) >> 11;
dma_cap->frpsel = (hw_cap & GMAC_HW_FEAT_FRPSEL) >> 10;
dma_cap->dvlan = (hw_cap & GMAC_HW_FEAT_DVLAN) >> 5;
+
+ return 0;
}
/* Enable/disable TSO feature and set MSS */
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -371,8 +371,8 @@ static int dwxgmac2_dma_interrupt(void _
return ret;
}
-static void dwxgmac2_get_hw_feature(void __iomem *ioaddr,
- struct dma_features *dma_cap)
+static int dwxgmac2_get_hw_feature(void __iomem *ioaddr,
+ struct dma_features *dma_cap)
{
u32 hw_cap;
@@ -445,6 +445,8 @@ static void dwxgmac2_get_hw_feature(void
dma_cap->frpes = (hw_cap & XGMAC_HWFEAT_FRPES) >> 11;
dma_cap->frpbs = (hw_cap & XGMAC_HWFEAT_FRPPB) >> 9;
dma_cap->frpsel = (hw_cap & XGMAC_HWFEAT_FRPSEL) >> 3;
+
+ return 0;
}
static void dwxgmac2_rx_watchdog(void __iomem *ioaddr, u32 riwt, u32 queue)
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -203,8 +203,8 @@ struct stmmac_dma_ops {
int (*dma_interrupt) (void __iomem *ioaddr,
struct stmmac_extra_stats *x, u32 chan, u32 dir);
/* If supported then get the optional core features */
- void (*get_hw_feature)(void __iomem *ioaddr,
- struct dma_features *dma_cap);
+ int (*get_hw_feature)(void __iomem *ioaddr,
+ struct dma_features *dma_cap);
/* Program the HW RX Watchdog */
void (*rx_watchdog)(void __iomem *ioaddr, u32 riwt, u32 queue);
void (*set_tx_ring_len)(void __iomem *ioaddr, u32 len, u32 chan);
@@ -255,7 +255,7 @@ struct stmmac_dma_ops {
#define stmmac_dma_interrupt_status(__priv, __args...) \
stmmac_do_callback(__priv, dma, dma_interrupt, __args)
#define stmmac_get_hw_feature(__priv, __args...) \
- stmmac_do_void_callback(__priv, dma, get_hw_feature, __args)
+ stmmac_do_callback(__priv, dma, get_hw_feature, __args)
#define stmmac_rx_watchdog(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, rx_watchdog, __args)
#define stmmac_set_tx_ring_len(__priv, __args...) \
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 108/151] net: phy: Do not shutdown PHYs in READY state
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (106 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 107/151] net: stmmac: fix get_hw_feature() on old hardware Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 109/151] net: dsa: mv88e6xxx: dont use PHY_DETECT on internal PHYs Greg Kroah-Hartman
` (48 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Florian Fainelli, David S. Miller
From: Florian Fainelli <f.fainelli@gmail.com>
commit f49823939e41121fdffada4d583e3e38d28336f9 upstream.
In case a PHY device was probed thus in the PHY_READY state, but not
configured and with no network device attached yet, we should not be
trying to shut it down because it has been brought back into reset by
phy_device_reset() towards the end of phy_probe() and anyway we have not
configured the PHY yet.
Fixes: e2f016cf7751 ("net: phy: add a shutdown procedure")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/phy/phy_device.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -3112,6 +3112,9 @@ static void phy_shutdown(struct device *
{
struct phy_device *phydev = to_phy_device(dev);
+ if (phydev->state == PHY_READY || !phydev->attached_dev)
+ return;
+
phy_disable_interrupts(phydev);
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 109/151] net: dsa: mv88e6xxx: dont use PHY_DETECT on internal PHYs
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (107 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 108/151] net: phy: Do not shutdown PHYs in READY state Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 110/151] net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work Greg Kroah-Hartman
` (47 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maarten Zanders, Maxime Chevallier,
Maarten Zanders, David S. Miller
From: Maarten Zanders <maarten.zanders@mind.be>
commit 4a3e0aeddf091f00974b02627c157843ce382a24 upstream.
mv88e6xxx_port_ppu_updates() interpretes data in the PORT_STS
register incorrectly for internal ports (ie no PPU). In these
cases, the PHY_DETECT bit indicates link status. This results
in forcing the MAC state whenever the PHY link goes down which
is not intended. As a side effect, LED's configured to show
link status stay lit even though the physical link is down.
Add a check in mac_link_down and mac_link_up to see if it
concerns an external port and only then, look at PPU status.
Fixes: 5d5b231da7ac (net: dsa: mv88e6xxx: use PHY_DETECT in mac_link_up/mac_link_down)
Reported-by: Maarten Zanders <m.zanders@televic.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Maarten Zanders <maarten.zanders@mind.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/mv88e6xxx/chip.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -749,7 +749,11 @@ static void mv88e6xxx_mac_link_down(stru
ops = chip->info->ops;
mv88e6xxx_reg_lock(chip);
- if ((!mv88e6xxx_port_ppu_updates(chip, port) ||
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ */
+ if (((!mv88e6xxx_phy_is_internal(ds, port) &&
+ !mv88e6xxx_port_ppu_updates(chip, port)) ||
mode == MLO_AN_FIXED) && ops->port_sync_link)
err = ops->port_sync_link(chip, port, mode, false);
mv88e6xxx_reg_unlock(chip);
@@ -772,7 +776,12 @@ static void mv88e6xxx_mac_link_up(struct
ops = chip->info->ops;
mv88e6xxx_reg_lock(chip);
- if (!mv88e6xxx_port_ppu_updates(chip, port) || mode == MLO_AN_FIXED) {
+ /* Internal PHYs propagate their configuration directly to the MAC.
+ * External PHYs depend on whether the PPU is enabled for this port.
+ */
+ if ((!mv88e6xxx_phy_is_internal(ds, port) &&
+ !mv88e6xxx_port_ppu_updates(chip, port)) ||
+ mode == MLO_AN_FIXED) {
/* FIXME: for an automedia port, should we force the link
* down here - what if the link comes up due to "other" media
* while we're bringing the port up, how is the exclusivity
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 110/151] net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (108 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 109/151] net: dsa: mv88e6xxx: dont use PHY_DETECT on internal PHYs Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 111/151] net: dsa: fix spurious error message when unoffloaded port leaves bridge Greg Kroah-Hartman
` (46 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arun Ramadoss, David S. Miller
From: Arun Ramadoss <arun.ramadoss@microchip.com>
commit ef1100ef20f29aec4e62abeccdb5bdbebba1e378 upstream.
When the ksz module is installed and removed using rmmod, kernel crashes
with null pointer dereferrence error. During rmmod, ksz_switch_remove
function tries to cancel the mib_read_workqueue using
cancel_delayed_work_sync routine and unregister switch from dsa.
During dsa_unregister_switch it calls ksz_mac_link_down, which in turn
reschedules the workqueue since mib_interval is non-zero.
Due to which queue executed after mib_interval and it tries to access
dp->slave. But the slave is unregistered in the ksz_switch_remove
function. Hence kernel crashes.
To avoid this crash, before canceling the workqueue, resetted the
mib_interval to 0.
v1 -> v2:
-Removed the if condition in ksz_mib_read_work
Fixes: 469b390e1ba3 ("net: dsa: microchip: use delayed_work instead of timer + work")
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/microchip/ksz_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -449,8 +449,10 @@ EXPORT_SYMBOL(ksz_switch_register);
void ksz_switch_remove(struct ksz_device *dev)
{
/* timer started */
- if (dev->mib_read_interval)
+ if (dev->mib_read_interval) {
+ dev->mib_read_interval = 0;
cancel_delayed_work_sync(&dev->mib_read);
+ }
dev->dev_ops->exit(dev);
dsa_unregister_switch(dev->ds);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 111/151] net: dsa: fix spurious error message when unoffloaded port leaves bridge
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (109 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 110/151] net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 112/151] net: encx24j600: check error in devm_regmap_init_encx24j600 Greg Kroah-Hartman
` (45 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alvin Šipraga, Vladimir Oltean,
Florian Fainelli, Jakub Kicinski
From: Alvin Šipraga <alsi@bang-olufsen.dk>
commit 43a4b4dbd48c9006ef64df3a12acf33bdfe11c61 upstream.
Flip the sign of a return value check, thereby suppressing the following
spurious error:
port 2 failed to notify DSA_NOTIFIER_BRIDGE_LEAVE: -EOPNOTSUPP
... which is emitted when removing an unoffloaded DSA switch port from a
bridge.
Fixes: d371b7c92d19 ("net: dsa: Unset vlan_filtering when ports leave the bridge")
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20211012112730.3429157-1-alvin@pqrs.dk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/dsa/switch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -148,7 +148,7 @@ static int dsa_switch_bridge_leave(struc
if (extack._msg)
dev_err(ds->dev, "port %d: %s\n", info->port,
extack._msg);
- if (err && err != EOPNOTSUPP)
+ if (err && err != -EOPNOTSUPP)
return err;
}
return 0;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 112/151] net: encx24j600: check error in devm_regmap_init_encx24j600
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (110 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 111/151] net: dsa: fix spurious error message when unoffloaded port leaves bridge Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 113/151] ethernet: s2io: fix setting mac address during resume Greg Kroah-Hartman
` (44 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hulk Robot, Nanyong Sun, Jakub Kicinski
From: Nanyong Sun <sunnanyong@huawei.com>
commit f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream.
devm_regmap_init may return error which caused by like out of memory,
this will results in null pointer dereference later when reading
or writing register:
general protection fault in encx24j600_spi_probe
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540
Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00
RSP: 0018:ffffc900010476b8 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000
RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094
RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a
R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001
R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08
FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459
spi_probe drivers/spi/spi.c:397
really_probe drivers/base/dd.c:517
__driver_probe_device drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:782
__device_attach_driver drivers/base/dd.c:899
bus_for_each_drv drivers/base/bus.c:427
__device_attach drivers/base/dd.c:971
bus_probe_device drivers/base/bus.c:487
device_add drivers/base/core.c:3364
__spi_add_device drivers/spi/spi.c:599
spi_add_device drivers/spi/spi.c:641
spi_new_device drivers/spi/spi.c:717
new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]
dev_attr_store drivers/base/core.c:2074
sysfs_kf_write fs/sysfs/file.c:139
kernfs_fop_write_iter fs/kernfs/file.c:300
new_sync_write fs/read_write.c:508 (discriminator 4)
vfs_write fs/read_write.c:594
ksys_write fs/read_write.c:648
do_syscall_64 arch/x86/entry/common.c:50
entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113
Add error check in devm_regmap_init_encx24j600 to avoid this situation.
Fixes: 04fbfce7a222 ("net: Microchip encx24j600 driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Nanyong Sun <sunnanyong@huawei.com>
Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/microchip/encx24j600-regmap.c | 10 ++++++++--
drivers/net/ethernet/microchip/encx24j600.c | 5 ++++-
drivers/net/ethernet/microchip/encx24j600_hw.h | 4 ++--
3 files changed, 14 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/microchip/encx24j600-regmap.c
+++ b/drivers/net/ethernet/microchip/encx24j600-regmap.c
@@ -497,13 +497,19 @@ static struct regmap_bus phymap_encx24j6
.reg_read = regmap_encx24j600_phy_reg_read,
};
-void devm_regmap_init_encx24j600(struct device *dev,
- struct encx24j600_context *ctx)
+int devm_regmap_init_encx24j600(struct device *dev,
+ struct encx24j600_context *ctx)
{
mutex_init(&ctx->mutex);
regcfg.lock_arg = ctx;
ctx->regmap = devm_regmap_init(dev, ®map_encx24j600, ctx, ®cfg);
+ if (IS_ERR(ctx->regmap))
+ return PTR_ERR(ctx->regmap);
ctx->phymap = devm_regmap_init(dev, &phymap_encx24j600, ctx, &phycfg);
+ if (IS_ERR(ctx->phymap))
+ return PTR_ERR(ctx->phymap);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(devm_regmap_init_encx24j600);
--- a/drivers/net/ethernet/microchip/encx24j600.c
+++ b/drivers/net/ethernet/microchip/encx24j600.c
@@ -1023,10 +1023,13 @@ static int encx24j600_spi_probe(struct s
priv->speed = SPEED_100;
priv->ctx.spi = spi;
- devm_regmap_init_encx24j600(&spi->dev, &priv->ctx);
ndev->irq = spi->irq;
ndev->netdev_ops = &encx24j600_netdev_ops;
+ ret = devm_regmap_init_encx24j600(&spi->dev, &priv->ctx);
+ if (ret)
+ goto out_free;
+
mutex_init(&priv->lock);
/* Reset device and check if it is connected */
--- a/drivers/net/ethernet/microchip/encx24j600_hw.h
+++ b/drivers/net/ethernet/microchip/encx24j600_hw.h
@@ -15,8 +15,8 @@ struct encx24j600_context {
int bank;
};
-void devm_regmap_init_encx24j600(struct device *dev,
- struct encx24j600_context *ctx);
+int devm_regmap_init_encx24j600(struct device *dev,
+ struct encx24j600_context *ctx);
/* Single-byte instructions */
#define BANK_SELECT(bank) (0xC0 | ((bank & (BANK_MASK >> BANK_SHIFT)) << 1))
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 113/151] ethernet: s2io: fix setting mac address during resume
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (111 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 112/151] net: encx24j600: check error in devm_regmap_init_encx24j600 Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 114/151] vhost-vdpa: Fix the wrong input in config_cb Greg Kroah-Hartman
` (43 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Jakub Kicinski
From: Arnd Bergmann <arnd@arndb.de>
commit 40507e7aada8422c38aafa0c8a1a09e4623c712a upstream.
After recent cleanups, gcc started warning about a suspicious
memcpy() call during the s2io_io_resume() function:
In function '__dev_addr_set',
inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:318:2,
inlined from 's2io_set_mac_addr' at drivers/net/ethernet/neterion/s2io.c:5205:2,
inlined from 's2io_io_resume' at drivers/net/ethernet/neterion/s2io.c:8569:7:
arch/x86/include/asm/string_32.h:182:25: error: '__builtin_memcpy' accessing 6 bytes at offsets 0 and 2 overlaps 4 bytes at offset 2 [-Werror=restrict]
182 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/netdevice.h:4648:9: note: in expansion of macro 'memcpy'
4648 | memcpy(dev->dev_addr, addr, len);
| ^~~~~~
What apparently happened is that an old cleanup changed the calling
conventions for s2io_set_mac_addr() from taking an ethernet address
as a character array to taking a struct sockaddr, but one of the
callers was not changed at the same time.
Change it to instead call the low-level do_s2io_prog_unicast() function
that still takes the old argument type.
Fixes: 2fd376884558 ("S2io: Added support set_mac_address driver entry point")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211013143613.2049096-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/neterion/s2io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -8566,7 +8566,7 @@ static void s2io_io_resume(struct pci_de
return;
}
- if (s2io_set_mac_addr(netdev, netdev->dev_addr) == FAILURE) {
+ if (do_s2io_prog_unicast(netdev, netdev->dev_addr) == FAILURE) {
s2io_card_down(sp);
pr_err("Can't restore mac addr after reset.\n");
return;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 114/151] vhost-vdpa: Fix the wrong input in config_cb
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (112 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 113/151] ethernet: s2io: fix setting mac address during resume Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 115/151] nfc: fix error handling of nfc_proto_register() Greg Kroah-Hartman
` (42 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Cindy Lu, Michael S. Tsirkin
From: Cindy Lu <lulu@redhat.com>
commit bcef9356fc2e1302daf373c83c826aa27954d128 upstream.
Fix the wrong input in for config_cb. In function vhost_vdpa_config_cb,
the input cb.private was used as struct vhost_vdpa, so the input was
wrong here, fix this issue
Fixes: 776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
Signed-off-by: Cindy Lu <lulu@redhat.com>
Link: https://lore.kernel.org/r/20210929090933.20465-1-lulu@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/vhost/vdpa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -316,7 +316,7 @@ static long vhost_vdpa_set_config_call(s
struct eventfd_ctx *ctx;
cb.callback = vhost_vdpa_config_cb;
- cb.private = v->vdpa;
+ cb.private = v;
if (copy_from_user(&fd, argp, sizeof(fd)))
return -EFAULT;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 115/151] nfc: fix error handling of nfc_proto_register()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (113 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 114/151] vhost-vdpa: Fix the wrong input in config_cb Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 116/151] NFC: digital: fix possible memory leak in digital_tg_listen_mdaa() Greg Kroah-Hartman
` (41 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ziyang Xuan, Krzysztof Kozlowski,
Jakub Kicinski
From: Ziyang Xuan <william.xuanziyang@huawei.com>
commit 0911ab31896f0e908540746414a77dd63912748d upstream.
When nfc proto id is using, nfc_proto_register() return -EBUSY error
code, but forgot to unregister proto. Fix it by adding proto_unregister()
in the error handling case.
Fixes: c7fe3b52c128 ("NFC: add NFC socket family")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/nfc/af_nfc.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/nfc/af_nfc.c
+++ b/net/nfc/af_nfc.c
@@ -60,6 +60,9 @@ int nfc_proto_register(const struct nfc_
proto_tab[nfc_proto->id] = nfc_proto;
write_unlock(&proto_tab_lock);
+ if (rc)
+ proto_unregister(nfc_proto->proto);
+
return rc;
}
EXPORT_SYMBOL(nfc_proto_register);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 116/151] NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (114 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 115/151] nfc: fix error handling of nfc_proto_register() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 117/151] NFC: digital: fix possible memory leak in digital_in_send_sdd_req() Greg Kroah-Hartman
` (40 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ziyang Xuan, Krzysztof Kozlowski,
Jakub Kicinski
From: Ziyang Xuan <william.xuanziyang@huawei.com>
commit 58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream.
'params' is allocated in digital_tg_listen_mdaa(), but not free when
digital_send_cmd() failed, which will cause memory leak. Fix it by
freeing 'params' if digital_send_cmd() return failed.
Fixes: 1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/nfc/digital_core.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/nfc/digital_core.c
+++ b/net/nfc/digital_core.c
@@ -277,6 +277,7 @@ int digital_tg_configure_hw(struct nfc_d
static int digital_tg_listen_mdaa(struct nfc_digital_dev *ddev, u8 rf_tech)
{
struct digital_tg_mdaa_params *params;
+ int rc;
params = kzalloc(sizeof(*params), GFP_KERNEL);
if (!params)
@@ -291,8 +292,12 @@ static int digital_tg_listen_mdaa(struct
get_random_bytes(params->nfcid2 + 2, NFC_NFCID2_MAXSIZE - 2);
params->sc = DIGITAL_SENSF_FELICA_SC;
- return digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN_MDAA, NULL, params,
- 500, digital_tg_recv_atr_req, NULL);
+ rc = digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN_MDAA, NULL, params,
+ 500, digital_tg_recv_atr_req, NULL);
+ if (rc)
+ kfree(params);
+
+ return rc;
}
static int digital_tg_listen_md(struct nfc_digital_dev *ddev, u8 rf_tech)
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 117/151] NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (115 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 116/151] NFC: digital: fix possible memory leak in digital_tg_listen_mdaa() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 118/151] pata_legacy: fix a couple uninitialized variable bugs Greg Kroah-Hartman
` (39 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ziyang Xuan, Krzysztof Kozlowski,
Jakub Kicinski
From: Ziyang Xuan <william.xuanziyang@huawei.com>
commit 291c932fc3692e4d211a445ba8aa35663831bac7 upstream.
'skb' is allocated in digital_in_send_sdd_req(), but not free when
digital_in_send_cmd() failed, which will cause memory leak. Fix it
by freeing 'skb' if digital_in_send_cmd() return failed.
Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/nfc/digital_technology.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/nfc/digital_technology.c
+++ b/net/nfc/digital_technology.c
@@ -465,8 +465,12 @@ static int digital_in_send_sdd_req(struc
skb_put_u8(skb, sel_cmd);
skb_put_u8(skb, DIGITAL_SDD_REQ_SEL_PAR);
- return digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sdd_res,
- target);
+ rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sdd_res,
+ target);
+ if (rc)
+ kfree_skb(skb);
+
+ return rc;
}
static void digital_in_recv_sens_res(struct nfc_digital_dev *ddev, void *arg,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 118/151] pata_legacy: fix a couple uninitialized variable bugs
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (116 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 117/151] NFC: digital: fix possible memory leak in digital_in_send_sdd_req() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 119/151] ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators() Greg Kroah-Hartman
` (38 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Damien Le Moal
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 013923477cb311293df9079332cf8b806ed0e6f2 upstream.
The last byte of "pad" is used without being initialized.
Fixes: 55dba3120fbc ("libata: update ->data_xfer hook for ATAPI")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/pata_legacy.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -352,7 +352,8 @@ static unsigned int pdc_data_xfer_vlb(st
iowrite32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
if (unlikely(slop)) {
- __le32 pad;
+ __le32 pad = 0;
+
if (rw == READ) {
pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
memcpy(buf + buflen - slop, &pad, slop);
@@ -742,7 +743,8 @@ static unsigned int vlb32_data_xfer(stru
ioread32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
if (unlikely(slop)) {
- __le32 pad;
+ __le32 pad = 0;
+
if (rw == WRITE) {
memcpy(&pad, buf + buflen - slop, slop);
iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 119/151] ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (117 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 118/151] pata_legacy: fix a couple uninitialized variable bugs Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:24 ` [PATCH 5.14 120/151] mlxsw: thermal: Fix out-of-bounds memory accesses Greg Kroah-Hartman
` (37 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hulk Robot, Wang Hai, Hans de Goede,
Damien Le Moal
From: Wang Hai <wanghai38@huawei.com>
commit 776c75010803849c1cc4f11031a2b3960ab05202 upstream.
I got a null-ptr-deref report:
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
...
RIP: 0010:regulator_enable+0x84/0x260
...
Call Trace:
ahci_platform_enable_regulators+0xae/0x320
ahci_platform_enable_resources+0x1a/0x120
ahci_probe+0x4f/0x1b9
platform_probe+0x10b/0x280
...
entry_SYSCALL_64_after_hwframe+0x44/0xae
If devm_regulator_get() in ahci_platform_get_resources() fails,
hpriv->phy_regulator will point to NULL, when enabling or disabling it,
null-ptr-deref will occur.
ahci_probe()
ahci_platform_get_resources()
devm_regulator_get(, "phy") // failed, let phy_regulator = NULL
ahci_platform_enable_resources()
ahci_platform_enable_regulators()
regulator_enable(hpriv->phy_regulator) // null-ptr-deref
commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional()
misuse") replaces devm_regulator_get_optional() with devm_regulator_get(),
but PHY regulator omits to delete "hpriv->phy_regulator = NULL;" like AHCI.
Delete it like AHCI regulator to fix this bug.
Fixes: commit 962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libahci_platform.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -440,10 +440,7 @@ struct ahci_host_priv *ahci_platform_get
hpriv->phy_regulator = devm_regulator_get(dev, "phy");
if (IS_ERR(hpriv->phy_regulator)) {
rc = PTR_ERR(hpriv->phy_regulator);
- if (rc == -EPROBE_DEFER)
- goto err_out;
- rc = 0;
- hpriv->phy_regulator = NULL;
+ goto err_out;
}
if (flags & AHCI_PLATFORM_GET_RESETS) {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 120/151] mlxsw: thermal: Fix out-of-bounds memory accesses
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (118 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 119/151] ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators() Greg Kroah-Hartman
@ 2021-10-18 13:24 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 121/151] platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() call Greg Kroah-Hartman
` (36 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Lezcano, Ido Schimmel,
Vadim Pasternak, Jakub Kicinski
From: Ido Schimmel <idosch@nvidia.com>
commit 332fdf951df8b870e3da86b122ae304e2aabe88c upstream.
Currently, mlxsw allows cooling states to be set above the maximum
cooling state supported by the driver:
# cat /sys/class/thermal/thermal_zone2/cdev0/type
mlxsw_fan
# cat /sys/class/thermal/thermal_zone2/cdev0/max_state
10
# echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state
# echo $?
0
This results in out-of-bounds memory accesses when thermal state
transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the
transition table is accessed with a too large index (state) [1].
According to the thermal maintainer, it is the responsibility of the
driver to reject such operations [2].
Therefore, return an error when the state to be set exceeds the maximum
cooling state supported by the driver.
To avoid dead code, as suggested by the thermal maintainer [3],
partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling
device with cooling levels") that tried to interpret these invalid
cooling states (above the maximum) in a special way. The cooling levels
array is not removed in order to prevent the fans going below 20% PWM,
which would cause them to get stuck at 0% PWM.
[1]
BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290
Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122
Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016
Workqueue: events_freezable_power_ thermal_zone_device_check
Call Trace:
dump_stack_lvl+0x8b/0xb3
print_address_description.constprop.0+0x1f/0x140
kasan_report.cold+0x7f/0x11b
thermal_cooling_device_stats_update+0x271/0x290
__thermal_cdev_update+0x15e/0x4e0
thermal_cdev_update+0x9f/0xe0
step_wise_throttle+0x770/0xee0
thermal_zone_device_update+0x3f6/0xdf0
process_one_work+0xa42/0x1770
worker_thread+0x62f/0x13e0
kthread+0x3ee/0x4e0
ret_from_fork+0x1f/0x30
Allocated by task 1:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
thermal_cooling_device_setup_sysfs+0x153/0x2c0
__thermal_cooling_device_register.part.0+0x25b/0x9c0
thermal_cooling_device_register+0xb3/0x100
mlxsw_thermal_init+0x5c5/0x7e0
__mlxsw_core_bus_device_register+0xcb3/0x19c0
mlxsw_core_bus_device_register+0x56/0xb0
mlxsw_pci_probe+0x54f/0x710
local_pci_probe+0xc6/0x170
pci_device_probe+0x2b2/0x4d0
really_probe+0x293/0xd10
__driver_probe_device+0x2af/0x440
driver_probe_device+0x51/0x1e0
__driver_attach+0x21b/0x530
bus_for_each_dev+0x14c/0x1d0
bus_add_driver+0x3ac/0x650
driver_register+0x241/0x3d0
mlxsw_sp_module_init+0xa2/0x174
do_one_initcall+0xee/0x5f0
kernel_init_freeable+0x45a/0x4de
kernel_init+0x1f/0x210
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff8881052f7800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 1016 bytes inside of
1024-byte region [ffff8881052f7800, ffff8881052f7c00)
The buggy address belongs to the page:
page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0
head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-1895-1fdc45c0244e@linaro.org/
[3] https://lore.kernel.org/linux-pm/af9857f2-578e-de3a-e62b-6baff7e69fd4@linaro.org/
CC: Daniel Lezcano <daniel.lezcano@linaro.org>
Fixes: a50c1e35650b ("mlxsw: core: Implement thermal zone")
Fixes: a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20211012174955.472928-1-idosch@idosch.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/core_thermal.c | 52 ++-------------------
1 file changed, 5 insertions(+), 47 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -24,16 +24,8 @@
#define MLXSW_THERMAL_ZONE_MAX_NAME 16
#define MLXSW_THERMAL_TEMP_SCORE_MAX GENMASK(31, 0)
#define MLXSW_THERMAL_MAX_STATE 10
+#define MLXSW_THERMAL_MIN_STATE 2
#define MLXSW_THERMAL_MAX_DUTY 255
-/* Minimum and maximum fan allowed speed in percent: from 20% to 100%. Values
- * MLXSW_THERMAL_MAX_STATE + x, where x is between 2 and 10 are used for
- * setting fan speed dynamic minimum. For example, if value is set to 14 (40%)
- * cooling levels vector will be set to 4, 4, 4, 4, 4, 5, 6, 7, 8, 9, 10 to
- * introduce PWM speed in percent: 40, 40, 40, 40, 40, 50, 60. 70, 80, 90, 100.
- */
-#define MLXSW_THERMAL_SPEED_MIN (MLXSW_THERMAL_MAX_STATE + 2)
-#define MLXSW_THERMAL_SPEED_MAX (MLXSW_THERMAL_MAX_STATE * 2)
-#define MLXSW_THERMAL_SPEED_MIN_LEVEL 2 /* 20% */
/* External cooling devices, allowed for binding to mlxsw thermal zones. */
static char * const mlxsw_thermal_external_allowed_cdev[] = {
@@ -646,49 +638,16 @@ static int mlxsw_thermal_set_cur_state(s
struct mlxsw_thermal *thermal = cdev->devdata;
struct device *dev = thermal->bus_info->dev;
char mfsc_pl[MLXSW_REG_MFSC_LEN];
- unsigned long cur_state, i;
int idx;
- u8 duty;
int err;
+ if (state > MLXSW_THERMAL_MAX_STATE)
+ return -EINVAL;
+
idx = mlxsw_get_cooling_device_idx(thermal, cdev);
if (idx < 0)
return idx;
- /* Verify if this request is for changing allowed fan dynamical
- * minimum. If it is - update cooling levels accordingly and update
- * state, if current state is below the newly requested minimum state.
- * For example, if current state is 5, and minimal state is to be
- * changed from 4 to 6, thermal->cooling_levels[0 to 5] will be changed
- * all from 4 to 6. And state 5 (thermal->cooling_levels[4]) should be
- * overwritten.
- */
- if (state >= MLXSW_THERMAL_SPEED_MIN &&
- state <= MLXSW_THERMAL_SPEED_MAX) {
- state -= MLXSW_THERMAL_MAX_STATE;
- for (i = 0; i <= MLXSW_THERMAL_MAX_STATE; i++)
- thermal->cooling_levels[i] = max(state, i);
-
- mlxsw_reg_mfsc_pack(mfsc_pl, idx, 0);
- err = mlxsw_reg_query(thermal->core, MLXSW_REG(mfsc), mfsc_pl);
- if (err)
- return err;
-
- duty = mlxsw_reg_mfsc_pwm_duty_cycle_get(mfsc_pl);
- cur_state = mlxsw_duty_to_state(duty);
-
- /* If current fan state is lower than requested dynamical
- * minimum, increase fan speed up to dynamical minimum.
- */
- if (state < cur_state)
- return 0;
-
- state = cur_state;
- }
-
- if (state > MLXSW_THERMAL_MAX_STATE)
- return -EINVAL;
-
/* Normalize the state to the valid speed range. */
state = thermal->cooling_levels[state];
mlxsw_reg_mfsc_pack(mfsc_pl, idx, mlxsw_state_to_duty(state));
@@ -998,8 +957,7 @@ int mlxsw_thermal_init(struct mlxsw_core
/* Initialize cooling levels per PWM state. */
for (i = 0; i < MLXSW_THERMAL_MAX_STATE; i++)
- thermal->cooling_levels[i] = max(MLXSW_THERMAL_SPEED_MIN_LEVEL,
- i);
+ thermal->cooling_levels[i] = max(MLXSW_THERMAL_MIN_STATE, i);
thermal->polling_delay = bus_info->low_frequency ?
MLXSW_THERMAL_SLOW_POLL_INT :
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 121/151] platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() call
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (119 preceding siblings ...)
2021-10-18 13:24 ` [PATCH 5.14 120/151] mlxsw: thermal: Fix out-of-bounds memory accesses Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 122/151] platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributes Greg Kroah-Hartman
` (35 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vadim Pasternak, Hans de Goede
From: Vadim Pasternak <vadimp@nvidia.com>
commit 9b024201693e397441668cca0d2df7055fe572eb upstream.
Change kstrtou32() argument 'base' to be zero instead of 'len'.
It works by chance for setting one bit value, but it is not supposed to
work in case value passed to mlxreg_io_attr_store() is greater than 1.
It works for example, for:
echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable
But it will fail for:
echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable,
where n > 1.
The flow for input buffer conversion is as below:
_kstrtoull(const char *s, unsigned int base, unsigned long long *res)
calls:
rv = _parse_integer(s, base, &_res);
For the second case, where n > 1:
- _parse_integer() converts 's' to 'val'.
For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3
'len' is set to 3 (string buffer 0x33 0x0a), etcetera.
- 'base' is equal or greater then '2' (length of input buffer).
As a result, _parse_integer() exits with result zero (rv):
rv = 0;
while (1) {
...
if (val >= base)-> (2 >= 2)
break;
...
rv++;
...
}
And _kstrtoull() in their turn will fail:
if (rv == 0)
return -EINVAL;
Fixes: 5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/mellanox/mlxreg-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/platform/mellanox/mlxreg-io.c
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -141,7 +141,7 @@ mlxreg_io_attr_store(struct device *dev,
return -EINVAL;
/* Convert buffer to input value. */
- ret = kstrtou32(buf, len, &input_val);
+ ret = kstrtou32(buf, 0, &input_val);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 122/151] platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributes
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (120 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 121/151] platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() call Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 123/151] spi: spidev: Add SPI ID table Greg Kroah-Hartman
` (34 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vadim Pasternak, Hans de Goede
From: Vadim Pasternak <vadimp@nvidia.com>
commit db9cc7d6f95e7d89b0ce57e785cfd9d67a7505d8 upstream.
Fix shift argument for function rol32(). It should be provided in bits,
while was provided in bytes.
Fixes: 86148190a7db ("platform/mellanox: mlxreg-io: Add support for complex attributes")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210927142214.2613929-3-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/mellanox/mlxreg-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/platform/mellanox/mlxreg-io.c
+++ b/drivers/platform/mellanox/mlxreg-io.c
@@ -98,7 +98,7 @@ mlxreg_io_get_reg(void *regmap, struct m
if (ret)
goto access_error;
- *regval |= rol32(val, regsize * i);
+ *regval |= rol32(val, regsize * i * 8);
}
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 123/151] spi: spidev: Add SPI ID table
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (121 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 122/151] platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributes Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 124/151] spi: bcm-qspi: clear MSPI spifie interrupt during probe Greg Kroah-Hartman
` (33 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mark Brown
From: Mark Brown <broonie@kernel.org>
commit 6840615f85f6046039ebc4989870ddb12892b7fc upstream.
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210923170023.1683-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spidev.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -673,6 +673,19 @@ static const struct file_operations spid
static struct class *spidev_class;
+static const struct spi_device_id spidev_spi_ids[] = {
+ { .name = "dh2228fv" },
+ { .name = "ltc2488" },
+ { .name = "sx1301" },
+ { .name = "bk4" },
+ { .name = "dhcom-board" },
+ { .name = "m53cpld" },
+ { .name = "spi-petra" },
+ { .name = "spi-authenta" },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, spidev_spi_ids);
+
#ifdef CONFIG_OF
static const struct of_device_id spidev_dt_ids[] = {
{ .compatible = "rohm,dh2228fv" },
@@ -819,6 +832,7 @@ static struct spi_driver spidev_spi_driv
},
.probe = spidev_probe,
.remove = spidev_remove,
+ .id_table = spidev_spi_ids,
/* NOTE: suspend/resume methods are not necessary here.
* We don't do anything except pass the requests to/from
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 124/151] spi: bcm-qspi: clear MSPI spifie interrupt during probe
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (122 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 123/151] spi: spidev: Add SPI ID table Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 125/151] drm/panel: olimex-lcd-olinuxino: select CRC32 Greg Kroah-Hartman
` (32 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kamal Dasu, Florian Fainelli, Mark Brown
From: Kamal Dasu <kdasu@broadcom.com>
commit 75b3cb97eb1f05042745c0655a7145b0262d4c5c upstream.
Intermittent Kernel crash has been observed on probe in
bcm_qspi_mspi_l2_isr() handler when the MSPI spifie interrupt bit
has not been cleared before registering for interrupts.
Fix the driver to move SoC specific custom interrupt handling code
before we register IRQ in probe. Also clear MSPI interrupt status
resgiter prior to registering IRQ handlers.
Fixes: cc20a38612db ("spi: iproc-qspi: Add Broadcom iProc SoCs support")
Signed-off-by: Kamal Dasu <kdasu@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20211008203603.40915-3-kdasu.kdev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm-qspi.c | 77 ++++++++++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 32 deletions(-)
--- a/drivers/spi/spi-bcm-qspi.c
+++ b/drivers/spi/spi-bcm-qspi.c
@@ -1250,10 +1250,14 @@ static void bcm_qspi_hw_init(struct bcm_
static void bcm_qspi_hw_uninit(struct bcm_qspi *qspi)
{
+ u32 status = bcm_qspi_read(qspi, MSPI, MSPI_MSPI_STATUS);
+
bcm_qspi_write(qspi, MSPI, MSPI_SPCR2, 0);
if (has_bspi(qspi))
bcm_qspi_write(qspi, MSPI, MSPI_WRITE_LOCK, 0);
+ /* clear interrupt */
+ bcm_qspi_write(qspi, MSPI, MSPI_MSPI_STATUS, status & ~1);
}
static const struct spi_controller_mem_ops bcm_qspi_mem_ops = {
@@ -1397,6 +1401,47 @@ int bcm_qspi_probe(struct platform_devic
if (!qspi->dev_ids)
return -ENOMEM;
+ /*
+ * Some SoCs integrate spi controller (e.g., its interrupt bits)
+ * in specific ways
+ */
+ if (soc_intc) {
+ qspi->soc_intc = soc_intc;
+ soc_intc->bcm_qspi_int_set(soc_intc, MSPI_DONE, true);
+ } else {
+ qspi->soc_intc = NULL;
+ }
+
+ if (qspi->clk) {
+ ret = clk_prepare_enable(qspi->clk);
+ if (ret) {
+ dev_err(dev, "failed to prepare clock\n");
+ goto qspi_probe_err;
+ }
+ qspi->base_clk = clk_get_rate(qspi->clk);
+ } else {
+ qspi->base_clk = MSPI_BASE_FREQ;
+ }
+
+ if (data->has_mspi_rev) {
+ rev = bcm_qspi_read(qspi, MSPI, MSPI_REV);
+ /* some older revs do not have a MSPI_REV register */
+ if ((rev & 0xff) == 0xff)
+ rev = 0;
+ }
+
+ qspi->mspi_maj_rev = (rev >> 4) & 0xf;
+ qspi->mspi_min_rev = rev & 0xf;
+ qspi->mspi_spcr3_sysclk = data->has_spcr3_sysclk;
+
+ qspi->max_speed_hz = qspi->base_clk / (bcm_qspi_spbr_min(qspi) * 2);
+
+ /*
+ * On SW resets it is possible to have the mask still enabled
+ * Need to disable the mask and clear the status while we init
+ */
+ bcm_qspi_hw_uninit(qspi);
+
for (val = 0; val < num_irqs; val++) {
irq = -1;
name = qspi_irq_tab[val].irq_name;
@@ -1433,38 +1478,6 @@ int bcm_qspi_probe(struct platform_devic
goto qspi_probe_err;
}
- /*
- * Some SoCs integrate spi controller (e.g., its interrupt bits)
- * in specific ways
- */
- if (soc_intc) {
- qspi->soc_intc = soc_intc;
- soc_intc->bcm_qspi_int_set(soc_intc, MSPI_DONE, true);
- } else {
- qspi->soc_intc = NULL;
- }
-
- ret = clk_prepare_enable(qspi->clk);
- if (ret) {
- dev_err(dev, "failed to prepare clock\n");
- goto qspi_probe_err;
- }
-
- qspi->base_clk = clk_get_rate(qspi->clk);
-
- if (data->has_mspi_rev) {
- rev = bcm_qspi_read(qspi, MSPI, MSPI_REV);
- /* some older revs do not have a MSPI_REV register */
- if ((rev & 0xff) == 0xff)
- rev = 0;
- }
-
- qspi->mspi_maj_rev = (rev >> 4) & 0xf;
- qspi->mspi_min_rev = rev & 0xf;
- qspi->mspi_spcr3_sysclk = data->has_spcr3_sysclk;
-
- qspi->max_speed_hz = qspi->base_clk / (bcm_qspi_spbr_min(qspi) * 2);
-
bcm_qspi_hw_init(qspi);
init_completion(&qspi->mspi_done);
init_completion(&qspi->bspi_done);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 125/151] drm/panel: olimex-lcd-olinuxino: select CRC32
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (123 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 124/151] spi: bcm-qspi: clear MSPI spifie interrupt during probe Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 126/151] drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read Greg Kroah-Hartman
` (31 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Vegard Nossum,
Sam Ravnborg, Dave Airlie
From: Vegard Nossum <vegard.nossum@oracle.com>
commit a14bc107edd0c108bda2245e50daa22f91c95d20 upstream.
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function `lcd_olinuxino_probe':
panel-olimex-lcd-olinuxino.c:(.text+0x303): undefined reference to `crc32_le'
Fixes: 17fd7a9d324fd ("drm/panel: Add support for Olimex LCD-OLinuXino panel")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211012115242.10325-1-vegard.nossum@oracle.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/panel/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -273,6 +273,7 @@ config DRM_PANEL_OLIMEX_LCD_OLINUXINO
depends on OF
depends on I2C
depends on BACKLIGHT_CLASS_DEVICE
+ select CRC32
help
The panel is used with different sizes LCDs, from 480x272 to
1280x800, and 24 bit per pixel.
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 126/151] drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (124 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 125/151] drm/panel: olimex-lcd-olinuxino: select CRC32 Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 127/151] drm/msm: Fix null pointer dereference on pointer edp Greg Kroah-Hartman
` (30 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ville Syrjälä,
Douglas Anderson, Dave Airlie
From: Douglas Anderson <dianders@chromium.org>
commit 97794170b696856483f74b47bfb6049780d2d3a0 upstream.
In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.
Let's fix this by adding a bounds check.
This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.
Fixes: e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1834,11 +1834,20 @@ static void connector_bad_edid(struct dr
u8 *edid, int num_blocks)
{
int i;
- u8 num_of_ext = edid[0x7e];
+ u8 last_block;
+
+ /*
+ * 0x7e in the EDID is the number of extension blocks. The EDID
+ * is 1 (base block) + num_ext_blocks big. That means we can think
+ * of 0x7e in the EDID of the _index_ of the last block in the
+ * combined chunk of memory.
+ */
+ last_block = edid[0x7e];
/* Calculate real checksum for the last edid extension block data */
- connector->real_edid_checksum =
- drm_edid_block_checksum(edid + num_of_ext * EDID_LENGTH);
+ if (last_block < num_blocks)
+ connector->real_edid_checksum =
+ drm_edid_block_checksum(edid + last_block * EDID_LENGTH);
if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
return;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 127/151] drm/msm: Fix null pointer dereference on pointer edp
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (125 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 126/151] drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 128/151] drm/msm/mdp5: fix cursor-related warnings Greg Kroah-Hartman
` (29 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Colin Ian King, Dmitry Baryshkov, Rob Clark
From: Colin Ian King <colin.king@canonical.com>
commit 2133c4fc8e1348dcb752f267a143fe2254613b34 upstream.
The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.
Addresses-Coverity: ("Dereference before null check")
Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/edp/edp_ctrl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1116,7 +1116,7 @@ void msm_edp_ctrl_power(struct edp_ctrl
int msm_edp_ctrl_init(struct msm_edp *edp)
{
struct edp_ctrl *ctrl = NULL;
- struct device *dev = &edp->pdev->dev;
+ struct device *dev;
int ret;
if (!edp) {
@@ -1124,6 +1124,7 @@ int msm_edp_ctrl_init(struct msm_edp *ed
return -EINVAL;
}
+ dev = &edp->pdev->dev;
ctrl = devm_kzalloc(dev, sizeof(*ctrl), GFP_KERNEL);
if (!ctrl)
return -ENOMEM;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 128/151] drm/msm/mdp5: fix cursor-related warnings
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (126 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 127/151] drm/msm: Fix null pointer dereference on pointer edp Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 129/151] drm/msm/submit: fix overflow check on 64-bit architectures Greg Kroah-Hartman
` (28 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dmitry Baryshkov, Rob Clark
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
commit c491a0c7bbf3a64732cb8414021429d15ec08eec upstream.
Since f35a2a99100f ("drm/encoder: make encoder control functions
optional") drm_mode_config_validate would print warnings if both cursor
plane and cursor functions are provided. Restore separate set of
drm_crtc_funcs to be used if separate cursor plane is provided.
[ 6.556046] ------------[ cut here ]------------
[ 6.556071] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_set func
[ 6.556091] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:648 drm_mode_config_validate+0x238/0x4d0
[ 6.567453] Modules linked in:
[ 6.577604] CPU: 1 PID: 76 Comm: kworker/u8:2 Not tainted 5.15.0-rc1-dirty #43
[ 6.580557] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
[ 6.587763] Workqueue: events_unbound deferred_probe_work_func
[ 6.593926] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 6.599740] pc : drm_mode_config_validate+0x238/0x4d0
[ 6.606596] lr : drm_mode_config_validate+0x238/0x4d0
[ 6.611804] sp : ffff8000121b3980
[ 6.616838] x29: ffff8000121b3990 x28: 0000000000000000 x27: 0000000000000001
[ 6.620140] x26: ffff8000114cde50 x25: ffff8000114cdd40 x24: ffff0000987282d8
[ 6.627258] x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000001
[ 6.634376] x20: ffff000098728000 x19: ffff000080a39000 x18: ffffffffffffffff
[ 6.641494] x17: 3136564e3631564e x16: 0000000000000324 x15: ffff800011c78709
[ 6.648613] x14: 0000000000000000 x13: ffff800011a22850 x12: 00000000000009ab
[ 6.655730] x11: 0000000000000339 x10: ffff800011a22850 x9 : ffff800011a22850
[ 6.662848] x8 : 00000000ffffefff x7 : ffff800011a7a850 x6 : ffff800011a7a850
[ 6.669966] x5 : 000000000000bff4 x4 : 40000000fffff339 x3 : 0000000000000000
[ 6.677084] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008093b800
[ 6.684205] Call trace:
[ 6.691319] drm_mode_config_validate+0x238/0x4d0
[ 6.693577] drm_dev_register+0x17c/0x210
[ 6.698435] msm_drm_bind+0x4b4/0x694
[ 6.702429] try_to_bring_up_master+0x164/0x1d0
[ 6.706075] __component_add+0xa0/0x170
[ 6.710415] component_add+0x14/0x20
[ 6.714234] msm_hdmi_dev_probe+0x1c/0x2c
[ 6.718053] platform_probe+0x68/0xe0
[ 6.721959] really_probe.part.0+0x9c/0x30c
[ 6.725606] __driver_probe_device+0x98/0x144
[ 6.729600] driver_probe_device+0xc8/0x15c
[ 6.734114] __device_attach_driver+0xb4/0x120
[ 6.738106] bus_for_each_drv+0x78/0xd0
[ 6.742619] __device_attach+0xdc/0x184
[ 6.746351] device_initial_probe+0x14/0x20
[ 6.750172] bus_probe_device+0x9c/0xa4
[ 6.754337] deferred_probe_work_func+0x88/0xc0
[ 6.758158] process_one_work+0x1d0/0x370
[ 6.762671] worker_thread+0x2c8/0x470
[ 6.766839] kthread+0x15c/0x170
[ 6.770483] ret_from_fork+0x10/0x20
[ 6.773870] ---[ end trace 5884eb76cd26d274 ]---
[ 6.777500] ------------[ cut here ]------------
[ 6.782043] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_move func
[ 6.782063] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:654 drm_mode_config_validate+0x290/0x4d0
[ 6.794362] Modules linked in:
[ 6.804600] CPU: 1 PID: 76 Comm: kworker/u8:2 Tainted: G W 5.15.0-rc1-dirty #43
[ 6.807555] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
[ 6.816148] Workqueue: events_unbound deferred_probe_work_func
[ 6.822311] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 6.828126] pc : drm_mode_config_validate+0x290/0x4d0
[ 6.834981] lr : drm_mode_config_validate+0x290/0x4d0
[ 6.840189] sp : ffff8000121b3980
[ 6.845223] x29: ffff8000121b3990 x28: 0000000000000000 x27: 0000000000000001
[ 6.848525] x26: ffff8000114cde50 x25: ffff8000114cdd40 x24: ffff0000987282d8
[ 6.855643] x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000001
[ 6.862763] x20: ffff000098728000 x19: ffff000080a39000 x18: ffffffffffffffff
[ 6.869879] x17: 3136564e3631564e x16: 0000000000000324 x15: ffff800011c790c2
[ 6.876998] x14: 0000000000000000 x13: ffff800011a22850 x12: 0000000000000a2f
[ 6.884116] x11: 0000000000000365 x10: ffff800011a22850 x9 : ffff800011a22850
[ 6.891234] x8 : 00000000ffffefff x7 : ffff800011a7a850 x6 : ffff800011a7a850
[ 6.898351] x5 : 000000000000bff4 x4 : 40000000fffff365 x3 : 0000000000000000
[ 6.905470] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008093b800
[ 6.912590] Call trace:
[ 6.919702] drm_mode_config_validate+0x290/0x4d0
[ 6.921960] drm_dev_register+0x17c/0x210
[ 6.926821] msm_drm_bind+0x4b4/0x694
[ 6.930813] try_to_bring_up_master+0x164/0x1d0
[ 6.934459] __component_add+0xa0/0x170
[ 6.938799] component_add+0x14/0x20
[ 6.942619] msm_hdmi_dev_probe+0x1c/0x2c
[ 6.946438] platform_probe+0x68/0xe0
[ 6.950345] really_probe.part.0+0x9c/0x30c
[ 6.953991] __driver_probe_device+0x98/0x144
[ 6.957984] driver_probe_device+0xc8/0x15c
[ 6.962498] __device_attach_driver+0xb4/0x120
[ 6.966492] bus_for_each_drv+0x78/0xd0
[ 6.971004] __device_attach+0xdc/0x184
[ 6.974737] device_initial_probe+0x14/0x20
[ 6.978556] bus_probe_device+0x9c/0xa4
[ 6.982722] deferred_probe_work_func+0x88/0xc0
[ 6.986543] process_one_work+0x1d0/0x370
[ 6.991057] worker_thread+0x2c8/0x470
[ 6.995223] kthread+0x15c/0x170
[ 6.998869] ret_from_fork+0x10/0x20
[ 7.002255] ---[ end trace 5884eb76cd26d275 ]---
Fixes: aa649e875daf ("drm/msm/mdp5: mdp5_crtc: Restore cursor state only if LM cursors are enabled")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210925192824.3416259-1-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -1125,6 +1125,20 @@ static void mdp5_crtc_reset(struct drm_c
__drm_atomic_helper_crtc_reset(crtc, &mdp5_cstate->base);
}
+static const struct drm_crtc_funcs mdp5_crtc_no_lm_cursor_funcs = {
+ .set_config = drm_atomic_helper_set_config,
+ .destroy = mdp5_crtc_destroy,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = mdp5_crtc_reset,
+ .atomic_duplicate_state = mdp5_crtc_duplicate_state,
+ .atomic_destroy_state = mdp5_crtc_destroy_state,
+ .atomic_print_state = mdp5_crtc_atomic_print_state,
+ .get_vblank_counter = mdp5_crtc_get_vblank_counter,
+ .enable_vblank = msm_crtc_enable_vblank,
+ .disable_vblank = msm_crtc_disable_vblank,
+ .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
+};
+
static const struct drm_crtc_funcs mdp5_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = mdp5_crtc_destroy,
@@ -1313,6 +1327,8 @@ struct drm_crtc *mdp5_crtc_init(struct d
mdp5_crtc->lm_cursor_enabled = cursor_plane ? false : true;
drm_crtc_init_with_planes(dev, crtc, plane, cursor_plane,
+ cursor_plane ?
+ &mdp5_crtc_no_lm_cursor_funcs :
&mdp5_crtc_funcs, NULL);
drm_flip_work_init(&mdp5_crtc->unref_cursor_work,
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 129/151] drm/msm/submit: fix overflow check on 64-bit architectures
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (127 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 128/151] drm/msm/mdp5: fix cursor-related warnings Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 130/151] drm/msm/a6xx: Track current ctx by seqno Greg Kroah-Hartman
` (27 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Stephen Boyd, Rob Clark
From: Arnd Bergmann <arnd@arndb.de>
commit 95c58291ee709424557996891926a05a32c5b13a upstream.
The overflow check does causes a warning from clang-14 when 'sz' is a type
that is smaller than size_t:
drivers/gpu/drm/msm/msm_gem_submit.c:217:10: error: result of comparison of constant 18446744073709551615 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (sz == SIZE_MAX) {
Change the type accordingly.
Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210927113632.3849987-1-arnd@kernel.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -161,7 +161,8 @@ out:
static int submit_lookup_cmds(struct msm_gem_submit *submit,
struct drm_msm_gem_submit *args, struct drm_file *file)
{
- unsigned i, sz;
+ unsigned i;
+ size_t sz;
int ret = 0;
for (i = 0; i < args->nr_cmds; i++) {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 130/151] drm/msm/a6xx: Track current ctx by seqno
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (128 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 129/151] drm/msm/submit: fix overflow check on 64-bit architectures Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 131/151] drm/msm/a4xx: fix error handling in a4xx_gpu_init() Greg Kroah-Hartman
` (26 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rob Clark
From: Rob Clark <robdclark@chromium.org>
commit 14eb0cb4e9a7323c8735cf6c681ed8423ce6ae06 upstream.
In theory a context can be destroyed and a new one allocated at the same
address, making the pointer comparision to detect when we don't need to
update the current pagetables invalid. Instead assign a sequence number
to each context on creation, and use this for the check.
Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 11 ++++++++++-
drivers/gpu/drm/msm/msm_drv.c | 3 +++
drivers/gpu/drm/msm/msm_drv.h | 1 +
4 files changed, 17 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -102,7 +102,7 @@ static void a6xx_set_pagetable(struct a6
u32 asid;
u64 memptr = rbmemptr(ring, ttbr0);
- if (ctx == a6xx_gpu->cur_ctx)
+ if (ctx->seqno == a6xx_gpu->cur_ctx_seqno)
return;
if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
@@ -135,7 +135,7 @@ static void a6xx_set_pagetable(struct a6
OUT_PKT7(ring, CP_EVENT_WRITE, 1);
OUT_RING(ring, 0x31);
- a6xx_gpu->cur_ctx = ctx;
+ a6xx_gpu->cur_ctx_seqno = ctx->seqno;
}
static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
@@ -1053,7 +1053,7 @@ static int a6xx_hw_init(struct msm_gpu *
/* Always come up on rb 0 */
a6xx_gpu->cur_ring = gpu->rb[0];
- a6xx_gpu->cur_ctx = NULL;
+ a6xx_gpu->cur_ctx_seqno = 0;
/* Enable the SQE_to start the CP engine */
gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -19,7 +19,16 @@ struct a6xx_gpu {
uint64_t sqe_iova;
struct msm_ringbuffer *cur_ring;
- struct msm_file_private *cur_ctx;
+
+ /**
+ * cur_ctx_seqno:
+ *
+ * The ctx->seqno value of the context with current pgtables
+ * installed. Tracked by seqno rather than pointer value to
+ * avoid dangling pointers, and cases where a ctx can be freed
+ * and a new one created with the same address.
+ */
+ int cur_ctx_seqno;
struct a6xx_gmu gmu;
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -619,6 +619,7 @@ static void load_gpu(struct drm_device *
static int context_init(struct drm_device *dev, struct drm_file *file)
{
+ static atomic_t ident = ATOMIC_INIT(0);
struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx;
@@ -632,6 +633,8 @@ static int context_init(struct drm_devic
ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
file->driver_priv = ctx;
+ ctx->seqno = atomic_inc_return(&ident);
+
return 0;
}
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -59,6 +59,7 @@ struct msm_file_private {
int queueid;
struct msm_gem_address_space *aspace;
struct kref ref;
+ int seqno;
};
enum msm_mdp_plane_property {
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 131/151] drm/msm/a4xx: fix error handling in a4xx_gpu_init()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (129 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 130/151] drm/msm/a6xx: Track current ctx by seqno Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 132/151] drm/msm/a3xx: fix error handling in a3xx_gpu_init() Greg Kroah-Hartman
` (25 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Rob Clark
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 980d74e7d03ccf2eaa11d133416946bd880c7c08 upstream.
This code returns 1 on error instead of a negative error. It leads to
an Oops in the caller. A second problem is that the check for
"if (ret != -ENODATA)" cannot be true because "ret" is set to 1.
Fixes: 5785dd7a8ef0 ("drm/msm: Fix duplicate gpu node in icc summary")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211001125759.GJ2283@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -699,13 +699,14 @@ struct msm_gpu *a4xx_gpu_init(struct drm
}
icc_path = devm_of_icc_get(&pdev->dev, "gfx-mem");
- ret = IS_ERR(icc_path);
- if (ret)
+ if (IS_ERR(icc_path)) {
+ ret = PTR_ERR(icc_path);
goto fail;
+ }
ocmem_icc_path = devm_of_icc_get(&pdev->dev, "ocmem");
- ret = IS_ERR(ocmem_icc_path);
- if (ret) {
+ if (IS_ERR(ocmem_icc_path)) {
+ ret = PTR_ERR(ocmem_icc_path);
/* allow -ENODATA, ocmem icc is optional */
if (ret != -ENODATA)
goto fail;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 132/151] drm/msm/a3xx: fix error handling in a3xx_gpu_init()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (130 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 131/151] drm/msm/a4xx: fix error handling in a4xx_gpu_init() Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 133/151] drm/msm/dsi: dsi_phy_14nm: Take ready-bit into account in poll_for_ready Greg Kroah-Hartman
` (24 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Rob Clark
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 3eda901995371d390ef82d0b6462f4ea8efbcfdf upstream.
These error paths returned 1 on failure, instead of a negative error
code. This would lead to an Oops in the caller. A second problem is
that the check for "if (ret != -ENODATA)" did not work because "ret" was
set to 1.
Fixes: 5785dd7a8ef0 ("drm/msm: Fix duplicate gpu node in icc summary")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211001125904.GK2283@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -571,13 +571,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm
}
icc_path = devm_of_icc_get(&pdev->dev, "gfx-mem");
- ret = IS_ERR(icc_path);
- if (ret)
+ if (IS_ERR(icc_path)) {
+ ret = PTR_ERR(icc_path);
goto fail;
+ }
ocmem_icc_path = devm_of_icc_get(&pdev->dev, "ocmem");
- ret = IS_ERR(ocmem_icc_path);
- if (ret) {
+ if (IS_ERR(ocmem_icc_path)) {
+ ret = PTR_ERR(ocmem_icc_path);
/* allow -ENODATA, ocmem icc is optional */
if (ret != -ENODATA)
goto fail;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 133/151] drm/msm/dsi: dsi_phy_14nm: Take ready-bit into account in poll_for_ready
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (131 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 132/151] drm/msm/a3xx: fix error handling in a3xx_gpu_init() Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 134/151] drm/msm/dsi: Fix an error code in msm_dsi_modeset_init() Greg Kroah-Hartman
` (23 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marijn Suijten, Dmitry Baryshkov, Rob Clark
From: Marijn Suijten <marijn.suijten@somainline.org>
commit 90b7c1c66132c20e8a550006011a3cbfb73dbfc1 upstream.
The downstream driver models this PLL lock check as an if-elseif-else.
The only way to reach the else case where pll_locked=true [1] is by
succeeding both readl_poll_timeout_atomic calls (which return zero on
success) in the if _and_ elseif condition. Hence both the "lock" and
"ready" bit need to be tested in the SM_READY_STATUS register before
considering the PLL locked and ready to go.
Tested on the Sony Xperia XA2 Ultra (nile-discovery, sdm630).
[1]: https://source.codeaurora.org/quic/la/kernel/msm-4.19/tree/drivers/clk/qcom/mdss/mdss-dsi-pll-14nm-util.c?h=LA.UM.9.2.1.r1-08000-sdm660.0#n302
Fixes: f079f6d999cb ("drm/msm/dsi: Add PHY/PLL for 8x96")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210906202552.824598-1-marijn.suijten@somainline.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 30 ++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -110,14 +110,13 @@ static struct dsi_pll_14nm *pll_14nm_lis
static bool pll_14nm_poll_for_ready(struct dsi_pll_14nm *pll_14nm,
u32 nb_tries, u32 timeout_us)
{
- bool pll_locked = false;
+ bool pll_locked = false, pll_ready = false;
void __iomem *base = pll_14nm->phy->pll_base;
u32 tries, val;
tries = nb_tries;
while (tries--) {
- val = dsi_phy_read(base +
- REG_DSI_14nm_PHY_PLL_RESET_SM_READY_STATUS);
+ val = dsi_phy_read(base + REG_DSI_14nm_PHY_PLL_RESET_SM_READY_STATUS);
pll_locked = !!(val & BIT(5));
if (pll_locked)
@@ -126,23 +125,24 @@ static bool pll_14nm_poll_for_ready(stru
udelay(timeout_us);
}
- if (!pll_locked) {
- tries = nb_tries;
- while (tries--) {
- val = dsi_phy_read(base +
- REG_DSI_14nm_PHY_PLL_RESET_SM_READY_STATUS);
- pll_locked = !!(val & BIT(0));
+ if (!pll_locked)
+ goto out;
- if (pll_locked)
- break;
+ tries = nb_tries;
+ while (tries--) {
+ val = dsi_phy_read(base + REG_DSI_14nm_PHY_PLL_RESET_SM_READY_STATUS);
+ pll_ready = !!(val & BIT(0));
- udelay(timeout_us);
- }
+ if (pll_ready)
+ break;
+
+ udelay(timeout_us);
}
- DBG("DSI PLL is %slocked", pll_locked ? "" : "*not* ");
+out:
+ DBG("DSI PLL is %slocked, %sready", pll_locked ? "" : "*not* ", pll_ready ? "" : "*not* ");
- return pll_locked;
+ return pll_locked && pll_ready;
}
static void dsi_pll_14nm_config_init(struct dsi_pll_config *pconf)
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 134/151] drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (132 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 133/151] drm/msm/dsi: dsi_phy_14nm: Take ready-bit into account in poll_for_ready Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 135/151] drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling Greg Kroah-Hartman
` (22 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Dmitry Baryshkov, Rob Clark
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 739b4e7756d3301dd673ca517afca46a5f635562 upstream.
Return an error code if msm_dsi_manager_validate_current_config().
Don't return success.
Fixes: 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211001123308.GF2283@kili
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/dsi/dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,8 +208,10 @@ int msm_dsi_modeset_init(struct msm_dsi
goto fail;
}
- if (!msm_dsi_manager_validate_current_config(msm_dsi->id))
+ if (!msm_dsi_manager_validate_current_config(msm_dsi->id)) {
+ ret = -EINVAL;
goto fail;
+ }
msm_dsi->encoder = encoder;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 135/151] drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (133 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 134/151] drm/msm/dsi: Fix an error code in msm_dsi_modeset_init() Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 136/151] acpi/arm64: fix next_platform_timer() section mismatch error Greg Kroah-Hartman
` (21 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Dmitry Baryshkov, Rob Clark
From: Dan Carpenter <dan.carpenter@oracle.com>
commit c8f01ffc83923a91e8087aaa077de13354a7aa59 upstream.
This disables a lock which wasn't enabled and it does not disable
the first lock in the array.
Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211001123409.GG2283@kili
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -463,7 +463,7 @@ static int dsi_bus_clk_enable(struct msm
return 0;
err:
- for (; i > 0; i--)
+ while (--i >= 0)
clk_disable_unprepare(msm_host->bus_clks[i]);
return ret;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 136/151] acpi/arm64: fix next_platform_timer() section mismatch error
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (134 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 135/151] drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 137/151] platform/x86: intel_scu_ipc: Fix busy loop expiry time Greg Kroah-Hartman
` (20 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jackie Liu, Hanjun Guo, Catalin Marinas
From: Jackie Liu <liuyun01@kylinos.cn>
commit 596143e3aec35c93508d6b7a05ddc999ee209b61 upstream.
Fix modpost Section mismatch error in next_platform_timer().
[...]
WARNING: modpost: vmlinux.o(.text.unlikely+0x26e60): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc
The function next_platform_timer() references
the variable __initdata acpi_gtdt_desc.
This is often because next_platform_timer lacks a __initdata
annotation or the annotation of acpi_gtdt_desc is wrong.
WARNING: modpost: vmlinux.o(.text.unlikely+0x26e64): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc
The function next_platform_timer() references
the variable __initdata acpi_gtdt_desc.
This is often because next_platform_timer lacks a __initdata
annotation or the annotation of acpi_gtdt_desc is wrong.
ERROR: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
make[1]: *** [scripts/Makefile.modpost:59: vmlinux.symvers] Error 1
make[1]: *** Deleting file 'vmlinux.symvers'
make: *** [Makefile:1176: vmlinux] Error 2
[...]
Fixes: a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver")
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Link: https://lore.kernel.org/r/20210823092526.2407526-1-liu.yun@linux.dev
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/arm64/gtdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -36,7 +36,7 @@ struct acpi_gtdt_descriptor {
static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
-static inline void *next_platform_timer(void *platform_timer)
+static inline __init void *next_platform_timer(void *platform_timer)
{
struct acpi_gtdt_header *gh = platform_timer;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 137/151] platform/x86: intel_scu_ipc: Fix busy loop expiry time
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (135 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 136/151] acpi/arm64: fix next_platform_timer() section mismatch error Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 138/151] mqprio: Correct stats in mqprio_dump_class_stats() Greg Kroah-Hartman
` (19 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Prashant Malani, Benson Leung,
Mika Westerberg, Hans de Goede
From: Prashant Malani <pmalani@chromium.org>
commit 41512e4dc0b84525495e784295092592adb87f1b upstream.
The macro IPC_TIMEOUT is already in jiffies (it is also used like that
elsewhere in the file when calling wait_for_completion_timeout()). Don’t
convert it using helper functions for the purposes of calculating the
busy loop expiry time.
Fixes: e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”)
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/intel_scu_ipc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -232,7 +232,7 @@ static inline u32 ipc_data_readl(struct
/* Wait till scu status is busy */
static inline int busy_loop(struct intel_scu_ipc_dev *scu)
{
- unsigned long end = jiffies + msecs_to_jiffies(IPC_TIMEOUT);
+ unsigned long end = jiffies + IPC_TIMEOUT;
do {
u32 status;
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 138/151] mqprio: Correct stats in mqprio_dump_class_stats().
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (136 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 137/151] platform/x86: intel_scu_ipc: Fix busy loop expiry time Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 139/151] mptcp: fix possible stall on recvmsg() Greg Kroah-Hartman
` (18 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, John Fastabend,
Sebastian Andrzej Siewior, Jakub Kicinski
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
commit 14132690860e4d06aa3e1c4d7d8e9866ba7756dd upstream.
Introduction of lockless subqueues broke the class statistics.
Before the change stats were accumulated in `bstats' and `qstats'
on the stack which was then copied to struct gnet_dump.
After the change the `bstats' and `qstats' are initialized to 0
and never updated, yet still fed to gnet_dump. The code updates
the global qdisc->cpu_bstats and qdisc->cpu_qstats instead,
clobbering them. Most likely a copy-paste error from the code in
mqprio_dump().
__gnet_stats_copy_basic() and __gnet_stats_copy_queue() accumulate
the values for per-CPU case but for global stats they overwrite
the value, so only stats from the last loop iteration / tc end up
in sch->[bq]stats.
Use the on-stack [bq]stats variables again and add the stats manually
in the global case.
Fixes: ce679e8df7ed2 ("net: sched: add support for TCQ_F_NOLOCK subqueues to sch_mqprio")
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
https://lore.kernel.org/all/20211007175000.2334713-2-bigeasy@linutronix.de/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sched/sch_mqprio.c | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)
--- a/net/sched/sch_mqprio.c
+++ b/net/sched/sch_mqprio.c
@@ -529,22 +529,28 @@ static int mqprio_dump_class_stats(struc
for (i = tc.offset; i < tc.offset + tc.count; i++) {
struct netdev_queue *q = netdev_get_tx_queue(dev, i);
struct Qdisc *qdisc = rtnl_dereference(q->qdisc);
- struct gnet_stats_basic_cpu __percpu *cpu_bstats = NULL;
- struct gnet_stats_queue __percpu *cpu_qstats = NULL;
spin_lock_bh(qdisc_lock(qdisc));
+
if (qdisc_is_percpu_stats(qdisc)) {
- cpu_bstats = qdisc->cpu_bstats;
- cpu_qstats = qdisc->cpu_qstats;
- }
+ qlen = qdisc_qlen_sum(qdisc);
- qlen = qdisc_qlen_sum(qdisc);
- __gnet_stats_copy_basic(NULL, &sch->bstats,
- cpu_bstats, &qdisc->bstats);
- __gnet_stats_copy_queue(&sch->qstats,
- cpu_qstats,
- &qdisc->qstats,
- qlen);
+ __gnet_stats_copy_basic(NULL, &bstats,
+ qdisc->cpu_bstats,
+ &qdisc->bstats);
+ __gnet_stats_copy_queue(&qstats,
+ qdisc->cpu_qstats,
+ &qdisc->qstats,
+ qlen);
+ } else {
+ qlen += qdisc->q.qlen;
+ bstats.bytes += qdisc->bstats.bytes;
+ bstats.packets += qdisc->bstats.packets;
+ qstats.backlog += qdisc->qstats.backlog;
+ qstats.drops += qdisc->qstats.drops;
+ qstats.requeues += qdisc->qstats.requeues;
+ qstats.overlimits += qdisc->qstats.overlimits;
+ }
spin_unlock_bh(qdisc_lock(qdisc));
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 139/151] mptcp: fix possible stall on recvmsg()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (137 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 138/151] mqprio: Correct stats in mqprio_dump_class_stats() Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 140/151] qed: Fix missing error code in qed_slowpath_start() Greg Kroah-Hartman
` (17 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paolo Abeni, Mat Martineau,
David S. Miller, syzbot+3360da629681aa0d22fe
From: Paolo Abeni <pabeni@redhat.com>
commit 612f71d7328c14369924384ad2170aae2a6abd92 upstream.
recvmsg() can enter an infinite loop if the caller provides the
MSG_WAITALL, the data present in the receive queue is not sufficient to
fulfill the request, and no more data is received by the peer.
When the above happens, mptcp_wait_data() will always return with
no wait, as the MPTCP_DATA_READY flag checked by such function is
set and never cleared in such code path.
Leveraging the above syzbot was able to trigger an RCU stall:
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 0-...!: (10499 ticks this GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1
(t=10500 jiffies g=13089 q=109)
rcu: rcu_preempt kthread starved for 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:28696 pid: 14 ppid: 2 flags:0x00004000
Call Trace:
context_switch kernel/sched/core.c:4955 [inline]
__schedule+0x940/0x26f0 kernel/sched/core.c:6236
schedule+0xd3/0x270 kernel/sched/core.c:6315
schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881
rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1955
rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128
kthread+0x405/0x4f0 kernel/kthread.c:327
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 8510 Comm: syz-executor827 Not tainted 5.15.0-rc2-next-20210920-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [inline]
RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [inline]
RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]
RIP: 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189
Code: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00
RSP: 0018:ffffc9000cd676c8 EFLAGS: 00000283
RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX: ffffffff88ea062a
RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870
RBP: ffffed100e9a110e R08: 0000000000000001 R09: ffff888074d08877
R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000
R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000
FS: 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [inline]
mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016
release_sock+0xb4/0x1b0 net/core/sock.c:3204
mptcp_wait_data net/mptcp/protocol.c:1770 [inline]
mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080
inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659
sock_recvmsg_nosec net/socket.c:944 [inline]
____sys_recvmsg+0x527/0x600 net/socket.c:2626
___sys_recvmsg+0x127/0x200 net/socket.c:2670
do_recvmmsg+0x24d/0x6d0 net/socket.c:2764
__sys_recvmmsg net/socket.c:2843 [inline]
__do_sys_recvmmsg net/socket.c:2866 [inline]
__se_sys_recvmmsg net/socket.c:2859 [inline]
__x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2859
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fc200d2dc39
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc5758e5a8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc200d2dc39
RDX: 0000000000000002 RSI: 00000000200017c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000f0b5ff
R10: 0000000000000100 R11: 0000000000000246 R12: 0000000000000003
R13: 00007ffc5758e5d0 R14: 00007ffc5758e5c0 R15: 0000000000000003
Fix the issue by replacing the MPTCP_DATA_READY bit with direct
inspection of the msk receive queue.
Reported-and-tested-by: syzbot+3360da629681aa0d22fe@syzkaller.appspotmail.com
Fixes: 7a6a6cbc3e59 ("mptcp: recvmsg() can drain data from multiple subflow")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mptcp/protocol.c | 55 +++++++++++++--------------------------------------
1 file changed, 15 insertions(+), 40 deletions(-)
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -515,7 +515,6 @@ static bool mptcp_check_data_fin(struct
sk->sk_shutdown |= RCV_SHUTDOWN;
smp_mb__before_atomic(); /* SHUTDOWN must be visible first */
- set_bit(MPTCP_DATA_READY, &msk->flags);
switch (sk->sk_state) {
case TCP_ESTABLISHED:
@@ -730,10 +729,9 @@ void mptcp_data_ready(struct sock *sk, s
/* Wake-up the reader only for in-sequence data */
mptcp_data_lock(sk);
- if (move_skbs_to_msk(msk, ssk)) {
- set_bit(MPTCP_DATA_READY, &msk->flags);
+ if (move_skbs_to_msk(msk, ssk))
sk->sk_data_ready(sk);
- }
+
mptcp_data_unlock(sk);
}
@@ -838,7 +836,6 @@ static void mptcp_check_for_eof(struct m
sk->sk_shutdown |= RCV_SHUTDOWN;
smp_mb__before_atomic(); /* SHUTDOWN must be visible first */
- set_bit(MPTCP_DATA_READY, &msk->flags);
sk->sk_data_ready(sk);
}
@@ -1701,21 +1698,6 @@ out:
return copied ? : ret;
}
-static void mptcp_wait_data(struct sock *sk, long *timeo)
-{
- DEFINE_WAIT_FUNC(wait, woken_wake_function);
- struct mptcp_sock *msk = mptcp_sk(sk);
-
- add_wait_queue(sk_sleep(sk), &wait);
- sk_set_bit(SOCKWQ_ASYNC_WAITDATA, sk);
-
- sk_wait_event(sk, timeo,
- test_bit(MPTCP_DATA_READY, &msk->flags), &wait);
-
- sk_clear_bit(SOCKWQ_ASYNC_WAITDATA, sk);
- remove_wait_queue(sk_sleep(sk), &wait);
-}
-
static int __mptcp_recvmsg_mskq(struct mptcp_sock *msk,
struct msghdr *msg,
size_t len, int flags,
@@ -2019,19 +2001,7 @@ static int mptcp_recvmsg(struct sock *sk
}
pr_debug("block timeout %ld", timeo);
- mptcp_wait_data(sk, &timeo);
- }
-
- if (skb_queue_empty_lockless(&sk->sk_receive_queue) &&
- skb_queue_empty(&msk->receive_queue)) {
- /* entire backlog drained, clear DATA_READY. */
- clear_bit(MPTCP_DATA_READY, &msk->flags);
-
- /* .. race-breaker: ssk might have gotten new data
- * after last __mptcp_move_skbs() returned false.
- */
- if (unlikely(__mptcp_move_skbs(msk)))
- set_bit(MPTCP_DATA_READY, &msk->flags);
+ sk_wait_data(sk, &timeo, NULL);
}
out_err:
@@ -2040,9 +2010,9 @@ out_err:
tcp_recv_timestamp(msg, sk, &tss);
}
- pr_debug("msk=%p data_ready=%d rx queue empty=%d copied=%d",
- msk, test_bit(MPTCP_DATA_READY, &msk->flags),
- skb_queue_empty_lockless(&sk->sk_receive_queue), copied);
+ pr_debug("msk=%p rx queue empty=%d:%d copied=%d",
+ msk, skb_queue_empty_lockless(&sk->sk_receive_queue),
+ skb_queue_empty(&msk->receive_queue), copied);
if (!(flags & MSG_PEEK))
mptcp_rcv_space_adjust(msk, copied);
@@ -2255,7 +2225,6 @@ static void mptcp_check_fastclose(struct
inet_sk_state_store(sk, TCP_CLOSE);
sk->sk_shutdown = SHUTDOWN_MASK;
smp_mb__before_atomic(); /* SHUTDOWN must be visible first */
- set_bit(MPTCP_DATA_READY, &msk->flags);
set_bit(MPTCP_WORK_CLOSE_SUBFLOW, &msk->flags);
mptcp_close_wake_up(sk);
@@ -3272,8 +3241,14 @@ unlock_fail:
static __poll_t mptcp_check_readable(struct mptcp_sock *msk)
{
- return test_bit(MPTCP_DATA_READY, &msk->flags) ? EPOLLIN | EPOLLRDNORM :
- 0;
+ /* Concurrent splices from sk_receive_queue into receive_queue will
+ * always show at least one non-empty queue when checked in this order.
+ */
+ if (skb_queue_empty_lockless(&((struct sock *)msk)->sk_receive_queue) &&
+ skb_queue_empty_lockless(&msk->receive_queue))
+ return 0;
+
+ return EPOLLIN | EPOLLRDNORM;
}
static __poll_t mptcp_check_writeable(struct mptcp_sock *msk)
@@ -3308,7 +3283,7 @@ static __poll_t mptcp_poll(struct file *
state = inet_sk_state_load(sk);
pr_debug("msk=%p state=%d flags=%lx", msk, state, msk->flags);
if (state == TCP_LISTEN)
- return mptcp_check_readable(msk);
+ return test_bit(MPTCP_DATA_READY, &msk->flags) ? EPOLLIN | EPOLLRDNORM : 0;
if (state != TCP_SYN_SENT && state != TCP_SYN_RECV) {
mask |= mptcp_check_readable(msk);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 140/151] qed: Fix missing error code in qed_slowpath_start()
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (138 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 139/151] mptcp: fix possible stall on recvmsg() Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 141/151] r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256 Greg Kroah-Hartman
` (16 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Abaci Robot, chongjiapeng, David S. Miller
From: chongjiapeng <jiapeng.chong@linux.alibaba.com>
commit a5a14ea7b4e55604acb0dc9d88fdb4cb6945bc77 upstream.
The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'rc'.
Eliminate the follow smatch warning:
drivers/net/ethernet/qlogic/qed/qed_main.c:1298 qed_slowpath_start()
warn: missing error code 'rc'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: d51e4af5c209 ("qed: aRFS infrastructure support")
Signed-off-by: chongjiapeng <jiapeng.chong@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1295,6 +1295,7 @@ static int qed_slowpath_start(struct qed
} else {
DP_NOTICE(cdev,
"Failed to acquire PTT for aRFS\n");
+ rc = -EINVAL;
goto err;
}
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 141/151] r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (139 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 140/151] qed: Fix missing error code in qed_slowpath_start() Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 142/151] ice: fix locking for Tx timestamp tracking flush Greg Kroah-Hartman
` (15 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vegard Nossum, David S. Miller
From: Vegard Nossum <vegard.nossum@oracle.com>
commit 9973a43012b6ad1720dbc4d5faf5302c28635b8c upstream.
Fix the following build/link errors by adding a dependency on
CRYPTO, CRYPTO_HASH, CRYPTO_SHA256 and CRC32:
ld: drivers/net/usb/r8152.o: in function `rtl8152_fw_verify_checksum':
r8152.c:(.text+0x2b2a): undefined reference to `crypto_alloc_shash'
ld: r8152.c:(.text+0x2bed): undefined reference to `crypto_shash_digest'
ld: r8152.c:(.text+0x2c50): undefined reference to `crypto_destroy_tfm'
ld: drivers/net/usb/r8152.o: in function `_rtl8152_set_rx_mode':
r8152.c:(.text+0xdcb0): undefined reference to `crc32_le'
Fixes: 9370f2d05a2a1 ("r8152: support request_firmware for RTL8153")
Fixes: ac718b69301c7 ("net/usb: new driver for RTL8152")
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -99,6 +99,10 @@ config USB_RTL8150
config USB_RTL8152
tristate "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
select MII
+ select CRC32
+ select CRYPTO
+ select CRYPTO_HASH
+ select CRYPTO_SHA256
help
This option adds support for Realtek RTL8152 based USB 2.0
10/100 Ethernet adapters and RTL8153 based USB 3.0 10/100/1000
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 142/151] ice: fix locking for Tx timestamp tracking flush
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (140 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 141/151] r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256 Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 143/151] block/rnbd-clt-sysfs: fix a couple uninitialized variable bugs Greg Kroah-Hartman
` (14 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jacob Keller, Tony Nguyen, David S. Miller
From: Jacob Keller <jacob.e.keller@intel.com>
commit 4d4a223a86afe658cd878800f09458e8bb54415d upstream.
Commit 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush")
added a lock around the Tx timestamp tracker flow which is used to
cleanup any left over SKBs and prepare for device removal.
This lock is problematic because it is being held around a call to
ice_clear_phy_tstamp. The clear function takes a mutex to send a PHY
write command to firmware. This could lead to a deadlock if the mutex
actually sleeps, and causes the following warning on a kernel with
preemption debugging enabled:
[ 715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573
[ 715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod
[ 715.435652] INFO: lockdep is turned off.
[ 715.439591] Preemption disabled at:
[ 715.439594] [<0000000000000000>] 0x0
[ 715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G W OE 5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c
[ 715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[ 715.468483] Call Trace:
[ 715.470940] dump_stack_lvl+0x6a/0x9a
[ 715.474613] ___might_sleep.cold+0x224/0x26a
[ 715.478895] __mutex_lock+0xb3/0x1440
[ 715.482569] ? stack_depot_save+0x378/0x500
[ 715.486763] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.494979] ? kfree+0xc1/0x520
[ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0
[ 715.502837] ? kasan_set_free_info+0x20/0x30
[ 715.507110] ? __kasan_slab_free+0x10b/0x140
[ 715.511385] ? slab_free_freelist_hook+0xc7/0x220
[ 715.516092] ? kfree+0xc1/0x520
[ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.527359] ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.535133] ? pci_device_remove+0xab/0x1d0
[ 715.539318] ? __device_release_driver+0x35b/0x690
[ 715.544110] ? driver_detach+0x214/0x2f0
[ 715.548035] ? bus_remove_driver+0x11d/0x2f0
[ 715.552309] ? pci_unregister_driver+0x26/0x250
[ 715.556840] ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.564799] ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0
[ 715.570554] ? do_syscall_64+0x3b/0x90
[ 715.574303] ? entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 715.579529] ? start_flush_work+0x542/0x8f0
[ 715.583719] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.599960] ? wait_for_completion_io+0x250/0x250
[ 715.604662] ? lock_acquire+0x196/0x200
[ 715.608504] ? do_raw_spin_trylock+0xa5/0x160
[ 715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.620813] ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.628497] ? __debug_check_no_obj_freed+0x1e8/0x3c0
[ 715.633550] ? trace_hardirqs_on+0x1c/0x130
[ 715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.646220] ? do_raw_spin_trylock+0xa5/0x160
[ 715.650581] ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.658797] ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.691037] ? _raw_spin_unlock_irqrestore+0x46/0x73
[ 715.696005] pci_device_remove+0xab/0x1d0
[ 715.700018] __device_release_driver+0x35b/0x690
[ 715.704637] driver_detach+0x214/0x2f0
[ 715.708389] bus_remove_driver+0x11d/0x2f0
[ 715.712489] pci_unregister_driver+0x26/0x250
[ 715.716857] ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[ 715.724637] __do_sys_delete_module.constprop.0+0x2d8/0x4e0
[ 715.730210] ? free_module+0x6d0/0x6d0
[ 715.733963] ? task_work_run+0xe1/0x170
[ 715.737803] ? exit_to_user_mode_loop+0x17f/0x1d0
[ 715.742509] ? rcu_read_lock_sched_held+0x12/0x80
[ 715.747215] ? trace_hardirqs_on+0x1c/0x130
[ 715.751401] do_syscall_64+0x3b/0x90
[ 715.754981] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 715.760033] RIP: 0033:0x7f4dfe59000b
[ 715.763612] Code: 73 01 c3 48 8b 0d 6d 1e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 1e 0c 00 f7 d8 64 89 01 48
[ 715.782357] RSP: 002b:00007ffe8c891708 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 715.789923] RAX: ffffffffffffffda RBX: 00005558a20468b0 RCX: 00007f4dfe59000b
[ 715.797054] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005558a2046918
[ 715.804189] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 715.811319] R10: 00007f4dfe603ac0 R11: 0000000000000206 R12: 00007ffe8c891940
[ 715.818455] R13: 00007ffe8c8920a3 R14: 00005558a20462a0 R15: 00005558a20468b0
Notice that this is the only case where we use the lock in this way. In
the cleanup kthread and work kthread the lock is only taken around the
bit accesses. This was done intentionally to avoid this kind of issue.
The way the lock is used, we only protect ordering of bit sets vs bit
clears. The Tx writers in the hot path don't need to be protected
against the entire kthread loop. The Tx queues threads only need to
ensure that they do not re-use an index that is currently in use. The
cleanup loop does not need to block all new set bits, since it will
re-queue itself if new timestamps are present.
Fix the tracker flow so that it uses the same flow as the standard
cleanup thread. In addition, ensure the in_use bitmap actually gets
cleared properly.
This fixes the warning and also avoids the potential deadlock that might
have occurred otherwise.
Fixes: 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/ice/ice_ptp.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -1324,22 +1324,21 @@ ice_ptp_flush_tx_tracker(struct ice_pf *
{
u8 idx;
- spin_lock(&tx->lock);
-
for (idx = 0; idx < tx->len; idx++) {
u8 phy_idx = idx + tx->quad_offset;
- /* Clear any potential residual timestamp in the PHY block */
- if (!pf->hw.reset_ongoing)
- ice_clear_phy_tstamp(&pf->hw, tx->quad, phy_idx);
-
+ spin_lock(&tx->lock);
if (tx->tstamps[idx].skb) {
dev_kfree_skb_any(tx->tstamps[idx].skb);
tx->tstamps[idx].skb = NULL;
}
- }
+ clear_bit(idx, tx->in_use);
+ spin_unlock(&tx->lock);
- spin_unlock(&tx->lock);
+ /* Clear any potential residual timestamp in the PHY block */
+ if (!pf->hw.reset_ongoing)
+ ice_clear_phy_tstamp(&pf->hw, tx->quad, phy_idx);
+ }
}
/**
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 143/151] block/rnbd-clt-sysfs: fix a couple uninitialized variable bugs
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (141 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 142/151] ice: fix locking for Tx timestamp tracking flush Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 144/151] nfp: flow_offload: move flow_indr_dev_register from app init to app start Greg Kroah-Hartman
` (13 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Gioh Kim, Jens Axboe
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 7904022decc260a19dd65b56ac896387f5da6f8c upstream.
These variables are printed on the error path if match_int() fails so
they have to be initialized.
Fixes: 2958a995edc9 ("block/rnbd-clt: Support polling mode for IO latency optimization")
Fixes: 1eb54f8f5dd8 ("block/rnbd: client: sysfs interface functions")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Gioh Kim <gi-oh.kim@ionos.com>
Link: https://lore.kernel.org/r/20211012084443.GA31472@kili
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/block/rnbd/rnbd-clt-sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/block/rnbd/rnbd-clt-sysfs.c
+++ b/drivers/block/rnbd/rnbd-clt-sysfs.c
@@ -71,8 +71,10 @@ static int rnbd_clt_parse_map_options(co
int opt_mask = 0;
int token;
int ret = -EINVAL;
- int i, dest_port, nr_poll_queues;
+ int nr_poll_queues = 0;
+ int dest_port = 0;
int p_cnt = 0;
+ int i;
options = kstrdup(buf, GFP_KERNEL);
if (!options)
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 144/151] nfp: flow_offload: move flow_indr_dev_register from app init to app start
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (142 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 143/151] block/rnbd-clt-sysfs: fix a couple uninitialized variable bugs Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 145/151] net: mscc: ocelot: make use of all 63 PTP timestamp identifiers Greg Kroah-Hartman
` (12 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Baowen Zheng, Simon Horman,
Louis Peens, Jakub Kicinski
From: Baowen Zheng <baowen.zheng@corigine.com>
commit 60d950f443a52d950126ad664fbd4a1eb8353dc9 upstream.
In commit 74fc4f828769 ("net: Fix offloading indirect devices dependency
on qdisc order creation"), it adds a process to trigger the callback to
setup the bo callback when the driver regists a callback.
In our current implement, we are not ready to run the callback when nfp
call the function flow_indr_dev_register, then there will be error
message as:
kernel: Oops: 0000 [#1] SMP PTI
kernel: CPU: 0 PID: 14119 Comm: kworker/0:0 Tainted: G
kernel: Workqueue: events work_for_cpu_fn
kernel: RIP: 0010:nfp_flower_indr_setup_tc_cb+0x258/0x410
kernel: RSP: 0018:ffffbc1e02c57bf8 EFLAGS: 00010286
kernel: RAX: 0000000000000000 RBX: ffff9c761fabc000 RCX: 0000000000000001
kernel: RDX: 0000000000000001 RSI: fffffffffffffff0 RDI: ffffffffc0be9ef1
kernel: RBP: ffffbc1e02c57c58 R08: ffffffffc08f33aa R09: ffff9c6db7478800
kernel: R10: 0000009c003f6e00 R11: ffffbc1e02800000 R12: ffffbc1e000d9000
kernel: R13: ffffbc1e000db428 R14: ffff9c6db7478800 R15: ffff9c761e884e80
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: fffffffffffffff0 CR3: 00000009e260a004 CR4: 00000000007706f0
kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: PKRU: 55555554
kernel: Call Trace:
kernel: ? flow_indr_dev_register+0xab/0x210
kernel: ? __cond_resched+0x15/0x30
kernel: ? kmem_cache_alloc_trace+0x44/0x4b0
kernel: ? nfp_flower_setup_tc+0x1d0/0x1d0 [nfp]
kernel: flow_indr_dev_register+0x158/0x210
kernel: ? tcf_block_unbind+0xe0/0xe0
kernel: nfp_flower_init+0x40b/0x650 [nfp]
kernel: nfp_net_pci_probe+0x25f/0x960 [nfp]
kernel: ? nfp_rtsym_read_le+0x76/0x130 [nfp]
kernel: nfp_pci_probe+0x6a9/0x820 [nfp]
kernel: local_pci_probe+0x45/0x80
So we need to call flow_indr_dev_register in app start process instead of
init stage.
Fixes: 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation")
Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Louis Peens <louis.peens@corigine.com>
Link: https://lore.kernel.org/r/20211012124850.13025-1-louis.peens@corigine.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/netronome/nfp/flower/main.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/netronome/nfp/flower/main.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.c
@@ -830,10 +830,6 @@ static int nfp_flower_init(struct nfp_ap
if (err)
goto err_cleanup;
- err = flow_indr_dev_register(nfp_flower_indr_setup_tc_cb, app);
- if (err)
- goto err_cleanup;
-
if (app_priv->flower_ext_feats & NFP_FL_FEATS_VF_RLIM)
nfp_flower_qos_init(app);
@@ -942,7 +938,20 @@ static int nfp_flower_start(struct nfp_a
return err;
}
- return nfp_tunnel_config_start(app);
+ err = flow_indr_dev_register(nfp_flower_indr_setup_tc_cb, app);
+ if (err)
+ return err;
+
+ err = nfp_tunnel_config_start(app);
+ if (err)
+ goto err_tunnel_config;
+
+ return 0;
+
+err_tunnel_config:
+ flow_indr_dev_unregister(nfp_flower_indr_setup_tc_cb, app,
+ nfp_flower_setup_indr_tc_release);
+ return err;
}
static void nfp_flower_stop(struct nfp_app *app)
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 145/151] net: mscc: ocelot: make use of all 63 PTP timestamp identifiers
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (143 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 144/151] nfp: flow_offload: move flow_indr_dev_register from app init to app start Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 146/151] net: mscc: ocelot: avoid overflowing the PTP timestamp FIFO Greg Kroah-Hartman
` (11 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit c57fe0037a4e3863d9b740f8c14df9c51ac31aa1 upstream.
At present, there is a problem when user space bombards a port with PTP
event frames which have TX timestamping requests (or when a tc-taprio
offload is installed on a port, which delays the TX timestamps by a
significant amount of time). The driver will happily roll over the 2-bit
timestamp ID and this will cause incorrect matches between an skb and
the TX timestamp collected from the FIFO.
The Ocelot switches have a 6-bit PTP timestamp identifier, and the value
63 is reserved, so that leaves identifiers 0-62 to be used.
The timestamp identifiers are selected by the REW_OP packet field, and
are actually shared between CPU-injected frames and frames which match a
VCAP IS2 rule that modifies the REW_OP. The hardware supports
partitioning between the two uses of the REW_OP field through the
PTP_ID_LOW and PTP_ID_HIGH registers, and by default reserves the PTP
IDs 0-3 for CPU-injected traffic and the rest for VCAP IS2.
The driver does not use VCAP IS2 to set REW_OP for 2-step timestamping,
and it also writes 0xffffffff to both PTP_ID_HIGH and PTP_ID_LOW in
ocelot_init_timestamp() which makes all timestamp identifiers available
to CPU injection.
Therefore, we can make use of all 63 timestamp identifiers, which should
allow more timestampable packets to be in flight on each port. This is
only part of the solution, more issues will be addressed in future changes.
Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mscc/ocelot.c | 4 +++-
include/soc/mscc/ocelot_ptp.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -546,7 +546,9 @@ static void ocelot_port_add_txtstamp_skb
skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
/* Store timestamp ID in OCELOT_SKB_CB(clone)->ts_id */
OCELOT_SKB_CB(clone)->ts_id = ocelot_port->ts_id;
- ocelot_port->ts_id = (ocelot_port->ts_id + 1) % 4;
+ ocelot_port->ts_id++;
+ if (ocelot_port->ts_id == OCELOT_MAX_PTP_ID)
+ ocelot_port->ts_id = 0;
skb_queue_tail(&ocelot_port->tx_skbs, clone);
spin_unlock(&ocelot_port->ts_id_lock);
--- a/include/soc/mscc/ocelot_ptp.h
+++ b/include/soc/mscc/ocelot_ptp.h
@@ -13,6 +13,8 @@
#include <linux/ptp_clock_kernel.h>
#include <soc/mscc/ocelot.h>
+#define OCELOT_MAX_PTP_ID 63
+
#define PTP_PIN_CFG_RSZ 0x20
#define PTP_PIN_TOD_SEC_MSB_RSZ PTP_PIN_CFG_RSZ
#define PTP_PIN_TOD_SEC_LSB_RSZ PTP_PIN_CFG_RSZ
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 146/151] net: mscc: ocelot: avoid overflowing the PTP timestamp FIFO
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (144 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 145/151] net: mscc: ocelot: make use of all 63 PTP timestamp identifiers Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 147/151] net: mscc: ocelot: warn when a PTP IRQ is raised for an unknown skb Greg Kroah-Hartman
` (10 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit 52849bcf0029ccc553be304e4f804938a39112e2 upstream.
PTP packets with 2-step TX timestamp requests are matched to packets
based on the egress port number and a 6-bit timestamp identifier.
All PTP timestamps are held in a common FIFO that is 128 entry deep.
This patch ensures that back-to-back timestamping requests cannot exceed
the hardware FIFO capacity. If that happens, simply send the packets
without requesting a TX timestamp to be taken (in the case of felix,
since the DSA API has a void return code in ds->ops->port_txtstamp) or
drop them (in the case of ocelot).
I've moved the ts_id_lock from a per-port basis to a per-switch basis,
because we need separate accounting for both numbers of PTP frames in
flight. And since we need locking to inc/dec the per-switch counter,
that also offers protection for the per-port counter and hence there is
no reason to have a per-port counter anymore.
Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/ocelot/felix.c | 6 +++++-
drivers/net/ethernet/mscc/ocelot.c | 37 ++++++++++++++++++++++++++++++-------
include/soc/mscc/ocelot.h | 5 ++++-
include/soc/mscc/ocelot_ptp.h | 1 +
4 files changed, 40 insertions(+), 9 deletions(-)
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -1406,8 +1406,12 @@ static void felix_txtstamp(struct dsa_sw
if (!ocelot->ptp)
return;
- if (ocelot_port_txtstamp_request(ocelot, port, skb, &clone))
+ if (ocelot_port_txtstamp_request(ocelot, port, skb, &clone)) {
+ dev_err_ratelimited(ds->dev,
+ "port %d delivering skb without TX timestamp\n",
+ port);
return;
+ }
if (clone)
OCELOT_SKB_CB(skb)->clone = clone;
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -536,22 +536,36 @@ void ocelot_port_disable(struct ocelot *
}
EXPORT_SYMBOL(ocelot_port_disable);
-static void ocelot_port_add_txtstamp_skb(struct ocelot *ocelot, int port,
- struct sk_buff *clone)
+static int ocelot_port_add_txtstamp_skb(struct ocelot *ocelot, int port,
+ struct sk_buff *clone)
{
struct ocelot_port *ocelot_port = ocelot->ports[port];
+ unsigned long flags;
+
+ spin_lock_irqsave(&ocelot->ts_id_lock, flags);
- spin_lock(&ocelot_port->ts_id_lock);
+ if (ocelot_port->ptp_skbs_in_flight == OCELOT_MAX_PTP_ID ||
+ ocelot->ptp_skbs_in_flight == OCELOT_PTP_FIFO_SIZE) {
+ spin_unlock_irqrestore(&ocelot->ts_id_lock, flags);
+ return -EBUSY;
+ }
skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
/* Store timestamp ID in OCELOT_SKB_CB(clone)->ts_id */
OCELOT_SKB_CB(clone)->ts_id = ocelot_port->ts_id;
+
ocelot_port->ts_id++;
if (ocelot_port->ts_id == OCELOT_MAX_PTP_ID)
ocelot_port->ts_id = 0;
+
+ ocelot_port->ptp_skbs_in_flight++;
+ ocelot->ptp_skbs_in_flight++;
+
skb_queue_tail(&ocelot_port->tx_skbs, clone);
- spin_unlock(&ocelot_port->ts_id_lock);
+ spin_unlock_irqrestore(&ocelot->ts_id_lock, flags);
+
+ return 0;
}
u32 ocelot_ptp_rew_op(struct sk_buff *skb)
@@ -600,6 +614,7 @@ int ocelot_port_txtstamp_request(struct
{
struct ocelot_port *ocelot_port = ocelot->ports[port];
u8 ptp_cmd = ocelot_port->ptp_cmd;
+ int err;
/* Store ptp_cmd in OCELOT_SKB_CB(skb)->ptp_cmd */
if (ptp_cmd == IFH_REW_OP_ORIGIN_PTP) {
@@ -617,7 +632,10 @@ int ocelot_port_txtstamp_request(struct
if (!(*clone))
return -ENOMEM;
- ocelot_port_add_txtstamp_skb(ocelot, port, *clone);
+ err = ocelot_port_add_txtstamp_skb(ocelot, port, *clone);
+ if (err)
+ return err;
+
OCELOT_SKB_CB(skb)->ptp_cmd = ptp_cmd;
}
@@ -676,9 +694,14 @@ void ocelot_get_txtstamp(struct ocelot *
id = SYS_PTP_STATUS_PTP_MESS_ID_X(val);
txport = SYS_PTP_STATUS_PTP_MESS_TXPORT_X(val);
- /* Retrieve its associated skb */
port = ocelot->ports[txport];
+ spin_lock(&ocelot->ts_id_lock);
+ port->ptp_skbs_in_flight--;
+ ocelot->ptp_skbs_in_flight--;
+ spin_unlock(&ocelot->ts_id_lock);
+
+ /* Retrieve its associated skb */
spin_lock_irqsave(&port->tx_skbs.lock, flags);
skb_queue_walk_safe(&port->tx_skbs, skb, skb_tmp) {
@@ -1917,7 +1940,6 @@ void ocelot_init_port(struct ocelot *oce
struct ocelot_port *ocelot_port = ocelot->ports[port];
skb_queue_head_init(&ocelot_port->tx_skbs);
- spin_lock_init(&ocelot_port->ts_id_lock);
/* Basic L2 initialization */
@@ -2041,6 +2063,7 @@ int ocelot_init(struct ocelot *ocelot)
mutex_init(&ocelot->stats_lock);
mutex_init(&ocelot->ptp_lock);
spin_lock_init(&ocelot->ptp_clock_lock);
+ spin_lock_init(&ocelot->ts_id_lock);
snprintf(queue_name, sizeof(queue_name), "%s-stats",
dev_name(ocelot->dev));
ocelot->stats_queue = create_singlethread_workqueue(queue_name);
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -600,10 +600,10 @@ struct ocelot_port {
/* The VLAN ID that will be transmitted as untagged, on egress */
struct ocelot_vlan native_vlan;
+ unsigned int ptp_skbs_in_flight;
u8 ptp_cmd;
struct sk_buff_head tx_skbs;
u8 ts_id;
- spinlock_t ts_id_lock;
phy_interface_t phy_mode;
@@ -677,6 +677,9 @@ struct ocelot {
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_info;
struct hwtstamp_config hwtstamp_config;
+ unsigned int ptp_skbs_in_flight;
+ /* Protects the 2-step TX timestamp ID logic */
+ spinlock_t ts_id_lock;
/* Protects the PTP interface state */
struct mutex ptp_lock;
/* Protects the PTP clock */
--- a/include/soc/mscc/ocelot_ptp.h
+++ b/include/soc/mscc/ocelot_ptp.h
@@ -14,6 +14,7 @@
#include <soc/mscc/ocelot.h>
#define OCELOT_MAX_PTP_ID 63
+#define OCELOT_PTP_FIFO_SIZE 128
#define PTP_PIN_CFG_RSZ 0x20
#define PTP_PIN_TOD_SEC_MSB_RSZ PTP_PIN_CFG_RSZ
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 147/151] net: mscc: ocelot: warn when a PTP IRQ is raised for an unknown skb
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (145 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 146/151] net: mscc: ocelot: avoid overflowing the PTP timestamp FIFO Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 148/151] net: mscc: ocelot: deny TX timestamping of non-PTP packets Greg Kroah-Hartman
` (9 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Florian Fainelli,
Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit 9fde506e0c53b8309f69b18b4b8144c544b4b3b1 upstream.
When skb_match is NULL, it means we received a PTP IRQ for a timestamp
ID that the kernel has no idea about, since there is no skb in the
timestamping queue with that timestamp ID.
This is a grave error and not something to just "continue" over.
So print a big warning in case this happens.
Also, move the check above ocelot_get_hwtimestamp(), there is no point
in reading the full 64-bit current PTP time if we're not going to do
anything with it anyway for this skb.
Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mscc/ocelot.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -714,12 +714,12 @@ void ocelot_get_txtstamp(struct ocelot *
spin_unlock_irqrestore(&port->tx_skbs.lock, flags);
+ if (WARN_ON(!skb_match))
+ continue;
+
/* Get the h/w timestamp */
ocelot_get_hwtimestamp(ocelot, &ts);
- if (unlikely(!skb_match))
- continue;
-
/* Set the timestamp into the skb */
memset(&shhwtstamps, 0, sizeof(shhwtstamps));
shhwtstamps.hwtstamp = ktime_set(ts.tv_sec, ts.tv_nsec);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 148/151] net: mscc: ocelot: deny TX timestamping of non-PTP packets
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (146 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 147/151] net: mscc: ocelot: warn when a PTP IRQ is raised for an unknown skb Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 149/151] net: mscc: ocelot: cross-check the sequence id from the timestamp FIFO with the skb PTP header Greg Kroah-Hartman
` (8 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit fba01283d85a09e0e2ef552c6e764b903111d90a upstream.
It appears that Ocelot switches cannot timestamp non-PTP frames,
I tested this using the isochron program at:
https://github.com/vladimiroltean/tsn-scripts
with the result that the driver increments the ocelot_port->ts_id
counter as expected, puts it in the REW_OP, but the hardware seems to
not timestamp these packets at all, since no IRQ is emitted.
Therefore check whether we are sending PTP frames, and refuse to
populate REW_OP otherwise.
Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mscc/ocelot.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -585,16 +585,12 @@ u32 ocelot_ptp_rew_op(struct sk_buff *sk
}
EXPORT_SYMBOL(ocelot_ptp_rew_op);
-static bool ocelot_ptp_is_onestep_sync(struct sk_buff *skb)
+static bool ocelot_ptp_is_onestep_sync(struct sk_buff *skb,
+ unsigned int ptp_class)
{
struct ptp_header *hdr;
- unsigned int ptp_class;
u8 msgtype, twostep;
- ptp_class = ptp_classify_raw(skb);
- if (ptp_class == PTP_CLASS_NONE)
- return false;
-
hdr = ptp_parse_header(skb, ptp_class);
if (!hdr)
return false;
@@ -614,11 +610,20 @@ int ocelot_port_txtstamp_request(struct
{
struct ocelot_port *ocelot_port = ocelot->ports[port];
u8 ptp_cmd = ocelot_port->ptp_cmd;
+ unsigned int ptp_class;
int err;
+ /* Don't do anything if PTP timestamping not enabled */
+ if (!ptp_cmd)
+ return 0;
+
+ ptp_class = ptp_classify_raw(skb);
+ if (ptp_class == PTP_CLASS_NONE)
+ return -EINVAL;
+
/* Store ptp_cmd in OCELOT_SKB_CB(skb)->ptp_cmd */
if (ptp_cmd == IFH_REW_OP_ORIGIN_PTP) {
- if (ocelot_ptp_is_onestep_sync(skb)) {
+ if (ocelot_ptp_is_onestep_sync(skb, ptp_class)) {
OCELOT_SKB_CB(skb)->ptp_cmd = ptp_cmd;
return 0;
}
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 149/151] net: mscc: ocelot: cross-check the sequence id from the timestamp FIFO with the skb PTP header
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (147 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 148/151] net: mscc: ocelot: deny TX timestamping of non-PTP packets Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 150/151] net: dsa: felix: break at first CPU port during init and teardown Greg Kroah-Hartman
` (7 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit ebb4c6a990f786d7e0e4618a0d3766cd660125d8 upstream.
The sad reality is that when a PTP frame with a TX timestamping request
is transmitted, it isn't guaranteed that it will make it all the way to
the wire (due to congestion inside the switch), and that a timestamp
will be taken by the hardware and placed in the timestamp FIFO where an
IRQ will be raised for it.
The implication is that if enough PTP frames are silently dropped by the
hardware such that the timestamp ID has rolled over, it is possible to
match a timestamp to an old skb.
Furthermore, nobody will match on the real skb corresponding to this
timestamp, since we stupidly matched on a previous one that was stale in
the queue, and stopped there.
So PTP timestamping will be broken and there will be no way to recover.
It looks like the hardware parses the sequenceID from the PTP header,
and also provides that metadata for each timestamp. The driver currently
ignores this, but it shouldn't.
As an extra resiliency measure, do the following:
- check whether the PTP sequenceID also matches between the skb and the
timestamp, treat the skb as stale otherwise and free it
- if we see a stale skb, don't stop there and try to match an skb one
more time, chances are there's one more skb in the queue with the same
timestamp ID, otherwise we wouldn't have ever found the stale one (it
is by timestamp ID that we matched it).
While this does not prevent PTP packet drops, it at least prevents
the catastrophic consequences of incorrect timestamp matching.
Since we already call ptp_classify_raw in the TX path, save the result
in the skb->cb of the clone, and just use that result in the interrupt
code path.
Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mscc/ocelot.c | 24 +++++++++++++++++++++++-
include/soc/mscc/ocelot.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -642,6 +642,7 @@ int ocelot_port_txtstamp_request(struct
return err;
OCELOT_SKB_CB(skb)->ptp_cmd = ptp_cmd;
+ OCELOT_SKB_CB(*clone)->ptp_class = ptp_class;
}
return 0;
@@ -675,6 +676,17 @@ static void ocelot_get_hwtimestamp(struc
spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
}
+static bool ocelot_validate_ptp_skb(struct sk_buff *clone, u16 seqid)
+{
+ struct ptp_header *hdr;
+
+ hdr = ptp_parse_header(clone, OCELOT_SKB_CB(clone)->ptp_class);
+ if (WARN_ON(!hdr))
+ return false;
+
+ return seqid == ntohs(hdr->sequence_id);
+}
+
void ocelot_get_txtstamp(struct ocelot *ocelot)
{
int budget = OCELOT_PTP_QUEUE_SZ;
@@ -682,10 +694,10 @@ void ocelot_get_txtstamp(struct ocelot *
while (budget--) {
struct sk_buff *skb, *skb_tmp, *skb_match = NULL;
struct skb_shared_hwtstamps shhwtstamps;
+ u32 val, id, seqid, txport;
struct ocelot_port *port;
struct timespec64 ts;
unsigned long flags;
- u32 val, id, txport;
val = ocelot_read(ocelot, SYS_PTP_STATUS);
@@ -698,6 +710,7 @@ void ocelot_get_txtstamp(struct ocelot *
/* Retrieve the ts ID and Tx port */
id = SYS_PTP_STATUS_PTP_MESS_ID_X(val);
txport = SYS_PTP_STATUS_PTP_MESS_TXPORT_X(val);
+ seqid = SYS_PTP_STATUS_PTP_MESS_SEQ_ID(val);
port = ocelot->ports[txport];
@@ -707,6 +720,7 @@ void ocelot_get_txtstamp(struct ocelot *
spin_unlock(&ocelot->ts_id_lock);
/* Retrieve its associated skb */
+try_again:
spin_lock_irqsave(&port->tx_skbs.lock, flags);
skb_queue_walk_safe(&port->tx_skbs, skb, skb_tmp) {
@@ -722,6 +736,14 @@ void ocelot_get_txtstamp(struct ocelot *
if (WARN_ON(!skb_match))
continue;
+ if (!ocelot_validate_ptp_skb(skb_match, seqid)) {
+ dev_err_ratelimited(ocelot->dev,
+ "port %d received stale TX timestamp for seqid %d, discarding\n",
+ txport, seqid);
+ dev_kfree_skb_any(skb);
+ goto try_again;
+ }
+
/* Get the h/w timestamp */
ocelot_get_hwtimestamp(ocelot, &ts);
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -694,6 +694,7 @@ struct ocelot_policer {
struct ocelot_skb_cb {
struct sk_buff *clone;
+ unsigned int ptp_class; /* valid only for clones */
u8 ptp_cmd;
u8 ts_id;
};
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 150/151] net: dsa: felix: break at first CPU port during init and teardown
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (148 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 149/151] net: mscc: ocelot: cross-check the sequence id from the timestamp FIFO with the skb PTP header Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 13:25 ` [PATCH 5.14 151/151] ionic: dont remove netdev->dev_addr when syncing uc list Greg Kroah-Hartman
` (6 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vladimir Oltean, Florian Fainelli,
Jakub Kicinski
From: Vladimir Oltean <vladimir.oltean@nxp.com>
commit 8d5f7954b7c8de54902a8beda141064a7e2e6ee0 upstream.
The NXP LS1028A switch has two Ethernet ports towards the CPU, but only
one of them is capable of acting as an NPI port at a time (inject and
extract packets using DSA tags).
However, using the alternative ocelot-8021q tagging protocol, it should
be possible to use both CPU ports symmetrically, but for that we need to
mark both ports in the device tree as DSA masters.
In the process of doing that, it can be seen that traffic to/from the
network stack gets broken, and this is because the Felix driver iterates
through all DSA CPU ports and configures them as NPI ports. But since
there can only be a single NPI port, we effectively end up in a
situation where DSA thinks the default CPU port is the first one, but
the hardware port configured to be an NPI is the last one.
I would like to treat this as a bug, because if the updated device trees
are going to start circulating, it would be really good for existing
kernels to support them, too.
Fixes: adb3dccf090b ("net: dsa: felix: convert to the new .change_tag_protocol DSA API")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/ocelot/felix.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -271,12 +271,12 @@ static void felix_8021q_cpu_port_deinit(
*/
static int felix_setup_mmio_filtering(struct felix *felix)
{
- unsigned long user_ports = 0, cpu_ports = 0;
+ unsigned long user_ports = dsa_user_ports(felix->ds);
struct ocelot_vcap_filter *redirect_rule;
struct ocelot_vcap_filter *tagging_rule;
struct ocelot *ocelot = &felix->ocelot;
struct dsa_switch *ds = felix->ds;
- int port, ret;
+ int cpu = -1, port, ret;
tagging_rule = kzalloc(sizeof(struct ocelot_vcap_filter), GFP_KERNEL);
if (!tagging_rule)
@@ -289,12 +289,15 @@ static int felix_setup_mmio_filtering(st
}
for (port = 0; port < ocelot->num_phys_ports; port++) {
- if (dsa_is_user_port(ds, port))
- user_ports |= BIT(port);
- if (dsa_is_cpu_port(ds, port))
- cpu_ports |= BIT(port);
+ if (dsa_is_cpu_port(ds, port)) {
+ cpu = port;
+ break;
+ }
}
+ if (cpu < 0)
+ return -EINVAL;
+
tagging_rule->key_type = OCELOT_VCAP_KEY_ETYPE;
*(__be16 *)tagging_rule->key.etype.etype.value = htons(ETH_P_1588);
*(__be16 *)tagging_rule->key.etype.etype.mask = htons(0xffff);
@@ -330,7 +333,7 @@ static int felix_setup_mmio_filtering(st
* the CPU port module
*/
redirect_rule->action.mask_mode = OCELOT_MASK_MODE_REDIRECT;
- redirect_rule->action.port_mask = cpu_ports;
+ redirect_rule->action.port_mask = BIT(cpu);
} else {
/* Trap PTP packets only to the CPU port module (which is
* redirected to the NPI port)
@@ -1241,6 +1244,7 @@ static int felix_setup(struct dsa_switch
* there's no real point in checking for errors.
*/
felix_set_tag_protocol(ds, port, felix->tag_proto);
+ break;
}
ds->mtu_enforcement_ingress = true;
@@ -1277,6 +1281,7 @@ static void felix_teardown(struct dsa_sw
continue;
felix_del_tag_protocol(ds, port, felix->tag_proto);
+ break;
}
ocelot_devlink_sb_unregister(ocelot);
^ permalink raw reply [flat|nested] 167+ messages in thread* [PATCH 5.14 151/151] ionic: dont remove netdev->dev_addr when syncing uc list
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (149 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 150/151] net: dsa: felix: break at first CPU port during init and teardown Greg Kroah-Hartman
@ 2021-10-18 13:25 ` Greg Kroah-Hartman
2021-10-18 15:41 ` [PATCH 5.14 000/151] 5.14.14-rc1 review Fox Chen
` (5 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-18 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Shannon Nelson, David S. Miller
From: Shannon Nelson <snelson@pensando.io>
commit 5c976a56570f29aaf4a2f9a1bf99789c252183c9 upstream.
Bridging, and possibly other upper stack gizmos, adds the
lower device's netdev->dev_addr to its own uc list, and
then requests it be deleted when the upper bridge device is
removed. This delete request also happens with the bridging
vlan_filtering is enabled and then disabled.
Bonding has a similar behavior with the uc list, but since it
also uses set_mac to manage netdev->dev_addr, it doesn't have
the same the failure case.
Because we store our netdev->dev_addr in our uc list, we need
to ignore the delete request from dev_uc_sync so as to not
lose the address and all hope of communicating. Note that
ndo_set_mac_address is expressly changing netdev->dev_addr,
so no limitation is set there.
Fixes: 2a654540be10 ("ionic: Add Rx filter and rx_mode ndo support")
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/pensando/ionic/ionic_lif.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
@@ -1357,6 +1357,10 @@ static int ionic_addr_add(struct net_dev
static int ionic_addr_del(struct net_device *netdev, const u8 *addr)
{
+ /* Don't delete our own address from the uc list */
+ if (ether_addr_equal(addr, netdev->dev_addr))
+ return 0;
+
return ionic_lif_addr(netdev_priv(netdev), addr, DEL_ADDR);
}
^ permalink raw reply [flat|nested] 167+ messages in thread* RE: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (150 preceding siblings ...)
2021-10-18 13:25 ` [PATCH 5.14 151/151] ionic: dont remove netdev->dev_addr when syncing uc list Greg Kroah-Hartman
@ 2021-10-18 15:41 ` Fox Chen
2021-10-18 20:58 ` Shuah Khan
` (4 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Fox Chen @ 2021-10-18 15:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, stable, Fox Chen
On Mon, 18 Oct 2021 15:22:59 +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 5.14.14 release.
> There are 151 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, 20 Oct 2021 13:23:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.14.14-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <foxhlchen@gmail.com>
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (151 preceding siblings ...)
2021-10-18 15:41 ` [PATCH 5.14 000/151] 5.14.14-rc1 review Fox Chen
@ 2021-10-18 20:58 ` Shuah Khan
2021-10-18 21:37 ` Florian Fainelli
` (3 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Shuah Khan @ 2021-10-18 20:58 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable, Shuah Khan
On 10/18/21 7:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.14.14 release.
> There are 151 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, 20 Oct 2021 13:23:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (152 preceding siblings ...)
2021-10-18 20:58 ` Shuah Khan
@ 2021-10-18 21:37 ` Florian Fainelli
2021-10-18 23:40 ` Guenter Roeck
` (2 subsequent siblings)
156 siblings, 0 replies; 167+ messages in thread
From: Florian Fainelli @ 2021-10-18 21:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On 10/18/21 6:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.14.14 release.
> There are 151 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, 20 Oct 2021 13:23:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (153 preceding siblings ...)
2021-10-18 21:37 ` Florian Fainelli
@ 2021-10-18 23:40 ` Guenter Roeck
2021-10-19 6:11 ` Greg Kroah-Hartman
2021-10-19 3:38 ` Naresh Kamboju
2021-10-19 6:09 ` Jon Hunter
156 siblings, 1 reply; 167+ messages in thread
From: Guenter Roeck @ 2021-10-18 23:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuah, patches, lkft-triage, pavel, jonathanh,
f.fainelli, stable
On 10/18/21 6:22 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.14.14 release.
> There are 151 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, 20 Oct 2021 13:23:15 +0000.
> Anything received after that time might be too late.
>
Building arm64:allmodconfig ... failed
--------------
Error log:
drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int (*)(struct device *)' from incompatible pointer type 'void (*)(struct device *)' [-Werror=incompatible-pointer-types]
96 | .remove = ffa_device_remove,
| ^~~~~~~~~~~~~~~~~
drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for 'ffa_bus_type.remove')
Guenter
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 23:40 ` Guenter Roeck
@ 2021-10-19 6:11 ` Greg Kroah-Hartman
0 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-19 6:11 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable
On Mon, Oct 18, 2021 at 04:40:03PM -0700, Guenter Roeck wrote:
> On 10/18/21 6:22 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.14.14 release.
> > There are 151 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, 20 Oct 2021 13:23:15 +0000.
> > Anything received after that time might be too late.
> >
>
> Building arm64:allmodconfig ... failed
> --------------
> Error log:
> drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int (*)(struct device *)' from incompatible pointer type 'void (*)(struct device *)' [-Werror=incompatible-pointer-types]
> 96 | .remove = ffa_device_remove,
> | ^~~~~~~~~~~~~~~~~
> drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for 'ffa_bus_type.remove')
Ah, function type changes, I'll go fix this up now and push out a -rc2.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (154 preceding siblings ...)
2021-10-18 23:40 ` Guenter Roeck
@ 2021-10-19 3:38 ` Naresh Kamboju
2021-10-19 6:13 ` Greg Kroah-Hartman
2021-10-19 6:09 ` Jon Hunter
156 siblings, 1 reply; 167+ messages in thread
From: Naresh Kamboju @ 2021-10-19 3:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sudeep Holla
Cc: open list, Shuah Khan, Florian Fainelli, patches, lkft-triage,
Jon Hunter, linux-stable, Pavel Machek, Andrew Morton,
Linus Torvalds, Guenter Roeck, Jens Wiklander
On Mon, 18 Oct 2021 at 19:08, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.14.14 release.
> There are 151 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, 20 Oct 2021 13:23:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Following build errors noticed while building Linux stable rc 5.14
with gcc-11 allmodconfig for arm64 architecture.
- 5.14.14 gcc-11 arm64 allmodconfig FAILED
> Sudeep Holla <sudeep.holla@arm.com>
> firmware: arm_ffa: Add missing remove callback to ffa_bus_type
drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int
(*)(struct device *)' from incompatible pointer type 'void (*)(struct
device *)' [-Werror=incompatible-pointer-types]
96 | .remove = ffa_device_remove,
| ^~~~~~~~~~~~~~~~~
drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for
'ffa_bus_type.remove')
cc1: some warnings being treated as errors
Build config:
https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/config
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
steps to reproduce:
https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/tuxmake_reproducer.sh
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-19 3:38 ` Naresh Kamboju
@ 2021-10-19 6:13 ` Greg Kroah-Hartman
2021-10-19 6:34 ` Naresh Kamboju
2021-10-19 9:18 ` Sudeep Holla
0 siblings, 2 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-19 6:13 UTC (permalink / raw)
To: Naresh Kamboju
Cc: Sudeep Holla, open list, Shuah Khan, Florian Fainelli, patches,
lkft-triage, Jon Hunter, linux-stable, Pavel Machek,
Andrew Morton, Linus Torvalds, Guenter Roeck, Jens Wiklander
On Tue, Oct 19, 2021 at 09:08:08AM +0530, Naresh Kamboju wrote:
> On Mon, 18 Oct 2021 at 19:08, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.14.14 release.
> > There are 151 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, 20 Oct 2021 13:23:15 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Following build errors noticed while building Linux stable rc 5.14
> with gcc-11 allmodconfig for arm64 architecture.
>
> - 5.14.14 gcc-11 arm64 allmodconfig FAILED
>
> > Sudeep Holla <sudeep.holla@arm.com>
> > firmware: arm_ffa: Add missing remove callback to ffa_bus_type
>
> drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int
> (*)(struct device *)' from incompatible pointer type 'void (*)(struct
> device *)' [-Werror=incompatible-pointer-types]
> 96 | .remove = ffa_device_remove,
> | ^~~~~~~~~~~~~~~~~
> drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for
> 'ffa_bus_type.remove')
> cc1: some warnings being treated as errors
>
> Build config:
> https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/config
>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Thanks, will go fix this up now.
> steps to reproduce:
> https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/tuxmake_reproducer.sh
Hm, no, those steps fail for me:
$ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-11 --kconfig allmodconfig
E: Unsupported architecture/toolchain combination: arm64/gcc-11
What did I do wrong?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-19 6:13 ` Greg Kroah-Hartman
@ 2021-10-19 6:34 ` Naresh Kamboju
2021-10-19 6:47 ` Greg Kroah-Hartman
2021-10-19 9:18 ` Sudeep Holla
1 sibling, 1 reply; 167+ messages in thread
From: Naresh Kamboju @ 2021-10-19 6:34 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sudeep Holla, open list, Shuah Khan, Florian Fainelli, patches,
lkft-triage, Jon Hunter, linux-stable, Pavel Machek,
Andrew Morton, Linus Torvalds, Guenter Roeck, Jens Wiklander
On Tue, 19 Oct 2021 at 11:43, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Oct 19, 2021 at 09:08:08AM +0530, Naresh Kamboju wrote:
> > On Mon, 18 Oct 2021 at 19:08, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.14.14 release.
> > > There are 151 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, 20 Oct 2021 13:23:15 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Following build errors noticed while building Linux stable rc 5.14
> > with gcc-11 allmodconfig for arm64 architecture.
> >
> > - 5.14.14 gcc-11 arm64 allmodconfig FAILED
> >
> > > Sudeep Holla <sudeep.holla@arm.com>
> > > firmware: arm_ffa: Add missing remove callback to ffa_bus_type
> >
> > drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int
> > (*)(struct device *)' from incompatible pointer type 'void (*)(struct
> > device *)' [-Werror=incompatible-pointer-types]
> > 96 | .remove = ffa_device_remove,
> > | ^~~~~~~~~~~~~~~~~
> > drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for
> > 'ffa_bus_type.remove')
> > cc1: some warnings being treated as errors
> >
> > Build config:
> > https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/config
> >
> > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
> Thanks, will go fix this up now.
>
> > steps to reproduce:
> > https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/tuxmake_reproducer.sh
>
> Hm, no, those steps fail for me:
> $ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-11 --kconfig allmodconfig
> E: Unsupported architecture/toolchain combination: arm64/gcc-11
>
> What did I do wrong?
May i request to force install and try,
$ pip install --force-reinstall tuxmake
$ tuxmake --version # this should get tuxmake 0.29.0
$ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-11
--kconfig allmodconfig
- Naresh
^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-19 6:34 ` Naresh Kamboju
@ 2021-10-19 6:47 ` Greg Kroah-Hartman
2021-10-19 13:04 ` Antonio Terceiro
0 siblings, 1 reply; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-19 6:47 UTC (permalink / raw)
To: Naresh Kamboju
Cc: Sudeep Holla, open list, Shuah Khan, Florian Fainelli, patches,
lkft-triage, Jon Hunter, linux-stable, Pavel Machek,
Andrew Morton, Linus Torvalds, Guenter Roeck, Jens Wiklander
On Tue, Oct 19, 2021 at 12:04:13PM +0530, Naresh Kamboju wrote:
> On Tue, 19 Oct 2021 at 11:43, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Oct 19, 2021 at 09:08:08AM +0530, Naresh Kamboju wrote:
> > > On Mon, 18 Oct 2021 at 19:08, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > This is the start of the stable review cycle for the 5.14.14 release.
> > > > There are 151 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, 20 Oct 2021 13:23:15 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > > The whole patch series can be found in one patch at:
> > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > Following build errors noticed while building Linux stable rc 5.14
> > > with gcc-11 allmodconfig for arm64 architecture.
> > >
> > > - 5.14.14 gcc-11 arm64 allmodconfig FAILED
> > >
> > > > Sudeep Holla <sudeep.holla@arm.com>
> > > > firmware: arm_ffa: Add missing remove callback to ffa_bus_type
> > >
> > > drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int
> > > (*)(struct device *)' from incompatible pointer type 'void (*)(struct
> > > device *)' [-Werror=incompatible-pointer-types]
> > > 96 | .remove = ffa_device_remove,
> > > | ^~~~~~~~~~~~~~~~~
> > > drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for
> > > 'ffa_bus_type.remove')
> > > cc1: some warnings being treated as errors
> > >
> > > Build config:
> > > https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/config
> > >
> > > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> >
> > Thanks, will go fix this up now.
> >
> > > steps to reproduce:
> > > https://builds.tuxbuild.com/1zhYTWmjxG50Rb8sGtfneME9kLT/tuxmake_reproducer.sh
> >
> > Hm, no, those steps fail for me:
> > $ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-11 --kconfig allmodconfig
> > E: Unsupported architecture/toolchain combination: arm64/gcc-11
> >
> > What did I do wrong?
>
> May i request to force install and try,
>
> $ pip install --force-reinstall tuxmake
> $ tuxmake --version # this should get tuxmake 0.29.0
> $ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-11
> --kconfig allmodconfig
Ah much better, I had an older version of tuxmake here.
Now it fails with an expected permission problem:
Error: writing blob: adding layer with blob "sha256:10348114f214e2f07f30fa82aaa743c1750b2a9025cc8bec19f3f4f2b087a96d": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument
E: Runtime preparation failed: failed to pull remote image docker.io/tuxmake/arm64_gcc-11
Note, I will not run kernel builds or random containers downloaded from
the internet as root, sorry :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-19 6:47 ` Greg Kroah-Hartman
@ 2021-10-19 13:04 ` Antonio Terceiro
0 siblings, 0 replies; 167+ messages in thread
From: Antonio Terceiro @ 2021-10-19 13:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Naresh Kamboju, Sudeep Holla, open list, Shuah Khan,
Florian Fainelli, patches, lkft-triage, Jon Hunter, linux-stable,
Pavel Machek, Andrew Morton, Linus Torvalds, Guenter Roeck,
Jens Wiklander
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
Hi,
On Tue, Oct 19, 2021 at 08:47:58AM +0200, Greg Kroah-Hartman wrote:
> Ah much better, I had an older version of tuxmake here.
>
> Now it fails with an expected permission problem:
> Error: writing blob: adding layer with blob "sha256:10348114f214e2f07f30fa82aaa743c1750b2a9025cc8bec19f3f4f2b087a96d": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid: lchown /etc/gshadow: invalid argument
> E: Runtime preparation failed: failed to pull remote image docker.io/tuxmake/arm64_gcc-11
>
> Note, I will not run kernel builds or random containers downloaded from
> the internet as root, sorry :)
Note that podman does *not* run as root by default¹, and that's why
tuxbuild recommends it instead of docker. What it does need, is the
ability to create an unprivileged user namespace. This includes:
- having the `kernel.unprivileged_userns_clone` sysctl set to 1
- having enough UIDs and GIDs in the /etc/sub*id mappings, which is the
error message you got is complaining about. Just having the following
lines should be enough:
$ grep -H terceiro /etc/sub*id
/etc/subgid:terceiro:100000:65536
/etc/subuid:terceiro:100000:65536
On Debian, those are added by default when you created an user
account. I'm not sure about other systems.
¹ by default in a podman container you are root from the POV of the
container, but uid 0 in the container is actually mapped to your regular
UID on the host system.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-19 6:13 ` Greg Kroah-Hartman
2021-10-19 6:34 ` Naresh Kamboju
@ 2021-10-19 9:18 ` Sudeep Holla
2021-10-19 9:34 ` Greg Kroah-Hartman
1 sibling, 1 reply; 167+ messages in thread
From: Sudeep Holla @ 2021-10-19 9:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Naresh Kamboju, open list, Shuah Khan, Florian Fainelli, patches,
lkft-triage, Jon Hunter, linux-stable, Pavel Machek,
Andrew Morton, Sudeep Holla, Linus Torvalds, Guenter Roeck,
Jens Wiklander
Hi Greg,
On Tue, Oct 19, 2021 at 08:13:24AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 19, 2021 at 09:08:08AM +0530, Naresh Kamboju wrote:
> > On Mon, 18 Oct 2021 at 19:08, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.14.14 release.
> > > There are 151 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, 20 Oct 2021 13:23:15 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Following build errors noticed while building Linux stable rc 5.14
> > with gcc-11 allmodconfig for arm64 architecture.
> >
> > - 5.14.14 gcc-11 arm64 allmodconfig FAILED
> >
> > > Sudeep Holla <sudeep.holla@arm.com>
> > > firmware: arm_ffa: Add missing remove callback to ffa_bus_type
> >
> > drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int
> > (*)(struct device *)' from incompatible pointer type 'void (*)(struct
> > device *)' [-Werror=incompatible-pointer-types]
> > 96 | .remove = ffa_device_remove,
> > | ^~~~~~~~~~~~~~~~~
> > drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for
> > 'ffa_bus_type.remove')
> > cc1: some warnings being treated as errors
Sorry for that.
Commit fc7a6209d571 ("bus: Make remove callback return void") was merged
in v5.15 I think.
Do you need me to send the patch for v5.14 or you have already fixed it ?
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 167+ messages in thread* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-19 9:18 ` Sudeep Holla
@ 2021-10-19 9:34 ` Greg Kroah-Hartman
0 siblings, 0 replies; 167+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-19 9:34 UTC (permalink / raw)
To: Sudeep Holla
Cc: Naresh Kamboju, open list, Shuah Khan, Florian Fainelli, patches,
lkft-triage, Jon Hunter, linux-stable, Pavel Machek,
Andrew Morton, Linus Torvalds, Guenter Roeck, Jens Wiklander
On Tue, Oct 19, 2021 at 10:18:18AM +0100, Sudeep Holla wrote:
> Hi Greg,
>
> On Tue, Oct 19, 2021 at 08:13:24AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Oct 19, 2021 at 09:08:08AM +0530, Naresh Kamboju wrote:
> > > On Mon, 18 Oct 2021 at 19:08, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > This is the start of the stable review cycle for the 5.14.14 release.
> > > > There are 151 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, 20 Oct 2021 13:23:15 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > > The whole patch series can be found in one patch at:
> > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > Following build errors noticed while building Linux stable rc 5.14
> > > with gcc-11 allmodconfig for arm64 architecture.
> > >
> > > - 5.14.14 gcc-11 arm64 allmodconfig FAILED
> > >
> > > > Sudeep Holla <sudeep.holla@arm.com>
> > > > firmware: arm_ffa: Add missing remove callback to ffa_bus_type
> > >
> > > drivers/firmware/arm_ffa/bus.c:96:27: error: initialization of 'int
> > > (*)(struct device *)' from incompatible pointer type 'void (*)(struct
> > > device *)' [-Werror=incompatible-pointer-types]
> > > 96 | .remove = ffa_device_remove,
> > > | ^~~~~~~~~~~~~~~~~
> > > drivers/firmware/arm_ffa/bus.c:96:27: note: (near initialization for
> > > 'ffa_bus_type.remove')
> > > cc1: some warnings being treated as errors
>
> Sorry for that.
>
> Commit fc7a6209d571 ("bus: Make remove callback return void") was merged
> in v5.15 I think.
>
> Do you need me to send the patch for v5.14 or you have already fixed it ?
I've already fixed this up, so all is good, no worries!
greg k-h
^ permalink raw reply [flat|nested] 167+ messages in thread
* Re: [PATCH 5.14 000/151] 5.14.14-rc1 review
2021-10-18 13:22 [PATCH 5.14 000/151] 5.14.14-rc1 review Greg Kroah-Hartman
` (155 preceding siblings ...)
2021-10-19 3:38 ` Naresh Kamboju
@ 2021-10-19 6:09 ` Jon Hunter
156 siblings, 0 replies; 167+ messages in thread
From: Jon Hunter @ 2021-10-19 6:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, stable, linux-tegra
On Mon, 18 Oct 2021 15:22:59 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.14.14 release.
> There are 151 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, 20 Oct 2021 13:23:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.14.14-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.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.14:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
114 tests: 114 pass, 0 fail
Linux version: 5.14.14-rc1-g20eb7f403c90
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 167+ messages in thread