Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Greg KH]

On Tue, Dec 15, 2015 at 01:29:19AM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/15/2015 01:21 AM, Rob Herring wrote:
> 
> Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators
> to
> enable a system with an integrated USB OTG dual-role transceiver to
> function
> as  an USB  OTG dual-role device.  In addition  to sensing/controlling
> Vbus,
> the chip also passes thru the ID signal  from the USB  OTG connector.
> On some Renesas boards,  this signal is  just fed into the SoC thru a
> GPIO
> pin --  there's no real  OTG controller, only host and gadget USB
> controllers
> sharing the same USB bus; however, we'd  like to allow host or gadget
> drivers
> to be loaded depending on the cable type,  hence the need for the MAX3355
> extcon driver. The Vbus status signals are also  wired to GPIOs (however,
> we
> aren't currently interested in them),  the OFFVBUS# signal is controlled
> by
> the host controllers, there's  also the SHDN# signal wired to a GPIO, it
> should be driven high for the  normal operation.
> >>>
> >>>
> >>>As multiple people have said, fix the spacing here.
> >>
> >>
> >>You are the first to complain abou _this_ patch. If you don't have other
> >>issues with this driver in which case you should have trimmed the reply at
> >>this point), I'd like to keep my spacing as is. Thank you.
> >
> >Your previous version was not "extcon-usb-gpio: add enable pin
> >support"[1] which has now been re-written to be max3355 specific?
> 
>No, the MAX3355 driver pre-dates that version. First there was a driver,
> then I tried to re-use the existing stuff (there was no extcon-usb-gpio at
> the time of writing my driver), then had to return to the separate driver
> idea...
> 
> >"So
> >what" and "I'd like to keep my spacing as is" aren't valid reasons.
> >Fix it, then I'll look at the rest again.
> 
>I'll consider doing that if you care to explain what's the problem with
> my spacing. TIA.

You are mixing 2 and 1 spaces between words, don't do that.
--
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] extcon: add Maxim MAX3355 driver

[Chanwoo Choi]

Hi Sergei,

On 2015년 12월 12일 08:22, Sergei Shtylyov wrote:
> Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators to
   ^^ ^^ 
> enable a system with an integrated USB OTG dual-role transceiver to function
> as  an USB  OTG dual-role device.  In addition  to sensing/controlling Vbus,
^^  ^^ ^^   ^^
> the chip also passes thru the ID signal  from the USB  OTG connector.
 ^^
> On some Renesas boards,  this signal is  just fed into the SoC thru a GPIO
 ^^  ^^
> pin --  there's no real  OTG controller, only host and gadget USB controllers
^^   ^^
> sharing the same USB bus; however, we'd  like to allow host or gadget drivers
 ^^
> to be loaded depending on the cable type,  hence the need for the MAX3355
   ^^
> extcon driver. The Vbus status signals are also  wired to GPIOs (however, we
> aren't currently interested in them),  the OFFVBUS# signal is controlled  by
   ^^ ^^  
> the host controllers, there's  also the SHDN# signal wired to a GPIO, it
   ^^
> should be driven high for the  normal operation.
   ^^
As above '^' expression, you used the double space between words.
You should fix it.

Thanks,
Chanwoo Choi


> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
> 
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
>   entry, the driver heading comment, the module description, and the change 
> log;
> - fixed up and reformatted the change log.
> 
>  Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 +
>  drivers/extcon/Kconfig  |8 
>  drivers/extcon/Makefile |1 
>  drivers/extcon/extcon-max3355.c |  153 
> 
>  4 files changed, 183 insertions(+)
> 
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO 
> pin
> +  connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> +  connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = < 4 GPIO_ACTIVE_LOW>;
> + id-gpios = < 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
>  
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> +   If you say yes here you get support for the USB OTG role detection by
> +   MAX3355. The MAX3355 chip integrates a charge pump and comparators to
> +   enable a system with an integrated USB OTG dual-role transceiver to
> +   function as an USB OTG dual-role device.
> +
>  config EXTCON_MAX77693
>   tristate "Maxim MAX77693 EXTCON Support"
>   depends on MFD_MAX77693 && INPUT
> Index: extcon/drivers/extcon/Makefile
> ===
> --- extcon.orig/drivers/extcon/Makefile
> +++ extcon/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)  += extcon-a
>  

Re: [PATCH] Add support for usbfs zerocopy.

[Steinar H. Gunderson]

On Mon, Dec 14, 2015 at 04:41:24PM +0800, Peter Chen wrote:
>> +ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory));
>> +if (ret) {
>> +return ret;
>> +}
> The braces are not needed.

New patch attached.

/* Steinar */
-- 
Software Engineer, Google Switzerland
>From 659c4025a0e182a1a205fc4d945a68b8cb3602f0 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" 
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.
To: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org,mrechber...@gmail.com

Add a new interface for userspace to preallocate memory that can be
used with usbfs. This gives two primary benefits:

 - Zerocopy; data no longer needs to be copied between the userspace
   and the kernel, but can instead be read directly by the driver from
   userspace's buffers. This works for all kinds of transfers (even if
   nonsensical for control and interrupt transfers); isochronous also
   no longer need to memset() the buffer to zero to avoid leaking kernel data.

 - Once the buffers are allocated, USB transfers can no longer fail due to
   memory fragmentation; previously, long-running programs could run into
   problems finding a large enough contiguous memory chunk, especially on
   embedded systems or at high rates.

Memory is allocated by using mmap() against the usbfs file descriptor,
and similarly deallocated by munmap(). Once memory has been allocated,
using it as pointers to a bulk or isochronous operation means you will
automatically get zerocopy behavior. Note that this also means you cannot
modify outgoing data until the transfer is complete. The same holds for
data on the same cache lines as incoming data; DMA modifying them at the
same time could lead to your changes being overwritten.

There's a new capability USBDEVFS_CAP_MMAP that userspace can query to see
if the running kernel supports this functionality, if just trying mmap() is
not acceptable.

Largely based on a patch by Markus Rechberger with some updates. The original
patch can be found at:

  http://sundtek.de/support/devio_mmap_v0.4.diff

Signed-off-by: Steinar H. Gunderson 
Signed-off-by: Markus Rechberger 
Acked-by: Alan Stern 
---
 drivers/usb/core/devio.c  | 229 +-
 include/uapi/linux/usbdevice_fs.h |   1 +
 2 files changed, 205 insertions(+), 25 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 38ae877c..f64dd3a 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -69,6 +70,7 @@ struct usb_dev_state {
 	spinlock_t lock;/* protects the async urb lists */
 	struct list_head async_pending;
 	struct list_head async_completed;
+	struct list_head memory_list;
 	wait_queue_head_t wait; /* wake up if a request completed */
 	unsigned int discsignr;
 	struct pid *disc_pid;
@@ -79,6 +81,17 @@ struct usb_dev_state {
 	u32 disabled_bulk_eps;
 };
 
+struct usb_memory {
+	struct list_head memlist;
+	int vma_use_count;
+	int urb_use_count;
+	u32 size;
+	void *mem;
+	dma_addr_t dma_handle;
+	unsigned long vm_start;
+	struct usb_dev_state *ps;
+};
+
 struct async {
 	struct list_head asynclist;
 	struct usb_dev_state *ps;
@@ -89,6 +102,7 @@ struct async {
 	void __user *userbuffer;
 	void __user *userurb;
 	struct urb *urb;
+	struct usb_memory *usbm;
 	unsigned int mem_usage;
 	int status;
 	u32 secid;
@@ -157,6 +171,107 @@ static int connected(struct usb_dev_state *ps)
 			ps->dev->state != USB_STATE_NOTATTACHED);
 }
 
+static void dec_usb_memory_use_count(struct usb_memory *usbm, int *count)
+{
+	struct usb_dev_state *ps = usbm->ps;
+	unsigned long flags;
+
+	spin_lock_irqsave(>lock, flags);
+	--*count;
+	if (usbm->urb_use_count == 0 && usbm->vma_use_count == 0) {
+		list_del(>memlist);
+		spin_unlock_irqrestore(>lock, flags);
+
+		usb_free_coherent(ps->dev, usbm->size, usbm->mem,
+usbm->dma_handle);
+		usbfs_decrease_memory_usage(
+			usbm->size + sizeof(struct usb_memory));
+		kfree(usbm);
+	} else {
+		spin_unlock_irqrestore(>lock, flags);
+	}
+}
+
+static void usbdev_vm_open(struct vm_area_struct *vma)
+{
+	struct usb_memory *usbm = vma->vm_private_data;
+	unsigned long flags;
+
+	spin_lock_irqsave(>ps->lock, flags);
+	++usbm->vma_use_count;
+	spin_unlock_irqrestore(>ps->lock, flags);
+}
+
+static void usbdev_vm_close(struct vm_area_struct *vma)
+{
+	struct usb_memory *usbm = vma->vm_private_data;
+
+	dec_usb_memory_use_count(usbm, >vma_use_count);
+}
+
+struct vm_operations_struct usbdev_vm_ops = {
+	.open = usbdev_vm_open,
+	.close = usbdev_vm_close
+};
+
+static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	struct usb_memory *usbm = NULL;
+	struct usb_dev_state *ps = file->private_data;
+	size_t size = vma->vm_end - vma->vm_start;
+	

RE: [PATCH v2] usb: gadget: forbid queuing request to a disabled ep

[Du, Changbin]

> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 3d583a1..b566a4b 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -402,6 +402,9 @@ static inline void usb_ep_free_request(struct usb_ep
> *ep,
>  static inline int usb_ep_queue(struct usb_ep *ep,
>  struct usb_request *req, gfp_t gfp_flags)
>  {
> + if (WARN_ON_ONCE(!ep->enabled))
> + return -ESHUTDOWN;
> +
>   return ep->ops->queue(ep, req, gfp_flags);
>  }
> 
> --
> 2.5.0
With  this patch, ep0 transfer breaks. it because the 'enabled' of ep0  is not 
set. Ep0 
is not enabled by usb_ep_enable, but in UDC driver. So there need another patch
to set ep0's flag also.

--
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 0/3] USB: add generic onboard USB HUB driver

[Fabio Estevam]

Hi Peter,

On Mon, Dec 14, 2015 at 5:26 AM, Peter Chen  wrote:

> Hi all,
>
> There is a known issue that the USB code can't handle USB HUB's
> external pins well, in that case, it may cause some onboard
> USB HUBs can't work since their PHY's clock or reset pin needs to
> operate.
>
> The user reported this issue at below:
> http://www.spinics.net/lists/linux-usb/msg131502.html
>
> In this patch set, I add a generic onboard USB HUB driver to
> handle this problem, the external signals will be configured
> before usb controller's initialization, it much likes we did
> it at board code before.
>
> The user needs to add this generic hub node at dts to support it.
>
> @The udoo users, help to test please.

This is what I get with your series applied:

[2.288300] usb 1-1: device descriptor read/64, error -71
[2.518083] usb 1-1: new full-speed USB device number 3 using ci_hdrc
[2.738078] usb 1-1: device descriptor read/64, error -71
[3.058078] usb 1-1: device descriptor read/64, error -71
[3.288079] usb 1-1: new full-speed USB device number 4 using ci_hdrc
[3.768069] usb 1-1: device not accepting address 4, error -71
[3.888084] usb 1-1: new full-speed USB device number 5 using ci_hdrc
[4.368067] usb 1-1: device not accepting address 5, error -71
[4.374117] usb usb1-port1: unable to enumerate USB device
--
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 0/3] USB: add generic onboard USB HUB driver

[Peter Chen]

On Mon, Dec 14, 2015 at 09:26:55AM -0200, Fabio Estevam wrote:
> Hi Peter,
> 
> On Mon, Dec 14, 2015 at 5:26 AM, Peter Chen  wrote:
> 
> > Hi all,
> >
> > There is a known issue that the USB code can't handle USB HUB's
> > external pins well, in that case, it may cause some onboard
> > USB HUBs can't work since their PHY's clock or reset pin needs to
> > operate.
> >
> > The user reported this issue at below:
> > http://www.spinics.net/lists/linux-usb/msg131502.html
> >
> > In this patch set, I add a generic onboard USB HUB driver to
> > handle this problem, the external signals will be configured
> > before usb controller's initialization, it much likes we did
> > it at board code before.
> >
> > The user needs to add this generic hub node at dts to support it.
> >
> > @The udoo users, help to test please.
> 
> This is what I get with your series applied:
> 
> [2.288300] usb 1-1: device descriptor read/64, error -71
> [2.518083] usb 1-1: new full-speed USB device number 3 using ci_hdrc
> [2.738078] usb 1-1: device descriptor read/64, error -71
> [3.058078] usb 1-1: device descriptor read/64, error -71
> [3.288079] usb 1-1: new full-speed USB device number 4 using ci_hdrc
> [3.768069] usb 1-1: device not accepting address 4, error -71
> [3.888084] usb 1-1: new full-speed USB device number 5 using ci_hdrc
> [4.368067] usb 1-1: device not accepting address 5, error -71
> [4.374117] usb usb1-port1: unable to enumerate USB device

Thanks, Fabio.

I am afraid I forget to set gpio as output, would you please apply
below patch against my original ones:

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 64eabe2..34b0708 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -24,7 +24,7 @@
compatible = "generic-onboard-hub";
clocks = < IMX6QDL_CLK_CKO>;
reset-gpios = < 12 GPIO_ACTIVE_LOW>;
-   reset-duration-us = <2>;
+   reset-duration-us = <10>;
};
 };
 
diff --git a/drivers/usb/misc/generic_onboard_hub.c 
b/drivers/usb/misc/generic_onboard_hub.c
index 7db5b78..2f0afa7 100644
--- a/drivers/usb/misc/generic_onboard_hub.c
+++ b/drivers/usb/misc/generic_onboard_hub.c
@@ -89,6 +89,8 @@ static int usb_hub_generic_probe(struct platform_device *pdev)
of_property_read_u32(node, "reset-duration-us", _us);
 
if (gpiod_reset) {
+   gpiod_direction_output(gpiod_reset, 1);
+
gpiod_set_value(gpiod_reset, 1);
usleep_range(duration_us, duration_us + 10);
gpiod_set_value(gpiod_reset, 0);

-- 

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

Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Philipp Zabel]

Hi Hans,

Am Freitag, den 11.12.2015, 19:21 +0100 schrieb Hans de Goede:
[...]
> >> @@ -119,13 +134,55 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
> >>   int reset_control_deassert(struct reset_control *rstc)
> >>   {
> >
> > Maybe WARN_ON(rstc->line->refcnt > 1) ?
> 
> I assume you mean deasser_cnt ? Seems reasonable with that change.

I meant refcnt. Currently drivers sharing reset lines (refcnt > 1)
and then using the non-shared reset control functions are bound to cause
unexpected behaviour. Now we can detect this for the first time.

> >>if (rstc->rcdev->ops->deassert)
> >> -  return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
> >> +  return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->line->id);
> >>
> >>return -ENOTSUPP;
> >>   }
> >>   EXPORT_SYMBOL_GPL(reset_control_deassert);
> >>
> >>   /**
> >> + * reset_control_assert_shared - asserts a shared reset line
> >> + * @rstc: reset controller
> >> + *
> >> + * Assert a shared reset line, this functions decreases the deassert count
> >> + * of the line by one and asserts it if, and only if, the deassert count
> >> + * reaches 0.
> >
> > "After calling this function the shared reset line may be asserted, or
> >   it may still be deasserted, as long as other users keep it so."
> 
> I take it this is to replace the text about "deassert count" ?

I thought you might append something like it. I just imagine that when
reading the documentation it might be helpful to also see the intended
effect described, especially given that a call to an _assert_ function
might leave the reset line in deasserted state, depending on the
refcount.

> >> + */
> >> +int reset_control_assert_shared(struct reset_control *rstc)
> >> +{
> >> +  if (!rstc->rcdev->ops->assert)
> >> +  return -ENOTSUPP;
> >
> > WARN_ON(rstc->line->deassert_cnt == 0)
> >
> > Actually, what to do in this case? Assume ops->assert was called, or do
> > it again to be sure? Certainly we don't want to wrap deassert_cnt, or
> > the next deassert_shared will do nothing.
> >
> >> +  rstc->line->deassert_cnt--;
> >> +  if (rstc->line->deassert_cnt)
> >
> > deassert_cnt isn't protected by any lock.
> 
> Right, good catch. I believe the best way to fix this is to change 
> deassert_cnt
> into an atomic_t and use atomic_dec_return / atomic_int_return,

Yes, that would work.

> Downside of using an atomic_t is that doing the WARN_ON you are asking for 
> above
> will not be race free, then, but since it is a should never happen scenario I
> guess we do not care about the check not being 100% race free. Or we can even
> just leave out the check ?

Since this is only a warning to notify driver developers we don't
support shared resets (apart from the clock-like use)

Not if we warn about refcnt instead of deassert_cnt above.

[...]
> >> + * of the line by one and deasserts the reset line (if it was not already
> >> + * deasserted).
> >
> > "After calling this function, the shared reset line is guaranteed to be
> >   deasserted."
> 
> Same question as above.

Same imprecise answer. I'd like to see the expected state after calling
this function in the description, in addition to the mechanism. This is
more important for the assert function. After calling deassert, the
reset line is deasserted, no reason to be surprised about that.

regards
Philipp

--
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: [linux-usb-users] g_serial is not working in rx path (K3.14)

[Felipe Balbi]

hi,

Ramajayam S  writes:
> Hi
>We are trying to enable g_serial in Intel platform and facing
> issue with RX path.
>
> stable kernel version: K3.14

you need to test with something more recent, like v4.3. If you are stuck
with Intel' v3.14 kernel, then you need to ask for support from Intel,
I'm afraid

> configuration enabled: USB_G_SERIAL
>
> testing details:
>
> writing from device side(ttyS0) to Windows Host(com 11-g_serial): working fine
>
> from ttyS0: echo test > /dev/ttyGS0  -- received in comm 11
>
> Typing any character from windows host pc(com 11 using teraterm) to
> device side: not working

what do you mean not working ? What happens ? Got usbmon trace or some
usb sniffer ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] Add support for usbfs zerocopy.

[Alan Stern]

On Mon, 14 Dec 2015, Steinar H. Gunderson wrote:

> On Mon, Dec 14, 2015 at 04:41:24PM +0800, Peter Chen wrote:
> >> +  ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory));
> >> +  if (ret) {
> >> +  return ret;
> >> +  }
> > The braces are not needed.
> 
> New patch attached.

I thought of something else, a more serious problem.  According to the
man page for munmap(2), closing the file descriptor does not unmap the
region.  Therefore we need to explicitly make sure that the usbcore
module cannot be unloaded while any memory mappings exist, by calling
try_module_get(THIS_MODULE) when a mapping is created and
module_put(THIS_MODULE) when a mapping is removed.

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

[PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller

[Yoshihiro Shimoda]

R-Car H3 has USB3.0 peripheral controllers. This controller's has the
following features:
 - Supports super, high and full speed
 - Contains 30 pipes for bulk or interrupt transfer
 - Contains dedicated DMA controller

This driver doesn't support the dedicated DMAC for now.

Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the latest Felipe's usb.git / testing/next branch.
 (commit id = e9284de9fae69f1d5e57a4817bfc36dc5f3adf71)

 .../devicetree/bindings/usb/renesas_usb3.txt   |   23 +
 drivers/usb/gadget/udc/Kconfig |   11 +
 drivers/usb/gadget/udc/Makefile|1 +
 drivers/usb/gadget/udc/renesas_usb3.c  | 1720 
 drivers/usb/gadget/udc/renesas_usb3.h  |  284 
 5 files changed, 2039 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/renesas_usb3.txt
 create mode 100644 drivers/usb/gadget/udc/renesas_usb3.c
 create mode 100644 drivers/usb/gadget/udc/renesas_usb3.h

diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
new file mode 100644
index 000..215eee7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -0,0 +1,23 @@
+Renesas Electronics USB3.0 Peripheral driver
+
+Required properties:
+  - compatible: Must contain one of the following:
+   - "renesas,usb3-peri-r8a7795"
+  - reg: Base address and length of the register for the USB3.0 Peripheral
+  - interrupts: Interrupt specifier for the USB3.0 Peripheral
+  - clocks: A list of phandle + clock specifier pairs
+
+Example:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,usb3-peri-r8a7795";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   };
+
+   usb3_peri1: usb@ee06 {
+   compatible = "renesas,usb3-peri-r8a7795";
+   reg = <0 0xee06 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 327>;
+   };
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index cdbff54..753c29b 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -174,6 +174,17 @@ config USB_RENESAS_USBHS_UDC
   dynamically linked module called "renesas_usbhs" and force all
   gadget drivers to also be dynamically linked.
 
+config USB_RENESAS_USB3
+   tristate 'Renesas USB3.0 Peripheral controller'
+   depends on ARCH_SHMOBILE || COMPILE_TEST
+   help
+  Renesas USB3.0 Peripheral controller is a USB peripheral controller
+  that supports super, high, and full speed USB 3.0 data transfers.
+
+  Say "y" to link the driver statically, or "m" to build a
+  dynamically linked module called "renesas_usb3" and force all
+  gadget drivers to also be dynamically linked.
+
 config USB_PXA27X
tristate "PXA 27x"
help
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index fba2049..dfee534 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -19,6 +19,7 @@ fsl_usb2_udc-y:= fsl_udc_core.o
 fsl_usb2_udc-$(CONFIG_ARCH_MXC)+= fsl_mxc_udc.o
 obj-$(CONFIG_USB_M66592)   += m66592-udc.o
 obj-$(CONFIG_USB_R8A66597) += r8a66597-udc.o
+obj-$(CONFIG_USB_RENESAS_USB3) += renesas_usb3.o
 obj-$(CONFIG_USB_FSL_QE)   += fsl_qe_udc.o
 obj-$(CONFIG_USB_S3C_HSUDC)+= s3c-hsudc.o
 obj-$(CONFIG_USB_LPC32XX)  += lpc32xx_udc.o
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
new file mode 100644
index 000..f302c89
--- /dev/null
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -0,0 +1,1720 @@
+/*
+ * Renesas USB3.0 Peripheral driver (USB gadget)
+ *
+ * Copyright (C) 2015  Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "renesas_usb3.h"
+
+static const char udc_name[] = "renesas_usb3";
+
+static int renesas_usb3_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
+gfp_t gfp_flags);
+static void usb3_start_pipen(struct renesas_usb3_ep *usb3_ep,
+struct renesas_usb3_request *usb3_req);
+
+static void usb3_write(struct renesas_usb3 *usb3, u32 data, u32 offs)
+{
+   iowrite32(data, usb3->reg + offs);
+}
+
+static u32 usb3_read(struct renesas_usb3 *usb3, u32 offs)
+{
+   return ioread32(usb3->reg + offs);
+}
+
+static void usb3_set_bit(struct renesas_usb3 *usb3, u32 bits, u32 offs)
+{
+   u32 val = usb3_read(usb3, 

Re: [PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

[Simon Horman]

On Fri, Dec 11, 2015 at 03:24:27PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/11/2015 5:12 AM, Simon Horman wrote:
> 
> >Add fallback compatibility strings for R-Car Gen2 and Gen3.
> >This is in keeping with the fallback scheme being adopted wherever
> >appropriate for drivers for Renesas SoCs.
> >
> >Signed-off-by: Simon Horman 
> >---
> >v3
> >* Moved documentation of SoC names to a separate patch
> >* Use correct fallback compatibility string in example
> >
> >v2
> >* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
> >   a single compatibility string for all of R-Car.
> >---
> >  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +-
> >  drivers/usb/renesas_usbhs/common.c  |  9 +
> >  2 files changed, 18 insertions(+), 1 deletion(-)
> >
> >diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> >b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >index a14c0bb561d5..c55cf77006d0 100644
> >--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
> >
> >  Required properties:
> >- compatible: Must contain one of the following:
> 
>Really?

Would "...one or more of the following" help?

> >+
> > - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> > - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> > - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> > - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> >+- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> >+- "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
> >+
> >+When compatible with the generic version, nodes must list the
> >+SoC-specific version corresponding to the platform first followed
> >+by the generic version.
> >+
> 
>This kinda contradicts the above claim.
> 
> [...]
> 
> MBR, 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

[PATCH 2/2] HID: Add new Japanese Surface 3 Pro Type Cover

[Akihiko Odaki]

Add support for the new Japanese version of Microsoft Surface 3 Pro
Type Cover.

Signed-off-by: Akihiko Odaki 
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/hid-multitouch.c| 3 +++
 drivers/hid/usbhid/hid-quirks.c | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8b78a7f..a12e392 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -683,6 +683,7 @@
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_30x07dc
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2  0x07e2
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
+#define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2_JP 0x07e3
 #define USB_DEVICE_ID_MS_TYPE_COVER_30x07de
 #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
 
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index dfc2698..b5e040d 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1342,6 +1342,9 @@ static const struct hid_device_id mt_devices[] = {
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
{ .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
+   USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2_JP) },
+   { .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
+   MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 7dd0953..50a57d0 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -91,6 +91,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, 
HID_QUIRK_NO_INIT_REPORTS },
+   { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2_JP, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
-- 
2.6.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

[PATCH 1/2] HID: Use multitouch driver for Type Covers

[Akihiko Odaki]

Use multitouch driver instead of microsoft one for Microsoft Surface
Type Covers.

By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as
the multitouch pads do.

Signed-off-by: Akihiko Odaki 
---
 drivers/hid/hid-core.c   | 14 --
 drivers/hid/hid-microsoft.c  | 10 --
 drivers/hid/hid-multitouch.c | 17 +
 3 files changed, 17 insertions(+), 24 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c6f7a69..43afc55 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -723,15 +723,6 @@ static void hid_scan_collection(struct hid_parser *parser, 
unsigned type)
type == HID_COLLECTION_PHYSICAL)
hid->group = HID_GROUP_SENSOR_HUB;
 
-   if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
-   (hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
-hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
-   hid->group == HID_GROUP_MULTITOUCH)
-   hid->group = HID_GROUP_GENERIC;
-
if ((parser->global.usage_page << 16) == HID_UP_GENDESK)
for (i = 0; i < parser->local.usage_index; i++)
if (parser->local.usage[i] == HID_GD_POINTER)
@@ -1933,11 +1924,6 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) 
},
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 77a2cf3..0dbc2a0 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -276,16 +276,6 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3),
-   .driver_data = MS_HIDINPUT },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2),
-   .driver_data = MS_HIDINPUT },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
-   .driver_data = MS_HIDINPUT },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3),
-   .driver_data = MS_HIDINPUT },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
-   .driver_data = MS_HIDINPUT },
 
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 3d664d0..dfc2698 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1330,6 +1330,23 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_ILITEK,
USB_DEVICE_ID_ILITEK_MULTITOUCH) },
 
+   /* Microsoft Surface Typecover */
+   { .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
+   MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
+   USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
+   { .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
+   MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
+   USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
+   { .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
+   MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
+   USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
+   { .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
+   MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
+   USB_DEVICE_ID_MS_TYPE_COVER_3) },
+   { .driver_data = MT_CLS_EXPORT_ALL_INPUTS,
+   MT_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
+   USB_DEVICE_ID_MS_POWER_COVER) },
+
/* 

Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers

[Bastien Nocera]

On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote:
> Use multitouch driver instead of microsoft one for Microsoft Surface
> Type Covers.
> 
> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as
> the multitouch pads do.

I've discussed this a couple of weeks back with Benjamin Tissoires, and
this patch would break the special keys (mute, brightness up/down,
keyboard backlight up/down and play/pause).

The recommended way to fix this was to move multi-touch processing into
the Microsoft driver, so that it would handle the trackpad's multi-
touch events.

You should be able to do this by carefully picking up the handling code
from hid-multitouch, or do something similar to what's done in hid-
wacom, which has the same problem as the Type Cover handling.

Can you confirm that this does indeed break those special keys? If it
does, it's a NAK from my side.

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

Deadlock in USB/IP driver

[Andrew Goodbody]

https://bugzilla.kernel.org/show_bug.cgi?id=109351

I posted the log snippet to this list on Friday with no response so far, so I 
filed a bug on it. Greg Kroah-Hartman responded to the bug to ask me to post on 
this list.
Outlook messed up the text formatting from the syslog on my first attempt so I 
am simply attaching the file this time.

Andrew
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.497958] usbip_core: USB/IP Core v1.0.0
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.499707] vhci_hcd vhci_hcd: USB/IP 
Virtual Host Controller
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.499713] vhci_hcd vhci_hcd: new USB bus 
registered, assigned bus number 3
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.501600] usb usb3: New USB device 
found, idVendor=1d6b, idProduct=0002
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.501602] usb usb3: New USB device 
strings: Mfr=3, Product=2, SerialNumber=1
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.501604] usb usb3: Product: USB/IP 
Virtual Host Controller
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.501605] usb usb3: Manufacturer: Linux 
4.3.0-040300-generic vhci_hcd
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.501606] usb usb3: SerialNumber: 
vhci_hcd
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.502978] hub 3-0:1.0: USB hub found
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.503138] hub 3-0:1.0: 8 ports detected
Dec 10 15:03:20 cbrx-fw01 kernel: [  220.504814] vhci_hcd: USB/IP 'Virtual' 
Host Controller (VHCI) Driver v1.0.0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.195937] vhci_hcd vhci_hcd: rhport(0) 
sockfd(15) devid(4) speed(2) speed_str(full-speed)
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304076] 
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304079] 
=
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304080] [ INFO: inconsistent lock 
state ]
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304082] 4.3.0-040300-generic 
#201511020846 Tainted: GE  
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304083] 
-
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304084] inconsistent {SOFTIRQ-ON-W} -> 
{IN-SOFTIRQ-W} usage.
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304085] swapper/0/0 
[HC0[0]:SC1[1]:HE1:SE0] takes:
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304086]  
(&(>lock)->rlock){+.?...}, at: [] 
vhci_hub_status+0x34/0x170 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304091] {SOFTIRQ-ON-W} state was 
registered at:
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304092]   [] 
__lock_acquire+0x831/0x1b40
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304095]   [] 
lock_acquire+0xaf/0x130
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304097]   [] 
_raw_spin_lock+0x31/0x40
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304100]   [] 
vhci_hub_control+0x69/0x9a0 [vhci_hcd]
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304102]   [] 
usb_hcd_submit_urb+0x757/0xaa0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304105]   [] 
usb_submit_urb.part.6+0x2f0/0x550
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304107]   [] 
usb_submit_urb+0x62/0x70
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304109]   [] 
usb_start_wait_urb+0x74/0x180
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304111]   [] 
usb_control_msg+0xc1/0x100
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304113]   [] 
hub_configure+0x129/0xba0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304114]   [] 
hub_probe+0x2b4/0x340
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304116]   [] 
usb_probe_interface+0x1bb/0x2e0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304117]   [] 
driver_probe_device+0x224/0x490
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304120]   [] 
__device_attach_driver+0x71/0xa0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304122]   [] 
bus_for_each_drv+0x5d/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304124]   [] 
__device_attach+0xbc/0x140
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304126]   [] 
device_initial_probe+0x13/0x20
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304128]   [] 
bus_probe_device+0xa3/0xb0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304129]   [] 
device_add+0x40d/0x690
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304131]   [] 
usb_set_configuration+0x50a/0x8e0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304133]   [] 
generic_probe+0x2e/0x80
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304136]   [] 
usb_probe_device+0x32/0x70
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304137]   [] 
driver_probe_device+0x224/0x490
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304139]   [] 
__device_attach_driver+0x71/0xa0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304141]   [] 
bus_for_each_drv+0x5d/0x90
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304142]   [] 
__device_attach+0xbc/0x140
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304144]   [] 
device_initial_probe+0x13/0x20
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304146]   [] 
bus_probe_device+0xa3/0xb0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304147]   [] 
device_add+0x40d/0x690
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304149]   [] 
usb_new_device+0x277/0x4b0
Dec 10 15:03:34 cbrx-fw01 kernel: [  234.304150]   [] 
usb_add_hcd+0x582/0x970
Dec 10 15:03:34 

RE: [PATCH] Add support for usbfs zerocopy.

[David Laight]

From: Alan Stern
> Sent: 14 December 2015 15:28
...
> I thought of something else, a more serious problem.  According to the
> man page for munmap(2), closing the file descriptor does not unmap the
> region.  Therefore we need to explicitly make sure that the usbcore
> module cannot be unloaded while any memory mappings exist, by calling
> try_module_get(THIS_MODULE) when a mapping is created and
> module_put(THIS_MODULE) when a mapping is removed.

Are you sure this is a problem?
It is more likely that either:
1) the mmap() holds a reference to the physical pages - so they don't
  get freed even though the driver frees its reference to the memory.
2) when the driver frees the memory the user-space page tables are
  invalidated - so the next access generates EFAULT.

Not that I've done the experiment (or tried to read the code).

If you need to monitor the mapping, you need to allow for partial unmaps.

David

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

Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers

[Donavan Lance]

On Mon, Dec 14, 2015 at 8:22 AM, Bastien Nocera  wrote:
> On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote:
>> Use multitouch driver instead of microsoft one for Microsoft Surface
>> Type Covers.
>>
>> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as
>> the multitouch pads do.
>
> I've discussed this a couple of weeks back with Benjamin Tissoires, and
> this patch would break the special keys (mute, brightness up/down,
> keyboard backlight up/down and play/pause).
>
> The recommended way to fix this was to move multi-touch processing into
> the Microsoft driver, so that it would handle the trackpad's multi-
> touch events.
>
> You should be able to do this by carefully picking up the handling code
> from hid-multitouch, or do something similar to what's done in hid-
> wacom, which has the same problem as the Type Cover handling.
>
> Can you confirm that this does indeed break those special keys? If it
> does, it's a NAK from my side.

For what it's worth the special keys on my keyboard work fine when
using this patch. I'm using a Surface Pro 3, Type Cover 3, running
GNOME and Fedora 23. The search, share, connect(?), and settings keys
are the only ones not mapped to anything out of the box, but they are
recognized by xev.
--
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] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/14/2015 04:24 AM, Rob Herring wrote:


Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to function
as  an USB  OTG dual-role device.  In addition  to sensing/controlling Vbus,
the chip also passes thru the ID signal  from the USB  OTG connector.
On some Renesas boards,  this signal is  just fed into the SoC thru a GPIO
pin --  there's no real  OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd  like to allow host or gadget drivers
to be loaded depending on the cable type,  hence the need for the MAX3355
extcon driver. The Vbus status signals are also  wired to GPIOs (however, we
aren't currently interested in them),  the OFFVBUS# signal is controlled  by
the host controllers, there's  also the SHDN# signal wired to a GPIO, it
should be driven high for the  normal operation.


As multiple people have said, fix the spacing here.


   You are the first to complain abou _this_ patch. If you don't have other 
issues with this driver in which case you should have trimmed the reply at 
this point), I'd like to keep my spacing as is. Thank you.


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

Kernel v4.3 - RCU hang, USB + SCSI implicated

[Ilia Mirkin]

Hello,

This is a follow-up to an earlier report where I was directed by
Oliver Neukum to repost to linux-scsi. I got lazy and forgot, but the
same issue happened a second time.

Original posting at: https://lkml.org/lkml/2015/11/16/569

This is an Intel Haswell system, DELL U2415 monitor (which has a USB
hub, with a mouse connected) connected over USB which in turn suspends
after a while (and disconnects from the bus). There's also a flash
reader thing in the computer case, which is also (internally)
connected over USB, but I don't think that powers down. However
they're on the same bus according to lsusb.

It seems that this time my SATA driver also got taken down this time
and so the log messages are a bit odd... they have ATA EH recovery
messages interspersed in them (but the logs made it to disk, so it
worked). Pardon the gmail-induced wrapping :(

Please let me know if there's any additional info I might provide to
help track this down.

Thanks,

  -ilia


Log:

INFO: rcu_sched detected stalls on CPUs/tasks:
\x090: (1 GPs behind) idle=e1d/141/0
softirq=78957631/78957633 fqs=6975
\x09(detected by 2, t=21002 jiffies, g=109144013, c=109144012, q=26882)
Task dump for CPU 0:
cc1plus R  running task14472 15396  15395 0x0008
  7fb90b706004 880049264280 0007
 88000b587f58 88003ebd3e80 88000b587f38 8108d834
 88003ebd3e80 0002 8800492642e8 0008
Call Trace:
 [] ? __do_page_fault+0x1b4/0x400
 [] ? retint_user+0x8/0xd
xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command.
xhci_hcd :00:14.0: Assuming host is dying, halting host.
xhci_hcd :00:14.0: HC died; cleaning up
usb 1-7: USB disconnect, device number 2
usb 2-4: USB disconnect, device number 2
usb 2-4.4: USB disconnect, device number 3
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 10 pio 16392
in\x0a Get event status notification 4a 01 00 00 10 00 00 00
08 00res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata1.00: exception Emask 0x0 SAct 0x7fff SErr 0x0 action 0x6 frozen
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:80:28:be:e0/00:00:5d:00:00/40 tag 16 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/e0:88:78:31:e1/00:00:5d:00:00/40 tag 17 ncq 114688
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/28:90:e8:d6:cd/00:00:25:00:00/40 tag 18 ncq 20480
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/60:98:10:d7:cd/01:00:25:00:00/40 tag 19 ncq 180224
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/18:a0:70:d8:cd/00:00:25:00:00/40 tag 20 ncq 12288
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:a8:38:b5:cd/00:00:25:00:00/40 tag 21 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/10:b0:90:d6:cd/00:00:25:00:00/40 tag 22 ncq 8192
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:b8:e8:3a:04/00:00:21:00:00/40 tag 23 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:c0:f0:3a:04/00:00:21:00:00/40 tag 24 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:c8:08:3b:04/00:00:21:00:00/40 tag 25 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:d0:10:3b:04/00:00:21:00:00/40 tag 26 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:d8:20:3b:04/00:00:21:00:00/40 tag 27 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:e0:38:3b:04/00:00:21:00:00/40 tag 28 ncq 4096
out\x0a res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY }

Re: [PATCH v2 2/3] ehci-platform: Add support for controllers with multiple reset lines

[Philipp Zabel]

Am Freitag, den 11.12.2015, 19:28 +0100 schrieb Hans de Goede:
[...]
> >> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
> >> b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> >> index a12d601..0701812 100644
> >> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> >> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> >> @@ -18,7 +18,7 @@ Optional properties:
> >>- clocks : a list of phandle + clock specifier pairs
> >>- phys : phandle + phy specifier pair
> >>- phy-names : "usb"
> >> - - resets : phandle + reset specifier pair
> >> + - resets : a list of phandle + reset specifier pairs
> >
> > Are there documented names for these resets?
> 
> This binding is a generic ehci controller binding, so even if
> the names are documented for the allwinner SoC we should
> not use names, just like the binding is deliberately not
> using names for the clocks either to keep it generic, so
> that we can reuse the binding + driver with many different SoCs.

I know, I'm just interested in understanding why this is necessary ...

> > Is the companion you
> > mention the Port Control?
> 
> Sort of, with USB-2, USB-1 compatibility is handled via a mux on the
> datalines (controlled by the EHCI controller Port Control) which muxes
> the lines to an USB-1 controller (typically either UHCI or OHCI) when the
> device does not connect after USB-2 highspeed handshaking.
> 
> This USB-1 controller (or controller_S_ in some case since the
> USB-1 companions may have less root-ports per controller then the EHCI
> has root-ports) is called the companion controller.
> 
> The 2 controllers are supposed to be 100% independent but on the H3
> Allwinner has done something (not documented) which requires one to
> deassert reset on both before you can talk to either one.

... so thank you for the explanation.

Acked-by: Philipp Zabel 

regards
Philipp

--
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 0/3] USB: add generic onboard USB HUB driver

[Arnd Bergmann]

On Monday 14 December 2015 15:26:11 Peter Chen wrote:
> Hi all,
> 
> There is a known issue that the USB code can't handle USB HUB's
> external pins well, in that case, it may cause some onboard
> USB HUBs can't work since their PHY's clock or reset pin needs to
> operate.
> 
> The user reported this issue at below:
> http://www.spinics.net/lists/linux-usb/msg131502.html
> 
> In this patch set, I add a generic onboard USB HUB driver to
> handle this problem, the external signals will be configured
> before usb controller's initialization, it much likes we did
> it at board code before.
> 
> The user needs to add this generic hub node at dts to support it.
> 
> @The udoo users, help to test please.

I still think need to do this properly by representing the hub
device as a USB device, using power sequencing code like MMC does.

Arnd
--
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 1/3] reset: Add shared reset_control_[de]assert variants

[Maxime Ripard]

Hi,

On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:
> diff --git a/include/linux/reset.h b/include/linux/reset.h
> index c4c097d..1cca8ce 100644
> --- a/include/linux/reset.h
> +++ b/include/linux/reset.h
> @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
>  int reset_control_assert(struct reset_control *rstc);
>  int reset_control_deassert(struct reset_control *rstc);
>  int reset_control_status(struct reset_control *rstc);
> +int reset_control_assert_shared(struct reset_control *rstc);
> +int reset_control_deassert_shared(struct reset_control *rstc);

Shouldn't that be handled in reset_control_get directly?

That would allow to share more code between the implementations, since
it would just be a flag to test in the get and not duplicate the
function definitions, and we could simply rely on the refcount to know
if we have to actually assert / deassert the device, in all the cases
(shared or not).

That would also allow us to catch easily if we're going to be able a
shared reset line or not, with the regular reset_control_get being
exclusive, and reset_control_get_shared or reset_control_get(..,
RESET_SHARED) being shared.

It would also avoid ending up with the shared variant used in every
generic driver eventually. We could just use the variant to see if we
have to use the shared get or not, and the rest of the driver is left
untouched, which is way less intrusive.

Moreover, it's also pretty much the pattern used everywhere else
(irqs, regulator, clocks, etc.), so it's going to be easier to review
as well.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Philipp Zabel]

Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard:
> Hi,
> 
> On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:
> > diff --git a/include/linux/reset.h b/include/linux/reset.h
> > index c4c097d..1cca8ce 100644
> > --- a/include/linux/reset.h
> > +++ b/include/linux/reset.h
> > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
> >  int reset_control_assert(struct reset_control *rstc);
> >  int reset_control_deassert(struct reset_control *rstc);
> >  int reset_control_status(struct reset_control *rstc);
> > +int reset_control_assert_shared(struct reset_control *rstc);
> > +int reset_control_deassert_shared(struct reset_control *rstc);
> 
> Shouldn't that be handled in reset_control_get directly?

This is about different expectations of the caller.
A driver calling reset_control_assert expects the reset line to be
asserted after the call. A driver calling reset_control_assert_shared
just signals that it doesn't care about the state of the reset line
anymore.
We could just as well call the two new functions
reset_control_deassert_get and reset_control_deassert_put.

regards
Philipp

--
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: [linux-usb-users] g_serial is not working in rx path (K3.14)

[Ramajayam S]

On Mon, Dec 14, 2015 at 9:50 PM, Felipe Balbi  wrote:
>
> hi,
>
> Ramajayam S  writes:
>> Hi
>>We are trying to enable g_serial in Intel platform and facing
>> issue with RX path.
>>
>> stable kernel version: K3.14
>
> you need to test with something more recent, like v4.3. If you are stuck
> with Intel' v3.14 kernel, then you need to ask for support from Intel,
ok
> I'm afraid
>
>> configuration enabled: USB_G_SERIAL
>>
>> testing details:
>>
>> writing from device side(ttyS0) to Windows Host(com 11-g_serial): working 
>> fine
>>
>> from ttyS0: echo test > /dev/ttyGS0  -- received in comm 11
>>
>> Typing any character from windows host pc(com 11 using teraterm) to
>> device side: not working
>
> what do you mean not working ? What happens ? Got usbmon trace or some
> usb sniffer ?
We have profiled using USB SW analyzer, by pressing enter key from USB
console(ttyGS0-com11 ) both the OUT/IN token sent from Host
PC(windows).
For IN token,
Working case: device is responded with proper data(approx 20 bytes for
command prompt display in ttyGSO-com11) and able to see raw data in
function   gs_write.
Non-Working Case: device is responded  with 1 byte of data and  able
to see raw data in function   gs_write (no response in command prompt
display --ttyGS0-com11)
>
> --
> 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

PROBLEM: general_protection when rmmod'ing xhci-pci

[chrysn]

[1.] One line summary of the problem:

general_protection when rmmod'ing xhci-pci

[2.] Full description of the problem/report:

since a bios update on my thinkpad yoga (20CD-0035GE, bios version
1.26), the laptop crashes occasionally when rmmod'ing xhci-pci (which
i've been using frequently in suspends since https://bugs.debian.org/790660).

i can't reproduce it precisely, but repeated rmmod and modprobe usually
does the 'trick'.

using the kdump mechanism, i've obtained the dmesg output of the crash
and an image thereof. i've used the `crash` and `objdump` tools to
identify what seems to be the culprit line to me:

$ crash ~/git/linux/vmlinux ./dump.201512141641
[...]
crash> bt
PID: 31037  TASK: 880197376f40  CPU: 2   COMMAND: "rmmod"
 #0 [880052a43b00] machine_kexec at 81051ad9
 #1 [880052a43b50] crash_kexec at 810eb9da
 #2 [880052a43c10] oops_end at 810175d4
 #3 [880052a43c30] general_protection at 81557cd8
[exception RIP: xhci_set_usb2_hardware_lpm+184]
RIP: a0bdf6c8  RSP: 880052a43ce0  RFLAGS: 00010046
RAX: 88001f429ce0  RBX: 880036c32800  RCX: 00cf
RDX: 0004  RSI: 880036c32800  RDI: 88014ffd22ac
RBP: 88014ffd2000   R8: 0005   R9: 0286
R10: 880212ef0ec8  R11:   R12: 2d322f326273752f
R13: 88014ffd2000  R14:   R15: 88014ffd22ac
ORIG_RAX:   CS: 0010  SS: 0018
 #4 [880052a43d28] usb_set_usb2_hardware_lpm at a091a8bc [usbcore]
 #5 [880052a43d40] usb_disable_device at a0917a6e [usbcore]
 #6 [880052a43d78] usb_disconnect at a090d9d0 [usbcore]
[...]

$ objdump -dS xhci-hcd.ko
[...]
6610 :
[... xhci_set_usb2_hardware_lpm+184 should therefore be 66c8 ...]
if (!udev->parent || udev->parent->parent ||
669c:   4d 8d bd ac 02 00 00lea0x2ac(%r13),%r15
66a3:   4c 89 ffmov%r15,%rdi
66a6:   e8 00 00 00 00  callq  66ab 

66ab:   44 0f b6 83 a2 04 00movzbl 0x4a2(%rbx),%r8d
66b2:   00 
66b3:   49 89 c1mov%rax,%r9
66b6:   49 8b 85 98 16 00 00mov0x1698(%r13),%rax
66bd:   41 8d 50 ff lea-0x1(%r8),%edx
66c1:   48 8d 04 d0 lea(%rax,%rdx,8),%rax
udev->descriptor.bDeviceClass == USB_CLASS_HUB)
return -EPERM;

if (udev->usb2_hw_lpm_capable != 1)
66c5:   4c 8b 20mov(%rax),%r12
66c8:   45 8b 5c 24 04  mov0x4(%r12),%r11d
[...]

that confuses me, as it seems to crash when it tries to reach into the
udev struct which has just some lines before successfully been used. (i
can't make heads or tails of how (%rax) should be *udev, but then again
my assembly is worse than rusty).

by the way, i don't think we are talking about a race condition here:
before using a self-built 4.4-rc4 kernel, i've used debian's 4.3, and
seen the crash in the very same function repeatedly.

[3.] Keywords (i.e., modules, networking, kernel):

xhci-pci usb pm

[4.] Kernel information

kernel built using `make deb-pkg` from 097b285d32c (4.4-rc4+).

[4.1.] Kernel version (from /proc/version):

Linux version 4.4.0-rc4+ (chrysn@hephaistos) (gcc version 5.3.1 20151207 
(Debian 5.3.1-3) ) #5 SMP Sun Dec 13 22:56:13 CET 2015

note that this has been observed on 4.3 as well.

[4.2.] Kernel .config file:

see attached

[5.] Most recent kernel version which did not have the bug:

unknown (i've had different suspend issues, and given the bios version
seems to play a role in this as well)

[6.] Output of Oops.. message (if applicable) with symbolic information
 resolved (see Documentation/oops-tracing.txt)

no oops happened. if the disassembled output in [2.] is insufficient,
i'd happily run my crash dump through any other tools to extract the
required information.

[7.] A small shell script or example program which triggers the
 problem (if possible)

$ rmmod xhci-pci

[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)

Linux hephaistos 4.4.0-rc4+ #5 SMP Sun Dec 13 22:56:13 CET 2015 x86_64 GNU/Linux
 
GNU C   5.3.1
GNU Make4.0
Binutils2.25.90.20151209
Util-linux  2.27.1
Mount   2.27.1
Linux C Library 2.21
Dynamic linker (ldd)2.21
Procps  3.3.10
Kbd 1.15.5
Console-tools   1.15.5
Sh-utils8.23
Udev228
Modules Loaded  ablk_helper ac aesni_intel aes_x86_64 af_alg ahci 
algif_skcipher ansi_cprng arc4 autofs4 battery binfmt_misc bluetooth bnep 
bridge btbcm btintel btrfs btrtl btusb button ccm cfg80211 coretemp 
cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace crc16 

RE: [PATCH] Add support for usbfs zerocopy.

[Alan Stern]

On Mon, 14 Dec 2015, David Laight wrote:

> From: Alan Stern
> > Sent: 14 December 2015 15:28
> ...
> > I thought of something else, a more serious problem.  According to the
> > man page for munmap(2), closing the file descriptor does not unmap the
> > region.  Therefore we need to explicitly make sure that the usbcore
> > module cannot be unloaded while any memory mappings exist, by calling
> > try_module_get(THIS_MODULE) when a mapping is created and
> > module_put(THIS_MODULE) when a mapping is removed.
> 
> Are you sure this is a problem?

I haven't actually tried to provoke a crash, if that's what you're 
asking.  Apart from that, yes, I'm sure this is a problem.

> It is more likely that either:
> 1) the mmap() holds a reference to the physical pages - so they don't
>   get freed even though the driver frees its reference to the memory.

The problem has nothing to do with the pages being freed.

> 2) when the driver frees the memory the user-space page tables are
>   invalidated - so the next access generates EFAULT.

I'm not sure what you're getting at here.  The page tables are 
invalidated when the user program calls munmap (or exits), and the 
driver frees the memory when that happens.

> Not that I've done the experiment (or tried to read the code).
> 
> If you need to monitor the mapping, you need to allow for partial unmaps.

That's not the problem either -- although I don't know how we should 
handle partial unmaps.  Can we disallow them?

The problem is that the user can map the memory, then close the file
descriptor, then rmmod the usbcore module, then unmap the memory
region.  When the unmap occurs, the memory subsystem will try to
dereference the usbdev_vm_ops structure -- which has been unloaded
along with the rest of usbcore.  This will cause an oops.

In theory we could prevent this problem by unmapping the memory when 
the file descriptor is closed.  But doing so would violate the 
guarantee in the munmap(2) documentation.

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 v7 0/4] usb/gadget: independent registration of gadgets and gadget drivers

[Peter Chen]

On Thu, Dec 10, 2015 at 11:13:24AM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi  writes:
> > Felipe Balbi  writes:
> >> Marek Szyprowski  writes:
> >>> Hello,
> >>>
> >>> This is a resurrection of the patches initially submitted by Ruslan
> >>> Bilovol in the following thread: https://lkml.org/lkml/2015/6/22/554
> >>>
> >>> The changes since the original submission (v5) includes rebase onto
> >>> latest linux-next branch, simplification of the code requested by Alan
> >>> Stern and Felipe Balbi, removal of a patch, which deleted __init/__exit
> >>> attributes (this change has been already merged) and fixes of the
> >>> checkpatch issues.
> >>>
> >>> This feature is urgently needed, because it is not longer possible to
> >>> use workaround to avoid deferred probe in UDC drivers due to
> >>> not-yet-probed i2c regulator drivers (for more information see
> >>> https://lkml.org/lkml/2015/10/30/374 ).
> >>>
> >>> This patchset has been successfully tested on Odroid XU3 boards with
> >>> DWC3 UDC driver being deferred by missing regulator drivers.
> >>
> >> there is one problem with this patchset. If I try to statically link
> >> gadget drivers, only one can be chosen, even though I can enable both
> >> dwc3 and dummy_hcd just fine. And, actually, this brings another
> >> problem. How do we handle systems which have 2 USB peripheral
> >> controllers (say, 2 instances of dwc3) and choose which gadget driver
> >> will bind to which controller ?
> >
> > We also seem to have issues with Kconfig. If I try to make gadget driver
> > built-in, when compiling I'll get asked again if I want gadget drivers
> > built-in.
> >
> > Another one: I just tried dummy_hcd built-in, g_zero built-in, dwc3 as a
> > module. I can never load anything to dwc3 ;-)
> 
> In all fairness, none of these are regressions. Can we agree to look at
> these during v4.5-rc so maybe v4.6 has a final solution ?
> 
> cheers
> 

Hi Felipe,

To support all of these, it will let legacy gadget driver usage as same
as configfs. If the user wants these relative new features, why not let
they use configfs. For legacy gadget drivers, it is better to keep the
main structure unchanging, then the user will not be surprise.

Here, we just want a solution for known issue, but not new features.

-- 

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

Re: [PATCH v2] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/15/2015 01:21 AM, Rob Herring wrote:


Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators
to
enable a system with an integrated USB OTG dual-role transceiver to
function
as  an USB  OTG dual-role device.  In addition  to sensing/controlling
Vbus,
the chip also passes thru the ID signal  from the USB  OTG connector.
On some Renesas boards,  this signal is  just fed into the SoC thru a
GPIO
pin --  there's no real  OTG controller, only host and gadget USB
controllers
sharing the same USB bus; however, we'd  like to allow host or gadget
drivers
to be loaded depending on the cable type,  hence the need for the MAX3355
extcon driver. The Vbus status signals are also  wired to GPIOs (however,
we
aren't currently interested in them),  the OFFVBUS# signal is controlled
by
the host controllers, there's  also the SHDN# signal wired to a GPIO, it
should be driven high for the  normal operation.



As multiple people have said, fix the spacing here.



You are the first to complain abou _this_ patch. If you don't have other
issues with this driver in which case you should have trimmed the reply at
this point), I'd like to keep my spacing as is. Thank you.


Your previous version was not "extcon-usb-gpio: add enable pin
support"[1] which has now been re-written to be max3355 specific?


   No, the MAX3355 driver pre-dates that version. First there was a driver, 
then I tried to re-use the existing stuff (there was no extcon-usb-gpio at the 
time of writing my driver), then had to return to the separate driver idea...



"So
what" and "I'd like to keep my spacing as is" aren't valid reasons.
Fix it, then I'll look at the rest again.


   I'll consider doing that if you care to explain what's the problem with my 
spacing. TIA.



Rob


MBR, 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 v2] extcon: add Maxim MAX3355 driver

[Rob Herring]

On Mon, Dec 14, 2015 at 11:36 AM, Sergei Shtylyov
 wrote:
> Hello.
>
> On 12/14/2015 04:24 AM, Rob Herring wrote:
>
>>> Maxim  Integrated MAX3355E chip integrates a  charge pump and comparators
>>> to
>>> enable a system with an integrated USB OTG dual-role transceiver to
>>> function
>>> as  an USB  OTG dual-role device.  In addition  to sensing/controlling
>>> Vbus,
>>> the chip also passes thru the ID signal  from the USB  OTG connector.
>>> On some Renesas boards,  this signal is  just fed into the SoC thru a
>>> GPIO
>>> pin --  there's no real  OTG controller, only host and gadget USB
>>> controllers
>>> sharing the same USB bus; however, we'd  like to allow host or gadget
>>> drivers
>>> to be loaded depending on the cable type,  hence the need for the MAX3355
>>> extcon driver. The Vbus status signals are also  wired to GPIOs (however,
>>> we
>>> aren't currently interested in them),  the OFFVBUS# signal is controlled
>>> by
>>> the host controllers, there's  also the SHDN# signal wired to a GPIO, it
>>> should be driven high for the  normal operation.
>>
>>
>> As multiple people have said, fix the spacing here.
>
>
>You are the first to complain abou _this_ patch. If you don't have other
> issues with this driver in which case you should have trimmed the reply at
> this point), I'd like to keep my spacing as is. Thank you.

Your previous version was not "extcon-usb-gpio: add enable pin
support"[1] which has now been re-written to be max3355 specific? "So
what" and "I'd like to keep my spacing as is" aren't valid reasons.
Fix it, then I'll look at the rest again.

Rob

[1] https://patchwork.ozlabs.org/patch/555378/
--
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] Add support for usbfs zerocopy.

[Peter Chen]

On Thu, Nov 26, 2015 at 01:19:13AM +0100, Steinar H. Gunderson wrote:
> +static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct usb_memory *usbm = NULL;
> + struct usb_dev_state *ps = file->private_data;
> + size_t size = vma->vm_end - vma->vm_start;
> + void *mem;
> + unsigned long flags;
> + dma_addr_t dma_handle;
> + int ret;
> +
> + ret = usbfs_increase_memory_usage(size + sizeof(struct usb_memory));
> + if (ret) {
> + return ret;
> + }

The braces are not needed.

-- 

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