Re: [PATCH 1/2] arm64: dts: qcom: x1e80100-crd: Add USB multiport fingerprint reader

[Johan Hovold <johan@kernel.org>]

On Thu, Dec 05, 2024 at 01:32:29PM +0530, Krishna Kurapati wrote:
> On 12/3/2024 6:45 PM, Krishna Kurapati wrote:
> > On 12/3/2024 3:50 PM, Johan Hovold wrote:
> >> On Mon, Nov 18, 2024 at 11:34:29AM +0100, Stephan Gerhold wrote:

> >>> +&usb_mp_dwc3 {
> >>> +    /* Limit to USB 2.0 and single port */
> >>> +    maximum-speed = "high-speed";
> >>> +    phys = <&usb_mp_hsphy1>;
> >>> +    phy-names = "usb2-1";
> >>> +};
> >>
> >> The dwc3 driver determines (and acts on) the number of ports based on
> >> the port interrupts in DT and controller capabilities.
> >>
> >> I'm not sure we can (should) just drop the other HS PHY and the SS PHYs
> >> that would still be there in the SoC (possibly initialised by the boot
> >> firmware).
> > 
> > The DWC3 core driver identifies number of ports based on xHCI registers. 
> > The QC Wrapper reads this number via interrupts. But these two values 
> > are independent of each other. The core driver uses these values to 
> > identify and manipulate phys. Even if only one HS is given in multiport 
> > it would be sufficient if the name is "usb2-1". If the others are 
> > missing, those phys would be read by driver as NULL and any ops to phys 
> > would be NOP.

No, the core driver still acts on these ports (to some extent) even if
there is no PHY specified (e.g. updates DWC3_GUSB2PHYCFG on suspend).

And IIRC I even had to specify more than just the fingerprint reader PHY
on the X13s to get it to enumerate. I never had time to fully determine
why this was the case though.

> However do we need to reduce the number of interrupts used in DTS ?
> We don't need to give all interrupts as there is only one port present.
> We don't want to enable all interrupts when ports are not exposed.

No, the interrupts are still there, wired up in the SoC, so we should
not change that.

With runtime PM eventually enabled and working as it should, the OS
should be able to power down any unused ports. And we could also
consider marking some ports as not physically accessible and not
connected as a further hint to the OS that they can be disabled even
sooner.

Johan