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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Aug 2022 13:35:22 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Felipe Balbi <balbi@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Krishna Kurapati <quic_kriskura@...cinc.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Pavankumar Kondeti <quic_pkondeti@...cinc.com>,
        quic_ppratap@...cinc.com, quic_vpulyala@...cinc.com,
        linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v2 7/9] dt-bindings: usb: qcom,dwc3: add wakeup-source
 property

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@...nel.org>
> > > > > Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> > > > 
> > > > 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

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