diff mbox series

[5/8] Revert "dt-bindings: usb: dwc3: Add wakeup-source property support"

Message ID 20220802151404.1797-6-johan+linaro@kernel.org
State New
Headers show
Series usb: dwc3: qcom: fix wakeup implementation | expand

Commit Message

Johan Hovold Aug. 2, 2022, 3:14 p.m. UTC
This reverts commit 098c4d43b91a269e89f60331a26a3f3b914677ed.

A devicetree binding should describe hardware capabilities and not be
used to configure power-management policies (even if things are a bit
blurry when it comes to "wakeup-source"). It should also not be used to
work around Linux driver implementation issues such as how to coordinate
the glue and core dwc3 drivers.

For the Qualcomm dwc3 controllers, it is the glue device that manages
the wakeup interrupts, which may or may not be able to wake the system
up from system suspend.

Also note that USB remote wakeup is always enabled during runtime
suspend.

Fixes: 098c4d43b91a ("dt-bindings: usb: dwc3: Add wakeup-source property support")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
---
 Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 5 -----
 1 file changed, 5 deletions(-)

Comments

Johan Hovold Aug. 3, 2022, 7:31 a.m. UTC | #1
On Tue, Aug 02, 2022 at 11:17:22AM -0600, Rob Herring wrote:
> On Tue, Aug 2, 2022 at 9:14 AM Johan Hovold <johan+linaro@kernel.org> wrote:

> > It should also not be used to
> > work around Linux driver implementation issues such as how to coordinate
> > the glue and core dwc3 drivers.
> >
> > For the Qualcomm dwc3 controllers, it is the glue device that manages
> > the wakeup interrupts, which may or may not be able to wake the system
> > up from system suspend.
> 
> While the reasoning to add this may have been for QCom, having this
> property for other users makes sense. On some platforms, 'snps,dwc3'
> is the only node (i.e. there's no wrapper node). So I don't think this
> should be reverted.

Fair enough. Let's keep it in the core child node then where we can
still retrieve from the glue parent directly.

(I assume you're not suggesting also adding 'wakeup-source' to the qcom
glue node, which is where the actual wakeup interrupts live.)

The glue and core parts needs to work in concert even if the current
implementation tends to make that harder than it should be.

Johan
Krzysztof Kozlowski Aug. 3, 2022, 7:51 a.m. UTC | #2
On 03/08/2022 09:31, Johan Hovold wrote:
> On Tue, Aug 02, 2022 at 11:17:22AM -0600, Rob Herring wrote:
>> On Tue, Aug 2, 2022 at 9:14 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> 
>>> It should also not be used to
>>> work around Linux driver implementation issues such as how to coordinate
>>> the glue and core dwc3 drivers.
>>>
>>> For the Qualcomm dwc3 controllers, it is the glue device that manages
>>> the wakeup interrupts, which may or may not be able to wake the system
>>> up from system suspend.
>>
>> While the reasoning to add this may have been for QCom, having this
>> property for other users makes sense. On some platforms, 'snps,dwc3'
>> is the only node (i.e. there's no wrapper node). So I don't think this
>> should be reverted.
> 
> Fair enough. Let's keep it in the core child node then where we can
> still retrieve from the glue parent directly.
> 
> (I assume you're not suggesting also adding 'wakeup-source' to the qcom
> glue node, which is where the actual wakeup interrupts live.)
> 
> The glue and core parts needs to work in concert even if the current
> implementation tends to make that harder than it should be.

I think it can still exist in the glue node (so your next patch),
because as you said this is the place with wakeup interrupt, so it looks
like correct hardware description. In the next patch you would need to
disallow it for the DWC node.

Best regards,
Krzysztof
Rob Herring Aug. 3, 2022, 11:26 p.m. UTC | #3
On Wed, Aug 03, 2022 at 09:31:06AM +0200, Johan Hovold wrote:
> On Tue, Aug 02, 2022 at 11:17:22AM -0600, Rob Herring wrote:
> > On Tue, Aug 2, 2022 at 9:14 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> 
> > > It should also not be used to
> > > work around Linux driver implementation issues such as how to coordinate
> > > the glue and core dwc3 drivers.
> > >
> > > For the Qualcomm dwc3 controllers, it is the glue device that manages
> > > the wakeup interrupts, which may or may not be able to wake the system
> > > up from system suspend.
> > 
> > While the reasoning to add this may have been for QCom, having this
> > property for other users makes sense. On some platforms, 'snps,dwc3'
> > is the only node (i.e. there's no wrapper node). So I don't think this
> > should be reverted.
> 
> Fair enough. Let's keep it in the core child node then where we can
> still retrieve from the glue parent directly.
> 
> (I assume you're not suggesting also adding 'wakeup-source' to the qcom
> glue node, which is where the actual wakeup interrupts live.)

'wakeup-source' belongs wherever the interrupt that causes wakeup is 
defined.

Rob
Johan Hovold Aug. 4, 2022, 5:47 a.m. UTC | #4
On Wed, Aug 03, 2022 at 05:26:44PM -0600, Rob Herring wrote:
> On Wed, Aug 03, 2022 at 09:31:06AM +0200, Johan Hovold wrote:
> > On Tue, Aug 02, 2022 at 11:17:22AM -0600, Rob Herring wrote:
> > > On Tue, Aug 2, 2022 at 9:14 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> > 
> > > > It should also not be used to
> > > > work around Linux driver implementation issues such as how to coordinate
> > > > the glue and core dwc3 drivers.
> > > >
> > > > For the Qualcomm dwc3 controllers, it is the glue device that manages
> > > > the wakeup interrupts, which may or may not be able to wake the system
> > > > up from system suspend.
> > > 
> > > While the reasoning to add this may have been for QCom, having this
> > > property for other users makes sense. On some platforms, 'snps,dwc3'
> > > is the only node (i.e. there's no wrapper node). So I don't think this
> > > should be reverted.
> > 
> > Fair enough. Let's keep it in the core child node then where we can
> > still retrieve from the glue parent directly.
> > 
> > (I assume you're not suggesting also adding 'wakeup-source' to the qcom
> > glue node, which is where the actual wakeup interrupts live.)
> 
> 'wakeup-source' belongs wherever the interrupt that causes wakeup is 
> defined.

Thanks for clarifying. That was my understanding as well, but I
misinterpreted your wish to keep the 'wakeup-source' property also in
the core node.

My thought was that if it turns out that there are systems that do not
use a glue node but that do indeed support wakeup, then such a property
could be added back later.

But let's keep it in the binding then.

Johan
Johan Hovold Aug. 4, 2022, 7:37 a.m. UTC | #5
On Wed, Aug 03, 2022 at 09:51:00AM +0200, Krzysztof Kozlowski wrote:
> On 03/08/2022 09:31, Johan Hovold wrote:
> > On Tue, Aug 02, 2022 at 11:17:22AM -0600, Rob Herring wrote:
> >> On Tue, Aug 2, 2022 at 9:14 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> > 
> >>> It should also not be used to
> >>> work around Linux driver implementation issues such as how to coordinate
> >>> the glue and core dwc3 drivers.
> >>>
> >>> For the Qualcomm dwc3 controllers, it is the glue device that manages
> >>> the wakeup interrupts, which may or may not be able to wake the system
> >>> up from system suspend.
> >>
> >> While the reasoning to add this may have been for QCom, having this
> >> property for other users makes sense. On some platforms, 'snps,dwc3'
> >> is the only node (i.e. there's no wrapper node). So I don't think this
> >> should be reverted.
> > 
> > Fair enough. Let's keep it in the core child node then where we can
> > still retrieve from the glue parent directly.
> > 
> > (I assume you're not suggesting also adding 'wakeup-source' to the qcom
> > glue node, which is where the actual wakeup interrupts live.)
> > 
> > The glue and core parts needs to work in concert even if the current
> > implementation tends to make that harder than it should be.
> 
> I think it can still exist in the glue node (so your next patch),
> because as you said this is the place with wakeup interrupt, so it looks
> like correct hardware description. In the next patch you would need to
> disallow it for the DWC node.

Ok, will do. Thanks.

Johan
Johan Hovold Aug. 4, 2022, 7:40 a.m. UTC | #6
On Thu, Aug 04, 2022 at 07:47:35AM +0200, Johan Hovold wrote:
> On Wed, Aug 03, 2022 at 05:26:44PM -0600, Rob Herring wrote:
> > On Wed, Aug 03, 2022 at 09:31:06AM +0200, Johan Hovold wrote:
> > > On Tue, Aug 02, 2022 at 11:17:22AM -0600, Rob Herring wrote:
> > > > On Tue, Aug 2, 2022 at 9:14 AM Johan Hovold <johan+linaro@kernel.org> wrote:
> > > 
> > > > > It should also not be used to
> > > > > work around Linux driver implementation issues such as how to coordinate
> > > > > the glue and core dwc3 drivers.
> > > > >
> > > > > For the Qualcomm dwc3 controllers, it is the glue device that manages
> > > > > the wakeup interrupts, which may or may not be able to wake the system
> > > > > up from system suspend.
> > > > 
> > > > While the reasoning to add this may have been for QCom, having this
> > > > property for other users makes sense. On some platforms, 'snps,dwc3'
> > > > is the only node (i.e. there's no wrapper node). So I don't think this
> > > > should be reverted.
> > > 
> > > Fair enough. Let's keep it in the core child node then where we can
> > > still retrieve from the glue parent directly.
> > > 
> > > (I assume you're not suggesting also adding 'wakeup-source' to the qcom
> > > glue node, which is where the actual wakeup interrupts live.)
> > 
> > 'wakeup-source' belongs wherever the interrupt that causes wakeup is 
> > defined.
> 
> Thanks for clarifying. That was my understanding as well, but I
> misinterpreted your wish to keep the 'wakeup-source' property also in
> the core node.
> 
> My thought was that if it turns out that there are systems that do not
> use a glue node but that do indeed support wakeup, then such a property
> could be added back later.
> 
> But let's keep it in the binding then.

I realise it may not have been clear that the patch I suggested to
revert was first merged for 6.0-rc1, in case that makes any difference.

But I'll drop the revert unless I hear otherwise.

Johan
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index 1779d08ba1c0..d41265ba8ce2 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -343,11 +343,6 @@  properties:
       This port is used with the 'usb-role-switch' property  to connect the
       dwc3 to type C connector.
 
-  wakeup-source:
-    $ref: /schemas/types.yaml#/definitions/flag
-    description:
-      Enable USB remote wakeup.
-
 unevaluatedProperties: false
 
 required: