From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>,
Alim Akhtar <alim.akhtar@samsung.com>,
Avri Altman <avri.altman@wdc.com>,
Bart Van Assche <bvanassche@acm.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Peter Wang <peter.wang@mediatek.com>,
Stanley Jhu <chu.stanley@gmail.com>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Chaotian Jing <Chaotian.Jing@mediatek.com>,
Neil Armstrong <neil.armstrong@linaro.org>
Cc: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>,
kernel@collabora.com, linux-scsi@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-phy@lists.infradead.org,
Conor Dooley <conor.dooley@microchip.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Subject: Re: [PATCH v6 00/24] MediaTek UFS Cleanup and MT8196 Enablement
Date: Mon, 16 Feb 2026 13:40:27 +0100 [thread overview]
Message-ID: <90e0cbe5-3219-4196-a4bd-015e320d07b3@collabora.com> (raw)
In-Reply-To: <20260124-mt8196-ufs-v6-0-e7c005b60028@collabora.com>
Il 24/01/26 13:00, Nicolas Frattaroli ha scritto:
> In this series, the existing MediaTek UFS binding is expanded and
> completed to correctly describe not just the existing compatibles, but
> also to introduce a new compatible in the from of the MT8196 SoC.
>
> The resets, which until now were completely absent from both the UFS
> host controller binding and the UFS PHY binding, are introduced to both.
> This also means the driver's undocumented and, in mainline, unused reset
> logic is reworked. In particular, the PHY reset is no longer a reset of
> the host controller node, but of the PHY node.
>
> This means the host controller can reset the PHY through the common PHY
> framework.
>
> The resets remain optional.
>
> Additionally, a massive number of driver cleanups are introduced. These
> were prompted by me inspecting the driver more closely as I was
> adjusting it to correspond to the binding.
>
> The driver still implements vendor properties that are undocumented in
> the binding. I did not touch most of those, as I neither want to
> convince the bindings maintainers that they are needed without knowing
> precisely what they're for, nor do I want to argue with the driver
> authors when removing them.
>
> Due to the "Marie Kondo with a chainsaw" nature of the driver cleanup
> patches, I humbly request that reviewers do not comment on displeasing
> code they see in the context portion of a patch before they've read the
> whole patch series, as that displeasing code may in fact be reworked in
> a subsequent patch of this series. Please keep comments focused on the
> changed lines of the diff; I know there's more that can be done, but it
> doesn't necessarily need to be part of this series.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Nicolas, can you please rebase this series on the latest linux-next?
All that you have to do is resend everything as-is, but drop patch [14/24], as the
same thing that you've done there landed in form of..
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/ufs/host/ufs-mediatek.c?h=next-20260213&id=bbb8d98fb4536594cb104fd630ea0f7dce3771d6
Besides. It feels like we're again playing a resend-and-nobody-cares game again
with this UFS driver.
I want to remind everyone that we've been trying to cleanup this thing for more
than a year and that our patches keep getting mostly ignored, if not for some
random nitpick here and there. (we: as I myself tried to clean it up a year ago
with my own patches that I had sent to the list - multiple versions of those)
Expressing my huge frustration here: at this point I'm not even sure why we keep
trying to make this right, other than being stubborn about feeling the need to
have good stuff in the kernel, instead of downstream code dumps which should've
never landed in the first place.
Though everyone here is human, and humans make mistakes (a lot), that's fine: the
problem happens when people negate mistakes, don't fix those, and don't care (not
because of lack of time, but because not caring at all, again - we've tried to do
those cleanups for a year now). One. Year.
Actually, more than one year, I don't even remember anymore.
This is not good behavior in a community, and should never happen.
Yet, here we are. Again. On the same driver. In the same subsystem.
Oh well.
Regards,
Angelo
> ---
> Changes in v6:
> - Reword "Rework probe function" commit to better justify the changes
> being made.
> - Drop "Add vendor prefix to clk-scale-up-vcore-min"
> - Add patch to remove clk-scale-up-vcore-min entirely, describing the
> process for bringing it back (in a different form) in the commit
> message.
> - Link to v5: https://lore.kernel.org/r/20260108-mt8196-ufs-v5-0-49215157ec41@collabora.com
>
> Changes in v5:
> - Drop "scsi: ufs: mediatek: Make scale_us in setup_clk_gating const" as
> someone else already got a patch in for this into next.
> - Make mtk_init_boost_crypt void
> - Don't disable/enable misc regulators during suspend/resume, but enable
> them once when acquiring with a devm helper.
> - Link to v4: https://lore.kernel.org/r/20251218-mt8196-ufs-v4-0-ddec7a369dd2@collabora.com
>
> Changes in v4:
> - bindings: Redo the supply situation, as the avdd pins don't describe
> the vcc(q2) card supplies.
> - bindings: format clock in mt8196 example more tersely.
> - phy: use devm_reset_control_get_optional_exclusive directly
> - driver: get and enable/disable the aforementioned avdd supplies.
> - Link to v3: https://lore.kernel.org/r/20251023-mt8196-ufs-v3-0-0f04b4a795ff@collabora.com
>
> Changes in v3:
> - Split mediatek,ufs bindings change into two patches, one for
> completing the existing binding, one for the MT8196
> - Add over a dozen driver cleanup patches
> - Add explicit support for the MT8196 compatible to the driver
> - Note: next-20251023, on which I based this, currently has a broken
> build due to an unrelated OPP core change that was merged with no
> build testing. I can't use next-20251022 either, as that lacks the
> recent mediatek UFS changes. It is what it is.
> - Link to v2: https://lore.kernel.org/r/20251016-mt8196-ufs-v2-0-c373834c4e7a@collabora.com
>
> Changes in v2:
> - Reorder define in mtk_sip_svc.h
> - Use bulk reset APIs in UFS host driver
> - Link to v1: https://lore.kernel.org/r/20251014-mt8196-ufs-v1-0-195dceb83bc8@collabora.com
>
> ---
> Nicolas Frattaroli (24):
> dt-bindings: phy: Add mediatek,mt8196-ufsphy variant
> dt-bindings: ufs: mediatek,ufs: Complete the binding
> dt-bindings: ufs: mediatek,ufs: Add mt8196 variant
> scsi: ufs: mediatek: Move MTK_SIP_UFS_CONTROL to mtk_sip_svc.h
> phy: mediatek: ufs: Add support for resets
> scsi: ufs: mediatek: Rework resets
> scsi: ufs: mediatek: Rework 0.9V regulator
> scsi: ufs: mediatek: Rework init function
> scsi: ufs: mediatek: Rework the crypt-boost stuff
> scsi: ufs: mediatek: Handle misc host voltage regulators
> scsi: ufs: mediatek: Rework probe function
> scsi: ufs: mediatek: Remove vendor kernel quirks cruft
> scsi: ufs: mediatek: Use the common PHY framework
> scsi: ufs: mediatek: Switch to newer PM ops helpers
> scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property
> scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths
> scsi: ufs: mediatek: Clean up logging prints
> scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state
> scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice
> scsi: ufs: mediatek: Rework hardware version reading
> scsi: ufs: mediatek: Back up idle timer in per-instance struct
> scsi: ufs: mediatek: Remove ret local from link_startup_notify
> scsi: ufs: mediatek: Remove undocumented "clk-scale-up-vcore-min"
> scsi: ufs: mediatek: Add MT8196 compatible, update copyright
>
> .../devicetree/bindings/phy/mediatek,ufs-phy.yaml | 16 +
> .../devicetree/bindings/ufs/mediatek,ufs.yaml | 173 +++-
> drivers/phy/mediatek/phy-mtk-ufs.c | 71 ++
> drivers/ufs/host/ufs-mediatek-sip.h | 9 -
> drivers/ufs/host/ufs-mediatek.c | 973 +++++++++------------
> drivers/ufs/host/ufs-mediatek.h | 17 +-
> include/linux/soc/mediatek/mtk_sip_svc.h | 3 +
> 7 files changed, 655 insertions(+), 607 deletions(-)
> ---
> base-commit: 4af4e95edc37ae54f64cbd75b46f16ce15f3a6b8
> change-id: 20251014-mt8196-ufs-cec4b9a97e53
>
> Best regards,
prev parent reply other threads:[~2026-02-16 12:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 12:00 Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 01/24] dt-bindings: phy: Add mediatek,mt8196-ufsphy variant Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 02/24] dt-bindings: ufs: mediatek,ufs: Complete the binding Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 03/24] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 04/24] scsi: ufs: mediatek: Move MTK_SIP_UFS_CONTROL to mtk_sip_svc.h Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 05/24] phy: mediatek: ufs: Add support for resets Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 06/24] scsi: ufs: mediatek: Rework resets Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 07/24] scsi: ufs: mediatek: Rework 0.9V regulator Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 08/24] scsi: ufs: mediatek: Rework init function Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 09/24] scsi: ufs: mediatek: Rework the crypt-boost stuff Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 10/24] scsi: ufs: mediatek: Handle misc host voltage regulators Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 11/24] scsi: ufs: mediatek: Rework probe function Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 12/24] scsi: ufs: mediatek: Remove vendor kernel quirks cruft Nicolas Frattaroli
2026-01-24 12:00 ` [PATCH v6 13/24] scsi: ufs: mediatek: Use the common PHY framework Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 14/24] scsi: ufs: mediatek: Switch to newer PM ops helpers Nicolas Frattaroli
2026-01-24 22:41 ` kernel test robot
2026-01-24 12:01 ` [PATCH v6 15/24] scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 16/24] scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 17/24] scsi: ufs: mediatek: Clean up logging prints Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 18/24] scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 19/24] scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 20/24] scsi: ufs: mediatek: Rework hardware version reading Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 21/24] scsi: ufs: mediatek: Back up idle timer in per-instance struct Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 22/24] scsi: ufs: mediatek: Remove ret local from link_startup_notify Nicolas Frattaroli
2026-01-24 12:01 ` [PATCH v6 23/24] scsi: ufs: mediatek: Remove undocumented "clk-scale-up-vcore-min" Nicolas Frattaroli
2026-01-26 14:53 ` AngeloGioacchino Del Regno
2026-01-24 12:01 ` [PATCH v6 24/24] scsi: ufs: mediatek: Add MT8196 compatible, update copyright Nicolas Frattaroli
2026-02-16 12:40 ` AngeloGioacchino Del Regno [this message]
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=90e0cbe5-3219-4196-a4bd-015e320d07b3@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=Chaotian.Jing@mediatek.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=broonie@kernel.org \
--cc=bvanassche@acm.org \
--cc=chu.stanley@gmail.com \
--cc=chunfeng.yun@mediatek.com \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@collabora.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@oss.qualcomm.com \
--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=neil.armstrong@linaro.org \
--cc=nicolas.frattaroli@collabora.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
all inboxes | Powered by JetHome®