On Mon, 7 Apr 2014, Greg KH wrote:
==Date: Mon, 7 Apr 2014 17:22:09 -0700
==From: Greg KH
==To: "Enrico Mioso (@atlantide)"
==Cc: net...@vger.kernel.org, linux-usb@vger.kernel.org,
==Oliver Neukum
==Subject: Re: Fault ammission :)
==
==On Mon, Apr 07, 2014 at 10:55:36AM +0200, Enrico Mios
From: xiao jin
Date: Tue, 25 Mar 2014 15:54:36 +0800
Subject: [PATCH] cdc-acm: some enhancement on acm delayed write
We find two problems on acm tty write delayed mechanism.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm suspend. More acm writ
ffs_epfile_io() is called from userspace, while ffs_func_esp_disable() might
be called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile->ep would be removed by
ffs_func_esp_disable() during ffs_epfile_io() is referring this pointer
ffs_epfile_io() is called from userspace, while ffs_func_esp_disable() might
be called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile->ep would be removed by
ffs_func_esp_disable() during ffs_epfile_io() is referring this pointer
On Mon, Apr 07, 2014 at 10:55:36AM +0200, Enrico Mioso (@atlantide) wrote:
> Just to say - that my first COMMIT (adding support fo ONDA MT828UP) was
> simply wrong. There was a firmware update, but it didn't influence the
> thing, so I simply mistaken. But now, with the latter commit fixing the
> t
Hi,
On Mon, Apr 07, 2014 at 03:12:09PM -0700, Randy Dunlap wrote:
> On 04/05/2014 11:42 AM, Apelete Seketeli wrote:
> > Document the process of writing an musb glue layer by taking the
> > Ingenic JZ4740 glue layer as an example, as it seems more simple than
> > most glue layers due to the basic f
On 04/05/2014 11:42 AM, Apelete Seketeli wrote:
> Document the process of writing an musb glue layer by taking the
> Ingenic JZ4740 glue layer as an example, as it seems more simple than
> most glue layers due to the basic feature set of the JZ4740 USB device
> controller.
>
> Signed-off-by: Apele
On Mon, Apr 07, 2014 at 09:04:41AM +, Amund Hov wrote:
>
> >>> The USB bus specification says that 255 devices can be connected to the
> >>> host, but that doesn't mean the xHCI host controller has all the
> >>> internal resources to support that.
> >
> > To me that sounds like such xHCI HCs c
Hi all,
I am implementing a driver (currently libusb-based, but may change to
kernel-based eventually) for a USB standard class type that makes use of
endpoint stalling as a synchronization mechanism to recover after error
conditions between device and host (the reasons for needing it are a bit
On Mon, Apr 07, 2014 at 09:04:41AM +, Amund Hov wrote:
>
> >>> The USB bus specification says that 255 devices can be connected to the
> >>> host, but that doesn't mean the xHCI host controller has all the
> >>> internal resources to support that.
> >
> > To me that sounds like such xHCI HCs c
On 04/03/2014 07:32 PM, Johan Hovold wrote:
Hi Mathias and Benjamin,
Mathias, I understand you've got quite a lot on your plate with xhci at
the moment, but have you had a change to look at this issue yet? It's an
xhci-issue (possibly due to buggy hw) which seems related to the
non-superspeed en
Hi,
On Mon, Apr 07, 2014 at 02:36:13PM +0530, sundeep subbaraya wrote:
> >> +/**
> >> + * xudc_wrstatus - Sets up the usb device status stages.
> >> + * @udc: pointer to the usb device controller structure.
> >> + */
> >> +static void xudc_wrstatus(struct xusb_udc *udc)
> >> +{
> >> + u32 epcf
On Mon, Apr 07, 2014 at 01:21:10PM +0200, Stefan Roese wrote:
> Hi Felipe,
>
> On 04.04.2014 17:35, Stefan Roese wrote:
> >>> I'm currently seeing a problem on an OMAP3530 based board (Technexion
> >>> TAO3530). Where the MUSB is configured as device/peripheral and the
> >>> ethernet
> >>> gadget
On Wed, 2 Apr 2014, Hannes Reinecke wrote:
> On 04/01/2014 11:28 PM, Alan Stern wrote:
> > On Tue, 1 Apr 2014, Hannes Reinecke wrote:
> >
> So if the above reasoning is okay then this patch should be doing
> the trick:
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/
On Mon, 7 Apr 2014, Peter Münster wrote:
> On Fri, Apr 04 2014, Alan Stern wrote:
>
> > No error messages about hung-up tasks 120 seconds later?
>
> Sorry. I had forgotten to wait 2 minutes...
>
> Here again the log with information about hung-up tasks.
This looks a lot like what you got befor
On Mon, 7 Apr 2014 tzi...@me.com wrote:
> Is there a way to test the maximum data transfer speed of an embedded device?
> I need to find the bottleneck of my system.
> I am currently using an i.mx6 freescale with kernel 3.0.35 from NAND
> which I can not update for several reasons. With gadgetfs I
Hi Felipe,
On 04.04.2014 17:35, Stefan Roese wrote:
>>> I'm currently seeing a problem on an OMAP3530 based board (Technexion
>>> TAO3530). Where the MUSB is configured as device/peripheral and the
>>> ethernet
>>> gadget is compiled into the kernel. This works without any problems
>>> and usb0
Is there a way to test the maximum data transfer speed of an embedded device?
I need to find the bottleneck of my system.
I am currently using an i.mx6 freescale with kernel 3.0.35 from NAND
which I can not update for several reasons. With gadgetfs I can
achieve a maximum of 15 MByte/s in High Spee
>>> The USB bus specification says that 255 devices can be connected to the
>>> host, but that doesn't mean the xHCI host controller has all the
>>> internal resources to support that.
>
> To me that sounds like such xHCI HCs can not be considered USB compliant. :\
I would tend to agree Peter. It
Hi Michal,
On Thu, Apr 3, 2014 at 8:53 PM, Michal Simek wrote:
>>> +struct xusb_udc {
>>> +struct usb_gadget gadget;
>>> +struct xusb_ep ep[8];
>>> +struct usb_gadget_driver *driver;
>>> +struct cmdbuf ch9cmd;
>>> +u32 usb_state;
>>> +u32 remote_wkp;
>>> +unsigned int
On Fri, Apr 04 2014, Alan Stern wrote:
> No error messages about hung-up tasks 120 seconds later?
Sorry. I had forgotten to wait 2 minutes...
Here again the log with information about hung-up tasks.
--
Peter
[ 97.307415] PM: Syncing filesystems ... done.
[ 97.412888] PM: Prepari
Just to say - that my first COMMIT (adding support fo ONDA MT828UP) was simply
wrong. There was a firmware update, but it didn't influence the thing, so I
simply mistaken. But now, with the latter commit fixing the thing, all works
fine.
I will be better to keep udev running :) .
References:
-
22 matches
Mail list logo
