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@xxxxxxxxxx> 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
