All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Louis-Alexis Eyraud" <louisalexis.eyraud@collabora.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org,
	linux-scsi@vger.kernel.org, neil.armstrong@linaro.org,
	olteanv@gmail.com, conor+dt@kernel.org
Subject: Re: [PATCH v11 21/24] scsi: ufs: mediatek: Back up idle timer in per-instance struct
Date: Tue, 01 Sep 2026 16:33:03 +0000	[thread overview]
Message-ID: <20260901163304.6D8841F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901-mt8196-ufs-v11-21-dbd007704490@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] A failed power mode change will permanently disable the auto-hibern8 timer due to brittle backup/restore logic.
- [High] Concurrent sysfs write to `auto_hibern8` races with power mode changes, circumventing hardware constraints and losing user configuration.
--

commit dec217a616e37a6d6c6074f353ace1fc743596e2
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

scsi: ufs: mediatek: Back up idle timer in per-instance struct

The MediaTek UFS driver uses a function-scope static variable to back up
a hardware register across a power change in the
ufs_mtk_pwr_change_notify function. This is dangerous, as it's only
correct if only ever one instance of the driver is loaded, which isn't
true if there's more than one device on a SoC that needs it, or it
otherwise gets loaded a second time.

> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
> index f405f511f41fd..4782fdf54866b 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -1441,27 +1441,24 @@ static int ufs_mtk_pwr_change_notify(struct ufs_hba *hba,
>  				enum ufs_notify_change_status stage,
>  				struct ufs_pa_layer_attr *dev_req_params)
>  {
> -	int ret = 0;
> -	static u32 reg;
> +	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
>  
>  	switch (stage) {
>  	case PRE_CHANGE:
>  		if (ufshcd_is_auto_hibern8_supported(hba)) {
> -			reg = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
> +			host->ahit = ufshcd_readl(
> +				hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
>  			ufs_mtk_auto_hibern8_disable(hba);
>  		}

[Severity: High]
This isn't a bug introduced by this patch, but does this brittle caching logic
risk permanently disabling the auto-hibernate feature?

In ufshcd_change_power_mode(), PRE_CHANGE is called first, which reads the
hardware timer value and disables it. If the subsequent
ufshcd_dme_change_power_mode() fails (e.g., due to a UIC command timeout),
POST_CHANGE is bypassed.

This leaves the hardware timer physically disabled (0).

On the next power mode change attempt, PRE_CHANGE reads the now-disabled
value (0) and overwrites host->ahit with 0. When POST_CHANGE eventually
succeeds, it restores 0, permanently disabling the feature until a reboot.

Could we instead restore from the core driver's hba->ahit, which reliably
tracks the configured value, rather than caching the physical hardware state
here?

> -		ret = ufs_mtk_pre_pwr_change(hba, dev_req_params);
> -		break;
> +		return ufs_mtk_pre_pwr_change(hba, dev_req_params);
>  	case POST_CHANGE:
>  		if (ufshcd_is_auto_hibern8_supported(hba))
> -			ufshcd_writel(hba, reg, REG_AUTO_HIBERNATE_IDLE_TIMER);
> -		break;
> -	default:
> -		ret = -EINVAL;
> -		break;
> +			ufshcd_writel(hba, host->ahit,
> +				      REG_AUTO_HIBERNATE_IDLE_TIMER);

[Severity: High]
This is a pre-existing issue, but does blindly restoring this cached value risk
losing user configuration and violating hardware constraints during a race
with sysfs?

When ufshcd_devfreq_scale() changes power modes, it holds clk_scaling_lock and
scan_mutex, but does not acquire hba->host_sem. Concurrently, a sysfs write to
the auto_hibern8 node invokes auto_hibern8_store(), which updates the hardware
register under hba->host_sem but without holding clk_scaling_lock.

If a sysfs write occurs immediately after PRE_CHANGE disabled the
auto-hibernate timer, the timer is re-enabled during
ufshcd_dme_change_power_mode(), violating the constraint this function is
trying to enforce.

Furthermore, when POST_CHANGE executes, it overwrites the register with the
stale host->ahit value, completely undoing the user's sysfs configuration.

> +		return 0;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-mt8196-ufs-v11-0-dbd007704490@collabora.com?part=21

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Louis-Alexis Eyraud" <louisalexis.eyraud@collabora.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org,
	linux-scsi@vger.kernel.org, neil.armstrong@linaro.org,
	olteanv@gmail.com, conor+dt@kernel.org
Subject: Re: [PATCH v11 21/24] scsi: ufs: mediatek: Back up idle timer in per-instance struct
Date: Tue, 01 Sep 2026 16:33:03 +0000	[thread overview]
Message-ID: <20260901163304.6D8841F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901-mt8196-ufs-v11-21-dbd007704490@collabora.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] A failed power mode change will permanently disable the auto-hibern8 timer due to brittle backup/restore logic.
- [High] Concurrent sysfs write to `auto_hibern8` races with power mode changes, circumventing hardware constraints and losing user configuration.
--

commit dec217a616e37a6d6c6074f353ace1fc743596e2
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

scsi: ufs: mediatek: Back up idle timer in per-instance struct

The MediaTek UFS driver uses a function-scope static variable to back up
a hardware register across a power change in the
ufs_mtk_pwr_change_notify function. This is dangerous, as it's only
correct if only ever one instance of the driver is loaded, which isn't
true if there's more than one device on a SoC that needs it, or it
otherwise gets loaded a second time.

> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
> index f405f511f41fd..4782fdf54866b 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -1441,27 +1441,24 @@ static int ufs_mtk_pwr_change_notify(struct ufs_hba *hba,
>  				enum ufs_notify_change_status stage,
>  				struct ufs_pa_layer_attr *dev_req_params)
>  {
> -	int ret = 0;
> -	static u32 reg;
> +	struct ufs_mtk_host *host = ufshcd_get_variant(hba);
>  
>  	switch (stage) {
>  	case PRE_CHANGE:
>  		if (ufshcd_is_auto_hibern8_supported(hba)) {
> -			reg = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
> +			host->ahit = ufshcd_readl(
> +				hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
>  			ufs_mtk_auto_hibern8_disable(hba);
>  		}

[Severity: High]
This isn't a bug introduced by this patch, but does this brittle caching logic
risk permanently disabling the auto-hibernate feature?

In ufshcd_change_power_mode(), PRE_CHANGE is called first, which reads the
hardware timer value and disables it. If the subsequent
ufshcd_dme_change_power_mode() fails (e.g., due to a UIC command timeout),
POST_CHANGE is bypassed.

This leaves the hardware timer physically disabled (0).

On the next power mode change attempt, PRE_CHANGE reads the now-disabled
value (0) and overwrites host->ahit with 0. When POST_CHANGE eventually
succeeds, it restores 0, permanently disabling the feature until a reboot.

Could we instead restore from the core driver's hba->ahit, which reliably
tracks the configured value, rather than caching the physical hardware state
here?

> -		ret = ufs_mtk_pre_pwr_change(hba, dev_req_params);
> -		break;
> +		return ufs_mtk_pre_pwr_change(hba, dev_req_params);
>  	case POST_CHANGE:
>  		if (ufshcd_is_auto_hibern8_supported(hba))
> -			ufshcd_writel(hba, reg, REG_AUTO_HIBERNATE_IDLE_TIMER);
> -		break;
> -	default:
> -		ret = -EINVAL;
> -		break;
> +			ufshcd_writel(hba, host->ahit,
> +				      REG_AUTO_HIBERNATE_IDLE_TIMER);

[Severity: High]
This is a pre-existing issue, but does blindly restoring this cached value risk
losing user configuration and violating hardware constraints during a race
with sysfs?

When ufshcd_devfreq_scale() changes power modes, it holds clk_scaling_lock and
scan_mutex, but does not acquire hba->host_sem. Concurrently, a sysfs write to
the auto_hibern8 node invokes auto_hibern8_store(), which updates the hardware
register under hba->host_sem but without holding clk_scaling_lock.

If a sysfs write occurs immediately after PRE_CHANGE disabled the
auto-hibernate timer, the timer is re-enabled during
ufshcd_dme_change_power_mode(), violating the constraint this function is
trying to enforce.

Furthermore, when POST_CHANGE executes, it overwrites the register with the
stale host->ahit value, completely undoing the user's sysfs configuration.

> +		return 0;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-mt8196-ufs-v11-0-dbd007704490@collabora.com?part=21

  reply	other threads:[~2026-09-01 16:33 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 15:38 [PATCH v11 00/24] MediaTek UFS Cleanup and MT8196 Enablement Louis-Alexis Eyraud
2026-09-01 15:38 ` Louis-Alexis Eyraud
2026-09-01 15:38 ` [PATCH v11 01/24] dt-bindings: phy: Add mediatek,mt8196-ufsphy variant Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:38 ` [PATCH v11 02/24] dt-bindings: ufs: mediatek,ufs: Complete the binding Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 16:01   ` sashiko-bot
2026-09-01 16:01     ` sashiko-bot
2026-09-01 15:38 ` [PATCH v11 03/24] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:38 ` [PATCH v11 04/24] scsi: ufs: mediatek: Move MTK_SIP_UFS_CONTROL to mtk_sip_svc.h Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:38 ` [PATCH v11 05/24] phy: mediatek: ufs: Add support for resets Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:38 ` [PATCH v11 06/24] scsi: ufs: mediatek: Rework resets Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:58   ` sashiko-bot
2026-09-01 15:58     ` sashiko-bot
2026-09-01 15:38 ` [PATCH v11 07/24] scsi: ufs: mediatek: Rework 0.9V regulator Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:59   ` sashiko-bot
2026-09-01 15:59     ` sashiko-bot
2026-09-01 15:38 ` [PATCH v11 08/24] scsi: ufs: mediatek: Add dual 0.9V supply support Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:59   ` sashiko-bot
2026-09-01 15:59     ` sashiko-bot
2026-09-01 15:38 ` [PATCH v11 09/24] scsi: ufs: mediatek: Rework init function Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 16:08   ` sashiko-bot
2026-09-01 16:08     ` sashiko-bot
2026-09-01 15:38 ` [PATCH v11 10/24] scsi: ufs: mediatek: Rework the crypt-boost stuff Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 15:38 ` [PATCH v11 11/24] scsi: ufs: mediatek: Handle misc host voltage regulators Louis-Alexis Eyraud
2026-09-01 15:38   ` Louis-Alexis Eyraud
2026-09-01 16:11   ` sashiko-bot
2026-09-01 16:11     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 12/24] scsi: ufs: mediatek: Remove undocumented downstream reset cruft Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 15:39 ` [PATCH v11 13/24] scsi: ufs: mediatek: Remove vendor kernel quirks cruft Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 15:39 ` [PATCH v11 14/24] scsi: ufs: mediatek: Use the common PHY framework Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:28   ` sashiko-bot
2026-09-01 16:28     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 15/24] scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 15:39 ` [PATCH v11 16/24] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:16   ` sashiko-bot
2026-09-01 16:16     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 17/24] scsi: ufs: mediatek: Clean up logging prints Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:18   ` sashiko-bot
2026-09-01 16:18     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 18/24] scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 15:39 ` [PATCH v11 19/24] scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 15:39 ` [PATCH v11 20/24] scsi: ufs: mediatek: Rework hardware version reading Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:24   ` sashiko-bot
2026-09-01 16:24     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 21/24] scsi: ufs: mediatek: Back up idle timer in per-instance struct Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:33   ` sashiko-bot [this message]
2026-09-01 16:33     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 22/24] scsi: ufs: mediatek: Remove ret local from link_startup_notify Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:26   ` sashiko-bot
2026-09-01 16:26     ` sashiko-bot
2026-09-01 15:39 ` [PATCH v11 23/24] scsi: ufs: mediatek: Remove undocumented "clk-scale-up-vcore-min" Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 15:39 ` [PATCH v11 24/24] scsi: ufs: mediatek: Add MT8196 compatible, update copyright Louis-Alexis Eyraud
2026-09-01 15:39   ` Louis-Alexis Eyraud
2026-09-01 16:32   ` sashiko-bot
2026-09-01 16:32     ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260901163304.6D8841F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=louisalexis.eyraud@collabora.com \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.