On Wed, 2014-03-19 at 17:58 -0700, Grant Grundler wrote:
> Oliver,
> So even with this additional change to usbnet_probe, the device is
> reporting a link but can't transmit packets.
> I've tried with three different USB dongles (AX88178, AX88772B, SMSC75xx).
>
> In the last case, I ran "ifconfig
Hi,
On Thursday 20 March 2014 12:26 PM, Chanwoo Choi wrote:
> Hi,
>
> On 03/20/2014 02:20 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 18 M
Hi.
We have some USB to CAN devices, and we have the typical problem that
the device node (e.g. /dev/pcan0, /dev/pcan1, etc.) is not always the
same for the same physical port. I understand that this is expected,
but that is solved by inspecting a bit the information that the kernel
provides to as
Hola Alejandro,
Alejandro Exojo wrote:
> But it seems to be failing quite a lot for me, at least on some kernel
> versions. I was expecting that `udevadm info --query=path` or `lsusb
> -t` would report exactly the same across reboots if the devices are
> the same ones, plugged to the same physical
From: Aaro Koskinen
> octeon-hcd will crash the kernel when SLOB is used. This usually happens
> after the 18-byte control transfer when a device descriptor is read.
> The DMA engine is always transfering full 32-bit words and if the
> transfer is shorter, some random garbage appears after the buff
2014-03-20 10:52 GMT+01:00 Peter Stuge :
> I understand the expectation, but I don't think Linux meets it.
>
> The difference in your logs is the usbX bus number, which really can
> not persist beyond the lifetime of that bus.
>
> Think of a laptop with a CardBus slot. CardBus is just PCI. If you
>
On Wed, 2014-03-19 at 23:04 +0100, Cédric Cabessa wrote:
[]
> diff --git a/drivers/staging/usbip/usbip_common.c
> b/drivers/staging/usbip/usbip_common.c
[]
> @@ -178,8 +178,8 @@ static void usbip_dump_usb_ctrlrequest(struct
> usb_ctrlrequest *cmd)
> }
>
> pr_debug(" ");
> -
On Thu, 20 Mar 2014, Alejandro Exojo wrote:
> 2014-03-20 10:52 GMT+01:00 Peter Stuge :
> > I understand the expectation, but I don't think Linux meets it.
> >
> > The difference in your logs is the usbX bus number, which really can
> > not persist beyond the lifetime of that bus.
> >
> > Think of
On Thu, 20 Mar 2014, David Laight wrote:
> From: Aaro Koskinen
> > octeon-hcd will crash the kernel when SLOB is used. This usually happens
> > after the 18-byte control transfer when a device descriptor is read.
> > The DMA engine is always transfering full 32-bit words and if the
> > transfer is
From: Suresh Gupta
DMA mapping functions are moved to common place in udc_core.c
which expect the DMA operation of gadget device
Signed-off-by: Suresh Gupta
---
Changes from previous version:
* Added description
drivers/usb/gadget/fsl_udc_core.c | 1 +
1 file changed, 1 insertion(+)
diff --g
This fix the fsl usb gadget driver in a way that the usb device
will be only "pulled up" on requests only when vbus is powered
Signed-off-by: Suresh Gupta
---
Changes from previous version:
* Removed re-factored code, Will send another patch for re-factoring
duplicated code
* Changed Descriptio
> > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > fsl_udc_devtype[] = {
> > > > > }, {
> > > > > .name = "imx-udc-mx51",
> > > > > }, {
> > > > > + .name = "fsl-usb2-udc",
> > > >
> > > > why aren't you just using chipidea ?
> > > > [
Hello!
I am developing on a phyFlex iMx.6 and want to send data via USB to a
Host connected via the OTG port.
The data is images from an image sensor, so I need a high performance (USB 2.0).
I am familiar with USB on the host side, but not the gadget side.
What's the best/easiest way to implement
On Wed, 19 Mar 2014, James Bottomley wrote:
> > Basically, usb-storage deadlocks when the SCSI error handler invokes
> > the eh_device_reset_handler callback while a command is running. The
> > command has timed out and will never complete normally, because the
> > device's firmware has crashed.
On Wed, 19 Mar 2014, Dan Williams wrote:
> Once usb-acpi has set the port's connect type the usb_device's
> ->removable attribute can be set in the standard location
> set_usb_port_removable().
>
> This also changes behavior in the case where the firmware says that the
> port connect type is unkn
On Fri, Mar 21, 2014 at 01:57:18AM +0530, Suresh Gupta wrote:
> This fix the fsl usb gadget driver in a way that the usb device
> will be only "pulled up" on requests only when vbus is powered
>
> Signed-off-by: Suresh Gupta
> ---
> Changes from previous version:
> * Removed re-factored code, Wil
On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
> > > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > > fsl_udc_devtype[] = {
> > > > > > }, {
> > > > > > .name = "imx-udc-mx51",
> > > > > > }, {
> > > > > > + .name
On Thu, 2014-03-20 at 11:36 -0400, Alan Stern wrote:
> On Wed, 19 Mar 2014, James Bottomley wrote:
>
> > > Basically, usb-storage deadlocks when the SCSI error handler invokes
> > > the eh_device_reset_handler callback while a command is running. The
> > > command has timed out and will never com
Hi,
On Thu, Mar 20, 2014 at 09:02:52AM -0700, gre...@linuxfoundation.org wrote:
> On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
> > > > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > > > fsl_udc_devtype[] = {
> > > > > > > }, {
> > > > > >
On Thu, 2014-03-20 at 11:58 -0400, Alan Stern wrote:
> On Wed, 19 Mar 2014, Dan Williams wrote:
>
> > Once usb-acpi has set the port's connect type the usb_device's
> > ->removable attribute can be set in the standard location
> > set_usb_port_removable().
> >
> > This also changes behavior in th
On Thu, 20 Mar 2014, James Bottomley wrote:
> OK, so I think we have three things to do
>
> 1. Investigate SCSI and fix it's abort state problem that's causing
> it not to send the abort second time around
> 2. Fix usb-storage to fail a reset it can't do (i.e. device reset
>
On Thu, Mar 20, 2014 at 12:15 AM, Oliver Neukum wrote:
...
> I have an idea. Could you test this patch?
...
> - if (dev->wait) {
..
> + if (waitqueue_active(&dev->wait)) {
Yes - building new image now (and transfer to USB and boot from USB).
Should know in an hour or so (doing other t
On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote:
> On Thu, 20 Mar 2014, James Bottomley wrote:
>
> > OK, so I think we have three things to do
> >
> > 1. Investigate SCSI and fix it's abort state problem that's causing
> > it not to send the abort second time around
> > 2. F
On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote:
> On Thu, 20 Mar 2014, James Bottomley wrote:
>
> > OK, so I think we have three things to do
> >
> > 1. Investigate SCSI and fix it's abort state problem that's causing
> > it not to send the abort second time around
> > 2. F
On Thu, 20 Mar 2014, James Bottomley wrote:
> On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote:
> > On Thu, 20 Mar 2014, James Bottomley wrote:
> >
> > > OK, so I think we have three things to do
> > >
> > > 1. Investigate SCSI and fix it's abort state problem that's causing
> > >
On Thu, 20 Mar 2014, James Bottomley wrote:
> On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote:
> > On Thu, 20 Mar 2014, James Bottomley wrote:
> >
> > > OK, so I think we have three things to do
> > >
> > > 1. Investigate SCSI and fix it's abort state problem that's causing
> > >
On Thu, 20 Mar 2014, James Bottomley wrote:
> OK, so I think we have three things to do
>
> 1. Investigate SCSI and fix it's abort state problem that's causing
> it not to send the abort second time around
> 2. Fix usb-storage to fail a reset it can't do (i.e. device reset
>
On Thu, 2014-03-20 at 15:48 -0400, Alan Stern wrote:
> On Thu, 20 Mar 2014, James Bottomley wrote:
>
> > On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote:
> > > On Thu, 20 Mar 2014, James Bottomley wrote:
> > >
> > > > OK, so I think we have three things to do
> > > >
> > > > 1. Investig
On Thu, 2014-03-20 at 15:59 -0400, Alan Stern wrote:
> On Thu, 20 Mar 2014, James Bottomley wrote:
>
> > OK, so I think we have three things to do
> >
> > 1. Investigate SCSI and fix it's abort state problem that's causing
> > it not to send the abort second time around
> > 2. F
Hello.
On 03/20/2014 01:04 AM, Cédric Cabessa wrote:
Signed-off-by: Cédric Cabessa
---
drivers/staging/usbip/vhci_hcd.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd
On 03/21/2014 12:34 AM, Sergei Shtylyov wrote:
Signed-off-by: Cédric Cabessa
---
drivers/staging/usbip/vhci_hcd.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c
b/drivers/staging/usbip/vhci_hcd.c
inde
On Thu, 20 Mar 2014, James Bottomley wrote:
> > I tried this patch first, because fixing the earlier bug would mask
> > this one.
> >
> > The patch sort of worked. But the first time I tried it, it failed in
> > a rather amusing way. While the second retry was running and hung,
> > scmd->result
On Thu, 20 Mar 2014, James Bottomley wrote:
> On Thu, 2014-03-20 at 15:59 -0400, Alan Stern wrote:
> > On Thu, 20 Mar 2014, James Bottomley wrote:
> >
> > > OK, so I think we have three things to do
> > >
> > > 1. Investigate SCSI and fix it's abort state problem that's causing
> > >
On Fri, 2014-03-21 at 00:34 +0300, Sergei Shtylyov wrote:
> On 03/20/2014 01:04 AM, Cédric Cabessa wrote:
> > diff --git a/drivers/staging/usbip/vhci_hcd.c
> > b/drivers/staging/usbip/vhci_hcd.c
[]
> > @@ -271,12 +271,14 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
> > typeReq, u16 wVa
On Tue, Mar 18, 2014 at 1:10 AM, Johan Hovold wrote:
> On Mon, Mar 17, 2014 at 11:58:57PM -0700, Benjamin West wrote:
>> On Mon, Mar 17, 2014 at 11:40 AM, Johan Hovold wrote:
>> >> issues. It's included below
>> >> https://gist.github.com/bewest/6488955#file-lsusb
>>
>> > I'm responding to this
From: Ben Chan
Date: Wed, 19 Mar 2014 14:00:04 -0700
> The MBIM extended functional descriptor, defined in "Universal Serial Bus
> Communications Class Subclass Specification for Mobile Broadband Interface
> Model, Revision 1.0, Errata-1" by USB-IF, indicates the operator preferred MTU
> value vi
On Wed, Mar 19, 2014 at 11:37:40AM +0100, Fiorenzo Zanotti wrote:
> Hi,
> I'm running an Ubuntu 13.10 32 bit desktop on a PC with ASROCK Z87 PRO4
> motherboard and I5-4670k cpu.
>
> Having Intel USB3 mode set to ENABLED or SMART or AUTO , a canon scanner
> D660U attached to one of the usb2 por
On Sun, Mar 16, 2014 at 07:52:30PM +0100, Martin Dauskardt wrote:
> Hi Sarah,
>
> I lost track on this issue. Is there a final patch? Is it ready for
> integration into the kernel? Is there any kernel version that
> includes a fix? Is there any timeline?
Mathias was working on this fix, but wante
On Thu, Mar 20, 2014 at 9:35 AM, Grant Grundler wrote:
> On Thu, Mar 20, 2014 at 12:15 AM, Oliver Neukum wrote:
> ...
>> I have an idea. Could you test this patch?
> ...
>> - if (dev->wait) {
> ..
>> + if (waitqueue_active(&dev->wait)) {
>
> Yes - building new image now (and transfer
On Wed, Mar 19, 2014 at 12:37:37PM +0100, Andreas Reis wrote:
> I've uploaded a dmesg with the new debugging patch to bugzilla:
> https://bugzilla.kernel.org/attachment.cgi?id=130041
>
> Andreas Reis
>
> On 18.03.2014 15:57, Alan Stern wrote:>
> > The debugging information didn't go far enough.
Johan and other usb-serial/ftdi maintainers,
Here is a small patch for you which adds the PID for Asante Snap
Pump's FTDI data cable to the device list. The Asante Snap pump is an
insulin pump, this device is a usb cable which connects to their
cradle.
The patch is listed below as well as here:
On 03/20/2014 11:45 PM, Joe Perches wrote:
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
[]
@@ -271,12 +271,14 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
}
break;
Ok, so it looks like Alan finally acked all the port power off patches.
Greg, how are you feeling about taking these for 3.15? I hear that
Linus may have to release an -rc8 or even -rc9, so they could go in and
still have some time to marinate in linux-next, but it's really your
call.
I usually
On Thu, Mar 20, 2014 at 02:33:33PM -0700, Sarah Sharp wrote:
> Ok, so it looks like Alan finally acked all the port power off patches.
>
> Greg, how are you feeling about taking these for 3.15? I hear that
> Linus may have to release an -rc8 or even -rc9, so they could go in and
> still have some
On Thu, Mar 20, 2014 at 02:52:25PM -0700, Greg KH wrote:
> On Thu, Mar 20, 2014 at 02:33:33PM -0700, Sarah Sharp wrote:
> > Ok, so it looks like Alan finally acked all the port power off patches.
> >
> > Greg, how are you feeling about taking these for 3.15? I hear that
> > Linus may have to rele
>> Can you please explain why we need to check if the waitqueue is active?
>
> and add a comment that answers the above question.
Oh the braces!!! Well, that's just mean...
I expect that we don't really need the waitqueue_active() check there
as long as we fix the patch to make sure t
On 03/21/2014 12:34 AM, Sergei Shtylyov wrote:
Signed-off-by: Cédric Cabessa
---
drivers/staging/usbip/vhci_hcd.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c
b/drivers/staging/usbip/vhci_hcd.c
inde
On Thu, Mar 20, 2014 at 10:11:42PM +0800, tzi...@me.com wrote:
> Hello!
>
> I am developing on a phyFlex iMx.6 and want to send data via USB to a
> Host connected via the OTG port.
> The data is images from an image sensor, so I need a high performance (USB
> 2.0).
How is your image sensor drive
Hello Bjørn,
I made the test like you suggested and I couldn't find any difference
between the printout for lsusb before and after the command.
What else I've been tried after read the page
http://www.draisberghof.de/usb_modeswitch/ was:
1 - For the file /etc/usb_modeswitch.conf I changed the E
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, March 20, 2014 9:33 PM
> To: Gupta Suresh-B42813
> Cc: ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v2] USB: Gadget: fsl driver pullup fix
>
> On Fri,
This fix the fsl usb gadget driver in a way that the usb device
will be only "pulled up" on requests only when vbus is powered
Signed-off-by: Suresh Gupta
---
Changes from previous version:
* fixed checkpatch error
drivers/usb/gadget/fsl_udc_core.c | 4
1 file changed, 4 insertions(+)
dif
On 2014-03-21 11:33, Julio Araujo wrote:
Hello Bjørn,
I made the test like you suggested and I couldn't find any difference
between the printout for lsusb before and after the command.
What else I've been tried after read the page
http://www.draisberghof.de/usb_modeswitch/ was:
1 - For the fil
52 matches
Mail list logo
