On Fri, May 30, 2014 at 09:30:36PM -0700, Greg KH wrote:
> On Wed, Oct 16, 2013 at 08:49:34AM -0700, Sarah Sharp wrote:
> > On Fri, Oct 04, 2013 at 11:39:47AM -0500, Drew Von Spreecken wrote:
> > > Sarah, I've enabled debugging for the module if it helps... Log attached.
> >
> > Hi Drew,
> >
> >
On Wed, Oct 16, 2013 at 08:49:34AM -0700, Sarah Sharp wrote:
> On Fri, Oct 04, 2013 at 11:39:47AM -0500, Drew Von Spreecken wrote:
> > Sarah, I've enabled debugging for the module if it helps... Log attached.
>
> Hi Drew,
>
> > On 09/30/2013 06:19 PM, Sarah Sharp wrote:
> > >Hi Drew!
> > >
> > >I
>
> On Wed, May 28, 2014 at 03:09:17PM +0800, Li Jun wrote:
> > From: Li Jun
> >
> > This patch adds HNP polling support for chipidea otg fsm driver, which
> > adds a SW timer to send HNP polling request.
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/chipidea/ci.h |2 ++
> >
On Fri, May 30, 2014 at 08:52:03AM +0300, pkt...@gmail.com wrote:
> From: Pantelis Koukousoulas
>
> Recent commit (14aec589327a6fc4035f5327d90ac5548f501c4c) added the
> "can_do_streams" field to the hcd structure but only set it to 1
> in the XHCI driver.
>
> dummy_hcd can also do streams so set
On Fri, May 30, 2014 at 12:04:01PM -0400, Alan Stern wrote:
> On Fri, 30 May 2014, Huang Rui wrote:
>
> > On Fri, May 30, 2014 at 10:25:40AM -0400, Alan Stern wrote:
> > > On Fri, 30 May 2014, Huang Rui wrote:
> > >
> > >
> > > Ugh, don't make a copy of the existing code. Use the facilities the
Adjunct is the output of dmidecode (:
I didn't try setting "try_handoff" to 0, but I think behavior is
predictable since in that case the kernel will never reach the
pci_write in question. I found a kernel compiling option named "Enable
PCI quirk workarounds". It seems what i've been looking for (i
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Friday, May 30, 2014 4:42 PM
>
> On Fri, May 23, 2014 at 11:39:24AM -0700, Paul Zimmerman wrote:
> > Newer DWC3 controllers can be built for USB 2.0-only mode, where
> > most of the USB 3.0 circuitry is left out. To support this mode,
> > the driv
Hi,
On Fri, May 23, 2014 at 11:39:24AM -0700, Paul Zimmerman wrote:
> Newer DWC3 controllers can be built for USB 2.0-only mode, where
> most of the USB 3.0 circuitry is left out. To support this mode,
> the driver must limit the speed programmed into the DCFG register
> to Hi-Speed or lower.
>
>
From: Benoit Taine
Date: Mon, 26 May 2014 17:21:23 +0200
> This issue was reported by coccicheck using the semantic patch
> at scripts/coccinelle/api/memdup.cocci
>
> Signed-off-by: Benoit Taine
> ---
> Tested by compilation without errors.
Applied to net-next, thank you.
--
To unsubscribe fr
On Fri, 30 May 2014, Dan Williams wrote:
> >> --- a/drivers/usb/core/driver.c
> >> +++ b/drivers/usb/core/driver.c
> >> @@ -29,7 +29,7 @@
> >> #include
> >> #include
> >>
> >> -#include "usb.h"
> >> +#include "hub.h"
> >
> > Why on earth would something like this be needed? You didn't remove
On Fri, May 30, 2014 at 7:47 AM, Alan Stern wrote:
> On Thu, 29 May 2014, Dan Williams wrote:
>
>> > Duplicating code like this is a little awkward. My preference would be
>> > to move both usb_remote_wakeup() and hub_handle_remote_wakeup() out
>> > from underneath the #if CONFIG_PM section.
>> >
On Fri, 30 May 2014, Huang Rui wrote:
> On Fri, May 30, 2014 at 10:25:40AM -0400, Alan Stern wrote:
> > On Fri, 30 May 2014, Huang Rui wrote:
> >
> >
> > Ugh, don't make a copy of the existing code. Use the facilities the
> > way they are meant to be used. Like the patch below.
> >
>
> Look
On Fri, May 30, 2014 at 11:28:36PM +0800, che-chun Kuo wrote:
> We found when we plug in/out usb3.0 device for stress testing, once
> usb_get_device_descriptor fail in hub_port_init, we will call
> hub_port_disable.
> Then usb3.0 device may not recover successfully with only hot reset like
> belo
On Fri, May 30, 2014 at 10:25:40AM -0400, Alan Stern wrote:
> On Fri, 30 May 2014, Huang Rui wrote:
>
>
> Ugh, don't make a copy of the existing code. Use the facilities the
> way they are meant to be used. Like the patch below.
>
Looks good to me, thank you to improve it. Will you send this
We found when we plug in/out usb3.0 device for stress testing, once
usb_get_device_descriptor fail in hub_port_init, we will call hub_port_disable.
Then usb3.0 device may not recover successfully with only hot reset like below
function
retval = hub_port_reset(hub, port1, udev, delay, false);
On Fri, 30 May 2014 pkt...@gmail.com wrote:
> From: Pantelis Koukousoulas
>
> dummy_hcd uses jiffies and seems to assume that HZ=1000 and no
> tickless behavior. This makes for some horrible performance in
> ordinary desktop kernels (tickless / HZ=250) as found in distros.
>
> This patch ports
On Fri, May 30, 2014 at 9:26 AM, Mathias Nyman wrote:
> I think the last part is not relevant in this case:
> "If this Event is due to a Host Controller Command, then this field
> shall be cleared to ‘0’."
>
> Is for xhci internal commands that also generate command completion events,
> but
> are
On Fri, 30 May 2014 pkt...@gmail.com wrote:
> From: Pantelis Koukousoulas
>
> Recent commit (14aec589327a6fc4035f5327d90ac5548f501c4c) added the
> "can_do_streams" field to the hcd structure but only set it to 1
> in the XHCI driver.
>
> dummy_hcd can also do streams so set can_do_streams = 1 f
On Fri, 30 May 2014 pkt...@gmail.com wrote:
> I couldn't use dummy_hcd with g_tcm_gadget (UAS storage) with recent 3.15-rc
> kernels, firstly it wouldn't even work because stream support was broken
> and when I could get it to work with g_mass_storage, performance was horrible
> due to the driver
On Thu, 29 May 2014, Dan Williams wrote:
> > Duplicating code like this is a little awkward. My preference would be
> > to move both usb_remote_wakeup() and hub_handle_remote_wakeup() out
> > from underneath the #if CONFIG_PM section.
> >
>
> Hmm, why not go all the way and nuke CONFIG_PM and
On Fri, 30 May 2014, Huang Rui wrote:
> Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> completion signal. When using TEST 5 -> 8 at usbtest module to verify
> a new device controller with gadget zero, it might be hang on this
> phase and this routine waits forever. And it
On 05/29/2014 09:28 AM, Pratyush Anand wrote:
> Hi Mathias,
>
> On Tue, May 06, 2014 at 11:54:15AM +0800, Pratyush ANAND wrote:
>> These patches provide support of LPM capability to the dwc3 xhci hosts.
>> Patches have been tested on STih407.
>>
>> Changes since V2:
>> -- checkpatch warning r
Hello.
On 05/30/2014 06:12 PM, Yoshihiro Shimoda wrote:
From Sergei Shtylyov
Should be "From:".
Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.
Signed-off-by: Sergei Shtylyov
Signed-o
>From Sergei Shtylyov
Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.
Signed-off-by: Sergei Shtylyov
Signed-off-by: Yoshihiro Shimoda
---
This patch is against the 'usb-next' branch of Greg KH's
On 05/29/2014 12:32 AM, grantksupp...@operamail.com wrote:
>> The patch that probably causes your xhci issue was added to 3.13, If you
>> are able
>> to test a 3.12 kernel and it works then I'm quite sure it's the same
>> issue as
>> Saran Neti had with commit 20e7acb13ff48
>
> looks like this is
The R-Car H2 and M2 SoCs come with an xHCI controller that requires
some specific initializations related to the firmware downloading and
some specific registers. This patch adds the support for this special
configuration as an xHCI quirk executed during probe and start.
Signed-off-by: Yoshihiro S
This patch adds the USB xHCI support for the R-Car H2 and M2 SoCs.
These SoCs use an xHCI but still need specific initialization, mainly
to setup the firmware downloading and the specific registers.
This patch set is based on the usb-next branch of Greg usb.git tree.
(commit id = 70d2f61fc7559df3d
Hello.
(2014/05/30 2:17), Sergei Shtylyov wrote:
> Hello.
>
> On 05/29/2014 05:32 AM, Yoshihiro Shimoda wrote:
>
>> From: Gregory CLEMENT
>
>> This commit extends the xhci-plat so that it can optionally be passed
>> a reference to a PHY through the Device Tree. It will be useful for
>> the Arm
David Laight writes:
> From: Bjørn Mork
> ...
>> > Since you are now copying the data out of the URB's skb before
>> > passing the ethernet packet upstream, is there ever any real
>> > requirement to use a small rx_max? or ever change rx_max?
>>
>> Yes. usbnet doesn't currently recycle skbs. C
David Laight writes:
> From: Bjørn Mork
>> David Laight writes:
>> > From: Bjørn Mork
>> >> It doesn't matter whether the buffer size goes up or down. We have to
>> >> keep usbnet and device syncronized to be able to split transfers at the
>> >> correct boundaries. The spec allow skipping short
In order to reduce the interrupt times in the embedded system,
a receiving workqueue is introduced.
This modification also enhanced the overall throughput as the
benefits of reducing interrupt occurrence.
This work was derived from previous work:
u_ether: move hardware transmit to RX workqueue.
Wh
On 05/30/2014 12:49 PM, Xenia Ragiadakou wrote:
> On 30/05/2014 04:13 πμ, Saran Neti wrote:
>> Hi Xenia,
>>
>> Thanks for looking into this.
>>
>> On Thu, May 29, 2014 at 6:31 PM, Xenia Ragiadakou
>> wrote:
>>> I misunderstood the following description regarding the slot id field of
>>> Command C
Hello.
After upgrading my kernel to 3.14.4 I discovered that my Intel NUC could no
longer utilize two PCTV nanoStick T2 290e USB DVB adapters at the same time.
I've tried further upgrading the kernel to 3.15-rc7 (or to usb-next) which
exhibit the same behavior. Using only one nanoStick works fine.
Hi All,
I'm happy to announce the libusb-1.0.19-rc2 release.
The big feature of this release is support for bulk-streams on
Mac OS X and Linux (using the new usbfs API for this from 3.15).
Changelog:
* Add support for USB bulk streams on Linux and Mac OS X (#11)
* Windows: Add AMD and Intel USB-
From: Bjørn Mork
...
> > Since you are now copying the data out of the URB's skb before
> > passing the ethernet packet upstream, is there ever any real
> > requirement to use a small rx_max? or ever change rx_max?
>
> Yes. usbnet doesn't currently recycle skbs. Continuously allocating 32
> kB s
From: Bjørn Mork
> David Laight writes:
> > From: Bjørn Mork
> >> It doesn't matter whether the buffer size goes up or down. We have to
> >> keep usbnet and device syncronized to be able to split transfers at the
> >> correct boundaries. The spec allow skipping short packets when using
> >> max s
On 29/05/14 19:55, Bjørn Mork wrote:
> Jim Baxter writes:
>
>> The NDP was ignoring the wNextNdpIndex in the NDP which
>> means that NTBs containing multiple NDPs would have missed
>> frames.
>
> Well, just for the record: I believe this field was meant to be reserved
> and always 0 in the CDC N
David Laight writes:
> From: Bjørn Mork
>> It doesn't matter whether the buffer size goes up or down. We have to
>> keep usbnet and device syncronized to be able to split transfers at the
>> correct boundaries. The spec allow skipping short packets when using
>> max sized transfers. If we don't
On 29/05/14 20:04, Eric Dumazet wrote:
> On Thu, 2014-05-29 at 18:12 +0100, Jim Baxter wrote:
>> This fixes a problem with dropped packets over 16k CDC-NCM
>> when the connection is being heavily used.
>>
>> The issue was that the skb truesize for the unpacked NCM
>> packets was too high after they
On 30/05/2014 04:13 πμ, Saran Neti wrote:
Hi Xenia,
Thanks for looking into this.
On Thu, May 29, 2014 at 6:31 PM, Xenia Ragiadakou wrote:
I misunderstood the following description regarding the slot id field of
Command Completion Event TRB:
"The Slot ID field shall be updated by the xHC to
Currently, in usb_sg_wait routine there isn't a timeout on waiting for
completion signal. When using TEST 5 -> 8 at usbtest module to verify
a new device controller with gadget zero, it might be hang on this
phase and this routine waits forever. And it's better to report a
error even though it fail
On Wed, May 28, 2014 at 03:09:16PM +0800, Li Jun wrote:
> From: Li Jun
>
> Peripheral answers OTG status selector request from host according to
> host request flag of gadget, length is 1. this flag may be set by application
> via kernel interface.
via ioctl or sysfs?
Does the HNP polling be us
From: Bjørn Mork
> It doesn't matter whether the buffer size goes up or down. We have to
> keep usbnet and device syncronized to be able to split transfers at the
> correct boundaries. The spec allow skipping short packets when using
> max sized transfers. If we don't tell usbnet about our new e
On 05/29/2014 08:23 PM, Richie Gress wrote:
>
>> Date: Wed, 28 May 2014 10:56:51 +0200
>> From: hverk...@xs4all.nl
>> To: searchfgold67...@live.com; linux-usb@vger.kernel.org;
>> linux-me...@vger.kernel.org
>> Subject: Re: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran
>> Microelect
On Wed, May 28, 2014 at 03:09:18PM +0800, Li Jun wrote:
> From: Li Jun
>
> This patch sets host request flag in sys input when a A device
> set a_bus_req or a B device set b_bus_req in peripheral role.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/otg_fsm.c | 13 -
> 1 f
On Wed, May 28, 2014 at 03:09:17PM +0800, Li Jun wrote:
> From: Li Jun
>
> This patch adds HNP polling support for chipidea otg fsm driver, which
> adds a SW timer to send HNP polling request.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/ci.h |2 ++
> drivers/usb/chipidea/ot
On Wed, May 28, 2014 at 03:08:20PM +0800, Li Jun wrote:
> From: Li Jun
>
> This patch adds host_request_flag in usb_gadget to store host request from
> application, clear the flag when otg leaves host state.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/common/usb-otg-fsm.c |4
> incl
On Wed, May 28, 2014 at 03:08:19PM +0800, Li Jun wrote:
> From: Li Jun
>
> This patch adds OTG status selector request sending function, can be used
> to poll peripheral if it wants to be host after OTG port is in host state.
You may just need to mention adding hnp polling API, and the usage of
Adding documentation for all the driver specific sysfs attributes.
Cc: Peter Stuge
Signed-off-by: Bjørn Mork
---
Documentation/ABI/testing/sysfs-class-net-cdc_ncm | 149 ++
1 file changed, 149 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-cdc_nc
The ethtool coalesce API is not applicable for this driver. Forcing
it to fit the NCM aggregation redefined the API in a driver specific
way, which is much worse than defining a clean new API. These ethtool
coalesce functions have therefore been replaced by a new sysfs API.
Signed-off-by: Bjørn Mo
After considering the comments received after the ethtool coalesce
support was commited, I have ended up concluding that we should
remove it again, while we can, before it hits a release. The idea
was not well enough thought through, and all comments received
pointed to advantages of using a sysfs
Cloning the big skbs we use for USB buffering chokes up TCP and
SCTP because the socket memory limits are hitting earlier than
they should. It is better to unconditionally copy the unwrapped
packets to freshly allocated skbs.
Reported-by: Jim Baxter
Acked-by: Eric Dumazet
Signed-off-by: Bjørn Mo
Attach a driver specific sysfs group to the netdev, and use it
for the rx/tx aggregation variables.
The datagram aggregation defined by the CDC NCM specification is
specific to this device class (including CDC MBIM). Using the
ethtool interrupt coalesce API as an interface to the aggregation
param
It doesn't matter whether the buffer size goes up or down. We have to
keep usbnet and device syncronized to be able to split transfers at the
correct boundaries. The spec allow skipping short packets when using
max sized transfers. If we don't tell usbnet about our new expected rx
buffer size, th
The mandatory GetNtbParameters control request is an important part of
the host <-> device protocol negotiation in CDC NCM (and CDC MBIM). It
gives device limits which the host must obey when configuring the
protocol aggregation variables. The driver will enforce this by
rejecting attempts to set a
We are calling usbnet_start_xmit() to flush any remaining data,
depending on the side effect that tx_curr_skb is set to NULL,
ensuring a new allocation using the updated tx_max. But this
side effect will only happen if there were any cached data ready
to transmit. If not, then an empty tx_curr_skb
The min_tx_pkt variable decides the cutoff point where the driver
will stop padding out NTBs to maximum size. The padding is a tradeoff
where we use some USB bus bandwidth to allow the device to receive
fixed size buffers. Different devices will have different optimal
settings, spanning from no pad
57 matches
Mail list logo
