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: <ZGOWayVsjhR2Y0cN@hovoldconsulting.com>
Date:   Tue, 16 May 2023 16:42:51 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
Cc:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Felipe Balbi <balbi@...nel.org>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, quic_pkondeti@...cinc.com,
        quic_ppratap@...cinc.com, quic_wcheng@...cinc.com,
        quic_jackp@...cinc.com, quic_harshq@...cinc.com,
        ahalaney@...hat.com
Subject: Re: [PATCH v8 7/9] arm64: dts: qcom: sc8280xp: Add multiport
 controller node for SC8280

On Tue, May 16, 2023 at 07:54:00PM +0530, Krishna Kurapati PSSNV wrote:
> 
> 
> On 5/16/2023 4:24 PM, Johan Hovold wrote:
> > On Mon, May 15, 2023 at 09:02:13PM +0530, Krishna Kurapati PSSNV wrote:
> >> On 5/15/2023 7:56 PM, Johan Hovold wrote:
> >>> On Sun, May 14, 2023 at 11:19:15AM +0530, Krishna Kurapati wrote:
> > 
> >>>> @@ -3133,6 +3133,72 @@ usb_1_role_switch: endpoint {
> >>>>    			};
> >>>>    		};
> >>>>    
> >>>> +		usb_2: usb@...8800 {
> >>>
> >>> As I believe someone already pointed out, this node is not in sort order
> >>> (i.e. it should go before usb@...8800).
> > 
> >>     I missed that message, but since I named it usb_2, so I placed it in
> >> order after usb_1. Hope that is fine !!
> > 
> > No, the nodes should be sorted by unit address so you need to move it.
> > 
> 
> Sure, in that case will put it in between usb_0 and usb_1 nodes.

No, it goes before usb_0 on sc8280xp.

           usb_2: usb@...8800 {
           usb_0: usb@...8800 {
           usb_1: usb@...8800 {

> >>>> +			interrupts-extended = <&pdc 127 IRQ_TYPE_EDGE_RISING>,
> >>>> +					      <&pdc 126 IRQ_TYPE_EDGE_RISING>,
> >>>> +					      <&pdc 16 IRQ_TYPE_LEVEL_HIGH>,
> >>>> +					      <&intc GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
> >>>> +					      <&intc GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
> >>>> +					      <&intc GIC_SPI 857 IRQ_TYPE_LEVEL_HIGH>,
> >>>> +					      <&intc GIC_SPI 856 IRQ_TYPE_LEVEL_HIGH>;
> >>>> +
> >>>> +			interrupt-names = "dp_hs_phy_irq",
> >>>> +					  "dm_hs_phy_irq",
> >>>> +					  "ss_phy_irq",
> >>>> +					  "pwr_event_1",
> >>>> +					  "pwr_event_2",
> >>>> +					  "pwr_event_3",
> >>>> +					  "pwr_event_4";
> > 
> >>>> +			interconnect-names = "usb-ddr", "apps-usb";
> >>>
> >>> Looks like 'wakeup-source' is missing here too.
> >>>
> >>
> >> I believe this property was added to enable wakeup from system suspend
> >> in host mode. I didn't add this property as currently I don't need to
> >> support wakeup. If any requirement comes in future, then I might need to
> >> add dp/dm interrupts (if any) for other ports as well and then need to
> >> change driver code to enable/disable them on suspend/resume.
> > 
> > If there are dp/dm/ss interrupts per ports then those need to be defined
> > in the binding and devicetree from the start.
> > 
> > Similar for 'wakeup-source' which indicates that the controller *can* be
> > used to wakeup the system from suspend (which those pdc interrupts
> > indicates).
> > 
> > Remember that the devicetree is supposed to describe the hardware, and
> > which features are currently supported in some version of software is
> > mostly irrelevant.

> Can I take this up as a separate series (Wakeup support for multiport) 
> once this series is merged. If I am adding interrupts for other ports, I 
> can add driver code to handle those interrupts as well.

Nope. You can possibly add driver support later, but the binding and
dtsi need to be correct from the start (and it may be easier to do it
all at once).

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ