From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: "Peter Wang (王信友)" <peter.wang@mediatek.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"wenst@chromium.org" <wenst@chromium.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"amergnat@baylibre.com" <amergnat@baylibre.com>
Subject: Re: [PATCH v4 3/8] scsi: ufs: ufs-mediatek: Remove useless mediatek,ufs-boost-crypt property
Date: Wed, 17 Apr 2024 11:34:49 +0200 [thread overview]
Message-ID: <657b3245-b294-44f0-8c40-668f474a9ea5@collabora.com> (raw)
In-Reply-To: <12cc437d2213720190a2fcf132411cfe4485f5d0.camel@mediatek.com>
Il 17/04/24 11:29, Peter Wang (王信友) ha scritto:
> On Wed, 2024-04-17 at 10:14 +0200, AngeloGioacchino Del Regno wrote:
>>
>>
>> Upstream supports platforms that do and don't need this feature, and
>> having
>> redundant device tree properties performing the same checks is not
>> just
>> suboptimal but plain wrong.
>>
>> Adding to this, devicetree describes the hardware - and there is no
>> physical
>> hardware switch that needs this redundant property, this means that
>> the
>> property that is getting removed in this commit (and the va09 one in
>> another
>> commit of this series) is a *software switch*, not HW.
>>
>> Keep in mind, also, that this feature (and again, the va09 one as
>> well) has
>> a specific requirement to be supported - and this is what the code
>> does even
>> without the software switch to add it.
>>
>> In case there's any need to disallow such feature from a specific
>> SoC, the DT
>> bindings can be modified such that a specific compatible string would
>> disallow
>> adding the required regulator and/or boost-microvolt properties.
>>
>> Besides, I want to remind you that there is no reason to drop
>> support, or have
>> them unreliably working, or use hacks, for SoCs that are "old" -
>> especially
>> when this is a driver that works on both old and new ones.
>>
>> Regards,
>> Angelo
>
> Hi Angelo,
>
> These two property(boost and va09) is not software switch, they
> are hardware switch. Because if platform support crypto boost, we set
> boost property in device tree. And if platform support ufs va09, we set
> va09 proberty in device tree. These property are main hardware switch.
I disagree. If a platform supports crypto boost, it will have the dvfsrc
regulator and the supported voltage for the boost; if a platform supports
ufs va09, it will have the va09 regulator assigned in the ufshci devicetree
node.
>
> We don't use sub switch like voltage or clock setting becasue it is
> not intiutive. Especially when va09 is not used by ufs (No va09
> property but have va09 voltage), The behavior should be wrong if ufs
> control va09 which used by other module.
>
As I said, devicetree describes hardware - and this strategy being intuitive
or not boils down to personal opinions and nothing else.
Aside personal opinions, again, properties not describing hardware are wrong.
And again, if VA09 shall not be controlled by the UFSHCI driver on a specific
platform, then the regulator shall not be assigned to the UFSHCI node on that
specific platform.
Regards,
Angelo
next prev parent reply other threads:[~2024-04-17 9:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 11:00 [PATCH v4 0/8] MediaTek UFS fixes and cleanups - Part 1 AngeloGioacchino Del Regno
2024-04-15 11:00 ` [PATCH v4 1/8] scsi: ufs: ufs-mediatek: Remove useless mediatek,ufs-support-va09 property AngeloGioacchino Del Regno
2024-04-15 11:00 ` [PATCH v4 2/8] scsi: ufs: ufs-mediatek: Fix property name for crypt boost voltage AngeloGioacchino Del Regno
2024-04-15 11:00 ` [PATCH v4 3/8] scsi: ufs: ufs-mediatek: Remove useless mediatek,ufs-boost-crypt property AngeloGioacchino Del Regno
2024-04-16 7:03 ` Peter Wang (王信友)
2024-04-16 7:55 ` AngeloGioacchino Del Regno
2024-04-16 10:31 ` Peter Wang (王信友)
2024-04-16 10:38 ` AngeloGioacchino Del Regno
2024-04-16 13:05 ` Peter Wang (王信友)
2024-04-17 8:14 ` AngeloGioacchino Del Regno
2024-04-17 9:29 ` Peter Wang (王信友)
2024-04-17 9:34 ` AngeloGioacchino Del Regno [this message]
2024-04-15 11:00 ` [PATCH v4 4/8] scsi: ufs: ufs-mediatek: Avoid underscores in crypt clock names AngeloGioacchino Del Regno
2024-04-15 11:00 ` [PATCH v4 5/8] dt-bindings: ufs: mediatek,ufs: Document MT8192 compatible with MT8183 AngeloGioacchino Del Regno
2024-04-15 13:00 ` Conor Dooley
2024-04-15 11:00 ` [PATCH v4 6/8] dt-bindings: ufs: mediatek,ufs: Document MT8195 compatible AngeloGioacchino Del Regno
2024-04-15 11:00 ` [PATCH v4 7/8] dt-bindings: ufs: mediatek,ufs: Document additional clocks AngeloGioacchino Del Regno
2024-04-15 13:00 ` Conor Dooley
2024-04-15 11:00 ` [PATCH v4 8/8] dt-bindings: ufs: mediatek,ufs: Document optional dvfsrc/va09 regulators AngeloGioacchino Del Regno
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=657b3245-b294-44f0-8c40-668f474a9ea5@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=alim.akhtar@samsung.com \
--cc=amergnat@baylibre.com \
--cc=avri.altman@wdc.com \
--cc=broonie@kernel.org \
--cc=bvanassche@acm.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jejb@linux.ibm.com \
--cc=krzysztof.kozlowski+dt@linaro.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-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=matthias.bgg@gmail.com \
--cc=peter.wang@mediatek.com \
--cc=robh@kernel.org \
--cc=wenst@chromium.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 read-only IMAP folder(s) and NNTP newsgroup(s).