[PATCH v2 0/3] USB: add generic onboard USB HUB driver
Peter Chen
hzpeterchen at gmail.com
Wed Feb 24 01:22:52 PST 2016
On Thu, Jan 07, 2016 at 08:18:02AM -0600, Rob Herring wrote:
> On Tue, Jan 5, 2016 at 9:20 PM, Peter Chen <hzpeterchen at gmail.com> wrote:
> > On Tue, Jan 05, 2016 at 08:36:31AM -0600, Rob Herring wrote:
> >> > 2. There are MFD USB devices, which includes several interfaces under
> >> > USB device,
> >> > like i2c, gpios, etc. Due to lack of device tree support, USB
> >> > class/device driver doesn't know
> >> > which kinds of interfaces are needed for this board.
> >>
> >> Are you talking about a device hard wired on the same board or
> >> something like GPIOs on FTDI chip which could be hot-plugged in any
> >> host (including non-DT based)?
> >
> > I talked about the case that the device hard wired on the board.
> > Hot-plug device's bus topology is unknown, we can't describe it
> > statically at dts.
>
> Correct, upstream (the USB side) can't be described, but it is the
> downstream side we care about describing.
>
> >> For the hotplug case, we will need a way to associate a DT overlay
> >> with the USB device and there may not even be a base DT to map the
> >> overlay into. In this case, the USB device's driver will need to load
> >> the overlay and trigger enumerating the child devices. Anyway, this is
> >> a separate issue from your problem.
> >>
> >
> > Since both you and Alan agree with my problem should be fixed at
> > bootloader, I give the kernel solution up.
>
> Surprising, no one ever seems to agree with that solution... There
> will be people with this problem and unable to update their
> bootloader.
>
Hi Rob, I noticed there are still some platform needs to this solution,
I would like to see if I can move this on, please review below dts
solution. In below case, there are two ports on the root hub, one is
USB HUB, the another is a USB wifi. Both of these devices need to have
power control before they can work.
At USB hcd driver, it will try to look-up all USB devices on this
controller, if the usb-pwr-ops is existed, it will try to get its
phandle, and do gpio and clock operations.
Optional properties:
- usb-pwr-ops: the power operations which need to do before this USB device
can work.
Example:
/ {
...
hub_genesys_1_pwr_ops: hub_genesys_1_pwr_ops {
compatible = "usb-pwrseq-simple";
reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
reset-duration-us = <10>;
clocks = <&clks IMX6QDL_CLK_CKO>;
};
wifi_nxp_2_pwr_ops: wifi_nxp_2_pwr_ops {
compatible = "usb-pwrseq-simple";
reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>, /* wifi_rst */
<&gpio4 7 GPIO_ACTIVE_LOW>; /* wifi_en */
reset-duration-us = <10>;
clocks = <&clks IMX6QDL_CLK_CKO1>;
};
...
};
&usb1 {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
hub: genesys at 1 {
compatible = "usb5e3,608";
reg = <1>;
usb-pwr-ops = <&hub_genesys_1_pwr_ops>
};
wifi: nxp at 2 {
compatible = "usb5e3,608";
reg = <2>;
usb-pwr-ops = <&wifi_nxp_2_pwr_ops>
};
}
--
Best Regards,
Peter Chen
More information about the linux-arm-kernel
mailing list