Re: [PATCH] clk: qcom: regmap-phy-mux: Rework the implementation

[Konrad Dybcio]

On 6/26/26 1:15 PM, Marek Szyprowski wrote:
> On 26.06.2026 11:46, Marek Szyprowski wrote:
>> On 11.06.2026 21:38, Dmitry Baryshkov wrote:
>>> On Mon, Jun 08, 2026 at 10:09:55AM -0500, Bjorn Andersson wrote:
>>>> On Thu, 09 Apr 2026 13:57:45 +0200, Konrad Dybcio wrote:
>>>>> The sole reason this hw exists is to let the branch clock downstream of
>>>>> it keep running, with the PHY disengaged. This is not possible with the
>>>>> current implementation, as the enabled status is hijacked to mean
>>>>> "enabled" = "use fast/PHY source" and "disabled" = "use XO source".
>>>>>
>>>>> This is an issue, since the mux enable state follows that of the child
>>>>> branch, making the desired "child enabled, MUX @ XO" combination
>>>>> impossible.
>>>>>
>>>>> [...]
>>>> Applied, thanks!
>>>>
>>>> [1/1] clk: qcom: regmap-phy-mux: Rework the implementation
>>>>       commit: e108373c54fbc844b7f541c6fd7ecb31772afd3c
>>> This breaks at PCIe at least on SM8350. The attached WiFi card is
>>> not detected anymore. Rewerting the patch makes it work again.
>> Same on QCS6490-based RubikPi3, after this patch the XHCI USB host controller PCI
>> devive is no longer detected.
> A few more comments. I've checked the PCIe initialization code called on Rubik Pi3
> board ("qcom_pcie_init_2_7_0()") and there is no call to set_rate(), which would 
> change the MUX to PHY. The PCIe init code only calls clk_bulk_prepare_enable(),
> but this became noop after this patch on the mentioned MUX.

Yeah, I sent a revert a couple days ago:

https://lore.kernel.org/linux-arm-msm/20260622-topic-phymux_revert-v1-1-f6ec85523840@xxxxxxxxxxxxxxxx/

The platform I originally tested this on seems to have different
defaults.

Konrad