[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200228081309.GA4531@taoren-ubuntuvm>
Date: Fri, 28 Feb 2020 00:13:11 -0800
From: Tao Ren <rentao.bupt@...il.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Mark Rutland <mark.rutland@....com>,
Felipe Balbi <balbi@...nel.org>, linux-aspeed@...ts.ozlabs.org,
devicetree@...r.kernel.org, Andrew Jeffery <andrew@...id.au>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
openbmc@...ts.ozlabs.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, Stephen Boyd <swboyd@...omium.org>,
Rob Herring <robh+dt@...nel.org>,
Joel Stanley <joel@....id.au>, taoren@...com,
Chunfeng Yun <chunfeng.yun@...iatek.com>,
Colin Ian King <colin.king@...onical.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 7/7] dt-bindings: usb: add documentation for aspeed
usb-vhub
On Fri, Feb 28, 2020 at 02:02:28PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2020-02-27 at 17:05 -0800, Tao Ren wrote:
> > > Also long run I think best is going to have a child node per downstream
> > > port, so we create a matching linux struct device. This will make it
> > > easier to deal with the other device-controller in the ast2600 which is
> > > basically one of these without a vhub above it.
> >
> > Maybe a dumb question: what would be the proper place to parse the child
> > node/properties when they are added? For example, in some usb_gadget_ops
> > callback?
>
> No. What the vhub would do is when it probes, it creates a platform
> device for each "port" child node that's linked to the DT node.
>
> The driver for the device then attaches to it via standard DT matching
> and checks if it has a vhub parent or not, and based on that, operates
> as a vhub child device or a standalone one.
>
> (For example, it might have different functions for EP selection since
> standalone devices have private EPs rather than a shared pool)
>
> They can both be in the same module or they can be separate modules
> with cross dependencies.
>
> Cheers,
> Ben.
I see. It's to describe these downstream devices (such as configurations
and according functions) in device tree, which is similar to defining a
composite device and linking functions/interfaces via configfs. Thanks for
the clarify.
Cheers,
Tao
Powered by blists - more mailing lists