From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Rob Herring <robh@kernel.org>
Cc: rentao.bupt@gmail.com, Felipe Balbi <balbi@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
Colin Ian King <colin.king@canonical.com>,
Stephen Boyd <swboyd@chromium.org>,
Mark Rutland <mark.rutland@arm.com>,
Linux USB List <linux-usb@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-aspeed@lists.ozlabs.org, devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
Tao Ren <taoren@fb.com>
Subject: Re: [PATCH v2 6/6] dt-bindings: usb: document aspeed vhub device ID/string properties
Date: Thu, 02 Apr 2020 21:37:35 +1100 [thread overview]
Message-ID: <c556467d63cd5de806b4bf1806caee013ba5a808.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAL_JsqKZeCC352TKFGDNRRogSefF9vq+J=WqCEeg59PBsSOW1w@mail.gmail.com>
On Tue, 2020-03-31 at 10:21 -0600, Rob Herring wrote:
> Surely the descriptor building code can be shared at a minimum.
>
> Regardless of whether gadget configfs fits, usually it is pretty clear
> whether something belongs in DT or userspace. That should be decided
> first.
>
> > Maybe we could expose the port as UDCs but not actually expose them on
> > the bus until the hub is "activated" via a special configfs entry...
>
> If control of the hub is done by userspace, I'd think configuration
> should be there too.
It's not in the current driver. For now, I expose the hub when the
driver loads/initializes, and it creates UDCs for each port, which are
then controlled from userspace.
That said, I did it this way because it was easy, not because there are
fundamental reasons to do so...
The main reason to want to change the hub descriptor is for the device
to advertise a vendor/device ID rather than our generic linux one,
which some vendors might want to do for ... reasons. I didn't implement
that functionality initially as in openbmc case, we didn't care. But I
know some vendors would like to, if anything because from a user
perspective, it's actually nice to have the string tell you that it's
your BMC rather than Linux Fundation Hub.
Originally I suggested we allow that via the device-tree because it was
the simplest way to get there and I love have to deal with less code ..
:)
However, if we want to support the whole language string set etc... it
gets really clumsy. So if there's a strong will to get there all the
way, then configfs is probably the way to go.
In that case, some sugery will probably be needed to make the gadget
descriptor building code a bit less dependent on the overall gadget
stuff... either that, or pre-create a "hub" gadget at driver loading
time that userspace can modify before "plugging".
In that case, the discussion should move back to linux-usb...
Cheers,
Ben.
prev parent reply other threads:[~2020-04-02 10:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-15 19:16 [PATCH v2 0/6] usb: gadget: aspeed: allow to customize vhub device rentao.bupt
2020-03-15 19:16 ` [PATCH v2 1/6] usb: gadget: aspeed: support multiple language strings rentao.bupt
2020-03-15 19:16 ` [PATCH v2 2/6] usb: gadget: add "usb_validate_langid" function rentao.bupt
2020-03-15 19:16 ` [PATCH v2 3/6] usb: gadget: aspeed: allow to set usb strings in device tree rentao.bupt
2020-03-15 19:16 ` [PATCH v2 4/6] usb: gadget: aspeed: allow to set device IDs " rentao.bupt
2020-03-15 19:16 ` [PATCH v2 5/6] usb: gadget: aspeed: fixup usb1 device descriptor at init time rentao.bupt
2020-03-15 19:16 ` [PATCH v2 6/6] dt-bindings: usb: document aspeed vhub device ID/string properties rentao.bupt
2020-03-30 19:23 ` Rob Herring
2020-03-31 0:13 ` Benjamin Herrenschmidt
2020-03-31 16:21 ` Rob Herring
2020-04-01 0:47 ` Tao Ren
2020-04-02 10:37 ` Benjamin Herrenschmidt [this message]
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=c556467d63cd5de806b4bf1806caee013ba5a808.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=andrew@aj.id.au \
--cc=balbi@kernel.org \
--cc=chunfeng.yun@mediatek.com \
--cc=colin.king@canonical.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=openbmc@lists.ozlabs.org \
--cc=rentao.bupt@gmail.com \
--cc=robh@kernel.org \
--cc=swboyd@chromium.org \
--cc=taoren@fb.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).