On Sat, Aug 06, 2022 at 06:41:37PM +0200, Johan Hovold wrote: > On Sat, Aug 06, 2022 at 08:38:48PM +0530, Manivannan Sadhasivam wrote: > > On Thu, Aug 04, 2022 at 05:09:59PM +0200, Johan Hovold wrote: > > > Add a wakeup-source property to the binding to describe whether the > > > wakeup interrupts can wake the system from suspend. > > > > > > Acked-by: Rob Herring <robh@xxxxxxxxxx> > > > Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx> > > > > So this is based on the fact that Qcom glue wrapper is supplying the wakeup > > interrupts. But isn't it possible that on other platform, the DWC IP can supply > > wakeup interrupts? > > Yeah, possibly, and that's why Rob suggested keeping the 'wakeup-source' > property also in the core node. > > > In the driver, the wakeup-source parsing has been moved to the Qcom glue driver. > > But this contradicts with the binding. > > That's irrelevant. The core driver does not implement wakeup support. It > was just added as a hack for the Qualcomm driver, and you won't get > wakeup-capability for other platforms by just parsing the property in > the core driver. > > When/if wakeup support for such a platform is added, then the core > driver may need to look at the property again. > My point is, the platform drivers are free to add "wakeup-source" property in the DWC node. Then in that case, the DWC driver should handle the capability, isn't it? I know it is broken currently, but moving the wakeup parsing code is not helping either. And... I'm aware of the fact that the binding should describe the hardware and not the limitation of the driver. So perhaps we should document it in the driver as a TODO or something? Thanks, Mani > Johan -- மணிவண்ணன் சதாசிவம்
