Received-SPF: pass (google.com: domain of linux-kernel+bounces-148249-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <657b3245-b294-44f0-8c40-668f474a9ea5@collabora.com>
Date: Wed, 17 Apr 2024 11:34:49 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/8] scsi: ufs: ufs-mediatek: Remove useless
 mediatek,ufs-boost-crypt property
To: =?UTF-8?B?UGV0ZXIgV2FuZyAo546L5L+h5Y+LKQ==?= <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>
References: <20240415110012.148871-1-angelogioacchino.delregno@collabora.com>
 <20240415110012.148871-4-angelogioacchino.delregno@collabora.com>
 <c9634a286fbdb4c98a7fe6703a4eb10d66dfcb9e.camel@mediatek.com>
 <4d60e9e4-9eae-4b0a-abb2-b1ad3d278fc9@collabora.com>
 <93db93aa7eb24a255f97a1a1e8e8d936dc908258.camel@mediatek.com>
 <f3920433-b0fa-4a64-9653-e385bf1eb5c7@collabora.com>
 <d11e174d85c7f5a9b4ffe5fb2bb15dfd5823f83e.camel@mediatek.com>
 <ecd7c691-db47-42aa-ab19-f554c20774af@collabora.com>
 <12cc437d2213720190a2fcf132411cfe4485f5d0.camel@mediatek.com>
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Content-Language: en-US
In-Reply-To: <12cc437d2213720190a2fcf132411cfe4485f5d0.camel@mediatek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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