Hi,
I notice a stable-specific regression on Bugzilla [1]. Quoting from it:
> The backport commit to 5.15 branch:
> 9d4f84a15f9c9727bc07f59d9dafc89e65aadb34 "arm64: dts: imx8mp: Add snps,gfladj-refclk-lpm-sel quirk to USB nodes" (from upstream commit 5c3d5ecf48ab06c709c012bf1e8f0c91e1fcd7ad)
> switched from "snps,dis-u2-freeclk-exists-quirk" to "snps,gfladj-refclk-lpm-sel-quirk".
>
> The problem is that the gfladj-refclk-lpm-sel-quirk quirk is not implemented / backported to 5.15 branch.
>
> This commit should be either reverted, or the commit introducing gfladj-refclk-lpm-sel-quirk needs to be merged to 5.15 kernel branch.
>
> As a result of this patch, on Gateworks Venice GW7400 revB board the USB 3.x devices which are connected to the USB Type C port does not enumerate and the following errors are generated:
>
> [ 14.906302] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command
> [ 15.122383] usb 2-1: device not accepting address 2, error -62
> [ 25.282195] xhci-hcd xhci-hcd.0.auto: Abort failed to stop command ring: -110
> [ 25.297408] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
> [ 25.305345] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
> [ 25.311058] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for stop endpoint command
> [ 25.334361] usb usb2-port1: couldn't allocate usb_device
>
> When the commit is reverted the USB 3.x drives works fine.
See Bugzilla for the full thread and attach dmesgs.
Anyway, I'm adding it to regzbot:
#regzbot introduced: 9d4f84a15f9c97 https://bugzilla.kernel.org/show_bug.cgi?id=217670
#regzbot title: regression in USB DWC3 driver due to missing gfladj-refclk-lpm-sel-quirk quirk
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217670
--
An old man doll... just what I always wanted! - Clara
cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and
calls iio_push_to_buffers_with_timestamp() without making sure the
`indio_dev` stays in buffer mode. There is a race if `indio_dev` exits
buffer mode right before cros_ec_sensors_push_data() accesses them.
An use-after-free on `indio_dev->active_scan_mask` was observed. The
call trace:
[...]
_find_next_bit
cros_ec_sensors_push_data
cros_ec_sensorhub_event
blocking_notifier_call_chain
cros_ec_irq_thread
It was caused by a race condition: one thread just freed
`active_scan_mask` at [1]; while another thread tried to access the
memory at [2].
Fix it by calling iio_device_claim_buffer_mode() to ensure the
`indio_dev` can't exit buffer mode during cros_ec_sensors_push_data().
[1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffe…
[2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sen…
Cc: stable(a)vger.kernel.org
Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO")
Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org>
---
Changes from v1(https://patchwork.kernel.org/project/linux-iio/patch/20230828094339.1248…:
- Use iio_device_{claim|release}_buffer_mode() instead of accessing `mlock`.
drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index b72d39fc2434..6bfe5d6847e7 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -190,8 +190,11 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev,
/*
* Ignore samples if the buffer is not set: it is needed if the ODR is
* set but the buffer is not enabled yet.
+ *
+ * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer
+ * is not enabled.
*/
- if (!iio_buffer_enabled(indio_dev))
+ if (iio_device_claim_buffer_mode(indio_dev) < 0)
return 0;
out = (s16 *)st->samples;
@@ -210,6 +213,7 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev,
iio_push_to_buffers_with_timestamp(indio_dev, st->samples,
timestamp + delta);
+ iio_device_release_buffer_mode(indio_dev);
return 0;
}
EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data);
--
2.42.0.rc2.253.gd59a3bf2b4-goog
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon cpu and Nvidia graphics - see below for system specs.
>
> Kernels 6.4.7 & 6.4.8 also compiled from source with identical configs hang with a frozen boot terminal screen after a significant way through the boot sequence (e.g. whilst running /etc/profile). The system may still be running as a sound is emitted when the power button is pressed (only way to escape from the system hang).
>
> The issue seems to be specific to the hardware of this desktop as the problem kernels do boot through to completion on other machines.
>
> A test was done with a different build (from Porteus) of kernel 6.5-RC4 and that did not hang - but kernel 6.4.7 from the same builder hung just like my build.
>
> I apologise that I cannot provide any detailed diagnostics - but I can put diagnostics into /etc/profile and provide screenshots if requested.
>
> Forum thread with more details and screenshots:
> https://forum.puppylinux.com/viewtopic.php?p=95733#p95733
>
> Computer Profile:
> Machine Dell Inc. Precision WorkStation T5400 (version: Not Specified)
> Mainboard Dell Inc. 0RW203 (version: NA)
> • BIOS Dell Inc. A11 | Date: 04/30/2012 | Type: Legacy
> • CPU Intel(R) Xeon(R) CPU E5450 @ 3.00GHz (4 cores)
> • RAM Total: 7955 MB | Used: 1555 MB (19.5%) | Actual Used: 775 MB (9.7%)
> Graphics Resolution: 1366x768 pixels | Display Server: X.Org 21.1.8
> • device-0 NVIDIA Corporation GT218 [NVS 300] [10de:10d8] (rev a2)
> Audio ALSA
> • device-0 Intel Corporation 631xESB/632xESB High Definition Audio Controller [8086:269a] (rev 09)
> • device-1 NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
> Network wlan1
> • device-0 Ethernet: Broadcom Inc. and subsidiaries NetXtreme BCM5754 Gigabit Ethernet PCI Express [14e4:167a] (rev 02)
See Bugzilla for the full thread.
FYI, this is stable-specific regression since it doesn't appear on mainline.
Also, I have asked the reporter to also open the issue on gitlab.freedesktop.org
tracker (as it is the standard for DRM subsystem).
To the reporter (on To: list): It'd been great if you also have netconsole
output on your Bugzilla report, providing that you have another machine
connecting to your problematic one.
Anyway, I'm adding this regression to be tracked by regzbot:
#regzbot introduced: v6.4.6..v6.4.7 https://bugzilla.kernel.org/show_bug.cgi?id=217776
#regzbot link: https://forum.puppylinux.com/viewtopic.php?p=95733#p95733
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217776
--
An old man doll... just what I always wanted! - Clara
Commit abd3ac7902fb ("watchdog: sbsa: Support architecture version 1")
introduced new timer math for watchdog revision 1 with the 48 bit offset
register.
The gwdt->clk and timeout are u32, but the argument being calculated is
u64. Without a cast, the compiler performs u32 operations, truncating
intermediate steps, resulting in incorrect values.
A watchdog revision 1 implementation with a gwdt->clk of 1GHz and a
timeout of 600s writes 3647256576 to the one shot watchdog instead of
300000000000, resulting in the watchdog firing in 3.6s instead of 600s.
Force u64 math by casting the first argument (gwdt->clk) as a u64. Make
the order of operations explicit with parenthesis.
Fixes: abd3ac7902fb ("watchdog: sbsa: Support architecture version 1")
Reported-by: Vanshidhar Konda <vanshikonda(a)os.amperecomputing.com>
Signed-off-by: Darren Hart <darren(a)os.amperecomputing.com>
Cc: Wim Van Sebroeck <wim(a)linux-watchdog.org>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Cc: linux-watchdog(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: <stable(a)vger.kernel.org> # 5.14.x
---
drivers/watchdog/sbsa_gwdt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
index fd3cfdda4949..76527324b63c 100644
--- a/drivers/watchdog/sbsa_gwdt.c
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -153,14 +153,14 @@ static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
timeout = clamp_t(unsigned int, timeout, 1, wdd->max_hw_heartbeat_ms / 1000);
if (action)
- sbsa_gwdt_reg_write(gwdt->clk * timeout, gwdt);
+ sbsa_gwdt_reg_write((u64)gwdt->clk * timeout, gwdt);
else
/*
* In the single stage mode, The first signal (WS0) is ignored,
* the timeout is (WOR * 2), so the WOR should be configured
* to half value of timeout.
*/
- sbsa_gwdt_reg_write(gwdt->clk / 2 * timeout, gwdt);
+ sbsa_gwdt_reg_write(((u64)gwdt->clk / 2) * timeout, gwdt);
return 0;
}
--
2.41.0
The OEMID is an 8-bit binary number that identifies the Device OEM
and/or the Device contents (when used as a distribution media either on
ROM or FLASH Devices). It occupies bits [111:104] in the CID register:
see the eMMC spec JESD84-B51 paragraph 7.2.3.
So it is 8 bits, and has been so since ever - this bug is so ancients I
couldn't even find its source. The furthest I could go is to commit
335eadf2ef6a (sd: initialize SD cards) but its already was wrong. Could
be because in SD its indeed 16 bits (a 2-characters ASCII string).
Another option as pointed out by Alex (offlist), it seems like this
comes from the legacy MMC specs (v3.31 and before).
It is important to fix it because we are using it as one of our quirk's
token, as well as other tools, e.g. the LVFS
(https://github.com/fwupd/fwupd/).
Signed-off-by: Avri Altman <avri.altman(a)wdc.com>
Cc: stable(a)vger.kernel.org
---
Changelog:
v1--v2:
Add Alex's note of the possible origin of this bug.
---
drivers/mmc/core/mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89cd48fcec79..4a4bab9aa726 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -104,7 +104,7 @@ static int mmc_decode_cid(struct mmc_card *card)
case 3: /* MMC v3.1 - v3.3 */
case 4: /* MMC v4 */
card->cid.manfid = UNSTUFF_BITS(resp, 120, 8);
- card->cid.oemid = UNSTUFF_BITS(resp, 104, 16);
+ card->cid.oemid = UNSTUFF_BITS(resp, 104, 8);
card->cid.prod_name[0] = UNSTUFF_BITS(resp, 96, 8);
card->cid.prod_name[1] = UNSTUFF_BITS(resp, 88, 8);
card->cid.prod_name[2] = UNSTUFF_BITS(resp, 80, 8);
--
2.42.0
In the regmap conversion in commit 4ef2774511dc ("hwmon: (nct6775)
Convert register access to regmap API") I reused the 'reg' variable
for all three register reads in the fan speed calculation loop in
nct6775_update_device(), but failed to notice that the value from the
first one (data->REG_FAN[i]) is actually used in the call to
nct6775_select_fan_div() at the end of the loop body. Since that
patch the register value passed to nct6775_select_fan_div() has been
(conditionally) incorrectly clobbered with the value of a different
register than intended, which has in at least some cases resulted in
fan speeds being adjusted down to zero.
Fix this by using dedicated temporaries for the two intermediate
register reads instead of 'reg'.
Signed-off-by: Zev Weiss <zev(a)bewilderbeest.net>
Fixes: 4ef2774511dc ("hwmon: (nct6775) Convert register access to regmap API")
Reported-by: Thomas Zajic <zlatko(a)gmx.at>
Tested-by: Thomas Zajic <zlatko(a)gmx.at>
Cc: stable(a)vger.kernel.org # v5.19+
---
drivers/hwmon/nct6775-core.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/nct6775-core.c b/drivers/hwmon/nct6775-core.c
index b5b81bd83bb1..d928eb8ae5a3 100644
--- a/drivers/hwmon/nct6775-core.c
+++ b/drivers/hwmon/nct6775-core.c
@@ -1614,17 +1614,21 @@ struct nct6775_data *nct6775_update_device(struct device *dev)
data->fan_div[i]);
if (data->has_fan_min & BIT(i)) {
- err = nct6775_read_value(data, data->REG_FAN_MIN[i], ®);
+ u16 tmp;
+
+ err = nct6775_read_value(data, data->REG_FAN_MIN[i], &tmp);
if (err)
goto out;
- data->fan_min[i] = reg;
+ data->fan_min[i] = tmp;
}
if (data->REG_FAN_PULSES[i]) {
- err = nct6775_read_value(data, data->REG_FAN_PULSES[i], ®);
+ u16 tmp;
+
+ err = nct6775_read_value(data, data->REG_FAN_PULSES[i], &tmp);
if (err)
goto out;
- data->fan_pulses[i] = (reg >> data->FAN_PULSE_SHIFT[i]) & 0x03;
+ data->fan_pulses[i] = (tmp >> data->FAN_PULSE_SHIFT[i]) & 0x03;
}
err = nct6775_select_fan_div(dev, data, i, reg);
--
2.42.0