Re: [PATCH v2 7/9] dt-bindings: usb: qcom,dwc3: add wakeup-source property

[Manivannan Sadhasivam]

On Sat, Aug 06, 2022 at 07:09:44PM +0200, Johan Hovold wrote:
> On Sat, Aug 06, 2022 at 10:22:38PM +0530, Manivannan Sadhasivam wrote:
> > 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?
> 
> No, not really. They wouldn't violate the current binding, but it would
> arguably still be wrong to do so unless that platform actually supports
> wakeup without involvement from a glue layer.
> 
> Perhaps we should reconsider reverting the binding update adding this
> property to the core node and only add it selectively for the platforms
> for which is actually applies (if they even exist).
> 

That sounds right to me.

> > I know it is broken currently, but moving the wakeup parsing code is not
> > helping either.
> 
> It's not even broken. It has never even been implemented.
> 
> Just because someone added a hack that should probably never have been
> merged in the first place, doesn't mean we should somehow pretend that
> we support it.
> 
> > 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?
> 
> I'd rather just revert the binding update to avoid having discussions
> like this. We don't even know if it's possible to support on any
> platform yet (and remember that none of this has even been in an rc
> release yet).
> 

Okay.

Thanks,
Mani

> Johan

-- 
மணிவண்ணன் சதாசிவம்