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
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 recogniz
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 core's device node equals glu
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 Chen
---
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
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 a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentatio
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 insertions(+)
create mode 100644
Documentation/devicetree/binding
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 crea
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
Signed-off-by:
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
Signed-off-by: Peter Chen
-
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 b
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 r
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 neg
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 speed for
> the attached device.
>
> Cc: Wei Xu
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 f
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
Cc: Guodong Xu
Cc: Amit
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
Cc: Amit Pundir
Cc: Rob Herring
Cc: Mark Rutlan
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, 14
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 drivers/pci/pci
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): trie
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 generation. But
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 to
> ->udc_stop() with endpoints still enabled.
>
>>
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 this to happen would be if we get to
->udc_stop() with en
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;
> int
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;
+ if (!dwc->pul
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 includ
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 ot
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 1783406..ca2ae5b 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>
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.
>>>
>>> Can you check if that's the case?
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 1783406..ca2ae5b 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++
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 runtim
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 Stern
Signed-off-by: Ulf Hansson
---
drivers/mm
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 oth
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
Signed-off-by: Ulf Hansson
---
driv
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 accesses is done when the
rtsx us
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
Tes
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, disc
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
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -241,6 +241,9 @@ int dwc
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 happen would be if we get to
>> ->udc_stop() with endpoints s
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 1783406..ca2ae5b 100644
> --- a/drivers/usb/dwc3/gadget.c
>>
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.
>
> Can you check if that's the case? i.
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
+++ b/drivers/usb/dwc3/gadget.c
@@ -241,6
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 check if any endpoints
>>>
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 dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep,
>
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++) {
> > >
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 wrote:
Hi,
On 13 October 2016 at 15:06, Felipe Balbi 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 wrote:
>>> Hi,
>>>
>>> On 13 October 2016 at 15:06, Felipe Balbi wrote:
Hi,
Baolin Wang writes:
> When system has
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 rece
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 work
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 writes:
When system has stpped the gadget, we should avoid queuing any requests
>>>
>>> q
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
>>
>> queueing is *not* a problem. Starting is. In fact, that's what your
>>
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 @@ static int dwc3_gadget_pullup(struct usb_gadget
*g, int is_on)
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 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
dwc->gadget_driver
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)
>>>
>>> is_on = !!is_on;
>>>
>>> +try_again:
>>> spin_lock_irqsave(
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 = NULL;
>>> spin_unlock_irqrestore(&dwc->lock, flags);
>>>
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:
>> spin_lock_irqsave(&dwc->lock, flags);
>> ret = dwc3_gad
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.
OK.
>
>> which will cause tranfer failed. Th
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(&dwc->lock, flags);
>>
>> + /*
>> + * Since the xHCI
Hi,
Baolin Wang writes:
> @@ -1742,6 +1791,17 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
> dwc->gadget_driver = NULL;
> spin_unlock_irqrestore(&dwc->lock, flags);
>
> + /*
> + * Since the xHCI will share the same interrupt with gadget, thus when
> + * f
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
^^^
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(&dwc->lock, flags);
> ret = dwc3_gadget_run_stop(dwc, is_on, false);
> spin_unlock_irqrestore(&
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
> > > s
61 matches
Mail list logo
