From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Felipe Balbi <balbi@kernel.org>, linux-usb@vger.kernel.org
Cc: Greg KH <greg@kroah.com>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@aj.id.au>
Subject: [v4,2/2] usb/gadget: Add driver for Aspeed SoC virtual hub
Date: Wed, 14 Mar 2018 14:53:36 +1100 [thread overview]
Message-ID: <1520999616.16434.100.camel@kernel.crashing.org> (raw)
On Tue, 2018-03-13 at 09:35 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2018-03-09 at 11:20 +0200, Felipe Balbi wrote:
> >
> > > diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > > new file mode 100644
> > > index 000000000000..31ed2b6e241b
> > > --- /dev/null
> > > +++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > > @@ -0,0 +1,429 @@
> >
> > missing SPDX license identifier (all files)
>
> Ah yup, the driver predates me knowing about them, I'll fix.
>
> > > +static bool force_usb1 = false;
> > > +static bool no_dma_desc = false;
> > > +
> > > +module_param_named(force_usb1, force_usb1, bool, 0644);
> > > +MODULE_PARM_DESC(force_usb1, "Set to true to force to USB1 speed");
> > > +module_param_named(no_dma_desc, no_dma_desc, bool, 0644);
> > > +MODULE_PARM_DESC(no_dma_desc, "Set to true to disable use of DMA descriptors");
> >
> > module parameters? Sorry, but no.
>
> Why ? Any suggestion then for the two above ? They are mostly meant as
> diagnostic/debug features if something doesn't work (for example, the
> board has some sub-standard wiring making USB2 unreliable, or a driver
> bug with DMA descriptors).
>
> I can just take them out completely but it feels like module parameters
> are the right thing to do in that specific case.
I've taken out the second one, it isn't that useful. I've left in the
first one however. This is the right thing to do. That setting (force
USB1 mode) needs to be applied as soon as the vhub gets initialized
at driver load time, regardless of what gadgets might be attached to
it later on.
It's purely a diagnostic function, I don't see a point having it
elsewhere.
.../...
> > > +void ast_vhub_init_hw(struct ast_vhub *vhub)
> > > +{
> > > + u32 ctrl;
> > > +
> > > + UDCDBG(vhub,"(Re)Starting HW ...\n");
> > > +
> > > + /* Enable PHY */
> > > + ctrl = VHUB_CTRL_PHY_CLK |
> > > + VHUB_CTRL_PHY_RESET_DIS;
> > > +
> > > +#if 0 /*
> > > + * This causes registers to become inaccessible during
> > > + * suspend. Need to figure out how to bring the controller
> > > + * back into life to issue a wakeup.
> > > + */
> > > + ctrl |= VHUB_CTRL_CLK_STOP_SUSPEND;
> > > +#endif
> >
> > no commented code.
>
> Why ? This documents a HW issue ... ie, one would normally want to set
> this bit but you can't because in practice you can't bring the HW back
> short of doing a full reset.
So I don't want to lose the "HW documentation" part of that, I've
turned the above into a comment:
/*
* We do *NOT* set the VHUB_CTRL_CLK_STOP_SUSPEND bit
* to stop the logic clock during suspend because
* it causes the registers to become inaccessible and
* we haven't yet figured out a good wayt to bring the
* controller back into life to issue a wakeup.
*/
It will be in v5 when I post it (I'll test a bit more and wait
for other replies from you, if I don't hear back I'll probably send
it by end of week or next week).
> > > + /*
> > > + * Set some ISO & split control bits according to Aspeed
> > > + * recommendation
> > > + *
> > > + * VHUB_CTRL_ISO_RSP_CTRL: When set tells the HW to respond
> > > + * with 0 bytes data packet to ISO IN endpoints when no data
> > > + * is available.
> > > + *
> > > + * VHUB_CTRL_SPLIT_IN: This makes a SOF complete a split IN
> > > + * transaction.
> > > + */
> > > + ctrl |= VHUB_CTRL_ISO_RSP_CTRL | VHUB_CTRL_SPLIT_IN;
> > > + writel(ctrl, vhub->regs + AST_VHUB_CTRL);
> > > + udelay(1);
> > > +
> > > + /* Set descriptor ring size */
> > > +#if AST_VHUB_DESCS_COUNT == 256
> > > + ctrl |= VHUB_CTRL_LONG_DESC;
> > > + writel(ctrl, vhub->regs + AST_VHUB_CTRL);
> > > +#elif AST_VHUB_DESCS_COUNT != 32
> > > + #error Invalid AST_VHUB_DESCS_COUNT
> > > +#endif
> >
> > find a better way for this. No ifdefs
>
> Ugh ? What's that rule ? I could do a module parameter but you hate
> that too and honestly keeping that an ifdef makes things easier. It's
> not meant to be changed unless a hardware or performance issues shows
> up, I wanted to keep both mode of operations available.
Oh well, I've just made it an if () and kept the #define, and the
#error turns into a BUILD_BUG_ON(). Same principle... but I don't
like those arbitrary "rules", I try to avoid them for things I
maintain (granted, not much anymore these days).
Do you have more comments for the rest of the driver or that's it ?
Cheers,
Ben.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2018-03-14 3:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 3:53 Benjamin Herrenschmidt [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-03-20 4:36 [v4,2/2] usb/gadget: Add driver for Aspeed SoC virtual hub Benjamin Herrenschmidt
2018-03-17 13:50 Alan Stern
2018-03-17 0:40 Benjamin Herrenschmidt
2018-03-17 0:38 Benjamin Herrenschmidt
2018-03-17 0:29 Benjamin Herrenschmidt
2018-03-16 20:56 Alan Stern
2018-03-16 7:23 Felipe Balbi
2018-03-16 0:40 Benjamin Herrenschmidt
2018-03-14 21:03 Benjamin Herrenschmidt
2018-03-14 8:54 Felipe Balbi
2018-03-12 22:35 Benjamin Herrenschmidt
2018-03-09 9:20 Felipe Balbi
2018-01-26 0:01 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=1520999616.16434.100.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=andrew@aj.id.au \
--cc=balbi@kernel.org \
--cc=greg@kroah.com \
--cc=joel@jms.id.au \
--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 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).