From: Li Jun
This patch adds response to a_alt_hnp_support set feature request from legacy
A device, that is, B-device can provide a message to the user indicating that
the user needs to connect the B-device to an alternate port on the A-device.
A device sets this feature indicates to the B-devic
The last lines of code at ci_udc_start finishes the same function
with .vbus_session if ci->vbus_active is 1.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/udc.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/ch
On Wed, 25 Feb 2015 22:13:51 +0100 Sebastian Reichel wrote:
> Hi Neil,
>
> On Tue, Feb 24, 2015 at 03:01:29PM +1100, NeilBrown wrote:
> > twl4030_charger currently finds the associated phy
> > using usb_get_phy() which will return the first USB2 phy.
> > If your platform has multiple such phys (
Andrew Morton asked me to prepare a big patch that removes
IRQF_DISABLED entirely (see https://lkml.org/lkml/2015/3/2/819). It
seems a good way to get rid of the few references and the definition
at once.
So please don't apply this patch. After, I can prepare another patch
later that takes care
Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
infinite timeout (0) would be passed to the underlying tty-driver's
wait_until_sent-operation as a negative timeout (-1), causing it to
return immediately.
This manifests itself for example as tcdrain() returning immediately,
dri
In case an infinite timeout (0) is requested, the irda wait_until_sent
implementation would use a zero poll timeout rather than the default
200ms.
Note that wait_until_sent is currently never called with a 0-timeout
argument due to a bug in tty_wait_until_sent.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-
This series fixes an overflow bug in tty_wait_until_sent, which is
currently broken on 64-bit machines for most TTY drivers (with
serial-core being the notable exception).
The final patch makes the tty_wait_until_sent timeout a maximum one so
that we actually honour the closing-wait timeout.
All
Remove incorrect and redundant wait_until_sent operation, which waits
for the driver buffer rather than any hardware buffers to drain,
something which is already taken care of by the tty layer (and
chars_in_buffer).
Signed-off-by: Johan Hovold
---
drivers/tty/bfin_jtag_comm.c | 13 -
Currently tty_wait_until_sent may take up to twice as long as the
requested timeout while waiting for driver and hardware buffers to
drain.
Fix this by taking the remaining number of jiffies after waiting for
driver buffers to drain into account so that the timeout actually
becomes a maximum timeo
Make sure to handle an infinite timeout (0).
Note that wait_until_sent is currently never called with a 0-timeout
argument due to a bug in tty_wait_until_sent.
Fixes: dcf010503966 ("USB: serial: add generic wait_until_sent
implementation")
Cc: stable # v3.10
Signed-off-by: Johan Hovold
---
On 3/3/2015 6:48 PM, Greg KH wrote:
> On Tue, Mar 03, 2015 at 05:06:45PM +, Joao Pinto wrote:
>> Hello,
>>
>> I am sending this email in order to get some feedback from you about a
>> feature that I am planning to do in a driver I am working on.
>
> I don't see any code here, or really, any sp
On Wed, Feb 25, 2015 at 04:54:02PM -0600, Felipe Balbi wrote:
> Without those we will see a kernel WARN()
> when loading musb on am335x devices.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/dma/cppi41.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/d
Le 02/03/2015 10:32, Bo Shen a écrit :
> Hi Nicolas,
>
> On 02/10/2015 09:55 AM, Bo Shen wrote:
>> This patch series enable usb device support on at91sam9n12ek board.
>>
>> Changes in v2:
>>- Base on next-20150209 (so, remove the modification of udc driver).
>>- Add pinctrl for usb1 vbus s
Le 12/02/2015 18:54, Sylvain Rochet a écrit :
> This patch add suspend/resume with wakeup support for Atmel USBA.
>
> On suspend: We stay continuously clocked if Vbus signal is not
> available. If Vbus signal is available we set the Vbus signal as a wake
> up source then we stop the USBA itself an
Le 12/02/2015 18:54, Sylvain Rochet a écrit :
> Start clocks on rising edge of the Vbus signal, stop clocks on falling
> edge of the Vbus signal.
>
> Add suspend/resume with wakeup support.
Hi Felipe,
I think this series by Sylvain is ready for inclusion. Are you able to
take it for the next cyc
Hi Mathias,
On Tue, Mar 3, 2015 at 8:40 PM, Alistair Grant wrote:
> Hi Mathias,
>
> On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman
> wrote:
>> On 28.02.2015 09:16, Alistair Grant wrote:
>>> ...
>>> * 3.19.0 with the following patches:
>>> * xhci: Allocate correct amount of scratchpad buffers
>>>
On 03/02/2015 12:39 PM, David Vrabel wrote:
On 26/02/15 13:35, Juergen Gross wrote:
Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a driver domain
(usually D
On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:
> >> - move module to appropriate location in kernel tree
> >
> > drivers/xen/ is the correct location for this driver.
>
> Hmm, so you regard placement of xen-netback under drivers/net and
> xen-blkback under drivers/block as wrong? I've jus
On 09/12/14 15:26, Mathias Nyman wrote:
Hi
On 09/11/2014 05:18 PM, Jay Larson wrote:
Mathias,
I was not able to locate an official method of inquiring about issues with xhci,
so I'm writing directly to you. If this is not the appropriate method please
accept my apologies and kindly direct me t
On 03/04/2015 02:41 PM, Ian Campbell wrote:
On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:
- move module to appropriate location in kernel tree
drivers/xen/ is the correct location for this driver.
Hmm, so you regard placement of xen-netback under drivers/net and
xen-blkback under d
On 04/03/15 13:31, Juergen Gross wrote:
> On 03/02/2015 12:39 PM, David Vrabel wrote:
>> On 26/02/15 13:35, Juergen Gross wrote:
>>> Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
>>> domU to communicate with a USB device assigned to that domU. The
>>> communication is all do
On 03/04/2015 02:53 PM, David Vrabel wrote:
On 04/03/15 13:31, Juergen Gross wrote:
On 03/02/2015 12:39 PM, David Vrabel wrote:
On 26/02/15 13:35, Juergen Gross wrote:
Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that d
On 04/03/15 14:09, Juergen Gross wrote:
>
> The main question whether it is worth to consider this alternative is
> the performance aspect. Does anyone have an idea which USB devices would
> typically be used via pvusb? I'd suspect memory sticks and USB disks
> and perhaps webcams being the most p
On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
> On 04/03/15 14:09, Juergen Gross wrote:
> >
> > The main question whether it is worth to consider this alternative is
> > the performance aspect. Does anyone have an idea which USB devices would
> > typically be used via pvusb? I'd suspect m
On 03/04/2015 03:29 PM, Ian Campbell wrote:
On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
On 04/03/15 14:09, Juergen Gross wrote:
The main question whether it is worth to consider this alternative is
the performance aspect. Does anyone have an idea which USB devices would
typically be
Juergen Gross wrote:
> Do you have another feeling about the probability of a need to do usb 3?
> If it is already on the horizon I wouldn't want to do the user space
> backend now and the kernel one next year. :-)
One year is pretty long in kernel time.
//Peter
--
To unsubscribe from this list:
On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote:
> On 03/04/2015 03:29 PM, Ian Campbell wrote:
> > On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote:
> >> On 04/03/15 14:09, Juergen Gross wrote:
> >>>
> >>> The main question whether it is worth to consider this alternative is
> >>> the p
On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote:
> On 03/02/2015 12:39 PM, David Vrabel wrote:
> >On 26/02/15 13:35, Juergen Gross wrote:
> >>Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
> >>domU to communicate with a USB device assigned to that domU. The
> >>
On 03/04/2015 04:27 PM, Greg KH wrote:
On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote:
On 03/02/2015 12:39 PM, David Vrabel wrote:
On 26/02/15 13:35, Juergen Gross wrote:
Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device
On Tue, 3 Mar 2015, Al Viro wrote:
> On Tue, Mar 03, 2015 at 10:47:14AM -0500, Alan Stern wrote:
> > On Tue, 3 Mar 2015, Al Viro wrote:
> >
> > > Looking at that thing again... why do they need to be dummy? After all,
> > > those methods start with get_ready_ep(), which will fail unless we have
On 26/02/15 18:53, Laurent Pinchart wrote:
Hi Sudeep,
Thank you for the patch.
On Thursday 26 February 2015 11:47:57 Sudeep Holla wrote:
As per the SAF1761 data sheet[0], the DcChipID register represents
the hardware version number (0001h) and the chip ID (1582h) for the
Peripheral Controlle
Hi Sudeep,
On Wednesday 04 March 2015 15:56:12 Sudeep Holla wrote:
> On 26/02/15 18:53, Laurent Pinchart wrote:
> > Hi Sudeep,
> >
> > Thank you for the patch.
> >
> > On Thursday 26 February 2015 11:47:57 Sudeep Holla wrote:
> >> As per the SAF1761 data sheet[0], the DcChipID register represent
Hi Matthias,
On Tue, Mar 03, 2015 at 06:12:44PM +0200, Mathias Nyman wrote:
> On 03.03.2015 11:59, Maxime Ripard wrote:
> > On Mon, Mar 02, 2015 at 08:23:37PM +0100, Gregory CLEMENT wrote:
> >> Hi Maxime,
> >>
> >> On 19/01/2015 14:01, Maxime Ripard wrote:
> >>> The Armada 385 AP board has a USB3
On 04/03/15 16:11, Laurent Pinchart wrote:
Hi Sudeep,
On Wednesday 04 March 2015 15:56:12 Sudeep Holla wrote:
[...]
Also I don't see any message on the host side. Let me know if there's
something wrong in my config or test commands.
Looks like a driver bug to me, .udc_start() and .udc_s
Use spin_{un,}lock_irq{save,restore} in isp1760_udc_{start,stop} to
prevent following potentially deadlock scenario between
isp1760_udc_{start,stop} and isp1760_udc_irq :
=
[ INFO: inconsistent lock state ]
4.0.0-rc2-4-gf7bb2ef60173 #51 Not tainted
-
Recently the Huawei e3276 devices my company was buying came with a new
firmware version and the word "hilink" printed all over them. Instead
of showing up as a usbserial device using the option driver, they show
up now as an ethernet device. While I can see the convenience factor in
this, it doe
On Wed, Mar 04, 2015 at 12:14:01PM -0500, Rick Farina wrote:
> Recently the Huawei e3276 devices my company was buying came with a new
> firmware version and the word "hilink" printed all over them. Instead
> of showing up as a usbserial device using the option driver, they show
> up now as an eth
On 03/04/15 12:34, Greg KH wrote:
> On Wed, Mar 04, 2015 at 12:14:01PM -0500, Rick Farina wrote:
>> Recently the Huawei e3276 devices my company was buying came with a new
>> firmware version and the word "hilink" printed all over them. Instead
>> of showing up as a usbserial device using the op
On Wed, Mar 04, 2015 at 12:41:09PM -0500, Rick Farina wrote:
>
>
> On 03/04/15 12:34, Greg KH wrote:
> > On Wed, Mar 04, 2015 at 12:14:01PM -0500, Rick Farina wrote:
> >> Recently the Huawei e3276 devices my company was buying came with a new
> >> firmware version and the word "hilink" printed al
Hi,
Is it necessary to use xHCI driver for USB 3.0 host controller? I am
trying to support Transdent PNU3 (having usb 3.0 controller) in my h/w
running 2.6.16 kernel. Is it not
possible to use other legacy host controllers (ohci/uhci/ehci) already
available in 2.6.16 kernel ? Will usb 3.0 not fal
On Wed, Mar 04, 2015 at 11:44:45PM +0530, temp sha wrote:
> Hi,
>
> Is it necessary to use xHCI driver for USB 3.0 host controller?
Yes.
> I am
> trying to support Transdent PNU3 (having usb 3.0 controller) in my h/w
> running 2.6.16 kernel.
You do realize just how old and obsolete 2.6.16 is, r
On Wed, 4 Mar 2015, temp sha wrote:
> Hi,
>
> Is it necessary to use xHCI driver for USB 3.0 host controller?
A USB-3 host controller _is_ an xHCI controller. Obviously it is
necessary to use the xhci-hcd driver to drive an xHCI controller.
> I am
> trying to support Transdent PNU3 (having u
Hi Kenneth Johansson,
Did you still get the bandwidth error when testing it with longer time?
Thanks,
Baolu
On 2015-03-03 10:06, Lu, Baolu wrote:
cc'ed usb mailing list.
On 2015-03-02 21:23, Kenneth Johansson wrote:
I have been running 3.19 prereleases and now 3.19 and have not got
the bandw
On 03/04/15 13:01, Greg KH wrote:
> And again, a kernel patch is the real way to fix it for everyone.
Okay, got a lot of things figured out and have everything working now.
Glad I spent the extra time because I found some neat things on the device.
I've made the following changes:
diff --git a/d
On 2015-03-05 10:00, Rick Farina wrote:
On 03/04/15 13:01, Greg KH wrote:
And again, a kernel patch is the real way to fix it for everyone.
Okay, got a lot of things figured out and have everything working now.
Glad I spent the extra time because I found some neat things on the device.
I've m
On 2015-03-05 11:53, Lars Melin wrote:
There is already support in option for a few other Huawei dongles with
the same type of interface attributes and that is the right place
for adding 12d1:1556
Here is the relevant part of option.c :
645{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VEN
Hello,
Peter Hung 於 2015/2/26 下午 06:02 寫道:
This series patch V8 is changed from V7 as following:
1. The V7 MSR strange delta value is checked with locking problem. We changed
f81232_set_mctrl() & f81232_read_msr() lock mechanism, the old version is
only locked with variable protection,
+cc Sebastian, Alan Stern
Hello Felipe,
On 2/28/2015 3:18 AM, Felipe Balbi wrote:
Hi Amit,
commit ef11982dd7a657512c362242508bb4021e0d67b6 (Add support for
interrupt EP) actually broke testusb for MUSB when MUSB is the gadget.
The reason is that we're requesting an endpoint with a 64-byte FIF
On Thu, Mar 05, 2015 at 01:59:45PM +0800, Peter Hung wrote:
> Did you received the series of F81232 V8 patches ? Please tell me if
> not received.
I got it. I just haven't had time to look at it yet. Will try to do so
this week.
Johan
--
To unsubscribe from this list: send the line "unsubscribe
49 matches
Mail list logo
