[6/8] dt-bindings: usb: Add NVIDIA Tegra XUSB device mode controller binding

[Thierry Reding <thierry.reding@gmail.com>]

On Thu, Feb 14, 2019 at 08:26:52PM +0530, Nagarjuna Kristam wrote:
> >> +		reg = <0x0 0x700d0000 0x0 0x8000>,
> >> +			<0x0 0x700d8000 0x0 0x1000>,
> >> +			<0x0 0x700d9000 0x0 0x1000>;
> >> +		interrupts = <0 44 0x4>;
> >> +		clocks = <&tegra_car TEGRA210_CLK_XUSB_DEV>,
> >> +			<&tegra_car TEGRA210_CLK_XUSB_SS>,
> >> +			<&tegra_car TEGRA210_CLK_XUSB_SSP_SRC>,
> >> +			<&tegra_car TEGRA210_CLK_XUSB_HS_SRC>,
> >> +			<&tegra_car TEGRA210_CLK_XUSB_FS_SRC>;
> > 
> > It's typical for common properties to go first and have more exotic ones
> > later. See other device tree nodes and try to stay consistent.
> > 
> > Also, does this not need any resets? I know that these are probably
> > dealt with as part of the power domains, but the DT should still
> > describe all signals that go into and come out of a block. The fact that
> > the driver doesn't use them is on OS-specific implementation detail.
> > 
> > Also, there's been some discussion surrounding shared resets lately and
> > we might end up with a situation where both the power domains and the
> > driver can again request an exclusive reset and make sure they only use
> > it exclusively at runtime.
> > 
> Since Resets are part of power domains, Is it fine to add reference of its
> mention by providing power domain handles here similar to extcon ?

Yes, I think that's fine. We should describe the hardware and its
dependencies. That the reset is typically used by the power domains is
an implementation detail.

Also, there's work in progress to allow resets to be marked temporarily
exclusive, which will allow them to be used both from the power domains
but also from drivers if they have a need to assert/deassert explicitly:

	http://patchwork.ozlabs.org/project/linux-tegra/list/?series=93420

We need this for display support, but I'm not sure if it's relevant for
XUSB. Do you know of any cases in XUSB where this might be useful? In
either case, I think it makes sense to list the resets in this node just
in case. If we don't need them in the kernel, that's fine, but we should
have them in DT in case we ever need them, or if another OS decides to
use them differently.

Thierry