July 2021 - Linux-stable-mirror

[PATCH AUTOSEL 4.14 01/25] spi: Make of_register_spi_device also set the fwnode

by Sasha Levin

From: Charles Keepax <ckeepax(a)opensource.cirrus.com> [ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ] Currently, the SPI core doesn't set the struct device fwnode pointer when it creates a new SPI device. This means when the device is registered the fwnode is NULL and the check in device_add which sets the fwnode->dev pointer is skipped. This wasn't previously an issue, however these two patches: commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the primary device") Added some code to the GPIO core which relies on using that fwnode->dev pointer to determine if a driver is bound to the fwnode and if not bind a stub GPIO driver. This means the GPIO providers behind SPI will get both the expected driver and this stub driver causing the stub driver to fail if it attempts to request any pin configuration. For example on my system: madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3 madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22 madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl gpio_stub_drv gpiochip3: Error applying setting, reverse things back gpio_stub_drv: probe of gpiochip3 failed with error -22 The firmware node on the device created by the GPIO framework is set through the of_node pointer hence things generally actually work, however that fwnode->dev is never set, as the check was skipped at device_add time. This fix appears to match how the I2C subsystem handles the same situation. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.c… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index da71a53b0df7..71f74015efb9 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1670,6 +1670,7 @@ of_register_spi_device(struct spi_controller *ctlr, struct device_node *nc) /* Store a pointer to the node in the device structure */ of_node_get(nc); spi->dev.of_node = nc; + spi->dev.fwnode = of_fwnode_handle(nc); /* Register the new device */ rc = spi_add_device(spi); -- 2.30.2

3 years, 5 months

1
24
0 0

[PATCH AUTOSEL 4.19 01/31] spi: Make of_register_spi_device also set the fwnode

by Sasha Levin

From: Charles Keepax <ckeepax(a)opensource.cirrus.com> [ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ] Currently, the SPI core doesn't set the struct device fwnode pointer when it creates a new SPI device. This means when the device is registered the fwnode is NULL and the check in device_add which sets the fwnode->dev pointer is skipped. This wasn't previously an issue, however these two patches: commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the primary device") Added some code to the GPIO core which relies on using that fwnode->dev pointer to determine if a driver is bound to the fwnode and if not bind a stub GPIO driver. This means the GPIO providers behind SPI will get both the expected driver and this stub driver causing the stub driver to fail if it attempts to request any pin configuration. For example on my system: madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3 madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22 madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl gpio_stub_drv gpiochip3: Error applying setting, reverse things back gpio_stub_drv: probe of gpiochip3 failed with error -22 The firmware node on the device created by the GPIO framework is set through the of_node pointer hence things generally actually work, however that fwnode->dev is never set, as the check was skipped at device_add time. This fix appears to match how the I2C subsystem handles the same situation. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.c… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index bbe33016d371..49f592e433a8 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1678,6 +1678,7 @@ of_register_spi_device(struct spi_controller *ctlr, struct device_node *nc) /* Store a pointer to the node in the device structure */ of_node_get(nc); spi->dev.of_node = nc; + spi->dev.fwnode = of_fwnode_handle(nc); /* Register the new device */ rc = spi_add_device(spi); -- 2.30.2

3 years, 5 months

1
30
0 0

[PATCH AUTOSEL 5.4 01/50] spi: Make of_register_spi_device also set the fwnode

by Sasha Levin

From: Charles Keepax <ckeepax(a)opensource.cirrus.com> [ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ] Currently, the SPI core doesn't set the struct device fwnode pointer when it creates a new SPI device. This means when the device is registered the fwnode is NULL and the check in device_add which sets the fwnode->dev pointer is skipped. This wasn't previously an issue, however these two patches: commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the primary device") Added some code to the GPIO core which relies on using that fwnode->dev pointer to determine if a driver is bound to the fwnode and if not bind a stub GPIO driver. This means the GPIO providers behind SPI will get both the expected driver and this stub driver causing the stub driver to fail if it attempts to request any pin configuration. For example on my system: madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3 madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22 madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl gpio_stub_drv gpiochip3: Error applying setting, reverse things back gpio_stub_drv: probe of gpiochip3 failed with error -22 The firmware node on the device created by the GPIO framework is set through the of_node pointer hence things generally actually work, however that fwnode->dev is never set, as the check was skipped at device_add time. This fix appears to match how the I2C subsystem handles the same situation. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.c… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index f8f3434d5ab1..ac05c9c86488 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1849,6 +1849,7 @@ of_register_spi_device(struct spi_controller *ctlr, struct device_node *nc) /* Store a pointer to the node in the device structure */ of_node_get(nc); spi->dev.of_node = nc; + spi->dev.fwnode = of_fwnode_handle(nc); /* Register the new device */ rc = spi_add_device(spi); -- 2.30.2

3 years, 5 months

1
49
0 0

[PATCH AUTOSEL 5.10 01/70] spi: Make of_register_spi_device also set the fwnode

by Sasha Levin

From: Charles Keepax <ckeepax(a)opensource.cirrus.com> [ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ] Currently, the SPI core doesn't set the struct device fwnode pointer when it creates a new SPI device. This means when the device is registered the fwnode is NULL and the check in device_add which sets the fwnode->dev pointer is skipped. This wasn't previously an issue, however these two patches: commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the primary device") Added some code to the GPIO core which relies on using that fwnode->dev pointer to determine if a driver is bound to the fwnode and if not bind a stub GPIO driver. This means the GPIO providers behind SPI will get both the expected driver and this stub driver causing the stub driver to fail if it attempts to request any pin configuration. For example on my system: madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3 madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22 madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl gpio_stub_drv gpiochip3: Error applying setting, reverse things back gpio_stub_drv: probe of gpiochip3 failed with error -22 The firmware node on the device created by the GPIO framework is set through the of_node pointer hence things generally actually work, however that fwnode->dev is never set, as the check was skipped at device_add time. This fix appears to match how the I2C subsystem handles the same situation. Signed-off-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.c… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/spi/spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 0cf67de741e7..bd8b1f79dce2 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2050,6 +2050,7 @@ of_register_spi_device(struct spi_controller *ctlr, struct device_node *nc) /* Store a pointer to the node in the device structure */ of_node_get(nc); spi->dev.of_node = nc; + spi->dev.fwnode = of_fwnode_handle(nc); /* Register the new device */ rc = spi_add_device(spi); -- 2.30.2

3 years, 5 months

1
69
0 0

[PATCH v2] mt76/mt7915: Fix unsigned compared against zero

by John Wood

The mt7915_dpd_freq_idx() function can return a negative value but this value is assigned to an unsigned variable named idx. Then, the code tests if this variable is less than zero. This can never happen with an unsigned type. So, change the idx type to a signed one. Addresses-Coverity-ID: 1484753 ("Unsigned compared against 0") Fixes: 495184ac91bb8 ("mt76: mt7915: add support for applying pre-calibration data") Signed-off-by: John Wood <john.wood(a)gmx.com> --- Changelog v1 -> v2 - Add Cc to stable(a)vger.kernel.org drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c index b3f14ff67c5a..764f25a828fa 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c @@ -3440,8 +3440,9 @@ int mt7915_mcu_apply_tx_dpd(struct mt7915_phy *phy) { struct mt7915_dev *dev = phy->dev; struct cfg80211_chan_def *chandef = &phy->mt76->chandef; - u16 total = 2, idx, center_freq = chandef->center_freq1; + u16 total = 2, center_freq = chandef->center_freq1; u8 *cal = dev->cal, *eep = dev->mt76.eeprom.data; + int idx; if (!(eep[MT_EE_DO_PRE_CAL] & MT_EE_WIFI_CAL_DPD)) return 0; -- 2.25.1

3 years, 5 months

2
1
0 0

[PATCH] bluetooth/virtio_bt: Fix dereference null return value

by John Wood

The alloc_skb function returns NULL on error. So, test this case and avoid a NULL dereference (skb->data). Addresses-Coverity-ID: 1484718 ("Dereference null return value") Fixes: afd2daa26c7ab ("Bluetooth: Add support for virtio transport driver") Signed-off-by: John Wood <john.wood(a)gmx.com> --- drivers/bluetooth/virtio_bt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c index c804db7e90f8..5f82574236c0 100644 --- a/drivers/bluetooth/virtio_bt.c +++ b/drivers/bluetooth/virtio_bt.c @@ -34,6 +34,8 @@ static int virtbt_add_inbuf(struct virtio_bluetooth *vbt) int err; skb = alloc_skb(1000, GFP_KERNEL); + if (!skb) + return -ENOMEM; sg_init_one(sg, skb->data, 1000); err = virtqueue_add_inbuf(vq, sg, 1, skb, GFP_KERNEL); -- 2.25.1

3 years, 5 months

3
2
0 0

[UPDATE][PATCH] thermal: int340x: processor_thermal: Fix tcc setting

by Srinivas Pandruvada

The following fixes are done for tcc sysfs interface: - TCC is 6 bits only from bit 29-24 - TCC of 0 is valid - When BIT(31) is set, this register is read only - Check for invalid tcc value - Error for negative values Fixes: fdf4f2fb8e899 ("drivers: thermal: processor_thermal_device: Export sysfs interface for TCC offset" Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- Update Added Fixes tag and cc to stable .../processor_thermal_device.c | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c index de4fc640deb0..0f0038af2ad4 100644 --- a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c +++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c @@ -78,24 +78,27 @@ static ssize_t tcc_offset_degree_celsius_show(struct device *dev, if (err) return err; - val = (val >> 24) & 0xff; + val = (val >> 24) & 0x3f; return sprintf(buf, "%d\n", (int)val); } -static int tcc_offset_update(int tcc) +static int tcc_offset_update(unsigned int tcc) { u64 val; int err; - if (!tcc) + if (tcc > 63) return -EINVAL; err = rdmsrl_safe(MSR_IA32_TEMPERATURE_TARGET, &val); if (err) return err; - val &= ~GENMASK_ULL(31, 24); - val |= (tcc & 0xff) << 24; + if (val & BIT(31)) + return -EPERM; + + val &= ~GENMASK_ULL(29, 24); + val |= (tcc & 0x3f) << 24; err = wrmsrl_safe(MSR_IA32_TEMPERATURE_TARGET, val); if (err) @@ -104,14 +107,15 @@ static int tcc_offset_update(int tcc) return 0; } -static int tcc_offset_save; +static unsigned int tcc_offset_save; static ssize_t tcc_offset_degree_celsius_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { + unsigned int tcc; u64 val; - int tcc, err; + int err; err = rdmsrl_safe(MSR_PLATFORM_INFO, &val); if (err) @@ -120,7 +124,7 @@ static ssize_t tcc_offset_degree_celsius_store(struct device *dev, if (!(val & BIT(30))) return -EACCES; - if (kstrtoint(buf, 0, &tcc)) + if (kstrtouint(buf, 0, &tcc)) return -EINVAL; err = tcc_offset_update(tcc); -- 2.27.0

3 years, 5 months

3
3
0 0

[PATCH v3 1/2] userfaultfd: do not untag user pointers

by Peter Collingbourne

If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers"). [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Signed-off-by: Peter Collingbourne <pcc(a)google.com> Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0… Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Cc: <stable(a)vger.kernel.org> # 5.4 --- Documentation/arm64/tagged-address-abi.rst | 25 +++++++++++++++------- fs/userfaultfd.c | 22 +++++++++---------- 2 files changed, 27 insertions(+), 20 deletions(-) diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 459e6b66ff68..737f9d8565a2 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,23 @@ how the user addresses are used by the kernel: 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start`` argument to the ``UFFDIO_REGISTER`` ``ioctl()`` + used on a file descriptor obtained from ``userfaultfd()``, as + fault addresses subsequently obtained by reading the file descriptor + will be untagged, which may otherwise confuse tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index dd7a6c62b56f..7613efe002c1 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1236,23 +1236,21 @@ static __always_inline void wake_userfault(struct userfaultfd_ctx *ctx, } static __always_inline int validate_range(struct mm_struct *mm, - __u64 *start, __u64 len) + __u64 start, __u64 len) { __u64 task_size = mm->task_size; - *start = untagged_addr(*start); - - if (*start & ~PAGE_MASK) + if (start & ~PAGE_MASK) return -EINVAL; if (len & ~PAGE_MASK) return -EINVAL; if (!len) return -EINVAL; - if (*start < mmap_min_addr) + if (start < mmap_min_addr) return -EINVAL; - if (*start >= task_size) + if (start >= task_size) return -EINVAL; - if (len > task_size - *start) + if (len > task_size - start) return -EINVAL; return 0; } @@ -1313,7 +1311,7 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, vm_flags |= VM_UFFD_MINOR; } - ret = validate_range(mm, &uffdio_register.range.start, + ret = validate_range(mm, uffdio_register.range.start, uffdio_register.range.len); if (ret) goto out; @@ -1519,7 +1517,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) goto out; - ret = validate_range(mm, &uffdio_unregister.start, + ret = validate_range(mm, uffdio_unregister.start, uffdio_unregister.len); if (ret) goto out; @@ -1668,7 +1666,7 @@ static int userfaultfd_wake(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_wake, buf, sizeof(uffdio_wake))) goto out; - ret = validate_range(ctx->mm, &uffdio_wake.start, uffdio_wake.len); + ret = validate_range(ctx->mm, uffdio_wake.start, uffdio_wake.len); if (ret) goto out; @@ -1708,7 +1706,7 @@ static int userfaultfd_copy(struct userfaultfd_ctx *ctx, sizeof(uffdio_copy)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_copy.dst, uffdio_copy.len); + ret = validate_range(ctx->mm, uffdio_copy.dst, uffdio_copy.len); if (ret) goto out; /* @@ -1765,7 +1763,7 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx, sizeof(uffdio_zeropage)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_zeropage.range.start, + ret = validate_range(ctx->mm, uffdio_zeropage.range.start, uffdio_zeropage.range.len); if (ret) goto out; -- 2.32.0.93.g670b81a890-goog

3 years, 5 months

2
1
0 0

[PATCH 1/4] media: rc-loopback: return set of valid emitters rather error

by Sean Young

The LIRC_SET_TRANSMITTER_MASK ioctl should return a list valid emitters if an invalid list was passed. Cc: stable(a)vger.kernel.org Signed-off-by: Sean Young <sean(a)mess.org> --- drivers/media/rc/rc-loopback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c index 1ba3f96ffa7d..15212244f83c 100644 --- a/drivers/media/rc/rc-loopback.c +++ b/drivers/media/rc/rc-loopback.c @@ -42,7 +42,7 @@ static int loop_set_tx_mask(struct rc_dev *dev, u32 mask) if ((mask & (RXMASK_REGULAR | RXMASK_LEARNING)) != mask) { dprintk("invalid tx mask: %u\n", mask); - return -EINVAL; + return RXMASK_REGULAR | RXMASK_LEARNING; } dprintk("setting tx mask: %u\n", mask); -- 2.31.1

3 years, 5 months

1
0
0 0

stable-rc/queue/4.14 baseline: 165 runs, 4 regressions (v4.14.238-19-gde73aa6e4dbd)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 165 runs, 4 regressions (v4.14.238-19-gde73aa6e4dbd) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ------------------+-------+---------------+----------+--------------------+------------ meson-gxm-q200 | arm64 | lab-baylibre | gcc-8 | defconfig | 1 rk3288-veyron-jaq | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 3 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.23… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.238-19-gde73aa6e4dbd URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: de73aa6e4dbd33c961e6d36664eaceed6de81101 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ------------------+-------+---------------+----------+--------------------+------------ meson-gxm-q200 | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/60dfa397f8100dcb0f11798f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.238-19-gde73aa6e4d… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.238-19-gde73aa6e4d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/60dfa397f8100dcb0f117990 failing since 123 days (last pass: v4.14.222-11-g13b8482a0f700, first fail: v4.14.222-120-gdc8887cba23e) platform | arch | lab | compiler | defconfig | regressions ------------------+-------+---------------+----------+--------------------+------------ rk3288-veyron-jaq | arm | lab-collabora | gcc-8 | multi_v7_defconfig | 3 Details: https://kernelci.org/test/plan/id/60df8f95c165f742cb11796b Results: 63 PASS, 6 FAIL, 1 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.238-19-gde73aa6e4d… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.238-19-gde73aa6e4d… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.bootrr.rockchip-iodomain-grf-probed: https://kernelci.org/test/case/id/60df8f95c165f742cb117983 failing since 17 days (last pass: v4.14.236-20-gdb14655bb4bf, first fail: v4.14.236-49-gfd4c319f2583) * baseline.bootrr.dwmmc_rockchip-sdio0-probed: https://kernelci.org/test/case/id/60df8f95c165f742cb11799c failing since 17 days (last pass: v4.14.236-20-gdb14655bb4bf, first fail: v4.14.236-49-gfd4c319f2583) * baseline.bootrr.dwmmc_rockchip-sdmmc-probed: https://kernelci.org/test/case/id/60df8f95c165f742cb11799d failing since 17 days (last pass: v4.14.236-20-gdb14655bb4bf, first fail: v4.14.236-49-gfd4c319f2583) 2021-07-02T22:13:20.836178 /lava-4130415/1/../bin/lava-test-case 2021-07-02T22:13:20.841471 [ 12.801494] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=dwmmc_rockchip-sdmmc-probed RESULT=fail>

3 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2021