Hi

-----Original Message-----
From: Roger Quadros [mailto:rogerq@ti.com]
Sent: Tuesday, May 10, 2016 3:35 PM
To: Peter Chen <redacted>
Cc: peter.chen@freescale.com; stern@rowland.harvard.edu; balbi@kernel.org;
gregkh@linuxfoundation.org; dan.j.williams@intel.com; jun.li@freescale.com;
mathias.nyman@linux.intel.com; tony@atomide.com; Joao.Pinto@synopsys.com;
abrestic@chromium.org; yoshihiro.shimoda.uh@renesas.com; linux-
usb@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
omap@vger.kernel.org; devicetree@vger.kernel.org
Subject: Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface

On 10/05/16 06:14, Peter Chen wrote:

quoted

On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote:

quoted

On 06/05/16 12:41, Peter Chen wrote:

quoted

On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:

quoted

The OTG core will use struct otg_hcd_ops to interface with the HCD
controller.

The main purpose of this interface is to avoid directly calling HCD
APIs from the OTG core as they wouldn't be defined in the built-in
symbol table if CONFIG_USB is m.

Signed-off-by: Roger Quadros <redacted>
Acked-by: Peter Chen <redacted>

Roger, after thinking more, I still think current dependency between
OTG, HCD and gadget are too complicated. Since the OTG can't work if
it is built as module, I suggest letting OTG depends on HCD &&
USB_GADGET, and it is a boolean, in that case, we don't need to
export any HCD and gadget ops, things will be much simpler.
What's your opinion?

How will it work if HCD and USB_GADGET are modules and OTG is built-in?

The OTG will not be compiled at this situation, since it is boolean.
In fact, like I mentioned at above, OTG or USB function can't work if
it is built as module.

Isn't this a limitation?
As per the current implementation dual role works fine even with both
USB_GADGET and HCD as module.

My understand: only make sense for pass build, host can't work before
gadget modules loaded; gadget can't work before hcd loaded, nothing
can work before all drivers are loaded.

In the real world it is unlikely that GADGET and HCD will be built-in.

Why? User enable USB_OTG means both drivers should be enabled anyway.
Even in non-OTG case, both may be built-in for machine with 2 ports
(one port is host only, the other one is peripheral only).

A general question, 2 drivers depends on each other, allowable?

cheers,
-roger

quoted

Peter

quoted

cheers,
-roger

quoted

Peter

quoted

---
 include/linux/usb/hcd.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index b98f831..861ccaa 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h

@@ -399,6 +399,30 @@ struct hc_driver {

 };

+/**
+ * struct otg_hcd_ops - Interface between OTG core and HCD
+ *
+ * Provided by the HCD core to allow the OTG core to interface
+with the HCD
+ *
+ * @add: function to add the HCD
+ * @remove: function to remove the HCD
+ * @usb_bus_start_enum: function to immediately start bus
+enumeration
+ * @usb_control_msg: function to build and send of a control urb
+ * @usb_hub_find_child: function to get pointer to the child
+device  */ struct otg_hcd_ops {
+	int (*add)(struct usb_hcd *hcd,
+		   unsigned int irqnum, unsigned long irqflags);
+	void (*remove)(struct usb_hcd *hcd);
+	int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int

port_num);

quoted

quoted

quoted

quoted

+	int (*usb_control_msg)(struct usb_device *dev, unsigned int

pipe,

quoted

quoted

quoted

quoted

+			       __u8 request, __u8 requesttype, __u16 value,
+			       __u16 index, void *data, __u16 size,
+			       int timeout);
+	struct usb_device * (*usb_hub_find_child)(struct usb_device

*hdev,

quoted

quoted

quoted

quoted

+						  int port1);
+};
+
 static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)  {
 	return hcd->driver->flags & HCD_BH;
--
2.7.4

--
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