From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Pawel Laszczak <pawell@cadence.com>,
"devicetree\@vger.kernel.org" <devicetree@vger.kernel.org>
Cc: "gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
"hdegoede\@redhat.com" <hdegoede@redhat.com>,
"heikki.krogerus\@linux.intel.com"
<heikki.krogerus@linux.intel.com>,
"robh+dt\@kernel.org" <robh+dt@kernel.org>,
"rogerq\@ti.com" <rogerq@ti.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jbergsagel\@ti.com" <jbergsagel@ti.com>,
"nsekhar\@ti.com" <nsekhar@ti.com>, "nm\@ti.com" <nm@ti.com>,
Suresh Punnoose <sureshp@cadence.com>,
"peter.chen\@nxp.com" <peter.chen@nxp.com>,
Jayshri Dajiram Pawar <jpawar@cadence.com>,
Rahul Kumar <kurahul@cadence.com>
Subject: RE: [PATCH v9 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
Date: Mon, 08 Jul 2019 09:29:01 +0300 [thread overview]
Message-ID: <87a7dpm442.fsf@linux.intel.com> (raw)
In-Reply-To: <BYAPR07MB4709EF3753AC0B87606B1182DDF70@BYAPR07MB4709.namprd07.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4994 bytes --]
Hi,
Pawel Laszczak <pawell@cadence.com> writes:
>>> +void cdns3_role_stop(struct cdns3 *cdns)
>>
>>not static? Why is it so that _start() is static but _stop() is not?
>>Looks fishy
>
> This function is used in cdns3_role_stop in debugfs.c file so it can't
> be static.
it's still super fishy. Why don't you need _start() from debugfs.c? In
any case, the role framework would remove the need for any of this, I
suppose.
>>> +static int cdns3_idle_role_start(struct cdns3 *cnds)
>>> +{ /* Hold PHY in RESET */
>>
>>huh?
>>
>>> + return 0;
>>> +}
>>> +
>>> +static void cdns3_idle_role_stop(struct cdns3 *cnds)
>>> +{
>>> + /* Program Lane swap and bring PHY out of RESET */
>>
>>double huh?
>>
>
> These functions were added for consistency with FSM described in controller specification.
> Yes, I know that you don't like empty functions :), but it could be helpful in
> understanding how this controller work.
frankly, it really doesn't. An empty function doesn't really help IMHO.
>>> +static const char *const cdns3_mode[] = {
>>> + [USB_DR_MODE_UNKNOWN] = "unknown",
>>> + [USB_DR_MODE_OTG] = "otg",
>>> + [USB_DR_MODE_HOST] = "host",
>>> + [USB_DR_MODE_PERIPHERAL] = "device",
>>> +};
>>
>>don't we have a generic version of this under usb/common ?
>>
> Yes, there is a similar array, but it is defined also as static
> and there is no function for converting value to string.
> There is only function for converting string to value.
right. You can add the missing interface generically instead of
duplicating the enumeration.
> There is also:
> [USB_DR_MODE_UNKNOWN] = "",
> Instead of:
> [USB_DR_MODE_UNKNOWN] = "unknown",
>
> So, for USB_DR_MODE_UNKNOWN user will not see anything information.
But that's what "unknown" means :-) We don't know the information.
>>> +static irqreturn_t cdns3_drd_irq(int irq, void *data)
>>> +{
>>> + irqreturn_t ret = IRQ_NONE;
>>> + struct cdns3 *cdns = data;
>>> + u32 reg;
>>> +
>>> + if (cdns->dr_mode != USB_DR_MODE_OTG)
>>> + return ret;
>>> +
>>> + reg = readl(&cdns->otg_regs->ivect);
>>> +
>>> + if (!reg)
>>> + return ret;
>>> +
>>> + if (reg & OTGIEN_ID_CHANGE_INT) {
>>> + dev_dbg(cdns->dev, "OTG IRQ: new ID: %d\n",
>>> + cdns3_get_id(cdns));
>>> +
>>> + ret = IRQ_HANDLED;
>>> + }
>>> +
>>> + if (reg & (OTGIEN_VBUSVALID_RISE_INT | OTGIEN_VBUSVALID_FALL_INT)) {
>>> + dev_dbg(cdns->dev, "OTG IRQ: new VBUS: %d\n",
>>> + cdns3_get_vbus(cdns));
>>> +
>>> + ret = IRQ_HANDLED;
>>> + }
>>> +
>>> + if (ret == IRQ_HANDLED)
>>> + queue_work(system_freezable_wq, &cdns->role_switch_wq);
>>> +
>>> + writel(~0, &cdns->otg_regs->ivect);
>>> + return ret;
>>> +}
>>
>>seems like you could use threaded irq to avoid this workqueue.
>
>
> This function is also called in cdns3_mode_write (debugfs.c file),
> therefor after changing it to threaded irq I will still need workqueue.
Why? debugfs writes are not atomic. They run in process context, right?
Just don't disable interrupts while running this and you should be fine.
>>> + cdns->desired_dr_mode = cdns->dr_mode;
>>> + cdns->current_dr_mode = USB_DR_MODE_UNKNOWN;
>>> +
>>> + ret = devm_request_threaded_irq(cdns->dev, cdns->otg_irq,
>>> + cdns3_drd_irq,
>>> + NULL, IRQF_SHARED,
>>
>>if you don't have a threaded handler, you should set IRQF_ONESHOT. I
>>would prefer if you implement a threaded handler that doesn't require
>>IRQF_ONESHOT, though.
>>
>
> IRQF_ONESHOT can be used only in threaded handled.
> "
> * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
> * Used by threaded interrupts which need to keep the
> * irq line disabled until the threaded handler has been run.
> "
so?
>>> + } else {
>>> + struct usb_request *request;
>>> +
>>> + if (priv_dev->eps[index]->flags & EP_WEDGE) {
>>> + cdns3_select_ep(priv_dev, 0x00);
>>> + return 0;
>>> + }
>>> +
>>> + cdns3_dbg(priv_ep->cdns3_dev, "Clear Stalled endpoint %s\n",
>>> + priv_ep->name);
>>
>>why do you need your own wrapper around dev_dbg()? This looks quite unnecessary.
>
> It's generic function used for adding message to trace.log. It's not wrapper to dev_dbg
>
> void cdns3_dbg(struct cdns3_device *priv_dev, const char *fmt, ...)
> {
> struct va_format vaf;
> va_list args;
>
> va_start(args, fmt);
> vaf.fmt = fmt;
> vaf.va = &args;
> trace_cdns3_log(priv_dev, &vaf);
> va_end(args);
> }
oh. Don't do it like that. Add a proper trace event that actually
decodes the information you want. These random messages will give you
trouble in the future. I had this sort of construct in dwc3 for a while
and it became clear that it's a bad idea. It's best to have trace events
that decode information coming from the HW. That way your trace logs
have a "predictable" shape/format and you can easily find problem areas.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-07-08 6:29 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-05 10:57 [PATCH v9 0/6] Introduced new Cadence USBSS DRD Driver Pawel Laszczak
2019-07-05 10:57 ` [PATCH v9 1/6] dt-bindings: add binding for USBSS-DRD controller Pawel Laszczak
2019-07-05 10:57 ` [PATCH v9 2/6] usb:gadget Separated decoding functions from dwc3 driver Pawel Laszczak
2019-07-05 11:27 ` Greg KH
2019-07-05 11:39 ` Pawel Laszczak
2019-07-05 11:49 ` Greg KH
2019-07-05 12:03 ` Pawel Laszczak
2019-07-05 11:39 ` Felipe Balbi
2019-07-05 11:44 ` Pawel Laszczak
2019-08-07 10:17 ` Roger Quadros
2019-08-07 10:22 ` Felipe Balbi
2019-08-08 3:07 ` Pawel Laszczak
2019-07-05 10:57 ` [PATCH v9 3/6] usb:gadget Patch simplify usb_decode_set_clear_feature function Pawel Laszczak
2019-07-05 10:57 ` [PATCH v9 4/6] usb:gadget Simplify usb_decode_get_set_descriptor function Pawel Laszczak
2019-07-05 10:57 ` [PATCH v9 5/6] usb:cdns3 Add Cadence USB3 DRD Driver Pawel Laszczak
2019-07-05 11:55 ` Felipe Balbi
2019-07-07 17:56 ` Pawel Laszczak
2019-07-08 6:29 ` Felipe Balbi [this message]
2019-07-08 10:59 ` Pawel Laszczak
2019-07-08 11:15 ` Felipe Balbi
2019-07-08 11:45 ` Pawel Laszczak
2019-07-08 11:59 ` Felipe Balbi
2019-07-08 12:39 ` Pawel Laszczak
2019-07-09 4:23 ` Pawel Laszczak
2019-07-09 6:36 ` Felipe Balbi
2019-07-09 7:07 ` Pawel Laszczak
2019-07-09 7:22 ` Felipe Balbi
2019-07-09 7:29 ` Pawel Laszczak
2019-07-10 8:25 ` Pawel Laszczak
2019-07-08 7:11 ` Felipe Balbi
2019-07-15 11:00 ` Pawel Laszczak
2019-08-07 10:34 ` Felipe Balbi
2019-08-10 20:39 ` Pawel Laszczak
2019-08-12 1:55 ` Peter Chen
2019-08-12 4:43 ` Pawel Laszczak
2019-08-12 5:24 ` Felipe Balbi
2019-08-12 7:13 ` Pawel Laszczak
2019-08-12 8:19 ` Felipe Balbi
2019-08-12 9:13 ` Pawel Laszczak
2019-08-12 9:45 ` Felipe Balbi
2019-08-12 10:26 ` Pawel Laszczak
2019-08-12 10:34 ` Felipe Balbi
2019-08-12 14:20 ` Alan Stern
2019-07-05 10:57 ` [PATCH v9 6/6] usb:cdns3 Fix for stuck packets in on-chip OUT buffer Pawel Laszczak
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=87a7dpm442.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=jbergsagel@ti.com \
--cc=jpawar@cadence.com \
--cc=kurahul@cadence.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=pawell@cadence.com \
--cc=peter.chen@nxp.com \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.com \
--cc=sureshp@cadence.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).