devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
To: Stephan Gerhold <stephan.gerhold@linaro.org>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	bjorn.andersson@oss.qualcomm.com
Cc: Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Aleksandrs Vinarskis <alex.vinarskis@gmail.com>,
	linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] phy: qcom: phy-qcom-snps-eusb2: Make repeater optional
Date: Wed, 19 Mar 2025 13:41:58 +0200	[thread overview]
Message-ID: <295bd48c-940a-4944-ab3b-ab7cd46e4fef@gmail.com> (raw)
In-Reply-To: <Z9qd1GJ1418CbaOt@linaro.org>

On 3/19/25 12:35, Stephan Gerhold wrote:
> On Wed, Mar 19, 2025 at 12:20:07PM +0200, Dmitry Baryshkov wrote:
>> On Tue, Mar 18, 2025 at 10:22:56PM -0500, Bjorn Andersson via B4 Relay wrote:
>>> From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>>>
>>> In a multiport configuration based on the SNPS eUSB2 PHY it's not
>>> necessary that all ports are connected to something.
>>>
>>> While this is allowed by the Devicetree binding, the implementation
>>> current fails probing for such PHYs, which also prevents the multiport
>>> controller from probing.
>>>
>>> The lack of repeater does not alter the fact that the PHY is there and
>>> attempts at describing only the used PHYs in Devicetree results in
>>> failures to initialize the USB controller.
>>>
>>> Make the repeater optional, to allow the these PHYs to be described in
>>> the DeviceTree and for the associated multiport controller to operate
>>> the other ports.
>>>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>>> ---
>>>  drivers/phy/qualcomm/phy-qcom-snps-eusb2.c | 10 +++++++---
>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-eusb2.c b/drivers/phy/qualcomm/phy-qcom-snps-eusb2.c
>>> index 1484691a41d59a7eaf257ef44300827c668bf7e0..8897d2072ccfcaa5b4a510c17761dcdeed5bad0f 100644
>>> --- a/drivers/phy/qualcomm/phy-qcom-snps-eusb2.c
>>> +++ b/drivers/phy/qualcomm/phy-qcom-snps-eusb2.c
>>> @@ -401,9 +401,13 @@ static int qcom_snps_eusb2_hsphy_probe(struct platform_device *pdev)
>>>  				     "failed to get regulator supplies\n");
>>>  
>>>  	phy->repeater = devm_of_phy_get_by_index(dev, np, 0);
>>> -	if (IS_ERR(phy->repeater))
>>> -		return dev_err_probe(dev, PTR_ERR(phy->repeater),
>>> -				     "failed to get repeater\n");
>>> +	if (IS_ERR(phy->repeater)) {
>>> +		if (PTR_ERR(phy->repeater) == -ENODEV)
>>> +			phy->repeater = NULL;
>>> +		else
>>> +			return dev_err_probe(dev, PTR_ERR(phy->repeater),
>>> +					     "failed to get repeater\n");
>> Can you use devm_of_phy_optional_get() or devm_phy_optional_get()
>> instead?
>>
> There is such a patch from Ivaylo already [1].
>
> @Ivaylo: Are you planning to re-spin that patch set?

Yes. I've spent the past week digging deeper into how my hardware works,
as well as improving the patchset.

>  Might be even worth
> putting that patch first / sending it separately, since Neil pointed out
> there that the bindings already have the repeater as non-required.

That's going to be... quite a bit of work. I have around 6-7 patches for this
driver alone, including moving the whole driver to ../, so moving this patch
to the front will be annoying.

Best regards,
Ivaylo

>
> Thanks,
> Stephan
>
> [1]: https://lore.kernel.org/linux-arm-msm/20250223122227.725233-6-ivo.ivanov.ivanov1@gmail.com/


  parent reply	other threads:[~2025-03-19 11:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19  3:22 [PATCH 0/2] arm64: dts: qcom: x1e80100-dell-xps13-9345: Enable fingerprint sensor Bjorn Andersson via B4 Relay
2025-03-19  3:22 ` [PATCH 1/2] phy: qcom: phy-qcom-snps-eusb2: Make repeater optional Bjorn Andersson via B4 Relay
2025-03-19 10:20   ` Dmitry Baryshkov
2025-03-19 10:35     ` Stephan Gerhold
2025-03-19 11:07       ` Dmitry Baryshkov
2025-03-19 11:41       ` Ivaylo Ivanov [this message]
2025-03-19  3:22 ` [PATCH 2/2] arm64: dts: qcom: x1e80100-dell-xps13-9345: Enable fingerprint sensor Bjorn Andersson via B4 Relay
2025-03-19 14:29   ` Konrad Dybcio
2025-03-19 15:05   ` Aleksandrs Vinarskis
2025-03-19 19:45     ` Bjorn Andersson
2025-03-20 22:16   ` Bryan O'Donoghue
2025-03-24 14:15   ` Stefan Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=295bd48c-940a-4944-ab3b-ab7cd46e4fef@gmail.com \
    --to=ivo.ivanov.ivanov1@gmail.com \
    --cc=alex.vinarskis@gmail.com \
    --cc=andersson@kernel.org \
    --cc=bjorn.andersson@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=kishon@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=robh@kernel.org \
    --cc=stephan.gerhold@linaro.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).