Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules

[Chen-Yu Tsai]

On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd  wrote:
> The ULPI bus can be built as a module, and it will soon be
> calling these functions when it supports probing devices from DT.
> Export them so they can be used by the ULPI module.
>
> Acked-by: Rob Herring 
> Cc: 
> Signed-off-by: Stephen Boyd 

I'm interested in this as well. The sunxi-rsb bus is non-enumerable
and DT only, and existing slave device drivers can be built as modules.
We'd need this to support modalias loading of drivers.

ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next] r8152: add new products of Lenovo

[Hayes Wang]

Add the following four products of Lenovo and sort the order of the list.

VID PID
0x17ef  0x3062
0x17ef  0x3069
0x17ef  0x720c
0x17ef  0x7214

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/cdc_ether.c | 28 
 drivers/net/usb/r8152.c |  6 +-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index c47ec0a..45e5e43 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -687,6 +687,20 @@ static const struct usb_device_id  products[] = {
.driver_info = 0,
 },
 
+/* ThinkPad USB-C Dock (based on Realtek RTL8153) */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3062, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+
+/* ThinkPad Thunderbolt 3 Dock (based on Realtek RTL8153) */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3069, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+
 /* Lenovo Thinkpad USB 3.0 Ethernet Adapters (based on Realtek RTL8153) */
 {
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x7205, USB_CLASS_COMM,
@@ -694,6 +708,20 @@ static const struct usb_device_id  products[] = {
.driver_info = 0,
 },
 
+/* Lenovo USB C to Ethernet Adapter (based on Realtek RTL8153) */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x720c, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+
+/* Lenovo USB-C Travel Hub (based on Realtek RTL8153) */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x7214, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+
 /* NVIDIA Tegra USB 3.0 Ethernet Adapters (based on Realtek RTL8153) */
 {
USB_DEVICE_AND_INTERFACE_INFO(NVIDIA_VENDOR_ID, 0x09ff, USB_CLASS_COMM,
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2886946..8d6e13c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4411,8 +4411,12 @@ static struct usb_device_id rtl8152_table[] = {
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
{REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
-   {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7205)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x304f)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x3062)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x3069)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7205)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x720c)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7214)},
{REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA,  0x09ff)},
{}
 };
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB GADGET: have a question about usb2eth

[Lipengcheng]

> -Original Message-
> From: Felipe Balbi [mailto:ba...@kernel.org]
> Sent: Monday, October 17, 2016 5:29 PM
> To: Lipengcheng; Peter Chen
> Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org; 
> linux-ker...@vger.kernel.org
> Subject: RE: USB GADGET: have a question about usb2eth
> 
> 
> Hi,
> 
> (please, avoid top-posting: http://daringfireball.net/2007/07/on_top)
> 
> Lipengcheng  writes:
> > Hi,
> > thank you for your suggestion.
> >
> > I have a question about usb2eth. In the function gen_ndis_set_resp of
> > the rndis.c, the value of *params->filter may be 0x20 from the pc set
> > command; Howerver the value is used cdc_filter =
> > dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c.
> > If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is
> > 0x20, the broadcast packet can not send the pc win7; At the result,
> > the linux ping the win7 is slow an the first. At the same time, Why
> > are different value between RNDIS_PACKET_TYPE_PROMISCUOUS and
> > USB_CDC_PACKET_TYPE_PROMISCUOUS? If the value of
> > RNDIS_PACKET_TYPE_PROMISCUOUS
> 
> because they are defined by different specifications. You should read both 
> CDC specification from USB.org and RNDIS spec from Microsoft to
> understand the details of that.
Ok. I will understand the different both CDC specification from USB.org and 
RNDIS spec from Microsoft. They should have transformational rule in the linux 
code
between CDC spe and RNDIS spe. Through debugging, I found there has been no 
conversion about the filter. I feel a little problem. I will find the rule.
> 
> > and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the
> > win7 is normal speed.
> 
> I don't understand what's going on here. Care to describe which kernel you're 
> using, which USB peripheral controller, what is the actual
> problem you're trying to solve?
VERSION = 3.18.20
USB peripheral controller: Synopsys HS OTG Linux Software Driver. It's not the 
standard linux code. But I think the controller do not have problem.
The probem is that I am using one controller board with Linux running on it. I 
want to interface my device to the Host computer (Windows OS) through USB.
I have driver ready at device side (linux) and the bridge has been established. 
The device side ping the Host computer is very slow at the first time. It 
spends 
a few minutes. The problem is the first ping takes too long time. Now I have a 
way to quickly ping at the first , but I do not know the risk about the 
change.I will
continue debug the problem. If it is valuable, I will submit the kernel 
community. 
Thanks very much!
> 
> --
> Balbi

Best Regards
Pengcheng Li

Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Baolin Wang]

Hi,

On 17 October 2016 at 19:53, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>>> Baolin Wang  writes:
 When we change the USB function with configfs dynamically, we possibly met 
 this
 situation: one core is doing the control transfer, another core is trying 
 to
 unregister the USB gadget from userspace, we must wait for completing this
 control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.

 Signed-off-by: Baolin Wang 
>>>
>>> Can you make sure this still works?
>>
>> With applying this patch, It can work well on my platform, but I have
>> some worries about the risk of accessing 'dwc->ep0state' without lock
>> protection in dwc3_gadget_pullup() function.
>
> hmm, I might be missing something, but I think there's no risk here. If
> anything, a wmb() is probably enough before reading ep0state. No?

OK, I agree with you and I think a wmb() is not useful here.

-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support

[Stephen Boyd]

The state of USB ChipIdea support on Qualcomm's platforms is not great.
The DT description of these devices requires up to three different nodes
for what amounts to be the same hardware block, when there should really
only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
duplicates the OTG state machine and touches the ci controller wrapper
registers when it should really be focused on the phy and the ULPI accesses
needed to get the phy working. There's also a slimmed down phy driver for
the msm8916 platform, but really the phy hardware is the same as other MSMs,
so we have two drivers doing pretty much the same thing. This leads to a
situtaion where we have the chipidea core driver, the "phy" driver, and
sometimes the ehci-msm.c driver operating the same device all at the same
time with very little coordination. This just isn't very safe and is
confusing from a driver perspective when trying to figure out who does what.
Finally, there isn't any HSIC support on platforms like apq8074 so we
should add that.

This patch series updates the ChipIdea driver and the MSM wrapper
(ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
times in the right places. To get there, we update the ChipIdea core to
have support for the ULPI phy bus introduced by Heikki. Along the way
we fix bugs with the extcon handling for peripheral and OTG mode controllers
and move the parts of phy-usb-msm.c that are touching the CI controller
wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
(phy-usb-msm.c) as a standard ULPI phy driver.

Once this series is accepted, we should be able to delete the phy-usb-msm.c,
phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
based phy driver (which also lives in drivers/phy/ instead of drivers/usb/phy/)
and the chipidea host core instead.

I've also sent separate patches for other minor pieces to make this
all work. The full tree can be found here[2], hacks and all to get
things working. I've tested this on the db410c, apq8074 dragonboard,
and ifc6410 with configfs gadgets and otg cables.

Patches based on v4.8-rc1

Changes from v4:
 * Picked up Acks from Rob
 * Updated HS phy init sequence DT property to restrict it to offsets

Changes from v3:
 * Picked up Acks from Peter
 * Updated extcon consolidation patch per Peter's comments
 * Folded in simplification from Heikki for ULPI DT matching

Changes from v2:
 * Added SoC specific compatibles in phy bindings
 * Dropped AVVIS patch for OTG statemachine
 * New patch to consolidate extcon handlers
 * Picked up Acks from Peter
 * Rebased onto v4.8-rc1
 * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
 * Dropped ULPI bindings for vid and pid overrides

Changes from v1:
 * Reworked ULPI device probing to keep using vendor/product ids that
   come from DT if needed and falls back to OF style match when product id
   is 0
 * PHY init later patch was rejected so that moved to a quirk flag and
   the msm wrapper started managing the phy on/off
 * Updated clk requirements for HSIC phy in binding doc
 * Added optional clk in wrapper for "housekeeping" found on older qcom
   platforms
 * Bug fix to OTGSC polling function
 * Changed runtime PM patch to set as active instead of get/put

TODO:
 * DMA fails on arm64 so we need something like [1] or [3] to make it work.
 * The db410c needs a driver to toggle the onboard switch to connect
   the usb hub instead of micro port when the usb cable is disconnected.
   I've sent a patch set for this[4], which needs some further
   discussion/development.
 * apq8064 platforms need a vbus regulator to really use otg and I haven't
   tried out the RPM based regulators yet
 * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
   device which requires the i2c driver to probe and send an i2c
   sequence before the HSIC controller enumerates or HSIC doesn't work.
   Right now I have a hack to force the controller to probe defer
   once so that usb4604 probes first. This needs a more proper solution
   like having the DT describe a linkage between the controller and
   the usb device so we can enforce probe ordering.
 * There are problems around the OTG switch still, due to how we handle
   extcon events that I'm working through

[1] https://lkml.org/lkml/2016/2/22/7
[2] 
https://git.linaro.org/people/stephen.boyd/linux.git/shortlog/refs/heads/usb-hsic-8074
[3] https://patchwork.kernel.org/patch/9319527/
[4] https://lkml.kernel.org/r/20160914014246.31847-1-stephen.b...@linaro.org

Stephen Boyd (23):
  of: device: Support loading a module with OF based modalias
  of: device: Export of_device_{get_modalias,uvent_modalias} to modules
  usb: ulpi: Support device discovery via DT
  usb: chipidea: Only read/write OTGSC from one place
  usb: chipidea: Handle extcon events properly
  usb: chipidea: Add platform flag for wrapper phy management
  usb: 

[PATCH v5 04/23] usb: chipidea: Only read/write OTGSC from one place

[Stephen Boyd]

With the id and vbus detection done via extcon we need to make
sure we poll the status of OTGSC properly by considering what the
extcon is saying, and not just what the register is saying. Let's
move this hw_wait_reg() function to the only place it's used and
simplify it for polling the OTGSC register. Then we can make
certain we only use the hw_read_otgsc() API to read OTGSC, which
will make sure we properly handle extcon events.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Cc: "Ivan T. Ivanov" 
Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID 
detect")
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci.h   |  3 ---
 drivers/usb/chipidea/core.c | 32 
 drivers/usb/chipidea/otg.c  | 34 ++
 3 files changed, 30 insertions(+), 39 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index cd414559040f..05bc4d631cb9 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -428,9 +428,6 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
 
 u8 hw_port_test_get(struct ci_hdrc *ci);
 
-int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
-   u32 value, unsigned int timeout_ms);
-
 void ci_platform_configure(struct ci_hdrc *ci);
 
 int dbg_create_files(struct ci_hdrc *ci);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e644d17..01390e02ee53 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -516,38 +516,6 @@ int hw_device_reset(struct ci_hdrc *ci)
return 0;
 }
 
-/**
- * hw_wait_reg: wait the register value
- *
- * Sometimes, it needs to wait register value before going on.
- * Eg, when switch to device mode, the vbus value should be lower
- * than OTGSC_BSV before connects to host.
- *
- * @ci: the controller
- * @reg: register index
- * @mask: mast bit
- * @value: the bit value to wait
- * @timeout_ms: timeout in millisecond
- *
- * This function returns an error code if timeout
- */
-int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
-   u32 value, unsigned int timeout_ms)
-{
-   unsigned long elapse = jiffies + msecs_to_jiffies(timeout_ms);
-
-   while (hw_read(ci, reg, mask) != value) {
-   if (time_after(jiffies, elapse)) {
-   dev_err(ci->dev, "timeout waiting for %08x in %d\n",
-   mask, reg);
-   return -ETIMEDOUT;
-   }
-   msleep(20);
-   }
-
-   return 0;
-}
-
 static irqreturn_t ci_irq(int irq, void *data)
 {
struct ci_hdrc *ci = data;
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 03b6743461d1..a829607c3e4d 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -104,7 +104,31 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
usb_gadget_vbus_disconnect(>gadget);
 }
 
-#define CI_VBUS_STABLE_TIMEOUT_MS 5000
+/**
+ * When we switch to device mode, the vbus value should be lower
+ * than OTGSC_BSV before connecting to host.
+ *
+ * @ci: the controller
+ *
+ * This function returns an error code if timeout
+ */
+static int hw_wait_vbus_lower_bsv(struct ci_hdrc *ci)
+{
+   unsigned long elapse = jiffies + msecs_to_jiffies(5000);
+   u32 mask = OTGSC_BSV;
+
+   while (hw_read_otgsc(ci, mask)) {
+   if (time_after(jiffies, elapse)) {
+   dev_err(ci->dev, "timeout waiting for %08x in OTGSC\n",
+   mask);
+   return -ETIMEDOUT;
+   }
+   msleep(20);
+   }
+
+   return 0;
+}
+
 static void ci_handle_id_switch(struct ci_hdrc *ci)
 {
enum ci_role role = ci_otg_role(ci);
@@ -116,9 +140,11 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
ci_role_stop(ci);
 
if (role == CI_ROLE_GADGET)
-   /* wait vbus lower than OTGSC_BSV */
-   hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
-   CI_VBUS_STABLE_TIMEOUT_MS);
+   /*
+* wait vbus lower than OTGSC_BSV before connecting
+* to host
+*/
+   hw_wait_vbus_lower_bsv(ci);
 
ci_role_start(ci, role);
}
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 03/23] usb: ulpi: Support device discovery via DT

[Stephen Boyd]

The qcom HSIC ULPI phy doesn't have any bits set in the vendor or
product ID registers. This makes it impossible to make a ULPI
driver match against the ID registers. Add support to discover
the ULPI phys via DT help alleviate this problem. In the DT case,
we'll look for a ULPI bus node underneath the device registering
the ULPI viewport (or the parent of that device to support
chipidea's device layout) and then match up the phy node
underneath that with the ULPI device that's created.

The side benefit of this is that we can use standard properties
in the phy node like clks, regulators, gpios, etc. because we
don't have firmware like ACPI to turn these things on for us. And
we can use the DT phy binding to point our phy consumer to the
phy provider.

The ULPI bus code supports native enumeration by reading the
vendor ID and product ID registers at device creation time, but
we can't be certain that those register reads will succeed if the
phy is not powered up. To avoid any problems with reading the ID
registers before the phy is powered we fallback to DT matching
when the ID reads fail.

If the ULPI spec had some generic power sequencing for these
registers we could put that into the ULPI bus layer and power up
the device before reading the ID registers. Unfortunately this
doesn't exist and the power sequence is usually device specific.
By having the device matched up with DT we can avoid this
problem.

Cc: Greg Kroah-Hartman 
Cc: Heikki Krogerus 
Cc: 
Cc: Rob Herring 
Signed-off-by: Stephen Boyd 
---
 Documentation/devicetree/bindings/usb/ulpi.txt | 20 +++
 drivers/usb/common/ulpi.c  | 79 --
 2 files changed, 93 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/ulpi.txt

diff --git a/Documentation/devicetree/bindings/usb/ulpi.txt 
b/Documentation/devicetree/bindings/usb/ulpi.txt
new file mode 100644
index ..ca179dc4bd50
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ulpi.txt
@@ -0,0 +1,20 @@
+ULPI bus binding
+
+
+Phys that are behind a ULPI connection can be described with the following
+binding. The host controller shall have a "ulpi" named node as a child, and
+that node shall have one enabled node underneath it representing the ulpi
+device on the bus.
+
+EXAMPLE
+---
+
+usb {
+   compatible = "vendor,usb-controller";
+
+   ulpi {
+   phy {
+   compatible = "vendor,phy";
+   };
+   };
+};
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 8b317702d761..c9480d77810c 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 /* -- 
*/
 
@@ -39,6 +42,10 @@ static int ulpi_match(struct device *dev, struct 
device_driver *driver)
struct ulpi *ulpi = to_ulpi_dev(dev);
const struct ulpi_device_id *id;
 
+   /* Some ULPI devices don't have a vendor id so rely on OF match */
+   if (ulpi->id.vendor == 0)
+   return of_driver_match_device(dev, driver);
+
for (id = drv->id_table; id->vendor; id++)
if (id->vendor == ulpi->id.vendor &&
id->product == ulpi->id.product)
@@ -50,6 +57,11 @@ static int ulpi_match(struct device *dev, struct 
device_driver *driver)
 static int ulpi_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
struct ulpi *ulpi = to_ulpi_dev(dev);
+   int ret;
+
+   ret = of_device_uevent_modalias(dev, env);
+   if (ret != -ENODEV)
+   return ret;
 
if (add_uevent_var(env, "MODALIAS=ulpi:v%04xp%04x",
   ulpi->id.vendor, ulpi->id.product))
@@ -60,6 +72,11 @@ static int ulpi_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 static int ulpi_probe(struct device *dev)
 {
struct ulpi_driver *drv = to_ulpi_driver(dev->driver);
+   int ret;
+
+   ret = of_clk_set_defaults(dev->of_node, false);
+   if (ret < 0)
+   return ret;
 
return drv->probe(to_ulpi_dev(dev));
 }
@@ -87,8 +104,13 @@ static struct bus_type ulpi_bus = {
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
+   int len;
struct ulpi *ulpi = to_ulpi_dev(dev);
 
+   len = of_device_get_modalias(dev, buf, PAGE_SIZE - 1);
+   if (len != -ENODEV)
+   return len;
+
return sprintf(buf, "ulpi:v%04xp%04x\n",
   ulpi->id.vendor, ulpi->id.product);
 }
@@ -153,23 +175,45 @@ EXPORT_SYMBOL_GPL(ulpi_unregister_driver);
 
 /* -- 
*/
 
-static int 

[PATCH v5 02/23] of: device: Export of_device_{get_modalias,uvent_modalias} to modules

[Stephen Boyd]

The ULPI bus can be built as a module, and it will soon be
calling these functions when it supports probing devices from DT.
Export them so they can be used by the ULPI module.

Acked-by: Rob Herring 
Cc: 
Signed-off-by: Stephen Boyd 
---
 drivers/of/device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8a22a253a830..6719ab35b62e 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char 
*str, ssize_t len)
 
return tsize;
 }
+EXPORT_SYMBOL_GPL(of_device_get_modalias);
 
 int of_device_request_module(struct device *dev)
 {
@@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct 
kobj_uevent_env *env)
}
mutex_unlock(_mutex);
 }
+EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
 
 int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
 {
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 17/23] usb: chipidea: msm: Restore wrapper settings after reset

[Stephen Boyd]

When the RESET bit is set in the USBCMD register it resets quite
a few of the wrapper's registers to their reset state. This
includes the GENCONFIG and GENCONFIG2 registers. Currently this
is done by the usb phy and ehci-msm drivers writing into the
controller wrapper's MMIO address space. Let's consolidate the
register writes into the wrapper driver instead so that we
clearly split the wrapper from the phys.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 4b0aadc2be2f..333817291798 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -14,11 +14,22 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "ci.h"
 
 #define HS_PHY_AHB_MODE0x0098
 
+#define HS_PHY_GENCONFIG   0x009c
+#define HS_PHY_TXFIFO_IDLE_FORCE_DIS   BIT(4)
+
+#define HS_PHY_GENCONFIG_2 0x00a0
+#define HS_PHY_SESS_VLD_CTRL_ENBIT(7)
+#define HS_PHY_ULPI_TX_PKT_EN_CLR_FIX  BIT(19)
+
+#define HSPHY_SESS_VLD_CTRLBIT(25)
+
 /* Vendor base starts at 0x200 beyond CI base */
 #define HS_PHY_SEC_CTRL0x0078
 #define HS_PHY_DIG_CLAMP_N BIT(16)
@@ -29,6 +40,7 @@ struct ci_hdrc_msm {
struct clk *iface_clk;
struct clk *fs_clk;
bool secondary_phy;
+   bool hsic;
void __iomem *base;
 };
 
@@ -48,6 +60,24 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
unsigned event)
 
/* use AHB transactor, allow posted data writes */
hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
+
+   /* workaround for rx buffer collision issue */
+   hw_write_id_reg(ci, HS_PHY_GENCONFIG,
+   HS_PHY_TXFIFO_IDLE_FORCE_DIS, 0);
+
+   if (!msm_ci->hsic)
+   hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
+   HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0);
+
+   if (!IS_ERR(ci->platdata->vbus_extcon.edev)) {
+   hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
+   HS_PHY_SESS_VLD_CTRL_EN,
+   HS_PHY_SESS_VLD_CTRL_EN);
+   hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
+HSPHY_SESS_VLD_CTRL);
+
+   }
+
usb_phy_init(ci->usb_phy);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
@@ -116,6 +146,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
struct reset_control *reset;
struct resource *res;
int ret;
+   struct device_node *ulpi_node, *phy_node;
 
dev_dbg(>dev, "ci_hdrc_msm_probe\n");
 
@@ -181,6 +212,14 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
if (ret)
goto err_mux;
 
+   ulpi_node = of_find_node_by_name(pdev->dev.of_node, "ulpi");
+   if (ulpi_node) {
+   phy_node = of_get_next_available_child(ulpi_node, NULL);
+   ci->hsic = of_device_is_compatible(phy_node, 
"qcom,usb-hsic-phy");
+   of_node_put(phy_node);
+   }
+   of_node_put(ulpi_node);
+
plat_ci = ci_hdrc_add_device(>dev,
pdev->resource, pdev->num_resources,
_hdrc_msm_platdata);
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 18/23] usb: chipidea: msm: Make platform data driver local instead of global

[Stephen Boyd]

If two devices are probed with this same driver, they'll share
the same platform data structure, while the chipidea core layer
writes and modifies it. This can lead to interesting results
especially if one device is an OTG type chipidea controller and
another is a host. Let's create a copy of this structure per each
device instance so that odd things don't happen.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 333817291798..2489a63d3e75 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -39,6 +39,7 @@ struct ci_hdrc_msm {
struct clk *core_clk;
struct clk *iface_clk;
struct clk *fs_clk;
+   struct ci_hdrc_platform_data pdata;
bool secondary_phy;
bool hsic;
void __iomem *base;
@@ -94,16 +95,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
unsigned event)
}
 }
 
-static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
-   .name   = "ci_hdrc_msm",
-   .capoffset  = DEF_CAPOFFSET,
-   .flags  = CI_HDRC_REGS_SHARED |
- CI_HDRC_DISABLE_STREAMING |
- CI_HDRC_OVERRIDE_AHB_BURST,
-
-   .notify_event   = ci_hdrc_msm_notify_event,
-};
-
 static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
   struct platform_device *pdev)
 {
@@ -164,7 +155,12 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
if (IS_ERR(phy))
return PTR_ERR(phy);
 
-   ci_hdrc_msm_platdata.usb_phy = phy;
+   ci->pdata.name = "ci_hdrc_msm";
+   ci->pdata.capoffset = DEF_CAPOFFSET;
+   ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
+ CI_HDRC_OVERRIDE_AHB_BURST;
+   ci->pdata.notify_event = ci_hdrc_msm_notify_event;
+   ci->pdata.usb_phy = phy;
 
reset = devm_reset_control_get(>dev, "core");
if (IS_ERR(reset))
@@ -220,9 +216,8 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
}
of_node_put(ulpi_node);
 
-   plat_ci = ci_hdrc_add_device(>dev,
-   pdev->resource, pdev->num_resources,
-   _hdrc_msm_platdata);
+   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
+pdev->num_resources, >pdata);
if (IS_ERR(plat_ci)) {
dev_err(>dev, "ci_hdrc_add_device failed!\n");
ret = PTR_ERR(plat_ci);
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path

[Stephen Boyd]

In the case of an extcon-usb-gpio device being used with the
chipidea driver we'll sometimes miss the BSVIS event in the OTGSC
register. Consider the case where we don't have a cable attached
and the id pin is indicating "host" mode. When we plug in the usb
cable for "device" mode a gpio goes high and indicates that we
should do the role switch and that vbus is high. When we're in
"host" mode the OTGSC register doesn't have BSVIE set.

The following scenario can happen:

CPU0


 ci_cable_notifier()
  update id cable state
  ci_irq()
   if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) { // true
ci->id_event = true;
ci_otg_queue_work()
 schedule()

 // same task as before
 ci_cable_notifier()
  update vbus cable state
   ci_irq()
if (ci->is_otg && (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) // false
   return IRQ_NONE

ci_otg_work() // switch task to the workqueue now
 if (ci->id_event)
  ci_handle_id_switch()
   ci_role_stop()
host_stop()
   hw_wait_vbus_lower_bsv(ci); // this times out because vbus is already set
   ci_role_start()
udc_id_switch_for_device()
 hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE, OTGSC_BSVIS | OTGSC_BSVIE);

At this point, we don't replay the vbus connect event because the
vbus event has already happened. This causes things like gadget
instances to never see vbus appear, and thus the gadget is never
started. Furthermore, we see timeout messages like:

timeout waiting for 800 in OTGSC

Let's workaround this by skiping the wait for BSV when we're
using an extcon for the vbus notification and let's properly
emulate the BSVIS event that would happen when we enable the
vbus interrupt while enabling "device" mode.

Cc: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci.h   |  2 ++
 drivers/usb/chipidea/core.c | 23 +--
 drivers/usb/chipidea/otg.c  | 31 ---
 3 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 59e22389c10b..e099b8bc79e2 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -437,6 +437,8 @@ static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
 static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
 #endif
 
+irqreturn_t __ci_irq(int irq, struct ci_hdrc *ci);
+
 u32 hw_read_intr_enable(struct ci_hdrc *ci);
 
 u32 hw_read_intr_status(struct ci_hdrc *ci);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 83bc2f2dd6a8..d1ae9a03e0fa 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -524,9 +524,8 @@ int hw_device_reset(struct ci_hdrc *ci)
return 0;
 }
 
-static irqreturn_t ci_irq(int irq, void *data)
+irqreturn_t __ci_irq(int irq, struct ci_hdrc *ci)
 {
-   struct ci_hdrc *ci = data;
irqreturn_t ret = IRQ_NONE;
u32 otgsc = 0;
 
@@ -570,9 +569,20 @@ static irqreturn_t ci_irq(int irq, void *data)
return IRQ_HANDLED;
}
 
-   /* Handle device/host interrupt */
-   if (ci->role != CI_ROLE_END)
-   ret = ci_role(ci)->irq(ci);
+   return ret;
+}
+
+static irqreturn_t ci_irq(int irq, void *data)
+{
+   irqreturn_t ret;
+   struct ci_hdrc *ci = data;
+
+   ret = __ci_irq(irq, ci);
+   if (ret == IRQ_NONE) {
+   /* Handle device/host interrupt */
+   if (ci->role != CI_ROLE_END)
+   ret = ci_role(ci)->irq(ci);
+   }
 
return ret;
 }
@@ -586,7 +596,8 @@ static int ci_cable_notifier(struct notifier_block *nb, 
unsigned long event,
cbl->connected = event;
cbl->changed = true;
 
-   ci_irq(ci->irq, ci);
+   __ci_irq(ci->irq, ci);
+
return NOTIFY_DONE;
 }
 
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 695f3fe3ae21..f4a21ade1901 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -84,36 +84,44 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
 void hw_write_otgsc(struct ci_hdrc *ci, u32 mask, u32 data)
 {
struct ci_hdrc_cable *cable;
+   bool raise_irq = false;
 
cable = >platdata->vbus_extcon;
if (!IS_ERR(cable->edev)) {
-   if (data & mask & OTGSC_BSVIS)
-   cable->changed = false;
-
/* Don't enable vbus interrupt if using external notifier */
if (data & mask & OTGSC_BSVIE) {
+   if (cable->enabled == false && cable->changed == true)
+   raise_irq = true;
cable->enabled = true;
data &= ~OTGSC_BSVIE;
} else if (mask & OTGSC_BSVIE) {
cable->enabled = false;
}
+
+   if (data & mask & OTGSC_BSVIS && !raise_irq)
+  

[PATCH v5 12/23] usb: chipidea: msm: Mark device as runtime pm active

[Stephen Boyd]

We're not properly marking the glue layer/wrapper device as
runtime active, so runtime PM believes that the hardware state is
inactive when we call pm_runtime_enable() in this driver. This
causes a problem when the glue layer has a power domain
associated with it, because runtime PM will go and disable the
power domain to match the 'inactive' state of the device. Let's
mark the device as active so that runtime PM doesn't improperly
power down this device when it's actually active.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 3889809fd0c4..89c1a02d69b5 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -80,6 +80,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, plat_ci);
 
+   pm_runtime_set_active(>dev);
pm_runtime_no_callbacks(>dev);
pm_runtime_enable(>dev);
 
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 15/23] usb: chipidea: msm: Add proper clk and reset support

[Stephen Boyd]

The msm chipidea controller uses two main clks, an AHB clk to
read/write the MMIO registers and a core clk called the system
clk that drives the controller itself. Add support for these clks
as they're required in all designs.

Also add support for an optional third clk that we need to turn
on to reset the controller and wrapper logic and other
"housekeeping" things. This clk was removed in later revisions of
the hardware because the reset methodology no longer required
clks to be enabled to propagate resets.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 72 +++---
 1 file changed, 68 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index b282a717bf8c..7e870a253f55 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -10,11 +10,20 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "ci.h"
 
 #define HS_PHY_AHB_MODE0x0098
 
+struct ci_hdrc_msm {
+   struct platform_device *ci;
+   struct clk *core_clk;
+   struct clk *iface_clk;
+   struct clk *fs_clk;
+};
+
 static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
struct device *dev = ci->gadget.dev.parent;
@@ -52,11 +61,20 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
 
 static int ci_hdrc_msm_probe(struct platform_device *pdev)
 {
+   struct ci_hdrc_msm *ci;
struct platform_device *plat_ci;
struct usb_phy *phy;
+   struct clk *clk;
+   struct reset_control *reset;
+   int ret;
 
dev_dbg(>dev, "ci_hdrc_msm_probe\n");
 
+   ci = devm_kzalloc(>dev, sizeof(*ci), GFP_KERNEL);
+   if (!ci)
+   return -ENOMEM;
+   platform_set_drvdata(pdev, ci);
+
/*
 * OTG(PHY) driver takes care of PHY initialization, clock management,
 * powering up VBUS, mapping of registers address space and power
@@ -68,29 +86,75 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 
ci_hdrc_msm_platdata.usb_phy = phy;
 
+   reset = devm_reset_control_get(>dev, "core");
+   if (IS_ERR(reset))
+   return PTR_ERR(reset);
+
+   ci->core_clk = clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   ci->iface_clk = clk = devm_clk_get(>dev, "iface");
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   ci->fs_clk = clk = devm_clk_get(>dev, "fs");
+   if (IS_ERR(clk)) {
+   if (PTR_ERR(clk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   ci->fs_clk = NULL;
+   }
+
+   ret = clk_prepare_enable(ci->fs_clk);
+   if (ret)
+   return ret;
+
+   reset_control_assert(reset);
+   usleep_range(1, 12000);
+   reset_control_deassert(reset);
+
+   clk_disable_unprepare(ci->fs_clk);
+
+   ret = clk_prepare_enable(ci->core_clk);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(ci->iface_clk);
+   if (ret)
+   goto err_iface;
+
plat_ci = ci_hdrc_add_device(>dev,
pdev->resource, pdev->num_resources,
_hdrc_msm_platdata);
if (IS_ERR(plat_ci)) {
dev_err(>dev, "ci_hdrc_add_device failed!\n");
-   return PTR_ERR(plat_ci);
+   ret = PTR_ERR(plat_ci);
+   goto err_mux;
}
 
-   platform_set_drvdata(pdev, plat_ci);
+   ci->ci = plat_ci;
 
pm_runtime_set_active(>dev);
pm_runtime_no_callbacks(>dev);
pm_runtime_enable(>dev);
 
return 0;
+
+err_mux:
+   clk_disable_unprepare(ci->iface_clk);
+err_iface:
+   clk_disable_unprepare(ci->core_clk);
+   return ret;
 }
 
 static int ci_hdrc_msm_remove(struct platform_device *pdev)
 {
-   struct platform_device *plat_ci = platform_get_drvdata(pdev);
+   struct ci_hdrc_msm *ci = platform_get_drvdata(pdev);
 
pm_runtime_disable(>dev);
-   ci_hdrc_remove_device(plat_ci);
+   ci_hdrc_remove_device(ci->ci);
+   clk_disable_unprepare(ci->iface_clk);
+   clk_disable_unprepare(ci->core_clk);
 
return 0;
 }
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 22/23] phy: Add support for Qualcomm's USB HSIC phy

[Stephen Boyd]

The HSIC USB controller on qcom SoCs has an integrated all
digital phy controlled via the ULPI viewport.

Cc: Kishon Vijay Abraham I 
Acked-by: Rob Herring 
Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qcom-usb-hsic.c| 160 +
 4 files changed, 233 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hsic.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
new file mode 100644
index ..3c7cb2be4b12
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
@@ -0,0 +1,65 @@
+Qualcomm's USB HSIC PHY
+
+PROPERTIES
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "qcom,usb-hsic-phy" and more specifically one 
of the
+   following:
+
+   "qcom,usb-hsic-phy-mdm9615"
+   "qcom,usb-hsic-phy-msm8974"
+
+- #phy-cells:
+Usage: required
+Value type: 
+Definition: Should contain 0
+
+- clocks:
+Usage: required
+Value type: 
+Definition: Should contain clock specifier for phy, calibration and
+a calibration sleep clock
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: Should contain "phy, "cal" and "cal_sleep"
+
+- pinctrl-names:
+Usage: required
+Value type: 
+Definition: Should contain "init" and "default" in that order
+
+- pinctrl-0:
+Usage: required
+Value type: 
+Definition: List of pinctrl settings to apply to keep HSIC pins in a glitch
+free state
+
+- pinctrl-1:
+Usage: required
+Value type: 
+Definition: List of pinctrl settings to apply to mux out the HSIC pins
+
+EXAMPLE
+
+usb-controller {
+   ulpi {
+   phy {
+   compatible = "qcom,usb-hsic-phy-msm8974",
+"qcom,usb-hsic-phy";
+   #phy-cells = <0>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_sleep>;
+   pinctrl-1 = <_default>;
+   clocks = < GCC_USB_HSIC_CLK>,
+< GCC_USB_HSIC_IO_CAL_CLK>,
+< GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
+   clock-names = "phy", "cal", "cal_sleep";
+   assigned-clocks = < GCC_USB_HSIC_IO_CAL_CLK>;
+   assigned-clock-rates = <96>;
+   };
+   };
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index fe00f9134d51..6bfc91a8ea3e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -453,6 +453,13 @@ config PHY_QCOM_UFS
help
  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HSIC
+   tristate "Qualcomm USB HSIC ULPI PHY module"
+   depends on USB_ULPI_BUS
+   select GENERIC_PHY
+   help
+ Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
+
 config PHY_TUSB1210
tristate "TI TUSB1210 ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a534cf5be07d..914b843eac13 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c
new file mode 100644
index ..47690f9945b9
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hsic.c
@@ -0,0 +1,160 @@
+/**
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ulpi_phy.h"
+
+#define ULPI_HSIC_CFG  0x30
+#define ULPI_HSIC_IO_CAL   0x33
+
+struct qcom_usb_hsic_phy {
+   struct ulpi *ulpi;
+   struct phy *phy;
+   struct pinctrl *pctl;
+   struct clk *phy_clk;
+   struct clk *cal_clk;
+   struct clk *cal_sleep_clk;
+};
+
+static int 

[PATCH v5 14/23] usb: chipidea: msm: Use hw_write_id_reg() instead of writel

[Stephen Boyd]

The MSM_USB_BASE macro trick is not very clear, and we're using
it for only one register write so let's just move to using
hw_write_id_reg() and passing the ci pointer instead. That
clearly shows what offset we're using and avoids needing to
include the msm_hsusb_hw.h file when we're going to delete that
file soon.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 719b20caf88e..b282a717bf8c 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -8,14 +8,12 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 
 #include "ci.h"
 
-#define MSM_USB_BASE   (ci->hw_bank.abs)
+#define HS_PHY_AHB_MODE0x0098
 
 static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
@@ -25,7 +23,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
unsigned event)
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
/* use AHB transactor, allow posted data writes */
-   writel(0x8, USB_AHBMODE);
+   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
usb_phy_init(ci->usb_phy);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 16/23] usb: chipidea: msm: Mux over secondary phy at the right time

[Stephen Boyd]

We need to pick the correct phy at runtime based on how the SoC
has been wired onto the board. If the secondary phy is used, take
it out of reset and mux over to it by writing into the TCSR
register. Make sure to do this on reset too, because this
register is reset to the default value (primary phy) after the
RESET bit is set in USBCMD.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 62 --
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 7e870a253f55..4b0aadc2be2f 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -8,29 +8,44 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "ci.h"
 
 #define HS_PHY_AHB_MODE0x0098
 
+/* Vendor base starts at 0x200 beyond CI base */
+#define HS_PHY_SEC_CTRL0x0078
+#define HS_PHY_DIG_CLAMP_N BIT(16)
+
 struct ci_hdrc_msm {
struct platform_device *ci;
struct clk *core_clk;
struct clk *iface_clk;
struct clk *fs_clk;
+   bool secondary_phy;
+   void __iomem *base;
 };
 
 static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
-   struct device *dev = ci->gadget.dev.parent;
+   struct device *dev = ci->dev->parent;
+   struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
 
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
+   if (msm_ci->secondary_phy) {
+   u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
+   val |= HS_PHY_DIG_CLAMP_N;
+   writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
+   }
+
/* use AHB transactor, allow posted data writes */
hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
usb_phy_init(ci->usb_phy);
@@ -59,6 +74,39 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
.notify_event   = ci_hdrc_msm_notify_event,
 };
 
+static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
+  struct platform_device *pdev)
+{
+   struct regmap *regmap;
+   struct device *dev = >dev;
+   struct of_phandle_args args;
+   u32 val;
+   int ret;
+
+   ret = of_parse_phandle_with_fixed_args(dev->of_node, "phy-select", 2, 0,
+  );
+   if (ret)
+   return 0;
+
+   regmap = syscon_node_to_regmap(args.np);
+   of_node_put(args.np);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   ret = regmap_write(regmap, args.args[0], args.args[1]);
+   if (ret)
+   return ret;
+
+   ci->secondary_phy = !!args.args[1];
+   if (ci->secondary_phy) {
+   val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
+   val |= HS_PHY_DIG_CLAMP_N;
+   writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
+   }
+
+   return 0;
+}
+
 static int ci_hdrc_msm_probe(struct platform_device *pdev)
 {
struct ci_hdrc_msm *ci;
@@ -66,6 +114,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
struct usb_phy *phy;
struct clk *clk;
struct reset_control *reset;
+   struct resource *res;
int ret;
 
dev_dbg(>dev, "ci_hdrc_msm_probe\n");
@@ -105,6 +154,11 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
ci->fs_clk = NULL;
}
 
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ci->base = devm_ioremap_resource(>dev, res);
+   if (!ci->base)
+   return -ENOMEM;
+
ret = clk_prepare_enable(ci->fs_clk);
if (ret)
return ret;
@@ -123,6 +177,10 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
if (ret)
goto err_iface;
 
+   ret = ci_hdrc_msm_mux_phy(ci, pdev);
+   if (ret)
+   goto err_mux;
+
plat_ci = ci_hdrc_add_device(>dev,
pdev->resource, pdev->num_resources,
_hdrc_msm_platdata);
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 05/23] usb: chipidea: Handle extcon events properly

[Stephen Boyd]

We're currently emulating the vbus and id interrupts in the OTGSC
read API, but we also need to make sure that if we're handling
the events with extcon that we don't enable the interrupts for
those events in the hardware. Therefore, properly emulate this
register if we're using extcon, but don't enable the interrupts.
This allows me to get my cable connect/disconnect working
properly without getting spurious interrupts on my device that
uses an extcon for these two events.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Cc: "Ivan T. Ivanov" 
Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID 
detect")
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/otg.c   | 46 +++-
 include/linux/usb/chipidea.h |  2 ++
 2 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index a829607c3e4d..0cf149e8 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -44,12 +44,15 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
else
val &= ~OTGSC_BSVIS;
 
-   cable->changed = false;
-
if (cable->state)
val |= OTGSC_BSV;
else
val &= ~OTGSC_BSV;
+
+   if (cable->enabled)
+   val |= OTGSC_BSVIE;
+   else
+   val &= ~OTGSC_BSVIE;
}
 
cable = >platdata->id_extcon;
@@ -59,15 +62,18 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
else
val &= ~OTGSC_IDIS;
 
-   cable->changed = false;
-
if (cable->state)
val |= OTGSC_ID;
else
val &= ~OTGSC_ID;
+
+   if (cable->enabled)
+   val |= OTGSC_IDIE;
+   else
+   val &= ~OTGSC_IDIE;
}
 
-   return val;
+   return val & mask;
 }
 
 /**
@@ -77,6 +83,36 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
  */
 void hw_write_otgsc(struct ci_hdrc *ci, u32 mask, u32 data)
 {
+   struct ci_hdrc_cable *cable;
+
+   cable = >platdata->vbus_extcon;
+   if (!IS_ERR(cable->edev)) {
+   if (data & mask & OTGSC_BSVIS)
+   cable->changed = false;
+
+   /* Don't enable vbus interrupt if using external notifier */
+   if (data & mask & OTGSC_BSVIE) {
+   cable->enabled = true;
+   data &= ~OTGSC_BSVIE;
+   } else if (mask & OTGSC_BSVIE) {
+   cable->enabled = false;
+   }
+   }
+
+   cable = >platdata->id_extcon;
+   if (!IS_ERR(cable->edev)) {
+   if (data & mask & OTGSC_IDIS)
+   cable->changed = false;
+
+   /* Don't enable id interrupt if using external notifier */
+   if (data & mask & OTGSC_IDIE) {
+   cable->enabled = true;
+   data &= ~OTGSC_IDIE;
+   } else if (mask & OTGSC_IDIE) {
+   cable->enabled = false;
+   }
+   }
+
hw_write(ci, OP_OTGSC, mask | OTGSC_INT_STATUS_BITS, data);
 }
 
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 5dd75fa47dd8..f9be467d6695 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -14,6 +14,7 @@ struct ci_hdrc;
  * struct ci_hdrc_cable - structure for external connector cable state tracking
  * @state: current state of the line
  * @changed: set to true when extcon event happen
+ * @enabled: set to true if we've enabled the vbus or id interrupt
  * @edev: device which generate events
  * @ci: driver state of the chipidea device
  * @nb: hold event notification callback
@@ -22,6 +23,7 @@ struct ci_hdrc;
 struct ci_hdrc_cable {
boolstate;
boolchanged;
+   boolenabled;
struct extcon_dev   *edev;
struct ci_hdrc  *ci;
struct notifier_block   nb;
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 13/23] usb: chipidea: msm: Rely on core to override AHBBURST

[Stephen Boyd]

The core framework already handles setting this parameter with a
platform quirk. Add the appropriate flag so that we always set
AHBBURST to 0. Technically DT should be doing this, but we always
do it for msm chipidea devices so setting the flag in the driver
works just as well. If the burst needs to be anything besides 0,
we expect the 'ahb-burst-config' dts property to be present.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 89c1a02d69b5..719b20caf88e 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -24,7 +24,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
unsigned event)
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
-   writel(0, USB_AHBBURST);
/* use AHB transactor, allow posted data writes */
writel(0x8, USB_AHBMODE);
usb_phy_init(ci->usb_phy);
@@ -47,7 +46,8 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
.name   = "ci_hdrc_msm",
.capoffset  = DEF_CAPOFFSET,
.flags  = CI_HDRC_REGS_SHARED |
- CI_HDRC_DISABLE_STREAMING,
+ CI_HDRC_DISABLE_STREAMING |
+ CI_HDRC_OVERRIDE_AHB_BURST,
 
.notify_event   = ci_hdrc_msm_notify_event,
 };
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 21/23] usb: chipidea: msm: Be silent on probe defer errors

[Stephen Boyd]

If something fails in ci_hdrc_add_device() due to probe defer, we
shouldn't print an error message. Be silent in this case as we'll
try probe again later.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 316044dba0ac..f1ede7909f54 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -262,8 +262,9 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
 pdev->num_resources, >pdata);
if (IS_ERR(plat_ci)) {
-   dev_err(>dev, "ci_hdrc_add_device failed!\n");
ret = PTR_ERR(plat_ci);
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "ci_hdrc_add_device failed!\n");
goto err_mux;
}
 
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 10/23] usb: chipidea: Consolidate extcon notifiers

[Stephen Boyd]

The two extcon notifiers are almost the same except for the
variable name for the cable structure and the id notifier inverts
the cable->state logic. Make it the same and replace two
functions with one to save some lines. This also makes it so that
the id cable state is true when the id pin is pulled low, so we
change the name of ->state to ->connected to properly reflect
that we're interested in the cable being connected.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Cc: "Ivan T. Ivanov" 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/core.c  | 45 
 drivers/usb/chipidea/otg.c   |  8 
 include/linux/usb/chipidea.h |  4 ++--
 3 files changed, 18 insertions(+), 39 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index f144e1bbcc82..83bc2f2dd6a8 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -577,35 +577,14 @@ static irqreturn_t ci_irq(int irq, void *data)
return ret;
 }
 
-static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
-   void *ptr)
+static int ci_cable_notifier(struct notifier_block *nb, unsigned long event,
+void *ptr)
 {
-   struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
-   struct ci_hdrc *ci = vbus->ci;
+   struct ci_hdrc_cable *cbl = container_of(nb, struct ci_hdrc_cable, nb);
+   struct ci_hdrc *ci = cbl->ci;
 
-   if (event)
-   vbus->state = true;
-   else
-   vbus->state = false;
-
-   vbus->changed = true;
-
-   ci_irq(ci->irq, ci);
-   return NOTIFY_DONE;
-}
-
-static int ci_id_notifier(struct notifier_block *nb, unsigned long event,
- void *ptr)
-{
-   struct ci_hdrc_cable *id = container_of(nb, struct ci_hdrc_cable, nb);
-   struct ci_hdrc *ci = id->ci;
-
-   if (event)
-   id->state = false;
-   else
-   id->state = true;
-
-   id->changed = true;
+   cbl->connected = event;
+   cbl->changed = true;
 
ci_irq(ci->irq, ci);
return NOTIFY_DONE;
@@ -714,27 +693,27 @@ static int ci_get_platdata(struct device *dev,
}
 
cable = >vbus_extcon;
-   cable->nb.notifier_call = ci_vbus_notifier;
+   cable->nb.notifier_call = ci_cable_notifier;
cable->edev = ext_vbus;
 
if (!IS_ERR(ext_vbus)) {
ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
if (ret)
-   cable->state = true;
+   cable->connected = true;
else
-   cable->state = false;
+   cable->connected = false;
}
 
cable = >id_extcon;
-   cable->nb.notifier_call = ci_id_notifier;
+   cable->nb.notifier_call = ci_cable_notifier;
cable->edev = ext_id;
 
if (!IS_ERR(ext_id)) {
ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
if (ret)
-   cable->state = false;
+   cable->connected = true;
else
-   cable->state = true;
+   cable->connected = false;
}
return 0;
 }
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 0cf149e8..695f3fe3ae21 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -44,7 +44,7 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
else
val &= ~OTGSC_BSVIS;
 
-   if (cable->state)
+   if (cable->connected)
val |= OTGSC_BSV;
else
val &= ~OTGSC_BSV;
@@ -62,10 +62,10 @@ u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
else
val &= ~OTGSC_IDIS;
 
-   if (cable->state)
-   val |= OTGSC_ID;
+   if (cable->connected)
+   val &= ~OTGSC_ID; /* host */
else
-   val &= ~OTGSC_ID;
+   val |= OTGSC_ID; /* device */
 
if (cable->enabled)
val |= OTGSC_IDIE;
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index d07b162073f7..7e3daa37cf60 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -12,7 +12,7 @@ struct ci_hdrc;
 
 /**
  * struct ci_hdrc_cable - structure for external connector cable state tracking
- * @state: current state of the line
+ * @connected: true if cable is connected, false otherwise
  * @changed: set to true when extcon event happen
  * @enabled: set to true if we've enabled the vbus or id interrupt
  * @edev: device which generate events
@@ -21,7 +21,7 @@ struct ci_hdrc;

[PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy

[Stephen Boyd]

The high-speed phy on qcom SoCs is controlled via the ULPI
viewport.

Cc: Kishon Vijay Abraham I 
Cc: 
Cc: Rob Herring 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  86 +++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qcom-usb-hs.c  | 286 +
 4 files changed, 381 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hs.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
new file mode 100644
index ..ed994dbc9248
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
@@ -0,0 +1,86 @@
+Qualcomm's USB HS PHY
+
+PROPERTIES
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "qcom,usb-hs-phy" and more specifically one of 
the
+following:
+
+"qcom,usb-hs-phy-apq8064"
+"qcom,usb-hs-phy-msm8916"
+"qcom,usb-hs-phy-msm8974"
+
+- #phy-cells:
+Usage: required
+Value type: 
+Definition: Should contain 0
+
+- clocks:
+Usage: required
+Value type: 
+Definition: Should contain clock specifier for the reference and sleep
+clocks
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: Should contain "ref" and "sleep" for the reference and sleep
+clocks respectively
+
+- resets:
+Usage: required
+Value type: 
+Definition: Should contain the phy and POR resets
+
+- reset-names:
+Usage: required
+Value type: 
+Definition: Should contain "phy" and "por" for the phy and POR resets
+respectively
+
+- v3p3-supply:
+Usage: required
+Value type: 
+Definition: Should contain a reference to the 3.3V supply
+
+- v1p8-supply:
+Usage: required
+Value type: 
+Definition: Should contain a reference to the 1.8V supply
+
+- extcon:
+Usage: optional
+Value type: 
+Definition: Should contain the vbus and ID extcons in the first and second
+cells respectively
+
+- qcom,init-seq:
+Usage: optional
+Value type: 
+Definition: Should contain a sequence of ULPI address and value pairs to
+program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related
+to Device Mode Eye Diagram test. The addresses are offsets
+   from the ULPI_EXT_VENDOR_SPECIFIC address, for example,
+   <0x1 0x53> would mean we should write the value 0x53 to address
+   0x81.
+
+EXAMPLE
+
+otg: usb-controller {
+   ulpi {
+   phy {
+   compatible = "qcom,usb-hs-phy-msm8974", 
"qcom,usb-hs-phy";
+   #phy-cells = <0>;
+   clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
+   clock-names = "ref", "sleep";
+   resets = < GCC_USB2A_PHY_BCR>, < 0>;
+   reset-names = "phy", "por";
+   v3p3-supply = <_l24>;
+   v1p8-supply = <_l6>;
+   extcon = <>, <_id>;
+   qcom,init-seq = /bits/ 8 <0x1 0x63>;
+   };
+   };
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6bfc91a8ea3e..3fcfc5899b6d 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -453,6 +453,14 @@ config PHY_QCOM_UFS
help
  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HS
+   tristate "Qualcomm USB HS PHY module"
+   depends on USB_ULPI_BUS
+   select GENERIC_PHY
+   help
+ Support for the USB high-speed ULPI compliant phy on Qualcomm
+ chipsets.
+
 config PHY_QCOM_USB_HSIC
tristate "Qualcomm USB HSIC ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 914b843eac13..df62074ded2f 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HS)  += phy-qcom-usb-hs.o
 obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
diff --git a/drivers/phy/phy-qcom-usb-hs.c b/drivers/phy/phy-qcom-usb-hs.c
new file mode 100644
index ..00cc86e94749
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hs.c
@@ -0,0 +1,286 @@
+/**
+ * Copyright (C) 2016 

[PATCH v5 19/23] usb: chipidea: msm: Add reset controller for PHY POR bit

[Stephen Boyd]

The MSM chipidea wrapper has two bits that are used to reset the
first or second phy. Add support for these bits via the reset
controller framework, so that phy drivers can reset their
hardware at the right time during initialization.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/Kconfig   |  1 +
 drivers/usb/chipidea/ci_hdrc_msm.c | 50 --
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 19c20eaa23f2..fc96f5cdcb5c 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -2,6 +2,7 @@ config USB_CHIPIDEA
tristate "ChipIdea Highspeed Dual Role Controller"
depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && 
!USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
select EXTCON
+   select RESET_CONTROLLER
help
  Say Y here if your system has a dual role high speed USB
  controller based on ChipIdea silicon IP. It supports:
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 2489a63d3e75..fe96df7b530c 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -31,8 +32,10 @@
 #define HSPHY_SESS_VLD_CTRLBIT(25)
 
 /* Vendor base starts at 0x200 beyond CI base */
+#define HS_PHY_CTRL0x0040
 #define HS_PHY_SEC_CTRL0x0078
 #define HS_PHY_DIG_CLAMP_N BIT(16)
+#define HS_PHY_POR_ASSERT  BIT(0)
 
 struct ci_hdrc_msm {
struct platform_device *ci;
@@ -40,11 +43,43 @@ struct ci_hdrc_msm {
struct clk *iface_clk;
struct clk *fs_clk;
struct ci_hdrc_platform_data pdata;
+   struct reset_controller_dev rcdev;
bool secondary_phy;
bool hsic;
void __iomem *base;
 };
 
+static int
+ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
+{
+   struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
+   void __iomem *addr = ci_msm->base;
+   u32 val;
+
+   if (id)
+   addr += HS_PHY_SEC_CTRL;
+   else
+   addr += HS_PHY_CTRL;
+
+   val = readl_relaxed(addr);
+   val |= HS_PHY_POR_ASSERT;
+   writel(val, addr);
+   /*
+* wait for minimum 10 microseconds as suggested by manual.
+* Use a slightly larger value since the exact value didn't
+* work 100% of the time.
+*/
+   udelay(12);
+   val &= ~HS_PHY_POR_ASSERT;
+   writel(val, addr);
+
+   return 0;
+}
+
+static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
+   .reset = ci_hdrc_msm_por_reset,
+};
+
 static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
struct device *dev = ci->dev->parent;
@@ -186,10 +221,18 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
if (!ci->base)
return -ENOMEM;
 
-   ret = clk_prepare_enable(ci->fs_clk);
+   ci->rcdev.owner = THIS_MODULE;
+   ci->rcdev.ops = _hdrc_msm_reset_ops;
+   ci->rcdev.of_node = pdev->dev.of_node;
+   ci->rcdev.nr_resets = 2;
+   ret = reset_controller_register(>rcdev);
if (ret)
return ret;
 
+   ret = clk_prepare_enable(ci->fs_clk);
+   if (ret)
+   goto err_fs;
+
reset_control_assert(reset);
usleep_range(1, 12000);
reset_control_deassert(reset);
@@ -198,7 +241,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 
ret = clk_prepare_enable(ci->core_clk);
if (ret)
-   return ret;
+   goto err_fs;
 
ret = clk_prepare_enable(ci->iface_clk);
if (ret)
@@ -236,6 +279,8 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
clk_disable_unprepare(ci->iface_clk);
 err_iface:
clk_disable_unprepare(ci->core_clk);
+err_fs:
+   reset_controller_unregister(>rcdev);
return ret;
 }
 
@@ -247,6 +292,7 @@ static int ci_hdrc_msm_remove(struct platform_device *pdev)
ci_hdrc_remove_device(ci->ci);
clk_disable_unprepare(ci->iface_clk);
clk_disable_unprepare(ci->core_clk);
+   reset_controller_unregister(>rcdev);
 
return 0;
 }
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 09/23] usb: chipidea: Add support for ULPI PHY bus

[Stephen Boyd]

Some phys for the chipidea controller are controlled via the ULPI
viewport. Add support for the ULPI bus so that these sorts of
phys can be probed and read/written automatically without having
to duplicate the viewport logic in each phy driver.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Cc: Heikki Krogerus 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/Kconfig  |   7 +++
 drivers/usb/chipidea/Makefile |   1 +
 drivers/usb/chipidea/ci.h |  21 
 drivers/usb/chipidea/core.c   |  31 +---
 drivers/usb/chipidea/ulpi.c   | 113 ++
 5 files changed, 167 insertions(+), 6 deletions(-)
 create mode 100644 drivers/usb/chipidea/ulpi.c

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 5e5b9eb7ebf6..19c20eaa23f2 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -38,4 +38,11 @@ config USB_CHIPIDEA_HOST
  Say Y here to enable host controller functionality of the
  ChipIdea driver.
 
+config USB_CHIPIDEA_ULPI
+   bool "ChipIdea ULPI PHY support"
+   depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_CHIPIDEA
+   help
+ Say Y here if you have a ULPI PHY attached to your ChipIdea
+ controller.
+
 endif
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 518e445476c3..39fca5715ed3 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -4,6 +4,7 @@ ci_hdrc-y   := core.o otg.o debug.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
 ci_hdrc-$(CONFIG_USB_OTG_FSM)  += otg_fsm.o
+ci_hdrc-$(CONFIG_USB_CHIPIDEA_ULPI)+= ulpi.o
 
 # Glue/Bridge layers go here
 
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 05bc4d631cb9..59e22389c10b 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /**
  * DEFINE
@@ -52,6 +54,7 @@ enum ci_hw_regs {
OP_ENDPTLISTADDR,
OP_TTCTRL,
OP_BURSTSIZE,
+   OP_ULPI_VIEWPORT,
OP_PORTSC,
OP_DEVLC,
OP_OTGSC,
@@ -187,6 +190,8 @@ struct hw_bank {
  * @test_mode: the selected test mode
  * @platdata: platform specific information supplied by parent device
  * @vbus_active: is VBUS active
+ * @ulpi: pointer to ULPI device, if any
+ * @ulpi_ops: ULPI read/write ops for this device
  * @phy: pointer to PHY, if any
  * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
  * @hcd: pointer to usb_hcd for ehci host driver
@@ -236,6 +241,10 @@ struct ci_hdrc {
 
struct ci_hdrc_platform_data*platdata;
int vbus_active;
+#ifdef CONFIG_USB_CHIPIDEA_ULPI
+   struct ulpi *ulpi;
+   struct ulpi_ops ulpi_ops;
+#endif
struct phy  *phy;
/* old usb_phy interface */
struct usb_phy  *usb_phy;
@@ -418,6 +427,16 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
 #endif
 }
 
+#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
+int ci_ulpi_init(struct ci_hdrc *ci);
+void ci_ulpi_exit(struct ci_hdrc *ci);
+int ci_ulpi_resume(struct ci_hdrc *ci);
+#else
+static inline int ci_ulpi_init(struct ci_hdrc *ci) { return 0; }
+static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
+static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
+#endif
+
 u32 hw_read_intr_enable(struct ci_hdrc *ci);
 
 u32 hw_read_intr_status(struct ci_hdrc *ci);
@@ -428,6 +447,8 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
 
 u8 hw_port_test_get(struct ci_hdrc *ci);
 
+void hw_phymode_configure(struct ci_hdrc *ci);
+
 void ci_platform_configure(struct ci_hdrc *ci);
 
 int dbg_create_files(struct ci_hdrc *ci);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 532085a096d9..f144e1bbcc82 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
[OP_ENDPTLISTADDR]  = 0x18U,
[OP_TTCTRL] = 0x1CU,
[OP_BURSTSIZE]  = 0x20U,
+   [OP_ULPI_VIEWPORT]  = 0x30U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC]  = 0x84U,
[OP_OTGSC]  = 0x64U,
@@ -110,6 +111,7 @@ static const u8 ci_regs_lpm[] = {
[OP_ENDPTLISTADDR]  = 0x18U,
[OP_TTCTRL] = 0x1CU,
[OP_BURSTSIZE]  = 0x20U,
+   [OP_ULPI_VIEWPORT]  = 0x30U,
[OP_PORTSC] = 0x44U,
[OP_DEVLC]  = 0x84U,
[OP_OTGSC]  = 0xC4U,
@@ -285,7 +287,7 @@ static int hw_device_init(struct ci_hdrc *ci, void 

[PATCH v5 08/23] usb: chipidea: Remove locking in ci_udc_start()

[Stephen Boyd]

We don't call hw_device_reset() with the ci->lock held, so it
doesn't seem like this lock here is protecting anything. Let's
just remove it. This allows us to call sleeping functions like
phy_init() from within the CI_HDRC_CONTROLLER_RESET_EVENT hook.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/udc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 661f43fe0f9e..145b1fd86f58 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1725,7 +1725,6 @@ static int ci_udc_start(struct usb_gadget *gadget,
 struct usb_gadget_driver *driver)
 {
struct ci_hdrc *ci = container_of(gadget, struct ci_hdrc, gadget);
-   unsigned long flags;
int retval = -ENOMEM;
 
if (driver->disconnect == NULL)
@@ -1752,7 +1751,6 @@ static int ci_udc_start(struct usb_gadget *gadget,
 
pm_runtime_get_sync(>gadget.dev);
if (ci->vbus_active) {
-   spin_lock_irqsave(>lock, flags);
hw_device_reset(ci);
} else {
usb_udc_vbus_handler(>gadget, false);
@@ -1761,7 +1759,6 @@ static int ci_udc_start(struct usb_gadget *gadget,
}
 
retval = hw_device_state(ci, ci->ep0out->qh.dma);
-   spin_unlock_irqrestore(>lock, flags);
if (retval)
pm_runtime_put_sync(>gadget.dev);
 
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 20/23] usb: chipidea: msm: Handle phy power states

[Stephen Boyd]

The ULPI phy on qcom platforms needs to be initialized and
powered on after a USB reset and before we toggle the run/stop
bit. Otherwise, the phy locks up and doesn't work properly. Hook
the phy initialization into the RESET event and the phy power off
into the STOPPED event.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 40 +++---
 drivers/usb/chipidea/core.c|  8 ++--
 drivers/usb/chipidea/host.c|  8 ++--
 include/linux/usb/chipidea.h   |  2 +-
 4 files changed, 33 insertions(+), 25 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index fe96df7b530c..316044dba0ac 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -80,20 +80,33 @@ static const struct reset_control_ops ci_hdrc_msm_reset_ops 
= {
.reset = ci_hdrc_msm_por_reset,
 };
 
-static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
+static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
 {
struct device *dev = ci->dev->parent;
struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
+   int ret;
 
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
+
+   hw_phymode_configure(ci);
if (msm_ci->secondary_phy) {
u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
val |= HS_PHY_DIG_CLAMP_N;
writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
}
 
+   ret = phy_init(ci->phy);
+   if (ret)
+   return ret;
+
+   ret = phy_power_on(ci->phy);
+   if (ret) {
+   phy_exit(ci->phy);
+   return ret;
+   }
+
/* use AHB transactor, allow posted data writes */
hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
 
@@ -113,21 +126,18 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
unsigned event)
 HSPHY_SESS_VLD_CTRL);
 
}
-
-   usb_phy_init(ci->usb_phy);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
-   /*
-* Put the phy in non-driving mode. Otherwise host
-* may not detect soft-disconnection.
-*/
-   usb_phy_notify_disconnect(ci->usb_phy, USB_SPEED_UNKNOWN);
+   phy_power_off(ci->phy);
+   phy_exit(ci->phy);
break;
default:
dev_dbg(dev, "unknown ci_hdrc event\n");
break;
}
+
+   return 0;
 }
 
 static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
@@ -167,7 +177,6 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 {
struct ci_hdrc_msm *ci;
struct platform_device *plat_ci;
-   struct usb_phy *phy;
struct clk *clk;
struct reset_control *reset;
struct resource *res;
@@ -181,21 +190,12 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, ci);
 
-   /*
-* OTG(PHY) driver takes care of PHY initialization, clock management,
-* powering up VBUS, mapping of registers address space and power
-* management.
-*/
-   phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
-   if (IS_ERR(phy))
-   return PTR_ERR(phy);
-
ci->pdata.name = "ci_hdrc_msm";
ci->pdata.capoffset = DEF_CAPOFFSET;
ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
- CI_HDRC_OVERRIDE_AHB_BURST;
+ CI_HDRC_OVERRIDE_AHB_BURST |
+ CI_HDRC_OVERRIDE_PHY_CONTROL;
ci->pdata.notify_event = ci_hdrc_msm_notify_event;
-   ci->pdata.usb_phy = phy;
 
reset = devm_reset_control_get(>dev, "core");
if (IS_ERR(reset))
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index d1ae9a03e0fa..fbef1c961572 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -327,6 +327,7 @@ void hw_phymode_configure(struct ci_hdrc *ci)
hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
}
 }
+EXPORT_SYMBOL_GPL(hw_phymode_configure);
 
 /**
  * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
@@ -503,9 +504,12 @@ int hw_device_reset(struct ci_hdrc *ci)
return ret;
}
 
-   if (ci->platdata->notify_event)
-   ci->platdata->notify_event(ci,
+   if 

[PATCH v5 06/23] usb: chipidea: Add platform flag for wrapper phy management

[Stephen Boyd]

The ULPI phy on qcom platforms needs to be initialized and
powered on after a USB reset and before we toggle the run/stop
bit. Otherwise, the phy locks up and doesn't work properly.
Therefore, add a flag to skip any phy power management in the
core layer, leaving it up to the glue driver to manage.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/core.c  | 6 ++
 include/linux/usb/chipidea.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 01390e02ee53..532085a096d9 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -361,6 +361,9 @@ static int _ci_usb_phy_init(struct ci_hdrc *ci)
  */
 static void ci_usb_phy_exit(struct ci_hdrc *ci)
 {
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_PHY_CONTROL)
+   return;
+
if (ci->phy) {
phy_power_off(ci->phy);
phy_exit(ci->phy);
@@ -379,6 +382,9 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
 {
int ret;
 
+   if (ci->platdata->flags & CI_HDRC_OVERRIDE_PHY_CONTROL)
+   return 0;
+
switch (ci->platdata->phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
case USBPHY_INTERFACE_MODE_UTMIW:
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index f9be467d6695..d07b162073f7 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -57,6 +57,7 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
 #define CI_HDRC_OVERRIDE_TX_BURST  BIT(10)
 #define CI_HDRC_OVERRIDE_RX_BURST  BIT(11)
+#define CI_HDRC_OVERRIDE_PHY_CONTROL   BIT(12) /* Glue layer manages phy */
enum usb_dr_modedr_mode;
 #define CI_HDRC_CONTROLLER_RESET_EVENT 0
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 07/23] usb: chipidea: Notify events when switching host mode

[Stephen Boyd]

The chipidea/udc.c file sends a CI_HDRC_CONTROLLER_RESET_EVENT to
the wrapper drivers when it calls hw_device_reset(), but that
function is not called from chipidea/host.c. And the udc.c file
sends the CI_HDRC_CONTROLLER_STOPPED_EVENT but the host.c file
doesn't do anything.

The intent of the reset event is to allow the wrapper driver to
do any wrapper specific things after the reset bit has been set
in the usb command register. Therefore, add this event hook in
the host role after we toggle that bit.

Similarly, the intent of the stopped event is to allow the
wrapper driver to do any wrapper specific things after the device
is stopped. So when we stop the host role, send the stopped
event.

Acked-by: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/host.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 96ae69502c86..f036a9e39ced 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -90,6 +90,9 @@ static int ehci_ci_reset(struct usb_hcd *hcd)
 
ehci->need_io_watchdog = 0;
 
+   if (ci->platdata->notify_event)
+   ci->platdata->notify_event(ci, CI_HDRC_CONTROLLER_RESET_EVENT);
+
ci_platform_configure(ci);
 
return ret;
@@ -187,6 +190,9 @@ static void host_stop(struct ci_hdrc *ci)
struct usb_hcd *hcd = ci->hcd;
 
if (hcd) {
+   if (ci->platdata->notify_event)
+   ci->platdata->notify_event(ci,
+   CI_HDRC_CONTROLLER_STOPPED_EVENT);
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
if (ci->platdata->reg_vbus && !ci_otg_is_fsm_mode(ci) &&
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 01/23] of: device: Support loading a module with OF based modalias

[Stephen Boyd]

In the case of ULPI devices, we want to be able to load the
driver before registering the device so that we don't get stuck
in a loop waiting for the phy module to appear and failing usb
controller probe. Currently we request the ulpi module via the
ulpi ids, but in the DT case we might need to request it with the
OF based modalias instead. Add a common function that allows
anyone to request a module with the OF based modalias.

Acked-by: Rob Herring 
Cc: 
Signed-off-by: Stephen Boyd 
---
 drivers/of/device.c   | 23 +++
 include/linux/of_device.h |  6 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index fd5cfad7c403..8a22a253a830 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -226,6 +226,29 @@ ssize_t of_device_get_modalias(struct device *dev, char 
*str, ssize_t len)
return tsize;
 }
 
+int of_device_request_module(struct device *dev)
+{
+   char *str;
+   ssize_t size;
+   int ret;
+
+   size = of_device_get_modalias(dev, NULL, 0);
+   if (size < 0)
+   return size;
+
+   str = kmalloc(size + 1, GFP_KERNEL);
+   if (!str)
+   return -ENOMEM;
+
+   of_device_get_modalias(dev, str, size);
+   str[size] = '\0';
+   ret = request_module(str);
+   kfree(str);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_device_request_module);
+
 /**
  * of_device_uevent - Display OF related uevent information
  */
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687a89d..e9afbcc8de12 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -37,6 +37,7 @@ extern const void *of_device_get_match_data(const struct 
device *dev);
 
 extern ssize_t of_device_get_modalias(struct device *dev,
char *str, ssize_t len);
+extern int of_device_request_module(struct device *dev);
 
 extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
 extern int of_device_uevent_modalias(struct device *dev, struct 
kobj_uevent_env *env);
@@ -78,6 +79,11 @@ static inline int of_device_get_modalias(struct device *dev,
return -ENODEV;
 }
 
+static inline int of_device_request_module(struct device *dev)
+{
+   return -ENODEV;
+}
+
 static inline int of_device_uevent_modalias(struct device *dev,
   struct kobj_uevent_env *env)
 {
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/8] power: add power sequence library

[Peter Chen]

On Tue, Oct 18, 2016 at 02:35:38AM +0200, Rafael J. Wysocki wrote:
> On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote:
> > On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > > > Hi all,
> > > > 
> > > > This is a follow-up for my last power sequence framework patch set [1].
> > > > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > > > power sequence instances will be added at postcore_initcall, the match
> > > > criteria is compatible string first, if the compatible string is not
> > > > matched between dts and library, it will try to use generic power 
> > > > sequence.
> > > >  
> > > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > > > if only one power sequence instance is needed, for more power sequences
> > > > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB 
> > > > hub driver).
> > > > 
> > > > In future, if there are special power sequence requirements, the special
> > > > power sequence library can be created.
> > > > 
> > > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > > > two hot-plug devices to simulate this use case, the related binding
> > > > change is updated at patch [1/6], The udoo board changes were tested
> > > > using my last power sequence patch set.[3]
> > > > 
> > > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > > > need to power on itself before it can be found by ULPI bus.
> > > > 
> > > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > > > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > > > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > > > 
> > > > Changes for v8:
> > > > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can 
> > > > avoid
> > > >   preallocate instances problem which the number of instance is decided 
> > > > at
> > > >   compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > > > - Delete pwrseq_compatible_sample.c which is the demo purpose to show 
> > > > compatible
> > > >   match method. [Patch 2/8]
> > > > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> > > > 
> > > > Changes for v7:
> > > > - Create kinds of power sequence instance at postcore_initcall, and 
> > > > match
> > > >   the instance with node using compatible string, the beneit of this is
> > > >   the host driver doesn't need to consider which pwrseq instance needs
> > > >   to be used, and pwrseq core will match it, however, it eats some 
> > > > memories
> > > >   if less power sequence instances are used. [Patch 2/8]
> > > > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. 
> > > > [Patch 2/8]
> > > > - Fix the comments Vaibhav Hiremath adds for error path for clock and 
> > > > do not
> > > >   use device_node for parameters at pwrseq_on. [Patch 2/8]
> > > > - Simplify the caller to use power sequence, follows Alan's commnets 
> > > > [Patch 4/8]
> > > > - Tested three pwrseq instances together using both specific compatible 
> > > > string and
> > > >   generic libraries.
> > > > 
> > > > Changes for v6:
> > > > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > > > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > > > - Applies Joshua Clayton's three dts changes for two boards,
> > > >   the USB device's reg has only #address-cells, but without #size-cells.
> > > > 
> > > > Changes for v5:
> > > > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > > > - Fix the linker error when the pwrseq user is compiled as module
> > > > 
> > > > Changes for v4:
> > > > - Create the patch on next-20160722 
> > > > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 
> > > > 5/6]
> > > > - Using more friendly wait method for reset gpio [Patch 2/6]
> > > > - Support multiple input clocks [Patch 2/6]
> > > > - Add Rob Herring's ack for DT changes
> > > > - Add Joshua Clayton's Tested-by
> > > > 
> > > > Changes for v3:
> > > > - Delete "power-sequence" property at binding-doc, and change related 
> > > > code
> > > >   at both library and user code.
> > > > - Change binding-doc example node name with Rob's comments
> > > > - of_get_named_gpio_flags only gets the gpio, but without setting gpio 
> > > > flags,
> > > >   add additional code request gpio with proper gpio flags
> > > > - Add Philipp Zabel's Ack and MAINTAINER's entry
> > > > 
> > > > Changes for v2:
> > > > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > > > - Should use structure not but its pointer for kzalloc
> > > > - Since chipidea core has no of_node, let core's of_node equals glue
> > > >   layer's at core's probe
> > > > 
> > > > Joshua Clayton (2):
> > > >   ARM: dts: imx6qdl: Enable usb node children with 
> > > >   ARM: dts: imx6q-evi: Fix onboard hub reset line
> > > > 
> > > > Peter Chen 

Re: usb_ep_{dis,en}able() calling context (was: Re: [PATCH 2/3] usb: dwc3: gadget: wait for End Transfer to complete)

[Peter Chen]

On Mon, Oct 17, 2016 at 12:51:48PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> > On Mon, Oct 17, 2016 at 11:06:49AM +0300, Felipe Balbi wrote:
> >> 
> >> Hi Baolin,
> >> 
> >> Baolin Wang  writes:
> >> >> Felipe Balbi  writes:
> >> >>> Instead of just delaying for 100us, we should
> >> >>> actually wait for End Transfer Command Complete
> >> >>> interrupt before moving on. Note that this should
> >> >>> only be done if we're dealing with one of the core
> >> >>> revisions that actually require the interrupt before
> >> >>> moving on.
> >> >>>
> >> >>> Reported-by: Baolin Wang 
> >> >>> Signed-off-by: Felipe Balbi 
> >> >>
> >> >> I've updated this one in order to fix the comment we had about delaying
> >> >> 100us. No further changes were made, only the comment. Here it is:
> >> >>
> >> >> 8<
> >> >> From f3fa94f3171709f787a30e3c5ce69a668960b66e Mon Sep 17 00:00:00 2001
> >> >> From: Felipe Balbi 
> >> >> Date: Thu, 13 Oct 2016 14:09:47 +0300
> >> >> Subject: [PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete
> >> >>
> >> >> Instead of just delaying for 100us, we should
> >> >> actually wait for End Transfer Command Complete
> >> >> interrupt before moving on. Note that this should
> >> >> only be done if we're dealing with one of the core
> >> >> revisions that actually require the interrupt before
> >> >> moving on.
> >> >>
> >> >> Reported-by: Baolin Wang 
> >> >> Signed-off-by: Felipe Balbi 
> >> >
> >> > From my testing, there are still some problems caused by the nested
> >> > lock, at lease I found 2 functions will issue the usb_ep_disable()
> >> > function with spinlock:
> >> 
> >> Thanks for testing. Seems like I really need to revisit locking in the
> >> entire gadget API. In either case, we need to have a larger discussion
> >> about this situation.
> >> 
> >> IMO, usb_ep_disable() and usb_ep_enable() should only be callable from
> >> process context, but that has never been a requirement before. Still,
> >> it's not far-fetched to assume that a controller (such as dwc3, but
> >> probably others) might sleep while cancelling a transfer because they
> >> need to wait for an Interrupt.
> >> 
> >> In fact, we know of two controllers that need this: dwc3 and dwc3.1.
> >> 
> >> I wonder if there are any other controllers with this
> >> requirement. Either way, We should also consider if there are any strong
> >> reasons to call usb_ep_disable() with interrupts disabled and locks held
> >> considering that UDC _must_ call ->complete() for each and every
> >> request.
> >> 
> >> If we go ahead with this, it'll mean a rather large series (again) to
> >> fix all the calling semantics in every single gadget driver for both
> >> usb_ep_enable() and usb_ep_disable(). Then, making sure all UDC drivers
> >> respect the requirement, then we update documentation about the
> >> functions and add might_sleep() to their implementation in udc/core.c
> >> 
> >> Anybody objects to this new requirement?
> >> 
> >
> > At chipidea driver, it might call usb_ep_disable at interrupt context,
> > eg, the bus reset interrupt. See chipidea/udc.c isr_reset_handler->
> > _gadget_stop_activity->usb_ep_disable.
> 
> That implementation is wrong. You should tell the gadget driver that
> reset happened by calling usb_gadget_udc_reset(). It's just that
> usb_gadget_udc_reset() would also need to be called with IRQs enabled
> after this rework happens.
> 

I see, the usb_ep_disable should be called from gadget driver if a bus
reset occurs. Would you consider add special handling like work queue for
dwc3's ep_disable API to wait something?

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] Revert "usb: dwc2: gadget: fix TX FIFO size and address initialization"

[John Youn]

This reverts commit aa381a7259c3 ("usb: dwc2: gadget: fix TX FIFO size
and address initialization").

The original commit removed the FIFO size programming per endpoint. The
DPTXFSIZn register is also used for DIEPTXFn and the SIZE field is r/w
in dedicated fifo mode. So it isn't appropriate to simply remove this
initialization as it might break existing behavior.

Also, some cores might not have enough fifo space to handle the
programming method used in the reverted patch, resulting in fifo
initialization failure.

Signed-off-by: John Youn 
Cc: Robert Baldyga 
Cc: Stefan Wahren 
---
 drivers/usb/dwc2/core.h   |  7 +++
 drivers/usb/dwc2/gadget.c | 47 +++
 2 files changed, 46 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index aad4107..2a21a04 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -259,6 +259,13 @@ enum dwc2_lx_state {
DWC2_L3,/* Off state */
 };
 
+/*
+ * Gadget periodic tx fifo sizes as used by legacy driver
+ * EP0 is not included
+ */
+#define DWC2_G_P_LEGACY_TX_FIFO_SIZE {256, 256, 256, 256, 768, 768, 768, \
+  768, 0, 0, 0, 0, 0, 0, 0}
+
 /* Gadget ep0 states */
 enum dwc2_ep0_state {
DWC2_EP0_SETUP,
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index aac4af3..24fbebc 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -189,7 +189,6 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
unsigned int ep;
unsigned int addr;
int timeout;
-   u32 dptxfsizn;
u32 val;
 
/* Reset fifo map if not correctly cleared during previous session */
@@ -218,13 +217,13 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 * given endpoint.
 */
for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
-   dptxfsizn = dwc2_readl(hsotg->regs + DPTXFSIZN(ep));
-
-   val = (dptxfsizn & FIFOSIZE_DEPTH_MASK) | addr;
-   addr += dptxfsizn >> FIFOSIZE_DEPTH_SHIFT;
-
-   if (addr > hsotg->fifo_mem)
-   break;
+   if (!hsotg->g_tx_fifo_sz[ep])
+   continue;
+   val = addr;
+   val |= hsotg->g_tx_fifo_sz[ep] << FIFOSIZE_DEPTH_SHIFT;
+   WARN_ONCE(addr + hsotg->g_tx_fifo_sz[ep] > hsotg->fifo_mem,
+ "insufficient fifo memory");
+   addr += hsotg->g_tx_fifo_sz[ep];
 
dwc2_writel(val, hsotg->regs + DPTXFSIZN(ep));
}
@@ -3807,10 +3806,36 @@ static void dwc2_hsotg_dump(struct dwc2_hsotg *hsotg)
 static void dwc2_hsotg_of_probe(struct dwc2_hsotg *hsotg)
 {
struct device_node *np = hsotg->dev->of_node;
+   u32 len = 0;
+   u32 i = 0;
 
/* Enable dma if requested in device tree */
hsotg->g_using_dma = of_property_read_bool(np, "g-use-dma");
 
+   /*
+   * Register TX periodic fifo size per endpoint.
+   * EP0 is excluded since it has no fifo configuration.
+   */
+   if (!of_find_property(np, "g-tx-fifo-size", ))
+   goto rx_fifo;
+
+   len /= sizeof(u32);
+
+   /* Read tx fifo sizes other than ep0 */
+   if (of_property_read_u32_array(np, "g-tx-fifo-size",
+   >g_tx_fifo_sz[1], len))
+   goto rx_fifo;
+
+   /* Add ep0 */
+   len++;
+
+   /* Make remaining TX fifos unavailable */
+   if (len < MAX_EPS_CHANNELS) {
+   for (i = len; i < MAX_EPS_CHANNELS; i++)
+   hsotg->g_tx_fifo_sz[i] = 0;
+   }
+
+rx_fifo:
/* Register RX fifo size */
of_property_read_u32(np, "g-rx-fifo-size", >g_rx_fifo_sz);
 
@@ -3832,10 +3857,13 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
struct device *dev = hsotg->dev;
int epnum;
int ret;
+   int i;
+   u32 p_tx_fifo[] = DWC2_G_P_LEGACY_TX_FIFO_SIZE;
 
/* Initialize to legacy fifo configuration values */
hsotg->g_rx_fifo_sz = 2048;
hsotg->g_np_g_tx_fifo_sz = 1024;
+   memcpy(>g_tx_fifo_sz[1], p_tx_fifo, sizeof(p_tx_fifo));
/* Device tree specific probe */
dwc2_hsotg_of_probe(hsotg);
 
@@ -3853,6 +3881,9 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
dev_dbg(dev, "NonPeriodic TXFIFO size: %d\n",
hsotg->g_np_g_tx_fifo_sz);
dev_dbg(dev, "RXFIFO size: %d\n", hsotg->g_rx_fifo_sz);
+   for (i = 0; i < MAX_EPS_CHANNELS; i++)
+   dev_dbg(dev, "Periodic TXFIFO%2d size: %d\n", i,
+   hsotg->g_tx_fifo_sz[i]);
 
hsotg->gadget.max_speed = USB_SPEED_HIGH;
hsotg->gadget.ops = _hsotg_gadget_ops;
-- 
2.10.0

--
To unsubscribe from this 

[PATCH v2 3/3] Revert "Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size"

[John Youn]

This binding was deprecated due to commit aa381a7259c3 ("usb: dwc2:
gadget: fix TX FIFO size and address initialization"). However that
commit is now reverted, so also revert this commit.

The binding is valid and shouldn't be deprecated.

This reverts commit 65e1ff7f4b5b ("Documentation: devicetree: dwc2:
Deprecate g-tx-fifo-size").

Signed-off-by: John Youn 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/dwc2.txt | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 7d16ebf..20a68bf 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,10 +26,7 @@ Refer to phy/phy-bindings.txt for generic phy consumer 
properties
 - g-use-dma: enable dma usage in gadget driver.
 - g-rx-fifo-size: size of rx fifo size in gadget mode.
 - g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
-
-Deprecated properties:
-- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0)
-  in gadget mode.
+- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget 
mode.
 
 Example:
 
-- 
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] Revert "usb: dwc2: gadget: change variable name to more meaningful"

[John Youn]

This reverts commit ba48eab8866c ("usb: dwc2: gadget: change variable
name to more meaningful").

This is needed to cleanly revert commit aa381a7259c3 ("usb: dwc2:
gadget: fix TX FIFO size and address initialization") which may cause
regressions on some platforms.

Signed-off-by: John Youn 
Cc: Robert Baldyga 
Cc: Stefan Wahren 
---
 drivers/usb/dwc2/gadget.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4cd6403..aac4af3 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -186,7 +186,7 @@ static void dwc2_hsotg_ctrl_epint(struct dwc2_hsotg *hsotg,
  */
 static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 {
-   unsigned int fifo;
+   unsigned int ep;
unsigned int addr;
int timeout;
u32 dptxfsizn;
@@ -217,8 +217,8 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 * them to endpoints dynamically according to maxpacket size value of
 * given endpoint.
 */
-   for (fifo = 1; fifo < MAX_EPS_CHANNELS; fifo++) {
-   dptxfsizn = dwc2_readl(hsotg->regs + DPTXFSIZN(fifo));
+   for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
+   dptxfsizn = dwc2_readl(hsotg->regs + DPTXFSIZN(ep));
 
val = (dptxfsizn & FIFOSIZE_DEPTH_MASK) | addr;
addr += dptxfsizn >> FIFOSIZE_DEPTH_SHIFT;
@@ -226,7 +226,7 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
if (addr > hsotg->fifo_mem)
break;
 
-   dwc2_writel(val, hsotg->regs + DPTXFSIZN(fifo));
+   dwc2_writel(val, hsotg->regs + DPTXFSIZN(ep));
}
 
/*
-- 
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb: dwc2: Revert incorrect FIFO changes

[John Youn]

This series reverts patches that incorrectly removed some FIFO
programming.

Hi Felipe,

This fixes a regression on 4.9-rc1, could you queue them in your fixes
tree?

Thanks,
John

v2:
* Added Rob Herring's Acked-by


John Youn (3):
  Revert "usb: dwc2: gadget: change variable name to more meaningful"
  Revert "usb: dwc2: gadget: fix TX FIFO size and address
initialization"
  Revert "Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size"

 Documentation/devicetree/bindings/usb/dwc2.txt |  5 +--
 drivers/usb/dwc2/core.h|  7 
 drivers/usb/dwc2/gadget.c  | 53 --
 3 files changed, 50 insertions(+), 15 deletions(-)

-- 
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 0/8] power: add power sequence library

[Rafael J. Wysocki]

On Monday, October 17, 2016 09:30:59 AM Peter Chen wrote:
> On Fri, Oct 14, 2016 at 02:09:31PM +0200, Rafael J. Wysocki wrote:
> > On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> > > Hi all,
> > > 
> > > This is a follow-up for my last power sequence framework patch set [1].
> > > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > > power sequence instances will be added at postcore_initcall, the match
> > > criteria is compatible string first, if the compatible string is not
> > > matched between dts and library, it will try to use generic power 
> > > sequence.
> > >
> > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > > if only one power sequence instance is needed, for more power sequences
> > > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
> > > driver).
> > > 
> > > In future, if there are special power sequence requirements, the special
> > > power sequence library can be created.
> > > 
> > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > > two hot-plug devices to simulate this use case, the related binding
> > > change is updated at patch [1/6], The udoo board changes were tested
> > > using my last power sequence patch set.[3]
> > > 
> > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > > need to power on itself before it can be found by ULPI bus.
> > > 
> > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> > > 
> > > Changes for v8:
> > > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can 
> > > avoid
> > >   preallocate instances problem which the number of instance is decided at
> > >   compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> > > - Delete pwrseq_compatible_sample.c which is the demo purpose to show 
> > > compatible
> > >   match method. [Patch 2/8]
> > > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
> > > 
> > > Changes for v7:
> > > - Create kinds of power sequence instance at postcore_initcall, and match
> > >   the instance with node using compatible string, the beneit of this is
> > >   the host driver doesn't need to consider which pwrseq instance needs
> > >   to be used, and pwrseq core will match it, however, it eats some 
> > > memories
> > >   if less power sequence instances are used. [Patch 2/8]
> > > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. 
> > > [Patch 2/8]
> > > - Fix the comments Vaibhav Hiremath adds for error path for clock and do 
> > > not
> > >   use device_node for parameters at pwrseq_on. [Patch 2/8]
> > > - Simplify the caller to use power sequence, follows Alan's commnets 
> > > [Patch 4/8]
> > > - Tested three pwrseq instances together using both specific compatible 
> > > string and
> > >   generic libraries.
> > > 
> > > Changes for v6:
> > > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> > > - Change chipidea core of_node assignment for coming user. (patch [5/6])
> > > - Applies Joshua Clayton's three dts changes for two boards,
> > >   the USB device's reg has only #address-cells, but without #size-cells.
> > > 
> > > Changes for v5:
> > > - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> > > - Fix the linker error when the pwrseq user is compiled as module
> > > 
> > > Changes for v4:
> > > - Create the patch on next-20160722 
> > > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 
> > > 5/6]
> > > - Using more friendly wait method for reset gpio [Patch 2/6]
> > > - Support multiple input clocks [Patch 2/6]
> > > - Add Rob Herring's ack for DT changes
> > > - Add Joshua Clayton's Tested-by
> > > 
> > > Changes for v3:
> > > - Delete "power-sequence" property at binding-doc, and change related code
> > >   at both library and user code.
> > > - Change binding-doc example node name with Rob's comments
> > > - of_get_named_gpio_flags only gets the gpio, but without setting gpio 
> > > flags,
> > >   add additional code request gpio with proper gpio flags
> > > - Add Philipp Zabel's Ack and MAINTAINER's entry
> > > 
> > > Changes for v2:
> > > - Delete "pwrseq" prefix and clock-names for properties at dt binding
> > > - Should use structure not but its pointer for kzalloc
> > > - Since chipidea core has no of_node, let core's of_node equals glue
> > >   layer's at core's probe
> > > 
> > > Joshua Clayton (2):
> > >   ARM: dts: imx6qdl: Enable usb node children with 
> > >   ARM: dts: imx6q-evi: Fix onboard hub reset line
> > > 
> > > Peter Chen (6):
> > >   binding-doc: power: pwrseq-generic: add binding doc for generic power
> > > sequence library
> > >   power: add power sequence library
> > >   binding-doc: usb: usb-device: add optional properties for power
> > > sequence
> > >   usb: core: add power sequence handling for USB 

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

[Rafał Miłecki]

On 17 October 2016 at 23:10, Hauke Mehrtens  wrote:
> On 10/17/2016 10:30 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki 
>>
>> Broadcom's Northstar XHCI controllers seem to need a special start
>> procedure to work correctly. There isn't any official documentation of
>> this, the problem is that controller doesn't detect any connected
>> devices with default setup. Moreover connecting USB device to controller
>> that doesn't run properly can cause SoC's watchdog issues.
>>
>> A workaround that was successfully tested on multiple devices is to
>> perform a fake doorbell. This patch adds code for doing this and enables
>> it on BCM4708 family.
>>
>> Signed-off-by: Rafał Miłecki 
>> ---
>> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated 
>> binding
>> for it. Thanks Rob for your comment on this.
>> ---
>>  drivers/usb/host/xhci-plat.c |  6 +
>>  drivers/usb/host/xhci.c  | 63 
>> +---
>>  drivers/usb/host/xhci.h  |  1 +
>>  3 files changed, 67 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index ed56bf9..b01a3be 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -56,12 +56,18 @@ static int xhci_priv_init_quirk(struct usb_hcd *hcd)
>>
>>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>>  {
>> + struct platform_device  *pdev = to_platform_device(dev);
>> + struct device_node  *node = pdev->dev.of_node;
>> +
>>   /*
>>* As of now platform drivers don't provide MSI support so we ensure
>>* here that the generic code does not try to make a pci_dev from our
>>* dev struct in order to setup MSI
>>*/
>>   xhci->quirks |= XHCI_PLAT;
>> +
>> + if (node && of_machine_is_compatible("brcm,bcm4708"))
>> + xhci->quirks |= XHCI_FAKE_DOORBELL;
>
> Are you sure only the bcm4708 and similar SoCs are affected? Having here
> a list with 3 or more checks would looks strange. I prefer your first patch.
>
> @Florian do you know if other Broadcom SoC are affected by this problem
> or are only Northstar SoCs affected?

I also believed usb3-fake-doorbell property looks nicer, but then just
followed Rob's suggestion.

I don't know about Northstar Plus or Northstar 2, I just know it's not
needed for BCM53573.

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] usb: xhci: add support for performing fake doorbell

[Hauke Mehrtens]

On 10/17/2016 10:30 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Broadcom's Northstar XHCI controllers seem to need a special start
> procedure to work correctly. There isn't any official documentation of
> this, the problem is that controller doesn't detect any connected
> devices with default setup. Moreover connecting USB device to controller
> that doesn't run properly can cause SoC's watchdog issues.
> 
> A workaround that was successfully tested on multiple devices is to
> perform a fake doorbell. This patch adds code for doing this and enables
> it on BCM4708 family.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated binding
> for it. Thanks Rob for your comment on this.
> ---
>  drivers/usb/host/xhci-plat.c |  6 +
>  drivers/usb/host/xhci.c  | 63 
> +---
>  drivers/usb/host/xhci.h  |  1 +
>  3 files changed, 67 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..b01a3be 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -56,12 +56,18 @@ static int xhci_priv_init_quirk(struct usb_hcd *hcd)
>  
>  static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
>  {
> + struct platform_device  *pdev = to_platform_device(dev);
> + struct device_node  *node = pdev->dev.of_node;
> +
>   /*
>* As of now platform drivers don't provide MSI support so we ensure
>* here that the generic code does not try to make a pci_dev from our
>* dev struct in order to setup MSI
>*/
>   xhci->quirks |= XHCI_PLAT;
> +
> + if (node && of_machine_is_compatible("brcm,bcm4708"))
> + xhci->quirks |= XHCI_FAKE_DOORBELL;

Are you sure only the bcm4708 and similar SoCs are affected? Having here
a list with 3 or more checks would looks strange. I prefer your first patch.

@Florian do you know if other Broadcom SoC are affected by this problem
or are only Northstar SoCs affected?

Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2] usb: xhci: add support for performing fake doorbell

[Rafał Miłecki]

From: Rafał Miłecki 

Broadcom's Northstar XHCI controllers seem to need a special start
procedure to work correctly. There isn't any official documentation of
this, the problem is that controller doesn't detect any connected
devices with default setup. Moreover connecting USB device to controller
that doesn't run properly can cause SoC's watchdog issues.

A workaround that was successfully tested on multiple devices is to
perform a fake doorbell. This patch adds code for doing this and enables
it on BCM4708 family.

Signed-off-by: Rafał Miłecki 
---
V2: Enable quirk for brcm,bcm4708 machines instead of adding separated binding
for it. Thanks Rob for your comment on this.
---
 drivers/usb/host/xhci-plat.c |  6 +
 drivers/usb/host/xhci.c  | 63 +---
 drivers/usb/host/xhci.h  |  1 +
 3 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..b01a3be 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -56,12 +56,18 @@ static int xhci_priv_init_quirk(struct usb_hcd *hcd)
 
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct device_node  *node = pdev->dev.of_node;
+
/*
 * As of now platform drivers don't provide MSI support so we ensure
 * here that the generic code does not try to make a pci_dev from our
 * dev struct in order to setup MSI
 */
xhci->quirks |= XHCI_PLAT;
+
+   if (node && of_machine_is_compatible("brcm,bcm4708"))
+   xhci->quirks |= XHCI_FAKE_DOORBELL;
 }
 
 /* called during probe() after chip reset completes */
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1a4ca02..c77035e9b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -153,6 +153,49 @@ static int xhci_start(struct xhci_hcd *xhci)
return ret;
 }
 
+/**
+ * xhci_fake_doorbell - Perform a fake doorbell on a specified slot
+ *
+ * Some controllers require a fake doorbell to start correctly. Without that
+ * they simply don't detect any devices.
+ */
+static int xhci_fake_doorbell(struct xhci_hcd *xhci, int slot_id)
+{
+   u32 temp;
+
+   /* Alloc a virt device for that slot */
+   if (!xhci_alloc_virt_device(xhci, slot_id, NULL, GFP_NOIO)) {
+   xhci_warn(xhci, "Could not allocate xHCI USB device data 
structures\n");
+   return -ENOMEM;
+   }
+
+   /* Ring fake doorbell for slot_id ep 0 */
+   xhci_ring_ep_doorbell(xhci, slot_id, 0, 0);
+   usleep_range(1000, 1500);
+
+   /* Read the status to check if HSE is set or not */
+   temp = readl(>op_regs->status);
+
+   /* Clear HSE if set */
+   if (temp & STS_FATAL) {
+   xhci_dbg(xhci, "HSE problem detected, status: 0x%08x\n", temp);
+   temp &= ~0x1fff;
+   temp |= STS_FATAL;
+   writel(temp, >op_regs->status);
+   usleep_range(1000, 1500);
+   readl(>op_regs->status);
+   }
+
+   /* Free virt device */
+   xhci_free_virt_device(xhci, slot_id);
+
+   /* We're done if controller is already running */
+   if (readl(>op_regs->command) & CMD_RUN)
+   return 0;
+
+   return xhci_start(xhci);
+}
+
 /*
  * Reset a halted HC.
  *
@@ -565,10 +608,20 @@ int xhci_init(struct usb_hcd *hcd)
 
 static int xhci_run_finished(struct xhci_hcd *xhci)
 {
-   if (xhci_start(xhci)) {
-   xhci_halt(xhci);
-   return -ENODEV;
+   int err;
+
+   err = xhci_start(xhci);
+   if (err) {
+   err = -ENODEV;
+   goto err_halt;
+   }
+
+   if (xhci->quirks & XHCI_FAKE_DOORBELL) {
+   err = xhci_fake_doorbell(xhci, 1);
+   if (err)
+   goto err_halt;
}
+
xhci->shared_hcd->state = HC_STATE_RUNNING;
xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
 
@@ -578,6 +631,10 @@ static int xhci_run_finished(struct xhci_hcd *xhci)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB3 roothub");
return 0;
+
+err_halt:
+   xhci_halt(xhci);
+   return err;
 }
 
 /*
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index b2c1dc5..52d7498 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1653,6 +1653,7 @@ struct xhci_hcd {
 #define XHCI_MTK_HOST  (1 << 21)
 #define XHCI_SSIC_PORT_UNUSED  (1 << 22)
 #define XHCI_NO_64BIT_SUPPORT  (1 << 23)
+#define XHCI_FAKE_DOORBELL (1 << 24)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
-- 
2.9.3

--
To unsubscribe from this list: send the line 

Re: [PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues

[Alan Stern]

On Mon, 17 Oct 2016, Ulf Hansson wrote:

> On 13 October 2016 at 13:37, Ulf Hansson  wrote:
> > The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are 
> > interfacing
> > an rtsx_usb device (managed by an mfd driver) while communicating with the
> > cards. The mmc/sd and memstick devices are children of the usb device.
> >
> > Issues has been reported [1] for rtsx, which have been investigated, 
> > discussed,
> > fixed, tested, etc, particularly when using mmc/sd cards. During the
> > investigation, some changes was proposed and tested successfully. In this
> > series I have picked up these changes and created some proper patches with
> > change-logs.
> >
> > It turned out that most of the problems was related to the runtime PM
> > deployment in the memstick and the mmc/sd driver, which are fixed in this
> > series.
> >
> > A couple of more issues were also discussed [2], which needs to be fixed as
> > well. Although they are out of scope for this series, so we will have to 
> > look
> > into those at a later point. Here's a brief summary of these leftovers:
> >
> > *)
> > It seems reasonable to turn off autosuspend for usb devices and instead 
> > rely on
> > the usb device's children to deal with autosuspend. The reason is simply 
> > that
> > the children has better knowledge of when using autosuspend makes sense.
> >
> > **)
> > Polling card detect mode is used both for mmc/sd and memstick. Because of 
> > the
> > lack of synchronization between the polling attempts for these subsystems, 
> > the
> > usb device may be powered on for unnecessary long intervals, thus we are
> > wasting power.
> >
> > Besides the above changes, I folded in a change in the mmc core which 
> > improves
> > the behaviour for mmc hosts using MMC_CAP2_NO_PRESCAN_POWERUP, which is the
> > case for the rtsx_usb_sdmmc driver.  This change should improve the boot 
> > time
> > with ~100ms per rtsx_usb_sdmmc device.
> >
> > Finally, as I couldn't find an active maintainer for the memstick
> > subsystem/driver and because the author of the drivers can be reached, I
> > volunteer to take this all through my mmc tree. Please tell me if that is
> > problem to any of you.
> >
> > [1]
> > https://www.spinics.net/lists/linux-usb/msg146998.html
> > [2]
> > https://www.spinics.net/lists/linux-mmc/msg39235.html
> >
> >
> > Alan Stern (1):
> >   memstick: rtsx_usb_ms: Runtime resume the device when polling for
> > cards
> >
> > Ulf Hansson (5):
> >   mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when
> > unused
> >   mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
> >   memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
> >   mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend
> >   mmc: core: Don't power off the card when starting the host
> >
> >  drivers/memstick/host/rtsx_usb_ms.c |  6 ++
> >  drivers/mmc/core/core.c |  9 -
> >  drivers/mmc/host/rtsx_usb_sdmmc.c   | 10 +-
> >  3 files changed, 15 insertions(+), 10 deletions(-)
> >
> > --
> > 1.9.1
> >
> 
> Patch 1->4 applied for fixes. Holding patch 5->6 for a while, as they
> are intended for next!

Thanks for taking care of all these updates.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[Wim Osterholt]

On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> Hi,
>
> I got one of those devices. However, I don't get a crash.
> Could you please give me instructions on how you trigger it?
  
That's not too hard, just plug it in. :-)
  
However you must have set cdc_acm in your kernel, or availabe as a module. 
It happens on all my machines on kernels 4.8 and 4.9.
Now, all my kernel configs will differ a bit, but must have something
peculiar in common. Or you've received a totally different device.
 
Here's one config at http://webserver.djo.tudelft.nl/.config-4.8.1
 
Many options are inherited by 'make oldconfig' from version to version,
without me knowing what it all means. So maybe it's just a weird combination
of options then?


Regards, Wim.


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: ftdi_sio: add support for Infineon TriBoard TC2X7

[Johan Hovold]

On Thu, Oct 06, 2016 at 06:40:11PM +0200, Stefan Tauner wrote:
> This adds support to ftdi_sio for the Infineon TriBoard TC2X7
> engineering board for first-generation Aurix SoCs with Tricore CPUs.
> Mere addition of the device IDs does the job.
> 
> Signed-off-by: Stefan Tauner 

Now applied, thanks.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[Oliver Neukum]

On Thu, 2016-09-08 at 14:58 +0200, Wim Osterholt wrote:
> On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> > > 
> > > The oops tells things that I didn't all write down, but it says
> > > null pointer dereference at 0246
> > 
> > That is the important part. I am sorry, but without the oops
> > nobody can help you. Please capture it

Hi,

I got one of those devices. However, I don't get a crash.
Could you please give me instructions on how you trigger it?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb_ep_{dis,en}able() calling context (was: Re: [PATCH 2/3] usb: dwc3: gadget: wait for End Transfer to complete)

[Alan Stern]

On Mon, 17 Oct 2016, Felipe Balbi wrote:

> Hi Baolin,
> 
> Baolin Wang  writes:
> >> Felipe Balbi  writes:
> >>> Instead of just delaying for 100us, we should
> >>> actually wait for End Transfer Command Complete
> >>> interrupt before moving on. Note that this should
> >>> only be done if we're dealing with one of the core
> >>> revisions that actually require the interrupt before
> >>> moving on.
> >>>
> >>> Reported-by: Baolin Wang 
> >>> Signed-off-by: Felipe Balbi 
> >>
> >> I've updated this one in order to fix the comment we had about delaying
> >> 100us. No further changes were made, only the comment. Here it is:
> >>
> >> 8<
> >> From f3fa94f3171709f787a30e3c5ce69a668960b66e Mon Sep 17 00:00:00 2001
> >> From: Felipe Balbi 
> >> Date: Thu, 13 Oct 2016 14:09:47 +0300
> >> Subject: [PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete
> >>
> >> Instead of just delaying for 100us, we should
> >> actually wait for End Transfer Command Complete
> >> interrupt before moving on. Note that this should
> >> only be done if we're dealing with one of the core
> >> revisions that actually require the interrupt before
> >> moving on.
> >>
> >> Reported-by: Baolin Wang 
> >> Signed-off-by: Felipe Balbi 
> >
> > From my testing, there are still some problems caused by the nested
> > lock, at lease I found 2 functions will issue the usb_ep_disable()
> > function with spinlock:
> 
> Thanks for testing. Seems like I really need to revisit locking in the
> entire gadget API. In either case, we need to have a larger discussion
> about this situation.
> 
> IMO, usb_ep_disable() and usb_ep_enable() should only be callable from
> process context, but that has never been a requirement before. Still,
> it's not far-fetched to assume that a controller (such as dwc3, but
> probably others) might sleep while cancelling a transfer because they
> need to wait for an Interrupt.
> 
> In fact, we know of two controllers that need this: dwc3 and dwc3.1.

It's not clear that this should be the deciding factor.  That is, does 
usb_ep_disable() need to wait until all the endpoint's outstanding 
transfers have been completed before it returns?  I don't think it 
does.

> I wonder if there are any other controllers with this
> requirement. Either way, We should also consider if there are any strong
> reasons to call usb_ep_disable() with interrupts disabled and locks held
> considering that UDC _must_ call ->complete() for each and every
> request.
> 
> If we go ahead with this, it'll mean a rather large series (again) to
> fix all the calling semantics in every single gadget driver for both
> usb_ep_enable() and usb_ep_disable(). Then, making sure all UDC drivers
> respect the requirement, then we update documentation about the
> functions and add might_sleep() to their implementation in udc/core.c
> 
> Anybody objects to this new requirement?

The usual times for calling usb_ep_disable() is when the gadget driver 
processes an altsetting or configuration change, or a reset or 
disconnect.  The notifications for these things happen in interrupt 
context, so it doesn't seem reasonable to require that endpoints be 
disabled in process context.

f_mass_storage has its own worker thread.  Mainly for other reasons, 
but it can also use the thread to handle these events.  But it doesn't 
seem right to require all gadget drivers to do the same thing.

There is still an open question about how a gadget driver can change 
altsettings, though.  A particular endpoint might be bulk in one 
altsetting and isochronous in another, for example.  I don't see how we 
can change the endpoint's characteristics without being allowed to 
sleep.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues

[Ulf Hansson]

On 13 October 2016 at 13:37, Ulf Hansson  wrote:
> The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing
> an rtsx_usb device (managed by an mfd driver) while communicating with the
> cards. The mmc/sd and memstick devices are children of the usb device.
>
> Issues has been reported [1] for rtsx, which have been investigated, 
> discussed,
> fixed, tested, etc, particularly when using mmc/sd cards. During the
> investigation, some changes was proposed and tested successfully. In this
> series I have picked up these changes and created some proper patches with
> change-logs.
>
> It turned out that most of the problems was related to the runtime PM
> deployment in the memstick and the mmc/sd driver, which are fixed in this
> series.
>
> A couple of more issues were also discussed [2], which needs to be fixed as
> well. Although they are out of scope for this series, so we will have to look
> into those at a later point. Here's a brief summary of these leftovers:
>
> *)
> It seems reasonable to turn off autosuspend for usb devices and instead rely 
> on
> the usb device's children to deal with autosuspend. The reason is simply that
> the children has better knowledge of when using autosuspend makes sense.
>
> **)
> Polling card detect mode is used both for mmc/sd and memstick. Because of the
> lack of synchronization between the polling attempts for these subsystems, the
> usb device may be powered on for unnecessary long intervals, thus we are
> wasting power.
>
> Besides the above changes, I folded in a change in the mmc core which improves
> the behaviour for mmc hosts using MMC_CAP2_NO_PRESCAN_POWERUP, which is the
> case for the rtsx_usb_sdmmc driver.  This change should improve the boot time
> with ~100ms per rtsx_usb_sdmmc device.
>
> Finally, as I couldn't find an active maintainer for the memstick
> subsystem/driver and because the author of the drivers can be reached, I
> volunteer to take this all through my mmc tree. Please tell me if that is
> problem to any of you.
>
> [1]
> https://www.spinics.net/lists/linux-usb/msg146998.html
> [2]
> https://www.spinics.net/lists/linux-mmc/msg39235.html
>
>
> Alan Stern (1):
>   memstick: rtsx_usb_ms: Runtime resume the device when polling for
> cards
>
> Ulf Hansson (5):
>   mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when
> unused
>   mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
>   memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
>   mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend
>   mmc: core: Don't power off the card when starting the host
>
>  drivers/memstick/host/rtsx_usb_ms.c |  6 ++
>  drivers/mmc/core/core.c |  9 -
>  drivers/mmc/host/rtsx_usb_sdmmc.c   | 10 +-
>  3 files changed, 15 insertions(+), 10 deletions(-)
>
> --
> 1.9.1
>

Patch 1->4 applied for fixes. Holding patch 5->6 for a while, as they
are intended for next!

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH resend] usb: increase ohci watchdog delay to 275 msec

[David Laight]

From: Bryan Paluch
> Sent: 17 October 2016 13:55
> Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
> with 20 ms of slack, after removing slack time some ohci controllers don't
> respond in time. Logs from systems with controllers that have the
> issue would show "HcDoneHead not written back; disabled"

If the 'normal' delay is that close to the watchdog timeout
I think I'd increase the watchdog significantly.

Either that or work out why the controllers aren't responding
more quickly.

David

Re: [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4

[Masahiro Yamada]

Hi Greg,


2016-10-17 21:30 GMT+09:00 Greg Kroah-Hartman :
> On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
>> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
>> needs to handle 4 reset lines for EHCI.
>
> Why?  What makes it different from other EHCI implementations?
>
> thanks,
>
> greg k-h


This is a generic EHCI driver, but the number of clocks/resets
are SoC-specific.



The following patch you picked up will remind you something?



commit 73577d61799e8d8bb7d69a9acdc54923e5998138
Author: Icenowy Zheng 
Date:   Fri Aug 12 11:06:22 2016 +0800

ehci-platform: add the max clock number to 4

Allwinner A64 EHCI requires 4 clocks to be enabled.

Signed-off-by: Icenowy Zheng 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 






-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH resend] usb: increase ohci watchdog delay to 275 msec

[Bryan Paluch]

Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"

Signed-off-by: Bryan Paluch 
---
Reported and discussed:
https://lkml.kernel.org/r/
 drivers/usb/host/ohci-hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 1700908..86612ac 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -72,7 +72,7 @@
 static const char  hcd_name [] = "ohci_hcd";

 #defineSTATECHANGE_DELAY   msecs_to_jiffies(300)
-#defineIO_WATCHDOG_DELAY   msecs_to_jiffies(250)
+#defineIO_WATCHDOG_DELAY   msecs_to_jiffies(275)

 #include "ohci.h"
 #include "pci-quirks.h"
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: increase ohci watchdog delay to 275 msec

[Bryan Paluch]

My Apologies, I never saw my original patch hit the linux-usb mailing
list either, I suspect it may have not been all plain text. (I did not
get a rejection message though). I will resend the original to
linux-usb.

On Mon, Oct 17, 2016 at 5:49 AM, Greg KH  wrote:
> On Sun, Oct 16, 2016 at 10:54:34AM -0400, Alan Stern wrote:
>> On Sat, 15 Oct 2016, Bryan Paluch wrote:
>>
>> > Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
>> > with 20 ms of slack, after removing slack time some ohci controllers don't
>> > respond in time. Logs from systems with controllers that have the
>> > issue would show "HcDoneHead not written back; disabled"
>> >
>> > Signed-off-by: Bryan Paluch 
>> > ---
>> > Reported and discussed:
>> > https://lkml.kernel.org/r/<
>> > pine.lnx.4.44l0.1610151100250.29083-100...@netrider.rowland.org>
>> >  drivers/usb/host/ohci-hcd.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
>> > index 1700908..86612ac 100644
>> > --- a/drivers/usb/host/ohci-hcd.c
>> > +++ b/drivers/usb/host/ohci-hcd.c
>> > @@ -72,7 +72,7 @@
>> >  static const char  hcd_name [] = "ohci_hcd";
>> >
>> >  #defineSTATECHANGE_DELAY   msecs_to_jiffies(300)
>> > -#defineIO_WATCHDOG_DELAY   msecs_to_jiffies(250)
>> > +#defineIO_WATCHDOG_DELAY   msecs_to_jiffies(275)
>> >
>> >  #include "ohci.h"
>> >  #include "pci-quirks.h"
>>
>> Acked-by: Alan Stern 
>>
>> Greg, this should be marked for -stable; the problem was apparently
>> introduced between 4.7 and 4.8.
>
> Ok, I would, but I don't see this patch in my inbox anywhere, was it
> posted publicly?
>
> confused,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4

[Greg Kroah-Hartman]

On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
> needs to handle 4 reset lines for EHCI.

Why?  What makes it different from other EHCI implementations?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Felipe Balbi]

Hi,

Baolin Wang  writes:
>> Baolin Wang  writes:
>>> When we change the USB function with configfs dynamically, we possibly met 
>>> this
>>> situation: one core is doing the control transfer, another core is trying to
>>> unregister the USB gadget from userspace, we must wait for completing this
>>> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>>>
>>> Signed-off-by: Baolin Wang 
>>
>> Can you make sure this still works?
>
> With applying this patch, It can work well on my platform, but I have
> some worries about the risk of accessing 'dwc->ep0state' without lock
> protection in dwc3_gadget_pullup() function.

hmm, I might be missing something, but I think there's no risk here. If
anything, a wmb() is probably enough before reading ep0state. No?

-- 
balbi


signature.asc
Description: PGP signature

Re: [balbi-usb:testing/next 57/84] drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state'

[Felipe Balbi]

Hi,

kbuild test robot  writes:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> testing/next
> head:   4281ef86fae986e0a9bb553fb311fe6d8e039118
> commit: 040f47e7330045feaa8c06bf2900db2eb2038e80 [57/84] usb: dwc3: Kconfig: 
> allow all glues to build if COMPILE_TEST
> config: blackfin-allmodconfig (attached as .config)
> compiler: bfin-uclinux-gcc (GCC) 6.2.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 040f47e7330045feaa8c06bf2900db2eb2038e80
> # save the attached .config to linux build tree
> make.cross ARCH=blackfin 
>
> All errors (new ones prefixed by >>):
>
>drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_suspend':
>>> drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function 
>>> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
>  pinctrl_pm_select_sleep_state(dev);
>  ^
>drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_resume':
>>> drivers/usb/dwc3/dwc3-st.c:338:2: error: implicit declaration of function 
>>> 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
>  pinctrl_pm_select_default_state(dev);
>  ^~~
>cc1: some warnings being treated as errors

looks like a bug in . Something along the
lines of below should be enough:

diff --git a/include/linux/pinctrl/consumer.h b/include/linux/pinctrl/consumer.h
index d7e5d608faa7..c8aa03aa1c42 100644
--- a/include/linux/pinctrl/consumer.h
+++ b/include/linux/pinctrl/consumer.h
@@ -44,7 +44,9 @@ extern void devm_pinctrl_put(struct pinctrl *p);
 extern int pinctrl_pm_select_default_state(struct device *dev);
 extern int pinctrl_pm_select_sleep_state(struct device *dev);
 extern int pinctrl_pm_select_idle_state(struct device *dev);
-#else
+#endif
+
+#else /* !CONFIG_PINCTRL */
 static inline int pinctrl_pm_select_default_state(struct device *dev)
 {
return 0;
@@ -57,9 +59,6 @@ static inline int pinctrl_pm_select_idle_state(struct device 
*dev)
 {
return 0;
 }
-#endif
-
-#else /* !CONFIG_PINCTRL */
 
 static inline int pinctrl_request_gpio(unsigned gpio)
 {


Linus, do you want me to send this as a proper patch? It's pretty clear
that currently we can have build regressions with these helpers. Was it
a conscious choice to not provide stubs or just a slip?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Baolin Wang]

Hi,

On 17 October 2016 at 18:10, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> When we change the USB function with configfs dynamically, we possibly met 
>> this
>> situation: one core is doing the control transfer, another core is trying to
>> unregister the USB gadget from userspace, we must wait for completing this
>> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>>
>> Signed-off-by: Baolin Wang 
>
> Can you make sure this still works?

With applying this patch, It can work well on my platform, but I have
some worries about the risk of accessing 'dwc->ep0state' without lock
protection in dwc3_gadget_pullup() function.

>
> 8<
> From 797c7caab630f650b9ab5e462e8588462e055073 Mon Sep 17 00:00:00 2001
> From: Baolin Wang 
> Date: Fri, 14 Oct 2016 17:11:33 +0800
> Subject: [PATCH] usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to
>  do so
>
> When we change the USB function with configfs dynamically, we possibly
> met this situation: one core is doing the control transfer, another core
> is trying to unregister the USB gadget from userspace, we must wait for
> completing this control tranfer, or it will hang the controller to set
> the DEVCTRLHLT flag.
>
> [ felipe.ba...@linux.intel.com: several fixes to the patch
> - call complete() before starting following SETUP transfer
> - add a macro for ep0_in_setup's timeout
> - change commit subject slightly
> - break lines at 72 characters (git adds an 8-character tab)
> - avoid changes to dwc3_gadget_run_stop() ]
>
> Signed-off-by: Baolin Wang 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/core.h   |  3 +++
>  drivers/usb/dwc3/ep0.c|  2 ++
>  drivers/usb/dwc3/gadget.c | 17 +
>  3 files changed, 22 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 2f6f7c4bc8d4..80e4e9aa2d33 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -38,6 +38,7 @@
>  #define DWC3_MSG_MAX   500
>
>  /* Global constants */
> +#define DWC3_PULL_UP_TIMEOUT   500 /* ms */
>  #define DWC3_ZLP_BUF_SIZE  1024/* size of a superspeed bulk */
>  #define DWC3_EP0_BOUNCE_SIZE   512
>  #define DWC3_ENDPOINTS_NUM 32
> @@ -756,6 +757,7 @@ struct dwc3_scratchpad_array {
>   * @ep0_usb_req: dummy req used while handling STD USB requests
>   * @ep0_bounce_addr: dma address of ep0_bounce
>   * @scratch_addr: dma address of scratchbuf
> + * @ep0_in_setup: one control transfer is completed and enter setup phase
>   * @lock: for synchronizing
>   * @dev: pointer to our struct device
>   * @xhci: pointer to our xHCI child
> @@ -853,6 +855,7 @@ struct dwc3 {
> dma_addr_t  ep0_bounce_addr;
> dma_addr_t  scratch_addr;
> struct dwc3_request ep0_usb_req;
> +   struct completion   ep0_in_setup;
>
> /* device lock */
> spinlock_t  lock;
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 5e642d65a3b2..417cfd3f04ab 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -284,6 +284,8 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
>  {
> int ret;
>
> +   complete(>ep0_in_setup);
> +
> ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
> DWC3_TRBCTL_CONTROL_SETUP, false);
> WARN_ON(ret < 0);
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index b53712cbc499..da79716be50d 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1557,6 +1557,21 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
> int is_on)
>
> is_on = !!is_on;
>
> +   /*
> +* Per databook, when we want to stop the gadget, if a control 
> transfer
> +* is still in process, complete it and get the core into setup phase.
> +*/
> +   if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
> +   reinit_completion(>ep0_in_setup);
> +
> +   ret = wait_for_completion_timeout(>ep0_in_setup,
> +   msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
> +   if (ret == 0) {
> +   dev_err(dwc->dev, "timed out waiting for SETUP 
> phase\n");
> +   return -ETIMEDOUT;
> +   }
> +   }
> +
> spin_lock_irqsave(>lock, flags);
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
> spin_unlock_irqrestore(>lock, flags);
> @@ -2954,6 +2969,8 @@ int dwc3_gadget_init(struct dwc3 *dwc)
> goto err4;
> }
>
> +   init_completion(>ep0_in_setup);
> +
> dwc->gadget.ops = _gadget_ops;
> dwc->gadget.speed 

[balbi-usb:testing/next 57/84] drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
testing/next
head:   4281ef86fae986e0a9bb553fb311fe6d8e039118
commit: 040f47e7330045feaa8c06bf2900db2eb2038e80 [57/84] usb: dwc3: Kconfig: 
allow all glues to build if COMPILE_TEST
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 040f47e7330045feaa8c06bf2900db2eb2038e80
# save the attached .config to linux build tree
make.cross ARCH=blackfin 

All errors (new ones prefixed by >>):

   drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_suspend':
>> drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function 
>> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration]
 pinctrl_pm_select_sleep_state(dev);
 ^
   drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_resume':
>> drivers/usb/dwc3/dwc3-st.c:338:2: error: implicit declaration of function 
>> 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration]
 pinctrl_pm_select_default_state(dev);
 ^~~
   cc1: some warnings being treated as errors

vim +/pinctrl_pm_select_sleep_state +328 drivers/usb/dwc3/dwc3-st.c

f83fca07 Peter Griffin 2014-09-05  322  {
f83fca07 Peter Griffin 2014-09-05  323  struct st_dwc3 *dwc3_data = 
dev_get_drvdata(dev);
f83fca07 Peter Griffin 2014-09-05  324  
f83fca07 Peter Griffin 2014-09-05  325  
reset_control_assert(dwc3_data->rstc_pwrdn);
f83fca07 Peter Griffin 2014-09-05  326  
reset_control_assert(dwc3_data->rstc_rst);
f83fca07 Peter Griffin 2014-09-05  327  
f83fca07 Peter Griffin 2014-09-05 @328  
pinctrl_pm_select_sleep_state(dev);
f83fca07 Peter Griffin 2014-09-05  329  
f83fca07 Peter Griffin 2014-09-05  330  return 0;
f83fca07 Peter Griffin 2014-09-05  331  }
f83fca07 Peter Griffin 2014-09-05  332  
f83fca07 Peter Griffin 2014-09-05  333  static int st_dwc3_resume(struct device 
*dev)
f83fca07 Peter Griffin 2014-09-05  334  {
f83fca07 Peter Griffin 2014-09-05  335  struct st_dwc3 *dwc3_data = 
dev_get_drvdata(dev);
f83fca07 Peter Griffin 2014-09-05  336  int ret;
f83fca07 Peter Griffin 2014-09-05  337  
f83fca07 Peter Griffin 2014-09-05 @338  
pinctrl_pm_select_default_state(dev);
f83fca07 Peter Griffin 2014-09-05  339  
f83fca07 Peter Griffin 2014-09-05  340  
reset_control_deassert(dwc3_data->rstc_pwrdn);
f83fca07 Peter Griffin 2014-09-05  341  
reset_control_deassert(dwc3_data->rstc_rst);

:: The code at line 328 was first introduced by commit
:: f83fca0707c66e36f14efef7f68702cb12de70b7 usb: dwc3: add ST dwc3 glue 
layer to manage dwc3 HC

:: TO: Peter Griffin 
:: CC: Felipe Balbi 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4

[Masahiro Yamada]

Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
needs to handle 4 reset lines for EHCI.

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/host/ehci-platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 876dca4..a268d9e 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -39,7 +39,7 @@
 
 #define DRIVER_DESC "EHCI generic platform driver"
 #define EHCI_MAX_CLKS 4
-#define EHCI_MAX_RSTS 3
+#define EHCI_MAX_RSTS 4
 #define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
 
 struct ehci_platform_priv {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] usb: gadgetfs: introduce feature control mechanism

[Felipe Balbi]

Hi,

Binyamin Sharet  writes:
> On 09/12/2016 04:11 PM, Alan Stern wrote:
>> On Mon, 12 Sep 2016, Binyamin Sharet (bsharet) wrote:
>>
 On 8 Sep 2016, at 23:24, Alan Stern  wrote:

 On Thu, 8 Sep 2016, Binyamin Sharet (bsharet) wrote:

>> On 8 Sep 2016, at 22:20, Alan Stern  wrote:
>>
>> On Thu, 8 Sep 2016, Binyamin Sharet (bsharet) wrote:
>>
 I was thinking more like:

 struct usb_gadgetfs_ioctl_arg {
uint16_t length;
uint8_t reserved[2];

uint8_t data[0];
 }

 but the principle is pretty much the same.

 Alan Stern

>>> Won’t the user lose the relevant information (e.g. feature
>>> structure) by using this model?
>> What feature structure?  Aren't your feature lists just vectors of 64 
>> bits?  They can be stored in the .data field above.
>>
>> Alan Stern
>>
> Not “just” - they are platform-dependant uint64_t. which means they
> won’t look the same on systems with different endianness. If the
> user is unaware of this, it can cause confusion w/r/t which bit is which.
>
> We can use 8-bit vectors instead and skip the endianness issue,
> but why define a generic usb_gadgetfs_ioctl_args structure instead
> of “features struct” for feature-related ioctls and different structs for
> other types of ioctl (if we’ll have such in the future)?
 Good point.  Yes, you can have different interfaces for different 
 ioctls.

 This whole question arose because I complained that the features API
 looked too extravagant, and Felipe said that he didn't want to run out
 of available fields in case any features in the future need them.

 But if you're worried about that, why limit yourself to 64 features and 
 24 bytes of extra data?  It doesn't make sense to think that some fixed 
 limit might end up being too small, but then restrict yourself to a 
 different fixed limit.

 Alan Stern
>>> What about changing the ioctl API for the “features” handling, and instead
>>> of passing an entire bitmap from user to kernel and vice versa, the user
>>> will only operate on a single feature (by feature id)?
>>>
>>> This way we’ll have a much simpler (and intuitive) API with the user -
>>> is_feature_supported(u64), is_feature_enabled(u64), enable_feature(u64)
>>> and disabled_feature(u64).
>>>
>>> So the internal representation of the supported/enabled features will not
>>> matter much to the user.
>> That's fine with me.  But since you're passing feature ID numbers to
>> the kernel, instead of feature bitmaps, the argument type should be
>> plain int, not u64.  Unless you think somebody will implement more than 
>> 2 billion features...  :-)
>>
>> Alan Stern
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Felipe - is it OK with you?

sounds good to me, yes :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4] usb: dwc3: Wait for control tranfer completed when stopping gadget

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> When we change the USB function with configfs dynamically, we possibly met 
> this
> situation: one core is doing the control transfer, another core is trying to
> unregister the USB gadget from userspace, we must wait for completing this
> control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
>
> Signed-off-by: Baolin Wang 

Can you make sure this still works?

8<
From 797c7caab630f650b9ab5e462e8588462e055073 Mon Sep 17 00:00:00 2001
From: Baolin Wang 
Date: Fri, 14 Oct 2016 17:11:33 +0800
Subject: [PATCH] usb: dwc3: gadget: don't clear RUN/STOP when it's invalid to
 do so

When we change the USB function with configfs dynamically, we possibly
met this situation: one core is doing the control transfer, another core
is trying to unregister the USB gadget from userspace, we must wait for
completing this control tranfer, or it will hang the controller to set
the DEVCTRLHLT flag.

[ felipe.ba...@linux.intel.com: several fixes to the patch
- call complete() before starting following SETUP transfer
- add a macro for ep0_in_setup's timeout
- change commit subject slightly
- break lines at 72 characters (git adds an 8-character tab)
- avoid changes to dwc3_gadget_run_stop() ]

Signed-off-by: Baolin Wang 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h   |  3 +++
 drivers/usb/dwc3/ep0.c|  2 ++
 drivers/usb/dwc3/gadget.c | 17 +
 3 files changed, 22 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f6f7c4bc8d4..80e4e9aa2d33 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -38,6 +38,7 @@
 #define DWC3_MSG_MAX   500
 
 /* Global constants */
+#define DWC3_PULL_UP_TIMEOUT   500 /* ms */
 #define DWC3_ZLP_BUF_SIZE  1024/* size of a superspeed bulk */
 #define DWC3_EP0_BOUNCE_SIZE   512
 #define DWC3_ENDPOINTS_NUM 32
@@ -756,6 +757,7 @@ struct dwc3_scratchpad_array {
  * @ep0_usb_req: dummy req used while handling STD USB requests
  * @ep0_bounce_addr: dma address of ep0_bounce
  * @scratch_addr: dma address of scratchbuf
+ * @ep0_in_setup: one control transfer is completed and enter setup phase
  * @lock: for synchronizing
  * @dev: pointer to our struct device
  * @xhci: pointer to our xHCI child
@@ -853,6 +855,7 @@ struct dwc3 {
dma_addr_t  ep0_bounce_addr;
dma_addr_t  scratch_addr;
struct dwc3_request ep0_usb_req;
+   struct completion   ep0_in_setup;
 
/* device lock */
spinlock_t  lock;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 5e642d65a3b2..417cfd3f04ab 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -284,6 +284,8 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
 {
int ret;
 
+   complete(>ep0_in_setup);
+
ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret < 0);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index b53712cbc499..da79716be50d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1557,6 +1557,21 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int 
is_on)
 
is_on = !!is_on;
 
+   /*
+* Per databook, when we want to stop the gadget, if a control transfer
+* is still in process, complete it and get the core into setup phase.
+*/
+   if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
+   reinit_completion(>ep0_in_setup);
+
+   ret = wait_for_completion_timeout(>ep0_in_setup,
+   msecs_to_jiffies(DWC3_PULL_UP_TIMEOUT));
+   if (ret == 0) {
+   dev_err(dwc->dev, "timed out waiting for SETUP 
phase\n");
+   return -ETIMEDOUT;
+   }
+   }
+
spin_lock_irqsave(>lock, flags);
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(>lock, flags);
@@ -2954,6 +2969,8 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err4;
}
 
+   init_completion(>ep0_in_setup);
+
dwc->gadget.ops = _gadget_ops;
dwc->gadget.speed   = USB_SPEED_UNKNOWN;
dwc->gadget.sg_supported= true;
-- 
2.10.0.440.g21f862b



-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: increase ohci watchdog delay to 275 msec

[Greg KH]

On Sun, Oct 16, 2016 at 10:54:34AM -0400, Alan Stern wrote:
> On Sat, 15 Oct 2016, Bryan Paluch wrote:
> 
> > Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
> > with 20 ms of slack, after removing slack time some ohci controllers don't
> > respond in time. Logs from systems with controllers that have the
> > issue would show "HcDoneHead not written back; disabled"
> > 
> > Signed-off-by: Bryan Paluch 
> > ---
> > Reported and discussed:
> > https://lkml.kernel.org/r/<
> > pine.lnx.4.44l0.1610151100250.29083-100...@netrider.rowland.org>
> >  drivers/usb/host/ohci-hcd.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> > index 1700908..86612ac 100644
> > --- a/drivers/usb/host/ohci-hcd.c
> > +++ b/drivers/usb/host/ohci-hcd.c
> > @@ -72,7 +72,7 @@
> >  static const char  hcd_name [] = "ohci_hcd";
> > 
> >  #defineSTATECHANGE_DELAY   msecs_to_jiffies(300)
> > -#defineIO_WATCHDOG_DELAY   msecs_to_jiffies(250)
> > +#defineIO_WATCHDOG_DELAY   msecs_to_jiffies(275)
> > 
> >  #include "ohci.h"
> >  #include "pci-quirks.h"
> 
> Acked-by: Alan Stern 
> 
> Greg, this should be marked for -stable; the problem was apparently
> introduced between 4.7 and 4.8.

Ok, I would, but I don't see this patch in my inbox anywhere, was it
posted publicly?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb_ep_{dis,en}able() calling context (was: Re: [PATCH 2/3] usb: dwc3: gadget: wait for End Transfer to complete)

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Mon, Oct 17, 2016 at 11:06:49AM +0300, Felipe Balbi wrote:
>> 
>> Hi Baolin,
>> 
>> Baolin Wang  writes:
>> >> Felipe Balbi  writes:
>> >>> Instead of just delaying for 100us, we should
>> >>> actually wait for End Transfer Command Complete
>> >>> interrupt before moving on. Note that this should
>> >>> only be done if we're dealing with one of the core
>> >>> revisions that actually require the interrupt before
>> >>> moving on.
>> >>>
>> >>> Reported-by: Baolin Wang 
>> >>> Signed-off-by: Felipe Balbi 
>> >>
>> >> I've updated this one in order to fix the comment we had about delaying
>> >> 100us. No further changes were made, only the comment. Here it is:
>> >>
>> >> 8<
>> >> From f3fa94f3171709f787a30e3c5ce69a668960b66e Mon Sep 17 00:00:00 2001
>> >> From: Felipe Balbi 
>> >> Date: Thu, 13 Oct 2016 14:09:47 +0300
>> >> Subject: [PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete
>> >>
>> >> Instead of just delaying for 100us, we should
>> >> actually wait for End Transfer Command Complete
>> >> interrupt before moving on. Note that this should
>> >> only be done if we're dealing with one of the core
>> >> revisions that actually require the interrupt before
>> >> moving on.
>> >>
>> >> Reported-by: Baolin Wang 
>> >> Signed-off-by: Felipe Balbi 
>> >
>> > From my testing, there are still some problems caused by the nested
>> > lock, at lease I found 2 functions will issue the usb_ep_disable()
>> > function with spinlock:
>> 
>> Thanks for testing. Seems like I really need to revisit locking in the
>> entire gadget API. In either case, we need to have a larger discussion
>> about this situation.
>> 
>> IMO, usb_ep_disable() and usb_ep_enable() should only be callable from
>> process context, but that has never been a requirement before. Still,
>> it's not far-fetched to assume that a controller (such as dwc3, but
>> probably others) might sleep while cancelling a transfer because they
>> need to wait for an Interrupt.
>> 
>> In fact, we know of two controllers that need this: dwc3 and dwc3.1.
>> 
>> I wonder if there are any other controllers with this
>> requirement. Either way, We should also consider if there are any strong
>> reasons to call usb_ep_disable() with interrupts disabled and locks held
>> considering that UDC _must_ call ->complete() for each and every
>> request.
>> 
>> If we go ahead with this, it'll mean a rather large series (again) to
>> fix all the calling semantics in every single gadget driver for both
>> usb_ep_enable() and usb_ep_disable(). Then, making sure all UDC drivers
>> respect the requirement, then we update documentation about the
>> functions and add might_sleep() to their implementation in udc/core.c
>> 
>> Anybody objects to this new requirement?
>> 
>
> At chipidea driver, it might call usb_ep_disable at interrupt context,
> eg, the bus reset interrupt. See chipidea/udc.c isr_reset_handler->
> _gadget_stop_activity->usb_ep_disable.

That implementation is wrong. You should tell the gadget driver that
reset happened by calling usb_gadget_udc_reset(). It's just that
usb_gadget_udc_reset() would also need to be called with IRQs enabled
after this rework happens.

-- 
balbi


signature.asc
Description: PGP signature

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Vivek Gautam]

On 10/17/2016 01:38 PM, Felipe Balbi wrote:

Hi,

Michael Niewöhner  writes:

Hi Felipe,
On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote:

Hi Felipe,

On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:

Hi,

Michael Niewöhner  writes:

The clocks are same across working/non-working.
Is it possible to bisect the commit that's causing hang for 4.8x ?


[c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor init and 
exit paths
This patch causes both the hang on reboot and the lsusb hang.

How to reproduce? Why don't we see this on x86 and TI boards? I'm
guessing this is failed bisection, as I can't see anything in that
commit that would cause reboot hang. Also, that code path is *NOT*
executed when you run lsusb.


I've tested this procedure multiple times to be sure:

- checkout c499ff71, compile, boot the odroid
- run lsusb -v => lsusb hangs, can't terminate with ctrl-c
- hard reset, after boot run poweroff or reboot => board does not completely 
power off / reboot (see log below)
- revert c499ff71, mrproper, compile, boot the odroid
- run lsusb -v => shows full output, not hanging
- run reboot or poweroff => board powers off / reboots just fine


dmesg poweroff not working:
...
[  120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
[  120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[  120.769212] systemd-shutdown[1]: Unmounting file systems.
[  120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
[  120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.
[  121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.101014] systemd-shutdown[1]: All filesystems unmounted.
[  121.106523] systemd-shutdown[1]: Deactivating swaps.
[  121.111585] systemd-shutdown[1]: All swaps deactivated.
[  121.116661] systemd-shutdown[1]: Detaching loop devices.
[  121.126395] systemd-shutdown[1]: All loop devices detached.
[  121.130525] systemd-shutdown[1]: Detaching DM devices.
[  121.135824] systemd-shutdown[1]: All DM devices detached.
[  121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.
[  121.171739] systemd-shutdown[1]: Powering off.

=> at this point removing the sd card would show a message
"removed mmc0" (not sure what the real message was...) so the board is not 
completely off.


dmesg poweroff working:
...
[  120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
[  120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[  120.769212] systemd-shutdown[1]: Unmounting file systems.
[  120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
[  120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.
[  121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[  121.101014] systemd-shutdown[1]: All filesystems unmounted.
[  121.106523] systemd-shutdown[1]: Deactivating swaps.
[  121.111585] systemd-shutdown[1]: All swaps deactivated.
[  121.116661] systemd-shutdown[1]: Detaching loop devices.
[  121.126395] systemd-shutdown[1]: All loop devices detached.
[  121.130525] systemd-shutdown[1]: Detaching DM devices.
[  121.135824] systemd-shutdown[1]: All DM devices detached.
[  121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.
[  121.171739] systemd-shutdown[1]: Powering off.
[  121.182331] rebo�



Best regards
Michael Niewöhner


I did some more tests with next-20161016. Reverting / commenting out
one part of your patch "solves" the lsusb hang, the reboot problem
and also the "debounce failed" message. [1]
Another "solution" is to call phy_power_off before phy_power_on. [2]

Disclaimer: I have no idea what I was doing ;-) These were just some
simple trial-and-error attempts that maybe help to find the real
cause of the problems.

[1]
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7287a76..5ef589d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -724,6 +724,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* Adjust Frame Length */
dwc3_frame_length_adjustment(dwc);
  
+/*

usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
@@ -733,6 +734,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
ret = phy_power_on(dwc->usb3_generic_phy);
if (ret < 0)
goto err3;
+*/
  
  	ret = dwc3_event_buffers_setup(dwc);

if (ret) {

[2]
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 7287a76..f6c8e13 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -726,6 +726,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
  
 

Re: usb_ep_{dis,en}able() calling context (was: Re: [PATCH 2/3] usb: dwc3: gadget: wait for End Transfer to complete)

[Peter Chen]

On Mon, Oct 17, 2016 at 11:06:49AM +0300, Felipe Balbi wrote:
> 
> Hi Baolin,
> 
> Baolin Wang  writes:
> >> Felipe Balbi  writes:
> >>> Instead of just delaying for 100us, we should
> >>> actually wait for End Transfer Command Complete
> >>> interrupt before moving on. Note that this should
> >>> only be done if we're dealing with one of the core
> >>> revisions that actually require the interrupt before
> >>> moving on.
> >>>
> >>> Reported-by: Baolin Wang 
> >>> Signed-off-by: Felipe Balbi 
> >>
> >> I've updated this one in order to fix the comment we had about delaying
> >> 100us. No further changes were made, only the comment. Here it is:
> >>
> >> 8<
> >> From f3fa94f3171709f787a30e3c5ce69a668960b66e Mon Sep 17 00:00:00 2001
> >> From: Felipe Balbi 
> >> Date: Thu, 13 Oct 2016 14:09:47 +0300
> >> Subject: [PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete
> >>
> >> Instead of just delaying for 100us, we should
> >> actually wait for End Transfer Command Complete
> >> interrupt before moving on. Note that this should
> >> only be done if we're dealing with one of the core
> >> revisions that actually require the interrupt before
> >> moving on.
> >>
> >> Reported-by: Baolin Wang 
> >> Signed-off-by: Felipe Balbi 
> >
> > From my testing, there are still some problems caused by the nested
> > lock, at lease I found 2 functions will issue the usb_ep_disable()
> > function with spinlock:
> 
> Thanks for testing. Seems like I really need to revisit locking in the
> entire gadget API. In either case, we need to have a larger discussion
> about this situation.
> 
> IMO, usb_ep_disable() and usb_ep_enable() should only be callable from
> process context, but that has never been a requirement before. Still,
> it's not far-fetched to assume that a controller (such as dwc3, but
> probably others) might sleep while cancelling a transfer because they
> need to wait for an Interrupt.
> 
> In fact, we know of two controllers that need this: dwc3 and dwc3.1.
> 
> I wonder if there are any other controllers with this
> requirement. Either way, We should also consider if there are any strong
> reasons to call usb_ep_disable() with interrupts disabled and locks held
> considering that UDC _must_ call ->complete() for each and every
> request.
> 
> If we go ahead with this, it'll mean a rather large series (again) to
> fix all the calling semantics in every single gadget driver for both
> usb_ep_enable() and usb_ep_disable(). Then, making sure all UDC drivers
> respect the requirement, then we update documentation about the
> functions and add might_sleep() to their implementation in udc/core.c
> 
> Anybody objects to this new requirement?
> 

At chipidea driver, it might call usb_ep_disable at interrupt context,
eg, the bus reset interrupt. See chipidea/udc.c isr_reset_handler->
_gadget_stop_activity->usb_ep_disable.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2]usb: dwc2: Clear GUSBCFG.UsbTrdTim before setting

[Felipe Balbi]

Hi,

Pengcheng Li  writes:
> The USBTRDTIM field needs to be cleared before setting a new value.
> Otherwise it will result in an incorrect value if phyif == GUSBCFG_PHYIF8.
>
> Change-Id: Ib3e33cf4fd15ada41dc070ff7b93858daafbd10f
> Signed-off-by: Pengcheng Li 
> Acked-by: John Youn 

which commit are you fixing? Seems like you're missing a:

Fixes: foobar 

line here. Also, you need to remove Gerritisms from commit log ;-)

-- 
balbi


signature.asc
Description: PGP signature

RE: USB GADGET: have a question about usb2eth

[Felipe Balbi]

Hi,

(please, avoid top-posting: http://daringfireball.net/2007/07/on_top)

Lipengcheng  writes:
> Hi,
>   thank you for your suggestion.
>
>   I have a question about usb2eth. In the function gen_ndis_set_resp
> of the rndis.c, the value of *params->filter may be 0x20 from the
> pc set command; Howerver the value is used cdc_filter = 
> dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c.
> If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is
> 0x20, the broadcast packet can not send the pc win7; At the result, 
> the linux ping the win7 is slow an the first. At the same time, Why are 
> different value between RNDIS_PACKET_TYPE_PROMISCUOUS and
> USB_CDC_PACKET_TYPE_PROMISCUOUS? If the value of RNDIS_PACKET_TYPE_PROMISCUOUS

because they are defined by different specifications. You should read
both CDC specification from USB.org and RNDIS spec from Microsoft to
understand the details of that.

> and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the win7 is
> normal speed.

I don't understand what's going on here. Care to describe which kernel
you're using, which USB peripheral controller, what is the actual
problem you're trying to solve?

-- 
balbi


signature.asc
Description: PGP signature

Re: USB crash on BeagleBoard-xM

[Oliver Neukum]

On Fri, 2016-10-14 at 01:16 +0100, Snaper wrote:
> Hi Oliver,
> 
> On 10/10/2016 08:19, Oliver Neukum wrote:
> > it is very hard for us to say something about that specific kernel.
> > We don't know the kernel tree. And the error seems to be in the OF
> > code. I think you are in the wrong list, or can you reproduce
> > teh problem with a mainline kernel?
> 
> I have reported this in 
> https://bugzilla.kernel.org/show_bug.cgi?id=169291 and have followed the 
> advice given by Greg there, to report to this ML.
> 
> I'm not using this kernel any longer (I created the micro-SD card with 
> the OS for this machine with another image), so if this is of no use for 
> the developers, it can be closed.

Then please close it. The report is definitely not enough
to fix the issue.

Sorry
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Problem with musb dma packet

[Andrew Goodbody]

> From: Bin Liu [mailto:b-...@ti.com]
> On Thu, Oct 06, 2016 at 02:45:30PM +, Andrew Goodbody wrote:
> > I am trying to investigate an issue on a TI Sitara CPU, AM3352 with
> > the musb USB controller.
> >
> > The scenario is that a device has been in use and working correctly.
> > The device is an Android device and is presenting as an MTP device.
> 
> AM3352 musb is the host or device? Sounds like it is the host.

Yes, musb is the host.

> > That first session of use is finished and the port is reset but the
> > device is not unplugged, so enumeration and configuration starts again
> 
> How this happened? How do you control the host reset the device but not
> re-enumerate it?

Not what I said. The device is of course re-enumerated after the reset. There 
can be multiple sessions of use of the device, but these multiple sessions 
occur without unplugging. Each session starts with a reset and continues as 
normal from there, but with the Android MTP devices only the first session is 
successful.

> > the next time it is needed. The transfers over EP0 using PIO all
> > proceed as expected. The problem is the first bulk packet sent to EP1,
> > which also happens to be the first dma packet. USBMON shows this
> > packet as being sent. However a hardware analyser does not show this
> > packet on the wire and of course there is no ACK either. Looking at
> > the debug info from the musb driver I can see the dma being started
> > and then the callback being called. MUSB_TXCSR_TXPKTRDY remains set as
> > does MUSB_TXCSR_TXFIFONOTEMPTY so nothing else happens. The TXCSR
> > register is 0x3403. The code is waiting for MUSB_TXCSR_TXPKTRDY to be
> > cleared but that will not happen until an ACK is received. It just
> > seems that the controller is not putting the packet onto the wire for
> > some reason.
> 
> Sounds to me that the cppi teamdown before/during bus reset was not
> complete, so the channels are not in the ready state for next transfers.
> 
> I don't have a better way to debug it, but you have to ensure the teardown
> sequence does follow that in the normal device detach. If the issue still
> happens, you would have to dump the cppi registers to see why the
> channels are in the wrong state.
> 
> >
> > This is on 4.5.1.
> >
> > I would welcome some pointers on how to proceed to debug this or else
> > any information on possible applicable errata and workarounds for
> > this.
> 
> It is more like software problem to me.
> 
> Good luck.
> 
> Regards,
> -Bin.
> 
> >
> > Thanks,
> > Andrew

OK, I did some more digging on this. Firstly I found it also happens in PIO 
mode. I then put another hub in the chain. This time I see the packet on the 
wire between the hubs. The packet however never leaves the downstream hub to 
get to the device. So it looks like the device is somehow blocking the bus and 
preventing the packet being sent. As this can be caused by multiple different 
devices, although all Android MTP, and it can also be seen with a RasPi host, 
the fault looks to be in the Android MTP stack not expecting to be restarted 
without a complete unplug.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Felipe Balbi]

Hi,

Michael Niewöhner  writes:
> Hi Felipe,
> On Fri, 2016-10-07 at 22:26 +0200, Michael Niewöhner wrote:
>> Hi Felipe,
>> 
>> On Fr, 2016-10-07 at 10:42 +0300, Felipe Balbi wrote:
>> > Hi,
>> > 
>> > Michael Niewöhner  writes:
>> > > 
>> > > > 
>> > > > The clocks are same across working/non-working.
>> > > > Is it possible to bisect the commit that's causing hang for 4.8x ?
>> > > 
>> > > 
>> > > [c499ff71ff2a281366c6ec7a904c547d806cbcd1] usb: dwc3: core: re-factor 
>> > > init and exit paths
>> > > This patch causes both the hang on reboot and the lsusb hang.
>> > 
>> > How to reproduce? Why don't we see this on x86 and TI boards? I'm
>> > guessing this is failed bisection, as I can't see anything in that
>> > commit that would cause reboot hang. Also, that code path is *NOT*
>> > executed when you run lsusb.
>> > 
>> 
>> I've tested this procedure multiple times to be sure:
>> 
>> - checkout c499ff71, compile, boot the odroid
>> - run lsusb -v => lsusb hangs, can't terminate with ctrl-c
>> - hard reset, after boot run poweroff or reboot => board does not completely 
>> power off / reboot (see log below)
>> - revert c499ff71, mrproper, compile, boot the odroid
>> - run lsusb -v => shows full output, not hanging
>> - run reboot or poweroff => board powers off / reboots just fine
>> 
>> 
>> dmesg poweroff not working:
>> ...
>> [  120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
>>    
>> [  120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining 
>> processes...   
>> [  120.769212] systemd-shutdown[1]: Unmounting file systems. 
>>    
>> [  120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
>>    
>> [  120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.  
>>    
>> [  121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) 
>>    
>> [  121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) 
>>    
>> [  121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) 
>>    
>> [  121.101014] systemd-shutdown[1]: All filesystems unmounted.   
>>    
>> [  121.106523] systemd-shutdown[1]: Deactivating swaps.  
>>    
>> [  121.111585] systemd-shutdown[1]: All swaps deactivated.   
>>    
>> [  121.116661] systemd-shutdown[1]: Detaching loop devices.  
>>    
>> [  121.126395] systemd-shutdown[1]: All loop devices detached.   
>>    
>> [  121.130525] systemd-shutdown[1]: Detaching DM devices.
>>    
>> [  121.135824] systemd-shutdown[1]: All DM devices detached. 
>>    
>> [  121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.  
>>    
>> [  121.171739] systemd-shutdown[1]: Powering off.
>> 
>> => at this point removing the sd card would show a message 
>> "removed mmc0" (not sure what the real message was...) so the board is not 
>> completely off.
>> 
>> 
>> dmesg poweroff working:
>> ...
>> [  120.733519] systemd-journald[144]: systemd-journald stopped as pid 144
>>    
>> [  120.742663] systemd-shutdown[1]: Sending SIGKILL to remaining 
>> processes...   
>> [  120.769212] systemd-shutdown[1]: Unmounting file systems. 
>>    
>> [  120.773713] systemd-shutdown[1]: Unmounting /sys/kernel/debug.
>>    
>> [  120.827211] systemd-shutdown[1]: Unmounting /dev/mqueue.  
>>    
>> [  121.081672] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) 
>>    
>> [  121.091687] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) 
>>    
>> [  121.095608] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) 
>>    
>> [  121.101014] systemd-shutdown[1]: All filesystems unmounted.   
>>    
>> [  121.106523] systemd-shutdown[1]: Deactivating swaps.  
>>    
>> [  121.111585] systemd-shutdown[1]: All swaps deactivated.   
>>    
>> [  121.116661] systemd-shutdown[1]: Detaching loop devices.  
>>    
>> [  121.126395] systemd-shutdown[1]: All loop devices detached.   
>>    
>> [  121.130525] systemd-shutdown[1]: Detaching DM devices.
>>    
>> [  121.135824] systemd-shutdown[1]: All DM devices detached. 
>>    
>> [  121.166327] systemd-shutdown[1]: /lib/systemd/system-shutdown succeeded.  
>>    
>> [  121.171739] systemd-shutdown[1]: Powering off.
>> [  121.182331] rebo�
>> 
>> 
>> 
>> Best regards
>> Michael Niewöhner
>
>
> I did some more tests with next-20161016. Reverting / commenting out
> one part of your patch "solves" the lsusb hang, the reboot problem
> and also the "debounce failed" message. [1]
> Another "solution" is to call phy_power_off before phy_power_on. [2]
>
> Disclaimer: I have no idea what I was doing ;-) These were just some
> simple trial-and-error attempts that maybe help to find the real
> 

usb_ep_{dis,en}able() calling context (was: Re: [PATCH 2/3] usb: dwc3: gadget: wait for End Transfer to complete)

[Felipe Balbi]

Hi Baolin,

Baolin Wang  writes:
>> Felipe Balbi  writes:
>>> Instead of just delaying for 100us, we should
>>> actually wait for End Transfer Command Complete
>>> interrupt before moving on. Note that this should
>>> only be done if we're dealing with one of the core
>>> revisions that actually require the interrupt before
>>> moving on.
>>>
>>> Reported-by: Baolin Wang 
>>> Signed-off-by: Felipe Balbi 
>>
>> I've updated this one in order to fix the comment we had about delaying
>> 100us. No further changes were made, only the comment. Here it is:
>>
>> 8<
>> From f3fa94f3171709f787a30e3c5ce69a668960b66e Mon Sep 17 00:00:00 2001
>> From: Felipe Balbi 
>> Date: Thu, 13 Oct 2016 14:09:47 +0300
>> Subject: [PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete
>>
>> Instead of just delaying for 100us, we should
>> actually wait for End Transfer Command Complete
>> interrupt before moving on. Note that this should
>> only be done if we're dealing with one of the core
>> revisions that actually require the interrupt before
>> moving on.
>>
>> Reported-by: Baolin Wang 
>> Signed-off-by: Felipe Balbi 
>
> From my testing, there are still some problems caused by the nested
> lock, at lease I found 2 functions will issue the usb_ep_disable()
> function with spinlock:

Thanks for testing. Seems like I really need to revisit locking in the
entire gadget API. In either case, we need to have a larger discussion
about this situation.

IMO, usb_ep_disable() and usb_ep_enable() should only be callable from
process context, but that has never been a requirement before. Still,
it's not far-fetched to assume that a controller (such as dwc3, but
probably others) might sleep while cancelling a transfer because they
need to wait for an Interrupt.

In fact, we know of two controllers that need this: dwc3 and dwc3.1.

I wonder if there are any other controllers with this
requirement. Either way, We should also consider if there are any strong
reasons to call usb_ep_disable() with interrupts disabled and locks held
considering that UDC _must_ call ->complete() for each and every
request.

If we go ahead with this, it'll mean a rather large series (again) to
fix all the calling semantics in every single gadget driver for both
usb_ep_enable() and usb_ep_disable(). Then, making sure all UDC drivers
respect the requirement, then we update documentation about the
functions and add might_sleep() to their implementation in udc/core.c

Anybody objects to this new requirement?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: dwc3: gadget: Wait for end transfer complete before free irq

[Felipe Balbi]

Hi,

(I have added you to another thread which is where we'll be collecting
discussion about this, however ...)

Alan Stern  writes:
> On Fri, 14 Oct 2016, Felipe Balbi wrote:
>
>> argh, we have nested spinlocks :-( Well, we shouldn't call
>> usb_ep_disable() with locks held AFAICR. So the following should be
>> enough:
>> 
>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>> index 919d7d1b611c..2e9359c58eb9 100644
>> --- a/drivers/usb/gadget/composite.c
>> +++ b/drivers/usb/gadget/composite.c
>> @@ -732,8 +732,10 @@ static void reset_config(struct usb_composite_dev *cdev)
>> DBG(cdev, "reset config\n");
>>  
>> list_for_each_entry(f, >config->functions, list) {
>> +   spin_unlock_irq(>lock);
>> if (f->disable)
>> f->disable(f);
>> +   spin_lock_irq(>lock);
>>  
>> bitmap_zero(f->endpoints, 32);
>> }
>> 
>> Alan, do you remember if we have a requirement for not holding locks
>> when calling usb_ep_disable()? I can't find Documentation about it, but
>> history shows me that usb_ep_disable() was called without locks and IRQs
>> enabled. Do you think we should update documentation about this?
>
> I don't think there is any requirement for interrupts to be enabled 
> when usb_ep_disable() runs.  At least, a quick check shows that both 
> net2280 and dummy-hcd use spin_lock_irqsave() rather than spin_lock() 
> in their disable routines.
>
> Holding locks is a different story.  It should be okay for a gadget 
> driver to hold one of its own locks when disabling an endpoint (which 
> means that the gadget's disable routine shouldn't wait for a concurrent 
> giveback to finish), but we might want to avoid holding a lock in the 
> composite core.  Although even that might be okay -- I can't think of 
> any reason why a udc driver would need to call back into the composite 
> core while disabling an endpoint.  It should be a pretty self-contained 
> operation.

True, but how do we handle controllers which need to wait for an
interrupt in order to cancel a transfer? Maybe we should change the
calling context of usb_ep_disable() so that it _must_ be called with
IRQs enabled?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] wusb: Stop using the stack for sg crypto scratch space

[Greg KH]

On Sun, Oct 16, 2016 at 10:17:53AM -0700, Andy Lutomirski wrote:
> On Thu, Oct 6, 2016 at 10:25 AM, Andy Lutomirski  wrote:
> > Pointing an sg list at the stack is verboten and, with
> > CONFIG_VMAP_STACK=y, will malfunction.  Use kmalloc for the wusb
> > crypto stack space instead.
> >
> > Untested -- I'm not entirely convinced that this hardware exists in
> > the wild.
> 
> Greg, could you queue this up for 4.9?  I can't guarantee that it
> works, but I can pretty much guarantee that the driver is busted
> without it.

Yes, it's in my queue, couldn't do anything until after -rc1 came out.
I'll catch up on it this week.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: USB GADGET: have a question about usb2eth

[Lipengcheng]

Hi,
thank you for your suggestion.
I have a question about usb2eth. In the function gen_ndis_set_resp
of the rndis.c, the value of *params->filter may be 0x20 from the
pc set command; Howerver the value is used cdc_filter = 
dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c.
If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is
0x20, the broadcast packet can not send the pc win7; At the result, 
the linux ping the win7 is slow an the first. At the same time, Why are 
different value between RNDIS_PACKET_TYPE_PROMISCUOUS and
USB_CDC_PACKET_TYPE_PROMISCUOUS? If the value of RNDIS_PACKET_TYPE_PROMISCUOUS
and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the win7 is
normal speed.

Best Regards
Pengcheng Li

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, October 17, 2016 9:56 AM
> To: Lipengcheng
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org; 
> linux-ker...@vger.kernel.org
> Subject: Re: USB GADGET: have a question about usb2eth
> 
> On Sat, Oct 15, 2016 at 09:19:33AM +, Lipengcheng wrote:
> > Hi,
> > I have a question about usb2eth. In the function gen_ndis_set_resp of 
> > the rndis.c, the value of *params->filter may be 0x20 from the pc
> set command; Howerver the value is used cdc_filter = 
> dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c. If 
> we do not
> judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is 0x20, the broadcast 
> packet can not send the pc win7; At the result, the linux
> ping the win7 is slow an the first.
> >
> 
> The Felipe's email has changed, please check MAINTAINERS.
> Besides, would you wrap up line to 75 characters please?
> 
> --
> 
> Best Regards,
> Peter Chen