On 10/23/2013 02:25 PM, Andrzej Pietrasiewicz wrote:
> diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
> index 0658908..9ccda73 100644
> --- a/drivers/usb/gadget/f_fs.c
> +++ b/drivers/usb/gadget/f_fs.c
> @@ -1901,30 +1916,38 @@ static int __ffs_data_got_strings(struct ffs_data
"ret" needs to be signed for the error handling to work.
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/phy/phy-twl6030-usb.c
b/drivers/usb/phy/phy-twl6030-usb.c
index 30e8a61..bad57ce 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -127,7 +127,8
Dirk Gouders writes:
[SNIP]
>> Are you sure this test-case exhibits the problem for you?
>
> Yes, but obviously, I did not describe it very clearly. The steps to
> reproduce the problem are:
>
> $ ./scripts/kconfig/mconf test.in
>--> change c0 and c1 to 'm'# This is the mis
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
> On Thu, Nov 07, 2013 at 05:20:49PM -, David Laight wrote:
> >
> > Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> > can only occur at a boundary between underlying USB frames (512 bytes for
> > 480M).
>
> While this change improves things a lot (it runs for 20 minutes rather than
> a few seconds), there is still something else wrong.
Almost certainly caused by an unrelated local change.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mess
On Thu, Nov 07 2013, Alan Stern wrote:
> What happens if the userspace daemon writes to epfile but the host
> changes the config or altsetting before all the data can be sent? Does
> the remaining data get flushed?
Each read and write is mapped to a single request, so the usual.
> I'm still a
Add the missing C_CMSPAR(tty) macro.
Signed-off-by: Andrew Lunn
---
include/linux/tty.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 64f864651d86..8d1ba896070a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -137,6 +137,7 @@ st
Add a driver which supports the following Moxa USB to serial converters:
* 2 ports : UPort 1250, UPort 1250I
* 4 ports : UPort 1410, UPort 1450, UPort 1450I
* 8 ports : UPort 1610-8, UPort 1650-8
* 16 ports : UPort 1610-16, UPort 1650-16
The UPORT devices don't directy fit t
> Hopefully my comments will suffice as guidance for mxuport, but we could
> iterate the flow-control handling separate from the other changes if you
> want.
Hi Johan
I just posted v5. It would be good if you could take a look at the
flow-control changes first.
Thanks
Andrew
--
To unsubs
> ... The Moxa
> UPORT only has one pair for data transfer and places a header on each
> transfer over the endpoint indicating for which port the transfer
> relates to. There is a second endpoint pair for events, such as modem
> control lines changing state, setting baud rates etc. Again, a
> multi
On Thu, 2013-11-07 at 07:56 -0800, Greg KH wrote:
> EHCI looks like it can be easily fixed, OHCI will take some more work,
> as will UHCI. The other "minor" hcd drivers should be easy to resolve
> as well, like I did previously with some of the other ones. I'll gladly
> take patches for all of t
This removes trivial dead code from drivers/usb/phy/phy-am335x.c
and drivers/usb/phy/phy-generic.c
Found by Coverity (CID 1127232 and CID 1127231)
Signed-off-by: Michael Opdenacker
---
drivers/usb/phy/phy-am335x.c | 2 --
drivers/usb/phy/phy-generic.c | 2 --
2 files changed, 4 deletions(-)
d
Hello Sebastian,
thank you for review, please see inline
W dniu 08.11.2013 09:02, Sebastian Andrzej Siewior pisze:
On 10/23/2013 02:25 PM, Andrzej Pietrasiewicz wrote:
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 0658908..9ccda73 100644
--- a/drivers/usb/gadget/f_fs
On Fri, Nov 08, 2013 at 02:57:05PM +0100, Oliver Neukum wrote:
> On Thu, 2013-11-07 at 07:56 -0800, Greg KH wrote:
>
> > EHCI looks like it can be easily fixed, OHCI will take some more work,
> > as will UHCI. The other "minor" hcd drivers should be easy to resolve
> > as well, like I did previou
W dniu 07.11.2013 19:28, Mark Charlebois pisze:
On Sat, Nov 2, 2013 at 10:44 AM, Michal Nazarewicz mailto:min...@mina86.com>> wrote:
On Wed, Oct 23 2013, Andrzej Pietrasiewicz wrote:
> From: Mark Charlebois mailto:charl...@gmail.com>>
>
> The use of variable length arrays i
On 11/08/2013 04:01 PM, Andrzej Pietrasiewicz wrote:
> Hello Sebastian,
Hallo Andrzej,
> Please correct me if I'm wrong but I think it is not possible to use
> usb_gstrings_attach(). Basically, usb_gstrings_attach() requires
>
> struct usb_gadget_strings **sp
>
> on input, then it does copy_gad
On Thu, 7 Nov 2013, Sarah Sharp wrote:
> > Probably the current code is wrong. The wakeup bits don't need to be
> > set during port suspend or root-hub suspend, but only during controller
> > suspend -- they get used only when the controller is not in D0. I
> > guess we should change both driver
On Thu, 7 Nov 2013, Sarah Sharp wrote:
> On Thu, Nov 07, 2013 at 05:20:49PM -, David Laight wrote:
> >
> > Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> > can only occur at a boundary between underlying USB frames (512 bytes for
> > 480M).
>
> Which version
On Thu, 7 Nov 2013, Julius Werner wrote:
> This patch adds a check for USB_STATE_NOTATTACHED to the
> hub_port_warm_reset_required() workaround for ports that end up in
> Compliance Mode in hub_events() when trying to decide which reset
> function to use. Trying to call usb_reset_device() with a N
On 03.07.13, Ming Lei wrote:
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 014dc99..26471cd 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -1648,6 +1635,72 @@ int usb_hcd_unlink_urb (struct urb *urb, int status)
>
> /*--
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 08 November 2013 16:46
> To: Sarah Sharp
> Cc: David Laight; net...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH] usb: xhci: Link TRB must not occur with a USB payload
> burst.
>
> On
Hi Michal,
On 11/08/2013 04:23 AM, Michal Nazarewicz wrote:
On Thu, Nov 07 2013, Alan Stern wrote:
What happens if the userspace daemon writes to epfile but the host
changes the config or altsetting before all the data can be sent? Does
the remaining data get flushed?
Each read and write is
On Fri, 8 Nov 2013, David Laight wrote:
> > The whole idea of TD fragments is exceedingly cloudy. The definition
> > doesn't make sense, and the spec doesn't say what the actual hardware
> > restrictions are, i.e., what is the underlying reality that the TD
> > fragment concept wants to express.
we have a helper to fetch endpoint type out of
a descriptor, let's use it.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/epautoconf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index a777f7b..feaaa7b
Hi folks,
here's a second RFC on my original endpoint feature flag RFC.
I have kept the boolean flags even though Michael suggested
using a single "supported_transfer_types" bitfield. I did that
for a reason which I considered to be quite valid.
Recent USB3.0 cores are starting to ship with buil
Start matching endpoints against feature flags,
this will help us dropping the naming conventions
currently used by the Gadget Framework.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/epautoconf.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --gi
Add a few flags to tell gadget framework which
features a particular endpoint supports.
Signed-off-by: Felipe Balbi
---
include/linux/usb/gadget.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 942ef5e..cf1d027 100
just so we can start using a more solid endpoint
matching system.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5452c0f..d687c3a 100644
--- a/drivers/u
On Fri, 8 Nov 2013, Felipe Balbi wrote:
> Start matching endpoints against feature flags,
> this will help us dropping the naming conventions
> currently used by the Gadget Framework.
The logic doesn't look quite right.
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/gadget/epautoconf.c | 28
On Mon, 2013-11-04 at 14:27 -0600, Dan Williams wrote:
> On Fri, 2013-11-01 at 13:53 +0100, Bjørn Mork wrote:
> > This reverts commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf.
> >
> > It's not easy to create a driver for all the various firmware
> > bugs out there.
> >
> > This change caused regr
Hi,
On Fri, Nov 08, 2013 at 02:24:43PM -0500, Alan Stern wrote:
> On Fri, 8 Nov 2013, Felipe Balbi wrote:
>
> > Start matching endpoints against feature flags,
> > this will help us dropping the naming conventions
> > currently used by the Gadget Framework.
>
> The logic doesn't look quite right
Hi,
I know that next-kernel may not stable/work. But for your information.
I tried 3.12.0-next-20131107-1-vanilla (next repository from Suse, because
compiling needs time and patience :-))
Two devices which worked with cdc_ncm now changed to huawei_cdc_ncm. So far so
ok.
But: E5776-s-32 (loc
On Fri, 8 Nov 2013, Sebastian Andrzej Siewior wrote:
> On 03.07.13, Ming Lei wrote:
...
> > + /*
> > +* We disable local IRQs here avoid possible deadlock because
> > +* drivers may call spin_lock() to hold lock which might be
> > +* acquired in one hard interrupt handler.
> > +*
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_gadget_ep0.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 3e9ec7c..f31b9b1 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
On Fri, Nov 08, 2013 at 02:20:24PM -0600, Bin Liu wrote:
no commit log == no commit ;-)
> Signed-off-by: Bin Liu
> ---
> drivers/usb/musb/musb_gadget_ep0.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_gadget_ep0.c
> b/d
Dan Williams writes:
> On Mon, 2013-11-04 at 14:27 -0600, Dan Williams wrote:
>> On Fri, 2013-11-01 at 13:53 +0100, Bjørn Mork wrote:
>> > This reverts commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf.
>> >
>> > It's not easy to create a driver for all the various firmware
>> > bugs out there.
>>
Thomas Schäfer writes:
> Hi,
>
> I know that next-kernel may not stable/work. But for your information.
>
> I tried 3.12.0-next-20131107-1-vanilla (next repository from Suse, because
> compiling needs time and patience :-))
>
> Two devices which worked with cdc_ncm now changed to huawei_cdc_ncm
On Fri, 2013-11-08 at 21:44 +0100, Bjørn Mork wrote:
> Dan Williams writes:
> > On Mon, 2013-11-04 at 14:27 -0600, Dan Williams wrote:
> >> On Fri, 2013-11-01 at 13:53 +0100, Bjørn Mork wrote:
> >> > This reverts commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf.
> >> >
> >> > It's not easy to crea
This patch removes an erroneous check of CSIZE, which made it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner
---
drivers/usb/serial/mos7840.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff
This patch removes an erroneous check of CSIZE, which made it impossible to set
CS5.
Compiles clean, but couldn't test against hardware.
Signed-off-by: Colin Leitner
---
drivers/usb/serial/spcp8x5.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff -
On Fri, Nov 8, 2013 at 2:42 PM, Felipe Balbi wrote:
> On Fri, Nov 08, 2013 at 02:20:24PM -0600, Bin Liu wrote:
>
> no commit log == no commit ;-)
I am not sure what else needs to say other than the subject. But I
will try to make some...
>
>> Signed-off-by: Bin Liu
>> ---
>> drivers/usb/musb/m
Hi
Considering the use case of function suspend (function driver unlinking
submitted urbs) is happening.
1) If there is a data transfer but due to inactivity on to the bus suspend
happened.
2) No data transfer is happening just device is suspending (unlink urbs)
and resuming (resubmit urbs).
For
On Fri, Nov 08, 2013 at 04:29:23PM -0600, Bin Liu wrote:
> On Fri, Nov 8, 2013 at 2:42 PM, Felipe Balbi wrote:
> > On Fri, Nov 08, 2013 at 02:20:24PM -0600, Bin Liu wrote:
> >
> > no commit log == no commit ;-)
>
> I am not sure what else needs to say other than the subject. But I
> will try to m
43 matches
Mail list logo
