>> + 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 ? - Nagarjuna > Thierry > >> + nvidia,xusb-padctl = <&padctl>; >> + extcon = <&extcon_usb>; >> + }; >> -- >> 2.7.4
