hello linux

good morning linux http://recoval.be/truth.php?coast=b20hf5neea2af2 Joe -- 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 v8 4/8] usb: core: add power sequence handling for USB devices

Some hard-wired USB devices need to do power sequence to let the device work normally, the typical power sequence like: enable USB PHY clock, toggle reset pin, etc. But current Linux USB driver lacks of such code to do it, it may cause some hard-wired USB devices works abnormal or can't be

[PATCH v8 5/8] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

From: Peter Chen At device tree, we have no device node for chipidea core, the glue layer's node is the parent node for host and udc device. But in related driver, the parent device is chipidea core. So, in order to let the common driver get parent's node, we let the

[PATCH v8 6/8] ARM: dts: imx6qdl: Enable usb node children with

From: Joshua Clayton Give usb nodes #address and #size attributes, so that a child node representing a permanently connected device such as an onboard hub may be addressed with a attribute Signed-off-by: Joshua Clayton Signed-off-by: Peter

[PATCH v8 3/8] binding-doc: usb: usb-device: add optional properties for power sequence

Add optional properties for power sequence. Signed-off-by: Peter Chen Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH v8 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

Add binding doc for generic power sequence library. Signed-off-by: Peter Chen Acked-by: Philipp Zabel Acked-by: Rob Herring --- .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++ 1 file changed, 48

[PATCH v8 8/8] ARM: dts: imx6q-evi: Fix onboard hub reset line

From: Joshua Clayton Previously the onboard hub was made to work by treating its reset gpio as a regulator enable. Get rid of that kludge now that pwseq has added reset gpio support Move pin muxing the hub reset pin into the usbh1 group Signed-off-by: Joshua Clayton

[PATCH v8 2/8] power: add power sequence library

We have an well-known problem that the device needs to do some power sequence before it can be recognized by related host, the typical example like hard-wired mmc devices and usb devices. This power sequence is hard to be described at device tree and handled by related host driver, so we have

[PATCH v8 7/8] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

The current dts describes USB HUB's property at USB controller's entry, it is improper. The USB HUB should be the child node under USB controller, and power sequence properties are under it. Besides, using gpio pinctrl setting for USB2415's reset pin. Tested-by: Maciej S. Szmigiero

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

Hi all, This is a follow-up for my last power sequence framework patch set [1]. According to Rob Herring and Ulf Hansson's comments[2]. The kinds of power sequence instances will be added at postcore_initcall, the match criteria is compatible string first, if the compatible string is not matched

Re: USB crash on BeagleBoard-xM

Hi Oliver, On 10/10/2016 08:19, Oliver Neukum wrote: it is very hard for us to say something about that specific kernel. We don't know the kernel tree. And the error seems to be in the OF code. I think you are in the wrong list, or can you reproduce teh problem with a mainline kernel? I have

[RFC][PATCH 0/2] dwc2 fixes for HiKey

I wanted to send out two patches we're using on the dwc2 driver in order to make HiKey function. The first is seemingly just a bug fix we ran into when changing modes while the bus was auto-suspended. The second is a little more interesting as it works around a limitation of the the device to

Re: [RFC][PATCH 2/2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

On Thu, Oct 13, 2016 at 4:29 PM, John Stultz wrote: > From: Chen Yu > > The Hi6220's usb controller is limited in that it does not > automatically autonegotiate the usb speed. Thus it requires a > quirk so that we can manually negotiate the best usb

[PATCH] net: asix: Avoid looping when the device does not respond

Check answers from USB stack and avoid re-sending the request multiple times if the device does not respond. This fixes the following problem, observed with a probably flaky adapter. [62108.732707] usb 1-3: new high-speed USB device number 5 using xhci_hcd [62108.914421] usb 1-3: New USB device

[RFC][PATCH 1/2] usb: dwc2: Force port resume on switching to device mode

From: Chen Yu We've seen failures when switching between host and gadget mode, which was diagnosed as being caused due to the bus being auto-suspended when we switched. So this patch forces a port resume when switching to device mode if the bus is suspended. Cc: Wei Xu

[RFC][PATCH 2/2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

From: Chen Yu The Hi6220's usb controller is limited in that it does not automatically autonegotiate the usb speed. Thus it requires a quirk so that we can manually negotiate the best usb speed for the attached device. Cc: Wei Xu Cc: Guodong Xu

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

Hi! I've branched the kernel package on the OpenSUSE Build Server, I'll try to apply the patch there (this ought to be cleanest method). Starting from the root of the kernel tarball, the patch should be applied to drivers/pci/pci.c, am I right? Cheers, Pierre. Le mercredi 12 octobre 2016,

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

On Fri, 14 Oct 2016, Pierre de Villemereuil wrote: > Hi! > > I've branched the kernel package on the OpenSUSE Build Server, I'll > try to apply the patch there (this ought to be cleanest method). > > Starting from the root of the kernel tarball, the patch should be > applied to

Re: [PATCH] usb: gadget: dummy_hcd: clear struct gadget on removal

On Tue, 11 Oct 2016, Rob Herring wrote: > The addition of CONFIG_DEBUG_TEST_DRIVER_REMOVE uncovered a bug in > dummy_hcd driver. The problem is the gadget's struct device is allocated > once in the initcall, so re-probing the device causes this warning: > > [ 13.516309] kobject (8f92f8b4):

Re: [PATCH net] qmi_wwan: add support for Quectel EC21 and EC25

From: Bjørn Mork Date: Mon, 10 Oct 2016 21:12:49 +0200 > The Quectel EC21 and EC25 need the same "set DTR" request as devices > based on the MDM9230 chipset, but has no USB3 support. Our best guess > is that the "set DTR" functionality depends on chipset and/or > baseband firmware

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

Hi, Baolin Wang writes: >> Baolin Wang writes: > Baolin Wang writes: > I'm thinking this is a bug in configfs interface of Gadget API, not > dwc3. The only reason for this to happen would be if we get

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

Hi Felipe, On 13 October 2016 at 19:23, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: Baolin Wang writes: I'm thinking this is a bug in configfs interface of Gadget API, not dwc3. The only reason for

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

On 13 October 2016 at 20:17, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: > @@ -241,6 +241,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep > *dep, unsigned cmd, > int susphy = false;

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, Baolin Wang writes: @@ -241,6 +241,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned cmd, int susphy = false; int ret = -EINVAL;

Re: Interactive whiteboards

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: Interactive whiteboards

Okay, I will collect the following information: 1) Plugging and unplugging USB diff with: cat /sys/kernel/debug/usb/devices 2) Plugging and unplugging USB diff with: cat /proc/bus/input/devices 3) What can I do to know for sure that the system sees the device as a serial device? Is there any

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi Felipe, On 13 October 2016 at 19:22, Felipe Balbi wrote: > > Hi, > > Janusz Dziedzic writes: Baolin Wang writes: >>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >>> index

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

Hi, Baolin Wang writes: >>> Baolin Wang writes: >>> I'm thinking this is a bug in configfs interface of Gadget API, not >>> dwc3. The only reason for this to happen would be if we get to >>> ->udc_stop() with endpoints still enabled.

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, On 13 October 2016 at 19:22, Felipe Balbi wrote: > > Hi, > > Janusz Dziedzic writes: Baolin Wang writes: >>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >>> index

[PATCH 4/6] memstick: rtsx_usb_ms: Manage runtime PM when accessing the device

Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. This is currently not the case and it could trigger various errors. Fix this by properly deal with runtime PM in this regards. This means making sure the device is

[PATCH 1/6] mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused

The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no SD card is inserted. This is wrong, as it could cause the device to remain runtime resumed when it's unused. Fix this behaviour. Tested-by: Ritesh Raj Sarraf Cc: Cc: Alan

[PATCH 6/6] mmc: core: Don't power off the card when starting the host

The MMC_CAP2_NO_PRESCAN_POWERUP was invented to avoid running the power up sequence, mmc_power_up(), during ->probe() of the mmc host driver, but instead defer this to the mmc detect work. This is especially useful for those hosts that suffers from a long initialization time, as this time would

[PATCH 5/6] mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend

Enable runtime PM autosuspend for the rtsx_usb_sdmmc driver to avoid the device being runtime suspended and runtime resumed between each request. Let's use a default timeout of 50ms, to be consistent with other mmc hosts. Cc: Ritesh Raj Sarraf Cc: Alan Stern

[PATCH 3/6] memstick: rtsx_usb_ms: Runtime resume the device when polling for cards

From: Alan Stern Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. Therefore when the rtsx_usb_ms driver polls for inserted memstick cards, let's add pm_runtime_get|put*() to make sure

[PATCH 2/6] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led

Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device, must be done when it's runtime resumed. Currently this isn't case when changing the led, so let's fix this by adding a pm_runtime_get_sync() and a pm_runtime_put() around those operations. Reported-by: Ritesh Raj Sarraf

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

The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing an rtsx_usb device (managed by an mfd driver) while communicating with the cards. The mmc/sd and memstick devices are children of the usb device. Issues has been reported [1] for rtsx, which have been investigated,

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, Janusz Dziedzic writes: >>> Baolin Wang writes: >> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >> index 1783406..ca2ae5b 100644 >> --- a/drivers/usb/dwc3/gadget.c >> +++

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

On 13 October 2016 at 18:56, Felipe Balbi wrote: > > Hi, > > Felipe Balbi writes: >> Hi, >> >> Baolin Wang writes: >> I'm thinking this is a bug in configfs interface of Gadget API, not >> dwc3. The only reason for this to

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

On 13 October 2016 at 12:41, Baolin Wang wrote: > On 13 October 2016 at 17:49, Felipe Balbi wrote: >> >> Hi, >> >> Baolin Wang writes: > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index

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

Hi, Felipe Balbi writes: > Hi, > > Baolin Wang writes: > I'm thinking this is a bug in configfs interface of Gadget API, not > dwc3. The only reason for this to happen would be if we get to > ->udc_stop() with endpoints still enabled. >

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

On 13 October 2016 at 17:49, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1783406..ca2ae5b 100644 --- a/drivers/usb/dwc3/gadget.c +++

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

Hi, Baolin Wang writes: I'm thinking this is a bug in configfs interface of Gadget API, not dwc3. The only reason for this to happen would be if we get to ->udc_stop() with endpoints still enabled. Can you check if that's the case? i.e. can you

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, Baolin Wang writes: >>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >>> index 1783406..ca2ae5b 100644 >>> --- a/drivers/usb/dwc3/gadget.c >>> +++ b/drivers/usb/dwc3/gadget.c >>> @@ -241,6 +241,9 @@ int

Re: [PATCH v7 2/8] power: add power sequence library

On Thu, Oct 13, 2016 at 09:04:42AM +0200, Heiko Stuebner wrote: > > > > +static int __init pwrseq_generic_register(void) > > > > +{ > > > > + struct pwrseq_generic *pwrseq_gen; > > > > + int i; > > > > + > > > > + for (i = 0; i < CONFIG_PWRSEQ_GENERIC_INSTANCE_NUMBER; i++) { > >

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

On 13 October 2016 at 16:28, Janusz Dziedzic wrote: > On 13 October 2016 at 10:21, Baolin Wang wrote: >> Hi, >> >> On 13 October 2016 at 16:16, Janusz Dziedzic >> wrote: >>> On 13 October 2016 at 09:37, Baolin Wang

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

On 13 October 2016 at 10:21, Baolin Wang wrote: > Hi, > > On 13 October 2016 at 16:16, Janusz Dziedzic > wrote: >> On 13 October 2016 at 09:37, Baolin Wang wrote: >>> Hi, >>> >>> On 13 October 2016 at 15:06, Felipe

Re: Interactive whiteboards

On Thu, Oct 13, 2016 at 10:24:38AM +0200, María Cano wrote: > Ok, I still have more IWB to investigate. I'll paste the new information soon. > We use a 3.10 kernel in our day-to-day (because is the kernel we have > fewer problems) but if you think it is advisable, I can use a newer > kernel (I

Re: Interactive whiteboards

Ok, I still have more IWB to investigate. I'll paste the new information soon. We use a 3.10 kernel in our day-to-day (because is the kernel we have fewer problems) but if you think it is advisable, I can use a newer kernel (I recently tested with the kernel 4.6.1 and all these boards were not

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, On 13 October 2016 at 16:16, Janusz Dziedzic wrote: > On 13 October 2016 at 09:37, Baolin Wang wrote: >> Hi, >> >> On 13 October 2016 at 15:06, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Baolin Wang

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

On 13 October 2016 at 09:37, Baolin Wang wrote: > Hi, > > On 13 October 2016 at 15:06, Felipe Balbi wrote: >> >> Hi, >> >> Baolin Wang writes: >>> When system has stpped the gadget, we should avoid queuing any requests >> >>

Re: [RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

On 13 October 2016 at 15:54, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Hi, >> >> On 13 October 2016 at 15:08, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Baolin Wang writes: @@ -1487,10 +1496,22

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

Hi, On 13 October 2016 at 15:51, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Hi, >> >> On 13 October 2016 at 15:02, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Baolin Wang writes: @@ -1742,6

Re: [RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

Hi, Baolin Wang writes: > Hi, > > On 13 October 2016 at 15:08, Felipe Balbi wrote: >> >> Hi, >> >> Baolin Wang writes: >>> @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, >>> int is_on) >>> >>>

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

Hi, Baolin Wang writes: > Hi, > > On 13 October 2016 at 15:02, Felipe Balbi wrote: >> >> Hi, >> >> Baolin Wang writes: >>> @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g) >>> dwc->gadget_driver

Re: [RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

Hi, On 13 October 2016 at 15:08, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, >> int is_on) >> >> is_on = !!is_on; >> >> +try_again: >>

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, On 13 October 2016 at 15:06, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> When system has stpped the gadget, we should avoid queuing any requests > > queueing is *not* a problem. Starting is. In fact, that's what your > patch is doing.

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

Hi, On 13 October 2016 at 15:02, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g) >> dwc->gadget_driver = NULL; >> spin_unlock_irqrestore(>lock, flags); >>

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

Hi, Baolin Wang writes: > @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g) > dwc->gadget_driver = NULL; > spin_unlock_irqrestore(>lock, flags); > > + /* > + * Since the xHCI will share the same interrupt with gadget,

Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

Hi, Baolin Wang writes: > When system has stpped the gadget, we should avoid queuing any requests queueing is *not* a problem. Starting is. In fact, that's what your patch is doing. > which will cause tranfer failed. Thus adding some disconnect checking to

Re: [RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

Hi, Baolin Wang writes: > @@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, > int is_on) > > is_on = !!is_on; > > +try_again: > spin_lock_irqsave(>lock, flags); > ret = dwc3_gadget_run_stop(dwc, is_on, false); >

Re: [PATCH v7 2/8] power: add power sequence library

Am Donnerstag, 13. Oktober 2016, 09:22:16 CEST schrieb Peter Chen: > On Wed, Oct 12, 2016 at 12:30:29PM +0200, Heiko Stuebner wrote: > > Hi, > > > > Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen: > > > We have an well-known problem that the device needs to do some power > > >

Re: xhci_hcd crash on linux 4.7.0

Hi, (please avoid top-posting, see: http://daringfireball.net/2007/07/on_top) Alex Damian writes: > Forgot to mention, I just reproduced it on the mainline 4.8.1 kernel. > > On Wed, Oct 12, 2016 at 5:13 PM, Alex Damian wrote: >> Hello, >> >>

Re: Interactive whiteboards

A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Thu, Oct 13, 2016 at