linux-kernel - Re: [PATCH v6 4/4] clk: qcom: add clock controller driver for qca8386/qca8084

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: <92058c25fb11b75ee0a2298a684825e9.sboyd@kernel.org>
Date:   Mon, 11 Sep 2023 13:11:48 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Jie Luo <quic_luoj@...cinc.com>, agross@...nel.org,
        andersson@...nel.org, catalin.marinas@....com, conor+dt@...nel.org,
        konrad.dybcio@...aro.org, krzysztof.kozlowski+dt@...aro.org,
        mturquette@...libre.com, p.zabel@...gutronix.de,
        robh+dt@...nel.org, will@...nel.org
Cc:     linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        quic_srichara@...cinc.com
Subject: Re: [PATCH v6 4/4] clk: qcom: add clock controller driver for qca8386/qca8084

Quoting Jie Luo (2023-09-08 04:10:35)
> 
> 
> Yes, the uniphy implements the clock provider that supports changing 
> rate, which will be upstream later, and nss_cc_mac5_rx_clk_src is the 
> special case, which is only used in the switch device qca8386.

Ok great.

> 
> For the phy device qca8084(uniphy has only 312.5M fix clock which is 
> registered by device tree), this clock nss_cc_mac5_rx_clk_src is not used.
> 
> The issue for the switch device(qca8386) here is the clock rate of 
> parent uniphy can't be changed because of the clock rate requirement of 
> branch clock, since the uniphy clock rate is decided by the current 
> working interface mode(PHY_INTERFACE_MODE_2500BASEX with 312.5M or 
> PHY_INTERFACE_MODE_SGMII with 125M).

Got it.

> 
> For example, when the uniphy works on PHY_INTERFACE_MODE_2500BASEX, then 
> the parent uniphy clock rate is 312.5M, which is decided by hardware and 
> can't be changed. when a branch clock requires a 25M clock, the parent 
> uniphy clock maybe updated to 125M by clock framework if the flag 
> CLK_SET_RATE_PARENT is set here, but the actual hardware clock rate of 
> uniphy is still 315.5M since the uniphy still works in the interface 
> mode PHY_INTERFACE_MODE_2500BASEX.
> 

If the parent rate can't change because CLK_SET_RATE_PARENT is missing
and the hardware doesn't allow it, then perhaps instead of having a
frequency table we should have rcg clk ops for determine_rate that
simply looks at the parent rates and finds the rate closest to what is
desired. And for the set_rate clk_op we can have it be simple and just
program a fixed divider. The benefit is less frequency tables that don't
do anything and less hard-coding of the frequency. I thought we already
had those rcg clk_ops but I couldn't find them with a quick glance.