date:20141223

This patch series adds USB device node and phy for exynos3250 SoC.
And enables for rinato and monk boards.

Jaewon Kim (4):
  ARM: dts: Add exynos_usbphy node for exynos3250
  ARM: dts: Add hsotg node for exynos3250
  ARM: dts: Enable USB node for exynos3250-rinato
  ARM: dts: Enable USB node for exynos3250-monk

 arch/arm/boot/dts/exynos3250-monk.dts   |   10 ++
 arch/arm/boot/dts/exynos3250-rinato.dts |   10 ++
 arch/arm/boot/dts/exynos3250.dtsi   |   22 ++
 3 files changed, 42 insertions(+)

-- 
1.7.9.5

--
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 4/4] ARM: dts: Enable USB node for exynos3250-monk

This patch adds device tree node for hsotg to control USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250-monk.dts |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 24822aa..0c1d85d 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -134,6 +134,16 @@
};
 };
 
+exynos_usbphy {
+   status = okay;
+};
+
+hsotg {
+   vusb_d-supply = ldo15_reg;
+   vusb_a-supply = ldo12_reg;
+   status = okay;
+};
+
 i2c_0 {
#address-cells = 1;
#size-cells = 0;
-- 
1.7.9.5

--
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 3/4] ARM: dts: Enable USB node for exynos3250-rinato

This patch enables hsotg and usbphy node to use USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250-rinato.dts |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 80aa8b4..bf4c17b 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,16 @@
};
 };
 
+exynos_usbphy {
+   status = okay;
+};
+
+hsotg {
+   vusb_d-supply = ldo15_reg;
+   vusb_a-supply = ldo12_reg;
+   status = okay;
+};
+
 i2c_0 {
#address-cells = 1;
#size-cells = 0;
-- 
1.7.9.5

--
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 1/4] ARM: dts: Add exynos_usbphy node for exynos3250

This patch adds device tree node for exynos_usbphy to use USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 2246549..d976007 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -279,6 +279,17 @@
status = disabled;
};
 
+   exynos_usbphy: exynos-usbphy@125B {
+   compatible = samsung,exynos3250-usb2-phy;
+   reg = 0x125B 0x100;
+   samsung,pmureg-phandle = pmu_system_controller;
+   samsung,sysreg-phandle = sys_reg;
+   clocks = cmu CLK_USBOTG, xusbxti;
+   clock-names = phy, ref;
+   #phy-cells = 1;
+   status = disabled;
+   };
+
amba {
compatible = arm,amba-bus;
#address-cells = 1;
-- 
1.7.9.5

--
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 2/4] ARM: dts: Add hsotg node for exynos3250

This patch adds device tree node for hsotg to control USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index d976007..e5c891a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -255,6 +255,17 @@
status = disabled;
};
 
+   hsotg: hsotg@1248 {
+   compatible = snps,dwc2;
+   reg = 0x1248 0x2;
+   interrupts = 0 141 0;
+   clocks = cmu CLK_USBOTG;
+   clock-names = otg;
+   phys = exynos_usbphy 0;
+   phy-names = usb2-phy;
+   status = disabled;
+   };
+
mshc_0: mshc@1251 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1251 0x1000;
-- 
1.7.9.5

--
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 v1 04/29] usb: dwc2: gadget: don't embed ep0 buffers

2014-12-23 Thread Robert Baldyga

Hi,

On 12/21/2014 05:14 PM, Mian Yousaf Kaukab wrote:
 When using DMA, data of the previous setup packet can be read back
 from cache because ep0 and ctrl buffers are embedded in struct s3c_hsotg.
 Allocate buffers instead of embedding them.
 
 Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com
 ---
  drivers/usb/dwc2/core.h   |  7 +--
  drivers/usb/dwc2/gadget.c | 20 ++--
  2 files changed, 23 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
 index 7a70a13..e841a56 100644
 --- a/drivers/usb/dwc2/core.h
 +++ b/drivers/usb/dwc2/core.h
 @@ -434,6 +434,9 @@ struct dwc2_hw_params {
   u32 snpsid;
  };
  
 +/* Size of control and EP0 buffers */
 +#define DWC2_CTRL_BUFF_SIZE 8
 +
  /**
   * struct dwc2_hsotg - Holds the state of the driver, including the 
 non-periodic
   * and periodic schedules
 @@ -684,8 +687,8 @@ struct dwc2_hsotg {
  
   struct usb_request *ep0_reply;
   struct usb_request *ctrl_req;
 - u8 ep0_buff[8];
 - u8 ctrl_buff[8];
 + void *ep0_buff;
 + void *ctrl_buff;
  
   struct usb_gadget gadget;
   unsigned int enabled:1;
 diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
 index d89c341..5de3a3a 100644
 --- a/drivers/usb/dwc2/gadget.c
 +++ b/drivers/usb/dwc2/gadget.c
 @@ -3485,7 +3485,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
  
   if (ret) {
   dev_err(dev, failed to enable supplies: %d\n, ret);
 - goto err_supplies;
 + goto err_clk;
   }
  
   /* usb phy enable */
 @@ -3495,6 +3495,22 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
   s3c_hsotg_hw_cfg(hsotg);
   s3c_hsotg_init(hsotg);
  
 + hsotg-ctrl_buff = devm_kzalloc(hsotg-dev,
 + DWC2_CTRL_BUFF_SIZE, GFP_KERNEL);
 + if (!hsotg-ctrl_buff) {
 + dev_err(dev, failed to allocate ctrl request buff\n);
 + ret = -ENOMEM;
 + goto err_supplies;
 + }
 +
 + hsotg-ep0_buff = devm_kzalloc(hsotg-dev,
 + DWC2_CTRL_BUFF_SIZE, GFP_KERNEL);
 + if (!hsotg-ep0_buff) {
 + dev_err(dev, failed to allocate ctrl reply buff\n);
 + ret = -ENOMEM;
 + goto err_supplies;
 + }
 +
   ret = devm_request_irq(hsotg-dev, irq, s3c_hsotg_irq, IRQF_SHARED,
   dev_name(hsotg-dev), hsotg);
   if (ret  0) {
 @@ -3503,7 +3519,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
   regulator_bulk_disable(ARRAY_SIZE(hsotg-supplies),
  hsotg-supplies);
   dev_err(dev, cannot claim IRQ for gadget\n);
 - goto err_clk;
 + goto err_supplies;

This is unrelated change. Should be in separate patch.

   }
  
   /* hsotg-num_of_eps holds number of EPs other than ep0 */
 

Reviewed-by: Robert Baldyga r.bald...@samsung.com

Best regards,
Robert Baldyga
--
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: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

2014-12-23 Thread Sergei Shtylyov


Hello.

On 12/23/2014 1:43 AM, David Cohen wrote:


Some platforms have an USB OTG port fully (or partially) controlled by
GPIOs:



(1) USB ID is connected directly to GPIO



Optionally:
(2) VBUS is enabled by a GPIO (when ID is grounded)


   Can't the host driver still control Vbus?


(3) Platform has 2 USB controllers connected to same port: one for
 device and one for host role. D+/- are switched between phys
 by GPIO.



As per initial version, this driver has the duty to control whether
USB-Host cable is plugged in or not:
  - If yes, OTG port is configured for host role
  - If no, by standard, the OTG port is configured for device role



Signed-off-by: David Cohen david.a.co...@linux.intel.com
---



Hi,



Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
  - The USB ID pin is connected directly to GPIO on SoC
  - When in host role, VBUS is provided by enabling a GPIO
  - Device and host roles are supported by 2 independent controllers with D+/-
pins from port switched between different phys according a GPIO level.



The ACPI table describes this USB port as a (virtual) device with all the
necessary GPIOs. This driver implements support to this virtual device as an
extcon class driver. All drivers that depend on the USB OTG port state (USB phy,
PMIC, charge detection) will listen to extcon events.


   It's very close to my setup on R-Car R8A7791 based boards. :-)
I have already submitted Maxim MAX3355 OTG chip GPIO-based driver.


Comments are welcome.



Br, David
---

  drivers/extcon/Kconfig   |   8 ++
  drivers/extcon/Makefile  |   1 +
  drivers/extcon/extcon-otg_gpio.c | 200 +++
  3 files changed, 209 insertions(+)
  create mode 100644 drivers/extcon/extcon-otg_gpio.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de6fa54..e8010cda4642 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,12 @@ config EXTCON_SM5502
  Silicon Mitus SM5502. The SM5502 is a USB port accessory
  detector and switch.

+config EXTCON_OTG_GPIO
+   tristate VIRTUAL USB OTG PORT support
+   depends on GPIOLIB
+   help
+ Say Y here to enable support for virtual USB OTG port device
+ controlled by GPIOs. This driver can be used when at least USB ID pin
+ is connected directly to GPIO.
+


   The entries in this file seem alphabetically sorted.


  endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42e5a27..9e81088c6584 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
  obj-$(CONFIG_EXTCON_PALMAS)   += extcon-palmas.o
  obj-$(CONFIG_EXTCON_RT8973A)  += extcon-rt8973a.o
  obj-$(CONFIG_EXTCON_SM5502)   += extcon-sm5502.o
+obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o


   The lines here are sorted too.


diff --git a/drivers/extcon/extcon-otg_gpio.c b/drivers/extcon/extcon-otg_gpio.c
new file mode 100644
index ..c5ee765a5f4f
--- /dev/null
+++ b/drivers/extcon/extcon-otg_gpio.c
@@ -0,0 +1,200 @@

[...]

+static irqreturn_t vuport_isr(int irq, void *priv)
+{
+   return IRQ_WAKE_THREAD;
+}


   It's the same as the default IRQ handler...


+   ret = devm_request_threaded_irq(dev, gpiod_to_irq(vup-gpio_usb_id),
+   vuport_isr, vuport_thread_isr,


   ... so you probably can just pass NULL instead of vuport_isr, no?

[...]


+static int __init vuport_init(void)
+{
+   return platform_driver_register(vuport_driver);
+}
+subsys_initcall(vuport_init);


   Hm, why?

WBR, Sergei

--
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 v1 11/29] usb: dwc2: gadget: configure fifos from device tree

2014-12-23 Thread Robert Baldyga

Hi,

On 12/21/2014 05:15 PM, Mian Yousaf Kaukab wrote:
 From: Gregory Herrero gregory.herr...@intel.com
 
 As fifo size can vary between SOCs, add possibility to configure
 them from device tree. Fifo sizes used by the legacy driver will
 be used If they are not provided by the device tree.
 
 Signed-off-by: Gregory Herrero gregory.herr...@intel.com
 Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com
 ---
  drivers/usb/dwc2/core.h   | 13 +++
  drivers/usb/dwc2/gadget.c | 88 
 ++-
  2 files changed, 77 insertions(+), 24 deletions(-)
 
 diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
 index fa5ee27..7c0b995 100644
 --- a/drivers/usb/dwc2/core.h
 +++ b/drivers/usb/dwc2/core.h
 @@ -193,6 +193,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}
 +
  /**
   * struct dwc2_core_params - Parameters for configuring the core
   *
 @@ -564,6 +571,9 @@ struct dwc2_hw_params {
   * @last_rst:   Time of last reset
   * @eps:The endpoints being supplied to the gadget framework
   * @g_using_dma:  Indicate if dma usage is enabled
 + * @g_rx_fifo_sz: Contains rx fifo size value
 + * @g_np_g_tx_fifo_sz:  Contains Non-Periodic tx fifo size value
 + * @g_tx_fifo_sz: Contains tx fifo size value per endpoints
   */
  struct dwc2_hsotg {
   struct device *dev;
 @@ -699,6 +709,9 @@ struct dwc2_hsotg {
   struct s3c_hsotg_ep *eps_in[MAX_EPS_CHANNELS];
   struct s3c_hsotg_ep *eps_out[MAX_EPS_CHANNELS];
   u32 g_using_dma;
 + u32 g_rx_fifo_sz;
 + u32 g_np_g_tx_fifo_sz;
 + u32 g_tx_fifo_sz[MAX_EPS_CHANNELS];
  #endif /* CONFIG_USB_DWC2_PERIPHERAL || CONFIG_USB_DWC2_DUAL_ROLE */
  };
  
 diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
 index d06485c..1fe733b 100644
 --- a/drivers/usb/dwc2/gadget.c
 +++ b/drivers/usb/dwc2/gadget.c
 @@ -174,15 +174,14 @@ static void s3c_hsotg_init_fifo(struct dwc2_hsotg 
 *hsotg)
  {
   unsigned int ep;
   unsigned int addr;
 - unsigned int size;
   int timeout;
   u32 val;
  
 - /* set FIFO sizes to 2048/1024 */
 -
 - writel(2048, hsotg-regs + GRXFSIZ);
 - writel((2048  FIFOSIZE_STARTADDR_SHIFT) |
 - (1024  FIFOSIZE_DEPTH_SHIFT), hsotg-regs + GNPTXFSIZ);
 + /* set RX/NPTX FIFO sizes */
 + writel(hsotg-g_rx_fifo_sz, hsotg-regs + GRXFSIZ);
 + writel((hsotg-g_rx_fifo_sz  FIFOSIZE_STARTADDR_SHIFT) |
 + (hsotg-g_np_g_tx_fifo_sz  FIFOSIZE_DEPTH_SHIFT),
 + hsotg-regs + GNPTXFSIZ);
  
   /*
* arange all the rest of the TX FIFOs, as some versions of this
 @@ -192,7 +191,7 @@ static void s3c_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
*/
  
   /* start at the end of the GNPTXFSIZ, rounded up */
 - addr = 2048 + 1024;
 + addr = hsotg-g_rx_fifo_sz + hsotg-g_np_g_tx_fifo_sz;
  
   /*
* Because we have not enough memory to have each TX FIFO of size at
 @@ -202,25 +201,14 @@ static void s3c_hsotg_init_fifo(struct dwc2_hsotg 
 *hsotg)
* given endpoint.
*/
  

You should also change the comment above since it's not true after your
changes.

 - /* 256*4=1024 bytes FIFO length */
 - size = 256;
 - for (ep = 1; ep = 4; ep++) {
 - val = addr;
 - val |= size  FIFOSIZE_DEPTH_SHIFT;
 - WARN_ONCE(addr + size  hsotg-fifo_mem,
 -   insufficient fifo memory);
 - addr += size;
 -
 - writel(val, hsotg-regs + DPTXFSIZN(ep));
 - }
 - /* 768*4=3072 bytes FIFO length */
 - size = 768;
 - for (ep = 5; ep = 8; ep++) {
 + for (ep = 1; ep  MAX_EPS_CHANNELS; ep++) {
 + if (!hsotg-g_tx_fifo_sz[ep])
 + continue;
   val = addr;
 - val |= size  FIFOSIZE_DEPTH_SHIFT;
 - WARN_ONCE(addr + size  hsotg-fifo_mem,
 + 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 += size;
 + addr += hsotg-g_tx_fifo_sz[ep];
  
   writel(val, hsotg-regs + DPTXFSIZN(ep));
   }
 @@ -3495,9 +3483,42 @@ static void s3c_hsotg_delete_debug(struct dwc2_hsotg 
 *hsotg)
  static void s3c_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

Re: usb: musb: Scheduling of interrupt endpoints

2014-12-23 Thread Carsten Behling


Would it help if I send a patch as a suggestion and as basis for discussion?

On 12/19/2014 01:38 PM, Carsten Behling wrote:

Hi all,

Long time ago, TI shipped a kernel named 
linux-2.6.32.17-psp03.01.01.39 with an additional kernel option

for scheduling of interrupt endpoints.

AFAIK, this seems to be the only possibility to attach more that 4 in 
endpoints to MUSB (at least on a DM368).


This feature reserves one hardware endpoint unit to time schedule 
interrupt in endpoints based

on its bInterval value triggered by the SOF interrupt.

I didn't find any discussion about adding such a feature to the 
mainline kernel.
IMHO, this feature is absolutely necessary. But there may be reasons, 
not to add it (e.g. CPU load).


Please let me know your thoughts and ideas.

Best regards
-Carsten



--
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] usb: dwc2: Fixed a few typos in comments

Signed-off-by: Mickael Maison mickael.mai...@gmail.com
---
 drivers/usb/dwc2/core.c   | 2 +-
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 7605850b..d5197d4 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -462,7 +462,7 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool 
select_phy, int irq)
dwc2_enable_common_interrupts(hsotg);
 
/*
-* Do device or host intialization based on mode during PCD and
+* Do device or host initialization based on mode during PCD and
 * HCD initialization
 */
if (dwc2_is_host_mode(hsotg)) {
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7a70a13..0d2ee29 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -381,7 +381,7 @@ struct dwc2_core_params {
  * @power_optimized Are power optimizations enabled?
  * @num_dev_ep  Number of device endpoints available
  * @num_dev_perio_in_ep Number of device periodic IN endpoints
- *  avaialable
+ *  available
  * @dev_token_q_depth   Device Mode IN Token Sequence Learning Queue
  *  Depth
  *   0 to 30
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..ede69dc 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -65,7 +65,7 @@ static inline void __bic32(void __iomem *ptr, u32 val)
writel(readl(ptr)  ~val, ptr);
 }
 
-/* forward decleration of functions */
+/* forward declaration of functions */
 static void s3c_hsotg_dump(struct dwc2_hsotg *hsotg);
 
 /**
-- 
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

[PATCH] usb: dwc3: Fixed a typo in comments

Signed-off-by: Mickael Maison mickael.mai...@gmail.com
---
 drivers/usb/dwc3/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f03b136..bd9f48d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2077,7 +2077,7 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, 
u32 epnum, bool force)
 * We have discussed this with the IP Provider and it was
 * suggested to giveback all requests here, but give HW some
 * extra time to synchronize with the interconnect. We're using
-* an arbitraty 100us delay for that.
+* an arbitrary 100us delay for that.
 *
 * Note also that a similar handling was tested by Synopsys
 * (thanks a lot Paul) and nothing bad has come out of it.
-- 
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] USB: gadget: udc: atmel: fix possible oops when unloading module

On Mon, Dec 22, 2014 at 05:26:14PM +0800, Songjun Wu wrote:
 When unloading the module, the urb request will be dequeued
 and the completion routine will be excuted.
 If no urb packet, the urb request will not be added to the endpoint queue
 and the completion routine pointer in urb request is NULL.
 Accessing to the NULL function pointer will cause the oops issue.
 Add the code to check the urb request is in the endpoint queue or not.
 If the urb request is not in the endpoint queue, a negative error code
 will be returned.

have you triggered the NULL pointer oops ? Care to add it to the commit
log.

Also, which commit is this fixing ? Does this need to be backported ?
When was the bug introduced ?

 Signed-off-by: Songjun Wu songjun...@atmel.com
 ---
  drivers/usb/gadget/udc/atmel_usba_udc.c |   12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
 b/drivers/usb/gadget/udc/atmel_usba_udc.c
 index ce88237..48629cc 100644
 --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
 +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
 @@ -828,7 +828,7 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct 
 usb_request *_req)
  {
   struct usba_ep *ep = to_usba_ep(_ep);
   struct usba_udc *udc = ep-udc;
 - struct usba_request *req = to_usba_req(_req);
 + struct usba_request *req;
   unsigned long flags;
   u32 status;
  
 @@ -837,6 +837,16 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct 
 usb_request *_req)
  
   spin_lock_irqsave(udc-lock, flags);
  
 + list_for_each_entry(req, ep-queue, queue) {
 + if (req-req == _req)
 + break;
 + }
 +
 + if (req-req != _req) {
 + spin_unlock_irqrestore(udc-lock, flags);
 + return -EINVAL;
 + }
 +
   if (req-using_dma) {
   /*
* If this request is currently being transferred,
 -- 
 1.7.9.5
 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: dwc3: Fixed a typo in comments

On Tue, Dec 23, 2014 at 05:22:21PM +0100, Mickael Maison wrote:
 Signed-off-by: Mickael Maison mickael.mai...@gmail.com

even obvious patches need a commit log, please write one and I'll
certainly queue your patch.

 ---
  drivers/usb/dwc3/gadget.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
 index f03b136..bd9f48d 100644
 --- a/drivers/usb/dwc3/gadget.c
 +++ b/drivers/usb/dwc3/gadget.c
 @@ -2077,7 +2077,7 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, 
 u32 epnum, bool force)
* We have discussed this with the IP Provider and it was
* suggested to giveback all requests here, but give HW some
* extra time to synchronize with the interconnect. We're using
 -  * an arbitraty 100us delay for that.
 +  * an arbitrary 100us delay for that.
*
* Note also that a similar handling was tested by Synopsys
* (thanks a lot Paul) and nothing bad has come out of it.
 -- 
 1.9.1
 

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] usb: dwc3: Fixed a typo in comments

Fixed a typo in comments

Signed-off-by: Mickael Maison mickael.mai...@gmail.com
---
 drivers/usb/dwc3/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f03b136..bd9f48d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2077,7 +2077,7 @@ static void dwc3_stop_active_transfer(struct dwc3 *dwc, 
u32 epnum, bool force)
 * We have discussed this with the IP Provider and it was
 * suggested to giveback all requests here, but give HW some
 * extra time to synchronize with the interconnect. We're using
-* an arbitraty 100us delay for that.
+* an arbitrary 100us delay for that.
 *
 * Note also that a similar handling was tested by Synopsys
 * (thanks a lot Paul) and nothing bad has come out of it.
-- 
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

[PATCH] usb: dwc2: Fixed a few typos in comments

Fixed 3 typos in comments

Signed-off-by: Mickael Maison mickael.mai...@gmail.com
---
 drivers/usb/dwc2/core.c   | 2 +-
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 7605850b..d5197d4 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -462,7 +462,7 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool 
select_phy, int irq)
dwc2_enable_common_interrupts(hsotg);
 
/*
-* Do device or host intialization based on mode during PCD and
+* Do device or host initialization based on mode during PCD and
 * HCD initialization
 */
if (dwc2_is_host_mode(hsotg)) {
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7a70a13..0d2ee29 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -381,7 +381,7 @@ struct dwc2_core_params {
  * @power_optimized Are power optimizations enabled?
  * @num_dev_ep  Number of device endpoints available
  * @num_dev_perio_in_ep Number of device periodic IN endpoints
- *  avaialable
+ *  available
  * @dev_token_q_depth   Device Mode IN Token Sequence Learning Queue
  *  Depth
  *   0 to 30
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..ede69dc 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -65,7 +65,7 @@ static inline void __bic32(void __iomem *ptr, u32 val)
writel(readl(ptr)  ~val, ptr);
 }
 
-/* forward decleration of functions */
+/* forward declaration of functions */
 static void s3c_hsotg_dump(struct dwc2_hsotg *hsotg);
 
 /**
-- 
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

[GIT PULL] USB patches

Hi Greg,

Here's my first set of fixes for v3.19-rc cycle. An early
Winter Solstice gift for you.

All patches have gone through my 300 randconfigs (no build
breakages or new warnings found) and I boot tested with
AM437x SK, AM437x IDK, Beagle x15 and Beagle Bone Black.

cheers

The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:

  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v3.19-rc2

for you to fetch changes up to 6785a1034461c2d2c205215f63a50a740896e55b:

  usb: gadget: udc: atmel: fix possible IN hang issue (2014-12-22 10:41:15 
-0600)


usb: fixes for v3.19-rc2

First set of fixes for current -rc cycle. There are
a couple of build break fixes after Tony Lindgren's
recent MUSB patchset, some memory leak fixes also
with MUSB, a use-after-free fix with the UAC1
function. Atmel UDC got a fix for a possible hang
and another for DMA setting, while dwc2 learned to
kill requests in -udc_stop() which fixes a few leaks
too.

One new device support here, dwc3 now supports Intel's
Sunrise Point.

Signed-off-by: Felipe Balbi ba...@ti.com


Bo Shen (2):
  usb: gadget: udc: atmel: change setting for DMA
  usb: gadget: udc: atmel: fix possible IN hang issue

Felipe Balbi (2):
  usb: musb: debugfs: cope with blackfin's oddities
  usb: musb: blackfin: fix build break

Heikki Krogerus (1):
  usb: dwc3: pci: add support for Intel Sunrise Point PCH

Julia Lawall (1):
  usb: gadget: fix misspelling of current function in string

Mario Schuknecht (1):
  usb: gadget: gadgetfs: Free memory allocated by memdup_user()

Peter Chen (1):
  usb: gadget: f_uac1: access freed memory at f_audio_free_inst

Rasmus Villemoes (1):
  usb: musb: Fix a few off-by-one lengths

Robert Baldyga (1):
  usb: dwc2: gadget: kill requests with 'force' in s3c_hsotg_udc_stop()

Sebastian Andrzej Siewior (1):
  usb: musb: stuff leak of struct usb_hcd

Tony Lindgren (1):
  usb: musb: Fix randconfig build issues for Kconfig options

 drivers/usb/dwc2/gadget.c   | 10 +++---
 drivers/usb/dwc3/dwc3-pci.c |  4 
 drivers/usb/gadget/function/f_hid.c |  5 +++--
 drivers/usb/gadget/function/f_midi.c|  2 +-
 drivers/usb/gadget/function/f_uac1.c|  2 +-
 drivers/usb/gadget/legacy/inode.c   |  1 +
 drivers/usb/gadget/udc/atmel_usba_udc.c |  7 +++
 drivers/usb/musb/Kconfig|  4 
 drivers/usb/musb/blackfin.c |  2 +-
 drivers/usb/musb/musb_cppi41.c  |  4 ++--
 drivers/usb/musb/musb_debugfs.c | 34 +
 drivers/usb/musb/musb_host.c|  1 -
 12 files changed, 45 insertions(+), 31 deletions(-)
--
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] cleanup on stack DECLARE_COMPLETIONs

2014-12-23 Thread Nicholas Mc Guire

fixups for incorrect use of DECLARE_COMPLETION. see also commit
6e9a4738 (completions: lockdep annotate on stack completions)
The only somewhat special case being
drivers/misc/sgi-gru/grukservices.c:quicktest2
which had a static qualifier in the original DECLARE_COMPLETION()
but that seems to be wrong (why should the completion persisted between
successive calls ?) so the conversion to DECLARE_COMPLETION_ONSTACK
was also applied and the static qualifier removed.

Not sure if this is suitable in this form or if it should go out as
5 seperate patches ? 

This was only code reviewed and compile tested

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
 drivers/macintosh/ams/ams-pmu.c   |4 ++--
 drivers/misc/sgi-gru/grukservices.c   |2 +-
 drivers/scsi/aha152x.c|2 +-
 drivers/usb/gadget/udc/fsl_qe_udc.c   |2 +-
 drivers/usb/gadget/udc/fsl_udc_core.c |2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/macintosh/ams/ams-pmu.c b/drivers/macintosh/ams/ams-pmu.c
index 4f61b3e..c2b178f 100644
--- a/drivers/macintosh/ams/ams-pmu.c
+++ b/drivers/macintosh/ams/ams-pmu.c
@@ -52,7 +52,7 @@ static void ams_pmu_req_complete(struct adb_request *req)
 static void ams_pmu_set_register(u8 reg, u8 value)
 {
static struct adb_request req;
-   DECLARE_COMPLETION(req_complete);
+   DECLARE_COMPLETION_ONSTACK(req_complete);

req.arg = req_complete;
if (pmu_request(req, ams_pmu_req_complete, 4, ams_pmu_cmd, 0x00, reg, 
value))
@@ -65,7 +65,7 @@ static void ams_pmu_set_register(u8 reg, u8 value)
 static u8 ams_pmu_get_register(u8 reg)
 {
static struct adb_request req;
-   DECLARE_COMPLETION(req_complete);
+   DECLARE_COMPLETION_ONSTACK(req_complete);

req.arg = req_complete;
if (pmu_request(req, ams_pmu_req_complete, 3, ams_pmu_cmd, 0x01, reg))
diff --git a/drivers/misc/sgi-gru/grukservices.c 
b/drivers/misc/sgi-gru/grukservices.c
index 913de07..4e412fe 100644
--- a/drivers/misc/sgi-gru/grukservices.c
+++ b/drivers/misc/sgi-gru/grukservices.c
@@ -1044,7 +1044,7 @@ done:

 static int quicktest2(unsigned long arg)
 {
-   static DECLARE_COMPLETION(cmp);
+   DECLARE_COMPLETION_ONSTACK(cmp);
unsigned long han;
int blade_id = 0;
int numcb = 4;
diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
index 2b960b3..b16afb9 100644
--- a/drivers/scsi/aha152x.c
+++ b/drivers/scsi/aha152x.c
@@ -1055,7 +1055,7 @@ static int aha152x_abort(Scsi_Cmnd *SCpnt)
 static int aha152x_device_reset(Scsi_Cmnd * SCpnt)
 {
struct Scsi_Host *shpnt = SCpnt-device-host;
-   DECLARE_COMPLETION(done);
+   DECLARE_COMPLETION_ONSTACK(done);
int ret, issued, disconnected;
unsigned char old_cmd_len = SCpnt-cmd_len;
unsigned long flags;
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index 795c99c..e0822f1 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -2630,7 +2630,7 @@ static int qe_udc_remove(struct platform_device *ofdev)
struct qe_udc *udc = platform_get_drvdata(ofdev);
struct qe_ep *ep;
unsigned int size;
-   DECLARE_COMPLETION(done);
+   DECLARE_COMPLETION_ONSTACK(done);

usb_del_gadget_udc(udc-gadget);

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 2df8074..c3830ad 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2529,7 +2529,7 @@ static int __exit fsl_udc_remove(struct platform_device 
*pdev)
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct fsl_usb2_platform_data *pdata = dev_get_platdata(pdev-dev);

-   DECLARE_COMPLETION(done);
+   DECLARE_COMPLETION_ONSTACK(done);

if (!udc_controller)
return -ENODEV;
--
1.7.10.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: [PATCH] cleanup on stack DECLARE_COMPLETIONs

On Tue, Dec 23, 2014 at 06:34:08PM +0100, Nicholas Mc Guire wrote:
 fixups for incorrect use of DECLARE_COMPLETION. see also commit
 6e9a4738 (completions: lockdep annotate on stack completions)
 The only somewhat special case being
 drivers/misc/sgi-gru/grukservices.c:quicktest2
 which had a static qualifier in the original DECLARE_COMPLETION()
 but that seems to be wrong (why should the completion persisted between
 successive calls ?) so the conversion to DECLARE_COMPLETION_ONSTACK
 was also applied and the static qualifier removed.
 
 Not sure if this is suitable in this form or if it should go out as
 5 seperate patches ? 
 
 This was only code reviewed and compile tested
 
 Signed-off-by: Nicholas Mc Guire der.h...@hofr.at

please split drivers/usb/gadget out of this patch so I can take it
through my tree.

-- 
balbi


signature.asc
Description: Digital signature

Re: usb: musb: Scheduling of interrupt endpoints

Hi,

On Tue, Dec 23, 2014 at 08:59:39AM -0600, Carsten Behling wrote:
 Would it help if I send a patch as a suggestion and as basis for
 discussion?

yes, it would also help if you didn't top-post :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: gadget: udc-core: call udc_stop() before gadget unbind

On Tue, Dec 23, 2014 at 07:34:15AM +0100, Robert Baldyga wrote:
 Hi Felipe,
 
 On 12/22/2014 05:34 PM, Felipe Balbi wrote:
  On Mon, Dec 15, 2014 at 11:05:22AM +0100, Robert Baldyga wrote:
  On 12/15/2014 06:13 AM, Peter Chen wrote:
  On Fri, Dec 12, 2014 at 02:17:28PM +0100, Robert Baldyga wrote:
  As usb function drivers assumes that all usb request will be completed
  before function unbind call, we should supply such behavior. In some
  cases ep_disable() won't kill all request effectively, because some
  IN requests can be in running state. In such situation it's possible
  to have unbind function called before last request completion, which
  can cause problems.
 
  Doesn't the function's disable/unbind should call usb_ep_dequeue to make
  sure the transfer has ended?
 
  USB function drivers like ECM or HID surely doesn't. It looks like
  there's assumption that all requests will be completed by UDC driver.
  
  that's a bug on those drivers :-)
 
 So we can't make assumptions that requests will be completed in
 ep_disable()?

oh, no you can. I misread it.

  Function ep_disable() should complete requests in hardware driver, but
  at least in DWC2 driver not all requests are completed at this stage
  
  and that's a bug on dwc2 :-)
 
 I have already found that out. Another UDC drivers simply kill all
 request without waiting for currently running, so I did the same in
 DWC2. Here is my patch:
 http://www.spinics.net/lists/linux-usb/msg118698.html

should be in my pull request already.

  (request which are in hardware FIFO are omitted to give them chance to
  be transferred). Those requests are forced to complete in udc_stop()
  
  that's wrong, we're disabling the endpoint anyway. Either dwc2 needs to
  wait_for_completion() or forcibly cancel the request. The bottom line is
  that control should not exit ep_disable() until all requests have been
  quiesced.
 
 So that's not bug in function drivers. They make correct assumption,
 because they expect that requests will be completed in ep_disable().

right :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: phy: Restore deferred probing path

On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
 From: Thierry Reding tred...@nvidia.com
 
 Commit 1290a958d48e (usb: phy: propagate __of_usb_find_phy()'s error on
 failure) broke platforms that rely on deferred probing to order probing
 of PHY and host controller drivers. The reason is that the commit simply
 propagates errors from __of_usb_find_phy(), which returns -ENODEV if no
 PHY has been registered yet for a given device tree node. The only case
 in which -EPROBE_DEFER would now be returned is if try_module_get() did
 fail, which does not make sense.
 
 The correct thing to do is to return -EPROBE_DEFER if a PHY hasn't been
 registered yet. The only condition under which it makes sense to return
 -ENODEV is if the device tree node representing the PHY has been
 disabled (via the status property) because in that case the PHY will
 never be registered.
 
 This patch addresses the problem by making __of_usb_find_phy() return an
 appropriate error code while keeping in line with the above-mentioned
 commit to propagate error codes rather than overwriting them. At the
 same time the check for a valid PHY is decoupled from the check for the
 try_module_get() call and a separate error code is returned if the
 latter fails.
 
 Signed-off-by: Thierry Reding tred...@nvidia.com

you forgot to add the magic Fixes: foo bar here, I'll add it this
time, but I've already sent my -rc2 pull request, so this will only show
up on -rc3.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 0/3] usb: phy: generic: device-tree support

On Mon, Dec 15, 2014 at 12:13:18AM +0100, Robert Jarzmik wrote:
 Robert Jarzmik robert.jarz...@free.fr writes:
 
  Hi Felipe,
 
  This is the 2nd opus of this serie.
  For patches 1 and 2, all comments have been addressed.
 
  For patch 3, you had a question about device charging spec and the regulator
  timings. I read the specs, saw the 15mn timing you were speaking of, but 
  didn't
  find a nice way to implement it. As I'd like this patchset to move forward, 
  I
  see these ways out :
   1) I leave it as is, making it as good as phy_gpio_vbus, but not better
   2) I remove all the regulator stuff, it you judge a partial implementation 
  is
  worse that a complete one
 
  Just tell me which solution you prefer.
 
 Ping ?

getting there, a few other patches pending :-)

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

Hi,

(no top-posting)

On Fri, Dec 19, 2014 at 12:16:04PM +0100, Eduard Gavin wrote:
 Hi Everybody,
 
 After several test with IGEPv2 board (OMAP3) and linux kernel 3.17 and
 3.18, the OTG works but, (from my point of view) with an weird
 behaviour.
 
 The OTG like a Host only is activated after load a gadget driver, I
 mean that, If I plug a USB memory dongle in the OTG port before load a
 Gadget driver like g_ether the dongle is not recognized. After load
 g_ether driver, the usb dongle is recognized without problems.
 I miss something in the configuration?
 It this the normal behaviour?

it's normal. If you configured your kernel for OTG/dual-role, you must
have both roles ready to go.

that should be considered common sense.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 06/17] net2280: Remove restart_dma inline function definition

On Fri, Nov 28, 2014 at 11:16:16PM +0300, Sergei Shtylyov wrote:
 On 11/28/2014 06:21 PM, Ricardo Ribalda Delgado wrote:
 
 Thanks for reviewing. I will fix it and resend it on the next version
 of the patchset to avoid spamming the ML
 
 I guess it is ok to add your Reviewed-by
 
Yes, if you like.
 
 Thanks!
 
Not at all. :-)
 
 [...]
 
 On 11/28/2014 04:50 PM, Ricardo Ribalda Delgado wrote:
 
 restart_dma is not used before it is declaration. Therefore we can
 
 s/it is/its/.
 
Also s/declaration/definition/.
 
 remove this definition.
 
 You're removing the declaration, not definition.

do I get a new version of this patch ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 05/22] usb: isp1760: Merge platform and OF glue codes

On Mon, Dec 01, 2014 at 09:47:06PM +0200, Laurent Pinchart wrote:
 Both handle platform devices, merge them.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

doesn't apply:

checking file drivers/usb/host/isp1760-if.c
Hunk #1 FAILED at 12.
Hunk #2 succeeded at 304 (offset -1 lines).
Hunk #3 succeeded at 332 (offset -1 lines).
Hunk #4 succeeded at 404 (offset -1 lines).
Hunk #5 succeeded at 431 (offset -1 lines).
Hunk #6 succeeded at 446 (offset -1 lines).
1 out of 6 hunks FAILED

please rebase on my testig/next, just wait some 15 minutes before
rebasing :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: qcserial: AT unsolicited response codes missing with Sierra Wireless MC7304

2014-12-23 Thread Reinhard Speyerer

Johan Hovold jo...@kernel.org wrote:

On Sun, Dec 21, 2014 at 11:25:45PM +0100, Reinhard Speyerer wrote:

When using a MC7304 with firmware revision SWI9X15C_05.05.16.02 on
Knoppix 7.4.2 with Linux kernel 3.16.3 and the qcserial driver I noticed
that AT unsolicited response codes (URCs) like +CREG were missing (the
mobile
has been set to AT+CREG=2 before and LACx/CIx is used instead of the
real
LACs/CIs):

Switching the mobile back to the option driver

caused the missing +CREG: to reappear:

The URCs are also present when using the vendor GobiSerial driver.

Do you have a link to that driver? The one I found does not seem to send
the control requests you mention below.

The vendor driver (USB drivers Linux QMI Software S2.20N2.27) is available from
http://developer.sierrawireless.com/Resources/Resources/AirPrime/Software/USB%20drivers%20Linux%20QMI%20Software.aspx
(registration required for downloading the driver).

Besides +CREG: other URCs like e.g. +CUSD: or +CMT: are also affected.
MC7710 devices with VID/PID 0x1199/0x68a2 which I cross-checked for
comparison do not show this problem.

The URCs are there also with qcserial?

Correct. With a MC7710 with firmware revision SWI9200X_03.05.24.00 the URCs
are also there with qcserial.

From comparing option.c and qcserial.c the only difference in
initialization visible to me is the option_send_setup code. The
proposed patch below for kernel 3.19 or later moves Sierra Wireless
VID/PID 0x1199/0x68c0 devices from the qcserial to the option driver
using an appropriate blacklist for the QMI/network interfaces (8..11)
and the USB audio interfaces (16..18) present in some firmwares.

An alternative to this patch would be to add the option_send_setup code
to qcserial.c for Sierra Wireless VID/PID 0x1199/0x68c0 devices.

I leaning towards adding modem-control support to qcserial (send_setup).

Can you confirm that the vendor driver is sending these control
requests?

Sorry, I could not verify that.

And did you already verify that adding them to qcserial fixes the issue
with MC7304?

To verify that the URCs do not appear as a side effect of other option
initialization code I will try to port the send_setup code to qcserial
and report on the results.

Regards,
Reinhard
--
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 v5] usb: gadget: f_fs: add no_disconnect mode

On Thu, Dec 18, 2014 at 09:55:10AM +0100, Robert Baldyga wrote:
 Since we can compose gadgets from many functions, there is the problem
 related to gadget breakage while FunctionFS daemon being closed. FFS
 function is userspace code so there is no way to know when it will close
 files (it doesn't matter what is the reason of this situation, it can
 be daemon logic, program breakage, process kill or any other). So when
 we have another function in gadget which, for example, sends some amount
 of data, does some software update or implements some real-time functionality,
 we may want to keep the gadget connected despite FFS function is no longer
 functional.
 
 We can't just remove one of functions from gadget since it has been
 enumerated, so the only way to keep entire gadget working is to make
 broken FFS function deactivated but still visible to host. For this
 purpose this patch introduces no_disconnect mode. It can be enabled
 by setting mount option no_disconnect=1, and results with defering
 function disconnect to the moment of reopen ep0 file or filesystem
 unmount. After closing all endpoint files, FunctionFS is set to state
 FFS_DEACTIVATED.
 
 When ffs-state == FFS_DEACTIVATED:
 - function is still bound and visible to host,
 - setup requests are automatically stalled,
 - transfers on other endpoints are refused,
 - epfiles, except ep0, are deleted from the filesystem,
 - opening ep0 causes the function to be closed, and then FunctionFS
   is ready for descriptors and string write,
 - altsetting change causes the function to be closed - we want to keep
   function alive until another functions are potentialy used, altsetting
   change means that another configuration is being selected or USB cable
   was unplugged, which indicates that we don't need to stay longer in
   FFS_DEACTIVATED state
 - unmounting of the FunctionFS instance causes the function to be closed.
 
 Signed-off-by: Robert Baldyga r.bald...@samsung.com

David, can you test it with your setup ?

cheers

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] gadget: cleanup on stack DECLARE_COMPLETIONs

2014-12-23 Thread Nicholas Mc Guire

fixups for incorrect use of DECLARE_COMPLETION. see also commit
6e9a4738 (completions: lockdep annotate on stack completions)

patch is against 3.18.0 linux-next

This was only code reviewed and compile tested

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
 drivers/usb/gadget/udc/fsl_qe_udc.c   |2 +-
 drivers/usb/gadget/udc/fsl_udc_core.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index 795c99c..e0822f1 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -2630,7 +2630,7 @@ static int qe_udc_remove(struct platform_device *ofdev)
struct qe_udc *udc = platform_get_drvdata(ofdev);
struct qe_ep *ep;
unsigned int size;
-   DECLARE_COMPLETION(done);
+   DECLARE_COMPLETION_ONSTACK(done);

usb_del_gadget_udc(udc-gadget);

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 2df8074..c3830ad 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2529,7 +2529,7 @@ static int __exit fsl_udc_remove(struct platform_device 
*pdev)
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct fsl_usb2_platform_data *pdata = dev_get_platdata(pdev-dev);

-   DECLARE_COMPLETION(done);
+   DECLARE_COMPLETION_ONSTACK(done);

if (!udc_controller)
return -ENODEV;
--
1.7.10.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: [PATCH v2] renesas_usbhs: fix platform init error message

On Fri, Dec 19, 2014 at 03:46:41PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 12/19/2014 4:33 AM, yoshihiro shimoda wrote:
 
 [...]
 
 There is a typo (prove instead of probe) in the error message 
 printed when
 the platform initialization fails. Replace that word with more fitting 
 init.
 
 Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
 
 this actually goes through me, I'll take it in a bit.
 
  Er, OK. Could you update MAINTAINERS?
 
 there is no entry for renesas driver in MAINTAINERS.
 
 Shimoda-san, care to send a patch adding yourself or Morimoto-san as
 maintainers for Renesas driver and pointing to my tree in kernel.org ?
 
 I would like to move the renesas_usbhs driver to drivers/usb/gadget/udc 
 somehow.
 Because the driver is almost used for a gadget driver.
 The driver has a host driver support now. But, it is not used recently.
 
 After that, this MAINTAINERS issue becomes clear, I think.
 Felipe-san and Sergei-san, what do you think?
 
  I'm against such move.
 
 Thank you for the reply. But, I would like to know why you are against such 
 move.
 
Because we still need the host mode; RZ/A1H (R7S72100) SoC should need it
 soon), and bi-modal USBHS hardware is better placed in its own directory.

yeah, I'll agree with Sergei here. All other dual role IPs have their
own directories (musb, dwc3, dwc2, isp1760, chipidea...).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2] renesas_usbhs: fix platform init error message

On Fri, Dec 12, 2014 at 10:45:26PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 11/05/2014 01:53 AM, Felipe Balbi wrote:
 
 There is a typo (prove instead of probe) in the error message printed 
 when
 the platform initialization fails. Replace that word with more fitting 
 init.
 
 Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
 
 this actually goes through me, I'll take it in a bit.
 
Felipe, I'm not seeing this patch anywhere in your tree. :-(

it's now on testing/next

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

Hi Peter,

Thanks for the review.

On Tue, Dec 23, 2014 at 09:25:18AM +0800, Peter Chen wrote:
 On Mon, Dec 22, 2014 at 02:43:37PM -0800, David Cohen wrote:
  Some platforms have an USB OTG port fully (or partially) controlled by
  GPIOs:
  
  (1) USB ID is connected directly to GPIO
  
  Optionally:
  (2) VBUS is enabled by a GPIO (when ID is grounded)
  (3) Platform has 2 USB controllers connected to same port: one for
  device and one for host role. D+/- are switched between phys
  by GPIO.
 
 Would you explain how it works? Choosing controller runtime?

Both controllers are (indirectly) connected to the same micro B port.
The D+/- goes from the port to a switch operated by a GPIO. From the
switch, D+/- may go to Host controller's phy or Device controller's phy.
Depends on the GPIO level.

 
  
  As per initial version, this driver has the duty to control whether
  USB-Host cable is plugged in or not:
 
 You mean Micro-AB cable, right?

In my case I'd say micro B. But USB-Host would be any cable or
combination of cables where USB ID is grounded.

 
   - If yes, OTG port is configured for host role
   - If no, by standard, the OTG port is configured for device role
  
  Signed-off-by: David Cohen david.a.co...@linux.intel.com
  ---
  
  Hi,
  
  Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
   - The USB ID pin is connected directly to GPIO on SoC
   - When in host role, VBUS is provided by enabling a GPIO
   - Device and host roles are supported by 2 independent controllers with 
  D+/-
 pins from port switched between different phys according a GPIO level.
  
  The ACPI table describes this USB port as a (virtual) device with all the
  necessary GPIOs. This driver implements support to this virtual device as an
  extcon class driver. All drivers that depend on the USB OTG port state (USB 
  phy,
  PMIC, charge detection) will listen to extcon events.
  
  Comments are welcome.
  
  Br, David
  ---
  
   drivers/extcon/Kconfig   |   8 ++
   drivers/extcon/Makefile  |   1 +
   drivers/extcon/extcon-otg_gpio.c | 200 
  +++
   3 files changed, 209 insertions(+)
   create mode 100644 drivers/extcon/extcon-otg_gpio.c
  
  diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
  index 6a1f7de6fa54..e8010cda4642 100644
  --- a/drivers/extcon/Kconfig
  +++ b/drivers/extcon/Kconfig
  @@ -93,4 +93,12 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
   
  +config EXTCON_OTG_GPIO
  +   tristate VIRTUAL USB OTG PORT support
  +   depends on GPIOLIB
  +   help
  + Say Y here to enable support for virtual USB OTG port device
  + controlled by GPIOs. This driver can be used when at least USB ID pin
  + is connected directly to GPIO.
  +
   endif # MULTISTATE_SWITCH
  diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
  index 0370b42e5a27..9e81088c6584 100644
  --- a/drivers/extcon/Makefile
  +++ b/drivers/extcon/Makefile
  @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
   obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
   obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
   obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
  +obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
  diff --git a/drivers/extcon/extcon-otg_gpio.c 
  b/drivers/extcon/extcon-otg_gpio.c
  new file mode 100644
  index ..c5ee765a5f4f
  --- /dev/null
  +++ b/drivers/extcon/extcon-otg_gpio.c
  @@ -0,0 +1,200 @@
  +/*
  + * Virtual USB OTG Port driver controlled by gpios
  + *
  + * Copyright (c) 2014, Intel Corporation.
  + * Author: David Cohen david.a.co...@linux.intel.com
  + *
  + * 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.
  + *
  + * This program is distributed in the hope that it will be useful,
  + * but WITHOUT ANY WARRANTY; without even the implied warranty of
  + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  + * GNU General Public License for more details.
  + */
  +
  +#include linux/acpi.h
  +#include linux/extcon.h
  +#include linux/gpio.h
  +#include linux/interrupt.h
  +#include linux/platform_device.h
  +
  +#define DRV_NAME   usb_otg_port
  +
  +struct vuport {
  +   struct device *dev;
  +   struct gpio_desc *gpio_vbus_en;
  +   struct gpio_desc *gpio_usb_id;
  +   struct gpio_desc *gpio_usb_mux;
  +
  +   struct extcon_dev edev;
  +};
  +
  +static const char *const vuport_extcon_cable[] = {
  +   [0] = USB-Host,
  +   NULL,
  +};
  +
  +/*
  + * If id == 1, USB port should be set to peripheral
  + * if id == 0, USB port should be set to host
  + *
  + * Peripheral: set USB mux to peripheral and disable VBUS
  + * Host: set USB mux to host and enable VBUS
  + */
  +static void vuport_set_port(struct vuport *vup, int id)
  +{

Re: usb: musb: Scheduling of interrupt endpoints

2014-12-23 Thread Carsten Behling


The following comment can be found in 'musb_schedule()':

'* REVISIT what we really want here is a regular schedule tree
 * like e.g. OHCI uses.'

So I assume the best practice would be to make an implementation based
on the code in in ohci-q.c. And it would be waste of time to port the old
interrupt endpoint scheduling feature of TI.

Am I right?

On 12/23/2014 08:59 AM, Carsten Behling wrote:
Would it help if I send a patch as a suggestion and as basis for 
discussion?


On 12/19/2014 01:38 PM, Carsten Behling wrote:

Hi all,

Long time ago, TI shipped a kernel named 
linux-2.6.32.17-psp03.01.01.39 with an additional kernel option

for scheduling of interrupt endpoints.

AFAIK, this seems to be the only possibility to attach more that 4 in 
endpoints to MUSB (at least on a DM368).


This feature reserves one hardware endpoint unit to time schedule 
interrupt in endpoints based

on its bInterval value triggered by the SOF interrupt.

I didn't find any discussion about adding such a feature to the 
mainline kernel.
IMHO, this feature is absolutely necessary. But there may be reasons, 
not to add it (e.g. CPU load).


Please let me know your thoughts and ideas.

Best regards
-Carsten





--
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] renesas_usbhs: fix platform init error message

2014-12-23 Thread Sergei Shtylyov


Hello.

On 12/23/2014 10:17 PM, Felipe Balbi wrote:

[...]


There is a typo (prove instead of probe) in the error message printed when
the platform initialization fails. Replace that word with more fitting init.



Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com



this actually goes through me, I'll take it in a bit.



 Er, OK. Could you update MAINTAINERS?



there is no entry for renesas driver in MAINTAINERS.



Shimoda-san, care to send a patch adding yourself or Morimoto-san as
maintainers for Renesas driver and pointing to my tree in kernel.org ?



I would like to move the renesas_usbhs driver to drivers/usb/gadget/udc somehow.
Because the driver is almost used for a gadget driver.
The driver has a host driver support now. But, it is not used recently.



After that, this MAINTAINERS issue becomes clear, I think.
Felipe-san and Sergei-san, what do you think?



 I'm against such move.



Thank you for the reply. But, I would like to know why you are against such 
move.



Because we still need the host mode; RZ/A1H (R7S72100) SoC should need it
soon), and bi-modal USBHS hardware is better placed in its own directory.



yeah, I'll agree with Sergei here. All other dual role IPs have their


   Thanks. :-)


own directories (musb, dwc3, dwc2, isp1760, chipidea...).


   However, I'm only seeing ISP1760 files in drivers/usb/host/...

WBR, Sergei

--
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: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

Hi Sergei,

On Tue, Dec 23, 2014 at 04:10:44PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 12/23/2014 1:43 AM, David Cohen wrote:
 
 Some platforms have an USB OTG port fully (or partially) controlled by
 GPIOs:
 
 (1) USB ID is connected directly to GPIO
 
 Optionally:
 (2) VBUS is enabled by a GPIO (when ID is grounded)
 
Can't the host driver still control Vbus?

I can't a clean way for host driver to control VBUS considering it
depends on USB ID.

 
 (3) Platform has 2 USB controllers connected to same port: one for
  device and one for host role. D+/- are switched between phys
  by GPIO.
 
 As per initial version, this driver has the duty to control whether
 USB-Host cable is plugged in or not:
   - If yes, OTG port is configured for host role
   - If no, by standard, the OTG port is configured for device role
 
 Signed-off-by: David Cohen david.a.co...@linux.intel.com
 ---
 
 Hi,
 
 Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
   - The USB ID pin is connected directly to GPIO on SoC
   - When in host role, VBUS is provided by enabling a GPIO
   - Device and host roles are supported by 2 independent controllers with 
  D+/-
 pins from port switched between different phys according a GPIO level.
 
 The ACPI table describes this USB port as a (virtual) device with all the
 necessary GPIOs. This driver implements support to this virtual device as an
 extcon class driver. All drivers that depend on the USB OTG port state (USB 
 phy,
 PMIC, charge detection) will listen to extcon events.
 
It's very close to my setup on R-Car R8A7791 based boards. :-)
 I have already submitted Maxim MAX3355 OTG chip GPIO-based driver.

Hm. I'll look for it. Thanks for pointing.

 
 Comments are welcome.
 
 Br, David
 ---
 
   drivers/extcon/Kconfig   |   8 ++
   drivers/extcon/Makefile  |   1 +
   drivers/extcon/extcon-otg_gpio.c | 200 
  +++
   3 files changed, 209 insertions(+)
   create mode 100644 drivers/extcon/extcon-otg_gpio.c
 
 diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
 index 6a1f7de6fa54..e8010cda4642 100644
 --- a/drivers/extcon/Kconfig
 +++ b/drivers/extcon/Kconfig
 @@ -93,4 +93,12 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
 
 +config EXTCON_OTG_GPIO
 +tristate VIRTUAL USB OTG PORT support
 +depends on GPIOLIB
 +help
 +  Say Y here to enable support for virtual USB OTG port device
 +  controlled by GPIOs. This driver can be used when at least USB ID pin
 +  is connected directly to GPIO.
 +
 
The entries in this file seem alphabetically sorted.

I'll fix it.

 
   endif # MULTISTATE_SWITCH
 diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
 index 0370b42e5a27..9e81088c6584 100644
 --- a/drivers/extcon/Makefile
 +++ b/drivers/extcon/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
   obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
   obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
   obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
 +obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
 
The lines here are sorted too.

Ditto.

 
 diff --git a/drivers/extcon/extcon-otg_gpio.c 
 b/drivers/extcon/extcon-otg_gpio.c
 new file mode 100644
 index ..c5ee765a5f4f
 --- /dev/null
 +++ b/drivers/extcon/extcon-otg_gpio.c
 @@ -0,0 +1,200 @@
 [...]
 +static irqreturn_t vuport_isr(int irq, void *priv)
 +{
 +return IRQ_WAKE_THREAD;
 +}
 
It's the same as the default IRQ handler...
 
 +ret = devm_request_threaded_irq(dev, gpiod_to_irq(vup-gpio_usb_id),
 +vuport_isr, vuport_thread_isr,
 
... so you probably can just pass NULL instead of vuport_isr, no?

I'll review that.

 
 [...]
 
 +static int __init vuport_init(void)
 +{
 +return platform_driver_register(vuport_driver);
 +}
 +subsys_initcall(vuport_init);
 
Hm, why?

We have drivers that depend on this one during their probe.

Br, David

 
 WBR, Sergei
 
--
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: [xhci_hcd] USB3 device unplug breaks system suspend

On Tue, 23 Dec 2014, Tobias Jakobi wrote:

  I don't know what would be appropriate.  Someone more familiar with the 
  xhci-hcd driver might be able to help.
  
  It's not always easy to tell why a device sends a wakeup signal.
 Hmm, I got the impression that this issue is very similar to the
 spurious wakeup problem when doing a system shutdown (and then the
 system just reboots). Only just that this affects suspend and not shutdown.

It may be very similar to that...  I have no way to tell.  It also may
be a problem in the ACPI subsystem, or in the BIOS.

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: USB Creative Soundcard non-functioning on 3.13 kernel and above

On Mon, 22 Dec 2014 robton...@gmail.com wrote:

 Ok I tried that kernel option first, and that actually worked without issue. 
 I 
 then tried your patch without that kernel option set, and it also worked.  
 Finally I tried that kernel option =y with your patch, and it worked as well. 
  
 
 So with that said, is there any need to provide further logs as without the 
 patch seems to work?  If so I will provide.  

No need for logs.  Not using the Kconfig option would explain the 
peculiar things I saw.

I'm going to withhold the patch for now, as it could affect other 
people adversely.  Since the Kconfig option solves your problem, 
there's no real need for the patch.

 As always, thank you for your time.  

You're welcome.

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: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

2014-12-23 Thread Sergei Shtylyov


Hello.

On 12/23/2014 10:57 PM, David Cohen wrote:


Some platforms have an USB OTG port fully (or partially) controlled by
GPIOs:



(1) USB ID is connected directly to GPIO



Optionally:
(2) VBUS is enabled by a GPIO (when ID is grounded)



Can't the host driver still control Vbus?



I can't a clean way for host driver to control VBUS considering it
depends on USB ID.


   You're using the cable state notifiers, why not control Vbus from there?
You need some way of passing the GPIO to host driver though... I assume you're 
not using the device tree, and your host controllers live on PCI, so the 
platform data is out of question. You may be right then...



(3) Platform has 2 USB controllers connected to same port: one for
 device and one for host role. D+/- are switched between phys
 by GPIO.



As per initial version, this driver has the duty to control whether
USB-Host cable is plugged in or not:
  - If yes, OTG port is configured for host role
  - If no, by standard, the OTG port is configured for device role



Signed-off-by: David Cohen david.a.co...@linux.intel.com
---



Hi,



Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
  - The USB ID pin is connected directly to GPIO on SoC
  - When in host role, VBUS is provided by enabling a GPIO
  - Device and host roles are supported by 2 independent controllers with D+/-
pins from port switched between different phys according a GPIO level.



The ACPI table describes this USB port as a (virtual) device with all the
necessary GPIOs. This driver implements support to this virtual device as an
extcon class driver. All drivers that depend on the USB OTG port state (USB phy,
PMIC, charge detection) will listen to extcon events.



It's very close to my setup on R-Car R8A7791 based boards. :-)
I have already submitted Maxim MAX3355 OTG chip GPIO-based driver.



Hm. I'll look for it. Thanks for pointing.


   http://marc.info/?l=linux-usbm=141825413802370
   In my case, Vbus is not controlled via GPIO though. I would have probably 
used the generic GPIO extcon driver if I didn't have to drive MAX3355's SHDN# 
pin high...
   There were also some other patches for this issue, the one probably 
interesting to you is there:


   http://marc.info/?l=linux-usbm=141877180912359


Comments are welcome.



Br, David


[...]


+static int __init vuport_init(void)
+{
+   return platform_driver_register(vuport_driver);
+}
+subsys_initcall(vuport_init);



Hm, why?



We have drivers that depend on this one during their probe.


   What about deferred probing? With EPROBE_DEFER we don't need to play the 
initcall games any more AFAIU.



Br, David


WBR, Sergei

--
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: Query regarding root hub reset

On Tue, 23 Dec 2014, Peter Chen wrote:

  The Linux USB stack supports turning off port power only under a very 
  limited
  set of conditions.  For example, if the port is hard-wired or not connected 
  at all,
  and if remote wakeup is not required.
  
 
 Alan, any reasons/limitations we do not support it (by libusb)?

For the same reason we don't allow userspace to interfere with any
device: When a kernel driver is in charge of a device, any changes the
user wants to make must go through the driver.  If users were allowed
to make changes to a device without telling the driver, then the driver
would not be able to do its job properly.

In fact, it's only a coincidence that Deepak's libusb call is able to
succeed.  Hub control messages use USB_RECIP_OTHER instead of
USB_RECIP_INTERFACE, even though they are always meant to go to the hub 
interface.  If the messages used USB_RECIP_INTERFACE then the kernel 
would prevent libusb from sending the message unless the user program 
first claimed the hub interface (which would mean unbinding the 
kernel's hub driver).

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: usb: musb: Scheduling of interrupt endpoints

2014-12-23 Thread Carsten Behling


Hi Felipe,

On 12/23/2014 12:27 PM, Felipe Balbi wrote:

Hi,

On Tue, Dec 23, 2014 at 08:59:39AM -0600, Carsten Behling wrote:

Would it help if I send a patch as a suggestion and as basis for
discussion?

yes, it would also help if you didn't top-post :-)

So would you suggestion be to port that feature from the old 
linux-2.6.32.17-psp03.01.01.39
kernel from TI or should we rather add a tree based implementation as 
done for OHCI?


-Carsten
--
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: [DISCUSSION] USB device remote wakeup is not working for S3 case

On Tue, 23 Dec 2014, Du, Changbin wrote:

  You have to make sure that wakeup is also enabled for the host
  controller the device is attached to.  For some host controllers, it
  may also be necessary to enable wakeup for the root hub.
  
 Yes, the root-hub is not wakeup enabled by default, actually hub
 devices are not enabled. It works after I enable it via sysfs interface.

On some hardware, device wakeup requests can work even when root-hub 
wakeup is disabled -- it varies.

In general we do not want hubs to be enabled for wakeup.  If they were, 
then your computer would wake up the moment you unplugged a USB device.  
You would not be able to (for example) to put your laptop to sleep, 
unplug a USB mouse, and put the laptop in its case.

   Could we also enable wakeup for usb mouse? Or is there any concern to
  enable it?
   Per my opinion, most people may expect clicking mouse can awake system.
  
  It doesn't matter to me, but you should ask the people on the
  linux-input mailing list.
  
  Also, what about wakeup for a non-USB mouse?  Shouldn't that be enabled
  as well?
 Unfortunately the mouse I found are all of usb so cannot confirm it. The
 concern is if we want usb keyboard/mouse wakeup work by default, it does
 make sense only if the parent hubs are also enabled by default.  This is a 
 policy
 issue and may be better place it on userspace. I have no better idea :) .

As mentioned above, it depends on the hardware.

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 06/17] net2280: Remove restart_dma inline function definition

2014-12-23 Thread Ricardo Ribalda Delgado

Hello Felipe

I was waiting for more comments for the other patches and I forgot to
resend this patch.

I am on holidays and without access to a computer with the right
tools, nevertheless , since the changes are only on the commit message
I have modified the patch with vi.

I have been very careful, but I cannot try to apply it. If it does not
work, please feel free to modify it yourself (if you want) or wait
until I am back


Thanks!!!

On Tue, Dec 23, 2014 at 7:44 PM, Felipe Balbi ba...@ti.com wrote:
 On Fri, Nov 28, 2014 at 11:16:16PM +0300, Sergei Shtylyov wrote:
 On 11/28/2014 06:21 PM, Ricardo Ribalda Delgado wrote:

 Thanks for reviewing. I will fix it and resend it on the next version
 of the patchset to avoid spamming the ML

 I guess it is ok to add your Reviewed-by

Yes, if you like.

 Thanks!

Not at all. :-)

 [...]

 On 11/28/2014 04:50 PM, Ricardo Ribalda Delgado wrote:

 restart_dma is not used before it is declaration. Therefore we can

 s/it is/its/.

Also s/declaration/definition/.

 remove this definition.

 You're removing the declaration, not definition.

 do I get a new version of this patch ?

 --
 balbi



-- 
Ricardo Ribalda
--
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: Query regarding root hub reset

On Tue, 23 Dec 2014, Deepak Das wrote:

 On 22 December 2014 at 22:13, Alan Stern st...@rowland.harvard.edu wrote:
  On Mon, 22 Dec 2014, Deepak Das wrote:
 
  Can somebody please help me to find the test-case/use-case of
  following snippet of code in drivers/usb/core/hub.c:hub_port_connect()
  :-
 
  /* maybe switch power back on (e.g. root hub was reset) */
  if (hub_is_port_power_switchable(hub)
   !port_is_power_on(hub, portstatus))
  set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
 
  The use case is that for unknown reasons, the hub turned off power to
  the port.  I doubt that this case ever happens, though.
 
 Yes, this is really annoying. I am not able to think of any practical
 use-case of
 this code.

If you want to remove it, I don't think anybody will object.

  Our use case is to switch the power off on any hub port if hub
  supports per port power control but currently port is turned back ON
  due to above code snippet.
 
  You mustn't switch off port power; only the hub driver is allowed to do
  that.  If the power is switched off then the port won't work.
 
 
 Yes, Correct. port will not work but that is what we needed. We need to 
 provide
 userspace application control over port power for some specific requirement.
 Port will work again if we turn the port power back on.

Userspace can control the port power if you first unbind the hub 
driver.  In fact, I posted a program to do this years ago:

http://marc.info/?l=linux-usbm=127162615232234w=2

  The Linux USB stack supports turning off port power only under a very
  limited set of conditions.  For example, if the port is hard-wired or
  not connected at all, and if remote wakeup is not required.
 
 Yes, we don't need remote wakeup so if hub supports per port power control 
 then
 it should be turn on/off by using Set/clearPortFeature which is done by libusb
 control transfer function.
 By using libusb function we are just  following 11.11 Hub Port Power Control
 section of USB 2.0 spec which says it's possible by set/clearPortFeature.
 Please correct me If I misunderstood.

Just because the hardware is capable of doing something, that doesn't
mean the operating system will permit users to do it.

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: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

On Tue, Dec 23, 2014 at 11:09:44PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 12/23/2014 10:57 PM, David Cohen wrote:
 
 Some platforms have an USB OTG port fully (or partially) controlled by
 GPIOs:
 
 (1) USB ID is connected directly to GPIO
 
 Optionally:
 (2) VBUS is enabled by a GPIO (when ID is grounded)
 
 Can't the host driver still control Vbus?
 
 I can't a clean way for host driver to control VBUS considering it
 depends on USB ID.
 
You're using the cable state notifiers, why not control Vbus from there?
 You need some way of passing the GPIO to host driver though... I assume
 you're not using the device tree, and your host controllers live on PCI, so
 the platform data is out of question. You may be right then...

Yes to all questions :)

 
 (3) Platform has 2 USB controllers connected to same port: one for
  device and one for host role. D+/- are switched between phys
  by GPIO.
 
 As per initial version, this driver has the duty to control whether
 USB-Host cable is plugged in or not:
   - If yes, OTG port is configured for host role
   - If no, by standard, the OTG port is configured for device role
 
 Signed-off-by: David Cohen david.a.co...@linux.intel.com
 ---
 
 Hi,
 
 Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
   - The USB ID pin is connected directly to GPIO on SoC
   - When in host role, VBUS is provided by enabling a GPIO
   - Device and host roles are supported by 2 independent controllers with 
  D+/-
 pins from port switched between different phys according a GPIO level.
 
 The ACPI table describes this USB port as a (virtual) device with all the
 necessary GPIOs. This driver implements support to this virtual device as 
 an
 extcon class driver. All drivers that depend on the USB OTG port state 
 (USB phy,
 PMIC, charge detection) will listen to extcon events.
 
 It's very close to my setup on R-Car R8A7791 based boards. :-)
 I have already submitted Maxim MAX3355 OTG chip GPIO-based driver.
 
 Hm. I'll look for it. Thanks for pointing.
 
http://marc.info/?l=linux-usbm=141825413802370
In my case, Vbus is not controlled via GPIO though. I would have probably
 used the generic GPIO extcon driver if I didn't have to drive MAX3355's
 SHDN# pin high...

Besides the USB ID, I need to control VBUS and the D+/- switch. We have
a new use case coming soon that may need to add a second switch control.

There were also some other patches for this issue, the one probably
 interesting to you is there:
 
http://marc.info/?l=linux-usbm=141877180912359

This one is interesting, but I'm restricted to ACPI and to the DSDTs already
released.
E.g. http://www.androidauthority.com/trekstor-xintron-lollipop-564364/

Br, David

 
 Comments are welcome.
 
 Br, David
 
 [...]
 
 +static int __init vuport_init(void)
 +{
 +  return platform_driver_register(vuport_driver);
 +}
 +subsys_initcall(vuport_init);
 
 Hm, why?
 
 We have drivers that depend on this one during their probe.
 
What about deferred probing? With EPROBE_DEFER we don't need to play the
 initcall games any more AFAIU.
 
 Br, David
 
 WBR, Sergei
 
--
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 v5] usb: gadget: f_fs: add no_disconnect mode

On Tue, Dec 23, 2014 at 12:48:58PM -0600, Felipe Balbi wrote:
 On Thu, Dec 18, 2014 at 09:55:10AM +0100, Robert Baldyga wrote:
  Since we can compose gadgets from many functions, there is the problem
  related to gadget breakage while FunctionFS daemon being closed. FFS
  function is userspace code so there is no way to know when it will close
  files (it doesn't matter what is the reason of this situation, it can
  be daemon logic, program breakage, process kill or any other). So when
  we have another function in gadget which, for example, sends some amount
  of data, does some software update or implements some real-time 
  functionality,
  we may want to keep the gadget connected despite FFS function is no longer
  functional.
  
  We can't just remove one of functions from gadget since it has been
  enumerated, so the only way to keep entire gadget working is to make
  broken FFS function deactivated but still visible to host. For this
  purpose this patch introduces no_disconnect mode. It can be enabled
  by setting mount option no_disconnect=1, and results with defering
  function disconnect to the moment of reopen ep0 file or filesystem
  unmount. After closing all endpoint files, FunctionFS is set to state
  FFS_DEACTIVATED.
  
  When ffs-state == FFS_DEACTIVATED:
  - function is still bound and visible to host,
  - setup requests are automatically stalled,
  - transfers on other endpoints are refused,
  - epfiles, except ep0, are deleted from the filesystem,
  - opening ep0 causes the function to be closed, and then FunctionFS
is ready for descriptors and string write,
  - altsetting change causes the function to be closed - we want to keep
function alive until another functions are potentialy used, altsetting
change means that another configuration is being selected or USB cable
was unplugged, which indicates that we don't need to stay longer in
FFS_DEACTIVATED state
  - unmounting of the FunctionFS instance causes the function to be closed.
  
  Signed-off-by: Robert Baldyga r.bald...@samsung.com
 
 David, can you test it with your setup ?

Works fine on my side.
Tested-by: David Cohen david.a.co...@linux.intel.com

 
 cheers
 
 -- 
 balbi


--
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: Kernel 3.17.x Attaching Keyspan 4-Port Serial to USB Adapter Causes Kernel Panic

2014-12-23 Thread Richard

 So the same kernel is used (3.17.4), but only the new system oopses?

Yes, using kernel.org's 3.17.4 on both systems, only the new Asus X99-A
based system oopses.  The older Asus P6X58D motherboard, running a very
similarly configured 3.17.4 kernel has no issues with  Keyspan USB adapter.

 This driver is a bit of a mess.
 Could you try the patch below and see if
 it fixes the problem?

Yes.  Thank you.  That fixes the issue.  I can now plug in the Keyspan
USB adapter to my new running system without the kernel freezing.  I
applied your patch to 3.17.7.   I have not yet tried it on 3.18.1.

Using minicom I tested the usb-serial devices and everything seems to work.

Richard



On 12/22/14 09:53, Johan Hovold wrote:
 [+CC: linux-usb ]
 
 On Sat, Dec 20, 2014 at 04:08:20PM -0800, Richard wrote:
 On a new Gentoo based system with Kernel.org Kernels 3.17.4 to 3.17.7
 when I physically plug the Keyspan 4-Port Serial to USB adapter into a
 usb port my system freezes with a unable to handle kernel NULL pointer
 deference message.

 My old system (also Gentoo based with Kernel.org 3.17.4) does not have
 this issue.  Both systems are using the USB_SERIAL_KEYSPAN_USA49W
 driver module.
 
 So the same kernel is used (3.17.4), but only the new system oopses?
 
 I tried booting into single user mode, using modprobe to load
 USB_SERIAL_KEYSPAN_USA49W.  lsmod shows the driver.  When I pluged the
 device in I receive the system freeze.  Below is what I copied off the
 console ...

 BUG:  Unable to handle kernel NULL pointer deference at 000...8c
 IP: [a006fbdd] usa49_instat_callback+0x4d/0xb0[keyspan]
 PGD 1037faa067 PUD 1038301067 PMD 0
 Oops: 0002 [#1] SMP
 Modules linked in: keyspan ezusb usbserial hid_generic ...
 
 This driver is a bit of a mess. Could you try the patch below and see if
 it fixes the problem?
 
 Thanks,
 Johan
 
 
From 3e98e15094be174d08dc31daab5c7b7791228515 Mon Sep 17 00:00:00 2001
 From: Johan Hovold jo...@kernel.org
 Date: Mon, 22 Dec 2014 18:39:39 +0100
 Subject: [PATCH] USB: keyspan: fix null-deref at probe
 
 Fix null-pointer dereference during probe if the interface-status
 completion handler is called before the individual ports have been set
 up.
 
 Reported-by: Richard richj...@pacbell.net
 Signed-off-by: Johan Hovold jo...@kernel.org
 ---
  drivers/usb/serial/keyspan.c | 20 +++-
  1 file changed, 15 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
 index 077c714f1285..e07b15ed5814 100644
 --- a/drivers/usb/serial/keyspan.c
 +++ b/drivers/usb/serial/keyspan.c
 @@ -410,6 +410,8 @@ static void   usa26_instat_callback(struct urb *urb)
   }
   port = serial-port[msg-port];
   p_priv = usb_get_serial_port_data(port);
 + if (!p_priv)
 + goto resubmit;
  
   /* Update handshaking pin state information */
   old_dcd_state = p_priv-dcd_state;
 @@ -420,7 +422,7 @@ static void   usa26_instat_callback(struct urb *urb)
  
   if (old_dcd_state != p_priv-dcd_state)
   tty_port_tty_hangup(port-port, true);
 -
 +resubmit:
   /* Resubmit urb so we continue receiving */
   err = usb_submit_urb(urb, GFP_ATOMIC);
   if (err != 0)
 @@ -527,6 +529,8 @@ static void   usa28_instat_callback(struct urb *urb)
   }
   port = serial-port[msg-port];
   p_priv = usb_get_serial_port_data(port);
 + if (!p_priv)
 + goto resubmit;
  
   /* Update handshaking pin state information */
   old_dcd_state = p_priv-dcd_state;
 @@ -537,7 +541,7 @@ static void   usa28_instat_callback(struct urb *urb)
  
   if (old_dcd_state != p_priv-dcd_state  old_dcd_state)
   tty_port_tty_hangup(port-port, true);
 -
 +resubmit:
   /* Resubmit urb so we continue receiving */
   err = usb_submit_urb(urb, GFP_ATOMIC);
   if (err != 0)
 @@ -607,6 +611,8 @@ static void   usa49_instat_callback(struct urb *urb)
   }
   port = serial-port[msg-portNumber];
   p_priv = usb_get_serial_port_data(port);
 + if (!p_priv)
 + goto resubmit;
  
   /* Update handshaking pin state information */
   old_dcd_state = p_priv-dcd_state;
 @@ -617,7 +623,7 @@ static void   usa49_instat_callback(struct urb *urb)
  
   if (old_dcd_state != p_priv-dcd_state  old_dcd_state)
   tty_port_tty_hangup(port-port, true);
 -
 +resubmit:
   /* Resubmit urb so we continue receiving */
   err = usb_submit_urb(urb, GFP_ATOMIC);
   if (err != 0)
 @@ -855,6 +861,8 @@ static void   usa90_instat_callback(struct urb *urb)
  
   port = serial-port[0];
   p_priv = usb_get_serial_port_data(port);
 + if (!p_priv)
 + goto resubmit;
  
   /* Update handshaking pin state information */
   old_dcd_state = p_priv-dcd_state;
 @@ -865,7 +873,7 @@ static void   usa90_instat_callback(struct urb *urb)
  
   if (old_dcd_state != p_priv-dcd_state  old_dcd_state)

Re: [PATCH 06/17] net2280: Remove restart_dma inline function definition

Hi,

(top-post :-)

On Tue, Dec 23, 2014 at 09:20:23PM +0100, Ricardo Ribalda Delgado wrote:
 Hello Felipe
 
 I was waiting for more comments for the other patches and I forgot to
 resend this patch.
 
 I am on holidays and without access to a computer with the right
 tools, nevertheless , since the changes are only on the commit message
 I have modified the patch with vi.
 
 I have been very careful, but I cannot try to apply it. If it does not
 work, please feel free to modify it yourself (if you want) or wait
 until I am back

I very much like this series, quite a bit of code removed and things
which were already default are now only option. Very good work. It's now
all on my testing/next

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: usb: musb: Scheduling of interrupt endpoints

Hi,

On Tue, Dec 23, 2014 at 02:16:57PM -0600, Carsten Behling wrote:
 On Tue, Dec 23, 2014 at 08:59:39AM -0600, Carsten Behling wrote:
 Would it help if I send a patch as a suggestion and as basis for
 discussion?
 yes, it would also help if you didn't top-post :-)
 
 So would you suggestion be to port that feature from the old
 linux-2.6.32.17-psp03.01.01.39
 kernel from TI or should we rather add a tree based implementation as done
 for OHCI?

quite frankly, I don't know and, because of my email domain, I can't
really say out loud what I really think about those old TI releases :-)

IMHO, the best thing would be to completely ignore old kernels and
have a critical look at that part of the code on MUSB Host. Right now,
MUSB has a really brain dead endpoint allocation algorithm and it only
works for bulk (dynamic allocation, that is). Interrupt and isochronous
are left out of dynamic allocation which, IMHO, makes no sense
what so ever.

I guess the users of MUSB would benefit a whole lot more if someone were
to redesign that logic altogether so that all endpoints can be
dynamically allocated.

One easy way to test things out is to attach a ton of hubs and several
USB Serial adapters to a single MUSB port. All hubs and all USB serial
adapters - of course, as long as you follow USB spec's limitation on
maximum tier level and maximum number of devices.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: usb: musb: Scheduling of interrupt endpoints

Hi,

A: No.
Q: Should I include quotations after my reply?

On Tue, Dec 23, 2014 at 01:39:14PM -0600, Carsten Behling wrote:
 The following comment can be found in 'musb_schedule()':
 
 '* REVISIT what we really want here is a regular schedule tree
  * like e.g. OHCI uses.'
 
 So I assume the best practice would be to make an implementation based
 on the code in in ohci-q.c. And it would be waste of time to port the
 old interrupt endpoint scheduling feature of TI.
 
 Am I right?

Frankly, OHCI is a better example than TI's MUSB from 200 years ago,
that's correct :-)

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v5] usb: gadget: f_fs: add no_disconnect mode

On Tue, Dec 23, 2014 at 12:47:55PM -0800, David Cohen wrote:
 On Tue, Dec 23, 2014 at 12:48:58PM -0600, Felipe Balbi wrote:
  On Thu, Dec 18, 2014 at 09:55:10AM +0100, Robert Baldyga wrote:
   Since we can compose gadgets from many functions, there is the problem
   related to gadget breakage while FunctionFS daemon being closed. FFS
   function is userspace code so there is no way to know when it will close
   files (it doesn't matter what is the reason of this situation, it can
   be daemon logic, program breakage, process kill or any other). So when
   we have another function in gadget which, for example, sends some amount
   of data, does some software update or implements some real-time 
   functionality,
   we may want to keep the gadget connected despite FFS function is no longer
   functional.
   
   We can't just remove one of functions from gadget since it has been
   enumerated, so the only way to keep entire gadget working is to make
   broken FFS function deactivated but still visible to host. For this
   purpose this patch introduces no_disconnect mode. It can be enabled
   by setting mount option no_disconnect=1, and results with defering
   function disconnect to the moment of reopen ep0 file or filesystem
   unmount. After closing all endpoint files, FunctionFS is set to state
   FFS_DEACTIVATED.
   
   When ffs-state == FFS_DEACTIVATED:
   - function is still bound and visible to host,
   - setup requests are automatically stalled,
   - transfers on other endpoints are refused,
   - epfiles, except ep0, are deleted from the filesystem,
   - opening ep0 causes the function to be closed, and then FunctionFS
 is ready for descriptors and string write,
   - altsetting change causes the function to be closed - we want to keep
 function alive until another functions are potentialy used, altsetting
 change means that another configuration is being selected or USB cable
 was unplugged, which indicates that we don't need to stay longer in
 FFS_DEACTIVATED state
   - unmounting of the FunctionFS instance causes the function to be closed.
   
   Signed-off-by: Robert Baldyga r.bald...@samsung.com
  
  David, can you test it with your setup ?
 
 Works fine on my side.
 Tested-by: David Cohen david.a.co...@linux.intel.com

just to make sure, did you try with and without the new parameter ? I
remember someone complaining about regressions when the new parameter
was used.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [GIT PULL] USB patches

2014-12-23 Thread Greg KH

On Tue, Dec 23, 2014 at 10:53:11AM -0600, Felipe Balbi wrote:
 Hi Greg,
 
 Here's my first set of fixes for v3.19-rc cycle. An early
 Winter Solstice gift for you.
 
 All patches have gone through my 300 randconfigs (no build
 breakages or new warnings found) and I boot tested with
 AM437x SK, AM437x IDK, Beagle x15 and Beagle Bone Black.
 
 cheers
 
 The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
 
   Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
 tags/fixes-for-v3.19-rc2

Pulled and pushed out, 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: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

Hi,

On Mon, Dec 22, 2014 at 02:43:37PM -0800, David Cohen wrote:
 Some platforms have an USB OTG port fully (or partially) controlled by
 GPIOs:
 
 (1) USB ID is connected directly to GPIO
 
 Optionally:
 (2) VBUS is enabled by a GPIO (when ID is grounded)

ok, so a fixed regulator with a GPIO enable pin.

 (3) Platform has 2 USB controllers connected to same port: one for
 device and one for host role. D+/- are switched between phys
 by GPIO.

so you have discrete mux with a GPIO select signal, like below ?


 .---..  ..
 |   ||  ||  D+
 |   ||  ||-.
 |   ||  ||  |
 |   |USB Host--|P   |  |
 |   ||  |H   |  |
 |   ||  |Y   |D-|
 |   ''  |0   |.|
 |   |   || ||
 |   |   ''  ..  D+
 |   |   ||--
 |   SOCGPIO | -||
 |   |   |   MUX  |
 |   |   ||--
 |   |   ..  ''  D-
 |   ..  ||   D-  |  |
 |   ||  |P   |--'  |
 |   ||  |H   |  |
 |   ||  |Y   |  |
 |   |   USB Device   --|1   |  |
 |   ||  ||  D+  |
 |   ||  ||-'
 |   ||  ||
 '---''  ''

I have been on and off about writing a pinctrl-gpio.c driver which would
allow us to hide this detail from users. It shouldn't really matter
which modes are available behind the mux, but we should be able to tell
the mux to go into mode 0 or mode 1 by toggling its select signal. And
it shouldn't really matter that we have a GPIO pin. The problem is: I
don't really know if pinctrl would be able to handle discrete muxes.

Adding Linus W to ask. Linus, what do you think ? Should we have a
pinctrl-gpio.c for such cases ? In TI we too have quite a few boards
which different modes hidden behind discrete muxes.

 As per initial version, this driver has the duty to control whether
 USB-Host cable is plugged in or not:
  - If yes, OTG port is configured for host role
  - If no, by standard, the OTG port is configured for device role

correct, this default-B is mandated by OTG spec anyway.

 Signed-off-by: David Cohen david.a.co...@linux.intel.com
 ---
 
 Hi,
 
 Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
  - The USB ID pin is connected directly to GPIO on SoC
  - When in host role, VBUS is provided by enabling a GPIO
  - Device and host roles are supported by 2 independent controllers with D+/-
pins from port switched between different phys according a GPIO level.
 
 The ACPI table describes this USB port as a (virtual) device with all the
 necessary GPIOs. This driver implements support to this virtual device as an
 extcon class driver. All drivers that depend on the USB OTG port state (USB 
 phy,
 PMIC, charge detection) will listen to extcon events.

Right I think you're almost there, but I still think that this needs to
be a bit broken down. First, we need some generic DRD library under
drivers/usb/common, and that should be the one listening to extcon cable
events. But your extcon driver should be doing only that: checking which
cable was attached, it shouldn't be doing the switch by itself. That
should be part of the DRD library.

That DRD library would also be the one enabling the (optional) VBUS
regulator.

George Cherian tried to implement a generic DRD library but I think
there are still too many changes happening on usbcore and udc-core. Most
of the pieces are already there (usb_del_hcd() and usb_del_gadget_udc()
know how to properly unload an hcd/udc), but there are details missing,
no doubt.

If we can find a way to broadcast (probably not the best term, but
whatever) a Hey ID pin was just grounded message, we can get things
working.

That message, btw, shouldn't really depend on extcon-gpio alone because
other platforms might use non-gpio methods to verify ID pin level. In
any case, we need to have generic ID_PIN_LOW and ID_PIN_HIGH messages
that a generic DRD library can listen to and load/unload the correct
drivers by means of usb_{add,del}_{hcd,gadget_udc}().

With that in mind, I think you can use extcon-gpio.c for your purposes
if the other pieces can be fullfilled by regulator and pinctrl.

 diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
 index 0370b42e5a27..9e81088c6584 100644
 --- a/drivers/extcon/Makefile
 +++ b/drivers/extcon/Makefile
 @@ -12,3 +12,4 @@

Re: [PATCH v2 05/22] usb: isp1760: Merge platform and OF glue codes

On Tue, Dec 23, 2014 at 12:47:42PM -0600, Felipe Balbi wrote:
 On Mon, Dec 01, 2014 at 09:47:06PM +0200, Laurent Pinchart wrote:
  Both handle platform devices, merge them.
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 
 doesn't apply:
 
 checking file drivers/usb/host/isp1760-if.c
 Hunk #1 FAILED at 12.
 Hunk #2 succeeded at 304 (offset -1 lines).
 Hunk #3 succeeded at 332 (offset -1 lines).
 Hunk #4 succeeded at 404 (offset -1 lines).
 Hunk #5 succeeded at 431 (offset -1 lines).
 Hunk #6 succeeded at 446 (offset -1 lines).
 1 out of 6 hunks FAILED
 
 please rebase on my testig/next, just wait some 15 minutes before
 rebasing :-)

oh, and after you rebase, can you add a patch moving this outside of the
host directory too ? Now that this is DRD, it doesn't make sense to keep
it under drivers/usb/host.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2] renesas_usbhs: fix platform init error message

On Tue, Dec 23, 2014 at 10:41:49PM +0300, Sergei Shtylyov wrote:
 Hello.
 
 On 12/23/2014 10:17 PM, Felipe Balbi wrote:
 
 [...]
 
 There is a typo (prove instead of probe) in the error message 
 printed when
 the platform initialization fails. Replace that word with more 
 fitting init.
 
 Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
 
 this actually goes through me, I'll take it in a bit.
 
  Er, OK. Could you update MAINTAINERS?
 
 there is no entry for renesas driver in MAINTAINERS.
 
 Shimoda-san, care to send a patch adding yourself or Morimoto-san as
 maintainers for Renesas driver and pointing to my tree in kernel.org ?
 
 I would like to move the renesas_usbhs driver to drivers/usb/gadget/udc 
 somehow.
 Because the driver is almost used for a gadget driver.
 The driver has a host driver support now. But, it is not used recently.
 
 After that, this MAINTAINERS issue becomes clear, I think.
 Felipe-san and Sergei-san, what do you think?
 
  I'm against such move.
 
 Thank you for the reply. But, I would like to know why you are against 
 such move.
 
 Because we still need the host mode; RZ/A1H (R7S72100) SoC should need 
  it
 soon), and bi-modal USBHS hardware is better placed in its own directory.
 
 yeah, I'll agree with Sergei here. All other dual role IPs have their
 
Thanks. :-)
 
 own directories (musb, dwc3, dwc2, isp1760, chipidea...).
 
However, I'm only seeing ISP1760 files in drivers/usb/host/...

There are patches pending :-) But now that I look at it, Laurent added
peripheral support but kept the thing under drivers/usb/host. I asked
him to move it out from there.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] USB: gadget: udc: atmel: fix possible oops when unloading module

2014-12-23 Thread Wu, Songjun



在 12/24/2014 00:24, Felipe Balbi 写道:

On Mon, Dec 22, 2014 at 05:26:14PM +0800, Songjun Wu wrote:

When unloading the module, the urb request will be dequeued
and the completion routine will be excuted.
If no urb packet, the urb request will not be added to the endpoint queue
and the completion routine pointer in urb request is NULL.
Accessing to the NULL function pointer will cause the oops issue.
Add the code to check the urb request is in the endpoint queue or not.
If the urb request is not in the endpoint queue, a negative error code
will be returned.


have you triggered the NULL pointer oops ? Care to add it to the commit
log.


Executing the 'insmod g_hid.ko', then executing the 'rmmod g_hid.ko', 
the NULL pointer oops will be triggered.




Also, which commit is this fixing ? Does this need to be backported ?
When was the bug introduced ?


Signed-off-by: Songjun Wu songjun...@atmel.com
---
  drivers/usb/gadget/udc/atmel_usba_udc.c |   12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index ce88237..48629cc 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -828,7 +828,7 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct 
usb_request *_req)
  {
struct usba_ep *ep = to_usba_ep(_ep);
struct usba_udc *udc = ep-udc;
-   struct usba_request *req = to_usba_req(_req);
+   struct usba_request *req;
unsigned long flags;
u32 status;

@@ -837,6 +837,16 @@ static int usba_ep_dequeue(struct usb_ep *_ep, struct 
usb_request *_req)

spin_lock_irqsave(udc-lock, flags);

+   list_for_each_entry(req, ep-queue, queue) {
+   if (req-req == _req)
+   break;
+   }
+
+   if (req-req != _req) {
+   spin_unlock_irqrestore(udc-lock, flags);
+   return -EINVAL;
+   }
+
if (req-using_dma) {
/*
 * If this request is currently being transferred,
--
1.7.9.5




--
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 Creative Soundcard non-functioning on 3.13 kernel and above

2014-12-23 Thread robtongue

On Tuesday 23 December 2014 15:06:17 Alan Stern wrote:
 On Mon, 22 Dec 2014 robton...@gmail.com wrote:
  Ok I tried that kernel option first, and that actually worked without
  issue. I then tried your patch without that kernel option set, and it
  also worked. Finally I tried that kernel option =y with your patch, and
  it worked as well.
  
  So with that said, is there any need to provide further logs as without
  the
  patch seems to work?  If so I will provide.
 
 No need for logs.  Not using the Kconfig option would explain the
 peculiar things I saw.
 
 I'm going to withhold the patch for now, as it could affect other
 people adversely.  Since the Kconfig option solves your problem,
 there's no real need for the patch.
 
  As always, thank you for your time.
 
 You're welcome.
 
 Alan Stern

I will go ahead and file a bug with the gentoo devs to discuss this kernel 
option being set by default in their package.  As long as the benefit outweighs 
the cost.  If you tell me it should be set, then it should be set.  
--
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: Query regarding root hub reset

On Tue, Dec 23, 2014 at 03:15:45PM -0500, Alan Stern wrote:
 On Tue, 23 Dec 2014, Peter Chen wrote:
 
   The Linux USB stack supports turning off port power only under a very 
   limited
   set of conditions.  For example, if the port is hard-wired or not 
   connected at all,
   and if remote wakeup is not required.
   
  
  Alan, any reasons/limitations we do not support it (by libusb)?
 
 For the same reason we don't allow userspace to interfere with any
 device: When a kernel driver is in charge of a device, any changes the
 user wants to make must go through the driver.  If users were allowed
 to make changes to a device without telling the driver, then the driver
 would not be able to do its job properly.

Why we can't turn port power off without unbinding driver?
I see we can reset device at devio, why we can reset a device, but
can't turn its port off?

 
 In fact, it's only a coincidence that Deepak's libusb call is able to
 succeed.  Hub control messages use USB_RECIP_OTHER instead of
 USB_RECIP_INTERFACE, even though they are always meant to go to the hub 
 interface.  If the messages used USB_RECIP_INTERFACE then the kernel 
 would prevent libusb from sending the message unless the user program 
 first claimed the hub interface (which would mean unbinding the 
 kernel's hub driver).
 

Some laptops turns off vbus during the system suspend, does the driver
is aware of it? 

-- 

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: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

On Tue, Dec 23, 2014 at 11:40:23AM -0800, David Cohen wrote:
 Hi Peter,
 
 Thanks for the review.
 
 On Tue, Dec 23, 2014 at 09:25:18AM +0800, Peter Chen wrote:
  On Mon, Dec 22, 2014 at 02:43:37PM -0800, David Cohen wrote:
   Some platforms have an USB OTG port fully (or partially) controlled by
   GPIOs:
   
   (1) USB ID is connected directly to GPIO
   
   Optionally:
   (2) VBUS is enabled by a GPIO (when ID is grounded)
   (3) Platform has 2 USB controllers connected to same port: one for
   device and one for host role. D+/- are switched between phys
   by GPIO.
  
  Would you explain how it works? Choosing controller runtime?
 
 Both controllers are (indirectly) connected to the same micro B port.
 The D+/- goes from the port to a switch operated by a GPIO. From the
 switch, D+/- may go to Host controller's phy or Device controller's phy.
 Depends on the GPIO level.
 

Get it, why the design like that? If your controller supports both
roles, the software can do role switch by ID pin (through gpio in your
case).

  
   
   As per initial version, this driver has the duty to control whether
   USB-Host cable is plugged in or not:
  
  You mean Micro-AB cable, right?
 
   +
   + vup-gpio_usb_mux = devm_gpiod_get_index(dev, usb mux,
   +  VUPORT_GPIO_USB_MUX);
   + if (IS_ERR(vup-gpio_usb_mux))
   + dev_info(dev, cannot request USB USB MUX, skipping it.\n);
  
  Using dev_err
 
 That's not really an error, although the IS_ERR() suggests otherwise.
 The driver works well if a board doesn't need this mux (I'll add a
 comment to state that clear). IMHO either keep dev_info or use dev_dgb
 instead?
 

If that, dev_dbg may be suitable.


-- 

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 1/1] Revert usb: chipidea: remove duplicate dev_set_drvdata for host_start

This reverts commit 14b4099c074f2ddf4d84b22d370170e61b527529

It moved platform_set_drvdata(pdev, ci) before hcd is created,
and the hcd will assign itself as ci controller's drvdata during
the hcd creation function (in usb_create_shared_hcd), so it
overwrites the real ci's drvdata which we want to use.

So, if the controller is at host mode, the system suspend
API will get the wrong struct ci_hdrc pointer, and cause the
oops.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/core.c | 2 +-
 drivers/usb/chipidea/host.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index e14eafb..4f3c5a0 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -669,7 +669,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ci)
return -ENOMEM;
 
-   platform_set_drvdata(pdev, ci);
ci-dev = dev;
ci-platdata = dev_get_platdata(dev);
ci-imx28_write_fix = !!(ci-platdata-flags 
@@ -783,6 +782,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
}
}
 
+   platform_set_drvdata(pdev, ci);
ret = devm_request_irq(dev, ci-irq, ci_irq, IRQF_SHARED,
ci-platdata-name, ci);
if (ret)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index c1694cf..48731d0 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -91,6 +91,7 @@ static int host_start(struct ci_hdrc *ci)
if (!hcd)
return -ENOMEM;
 
+   dev_set_drvdata(ci-dev, ci);
hcd-rsrc_start = ci-hw_bank.phys;
hcd-rsrc_len = ci-hw_bank.size;
hcd-regs = ci-hw_bank.abs;
-- 
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

[PATCH 0/1] usb: chipidea: one bug fix for v3.19

Hi Greg,

It causes oops during the system suspend routine at host mode sometimes.

Peter Chen (1):
  Revert usb: chipidea: remove duplicate dev_set_drvdata for
host_start

 drivers/usb/chipidea/core.c | 2 +-
 drivers/usb/chipidea/host.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

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

[PATCH] usb: gadget: ffs: Fix sparse error

2014-12-23 Thread Rohith Seelaboyina

This patch fixes the sparse error in functionfs
driver.

drivers/usb/gadget/function/f_fs.c:400:44: error: bad
constant experssion.

Dynamic memory allocation through kmalloc is more safer
than declaring variable array size, Fix this error by
using kmalloc for memory allocation, Check if memory
allocation is successful and return -ENOMEM on failure.

Signed-off-by: Rohith Seelaboyina rseelaboy...@nvidia.com
---
 drivers/usb/gadget/function/f_fs.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 63314ede7ba6..6ac50891b697 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -397,10 +397,15 @@ static ssize_t __ffs_ep0_read_events(struct ffs_data 
*ffs, char __user *buf,
 * We are holding ffs-ev.waitq.lock and ffs-mutex and we need
 * to release them.
 */
-   struct usb_functionfs_event events[n];
unsigned i = 0;
+   int ret;
+   struct usb_functionfs_event *events = kmalloc(n *
+   sizeof(struct usb_functionfs_event), GFP_KERNEL);
+
+   if (unlikely(!events))
+   return -ENOMEM;
 
-   memset(events, 0, sizeof events);
+   memset(events, 0, n * sizeof(*events));
 
do {
events[i].type = ffs-ev.types[i];
@@ -421,8 +426,10 @@ static ssize_t __ffs_ep0_read_events(struct ffs_data *ffs, 
char __user *buf,
spin_unlock_irq(ffs-ev.waitq.lock);
mutex_unlock(ffs-mutex);
 
-   return unlikely(__copy_to_user(buf, events, sizeof events))
-   ? -EFAULT : sizeof events;
+   ret = unlikely(__copy_to_user(buf, events, n * sizeof(*events)))
+   ? -EFAULT : n * sizeof(*events);
+   kfree(events);
+   return ret;
 }
 
 static ssize_t ffs_ep0_read(struct file *file, char __user *buf,
-- 
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] usb: gadget: ffs: Fix sparse error

2014-12-23 Thread Joe Perches

On Wed, 2014-12-24 at 10:59 +0530, Rohith Seelaboyina wrote:
 Dynamic memory allocation through kmalloc is more safer
 than declaring variable array size, Fix this error by
 using kmalloc for memory allocation, Check if memory
 allocation is successful and return -ENOMEM on failure.
[]
 diff --git a/drivers/usb/gadget/function/f_fs.c 
 b/drivers/usb/gadget/function/f_fs.c
[]
 @@ -397,10 +397,15 @@ static ssize_t __ffs_ep0_read_events(struct ffs_data 
 *ffs, char __user *buf,
* We are holding ffs-ev.waitq.lock and ffs-mutex and we need
* to release them.
*/
 - struct usb_functionfs_event events[n];
   unsigned i = 0;
 + int ret;
 + struct usb_functionfs_event *events = kmalloc(n *
 + sizeof(struct usb_functionfs_event), GFP_KERNEL);
 +
 + if (unlikely(!events))
 + return -ENOMEM;
  
 - memset(events, 0, sizeof events);
 + memset(events, 0, n * sizeof(*events));

kcalloc without memset please.


--
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/4] ARM: dts: Add hsotg node for exynos3250

This patch adds device tree node for hsotg to control USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 27d385f..204a84b 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -255,6 +255,17 @@
status = disabled;
};
 
+   hsotg: hsotg@1248 {
+   compatible = snps,dwc2;
+   reg = 0x1248 0x2;
+   interrupts = 0 141 0;
+   clocks = cmu CLK_USBOTG;
+   clock-names = otg;
+   phys = exynos_usbphy 0;
+   phy-names = usb2-phy;
+   status = disabled;
+   };
+
mshc_0: mshc@1251 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1251 0x1000;
-- 
1.7.9.5

--
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 3/4] ARM: dts: Enable USB node for exynos3250-rinato

This patch enables hsotg and usbphy node to use USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250-rinato.dts |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 80aa8b4..bf4c17b 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -125,6 +125,16 @@
};
 };
 
+exynos_usbphy {
+   status = okay;
+};
+
+hsotg {
+   vusb_d-supply = ldo15_reg;
+   vusb_a-supply = ldo12_reg;
+   status = okay;
+};
+
 i2c_0 {
#address-cells = 1;
#size-cells = 0;
-- 
1.7.9.5

--
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 4/4] ARM: dts: Enable USB node for exynos3250-monk

This patch adds device tree node for hsotg to control USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250-monk.dts |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-monk.dts 
b/arch/arm/boot/dts/exynos3250-monk.dts
index 24822aa..0c1d85d 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -134,6 +134,16 @@
};
 };
 
+exynos_usbphy {
+   status = okay;
+};
+
+hsotg {
+   vusb_d-supply = ldo15_reg;
+   vusb_a-supply = ldo12_reg;
+   status = okay;
+};
+
 i2c_0 {
#address-cells = 1;
#size-cells = 0;
-- 
1.7.9.5

--
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/4] ARM: dts: Add exynos_usbphy node for exynos3250

This patch adds device tree node for exynos_usbphy to use USB 2.0 Device.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 2246549..27d385f 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -279,6 +279,16 @@
status = disabled;
};
 
+   exynos_usbphy: exynos-usbphy@125B {
+   compatible = samsung,exynos3250-usb2-phy;
+   reg = 0x125B 0x100;
+   samsung,pmureg-phandle = pmu_system_controller;
+   clocks = cmu CLK_USBOTG, cmu CLK_SCLK_UPLL;
+   clock-names = phy, ref;
+   #phy-cells = 1;
+   status = disabled;
+   };
+
amba {
compatible = arm,amba-bus;
#address-cells = 1;
-- 
1.7.9.5

--
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 0/4] ARM: dts: Add USB node for exynos3250 SoC boards

This patch series adds USB device node and phy for exynos3250 SoC.
And enables for rinato and monk boards.

Changes in v2:
 - remove unnessasary property samsung,sysreg-phandle
 - change xusbxti clock to CLK_SCLK_UPLL

Jaewon Kim (4):
  ARM: dts: Add exynos_usbphy node for exynos3250
  ARM: dts: Add hsotg node for exynos3250
  ARM: dts: Enable USB node for exynos3250-rinato
  ARM: dts: Enable USB node for exynos3250-monk

 arch/arm/boot/dts/exynos3250-monk.dts   |   10 ++
 arch/arm/boot/dts/exynos3250-rinato.dts |   10 ++
 arch/arm/boot/dts/exynos3250.dtsi   |   21 +
 3 files changed, 41 insertions(+)

-- 
1.7.9.5

--
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 0/6] chipidea: add runtime pm and usb wakeup

Hi all,

This is enhancement for usb: chipidea: add runtime power management support
(http://www.spinics.net/lists/linux-usb/msg118987.html), it adds
- USB as wakeup source support
- Fix system hang when unload module
The runtime pm close the clock before access hardware registers.
- Fix system hang at boots up sometimes at some boards
The reason is disable PLL/USB PHY just after enable PLL/USB PHY,
we set two seconds autosuspend timer to fix this issue.

Since runtime pm will take the PHY enter low power mode and gate the controller 
clock,
if there is no related wakeup logic, the usb will can't be used any more, and 
wakeup
logic is different per vendor/platform, I only enable the platforms which I 
have tested.
For platforms who want to use runtime pm and usb as wakeup source, please 
enable it
at related glue layer driver.

Tested at imx6dl evk, imx6sl evk, and imx6sx evk.

Comments are welcome.

Peter Chen (6):
  usb: chipidea: add runtime power management support
  usb: chipidea: usbmisc_imx: add .set_wakeup interface
  usb: chipidea: imx: add runtime power management support
  usb: chipidea: add usb as system wakeup source
  usb: chipidea: imx: add usb as system wakeup source
  doc: usb: chipidea: add usb wakeup enable example

 Documentation/usb/chipidea.txt |  21 +++
 drivers/usb/chipidea/ci.h  |   6 ++
 drivers/usb/chipidea/ci_hdrc_imx.c | 119 +++--
 drivers/usb/chipidea/ci_hdrc_imx.h |   1 +
 drivers/usb/chipidea/core.c| 110 --
 drivers/usb/chipidea/otg.c |   2 +
 drivers/usb/chipidea/usbmisc_imx.c |  52 
 include/linux/usb/chipidea.h   |   1 +
 8 files changed, 300 insertions(+), 12 deletions(-)

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

[PATCH 3/6] usb: chipidea: imx: add runtime power management support

Add runtime pm support for imx, only imx6 series are supported and tested.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 106 ++---
 1 file changed, 100 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 353989e..5ad85fe 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -25,6 +25,7 @@
 
 struct ci_hdrc_imx_platform_flag {
unsigned int flags;
+   bool runtime_pm;
 };
 
 static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
@@ -34,9 +35,24 @@ static const struct ci_hdrc_imx_platform_flag imx28_usb_data 
= {
.flags = CI_HDRC_IMX28_WRITE_FIX,
 };
 
+static const struct ci_hdrc_imx_platform_flag imx6q_usb_data = {
+   .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+};
+
+static const struct ci_hdrc_imx_platform_flag imx6sl_usb_data = {
+   .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+};
+
+static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = {
+   .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+};
+
 static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
{ .compatible = fsl,imx28-usb, .data = imx28_usb_data},
{ .compatible = fsl,imx27-usb, .data = imx27_usb_data},
+   { .compatible = fsl,imx6q-usb, .data = imx6q_usb_data},
+   { .compatible = fsl,imx6sl-usb, .data = imx6sl_usb_data},
+   { .compatible = fsl,imx6sx-usb, .data = imx6sl_usb_data},
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
@@ -46,6 +62,8 @@ struct ci_hdrc_imx_data {
struct platform_device *ci_pdev;
struct clk *clk;
struct imx_usbmisc_data *usbmisc_data;
+   bool supports_runtime_pm;
+   bool in_lpm;
 };
 
 /* Common functions shared by usbmisc drivers */
@@ -144,6 +162,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
pdata.usb_phy = data-phy;
pdata.flags |= imx_platform_flag-flags;
+   if (pdata.flags  CI_HDRC_SUPPORTS_RUNTIME_PM)
+   data-supports_runtime_pm = true;
 
ret = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (ret)
@@ -174,8 +194,10 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, data);
 
-   pm_runtime_no_callbacks(pdev-dev);
-   pm_runtime_enable(pdev-dev);
+   if (data-supports_runtime_pm) {
+   pm_runtime_set_active(pdev-dev);
+   pm_runtime_enable(pdev-dev);
+   }
 
return 0;
 
@@ -190,14 +212,18 @@ static int ci_hdrc_imx_remove(struct platform_device 
*pdev)
 {
struct ci_hdrc_imx_data *data = platform_get_drvdata(pdev);
 
-   pm_runtime_disable(pdev-dev);
+   if (data-supports_runtime_pm) {
+   pm_runtime_get_sync(pdev-dev);
+   pm_runtime_disable(pdev-dev);
+   pm_runtime_put_noidle(pdev-dev);
+   }
ci_hdrc_remove_device(data-ci_pdev);
clk_disable_unprepare(data-clk);
 
return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 static int imx_controller_suspend(struct device *dev)
 {
struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
@@ -205,6 +231,7 @@ static int imx_controller_suspend(struct device *dev)
dev_dbg(dev, at %s\n, __func__);
 
clk_disable_unprepare(data-clk);
+   data-in_lpm = true;
 
return 0;
 }
@@ -212,25 +239,92 @@ static int imx_controller_suspend(struct device *dev)
 static int imx_controller_resume(struct device *dev)
 {
struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
 
dev_dbg(dev, at %s\n, __func__);
 
-   return clk_prepare_enable(data-clk);
+   if (!data-in_lpm) {
+   WARN_ON(1);
+   return 0;
+   }
+
+   ret = clk_prepare_enable(data-clk);
+   if (ret)
+   return ret;
+
+   data-in_lpm = false;
+
+   ret = imx_usbmisc_set_wakeup(data-usbmisc_data, false);
+   if (ret) {
+   dev_err(dev, usbmisc set_wakeup failed, ret=%d\n, ret);
+   goto clk_disable;
+   }
+
+   return 0;
+
+clk_disable:
+   clk_disable_unprepare(data-clk);
+   return ret;
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int ci_hdrc_imx_suspend(struct device *dev)
 {
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+
+   if (data-in_lpm)
+   /* The core's suspend doesn't run */
+   return 0;
+
return imx_controller_suspend(dev);
 }
 
 static int ci_hdrc_imx_resume(struct device *dev)
 {
-   return imx_controller_resume(dev);
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret;
+
+   ret = imx_controller_resume(dev);
+   if (!ret  data-supports_runtime_pm) {
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   }
+
+   return

[PATCH 2/6] usb: chipidea: usbmisc_imx: add .set_wakeup interface

This API is used to enable/disable usb wakeup, only imx6 series are
added, since I don't have other imx hardware on hand. Other imx users
can add their API according to reference manual after testing.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
 drivers/usb/chipidea/usbmisc_imx.c | 52 ++
 2 files changed, 53 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h 
b/drivers/usb/chipidea/ci_hdrc_imx.h
index 4ed828f..635717e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.h
+++ b/drivers/usb/chipidea/ci_hdrc_imx.h
@@ -22,5 +22,6 @@ struct imx_usbmisc_data {
 
 int imx_usbmisc_init(struct imx_usbmisc_data *);
 int imx_usbmisc_init_post(struct imx_usbmisc_data *);
+int imx_usbmisc_set_wakeup(struct imx_usbmisc_data *, bool);
 
 #endif /* __DRIVER_USB_CHIPIDEA_CI_HDRC_IMX_H */
diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index eb77e32..90b7d7f 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -55,6 +55,10 @@
 #define MX53_USB_PLL_DIV_24_MHZ0x01
 
 #define MX6_BM_OVER_CUR_DISBIT(7)
+#define MX6_BM_WAKEUP_ENABLE   BIT(10)
+#define MX6_BM_ID_WAKEUP   BIT(16)
+#define MX6_BM_VBUS_WAKEUP BIT(17)
+#define MX6_BM_WAKEUP_INTR BIT(31)
 
 #define VF610_OVER_CUR_DIS BIT(7)
 
@@ -63,6 +67,8 @@ struct usbmisc_ops {
int (*init)(struct imx_usbmisc_data *data);
/* It's called once after adding a usb device */
int (*post)(struct imx_usbmisc_data *data);
+   /* It's called when we need to enable/disable usb wakeup */
+   int (*set_wakeup)(struct imx_usbmisc_data *data, bool enabled);
 };
 
 struct imx_usbmisc {
@@ -202,6 +208,35 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data 
*data)
return 0;
 }
 
+static int usbmisc_imx6q_set_wakeup
+   (struct imx_usbmisc_data *data, bool enabled)
+{
+   struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
+   unsigned long flags;
+   u32 val;
+   u32 wakeup_setting = (MX6_BM_WAKEUP_ENABLE |
+   MX6_BM_VBUS_WAKEUP | MX6_BM_ID_WAKEUP);
+   int ret = 0;
+
+   if (data-index  3)
+   return -EINVAL;
+
+   spin_lock_irqsave(usbmisc-lock, flags);
+   val = readl(usbmisc-base + data-index * 4);
+   if (enabled) {
+   val |= wakeup_setting;
+   writel(val, usbmisc-base + data-index * 4);
+   } else {
+   if (val  MX6_BM_WAKEUP_INTR)
+   pr_debug(wakeup int at ci_hdrc.%d\n, data-index);
+   val = ~wakeup_setting;
+   writel(val, usbmisc-base + data-index * 4);
+   }
+   spin_unlock_irqrestore(usbmisc-lock, flags);
+
+   return ret;
+}
+
 static int usbmisc_imx6q_init(struct imx_usbmisc_data *data)
 {
struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
@@ -219,6 +254,8 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data *data)
spin_unlock_irqrestore(usbmisc-lock, flags);
}
 
+   usbmisc_imx6q_set_wakeup(data, false);
+
return 0;
 }
 
@@ -256,6 +293,7 @@ static const struct usbmisc_ops imx53_usbmisc_ops = {
 };
 
 static const struct usbmisc_ops imx6q_usbmisc_ops = {
+   .set_wakeup = usbmisc_imx6q_set_wakeup,
.init = usbmisc_imx6q_init,
 };
 
@@ -291,6 +329,20 @@ int imx_usbmisc_init_post(struct imx_usbmisc_data *data)
 }
 EXPORT_SYMBOL_GPL(imx_usbmisc_init_post);
 
+int imx_usbmisc_set_wakeup(struct imx_usbmisc_data *data, bool enabled)
+{
+   struct imx_usbmisc *usbmisc;
+
+   if (!data)
+   return 0;
+
+   usbmisc = dev_get_drvdata(data-dev);
+   if (!usbmisc-ops-set_wakeup)
+   return 0;
+   return usbmisc-ops-set_wakeup(data, enabled);
+}
+EXPORT_SYMBOL_GPL(imx_usbmisc_set_wakeup);
+
 static const struct of_device_id usbmisc_imx_dt_ids[] = {
{
.compatible = fsl,imx25-usbmisc,
-- 
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

[PATCH 5/6] usb: chipidea: imx: add usb as system wakeup source

Enable USB as system wakeup source, and each platform needs to implement
imx_usbmisc_set_wakeup in usbmisc_imx.c to support.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 5ad85fe..f7f9fd4 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -199,6 +199,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
pm_runtime_enable(pdev-dev);
}
 
+   device_set_wakeup_capable(pdev-dev, true);
+
return 0;
 
 disable_device:
@@ -270,12 +272,23 @@ clk_disable:
 #ifdef CONFIG_PM_SLEEP
 static int ci_hdrc_imx_suspend(struct device *dev)
 {
+   int ret;
+
struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
 
if (data-in_lpm)
/* The core's suspend doesn't run */
return 0;
 
+   if (device_may_wakeup(dev)) {
+   ret = imx_usbmisc_set_wakeup(data-usbmisc_data, true);
+   if (ret) {
+   dev_err(dev, usbmisc set_wakeup failed, ret=%d\n,
+   ret);
+   return ret;
+   }
+   }
+
return imx_controller_suspend(dev);
 }
 
-- 
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

[PATCH 4/6] usb: chipidea: add usb as system wakeup source

The USB signal can be system wakeup source, this patch add the
support, for how to enable it, see Documentation/usb/chipidea.txt.
Since USB wakeup enable logic is vendor/platform specific, the
glue layer needs to implement it to support this feature.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/core.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 63d2b39..6d9dc2d 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -808,6 +808,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (ci_otg_is_fsm_mode(ci))
ci_hdrc_otg_fsm_start(ci);
 
+   device_set_wakeup_capable(pdev-dev, true);
+
ret = dbg_create_files(ci);
if (!ret)
return 0;
@@ -898,6 +900,11 @@ static int ci_suspend(struct device *dev)
return 0;
}
 
+   if (device_may_wakeup(dev)) {
+   usb_phy_set_wakeup(ci-usb_phy, true);
+   enable_irq_wake(ci-irq);
+   }
+
ci_controller_suspend(ci);
 
return 0;
@@ -908,6 +915,9 @@ static int ci_resume(struct device *dev)
struct ci_hdrc *ci = dev_get_drvdata(dev);
int ret;
 
+   if (device_may_wakeup(dev))
+   disable_irq_wake(ci-irq);
+
ret = ci_controller_resume(dev);
if (ret)
return ret;
-- 
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

[PATCH 1/6] usb: chipidea: add runtime power management support

Add runtime power management support.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/ci.h|   6 +++
 drivers/usb/chipidea/core.c  | 100 ---
 drivers/usb/chipidea/otg.c   |   2 +
 include/linux/usb/chipidea.h |   1 +
 4 files changed, 103 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 65913d4..a0aeb8d 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -169,6 +169,9 @@ struct hw_bank {
  * @b_sess_valid_event: indicates there is a vbus event, and handled
  * at ci_otg_work
  * @imx28_write_fix: Freescale imx28 needs swp instruction for writing
+ * @supports_runtime_pm: if runtime pm is supported
+ * @in_lpm: if the core in low power mode
+ * @wakeup_int: if wakeup interrupt occur
  */
 struct ci_hdrc {
struct device   *dev;
@@ -211,6 +214,9 @@ struct ci_hdrc {
boolid_event;
boolb_sess_valid_event;
boolimx28_write_fix;
+   boolsupports_runtime_pm;
+   boolin_lpm;
+   boolwakeup_int;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a57dc88..63d2b39 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -491,6 +491,13 @@ static irqreturn_t ci_irq(int irq, void *data)
irqreturn_t ret = IRQ_NONE;
u32 otgsc = 0;
 
+   if (ci-in_lpm) {
+   disable_irq_nosync(irq);
+   ci-wakeup_int = true;
+   pm_runtime_get(ci-dev);
+   return IRQ_HANDLED;
+   }
+
if (ci-is_otg) {
otgsc = hw_read_otgsc(ci, ~0);
if (ci_otg_is_fsm_mode(ci)) {
@@ -673,6 +680,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci-platdata = dev_get_platdata(dev);
ci-imx28_write_fix = !!(ci-platdata-flags 
CI_HDRC_IMX28_WRITE_FIX);
+   ci-supports_runtime_pm = !!(ci-platdata-flags 
+   CI_HDRC_SUPPORTS_RUNTIME_PM);
 
ret = hw_device_init(ci, base);
if (ret  0) {
@@ -788,6 +797,14 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (ret)
goto stop;
 
+   if (ci-supports_runtime_pm) {
+   pm_runtime_set_active(pdev-dev);
+   pm_runtime_enable(pdev-dev);
+   pm_runtime_set_autosuspend_delay(pdev-dev, 2000);
+   pm_runtime_mark_last_busy(ci-dev);
+   pm_runtime_use_autosuspend(pdev-dev);
+   }
+
if (ci_otg_is_fsm_mode(ci))
ci_hdrc_otg_fsm_start(ci);
 
@@ -807,6 +824,12 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 {
struct ci_hdrc *ci = platform_get_drvdata(pdev);
 
+   if (ci-supports_runtime_pm) {
+   pm_runtime_get_sync(pdev-dev);
+   pm_runtime_disable(pdev-dev);
+   pm_runtime_put_noidle(pdev-dev);
+   }
+
dbg_remove_files(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
@@ -815,13 +838,14 @@ static int ci_hdrc_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
 static void ci_controller_suspend(struct ci_hdrc *ci)
 {
+   disable_irq(ci-irq);
ci_hdrc_enter_lpm(ci, true);
-
-   if (ci-usb_phy)
-   usb_phy_set_suspend(ci-usb_phy, 1);
+   usb_phy_set_suspend(ci-usb_phy, 1);
+   ci-in_lpm = true;
+   enable_irq(ci-irq);
 }
 
 static int ci_controller_resume(struct device *dev)
@@ -830,23 +854,49 @@ static int ci_controller_resume(struct device *dev)
 
dev_dbg(dev, at %s\n, __func__);
 
-   ci_hdrc_enter_lpm(ci, false);
+   if (!ci-in_lpm) {
+   WARN_ON(1);
+   return 0;
+   }
 
+   ci_hdrc_enter_lpm(ci, false);
if (ci-usb_phy) {
usb_phy_set_suspend(ci-usb_phy, 0);
usb_phy_set_wakeup(ci-usb_phy, false);
hw_wait_phy_stable();
}
 
+   ci-in_lpm = false;
+   if (ci-wakeup_int) {
+   ci-wakeup_int = false;
+   pm_runtime_mark_last_busy(ci-dev);
+   pm_runtime_put_autosuspend(ci-dev);
+   enable_irq(ci-irq);
+   }
+
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int ci_suspend(struct device *dev)
 {
struct ci_hdrc *ci = dev_get_drvdata(dev);
 
if (ci-wq)
flush_workqueue(ci-wq);
+   /*
+* Controller needs to be active during suspend, otherwise the core
+* may run resume when the parent is at suspend if other driver's
+* suspend fails, it occurs before parent's suspend has not started,
+* but the core suspend has finished.
+*/
+

[PATCH 6/6] doc: usb: chipidea: add usb wakeup enable example

Add the example for how to enable USB as system wakeup source.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 Documentation/usb/chipidea.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt
index 995c8bc..3f848c1 100644
--- a/Documentation/usb/chipidea.txt
+++ b/Documentation/usb/chipidea.txt
@@ -69,3 +69,24 @@ cat /sys/kernel/debug/ci_hdrc.0/registers
 --
 On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
 July 27, 2012 Revision 2.0 version 1.1a
+
+2. How to enable USB as system wakeup source
+---
+Below is the example for how to enable USB as system wakeup source
+at imx6 platform.
+
+2.1 Enable core's wakeup
+echo enabled  /sys/bus/platform/devices/ci_hdrc.0/power/wakeup
+2.2 Enable glue layer's wakeup
+echo enabled  /sys/bus/platform/devices/2184000.usb/power/wakeup
+2.3 Enable PHY's wakeup (optional)
+echo enabled  /sys/bus/platform/devices/20c9000.usbphy/power/wakeup
+2.4 Enable roothub's wakeup
+echo enabled  /sys/bus/usb/devices/usb1/power/wakeup
+2.5 Enable related device's wakeup
+echo enabled  /sys/bus/usb/devices/1-1/power/wakeup
+
+If the system has only one usb port, and you want usb wakeup at this port, you
+can use below script to enable usb wakeup.
+for i in $(find /sys -name wakeup | grep usb);do echo enabled  $i;done;
+
-- 
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

[PATCH 1/3] usb: chipidea: clear otg interrupt status for otg capable controller

We need to do it for all otg capable controller, not only peripheral
featured otg capable controller, otherwise, the host-only role, but
otg capable controller may be responded by otg interrupt.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/core.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 6d9dc2d..2337354 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -649,8 +649,12 @@ static void ci_get_otg_capable(struct ci_hdrc *ci)
ci-is_otg = (hw_read(ci, CAP_DCCPARAMS,
DCCPARAMS_DC | DCCPARAMS_HC)
== (DCCPARAMS_DC | DCCPARAMS_HC));
-   if (ci-is_otg)
+   if (ci-is_otg) {
dev_dbg(ci-dev, It is OTG capable controller\n);
+   /* Disable and clear all OTG irq */
+   hw_write_otgsc(ci, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
+   OTGSC_INT_STATUS_BITS);
+   }
 }
 
 static int ci_hdrc_probe(struct platform_device *pdev)
@@ -749,9 +753,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
}
 
if (ci-is_otg  ci-roles[CI_ROLE_GADGET]) {
-   /* Disable and clear all OTG irq */
-   hw_write_otgsc(ci, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
-   OTGSC_INT_STATUS_BITS);
ret = ci_hdrc_otg_init(ci);
if (ret) {
dev_err(dev, init otg fails, ret = %d\n, ret);
-- 
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

[PATCH 3/3] usb: chipidea: usbmisc_imx: add imx6sx initialization routine

Except the same process with earlier imx6, it has below two features:

- Choose which vbus voltage as vbus wakeup source
We choose B_SESSION_VALID as vbus wakeup source since when the system
goes to suspend, the vbus comparator can't compare the vbus voltage
for VBUS_VALID.

- Disable dp/dm (linestate) change as wakeup source at device mode
when the vbus is not there, we don't expect dp/dm change waking up
usb controller at this situation.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/usbmisc_imx.c | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 90b7d7f..8af070f 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -58,7 +58,16 @@
 #define MX6_BM_WAKEUP_ENABLE   BIT(10)
 #define MX6_BM_ID_WAKEUP   BIT(16)
 #define MX6_BM_VBUS_WAKEUP BIT(17)
+#define MX6SX_BM_DPDM_WAKEUP_ENBIT(29)
 #define MX6_BM_WAKEUP_INTR BIT(31)
+#define MX6_USB_OTG1_PHY_CTRL  0x18
+/* For imx6dql, it is host-only controller, for later imx6, it is otg's */
+#define MX6_USB_OTG2_PHY_CTRL  0x1c
+#define MX6SX_USB_VBUS_WAKEUP_SOURCE(v)(v  8)
+#define MX6SX_USB_VBUS_WAKEUP_SOURCE_VBUS  MX6SX_USB_VBUS_WAKEUP_SOURCE(0)
+#define MX6SX_USB_VBUS_WAKEUP_SOURCE_AVALIDMX6SX_USB_VBUS_WAKEUP_SOURCE(1)
+#define MX6SX_USB_VBUS_WAKEUP_SOURCE_BVALIDMX6SX_USB_VBUS_WAKEUP_SOURCE(2)
+#define MX6SX_USB_VBUS_WAKEUP_SOURCE_SESS_END  MX6SX_USB_VBUS_WAKEUP_SOURCE(3)
 
 #define VF610_OVER_CUR_DIS BIT(7)
 
@@ -259,6 +268,35 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data 
*data)
return 0;
 }
 
+static int usbmisc_imx6sx_init(struct imx_usbmisc_data *data)
+{
+   void __iomem *reg = NULL;
+   unsigned long flags;
+   struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
+   u32 val;
+   int ret = 0;
+
+   usbmisc_imx6q_init(data);
+
+   if (data-index == 0 || data-index == 1) {
+   reg = usbmisc-base + MX6_USB_OTG1_PHY_CTRL + data-index * 4;
+   spin_lock_irqsave(usbmisc-lock, flags);
+   /* Set vbus wakeup source as bvalid */
+   val = readl(reg);
+   writel(val | MX6SX_USB_VBUS_WAKEUP_SOURCE_BVALID, reg);
+   /*
+* Disable dp/dm wakeup in device mode when vbus is
+* not there.
+*/
+   val = readl(usbmisc-base + data-index * 4);
+   writel(val  ~MX6SX_BM_DPDM_WAKEUP_EN,
+   usbmisc-base + data-index * 4);
+   spin_unlock_irqrestore(usbmisc-lock, flags);
+   }
+
+   return ret;
+}
+
 static int usbmisc_vf610_init(struct imx_usbmisc_data *data)
 {
struct imx_usbmisc *usbmisc = dev_get_drvdata(data-dev);
@@ -301,6 +339,11 @@ static const struct usbmisc_ops vf610_usbmisc_ops = {
.init = usbmisc_vf610_init,
 };
 
+static const struct usbmisc_ops imx6sx_usbmisc_ops = {
+   .set_wakeup = usbmisc_imx6q_set_wakeup,
+   .init = usbmisc_imx6sx_init,
+};
+
 int imx_usbmisc_init(struct imx_usbmisc_data *data)
 {
struct imx_usbmisc *usbmisc;
@@ -372,6 +415,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.compatible = fsl,vf610-usbmisc,
.data = vf610_usbmisc_ops,
},
+   {
+   .compatible = fsl,imx6sx-usbmisc,
+   .data = imx6sx_usbmisc_ops,
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
-- 
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

[PATCH 1/2] usb: phy: phy-mxs-usb: add power down and disable wakeup for .shutdown

When we shut down the PHY, we need to power down all PHY's functions
as well as disable wakeup, it is the opposite operation we do at .init.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/phy/phy-mxs-usb.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index b9589f6..eaf94b0 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -293,6 +293,17 @@ static int mxs_phy_init(struct usb_phy *phy)
 static void mxs_phy_shutdown(struct usb_phy *phy)
 {
struct mxs_phy *mxs_phy = to_mxs_phy(phy);
+   u32 value = BM_USBPHY_CTRL_ENVBUSCHG_WKUP |
+   BM_USBPHY_CTRL_ENDPDMCHG_WKUP |
+   BM_USBPHY_CTRL_ENIDCHG_WKUP |
+   BM_USBPHY_CTRL_ENAUTOSET_USBCLKS |
+   BM_USBPHY_CTRL_ENAUTOCLR_USBCLKGATE |
+   BM_USBPHY_CTRL_ENAUTOCLR_PHY_PWD |
+   BM_USBPHY_CTRL_ENAUTOCLR_CLKGATE |
+   BM_USBPHY_CTRL_ENAUTO_PWRON_PLL;
+
+   writel(value, phy-io_priv + HW_USBPHY_CTRL_CLR);
+   writel(0x, phy-io_priv + HW_USBPHY_PWD);
 
writel(BM_USBPHY_CTRL_CLKGATE,
   phy-io_priv + HW_USBPHY_CTRL_SET);
-- 
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

[PATCH 2/3] doc: usb: usbmisc-imx: add imx6sx compatible string

Add compatible string for imx6sx-usbmisc.

Signed-off-by: Peter Chen peter.c...@freescale.com
---
 Documentation/devicetree/bindings/usb/usbmisc-imx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt 
b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
index c101a4b..3539d4e 100644
--- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
@@ -5,6 +5,7 @@ Required properties:
 - compatible: Should be one of below:
fsl,imx6q-usbmisc for imx6q
fsl,vf610-usbmisc for Vybrid vf610
+   fsl,imx6sx-usbmisc for imx6sx
 - reg: Should contain registers location and length
 
 Examples:
-- 
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

[PATCH 2/2] usb: phy: phy-mxs-usb: do not depend on speed for disconnect notifier