W dniu 14.07.2014 23:59, Jonathan pisze:
> Julian,
>
> My issue appears to be related to the Etron xhci controller on my motherboard
> and not the ASMedia chipset in my USB dock. You can identify your xhci
> controller with the lspci command which will help to determine if we are
> actually hav
On Sun, Jul 06, 2014 at 09:26:02PM +0500, Abbas Raza wrote:
> From: Abbas Raza
>
> There are 2 methods for ZLP (zero-length packet) generation:
> 1) In software
> 2) Automatic generation by device controller
>
> 1) is implemented in UDC driver and it attaches ZLP to IN packet if
>descriptor-
Hi Paul,
On 6/25/14, 1:24 PM, Paul Zimmerman wrote:
>> From: Dinh Nguyen [mailto:dinh.li...@gmail.com]
>> Sent: Wednesday, June 25, 2014 8:52 AM
>>
>> I was wondering if you have ever tested this driver with a USB/ethernet
>> dongle? I'm using the apple usb/ethernet dongle, which is basically just
From: Olivier Sobrie
Date: Mon, 14 Jul 2014 12:08:49 +0200
> The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
> in the code. So, remove it.
>
> Signed-off-by: Olivier Sobrie
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a me
From: Olivier Sobrie
Date: Mon, 14 Jul 2014 12:08:50 +0200
> When the module sends bursts of data, sometimes a deadlock happens in
> the hso driver when the tty buffer doesn't get the chance to be flushed
> quickly enough.
>
> Remove the endless while loop in function put_rxbuf_data() which is
>
>> >> I should have been more specific then. I think I understand, but to
>> >> be sure, if I splice a USB cable, power VBUS with an external 5V power
>> >> supply, and connect a host and device, the device will work as if the
>> >> cable was connected to the host normally?
>> >
>> > Yes. But why
Julian,
My issue appears to be related to the Etron xhci controller on my motherboard
and not the ASMedia chipset in my USB dock. You can identify your xhci
controller with the lspci command which will help to determine if we are
actually having the same problem.
Please see:
https://bugzilla.
On Mon, 2014-07-14 at 11:04 -0400, Alan Stern wrote:
> On Mon, 14 Jul 2014, Oliver Neukum wrote:
>
> > On Mon, 2014-07-14 at 07:50 -0700, Greg KH wrote:
> >
> > > So if I have hubs with the same "broken" port, I'll only get one
> > > message? What if I have 2 "broken" ports, I'll keep getting th
Hello,
the same happens to me on an up-to-date Fedora 20 installation with
Lacie Rugged USB3:
[ 217.024320] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd
[ 217.042067] usb 4-2: New USB device found, idVendor=059f, idProduct=1061
[ 217.042077] usb 4-2: New USB device strings: Mfr=2
+Gregory
On Mon, Jul 14, 2014 at 11:36 AM, Julius Werner wrote:
>> Nope - since CONFIG_USB_XHCI_MVEBU can be 'y' or 'm' we need the ifneq
>> here (which matches against both) to ensure xhci-mvebu.o is built is
>> part of xhci-plat-hcd.o.
>
> Oh... does it make sense to have it tristate at all, th
Hi Maciej,
The patch is up here, I think you should've been CCed on it:
https://lkml.org/lkml/2014/7/8/571
I've only been able to test it on 3.8 with a normal controller, so
please test it on both 3.2 and later-than-3.2 with both your quirky
and a normal host controller (if you can), and add your
> Nope - since CONFIG_USB_XHCI_MVEBU can be 'y' or 'm' we need the ifneq
> here (which matches against both) to ensure xhci-mvebu.o is built is
> part of xhci-plat-hcd.o.
Oh... does it make sense to have it tristate at all, then? Looks like
was never really buildable as an independent module (and
Julius, I am back from vacation and ready to do further tests, or to
test your patch if it is available. Apologies for the delay, I have
been away from the hardware for a week.
Thanks
Maciej Puzio
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to
[ +CC: Jiri and linux-input ]
On Wed, Jul 09, 2014 at 03:07:33PM +0200, Johan Hovold wrote:
> On Mon, Jul 07, 2014 at 10:34:30PM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Jul 07, 2014 at 11:24:42AM +0200, Johan Hovold wrote:
>
> > > I ended up getting the same laptop so now I'm facing the same
Hello.
On 07/14/2014 09:05 PM, Robert Jarzmik wrote:
Use devm_* helpers in the probe function to simplify the error path and
the remove path.
Signed-off-by: Robert Jarzmik
Cc: Sergei Shtylyov
---
Since V1: Addressed Sergei's comments
Since V2: Addressed Sergei's comments on includes
---
On Mon, Jul 14, 2014 at 5:49 AM, Vivek Gautam wrote:
> The host controller by itself may sometimes need to handle PHY
> and/or calibrate some of the PHY settings to get full support out
> of the PHY controller. The PHY core provides a calibration
> funtionality now to do so.
> Therefore, facilitat
On Thu, Jul 10, 2014 at 11:34 AM, Julius Werner wrote:
>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
>> index af89a90..bafba71 100644
>> --- a/drivers/usb/host/Makefile
>> +++ b/drivers/usb/host/Makefile
>> @@ -15,19 +15,19 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
>> xhc
Remove mach specific includes and use platform_data includes.
Signed-off-by: Robert Jarzmik
---
drivers/usb/gadget/pxa27x_udc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index fed8b2e..04aced8 100644
--
Add support for device-tree device discovery. If devicetree is not
provided, fallback to legacy platform data "discovery".
Signed-off-by: Robert Jarzmik
Cc: devicet...@vger.kernel.org
---
Since V1: change OF id mrvl,pxa27x_udc -> marvell,pxa27x-udc
This is a consequence of other DT rev
Use devm_* helpers in the probe function to simplify the error path and
the remove path.
Signed-off-by: Robert Jarzmik
Cc: Sergei Shtylyov
---
Since V1: Addressed Sergei's comments
Since V2: Addressed Sergei's comments on includes
---
drivers/usb/gadget/pxa27x_udc.c | 54 +++---
Add documentation for device-tree binding of arm PXA 27x udc (usb
device) driver.
Signed-off-by: Robert Jarzmik
Cc: devicet...@vger.kernel.org
---
Since V1: change OF id mrvl,pxa27x_udc -> marvell,pxa27x-udc
This is a consequence of other DT reviews on the marvell
namings.
Si
On Mon, 14 Jul 2014, Oliver Neukum wrote:
> On Mon, 2014-07-14 at 07:50 -0700, Greg KH wrote:
>
> > So if I have hubs with the same "broken" port, I'll only get one
> > message? What if I have 2 "broken" ports, I'll keep getting the
> > messages?
>
> Well, hubs are not a problem.
>
> > I'm not
On Mon, 14 Jul 2014, Jörn Horstmann wrote:
> Hi USB Developers, I'd like to report a suspend problem on the Thinkpad E540
> and hope you can help me debug or fix it. The laptop fails to suspend, meaning
> the fan stays on and resume is not possible. The problem exists at least
> between kernel ver
On Mon, 14 Jul 2014, Grant wrote:
> >> >> You are right, the device will get 5 volts. However it is still part
> >> >> of the spec that 2ms without a SOF will force the device into suspend
> >> >> mode, so it will use less than 2ma. So depending on your definition of
> >> >> function, there will b
Sorry, what I meant was that 3.13 was the earliest kernel I tried,
since it is the ubuntu 14.04 default, and it also did not work there.
If there is a way to determine the changes between bios revisions 1.61
and 2.07, that might help, but I don't know how to do that.
Thanks,
Jörn
On Mon, Jul 14
On Mon, 14 Jul 2014, Lee Jones wrote:
> On Fri, 11 Jul 2014, Alan Stern wrote:
> > On Fri, 11 Jul 2014, Peter Griffin wrote:
> > > On Thu, 10 Jul 2014, Alan Stern wrote:
> > >
> > > > On Thu, 10 Jul 2014, Peter Griffin wrote:
> > > >
> > > > > This driver adds support for the USB HCD present in
On Mon, 2014-07-14 at 07:50 -0700, Greg KH wrote:
> So if I have hubs with the same "broken" port, I'll only get one
> message? What if I have 2 "broken" ports, I'll keep getting the
> messages?
Well, hubs are not a problem.
> I'm not suggesting that we have a "broken port" flag per port for ea
On Mon, Jul 14, 2014 at 03:50:03PM +0200, Jörn Horstmann wrote:
> Hi USB Developers, I'd like to report a suspend problem on the Thinkpad E540
> and hope you can help me debug or fix it. The laptop fails to suspend, meaning
> the fan stays on and resume is not possible. The problem exists at least
On Mon, Jul 14, 2014 at 11:49:38AM +0530, Kishon Vijay Abraham I wrote:
> Greg,
>
> On Thursday 05 June 2014 06:22 PM, Heikki Krogerus wrote:
> > This allows resources such as GPIOs and clocks, which can be
> > matched based on the device name when requested, to be
> > assigned even when PLATFORM_
On Mon, Jul 14, 2014 at 03:39:49PM +0200, oneu...@suse.de wrote:
> From: Oliver Neukum
>
> Some laptops have an internal port for a BT device which picks
> up noise when the kill switch is used, but not enough to trigger
> printk_rlimit(). So we shouldn't log consecutive faults of this kind.
>
>
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
system (SS-OVS) which consists of an excersizer and analyzer.
USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
Link Layer Validation (LVS).
Some modifications are needed for an embedded Linux USB host t
1st patch exports usb_alloc_dev symbol so that lvstest driver in second
patch can be compiled as module.
Pratyush Anand (2):
USB: Add EXPORT_SYMBOL for usb_alloc_dev
USB: Add LVS Test device driver
Documentation/ABI/testing/sysfs-bus-usb-lvstest | 47 +++
drivers/usb/core/usb.c
usb_alloc_dev is used by lvstest driver now which can be built as
module. Therefore export usb_alloc_dev symbol.
Signed-off-by: Pratyush Anand
---
drivers/usb/core/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 4d11449..2dd2362 100
From: Oliver Neukum
Some laptops have an internal port for a BT device which picks
up noise when the kill switch is used, but not enough to trigger
printk_rlimit(). So we shouldn't log consecutive faults of this kind.
Signed-off-by: Oliver Neukum
---
drivers/usb/core/hub.c | 11 ---
1
On Mon, 14 Jul 2014 12:08:50 +0200
Olivier Sobrie wrote:
> When the module sends bursts of data, sometimes a deadlock happens in
> the hso driver when the tty buffer doesn't get the chance to be flushed
> quickly enough.
>
> Remove the endless while loop in function put_rxbuf_data() which is
> c
Some quirky PHYs may require to be calibrated post the
hcd initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along
with Synopsys's DWC3 controller, is one such PHY which needs
to be calibrated post xhci's reset at initialization time and
at resume time, to get the controller wo
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and U
Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level as well as
Tx-Vboost-Level should be controlled for Super-Speed op
Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.
Signed-off-by: vivek Gautam
---
drivers/phy/phy-core.c | 36
This series is based on Heikki's patches for simpliefied phy lookup table:
[PATCHv2 0/6] phy: simplified phy lookup [1], applied against 'next' branch
of Kishon's linux-phy tree.
Changes since v2:
1) Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy,
in order to make it
>> >> You are right, the device will get 5 volts. However it is still part
>> >> of the spec that 2ms without a SOF will force the device into suspend
>> >> mode, so it will use less than 2ma. So depending on your definition of
>> >> function, there will be power, but no activity. If it uses more t
Hello,
On 2014-07-10 07:22, Joonyoung Shim wrote:
The usb device will autoresume from choose_wakeup() if it is
autosuspended with the wrong wakeup setting, but below errors occur
because usb3503 misc driver will switch to standby mode when suspended.
As add USB_QUIRK_RESET_RESUME, it can stop s
Hello,
On 2014-07-10 07:22, Joonyoung Shim wrote:
The usb3503 needs to switch to standby mode while suspending and should
switch to hub mode when resumed. Also we can control clock on PM
function.
Signed-off-by: Joonyoung Shim
Acked-by: Marek Szyprowski
---
drivers/usb/misc/usb3503.c |
W dniu 14.07.2014 11:50, Sebastian Andrzej Siewior pisze:
On 07/14/2014 11:35 AM, Andrzej Pietrasiewicz wrote:
A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same
When the module sends bursts of data, sometimes a deadlock happens in
the hso driver when the tty buffer doesn't get the chance to be flushed
quickly enough.
Remove the endless while loop in function put_rxbuf_data() which is
called by the urb completion handler.
If there isn't enough room in the
The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
in the code. So, remove it.
Signed-off-by: Olivier Sobrie
---
drivers/net/usb/hso.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index a3a0586..9ca2b41 100644
On Thu, Jul 10, 2014 at 06:12:48PM +0300, Tuomas Tynkkynen wrote:
> Thierry,
>
> Since Stephen's on a vacation, I'd like to double-check with you that the DT
> changes looks good. Greg has applied these to the USB tree today.
Yes, looks sane to me. Not sure how much people will like to see the DT
On 07/14/2014 11:35 AM, Andrzej Pietrasiewicz wrote:
> A userland tool for assembling gadgets with configfs needs to know what
> it can or cannot do, that is, what usb functions are available.
> Knowing what functions there are is not the same thing as being able
> to discover it, so in fact this l
W dniu 11.07.2014 15:22, Sebastian Andrzej Siewior pisze:
On 07/10/2014 04:17 PM, Krzysztof Opasiak wrote:
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.
Using udc clas is not a good idea. This may cause failures in userspace.
failu
Hi,
CC: Sergei, Yoshihiro
On Wed, Jul 9, 2014 at 3:47 PM, Antoine Ténart
wrote:
> This patch adds the support to PHY framework in HCD code while keeping
> the USB PHY compatibility. Changes are done in both the HCD common code
> and in the drivers accessing its PHY. This is done in two steps:
>
On Fri, 11 Jul 2014, Alan Stern wrote:
> On Fri, 11 Jul 2014, Peter Griffin wrote:
> > On Thu, 10 Jul 2014, Alan Stern wrote:
> >
> > > On Thu, 10 Jul 2014, Peter Griffin wrote:
> > >
> > > > This driver adds support for the USB HCD present in STi
> > > > SoC's from STMicroelectronics. It has bee
51 matches
Mail list logo
