[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <622c0fd6-e4e2-6597-d0a2-ff449d7d2f59@quicinc.com>
Date: Tue, 6 Aug 2024 11:58:02 -0700
From: Trilok Soni <quic_tsoni@...cinc.com>
To: Caleb Connolly <caleb.connolly@...aro.org>,
Elson Roy Serrao
<quic_eserrao@...cinc.com>, <andersson@...nel.org>,
<konrad.dybcio@...aro.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
<conor+dt@...nel.org>, <gregkh@...uxfoundation.org>
CC: <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 0/8] Enable EUD on Qualcomm sm8450 SoC
On 8/1/2024 3:52 AM, Caleb Connolly wrote:
> Hi Trilok,
>
> On 31/07/2024 21:58, Trilok Soni wrote:
>> On 7/31/2024 4:13 AM, Caleb Connolly wrote:
>>>> 2.) Proper routing of USB role switch notifications: EUD hub is physically
>>>> present in between the USB connector and the USB controller. So the
>>>> usb role switch notifications originating from the connector should
>>>> route through EUD. EUD also relies on role switch notifications to
>>>> communicate with the USB, regarding EUD attach/detach events.
>>>>
>>>> This series aims at implementing the above aspects to enable EUD on
>>>> Qualcomm sm8450 SoC.
>>>
>>> Are there any plans to make this feature available for folks outside of Qualcomm / an NDA?
>>>
>>> There is an openOCD fork on CodeLinaro but it still requires some proprietary library which is only available to folks with a quicinc email as I understand it.
>>>
>>
>> Which codelinaro link are you referring here?
>
> That would be https://git.codelinaro.org/clo/la/openocd-org/openocd/-/blob/qcom_changes/README_QCOM?ref_type=heads
>
> Which says:
>
> Qualcomm specific tools:
> - Login to qpm.qualcomm.com
> - QUTS: 1.64.1.39 (version & above)
> - Qualcomm Host USB Product Suite - QUD QC only : 1.00.63 (supported version)
> - EUD QC : 2.1.1 (supported version)
>
> I believe the specific versions of QUD and EUD are only available to Qualcomm engineers and not even to OEMs, though I might be mistaken.
Thanks. So are we okay w/ one of the following option? (trying to understand the need here properly before I relay it internally).
Options:
(1) Provide EUD library and tools - proprietary w/o any login requirement.
(2) Provide open-source EUD library and tools w/o any login requirement.
Is Option (1) fine to begin with or option 2 is must?
--
---Trilok Soni
Powered by blists - more mailing lists