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]

Message-ID: <Yu6gWHt5BphADaNR@hovoldconsulting.com>
Date:   Sat, 6 Aug 2022 19:09:44 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.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 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).

> 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).

Johan