[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29752cbf-9fe4-48ce-bf21-0bb3daf7d691@quicinc.com>
Date: Fri, 3 Nov 2023 23:54:16 +0530
From: Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To: Caleb Connolly <caleb.connolly@...aro.org>,
Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
Bjorn Andersson <andersson@...nel.org>,
"Konrad Dybcio" <konrad.dybcio@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
CC: <quic_wcheng@...cinc.com>, <linux-usb@...r.kernel.org>,
Conor Dooley <conor+dt@...nel.org>,
<linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
Andy Gross <agross@...nel.org>,
"Philipp Zabel" <p.zabel@...gutronix.de>,
Rob Herring <robh+dt@...nel.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
<devicetree@...r.kernel.org>, <quic_ppratap@...cinc.com>,
<quic_jackp@...cinc.com>
Subject: Re: [RFC 1/8] dt-bindings: usb: qcom,dwc3: Add bindings to enable
runtime
On 11/3/2023 8:26 PM, Caleb Connolly wrote:
>
>
> On 03/11/2023 05:34, Krishna Kurapati PSSNV wrote:
>>
>>
>> On 11/3/2023 12:10 AM, Caleb Connolly wrote:
>>>> Hi Caleb,
>>>>
>>>> There are two types of platforms, some use extcon and some use
>>>> role-switch to deliver vbus/id notifications. Extcon targets already
>>>> have this qscratch modifications present today in vbus and id
>>>> handlers. But for role-switch based targets we don't have any way to
>>>> get this notification to dwc3-qcom. In this implementation, I wanted
>>>> to get those notications from core to glue and for this we
>>>> implenented vendor hooks.
>>>>
>>>> The property added has been used to do two things:
>>>>
>>>> 1. Register glue's vendor hooks to core driver
>>>> 2. Do runtime_allow for glue (and by default for core as the dt is
>>>> not flattened)
>>>>
>>>> In case of extcon, we don't want to register vendor hooks as
>>>> notifications are not necessary.
>>>
>>> Could it just be enabled when role_switch is present then?
>>>>
>>
>> So we would register vendor hooks when usb-role-switch is present but
>> don't do runtime allow, and leave that option to user space right ?
>> I think it would work and we can do away with the binding completely.
>
> Can we still enable runtime suspend? Maybe someone else wants to chime
> in here, but I'd guess that it's preferable to have it enabled by
> default, particularly for devices like phones. Or are there side effects
> from this?
>>
AFAIK, I don't see any side effects whether we enable runtime from user
space or do runtime_allow() here in kernel itself and leave qscratch
config to vendor hooks.
But leaving it enabled by default, we do this for almost all targets in
downstream today. So I guess there would be no side effects.
Regards,
Krishna,
Powered by blists - more mailing lists