[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50e56220-8068-4e2e-a586-9d0474963085@linaro.org>
Date: Thu, 30 Nov 2023 09:03:17 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Chunfeng Yun (云春峰)
<Chunfeng.Yun@...iatek.com>, "vkoul@...nel.org" <vkoul@...nel.org>,
Macpaul Lin (林智斌)
<Macpaul.Lin@...iatek.com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>
Cc: Pablo Sun (孫毓翔) <pablo.sun@...iatek.com>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Bear Wang (萩原惟德)
<bear.wang@...iatek.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH 1/2] dt-bindings: phy: mediatek: tphy: add a property for
force-mode switch
On 30/11/2023 02:51, Chunfeng Yun (云春峰) wrote:
>>> 3. How about we revise the description as follows for more
>> precisely?
>>>
>>> mediatek,force-mode:
>>> description:
>>> The force mode is used to manually switch the shared PHY mode
>>> between USB and PCIe. When force-mode is set, the USB 3.0 mode
>>> will be selected. This is typically required for older SoCs
>>> that do not automatically manage PHY mode switching.
>>> For newer SoCs that support it, it is preferable to use the
>>> "mediatek,syscon-type" property instead.
>>> type: boolean
>>
>> Again, what is force-mode?
> Our DE describe this behavior as force-mode, as you see, the driver
What is "DE"?
> power down controller and reset pipe to set the mode directly we want,
So force-mode is driver behavior?
> but usually the phy controller switch to the mode automatically
> according to the external signal, e.g. trapping pin, efuse etc.
>
>> It looks like you wrote bindings for the
>> driver behavior. Bindings describe hardware, not how the driver
>> should
>> behave. The property might be reasonable, but you must describe here
>> hardware characteristics/issue/etc.
You must address this, in such case.
Best regards,
Krzysztof
Powered by blists - more mailing lists