From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: "Peter Wang (王信友)" <peter.wang@mediatek.com>,
"Chunfeng Yun (云春峰)" <Chunfeng.Yun@mediatek.com>,
"kishon@kernel.org" <kishon@kernel.org>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"chu.stanley@gmail.com" <chu.stanley@gmail.com>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"robh@kernel.org" <robh@kernel.org>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@hansenpartnership.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"vkoul@kernel.org" <vkoul@kernel.org>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Chaotian Jing (井朝天)" <Chaotian.Jing@mediatek.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"kernel@collabora.com" <kernel@collabora.com>,
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>
Subject: Re: [PATCH v3 09/24] scsi: ufs: mediatek: Rework the crypt-boost stuff
Date: Mon, 10 Nov 2025 10:19:25 +0100 [thread overview]
Message-ID: <6210035.lOV4Wx5bFT@workhorse> (raw)
In-Reply-To: <9ae7495023a8562566ff57bd2dfa60524194ee30.camel@mediatek.com>
On Tuesday, 4 November 2025 08:28:18 Central European Standard Time Chaotian Jing (井朝天) wrote:
> On Thu, 2025-10-23 at 21:49 +0200, Nicolas Frattaroli wrote:
> > I don't know whether the crypt-boost functionality as it is currently
> > implemented is even appropriate for mainline. It might be better done
> > in
> > some generic way. But what I do know is that I can rework the code to
> > make it less obtuse.
> >
> > Prefix the boost stuff with the appropriate vendor prefix, remove the
> > pointless clock wrappers, and rework the function.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/ufs/host/ufs-mediatek.c | 91 +++++++++++++++--------------
> > ------------
> > 1 file changed, 32 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-
> > mediatek.c
> > index 131f71145a12..9c0ac72d6e43 100644
> > --- a/drivers/ufs/host/ufs-mediatek.c
> > +++ b/drivers/ufs/host/ufs-mediatek.c
> > @@ -562,21 +562,6 @@ static int ufs_mtk_mphy_power_on(struct ufs_hba
> > *hba, bool on)
> > return 0;
> > }
> >
> > -static int ufs_mtk_get_host_clk(struct device *dev, const char
> > *name,
> > - struct clk **clk_out)
> > -{
> > - struct clk *clk;
> > - int err = 0;
> > -
> > - clk = devm_clk_get(dev, name);
> > - if (IS_ERR(clk))
> > - err = PTR_ERR(clk);
> > - else
> > - *clk_out = clk;
> > -
> > - return err;
> > -}
> > -
> > static void ufs_mtk_boost_crypt(struct ufs_hba *hba, bool boost)
> > {
> > struct ufs_mtk_host *host = ufshcd_get_variant(hba);
> > @@ -633,65 +618,53 @@ static void ufs_mtk_boost_crypt(struct ufs_hba
> > *hba, bool boost)
> > clk_disable_unprepare(cfg->clk_crypt_mux);
> > }
> >
> > -static int ufs_mtk_init_host_clk(struct ufs_hba *hba, const char
> > *name,
> > - struct clk **clk)
> > -{
> > - int ret;
> > -
> > - ret = ufs_mtk_get_host_clk(hba->dev, name, clk);
> > - if (ret) {
> > - dev_info(hba->dev, "%s: failed to get %s: %d",
> > __func__,
> > - name, ret);
> > - }
> > -
> > - return ret;
> > -}
> > -
> > -static void ufs_mtk_init_boost_crypt(struct ufs_hba *hba)
> > +static int ufs_mtk_init_boost_crypt(struct ufs_hba *hba)
> You change the return type but never checked the return value when
> calling this function ?
Yeah, I should probably check the return in ufs_mtk_init_host_caps
instead of continuing on silently.
> > {
> > struct ufs_mtk_host *host = ufshcd_get_variant(hba);
> > struct ufs_mtk_crypt_cfg *cfg;
> > struct device *dev = hba->dev;
> > - struct regulator *reg;
> > - u32 volt;
> > + int ret;
> >
> > - host->crypt = devm_kzalloc(dev, sizeof(*(host->crypt)),
> > - GFP_KERNEL);
> > - if (!host->crypt)
> > - goto disable_caps;
> > + cfg = devm_kzalloc(dev, sizeof(*cfg), GFP_KERNEL);
> > + if (!cfg)
> > + return -ENOMEM;
> >
> > - reg = devm_regulator_get_optional(dev, "dvfsrc-vcore");
> > - if (IS_ERR(reg)) {
> > - dev_info(dev, "failed to get dvfsrc-vcore: %ld",
> > - PTR_ERR(reg));
> > - goto disable_caps;
> > + cfg->reg_vcore = devm_regulator_get_optional(dev, "dvfsrc-
> > vcore");
> > + if (IS_ERR(cfg->reg_vcore)) {
> > + dev_err(dev, "Failed to get dvfsrc-vcore: %pe", cfg-
> > >reg_vcore);
> Since this regulator is optional, why use dev_err ? and why retune an
> error since you never check the return value ?
Because get_optional doesn't mean what you think it means. It means
the function returns -ENODEV if the regulator is absent, instead of
creating a dummy supply. We want to hard error out if the regulator
is absent, because the regulator is needed.
Whether or not the return code is checked makes no functional
difference in this case. If this function exits early,
UFS_MTK_CAP_BOOST_CRYPT_ENGINE isn't added to the host caps,
and the host->crypt member isn't set to cfg.
The return code may be useful for additional logging, which is not
critical to the correctness of the code.
> > + return PTR_ERR(cfg->reg_vcore);
> > }
> >
> > - if (of_property_read_u32(dev->of_node, "boost-crypt-vcore-min",
> > - &volt)) {
> > - dev_info(dev, "failed to get boost-crypt-vcore-min");
> > - goto disable_caps;
> > + ret = of_property_read_u32(dev->of_node, "mediatek,boost-crypt-
> > vcore-min",
> > + &cfg->vcore_volt);
> > + if (ret) {
> > + dev_err(dev, "Failed to get mediatek,boost-crypt-vcore-
> > min: %pe\n",
> > + ERR_PTR(ret));
> > + return ret;
> > }
> >
> > - cfg = host->crypt;
> > - if (ufs_mtk_init_host_clk(hba, "crypt_mux",
> > - &cfg->clk_crypt_mux))
> > - goto disable_caps;
> > + cfg->clk_crypt_mux = devm_clk_get(dev, "crypt_mux");
> > + if (IS_ERR(cfg->clk_crypt_mux)) {
> > + dev_err(dev, "Failed to get clock crypt_mux: %pe\n",
> > cfg->clk_crypt_mux);
> > + return PTR_ERR(cfg->clk_crypt_mux);
> > + }
> >
> > - if (ufs_mtk_init_host_clk(hba, "crypt_lp",
> > - &cfg->clk_crypt_lp))
> > - goto disable_caps;
> > + cfg->clk_crypt_lp = devm_clk_get(dev, "crypt_lp");
> > + if (IS_ERR(cfg->clk_crypt_lp)) {
> > + dev_err(dev, "Failed to get clock crypt_lp: %pe\n",
> > cfg->clk_crypt_lp);
> > + return PTR_ERR(cfg->clk_crypt_lp);
> > + }
> >
> > - if (ufs_mtk_init_host_clk(hba, "crypt_perf",
> > - &cfg->clk_crypt_perf))
> > - goto disable_caps;
> > + cfg->clk_crypt_perf = devm_clk_get(dev, "crypt_perf");
> > + if (IS_ERR(cfg->clk_crypt_perf)) {
> > + dev_err(dev, "Failed to get clock crypt_perf: %pe\n",
> > cfg->clk_crypt_perf);
> > + return PTR_ERR(cfg->clk_crypt_perf);
> > + }
> >
> > - cfg->reg_vcore = reg;
> > - cfg->vcore_volt = volt;
> > + host->crypt = cfg;
> > host->caps |= UFS_MTK_CAP_BOOST_CRYPT_ENGINE;
> >
> > -disable_caps:
> > - return;
> > + return 0;
> > }
> >
> > static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
> >
>
next prev parent reply other threads:[~2025-11-10 9:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 19:49 [PATCH v3 00/24] MediaTek UFS Cleanup and MT8196 Enablement Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 01/24] dt-bindings: phy: Add mediatek,mt8196-ufsphy variant Nicolas Frattaroli
2025-10-24 17:09 ` Conor Dooley
2025-10-23 19:49 ` [PATCH v3 02/24] dt-bindings: ufs: mediatek,ufs: Complete the binding Nicolas Frattaroli
2025-10-24 17:25 ` Conor Dooley
2025-11-04 5:43 ` Chaotian Jing (井朝天)
2025-10-23 19:49 ` [PATCH v3 03/24] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant Nicolas Frattaroli
2025-10-24 17:13 ` Conor Dooley
2025-10-24 17:51 ` Nicolas Frattaroli
2025-10-26 22:25 ` Conor Dooley
2025-10-23 19:49 ` [PATCH v3 04/24] scsi: ufs: mediatek: Move MTK_SIP_UFS_CONTROL to mtk_sip_svc.h Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 05/24] phy: mediatek: ufs: Add support for resets Nicolas Frattaroli
2025-10-24 9:06 ` Philipp Zabel
2025-10-23 19:49 ` [PATCH v3 06/24] scsi: ufs: mediatek: Rework resets Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 07/24] scsi: ufs: mediatek: Rework 0.9V regulator Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 08/24] scsi: ufs: mediatek: Rework init function Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 09/24] scsi: ufs: mediatek: Rework the crypt-boost stuff Nicolas Frattaroli
2025-11-04 7:28 ` Chaotian Jing (井朝天)
2025-11-10 9:19 ` Nicolas Frattaroli [this message]
2025-10-23 19:49 ` [PATCH v3 10/24] scsi: ufs: mediatek: Rework probe function Nicolas Frattaroli
2025-11-05 6:28 ` Chaotian Jing (井朝天)
2025-11-10 9:23 ` Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 11/24] scsi: ufs: mediatek: Remove vendor kernel quirks cruft Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 12/24] scsi: ufs: mediatek: Use the common PHY framework Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 13/24] scsi: ufs: mediatek: Switch to newer PM ops helpers Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 14/24] scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 15/24] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 16/24] scsi: ufs: mediatek: Add vendor prefix to clk-scale-up-vcore-min Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 17/24] scsi: ufs: mediatek: Clean up logging prints Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 18/24] scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 19/24] scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 20/24] scsi: ufs: mediatek: Rework hardware version reading Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 21/24] scsi: ufs: mediatek: Back up idle timer in per-instance struct Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 22/24] scsi: ufs: mediatek: Make scale_us in setup_clk_gating const Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 23/24] scsi: ufs: mediatek: Remove ret local from link_startup_notify Nicolas Frattaroli
2025-10-23 19:49 ` [PATCH v3 24/24] scsi: ufs: mediatek: Add MT8196 compatible, update copyright Nicolas Frattaroli
2025-10-24 9:00 ` [PATCH v3 00/24] MediaTek UFS Cleanup and MT8196 Enablement AngeloGioacchino Del Regno
2025-10-24 17:22 ` Conor Dooley
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=6210035.lOV4Wx5bFT@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=Chaotian.Jing@mediatek.com \
--cc=Chunfeng.Yun@mediatek.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=avri.altman@wdc.com \
--cc=broonie@kernel.org \
--cc=bvanassche@acm.org \
--cc=chu.stanley@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@collabora.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=louisalexis.eyraud@collabora.com \
--cc=martin.petersen@oracle.com \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=peter.wang@mediatek.com \
--cc=robh@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).