diff mbox series

[1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch

Message ID 20231125012303.760-1-chunfeng.yun@mediatek.com (mailing list archive)
State New, archived
Headers show
Series [1/2] dt-bindings: phy: mediatek: tphy: add a property for force-mode switch | expand

Commit Message

Chunfeng Yun (云春峰) Nov. 25, 2023, 1:23 a.m. UTC
Due to some old SoCs with shared t-phy only support force-mode switch, and
can't use compatible to distinguish between shared and non-shared t-phy,
add a property to supported it.
But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.

Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Krzysztof Kozlowski Nov. 25, 2023, 10:37 a.m. UTC | #1
On 25/11/2023 02:23, Chunfeng Yun wrote:
> Due to some old SoCs with shared t-phy only support force-mode switch, and
> can't use compatible to distinguish between shared and non-shared t-phy,
> add a property to supported it.
> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
>  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> index 2bb91542e984..eedba5b7025e 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> @@ -235,6 +235,12 @@ patternProperties:
>            Specify the flag to enable BC1.2 if support it
>          type: boolean
>  
> +      mediatek,force-mode:
> +        description:
> +          Use force mode to switch shared phy mode, perfer to use the bellow

I still do not understand what is the "force mode" you want to use. What
modes do you have? What are the characteristics of force mode?

Also, please run spellcheck.

Best regards,
Krzysztof
Macpaul Lin Nov. 27, 2023, 7:09 a.m. UTC | #2
On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
> 	
> 
> External email : Please do not click links or open attachments until you 
> have verified the sender or the content.
> 
> On 25/11/2023 02:23, Chunfeng Yun wrote:
>> Due to some old SoCs with shared t-phy only support force-mode switch, and
>> can't use compatible to distinguish between shared and non-shared t-phy,
>> add a property to supported it.
>> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.
>> 
>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>> ---
>>  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6 ++++++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>> index 2bb91542e984..eedba5b7025e 100644
>> --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>> @@ -235,6 +235,12 @@ patternProperties:
>>            Specify the flag to enable BC1.2 if support it
>>          type: boolean
>>  
>> +      mediatek,force-mode:
>> +        description:
>> +          Use force mode to switch shared phy mode, perfer to use the bellow
> 
> I still do not understand what is the "force mode" you want to use. What
> modes do you have? What are the characteristics of force mode?
> 
> Also, please run spellcheck.
> 
> Best regards,
> Krzysztof
> 

Thanks!

1. I've tested this patch and it could solve the clock unstable for
XHCI1 on mt8195 or mt8395 during system boot up or during
unload/reload the phy driver.

The error message has been listed as follows.

[   13.849936][   T72] xhci-mtk 11290000.usb: supply vbus not found, 
using dummy regulator
[   13.851300][   T72] xhci-mtk 11290000.usb: uwk - reg:0x400, version:104
[   13.852624][   T72] xhci-mtk 11290000.usb: xHCI Host Controller
[   13.853393][   T72] xhci-mtk 11290000.usb: new USB bus registered, 
assigned bus number 3
[   13.874490][   T72] xhci-mtk 11290000.usb: clocks are not stable (0x3d0f)
[   13.875369][   T72] xhci-mtk 11290000.usb: can't setup: -110
[   13.876091][   T72] xhci-mtk 11290000.usb: USB bus 3 deregistered
[   13.877081][   T72] xhci-mtk: probe of 11290000.usb failed with error 
-110

2. This is a fix patch to XHCI1 since MT8195 has been upstream.
Please add "Fixes:" tags and "Cc: stable@kernel.org" to back ward
porting to previous stable trees.

For example, add
Fixes: 6b5ef194611e5 ("phy: mediatek: tphy: remove macros to prepare 
bitfield")
is suggested since the force-mode was missing in the previous
implementation which causes hardware function was abnormal.
However, add
Fixes: 33d18746fa514 ("phy: phy-mtk-tphy: use new io helpers to access 
register")
will be better since the USB support for mt8195 is already enabled in 
late 2021.

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

Thanks,
Macpaul Lin
Krzysztof Kozlowski Nov. 27, 2023, 7:21 a.m. UTC | #3
On 27/11/2023 08:09, Macpaul Lin wrote:
> On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
>> 	
>>
>> External email : Please do not click links or open attachments until you 
>> have verified the sender or the content.
>>
>> On 25/11/2023 02:23, Chunfeng Yun wrote:
>>> Due to some old SoCs with shared t-phy only support force-mode switch, and
>>> can't use compatible to distinguish between shared and non-shared t-phy,
>>> add a property to supported it.
>>> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.
>>>
>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>> ---
>>>  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>>> index 2bb91542e984..eedba5b7025e 100644
>>> --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>>> @@ -235,6 +235,12 @@ patternProperties:
>>>            Specify the flag to enable BC1.2 if support it
>>>          type: boolean
>>>  
>>> +      mediatek,force-mode:
>>> +        description:
>>> +          Use force mode to switch shared phy mode, perfer to use the bellow
>>
>> I still do not understand what is the "force mode" you want to use. What
>> modes do you have? What are the characteristics of force mode?
>>
>> Also, please run spellcheck.
>>
>> Best regards,
>> Krzysztof
>>
> 
> Thanks!
> 
> 1. I've tested this patch and it could solve the clock unstable for
> XHCI1 on mt8195 or mt8395 during system boot up or during
> unload/reload the phy driver.
> 
> The error message has been listed as follows.
> 
> [   13.849936][   T72] xhci-mtk 11290000.usb: supply vbus not found, 
> using dummy regulator
> [   13.851300][   T72] xhci-mtk 11290000.usb: uwk - reg:0x400, version:104
> [   13.852624][   T72] xhci-mtk 11290000.usb: xHCI Host Controller
> [   13.853393][   T72] xhci-mtk 11290000.usb: new USB bus registered, 
> assigned bus number 3
> [   13.874490][   T72] xhci-mtk 11290000.usb: clocks are not stable (0x3d0f)
> [   13.875369][   T72] xhci-mtk 11290000.usb: can't setup: -110
> [   13.876091][   T72] xhci-mtk 11290000.usb: USB bus 3 deregistered
> [   13.877081][   T72] xhci-mtk: probe of 11290000.usb failed with error 
> -110
> 
> 2. This is a fix patch to XHCI1 since MT8195 has been upstream.
> Please add "Fixes:" tags and "Cc: stable@kernel.org" to back ward
> porting to previous stable trees.
> 
> For example, add
> Fixes: 6b5ef194611e5 ("phy: mediatek: tphy: remove macros to prepare 
> bitfield")
> is suggested since the force-mode was missing in the previous
> implementation which causes hardware function was abnormal.
> However, add
> Fixes: 33d18746fa514 ("phy: phy-mtk-tphy: use new io helpers to access 
> register")
> will be better since the USB support for mt8195 is already enabled in 
> late 2021.
> 
> 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? 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.

Also, your driver change suggests this is compatible specific, so why it
cannot be deduced from compatible?

Best regards,
Krzysztof
AngeloGioacchino Del Regno Nov. 27, 2023, 1:37 p.m. UTC | #4
Il 27/11/23 08:21, Krzysztof Kozlowski ha scritto:
> On 27/11/2023 08:09, Macpaul Lin wrote:
>> On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
>>> 	
>>>
>>> External email : Please do not click links or open attachments until you
>>> have verified the sender or the content.
>>>
>>> On 25/11/2023 02:23, Chunfeng Yun wrote:
>>>> Due to some old SoCs with shared t-phy only support force-mode switch, and
>>>> can't use compatible to distinguish between shared and non-shared t-phy,
>>>> add a property to supported it.
>>>> But now prefer to use "mediatek,syscon-type" on new SoC as far as possible.

Two questions:
1. Why is it *not* possible to use the compatible string to distinguish between
    shared and non-shared T-PHYs?
2. If we really can't use compatibles, what's the reason why we can't use the
    "mediatek,syscon-type" property?

Regards,
Angelo

>>>>
>>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>>>> index 2bb91542e984..eedba5b7025e 100644
>>>> --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>>>> +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
>>>> @@ -235,6 +235,12 @@ patternProperties:
>>>>             Specify the flag to enable BC1.2 if support it
>>>>           type: boolean
>>>>   
>>>> +      mediatek,force-mode:
>>>> +        description:
>>>> +          Use force mode to switch shared phy mode, perfer to use the bellow
>>>
Chunfeng Yun (云春峰) Nov. 30, 2023, 1:51 a.m. UTC | #5
On Mon, 2023-11-27 at 08:21 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 27/11/2023 08:09, Macpaul Lin wrote:
> > On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
> >> 
> >>
> >> External email : Please do not click links or open attachments
> until you 
> >> have verified the sender or the content.
> >>
> >> On 25/11/2023 02:23, Chunfeng Yun wrote:
> >>> Due to some old SoCs with shared t-phy only support force-mode
> switch, and
> >>> can't use compatible to distinguish between shared and non-shared 
> t-phy,
> >>> add a property to supported it.
> >>> But now prefer to use "mediatek,syscon-type" on new SoC as far as
> possible.
> >>>
> >>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> >>> ---
> >>>  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6
> ++++++
> >>>  1 file changed, 6 insertions(+)
> >>>
> >>> diff --git
> a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> >>> index 2bb91542e984..eedba5b7025e 100644
> >>> --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> >>> +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> >>> @@ -235,6 +235,12 @@ patternProperties:
> >>>            Specify the flag to enable BC1.2 if support it
> >>>          type: boolean
> >>>  
> >>> +      mediatek,force-mode:
> >>> +        description:
> >>> +          Use force mode to switch shared phy mode, perfer to
> use the bellow
> >>
> >> I still do not understand what is the "force mode" you want to
> use. What
> >> modes do you have? What are the characteristics of force mode?
> >>
> >> Also, please run spellcheck.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> > 
> > Thanks!
> > 
> > 1. I've tested this patch and it could solve the clock unstable for
> > XHCI1 on mt8195 or mt8395 during system boot up or during
> > unload/reload the phy driver.
> > 
> > The error message has been listed as follows.
> > 
> > [   13.849936][   T72] xhci-mtk 11290000.usb: supply vbus not
> found, 
> > using dummy regulator
> > [   13.851300][   T72] xhci-mtk 11290000.usb: uwk - reg:0x400,
> version:104
> > [   13.852624][   T72] xhci-mtk 11290000.usb: xHCI Host Controller
> > [   13.853393][   T72] xhci-mtk 11290000.usb: new USB bus
> registered, 
> > assigned bus number 3
> > [   13.874490][   T72] xhci-mtk 11290000.usb: clocks are not stable
> (0x3d0f)
> > [   13.875369][   T72] xhci-mtk 11290000.usb: can't setup: -110
> > [   13.876091][   T72] xhci-mtk 11290000.usb: USB bus 3
> deregistered
> > [   13.877081][   T72] xhci-mtk: probe of 11290000.usb failed with
> error 
> > -110
> > 
> > 2. This is a fix patch to XHCI1 since MT8195 has been upstream.
> > Please add "Fixes:" tags and "Cc: stable@kernel.org" to back ward
> > porting to previous stable trees.
> > 
> > For example, add
> > Fixes: 6b5ef194611e5 ("phy: mediatek: tphy: remove macros to
> prepare 
> > bitfield")
> > is suggested since the force-mode was missing in the previous
> > implementation which causes hardware function was abnormal.
> > However, add
> > Fixes: 33d18746fa514 ("phy: phy-mtk-tphy: use new io helpers to
> access 
> > register")
> > will be better since the USB support for mt8195 is already enabled
> in 
> > late 2021.
> > 
> > 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
power down controller and reset pipe to set the mode directly we want,
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.
> 
> Also, your driver change suggests this is compatible specific, so why
> it
> cannot be deduced from compatible?
that is because on the same SoC, some t-phy supported USB3 are shared
with PCIe, but others are not, use the SoC's compatible can not
distinguish them.
> 
> Best regards,
> Krzysztof
>
Chunfeng Yun (云春峰) Nov. 30, 2023, 2 a.m. UTC | #6
On Mon, 2023-11-27 at 14:37 +0100, AngeloGioacchino Del Regno wrote:
> Il 27/11/23 08:21, Krzysztof Kozlowski ha scritto:
> > On 27/11/2023 08:09, Macpaul Lin wrote:
> > > On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
> > > > 	
> > > > 
> > > > External email : Please do not click links or open attachments
> > > > until you
> > > > have verified the sender or the content.
> > > > 
> > > > On 25/11/2023 02:23, Chunfeng Yun wrote:
> > > > > Due to some old SoCs with shared t-phy only support force-
> > > > > mode switch, and
> > > > > can't use compatible to distinguish between shared and non-
> > > > > shared t-phy,
> > > > > add a property to supported it.
> > > > > But now prefer to use "mediatek,syscon-type" on new SoC as
> > > > > far as possible.
> 
> Two questions:
> 1. Why is it *not* possible to use the compatible string to
> distinguish between
>     shared and non-shared T-PHYs?
There may be shared t-phy and non-shared t-phy at the same time on the
SoC.

> 2. If we really can't use compatibles, what's the reason why we can't
> use the
>     "mediatek,syscon-type" property?
It need hardware support it, it uses a top pericfg register to tell the
phy that the mode we want before power on the phy controller.


> 
> Regards,
> Angelo
> 
> > > > > 
> > > > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > > > > ---
> > > > >   Documentation/devicetree/bindings/phy/mediatek,tphy.yaml |
> > > > > 6 ++++++
> > > > >   1 file changed, 6 insertions(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > index 2bb91542e984..eedba5b7025e 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > > > @@ -235,6 +235,12 @@ patternProperties:
> > > > >             Specify the flag to enable BC1.2 if support it
> > > > >           type: boolean
> > > > >   
> > > > > +      mediatek,force-mode:
> > > > > +        description:
> > > > > +          Use force mode to switch shared phy mode, perfer
> > > > > to use the bellow
> 
>
Chunfeng Yun (云春峰) Nov. 30, 2023, 2:28 a.m. UTC | #7
On Mon, 2023-11-27 at 15:09 +0800, Macpaul Lin wrote:
> On 11/25/23 18:37, Krzysztof Kozlowski and Chunfeng Yun wrote:
> > 	
> > 
> > External email : Please do not click links or open attachments
> > until you 
> > have verified the sender or the content.
> > 
> > On 25/11/2023 02:23, Chunfeng Yun wrote:
> > > Due to some old SoCs with shared t-phy only support force-mode
> > > switch, and
> > > can't use compatible to distinguish between shared and non-shared 
> > > t-phy,
> > > add a property to supported it.
> > > But now prefer to use "mediatek,syscon-type" on new SoC as far as
> > > possible.
> > > 
> > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > > ---
> > >  Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 6
> > > ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > index 2bb91542e984..eedba5b7025e 100644
> > > --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
> > > @@ -235,6 +235,12 @@ patternProperties:
> > >            Specify the flag to enable BC1.2 if support it
> > >          type: boolean
> > >  
> > > +      mediatek,force-mode:
> > > +        description:
> > > +          Use force mode to switch shared phy mode, perfer to
> > > use the bellow
> > 
> > I still do not understand what is the "force mode" you want to use.
> > What
> > modes do you have? What are the characteristics of force mode?
> > 
> > Also, please run spellcheck.
> > 
> > Best regards,
> > Krzysztof
> > 
> 
> Thanks!
> 
> 1. I've tested this patch and it could solve the clock unstable for
> XHCI1 on mt8195 or mt8395 during system boot up or during
> unload/reload the phy driver.
> 
> The error message has been listed as follows.
> 
> [   13.849936][   T72] xhci-mtk 11290000.usb: supply vbus not found, 
> using dummy regulator
> [   13.851300][   T72] xhci-mtk 11290000.usb: uwk - reg:0x400,
> version:104
> [   13.852624][   T72] xhci-mtk 11290000.usb: xHCI Host Controller
> [   13.853393][   T72] xhci-mtk 11290000.usb: new USB bus
> registered, 
> assigned bus number 3
> [   13.874490][   T72] xhci-mtk 11290000.usb: clocks are not stable
> (0x3d0f)
> [   13.875369][   T72] xhci-mtk 11290000.usb: can't setup: -110
> [   13.876091][   T72] xhci-mtk 11290000.usb: USB bus 3 deregistered
> [   13.877081][   T72] xhci-mtk: probe of 11290000.usb failed with
> error 
> -110
> 
> 2. This is a fix patch to XHCI1 since MT8195 has been upstream.
> Please add "Fixes:" tags and "Cc: stable@kernel.org" to back ward
> porting to previous stable trees.
> 
> For example, add
> Fixes: 6b5ef194611e5 ("phy: mediatek: tphy: remove macros to prepare 
> bitfield")
> is suggested since the force-mode was missing in the previous
> implementation which causes hardware function was abnormal.
> However, add
> Fixes: 33d18746fa514 ("phy: phy-mtk-tphy: use new io helpers to
> access 
> register")
> will be better since the USB support for mt8195 is already enabled
> in 
> late 2021.
It don't take into account this case, it assume that only use the
default mode (PCIe).

> 
> 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. 
seems not right, the mode/type is selected by the phy consumer.

> 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

> 
> Thanks,
> Macpaul Lin
Krzysztof Kozlowski Nov. 30, 2023, 8:03 a.m. UTC | #8
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
Chunfeng Yun (云春峰) Dec. 10, 2023, 9:09 a.m. UTC | #9
On Thu, 2023-11-30 at 09:03 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  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"?
Hardware designer

> 
> > power down controller and reset pipe to set the mode directly we
> want,
> 
> So force-mode is driver behavior?
hardware supported, need software to set some registers

> 
> > 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.
OK, I'll modify the description

Thanks

> 
> 
> 
> Best regards,
> Krzysztof
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index 2bb91542e984..eedba5b7025e 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -235,6 +235,12 @@  patternProperties:
           Specify the flag to enable BC1.2 if support it
         type: boolean
 
+      mediatek,force-mode:
+        description:
+          Use force mode to switch shared phy mode, perfer to use the bellow
+          property "mediatek,syscon-type" if the hardware support it.
+        type: boolean
+
       mediatek,syscon-type:
         $ref: /schemas/types.yaml#/definitions/phandle-array
         maxItems: 1