lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aeb364a3-6c05-4a1b-ba32-e687a89f20f8@quicinc.com>
Date: Tue, 26 Dec 2023 15:25:22 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, <agross@...nel.org>,
        <andersson@...nel.org>, <konrad.dybcio@...aro.org>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <andrew@...n.ch>, <hkallweit1@...il.com>, <linux@...linux.org.uk>,
        <robert.marko@...tura.hr>
CC: <linux-arm-msm@...r.kernel.org>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_srichara@...cinc.com>
Subject: Re: [PATCH v4 5/5] dt-bindings: net: ipq4019-mdio: Document ipq5332
 platform



On 12/25/2023 6:29 PM, Krzysztof Kozlowski wrote:
> On 25/12/2023 09:44, Luo Jie wrote:
>> Update the yaml file for the new DTS properties.
>>
>> 1. qcom,cmn-ref-clock-frequency for the CMN PLL source clock select.
>> 2. clock-frequency for MDIO clock frequency config.
>> 3. add uniphy AHB & SYS GCC clocks.
> 
> I see two new compatibles, so your list is missing main point.

will add the compatibles into the list, thanks.

> 
>>
>> Signed-off-by: Luo Jie <quic_luoj@...cinc.com>
>> ---
>>   .../bindings/net/qcom,ipq4019-mdio.yaml       | 141 +++++++++++++++++-
>>   1 file changed, 136 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
>> index 3407e909e8a7..205500cb1fd1 100644
>> --- a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
>> +++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
>> @@ -18,8 +18,10 @@ properties:
>>   
>>         - items:
>>             - enum:
>> +              - qcom,ipq5332-mdio
>>                 - qcom,ipq6018-mdio
>>                 - qcom,ipq8074-mdio
>> +              - qcom,ipq9574-mdio
>>             - const: qcom,ipq4019-mdio
>>   
>>     "#address-cells":
>> @@ -30,19 +32,76 @@ properties:
>>   
>>     reg:
>>       minItems: 1
>> -    maxItems: 2
>> -    description:
>> -      the first Address and length of the register set for the MDIO controller.
>> -      the second Address and length of the register for ethernet LDO, this second
>> -      address range is only required by the platform IPQ50xx.
>> +    maxItems: 5
>> +    description: |
>> +      The first address and length of the register set for the MDIO controller,
>> +      the optional second address and length of the register is for CMN block,
>> +      the optional third, fourth and fifth address and length of the register
>> +      for Ethernet LDO, the optional Ethernet LDO address range is required by
> 
> Wait, required? You said in in response to Rob these are not required!

As for the response to Rob, i was saying the uniphy ahb and sys clocks
are not needed on ipq9574.
The LDO are needed on ipq5332 and ipq5018 currently.

> 
>> +      the platform IPQ50xx/IPQ5332.
> 
> So these are valid for all platforms or not? Looks not, but nothing
> narrows the list for other boards.

i add the limitation on the reg usage for the ipq5332 platform on the
following part "if condition" of this patch, i will update the patch
to narrow down for the other compatibles.

> 
> Anyway, why do you add entries in the middle? LDO was the second, so it
> cannot be now fifth.

As Rob's suggestion, i move the cmn_blk to second location for
simplifying the limitation description, i checked the upstream dts code,
the LDO is not used currently, so we can move cmn_blk to the second
location here.

> 
>> +
>> +  reg-names:
>> +    minItems: 1
>> +    items:
>> +      - const: mdio
>> +      - const: cmn_blk
>> +      - const: eth_ldo1
>> +      - const: eth_ldo2
>> +      - const: eth_ldo3
>>   
>>     clocks:
>> +    minItems: 1
>>       items:
>>         - description: MDIO clock source frequency fixed to 100MHZ
>> +      - description: UNIPHY0 AHB clock source frequency fixed to 100MHZ
>> +      - description: UNIPHY1 AHB clock source frequency fixed to 100MHZ
>> +      - description: UNIPHY0 SYS clock source frequency fixed to 24MHZ
>> +      - description: UNIPHY1 SYS clock source frequency fixed to 24MHZ
>>   
>>     clock-names:
>> +    minItems: 1
>>       items:
>>         - const: gcc_mdio_ahb_clk
>> +      - const: uniphy0_ahb
>> +      - const: uniphy1_ahb
>> +      - const: uniphy0_sys
>> +      - const: uniphy1_sys
>> +
>> +  qcom,cmn-ref-clock-frequency:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    enum:
>> +      - 25000000
>> +      - 31250000
>> +      - 40000000
>> +      - 48000000
>> +      - 50000000
>> +      - 96000000
>> +    default: 48000000
>> +    description: |
>> +      The reference clock source of CMN PLL block is selectable, the
>> +      reference clock source can be from wifi module or the external
>> +      xtal, the reference clock frequency 48MHZ can be from internal
>> +      wifi or the external xtal, if absent, the internal 48MHZ is used,
>> +      if the 48MHZ is specified, which means the external 48Mhz is used.
> 
> This does not resolve mine and Conor's concerns from previous version.
> External clocks are defined as clock inputs.

No matter the external or internal reference clock, they are the clock
source selection for CMN, there are only 48MHZ can be external or 
internal, other clocks have the different clock rate, so the internal
48MHZ reference clock can be implied when the 
"qcom,cmn-ref-clock-frequency" is not defined, which is suggested by 
Conor in the previous
comments.

> 
>> +
>> +  clock-frequency:
>> +    enum:
>> +      - 390625
>> +      - 781250
>> +      - 1562500
>> +      - 3125000
>> +      - 6250000
>> +      - 12500000
>> +    default: 390625
>> +    description: |
>> +      The MDIO bus clock that must be output by the MDIO bus hardware,
>> +      only the listed frequencies above can be supported, other frequency
>> +      will cause malfunction. If absent, the default hardware value 0xff
>> +      is used, which means the default MDIO clock frequency 390625HZ, The
>> +      MDIO clock frequency is MDIO_SYS_CLK/(MDIO_CLK_DIV + 1), the SoC
>> +      MDIO_SYS_CLK is fixed to 100MHZ, the MDIO_CLK_DIV is from MDIO control
>> +      register, there is higher clock frequency requirement on the normal
>> +      working case where the MDIO slave devices support high clock frequency.
>>   
>>   required:
>>     - compatible
>> @@ -59,8 +118,10 @@ allOf:
>>             contains:
>>               enum:
>>                 - qcom,ipq5018-mdio
>> +              - qcom,ipq5332-mdio
>>                 - qcom,ipq6018-mdio
>>                 - qcom,ipq8074-mdio
>> +              - qcom,ipq9574-mdio
>>       then:
>>         required:
>>           - clocks
>> @@ -70,6 +131,20 @@ allOf:
>>           clocks: false
>>           clock-names: false
>>   
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - qcom,ipq5332-mdio
>> +    then:
>> +      properties:
>> +        clocks:
>> +          minItems: 5
>> +          maxItems: 5
>> +        reg-names:
>> +          minItems: 4
> 
> Why all other variants now have 5 clocks and 5 reg entries? Nothing of
> it is explained in the commit msg.

 From the condition above, only "qcom,ipq5332-mdio" has 5 clocks (mdio +
4 uniphy clocks) and 4 regs (mdio + cmn_blk + 2 LDOs) as the cmn_blk is
moved to the second location.

how it can gives the 5 clocks and 5 regs for other variants here?


> 
>> +
>>   unevaluatedProperties: false
>>   
>>   examples:
>> @@ -100,3 +175,59 @@ examples:
>>           reg = <4>;
>>         };
>>       };
>> +
>> +  - |
>> +    #include <dt-bindings/clock/qcom,ipq5332-gcc.h>
>> +    #include <dt-bindings/gpio/gpio.h>
>> +
>> +    mdio@...00 {
>> +      #address-cells = <1>;
>> +      #size-cells = <0>;
> 
> That's not the order of properties. compatible is always the first, reg
> and reg-names follow. See DTS coding style.

will correct this, thanks.

> 
>> +      compatible = "qcom,ipq5332-mdio",
>> +                   "qcom,ipq4019-mdio";
>> +
>> +      reg = <0x90000 0x64>,
>> +            <0x9b000 0x800>,
>> +            <0x7a00610 0x4>,
>> +            <0x7a10610 0x4>;
>> +
> 
> Drop blank line.
Ok.

> 
>> +      reg-names = "mdio",
>> +                  "cmn_blk",
>> +                  "eth_ldo1",
>> +                  "eth_ldo2";
>> +
>> +      clocks = <&gcc GCC_MDIO_AHB_CLK>,
>> +               <&gcc GCC_UNIPHY0_AHB_CLK>,
>> +               <&gcc GCC_UNIPHY1_AHB_CLK>,
>> +               <&gcc GCC_UNIPHY0_SYS_CLK>,
>> +               <&gcc GCC_UNIPHY1_SYS_CLK>;
>> +
> 
> Drop blank line
Ok.

> 
>> +      clock-names = "gcc_mdio_ahb_clk",
>> +                    "uniphy0_ahb",
>> +                    "uniphy1_ahb",
>> +                    "uniphy0_sys",
>> +                    "uniphy1_sys";
>> +
>> +      clock-frequency = <6250000>;
>> +      reset-gpios = <&tlmm 51 GPIO_ACTIVE_LOW>;
>> +
> 
> Best regards,
> Krzysztof
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ