From: Greg KH <greg@kroah.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"balbi@kernel.org" <balbi@kernel.org>
Subject: Re: Aspeed vhub configuration
Date: Tue, 2 Jul 2019 14:24:30 +0200 [thread overview]
Message-ID: <20190702122430.GC12019@kroah.com> (raw)
In-Reply-To: <44bb150fb8b283a3036a382fa7e821b045554c15.camel@kernel.crashing.org>
On Tue, Jul 02, 2019 at 09:33:11PM +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> The Aspeed USB gadget "vhub" implements a hub emulation with a number
> of UDCs representing the hub slots. It's working ok now and has been
> upstream for a bit, however, one thing that's been annoying to some
> users is that I've just hard coded the hub's device descriptor. IE, the
> vendor/product ID, strings etc...
>
> Various BMC SW stack vendors want to customize that, also possibly the
> number of ports etc...
>
> I originally thought about configfs but after more thoughts I don't
> think it's really a good fit. The vhub is a fixed thing. When you have
> the HW, you have that hub, it's not like you can create different
> things, and populate differently.
>
> That leaves me with two approaches, that aren't mutually exclusive, but
> I'd like to run them past the folks here before I start coding:
>
> - The defaults, currently hard coded, could be replaced with Kconfig
> options.
>
> - The device-tree node could contain optional override of those
> defaults, allowing a vendor to customize the hub for a given board.
> It's not per-se a HW description, but the device-tree is also fairly
> commonly used for HW configuration, even if some people disagree with
> me on that one (hint: they are wrong :-)
>
> - I could add sysfs properties underneath the vhub device instance to
> customize it. This would also allow userspace to control whether the
> hub is "connected" to the host or not, which could be useful, some
> systems don't want it to always be there. Today there's no choice.
>
> Any other option ? If somebody says netlink I will scream :)
DT seems like the logical choice, I'll not object to that.
thanks,
greg k-h
next prev parent reply other threads:[~2019-07-02 12:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 11:33 Aspeed vhub configuration Benjamin Herrenschmidt
2019-07-02 12:24 ` Greg KH [this message]
2019-07-02 12:29 ` Benjamin Herrenschmidt
2019-07-02 12:56 ` Felipe Balbi
2019-07-02 13:10 ` Benjamin Herrenschmidt
2019-07-03 6:24 ` Felipe Balbi
2019-07-03 22:52 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190702122430.GC12019@kroah.com \
--to=greg@kroah.com \
--cc=balbi@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.